What is PCI DSS Compliance Validation: Complete Guide

With the FTC receiving 449,032 credit card fraud reports in 2024, every business that touches a credit card number lives with the same quiet pressure: prove your cardholder data is safe, or lose the right to process payments. That proof usually comes in the form of PCI DSS compliance validation—typically a Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ), plus an Attestation of Compliance (AOC), depending on the organization's level and assessment path.

The confusion usually starts with the word "certification" itself. Unlike SOC 2 or ISO 27001, the PCI Security Standards Council does not hand out a universal PCI certificate stamped with a seal. What you actually get, how you get it, and who decides whether you have it are different from most other frameworks—and the answers depend heavily on how many transactions you process, what kind of business you run, and which payment brand or acquirer is asking.

This guide walks through what PCI DSS compliance validation actually is, the four merchant levels, all 12 requirements, the six-step path to getting validated, what it costs, who can perform the assessment, and how modern teams stay continuously audit-ready instead of scrambling once a year.

What Is PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) is a set of technical and operational requirements designed to protect cardholder data anywhere it is stored, processed, or transmitted. The current version is PCI DSS v4.0.1, which became the only active version of the standard supported by the PCI Security Standards Council (PCI SSC) after December 31, 2024.

PCI DSS was created by the five major payment card brands and is maintained by the PCI SSC, a global forum that develops and drives adoption of data security standards for safe payments worldwide. The five founding card brands are:

• Visa

• Mastercard

• American Express

• Discover

• JCB

If your organization accepts, stores, transmits, or processes cardholder data—or operates systems connected to environments that do—PCI DSS applies to you. That covers merchants, service providers, payment processors, and most SaaS companies that integrate with payment workflows. The requirement to comply usually comes from your acquiring bank, the card brands, or a contractual obligation with a customer.

How Organizations Validate PCI DSS Compliance

Here is the first thing most teams get wrong: there is no universal "PCI certificate" issued by the PCI SSC. The Council writes the standard, trains assessors, and maintains the documentation, but it does not certify individual businesses. Instead, organizations validate their compliance through a formal assessment or a self-assessment and produce documentation that proves their status. That validation process is what people commonly mean when they say "PCI DSS certification."

The documentation you receive—not a certificate from PCI SSC—is what acquiring banks, payment brands, and enterprise customers actually want to see.

Compliance vs. Validation

Compliance means meeting all applicable PCI DSS requirements. Validation refers to the formal process that proves you meet them. The two get used interchangeably, but understanding the distinction matters when you set expectations internally or with customers.

You can technically be compliant without going through a formal validation—but in practice, acquiring banks and payment processors require documented proof. Without validation, no one outside your organization has reason to take your word for it.

PCI Certificate of Compliance

What you actually receive at the end of a successful assessment is a combination of documents. There are two ways for a company to attest to PCI DSS compliance:

• Report on Compliance (ROC): A detailed third-party audit report prepared by a Qualified Security Assessor (QSA). The ROC applies to Level 1 merchants and Level 1 service providers.

• Self-Assessment Questionnaire (SAQ): A validation mechanism organizations use to self-attest. There are 10 SAQ types, each containing a subset of the PCI DSS requirements relevant to how an organization processes payment card data. SAQs apply to Level 2, 3, and 4 merchants and certain service providers.

Regardless of which path you take, you also complete an Attestation of Compliance (AOC)—a declaration of the results of your PCI DSS assessment, signed by your organization and, if a QSA was involved, by the QSA company. The AOC is the artifact most people mean when they say "pci certificate of compliance." Unlike the ROC, an AOC is not considered sensitive, and third-party service providers are expected to share their AOC with customers (similar to how SOC 2 reports are shared).

The Role of the PCI Security Standards Council

The PCI SSC writes and maintains the standard, qualifies QSAs and Internal Security Assessors (ISAs), trains Approved Scanning Vendors (ASVs), and publishes supporting documentation, including the Quick Reference Guide and the Prioritized Approach for PCI DSS. It does not issue certifications, does not perform audits, and cannot tell an individual business which merchant level applies to it.

For the most current standard, supporting documents, and SAQ templates, the PCI Security Standards Council website is the authoritative source.

