What is a Report on Compliance?

A Report on Compliance (RoC) is the detailed PCI DSS assessment report that a Qualified Security Assessor writes after auditing a Level 1 merchant or Level 1 service provider. It walks through every one of the 12 PCI DSS requirements, breaks each one down into its sub-requirements and testing procedures, and records what the QSA tested, what evidence they reviewed, and the in-place or not-in-place determination. RoCs typically run several hundred pages, cost £30,000 to £80,000 to produce, and have to be re-issued every year. The shorter Attestation of Compliance (AoC) that's submitted to acquirers is the public-facing summary signed off the back of the RoC.

The Report on Compliance is the deepest form of PCI DSS validation there is, and it's done to the merchant by an independent assessor — not by the merchant themselves. That's the line that separates it from a Self-Assessment Questionnaire, which Levels 2 to 4 fill in on their own. A failed RoC isn't a soft warning either: the merchant is treated as non-compliant from the date of assessment until the gaps are remediated, which can mean fines from the card brands or escalation by the acquirer. Because the document includes network diagrams, data flows, and detailed control testing, it's confidential — most service providers will share their AoC on request but keep the RoC under NDA.

What a Report on Compliance Is

A Report on Compliance (RoC) is the most detailed and rigorous form of PCI DSS compliance documentation. It is produced by a Qualified Security Assessor (QSA) after conducting a thorough on-site assessment of an organisation's cardholder data environment. The RoC documents every PCI DSS requirement, describes how the organisation meets (or does not meet) each one, and provides the evidence supporting those conclusions.

If the Attestation of Compliance (AoC) is the summary certificate, the RoC is the full audit report behind it. It typically runs to hundreds of pages and provides a thorough picture of an organisation's security posture as it relates to payment card data.

Who Needs a RoC

Not every organisation needs a Report on Compliance. RoCs are required for Level 1 merchants (those processing more than six million card transactions per year) and Level 1 service providers (those that store, process, or transmit cardholder data on behalf of other organisations).

Smaller merchants and service providers typically validate compliance through Self-Assessment Questionnaires (SAQs), which are less detailed but follow the same underlying requirements. However, some acquiring banks or business partners may request a RoC even from organisations that are not strictly required to produce one, particularly where the relationship involves handling large volumes of sensitive data.

Paytia, for example, maintains a RoC as part of its PCI DSS Level 1 certification. This gives Paytia's clients confidence that the platform they are trusting with their customers' card data has been independently and rigorously assessed.

What the RoC Contains

A RoC follows a structured template provided by the PCI SSC. It covers every one of the PCI DSS requirements in detail, organised into the following sections.

Executive Summary

A high-level overview of the assessment, including the scope, key findings, and overall compliance status. This section gives the reader the bottom line before diving into the details.

Scope of Assessment

A detailed description of the cardholder data environment that was assessed. This includes network diagrams, data flow diagrams, lists of systems and applications in scope, and descriptions of how card data enters, moves through, and leaves the environment. The scope section is critical because it defines the boundaries of the assessment -- anything outside the stated scope has not been assessed.

Requirement-by-Requirement Assessment

This is the bulk of the document. For each of the PCI DSS requirements (and their sub-requirements), the RoC describes the controls in place, the testing procedures the QSA performed, the evidence gathered, and whether the requirement is met, not met, or met with compensating controls.

For example, under Requirement 3 (Protect Stored Account Data), the RoC would describe what cardholder data is stored, how it is encrypted, who has access, how access is controlled, and what the QSA did to verify these controls are working.

Compensating Controls

If an organisation cannot meet a specific requirement as stated but has implemented alternative controls that provide equivalent security, these are documented as compensating controls. Each compensating control worksheet explains the constraint that prevents compliance with the original requirement, the objective of the original requirement, and how the compensating control meets that objective.

The RoC Process

Producing a RoC is a significant undertaking. The process typically unfolds over several weeks or months, depending on the size and complexity of the cardholder data environment.

