What is PCI Attestation of Compliance?

If you accept card payments, the PCI Data Security Standard is the rulebook that governs how cardholder data needs to be handled, and the PCI Attestation of Compliance (AOC) is the document that proves you're actually doing what you’re supposed to be doing. 

Read this post to learn everything you need to know about the PCI attestation process: what the document is, how to complete it step by step, what PCI DSS v4.0.1 now requires, and what happens once you've signed on the dotted line.

What is a PCI attestation of compliance document?

A PCI Attestation of Compliance is a formal declaration that a merchant or service provider has undergone a PCI DSS assessment and meets the security requirements for handling cardholder data. Think of it as the official receipt for all the compliance work you've done. It's completed after either a Self-Assessment Questionnaire (SAQ) or a Report on Compliance (ROC), and it's the document you submit to your acquiring bank or share with the entities you serve as proof that your payment environment is secure.

The PCI Security Standards Council defines the AOC as the form merchants and service providers use to present the results of their compliance assessment, whether that assessment was completed by a Qualified Security Assessor (QSA), an Internal Security Assessor (ISA), or through self-assessment. There are two distinct versions of the PCI attestation of compliance form: one for merchants and one for service providers. If you're a business submitting a PCI attestation of compliance as a service provider, the requirements you're attesting to are more rigorous, and your AOC is going to need to be backed by a full ROC rather than an SAQ.

It's also worth addressing a question we hear often: has the AOC been replaced by something newer? Nope, it hasn't. PCI DSS v4.0.1 is the current and fully enforced standard as of March 31, 2025, and the AOC remains the active validation document for both merchants and service providers. No successor framework or replacement document has been introduced. What has changed significantly is the scope and specificity of what you're attesting to, which is exactly why this guide exists.

How the merchant AOC differs from the service provider AOC

Merchants use the AOC to confirm that their own payment environment meets PCI DSS requirements. Depending on your merchant level, which we'll get to in a moment, that might mean completing an SAQ internally or going through a full ROC with a third-party assessor.

Service providers operate under a different and more demanding set of rules. A PCI DSS attestation of compliance document submitted by a service provider must reflect a ROC completed by a QSA, and the scoping obligations are wider. Under v4.0.1, service providers must conduct a formal review of their cardholder data environment (CDE) at least every six months, compared to the annual requirement for merchants. If your platform processes, stores, or transmits cardholder data on behalf of other merchants, your AOC carries considerably more weight and your compliance posture needs to match that responsibility.

The PCI attestation of compliance process from start to finish

The AOC isn't something you simply fill out and file. It's the end product of a structured assessment process, and understanding where the form sits within that process makes the whole thing considerably less daunting. Here's how the process works from the first step to the last.

1. Determine your merchant level.

Merchant levels are set by Visa and Mastercard based on your annual transaction volume. Level 1 applies to merchants processing more than six million transactions annually, Level 2 covers one to six million, Level 3 covers 20,000 to one million, and Level 4 covers fewer than 20,000. Service providers have their own tiering structure. Your level determines which type of assessment you're required to complete, and getting this wrong at the start cascades into problems throughout the rest of the process.

2. Identify which SAQ type applies to you, or confirm that a ROC is required.

Level 1 merchants and most service providers must complete a ROC with a QSA or ISA. Merchants at Levels 2 through 4 generally complete a self-assessment using one of several SAQ types, each designed for a specific payment environment. This step got meaningfully more complex in early 2025. The PCI SSC significantly tightened SAQ A eligibility criteria, and merchants whose websites can influence a payment transaction in any way, including by loading JavaScript on a payment form page, no longer qualify. Those merchants now need to complete SAQ A-EP or SAQ D instead, which carry substantially heavier compliance obligations. If you've been using SAQ A for a while and haven't revisited that determination recently, now is the time.

3. Conduct a gap analysis against PCI DSS v4.0.1.

Before you start the formal assessment, you need to know where you stand. As of March 31, 2025, all 64 new or updated requirements introduced in PCI DSS v4.0 are fully mandatory, including the 51 requirements that were originally classified as future-dated best practices during the 2022–2025 transition window. Assessors who previously marked those requirements as "Not Applicable" in earlier ROCs can no longer do so. A gap analysis against the current v4.0.1 standard tells you exactly what's missing before your QSA or your own team starts the formal work.

4. Complete your SAQ or engage a QSA for your ROC.

An SAQ can be completed by an internal team, but it requires discipline and genuine familiarity with your payment architecture. A ROC is a formal, independent assessment conducted by a QSA from the PCI SSC's approved list. For service providers and Level 1 merchants, this isn't optional. The ROC is the foundational document from which your PCI DSS attestation of compliance document is derived, so the quality of the assessment directly determines the quality of the attestation.

