PCI DSS Compliance Checklist: All 12 Requirements for 2026

Posted: March 31, 2026 to Blog.

PCI DSS Compliance Checklist: All 12 Requirements Explained for 2026

Every organization that stores, processes, or transmits credit card data must comply with the Payment Card Industry Data Security Standard (PCI DSS). Version 4.0 is now fully enforceable, with all future-dated requirements mandatory as of March 31, 2025. If your organization has not completed its transition from PCI DSS v3.2.1, you are already behind, and every day of non-compliance increases both your financial risk and your liability exposure.

This PCI DSS compliance checklist walks through all 12 requirements in detail, explains what changed in v4.0, identifies which Self-Assessment Questionnaire (SAQ) applies to your business, and provides cost estimates for achieving and maintaining compliance. Whether you are a small e-commerce merchant processing 20,000 transactions annually or a service provider handling millions, the core requirements apply to you. The scope and audit rigor scale with your transaction volume, but the security controls do not become optional at lower levels.

Organizations that invest in cybersecurity services specifically aligned to PCI DSS find that the standard serves double duty: it protects cardholder data and simultaneously strengthens your overall security posture against ransomware, data breaches, and business email compromise.

What Is PCI DSS v4.0 and Why It Matters

PCI DSS is a set of security standards created by the Payment Card Industry Security Standards Council (PCI SSC), which was founded by American Express, Discover, JCB International, Mastercard, and Visa. The standard applies to any entity that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). This includes merchants, payment processors, acquirers, issuers, and service providers.

Version 4.0, released in March 2022, replaced version 3.2.1 after a three-year transition period. The transition officially ended on March 31, 2025, making all v4.0 requirements mandatory. Organizations assessed after that date must demonstrate compliance with the full v4.0 standard, including the 64 new requirements that were previously listed as best practices.

PCI DSS v4.0 introduced several structural changes that affect how organizations approach compliance:

• Customized Approach: Organizations can now meet requirements using alternative controls that satisfy the stated security objective, rather than strictly following the defined approach. This gives mature security programs more flexibility but requires documented risk analysis and validation by a Qualified Security Assessor (QSA).
• Targeted Risk Analysis: Several requirements now allow organizations to determine the frequency of certain activities (scans, log reviews, password changes) through their own risk analysis rather than prescribing fixed intervals.
• Enhanced Authentication: Multi-factor authentication (MFA) is now required for all access into the cardholder data environment (CDE), not just remote access. This is one of the most impactful changes for organizations that previously relied on single-factor authentication for internal access.
• Client-Side Security: New requirements address security of payment pages rendered in consumer browsers, including script management and integrity monitoring. This targets the growing threat of Magecart-style attacks that inject malicious JavaScript into checkout pages.
• Continuous Compliance: The standard now emphasizes that compliance is an ongoing process, not an annual event. Organizations must maintain security controls continuously and have mechanisms to detect and respond when controls fail.

For a deeper look at how PCI DSS fits into broader payment security obligations, see our PCI DSS compliance services page.

PCI DSS Compliance Levels: Which One Applies to You

The card brands (primarily Visa and Mastercard) categorize merchants into four compliance levels based on annual transaction volume. Your level determines whether you need a full on-site audit by a QSA or can self-assess using a SAQ.

Merchant Compliance Levels

Level	Annual Transactions	Assessment Requirement
Level 1	Over 6 million (Visa/Mastercard)	Annual on-site assessment by a QSA, quarterly network scans by an ASV
Level 2	1 million to 6 million	Annual SAQ, quarterly ASV scans; some acquirers may require a QSA assessment
Level 3	20,000 to 1 million e-commerce transactions	Annual SAQ, quarterly ASV scans
Level 4	Fewer than 20,000 e-commerce or up to 1 million other transactions	Annual SAQ, quarterly ASV scans (recommended, may be required by acquirer)

Service providers have a separate classification: Level 1 applies to those storing, processing, or transmitting more than 300,000 card transactions annually, and Level 2 covers fewer than 300,000. All Level 1 service providers must undergo an annual QSA assessment.

SAQ Types Explained

Self-Assessment Questionnaires vary significantly in scope. Choosing the correct SAQ is critical because completing the wrong one can result in a failed assessment or a false sense of security.

SAQ Type	Applies To	Approximate Questions
SAQ A	Merchants that fully outsource cardholder data to PCI-validated third parties (e.g., hosted payment pages, iframes). No electronic storage, processing, or transmission of CHD on merchant systems.	~30
SAQ A-EP	E-commerce merchants that partially outsource payment processing but whose website could affect transaction security (e.g., direct POST or JavaScript redirects).	~190
SAQ B	Merchants using only imprint machines or standalone dial-out terminals with no electronic cardholder data storage.	~40
SAQ B-IP	Merchants using standalone, PTS-approved payment terminals with IP connectivity, no electronic cardholder data storage.	~80
SAQ C	Merchants with payment application systems connected to the Internet, no electronic cardholder data storage.	~160
SAQ C-VT	Merchants manually entering one transaction at a time via a virtual terminal provided by a third-party service provider.	~80
SAQ D (Merchant)	All other merchants not fitting the criteria above, including those that store CHD electronically.	~330
SAQ D (Service Provider)	Service providers eligible to self-assess.	~330

