ROC vs AOC: How to Read Your PCI DSS Report on Compliance

A Qualified Security Assessor (QSA) who finishes your PCI DSS assessment gives you two documents. The Report on Compliance (ROC) is the assessor's detailed account of what was tested and what was found. The Attestation of Compliance (AOC) is a much shorter form that summarizes those results and declares your compliance status, signed by your company and by the QSA company. (ROC here always means Report on Compliance, not the Registrar of Companies.)

You keep the ROC and work from it. You usually send the AOC to anyone who needs proof of compliance, though an acquirer or customer can also ask for parts of the ROC.

ROC vs AOC: what each document is and who signs it

The Report on Compliance

The QSA writes the ROC on the PCI SSC's ROC Reporting Template, which the PCI DSS standard requires for every Report on Compliance. The current version is the template for PCI DSS v4.0.1, published in August 2024. The guide on how QSAs are vetted explains how assessors are qualified.

The template has two main parts:

• Part I, Assessment Overview, describes your business, the assessed environment and how the assessment was carried out. Its first section includes the overall assessment result and the attestation signatures.

• Part II, Findings and Observations, works through every PCI DSS requirement. For each one, the assessor records a finding, explains why that finding was chosen and lists the evidence behind it.

A full ROC is long and describes your network, systems and security controls in detail, so treat it as confidential.

The Attestation of Compliance

The AOC is the PCI SSC's form for confirming the assessment was completed and stating the result, with separate versions for merchants and for service providers. The service provider form, for example, covers contact details (Part 1), an executive summary of scope and environment (Part 2), a summary of findings for each requirement (Part 2g), the validation and signatures (Part 3) and an optional action plan for non-compliant requirements (Part 4).

An executive officer of the assessed company signs the entity's attestation. On the assessor side, the lead QSA and a duly authorized officer of the QSA company sign. Both documents carry the same Date of Report, which ties the AOC to the ROC it summarizes.

Merchants who validate with a Self-Assessment Questionnaire complete an AOC too, on the SAQ version of the form. The SAQ guide for small merchants covers that route.

Side-by-side comparison

How to read a PCI DSS report, section by section

Read the ROC in order. Every later finding only holds for what was in scope.

Start with the assessment overview and scope

Check that Part I's description of your cardholder data environment (CDE) matches your real setup: the business functions, locations, systems, networks and third-party service providers involved. If a payment channel or a data centre you use is missing from scope, the report says nothing about it.

Two more items in this part need a check:

• Date of Report. PCI SSC FAQ 1583 treats the Date of Report as the completion date of the assessment, the date when you and the QSA company agreed on the final ROC. You will find it in section 1.2 of the ROC. The AOC signature dates should match it or come shortly after.

• Full or partial assessment. The overall result in Part I states whether every requirement was assessed or only some. A partial assessment is allowed, for example when your acquirer asks you to validate a subset of requirements (PCI SSC FAQ 1382). The report must then say clearly which requirements were tested and which were not.

What the requirement findings mean

In Part II, each requirement gets a finding. Four values carry the result, and the AOC's summary table has a column for each of them.

• In Place. The assessor tested the requirement and found it met.

• Not Applicable. The requirement does not apply to your environment, and the assessor has documented the testing that confirms this. The PCI DSS standard gives the example of an entity that does not store PAN: the Requirement 3 controls for stored PAN do not apply to it. The AOC asks for the reason behind every Not Applicable response.

• Not Tested. The assessor did not test the requirement, so the report says nothing about whether it applies or is met. It appears in a partial assessment, and also where a legal constraint prevented testing (see the Non-Compliant status below). The AOC must list each Not Tested requirement with the reason.

• Not in Place. The requirement is not met. One Not in Place finding prevents a Compliant result, except in the narrow legal exception case covered below.

Not Applicable and Not Tested are easy to confuse. Not Applicable is a conclusion the assessor tested and documented. Not Tested means the assessor did not assess the requirement at all.

