Under PCI DSS v4.0.1, what distinguishes a Self-Assessment Questionnaire from a Report on Compliance, and what does the AOC attest?

## Three documents, three jobs **PCI DSS v4.0.1** separates *doing* an assessment from *reporting* it and from *attesting* to it: | Document | Glossary definition | Who typically completes it | |---|---|---| | **SAQ** - Self-Assessment Questionnaire | Reporting tool used to document self-assessment results | The entity itself | | **ROC** - Report on Compliance | Reporting tool used to document detailed results from an assessment | A QSA, or an ISA where the brands permit | | **AOC** - Attestation of Compliance | Official PCI SSC form for merchants and service providers to attest to the results documented in an SAQ or ROC | The entity, covering whichever report was used | - A **QSA** (Qualified Security Assessor) company is qualified by PCI SSC to validate an entity's adherence to PCI DSS. - An **ISA** is the other assessor type the standard names alongside QSAs for ROC work; it leaves to the brands and acquirers whether an ISA may be used. - The ROC must be written on the **PCI DSS ROC Template**; official AOCs are available only from the PCI SSC website. ## The assessment process Section 12 of the standard lists the high-level steps: 1. Confirm the scope of the assessment. 2. Perform the assessment of the environment. 3. Complete the applicable report (SAQ or ROC). 4. Complete the AOC for merchants or service providers in its entirety. 5. Submit the report and AOC, with other requested documentation such as **ASV scan reports** (external scans at least once every three months under Requirement 11.3.2), to the requesting organization - payment brands and acquirers for merchants, other requesters for service providers. 6. If required, remediate requirements not in place and provide an updated report. A requirement is **not in place** if its controls are not yet implemented or are scheduled for a future date; the assessor reassesses after remediation. ## Who decides SAQ or ROC The standard does not assign validation routes. It says whether an entity must comply with or validate PCI DSS "is at the discretion of those organizations that manage compliance programs (such as payment brands and acquirers)". In practice: - **Merchant levels** based on transaction volume are defined by the card brands and applied by acquirers, not by PCI DSS. Large merchants are usually required to have a ROC; smaller ones are often allowed an SAQ. - **SAQ types** and their eligibility criteria are set out in the PCI SSC's SAQ documents and SAQ Instructions and Guidelines, separate from the standard. They follow how the merchant accepts cards - for example, the glossary defines a virtual payment terminal "in the context of SAQ C-VT". - **Service providers** report to their customers and other requesters as well as to brands. ## What the paperwork enables and restricts - **Sharing.** The standard lists the ROC or SAQ among artifacts an entity may treat as sensitive, but says the AOC "is not considered sensitive" and that third-party service providers are expected to share their AOC with customers. A merchant monitoring a provider's compliance status at least once every 12 months under Requirement 12.8.4 usually starts with the provider's AOC. - **Customized approach.** Entities completing an SAQ are **not eligible** to use the customized approach; they may instead have a QSA or ISA assess them and document it on the ROC Template (Appendix D). - **Compensating controls** are documented in whichever report is used, ROC or SAQ, with the Appendix C worksheet. ## Common misunderstandings - **"PCI certification."** The standard's vocabulary is assessment, validation and attestation. There is no certificate issued by the Council; the AOC is the entity's attestation. - **"The Council enforces PCI DSS."** It publishes the standard and qualifies assessors; brands and acquirers run the compliance programs. - **"An SAQ is a lighter standard."** An SAQ is a reporting format. The security requirements the entity must meet come from the same standard; an SAQ applies to entities whose card-handling design means fewer requirements apply.