5. Complete the PCI attestation of compliance form.

Once your SAQ or ROC is complete, you complete the AOC form itself. This is where you formally declare the results of your assessment. The v4.0.1 versions of the AOC for both merchants and service providers were published by the PCI SSC in October 2024. Using the v4.0 or v3.2.1 forms is no longer valid for new assessments. If you're still holding a template that predates October 2024, it needs to be replaced.

6. Submit to your acquiring bank.

Merchants submit their completed SAQ or ROC, along with the PCI merchant attestation form and quarterly Approved Scanning Vendor (ASV) scan reports, to their acquiring bank. Service providers don't submit to an acquiring bank — instead, they make their PCI attestation of compliance document available to the merchants and processors they serve, typically upon request or as part of a vendor due diligence process.

7. Repeat the process annually.

Compliance is something you’ll always be working on. The AOC has to be renewed every 12 months, and under v4.0.1, several of the underlying activities that feed into it happen much more frequently: quarterly vulnerability scans, continuous automated log review, access reviews every six months, and semi-annual CDE scoping for service providers. The compliance program that keeps your AOC current needs to be a year-round operational practice, not a sprint you run in Q4.

The PCI requirements for attestation

The AOC reflects the results of your assessment against all 12 core PCI DSS requirements. The 12 requirements themselves haven't changed structurally in v4.0.1, but the enforcement scope within several of them has expanded materially. Here's a practical breakdown of each requirement and the most important v4.0.1 updates you need to know about.

Requirement 1: Install and maintain network security controls. The language was updated from v3.2.1's narrow focus on firewalls and routers to reflect the broader range of technologies now used in modern payment environments. Your network security controls need to protect the full scope of how cardholder data actually moves through your systems today.

Requirement 2: Apply secure configurations to all system components. Default credentials and vendor-supplied settings remain a leading attack vector. This requirement mandates that every system component in your CDE is configured securely before it's deployed and remains reviewed on an ongoing basis.

Requirement 3: Protect stored account data. Under v4.0.1, the requirements around sensitive authentication data (SAD) that's stored before authorization are more specific. Encryption is now required for pre-authorization SAD, and you must define and document your retention and disposal periods for that data.

Requirement 4: Protect cardholder data with strong cryptography during transmission. Data in transit must be encrypted using strong, current cryptographic protocols. This applies to every path cardholder data takes: from the browser to your servers, from your systems to gateways, and across any internal network segments.

Requirement 5: Protect all systems and networks from malicious software. This one got a meaningful update in v4.0.1. Phishing detection and prevention controls are now required, which means you need documented processes or automated tools in place to detect and prevent phishing attacks against personnel who have access to cardholder data environments.

Requirement 6: Develop and maintain secure systems and software. Two of the most impactful updates in the entire v4.0 cycle sit here. Requirements 6.4.3 and 11.6.1 are now mandatory for all applicable merchants. Requirement 6.4.3 requires that every script running on a payment page is authorized, documented in an inventory, and has its integrity validated. 

Requirement 11.6.1 requires a change and tamper detection mechanism that alerts personnel to unauthorized modifications to payment pages, assessed at minimum weekly. These requirements were designed to counter Magecart-style e-skimming attacks, and they're particularly important for merchants completing SAQ A-EP or SAQ D.

Requirement 7: Restrict access to system components and cardholder data by business need. The principle of least privilege applies here in full. Access to cardholder data must be limited to individuals whose job function requires it, and that access must be reviewed regularly. v4.0.1 requires that human accounts are reviewed at least every six months and that application and system account access reviews are conducted on a frequency determined by a targeted risk analysis.

Requirement 8: Identify users and authenticate access to system components. This is one of the most operationally demanding updates in v4.0.1. Multi-factor authentication (MFA) is now required for all access into the cardholder data environment, not just remote access. The minimum password length has increased to 12 characters. And automated mechanisms are now required for managing and reviewing application and system account credentials.

Requirement 9: Restrict physical access to cardholder data. Physical security controls, including access logs, visitor management, and media protection, must be in place for all locations where cardholder data is stored or processed. This requirement applies regardless of whether data is stored digitally or in physical form.

Requirement 10: Log and monitor all access to system components. Automated log review mechanisms are now required for all CDE components. Manual log reviews, which were already impractical at any meaningful scale, are no longer a compliant approach for in-scope systems. Tools like SIEM solutions have effectively become a compliance requirement rather than an optional investment.

Requirement 11: Test security of systems and networks regularly. Internal vulnerability scans are now required to be authenticated scans, conducted quarterly. This means your scanner needs to log into target systems using valid credentials to conduct the scan from within, not just probe them from the outside. Separately, merchants using SAQ A are now subject to quarterly external ASV scans, which is a new obligation for that segment under v4.0.1.

