PCI Audit: A Complete Guide for 2026

What is a PCI audit

A PCI audit is the formal process by which an organization validates its compliance with the Payment Card Industry Data Security Standard (PCI-DSS). Any organization that stores, processes, or transmits cardholder data — credit card numbers, expiration dates, CVVs, or cardholder names associated with account numbers — falls within scope. The audit evaluates whether the organization’s technical controls, policies, and procedures meet the specific requirements defined by PCI-DSS for protecting that data throughout its lifecycle.

The PCI Security Standards Council (PCI SSC) develops and maintains the standard. The five major payment brands — Visa, Mastercard, American Express, Discover, and JCB — enforce compliance through their respective programs and through the acquiring banks that process transactions on behalf of merchants. Non-compliance does not trigger direct penalties from the PCI SSC itself. Instead, the payment brands impose fines, increased fees, and processing restrictions through the acquiring bank, which passes those costs to the merchant.

The scope of a PCI audit extends to every system, process, and person that touches cardholder data or could affect its security. This includes payment terminals, e-commerce platforms, databases storing card data, network segments that carry card traffic, third-party service providers with access to card data, and the employees who administer those systems. Scope definition is the single most consequential decision in a PCI audit — it determines the cost, timeline, complexity, and number of controls that must be tested. Organizations that invest in risk management frameworks early tend to approach PCI scoping more strategically, reducing their cardholder data environment before the audit begins rather than trying to validate a sprawling footprint after the fact.

PCI-DSS is not a one-time certification. Compliance is validated annually and must be maintained continuously. A clean audit in January does not exempt the organization from meeting every requirement in July. This continuous obligation distinguishes PCI-DSS from point-in-time assessments and makes it one of the more operationally demanding compliance frameworks for organizations that handle payment data directly.

PCI-DSS 4.0: what changed

PCI-DSS 4.0 replaced version 3.2.1 as the active standard, with all organizations required to comply by March 31, 2025. The update was the most significant revision since the standard’s creation, introducing structural flexibility alongside stricter technical requirements. Organizations preparing for their next PCI audit need to understand both categories of change.

The customized approach

PCI-DSS 4.0 introduced the customized approach as a formal alternative to the defined approach (following each requirement as written) and compensating controls. Under the customized approach, an organization can meet the security objective behind a requirement using a method not explicitly prescribed by the standard — as long as it can demonstrate to the QSA that the alternative method achieves equivalent or greater security. The customized approach requires a targeted risk analysis, documented control design, and evidence that the alternative works. It is not a shortcut — it is more documentation-intensive than the defined approach and requires QSAs with deeper expertise to evaluate.

Expanded authentication requirements

Version 4.0 extended multi-factor authentication (MFA) requirements beyond remote access to the cardholder data environment. MFA is now required for all access to the CDE, not just remote connections. The standard also strengthened password requirements — a minimum of 12 characters (up from 7 in 3.2.1) for accounts used by personnel, though this requirement allows for 8-character minimums if the system does not support 12. Shared and generic accounts face tighter controls, with required documentation and approval for any remaining exceptions.

E-commerce and payment page security

PCI-DSS 4.0 added new requirements specifically targeting e-commerce skimming attacks — the type of attack where malicious JavaScript on a payment page captures card data before it reaches the legitimate payment processor. Organizations must now maintain an inventory of all scripts on payment pages, justify each script’s presence, implement mechanisms to detect unauthorized script changes, and confirm the integrity of HTTP headers that could affect payment page content. These requirements (6.4.3 and 11.6.1) address the Magecart-style attacks that have compromised hundreds of e-commerce sites.

Targeted risk analysis

Several PCI-DSS 4.0 requirements now mandate targeted risk analyses where previous versions prescribed fixed frequencies. For example, rather than requiring vulnerability scans at a set interval, the standard allows organizations to determine scan frequency based on a documented risk analysis. This flexibility comes with accountability — the risk analysis itself is auditable, and the QSA evaluates whether the chosen frequency is appropriate given the risk. Organizations that lack experience with formal risk analysis methodology may find that a structured risk management framework makes these targeted analyses more defensible.

Roles and responsibilities

PCI-DSS 4.0 added an explicit requirement that every single PCI-DSS requirement has a documented owner — a person or team responsible for its implementation and maintenance. This sounds administrative, but the intent is to eliminate the organizational ambiguity that causes control drift. When no one owns a requirement, no one monitors it, and the audit finding is inevitable. Documenting ownership also makes it clear where security policies need updating to reflect the actual operating model.

