Some security requirements are easy to ignore—until something breaks. PCI DSS compliance isn’t one of them. If your business handles cardholder data, there’s a line you eventually cross where self-attestation no longer applies.
That’s where a Report on Compliance comes in. It’s not just a box to tick. For Level 1 merchants and certain service providers, an RoC becomes mandatory—and with it, the audit process shifts entirely.
Let’s walk through who needs it, what it involves, and how to prepare before a QSA steps in.
What Is a Report on Compliance, and How Is It Different from an SAQ?
A Report on Compliance is a formal validation method used to demonstrate full PCI DSS compliance. It is reviewed and signed off by a Qualified Security Assessor (QSA), who conducts the audit and documents your results across all applicable PCI requirements.
In contrast, a Self-Assessment Questionnaire (SAQ) is a self-declared method used by eligible businesses to confirm their PCI posture. The SAQ route only applies to organizations that meet the eligibility criteria and process fewer transactions annually.
The RoC is thorough. It requires not only evidence, but also formal scoping, interviews, technical validation, and documented attestation by a certified third-party assessor. The result is a signed and submitted report that your acquiring bank or card brand can review.
Who Needs a Full RoC?
The requirement for a full RoC begins with Level 1 merchants—those handling 6 million+ Visa or Mastercard transactions per year (combined volume across all channels). This threshold is set by the major card brands and enforced through your acquiring bank.
RoCs are also required for:
- Service providers with access to cardholder data or that manage systems touching the Cardholder Data Environment (CDE)
- Merchants or providers required to validate compliance through RoC based on contractual obligations or bank requests
- Organizations undergoing M&A, due diligence, or certifications requiring evidence of enterprise-grade compliance
See Visa’s current merchant level definitions here
What’s Included in the RoC Audit Process?
The RoC audit is not just paperwork. It’s a structured review that validates compliance across all 12 core PCI DSS requirements, as outlined in v4.0. This typically includes:
- Scoping: Reviewing what systems, people, and environments are in scope
- Gap Analysis: Identifying non-compliant areas before formal audit begins
- Evidence Collection: Reviewing policies, logs, configurations, access controls, encryption, and retention practices
- Interviews and Observations: Conducting onsite or remote walkthroughs with stakeholders and system owners
- Final Documentation: Completing the official RoC template and submitting it to your acquiring bank
Auditors often flag the scoping phase as where most issues begin. Businesses either underestimate what’s in scope or fail to isolate cardholder data effectively.
Check out the PCI SSC Quick Reference Guide that gives a strong overview of scope boundaries and segmentation.
Common Triggers for Needing an RoC
Some businesses aren’t sure when the RoC becomes necessary. Here are common triggers beyond just the 6 million transaction threshold:
- Growth in volume due to a new product, region, or customer base
- Migration from hosted eCommerce to self-managed infrastructure
- Becoming a SaaS provider or payments integrator
- Expanding to handle B2B payment flows for clients
- Auditor or acquirer mandates RoC as part of a vendor agreement
Here’s one example: A mid-market subscription business scales rapidly after integrating with a marketplace. As payment volume rises and card data flows shift, they transition from SAQ-D to a full RoC to meet partner requirements and avoid fines.
Benefits of Completing a RoC
Though more intensive, a properly executed RoC provides benefits that ripple across the business. Here are some of those benefits:
- Stronger risk posture: A third-party-verified assessment identifies misconfigurations and access loopholes earlier
- Faster deal flow: Enterprise clients often require proof of audit as part of procurement or vendor reviews
- Breach readiness: In the event of an incident, a recent RoC can serve as a reference point for incident response or investigation
- Fewer disputes with partners: Audited documentation offers clarity when working with banks or third-party processors
Many organizations that initially resist a full RoC later treat it as a blueprint for improving not just cardholder data protection, but internal governance as a whole.
Real-World Audit Prep Tips (Without the Stress)
Some parts of an RoC audit catch teams off guard. Here’s what often helps:
- Centralize documentation early: Policies, diagrams, vendor attestations, and access logs should be in one place before audit week
- Segment early and clearly: Clear network segmentation reduces scope and simplifies technical review
- Review logs for data retention and archiving: Missing or incomplete logs remain one of the top QSA findings
- Plan for staff interviews: Your sysadmins, security analysts, and customer support leads may be involved in auditor walkthroughs
Budget for QSA fees and time impact: RoCs are not cheap; project management matters
Final Thoughts
A full RoC marks a turning point in how your business approaches PCI DSS.
What starts as a mandatory assessment often becomes a tool to mature internal systems, documentation, and third-party relationships.
While the costs and complexity are real, the tradeoff is long-term clarity, across your teams, clients, and regulators.
With cardholder data under scrutiny more than ever, being ready for a formal audit shows the kind of discipline that security and compliance leaders increasingly expect.
Here’s the official PCI DSS v4.0 page for full documentation and guidance.