• Engagement planning The QSA and the organisation agree on the scope, timeline, and logistics of the assessment. This includes identifying key contacts, scheduling site visits, and determining which systems and processes need to be examined.
• Documentation review The QSA reviews security policies, procedures, network diagrams, data flow diagrams, and other documentation before the on-site visit. This helps identify potential gaps early and makes the on-site work more efficient.
• On-site assessment The QSA visits the organisation's facilities (or conducts the assessment remotely, where permitted) to test controls, examine systems, review configurations, and interview staff. This is where the QSA gathers the evidence that will support the findings in the RoC.
• Gap remediation If the QSA identifies controls that are not in place or not working effectively, the organisation has an opportunity to fix them during the assessment window. The QSA will then re-test the remediated controls before finalising the RoC.
• Report writing The QSA compiles the findings into the RoC template, documenting every requirement, the testing performed, and the evidence gathered. This is the most labour-intensive part of the process.
• Finalisation The completed RoC is reviewed by the organisation, signed by both parties, and submitted along with the Attestation of Compliance to the relevant acquiring banks or card brands.

RoC and Telephone Payments

For organisations that process telephone payments, the RoC will include detailed assessment of the telephony environment. The QSA will examine how card data is captured during phone calls, whether call recordings contain cardholder data, how agent workstations are secured, and what controls protect the voice channel.

Organisations using DTMF masking can significantly simplify this section of the RoC. Because card data never enters the telephony environment, the QSA can confirm that the telephony systems, agent workstations, and call recording platform are outside the scope of the assessment. The focus shifts to the relationship with the DTMF masking provider and their PCI DSS Level 1 certification, rather than the merchant's own infrastructure.

This scope reduction can save weeks of assessment time and significantly reduce the cost of the QSA engagement.

RoC vs SAQ

The Report on Compliance and the Self-Assessment Questionnaire serve the same fundamental purpose -- validating PCI DSS compliance -- but they differ significantly in depth and rigour.

• RoC Produced by an independent QSA. Involves on-site testing, evidence gathering, and staff interviews. Hundreds of pages long. Required for Level 1 organisations.
• SAQ Completed by the organisation itself (self-assessment). No independent verification required (though a QSA can assist). Much shorter and simpler. Used by Level 2, 3, and 4 merchants.

The RoC provides much greater assurance because the assessment is conducted by an independent, qualified third party. This is why Level 1 organisations -- those processing the highest volumes of transactions or those handling card data on behalf of others -- are required to go through the full RoC process.

What a RoC actually costs to produce

The RoC is the most expensive piece of paperwork in payments. A typical UK or European RoC engagement for a mid-sized Level 1 merchant runs to between £30,000 and £80,000 in QSA fees. That's before the internal cost — engineering, security, compliance, and product time pulled into the assessment, which can easily double or triple the external bill. Large service providers and global merchants regularly spend six figures every year just to keep the RoC current.

The factors that move the cost are predictable. Scope is the biggest lever — if you've got 500 in-scope systems, the QSA has to test 500 in-scope systems. Geography matters because on-site visits to multiple locations multiply the day rate. Complexity matters because every custom-built control needs a tailored test plan and a tailored compensating-control worksheet. And the QSA firm itself matters — Big Four firms charge more than specialist boutiques, and the gap can be 2x.

The 12 requirements the RoC tests, by section

The RoC walks through all 12 PCI DSS requirements in the same order the standard lays them out. For each one, the QSA documents what they tested, what evidence they reviewed, and whether the requirement is "in place," "not in place," or "in place with compensating controls." The sections are:

• Requirements 1 and 2 — build and maintain a secure network and systems (firewalls, configuration standards).
• Requirements 3 and 4 — protect cardholder data (storage protection, encryption of data in transit).
• Requirements 5 and 6 — vulnerability management (anti-malware, secure development).
• Requirements 7, 8, and 9 — access control (least privilege, authentication, physical access).
• Requirements 10 and 11 — monitoring and testing (logging, vulnerability scanning, penetration testing).
• Requirement 12 — security policy and programme management.

Each top-level requirement has sub-requirements, and each sub-requirement has its own testing procedures. PCI DSS v4.0.1 expanded the sub-requirement count to around 250 — and the RoC has to walk through every single one with evidence.

Evidence the QSA actually wants to see

QSAs don't take "we do that" on trust. For every requirement, they want evidence — usually one of:

• Configuration screenshots showing the control is enabled (firewall ruleset, encryption setting, password policy).
• Log samples showing the control is firing (failed logins logged, file integrity checks running, vulnerability scans completing).
• Sampled records showing the process is followed (change tickets, access reviews, training completion records).
• Live demonstrations during interviews (an engineer logging in to show MFA in action, an admin showing how a user account is provisioned and deprovisioned).

