Only 14% of organizations maintain full PCI DSS compliance at any given time, according to the Verizon 2024 Payment Security Report. The other 86% operate with compliance gaps that expose them to escalating fines, breach liability, and potential loss of card processing privileges.
This PCI compliance checklist breaks down all 12 PCI DSS requirements, explains the v4.0 changes that became mandatory in March 2025, and covers the scope reduction strategies that can cut your compliance burden from 328 controls to 24.
What is PCI DSS and who must comply?
PCI DSS (Payment Card Industry Data Security Standard) is the security framework governing any organization that stores, processes, or transmits cardholder data. The standard is maintained by the PCI Security Standards Council and enforced by the card networks: Visa, Mastercard, American Express, Discover, and JCB.
Compliance is not optional. Any merchant accepting card payments, any service provider handling card data on behalf of merchants, and any entity whose systems touch cardholder data must comply. The specific compliance requirements depend on transaction volume:
| Level | Transaction volume | Validation requirement |
|---|---|---|
| Level 1 | 6+ million transactions/year | External QSA audit, Report on Compliance (ROC) |
| Level 2 | 1-6 million transactions/year | SAQ, some may require QSA audit |
| Level 3 | 20,000-1 million e-commerce transactions/year | SAQ |
| Level 4 | Under 20,000 e-commerce transactions/year | SAQ |
The Cardholder Data Environment (CDE) defines which systems fall within PCI scope. Any system that stores, processes, or transmits cardholder data, plus any system connected to those systems, is in scope. This is where scope reduction through tokenization and outsourcing becomes relevant: remove systems from the CDE, and they exit your compliance boundary.
The 12 PCI DSS requirements explained
PCI DSS v4.0 contains over 500 specific requirements organized under 12 principal requirements. Each requirement addresses a distinct security domain.
| Req. | Domain | Core obligation |
|---|---|---|
| 1 | Network security controls | Firewalls, segmentation, traffic rules |
| 2 | Secure configurations | Remove vendor defaults, document standards |
| 3 | Protect stored data | Tokenize/encrypt PANs, never store SAD |
| 4 | Encrypt transmission | TLS 1.2+ for data in transit |
| 5 | Anti-malware | Deploy and maintain on all affected systems |
| 6 | Secure development | Secure SDLC, payment page script controls |
| 7 | Access control | Need-to-know basis, role-based access |
| 8 | User authentication | Unique IDs, MFA for CDE access, 12-char passwords |
| 9 | Physical access | Badges, visitor logs, video monitoring |
| 10 | Logging and monitoring | Track all access, daily log review |
| 11 | Security testing | Quarterly scans, annual pen tests, page monitoring |
| 12 | Policies and programs | Security policy, training, incident response |
Each requirement maps to a security domain. Requirements 3, 6, and 11 changed most significantly in v4.0.
Requirement 1: Install and maintain network security controls
Network security controls (firewalls, security groups, network segmentation) must restrict traffic between trusted and untrusted networks. Cardholder data environments require explicit inbound and outbound rules, with all allowed traffic documented and justified. Segmentation that isolates the CDE from other networks reduces scope.
Requirement 2: Apply secure configurations to all system components
Vendor-supplied defaults for passwords, configurations, and unnecessary services must be changed or disabled before deployment. This applies to all system components: servers, network devices, applications, databases, and security systems. Configuration standards must be documented and maintained.
Requirement 3: Protect stored account data
Cardholder data storage must be minimized. When storage is necessary, primary account numbers (PANs) must be rendered unreadable through tokenization, truncation, hashing, or encryption. Sensitive authentication data (full track data, CVV/CVC, PINs) must never be stored after authorization.
Requirement 4: Protect cardholder data with strong cryptography during transmission
Cardholder data transmitted across open, public networks must be encrypted using strong cryptography. This includes transmission over the internet, wireless networks, and cellular technologies. TLS 1.2 or higher is required; SSL and early TLS versions are prohibited.
Requirement 5: Protect all systems and networks from malicious software
Anti-malware solutions must be deployed on all systems commonly affected by malware. This includes Windows systems, workstations, and increasingly Linux servers. Solutions must be kept current, perform periodic scans, and generate audit logs.
Requirement 6: Develop and maintain secure systems and software
Secure development practices must be followed for all software developed internally or by third parties. This includes secure coding guidelines, code reviews, vulnerability identification during development, and protection of payment page scripts. Requirement 6.4.3 (discussed below) adds specific controls for client-side scripts on payment pages.
Requirement 7: Restrict access to system components and cardholder data by business need to know
Access to cardholder data and CDE systems must be limited to personnel whose job requires it. Access control systems must default to “deny all” and grant access only when explicitly authorized. Role-based access control enforces least privilege.
Requirement 8: Identify users and authenticate access to system components
Every user must have a unique ID. PCI DSS v4.0 requires multi-factor authentication (MFA) for all access to the CDE, not just administrative access. Password requirements increased to minimum 12 characters (up from 8 in v3.2.1).
Requirement 9: Restrict physical access to cardholder data
Physical access to systems containing cardholder data must be controlled. This includes data centers, server rooms, and any location where cardholder data is present. Visitor logs, access badges, and video monitoring are standard controls.
Requirement 10: Log and monitor all access to system components and cardholder data
Logging mechanisms must track all access to network resources and cardholder data. Logs must include user identification, event type, date/time, success/failure, and data accessed. Log integrity must be protected, and logs must be reviewed at least daily.
Requirement 11: Test security of systems and networks regularly
Vulnerability scans (internal and external) must run at least quarterly. Penetration testing must occur annually and after significant changes. PCI DSS v4.0 adds requirement 11.6.1 for automated change detection on payment pages, with alerting on unauthorized modifications.
Requirement 12: Support information security with organizational policies and programs
A formal information security policy must exist and be maintained. This includes risk assessment processes, security awareness training, incident response procedures, and service provider management. Documentation requirements under v4.0 are extensive: penetration test reports, segmentation test results, vulnerability scans, risk assessments, training records, and incident response plans.
PCI DSS v4.0: key changes and transition timeline
PCI DSS v4.0 was released in March 2022 and became mandatory in March 2024 when v3.2.1 was retired. However, 51 requirements were future-dated, meaning organizations had until March 31, 2025 to implement them. Those requirements are now mandatory.
The 51 future-dated PCI DSS v4.0 requirements became mandatory on March 31, 2025. Organizations that have not implemented requirements 6.4.3, 11.6.1, expanded MFA, and the other future-dated controls are now non-compliant.
| Date | Milestone |
|---|---|
| March 2022 | PCI DSS v4.0 released |
| March 2024 | PCI DSS v3.2.1 retired, v4.0 mandatory |
| June 2024 | PCI DSS v4.0.1 published (minor clarifications) |
| March 31, 2025 | 51 future-dated requirements became mandatory |
Key v4.0 changes now in effect:
| Requirement | Change | Impact |
|---|---|---|
| 6.4.3 | Payment page script inventory | Full inventory, authorization, and integrity controls |
| 11.6.1 | Change detection on payment pages | Automated monitoring at least every 7 days |
| 8.3.6 | MFA for all CDE access | Applies to all access, not just remote admin |
| 8.3.6 | 12-character minimum passwords | Up from 8 characters in v3.2.1 |
| Multiple | Shift to continuous monitoring | Risk-based frequencies, not just annual/quarterly |
Requirement 6.4.3: Payment page script inventory and integrity
Organizations must maintain a complete inventory of all scripts executing on payment pages. Each script requires documented authorization and integrity verification mechanisms. This targets Magecart-style attacks where malicious scripts skim card data from payment forms.
Requirement 11.6.1: Change detection on payment pages
Automated detection and alerting on unauthorized modifications to payment pages, including HTTP headers and page content. Minimum frequency: every 7 days, or per a targeted risk analysis if more frequent.
Expanded MFA requirements
MFA is now required for all access to the CDE, not just remote administrative access. This applies to both onsite and remote access.
Password length increase
Minimum password length increased from 8 to 12 characters. Systems that cannot technically support 12 characters may use 8 as an exception.
Shift to continuous monitoring
PCI DSS v4.0 moves from periodic point-in-time validation toward continuous security monitoring. Organizations must define security control frequencies based on their own risk assessments rather than defaulting to annual or quarterly.
Determining your SAQ type and compliance scope
Self-Assessment Questionnaires (SAQs) vary in scope based on how your organization handles cardholder data. The difference is substantial: SAQ A contains 24 requirements, while SAQ D contains 328.
| SAQ type | Applicable to | Requirements |
|---|---|---|
| SAQ A | E-commerce merchants with fully outsourced card functions (no electronic storage, processing, or transmission of CHD) | 24 |
| SAQ A-EP | E-commerce merchants using iframe/redirect, but whose website could affect payment page security | 139 |
| SAQ B | Merchants using imprint machines or standalone dial-out terminals only | 41 |
| SAQ C | Merchants with payment application systems connected to the internet, no electronic CHD storage | 160 |
| SAQ D | All other merchants and all service providers | 328 |
SAQ type depends on your payment architecture:
- If cardholder data passes through your servers before reaching a payment processor, you face SAQ D or a QSA assessment
- If you use an iframe or redirect where card data goes directly from the customer’s browser to the payment provider, you may qualify for SAQ A-EP or SAQ A
- If your systems never touch cardholder data and you use a fully hosted payment page, SAQ A applies
The architecture decision happens at implementation, not at compliance time. Choosing the right integration pattern upfront determines your compliance burden for years.
Scope reduction strategies: tokenization and outsourcing
Scope reduction removes systems from your CDE, decreasing the number of controls you must implement and validate. The two primary mechanisms are tokenization and outsourcing payment handling to a PCI-compliant provider.
Tokenization
Tokenization replaces cardholder data with a non-sensitive token that has no exploitable value if stolen. The token can be used for recurring charges, refunds, and transaction references without exposing the actual card number.
Tokenization eliminates PCI scope when implemented correctly. The card data must pass directly from the customer’s browser to the tokenization service. If card data touches your servers before tokenization, those servers remain in scope.
According to the PCI Security Standards Council’s Tokenization Guidelines, effective tokenization requires:
- Token generation occurs outside your systems
- No reverse-engineering path from token to PAN exists in your environment
- Token storage systems do not store or have access to PANs
Outsourcing to PCI-compliant providers
Using a payment orchestration platform with PCI Level 1 certification can shift compliance burden from your organization to the provider. Your CDE boundary shrinks to exclude systems the provider manages.
This does not eliminate all compliance obligations. You must:
- Verify the provider’s Attestation of Compliance (AOC) annually, checking date, assessor, and scope
- Review data flow diagrams to confirm card data routing matches what’s documented
- Maintain a vendor risk management program
- Complete your own SAQ covering the systems that remain in scope
The reduction is real: SAQ A’s 24 requirements versus SAQ D’s 328 represents a 93% decrease in compliance controls. For organizations seeking to expand payment capabilities without proportionally expanding their compliance team, this is the primary value of outsourcing.
What remains your responsibility
Regardless of outsourcing, you remain responsible for:
- Vendor selection and due diligence
- Ongoing monitoring of provider compliance status
- Protecting any systems that connect to the provider
- Incident response coordination if the provider has a breach
- Contractual provisions (data processing agreements, breach notification terms)
The real cost of PCI compliance and non-compliance
PCI compliance costs vary by organization size and complexity. Non-compliance costs can exceed compliance costs by orders of magnitude.
Compliance costs vary by organization size:
| Organization type | Annual compliance cost |
|---|---|
| Small business (Level 4) | $5,000-$20,000 |
| Mid-size organization | $50,000-$200,000 |
| Level 1 merchant (first year) | $245,000-$600,000 |
| Level 1 merchant (ongoing) | $160,000-$350,000 |
Source: Feroot Security, Centraleyes, 2025
QSA assessment costs depend on scope:
| Assessment type | Cost range |
|---|---|
| SAQ-assisted assessments | $10,000-$40,000 |
| Full Report on Compliance (ROC) | $30,000-$200,000 |
Source: Thoropass, 2025
Card networks impose escalating fines for non-compliance:
| Duration of non-compliance | Monthly fine |
|---|---|
| Months 1-3 | $5,000-$10,000 |
| Months 4-6 | $25,000-$50,000 |
| Beyond 6 months | $100,000 |
Source: Clone Systems, 2025
Data breach costs extend beyond fines. According to industry data compiled by Accutive Security, average breach costs by industry:
| Industry | Average breach cost |
|---|---|
| Healthcare | $10.93 million |
| Financial services | $5.97 million |
| Retail | $3.28 million |
Target’s 2013 breach, which exploited PCI compliance failures, cost $292 million in total.
Beyond direct costs, non-compliance can result in loss of card processing privileges, leaving a business unable to accept card payments.
How Orchestra reduces PCI compliance burden
Orchestra operates as a PCI Level 1 certified payment orchestration platform. By routing card data through Orchestra rather than your own systems, you can reduce your CDE boundary and qualify for a simpler SAQ type.
How the integration works
Orchestra’s JavaScript library loads directly in the customer’s browser. When the customer enters card details, that data passes from their browser to Orchestra’s tokenization service. Your servers receive a token, not the card number.
Because card data never touches your servers, your CDE is minimized or even eliminated entirely. If you previously faced SAQ D compliance (328 requirements), this architecture can qualify you for SAQ A (24 requirements).
What Orchestra handles
- Secure card data collection via browser-based tokenization
- PCI-compliant storage of card data in Orchestra’s vault
- 3D Secure authentication where required for SCA compliance
- Connections to 90+ payment providers through a single integration
What remains your responsibility
- SAQ A completion and annual validation
- Protecting your systems that connect to Orchestra’s API
- Vendor due diligence (reviewing Orchestra’s AOC, completing your vendor risk assessment)
- Incident response coordination
The cost of maintaining your own card vault often exceeds the cost of outsourcing. Vaulting requires PCI-compliant infrastructure, encryption key management, and ongoing QSA assessments for the vault itself. Outsourcing shifts those costs and responsibilities to the provider.
For organizations adding new payment methods, processors, or markets, Orchestra’s single integration prevents each addition from expanding your compliance scope. You add capabilities without adding CDE surface area.
Frequently asked questions
What SAQ type applies if I use a payment orchestration platform?
Using a payment orchestration platform with tokenization typically qualifies you for SAQ A (24 requirements) or SAQ A-EP, depending on whether your servers handle cardholder data. SAQ A requires all card data to pass directly from the customer’s browser to the tokenization service, with your servers receiving only tokens.
Does tokenization completely eliminate PCI scope for my systems?
Tokenization can eliminate scope when implemented correctly. Card data must pass directly from the customer to the tokenization service with no intermediate stops in your systems. You remain responsible for vendor management, protecting the systems that receive tokens, and completing the appropriate SAQ for your reduced scope.
What are the key differences between PCI DSS v3.2.1 and v4.0?
PCI DSS v4.0 adds over 130 new requirements including expanded MFA for all CDE access (not just remote admin), new payment page script controls (requirements 6.4.3 and 11.6.1), minimum 12-character passwords, and a shift from periodic validation to continuous monitoring. 51 of these requirements were future-dated and became mandatory March 31, 2025.
How does outsourcing payment processing affect my CDE boundary?
Outsourcing to a PCI-compliant provider removes those systems from your CDE, but you must verify the provider’s AOC (Attestation of Compliance), review their data flow diagrams to confirm data routing, and maintain a vendor risk management program. You remain responsible for the systems that connect to the provider and for completing your own SAQ.
What documentation do I need for a PCI DSS assessment?
Required documentation includes penetration testing reports, segmentation testing results, vulnerability scan reports, risk assessment reports, information security policy, training records, incident response plan, and data flow diagrams showing how cardholder data moves through your environment. PCI DSS v4.0 expanded documentation requirements compared to earlier versions.
How much does PCI DSS compliance cost?
Costs vary by organization size: small businesses typically spend $5,000-$20,000 annually, while large organizations face $50,000-$200,000. Level 1 merchants requiring full QSA assessments can expect $245,000-$600,000 in first-year costs and $160,000-$350,000 ongoing. QSA audits alone cost $30,000-$200,000 depending on scope.
What are PCI DSS requirements 6.4.3 and 11.6.1?
Requirement 6.4.3 mandates a complete inventory of all scripts executing on payment pages, with documented authorization and integrity controls for each script. Requirement 11.6.1 requires automated detection and alerting on unauthorized changes to payment pages, including HTTP headers and page content, at least every 7 days. Both became mandatory March 31, 2025.
What happens if you fail PCI compliance?
Non-compliance fines start at $5,000-$10,000 per month and escalate to $100,000 per month after six months of continued non-compliance. Additional consequences include potential loss of card processing privileges and liability for breach costs. Average breach costs exceed $4 million, with retail breaches averaging $3.28 million and financial services breaches averaging $5.97 million.
