The PCI-DSS v4.0.1 cheat sheet covers the 12 requirements, compliance levels (SAQ/QSA), CDE scope, key technical controls, and changes from v3.2.1 to v4.0.
| Aspect | Detail |
|---|---|
| Current standard | |
| Previous active | PCI-DSS v4.0 (retired December 31, 2024) |
| Retired | PCI-DSS v3.2.1 (retired March 31, 2024) |
| Publisher | |
| Scope | Any entity storing, processing, or transmitting CHD |
| Requirements | |
| Enforcement | Card brands (Visa, Mastercard, Amex, Discover, JCB) |
| New reqs mandatory | All new v4.0 requirements: |
| Term | Meaning |
|---|---|
| CHD | Cardholder Data: PAN, cardholder name, expiry date, service code |
| SAD | Sensitive Authentication Data: CVV/CVC, PIN/PIN block, full track data (mag stripe/chip) |
| CDE | |
| PAN | Primary Account Number (the card number itself) |
| QSA | Qualified Security Assessor (PCI SSC certified auditor) |
| ISA | Internal Security Assessor (internal trained assessor) |
| ASV | Approved Scanning Vendor (external vulnerability scans) |
| SAQ | Self-Assessment Questionnaire |
| ROC | Report on Compliance (produced by QSA) |
| AOC | Attestation of Compliance (signed declaration) |
| TPSP | Third-Party Service Provider |
| Date | Event |
|---|---|
| March 31, 2022 | |
| March 31, 2024 | |
| June 11, 2024 | |
| December 31, 2024 | |
| March 31, 2025 |
v4.0.1 changes (clarifications only): Req 3 (keyed hash clarification), Req 6 (critical vulns language restored), Req 8 (phishing-resistant MFA exemption note), Req 12 (TPSP relationship clarifications). No requirements added or removed.
| Goal | Req | Title | Key Sub-areas |
|---|---|---|---|
| Secure Network | Install and maintain network security controls | Firewalls, NSCs, network diagrams, rule review every 6 months | |
| Apply secure configurations to all system components | No defaults, hardening guides, shared hosting isolation | ||
| Protect CHD | Protect stored account data | No SAD post-auth, PAN encryption/truncation/tokenization, key mgmt | |
| Protect CHD with strong cryptography during transmission over open, public networks | TLS 1.2+ mandatory, TLS 1.3 preferred, no SSL/TLS 1.0/1.1 | ||
| Vuln Mgmt | Protect all systems and networks from malicious software | Anti-malware, EDR, removable media scan, phishing controls | |
| Develop and maintain secure systems and software | Secure SDLC, WAF, patching, SBOM, e-skimming (6.4.3) | ||
| Access Control | Restrict access to system components and CHD by business need to know | RBAC, least privilege, access reviews every 6 months | |
| Identify users and authenticate access to system components | MFA for all CDE access, 12-char passwords, account lockout | ||
| 9 | Restrict physical access to cardholder data | Physical entry controls, POS tamper protection, media destruction | |
| Monitor & Test | Log and monitor all access to system components and CHD | SIEM, 12-month retention, 3 months online, daily log review | |
| Test security of systems and networks regularly | Quarterly ASV scans, annual pentest, IDS/IPS, FIM, 11.6.1 | ||
| IS Policy | 12 | Support IS with organizational policies and programs | Security policy, risk assessment, incident response, TPSP mgmt |
MUST NOT store after authorization:
- SAD: full magnetic stripe / chip data
- SAD: CVV / CVV2 / CVC / CVC2
- SAD: PIN / PIN blocks
If PAN must be stored, it MUST be protected by one of:
- Truncation : show only last 4 digits (or first 6 + last 4 max)
- One-way keyed hash : HMAC-SHA256 minimum; different from PAN hash used elsewhere
- Strong encryption : AES-256 minimum
- Tokenization : replace PAN with non-derivable token (vault is in scope)
Key management requirements:
- Documented key management procedures (generation, distribution, storage, retirement)
- Cryptographic key rotation: at least every 2 years or upon suspected compromise
- Split knowledge and dual control for key custodians
- Keys stored separately from encrypted data
- Cryptographic key inventory maintained (new in v4.0)
- TLS 1.2 minimum (TLS 1.3 strongly preferred)
- TLS 1.0 and 1.1 PROHIBITED
- SSL PROHIBITED (no exception)
- Inventory of trusted TLS certificates required
- Never send PAN over unencrypted channels
(email, chat, SMS, unencrypted HTTP)
- PANs received via insecure channels must be
secured or deleted immediately
Secure SDLC requirements:
- OWASP Top 10 addressed in development
- Code reviews for all custom/bespoke code
- SAST + DAST integrated in development pipeline
- WAF: required for all web-facing apps in CDE
- Patch management: critical vulns within 1 month
New in v4.0:
- SBOM (Software Bill of Materials) for bespoke and custom software
- Req 6.4.3: Inventory and integrity-check ALL scripts on payment pages
(SRI hashes, CSP, or authorized script list)
- E-skimming mitigation: scripts must be justified (business purpose documented)
User account requirements:
- Unique user ID per person (no shared accounts, no shared generic accounts)
- MFA required for: ALL access into CDE (v4.0 expansion)
Remote access to CDE
All administrative access to CDE
- Phishing-resistant MFA (FIDO2/WebAuthn) exempted from some requirements
Password policy (v4.0 / v4.0.1):
- Minimum 12 characters (was 7 in v3.2.1)
- Complexity: uppercase + lowercase + digits + special characters
- Change every 90 days OR use additional authentication factor
- Account lockout: after 10 failed consecutive attempts
- Inactivity session timeout: 15 minutes
Privileged accounts:
- Review access rights every 6 months
- Use PAM / just-in-time access for administrative tasks
- Log all privileged account actions
Events that MUST be logged:
- All user access to CHD and cardholder data systems
- All actions by individuals with root/admin privileges
- Access to audit trails (who read the logs)
- Invalid logical access attempts (failed logins)
- Use of identification/authentication mechanisms
- Initialization, stopping, or pausing of audit logs
- Creation and deletion of system-level objects
Log retention:
- Minimum 12 months total retention
- At least 3 months must be immediately available for analysis
SIEM/monitoring requirements:
- Centralized log aggregation from all in-scope systems
- Real-time alerts on critical and suspicious events
- Automated log review mechanism (daily manual review acceptable)
- Anomaly and threat detection (behavioral analytics preferred)
- Alert on detection of critical file changes (FIM integration)
External vulnerability scans:
- Quarterly scans by ASV (Approved Scanning Vendor)
- Rescan until clean passing result achieved
- Required after significant changes
Internal vulnerability scans:
- Quarterly internal scans (authenticated scans preferred in v4.0)
- Rescan after significant infrastructure changes
- Risk-rank vulnerabilities and remediate per defined timelines
Penetration testing:
- Annual external + internal network penetration test
- Annual application-layer penetration test
- After significant infrastructure or application changes
- Scope: entire CDE perimeter + all critical systems
- Pentest methodology must be documented (PTES, OWASP, NIST SP 800-115)
Intrusion detection and file integrity:
- IDS/IPS on CDE perimeter and critical internal network points
- File Integrity Monitoring (FIM) for critical OS files, config files, content
- Req 11.6.1 (new v4.0): Detect unauthorized changes to payment page HTTP headers
and content at least every 7 days
Req 6.4.3 - Manage all payment page scripts:
- Maintain inventory of ALL scripts loaded on payment pages (first-party + third-party)
- Justify each script: documented business/technical need
- Ensure integrity: use Subresource Integrity (SRI) hashes OR Content Security Policy (CSP)
- Review and revalidate script inventory regularly
Req 11.6.1 - Change and tamper detection for payment pages:
- Deploy mechanism to detect unauthorized modifications to:
* HTTP headers (X-Frame-Options, CSP, etc.)
* Payment page content (HTML, JS)
- Alert on unauthorized changes within 7 days of change detection
- Acceptable mechanisms: CSP, SRI, automated payment page scanning tools
- Targets Magecart / web skimming attack class
Install and maintain network security controls (NSCs):
- Deploy firewalls / next-gen firewalls at all CDE boundaries
- Maintain current network diagrams showing all CHD data flows
- Maintain current system component inventory
- Review firewall/router rule sets every 6 months
- Default deny-all inbound AND outbound, with explicit allow-list
- No direct public access from internet to CDE (use DMZ)
- Restrict inbound and outbound traffic to only what is necessary
Key v4.0 changes:
- Terminology shift: "firewalls" replaced by "network security controls"
(covers cloud security groups, micro-segmentation, SDN, ZTNA)
- NSCs must control traffic between trusted and untrusted networks
- Roles and responsibilities must be explicitly documented
Apply secure configurations to all system components:
- Change all vendor-supplied defaults (passwords, SNMP strings, accounts)
- Disable unnecessary services, protocols, ports, and accounts
- Harden all system components per industry-accepted standards
(CIS Benchmarks, DISA STIGs, vendor hardening guides)
- Maintain documented configuration standards for all system types
- Shared hosting providers must protect each entity's CDE
Key v4.0 changes:
- Roles and responsibilities must be explicitly documented
- Inventory of all system components with function/owner
- Wireless vendor defaults must also be changed (WPA keys, SSID, etc.)
Protect all systems and networks from malicious software:
- Deploy anti-malware on ALL systems commonly affected by malware
- Anti-malware must be kept current (signatures/heuristics auto-updated)
- Periodic + real-time scanning enabled
- Anti-malware logs retained per Req 10
- Users cannot disable anti-malware without management approval
(and only for a limited time with documented justification)
Key v4.0 changes:
- Req 5.2.3.1: Evaluate systems NOT commonly affected (risk-based)
- Req 5.3.3: Scan removable media on connection OR use continuous scan
- Req 5.4.1: Technical controls to detect AND protect against phishing
(email filtering, link rewriting, sandboxing, DMARC/DKIM/SPF)
- Removable media scanning: on-insert or continuous behavioral analysis
Restrict access to system components and CHD to only authorized persons:
- Role-based access control (RBAC) model
- Default deny-all, grant access only as explicitly needed
- Access limited to least privileges required for job function
- Access control lists (ACLs) documented and maintained
- Review all user access rights at least every 6 months (Req 7.2.5)
Key v4.0 changes:
- Req 7.2.4: Review application and system accounts and privileges
- Req 7.2.5: All access assigned and managed via an access control model
- Req 7.2.5.1: Review application/system account access every 6 months
- Access control model must cover ALL system components (not just CHD)
Restrict physical access to cardholder data:
- Physical entry controls for CDE (badge readers, locks, cameras)
- Distinguish between onsite personnel and visitors
- Visitors: log entry/exit, escort at all times, visible badge
- Physically secure all media containing CHD
- Destroy media containing CHD when no longer needed
(cross-cut shredding, degaussing, or certified destruction)
- Protect POS devices against tampering and substitution
(maintain device inventory, inspect periodically, train staff)
Key v4.0 changes:
- Roles and responsibilities explicitly documented
- Periodic POS terminal inspection required (9.5.1.2)
- Restrict physical access to sensitive areas (server rooms, network closets)
Support information security with organizational policies and programs:
- Establish, publish, maintain a comprehensive IS policy (reviewed annually)
- Perform formal risk assessment at least annually and upon significant changes
(Req 12.3: use targeted risk analysis for flexible control frequencies)
- Security awareness training for all personnel upon hire + annually
- Screen personnel with access to CDE prior to hire (background checks)
- Manage all TPSPs with documented agreements (Req 12.8)
TPSP management (Req 12.8 / 12.9):
- Maintain inventory of all TPSPs with access to CHD or CDE
- Written agreements acknowledging TPSP responsibility for CHD security
- Due diligence before engagement + monitor TPSP PCI compliance status
- TPSPs must provide PCI DSS compliance status annually to customers (12.9)
Incident Response Plan (Req 12.10):
- Documented IRP covering: detection, containment, eradication, recovery
- Specific roles and responsibilities, contact info, communication plan
- IRP must address: card brand notification requirements, forensic procedures
- Annual testing of IRP (tabletop exercise or simulated incident)
- Post-incident review (lessons learned) after each confirmed incident
- Req 12.10.4.1 (new v4.0): Targeted risk analysis for frequency of
periodic incident response training
- Staff must be trained on IRP procedures
Designated Entities Supplemental Validation (DESV):
- Extra controls for entities designated by card brands (high-risk)
- Includes business-as-usual (BAU) monitoring of PCI controls
When an entity cannot meet a requirement as stated due to
legitimate technical or business constraints:
1. Identify the constraint preventing compliance
2. Document the original objective of the requirement
3. Design alternative control(s) that:
- Meet the intent and rigor of the original requirement
- Provide a similar level of protection
- Are "above and beyond" other PCI DSS requirements
4. Complete a Compensating Controls Worksheet per control
5. QSA must validate and document in ROC
Compensating controls are NOT:
- A way to skip requirements
- Acceptable if the original requirement can be met
- Permanent (must be re-evaluated each assessment cycle)
| Level | Annual Transaction Volume | Required Assessment |
|---|---|---|
| Level 1 | Annual on-site ROC by QSA or ISA + quarterly ASV scan | |
| Level 2 | 1 - 6 million transactions | Annual SAQ + quarterly ASV scan |
| Level 3 | 20,000 - 1 million e-commerce transactions | Annual SAQ + quarterly ASV scan |
| Level 4 | Annual SAQ + quarterly ASV scan (recommended) |
Note: Card brands (Visa, Mastercard, Amex) may impose Level 1 independently after a confirmed breach, regardless of volume.
| Level | Annual Transaction Volume | Required Assessment |
|---|---|---|
| Level 1 | Annual ROC by QSA + quarterly ASV scan | |
| Level 2 | Annual SAQ D (service provider version) + quarterly ASV scan |
Service providers face additional requirements vs merchants: semi-annual penetration testing, quarterly internal scans, 12.8 TPSP management controls.
| SAQ | Merchant Type | CHD Handling | Approx. Controls |
|---|---|---|---|
| SAQ A | No CHD on merchant systems | ~22 requirements | |
| SAQ A-EP | E-commerce, partial outsource, page directly POSTs to payment processor | Partial - redirect or iFrame | ~190 requirements |
| SAQ B | Card-present only: imprint machines or standalone dial-up terminals | No electronic CHD storage | ~41 requirements |
| SAQ B-IP | Standalone IP-connected POS terminals (no electronic CHD storage) | Terminal only, no CHD storage | ~83 requirements |
| SAQ C | POS with internet connection, no electronic CHD storage | POS only | ~160 requirements |
| SAQ C-VT | Virtual terminals only via web browser (keyed-in transactions) | No CHD stored electronically | ~65 requirements |
| SAQ P2PE | Hardware terminals managed within a validated P2PE solution | P2PE solution handles encryption | ~35 requirements |
| SAQ D | Any CHD handling | All 12 requirements | |
| SAQ D (SP) | Any CHD handling | All 12 + SP requirements |
| Req | Control | Detail |
|---|---|---|
| 3.3.3 | SAD storage for issuers | Issuers storing SAD must document business justification + secure storage |
| 8.3.10.1 | SP customer password change | If SP manages customer passwords, unique temp password per customer |
| 11.3.1.1 | Internal scan management | Address non-critical vulns from internal scans via targeted risk analysis |
| 11.4.7 | SPs supporting multi-tenant must test segmentation controls every 6 months | |
| 12.8 | TPSP agreements | Written acknowledgment of shared CHD security responsibility |
| 12.9.1 | Provide PCI DSS compliance status and responsibility info to customers | |
| 12.9.2 | Respond to customer requests for PCI compliance information promptly | |
| A1.1 | Multi-tenant isolation | Logical isolation between tenants, each tenant can only access own CDE |
| A1.2 | Tenant logging | Enable tenant-specific logging and monitoring |
Semi-annual penetration testing required for service providers (vs annual for merchants). Must include segmentation validation if multi-tenant.
IN SCOPE - System components that:
STORE CHD / SAD : payment databases, file servers, backup systems
PROCESS CHD / SAD : POS terminals, payment gateways, web servers, batch processors
TRANSMIT CHD / SAD : network switches, routers, proxies, load balancers handling CHD traffic
CAN IMPACT SECURITY : systems that can affect the security of CHD even if they don't touch it
- Active Directory domain controllers (auth for CDE systems)
- DNS servers resolving CDE hostnames
- NTP servers used by CDE components
- Patch management / SCCM servers pushing to CDE
- SIEM / log aggregators receiving CDE logs
- Jump hosts / bastion servers providing CDE access
- Vulnerability scanners targeting CDE
OUT OF SCOPE (only if properly isolated):
- Corporate LAN (if segmented from CDE with firewall + no CHD path)
- HR/ERP systems with no CHD and no network path to CDE
- Dev/test environments (if no real CHD, no path to production CDE)
| Technique | How it Reduces Scope | Residual Scope |
|---|---|---|
| Replace PAN with non-derivable token; only token vault + vault HSM in scope | Token vault system | |
| Card encrypted at terminal before reaching merchant; merchant never decrypts | Terminal hardware only | |
| Isolate CDE with firewalls, VLANs, ACLs; prevent all non-CHD traffic paths | CDE VLAN only | |
| Cloud PSP redirect | User redirected to PSP for payment page; merchant handles no CHD | Minimal - SAQ A eligible |
| iFrame-hosted payment | PSP iFrame embedded in merchant page; CHD goes directly to PSP | iFrame host + CSP controls |
Segmentation validation: Must be tested annually (and after significant changes) by a penetration test confirming no path from out-of-scope to in-scope systems.
| Area | Req | v3.2.1 | v4.0 / v4.0.1 |
|---|---|---|---|
| MFA | 8 | Required for remote access + non-consumer admin | |
| Password length | 8 | Minimum 7 characters | |
| Customized approach | All | Not available | |
| Targeted risk analysis | Various | Limited | |
| SBOM | 6 | Not required | Required for bespoke/custom software |
| Payment page scripts | 6.4.3 | Not explicit | |
| Payment page tamper | 11.6.1 | Not explicit | Detect unauthorized changes to payment pages within 7 days |
| Anti-phishing | 5 | Not explicit | |
| Roles & responsibilities | All | Recommended | |
| Vuln remediation | 6 | Critical patches within 1 month | |
| Removable media | 5 | Periodic scan | Scan on connection OR continuous scanning |
| Cryptography inventory | 3 | Not required | |
| Annual security training | 12 | Generic awareness | Must reflect latest threat landscape annually |
The customized approach (new in v4.0) allows organizations to design their own security controls to meet the stated objective of a requirement, rather than following the prescriptive defined approach.
Requirements for using customized approach:
1. Document the control objective being met
2. Perform a targeted risk analysis for the custom control
3. Document the custom control design and evidence
4. Test the custom control effectiveness
5. QSA must validate: customized controls require QSA assessment (no SAQ)
6. Maintain ongoing evidence of control effectiveness
When to use:
- Organization has mature security program exceeding prescriptive requirements
- Technology stack doesn't map cleanly to prescriptive control language
- Emerging technology (cloud-native, Zero Trust, passwordless)
When NOT to use:
- Not available for all requirements (some are prescriptive-only)
- Requires significantly more documentation burden
- Not compatible with SAQ (only ROC/QSA assessments)
The following requirements were "best practice" until March 31, 2025 and are now mandatory:
| Req | Description |
|---|---|
| 3.3.2 | Encryption of SAD stored before completion of authorization (issuers only) |
| 3.5.1.2 | Disk-level encryption no longer acceptable as sole PAN protection |
| 3.6.1.1 | Cryptographic key inventory maintained |
| 5.3.3 | Anti-malware scans on removable media upon connection |
| 5.4.1 | Anti-phishing technical controls deployed |
| 6.3.2 | Software inventory for bespoke and custom software (SBOM) |
| 7.2.5 | Access review for all accounts every 6 months |
| 7.2.5.1 | Application/system account access review every 6 months |
| 8.3.6 | Minimum 12-character passwords |
| 8.4.2 | MFA for all access into the CDE |
| 8.5.1 | MFA implementation - all authentication factors independent |
| 8.6.1 | System/application accounts: interactive login managed on exception basis |
| 8.6.2 | No hard-coded passwords in scripts or custom application code |
| 10.4.1.1 | Automated audit log review mechanisms |
| 10.7.2 | Detect, alert, address failures of critical security controls promptly |
| 12.3.1 | Targeted risk analysis to determine frequency of periodic activities |
| 12.6.3.1 | Security awareness training includes threat awareness |
| 12.10.4.1 | Frequency of IR training via targeted risk analysis |
| Assessment | Full Name | Who Performs | Who Uses It | Scope |
|---|---|---|---|---|
| ROC | Report on Compliance | Level 1 merchants and Level 1 SPs | Full 12 requirements, all sub-reqs | |
| SAQ | Self-Assessment Questionnaire | Merchant / SP (self-assessed) | SAQ type-dependent subset | |
| AOC | Attestation of Compliance | Signed by merchant/SP executive + QSA (if ROC) | Accompanies ROC or SAQ | |
| AOSC | Attestation of Scan Compliance | ASV (Approved Scanning Vendor) | All merchants requiring external scans | Quarterly external vulnerability scan |
ROC structure: Executive summary + scope definition + evidence findings per requirement + compensating controls (if any) + AOC signed by QSA and entity executive. Valid for 12 months.
| Control Area | Requirement | Specifics |
|---|---|---|
| PAN at rest | Req 3 | AES-256 preferred; TDES (3DES) legacy only, being retired |
| PAN in transit | Req 4 | TLS 1.2+ (1.3 preferred), no SSL, no TLS 1.0/1.1 |
| Key storage | Req 3 | Keys stored separately from encrypted data |
| Key rotation | Req 3 | Every 2 years or on suspected compromise |
| Key custodians | Req 3 | Split knowledge + dual control |
| Key inventory | Req 3 | |
| HSM | Req 3 | Hardware Security Module recommended for key protection |
CDE isolation requirements:
- Firewall between CDE and all other networks (internal + external)
- "Deny all" default with explicit allow-list rules
- DMZ for any public-facing systems touching CHD
- Review and test firewall rules every 6 months
- Document all connections into and out of CDE
- Network diagram showing all CHD data flows (maintained current)
Segmentation validation:
- Penetration test MUST confirm segmentation effectiveness
- Annual test + after significant network changes
- Confirm no path from out-of-scope to CDE systems
- Test all access points (firewall, VLAN, ACL, cloud security groups)
ASV (Approved Scanning Vendor) external vulnerability scans:
- Required quarterly for ALL merchants and SPs (Req 11.3.2)
- Must use PCI SSC approved scanning vendor
- Scan scope: all externally facing IP addresses and domains in CDE
- Passing scan: no vulnerabilities scored CVSS 4.0+ (after exceptions)
- Failed scan: remediate and rescan until passing result
- Rescan required after significant infrastructure changes
- Scan disputes: can submit to ASV for rescoring with evidence
- Scan results valid for 90 days (quarterly cadence)
ASV scan vs internal scan vs pentest:
- ASV scan: external automated vuln scan (quarterly, by ASV)
- Internal scan: internal vuln scan (quarterly, can be self-performed)
- Pentest: manual exploitation testing (annual, by qualified tester)
Penetration testing requirements:
- Annual external penetration test
- Annual internal penetration test
- Annual application-layer penetration test (for bespoke/custom apps)
- After ANY significant change to CDE infrastructure or applications
- Service providers: every 6 months (instead of annual)
Scope and methodology:
- Entire CDE perimeter and all critical internal systems
- Must follow industry-accepted methodology
(PTES, OWASP Testing Guide, NIST SP 800-115, CREST)
- Network-layer AND application-layer testing
- Must test from both inside and outside the network
- Include segmentation validation (confirm isolation of CDE)
Remediation:
- All exploitable vulnerabilities must be remediated
- Retest to verify remediation effectiveness
- Document findings, risk ratings, and remediation evidence
- Retain pentest reports for QSA review
Tester qualifications:
- Organizational independence (not the team that built/manages the systems)
- External tester not required but must be qualified
- For service providers: external tester or organizational independence