A Guide to the PCI Report on Compliance (RoC)

If your business processes credit card data, protecting client information is a key responsibility. The Security Standards Council (SSC) developed Payment Card Industry (PCI) Data Security Standards (DSS) to make these protections easier to achieve.

The PCI DSS process requires quite a few steps. One of these is receiving a Report on Compliance (RoC), which proves that you’ve taken the right measures to protect sensitive cardholder data.

Understanding the PCI RoC process can save you from compliance headaches and strengthen your overall security posture, whether you're a merchant or service provider.

What Is a PCI DSS Report on Compliance?

A PCI RoC is an in-depth evaluation that proves a business meets PCI DSS requirements. It usually comes from a Qualified Security Assessor (QSA) or an Internal Security Assessor (ISA) and thoroughly examines your organization’s security practices, from how you store and transmit cardholder data to how you assess risk.

By assessing compliance with the PCI DSS requirements, the RoC demonstrates your commitment to protecting sensitive customer information. This report is key to maintaining trust and strengthening security, especially if your business operates in regulated industries like financial services, healthcare, and technology.

Who Needs a PCI DSS Report on Compliance?

Not every organization handling credit card data needs a RoC. It depends on your PCI DSS compliance level.

Generally, Level 1 merchants and Level 1 service providers, like hosted e-commerce providers, must complete a RoC annually. Level 2 merchants typically complete a Self-Assessment Questionnaire (SAQ), but some payment brands or acquiring banks may still require a RoC. For Level 3 and Level 4 merchants, an SAQ is usually sufficient. Both levels must also complete quarterly vulnerability scans by an Approved Scanning Vendor (ASV).

If an organization has experienced a data breach or a significant security incident, it might be required to complete a RoC, regardless of its level and transaction volume. Ultimately, your acquiring bank or payment brand determines if your organization must submit a RoC or if an SAQ will suffice.

Difference Between Report on Compliance, Attestation of Compliance, and Self-Assessment Questionnaire

Understanding how the PCI RoC, AoC, and SAQ differ—and when each applies—helps your organization streamline compliance efforts and avoid unnecessary complexity.

What Is a Self-Assessment Questionnaire?

The SAQ is a validation tool for smaller merchants and service providers. It’s a do-it-yourself checklist that demonstrates PCI DSS compliance without requiring an on-site assessment by a QSA.

SAQs come in multiple versions tailored to different business models and payment processing methods. While each is more streamlined and cost-effective than a RoC, the SAQ lacks the depth of a formal audit and is generally reserved for organizations with lower risk profiles.

What Is an Attestation of Compliance?

An Attestation of Compliance (AoC) formally declares an organization’s PCI DSS compliance status. Organizations typically complete it after finalizing an SAQ or RoC.

While the RoC dives deep into systems, policies, and vulnerabilities, the AoC simply verifies and attests to those findings, making it easier to share compliance status with stakeholders or acquiring banks.

What Does a Report on Compliance Cover?

Each section of an RoC serves a specific purpose, providing clarity and accountability for both internal teams and external stakeholders.

Here are the key components of a RoC and what each section entails:

Contact Information and Report Date

This section outlines the contact details of the assessed organization and the QSA or ISA responsible for the evaluation. It also includes the date and timeframe of the assessment, providing a clear reference point for when the compliance validation happened.

Executive Summary

The executive summary provides an overview of the results for stakeholders who need a quick snapshot of their organization’s compliance status without going into technical specifics. It outlines the audit's scope, your organization's cardholder data environment (CDE), and significant findings from the compliance validation.

Description of Scope and Approach Taken

This section explains the scope of the PCI DSS assessment, identifying which systems, networks, and processes were included. It also details the assessment methodologies and testing procedures the assessor used to evaluate compliance.

Details About the Reviewed Environment

This part examines the CDE's technical and operational details. It includes network diagrams, descriptions of data flows, and the role of third-party providers involved in storing or transmitting cardholder data.

Quarterly Scan Results

The quarterly vulnerability scan results section summarizes findings from an ASV's last four external scans. It highlights vulnerabilities, remediation efforts, and whether the scans met PCI DSS standards.

Findings and Observations

This is the core of the RoC, where the assessor documents their evaluation of the organization’s compliance with PCI DSS requirements. Each requirement appears here in detail, with observations about how well your organization meets the specific standards. This includes areas where you achieved compliance or needed remediation.

5 Steps in the PCI Report on Compliance Process

Completing a PCI RoC is a multi-step process that requires careful planning, collaboration, and documentation. Each phase builds on the previous one, guiding your organization from preparation to validation. Below, we’ll walk through the key steps in the RoC process.

1. Locate a QSA

The first step in the RoC process is to hire a QSA (or use an ISA if your organization has one on staff). When selecting a QSA, look for one with experience in your industry, clear communication practices, and a well-documented assessment methodology.