Merchant levels and validation types

The payment brands classify merchants into four levels based on annual transaction volume. The merchant level determines the type of validation required — a full QSA-led audit or a self-assessment questionnaire. Understanding which level applies to your organization is the first step in planning a PCI audit.

Merchant level definitions

The following thresholds apply to Visa’s classification system. Mastercard, American Express, Discover, and JCB use similar but not identical thresholds — check each brand’s specific program if your organization processes transactions across multiple brands.

• Level 1: More than 6 million transactions per year across all channels, or any merchant that has experienced a data breach, or any merchant that a payment brand identifies as Level 1 at its discretion. Requires an annual on-site assessment by a QSA, a Report on Compliance (ROC), and quarterly network scans by an Approved Scanning Vendor (ASV).
• Level 2: 1 million to 6 million transactions per year. Requires an annual SAQ (the applicable SAQ type depends on how the merchant processes cards) and quarterly ASV scans. Some acquirers may require Level 2 merchants to engage a QSA.
• Level 3: 20,000 to 1 million e-commerce transactions per year. Requires an annual SAQ and quarterly ASV scans.
• Level 4: Fewer than 20,000 e-commerce transactions or up to 1 million total transactions per year via other channels. Requires an annual SAQ and quarterly ASV scans. Validation requirements are determined by the acquirer.

QSA audit vs self-assessment questionnaire

A QSA audit is the most rigorous form of PCI validation. The Qualified Security Assessor is a certified individual employed by a QSA Company (QSAC) that has been approved by the PCI SSC. The QSA conducts on-site and remote testing, interviews personnel, reviews documentation, inspects configurations, and produces a Report on Compliance. The ROC is the formal attestation that the organization meets PCI-DSS requirements. QSA audits take weeks to months of fieldwork and produce hundreds of pages of evidence documentation.

A self-assessment questionnaire (SAQ) is a structured checklist that the merchant completes to attest to its own compliance. There are multiple SAQ types — SAQ A for merchants that fully outsource payment processing (no electronic card data storage), SAQ A-EP for e-commerce merchants using third-party payment pages, SAQ B for merchants using standalone dial-up terminals, SAQ C for merchants with payment applications connected to the internet, SAQ C-VT for virtual terminal merchants, and SAQ D for merchants that do not qualify for any other type. SAQ D is effectively a full self-assessment against all PCI-DSS requirements and is the most demanding SAQ.

The choice between QSA audit and SAQ is not always discretionary. Level 1 merchants must use a QSA. For Levels 2 through 4, the acquiring bank may impose additional requirements beyond the minimum — especially after a security incident or when the merchant’s processing environment is complex. Organizations should confirm validation requirements with their acquirer before assuming an SAQ will suffice.

The 12 PCI-DSS requirements

PCI-DSS organizes its requirements into six domains covering the full spectrum of controls needed to protect cardholder data. Understanding the structure helps organizations map existing controls to PCI requirements and identify gaps before the audit begins.

Build and maintain a secure network and systems

• Requirement 1: Install and maintain network security controls. Formerly “install and maintain a firewall configuration,” this requirement now covers all network security controls — firewalls, cloud security groups, software-defined networking controls, and any technology that restricts network traffic. The standard requires documented rules, review of rules at least every six months, and restrictions on traffic between untrusted networks and the cardholder data environment.
• Requirement 2: Apply secure configurations to all system components. Default passwords, unnecessary services, and insecure default settings must be eliminated before systems enter the cardholder data environment. Configuration standards must be documented, applied consistently, and verified through regular review.

Protect account data

• Requirement 3: Protect stored account data. If cardholder data must be stored, it must be protected using encryption, truncation, masking, or hashing. Sensitive authentication data (CVV, full magnetic stripe data, PIN blocks) must never be stored after authorization. Encryption key management must follow documented procedures with appropriate key custodian controls.
• Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks. All cardholder data transmitted over networks that are not physically controlled by the organization must be encrypted using strong cryptography. TLS 1.2 or higher is required. Certificate management and cipher suite configuration are auditable controls.

Maintain a vulnerability management program

• Requirement 5: Protect all systems and networks from malicious software. Anti-malware solutions must be deployed on all systems commonly affected by malware, kept current, and configured for active protection and logging. Periodic evaluations of systems not commonly affected by malware are required to confirm the risk assessment remains valid.
• Requirement 6: Develop and maintain secure systems and software. All system components must be protected from known vulnerabilities through timely patching. Custom and bespoke software must be developed using secure development practices. The e-commerce script integrity requirements (6.4.3) added by PCI-DSS 4.0 fall under this domain.

