PCI DSS compliance is not self-declared; it is validated. How depends on the entity and its transaction volume. A Report on Compliance (ROC), performed by a Qualified Security Assessor or a trained internal security assessor, is the full assessment for the largest merchants and most service providers. A Self-Assessment Questionnaire (SAQ) is the lighter, self-validated path for smaller merchants. Either way the result is captured in an Attestation of Compliance (AOC), the signed statement of the assessment's outcome, and network scanning by an Approved Scanning Vendor supports the external-vulnerability requirements.
A PCI DSS assessment is the validation of an entity's compliance with the standard, which the standard treats as a discipline separate from building the program itself. The form the assessment takes is set by the type of entity and the volume of card data it handles. This guide covers the ROC, the SAQ, the AOC, the people who perform the assessment, how merchant level decides the path, and where assessments go wrong.
How compliance is validated
PCI DSS is enforced by the payment brands through the acquiring banks, and they require entities to validate compliance on a defined cycle, typically annually, with quarterly network scanning. Validation is an assessment against the standard's requirements that produces evidence, rather than a self-declaration. The two main routes are the Report on Compliance and the Self-Assessment Questionnaire.
ROC versus SAQ
| Path | What it is |
|---|---|
| Report on Compliance (ROC) | The full assessment, documenting how each requirement is met. Performed by a QSA or a qualified internal security assessor. Required for the largest merchants and most service providers. |
| Self-Assessment Questionnaire (SAQ) | A self-validated questionnaire for smaller merchants. Several SAQ types exist, each matched to how the merchant accepts and handles card data. |
| Attestation of Compliance (AOC) | The signed statement of the assessment's result. It accompanies both the ROC and the SAQ and is what the acquirer or brand receives. |
There is no single SAQ. The Council publishes several, each matched to how a merchant accepts and handles card data: SAQ A for fully outsourced e-commerce or mail and telephone order, SAQ A-EP for e-commerce merchants that partially manage the payment page, SAQ B and B-IP for imprint or standalone terminal merchants, SAQ C and C-VT for payment-application or virtual-terminal merchants, SAQ P2PE for merchants using a validated point-to-point encryption solution, and SAQ D, the most extensive, for everyone else and for service providers. Completing an SAQ that does not match how the merchant accepts and handles card data tests the wrong set of controls.
Who performs the assessment
A Qualified Security Assessor is a company the PCI Security Standards Council certifies to perform ROC assessments. A trained internal security assessor can perform a ROC for their own organization where the brand permits. An Approved Scanning Vendor runs the external vulnerability scans that several requirements depend on. The SAQ, by contrast, is completed by the merchant itself.
How merchant level sets the path
The payment brands sort merchants into levels by annual transaction volume, and the level drives the validation path. The highest-volume level generally requires an annual ROC and quarterly ASV scans; lower levels can validate by SAQ. Service providers have their own level scheme. Because the brands set the thresholds, the exact level definitions should be confirmed with the acquirer.
How to approach one
Step 1: Confirm the entity's level and the required path
The merchant or service-provider level is established with the acquirer, which sets whether a ROC or an SAQ is required and which SAQ type applies.
Step 2: Scope the cardholder data environment
Define the systems in scope, since assessment scope follows the cardholder data environment and any connected systems.
Step 3: Run the assessment and the scans
Complete the ROC or SAQ against the requirements and arrange the ASV scans the path requires.
Step 4: Sign the Attestation of Compliance
Capture the result in the AOC and provide it to the acquirer or brand.
Step 5: Maintain between assessments
Keep the controls operating and the targeted risk analyses current, since validation is a point-in-time snapshot of an ongoing obligation.
Where it goes wrong
- Wrong SAQ type. The merchant completes an SAQ that does not match how it actually handles card data, so the assessment covers the wrong controls.
- Scope drawn too narrow. Connected systems are left out of the cardholder data environment, understating what must be assessed.
- Treated as a once-a-year event. Controls drift between assessments, so the AOC reflects a state the environment no longer matches.
A PCI DSS assessment is how compliance is proven to the brands and acquirers. For the wider standard, see the PCI DSS compliance guide and the PCI DSS glossary; for the analysis that justifies control frequency, see the PCI DSS risk assessment guide.
Primary sources
- PCI DSS v4.0.1 validation requirements (ROC, SAQ, AOC): How PCI DSS compliance is validated: the Report on Compliance by a QSA or internal security assessor, the Self-Assessment Questionnaire, and the Attestation of Compliance.
- PCI DSS v4.0.1 (PCI Security Standards Council): The Payment Card Industry Data Security Standard: the 12 requirements, scoping of the cardholder data environment, and the SAQ and ROC validation paths.