Compensating controls and the customized approach

Some findings rest on controls that differ from the requirement as written. The ROC flags these in the Part I summary, and the AOC's results table gives them separate columns.

• Compensating controls belong to the defined approach. You use them when a legitimate and documented technical or business constraint stops you from meeting a requirement as stated, and other controls reduce the risk enough instead. They are documented on the Compensating Controls Worksheet (Appendix C of PCI DSS) and included with the ROC. Under PCI DSS v4.0.1, you must document compensating controls each year, and the assessor must review and validate them, so a compensating control accepted this year is not settled for next year.

• The customized approach lets you meet a requirement's stated objective with controls of your own design. The standard intends it for risk-mature organizations that run a formal risk-management program. Some requirements have no customized approach objective, and for those the option is closed. Where it is used, the assessor records the controls and the testing on the ROC Template's Appendix E. A customized control has no predefined testing procedures, so read closely how the assessor tested it.

For compensating controls and customized controls alike, note which requirements they cover and why, because your acquirer may ask about them. Recheck both before the next assessment.

What the ROC should show about segmentation testing

Network segmentation is not itself a PCI DSS requirement, but isolating the CDE can reduce the scope of your assessment. If you rely on segmentation to keep systems out of scope, requirement 11.4.5 asks you to prove it works by running penetration tests on your segmentation controls. Among its conditions, the tests must be:

• repeated at least once every 12 months and after any change to segmentation controls or methods;

• carried out on all segmentation controls and methods in use, following your defined penetration testing methodology;

• designed to confirm that the controls are operational and effective, and that they isolate the CDE from all out-of-scope systems;

• performed by a qualified internal resource or a qualified external third party, with organizational independence (the tester does not have to be a QSA or ASV).

Requirement 11.4.6 applies to service providers only and sets a shorter interval: the same segmentation testing at least once every six months and after any changes.

When you read the 11.4.5 finding (and 11.4.6 if you are a service provider), check that the test dates fall within the required interval and that a test followed each segmentation change in the period. Then compare what the test covered with the out-of-scope areas described in Part I. If something was excluded from scope because of segmentation but the test never covered that boundary, the scope in Part I is not supported.

Segmentation testing is one part of the wider penetration testing requirements under 11.4. If you need that testing done, see Accorp's service page on PCI penetration testing requirements.

Which document to share, and with whom

• Your acquirer and the payment brands. These organizations accept your compliance validation. They normally receive your AOC and may ask for the ROC as well. Their reporting rules can differ, so ask your acquirer or the relevant payment brand exactly what to submit and in what form.

• Your customers, if you are a service provider. PCI SSC FAQ 1576 says a third-party service provider with its own assessment is expected to give customers its AOC on request, covering the services provided to that customer. A customer may also ask for relevant sections of the ROC. Under requirements 12.9.1 and 12.9.2, you should be able to show which PCI DSS requirements you handle and which stay with the customer; a responsibility matrix is one way to do that.

You can redact an AOC before you share it. FAQ 1354 allows you to remove sensitive details the recipient does not need, such as data centre locations or the technologies in your CDE. You should not redact the parts a recipient needs, such as the scope, the services covered, the requirements assessed, the findings, or the validation and signature section. If the service information itself is sensitive, consider sharing it under a confidentiality agreement instead of cutting it. The same FAQ advises checking the recipient's requirements before you send a redacted AOC.

When you are the one reviewing a vendor's AOC

If a vendor sends you its AOC, read it the way you would read your own:

1. Check that the services you buy are listed in scope. An AOC only covers the services named in it.

2. Find the Date of Report and confirm the assessment is current enough for your purposes.

3. Read Part 3. Note whether it is a full or partial assessment and which overall status it gives (the three options are explained in the next section). Any status other than Compliant is a reason to ask the vendor follow-up questions.

4. In the summary table, look for Not Tested, compensating control and customized approach entries against requirements that matter to the service you use.

