Defined Approach
PCIComplianceHubLast updated
The traditional method of meeting PCI DSS, in which an organization implements each requirement as written and the assessor tests it against the defined testing procedures published in the standard. It remains the default, and it is the only route available to an organization completing a Self-Assessment Questionnaire. Compensating controls are available under the defined approach; they have no equivalent under the Customized Approach.
Applies to. Any entity validating against v4.0.1, requirement by requirement. Under the defined approach the assessor applies the testing procedures printed beside each requirement, and the entity's evidence is judged against the requirement as written. The choice is made per requirement, so an entity can use the defined approach for most of the standard and the customised approach for a few requirements, which then need the targeted risk analysis, controls matrix and senior management approval that 12.3.2 describes.
Example. A service provider meets 6.3.3 by installing patches for critical vulnerabilities within one month of release and shows the assessor its patch records and scan results. That is the defined approach: nothing beyond the requirement's own testing procedures is needed. Had it wanted to justify a different patching model, it would have needed the Appendix D documentation and a targeted risk analysis under 12.3.2.
Limits. The defined approach is not the 'old way' that v4.x replaced; it is still the primary route and the only one open to an entity completing an SAQ. It is not the same as a compensating control: a compensating control is used within the defined approach when a requirement cannot be met as written, and it is not available under the customised approach. A defined-approach requirement can still leave the frequency to the entity: 5.2.3.1 is met under the defined approach, yet its frequency comes from a targeted risk analysis under 12.3.1. That flexibility does not turn it into the customised approach.