August 6, 2026

What Goes into a PCI Report on Compliance, Step by Step

Amanda Waldmann

Increasing trust with AI for audit and advisory firms.

Key insights

A Report on Compliance (RoC) is the formal deliverable a Qualified Security Assessor (QSA) produces to show a merchant or service provider meets PCI DSS.
Each card brand sets its own thresholds for who needs a RoC versus a Self-Assessment Questionnaire (SAQ), so one merchant can owe a RoC to one brand and an SAQ to another in the same year.
Defining the cardholder data environment (CDE) drives engagement cost more than drafting. In an unsegmented network, one system that touches card data can pull everything connected to it into scope.

PCI DSS is the standard any organization has to meet if it touches payment card data. Larger merchants and service providers prove they meet it through a RoC, which is produced by a QSA firm. Smaller entities usually complete an SAQ instead.

Most RoC budgets don't go sideways in drafting. They go sideways before anyone opens the template. Scope gets defined too loosely, evidence trickles in late, and fieldwork turns into a scavenger hunt for things that should have been settled in planning. In 2026, that's an even more expensive mistake, because every RoC now runs against the full current PCI requirements, and the work papers behind it have to hold up years later.

This article walks through what a RoC actually contains, who needs one, and the six phases a typical engagement moves through.

What a RoC actually documents

Think of a RoC as two things stitched together: a formal, structured report on the outside, and a mountain of work papers on the inside. The report itself follows a PCI SSC template published by the PCI Security Standards Council (PCI SSC) and captures the environment, the assessment methodology, and how the entity did against each requirement. The work papers underneath are where the hours actually live.

The template splits into two parts, and when those parts don't match up, that's exactly what quality assurance (QA) reviewers and acquirers catch.

Part I: the assessment overview and scope

First, the version housekeeping: PCI DSS v4.0.1 is the version every 2026 RoC is measured against. It came out in June 2024, and the 51 future-dated requirements that used to have a runway went live on 31 March 2025. In other words, grace periods are over.

Part I sets the stage for the whole report. It records when evidence was gathered, how the testing was performed, and whether any of it happened remotely (and if so, why). Then comes the section that carries the most weight: scope. A reviewer picking up the report should be able to follow account data through the environment and see exactly which system components sit inside or touch the CDE — the systems, people, and processes that store, process, or transmit cardholder data. This is also where segmentation controls (the network barriers that keep other systems out of the CDE) get explained, along with why certain systems were left out and which third parties connect in.

Part I also lists every piece of evidence the rest of the report refers back to.

Part II: findings, evidence, and sampling

Part II is where the assessor's judgment lives. For each requirement, the assessor picks one of four findings: In Place, In Place with Remediation, Not Applicable, or Not in Place. The current template folded the old compensating-control finding into In Place with Remediation and dropped Not Tested as a standalone option. Every finding needs an explanation of why the assessor picked it, plus pointers to the supporting evidence back in Part I.

A few special cases get their own appendix. When the exact requirement isn't feasible, a client can use a compensating control (an alternative that meets the same intent), which is documented in Appendix C. Or a client can use the Customized Approach, where they design their own control to meet the requirement's stated objective, which is documented in Appendix E. Both are only available on a full QSA-led RoC, not an SAQ.

Part II also documents the vulnerability scans. PCI DSS requires two kinds: internal scans, which the entity can run itself, and external scans, which have to be run by an Approved Scanning Vendor (ASV) — an outside firm authorized by PCI SSC to do that testing. For each scan, the report captures when it ran, who ran it, whether anything failed, and the re-scans that confirmed the fixes. After the first cycle, passing scans are the bar.

Who needs a RoC vs. a self-assessment questionnaire

Not everyone needs a full RoC, and figuring out who does takes some care. Each card brand — Visa, Mastercard, American Express, and the rest — defines merchant and service provider "levels" on its own terms. On top of that, acquirers (the banks that process card transactions for a merchant) can always demand more than the brand minimums. The upshot: one merchant can owe a RoC to one brand and an SAQ to another, in the same year, for the same environment.

Merchant thresholds diverge more than most clients expect

Each brand sorts merchants into tiers — Level 1 down to Level 4 — with Level 1 being the highest-volume merchants and the ones that face the strictest validation requirements (typically a full RoC). Lower levels usually get to complete an SAQ instead. The catch is that each brand sets its own transaction-volume cutoffs for those tiers, so the same merchant can land in different levels across brands.

Visa's Level 1 kicks in above 6 million transactions a year across all channels, and validation means an annual RoC from a QSA (or from internal resources with an officer signing off). American Express draws its Level 1 line much lower, at 2.5 million Amex transactions, with the RoC mandatory. So a merchant running 3 million Amex transactions a year is a Level 1 for Amex and a Level 2 for Visa at the same time. Mapping that out brand by brand belongs in the QSA's scoping conversation, up front.

Mastercard adds a wrinkle of its own. Some Level 2 merchants doing self-assessments still have to engage a QSA or Internal Security Assessor (ISA) to validate compliance, which pulls an assessor into the picture even when the reporting package is still an SAQ. A breach can rewrite everything: brands can bump any merchant up a level after a compromise, which turns next year's SAQ into a full RoC.

Service providers face a lower bar and a registry incentive

Service providers — companies that handle cardholder data on behalf of merchants — generally have to prove more with less volume. Visa treats any service provider above its Level 1 threshold as needing an annual QSA-led RoC. For advisory firms, getting on Mastercard's compliant service provider list requires a RoC attestation from a PCI SSC-approved QSA. Because that registry listing is a sales asset customers actively check, plenty of smaller service providers commission a RoC even when they don't technically have to. That's more RoC volume for QSA firms to plan for.

