TL;DR: 12 PCI DSS 4.0.1 requirements reference
- Beyond the 12: PCI DSS has 12 top-level requirements. Everyone quotes that number and stops. The interesting fact is that 4.0.1 now has over 400 sub-requirements, and the two most people fail are the newest ones nobody had evidence for before 2025.
- The two most failed: PCI DSS 4.0.1 became mandatory in March 2025. Requirements 6.4.3 (script inventory, business justification, integrity verification, change detection) and 11.6.1 (HTTP header monitoring on payment pages) are the two most under-prepared in current assessments. cside produces both artifacts continuously.
- Where to start: If you are scoping a 4.0.1 assessment and have no script inventory or header monitoring, start there before touching Requirements 3 or 12. If your 6.4.3 and 11.6.1 evidence is already flowing, focus scope creep review and MFA rollout under 8.4.2 next.
Short on time? See cside PCI Shield. It covers everything below in one deployment.
The 12 PCI DSS requirements are the core of the Payment Card Industry Data Security Standard. Every entity that stores, processes, or transmits card data has to meet them. This is the practical reference for what each requirement covers in PCI DSS 4.0.1, what changed from 3.2.1, and where most environments have gaps.
The structure: 6 goals, 12 requirements
PCI DSS organizes its controls under six security goals. Each goal contains one or more of the 12 top-level requirements. Each requirement contains multiple sub-requirements, and the total sub-requirement count in 4.0.1 is over 400.
Goal 1: Build and maintain a secure network and systems
Requirement 1: Install and maintain network security controls. Firewalls, router configurations, and network segmentation must isolate the cardholder data environment from untrusted networks. Every rule needs documented business justification.
Requirement 2: Apply secure configurations to all system components. No default passwords, no default accounts, no unnecessary services. Hardening baselines must be documented and applied to every system.
Goal 2: Protect account data
Requirement 3: Protect stored account data. Cardholder data must be encrypted using strong cryptography at rest. Sensitive authentication data (CVV, PIN, full track) must not be stored after authorization. If you do not need to store cardholder data, do not. The fastest path to Requirement 3 compliance is to not have the data.
Requirement 4: Protect cardholder data with strong cryptography during transmission. TLS 1.2 or higher across public networks. Deprecated protocols and weak ciphers must be inventoried and removed.
Goal 3: Maintain a vulnerability management program
Requirement 5: Protect all systems and networks from malicious software. Anti-malware controls on all systems in the CDE. Regular scanning and definition updates.
Requirement 6: Develop and maintain secure systems and software. Patch management, secure coding practices, change management. This is where Requirement 6.4.3 lives: the client-side script inventory and integrity control that was new in 4.0. See our practical guide to complying with PCI 6.4.3 and 11.6.1 for the specific implementation.
Goal 4: Implement strong access control measures
Requirement 7: Restrict access to system components and cardholder data by business need to know. Role-based access controls, least privilege, documented access approval.
Requirement 8: Identify users and authenticate access to system components. Unique IDs for every user, strong password requirements, MFA on all administrative access to the CDE (strengthened in 4.0.1 under 8.4.2).
Requirement 9: Restrict physical access to cardholder data. Physical controls on facilities that store cardholder data or house CDE systems.
Goal 5: Regularly monitor and test networks
Requirement 10: Log and monitor all access to system components and cardholder data. Comprehensive logging, log integrity, log review, and time synchronization across systems.
Requirement 11: Test security of systems and networks regularly. Vulnerability scans (internal and external, quarterly), penetration testing (annual + after significant change), and, critical for 4.0.1, Requirement 11.6.1 covering HTTP header monitoring on payment pages.
Goal 6: Maintain an information security policy
Requirement 12: Support information security with organizational policies and programs. Security policy, risk assessment, security awareness training, incident response, vendor management. Requirement 12 is the framework requirement that ties every other control back to an organizational commitment.
What's new in 4.0.1 versus 3.2.1
PCI DSS 4.0.1 became mandatory in March 2025. The biggest changes since 3.2.1:
| Change | Requirement | Impact |
|---|---|---|
| Script inventory + integrity on payment pages | 6.4.3 | Most environments had zero coverage before 2025 |
| HTTP header monitoring on payment pages | 11.6.1 | Same, new artifact required |
| Password rules strengthened | 8.3.6 | 12-character minimum |
| MFA on administrative access to CDE | 8.4.2 | Applies to non-console admin, not just remote |
| Cryptographic inventory | 12.3.3 | Cipher and protocol documentation |
| Log retention and review | 10.7.2/3 | Expanded log-review requirements |
| Customized approach | Multiple | New alternative to defined approach for controls |
The customized approach lets organizations meet the intent of a requirement with a different control than the standard prescribes, as long as they document the risk analysis and controls formally. This is powerful for mature security programs and dangerous for organizations that use it to justify weaker controls.
Where audits get stuck
Working with merchants going through 4.0.1 assessments, three patterns show up repeatedly:
- Requirements 6.4.3 and 11.6.1: no script inventory, no integrity monitoring, no HTTP header monitoring. See the QSA guide for what auditors specifically look for.
- Scope creep: the CDE includes more systems than the initial scope diagram showed, usually because segmentation is weaker than assumed
- Manual evidence: QSAs need continuous evidence, not screenshots taken during the assessment week
The full PCI DSS requirements list
PCI DSS 4.0.1 is organized into 6 goals and 12 requirements. The full PCI DSS requirements list is:
- Install and maintain network security controls.
- Apply secure configurations to all system components.
- Protect stored account data.
- Protect cardholder data with strong cryptography during transmission over open, public networks.
- Protect all systems and networks from malicious software.
- Develop and maintain secure systems and software.
- Restrict access to system components and cardholder data by business need to know.
- Identify users and authenticate access to system components.
- Restrict physical access to cardholder data.
- Log and monitor all access to system components and cardholder data.
- Test security of systems and networks regularly.
- Support information security with organizational policies and programs.
Requirements 6.4.3 and 11.6.1, both under requirement 6 and requirement 11 above, are where client-side script security lives: 6.4.3 governs the inventory and authorization of payment-page scripts, and 11.6.1 requires change and tamper detection on those scripts and on critical HTTP headers.
Where cside fits
Requirements 6.4.3 and 11.6.1 are cside's home ground. Continuous script inventory, business-justification tagging, integrity monitoring, HTTP header change detection, and audit-ready alert history come from the platform. The PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 compliance guide walks through what the dashboard produces and how a QSA reads it.
For the broader picture on preparing for a full assessment, see the Report on Compliance guide and the SAQ D guide.