The most common mistake organizations make is assuming they qualify for SAQ A when their payment page implementation actually places them in SAQ A-EP territory. Any JavaScript loaded from your domain that could affect the payment page means your web server is in scope, moving you from approximately 30 questions to approximately 190.

The Complete PCI DSS v4.0 Checklist: All 12 Requirements

Below is a detailed breakdown of each PCI DSS requirement, including what it covers, key sub-requirements, what changed in v4.0, and practical implementation guidance. Use this as a working checklist for your compliance program.

Requirement 1: Install and Maintain Network Security Controls

Requirement 1 establishes the foundation of your cardholder data environment's perimeter defense. In v4.0, the language changed from "firewalls and routers" to "network security controls" (NSCs) to acknowledge that modern network security extends beyond traditional hardware firewalls to include cloud security groups, software-defined networking, and zero-trust architectures.

Key sub-requirements:

• 1.1: Define and document processes for managing network security controls, including roles and responsibilities, and ensure they are reviewed at least annually.
• 1.2: Configure NSCs to restrict inbound and outbound traffic to only what is necessary for the cardholder data environment. All traffic that is not explicitly allowed must be denied.
• 1.3: Restrict network access between the CDE and all other networks, including wireless, internal, and external networks. Use DMZ architecture to prevent direct access from the Internet to the CDE.
• 1.4: Control network connections between trusted and untrusted networks. Personal firewall software or equivalent functionality must be installed on portable computing devices that connect to the Internet outside the corporate network and are also used to access the CDE.
• 1.5: Risks to the CDE from computing devices that can connect to both untrusted networks and the CDE are mitigated.

What changed in v4.0: The scope expanded beyond traditional firewalls to include any technology that controls network traffic. Organizations must now diagram and document all NSCs, not just firewalls. The requirement for personal firewall software was updated to address the reality of remote work and cloud-connected endpoints.

Practical implementation: Start by creating a complete network diagram that shows every connection to and within the CDE. Document every firewall rule, security group, and access control list. Implement a formal change management process for any network configuration changes. Test firewall rules quarterly to verify they match your documented ruleset.

Requirement 2: Apply Secure Configurations to All System Components

Requirement 2 addresses the risk of using vendor-supplied default passwords, settings, and configurations. Default credentials and configurations are publicly known and are among the first things attackers try when targeting a system.

Key sub-requirements:

• 2.1: Define and document processes for applying secure configurations to all system components, including roles and responsibilities.
• 2.2: System components are configured and managed securely. This includes changing all vendor-supplied defaults before installing a system on the network, removing or disabling unnecessary services, protocols, daemons, and functions, and configuring security parameters to prevent misuse.
• 2.3: Wireless environments connected to or that could affect the CDE are configured and managed securely. Default wireless encryption keys, passwords, and SNMP community strings must be changed at installation.

What changed in v4.0: The requirement now explicitly addresses all system components, not just servers. This includes network devices, IoT devices, cloud instances, containers, and any other technology in scope. Organizations must maintain a configuration standard for every type of system component in their CDE and verify compliance against those standards regularly.

Practical implementation: Use CIS Benchmarks or vendor security guides to create hardening standards for every system type. Automate configuration checks using tools like Ansible, Chef, or cloud-native configuration management services. Maintain an inventory of all default accounts and verify they are disabled or have changed credentials.

Requirement 3: Protect Stored Account Data

Requirement 3 governs how cardholder data is stored, retained, and disposed of. The fundamental principle is simple: if you do not need to store cardholder data, do not store it. If you must store it, protect it with strong controls and limit its retention to the minimum period required by business, legal, or regulatory needs.

Key sub-requirements:

• 3.1: Define and document processes for protecting stored account data, including a data retention and disposal policy.
• 3.2: Storage of account data is kept to a minimum. Implement a data retention policy that defines how long CHD is stored and requires secure deletion when no longer needed. Sensitive authentication data (full track data, CVV/CVC, PINs) must never be stored after authorization, even if encrypted.
• 3.3: Stored primary account numbers (PANs) are secured by rendering them unreadable. Acceptable methods include one-way hashing, truncation, index tokens with securely stored pads, and strong cryptography with associated key management.
• 3.4: PANs must be secured with strong cryptography whenever stored. Full disk encryption alone is not sufficient for removable media.
• 3.5: Primary account numbers are secured wherever they are stored, including on primary storage, backups, logs, and receiving systems.
• 3.6 and 3.7: Cryptographic keys used to protect stored cardholder data must be managed securely throughout their lifecycle, including generation, distribution, storage, rotation, and retirement.