Requirement 12: Support information security with organizational policies. A formal, documented scoping exercise for your CDE is now a tracked annual requirement. For service providers, that exercise must happen at least every six months, and it must also be triggered by any significant organizational changes. This requirement makes the often-informal scoping discussion a first-class compliance obligation with its own audit trail.

If you want a deeper look at how these requirements connect to your broader payments compliance program, that context matters for building a posture that holds up year after year rather than just at assessment time.

Benefits of completing your PCI attestation of compliance

Compliance work rarely inspires enthusiasm, but there are genuinely compelling reasons to treat your AOC as more than a box-checking exercise. Here's what completing it actually gets you.

Maintain your ability to process card payments

This is the most straightforward consequence of non-compliance and the one that tends to focus minds quickly. Non-compliant merchants can face monthly fines from acquiring banks ranging from $5,000 to $100,000, with penalties that escalate the longer the non-compliance continues. Beyond the fines, acquiring banks can restrict or revoke a merchant's ability to process card transactions entirely until compliance is restored. For most businesses, that's not a recoverable situation.

Reduce your exposure to breach costs

The compliance assessment process forces a systematic audit of your cardholder data environment, and that audit often surfaces vulnerabilities that were living quietly in the background long before any assessor showed up. Given that the average data breach cost $4.88 million in 2024, the cost of proactive compliance work looks like a bargain by comparison. A strong AOC process doesn't just satisfy a regulatory requirement; it actively closes the gaps that breaches exploit.

Build trust with partners and customers

For service providers in particular, a current and complete PCI DSS attestation of compliance document has become a de facto commercial prerequisite. When merchants evaluate payment vendors, the first question their compliance and security teams ask is whether the provider holds valid PCI DSS Level 1 certification. An up-to-date AOC answers that question before it becomes a dealbreaker. And in an environment where payment fraud prevention is a board-level concern, demonstrable compliance is a competitive differentiator, not just a regulatory checkbox.

Establish security as a continuous discipline

PCI DSS v4.0.1 was deliberately designed to move the industry away from point-in-time compliance assessments toward a continuous security posture. The quarterly scans, automated log reviews, semi-annual access reviews, and ongoing script monitoring requirements aren't bureaucratic overhead. They're the infrastructure of a payment environment that stays secure between assessments, which is when most breaches actually happen.

What happens after you complete your PCI attestation of compliance?

This is the part that most guides skip, so let's address it directly.

Submitting the document

Where the AOC goes depends on who you are. Merchants submit their completed PCI merchant attestation form to their acquiring bank, along with the supporting SAQ or ROC and the most recent quarterly ASV scan reports. Service providers don't submit to an acquiring bank. Instead, they share their AOC with the merchants, processors, and other entities they serve, typically as part of a vendor security review or contractual due diligence process. If you're a service provider and you don't have a clean, ready-to-share version of your current AOC, your sales and partnership teams will eventually feel that gap.

Your 12-month clock starts over

The AOC covers a specific assessment period, and the moment it's complete, the next one begins. Annual reassessment is a firm requirement, and several of the controls that underpin your AOC have shorter internal cycles: quarterly scans, continuous automated log monitoring, access reviews every six months, and for service providers, CDE scoping at least every six months as well. The most effective way to approach the annual assessment is to treat those recurring controls as operational rhythms rather than compliance deadlines.

Reducing your scope for next year

One of the most valuable outcomes of completing a thorough AOC is understanding what can be taken out of scope entirely. Merchants who route payment data through a Level 1-compliant service provider remove a significant portion of their infrastructure from PCI scope because sensitive cardholder data never touches their own systems in the first place. That reduction in scope translates directly into a faster, less expensive compliance cycle the following year. If your current payment infrastructure has you personally responsible for a large CDE, it's worth asking whether that's the most efficient way to carry that burden. Understanding how tokenization reduces PCI scope is a good place to start that conversation.

Reduce your PCI compliance scope with Spreedly

Completing your AOC is the goal. Completing a simpler, narrower one each year is the strategy.

Spreedly holds Level 1 PCI DSS compliance, the highest merchant level, which means that when cardholder data flows through Spreedly's Vault, it doesn't touch your systems, your infrastructure stays out of scope, your annual assessment covers less ground, and your engineering team spends less time in rooms with QSAs and more time building things that move your business forward.

Spreedly Protect adds another layer to that picture, embedding fraud management and 3DS decisioning directly into the payment flow so that security controls and compliance obligations work together rather than pulling in opposite directions. 

If you're working through a compliance cycle right now, or preparing for one, talk to us about how Spreedly can compress the scope of what you need to attest to. The compliance work doesn't disappear, but there's no reason to do more of it than you have to.