Implement strong access control measures

• Requirement 7: Restrict access to system components and cardholder data by business need to know. Access must be limited to individuals whose job function requires it. Role-based access control, documented access policies, and regular review of access rights are required.
• Requirement 8: Identify users and authenticate access to system components. Every user must be assigned a unique identifier. MFA is required for all access to the CDE (expanded in 4.0 beyond remote access only). Password and authentication policies must meet the standard’s minimum requirements, including the 12-character minimum introduced in 4.0.
• Requirement 9: Restrict physical access to cardholder data. Physical access to systems storing or processing cardholder data must be controlled through facility entry controls, visitor management, media handling procedures, and point-of-interaction device protection.

Regularly monitor and test networks

• Requirement 10: Log and monitor all access to system components and cardholder data. Audit trails must capture all user access, administrative actions, and security events. Logs must be reviewed daily (automated or manual), retained for at least 12 months (with 3 months immediately available), and protected against tampering. Time synchronization across all systems is required.
• Requirement 11: Test security of systems and networks regularly. Quarterly ASV scans, annual penetration testing, internal vulnerability scanning, and wireless access point detection are required. PCI-DSS 4.0 added the requirement for mechanisms to detect unauthorized changes on payment pages (11.6.1) and expanded segmentation testing requirements.

Maintain an information security policy

• Requirement 12: Support information security with organizational policies and programs. A comprehensive information security policy must be established, published, and maintained. This includes an incident response plan, security awareness training, a process for managing service provider relationships, and the targeted risk analyses required throughout PCI-DSS 4.0. Every requirement must have a documented owner (new in 4.0).

The PCI audit process step by step

A PCI audit follows a structured sequence from initial scoping through final attestation. The process below describes a Level 1 QSA-led audit — the most comprehensive form of PCI validation. SAQ-based validation follows a similar logical sequence but with the organization performing the evaluation rather than an independent assessor.

Step 1: Define the cardholder data environment

Before any testing begins, the organization must identify every system, network segment, process, and person that stores, processes, or transmits cardholder data — or that could affect the security of systems that do. This is the cardholder data environment (CDE). The CDE definition also includes connected-to systems — any system on the same network segment or with a trust relationship to a CDE system. Accurate CDE definition requires data flow mapping: tracing every path that cardholder data takes from entry (point of sale, e-commerce form, call center) through processing, transmission, and storage to disposal.

This is also the stage where scope reduction strategies take effect. Tokenization, network segmentation, outsourced payment processing, and point-to-point encryption reduce the CDE footprint before the audit begins. The QSA validates the effectiveness of scope reduction measures — segmentation testing, for instance, is itself an auditable control.

Step 2: Gap assessment and readiness

Most organizations conduct a pre-audit gap assessment against PCI-DSS requirements before engaging the QSA for the formal audit. The gap assessment identifies control deficiencies, missing documentation, and configuration drift so that remediation can begin before fieldwork starts. Engaging a strategic security advisor for the gap assessment phase brings cross-client perspective on common pitfalls and accelerates the readiness timeline.

Gap assessment deliverables typically include a requirement-by-requirement compliance status (compliant, partially compliant, non-compliant), a remediation roadmap with prioritized actions, an evidence inventory identifying which evidence exists and which must be created, and an estimated timeline to audit readiness. Organizations that skip the gap assessment and proceed directly to the formal audit risk receiving findings that could have been remediated in advance — at lower cost and without the pressure of an active audit timeline.

Step 3: Remediation

Findings from the gap assessment drive a remediation sprint. Typical remediation activities include implementing or strengthening access controls, deploying or reconfiguring logging and monitoring, writing or updating security policies and procedures, conducting segmentation testing, deploying anti-malware or endpoint protection, and establishing evidence collection processes for controls that must demonstrate ongoing operation (not just point-in-time design). The remediation phase is where most of the work happens — and where most of the cost accumulates outside the audit fees themselves.

Step 4: Formal QSA assessment

The QSA conducts the formal on-site and remote assessment. Fieldwork includes document review (policies, procedures, network diagrams, data flow diagrams), configuration inspection (firewall rules, encryption settings, access control lists, logging configurations), personnel interviews (system administrators, developers, security team, management), and technical testing (vulnerability scanning, penetration testing review, segmentation validation). The QSA tests each applicable requirement using a combination of examination, observation, and interview — the same methodology used in a broader cybersecurity audit, but scoped specifically to PCI-DSS controls.