What changed in v4.0: Disk-level encryption is no longer acceptable as the sole mechanism for rendering PANs unreadable on non-removable storage. Organizations must use data-level encryption, tokenization, or other methods that protect the data independently of the storage medium. The requirement also added explicit guidance on keyed cryptographic hashes, requiring that the hash include a per-transaction or per-record salt.

Practical implementation: Conduct a data discovery scan to find every location where cardholder data is stored, including databases, log files, email archives, backup tapes, spreadsheets, and shared drives. You will almost certainly find CHD in places you did not expect. Implement tokenization wherever possible to remove raw PANs from your environment. Use a hardware security module (HSM) or cloud KMS for cryptographic key management.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

Requirement 4 protects cardholder data as it moves across networks. Any transmission of CHD over open, public networks must use strong cryptography to prevent interception.

Key sub-requirements:

• 4.1: Define and document processes for protecting cardholder data during transmission using strong cryptography.
• 4.2: PAN is protected with strong cryptography during transmission over open, public networks. This includes the Internet, wireless networks, cellular technologies, and satellite communications. TLS 1.2 or higher is required. SSL, early TLS (1.0), and TLS 1.1 are no longer acceptable.
• 4.3 (new in v4.0): Certificates used for PAN transmission over open, public networks are confirmed as valid and not expired or revoked.

What changed in v4.0: TLS certificate management became an explicit requirement. Organizations must verify that certificates are valid, trusted, and not expired. The standard also clarified that end-user messaging technologies (email, instant messaging, SMS, chat) must not be used to send PAN unless the organization can demonstrate strong cryptographic protection for the entire transmission path.

Practical implementation: Audit all network connections that transmit cardholder data. Verify TLS 1.2 or higher is enforced on all connections. Disable TLS 1.0 and 1.1 on all systems. Implement certificate monitoring to detect expiring or revoked certificates before they cause outages or security gaps. Train staff never to send card numbers via email or messaging applications.

Requirement 5: Protect All Systems and Networks from Malicious Software

Requirement 5 mandates anti-malware protections on all systems commonly affected by malicious software. In v4.0, the scope expanded to include any system that could introduce malware to the CDE, not just Windows endpoints.

Key sub-requirements:

• 5.1: Define and document processes for protecting all systems and networks from malicious software.
• 5.2: Malicious software (malware) is prevented or detected and addressed. Anti-malware solutions must be deployed on all system components except those specifically identified as not commonly affected by malware, and that determination must be supported by a periodic evaluation (at least every 12 months) that confirms the risk remains low.
• 5.3: Anti-malware mechanisms and processes are active, maintained, and monitored. Solutions must perform periodic scans and real-time monitoring. Users must not be able to disable or alter anti-malware unless specifically authorized by management for a limited time period.
• 5.4 (new in v4.0): Anti-phishing mechanisms must protect users against phishing attacks. This is a new requirement that acknowledges phishing as the primary initial access vector for most breaches.

What changed in v4.0: The most significant addition is Requirement 5.4, which mandates anti-phishing controls. Organizations must implement both technical controls (email filtering, link analysis, anti-spoofing technologies like DMARC/DKIM/SPF) and user awareness training. The standard also requires organizations to periodically reevaluate systems that were previously considered not at risk for malware, since the threat landscape changes continuously.

Practical implementation: Deploy endpoint detection and response (EDR) rather than traditional antivirus alone. Configure email security gateways with anti-phishing capabilities. Implement DMARC, DKIM, and SPF on all domains. Conduct regular security assessments that include malware detection testing. Run phishing simulations to measure and improve employee resistance to social engineering.

Requirement 6: Develop and Maintain Secure Systems and Software

Requirement 6 addresses application security and patch management. It covers both custom-developed software and third-party software components. If your organization develops any software that handles cardholder data, including payment applications, web applications, and APIs, this requirement has significant implications for your development practices.

Key sub-requirements:

• 6.1: Define and document processes for developing and maintaining secure systems and software.
• 6.2: Bespoke and custom software are developed securely. This includes training developers in secure coding practices, performing code reviews, and using secure development lifecycle (SDLC) methodologies.
• 6.3: Security vulnerabilities are identified and addressed. Deploy patches and updates within defined timeframes: critical and high-severity patches within 30 days of release, and medium-severity patches within a risk-based timeline. Maintain an inventory of all software components and monitor for vulnerabilities.
• 6.4: Public-facing web applications are protected against attacks. Deploy a web application firewall (WAF) or equivalent technology. In v4.0, this requirement also mandates management of all scripts loaded by the consumer browser on payment pages (Requirement 6.4.3, a major new control targeting supply chain attacks on payment pages).
• 6.5: Changes to all system components in the production environment are managed using established change control procedures.