PCI DSS Compliance Levels

PCI DSS compliance requirements scale with how much payment card data you handle. Merchants fall into one of four levels based on annual transaction volume, and service providers fall into a separate two-level structure based on the volume they process on behalf of merchants. Validation expectations can vary by card brand, acquirer, and whether the entity is a merchant or service provider.

A critical note: only your acquiring bank or the relevant payment card brand can confirm which level applies to you. PCI SSC does not assign merchant levels, and neither does any compliance platform. The thresholds below are a general guide—your bank's program may differ.

Level 1

Level 1 is the highest-volume tier and the only level that universally requires a ROC. Organizations at this level engage a QSA for an annual on-site assessment, run quarterly external vulnerability scans through an ASV, and produce a full ROC, an AOC, and any required ASV scan reports.

Level 2

Level 2 merchants typically complete an annual SAQ. Some payment brands require a Level 2 merchant to use a QSA or ISA to validate the SAQ, so the requirement is not purely self-attested in every case. Quarterly ASV scans are commonly required by acquiring banks and card brands, particularly when the Cardholder Data Environment is exposed to the internet.

Level 3

Level 3 applies primarily to mid-volume e-commerce merchants. Validation is generally through an annual SAQ, with ASV scans expected for internet-facing environments or when required by the acquirer.

Level 4

Level 4 covers the smallest merchants. SAQ completion is recommended, and the specific scanning and validation requirements depend on the acquiring bank's compliance program.

Service Provider Levels

Service providers—any organization that stores, processes, or transmits cardholder data on behalf of another entity—are classified separately. Level 1 service providers (typically those processing more than 300,000 transactions annually for a given card brand) require an annual ROC. Level 2 service providers generally complete an annual SAQ-D or, in some cases, a QSA-led assessment based on acquirer requirements. Service provider scoping is broader, and scope must be confirmed at least every six months instead of annually.

The 12 PCI DSS Requirements

PCI DSS organizes its security controls into 12 requirements grouped under six high-level goals. In PCI DSS v4.0.1, those 12 requirements expand into a comprehensive set of sub-requirements—not all of which apply to every organization, but each one is highly prescriptive about how often the control must be performed and how it must be evidenced.

This is the foundational structure of pci security under the standard.

Build and Maintain a Secure Network and Systems

• Requirement 1: Install and maintain network security controls, including firewalls and other technologies that govern traffic between trusted and untrusted networks.

• Requirement 2: Apply secure configurations to all system components, including changing vendor-supplied defaults and removing or disabling unnecessary services.

Protect Account Data

• Requirement 3: Protect stored account data through encryption, truncation, masking, hashing, or tokenization—and store as little of it as possible.

• Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks.

Maintain a Vulnerability Management Program

• Requirement 5: Protect all systems and networks from malicious software through anti-malware controls and ongoing detection.

• Requirement 6: Develop and maintain secure systems and software, including secure coding practices and timely patching of critical vulnerabilities (within 30 days under PCI DSS v4.0.1).

Implement Strong Access Control Measures

• Requirement 7: Restrict access to system components and cardholder data on a need-to-know basis.

• Requirement 8: Identify users and authenticate access to system components, including multi-factor authentication for access into the Cardholder Data Environment (CDE), except for accounts authenticated solely with phishing-resistant authentication factors.

• Requirement 9: Restrict physical access to cardholder data and the systems that store, process, or transmit it.

Regularly Monitor and Test Networks

• Requirement 10: Log and monitor all access to system components and cardholder data, and retain logs for at least 12 months.

• Requirement 11: Regularly test the security of systems and networks, including quarterly external ASV scans and at least annual internal and external penetration tests.

Maintain an Information Security Policy

• Requirement 12: Support information security with organizational policies and programs, including risk assessments, training, and clearly assigned roles and responsibilities for each control.

For a detailed breakdown of each sub-requirement and how to evidence it, see the full PCI DSS compliance checklist.

How to Validate PCI DSS Compliance

The path from "we need to comply" to "we have an AOC" follows the same six steps for nearly every organization. The PCI SSC describes the lifecycle as four ongoing phases—Assess, Remediate, Report, and Monitor and Maintain—and the steps below align with that model while breaking it into the practical work your team will do.