Step 5: Report on Compliance and Attestation of Compliance

The QSA produces two documents: the Report on Compliance (ROC) and the Attestation of Compliance (AOC). The ROC is the detailed audit report documenting the testing performed, evidence reviewed, and compliance determination for each requirement. The AOC is a summary attestation signed by the organization and the QSA confirming the compliance status. The AOC is the document typically shared with acquiring banks, payment brands, and business partners. The full ROC is shared on request but is not routinely distributed.

Step 6: Remediation of findings and ongoing compliance

If the audit identifies non-compliant requirements, the organization produces a remediation plan and timeline. The QSA may conduct a follow-up assessment to validate remediation. Between annual audits, the organization must maintain compliance continuously — quarterly ASV scans, ongoing log monitoring, access reviews, and all other operational controls must run year-round. Compliance is not a once-a-year event; the audit validates a year of continuous operation.

Common PCI audit findings

Certain PCI audit findings recur across industries, company sizes, and assessment cycles. Understanding the most common findings allows organizations to address them proactively during the gap assessment and remediation phases rather than discovering them during formal QSA fieldwork.

Incomplete or inaccurate scope definition

The most consequential finding is not a failed control — it is an incorrect CDE definition. Organizations frequently undercount the systems in scope, miss connected-to systems, or fail to account for data flows through cloud services, call centers, or third-party integrations. An inaccurate scope means that controls tested during the audit do not cover all systems that actually handle cardholder data. QSAs routinely expand scope during fieldwork when data flow analysis reveals systems that were not included in the organization’s initial CDE definition.

Logging and monitoring gaps

Requirement 10 — logging and monitoring — is one of the most frequently cited areas of non-compliance. Common issues include incomplete log coverage (not all CDE systems feed into centralized logging), insufficient log retention (less than 12 months, or less than 3 months immediately accessible), lack of daily log review (automated or manual), and missing time synchronization across systems. These findings are common because logging infrastructure requires ongoing operational investment, not just initial configuration.

Weak access control and authentication

Despite being one of the most audited domains in every security framework, access control findings persist. Common issues include shared or generic accounts without documented justification, MFA not deployed for all CDE access (especially after the 4.0 expansion), access reviews not performed at required intervals, and stale accounts that were not deprovisioned after personnel changes. Organizations that conduct regular vendor risk assessments often catch third-party access issues before the auditor does — vendor accounts with CDE access are a frequent source of findings.

Segmentation failures

Organizations that rely on network segmentation to reduce PCI scope must validate that segmentation actually works — and that validation is itself an auditable control. Segmentation testing must confirm that systems outside the CDE cannot communicate with systems inside the CDE through any path. Common findings include segmentation that was designed correctly but degraded over time due to firewall rule changes, new VLANs, or cloud networking modifications that were not evaluated for PCI impact.

Encryption and key management deficiencies

Requirement 3 (stored data) and Requirement 4 (data in transit) produce findings when organizations use outdated cryptographic protocols, fail to rotate encryption keys on schedule, lack documented key management procedures, or store sensitive authentication data after authorization. The transition away from TLS 1.0 and 1.1 has been required since PCI-DSS 3.2.1, but legacy systems and third-party integrations still surface as findings when they support deprecated protocols.

Missing or outdated documentation

PCI-DSS 4.0 strengthened documentation requirements across the board. Every requirement must have a documented owner. Security policies must be current and reflect actual practice. Network diagrams and data flow diagrams must be accurate. Targeted risk analyses must be documented and reviewed. Organizations that treat documentation as a one-time exercise for the initial audit and do not maintain it between cycles consistently receive findings on subsequent audits.

PCI compliance vs PCI certification

The terms “PCI compliant” and “PCI certified” are used interchangeably in vendor marketing, but they are not the same thing — and the distinction matters for organizations evaluating their own status and their partners’ status.

PCI compliance

PCI compliance means the organization meets the requirements of PCI-DSS as validated by the appropriate method for its merchant or service provider level. For Level 1 entities, compliance is validated by a QSA-produced ROC and AOC. For Levels 2 through 4, compliance is self-attested via SAQ and AOC. Compliance is a continuous state — the organization must meet all applicable requirements at all times, not just during the annual validation window.

PCI certification