If the AOC leaves open questions about a requirement you depend on, ask for the relevant ROC sections. The guide to managing shared payment risk with third-party vendors covers the wider vendor process.

When the report shows gaps

Part 3 of the AOC carries the overall result and offers three statuses:

• Compliant. All sections of the ROC are complete and every assessed requirement has a passing finding, such as In Place or Not Applicable, with none marked Not in Place. In a partial assessment, compliance is stated for all requirements except those marked Not Tested.

• Non-Compliant. Not all sections of the ROC are complete, or one or more requirements are Not in Place. Under PCI SSC FAQ 1486, a requirement the assessor could not test because of a legal constraint, such as travel restrictions, is marked Not Tested, and Part 3 of the AOC is marked Non-Compliant.

• Compliant but with Legal exception. One or more assessed requirements are Not in Place because a legal restriction prevents you from meeting them. PCI SSC FAQ 1486 says this needs additional review by your acquirer or payment brand. This status does not cover a requirement the assessor could not test because of a legal constraint.

With a Non-Compliant result, you may be asked to complete Part 4 of the AOC, the action plan for non-compliant requirements. The form says to complete it only when the entity receiving the AOC requests it. Start with the Not in Place findings in Part II, where the assessor's notes show what was missing and what evidence was reviewed. That gives you a concrete list to fix and discuss with your acquirer.

Next step

A Compliant result still leaves work for the year ahead. Before your next assessment, go back to this year's ROC and confirm that the Part I scope still matches your environment, that every compensating control is still justified, and that segmentation testing is planned within the required interval. If you are preparing for your next assessment, see our PCI DSS assessment services.

Frequently asked questions

1. What is a PCI DSS report?

In PCI DSS, the main assessment report is the Report on Compliance (ROC), which a Qualified Security Assessor writes on the PCI SSC's ROC Reporting Template. Part I describes your business, the assessed environment and how the assessment was done. Part II records a finding for every requirement, with the reason and the evidence. The much shorter Attestation of Compliance (AOC) summarizes the result.

2. What is the difference between a ROC and an AOC?

The ROC is the assessor's detailed account of what was tested and found, and you keep it confidential. The AOC is a short form that summarizes those results and declares your compliance status. An executive officer of your company, the lead QSA and an officer of the QSA company sign it. Both documents carry the same Date of Report.

3. Who gets the ROC and who gets the AOC?

You keep the ROC, and the AOC is what you usually send out. Your acquirer and the payment brands normally receive your AOC and may ask for the ROC as well. Their reporting rules can differ, so ask them exactly what to submit. If you are a service provider, PCI SSC FAQ 1576 says you are expected to give customers your AOC on request, covering the services you provide to them.

4. Can I share my ROC with customers?

Usually you share the AOC, not the ROC. A customer may still ask for relevant sections of your ROC (PCI SSC FAQ 1576). Before you send an AOC, you can redact sensitive details the recipient does not need, such as data centre locations. FAQ 1354 says you should not redact parts such as the scope, the services covered, the requirements assessed or the findings.

5. What does Not Tested mean, and what makes an AOC Non-Compliant?

Not Tested means the assessor did not test the requirement, so the report says nothing about whether it applies or is met. A partial assessment states compliance for everything except the Not Tested requirements. An AOC is Non-Compliant when ROC sections are incomplete or a requirement is Not in Place. PCI SSC FAQ 1486 adds one case: if a legal constraint stopped the assessor from testing a requirement, it is marked Not Tested and the AOC is Non-Compliant.

6. What should the ROC show for requirement 11.4.5?

If you use network segmentation to keep systems out of scope, requirement 11.4.5 asks for penetration tests of your segmentation controls at least once every 12 months and after any change to them. In the ROC, check that the test dates fall within that interval and that a test followed each change. Then check that the tests covered every out-of-scope boundary described in Part I. Service providers also have 11.4.6, which sets a six-month interval.