Summary
- A Report on Compliance (ROC) is a formal PCI DSS audit report conducted by a Qualified Security Assessor (QSA).
- ROCs are required for Level 1 merchants and service providers processing large volumes of cardholder data.
- The report documents control testing results, gaps, and compliance status across all 12 PCI DSS requirements.
- ROCs must be submitted to acquiring banks or payment brands annually.
- AROC (Attestation of ROC) and ASV scans are typically submitted alongside the Report on Compliance (ROC).

What Is a Report on Compliance?
A Report on Compliance (ROC) is a detailed audit report that verifies an organization’s compliance with the PCI Data Security Standard (PCI DSS). It must be completed by a Qualified Security Assessor (QSA) or an ISA-certified internal assessor and submitted to the organization’s acquiring bank or card brand upon request.
The Report on Compliance (ROC) includes:
- A description of the organization’s cardholder data environment (CDE)
- Documentation of which PCI DSS requirements are in place, tested, and met
- Any gaps or compensating controls used
- Interview findings, network diagrams, and evidence summaries
- Final compliance status across all 12 PCI DSS sections
The Report on Compliance (ROC) is the gold standard of PCI validation. It provides a complete picture of your compliance posture.
Who Needs a ROC?
A ROC is required for:
- Level 1 merchants (processing over 6 million Visa or Mastercard transactions annually)
- Level 1 service providers (processing, storing, or transmitting large volumes of cardholder data for others)
- Any organization explicitly required to submit a ROC by its acquiring bank or card brand
- Lower-level merchants (Levels 2–4) usually complete a Self-Assessment Questionnaire (SAQ) instead—but some opt for a ROC to demonstrate higher assurance.
What’s Included in a ROC?
A PCI ROC includes:
- Executive summary of the business model and CDE
- Scoping narrative to define what systems are in scope
- Testing results for each of the 12 PCI DSS requirement categories
- Evidence collected through interviews, documentation review, and technical testing
- Findings including passed, failed, or partially met controls
- Compensating control worksheets (if applicable)
- Final compliance determination and assessor attestation
The process is comprehensive and may take weeks or months to complete—especially in complex, multi-cloud, or distributed environments.
Real-World Example
A global fintech company processing over 12 million transactions annually was required to submit a ROC under PCI DSS 4.0. During the QSA-led audit, the team discovered gaps in client-side script monitoring and lacked evidence of compliance with Requirement 11.6.1. By implementing automated script monitoring and evidence capture, the organization resolved the issue and received a passing ROC within the audit deadline.
FAQ
How often do I need a ROC?
Annually. If you’re a Level 1 merchant or service provider, you must complete a ROC every 12 months and keep it on file for submission.
Can I complete my own ROC without a QSA?
Only if your internal team includes an ISA (Internal Security Assessor) certified by the PCI SSC and your acquirer permits it. Most organizations still use a QSA.
Do I need a ROC if I use Stripe or Shopify?
Likely not—unless you’re a Level 1 service provider yourself. Hosted payment providers can reduce your PCI scope, but you must validate eligibility for a simpler SAQ.
Conclusion
A Report on Compliance (ROC) is the most formal and rigorous way to validate PCI DSS compliance. It’s not just a report—it’s a full-scale audit of your cardholder data environment, policies, technical controls, and operational practices.
If you’re a high-volume merchant or service provider, a ROC is required—and it must be:
- Completed annually by a QSA or ISA
- Supported with evidence, diagrams, and control testing
- Accompanied by a signed AOC for partner or acquirer distribution
- Aligned with PCI DSS 4.0 controls, including newer client-side and real-time monitoring requirements
Treat the ROC process not just as a regulatory task—but as an opportunity to harden your systems, improve documentation, and strengthen customer trust.