The Designated Entities Supplemental Validation (DESV) is an additional documentation that Qualified Security Assessors (QSA) can - or in some cases have to - use to validate organisations that must be PCI DSS compliant. PCI DSS v3.2 was released in April 2016 and it officially introduced this additional set of instructions.

The document was first released in June 2015 (that's why it reads "For use with PCI DSS v3.1") and it has been created for a particular category of organisations. Before we continue digging into it, I suggest you to download version 1.0 of the original document from the PCI SSC public repository.

Here you will find as well the Supplemental AOC for Onsite Assessments, the Supplemental Report on Compliance and  a press release from June 2015 where you can read the following:

“Locations that aggregate large amounts of cardholder data remain at greater risk of being the target of a focused attack,"

That's what Troy Leach (PCI Security Standards Council Chief Technology Officer) said. And he continues:

“Breach trends continue to point to this, which is why the latest version of the PCI DSS already includes greater stringency around security of dependent services and active monitoring for new threats. The PCI DSS Designated Entities Supplemental Validation procedures are not new requirements, but criteria that can help any organization in assessing and documenting how it’s maintaining existing PCI DSS controls on an ongoing basis.”

What is the purpose of the PCI DSS Designated Entities Supplemental Validation?

The DESV was created to support organizations protecting the payment and personal data involved in the transactions - but not only - that their clients make to purchase their products and services. The goal is to make certain payment security practices become a recurring activity devoted to keep your organisation compliant at all time and protect payment data from compromise.

While the DESV was created to support organisations that deal with a large amount of clients (and consequently handle a lot of payment and personal data), it is strongly suggested to all organizations to apply the procedures described in this supplemental validation "to ensure ongoing compliance and security throughout the year".

The organisations that must apply the guidelines contained in this additional document, are those "entities designated by a payment brand(s) or acquirer as requiring additional validation of existing PCI DSS requirements".

Here is a general overview of the type of organisations that must use the DESV:

  • Those storing, processing, and/or transmitting large volumes of cardholder data,
  • Those providing aggregation points for cardholder data, or
  • Those that have suffered significant or repeated breaches of cardholder data.

The supplemental validation steps are intended to be a recurrent practice, business-as-usual (BAU) processes. Following the same structure used for the PCI DSS 3.2 official document and previous releases, the Designated Entities Supplemental Validation document is divided into sections (DE) that describe how to control specific areas:

  • DE.1 - Implement a PCI DSS compliance program.
  • DE.2 - Document and validate PCI DSS scope.
  • DE.3 - Validate PCI DSS is incorporated into business-as-usual (BAU) activities.
  • DE.4 - Control and manage logical access to the cardholder data environment.
  • DE.5 - Identify and respond to suspicious events.

These sections deliver important information that has to be applied in addition to the one already contained in the PCI DSS 3.2, the leatest version released of the standard.

For example, PCI DSS requirement 12 explains how to create a security awareness program and the DE.1 adds important guidelines regarding executive management's responsibilities, accountability, definition of Roles and Responsibilities within the organisation and deeper analysis and maintenance guidelines for the information included in the program itself.

DE.2 is about validating the scope of the PCI DSS and brings additional information and procedures that have to be flanked to all the 12 PCI DSS requirements.

DE.3 is about implementing a process to immediately detect and alert on critical security control failures. Examples of critical security controls include, but are not limited to:

  • Firewalls
  • IDS/IPS
  • FIM
  • Anti-virus
  • Physical access controls
  • Logical access controls
  • Audit logging mechanisms
  • Segmentation controls (if used)

These are just some examples showing the added value of the Designated Entities Supplemental Validation. I strongly suggest you to read the official document from the PCI Council website. Anybody can access it, read it and understand it.

Having questions about these additional instructions is just natural at this point, considering that the DESV is a pretty new document. The PCI Council thought about this too, and prepared an additional document that answers the most recurrent question marks. Find it here.

And don't forget to take a very good look at the PCI DSS 3.2 release too. If you are struggling to comply with PCI DSS v3.2, well you know where to find us!

Advantio_Blog_Banners_PCI-DSS-WhitePaper_V1.1

 

Column Header Text Column Header Text Column Header Text

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Discover More

Advantio_Blog_DNS_Diagram_V1 Image caption goes here. This is HTML text.

Marco Borza

Written by

I am the Founder of Advantio.
Technology has been my passion since I was a kid; when I first heard the handshake of an old 300bps modem I realised security would be key in an interconnected world. Since then it has become my passion and primary focus.
The reason why I've started my own business is to make IT Security simple.

Certifications: CISSP / CCSA (Checkpoint) / ITIL Foundations / ACSA (ArcSight)/ Linux+/ PCI-QSA / PA-QSA

Schedule a call with an expert