PCI DSS v4.0 contains 12 top-level requirements, each containing multiple detailed sub-requirements (sometimes called testing procedures). Each requirement describes a specific security objective, such as installing firewalls, protecting stored card data, or maintaining security policies. Below each requirement, the standard specifies testing procedures that define how compliance is validated. Understanding all 12 requirements at a structural level is the essential foundation for any implementation or assessment program.
The 12 requirements are organized under six control objectives that represent the key domains of payment card security. Each control objective contains two requirements. This article walks through all 12, explaining what each requirement covers, the key sub-components, and the most common implementation challenges.
| KEY IDEA | PCI DSS v4.0 introduced a "Customized Approach" alongside the traditional "Defined Approach." Under the Customized Approach, organizations can implement alternative controls that meet the stated objective of a requirement, even if they differ from the prescriptive control described. This flexibility comes with additional documentation, risk analysis, and QSA testing burdens. |
Requirement 1: Install and Maintain Network Security Controls
Requirement 1 mandates that organizations install and maintain firewalls and network security controls to protect the cardholder data environment. The requirement covers the design and maintenance of network architecture, including creation of a network diagram showing all connections between the CDE and external systems or the internet. Organizations must document and enforce a set of firewall rules that define what traffic is permitted and blocked. Rule sets must be reviewed at least every six months to ensure rules remain current and aligned with business needs.
Key sub-requirements include: defining a network architecture and cardholder data environment boundary, deploying firewalls at the CDE perimeter, establishing a demilitarized zone (DMZ) for internet-facing systems, creating network diagrams showing data flows, documenting firewall rules with business justification, and reviewing rules periodically. A common implementation challenge is keeping network diagrams current as systems and connections evolve.
Requirement 2: Apply Secure Configurations to All System Components
Requirement 2 requires that all systems in the CDE be configured securely. This begins with eliminating default configurations—default passwords, default ports, and default services that manufacturers enable by default. Organizations must establish and maintain hardening standards based on industry benchmarks (such as CIS Benchmarks, which provide detailed hardening guidelines for common operating systems and applications). All unnecessary services and ports must be disabled, all default credentials must be changed, and documentation of all system components and their configurations must be maintained.
Key sub-requirements include: identifying and documenting all system components, establishing hardening standards aligned with industry best practices, disabling unnecessary services and protocols, changing all default passwords and credentials, testing system configurations before deployment, and regularly reviewing system inventory. A common implementation challenge is maintaining hardening standards at scale, particularly in organizations with hundreds or thousands of systems.
Requirement 3: Protect Stored Account Data
Requirement 3 is one of the most critical and frequently misunderstood requirements. It mandates that organizations never store sensitive authentication data (CVV, PIN, full track data) after transaction authorization, and that the primary account number (PAN)—the 16-digit card number—must be rendered unreadable in storage. This means that if cardholder data must be stored, the PAN must be protected through one of four mechanisms: encryption, truncation, tokenization, or hashing. Additionally, PANs that appear in logs, configuration files, backup media, or cardholder communication must be rendered unreadable.
Key sub-requirements include: establishing a policy for sensitive data retention (ideally minimizing or eliminating storage altogether), implementing strong encryption for stored PANs using validated cryptographic algorithms, maintaining proper key management, truncating or tokenizing PANs to render them unreadable, implementing data discovery procedures to locate unintended PANs in logs and file systems, and rendering PANs unreadable even in debug output and temporary files. A common implementation challenge is discovering where PANs are stored unexpectedly—in logs, backups, debug files, or third-party systems—and remediating those uncontrolled storage locations.
Requirement 4: Protect Cardholder Data with Strong Cryptography in Transit
Requirement 4 mandates that cardholder data be encrypted when transmitted across public networks or untrusted networks. This requirement specifically requires TLS 1.2 as a minimum (TLS 1.3 is preferred), with strong cipher suites. All certificates must be valid and current, and must be managed through a formal certificate lifecycle process. Additionally, organizations must maintain an inventory of all trusted keys and certificates, with documentation of their purpose and usage.
Key sub-requirements include: implementing TLS 1.2 or higher for all transmission of cardholder data, managing SSL/TLS certificates with a formal process including renewal before expiration, validating that certificates are legitimate and trusted, implementing strong cipher suites and disabling weak ciphers, preventing cardholder data transmission over end-user messaging applications, and maintaining inventory of trusted keys and certificates. A common implementation challenge is upgrading legacy systems that still rely on older TLS versions (1.0, 1.1) to TLS 1.2 or higher.
Requirement 5: Protect All Systems from Malicious Software
Requirement 5 mandates that organizations deploy anti-malware software on all systems that are commonly targeted by malware, with definitions and monitoring kept current. For systems not commonly affected by malware (such as hardened network appliances or modern Linux systems in secure configurations), periodic evaluations are required instead of continuous anti-malware software. Additionally, organizations must implement anti-phishing mechanisms to protect personnel from phishing attacks, which are the most common initial access vector for breaches.
Key sub-requirements include: deploying anti-malware software on all systems commonly targeted by malware, keeping malware definitions current through automatic updates or regular manual updates, performing periodic evaluations for systems not commonly affected by malware, monitoring all anti-malware tools and responding to alerts, implementing anti-phishing mechanisms such as email filtering and URL filtering, and training personnel to recognize phishing attacks. A common implementation challenge is ensuring coverage across all system types, including Linux systems where anti-malware software is less common but periodic vulnerability evaluations are required.
Requirement 6: Develop and Maintain Secure Systems and Software
Requirement 6 is the broadest and most complex requirement, covering secure development practices, vulnerability management, and application security. It mandates that organizations implement a secure development lifecycle (SDLC) that incorporates security at every stage: design, development, testing, and deployment. All systems and code must be tested for security vulnerabilities before deployment to production. Public-facing web applications must be protected with a Web Application Firewall (WAF). Additionally, organizations must manage software supply chain security, including third-party software, libraries, and components.
Key sub-requirements include: establishing an SDLC that integrates security, implementing secure coding practices, performing security testing (static analysis, dynamic analysis, penetration testing) before deployment, deploying WAF for public-facing web applications, managing third-party and open-source software for vulnerabilities, implementing change control processes, and protecting system components from unauthorized modification. A common implementation challenge is integrating security into fast-moving development cycles without slowing velocity, particularly in organizations practicing continuous delivery or DevOps.
Requirement 7: Restrict Access by Business Need to Know
Requirement 7 mandates that access to cardholder data and systems be limited to the minimum required for job function—the principle of least privilege. This requires that organizations assign access based on documented business need, track who has access to what, and regularly review access assignments to ensure they remain appropriate. Role-based access control (RBAC) is the preferred mechanism, with roles defined around job functions and access granted at the role level rather than to individual users.
Key sub-requirements include: restricting access to cardholder data by least privilege and business need to know, implementing role-based access control, documenting access assignments and business justification, restricting access to PCI DSS requirements and assessment tools to authorized personnel, requiring management approval for all access, restricting physical access to the CDE, and implementing access control mechanisms including user IDs, passwords, and multi-factor authentication. A common implementation challenge is access creep—over time, users accumulate access rights as they change roles but old access is never removed—requiring regular access reviews and removal of unnecessary permissions.
Requirement 8: Identify Users and Authenticate Access
Requirement 8 mandates that all users have unique IDs for authentication to system components in the CDE. Users must be uniquely identified so that their actions in logs can be traced to a specific individual. Multi-factor authentication (MFA) is required for all access into the CDE (both local and remote) and for all non-console administrative access to system components. Additionally, organizations must implement a password policy requiring a minimum of 12 characters, complexity requirements, and procedures for managing service accounts (accounts used by applications or services rather than individuals).
Key sub-requirements include: assigning unique user IDs to all individuals accessing the CDE, implementing MFA for all CDE access and non-console administrative access, establishing a password policy with 12-character minimum, complexity requirements, and change frequency, preventing reuse of previous passwords, implementing MFA at the application level or network level, managing service accounts with strong credentials and restricted permissions, and implementing MFA for all administrative access to systems in the CDE. A common implementation challenge is MFA coverage gaps, particularly in legacy systems or application-level administrative access that often lack built-in MFA support.
Requirement 9: Restrict Physical Access to Cardholder Data
Requirement 9 mandates that physical access to the CDE and cardholder data be restricted to authorized personnel. This includes controlling access to facilities housing servers or network equipment, managing visitor access, controlling removable media and the storage of sensitive data, and implementing controls for point-of-interaction (POI) devices such as ATMs and payment terminals. Organizations must maintain logs of physical access, securely dispose of media containing cardholder data, and implement anti-skimming controls on payment card acceptance devices.
Key sub-requirements include: restricting physical access to the CDE through badge systems, visitor logs, and security measures, maintaining an up-to-date inventory of POI devices, managing removable media securely, maintaining secure disposal procedures for media containing cardholder data, restricting access to backup media, preventing unauthorized skimming of card data, and implementing monitoring systems for physical access. A common implementation challenge is distributed physical locations—for organizations with multiple offices, retail locations, or data centers, implementing consistent physical access controls and monitoring across all locations is complex.
Requirement 10: Log and Monitor All Access
Requirement 10 mandates that all access to systems, networks, and cardholder data be logged, with logs retained for a minimum of one year and made immediately available for at least three months. The standard specifies which events must be logged: user access, administrative actions, access to audit logs, invalid access attempts, use of identification and authentication mechanisms, and attempts to access or modify audit logs. Logs must be protected from unauthorized modification—they must be tamper-evident and immutable, typically through write-once storage or cryptographic protection.
Key sub-requirements include: logging all access to systems containing cardholder data, logging administrative and privileged activities, logging access to cardholder data, protecting logs from modification or deletion, retaining logs for at least 12 months with at least three months immediately available, regularly reviewing logs for suspicious activities, synchronizing system clocks for accurate logging, and using centralized log management. A common implementation challenge is log volume management—CDE systems generate enormous quantities of logs, making real-time or daily review by humans infeasible, necessitating automated analysis, alerting, and SIEM (Security Information and Event Management) systems.
Requirement 11: Test Security of Systems and Networks Regularly
Requirement 11 mandates that organizations perform regular vulnerability assessments and penetration testing to identify and remediate security weaknesses before attackers can exploit them. This includes internal vulnerability scans at least quarterly, external vulnerability scans by an Approved Scanning Vendor (ASV) at least quarterly, annual penetration testing by qualified personnel, regular testing of network segmentation, and testing of wireless access points for rogue or unsecured devices.
Key sub-requirements include: performing internal vulnerability scans at least quarterly and after any significant change to systems, performing external vulnerability scans by ASV at least quarterly, conducting annual penetration testing covering network and application layers, testing segmentation controls and documenting results, testing for default credentials and unnecessary services, and maintaining a remediation process for identified vulnerabilities. A common implementation challenge is coordinating ASV scanning and remediation cycles, and determining what constitutes a significant change that requires immediate post-change scanning.
Requirement 12: Maintain an Information Security Policy and Program
Requirement 12 is the governance foundation of PCI DSS, requiring that organizations establish comprehensive information security policies, perform risk assessments, provide security awareness training, implement vendor management procedures, and maintain an incident response plan. A key v4.0 addition is the Targeted Risk Analysis (TRA), which requires organizations to assess specific risks and document the rationale for control frequency and implementation decisions. Additionally, organizations must define clear security accountability and responsibility throughout the organization.
Key sub-requirements include: establishing an information security policy, performing regular risk assessments, conducting annual TRA for 13 specific sub-requirements, providing security awareness training to all personnel, maintaining a vendor management program, implementing incident response planning, conducting regular reviews of security policies and personnel, documenting management approval and authorization, and establishing security incident reporting and response procedures. A common implementation challenge is keeping policies current and maintaining evidence of staff training and management review, particularly in organizations with high staff turnover or distributed teams.
v4.0 Changes That Matter Most
PCI DSS v4.0 introduced several significant changes that affected requirements across all 12 areas. The Customized Approach (discussed in Requirement 2 and throughout) allows alternative controls. Expanded MFA requirements now cover all CDE access, not just remote access. JavaScript management (Requirement 6.4.3) requires inventory and integrity verification of all scripts on payment pages. Password requirements increased to 12 characters minimum. The Targeted Risk Analysis requirement adds formal risk documentation to multiple sub-requirements. Anti-phishing controls (Requirement 5.4.1) explicitly address personnel protection.
| In our experience working with Indonesian payment organizations, the three most commonly missed v4.0 requirements are 6.4.3 (JavaScript inventory on payment pages), 8.4.2 (MFA for all CDE access), and 12.3.2 (Targeted Risk Analysis documentation). These three are worth prioritizing in any gap assessment, as they are both high-impact and frequently underestimated in implementation effort. |