PCI DSS 4.0 introduced a second way to meet a requirement. Alongside the defined approach, where you implement the requirement as written, the customized approach lets you design your own control to meet the requirement's stated objective. It was the most discussed change in the new version, and it is the least understood.
The common assumption is that it offers flexibility at lower cost. The reverse is closer to true. The customized approach trades prescriptive wording for a heavier burden of proof: you document the control, analyze its risk, test it yourself, and give your assessor enough to design a test of their own.
This article covers what the approach is, where it is available, what you must produce, how your assessor tests it, when it makes sense, and how it differs from compensating controls.
What the customized approach is
Each requirement in PCI DSS 4.0.1 is laid out in parts: the defined approach requirement and its testing procedures, a purpose statement, applicability notes, guidance and, for most requirements, a customized approach objective. The objective states the outcome the requirement exists to achieve, written so it does not depend on a particular technology.
Under the customized approach, you meet that objective with a control you design. Your assessor does not use the defined testing procedures, because they test the defined requirement. Instead, the assessor derives testing procedures for your control from your documentation.
The standard positions this for organizations with mature risk management that can show a control works, not as a default. You can use both approaches in one assessment: customized for a handful of requirements, defined for the rest.
Where it is available
Two limits apply.
Not every requirement has an objective. Where a requirement has no customized approach objective, the defined approach is the only option.
Not through self-assessment. The self-assessment questionnaires do not support the customized approach. If you want to use it, expect to validate with a report on compliance, prepared by an assessor.
Whether you may validate with a report on compliance or must use a particular method is set by card brands and acquirers, as covered in QSA vs ISA: who assesses PCI DSS.
What you must produce
Appendix D of the standard sets out what an entity using the customized approach must do for each customized control. Appendix E provides sample templates for two of the documents. In summary, you must:
Document the control in a controls matrix. Appendix E1 is the sample template. Among other things, it records the requirement and its objective, what the control is, how it meets the objective, who is responsible, and how it is tested and monitored.
Perform a targeted risk analysis. Requirement 12.3.2 asks for one for each requirement met with the customized approach. Appendix E2 is the sample template. The analysis must be approved by senior management and performed at least once every 12 months.
Test the control yourself. Document what was tested, how, when and the results, in the controls matrix.
Monitor and keep evidence of effectiveness. Not a single test, but ongoing evidence that the control keeps meeting the objective.
Give it all to your assessor. The controls matrix, the risk analysis, your testing evidence and your effectiveness evidence.
The targeted risk analysis here is not the same exercise as the one under 12.3.1, which justifies frequencies for defined requirements that let you choose them. The 12.3.2 analysis argues that a control you designed protects as well as the defined requirement would. It needs to name what could go wrong if the objective were not met and explain how your control prevents or detects it.
How your assessor tests it
Your assessor reads the controls matrix and the risk analysis, decides whether the control as designed would meet the objective, and then writes testing procedures to confirm it does. Those procedures, and the results, go into the report on compliance.
Expect two things. First, more time. The assessor is designing a test rather than following one, and will ask questions the defined procedures never would. Second, a higher bar for evidence. A defined requirement can be tested against its own wording. A customized control is tested against an outcome, so your evidence has to show the outcome.
Independence matters here too. If your assessor's firm helped you design the control, ask early how its independence rules apply. Designing a control and then assessing it is the situation those rules exist to prevent.
When it makes sense, and when it does not
The customized approach earns its overhead in a narrow set of cases.
It fits when:
The defined wording assumes a technology or architecture you do not use, and your design meets the objective in a different way
You already run a control that is stronger than the defined requirement, and meeting the defined wording as well would add cost without adding security
You have the risk management maturity to write and maintain the controls matrix and risk analysis every year
It does not fit when:
You want to avoid a requirement. The objective still has to be met, and shown to be met.
You cannot meet a requirement because of a technical or business constraint. That is what compensating controls are for.
You self-assess. The SAQs do not support it.
It is your first assessment under the standard. Learning the defined requirements first gives you, and your assessor, a baseline.
Consider a hypothetical. Say a payments company never allows interactive logins to production. Engineers request access through a workflow that issues a short-lived credential for one task and records every command. The defined wording of some authentication requirements assumes long-lived accounts. A customized control could meet the objective more directly, if the company can show its testing and monitoring, and its assessor agrees the outcome is met.
How it differs from compensating controls
The two are easy to confuse. They answer different questions.
| Defined approach | Customized approach | Compensating control | |
|---|---|---|---|
| What you meet | The requirement as written | The requirement's objective | The intent and rigor of the requirement, through other means |
| When it is used | By default | By choice, where an objective exists | Only when a legitimate, documented constraint prevents the defined requirement |
| Key documents | Your normal evidence | Controls matrix and targeted risk analysis | Compensating controls worksheet |
| Self-assessment | Yes | No | Yes, with the worksheet |
Compensating controls belong to the defined approach. They exist because you cannot meet the requirement as written. The customized approach exists because you have chosen to meet the objective differently. A later article in this series covers compensating controls in depth.
Getting started
If you think a requirement is a candidate:
Read its customized approach objective, purpose and guidance together.
Write one paragraph explaining how your control meets the objective. If the paragraph is hard to write, stop there.
Draft the controls matrix and targeted risk analysis from the Appendix E templates.
Share them with your assessor before fieldwork, and ask how they would test the control.
Decide only then, with the effort in front of you.
For the wider context of the 4.0 changes, see what changed in PCI DSS 4.0. The PCI DSS framework page summarizes the requirements by section.
How TrustLynce helps
TrustLynce keeps each targeted risk analysis in the risk register with its owner, approval and annual review date. The controls matrix maps to your other framework controls through compliance automation, so evidence you test once can support several requirements.