This article includes insights from, Brian Carey, Qualified Security Assessor (QSA) and Senior Security Consultant at GraVoc. He helps organizations navigate PCI DSS compliance, security assessments, and risk management.
Organizations validate PCI compliance through a Self-Assessment Questionnaire (SAQ) or a Report on Compliance (ROC), but understanding which path applies to your business can be confusing.
As a PCI Qualified Security Assessor (QSA), GraVoc's Brian Carey has worked with many organizations that started with the wrong validation method. Some assumed they could complete an SAQ when their payment environment actually required the more rigorous ROC. As Brian explains,
"Choosing the wrong validation method can lead to false assumptions about compliance, which is something we see quite often."
Understanding the differences between an SAQ, ROC, and Attestation of Compliance (AOC) is the first step toward determining your PCI compliance requirements. While the SAQ and ROC are methods for validating compliance, the AOC is the formal document used to attest the results of that validation.
In this guide, we'll explain what each means, when an SAQ may be sufficient, when a ROC may be required, common compliance mistakes businesses make, and how to choose the right validation path for your environment.
Key takeaways
- An SAQ is a self-assessment, a ROC is an independent assessment performed by a QSA, and an AOC is the document used to demonstrate compliance.
- Merchant level, transaction volume, PCI scope, and card brand requirements all influence whether an organization can use an SAQ or requires a ROC.
- Outsourcing payment processing doesn't automatically eliminate PCI responsibilities.
- PCI scope often expands over time due to new technologies, integrations, and business processes.
- Many organizations unknowingly choose the wrong validation method, leading to compliance gaps and unnecessary risk.
- Understanding your environment is the first step toward selecting the right PCI validation path.
Prefer to watch instead?
In this short video, Brian explains the differences between SAQs, ROCs, and AOCs, common misconceptions he sees during PCI assessments, and why choosing the wrong validation method can create a false sense of compliance.
What is a PCI SAQ?
A Self-Assessment Questionnaire (SAQ) allows an organization to assess its own compliance with PCI DSS requirements. There are 10 SAQ types, designed for different payment environments. Depending on the SAQ type, businesses evaluate themselves against a subset or, in some cases, all PCI DSS requirements.
At a high level:
- SAQ A: Typically used by merchants that fully outsource payment processing and do not electronically store, process, or transmit cardholder data.
- SAQ A-EP: Intended for eCommerce merchants that outsource payment processing but whose websites can still impact the security of the payment transaction.
- SAQ B: Designed for merchants using standalone dial-out terminals and who do not store electronic cardholder data.
- SAQ B-IP: Applies to merchants using standalone IP-connected payment terminals.
- SAQ C-VT: For merchants that manually enter payment information into a web-based virtual terminal provided by a payment processor.
- SAQ C: Used by merchants with payment application systems connected to the internet but with limited payment infrastructure.
- SAQ P2PE: For merchants using a validated Point-to-Point Encryption (P2PE) solution.
- SAQ SPoC: For merchants that use a commercial, off-the-shelf mobile device with a validated card reader.
- SAQ D (Merchant): The most comprehensive merchant SAQ, used when no other SAQ type applies.
- SAQ D (Service Provider): Intended for service providers and includes the full set of applicable PCI DSS requirements.
Read our detailed guide, PCI SAQ Types: Which SAQ Is Right for Your Business?, for a breakdown of each questionnaire type and eligibility requirements.
What is a PCI ROC?
A Report on Compliance (ROC) is the most comprehensive PCI validation method available. Brian explains, "A ROC is a formal, independent assessment performed by a qualified security assessor, or QSA. It is the most comprehensive validation method and results in a detailed report that evaluates every applicable PCI requirement”
A ROC is typically required for:
- Level 1 merchants
- Certain service providers
- Organizations processing millions of payment card transactions annually
- Businesses that store, process, or transmit significant amounts of cardholder data
- Organizations with complex or highly integrated payment environments
- Businesses whose acquiring bank or payment card brand requires independent PCI validation
One of the primary factors that determines whether a ROC is required is merchant level classification. Visa and Mastercard both establish PCI compliance validation requirements based on merchant and service provider classifications. For instance, Visa classifies merchants processing over 6 million transactions annually across all channels as Level 1 and requires they complete an ROC. For current merchant-level guidance, consult the official requirements published by Visa and Mastercard.
In general, merchants with large transaction volumes and certain service providers are required to annually validate compliance through a ROC.
Brian says, "A ROC provides a much higher level of assurance, not just to regulators, but also to partners, customers, and acquiring banks. It demonstrates that controls have been independently tested, not just self-reported."
What is a PCI AOC?
An Attestation of Compliance (AOC) is the formal document organizations use to demonstrate PCI compliance to external stakeholders.
Whether compliance is validated through an SAQ or a ROC, the AOC serves as the official declaration that the assessment was completed and compliance requirements were met.
Many organizations mistakenly assume that the AOC is a separate assessment. The AOC is the outcome, while the SAQ or ROC is the validation method used.
As Brian notes, "Regardless of which method you use, you will require an attestation of compliance, or AOC. This is a separate document and usually the document which you can provide to your external stakeholders."
PCI compliance mistakes: Why understanding the difference between SAQ & ROC matters
Many organizations run into problems because they misunderstood which assessment applies to them. Brian notes, "A business might believe that they are compliant because they completed an SAQ, when in reality their environment actually requires a ROC, or at least a more comprehensive SAQ."
Here are 3 of the biggest PCI compliance mistakes businesses make:
Mistake #1: "We Use a Third-Party Payment Processor, So PCI Doesn't Apply"
This is one of the most common misconceptions PCI assessors encounter.
As Brian says, "One of the biggest is, we use a third-party payment processor, so we're out of scope for PCI."
Unfortunately, it's often incorrect.
"In reality, even if payments are outsourced, systems that touch, transmit, or can impact cardholder data may still be in scope."
For example, eCommerce websites, payment integrations, customer portals, and connected applications can all introduce PCI scope in ways organizations may not expect. This is why businesses that assume they qualify for SAQ A sometimes discover they require SAQ A-EP or a more comprehensive assessment after a proper scoping review.
Mistake #2: Using the Same SAQ Every Year
PCI scope isn't static. According to Brian, "PCI scope can change over time. New integrations, new tools, or even new analytics platforms can introduce risk and expand scope without the organization even realizing it."
Any new tools or changes to your environment can impact scope and potentially affect which PCI validation method applies.
Mistake #3: Assuming a ROC Is Optional
Many organizations assume they'll pursue a ROC when they're ready. However, Brian says, "The reality is, this requirement isn't optional. It's driven by transaction volume, contractual obligations, and risk profile, not just your preference."
Whether a ROC is required is typically influenced by PCI obligations and stakeholder requirements, not organizational preference.
Do you need an SAQ or a ROC?
Ultimately, choosing between every environment is different, but there are some general indicators.
You May Qualify for an SAQ If:
- Cardholder data is fully outsourced
- Your environment is simple and well-defined
- You do not store cardholder data
- PCI scope is limited and clearly understood
A ROC May Be Required If:
- You store, process, or transmit significant amounts of cardholder data
- Your environment includes multiple interconnected systems
- There are extensive third-party integrations
- Independent validation is required by acquiring banks or payment brands
- Your merchant or service provider level requires a ROC
At the end of the day, determining the correct validation method requires understanding your payment environment, compliance obligations, and PCI scope.
Frequently asked questions about PCI SAQ vs ROC vs AOC
What do I need to provide to a bank or customer as proof of PCI compliance?
Most organizations provide an AOC. Some stakeholders may also request supporting documentation, such as a Report on Compliance (ROC), security scan results, or additional evidence based on contractual requirements and risk considerations.
When is an SAQ enough?
An SAQ may be sufficient if your organization meets the eligibility requirements for a specific SAQ type and your acquiring bank and payment card brands permit self-assessment validation. The answer depends on factors such as PCI scope, payment architecture, merchant level, and transaction volume.
If I complete an SAQ, do I still need an AOC?
Typically, yes. The SAQ is the assessment itself, while the AOC is the document used to formally attest that the assessment was completed and compliance requirements were met.
When do I need a Qualified Security Assessor (QSA)?
A QSA is required when an organization must complete an independent PCI assessment resulting in a ROC. Many organizations also engage a QSA for PCI scoping exercises, SAQ selection, readiness assessments, and guidance on complex PCI requirements.