Strictly speaking, there is no “PCI certification” in the way that ISO 27001 certification exists. The PCI SSC does not issue certificates to compliant organizations. What exists is a compliance validation — the ROC or SAQ that documents the organization’s compliance status at the time of assessment. Some QSA firms issue “certificates of compliance” as a courtesy document, but these do not carry the weight of an ISO certification from an accredited body. They are a summary of the ROC findings, not an independent credential.

What this means in practice

When a vendor says “we are PCI certified,” ask for the AOC. The AOC specifies the scope of the assessment, the SAQ type or ROC designation, the merchant or service provider level, and the date of the assessment. An AOC from a QSA-led Level 1 assessment carries significantly more weight than a self-completed SAQ A from a Level 4 merchant. Both are “PCI compliant,” but the rigor and scope of validation are not comparable. Organizations performing third-party risk assessments should request the AOC, not accept marketing claims of certification at face value.

Cost and timeline

PCI audit cost and timeline vary dramatically based on merchant level, the complexity of the cardholder data environment, organizational readiness, and whether the engagement includes gap assessment and remediation or is limited to the formal audit.

Cost by merchant level

• Level 1 (QSA audit): $50,000 to $200,000+ for the QSA engagement alone. The range reflects CDE complexity — a single e-commerce platform with tokenized payments is at the low end; a multi-location retailer with in-store POS, e-commerce, call center, and stored card-on-file data is at the high end. Remediation costs (implementing controls, deploying tools, updating configurations) can equal or exceed the audit fee.
• Level 2 (SAQ with optional QSA): $15,000 to $50,000. Many Level 2 merchants engage a QSA or ISA to assist with the SAQ for quality assurance, even when not strictly required. The cost depends on the applicable SAQ type and whether remediation support is included.
• Level 3 (SAQ): $5,000 to $25,000 including ASV scanning and any external assistance. Organizations with simple payment environments (SAQ A or SAQ B) are at the low end. Those completing SAQ D incur higher costs due to the breadth of requirements.
• Level 4 (SAQ): $2,000 to $15,000. Many Level 4 merchants have minimal cardholder data exposure because they use hosted payment pages or POS terminals that handle encryption end-to-end. The validation cost reflects this simplicity.

Cost drivers beyond the audit fee

The audit fee is often a fraction of the total cost of PCI compliance. Additional cost categories include:

• Remediation. Implementing new controls, deploying tools (SIEM, endpoint protection, MFA, encryption), and reconfiguring systems to meet requirements. For first-time Level 1 audits, remediation can cost $100,000 to $500,000+ depending on the starting maturity level.
• Scope reduction. Tokenization platforms, hosted payment pages, P2PE solutions, and network segmentation projects reduce long-term audit cost but require upfront investment.
• Quarterly ASV scans. $1,000 to $5,000 per quarter depending on the number of IP addresses and domains scanned.
• Annual penetration testing. $15,000 to $50,000 for external and internal penetration testing at the required scope.
• Ongoing operational costs. Log monitoring, access reviews, policy maintenance, training, and the personnel time required to maintain compliance between annual audits.

Timeline by merchant level

• Level 1 (first-time QSA audit): 6 to 12 months from gap assessment through ROC delivery. The gap assessment and remediation phase (3 to 6 months) typically takes longer than the formal QSA fieldwork (4 to 8 weeks). Organizations with mature security programs move faster; those building PCI controls from scratch need the full timeline.
• Level 1 (renewal): 2 to 4 months. The QSA builds on prior-year documentation and evidence. Renewal cycles are faster unless the CDE has changed significantly or new PCI-DSS requirements have taken effect.
• Level 2-3 (SAQ with remediation): 2 to 4 months for organizations that need to close gaps. Organizations that maintain continuous compliance can complete the SAQ in 2 to 4 weeks.
• Level 4 (SAQ): 1 to 4 weeks for organizations with simple payment environments and existing documentation.

The most significant timeline variable is organizational readiness. An organization with documented policies, established evidence collection processes, and a well-defined CDE moves through the process at the lower end of each range. An organization encountering PCI-DSS for the first time — or one whose cardholder data environment has grown without corresponding security investment — needs the full timeline. Engaging strategic security oversight early in the process brings structured methodology, cross-client pattern recognition, and the operational discipline that compresses timelines and reduces surprises during formal QSA fieldwork.

For deeper context on building a security program that sustains compliance across PCI-DSS, SOC 2, and other frameworks, see Cyber War…and Peace — a strategic guide covering risk assessment methodology, board-level reporting, and the transition from compliance-driven security to a measured, continuously improving program.