1. Determine Your Compliance Level and Scope

Start by confirming your merchant or service provider level with your acquiring bank or the relevant payment brand. Then define the scope of your Cardholder Data Environment—every system component that stores, processes, or transmits cardholder data, plus anything connected to or affecting those systems.

Scoping is where most PCI DSS programs win or lose. The standard requires you to document scope and confirm it at least annually—or every six months for service providers—including identifying all data flows, account data storage locations, segmentation controls, and third-party connections to the CDE.

2. Complete a Gap Assessment

Compare your current security posture against every applicable PCI DSS requirement. A gap assessment surfaces the controls that are missing, partially implemented, or improperly evidenced—long before a QSA finds them. Most organizations discover that controls they considered "in place" for SOC 2 or ISO 27001 do not meet the more prescriptive PCI requirements, particularly around penetration testing, logging, and segmentation.

3. Remediate Gaps and Implement Controls

Close the gaps your assessment surfaced. That includes deploying or hardening technical controls, updating policies, formalizing procedures, and assigning ownership for each requirement. PCI DSS v4.0.1 requires clearly assigned roles and responsibilities for every requirement—this is not optional.

4. Complete the Required Assessment

If you are a Level 1 merchant or Level 1 service provider, engage a QSA to perform the on-site assessment that produces your ROC. For other levels, complete the SAQ that matches how your organization handles cardholder data. There are 10 SAQ types ranging from SAQ A (a shorter form for e-commerce companies that fully outsource account data to compliant third parties) to SAQ D (covers the full set of PCI DSS requirements for service providers and merchants that do not qualify for any other SAQ).

Both paths typically require quarterly external vulnerability scans by an Approved Scanning Vendor, especially for internet-facing environments or when required by your acquirer or card brand. Drata is not an ASV; you will need to engage one separately for scan reports.

5. Submit Compliance Documentation

Submit the completed ROC or SAQ, your signed AOC, and any required ASV scan reports to the requesting organization—typically your acquiring bank or the payment brand. You do not submit to the PCI SSC. The bank or brand is the entity that accepts and tracks your compliance.

6. Receive Your Attestation of Compliance

The signed AOC is the artifact that proves your status to business partners. This is the document people generally have in mind when they refer to a pci dss certificate. Keep it accessible, share it appropriately with customers who request proof, and start preparing for next year's validation—PCI DSS compliance is renewed annually.

How Much Does PCI DSS Validation Cost

There is no fixed price for PCI DSS validation, and any specific figure you see online almost always reflects one organization's circumstances. The total cost depends on several factors:

• Compliance level: A Level 1 ROC with a QSA is materially more expensive than completing a SAQ.

• Scope of the cardholder data environment: Larger CDEs, more system components, and more network segmentation all increase effort.

• Gap remediation: Fixing vulnerabilities, deploying new tooling, and rewriting policies and procedures is often the largest line item.

• QSA fees: If your level requires a QSA, fees vary by firm, scope, and the duration of the engagement. A typical PCI DSS 4.0.1 assessment takes four to eight months, with six months being the average.

• Vulnerability scanning: Quarterly ASV scans are required at Level 1 and commonly expected at lower levels for internet-facing environments.

• Internal resources: Staff time for preparation, evidence collection, and ongoing maintenance is the cost organizations consistently underestimate.

The honest answer for most mid-market and enterprise organizations is that the manual labor of preparation—not the QSA fee—drives the largest portion of cost. Automating evidence collection, control monitoring, and audit preparation is where modern programs reduce total cost of compliance.

Who Can Perform PCI DSS Assessments

The right answer depends on your level and the kind of attestation you need. Three options exist.

Qualified Security Assessor

A Qualified Security Assessor (QSA) is a security professional, employed by a QSA company, who has been trained and certified by the PCI SSC to perform PCI DSS assessments. QSAs produce the ROC required for Level 1 merchants and Level 1 service providers. They evaluate your CDE against every applicable requirement and document the findings in a formal report.

QSAs are independent from the organizations they assess. The QSA company signs the AOC alongside your organization, which is part of why the ROC carries the weight it does with banks and enterprise customers.

