Customized Approach vs Defined Approach in PCI DSS v4.0.1: How to Choose

PCI DSS v4.0 introduced something the standard had never offered before: a formal choice in how you meet a requirement. For most requirements you can now follow the Defined Approach (do what the requirement says, exactly as written) or the Customized Approach (meet the requirement’s security objective with controls you design yourself).

Flexibility sounds attractive, and vendors have been quick to market “customized approach ready” products. But the Customized Approach is one of the most misunderstood features of PCI DSS v4.0.1, and choosing it for the wrong reasons creates more work, not less. As assessors, we spend a lot of time talking clients out of it, and occasionally into it. This guide explains how each approach works, what the Customized Approach really costs, and a practical rule for deciding.

The Defined Approach: the standard as written

The Defined Approach is PCI DSS as everyone has always known it. Each requirement states a control (“passwords must contain at least 12 characters”) and the assessor validates it using the testing procedures printed in the standard. It is predictable for you, predictable for your assessor, and predictable for the banks and partners who read your attestation.

Within the Defined Approach there is one long-standing flexibility mechanism: compensating controls. If a legitimate, documented technical or business constraint prevents you from meeting a requirement as stated, you can implement an alternative control that goes above and beyond the original requirement’s rigour. Compensating controls are reviewed at every assessment and are intended as a bridge, not a destination.

The Customized Approach: meeting the objective your own way

Every requirement in v4.x carries a stated Customized Approach Objective: the security outcome the requirement exists to achieve. Under the Customized Approach, you design your own control to meet that objective, and your assessor designs their own testing procedures to validate it, because the standard’s printed testing procedures no longer apply.

The paperwork is substantial, and it is yours to produce, not the assessor’s. For every requirement met with the Customized Approach you must provide:

• A controls matrix documenting what the control is, how it operates, who runs it, and how it meets the stated objective.
• A Targeted Risk Analysis under Requirement 12.3.2 showing the customized control provides protection at least equivalent to the defined requirement. This is a different analysis from the frequency-setting TRA in 12.3.1, which we cover in our Targeted Risk Analysis guide.
• Evidence of testing and monitoring, because you must show the control actually works and keeps working, with maintenance procedures and defined metrics.

Your QSA then reviews all of it, derives bespoke testing procedures, tests the control, and documents the whole exercise in the Report on Compliance.

The restrictions people miss

Three hard limits decide the question for most organisations before any strategy discussion begins.

• No self-assessment. The Customized Approach is only available in a QSA-led assessment producing a Report on Compliance. If you validate with an SAQ, the Customized Approach is simply not on the table.
• Per requirement, not wholesale. You choose the approach requirement by requirement. Nobody “does a customized assessment”; a real ROC might use the Customized Approach for two or three requirements and the Defined Approach for everything else.
• It is not the easy road. The Council designed it for security-mature organisations with risk teams that can produce and maintain the documentation above. If the motivation is “we cannot meet the requirement”, the correct tool is usually a compensating control or, better, remediation.

Customized Approach vs compensating controls

These two are constantly confused, and the difference matters at assessment time.

When the Customized Approach genuinely makes sense

We see three situations where it earns its overhead.

1. Your technology genuinely outpaces the control as written. The classic example: requirement text built around traditional anti-malware or password rotation, while your environment uses advanced endpoint detection or passwordless authentication that meets the objective more effectively than the literal control.
2. Modern architectures where the literal control fits awkwardly. Immutable, short-lived container infrastructure can satisfy some objectives through rebuild-and-redeploy patterns rather than the traditional processes the defined requirement assumes.
3. Mature risk organisations that already produce this evidence. If your security team already maintains control documentation, testing evidence and risk analyses at this standard, the marginal cost of the Customized Approach is small, and it lets you keep well-engineered controls instead of bolting on parallel ones just to satisfy wording.

Outside those cases, the Defined Approach is almost always cheaper, faster and less contentious. In our assessment work across New Zealand and Australia, the overwhelming majority of requirements are still validated the defined way, and that is the right outcome.

A practical decision rule

For each requirement where you are tempted by the Customized Approach, ask three questions in order. First: can we simply meet the requirement as written? If yes, do that. Second: if we cannot, is the blocker a temporary constraint? If yes, use a compensating control and plan remediation. Third: do we have a better-than-standard control, plus the risk-analysis and documentation capability to prove equivalence every year? Only a yes here justifies the Customized Approach, and it is worth a conversation with your QSA before you commit, because early alignment on how the control will be tested prevents unpleasant surprises mid-assessment.

Frequently asked questions

Is the Customized Approach easier than the Defined Approach?

No. It removes the prescriptive control but replaces it with a documentation and evidence burden that is heavier: a controls matrix, a Requirement 12.3.2 Targeted Risk Analysis, testing evidence, and bespoke assessor validation. It exists for mature organisations that want flexibility, not for organisations looking for a shortcut.

Can we use the Customized Approach in our SAQ?

No. It is available only in assessments performed by a QSA (or ISA) resulting in a Report on Compliance. Self-assessment questionnaires use the Defined Approach only.

Do we have to pick one approach for the whole assessment?

No. The choice is made requirement by requirement. Most organisations that use the Customized Approach at all apply it to a small handful of requirements and validate everything else the defined way, and both approaches can even be blended for a single requirement applied to different system components.

What happens if our QSA does not accept our customized control?

The assessor must be satisfied the control meets the Customized Approach Objective and that the evidence supports it. If not, the requirement is not in place, exactly as if a defined control had failed. This is why we recommend involving your assessor while the control and the 12.3.2 analysis are being designed, not after.

Talk it through before you commit

Cianaa’s QSAs assess both approaches and can tell you quickly, and honestly, whether a customized control is worth the overhead in your environment or whether the defined path gets you there with less friction. If you are weighing this decision for an upcoming assessment, talk to our assessors or start with our PCI DSS services overview.