Defined Approach

Expanded Definition

The defined approach is PCI DSS’s prescriptive compliance model: the organisation implements the exact control requirements in the standard and demonstrates conformance through the standardised testing procedures. It is the clearest path when a team wants predictable expectations and repeatable audit evidence.

Its boundary is important. The defined approach is about following the control text as written, not tailoring the control objective to a custom architecture. That makes it different from a more flexible “design your own control, then prove equivalence” mindset. In practice, the approach works best when the payment environment can adopt the required safeguards without major exceptions, and when the organisation values simplicity in assessment over design freedom.

PCI DSS still expects the controls to be effective, not just present. So the defined approach is not a shortcut around security outcomes, it is a prescribed route to them. A common misunderstanding is to treat it as “minimum effort compliance”; in reality, the standard’s testing criteria can still be demanding, especially where segmentation, logging, or access restriction must be shown consistently.

Examples and Use Cases

• A merchant deploys the required logging, password, and network segmentation controls exactly as written, then uses the prescribed PCI DSS test steps to evidence compliance.
• A payment processor prefers the defined approach because auditors can compare implementation directly against the standard without assessing custom compensating logic.
• An organisation with a conventional cardholder data environment chooses the defined approach to reduce interpretation risk and keep control ownership straightforward.
• A team uses the defined approach for recurring assessments where stable infrastructure makes fixed control expectations easier to maintain than bespoke control narratives.
• A company avoids custom control design because the operational tradeoff is clear: less flexibility, but faster review and less ambiguity during validation.

For many teams, the practical advantage is consistency. The downside is that if the environment is unusual, highly distributed, or heavily abstracted, strict prescription can become awkward and may require more redesign than a customised approach would.

Security Implications

The security value of the defined approach is that it reduces ambiguity. When controls are implemented exactly as required, there is less room for interpretive drift between design, operations, and assessment. That can improve baseline discipline for access restriction, monitoring, and system hardening.

The main failure mode is superficial compliance, where controls exist on paper but are not operating as intended. Fixed-control models can also encourage checkbox behaviour if teams optimise for passing the test rather than reducing real exposure. In that case, the organisation may satisfy the assessment while leaving gaps in segmentation, logging coverage, or exception handling.

Another practical issue is control rigidity. If the environment changes faster than the standard or the implementation process, teams can accumulate exceptions, inconsistent configurations, or assessment friction. The most useful practitioner observation is that the defined approach succeeds when ownership is clear and control states are kept stable enough for repeatable validation.

Security, Operational and Governance Implications

The defined approach is a governance choice as much as a compliance choice. It signals that the organisation prefers a control model with low interpretive variance, clear evidence, and a direct relationship between requirement text and implementation. That can simplify accountability across security, operations, and audit functions.

Its operational consequence is that change management becomes tightly coupled to compliance maintenance. Teams need to know when a new system design, exception, or third-party dependency affects the prescribed control set, because the approach leaves less room to argue that an alternate design is “equivalent” in practice.

This is why the defined approach is often attractive in mature, well-understood payment environments. It provides a stable baseline, but it also places pressure on documentation hygiene, configuration consistency, and evidence collection discipline. If those are weak, the approach exposes the gap quickly.

Related resources from NHI Mgmt Group

• What is the difference between the defined approach and the customized approach in PCI DSS 4.0?
• How should organizations approach the governance of AI agents?
• Why do APIs need a different approach than user authentication for post-quantum readiness?
• When does OIDC federation work better than a vault-based approach?