Which Businesses Are Required to Submit a PCI ROC?

Key Takeaways

• A PCI ROC is the formal report used to document an onsite PCI DSS assessment, and it is typically required when a business needs the fullest level of PCI validation.
• Level 1 merchants and Level 1 service providers are the businesses most commonly required to complete a PCI DSS ROC. 
• Not every business subject to PCI DSS needs a ROC, because some organizations validate compliance through a Self-Assessment Questionnaire instead. 
• The need for a ROC PCI compliance report is usually driven by business type, transaction volume, and the validation requirements set by the acquiring bank or payment brand. 

What Is a PCI ROC?

A PCI ROC stands for PCI Report on Compliance. It is the detailed report created during an on-site PCI DSS assessment. It is used to document whether the organization met each applicable PCI DSS requirement. PCI SSC’s current document library shows that the ROC remains an active reporting document under PCI DSS v4.0.1, and PCI SSC announced the v4.0.1 ROC template in August 2024.

The PCI compliance ROC is more detailed than an SAQ and is typically associated with larger, more complex, or more closely reviewed card-data environments.

Why Only Some Businesses Need a ROC 

PCI requirements are tiered. Card brands and acquirers do not treat every business the same way. Validation expectations depend on the organization’s role in the payment ecosystem, its transaction volume, and the requirements imposed by the parties that accept its PCI compliance documentation. Visa says the merchant level is based on total Visa transaction volume over a 12-month period and that this level determines the necessary validation requirements. Visa also says acquirers must ensure merchants validate at the appropriate level and obtain the required compliance validation documentation.

That is why a business can be fully in scope for PCI DSS without automatically needing a PCI ROC. PCI DSS may apply either way. The real question is which validation method applies.

PCI ROC vs. SAQ

A ROC and an SAQ are both validation tools, but they are not the same thing.

A ROC is tied to an on-site PCI DSS assessment. An SAQ is intended for SAQ-eligible merchants and service providers performing a self-assessment. PCI SSC’s bulletin on the v4.0.1 SAQs says these questionnaires are validation tools intended to assist SAQ-eligible entities in performing and reporting the results of their PCI DSS self-assessment.

Which Businesses Usually Need a PCI ROC?

Level 1 Merchants

Level 1 merchants are the most common example.

Visa says the merchant level is determined by total Visa transaction volume over 12 months and that validation requirements follow from that level. Mastercard states more directly that Level 1 merchants must undergo an annual PCI DSS assessment, resulting in the completion of a ROC and AOC. That means large merchants processing high annual volumes of card transactions are the businesses most clearly associated with the PCI DSS ROC requirement.

Level 1 Service Providers

Level 1 service providers are another major group that commonly need a ROC.

Mastercard’s service provider FAQ says Level 1 service providers must validate PCI DSS compliance annually by successfully undergoing a PCI assessment resulting in the completion of a Report on Compliance. Mastercard’s public materials also tie annual PCI validation to registered Level 1 and Level 2 service providers, with review of SAQs or ROCs depending on the provider and program context.

In practical terms, this can include payment processors, gateways, and other service providers whose systems or services affect the security of cardholder data. Not every service provider is automatically in the same validation category, but Level 1 service providers are one of the clearest groups that typically require a ROC PCI compliance assessment.

Businesses Required To Do So by an Acquirer or Payment Brand

Some businesses are required to complete a ROC even if they do not fit the simplest “Level 1 merchant” description.

Visa makes clear that acquirers are responsible for ensuring merchants validate at the correct level and provide the required compliance documentation. Mastercard’s public guidance similarly shows that validation obligations are shaped by program rules and by the parties managing PCI reporting within the payment ecosystem.

Can a Lower-Level Businesses Ever Need a ROC?

Not every ROC is tied only to the highest merchant tier. Mastercard’s public guidance says Level 2 merchants generally complete an annual SAQ. Even so, merchants completing SAQ A may alternatively engage a PCI SSC-approved QSA to complete a ROC at their own discretion. PCI SSC’s SAQ guidance also makes clear that SAQs are for SAQ-eligible entities, which means not every lower-level business will always use that route in practice.

So while Level 1 merchants and Level 1 service providers are by far the most common businesses required to submit a PCI compliance report, they are not always the only ones that may end up using a ROC.

What Does a PCI ROC Include?

A ROC is not a short form. It is a detailed report used to document the scope of the assessment, the environment reviewed, the testing performed, and the compliance status for each applicable requirement. PCI SSC’s v4.0.1 ROC materials remain part of the current reporting framework, which reflects the continuing role of the ROC in formal PCI DSS assessments.

That level of detail is one reason the ROC is associated with organizations that need stronger formal validation. It is meant to show how the assessment was performed and how the conclusions were reached, not simply state that the organization is compliant.

How Do You Know If Your Business Needs One?

If your organization is a Level 1 merchant, a Level 1 service provider, or a business that your acquirer or payment brand has directed to validate through a full onsite assessment, you likely need a PCI ROC. If your organization is SAQ-eligible, your validation path may be different.

The best next step is to confirm your merchant or service-provider level and then verify the required validation method with the party that accepts your PCI documentation. Visa’s guidance makes clear that acquirers play a central role in that decision for merchants, and Mastercard’s public materials show the same structured approach through its program requirements.

How Centraleyes Supports ROC Readiness

Centraleyes helps businesses prepare for PCI ROC submission by generating PCI reporting based on their actual environment. Instead of building documentation by hand, teams can use Centraleyes to centralize evidence, track control status, manage remediation, and maintain a clearer view of readiness across the assessment process. The result is a more structured, submission-ready path to PCI documentation with less manual effort.

FAQs

How do you know whether your business is being treated as a merchant or a service provider for PCI validation purposes?

That question matters because ROC expectations are often tied to entity classification before anything else. A business’s role in the payment ecosystem affects which validation track applies, how levels are interpreted, and which party is responsible for accepting the documentation. Card-brand programs distinguish between merchants and service providers for exactly this reason. 

Why do some businesses with similar payment environments end up with different ROC requirements?

Because PCI validation is not based on the technical environment alone. Two companies may have similar payment flows but different reporting obligations because their acquirers, card brands, contractual arrangements, or formal classifications are different. In practice, PCI validation is shaped by both the environment and the business relationship around it. 

If a business has changed its payment environment recently, does that matter for ROC preparation?

Yes. Changes to architecture, payment flows, service-provider relationships, or segmentation assumptions can all affect scope and assessment readiness. Since an ROC is tied to the actual assessed environment, teams need to make sure the documented picture reflects what is really in place at the time of review.