What changed in v4.0: Requirement 6.4.3 is one of the most talked-about new controls. It requires organizations to manage all payment page scripts, maintain an inventory of scripts and their justification, implement a method to confirm the integrity of each script, and authorize scripts before they are added. This directly addresses Magecart attacks where attackers inject card-skimming JavaScript into third-party scripts loaded on checkout pages.

Practical implementation: Implement a software composition analysis (SCA) tool to track all third-party libraries and their vulnerabilities. Deploy a WAF in front of all public-facing payment applications. For Requirement 6.4.3, implement Content Security Policy (CSP) headers, Subresource Integrity (SRI) tags, and real-time script change monitoring on all payment pages. Establish a formal patch management process with SLAs tied to vulnerability severity.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

Requirement 7 implements the principle of least privilege: access to cardholder data and systems within the CDE must be limited to individuals whose job responsibilities require that access. This is not simply about user accounts. It covers system-level access, application-level access, file-level access, and database access.

Key sub-requirements:

• 7.1: Define and document processes for restricting access to system components and cardholder data by business need to know.
• 7.2: Access to system components and data is appropriately defined and assigned. Implement a role-based access control (RBAC) model that defines access privileges by job function. Access must be assigned based on least privilege, granting only the minimum access necessary for each role. All access assignments must be documented and approved by authorized management.
• 7.3: Access to system components and data is managed via an access control system. The access control system must default to deny-all and must cover all system components in the CDE.

What changed in v4.0: The standard now requires that access reviews occur at least every six months, rather than leaving the frequency undefined. Organizations must also review all user and application accounts and their access privileges semiannually and remove or disable any accounts and access that are no longer needed. Third-party and vendor accounts must be enabled only during the time period needed and disabled when not in use.

Practical implementation: Document every role that requires access to the CDE and the specific access level each role needs. Implement an identity governance and administration (IGA) solution or at minimum maintain a role-access matrix. Conduct access reviews every six months and document results. Disable vendor and third-party accounts when not in active use. Remove access immediately when employees change roles or leave the organization.

Requirement 8: Identify Users and Authenticate Access to System Components

Requirement 8 ensures every person who accesses the CDE is uniquely identified and authenticated. Shared accounts, generic accounts, and weak authentication are the root cause of many PCI breaches because they prevent organizations from tracing malicious activity to a specific individual.

Key sub-requirements:

• 8.1: Define and document processes for identifying users and authenticating access to system components.
• 8.2: User identification and related accounts are strictly managed throughout their lifecycle. Every user must have a unique ID. Group, shared, or generic accounts must not be used. Service and application accounts used for automated processes must be managed individually and documented.
• 8.3: Strong authentication for users and administrators is established and managed. Passwords must be at least 12 characters (increased from 7 in v3.2.1). Multi-factor authentication is required for all access into the CDE, including console access, not just remote access.
• 8.4: Multi-factor authentication is implemented to secure access into the CDE. MFA must use at least two of three authentication factors: something you know, something you have, and something you are. The authentication factors must be independent, meaning compromise of one does not grant access to another.
• 8.5: Multi-factor authentication systems are configured to prevent misuse. MFA must not be bypassed by any user, including administrators. Replay attacks and brute force attempts against MFA must be prevented.
• 8.6: Use of application and system accounts and associated authentication factors is strictly managed. Service accounts must have strong, unique passwords and be documented with business justification.

What changed in v4.0: The minimum password length increased from 7 to 12 characters (or 8 characters if the system does not support 12). MFA is now required for all access into the CDE, not just remote access. This means console access, local network access, and any administrative access must also use MFA. The requirement also added specific controls for service and application account authentication, addressing the often-overlooked risk of service accounts with static, never-rotated passwords.

Practical implementation: Deploy an MFA solution that covers all access paths to the CDE: VPN, console, RDP, SSH, application logins, and administrative interfaces. Update password policies to require 12 characters minimum. Inventory all service accounts, document their purpose, and implement password rotation on a defined schedule. Disable or lock accounts after no more than 10 failed authentication attempts.

Requirement 9: Restrict Physical Access to Cardholder Data

Requirement 9 governs physical security for any facility that houses systems or media containing cardholder data. This includes data centers, server rooms, offices where card numbers are visible on screens, and any area where payment terminals or cardholder data storage media are located.

Key sub-requirements:

• 9.1: Define and document processes for restricting physical access to cardholder data.
• 9.2: Physical access controls manage entry into facilities and systems containing cardholder data. Implement badge-based access control, video surveillance, and visitor management procedures. Visitors must be authorized, escorted in sensitive areas, and identified by a visible badge that distinguishes them from employees.
• 9.3: Physical access for personnel and visitors is authorized and managed. Visitor logs must be maintained and retained for at least three months.
• 9.4: Media with cardholder data is securely stored, accessed, distributed, and destroyed. Classify media containing CHD and maintain strict physical controls over its distribution and destruction. Destroy media when it is no longer needed for business or legal reasons using cross-cut shredding, incineration, pulping, or degaussing for electronic media.
• 9.5: Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution. Maintain a list of all devices, periodically inspect them for tampering, and train personnel to detect suspicious behavior around terminals.

What changed in v4.0: The terminology shifted from "point-of-sale" to "point-of-interaction" (POI) to cover a broader range of card acceptance devices. The standard added emphasis on training personnel who interact with POI devices to recognize tampering indicators such as unexpected attachments, different serial numbers, or broken security seals.

Practical implementation: Install card access systems on all entrances to areas containing cardholder data. Deploy video surveillance cameras on entrances, exits, and sensitive areas, and retain footage for at least three months. Create a POI device inventory that includes make, model, serial number, and location. Inspect devices at least monthly for evidence of tampering. Train cashiers and front-line staff on what to look for and whom to contact if tampering is suspected.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Requirement 10 establishes the logging and monitoring infrastructure that makes it possible to detect, investigate, and respond to security incidents. Without comprehensive logging, organizations cannot determine when a breach occurred, what data was accessed, or how the attacker entered. Nearly every major breach investigation reveals that logs either did not exist, were not reviewed, or were insufficient to reconstruct the attack timeline.

Key sub-requirements:

• 10.1: Define and document processes for logging and monitoring all access to system components and cardholder data.
• 10.2: Audit logs are implemented to support the detection of anomalies and suspicious activity. Log events must include all individual user access to cardholder data, all actions taken by anyone with root or administrative privileges, access to all audit trails, invalid logical access attempts, use of and changes to identification and authentication mechanisms, initialization and stopping of audit logs, and creation and deletion of system-level objects.
• 10.3: Audit logs are protected from destruction and unauthorized modifications. Logs must be sent to a centralized log server or SIEM. Access to logs must be limited to those with a job-related need. Integrity monitoring mechanisms must be in place to detect log tampering.
• 10.4: Audit logs are reviewed to identify anomalies or suspicious activity. Organizations must implement automated log review mechanisms (not manual review alone) to identify potential security events. All critical security events must trigger alerts for immediate investigation.
• 10.5: Audit log history is retained and available for analysis. Retain at least 12 months of audit log history, with at least the most recent three months immediately available for analysis.
• 10.6: Time synchronization mechanisms support consistent time across all systems. Use NTP or a similar protocol to synchronize all system clocks. Accurate timestamps are essential for correlating events across systems during incident investigations.
• 10.7 (new in v4.0): Failures of critical security control systems are detected, reported, and responded to promptly. This includes failures in firewalls, IDS/IPS, anti-malware, access controls, audit logging, and segmentation controls. Organizations must have processes to detect failures, generate alerts, and restore security functions promptly.

What changed in v4.0: Requirement 10.4 now mandates automated mechanisms for reviewing audit logs, replacing the previous allowance for purely manual review. Requirement 10.7 is entirely new and requires organizations to detect when security controls themselves fail, addressing the scenario where an attacker disables logging or security tools as part of their attack.

Practical implementation: Deploy a SIEM (Security Information and Event Management) platform or managed security operations center (SOC) service. Configure log sources to capture all required event types. Establish alerting rules for critical events such as multiple failed logins, privilege escalation, and configuration changes. Test log integrity and retention quarterly. Document the response procedure for security control failures.

Requirement 11: Test Security of Systems and Networks Regularly

Requirement 11 mandates ongoing security testing to verify that controls are working and to identify new vulnerabilities before attackers exploit them. This includes vulnerability scanning, penetration testing, network intrusion detection, and file integrity monitoring.

Key sub-requirements:

