Skip to main content
Commerce Security Authority
Category: PCI DSS Compliance

Report on Compliance

Also known as: ROC, PCI DSS Report on Compliance, RoC
Simply put

A Report on Compliance (ROC) is a formal document that records the results of a detailed PCI DSS assessment of an organization, describing how well it meets the standard's security requirements. It is typically produced during an onsite assessment and is used as part of the process for demonstrating, or validating, PCI DSS compliance. It can apply to merchants and service providers, and is often prepared with the involvement of an external assessor.

Formal definition

The Report on Compliance (ROC) is the documented output of a PCI DSS assessment, produced during onsite assessments as part of an entity's validation process, using the ROC Reporting Template published by the PCI Security Standards Council for the applicable PCI DSS version. It records detailed findings on the entity's adherence to PCI DSS requirements, including scope, tested controls, and the assessor's conclusions for each requirement. According to the evidence, it may be performed for both merchants and service providers and is described as being conducted by an external Qualified Security Assessor; assessment frequency, eligibility, and whether a ROC versus a Self-Assessment Questionnaire applies are governed by acquirer and payment brand program rules and are not determined by PCI DSS alone. Note that ROC template structure, requirement numbering, and reporting instructions differ between PCI DSS versions, so practitioners should confirm details against the current published reporting template rather than assuming a fixed format. The ROC is a validation and reporting artifact and is distinct from the underlying PCI DSS control requirements themselves and from other PCI standards such as PA-DSS, the PCI Software Security Framework, PCI PIN, PCI P2PE, and PCI 3DS.

Why it matters

The Report on Compliance is the primary artifact through which an organization demonstrates, in detail, that its handling of payment card data was assessed against PCI DSS requirements. Unlike a simple attestation, the ROC records scope, the controls that were tested, and the assessor's conclusions for each requirement, giving acquirers and payment brands a documented basis for evaluating an entity's validation. For merchants and service providers whose programs call for an onsite assessment, the ROC is often the difference between a compliance claim that can be independently reviewed and one that cannot.

Because the ROC captures scope and per-requirement findings, it also functions as a working record of where an entity's cardholder data environment begins and ends and how its controls were evaluated at a point in time. That makes it relevant well beyond the assessment itself: it informs remediation planning, supports discussions with acquirers, and provides a reference for the next assessment cycle. It is important to remember, however, that a ROC is a validation and reporting document, not a guarantee of security; it reflects the state of controls as assessed and does not by itself eliminate risk or fraud.

Whether a given entity needs a ROC at all, and how often, is governed by acquirer and payment brand program rules rather than by PCI DSS alone. Some entities validate through a Self-Assessment Questionnaire instead. Practitioners should also note that the ROC Reporting Template, requirement numbering, and reporting instructions differ between PCI DSS versions, so the exact structure and expectations should be confirmed against the current published template rather than assumed from a prior engagement.

Who it's relevant to

Merchants
Merchants whose acquirer or payment brand program calls for an onsite assessment rely on the ROC to validate PCI DSS compliance. It documents their cardholder data environment scope and per-requirement findings. Whether a ROC applies, versus a Self-Assessment Questionnaire, is determined by acquirer and payment brand program rules rather than PCI DSS alone.
Service Providers
The ROC applies to service providers as well as merchants, giving them a detailed, assessor-reviewed record they can reference with the clients and acquirers who depend on their handling of payment card data. As with merchants, applicability and frequency are governed by program rules.
Qualified Security Assessors (QSAs)
External QSAs conduct the onsite assessment and prepare the ROC using the ROC Reporting Template for the applicable PCI DSS version, documenting scope, tested controls, and conclusions for each requirement. They should confirm template structure and reporting instructions against the current published version.
Acquirers and Payment Brands
Acquirers and payment brands use the ROC as documented evidence within an entity's validation process. Their program rules govern who must produce a ROC, how often, and whether a ROC or a Self-Assessment Questionnaire applies, and these rules can vary by region and change over time.
Compliance Officers and Security Teams
Internal compliance and security staff use the ROC to understand assessed scope, track per-requirement findings, and plan remediation. Because the ROC reflects control state at the time of assessment and is a reporting artifact rather than a security guarantee, teams should treat it as an input to ongoing risk management rather than a substitute for it.

Inside ROC

Assessor and Entity Identification
Documentation identifying the assessed entity and the Qualified Security Assessor (QSA) or Internal Security Assessor (ISA) performing the assessment, along with the assessment period and the scope of the environment reviewed. Roles and qualifications for assessors are defined under the PCI DSS assessment program rather than by any single named requirement.
Scope Definition and Cardholder Data Environment (CDE)
A description of the systems, networks, people, and processes in scope, including where cardholder data (such as PAN, cardholder name, expiration date, and service code) is stored, processed, or transmitted. Sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, and PIN/PIN blocks) must not be stored after authorization even if encrypted, and the scoping narrative should reflect this distinction.
Findings Against PCI DSS Requirements
A detailed reporting of each PCI DSS requirement and testing procedure, with the assessor's finding for each item. Requirement numbering and wording differ between PCI DSS versions, so the ROC should reference the specific version assessed; readers should confirm details against the current published standard rather than assuming fixed numbers.
Testing Procedures and Evidence
A record of the testing performed, including interviews, observations, documentation review, and sampling methodology, along with the evidence supporting each finding. This substantiates how the assessor reached conclusions about whether controls were in place.
Compensating Controls Worksheets
Where a stated requirement is not met as written, documentation of any compensating controls, including the constraint, objective, identified risk, and how the alternative control meets the intent and rigor of the original requirement.
Data Protection Method Descriptions
Descriptions of how in-scope data is protected, which may include tokenization, encryption, truncation, masking, or hashing. These transform or reduce data differently, and their effect on scope depends on implementation and validation rather than the label used, so the ROC should describe how each method is deployed.
Attestation of Compliance (AOC) Linkage
The ROC supports and is accompanied by an Attestation of Compliance, a summary document that reflects the outcome of the detailed assessment recorded in the ROC.

