The 2019 PCI North America Community Meeting was held two weeks ago in beautiful Vancouver, British Columbia, Canada. Along with the usual opportunities for networking with both new and existing community members, the conference provided some great takeaways for the many PCI standards themselves as well, including more sneak peeks into the much-anticipated PCI DSS v4.0. Version 4.0 of the PCI DSS stands to be the most significant update to the standard since the move from v2.0 to v3.0 in 2013. While the new standard will see many significant changes overall, one of the more intriguing changes will be the ability for assessed entities to opt for a defined implementation testing approach or a customized implementation testing approach (or a combination of both). We’ll discuss this in more detail and provide examples of how the customized implementation approach allows integration with other control-based examination frameworks such as System and Organizational Controls (SOC) examinations (SOC 1, SOC 2, SOC 3).
What is it?
With the introduction of the customized implementation testing approach, the PCI SSC appears to have responded to a frequent request from both assessors and assessed entities alike: having the ability to implement controls that meet the security intent of the PCI DSS requirements (an objective-based approach) without necessarily following the letter of the requirements word-for-word. So, what are these two approaches? The defined implementation testing approach is what we currently see today. Entities opting for a defined testing approach would follow the current PCI DSS requirements and testing procedures. The defined implementation approach provides defined procedures on how to meet the requirements. This is the same process that exists in the current PCI DSS, version 3.2.1. In the customized implementation testing approach, on the other hand, customized controls designed together between the assessed entity and the Qualified Security Assessor (QSA) may be implemented which meet the security intent of the requirement. Each requirement will have an expanded definition of the security intent of the requirement along with supplemental guidance. This allows greater flexibility for assessed entities to implement controls that may better align with their organizational objectives and still meet the PCI DSS requirements, even if the control is not specifically specified by the PCI DSS, and is likely best suited for entities with greater control maturity. In a way, it is like using a compensating control worksheet without having to provide a business, technical or legal constraint. Assessed entities will also have the ability to utilize a combined approach, meaning the ability to follow the defined implementation approach for some requirements, and a customized implementation approach for others.
What does this mean?
The introduction of these new testing approaches stands to provide assessed entities the ability to better align their PCI compliance initiatives with other compliance standards they may also be required to adhere to. Additionally, it introduces more flexibility into the PCI DSS standard as a whole, making it a bit more similar to other examination frameworks. SOC examinations would be a great example of this. For those who are unfamiliar, a SOC report, or System and Organization Controls report, is a report on controls at a service organization relevant to the service organization’s system. A SOC report comes in 3 flavors:
- SOC 1: Report on controls at a service organization relevant to user entities’ controls over financial reporting
- SOC 2: Report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy (Trust Services Criteria)
- SOC 3: Similar to SOC 2, but for general use
Additionally, a SOC report also comes in two types: a Type 1 report includes controls at a service organization as of a specified point in time, whereas a Type 2 report includes controls over a specified period of time (typically 6 or 12 months). While the different SOC reports serve different audiences and have different subject matter, there are similarities. All reports have overall control objectives (specified by the service organization for SOC 1 and specified by the Trust Services Criteria for SOC 2 and SOC 3), and all reports allow the entity undergoing the examination to define the controls in place to meet the control objectives.
Organizations familiar with the practice of defining controls to meet control objectives or the Trust Services Criteria are likely to feel a sense of greater flexibility in meeting the PCI DSS requirements especially where the organization’s control maturity enhances new or existing PCI DSS security requirements.
What’s Next?
The draft of PCI DSS version 4.0 is expected to be released to stakeholders in October 2019 with request for comments due around December 2019. Because significant changes are expected based on comments from assessors and participating organizations, entities considering the customized implementation approach should wait for the draft to be finalized before formally considering and discussing any customized implementation approach with their assessor. A minimum space of one year is expected between the final version and the effective date of PCI DSS v4.0
(Photo: Schellman's Jeff Lasker with Keynote Speaker Mike Massimino.)
About the Author
More Content by Jeff Lasker
