What are the 12 requirements of PCI DSS 4.0 Compliance?

The 12 requirements of PCI DSS 4 compliance are:

Requirement 1: Install and Maintain Network Security Controls

This requirement focuses on implementing robust network security controls to protect the cardholder data environment (CDE) from unauthorized access and compromise.

Key aspects include:

  • Defined Processes: Organizations must have formal, documented processes for approving, testing, implementing, and maintaining network security controls like firewalls, intrusion detection/prevention systems (IDS/IPS), web application firewalls (WAFs), routers, and other network devices. Clear roles and responsibilities should be assigned for these processes.
  • Network Security Control Configuration: All network security controls must be properly configured to restrict traffic and provide adequate logging and monitoring capabilities. This includes firewall rulesets to filter traffic based on IP addresses, ports, protocols, and maintaining secure configuration standards for other controls.
  • Cardholder Data Environment Access Restrictions: Access to and from the CDE must be tightly controlled and restricted only to authorized sources and destinations. Inbound internet traffic should be limited to only the ports and services required for business operations.
  • Network Segmentation: The CDE must be isolated from other networks via proper network segmentation controls like firewalls, ACLs, and VLANs. This reduces the scope of the CDE and protects it from unauthorized access from other network zones.
  • Secure Remote Access: If remote access to the CDE is allowed, it must be secured using multi-factor authentication, encrypted connections, and other strong access control mechanisms to prevent exploitation.
  • Untrusted Network Risks: Risks from computing devices that can connect to both untrusted networks like the internet and the CDE must be identified and mitigated through appropriate security controls like personal firewalls, IPS/IDS, and malware protection.
  • Wireless Security: If wireless technologies are used, they must be secured through changing defaults, using strong encryption, authentication mechanisms, and limiting connectivity into the CDE.

Overall, this requirement mandates a secure network architecture and environment for the CDE through documented processes, proper configurations, access restrictions, segmentation, secure remote access, and risk mitigation controls.

Requirement 2: Apply Secure Configurations to All System Components

This requirement ensures that all system components (servers, workstations, wireless devices, etc.) within the CDE have secure configuration standards applied from initial deployment through their lifecycle. Key points include:

  • Secure Configuration Processes: Organizations must define and implement processes for hardening all system components per secure configuration standards before being deployed into the CDE. This includes processes for managing changes to configurations.
  • Vendor-Supplied Defaults: All vendor-supplied default settings like passwords, open ports, test accounts, and sample data must be changed, disabled or removed before deploying systems into production. Secure configuration baselines should replace defaults.
  • Configuration Standards: Comprehensive secure configuration standards must be developed covering areas like system hardening, file integrity monitoring, implementing only required services/protocols, security logging, and vulnerability management.
  • Change Control: Any changes to system configurations must follow strict change control processes to ensure they do not introduce new vulnerabilities or weaken existing security controls.
  • Roles and Responsibilities: Clear roles and responsibilities must be assigned for all activities related to defining, implementing, and managing secure system configurations across the CDE.
  • The intent is to ensure systems are hardened from initial deployment and their configurations are securely maintained on an ongoing basis through formal processes to reduce the attack surface.

Requirement 3: Protect Stored Account Data

This requirement focuses on protecting any stored account data like Primary Account Numbers (PAN) through rendering it unreadable, strictly limiting storage amounts/locations and implementing robust key management processes. Key aspects include:

  • Data Storage Limits: Only the minimum amount of cardholder data required for business, legal or regulatory needs should be stored. Any other unnecessary stored data must be securely rendered irretrievable.
  • Rendering Data Unreadable: Any stored PAN must be rendered unreadable either through one-way non-reversible hashes (using a PCI-approved algorithm) or strong cryptography using approved algorithms like AES-256 or higher.
  • Key Management: For any disk-level or file-level encryption of PANs, there must be robust cryptographic key management techniques covering all stages of the key lifecycle – generation, distribution, storage, termination, and documentation.
  • Truncation/Masking: Any display of PAN must mask it, showing only portions like the first 6 and last 4 digits. The remaining digits must be rendered unreadable.
  • Removable Media Controls: If PAN needs to be stored on removable or backup media, it must be encrypted with associated key management controls.