• 11.1: Define and document processes for regularly testing security of systems and networks.
• 11.2: Wireless access points are identified and monitored, and unauthorized wireless access points are addressed. Conduct wireless scans at least quarterly to detect rogue access points. This applies even if your organization does not use wireless networking, because an attacker could install a rogue access point on your network.
• 11.3: External and internal vulnerabilities are regularly identified, prioritized, and addressed. Run internal vulnerability scans at least quarterly (and after any significant change). Run external vulnerability scans at least quarterly by a PCI-approved Approved Scanning Vendor (ASV). Address critical and high-severity vulnerabilities promptly. Rescan to verify remediation.
• 11.4: External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected. Conduct penetration tests at least annually and after any significant infrastructure or application change. Testing must cover both the network layer and the application layer. Segmentation testing must be performed at least every six months (annually for SAQ-eligible merchants).
• 11.5: Network intrusions and unexpected file changes are detected and responded to. Deploy intrusion detection or intrusion prevention systems (IDS/IPS) at the perimeter and at critical points within the CDE. Implement file integrity monitoring (FIM) on critical system files, configuration files, and content files.
• 11.6 (new in v4.0): Unauthorized changes on payment pages are detected and responded to. This requirement mandates a mechanism to detect changes to HTTP headers, payment page content, and scripts on pages that load in the consumer's browser. This is the companion to Requirement 6.4.3's script management requirement.

What changed in v4.0: Requirement 11.6 is entirely new and directly targets the growing threat of e-commerce skimming attacks. Organizations must implement a mechanism to alert on unauthorized modifications to payment pages, whether that modification occurs on the server or through tampered third-party scripts loaded in the browser. Authenticated internal vulnerability scanning is now required (previously only recommended). Penetration testing methodology must cover the entire CDE perimeter and all critical systems.

