PCI DSS validation step by step: ROC, SAQ and AOC explained

Who decides how you validate

Validation shows, every year and on standard forms, that PCI DSS is met across your cardholder data environment. The PCI Security Standards Council writes the standard and those forms and qualifies the assessors and scanning vendors, but it does not run compliance programmes. Each participating card brand (American Express, Discover, JCB International, Mastercard, UnionPay and Visa) runs its own, and the Council refers reporting questions to them.

Levels

The brands group merchants and service providers into levels, mainly by yearly transaction volume, with a validation route for each: the top level generally files an annual ROC, while lower levels usually self-assess. Thresholds vary by brand and change over time, so check each brand's current programme. A brand can also move an entity up a level after a data compromise.

The acquirer's role

For merchants, the acquirer applies the brand rules: it confirms your level, decides whether an SAQ is enough, can ask for more than the brand minimum and sets the date your AOC is due. Service providers give their AOC to their customers, who must monitor their providers under Requirement 12.

The validation documents at a glance

None of the documents below is a certificate. The AOC, the Council's official form for attesting the result, is what most recipients ask to see.

The self-assessment route

SAQs are validation tools for merchants and service providers that are allowed to assess themselves. Each is written for one kind of payment environment, with eligibility criteria that must all be met: from a short questionnaire for card-not-present merchants that outsource every card data function to compliant providers, to SAQ D, the full requirement set for merchants that fit no other type.

Eligibility turns on how you take payments and whether your own systems can affect the transaction; it also decides whether ASV scans are included. Our guide Which SAQ applies to you: eligibility explained works through the choice. Every answer of in place still needs evidence a QSA would accept.

The ROC route, step by step

1. Scope and assessor

Document the cardholder data environment: data flows, connected systems, third parties and locations. Choose a QSA company from the Council's public list, check that the individual assessors it assigns are qualified, and agree the scope with them before fieldwork, not during it.

2. Gap analysis and remediation

A gap analysis tests each requirement against evidence the way the assessor will, then becomes a remediation plan with owners and dates. Reduce the scope first, as our guide PCI DSS scoping and segmentation: shrinking the CDE explains; each system taken out is one less to harden, log and test.

3. Fieldwork

Every requirement carries testing procedures the QSA must perform: examining documents and configurations, interviewing the people responsible, observing processes and sampling systems, sites and records. Fieldwork may be on site, remote or both.

4. Report and attestation

The QSA writes the ROC in the mandatory ROC Template, recording what was tested and found for each requirement, and the QSA company normally reviews it before release. The AOC, signed by your executive officer and the QSA, then goes to your acquirer or the brand, and to your customers if you are a service provider.

Scans, penetration tests and the annual cycle

Requirement 11 builds a testing calendar into the year. An ASV scans your external systems every three months, rescanning until each quarter passes, and internal vulnerability scans follow the same rhythm. Internal and external penetration tests are due at least every twelve months and after significant change, and segmentation that keeps systems out of scope is tested yearly, or every six months for service providers.

At the annual assessment the QSA expects four passing quarterly scans from the previous twelve months. A first assessment can proceed with fewer if the latest scan passed, a documented procedure requires quarterly scanning and earlier failures were fixed and rescanned; after that, a missed quarter cannot be scanned in hindsight.

Plan backwards from your AOC due date: test early enough to close findings before fieldwork, space the scans evenly and reconfirm the scope, as Requirement 12 asks.

How long each part of validation takes

Phases overlap. Most first validations take three to nine months end to end, because controls must run long enough to leave evidence; renewals are quicker.

Where validation goes wrong

• Scope creep. A new payment channel, a support tool reaching into the environment or a flat network found at fieldwork adds systems nobody planned for. Reassess the scope whenever something changes.
• Evidence gaps. A control that leaves no record cannot be tested; daily log reviews, six-monthly access reviews and change approvals are the usual casualties.
• Compensating controls not documented. A compensating control counts only when written up on the worksheet in Appendices B and C of the standard, meeting the intent of the original requirement and validated by the assessor each time; otherwise the requirement is reported as not in place.
• Missed quarterly scans. A failed scan never rescanned, a new IP range left out or a forgotten quarter leaves a gap the assessor must report.
• Unchecked third parties. Providers that handle card data or can affect its security need a current AOC and a written split of responsibilities; their size proves nothing.

PCI DSS validation: questions buyers ask