The evidence binder for a typical RoC runs into the thousands of files. Service providers usually pre-stage evidence in a structured workspace so the QSA can navigate it efficiently — anything less and the assessment timeline blows out.

Where Level 1 service providers diverge from Level 1 merchants

The RoC structure is the same, but the focus shifts. For a Level 1 merchant, the QSA cares about the merchant's own environment — websites, contact centres, retail estate, back-office systems. For a Level 1 service provider, the QSA cares about the systems that handle cardholder data on behalf of other businesses — the API, the dashboard, the tokenisation vault, the underlying infrastructure.

Service providers also pick up additional requirements that don't apply to merchants — Requirement 12.8 (managing service provider relationships) flips around, and Requirement 12.9 obliges service providers to acknowledge in writing that they're responsible for the security of cardholder data they handle. Paytia's RoC, for example, has these service-provider requirements assessed in detail because its clients reference them in their own compliance programmes.

How DTMF masking shows up in a RoC

For a merchant whose only card-handling channel is the contact centre, a RoC engagement could in principle drag every agent workstation, recording server, CRM, and headset into scope. The same engagement after DTMF masking is in place looks very different.

The QSA verifies how card data enters the masking provider's environment, checks the segmentation that keeps the merchant's telephony system out of scope, and confirms the contractual and technical boundaries with the service provider. The merchant's own systems — agent workstations, CRM, call recording platform — drop out of scope for storage and processing of cardholder data, even though they remain in scope for the "connected systems" requirement (Requirement 1.4.1) because they can talk to the in-scope provider.

Concretely, that usually means the RoC scope section shrinks from hundreds of systems to a handful — the segment that talks to the masking provider, the policies that govern that segment, and the service provider relationship itself. The QSA's time on the engagement drops accordingly, and the merchant's annual RoC cost drops with it.

What happens if the QSA finds gaps

One of the practical differences between a RoC and a SAQ is what happens when the assessment uncovers a control that isn't working. In a SAQ, the merchant simply marks the requirement "not in place" and either accepts the non-compliance or remediates and re-attests. In a RoC, the QSA and the merchant typically work through a remediation window during the engagement itself.

The merchant fixes the gap. The QSA re-tests. If the fix holds, the requirement is recorded as "in place" with a note about the remediation activity. If the fix doesn't hold or the timeline is too tight, the QSA either records the gap as "not in place" or documents a compensating control if one exists. The completed RoC then either confirms full compliance or flags the residual gaps to the acquirer.

It's worth understanding that the QSA can't "give a pass" on a control that isn't working — their professional obligation is to record what they found. A RoC with significant gaps still gets delivered, but it's delivered as a non-compliant RoC, and that has direct consequences with acquirers and card brands.

The Attestation of Compliance the RoC produces

The RoC is the detailed audit report. The Attestation of Compliance (AoC) is the short, signed cover document that summarises the result. The AoC is the version a service provider shares with prospects — it confirms compliance status, lists the scope, and is signed by both the QSA and the assessed entity, but it doesn't reveal the underlying network diagrams, evidence, or testing notes.

This is why most due-diligence reviews ask for the AoC rather than the full RoC. The AoC tells the procurement team what they need to know without exposing security-sensitive detail. If a customer specifically wants the RoC, it's almost always under NDA, and many service providers will only share extracts rather than the full document.

RoC renewal — what changes year to year

The RoC is a point-in-time assessment with a 12-month validity period. Renewal isn't a copy-and-paste exercise — PCI DSS v4.0.1 explicitly puts weight on demonstrating that controls have been operating continuously between assessments, not just at the moment the QSA looks. That means evidence from across the year matters: vulnerability scan history, penetration test reports, access reviews, training records, incident response exercises.

The big content shift in PCI DSS v4.0.1 was the introduction of the "customised approach" — a new way to meet a requirement using a control the QSA hasn't seen before, supported by a risk assessment and tailored testing. The customised approach gives flexibility for cloud-native architectures that don't fit the original PCI DSS shape. Done well, it strengthens the assessment. Done badly, it adds weeks to the engagement while the QSA and the merchant negotiate the tailored test plan.