Requirements 1–4
Network security, secure configurations, stored data protection, and cryptography in transit.
Req 1 – Install & Maintain Network Security Controls
Sub Control Objectives
1.1 Processes and mechanisms for installing and maintaining NSCs are defined and understood.
1.2 Network security controls are configured and maintained.
1.3 Network access to/from the CDE is restricted.
1.4 Connections between trusted and untrusted networks are controlled.
1.5 Risks to CDE from devices on untrusted networks are mitigated.
Req 2 – Apply Secure Configurations to All System Components
Sub Control Objectives
2.1 Processes and mechanisms for applying secure configurations are defined and understood.
2.2 System components are configured and managed securely.
2.3 Wireless environments are configured and managed securely.
Req 3 – Protect Stored Account Data
Sub Control Objectives
3.1 Processes and mechanisms for protecting stored account data are defined and understood.
3.2 Storage of account data is kept to a minimum.
3.3 Sensitive authentication data is not stored after authorization.
3.4 Access to full PAN displays and copy ability are restricted.
3.5 PAN is secured wherever it is stored.
3.6 Cryptographic keys used to protect stored account data are secured.
3.7 Key-management processes covering all aspects of the key lifecycle are defined and implemented.
Req 4 – Protect CHD with Strong Cryptography in Transit
Sub Control Objectives
4.1 Processes and mechanisms for protecting CHD with strong cryptography in transit are defined and understood.
4.2 PAN is protected with strong cryptography during transmission.
Requirements 5–8
Malware protection, secure development, access control, and strong authentication.
Req 5 – Protect Systems and Networks from Malicious Software
Sub Control Objectives
5.1 Processes and mechanisms for protecting against malicious software are defined and understood.
5.2 Malicious software is prevented, or detected and addressed.
5.3 Anti-malware mechanisms and processes are active, maintained, and monitored.
5.4 Anti-phishing mechanisms protect users against phishing attacks.
Req 6 – Develop and Maintain Secure Systems and Software
Sub Control Objectives
6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.
6.2 Bespoke and custom software are developed securely.
6.3 Security vulnerabilities are identified and addressed.
6.4 Public-facing web applications are protected against attacks.
6.5 Changes to all system components are managed securely.
Req 7 – Restrict Access by Business Need to Know
Sub Control Objectives
7.1 Processes and mechanisms for restricting access by business need to know are defined and understood.
7.2 Access to system components and data is appropriately defined and assigned.
7.3 Access is managed via access control system(s).
Req 8 – Identify Users and Authenticate Access
Sub Control Objectives
8.1 Processes and mechanisms for identifying users and authenticating access are defined and understood.
8.2 User and administrator accounts are strictly managed throughout their lifecycle.
8.3 Strong authentication for users and administrators is established and managed.
8.4 MFA is implemented to secure access into the CDE.
8.5 MFA systems are configured to prevent misuse.
8.6 Application and system accounts and authentication factors are strictly managed.
Requirements 9–12
Physical security, logging and monitoring, testing, and governance.
Req 9 – Restrict Physical Access to Cardholder Data
Sub Control Objectives
9.1 Processes and mechanisms for restricting physical access to CHD are defined and understood.
9.2 Physical access controls manage entry into facilities and systems containing CHD.
9.3 Physical access for personnel and visitors is authorized and managed.
9.4 Media with CHD is securely stored, accessed, distributed, and destroyed.
9.5 POI devices are protected from tampering and unauthorized substitution.
Req 10 – Log and Monitor All Access
Sub Control Objectives
10.1 Processes and mechanisms for logging and monitoring all access are defined and understood.
10.2 Audit logs support detection of anomalies, suspicious activity, and forensic analysis.
10.3 Audit logs are protected from destruction and unauthorized modifications.
10.4 Audit logs are reviewed to identify anomalies or suspicious activity.
10.5 Audit log history is retained and available for analysis.
10.6 Time-synchronization mechanisms support consistent time settings across all systems.
10.7 Failures of critical security control systems are detected, reported, and responded to promptly.
Req 11 – Test Security of Systems and Networks Regularly
Sub Control Objectives
11.1 Processes and mechanisms for regularly testing security are defined and understood.
11.2 Wireless access points are identified, monitored, and unauthorized ones addressed.
11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.
11.4 Penetration testing is regularly performed and exploitable weaknesses are corrected.
11.5 Network intrusions and unexpected file changes are detected and responded to.
11.6 Unauthorized changes on payment pages are detected and responded to.
Req 12 – Support Information Security with Policies & Programs
Sub Control Objectives
12.1 A comprehensive information security policy governing protection of information assets is known and current.
12.2 Acceptable use policies for end-user technologies are defined and implemented.
12.3 Risks to the CDE are formally identified, evaluated, and managed.
12.4 PCI DSS compliance is managed.
12.5 PCI DSS scope is documented and validated.
12.6 Security awareness education is an ongoing activity.
12.7 Personnel are screened to reduce risks from insider threats.
12.8 Risk from third-party service provider relationships is managed.
12.9 Third-party service providers support their customers' PCI DSS compliance.
12.10 Suspected and confirmed security incidents impacting the CDE are responded to immediately.
Key Timing & Concept Values
Quick PCI DSS v4.0.1 reference for exams, workshops, and gap assessments.
| Item | Value | Very Short Explanation (PCI DSS 4.0.1) |
|---|---|---|
| Password change | 90 Days | Standard password rotation for high‑risk accounts |
| PCIDSS Current Version | 4.0.1 (2024) | Latest maintenance update to v4.0 |
| PCIDSS born in | 2004 | First release of PCI DSS |
| Account inactivity lockout | 90 Days | Dormant accounts must be disabled |
| Firewall review | 6 Months | Rule sets must be validated regularly |
| Audit logs retention | 12 months + 3 months online | Required for forensic readiness |
| Inbound/Outbound restrictions | Least privilege | Only necessary traffic allowed |
| Physical access logs | 3 Months | Track physical entry to secure areas |
| DMZ | Network segmentation | Isolates public‑facing systems |
| Internal vulnerability scan | Quarterly | Required for internal security posture |
| External vulnerability scan | ASV | Must be performed by PCI‑approved vendor |
| Penetration testing | Annually / major change | Validates security controls |
| FIM | Detects unauthorized changes | Required for critical files |
| Policy review | Annually | Ensures policies remain current |
| PCI DSS 3.2.1 retired | March 2024 | Fully replaced by v4.0 |
| TRA | Entity‑defined frequency | Allows flexibility for some controls |
| TRA approval | Senior management | Must approve risk‑based decisions |
| AOC | Attestation of Compliance | Formal validation of PCI status |
| Internal scans mandatory | From v4.0 | Strengthened scanning requirements |
| MFA mandatory | All devices | MFA required for all CDE access |
| Payment script review | 7 days or change | Detects tampering on payment pages |
| Phishing‑resistant MFA | FIDO2 / WebAuthn | Strongest MFA category |
| ROC/SAQ output | AOC | Required compliance evidence |
| Customized controls | TRA required | Must meet objective in Annex D |
| Compensating controls | Senior management | Must justify why standard control not met |
| Access rights review | 6 Months | Ensures least privilege is maintained |
| AOC findings | < 12 months | Findings must be current |
| Ecommerce with checkout page | SAQ AEP | Merchant website influences payment page |
| Req 11.6.1 | Tamper detection | Protects payment pages from modification |
| Idle session timeout | 15 minutes | Reduces risk of unattended sessions |
| Access review frequency | 6 Months | Required periodic access validation |
| Failed auth lockout | 30 minutes | Prevents brute‑force attacks |
| Customised Approach objective | Annex D | Defines security objective for alternatives |
| Non-console admin access | Strong crypto | Protects remote admin sessions |
| Who submits ROC | Level 1 merchants/providers | Highest‑volume entities |
| Req 7.2.1 principle | Deny‑all by default | Only explicit access allowed |
| Scope confirmation | Annual + major change | Ensures accurate PCI boundaries |
| Major change in 8.4.2 | MFA for all CDE access | Stronger authentication requirement |
| Cloud shared responsibility | Shared model | Provider + customer both responsible |
| PAN unreadable method | SHA256 + salt | Approved method for unreadability |
| Customised control acceptance | TRA + Annex D | Must meet stated objective |
| CDE definition | People, processes, tech | All components handling CHD |
SAQ Types
High-level mapping of Self-Assessment Questionnaires to common merchant scenarios.
| SAQ Type | Scope Summary |
|---|---|
| SAQ A | Fully outsourced payments, no card data on your systems. |
| SAQ B | Old‑style dial‑out terminals only. |
| SAQ EP | E‑commerce site + outsourced payments, but your website still matters. |
| SAQ P2PE | Using validated encrypted terminals that reduce PCI scope. |