Category: PCI DSS Compliance
Defined Approach
Simply put
The evidence provided does not describe "Defined Approach" as it is used in payment security or PCI DSS. The available sources refer to "defined approaches" in the context of OECD toxicology and skin sensitization testing (OECD Guideline No. 497), which is an unrelated scientific domain. As a result, a payment-security definition cannot be generated from this evidence without inventing facts.
Formal definition
No PCI DSS-relevant evidence was supplied for this term. In PCI DSS usage, "Defined Approach" refers to the traditional method of meeting a requirement by implementing the stated controls and testing procedures, contrasted with the "Customized Approach"; however, none of the provided sources address this meaning. The supplied sources instead concern OECD-defined approaches to testing and assessment for chemical hazard endpoints (e.g., skin sensitization under OECD TG 497), which are outside the scope of payment security. Readers should confirm the payment-security definition against the current published PCI DSS standard, as this evidence packet does not support such a definition.
Why it matters
The evidence digest supplied for this term does not contain any material relevant to payment security or PCI DSS. Every source in the packet concerns OECD toxicology and chemical hazard assessment, specifically "defined approaches" to skin sensitization testing under OECD Guideline No. 497 (TG 497). These sources describe scientific methods such as regression-based models and the "2 out of 3" approach for classifying whether a test chemical is potentially skin sensitizing. None of this relates to how the term "Defined Approach" is used in the context of PCI DSS requirement validation.
Who it's relevant to
Compliance officers and QSAs
Those who assess PCI DSS compliance would be the primary audience for a payment-security definition of "Defined Approach." However, the evidence supplied here does not support such a definition, and readers in this role should refer to the current published PCI DSS standard for the authoritative meaning and validation procedures.
Merchants and service providers
Organizations validating their PCI DSS posture would need to understand how the Defined Approach differs from the Customized Approach when documenting controls. This evidence packet does not contain that information, so any operational guidance should be drawn from the current standard rather than from these sources.
Note on evidence relevance
The supplied sources concern OECD toxicology and skin sensitization testing (OECD TG 497), an unrelated scientific domain. Readers seeking the payment-security meaning of "Defined Approach" should disregard this evidence and consult the current published PCI DSS standard directly.
Inside Defined Approach
Prescribed Requirements and Testing Procedures
The Defined Approach follows the requirements and associated testing procedures as they are stated in the PCI DSS. Each requirement has defined testing procedures that an assessor uses to determine whether the control is in place as written. Requirement numbering and wording differ between PCI DSS versions, so practitioners should confirm the specific requirement text against the current published standard.
Traditional Validation Method
The Defined Approach represents the traditional method of implementing and validating PCI DSS controls, in which an entity meets a requirement by following the stated control and the assessor confirms it against the defined testing procedures.
Relationship to the Customized Approach
The Defined Approach is one of two options for meeting many PCI DSS requirements; the other is the Customized Approach, in which an entity designs its own controls to meet a stated security objective and supports them with a targeted risk analysis and additional evidence. An entity may use the Defined Approach for some requirements and the Customized Approach for others.
Documentation and Assessment Evidence
Under the Defined Approach, the entity provides evidence that the control is implemented as specified, and the assessor records the result against the defined testing procedures, typically reflected in the applicable reporting documentation for the assessment.
Scope of Applicability
The Defined Approach is a validation and implementation option within PCI DSS specifically. It does not itself govern controls that fall under separate standards such as PA-DSS, the PCI Software Security Framework, PCI PIN, PCI P2PE, or PCI 3DS, which have their own requirements and validation processes.
Common questions
Answers to the questions practitioners most commonly ask about Defined Approach.
Is the Defined Approach the same as the old, pre-existing way of validating PCI DSS, meaning it is being phased out?
No. The Defined Approach reflects the traditional method of meeting a requirement by implementing the controls exactly as stated and validating against the stated testing procedures, but it remains a fully supported and valid validation method. It sits alongside the Customized Approach as one of two ways an entity may meet applicable requirements, rather than being a deprecated predecessor. Confirm the specifics against the current published version of PCI DSS, since wording and structure differ between versions.
Does choosing the Defined Approach mean an assessor has no discretion and simply checks a box?
Not exactly. The Defined Approach uses the prescribed requirements and their associated testing procedures, which gives a consistent, well-established basis for assessment. However, the assessor still gathers and evaluates evidence to determine whether the control is properly implemented and effective in the assessed environment. The structured nature of the approach reduces ambiguity but does not remove the need for the assessor to examine evidence and exercise professional judgment about whether the requirement is met.
How do I decide between the Defined Approach and the Customized Approach for a given requirement?
The choice is made per requirement, not for the whole assessment. Many entities use the Defined Approach for most requirements because it is prescriptive and well understood, and consider the Customized Approach only where they meet the requirement's objective through controls that differ from the stated ones. Factors include the maturity of your control documentation, your ability to support the additional analysis the Customized Approach requires, and your assessor's and stakeholders' expectations. Review the current standard to confirm how each approach is documented and validated.
What documentation should I prepare when validating a requirement under the Defined Approach?
Prepare evidence that maps to each stated testing procedure for the requirement, such as configurations, policies, procedures, records, and interviews that demonstrate the control is implemented as described. Because the Defined Approach relies on the prescribed testing procedures, aligning your evidence to those procedures helps the assessor evaluate the requirement efficiently. Confirm the exact testing procedures against the current published version, since numbering and wording vary between versions.
Can I mix the Defined Approach and the Customized Approach within the same assessment?
Yes, the choice is generally made on a per-requirement basis, so an entity can meet some requirements using the Defined Approach and others using the Customized Approach. This lets an organization keep the prescriptive method where it fits and apply customization only where its controls differ from the stated ones. Document which approach applies to each requirement and validate accordingly, following the current standard's guidance for each method.
How does using the Defined Approach affect the reporting for an assessment?
When a requirement is met using the Defined Approach, it is documented and reported against the stated requirement and its testing procedures, reflecting that the prescribed controls were assessed as implemented. This differs from the Customized Approach, which involves additional analysis and documentation to show the requirement's objective is met by alternative controls. Follow the reporting templates and instructions in the current published version of PCI DSS to ensure the approach used is recorded correctly for each requirement.
Common misconceptions
The Defined Approach and the Customized Approach are the same thing, or one has replaced the other.
They are distinct options for meeting PCI DSS requirements. The Defined Approach follows the requirement as written with its defined testing procedures, while the Customized Approach lets an entity design its own controls to meet a stated objective, supported by a targeted risk analysis. An entity may use each approach for different requirements.
The Defined Approach is a legacy compensating control mechanism for requirements an entity cannot meet.
The Defined Approach is the traditional method of implementing a requirement exactly as stated and validating it against defined testing procedures. It is not the same as using a compensating control or the Customized Approach, which address situations where the stated control is met differently.
Requirement numbers and wording referenced under the Defined Approach are fixed across all versions of PCI DSS.
Requirement numbering and wording differ between PCI DSS versions. Practitioners should confirm the exact requirement text and testing procedures against the current published standard rather than assuming a fixed requirement number.
Best practices
Confirm the exact requirement wording and defined testing procedures against the current published version of PCI DSS, since numbering and language change between versions.
Decide per requirement whether the Defined Approach or the Customized Approach is more appropriate, and document that decision, rather than assuming one approach applies to the entire assessment.
Maintain evidence that each control is implemented as specified so the assessor can validate it against the defined testing procedures.
Do not treat the Defined Approach as a substitute for controls governed by separate standards such as PCI PIN, PCI P2PE, PCI 3DS, the PCI Software Security Framework, or PA-DSS; validate those under their own frameworks.
When cardholder data and sensitive authentication data are in scope, verify that sensitive authentication data is not retained after authorization, and that any stored cardholder data is protected under the applicable defined controls.
Engage a qualified assessor early to align interpretation of the defined testing procedures and avoid gaps between how a control is implemented and how it will be validated.