Once a RoC is on the table, the engagement usually moves through six phases.

1. Define and validate the scope of the cardholder data environment

Scope is where an engagement gets won or lost. If a client's network is flat (no internal segmentation between systems), PCI SSC's scoping guidance pulls every connected system into scope as soon as one of them touches card data. PCI DSS doesn't require segmentation, but it's the single biggest lever on cost and effort. That's why scope reduction is a conversation to have before fieldwork, not during.

The client defines the scope and provides the documentation; the QSA validates it. And validation matters, because the client's view is a starting point, not the final answer. Systems that were wrongly ruled out of scope have been the entry point in real breaches, and PCI SSC's guidance on modern network architectures has pulled things like administrator workstations into scope for organizations that never thought to count them. A scope that holds up in QA is one the assessor actually tested.

2. Run a gap assessment before formal testing

Larger engagements typically follow a review-remediate-validate rhythm. The assessor takes a first pass against the requirements, flags gaps, and the client fixes them and sends back updated evidence before formal testing starts. The whole point is the sequence: catching a failed requirement in the gap phase means a remediation cycle. Catching the same failure during formal testing means a Not in Place finding — unless it's fixed inside the assessment window and revalidated as In Place with Remediation.

Client preparation shows up in the evidence trail. The smoother gap assessments have it ready to go from day one: security policies, change control records, network diagrams, scan reports, training records, and interview time with senior management. When a client treats the gap phase as a dress rehearsal for evidence production, the formal assessment tends to run much smoother.

3. Collect evidence and execute the testing procedures

Work papers are the defense trail for the final report. They pull together observations, system-testing results, configuration data, file lists, interview notes, documentation excerpts, references, and screenshots — basically everything the assessor saw or was told.

Testing itself is a mix of methods: watching how systems are configured, reading documents, interviewing people, observing processes in action, and pulling samples. Sampling calls belong to the assessor, and year-over-year sample rotation is still a QA checkpoint.

v4.0.1 also added some documentation work in this phase. Targeted risk analyses — structured evaluations of the risk behind a control's frequency or design — are now required any time a requirement has flexible frequency, and for every requirement met through the Customized Approach.

One useful mental model here: evidence gathering, matching, and cataloging is repeatable, high-volume work. The finding on each requirement is a judgment call. Firms that separate those two workstreams, and put the repeatable half on rails, tend to keep RoC engagements profitable.

4. Draft the report in the current template

The RoC template is the standard document PCI SSC publishes for QSAs to fill out — the actual file where the assessment gets written up. For reports drafted in 2026, the current version is mandatory, and since January 2025 that's meant RoC Template r3.

r3 streamlined a few things worth knowing about. The detailed remote-testing tables collapsed into a single question and justification. Sampling documentation moved into Part II next to the findings it supports. The separate lead assessor attestation signature is gone.

Drafting in r3 offers a bit of flexibility, but only on presentation. Firms can tweak table layouts and add appendices. The prescribed tables still need every required detail, every finding still references its evidence by number, and every compensating or customized control still gets its matching appendix filled out.

5. Put the report through internal QA before it leaves the firm

Before a RoC leaves the firm, it goes through an internal QA review. That QA review is what gives the firm reasonable assurance that the assessment was complete, that the results are correct, and that someone outside the engagement team can actually read and understand it. PCI SSC's own quality program checks RoCs against the same bar.

QA reviewers are looking for one coherent story that holds up across the RoC and the Attestation of Compliance (AOC). Most drafts trip up in the same spot: another reviewer can't reproduce the testing just by reading the write-up. A note that firewall configurations were "reviewed and marked in place" fails that test. A description of which configurations, examined how, and showing what, passes.

QSA firms also do an annual quality assurance review of their own and hand it to PCI SSC. A weak RoC creates risk at the firm level, not just the engagement level.

6. Sign the attestation and submit the package

The AOC is the official form that summarizes the assessment results. An authorized officer at the QSA Company signs it, which formally puts the firm's name behind the work. From there, merchants submit the RoC, AOC, and supporting documentation (like ASV scan reports) to their acquirer. Service providers submit to the payment brand or whoever requested the assessment. PCI SSC itself doesn't routinely receive these packages or enforce compliance. Acceptance sits with the brands and acquirers reading them.

For the assessment team, submitting isn't the finish line. It's the start of retention and revalidation work. Assessment results and related materials have to be available to PCI SSC on request for at least three years after the assessment, so work paper organization matters well past sign-off. Annual revalidation and passing scans keep going, with scope confirmed at least every 12 months. A RoC isn't a one-time deliverable. It's a recurring rhythm of scoping, testing, drafting, QA, and revalidation.

Running RoC engagements on one platform

Six phases of detailed requirements produce a huge volume of evidence, and that record is hard to keep straight when teams run it out of email threads, spreadsheets, shared drives, and other disconnected tools. Fieldguide puts the full engagement lifecycle in one place: a pre-built PCI DSS framework, client request tracking, evidence collection, workpapers, and AI-assisted reporting, with practitioners reviewing and approving every output. Field Agents handle the evidence-heavy workflow steps, so a compliance practice can grow without QA turning into the bottleneck. Maxwell Locke & Ritter reported 5x growth in its risk and compliance practice after moving engagements onto the platform. To see how Fieldguide can support your PCI RoC engagements end to end, book a demo.