Common questions

Answers to the questions practitioners most commonly ask about ROC.

Does having a Report on Compliance mean an organization is permanently secure or breach-proof?
No. A ROC reflects an assessor's findings for the assessed environment during a defined assessment period against the applicable version of PCI DSS. It is a point-in-time validation of the controls in scope at the time of assessment, not a guarantee of ongoing security or a promise that a breach cannot occur. Environments change, and controls must be maintained continuously; a ROC does not attest to security after the assessment window, nor does it cover systems, processes, or data flows that were out of scope.
Is a Report on Compliance the same thing as a Self-Assessment Questionnaire (SAQ) or an Attestation of Compliance (AOC)?
No, these are distinct documents. A ROC is a detailed report typically produced through an assessment (commonly by a Qualified Security Assessor) documenting how each applicable requirement was evaluated and the findings. An SAQ is a self-assessment validation instrument used by eligible entities. An AOC is a summary attestation of the validation result. The ROC contains the underlying detail and testing evidence narrative, whereas the AOC is a shorter statement of the outcome; the SAQ is a separate validation path. Which document applies depends on the entity's validation requirements, which are governed by the applicable card brand and acquirer rules.
Who determines the scope documented in a Report on Compliance?
Scope is defined by the assessed entity and confirmed through the assessment process, covering the people, processes, and technology that store, process, or transmit cardholder data, as well as connected or security-impacting systems. The assessor reviews scope for accuracy, but responsibility for identifying all in-scope systems and data flows rests with the entity. Because scope-reduction techniques such as tokenization, segmentation, encryption, or truncation affect what falls in scope based on implementation and validation, the ROC should document how scope was determined and any methods used to reduce it.
How should sensitive authentication data be handled when preparing for a ROC assessment?
Confirm that sensitive authentication data—such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks—is not retained after authorization, even in encrypted form. Assessment activities documented in a ROC typically include testing for the presence of such data in storage, logs, and other locations. Cardholder data such as PAN may be stored only under the defined protection controls, and the ROC should reflect how those controls were tested. Distinguishing these data categories clearly before assessment helps avoid findings related to prohibited storage.
How is each requirement's status documented within a Report on Compliance?
A ROC records, for each applicable requirement, the assessor's determination of how the requirement was met, along with the testing performed and observations. Because requirement numbering and wording differ between versions of PCI DSS, the report is tied to the specific version assessed, and readers should confirm requirement references against the current published standard rather than assuming fixed numbers. Where a requirement is met through alternative means, the ROC should document that approach and how the assessor validated it.
What should teams verify about assessment period and version before relying on a ROC?
Check the PCI DSS version the assessment was conducted against and the assessment period covered, since both affect what the report represents. A ROC validates the environment as it existed during the assessment; subsequent changes to systems, data flows, or scope are not reflected. Acquirers, processors, or partners relying on a ROC should confirm it aligns with the version currently required by the applicable card brand and their own contractual obligations, which vary by region and change over time.

Common misconceptions

A ROC is the same thing as a Self-Assessment Questionnaire (SAQ) or an Attestation of Compliance (AOC).
A ROC is a detailed assessment report typically produced through an on-site assessment, whereas an SAQ is a self-assessment tool and the AOC is a summary attestation. They serve different purposes, and eligibility to use an SAQ versus a ROC depends on how the entity validates compliance under card brand and network rules.
A completed ROC governs software and application security requirements as well.
A ROC documents compliance against PCI DSS. Related but separate standards such as PA-DSS, the PCI Software Security Framework, PCI PIN, PCI P2PE, and PCI 3DS govern their own controls and validation, and a PCI DSS ROC does not by itself demonstrate compliance with those other standards.
A passing ROC means the environment is fully secure and free from breach or fraud.
A ROC reflects the assessor's findings for a defined scope during a defined assessment period. It is intended to demonstrate that in-scope controls were assessed as in place at that time; it does not guarantee ongoing security, and it does not eliminate fraud, which is addressed by separate controls and governed in part by card brand and network rules.

Best practices

Confirm the applicable PCI DSS version before beginning, and map findings to that version's requirements and testing procedures rather than to assumed or outdated requirement numbers.
Document scope rigorously, clearly identifying where cardholder data resides and confirming that no sensitive authentication data is retained after authorization, even in encrypted form.
Describe each data protection method precisely, distinguishing tokenization, encryption, truncation, masking, and hashing, and explain how the implementation and validation affect scope rather than relying on the label alone.
Support every finding with specific evidence, including the sampling methodology, interviews, observations, and documentation reviewed, so conclusions are traceable and defensible.
Complete compensating controls worksheets fully where a requirement is not met as written, addressing the constraint, objective, risk, and how the alternative meets the intent and rigor of the original control.
Keep the ROC scoped to PCI DSS and note where controls fall under separate standards such as PA-DSS, the PCI Software Security Framework, PCI PIN, PCI P2PE, or PCI 3DS, so readers do not assume broader coverage than the assessment provides.