PCI DSS 4.0 – Defined Approach vs. Customized Approach

Part 2 of the PCI DSS 4.0 Launch Series

The content of this blog is based solely on the PCI Data Security Standard (DSS) version 4.0 and related validation documents and does not incorporate any additional clarification/guidance provided by the PCI Security Standards Council (SSC) after the date of this blog.

Under PCI DSS version 4.0, entities can now leverage both the Defined Approach and/or the Customized Approach to achieve and maintain compliance.

The Defined Approach is basically the same methodology from prior versions – an explicit detailed control statement and related specific testing procedures the assessor must complete to confirm the control is in place.  Compensating controls are still an option and can be leveraged if needed.  This approach is ideal for organizations with less-mature security/compliance/risk programs, significant budget constraints, and/or existing controls that can easily align with the specific requirements.

One of the ongoing challenges to maintaining PCI compliance in many organizations is the specificity/prescriptiveness of the controls.  Some entities, especially those with more mature security/compliance/risk programs and/or those with significant business needs to deviate from the letter of the requirements, may benefit from the Customized Approach.  In this methodology, the entity selects controls that can be demonstrated to meet the Customized Approach Objective, even if those controls do not align with the corresponding Defined Approach Requirement, and the assessor develops appropriate testing procedures to confirm the controls meet the objective.

While this new approach supports innovation and flexibility, it also introduces significant additional work for both the entity and the assessor.  In order to use the Customized Approach for a given requirement, the entity must perform and document an extensive “targeted risk analysis,” with multiple required steps (shown in Appendix E), in addition to documenting, testing, and maintaining the customized controls.  The entity and the assessor “are expected to work together to ensure…they agree that the customized control(s) fully meets the customized approach objective.”  We are expecting additional guidance from the Council on how best to do this and resolve the unavoidable differences of opinion this will engender.  The assessor then must derive, as well as execute, appropriate testing procedures for the controls in question.

To make things even more fun, entities can use either approach for any given requirement.  In fact, entities can use one approach for some system components and the other approach for other system components within the same requirement.  The additional risk analysis work and testing procedure development work adds up in a hurry in this scenario and will have significant impact on the cost of assessments. We’ll be exploring changes to the ROC template, including the Customized Approach Template that has to be leveraged for every Customized Approach requirement, later in this blog series.

Each requirement in the PCI DSS 4.0 contains the following sections:

• Defined Approach Requirements – This is the requirement itself, now presented more clearly as a statement of fact in many cases.
• Defined Approach Testing Procedures – Just like previous versions, these are the steps the assessor must take to verify the Defined Approach Requirements are both in place and have been in place (especially for requirements with activities specifically recurring or ongoing throughout the prior year).  NOTE:  Specific sampling procedures have been removed from individual requirements; sampling can be leveraged by the assessor wherever appropriate, within parameters described in Section 6 of the DSS.
• Customized Approach Objective – This is a restatement of the Defined Approach Requirement, worded more like a control objective seen in other cyber security standards in order to support the entity’s selection of controls sufficient to the meet the objective.
• Applicability Notes – This is additional direction/detail in support of the requirement, regardless of Approach, and “must be fully considered during an assessment.”  In other words, it is part of the standard and is as binding as the requirement wording itself.
• Guidance – Just like previous versions, this is additional background/detail to help entities understand the nature and intent of the requirement and how to meet it.  This is the only section of the requirement that is not binding.  The content in this section has been significantly expanded for many requirements.

In Part 3 of this blog series, we’ll take a look at some of the major new and updated requirements in Version 4.0.