Which Businesses Are Required to Submit a PCI ROC?
Key Takeaways
- While a Self-Assessment Questionnaire (SAQ) is a self-driven validation tool for smaller or less complex entities, the Report on Compliance (ROC) is the mandatory reporting vehicle for assessor-led PCI DSS assessments.
- If your business has engaged a QSA for a full validation engagement, the ROC is the non-negotiable output.
- PCI DSS v4.0.1 is in effect. Assessors must use the ROC Template, Revision 3 (released in January 2025), to document compliance.
- Selecting a “Not Tested” status for any requirement automatically classifies the engagement as a “Partial Assessment.”
Setting the Stage for PCI Compliance
In the high-stakes world of global payments, protecting account data is a fundamental business imperative. The PCI Security Standards Council (PCI SSC) maintains the PCI Data Security Standard (PCI DSS), a rigorous framework designed to secure the payment ecosystem. While every entity handling cardholder data must remain compliant, the reporting requirements vary significantly based on transaction volume and risk profile.
What is a ROC?
The ROC PCI is the mandatory template that a qualified security assessor (QSA) must use to document the results of a detailed assessment. The QSA uses the ROC to show how the business was tested against PCI DSS requirements and what the assessor found.
The assessor may:
- Visit or observe parts of the environment
- Speak with technical and business staff
- Review system settings
- Look at the testing results
- Examine documents, screenshots, file lists, policies etc.
Are You a Merchant or Service Provider?
1. A merchant is a business that accepts card payments for its own products or services. This could be a retailer, an e-commerce store, a restaurant group, a healthcare provider, a university, a hotel, or any other organization that takes payment cards from customers.
2. A service provider is different. A service provider stores, processes, transmits, or can affect the security of cardholder data on behalf of another business. This may include payment processors, payment gateways, hosting providers, managed service providers, SaaS platforms, or other vendors connected to a cardholder data environment.
ROC requirements can apply to both merchants and service providers, but the reason may be different. For merchants, the requirement is often tied to transaction volume and merchant level. For service providers, it is usually tied to the services they provide, the number of accounts they affect, customer requirements, or card brand and acquirer expectations.
Who is Required to Submit a PCI ROC?
If you are undergoing a detailed PCI DSS assessment rather than a self-assessment, you must use the ROC template. While specific mandates are set by card brands and acquirers, the ROC requirement generally applies to:
- Level 1 Merchants and Service Providers: High-volume entities that require on-site validation.
- Designated Entities: Organizations requiring supplemental validation (DESV) due to their risk profile or a history of data compromise.
- Multi-tenant Service Providers: Providers serving multiple customers must address specific risks outlined in Appendix A1.
- Complex Environments: Any entity that chooses to engage a QSA for a full, formal validation.
What to Expect During a PCI DSS ROC Assessment
A PCI ROC assessment is more involved than completing an SAQ. Here’s what businesses should expect:
1. Scoping comes first
The assessor will identify which systems, locations, payment channels, applications, vendors, and business processes are part of the cardholder data environment.
2. Documentation review
The assessor will review policies, procedures, network diagrams, system inventories, incident response plans, access control processes, vendor documentation, and other PCI-related records.
3. Evidence collection
The business will need to provide proof that controls are actually in place. This may include vulnerability scan results, penetration test reports, firewall configurations, access review records, logging evidence, training records, and screenshots.
4. Staff interviews
The assessor may speak with security, IT, compliance, operations, and business process owners to confirm how controls work in practice.
5. Control testing
The assessor will test selected requirements by reviewing configurations, inspecting systems, observing processes, and validating samples.
6. Third-party review
If service providers support the cardholder data environment, the assessor may review their contracts, responsibilities, and Attestations of Compliance.
7. Gap identification
If a requirement is not fully met, the business may need to remediate the issue before the final ROC can show the requirement as “In Place.”
8. Assessment findings are assigned
Each requirement will be marked with a finding, such as In Place, Not Applicable, Not Tested, or Not in Place.
9. The ROC is completed
The final ROC documents the assessor’s testing, evidence review, scope, findings, and conclusions using the official PCI SSC template.
10. The AOC may be shared afterward
In many cases, the Attestation of Compliance is the document shared with banks, payment brands, customers, or business partners, while the full ROC is shared more selectively.
Understanding Assessment Findings and Reporting Options
Assessing ROC PCI compliance requires precision. For every sub-requirement, an assessor must assign one of four findings. A hallmark of a senior consultant is understanding the nuance between “Not Applicable” and “Not Tested.”
| Assessment Finding | Technical Definition | Required Reporting Action |
| In Place | All elements of the requirement are met through thorough testing. | Describe how testing and evidence demonstrate compliance. |
| Not Applicable (N/A) | The requirement does not apply (e.g., no wireless technology). Includes “best practice” requirements until their effective date (e.g., after March 31, 2025). | Assessor must render an opinion. Describe testing performed to confirm the technology or process is truly absent. |
| Not Tested | Requirement excluded from consideration (e.g., assessing only a subset of milestones). Results in a Partial Assessment. | No opinion needed. Describe why the requirement was excluded based on entity instructions. |
| Not in Place | Elements are not met, are in remediation, or require further testing before status is known. Also used for legal prohibitions. | Describe why it is not met. If due to law, identify the specific statutory law or regulation (not just legal advice). |
ROC vs. AOC: What Do You Actually Submit?
A ROC and an AOC are closely related, but they are not the same document.
A PCI compliance ROC is the detailed assessment report. It documents the assessor’s testing, evidence review, findings, scope, sampling decisions, service provider dependencies, and explanations for each PCI DSS requirement. It is the full record of the assessment.
The AOC, or Attestation of Compliance, is the formal attestation that summarizes the results of the assessment. In many situations, the AOC is the document shared more broadly with banks, payment brands, business partners, or customers. The ROC itself may be shared more selectively because it contains much more detailed information about the assessed environment.
The Road to v4.0.1: Current Standards and Templates
The transition to PCI DSS v4.0.1 in June 2024 brought significant administrative refinements. To align with these changes, the Council released ROC Template Revision 3 in January 2025.
A critical “expert level” update in Revision 3 is the change to Section 6.2 (Sampling). A new row has been added to the end of the sampling table for “If ‘Yes’ responses.” This is a mandatory administrative detail that, if missed, can lead to report rejection during quality assurance reviews. For further granular details, practitioners should always consult the official PCI DSS v4.x Report on Compliance Template – Frequently Asked Questions document on the PCI SSC website.
FAQs
1. Can we use our own company logo on the ROC?
Yes. Personalization is acceptable on the title page, including the addition of company logos, though the rest of the template structure must remain untouched.
2. Can we delete sections of the ROC template that don’t apply to us?
No. The assessor must not remove any content from Part I or Part II. If a section does not apply, it must be marked as “Not Applicable” (N/A). Deleting rows or sections is a violation of the reporting instructions.
3. What happens if a requirement is “Not in Place” because a local law forbids it?
The assessor must select “Not in Place” and provide a description of the specific statutory law or regulation that prohibits compliance. It is important to note that contractual obligations or general “legal advice” are not valid legal restrictions.
4. What are the evidence retention requirements for an ROC?
While the ROC is a summary, the underlying “work papers” must be comprehensive. Section 6.1 of the template requires the assessor to document their actual evidence retention policy. This ensures all observations and testing results are archived for the duration required by card brands or acquirers.
The post Which Businesses Are Required to Submit a PCI ROC? appeared first on Centraleyes.
*** This is a Security Bloggers Network syndicated blog from Centraleyes authored by Rebecca Kappel. Read the original post at: https://www.centraleyes.com/which-businesses-are-required-to-submit-a-pci-roc-2/