Internal Security Assessor

An Internal Security Assessor (ISA) is an employee of your organization who has completed PCI SSC training to perform PCI DSS assessments internally. ISAs can be a useful complement to a QSA—particularly for ongoing readiness, gap assessments, and SAQ validation in cases where a payment brand allows an ISA to sign off. An ISA cannot replace a QSA for organizations that are required to submit a ROC.

Self-Assessment Questionnaire

For organizations not required to submit a ROC, the SAQ is the standard validation method. Being "SAQ-eligible" means your organization meets the eligibility criteria specified in a chosen SAQ type—criteria your acquiring bank or the payment brand confirms. You complete the questionnaire honestly, attach an AOC, and submit both to the requesting organization. There is no central submission portal; you send documentation to whichever entity is asking for proof.

A common misconception: completing an SAQ does not mean the requirements are softer. SAQ D, for example, covers the full set of PCI DSS requirements for organizations not eligible for a more targeted SAQ. The SAQ format simply allows self-attestation rather than third-party audit.

How to Maintain PCI DSS Compliance

PCI DSS is annual, but PCI compliance is not. The standard is built around the assumption that controls operate continuously and that "business as usual" processes keep cardholder data protected every day of the year—not only during assessment windows. Several activities run on rolling cycles regardless of your formal validation date:

• Continuous control monitoring: Verify that authentication, encryption, access management, and other technical controls are operating as intended, not just at point-in-time.

• Quarterly vulnerability scans: External ASV scans are required four times per year for systems facing the internet at Level 1, and commonly required at lower levels by acquirers or card brands.

• Penetration testing: internal and external penetration tests at least annually, plus after any significant infrastructure or application change.

• Scope revalidation: Confirm and document scope at least annually—every six months for service providers—and after any significant change to the in-scope environment.

• Policy updates: Keep security policies aligned with the current version of the standard, currently PCI DSS v4.0.1.

• Personnel training: Ensure staff with access to or responsibility for the CDE understand their obligations under the standard.

This is the part of the program that point-in-time approaches consistently underdeliver. Trust cannot be a point-in-time exercise—especially in a world where systems, vendors, and threats change every day.

Simplify PCI DSS Readiness With the Drata Agentic Trust Management Platform

PCI DSS is one of the most prescriptive frameworks in security and compliance. Hundreds of sub-requirements, each with specific frequency, evidence, and ownership expectations, will overwhelm a spreadsheet-driven program—and a spreadsheet-driven program will, in turn, overwhelm your team.

The Drata Agentic Trust Management Platform helps organizations operationalize PCI DSS as a continuous program across four core capabilities: Automated Governance, Integrated Risk Management, Continuous Compliance, and Accelerated Security Assurance. For teams pursuing PCI DSS v4.0.1, Drata provides:

• A dedicated PCI DSS v4.0.1 framework with pre-mapped controls aligned to the standard's requirements, plus the option to select an SAQ type and automatically mark non-applicable requirements out of scope.

• Continuous Control Monitoring that supports ongoing readiness for authentication, encryption, access management, and other PCI safeguards between formal assessments.

• 22 policy templates provisioned for PCI DSS v4.0.1 (up from 18 under v4.0), including network security, logging and monitoring, encryption, vendor management, and incident response.

• Audit Hub for centralized evidence collection and QSA collaboration, so audit prep becomes review—not reconstruction.

• Risk Management and Third-Party Risk Management to maintain visibility into vendors that touch your CDE.

• Trust Center to securely share PCI posture, SAQ results, or ROC summaries with customers and stakeholders.

• Multi-framework reuse, with overlapping controls between PCI DSS and SOC 2 out of the box, so the work you do for one framework reduces the work you do for the next (exact savings depend on scope, selected trust criteria, and your PCI validation path).

Drata is not an Approved Scanning Vendor, so organizations still need to engage an ASV for required external vulnerability scans.

The result is a compliance program that stays current—not one that resets every year. Book a demo to see how Drata supports continuous PCI DSS readiness alongside SOC 2, ISO 27001, HIPAA, and more.

Frequently Asked Questions About PCI DSS Compliance Validation