The customized approach is one of the most talked-about additions in PCI DSS 4.0, which the PCI Security Standards Council published on March 31, 2022. It lets an organization meet a requirement's stated security objective with a control it designed itself, instead of implementing the requirement exactly as written. The flexibility comes with conditions: a controls matrix, a targeted risk analysis for each customized requirement under Requirement 12.3.2, senior management sign-off, and testing procedures that your assessor designs specifically for your control. It isn't available if you validate with a Self-Assessment Questionnaire (SAQ), and some requirements aren't eligible at all.
Here's how it works, what it costs you in effort, and how to tell whether it fits your organization.
What is the customized approach in PCI DSS 4.0?
PCI DSS 4.0 gives you two ways to meet a requirement. The defined approach is the familiar one: implement the requirement as written and let the assessor test it with the procedures published in the standard. The customized approach starts from the outcome instead.
Most requirements in 4.0 include a customized approach objective, which is a short statement of what the requirement is meant to achieve. Under the customized approach, you design a control that meets that objective, then prove to your assessor that it works and keeps working.
The Council has described the customized approach as intended for risk-mature organizations. It's a way to accommodate different technologies and security architectures, not a shortcut around requirements you find inconvenient.
How is it different from the defined approach and compensating controls?
The customized approach is easy to confuse with compensating controls, but the two solve different problems. Compensating controls belong to the defined approach. You use them when a legitimate technical or business constraint prevents you from meeting a requirement as written. The customized approach is for organizations that choose to meet the objective differently, with no constraint needed.
| Defined approach | Defined approach with compensating control | Customized approach | |
|---|---|---|---|
| When it's used | Default for most requirements | A legitimate constraint prevents meeting the requirement as written | The organization chooses a different way to meet the objective |
| What you implement | The requirement as written | Alternative controls that address the requirement's intent | A control you design to meet the customized approach objective |
| Who writes the test procedures | Published in the standard | Assessor, based on the compensating control | Assessor, derived for your specific control |
| Key documentation | Standard evidence | Compensating control worksheet | Controls matrix, targeted risk analysis, testing and monitoring evidence |
| Available with an SAQ | Yes | Yes | No |
You don't have to choose one approach for your whole environment. You can use the defined approach for most requirements and the customized approach for one or two where it makes sense.
What is a customized approach objective?
Each objective describes the outcome a requirement exists to produce, stated independently of any particular technology. Take Requirement 8.3.6, which sets a minimum password length and complexity. Its customized approach objective says, in effect, that a guessable password shouldn't be verifiable through an online or offline brute-force attack. The defined requirement tells you how to get there. The objective tells you where "there" is.
A customized control has to meet the whole objective. Meeting part of it, or meeting it only for some of the systems the requirement covers, isn't enough.
Which requirements aren't eligible?
Not every requirement can be customized. Several requirements have no stated customized approach objective, and the standard says plainly that the customized approach isn't an option for them. Check the specific requirements you have in mind before you invest any design effort.
What documentation does the customized approach require?
Appendix D of PCI DSS 4.0 sets out what the organization must produce and maintain for each customized control. Appendix E provides sample templates. You don't have to use those templates, but your documentation must contain everything they ask for.
At a minimum you'll need:
- A controls matrix for each customized control
- A targeted risk analysis for each requirement met with the customized approach
- Evidence that you've tested the control and that it works
- Evidence that you monitor and maintain the control's effectiveness over time
The controls matrix
The controls matrix describes the customized control in enough detail for an assessor to understand and test it. The sample in Appendix E1 asks for the requirement and its objective, and for what the control is, where and when it operates, and who is responsible for it. It also asks how the control meets the objective, and how you test and monitor it.
Treat the matrix as a design document, not a form to fill in afterwards. If you can't clearly explain how the control meets the objective, the assessor won't be able to either.
The targeted risk analysis under Requirement 12.3.2
Requirement 12.3.2 requires a targeted risk analysis for each PCI DSS requirement you meet with the customized approach. The analysis must include documented evidence covering every element in Appendix D, including at least a controls matrix and a risk analysis. Senior management must approve it, and you must perform it again at least once every 12 months.
Unlike many new 4.0 requirements, 12.3.2 isn't future-dated. It applies as soon as you use the customized approach.
The sample template in Appendix E2 walks through five stages:
- Identify the requirement. Name the requirement and its customized approach objective.
- Describe the proposed solution. Explain what the customized control does and how it meets the objective.
- Analyze changes to likelihood. Assess how the customized control changes the likelihood of the "mischief" the requirement is designed to prevent. The template uses that word for the threat or undesired outcome behind the objective.
- Analyze changes to impact. Assess how the customized control affects the impact if unauthorized access to account data occurs.
- Approve and review. Record senior management approval and set up the ongoing review.
The central questions are how your control affects the likelihood and impact of that mischief, and whether you can back your answer with evidence. If you can't, the customized control isn't ready.
Testing and monitoring evidence
You're expected to test your own customized control before the assessor does, and to keep testing it. Your evidence should show the control operating over time, not just on the day of the assessment. That usually means logs, reports, test results and records of how you responded to failures.
How does an assessor validate a customized control?
The assessor starts with your documentation. They check that the controls matrix and risk analysis are complete and that the control, as described, would meet the objective.
They then derive their own testing procedures for your control. The standard doesn't publish procedures for customized controls, because each control is different. Your controls matrix informs the assessor's testing but doesn't replace it. Finally, the assessor carries out those procedures and documents the results in the Report on Compliance.
This has practical consequences. Expect more assessor time, and so more cost, for every customized requirement. Expect questions about design and evidence that a defined-approach assessment would never raise. Involve your assessor early, before you've built anything, so there are no surprises about what evidence they'll need.
Because this validation depends on assessor-derived testing, the customized approach isn't supported in SAQs. Organizations that validate by self-assessment use the defined approach, with compensating controls where needed.
Who should use the customized approach?
The customized approach is a good fit when most of these are true:
- You already run a mature risk management program. You perform formal risk analyses, senior management engages with them, and decisions are documented.
- You design and test your own controls. You have internal testing or internal audit capability that can produce evidence on its own schedule, not just at assessment time.
- Your architecture doesn't match the defined wording. For example, your access control, network segmentation or authentication model achieves the objective but doesn't match the defined requirement's assumptions.
- You validate through an assessor-led Report on Compliance. The customized approach isn't available through self-assessment.
- The benefit justifies the overhead. Customizing one requirement across a large environment can make sense. Customizing to avoid a modest change usually doesn't.
For most small and mid-sized organizations, the defined approach will remain the simpler and cheaper route. That's not a failure of ambition. The defined approach is well understood, predictable to assess and fully valid.
If you're facing a one-off constraint, such as a legacy system that can't support a specific setting, compensating controls are usually the better tool. The customized approach is for deliberate design choices, not temporary gaps.
Frequently asked questions
Can we use the customized approach if we complete an SAQ?
No. The customized approach isn't supported in SAQs. It requires assessor-derived testing procedures, which only fit an assessor-led Report on Compliance.
Can we mix the defined and customized approaches?
Yes. The approach is chosen requirement by requirement. Many organizations that use the customized approach will do so for a small number of requirements and use the defined approach everywhere else.
Is the customized approach available now?
Yes, once you're assessed against PCI DSS 4.0. Version 3.2.1 remains valid until March 31, 2024, and it has no customized approach. Requirement 12.3.2 isn't future-dated, so if you customize a requirement in a 4.0 assessment, the supporting risk analysis is required from the start.
Will the customized approach reduce our compliance effort?
Rarely. Each customized requirement adds a controls matrix, a risk analysis, management approval, ongoing testing evidence and extra assessor work. Its value is flexibility, not savings.
Next steps
- Read the customized approach objectives for the requirements that cause you the most friction today. Sometimes the objective shows that the defined requirement is easier to meet than you assumed.
- Before you plan a customized control, confirm that the requirement actually has a customized approach objective. Without one, customization isn't an option.
- If you're considering customization, draft the controls matrix and the Appendix E2 risk analysis before you build or buy anything. If you can't make a convincing case on paper, you won't make one to an assessor.
- Talk to your assessor early about evidence expectations and the likely effect on assessment effort.
- If you validate with an SAQ, focus on the defined approach and use compensating controls for genuine constraints.