2. Provide Documentation to Your QSA

Before the assessment begins, you must gather and share documentation with your QSA. This includes:

Security policies and procedures
Network architecture diagrams
Incident response plans
Access control policies
Evidence of security awareness training

3. Complete the Assessment Process

During this phase, the QSA conducts an on-site audit and evaluates your organization’s compliance with PCI DSS requirements. Following an application security risk assessment checklist beforehand can help you include all critical components and save time.

This phase involves:

Interviews with key personnel involved in cardholder data handling
Technical testing and verification of security controls
Review of evidence and documentation provided by your team

Throughout this phase, the QSA will identify any gaps or vulnerabilities and provide recommendations for remediation.

4. Address Identified Gaps

If the assessment uncovers non-compliance issues, you must address them before the RoC can be finalized. This might involve:

Patching vulnerabilities
Updating security configurations
Implementing compensating controls

5. Finalize and Submit the RoC

Once remediation is complete, the QSA finalizes the RoC document and submits it for review. This report attests to PCI DSS compliance and must be retained for audit purposes. At this stage, it’s also common to receive an AoC.

RoC Results

At the end of a PCI RoC assessment, the QSA categorizes each PCI DSS requirement based on how well your organization met the specified criteria. These results clearly show your compliance status and highlight areas requiring attention.

Here are the possible outcomes:

In Place: This result indicates that the requirement is fully compliant and validated during the assessment.
In Place With Remediation: The requirement was not fully met initially, but your organization successfully remediated the issue during the assessment period. The QSA verified that you implemented the necessary fixes and now meet the PCI DSS requirements.
Not Applicable: This result applies when a specific PCI DSS requirement doesn’t apply to your organization's environment or operations. For example, if your organization doesn’t store cardholder data, certain encryption or storage requirements might not be relevant. The QSA must document the justification for marking a requirement as not applicable.
Not Tested: This outcome means the QSA didn’t assess the requirement during the evaluation. This is rare and happens when specific conditions prevent testing, but the reason must be documented.
Not in Place: This indicates that you didn’t meet the requirement at the time of assessment. The necessary controls, policies, or technical measures are either missing, improperly configured, or ineffective.

How to Recover after a Failed RoC

Failing a PCI RoC can be a significant setback, but it also serves as an opportunity to improve your organization's security practices and compliance posture. Recovery requires clear communication, swift action, and a structured plan.

Here are the key steps your organization should follow:

1. Notify Relevant Stakeholders

Once you receive a failed RoC result, the priority is to notify key stakeholders—your executive leadership team, IT department, acquiring bank, and payment brands. Open communication sets expectations and ensures alignment on the next steps.

2. Identify the Problem

Next, work with your QSA to review the findings from the failed assessment. Identify the root causes of non-compliance, whether from policy gaps, technical vulnerabilities, or process failures.

This step may include:

Analyzing the assessment findings line by line
Conducting internal reviews of affected systems
Mapping vulnerabilities to their corresponding PCI DSS requirements

3. Create a Recovery Plan

Develop a detailed recovery plan that outlines actionable steps to address each non-compliance issue. Create a prioritized list of tasks based on risk and urgency, timelines and deadlines for remediation efforts, and clear ownership and accountability for each action item.

4. Implement Remediation Measures

Start addressing the identified issues systematically. This phase may involve:

Patching vulnerabilities in systems and software
Updating or refining security policies and procedures
Enhancing network segmentation and encryption controls
Training staff on security best practices

Your QSA will need evidence of these changes during reassessment, so document every step.

5. Perform Internal Audits and Validation

Before scheduling a reassessment, conduct internal audits to verify that all remediation measures have been effectively implemented. Re-test security controls to ensure they function as intended, conduct vulnerability scans and penetration testing, and review updated documentation for accuracy.

6. Schedule a Reassessment

Once confident in your remediation efforts, schedule a reassessment with your QSA. This follow-up review should focus on previously identified issues to make sure you address all gaps. Provide your QSA with clear evidence of your remediation work, including updated policies, configurations, and testing results.

7. Foster a Culture of Continuous Compliance

PCI DSS compliance isn’t a one-time event—it requires ongoing effort. To maintain compliance and prevent future failures:

Conduct regular internal compliance reviews
Stay up-to-date with PCI DSS updates and best practices
Implement continuous monitoring tools to detect vulnerabilities early
Provide ongoing security awareness training for employees

PCI DSS Compliance With Legit Security

Achieving PCI DSS compliance is about building a secure foundation that protects cardholder data and earns customer trust. From navigating RoC requirements to addressing compliance gaps, every step plays a role in maintaining strong security practices.

Legit Security simplifies PCI DSS compliance by streamlining processes and making sure you have the evidence and attestation for audits and assessments. Identify vulnerabilities early, ensure continuous security readiness at all times, and help your organization focus on growth without compromising security. Schedule a demo to learn more.