Compliance with the controls of the PCI SSC standards is governed by two elements that work together: the standard as such and its related validation program. Here we explain their differences.

Where an entity requires proof of compliance with a particular security standard, it is necessary to identify:

  • Why is the entity required to demonstrate compliance?
  • Who is requesting that compliance?
  • To whom is it necessary to prove that the entity complies?
  • How is that compliance demonstrated?
  • Is it an internal request (by Internal Audit, for example) or external request (by a customer, by a supplier, for government reasons, etc.)?
  • What controls are applicable?
  • What is the risk if such compliance is not demonstrated?

This process is part of the compliance activities (compliance) of the GRC framework (Governance, Risk Management, and Compliance). Once these questions are answered, it is possible to articulate the necessary and complementary activities with the risk management and corporate governance components to carry out the compliance program that has been identified.

Relationship between GRC concept blocks. Source: www.deacosta.com

This task is not unrelated to compliance with the requirements described in the standards of the Payment Card Industry Security Standards Council (PCI SSC). As described in the article What is PCI DSS?, the PCI SSC is composed of five founding entities (AMEX, Discover, JCB, MasterCard and Visa) and one new member (China UnionPay):

Recall that the origin of the PCI SSC took place when these companies, competing with each other, sought the implementation of a common security framework for the protection of card data. For this reason, the original task of the PCI SCC was the centralisation and formalisation of a set of security controls that should be fulfilled by those entities that process, store or transmit card data or offer services that could affect the security of such environments.

And it is precisely at this point that the confusion comes: Many entities (and even their own) Qualified Security Advisors – QSA) tend to have ambiguities regarding the definition of responsibilities in terms of compliance by not distinguishing between who is responsible for defining security controls and who lays down the rules under which those controls are to be assessed.

What is a standard?

In this context, A standard is a set of physical, logical, administrative, and documentary security controls aimed at protecting a specific set of data.. In the case of PCI Security Standards Council (PCI SSC), this entity has developed multiple safety standards They define specific security requirements oriented towards the protection of each of the areas related to the security of payment card data, from its printing in plastic through its capture and authentication in face-to-face and non-face-to-face payment channels, to the security of the devices responsible for providing cryptographic routines for the protection of the associated data.

These standards are published in the PCI SSC website They are usually accompanied by other supporting documents such as Frequently Asked Questions (FAQs), supplementary guides and additional material. Likewise, a series of forms are included for the reporting of compliance by the affected entities.

What is a validation program?

On the other hand, and in a complementary way, each of the payment brands that are part of the PCI SSC individually define who should implement the standards defined by the PCI SSC, how they should evaluate it, how compliance should be reported, how many should perform these validations and what happens if an entity does not comply or has a security incident that affects the card data it manages (fines and penalties). This is called a ‘validation programme’ or ‘compliance programme’.. In some cases, payment brands usually manage listings of entities that meet the standards of the PCI SSC as is the case of Visa with the Global Supplier Registry or MasterCard with your list of registered service providers.

That being the case, usually each payment brand (payment brand) maintains its own validation (or compliance) program which stipulates the rules it deems necessary to protect the data of payment cards issued under its brand.

Although this criterion ruled for many years, PCI SSC itself has for some time been able to perform both standards development and associated validation program management functions, as is the case with P2PE, PCI SSF, CPoC, SPoC and Mpocc standards, where the PCI SSC maintains a list of entities that meet these standards.

Validation standards and programs

In the following table you can identify if a particular standard is managed by a validation program (or compliance) of the payment marks or if on the contrary the PCI SSC itself manages both the standard and the program:

 

StandardAssociated with a PCI SSC validation programAssociated with a payment brand compliance program
P2PEX
PCI SSF (Secure SSL and Secure Software)X
CPoC, SPoC and MpoccX
PCI PTS (POI and HSM)X
Card Production (Logical and Physical)X
PCI DSSX
PCI PINX
PCI Token Service Provider (TSP)X
PCI 3-D Secure (3DS)X

Taking into account this definition of responsibilities, if an entity has any questions regarding compliance with a certain standard, can be directed to payment brands (in the case where the standard is managed through a payment mark compliance program) or directly to the PCI SSC.

Posted by David Acosta

Qualified Security Assessor (QSA) for PCI DSS, PCI PIN, PCI 3DS, P2PE and PCI TSP. CISSP, CISA, CISM, CRISC, C|EH, C|HFI.

Leave to Reply