In this interview with the Council’s Global Head of Standards, Emma Sutcliffe, we address key questions about the upcoming request for comments (RFC) on a first draft of PCI Data Security Standard Version 4.0 (PCI DSS v4.0). PCI DSS v4.0 is a key discussion topic at the 2019 PCI Community Meetings this week in Vancouver, next month in Dublin and in Melbourne in November.
1. What documentation will be included in the October RFC on PCI DSS v4.0?
Emma Sutcliffe: The October RFC will include a first draft of PCI DSS v4.0 and a sample of the draft reporting template for a proposed new validation method to support customized implementations. A Summary of Changes document that outlines the key changes in the draft will be provided, as well as guidance for stakeholders to help focus their reviews and maximize the value of their feedback. We recommend keeping the Summary of Changes close by while reviewing the draft updates, as the numbering and wording of all requirements will be different, and these supporting materials will help ease the review process.
The draft of PCI DSS v4.0 addresses feedback received during the 2017 RFC and reflects changes in payments environments and security technologies. The updates made to the standard focus on strengthening security and adding flexibility.
While the 12 core PCI DSS requirements remain fundamentally the same, several new requirements are proposed to address evolving risks and threats to payment data and to reinforce security as a continuous process. Additionally, all requirements are redesigned to focus on security objectives, and there is a new validation option that gives more flexibility to organizations using different methodologies to meet the intent of PCI DSS requirements.
PCI SSC stakeholder feedback will directly contribute to the evolution of the standard, including consideration of proposed new requirements. We hope all interested parties will participate in the upcoming RFC, which will run for six weeks. As a reminder, the RFC is open to Participating Organizations (POs), Qualified Security Assessors (QSAs), and Approved Scanning Vendors (ASVs).
2. How are the requirements being redesigned to focus on security objectives? Can you provide an example of what stakeholders will see in the draft standard in the upcoming RFC?
Emma Sutcliffe: With version 4.0, the Council is evolving the PCI DSS to support a range of evolving payment environments, technologies, and methodologies for achieving security. The requirements will be written as outcome-based statements focused on implementation of the security control as the end result. For many requirements, this is achieved by simply changing the language from stating what ‘must’ be implemented to what the resulting security outcome ‘is’. The draft of PCI DSS v4.0 also includes intent statements specifically linking each requirement to a security outcome. The intent statements directly support the new, customized validation approach by clearly identifying the security outcome that customized implementations are required to meet. This will clarify what needs to be achieved with more flexibility in ‘how’ the organization achieves the desired security outcome.
3. What is the new validation option to support this new outcomes-based approach? How is this different than compensating controls?
Emma Sutcliffe: Firstly, it is important to note that the traditional methods for validating PCI DSS are not going away with version 4.0. Entities with controls in place that meet the PCI DSS requirements as stated and that are comfortable with the current methods for validating how PCI DSS requirements are met can continue to use this approach.
The new validation option gives organizations the flexibility to take a customized approach to demonstrate how they are meeting the security intent of each PCI DSS requirement. This customized approach supports organizations using security approaches that may be different than traditional PCI DSS requirements. Through customized validation, entities can show how their specific implementation meets the intent and addresses the risk, providing an alternative way to meeting the requirement as stated. By offering two approaches to PCI DSS validation, entities can identify which approach is best suited to their security implementation for each PCI DSS requirement.
Customized validation is a natural evolution of compensating controls, which were designed as a mechanism for organizations to demonstrate how they meet the intent of PCI DSS requirements in a different way. Unlike compensating controls, customized validation will not require a business or technical justification for meeting the requirements using alternative methods, as the requirements will now be outcome-based.
Compensating controls will be removed from the draft version of the standard in the October RFC, and a draft sample of the reporting template for this customized validation option will be included so organizations can see and comment on this proposed approach.
4. What are some of the new and revised requirements to address evolving risks and threats to payment data?
Emma Sutcliffe: As I mentioned earlier, in the upcoming RFC the draft standard will include many proposed new and revised requirements. This is the first time we are sharing a draft of the standard for review and feedback, and we are really looking to our stakeholders to provide input on these draft changes.
Examples of some of the proposed new requirements include requirements for organizations to verify their PCI DSS scope and some additional requirements for service providers. There are also proposed revisions to requirements on passwords to accommodate different authentication options, and an update to the risk assessment requirement to provide greater clarity and guidance for organizations on the risk management process.
I’d also like to emphasize the point that the PCI DSS version being provided for RFC is a draft only. There may be requirements added, removed, or changed before the standard is finalized sometime late next year. This is a real opportunity for stakeholders to provide feedback about potential new requirements before they are finalized in the standard.
5. Will version 4.0 address the cloud?
Emma Sutcliffe: PCI DSS has always been technology neutral, in that requirements are intended to apply to all type of environments and support whatever technology being used. The draft of PCI DSS v4.0 further supports the use of different technologies, such as cloud, by introducing more flexibility to the wording of requirements and adding intent statements.
The standard is also supported by information supplements that provide guidance and considerations for applying PCI DSS to specific technologies, including cloud environments. The guidance from these information supplements is being reviewed for potential inclusion in the draft. Also, the draft of Appendix A1 is being reviewed to provide clarity around the role and expectations for cloud providers.
Also on the blog: 3 Things to Know about PCI DSS v4.0 Development