The objective is to minimize the storage of sensitive authentication data, strictly control any required storage through encryption/masking and have mature key management practices.

Requirement 4: Encrypt Transmission of Cardholder Data Across Open, Public Networks

This requirement mandates the use of strong cryptography and security protocols to safeguard all transmission of cardholder data across open, public networks like the internet. Key points include:

  • Transmission Encryption: Cardholder data must be encrypted during transmission using strong cryptography and security protocols like TLS 1.2 or higher, SSH, IPsec VPN or other PCI-approved encryption mechanisms.
  • Encryption Strength: Only trusted keys and certificates from approved providers should be used. Weak encryption like SSL, early TLS versions, anonymous connections must not be used.
  • Sending Unencrypted PANs: Sending unencrypted PANs by end-user messaging technologies like email, chat, instant messaging is prohibited. Proper transmission encryption mechanisms must be used.
  • Reviewing Protocols/Ciphers: Documented policies must exist for reviewing crypto protocols, ciphers and associated configurations at least annually and after any breach or new vulnerability is identified.

The intent is to ensure any cardholder data traversing public networks is secured through robust encryption mechanisms to prevent interception and compromise during transmission.

Requirement 5: Protect All Systems and Networks from Malicious Software

This requirement focuses on implementing robust anti-malware controls to protect systems in the CDE from malicious software that could lead to a compromise of cardholder data. Key aspects include:

  • Anti-Malware Deployment: All system components in the CDE must have anti-malware solutions deployed that are capable of detecting, preventing and removing malicious code like viruses, worms, trojans etc.
  • Continuous Monitoring: Anti-malware solutions must perform periodic scans of systems at least weekly and provide continuous monitoring and real-time protection capabilities.
  • Signature Updates: All anti-malware mechanisms must be kept up-to-date with the latest signature definitions and engine updates to ensure protection against the latest malware threats.
  • Removable Media Scanning: Any removable media or mobile devices that are allowed to connect to the CDE must be scanned for malware before connection.
  • Security Awareness: Personnel must be made aware of malware risks and trained on policies/procedures for protecting systems against malware.

The goal is to have layered anti-malware defenses to prevent, detect and remediate malware threats that could potentially impact the security of the CDE.

Requirement 6: Develop and Maintain Secure Systems and Applications

This requirement covers processes for ensuring that all system components and software applications within the CDE are secure, both during development/acquisition and through their lifecycle. Key points include:Secure Development: If developing applications in-house, organizations must follow secure software development practices like code reviews, secure coding techniques, vulnerability testing etc.Vendor Security Assurance: For commercial or outsourced software, organizations must have processes to ensure software vendors maintain secure development practices and provide assurance that their products do not contain vulnerabilities.Software Inventory: A current inventory of all system components and software within the CDE scope must be maintained.Change Control: Any changes to system components must follow strict change control processes to ensure they do not introduce new vulnerabilities.Vulnerability Management: Processes must exist for identifying newly discovered security vulnerabilities and assigning risk ratings based on impact to the environment. Identified high-risk vulnerabilities must be resolved.The intent is to ensure that all software and system components are secured through their entire lifecycle – from design/acquisition to implementation, maintenance and retirement.123567

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

This requirement focuses on implementing the principle of least privilege for access to the CDE and cardholder data. Only those individuals whose job roles require access should be granted it. Key aspects include:

  • Access Control Policy: There must be a formal policy defining access control standards for granting, revoking and reviewing access to the CDE and cardholder data.
  • Need-to-Know Access: Access privileges to the CDE must be granted based solely on the individual’s job role and their strict need-to-know for performing their duties. Privileges must be revoked immediately after their need is over.
  • Least Privilege: Users must be provided with the minimum level of access necessary to perform their job functions in order to limit potential damage from errors or malicious actions.
  • Access Approval and Review: All access must be formally approved and set up with an expiry date. Access lists must be reviewed quarterly to ensure appropriateness.