Practical implementation: Engage a qualified penetration testing firm (such as Petronella's financial services security team) that understands PCI-specific testing methodology. Schedule quarterly internal scans and ASV scans in advance to avoid last-minute compliance gaps. Deploy FIM on all payment page files and monitor for changes in real time. For Requirement 11.6, implement real-time monitoring of payment page scripts using CSP reporting, JavaScript integrity monitoring, or a dedicated e-commerce security solution.

Requirement 12: Support Information Security with Organizational Policies and Programs

Requirement 12 covers the governance, policy, and people aspects of PCI DSS. Technical controls without supporting policies, training, and management oversight will eventually fail. This requirement establishes the organizational framework that sustains all other requirements.

Key sub-requirements:

• 12.1: A comprehensive information security policy is established, published, maintained, and disseminated to all relevant personnel and relevant vendors and business partners. The policy must be reviewed at least annually and updated when the environment changes.
• 12.2: Acceptable use policies for end-user technologies are defined and implemented.
• 12.3: Risks to the cardholder data environment are formally identified, evaluated, and managed. This requirement now explicitly mandates a targeted risk analysis for any requirement where the organization defines the frequency of a control activity (such as log review frequency, scan frequency, or password change intervals).
• 12.4 (enhanced in v4.0): PCI DSS compliance is managed as an ongoing program. For service providers, executive management must establish responsibility for protecting cardholder data, and the organization must perform quarterly reviews to confirm that personnel are following security policies and operating procedures.
• 12.5: PCI DSS scope is documented and validated. Organizations must document and confirm PCI DSS scope at least annually, and service providers must do so every six months. This formalized scoping exercise must identify all data flows, all system components in scope, and any segmentation controls.
• 12.6: Security awareness education is an ongoing activity for all personnel. Training must occur upon hire and at least annually. The content must address threats and vulnerabilities relevant to the organization, including phishing and social engineering.
• 12.7: Personnel are screened to reduce risks from insider threats. Background checks (within legal constraints) must be conducted on personnel who have access to the CDE.
• 12.8: Risk to information assets associated with third-party service provider (TPSP) relationships is managed. Maintain a list of all TPSPs that have access to CHD or could affect the security of the CDE. Monitor their PCI DSS compliance status. Obtain their Attestation of Compliance (AOC) or other evidence of their compliance annually.
• 12.9: Third-party service providers support their customers' PCI DSS compliance through written agreements that acknowledge their responsibility for protecting cardholder data.
• 12.10: Security incidents and suspected security incidents are responded to immediately. Maintain an incident response plan (IRP), test it at least annually, and train designated incident response personnel. The IRP must include specific procedures for responding to detected card data breaches, including notification of the card brands.

What changed in v4.0: Requirement 12.3's targeted risk analysis process is new and affects multiple other requirements throughout the standard. Organizations that choose to define their own frequency for certain activities must now document the risk analysis that supports that decision. Requirement 12.5's formal scoping validation is now mandatory, closing a gap where many organizations operated with outdated or inaccurate scope definitions. Service provider requirements in 12.4 were enhanced to include quarterly operational reviews.

Practical implementation: Designate a PCI DSS compliance owner who reports to senior leadership. Conduct annual policy reviews and update policies when significant changes occur. Maintain a service provider register and track their compliance status. Develop and test your incident response plan with tabletop exercises. Conduct scoping workshops annually, involving network engineering, application development, and business stakeholders who understand all cardholder data flows.

Penalties for PCI DSS Non-Compliance

PCI DSS is not a law, but non-compliance carries financial and operational consequences that rival regulatory penalties. The card brands impose fines on acquiring banks, which pass those costs to non-compliant merchants through their merchant agreements.

• Monthly fines: Card brands can levy fines of $5,000 to $100,000 per month against acquirers who fail to ensure their merchants are PCI DSS compliant. These fines are typically passed through to the merchant.
• Breach liability: If a non-compliant merchant experiences a data breach, they are liable for the cost of card reissuance ($3 to $10 per card), fraud losses on compromised cards, forensic investigation costs ($20,000 to $500,000+), and card brand fines that can reach several million dollars.
• Increased processing fees: Non-compliant merchants may be placed in higher-risk merchant categories with increased transaction fees.
• Loss of card acceptance: In extreme cases, card brands can revoke a merchant's ability to accept credit and debit cards entirely.
• State breach notification laws: All 50 U.S. states have data breach notification laws, many of which carry fines for delayed or inadequate notification. Several states, including Minnesota and Nevada, have enacted laws that specifically reference PCI DSS as the standard of care for payment security.
• Litigation: Breached organizations face class-action lawsuits from affected cardholders and customers. Non-compliance with PCI DSS is frequently cited as evidence of negligence in these cases.

The average total cost of a payment card data breach for a mid-size merchant ranges from $150,000 to $3 million when factoring in forensic investigation, fines, card reissuance costs, increased processing fees, and lost business. For large enterprises, costs can exceed $10 million. Compared to these figures, the investment in achieving and maintaining PCI DSS compliance is a straightforward risk management decision.

PCI DSS Compliance Cost Estimates for 2026

Compliance costs vary significantly based on your organization's size, complexity, current security posture, and the SAQ type that applies. Below are realistic cost ranges based on current market rates.

Cost Category	Small Merchant (SAQ A)	Mid-Size Merchant (SAQ C/D)	Large Merchant / Service Provider (Level 1)
Annual QSA Assessment	N/A (self-assessment)	$15,000 - $50,000	$50,000 - $250,000+
Quarterly ASV Scans	$400 - $2,000	$2,000 - $8,000	$8,000 - $25,000
Annual Penetration Testing	$3,000 - $8,000	$10,000 - $40,000	$30,000 - $100,000+
Security Tools (WAF, SIEM, EDR, FIM)	$1,000 - $5,000	$15,000 - $60,000	$75,000 - $300,000+
Gap Remediation (first year)	$2,000 - $10,000	$25,000 - $150,000	$100,000 - $1,000,000+
Ongoing Compliance Management	$500 - $2,000	$10,000 - $40,000	$50,000 - $200,000+
Estimated Annual Total	$7,000 - $27,000	$77,000 - $348,000	$313,000 - $1,875,000+

These estimates assume a reasonably mature security program. Organizations starting from scratch will face higher first-year costs for gap remediation. Conversely, organizations that already maintain strong security practices (such as those compliant with other frameworks like SOC 2 or HIPAA) will find significant overlap that reduces the incremental effort required for PCI DSS.

Key Changes from PCI DSS v3.2.1 to v4.0: Summary

For organizations transitioning from v3.2.1, here are the most impactful changes to address in your compliance program:

Change Area	v3.2.1	v4.0
MFA Scope	Required for remote access only	Required for all access into the CDE
Minimum Password Length	7 characters	12 characters (8 if system cannot support 12)
Disk Encryption	Acceptable as sole protection for PAN	Not acceptable as sole protection on non-removable storage
Payment Page Scripts	No specific requirement	Must inventory, authorize, and integrity-monitor all scripts (6.4.3)
Payment Page Tampering	No specific requirement	Must detect unauthorized changes to payment pages (11.6)
Anti-Phishing	No specific requirement	Must implement anti-phishing mechanisms (5.4)
Internal Vulnerability Scanning	Authenticated scanning recommended	Authenticated scanning required
Log Review	Manual review acceptable	Automated mechanisms required (10.4)
Security Control Failures	No specific requirement	Must detect and respond to control failures (10.7)
Scoping Validation	Recommended	Mandatory annual validation (12.5)
Approach Options	Defined approach only (with compensating controls)	Defined approach or customized approach

Organizations that previously relied on compensating controls under v3.2.1 should evaluate whether the new customized approach better serves their needs. The customized approach provides more flexibility but requires more rigorous documentation and QSA validation of the alternative controls.

Building Your PCI DSS Compliance Roadmap

Achieving PCI DSS compliance is a structured process that follows a predictable sequence. Whether you are starting from scratch or remediating gaps identified in a prior assessment, this roadmap provides a practical path forward.

Phase 1: Scope and Assess (Weeks 1-4)

• Identify all cardholder data flows in your organization
• Document every system component that stores, processes, or transmits CHD
• Determine your merchant level and applicable SAQ type
• Conduct a gap assessment against all 12 requirements
• Prioritize findings by risk severity and remediation effort

Phase 2: Remediate (Weeks 5-16)

• Address critical and high-severity gaps first
• Implement required technical controls (MFA, encryption, logging, FIM)
• Deploy or update security tools (WAF, SIEM, EDR, ASV scanning)
• Develop required policies and procedures
• Train staff on security awareness and PCI-specific responsibilities

Phase 3: Validate (Weeks 17-20)

• Run internal and external vulnerability scans
• Conduct penetration testing
• Complete the applicable SAQ or prepare for QSA on-site assessment
• Compile evidence packages for each requirement
• Submit Attestation of Compliance (AOC) to acquirer

Phase 4: Maintain (Ongoing)

• Monitor security controls continuously
• Run quarterly ASV scans and internal vulnerability scans
• Review access privileges every six months
• Validate PCI DSS scope annually
• Update policies and procedures when the environment changes
• Prepare for annual reassessment

The most common failure point is Phase 4. Many organizations treat PCI DSS compliance as a one-time project rather than an ongoing program. They achieve compliance, pass their assessment, and then let controls degrade until the next assessment cycle. By that point, they face another round of expensive remediation. Continuous compliance monitoring tools like ComplianceArmor help organizations maintain their compliance posture between assessments by tracking control effectiveness, evidence collection, and policy currency in real time.

Frequently Asked Questions About PCI DSS Compliance

Who needs to comply with PCI DSS?
Any organization that stores, processes, or transmits credit or debit card data must comply with PCI DSS. This includes merchants of all sizes, payment processors, payment gateways, hosting providers that store CHD, and any service provider involved in the payment chain. Even if you outsource payment processing entirely, you still have PCI DSS obligations (though your scope may be significantly reduced under SAQ A).

Is PCI DSS compliance required by law?
PCI DSS itself is not a federal law, but it is a contractual obligation enforced through merchant agreements with acquiring banks and card brands. Several U.S. states, including Nevada, Minnesota, and Washington, have enacted laws that reference PCI DSS or incorporate its requirements into state data security statutes. Courts also routinely cite PCI DSS non-compliance as evidence of negligence in breach litigation.

How often do I need to validate PCI DSS compliance?
Compliance must be validated annually through either a SAQ or a QSA-conducted Report on Compliance (ROC). Quarterly external vulnerability scans by an ASV are required for all merchants and service providers. Internal vulnerability scans must also run at least quarterly. Penetration testing must be conducted at least annually.

What is the difference between PCI DSS compliance and PCI DSS certification?
Technically, there is no "PCI DSS certification." Organizations achieve compliance and receive an Attestation of Compliance (AOC) and either a SAQ or ROC as evidence of their compliance status. The term "PCI certified" is commonly used in the industry but is not an official PCI SSC designation.

Can I reduce my PCI DSS scope?
Yes. Scope reduction is one of the most effective strategies for simplifying PCI DSS compliance. Common approaches include tokenization (replacing PANs with non-sensitive tokens), point-to-point encryption (P2PE) validated by the PCI SSC, network segmentation to isolate the CDE, and outsourcing payment processing to PCI-validated service providers. Each of these reduces the number of systems and processes that fall within your PCI DSS assessment scope.

How long does it take to become PCI DSS compliant?
For organizations starting from a mature security baseline, initial compliance can typically be achieved in three to six months. For organizations with significant gaps, the timeline extends to six to twelve months. The complexity of your cardholder data environment, the number of locations, and the volume of remediation required all affect the timeline. Planning a budget for remediation and allocating dedicated staff or an external partner are the two factors that most influence speed to compliance.

What happens during a PCI DSS assessment?
A QSA-conducted assessment involves reviewing documentation (policies, procedures, network diagrams, data flow diagrams), interviewing personnel responsible for security controls, observing processes in action, and testing technical controls through configuration reviews, vulnerability scans, and evidence sampling. The assessment typically takes two to four weeks on-site for Level 1 merchants, depending on the size and complexity of the environment.

Does PCI DSS apply to debit cards and prepaid cards?
Yes. PCI DSS applies to all payment cards bearing the logo of any of the five founding card brands: Visa, Mastercard, American Express, Discover, and JCB. This includes credit cards, debit cards, prepaid cards, and gift cards issued under these brands.

For additional guidance on protecting financial data across multiple compliance frameworks, see our guide on cybersecurity for financial services organizations.

PCI DSS compliance is not optional, and it is not a one-time project. It is an ongoing security program that protects your customers' payment data, reduces your breach liability, and strengthens your organization's overall security posture. The 12 requirements covered in this checklist provide a comprehensive framework, but implementing them correctly requires expertise in network security, application security, encryption, access control, and compliance management. Contact Petronella Technology Group at 919-348-4912 to discuss how we can help your organization achieve and maintain PCI DSS compliance.