PCI DSS 4.0 – Welcomed Changes On The Way
If you are in the Payment Card Industry (PCI) community, you are likely aware of a new version of the Data Security Standard (DSS) on the horizon. It is definitely time. The last major revision of the standard was from version 2.0 to 3.0 in late 2013. While the PCI Security Standards Council (SSC) has released three iterative updates since, those changes mostly added clarification and a few additional requirements. So, with news of version 4.0 in the works, there are plenty of questions around just what kind of update the PCI SSC had in mind. Well, the PCI community got a glimpse of some of those changes at this year’s PCI North America Community Meeting this week in Vancouver. Spoiler alert. This appears to be a pretty big overhaul.
While version 4.0 isn’t finalized and still considered in draft, the most impactful change is already clear. The PCI SSC has rightly shifted the focus of the requirements from prescriptive “you must” type language to a more direct focus on the desired security outcome. This addresses one of the key challenges with the DSS for some time. That is, the current prescriptive statements are pretty rigid. The effect of this is organizations may often times meet the intent of the requirement but not in the way prescribed in the DSS. With the rapid advancements of technology solutions and capabilities as well as considering each organization’s uniqueness in its architecture, security capabilities, and personnel, there is a real need to enable flexibility for organizations to demonstrate compliance. So how does this play out in the standard itself? The PCI SSC has documented two different ways for organizations to validate these requirements: Defined and Customized. Each approach is described briefly below. The golden nugget here is that organizations can use either of these approaches on any of the requirements throughout the DSS and can use both within a PCI assessment.
Defined Approach
Let’s tackle the Defined approach first as this is what happens today and is not a new strategy. The Defined approach simply means you follow the current PCI DSS requirements and testing procedures as written. This is still a helpful and valid approach as many organizations already align with the current requirements and do not have a need for any custom approach to meeting the control objectives. Also, some organizations will continue to benefit from the more prescriptive direction on how to meet the objectives. Again, no changes here as this is what organizations do today.
Customized Approach
Remember, the new focus from the PCI SSC is on security outcomes and the intent of the control. The Customized approach allows for this by giving organizations the flexibility to demonstrate how they have met the intent of the control and arrived at the desired security outcome of the requirement. While this allows for more flexibility, it isn’t a “Get Out of Jail Free” card either. For each requirement where this approach is leveraged, organizations have the responsibility to document the control, how it meets the intent or the security outcome, provide sufficient evidences to support this, as well as how those controls are maintained and remain effective.
For those seasoned PCI professionals and Qualified Security Assessors (QSA) out there, you may be thinking this Customized approach sounds a lot like current compensating controls. You are correct. Compensating controls have always existed to allow for organizations to document and demonstrate how they meet the intent of the control differently than the prescribed control. The PCI SSC acknowledged this as well and that the move to the Customized approach is a maturation of the compensating controls process. This movement is further cemented by the fact that compensating controls are not included in the current draft of the 4.0 DSS. Yes, you read that correctly. This just further signals the SSC’s direction and commitment to an outcome-based approach.
Are there still some unanswered questions here? Yes. Is there some concern over how this plays out, specifically when an organization and their QSA disagree on the Customized approach not achieving the desired security outcome? Definitely. Regardless, those growing pains will be well worth it. This change is a welcomed one and is a great sign of the overall direction of the PCI SSC. Enabling and accommodating for robust risk management approaches is a win for both organizations and QSAs alike.
So, the million-dollar question is when can organizations start to take advantage of this? Well, the answer is…not yet. Version 4.0 of the DSS is still in draft. The PCI SSC is releasing it to participating organizations and QSAs through a formal Request For Comment (RFC) process next month. This will allow time to review not only the topics mentioned above, but also a large number of overall requirement changes the PCI SSC hinted at. Based on the amount of feedback they receive and subsequent suggestions for changes, the timeline appears to be late next year, or early 2021 – knowing it could shift either direction based on several different factors. Regardless, the best news is the PCI community can already know it will be worth the wait.
If you are interested in additional thoughts on the upcoming version of the DSS, the PCI SSC recently published a blog on the change discussed in this article and addressed a few other questions regarding the DSS v. 4.0 here.
About GuidePoint Security
GuidePoint Security provides trusted cybersecurity expertise, solutions and services that help organizations make better decisions that minimize risk. By taking a three-tiered, holistic approach for evaluating security posture and ecosystems, GuidePoint enables some of the nation’s top organizations, such as Fortune 500 companies and U.S government agencies, to identify threats, optimize resources and integrate best-fit solutions that mitigate risk.
Contributing Author
Gary Brickhouse, VP, GRC Services & CISO, GuidePoint Security
Gary is responsible for all aspects of GuidePoint’s Governance, Risk, and Compliances services including: building and managing the GRC team; offering and collateral development; pre-sales and sales enablement support; practice methodology; and service delivery.