The goal is to limit the potential for data exposure and compromise by restricting access to the minimum necessary based on strict business need-to-know.

Requirement 8: Identify and Authenticate Access to System Components

This requirement covers the use of robust identification and authentication mechanisms for users accessing systems and components within the CDE.

Key aspects include:

  • User Identification: All users must be assigned a unique ID for identifying and tracking their activities on systems within the CDE.
  • Authentication Methods: Strong authentication controls like multi-factor authentication, minimum password requirements, password expiry policies etc. must be implemented.
  • Authentication Policy: There must be a formal policy defining authentication requirements, covering areas like password complexity, failed login attempt handling, idle session termination etc.
  • Physical Security: Any physical access to systems in the CDE must also require robust authentication mechanisms like biometrics or badge access.

The objective is to ensure that only legitimate users can access CDE resources through the use of robust identification and authentication mechanisms.

Requirement 9: Restrict Physical Access to Cardholder Data

This requirement covers physical security controls to protect systems that store, process or transmit cardholder data. Key points include:

  • Physical Access Controls: Appropriate entry controls like video cameras, access control mechanisms etc. must be in place to allow only authorized individuals into areas housing CDE systems.
  • Physical Media Security: Strict controls must govern the secure storage, transportation and distribution of any physical media containing cardholder data.
  • Physical Logs: All physical access to cardholder data or systems in the CDE must be logged, and these logs must be reviewed periodically.
  • Visitor Controls: Strict controls like visitor logs, escorts, credentials etc. must be implemented to manage any visitors to areas housing CDE systems.

The goal is to prevent unauthorized physical access that could lead to a data compromise through robust physical security controls.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

This requirement focuses on implementing logging mechanisms to reconstruct events related to the CDE and monitoring those logs for identification of potential issues. Key aspects include:

  • Audit Logs: Audit logs must be enabled on all system components to track all individual accesses to cardholder data.
  • Logging Configuration: Logging must be enabled for all system components, capturing details like user ID, date/time, event data etc.
  • Log Management: There must be processes for monitoring all logs related to the CDE at least daily. Logs must be secured and retained as per policy.
  • Log Reviews: Logs of all system components must be reviewed daily, either manually or via log monitoring/management tools to identify any issues.

The goal is to have robust audit trails of all activities involving the CDE to permit timely identification and triage of issues.

Requirement 11: Test Security Systems and Processes Regularly

This requirement mandates frequent testing and auditing of implemented security systems and processes to ensure their effectiveness in protecting the CDE. Key points include:

  • Testing Processes: Formal processes must exist for regularly testing the effectiveness of security controls like firewalls, IDS/IPS, file integrity monitoring etc.
  • Vulnerability Scans: External and internal vulnerability scans must be performed quarterly and after any significant change, to identify any new vulnerabilities.
  • Penetration Testing: External and internal penetration tests must be performed annually and after any significant infrastructure or application upgrade/modification.
  • Test Coverage: Testing must cover the entire CDE perimeter and critical systems to confirm proper segmentation between trusted and untrusted networks. The goal is to implement robust security testing processes to continuously validate the effectiveness of security controls in the CDE.

Requirement 12: Maintain an Information Security Policy

This requirement ties together the previous 11 requirements into a formal security policy and associated program. Key aspects include:

  • Information Security Policy: There must be a formal, overarching information security policy that is reviewed at least annually and disseminated to all relevant personnel.
  • Risk Assessment: An annual risk assessment must be performed that identifies threats, vulnerabilities and results in a formal risk mitigation strategy.
  • Usage Policies: There must be defined operational policies covering areas like security awareness, acceptable use, incident response etc.
  • Roles and Responsibilities: Clear roles and responsibilities for all personnel involved in CDE security must be defined and documented.
  • The intent is to have an overarching security program with executive support, driven by policies and formalized risk management processes.

These 12 requirements, when implemented robustly per the PCI DSS guidelines, are designed to provide a secure environment for protecting cardholder data and mitigating the associated risks.

PCI DSS 4.0 Compliance FAQs Answered

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top