Appendix A3 of PCI DSS v4.0 provides additional validation requirements for designated entities with complex environments, including supplementary controls and documentation to ensure comprehensive compliance and data protection tailored to specific organizational needs.

• Establishment of Responsibility for Account Data Protection and a PCI DSS Compliance Program (A3.1.1)

  Responsibility for protecting account data and managing PCI DSS compliance must be established and assigned.

• Formal PCI DSS Compliance Program in place (A3.1.2)

  A formal PCI DSS compliance program must be in place to manage and ensure ongoing compliance.

• Specifically Defined and Formally Assigned PCI DSS Compliance Roles and Responsibilities (A3.1.3)

  Roles and responsibilities for PCI DSS compliance must be specifically defined and formally assigned.

• PCI DSS and/or Information Security Training Provided to Personnel with PCI DSS Compliance Responsibilities (A3.1.4)

  Personnel with PCI DSS compliance responsibilities must receive appropriate PCI DSS and/or information security training.

• The PCI DSS scope must be documented and validated (A3.1.5)

  Subcontrol A3.1.5 requires that organizations document and validate the scope of their PCI DSS environment. This involves clearly identifying and documenting all system components, processes, and people involved in handling cardholder data. The validation process ensures that all relevant elements within the defined scope are accurately included in the PCI DSS assessment, thereby ensuring comprehensive coverage and protection.

• Frequent PCI DSS Scope Validation (A3.2.1)

  PCI DSS scope must be validated frequently to ensure it accurately reflects the organization's environment.

• Determination of PCI DSS Scope Impact for All Changes to Systems or Networks (A3.2.2)

  The impact of changes to systems or networks on PCI DSS scope must be determined.

• Methodology Implementation for Prompt Identification of Attack Patterns (A3.5.1)

  A methodology must be implemented to promptly identify attack patterns.

• PCI DSS Requirements Implementation on New or Changed Systems and Networks (A3.2.2.1)

  PCI DSS requirements must be implemented on new or changed systems and networks.

• Formal (Internal) Review of the Impact to PCI DSS Scope and Applicability of Controls (A3.2.3)

  A formal internal review must be conducted to assess the impact on PCI DSS scope and control applicability.

• PCI DSS Scope Confirmation if Segmentation is Used (A3.2.4)

  PCI DSS scope must be confirmed when segmentation is used to ensure proper control boundaries.

• Data-discovery Methodology Implementation (A3.2.5)

  A methodology for discovering data must be implemented to identify sensitive information within the organization.

• Data Discovery Methods Confirmation (A3.2.5.1)

  Methods used for data discovery must be confirmed to ensure they are effective and accurate.

• Implementation of Response Procedures Initiated Upon Detection of Cleartext PAN Outside the CDE (A3.2.5.2)

  Response procedures must be implemented to address the detection of cleartext PAN outside the Cardholder Data Environment (CDE).

• Mechanisms Implementation for Detecting and Preventing Cleartext PAN from Leaving the CDE (A3.2.6)

  Mechanisms must be implemented to detect and prevent cleartext PAN from leaving the Cardholder Data Environment (CDE).

• Implementation of Response Procedures Initiated upon Detection of Attempts to Remove Cleartext PAN from the CDE (A3.2.6.1)

  Response procedures must be implemented to address attempts to remove cleartext PAN from the Cardholder Data Environment (CDE).

• Implement and maintain processes to detect, alert, and respond to failures of critical security control systems (A3.2.6.1)

  Subcontrol A3.2.6.1 mandates that organizations implement and maintain processes to detect, alert, and respond to failures in critical security control systems. This ensures that any issues or malfunctions in security controls are identified promptly, with appropriate alerts generated to notify relevant personnel. Additionally, processes must be in place to address and remediate these failures to maintain the integrity and effectiveness of the security controls.

• Processes for Responding to Failures in Security Control Systems (A3.3.1.2)

  Processes must be in place to respond to failures in security control systems.

• Hardware and Software Technologies Periodic Review (A3.3.2)

  Hardware and software technologies must be reviewed periodically to ensure their effectiveness.

• Regular Reviews Performed to Verify BAU Activities are being Followed (A3.3.3)

  Regular reviews must be performed to ensure Business-As-Usual (BAU) activities are being followed.

• Regular Reviews Performed to Verify BAU Activities are being Followed (A3.3.3)

  Regular reviews must be performed to ensure Business-As-Usual (BAU) activities are being followed.

• Regular Review of User Accounts and Access Privileges to In-scope System Components (A3.4.1)

  User accounts and access privileges to in-scope system components must be reviewed regularly.

Appendix A2 of PCI DSS v4.0 outlines additional requirements for entities using SSL or early TLS in card-present POS environments, including transitioning to stronger protocols and ensuring secure configurations to protect cardholder data during transactions.

• POS POI Terminals at the Merchant or Payment Acceptance Location that Use SSL and/or Early TLS (A2.1.1)

  POS Point of Interaction (POI) terminals at the merchant or payment acceptance location that use SSL or early TLS must comply with PCI DSS requirements.

• Service Providers with Existing Connection Points to POS POI Terminals that Use SSL and/or early TLS (A2.1.2)

  Service providers with existing connections to POS POI terminals using SSL or early TLS must ensure compliance with PCI DSS.

• Service Providers Secure Service Offering (A2.1.3)

  Service providers must offer secure services that comply with PCI DSS requirements for SSL and early TLS usage.

PCI DSS v4.0 Requirement 1 mandates organizations to implement and maintain network security controls, such as firewalls and routers, to protect cardholder data by controlling inbound and outbound network traffic, ensuring secure configurations, and minimizing exposure to potential threats.

• Management of Security Policies and Operational Procedures Identified in Requirement 1 (1.1.1)

  The subcontrol 1.1.1 under PCI DSS v4.0 Requirement 1 focuses on ensuring that security policies and operational procedures governing the management of network security controls are documented, regularly reviewed, and updated to reflect changes in the network environment. This ensures that all relevant personnel are informed about and adhere to these policies and procedures to maintain a robust security posture.

• Security Controls Implementation on Computing Devices (1.5.1)

  Subcontrol 1.5.1 requires organizations to implement security controls on computing devices to protect them from threats and vulnerabilities. This involves ensuring that appropriate security measures are in place to safeguard computing devices, such as servers, workstations, and other endpoints, which are critical to the security of the Cardholder Data Environment (CDE).

• Disclosure of Internal IP Addresses and Routing Information Limitation (1.4.5)

  Subcontrol 1.4.5 requires organizations to limit the disclosure of internal IP addresses and routing information. This measure aims to prevent unauthorized parties from gaining insight into the internal network structure, which could be exploited to facilitate attacks or unauthorized access.

• Cardholder Data Accessibility from Untrusted Networks (1.4.4)

  Subcontrol 1.4.4 requires organizations to ensure that cardholder data is not accessible from untrusted networks. This means implementing controls to prevent unauthorized access to sensitive payment information from external or less secure networks, thereby protecting the confidentiality and integrity of cardholder data.

• Anti-spoofing Measures Implementation (1.4.3)

  Subcontrol 1.4.3 requires organizations to implement anti-spoofing measures to prevent attackers from falsifying the origin of network traffic. Anti-spoofing measures are designed to detect and mitigate attempts to impersonate legitimate network addresses or systems, thereby enhancing the security of the network and protecting sensitive information.

• Evaluation and Restriction of Inbound Traffic from Untrusted Networks to Trusted Networks (1.4.2)

  Subcontrol 1.4.2 requires organizations to evaluate and restrict inbound traffic from untrusted networks to trusted networks. This involves assessing the sources and nature of inbound traffic from external or less secure networks and implementing controls to ensure that only authorized and necessary traffic is allowed to enter trusted networks, thereby protecting sensitive information and maintaining network security.

• NSCs Implementation Between Trusted and Untrusted Networks (1.4.1)

  Subcontrol 1.4.1 requires organizations to implement network security controls (NSCs) between trusted and untrusted networks. This ensures that there is a secure boundary separating internal trusted networks, such as those housing sensitive payment card data, from external or less secure networks, such as the internet. Properly implemented NSCs protect against unauthorized access and potential threats originating from untrusted sources.

• Documentation and Assignment of Roles and Responsibilities for Performing Activities in Requirement 1 (1.1.2)

  Subcontrol 1.1.2 under PCI DSS v4.0 Requirement 1 mandates that organizations must document and assign roles and responsibilities related to the installation, maintenance, and management of network security controls. This ensures that specific tasks are clearly defined and allocated to individuals or teams, promoting accountability and effective management of network security measures.

• Implementation of NSC Configurations Standard (1.2.1)

  Subcontrol 1.2.1 under PCI DSS v4.0 Requirement 1 mandates that organizations must implement a standardized configuration for network security controls. This includes establishing and maintaining consistent security configurations for network devices, such as firewalls, routers, and switches, to ensure a robust and uniform security posture across the network.

• NSC Configurations and Changes Approval and Management (1.2.2)

  Subcontrol 1.2.2 requires organizations to implement a formal process for approving and managing changes to network security control configurations. This ensures that any modifications to network security settings are reviewed, authorized, and documented to prevent unauthorized changes and maintain the integrity of network security measures.

• Accurate Network Diagram Maintenance (1.2.3)

  Subcontrol 1.2.3 requires organizations to maintain accurate and up-to-date network diagrams that clearly depict the network infrastructure and security controls. These diagrams are essential for understanding the network's layout, the placement of security controls, and the flow of data across the network.

• Accurate Data-flow Diagram(s) Maintenance (1.2.4)

  Subcontrol 1.2.4 requires organizations to maintain accurate and up-to-date data-flow diagrams that illustrate the flow of data through the network, including how data is transmitted, processed, and stored. These diagrams are essential for understanding and securing the flow of sensitive information, including payment card data.

• Services, Protocols, and Ports Approval and Management (1.2.5)

  Subcontrol 1.2.5 requires organizations to implement a formal process for approving and managing the services, protocols, and ports that are allowed on their network. This ensures that only necessary and secure services, protocols, and ports are enabled, reducing the potential attack surface and minimizing security risks.

• Services, Protocols, and Ports Security Implementation (1.2.6)

  Subcontrol 1.2.6 requires organizations to implement security measures for managing services, protocols, and ports to ensure they are securely configured and appropriately protected. This involves setting security configurations and restrictions to minimize potential vulnerabilities associated with services, protocols, and ports used within the network.

• Periodic Review and Examination for Configurations of NSCs (1.2.7)

  Subcontrol 1.2.7 requires organizations to perform periodic reviews and examinations of the configurations of network security controls (NSCs) to ensure that they remain secure and effective. This involves regularly assessing and validating the configuration settings of network security devices to confirm they adhere to security policies and best practices.

• Security and Consistency of Configuration files for NSCs (1.2.8)

  Subcontrol 1.2.8 requires organizations to ensure the security and consistency of configuration files for network security controls (NSCs). This involves implementing measures to protect configuration files from unauthorized access and modification while ensuring that configurations are consistently applied across all network security devices.

• Evaluation and Restriction of Inbound Traffic to the CDE (1.3.1)

  Subcontrol 1.3.1 requires organizations to evaluate and restrict inbound traffic to the Cardholder Data Environment (CDE). This involves assessing the sources of inbound traffic and implementing controls to ensure that only authorized and necessary traffic is allowed to enter the CDE, thus protecting sensitive payment card data from unauthorized access and potential threats.

• Evaluation and Restriction of Outbound Traffic from the CDE (1.3.2)

  Subcontrol 1.3.2 requires organizations to evaluate and restrict outbound traffic from the Cardholder Data Environment (CDE). This involves assessing the destinations of outbound traffic and implementing controls to ensure that only authorized and necessary outbound traffic is allowed, thus preventing unauthorized data exfiltration and protecting sensitive payment information.

• NSCs Installation Between Wireless Networks and the CDE (1.3.3)

  Subcontrol 1.3.3 requires organizations to install network security controls (NSCs) between wireless networks and the Cardholder Data Environment (CDE). This ensures that wireless networks are properly segregated from the CDE, preventing unauthorized access and protecting sensitive payment information from potential threats originating from wireless connections.

PCI DSS v4.0 Requirement 2 requires organizations to establish and maintain secure configurations for all system components, ensuring they are hardened against vulnerabilities by disabling unnecessary functions, services, and protocols, and regularly updating software to protect cardholder data.

• Changed Wireless Encryption Keys (2.3.2)

  Subcontrol 2.3.2 requires organizations to change wireless encryption keys whenever there is a suspected or confirmed compromise, when employees with knowledge of the keys leave the organization, or periodically as part of a regular security practice. This ensures that wireless communications remain secure by preventing unauthorized access that could result from outdated or compromised encryption keys.

• Wireless Vendor Changed Defaults at Installation or Confirmed Secure (2.3.1)

  Subcontrol 2.3.1 requires that wireless devices, when installed, have vendor-supplied defaults either changed or confirmed as secure. This includes changing default passwords, SSIDs, encryption settings, and other security-related configurations that are typically set by the manufacturer. The objective is to ensure that wireless devices do not retain default settings that could be exploited by attackers.

• Non-console Administrative Access Encryption (2.2.7)

  Subcontrol 2.2.7 requires organizations to encrypt all non-console administrative access to system components. This ensures that any administrative activities performed remotely (not physically at the console) are secured by encryption, protecting sensitive information such as usernames, passwords, and configuration data from interception and unauthorized access.

• System Security Parameters Misuse Prevention (2.2.6)

  Subcontrol 2.2.6 mandates that organizations implement measures to prevent the misuse of system security parameters. This involves ensuring that security-related settings and configurations are managed in a way that minimizes the risk of misconfiguration, unauthorized changes, or exploitation. The goal is to maintain the integrity and security of system components by safeguarding critical security parameters.

• Insecure Services, Protocols, or Daemons Examination (2.2.5)

  Subcontrol 2.2.5 requires organizations to identify and examine services, protocols, and daemons that are considered insecure. This examination involves evaluating the security risks associated with these elements and determining whether they can be disabled or replaced with more secure alternatives. If disabling or replacing is not feasible, organizations must implement compensating controls to mitigate the risks.

• Necessary Services, Protocols, Daemons, and Functions Permissions (2.2.4)

  Subcontrol 2.2.4 requires organizations to ensure that only the necessary services, protocols, daemons, and functions are enabled on system components. Any services or protocols that are not essential to the system’s function should be disabled or removed to reduce the attack surface and minimize the risk of security breaches.

• Primary Functions Security Level Requirement (2.2.3)

  Subcontrol 2.2.3 requires organizations to ensure that system components performing primary functions are secured to a level appropriate to the risk associated with those functions. This includes implementing security measures that protect these components from unauthorized access, vulnerabilities, and potential threats, thereby maintaining the integrity and availability of the systems that are critical to business operations.

• Vendor Default Accounts Management (2.2.2)

  Subcontrol 2.2.2 requires organizations to manage vendor default accounts by removing or disabling them. Vendor default accounts are pre-configured accounts created by hardware or software vendors that are often installed with default passwords and settings. These accounts can pose significant security risks if left active and are a common target for attackers seeking to exploit weak or known default credentials.

• Configuration Standards Development and Implementation (2.2.1)

  Subcontrol 2.2.1 requires organizations to develop and implement configuration standards for all system components. These standards define secure configuration settings and practices that must be applied to ensure that system components are protected against vulnerabilities and threats.

• Documentation and Assignment of Roles and Responsibilities for Performing Activities in Requirement 2 (2.1.2)

  Subcontrol 2.1.2 requires organizations to document and assign roles and responsibilities for performing activities related to applying secure configurations to all system components. This includes clearly defining and documenting who is responsible for ensuring secure configurations, monitoring compliance, and managing changes across all system components.

• Management of Security Policies and Operational Procedures Identified in Requirement 2 (2.1.1)

  Subcontrol 2.1.1 requires organizations to manage security policies and operational procedures related to applying secure configurations to all system components. This includes establishing, maintaining, and enforcing policies and procedures that ensure system components are securely configured to protect against vulnerabilities and threats.

PCI DSS v4.0 Requirement 3 mandates organizations to protect stored account data by implementing encryption, truncation, masking, and other secure storage techniques to prevent unauthorized access or disclosure of cardholder data.

• Cryptographic Architecture Documentation (3.6.1.1)

  Subcontrol 3.6.1.1 requires organizations to document their cryptographic architecture. This includes detailed documentation of how cryptographic keys are managed, used, and protected within the organization's IT environment. The documentation should cover key management processes, encryption methodologies, and the overall cryptographic framework to ensure transparency, compliance, and security.

• Procedures to Protect Cryptographic Keys (3.6.1)

  Subcontrol 3.6.1 requires that organizations establish and maintain procedures to protect cryptographic keys used for encrypting cardholder data. This includes ensuring the secure management, handling, and storage of cryptographic keys to prevent unauthorized access or compromise.

• Stored PAN Rendered Unreadable (3.5.1)

  Subcontrol 3.5.1 requires that the Primary Account Number (PAN) stored within the environment be rendered unreadable using cryptographic measures. This ensures that PANs are protected from unauthorized access by rendering the stored data unreadable without the appropriate decryption keys or processes.

• Relocation of PAN to Unauthorized Storage Devices Prevention (3.4.2)

  Subcontrol 3.4.2 requires that measures be in place to prevent the relocation of Primary Account Numbers (PANs) to unauthorized storage devices. This includes ensuring that PANs are not transferred or stored on devices or systems that are not specifically approved for storing sensitive authentication data. Implementing these measures helps to prevent unauthorized access and ensure that PANs are only stored in secure and compliant environments.

• PAN Masking and Authorized Access Requirements (3.4.1)

  Subcontrol 3.4.1 requires that the Primary Account Number (PAN) be masked when displayed, such that only a limited number of digits are visible (e.g., the first six and last four digits). Additionally, it mandates that access to the full PAN be restricted to authorized personnel only. This control aims to minimize the exposure of sensitive cardholder data and limit the risk of unauthorized access and data breaches.

• Storage of Sensitive Authentication Data Security Procedures (3.3.3)

  Subcontrol 3.3.3 mandates the implementation of security procedures for the storage of sensitive authentication data (SAD). This includes creating and maintaining security procedures that specifically address how SAD is stored, protected, and managed to ensure it is not exposed to unauthorized access or misuse. The procedures must be comprehensive and cover aspects such as access controls, encryption, and secure data handling practices.

• SAD Encryption Using Strong Cryptography (3.3.2)

  Subcontrol 3.3.2 requires that sensitive authentication data (SAD) be protected through encryption using strong cryptographic methods. This control mandates that any stored SAD, which includes card verification codes (CVCs), PINs, and other sensitive authentication information, must be encrypted to ensure its confidentiality and integrity. The encryption must be implemented using cryptographic algorithms and key management practices that meet current industry standards.

• Non-retention Upon Completion of Authorization Process Requirement for Personal Identification Number (PIN) and PIN block (3.3.1.3)

  Subcontrol 3.3.1.3 requires that personal identification numbers (PINs) and PIN blocks must not be retained after the authorization process is complete. PINs and PIN blocks, which are used to authenticate cardholder transactions, contain highly sensitive data. Therefore, they must be immediately and securely deleted or rendered unreadable after the authorization process to protect against unauthorized access and potential fraud.

• Non-retention Upon Completion of Authorization Process Requirement for Card Verification Code (3.3.1.2)

  Subcontrol 3.3.1.2 requires that card verification codes (CVCs), card validation codes (CAVCs), or any other forms of card verification data must not be retained after the authorization process is completed. This data, which includes CVV2/CVC2 values found on the card, is used to verify the cardholder's identity during a transaction but must be immediately and securely deleted or rendered unreadable once the authorization is obtained.

• Non-retention Upon Completion of Authorization Process Requirement for Full Contents of Any Track (3.3.1.1)

  Subcontrol 3.3.1.1 mandates that organizations must not retain the full contents of any magnetic stripe (track) data after the authorization process is completed. This requirement specifically targets the full magnetic stripe data read from the card during a transaction, which includes information such as the cardholder's name, account number, and other sensitive details. Once authorization is obtained, this data must be immediately and securely deleted to prevent unauthorized access and misuse.

• Non-retention After Authorization Requirement for All Sensitive Authentication Data (SAD) (3.3.1)

  Subcontrol 3.3.1 mandates that sensitive authentication data (SAD), including card verification codes (CVCs), card validation codes (CAVCs), and PINs, must not be stored after authorization. After a transaction has been authorized, this data must be immediately and securely deleted or rendered unreadable. The purpose of this requirement is to minimize the risk of unauthorized access and fraud by ensuring that sensitive authentication data is not retained beyond its necessary use.

• Non-retention After Authorization Requirement for All Sensitive Authentication Data (SAD) (3.3.1)

  Subcontrol 3.3.1 requires that sensitive authentication data (SAD), which includes card verification codes (CVCs), card validation codes (CAVCs), and other authentication data, must not be retained after authorization. Once authorization is completed, this data should be immediately and securely deleted or rendered unreadable. This control is designed to protect sensitive data from unauthorized access and mitigate the risk of data breaches.

• Implementation of Data Retention and Disposal Policies, Procedures, and Processes (3.2.1)

  Subcontrol 3.2.1 requires organizations to implement comprehensive data retention and disposal policies, procedures, and processes to ensure that stored account data is only retained for as long as necessary and securely disposed of when no longer needed. This control aims to minimize the risk of unauthorized access to sensitive data by reducing the amount of stored data and ensuring that it is securely handled throughout its lifecycle.

• Documentation and Assignment of Roles and Responsibilities for Performing Activities in Requirement 3 (3.1.2)

  Subcontrol 3.1.2 requires organizations to document and assign clear roles and responsibilities for all activities related to the protection of stored account data. This involves identifying the personnel responsible for specific tasks, ensuring they have the necessary skills and training, and formally documenting these assignments. The goal is to establish accountability and clarity in the management of stored account data, reducing the risk of data breaches and non-compliance.

• Management of Security Policies and Operational Procedures Identified in Requirement 3 (3.1.1)

  Subcontrol 3.1.1 focuses on the development, implementation, and management of security policies and operational procedures that address the protection of stored account data. This includes ensuring that policies and procedures are clearly defined, documented, communicated to relevant personnel, and consistently followed. The goal is to establish a robust framework for protecting stored account data from unauthorized access, disclosure, and misuse.

• Cryptographic Key Changes (3.7.4)

  Subcontrol 3.7.4 requires that organizations have procedures in place for managing changes to cryptographic keys, including key rotation, re-keying, and updates. This ensures that cryptographic keys are kept secure and effective over time, mitigating the risk of key compromise.

• Retirement, Replacement, or Destruction of Keys (3.7.5)

  Subcontrol 3.7.5 requires organizations to have procedures in place for the retirement, replacement, and destruction of cryptographic keys. This ensures that outdated or compromised keys are securely managed and removed to prevent unauthorized access to sensitive data.

• Cleartext Cryptographic Key-management Operations (3.7.6)

  Subcontrol 3.7.6 requires that cryptographic key-management operations, such as key generation, storage, and distribution, are not performed in cleartext. This means that all key-management operations must be conducted using secure methods to prevent unauthorized access to key material.

• Prevention of Unauthorized Substitution of Cryptographic Keys (3.7.7)

  Subcontrol 3.7.7 mandates that organizations implement measures to prevent unauthorized substitution of cryptographic keys. This ensures that cryptographic keys used for encrypting and decrypting sensitive data are not replaced or altered by unauthorized individuals, thereby protecting the integrity of encrypted data.

• Cryptographic Key custodians' Formal Acknowledgement (3.7.8)

  Subcontrol 3.7.8 requires that individuals designated as custodians of cryptographic keys formally acknowledge their responsibilities. This formal acknowledgment ensures that key custodians understand their roles, the importance of safeguarding cryptographic keys, and the associated security and compliance requirements.

• Guidance on Secure Transmission, Storage, and Cryptographic Keys Update (3.7.9)

  Subcontrol 3.7.9 provides guidance on the secure transmission, storage, and updating of cryptographic keys. This guidance ensures that cryptographic keys used to protect stored account data are handled in a manner that maintains their security and integrity throughout their lifecycle.

• Disk-level and Partition-level Encryption (3.5.1.2)

  Subcontrol 3.5.1.2 requires that encryption be applied at both the disk level and partition level to protect stored account data. This ensures that data is encrypted as it resides on physical disks or partitions, making it unreadable to unauthorized users who may gain access to the storage media. Disk-level and partition-level encryption helps safeguard cardholder data by ensuring its confidentiality even if physical devices are compromised.

• Disk-level and Partition-level Encryption Management (3.5.1.3)

  Subcontrol 3.5.1.3 requires the effective management of disk-level and partition-level encryption to ensure that encryption mechanisms are properly configured, maintained, and monitored. This includes managing the encryption solutions, ensuring compliance with encryption policies, and handling encryption key management to protect stored account data effectively.

• Keyed Cryptographic Hashes Processes and Procedures (3.5.1.1)

  Subcontrol 3.5.1.1 focuses on the use of keyed cryptographic hashes to secure stored cardholder data. Specifically, it requires that processes and procedures for using keyed cryptographic hashes are in place to ensure that such hashes are used appropriately to protect stored account data. Keyed cryptographic hashes, such as HMAC (Hash-based Message Authentication Code), are used to verify the integrity and authenticity of data by applying a secret key to the hashing process.

• Secure Distribution of Cryptographic Keys (3.7.2)

  Subcontrol 3.7.2 mandates that cryptographic keys must be distributed securely to prevent unauthorized access during the distribution process. This involves using secure methods and protocols to ensure that keys are protected from interception or tampering while being transmitted from one location to another.

• Cryptographic Keys Secure Storage (3.6.1.2)

  Subcontrol 3.6.1.2 mandates that cryptographic keys used for encrypting cardholder data must be stored securely to prevent unauthorized access and ensure their protection throughout their lifecycle. Secure storage involves using robust mechanisms and controls to protect keys from exposure, tampering, or theft.

• Secure Storage of Cryptographic Keys (3.7.3)

  Subcontrol 3.7.3 requires that cryptographic keys be stored securely to protect them from unauthorized access and tampering. Secure storage practices ensure that keys are kept in a protected environment where they are safeguarded against physical and logical threats.

• Access to Cleartext Cryptographic Key Components Restriction (3.6.1.3)

  Subcontrol 3.6.1.3 mandates that access to cleartext cryptographic key components (keys that are not encrypted or obscured) must be strictly restricted. This restriction ensures that cleartext key components are protected from unauthorized access, thereby safeguarding the encryption keys and maintaining the overall security of cardholder data.

• Cryptographic Keys Storage Locations (3.6.1.4)

  Subcontrol 3.6.1.4 requires organizations to establish and maintain secure locations for storing cryptographic keys. These storage locations must be protected against unauthorized access and physical or logical attacks to ensure the integrity and confidentiality of the keys.

• Generation of Strong Cryptographic Keys (3.7.1)

  Subcontrol 3.7.1 requires that cryptographic keys used for protecting cardholder data are generated using strong cryptographic algorithms and methods. This ensures that the keys are robust and resistant to attacks, thereby enhancing the security of encrypted data.

PCI DSS v4.0 Requirement 4 requires organizations to protect cardholder data during transmission over open, public networks by using strong cryptography and security protocols, such as TLS, to prevent interception, tampering, or unauthorized access.

• Entity’s Trusted Keys and Certificates Maintenance (4.2.1.1)

  Subcontrol 4.2.1.1 addresses the maintenance of trusted keys and certificates used for protecting cardholder data during transmission over open, public networks. This involves ensuring that cryptographic keys and certificates are properly managed, including their issuance, renewal, and revocation, to maintain the security and integrity of encrypted communications.

• Wireless Networks Cryptography Implementation (4.2.1.2)

  Ensure that strong cryptography is used to protect cardholder data transmitted over wireless networks.

• PAN Security with Messaging Technologies (4.2.2)

  Ensure that PAN (Primary Account Number) is protected during transmission through messaging technologies using strong cryptographic methods.

• Strong Cryptography and Security Protocols Implementation (4.2.1)

  Subcontrol 4.2.1 focuses on the implementation of strong cryptographic methods and security protocols to protect cardholder data during transmission over open, public networks. This subcontrol mandates the use of cryptographic techniques and protocols that are robust and compliant with current industry standards to ensure the confidentiality and integrity of data in transit.

• Documentation and Assignment of Roles and Responsibilities for Performing Activities in Requirement 4 (4.1.2)

  Subcontrol 4.1.2 focuses on documenting and assigning specific roles and responsibilities related to the protection of cardholder data during transmission over open, public networks. This subcontrol ensures that roles are clearly defined and documented, and that personnel are aware of their responsibilities in maintaining the security of data transmission.

• Management of Security Policies and Operational Procedures Identified in Requirement 4 (4.1.1)

  Subcontrol 4.1.1 involves the management of security policies and operational procedures specific to protecting cardholder data during transmission over open, public networks. This includes ensuring that appropriate policies and procedures are in place and are actively managed to enforce the use of strong cryptography to safeguard cardholder data.

PCI DSS v4.0 Requirement 5 requires organizations to protect all systems and networks from malicious software by implementing anti-virus, anti-malware, and other threat detection tools, regularly updating them, and conducting periodic scans to detect and prevent malware infections.

• Protection against Phishing Attacks (5.4.1)

  Implement measures to protect against phishing attacks targeting systems and users.

• Anti-malware Solution(s) for Removable Electronic Media (5.3.3)

  Deploy anti-malware solutions for removable electronic media to prevent malware infections.

• Audit Logs for Anti-malware solution(s) Enabled and Retained (5.3.4)

  Enable and retain audit logs for anti-malware solutions to track and review malware-related activities.

• Anti-malware Mechanisms Modification and Configuration Management (5.3.5)

  Manage changes to anti-malware mechanisms and their configurations to ensure continued effectiveness.

• Performed Evaluations of System Components Defined in the Entity’s Targeted Risk Analysis (5.2.3.1)

  Conduct evaluations of system components as defined in the organization’s targeted risk analysis.

• Current Anti-malware Solution(s) Via Automatic Updates (5.3.1)

  Ensure anti-malware solutions are kept current through automatic updates.

• Periodic Scans or Systems Behavioral Analysis as Anti-malware Solution(s) (5.3.2)

  Perform periodic scans or behavioral analysis to detect malware and malicious activity.

• Determination of Optimum Period to Undertake Periodic Scans Based on Own Assessment (5.3.2.1)

  Determine the optimal frequency for periodic scans based on your own risk assessment and security needs.

• Management of Security Policies and Operational Procedures Identified in Requirement 5 (5.1.1)

  Develop, document, and manage security policies and operational procedures to protect systems and networks from malicious software.

• Documentation and Assignment of Roles and Responsibilities for Performing Activities in Requirement 5 (5.1.2)

  Document and assign roles and responsibilities for managing and executing activities related to protecting systems and networks from malicious software.

• Anti-malware Solution(s) Deployment on All System Components (5.2.1)

  Deploy anti-malware solutions on all system components to protect against malicious software.

• Protection Against All Known Types and Forms of Malware (5.2.2)

  Ensure protection against all known types and forms of malware, including viruses, worms, and ransomware.

• System Components Periodic Evaluation (5.2.3)

  Periodically evaluate system components for effectiveness in malware protection.

PCI DSS v4.0 Requirement 6 mandates organizations to develop and maintain secure systems and software by implementing secure coding practices, applying patches promptly, and regularly testing for vulnerabilities to protect against security threats.

• Bespoke and Custom Software Secure Development (6.2.1)

  Ensure secure development practices for bespoke and custom software.

• Software Development Personnel Training (6.2.2)

  Train software development personnel on secure coding and development practices.

• Bespoke and Custom Software Review Process (6.2.3)

  Implement a review process for bespoke and custom software to ensure security.

• Standard Procedure for Manual Code Review (6.2.3.1)

  Establish and follow a standard procedure for manual code review.

• Software Engineering Techniques for Prevention or Mitigation of Common Software Attacks and Related Vulnerabilities (6.2.4)

  Apply software engineering techniques to prevent or mitigate common software attacks and vulnerabilities.

• Identification and Management of Security Vulnerabilities (6.3.1)

  Identify and manage security vulnerabilities in systems and software.

• Maintenance of Inventory of Bespoke and Custom Software, and Third-party Software Components Incorporated into Bespoke and Custom Software (6.3.2)

  Maintain an inventory of bespoke and custom software and third-party components used.

• Required Installation of Applicable Security Patches and Updates (6.3.3)

  Install applicable security patches and updates in a timely manner.

• Applications Protection Against Known Attacks (6.4.1)

  Protect applications against known attacks by implementing appropriate security measures.

• Deployment of Automated Technical Solution for Continuous Detection and Prevention of Web-based Attacks (6.4.2)

  Deploy automated solutions for continuous detection and prevention of web-based attacks.

• Management of All Payment Page Scripts Loaded and Executed in the Consumer’s Browser (6.4.3)

  Manage payment page scripts to ensure security and integrity in the consumer’s browser.

• Changes to System Components in the Production Environment According to Established Procedures (6.5.1)

  Ensure changes to system components in the production environment follow established procedures.

• Applicable PCI DSS Requirements on All New or Changed Systems and Networks (6.5.2)

  Ensure all new or changed systems and networks comply with applicable PCI DSS requirements.

• Pre-production Environments Separation from Production Environments (6.5.3)

  Maintain separation between pre-production and production environments.

• Separated Roles and Functions Between Production and Pre-production Environments (6.5.4)

  Ensure separate roles and functions for production and pre-production environments.

• Non-availability of Live PANs in Pre-production Environments (6.5.5)

  Ensure that live PANs are not available in pre-production environments.

• Test Data and Test Accounts Removal from System Components Before System Production (6.5.6)

  Remove test data and accounts from system components before production.

• Management of Security Policies and Operational Procedures Identified in Requirement 6 (6.1.1)

  Develop, document, and manage security policies and operational procedures for secure system and software development.

• Documentation and Assignment of Roles and Responsibilities for Performing Activities in Requirement 6 (6.1.2)

  Document and assign roles and responsibilities for secure systems and software development activities.

PCI DSS v4.0 Requirement 7 requires organizations to restrict access to system components and cardholder data based on business need-to-know, ensuring that only authorized personnel have access to sensitive information, minimizing the risk of unauthorized access.

• Management of Security Policies and Operational Procedures Identified in Requirement 7 (7.1.1)

  Develop, document, and manage security policies and operational procedures for access control based on business need to know.

• Documentation and Assignment of Roles and Responsibilities for Performing Activities in Requirement 7 (7.1.2)

  Document and assign roles and responsibilities for access control activities based on business need to know.

• Access Control Model Defined (7.2.1)

  Define and implement an access control model based on business need to know.

• Assigned Access to Users and Privileged Users (7.2.2)

  Assign access to users and privileged users based on their roles and business need to know.

• Required Privileges Approval by Authorized Personnel (7.2.3)

  Ensure that required privileges are approved by authorized personnel before granting access.

• Periodic Review Process of All User Accounts and Related Access Privileges, Including Third-party/Vendor Accounts (7.2.4)

  Conduct periodic reviews of all user accounts and related access privileges, including those of third-party vendors.

• Management of Application and System Accounts and Related Access Privileges (7.2.5)

  Manage application and system accounts and their related access privileges based on business need to know.

• Periodic Review Process of All Access by Application and System Accounts and Related Access Privileges (7.2.5.1)

  Conduct periodic reviews of all access by application and system accounts and related access privileges.

• All User Access to Query Repositories of Stored Cardholder Data Restriction (7.2.6)

  Restrict all user access to query repositories containing stored cardholder data.

• Access Control System(s) Mechanisms to Restrict Access Based on User’s Need to Know (7.3.1)

  Use access control systems to restrict access based on the user’s need to know.

• Access Control System(s) Configuration to Enforce Permissions (7.3.2)

  Configure access control systems to enforce permissions appropriately.

• Configure access control systems to deny all access by default and allow access only based on explicit permissions (7.3.3)

  Subcontrol 7.3.3 requires organizations to configure their access control systems with a "deny all" by default policy. This means that access to systems and data is denied unless explicitly permitted by an access control rule. This configuration ensures that only authorized users with explicit permissions are granted access, thereby enhancing security and reducing the risk of unauthorized access.

PCI DSS v4.0 Requirement 8 mandates organizations to identify users and authenticate their access to system components by implementing strong authentication mechanisms, such as unique IDs, passwords, and multi-factor authentication, to ensure that only authorized users can access sensitive systems and data.

• Management of Security Policies and Operational Procedures Identified in Requirement 8 (8.1.1)

  Develop, document, and manage security policies and procedures for authentication and user identification.

• Documentation and Assignment of Roles and Responsibilities for Performing Activities in Requirement 8 (8.1.2)

  Document and assign roles and responsibilities for activities related to authentication and user identification.

• Unique ID Assigned to Users for Access to System Components and Cardholder Data (8.2.1)

  Assign a unique ID to each user for access to system components and cardholder data.

• Management of Group, Shared, or Generic Accounts, or Other Shared Authentication Credentials (8.2.2)

  Manage group, shared, or generic accounts and other shared authentication credentials.

• Service Providers Using Unique Authentication Factors for Each Customer Premises (8.2.3)

  Service providers must use unique authentication factors for each customer premises.

• Addition, Deletion, and Modification of User IDs, Authentication Factors, and other Identifier Objects Management (8.2.4)

  Manage the addition, deletion, and modification of user IDs, authentication factors, and other identifiers.

• Access for Terminated Users Immediate Revocation (8.2.5 )

  Ensure immediate revocation of access for terminated users.

• Inactive User Accounts Removal within 90 Days of Inactivity (8.2.6)

  Remove inactive user accounts within 90 days of inactivity.

• Management of Accounts Used by Third Parties to Access, Support, or Maintain System Components via Remote Access (8.2.7)

  Manage accounts used by third parties for remote access to system components.

• User Re-authentication Requirement to Re-activate Terminal or Session (8.2.8)

  Require user re-authentication to re-activate terminals or sessions.

• User Access to System Components Authentication Requirement Via Authentication Factors (8.3.1)

  Ensure user access to system components is authenticated via authentication factors.

• Use of Strong Cryptography to Render All Authentication Factors Unreadable (8.3.2)

  Use strong cryptography to render all authentication factors unreadable.

• User Identity Verification for Modifying any Authentication factor (8.3.3)

  Verify user identity before modifying any authentication factor.

• Invalid Authentication Attempts Limitation (8.3.4)

  Limit the number of invalid authentication attempts.

• Passwords/Passphrases Set and Reset Requirement (8.3.5)

  Set and reset passwords/passphrases according to specified requirements.

• Passwords/Passphrases Minimum Level of Complexity Requirement (8.3.6)

  Enforce minimum complexity requirements for passwords/passphrases.

• Previously Used Password/Passphrase Requirement (8.3.7)

  Prevent the reuse of previously used passwords/passphrases.

• Authentication Policies and Procedures Documentation and Communication (8.3.8)

  Document and communicate authentication policies and procedures.

• Requirements for Passwords/Passphrases Used as the Only Authentication Factor for User Access (8.3.9)

  Define requirements for passwords/passphrases used as the only authentication factor.

• Guidance Provided to Customer Users When Passwords/Passphrases Used as the Only Authentication Factor for Customer User Access to Cardholder Data (8.3.10)

  Provide guidance to customer users when passwords are the only authentication factor for accessing cardholder data.

• Requirements for Passwords/Passphrases Used as the only Authentication Factor for Customer User Access to Cardholder Data (8.3.10.1)

  Define requirements for passwords used as the only authentication factor for customer access to cardholder data.

• Use of Authentication Factors (8.3.11)

  Use authentication factors for user access.

• Implementation of MFA for all Non-console Access into the CDE for Personnel with Administrative Access (8.4.1)

  Implement multi-factor authentication (MFA) for non-console access into the Cardholder Data Environment (CDE) for administrative personnel.

• MFA Implementation for All Access into the CDE (8.4.2)

  Implement MFA for all access into the Cardholder Data Environment (CDE).

• MFA Implementation for Remote Network Access (8.4.3)

  This subcontrol mandates the implementation of multi-factor authentication (MFA) for any remote access to systems within the Cardholder Data Environment (CDE). It ensures that multiple forms of authentication are required before access is granted to sensitive systems from outside the network.

• MFA Systems Implementation (8.5.1)

  Subcontrol 8.5.1 requires that multi-factor authentication (MFA) systems are implemented and operational for systems accessing cardholder data, ensuring that all users are authenticated using multiple factors before accessing sensitive systems.

• Management of Accounts used by Systems or Applications for Interactive Login (8.6.1)

  Addresses the management of system or application accounts used for interactive logins.

• Passwords/Passphrases for any Application and System accounts Used for Interactive Login (8.6.2)

  Requires strong passwords/passphrases for interactive login accounts.

• Passwords/Passphrases for Application and System Accounts Protection Against Misuse (8.6.3)

  Requires protection of passwords/passphrases from misuse.

• Passwords/Passphrases for Application and System Accounts Protection Against Misuse (8.6.3)

  Requires protection of passwords/passphrases from misuse.

• Passwords/Passphrases for Application and System Accounts Protection Against Misuse (8.6.3)

  Requires protection of passwords/passphrases from misuse.

PCI DSS v4.0 Requirement 9 requires organizations to restrict physical access to cardholder data by implementing physical security controls, such as secured facilities, access controls, and monitoring, to prevent unauthorized individuals from accessing sensitive data.

• Use of Visitor Log for Physical Record of Visitor Activity Maintenance (9.3.4)

  Requires maintenance of a visitor log for tracking visitor activity.

• Physical Security of All Media with Cardholder Data (9.4.1)

  Requires physical security measures for all media containing cardholder data.

• Storage Location Security of Offline Media Backups (9.4.1.1)

  Requires secure storage of offline media backups.

• Periodic Review of the Security of Offline Media Backup Location(s) (9.4.1.2)

  Requires periodic review of the security of offline media backup locations.

• Media Classification in Accordance with the Sensitivity of the Data. (9.4.2)

  Requires classification of media according to the sensitivity of the data it contains.

• Security of Media Sent Outside the Facility (9.4.3)

  Requires security measures for media sent outside the facility.

• Security of Media Sent Outside the Facility (9.4.3)

  Requires security measures for media sent outside the facility.

• Security of Media Sent Outside the Facility (9.4.3)

  Requires security measures for media sent outside the facility.

• Management Approval of Media Moved Outside the Facility (9.4.4)

  Requires management approval for media moved outside the facility.

• Maintenance of Inventory Logs of Electronic Media (9.4.5)

  Requires maintenance of inventory logs for electronic media.

• Inventories of Electronic Media Conducted Periodically (9.4.5.1)

  Requires periodic inventories of electronic media.

• Destruction of Hard-copy Materials No longer Needed for Business or Legal Reasons (9.4.6)

  Requires destruction of hard-copy materials no longer needed.

• Destruction of Electronic Media No Longer Needed for Business or Legal Reasons (9.4.7)

  Requires destruction of electronic media no longer needed.

• Procedures to Protect POI Devices from Tampering and Unauthorized Substitution (9.5.1)

  Requires procedures to protect Point-of-Interaction (POI) devices from tampering and substitution.

• Up-to-date List of POI Devices Maintenance (9.5.1.1)

  Requires maintenance of an up-to-date list of POI devices.

• Periodic Inspection of POI Device Surfaces to Detect Tampering and Unauthorized Substitution (9.5.1.2)

  Requires periodic inspection of POI device surfaces.

• POI Devices Inspection at a Frequency that addresses the Entity’s Risk (9.5.1.2.1)

  Requires inspection of POI devices at a frequency based on risk.

• Training of Personnel in POI Environments About the Types of Attacks Against POI Devices (9.5.1.3)

  Requires training for personnel on types of attacks against POI devices.

• Management of Security Policies and Operational Procedures Identified in Requirement 9 (9.1.1)

  Requires management of security policies and operational procedures related to physical access to cardholder data.

• Documentation and Assignment of Roles and Responsibilities for Performing Activities in Requirement 9 (9.1.2)

  Requires documentation and assignment of roles and responsibilities for physical access control activities.

• Facility Entry Controls for Physical Access to Systems in the CDE Restriction (9.2.1)

  Requires controls to restrict physical access to systems within the Cardholder Data Environment (CDE).

• Individual Physical Access to Sensitive Areas Monitoring Procedure (9.2.1.1)

  Requires monitoring procedures for individual physical access to sensitive areas.

• Implementation of Physical and/or Logical Controls to Restrict Use of Publicly Accessible Network Jacks (9.2.2)

  Requires controls to restrict use of publicly accessible network jacks.

• Restriction on Physical Access to Wireless Access Points, Gateways, Networking/Communications Hardware, and Telecommunication Lines (9.2.3)

  Requires restriction of physical access to critical network components.

• Access to Consoles in Sensitive Areas Restriction (9.2.4)

  Requires restriction of access to consoles in sensitive areas.

• Procedures Implementation for Authorizing and Managing Physical Access of Personnel (9.3.1)

  Requires procedures for authorizing and managing physical access of personnel.

• Controlled Physical Access to Sensitive Areas for Personnel (9.3.1.1)

  Requires controlled physical access to sensitive areas for personnel.

• Controlled Physical Access to Sensitive Areas for Personnel (9.3.1.1)

  Requires controlled physical access to sensitive areas for personnel.

• Procedures Implementation for Authorizing and Managing Visitor Access (9.3.2)

  Requires procedures for authorizing and managing visitor access.

• Visitor Badges or Identification Requirements and Procedure (9.3.3)

  Requires the use of visitor badges or identification requirements and procedures.

• Controlled Physical Access to Sensitive Areas for Personnel (9.3.1.1)

  Requires controlled physical access to sensitive areas for personnel.

PCI DSS v4.0 Requirement 10 requires organizations to log and monitor all access to system components and cardholder data, ensuring comprehensive audit trails and real-time monitoring to detect and respond to security incidents effectively.

• Exceptions and Anomalies Identified During the Review Process (10.4.3)

  Identification and management of exceptions and anomalies during log reviews

• Retention of Audit Log History for at Least 12 Months (10.5.1)

  Retention of audit log history for a minimum of 12 months

• System Clocks and Time are Synchronized Using Time-synchronization Technology (10.6.1)

  Use of time-synchronization technology to synchronize system clocks

• Systems Configuration to the Correct and Consistent Time (10.6.2)

  Systems configured to use the correct and consistent time

• Time Synchronization Settings and Data Protection (10.6.3)

  Protection of time synchronization settings and data to prevent tampering

• Failures of Critical Security Control Systems Detection and Management for Service Providers Only (10.7.1)

  Detection and management of failures in critical security control systems for service providers

• Failures of Critical Security Control Systems Detected, Alerted, and Addressed Promptly (A3.3.1),Failures of Critical Security Control Systems Detection and Management (10.7.2)

  Failures in critical security systems must be detected, alerted, and addressed promptly

• Failures of Critical Security Control Systems Responded to Promptly (10.7.3)

  Prompt response to failures in critical security control systems

• Read Access to Audit Logs Files Limitation (10.3.1)

  Requires limiting read access to audit log files.

• Protected Audit Log Files to Prevent Modifications by Individuals (10.3.2)

  Requires protection of audit log files to prevent modifications.

• Audit Log Files Backup Configurations (10.3.3)

  Requires proper backup configurations for audit log files.

• File Integrity Monitoring or Change-Detection Mechanisms (10.3.4)

  Requires file integrity monitoring or change-detection mechanisms.

• Required Regular Audit Log Reviews (10.4.1)

  Regular review of audit logs for security and compliance

• Automated Mechanisms Used to Perform Audit Log Reviews (10.4.1.1)

  Use of automated mechanisms for audit log reviews

• Periodic Review of Logs of All Other System Components (10.4.2)

  Periodic review of logs from all system components not covered under other specific requirements

• Frequency of Periodic Log Reviews for All Other System Components Defined in the Entity’s Targeted Risk Analysis (10.4.2.1)

  Frequency of periodic log reviews based on targeted risk analysis

• Audit Logs Capture All Changes to Audit Log Activity Status (10.2.1.6)

  Requires audit logs to capture all changes to audit log activity status.

• Audit Logs Capture All Creation and Deletion of System-level Objects (10.2.1.7)

  Requires audit logs to capture all creation and deletion of system-level objects.

• Audit Logs Record Details for Each Auditable Event (10.2.2)

  Requires audit logs to record details for each auditable event.

• Management of Security Policies and Operational Procedures Identified in Requirement 10 (10.1.1)

  Requires management of security policies and procedures for logging and monitoring.

• Documentation and Assignment of Roles and Responsibilities for Performing Activities in Requirement 10 (10.1.2)

  Requires documentation and assignment of roles and responsibilities for logging and monitoring activities.

• Enabled and Active Audit Logs for System Components and Cardholder Data (10.2.1)

  Requires audit logs to be enabled and active for system components and cardholder data.

• Audit Logs Capture Individual User Access to Cardholder Data (10.2.1.1)

  Requires audit logs to capture individual user access to cardholder data.

• Audit Logs Capture Actions Taken by Individual with Administrative Access (10.2.1.2)

  Requires audit logs to capture actions taken by individuals with administrative access.

• Audit Logs Capture All Access to Audit Logs (10.2.1.3)

  Requires audit logs to capture all access to audit logs themselves.

• Audit Logs Capture All Invalid Logical Access Attempts (10.2.1.4)

  Requires audit logs to capture all invalid logical access attempts.

• Audit Logs Capture All Changes to Identification and Authentication Credentials (10.2.1.5)

  Requires audit logs to capture all changes to identification and authentication credentials.

PCI DSS v4.0 Requirement 11 mandates organizations to regularly test the security of systems and networks through vulnerability scans, penetration testing, and other assessments to identify and address potential security weaknesses.

• Documentation and Assignment of Roles and Responsibilities for Performing Activities in Requirement 11 (11.1.2)

  Documentation and assignment of roles and responsibilities for system and network security testing activities

• Authorized and Unauthorized Wireless Access Points Management (11.2.1)

  Management of authorized and unauthorized wireless access points

• Inventory of Authorized Wireless Access Points Maintenance (11.2.2)

  Maintenance of an inventory of authorized wireless access points

• Internal Vulnerability Scans Periodically Performed (11.3.1)

  Periodic internal vulnerability scans to identify security weaknesses

• Vulnerabilities Management (11.3.1.1)

  Management of identified vulnerabilities to reduce security risks

• Internal Vulnerability Scans Performed via Authenticated Scanning (11.3.1.2)

  Use of authenticated scanning for internal vulnerability scans

• Internal Vulnerability Scans Performed After Any Significant Change (11.3.1.3)

  Internal vulnerability scans performed after significant changes to systems or networks

• External Vulnerability Scans Performed as Required (11.3.2)

  Regular external vulnerability scans to identify potential external threats

• External Vulnerability Scans Performed After Any Significant Change (11.3.2.1)

  External vulnerability scans performed after significant changes to systems or networks

• Penetration Testing Methodology Documentation and Implementation (11.4.1)

  Documentation and implementation of penetration testing methodologies

• Internal Penetration Testing Performed per Entity's Defined Methodology and Standards (11.4.2)

  Internal penetration testing conducted according to defined methodology and standards

• External Penetration Testing Performed per Entity's Defined Methodology and Standards (11.4.3)

  External penetration testing conducted according to defined methodology and standards

• Mitigation of Exploitable Vulnerabilities and Security Weaknesses Found During Penetration Testing (11.4.4)

  Mitigation of vulnerabilities and weaknesses identified during penetration testing

• Penetration Tests are Performed on Segmentation Controls (11.4.5)

  Penetration tests on segmentation controls ensure that segmentation is effective in isolating environments to protect cardholder data

• Penetration Tests are Performed on Segmentation Controls for Service Providers Only (11.4.6)

  Service providers must conduct penetration tests on their segmentation controls to verify their effectiveness in isolating customer data

• Multi-tenant Service Providers Support Their Customers for External Penetration Testing (11.4.7)

  Multi-tenant service providers must assist their customers in conducting external penetration testing to ensure the security of shared environments

• Intrusion-detection and/or Intrusion-prevention Techniques (11.5.1)

  Intrusion-detection and/or intrusion-prevention systems must be deployed to monitor and protect the network from unauthorized access

• Intrusion-detection and/or Intrusion-prevention Techniques Detection and Prevention (11.5.1.1)

  Systems for intrusion detection and prevention must be capable of detecting and preventing unauthorized access to the network

• Change-detection Mechanism Deployment (11.5.2)

  Change-detection mechanisms must be deployed to alert personnel of unauthorized modifications to critical system files and configurations

• Change- and tamper-detection Mechanism Deployment (11.6.1)

  Mechanisms to detect changes and tampering with system configurations must be deployed to protect the integrity of critical systems

• Management of Security Policies and Operational Procedures Identified in Requirement 11 (11.1.1)

  Management of security policies and operational procedures related to system and network testing

PCI DSS v4.0 Requirement 12 requires organizations to support information security by establishing, maintaining, and enforcing comprehensive security policies and programs that address all aspects of data protection and compliance.

• Information Security Policy Management (12.1.1)

  An information security policy must be established, documented, and maintained to guide security practices within the organization

• Information Security Policy Reviewed at least once every 12 Months (12.1.2)

  The information security policy must be reviewed at least annually to ensure it remains effective and relevant

• Definition of Information Security Roles and Responsibilities for All Personnel (12.1.3)

  Information security roles and responsibilities must be defined and assigned to ensure accountability and effective security management

• Responsibility for Information Security Assigned to a member of Executive Management (12.1.4)

  Responsibility for overseeing information security must be assigned to a member of executive management to ensure accountability

• Acceptable Use Policies for End-User Technologies Documentation and Implementation (12.2.1)

  Acceptable use policies for end-user technologies must be documented and implemented to ensure secure usage practices

• Targeted Risk Analysis Documentation (12.3.1)

  Targeted risk analyses must be documented to identify and mitigate specific risks to the organization's security posture

• Entity Meets PCI DSS Requirement Using the Customized Approach (12.3.2)

  The entity may use a customized approach to meet PCI DSS requirements, provided it demonstrates that the approach achieves the desired outcomes

• Documentation and Review of Cryptographic Cipher Suites and Protocols in Use (12.3.3)

  Cryptographic cipher suites and protocols in use must be documented and reviewed to ensure they remain secure and effective

• Regular Review of Hardware and Software Technologies in Use (12.3.4)

  Hardware and software technologies in use must be regularly reviewed to ensure they remain secure and up-to-date

• Responsibility Establishment by Executive Management for the Protection of Cardholder Data and a PCI DSS Compliance Program (12.4.1)

  Executive management must establish responsibility for protecting cardholder data and maintaining PCI DSS compliance

• Regular Reviews Performed to Confirm Personnel are Performing Tasks in Accordance with Security Policies and Operational Procedures (12.4.2)

  Regular reviews must be conducted to ensure that personnel are performing their tasks in line with security policies and procedures

• Documentation of Reviews Conducted in Accordance with Requirement 12.4.2 (12.4.2.1)

  Reviews conducted in accordance with Requirement 12.4.2 must be documented to provide evidence of compliance

• Maintenance of Current Inventory of System Components that are in scope for PCI DSS (12.5.1)

  A current inventory of system components that are in scope for PCI DSS must be maintained to support security management

• PCI DSS Scope Documentation and Validation by the Entity (12.5.2)

  Documentation and validation of PCI DSS scope are required to ensure all relevant components are included in the assessment.

• Accuracy of PCI DSS Scope Verification (12.5.2.1)

  PCI DSS scope must be verified for accuracy to ensure that all applicable components are included.

• PCI DSS Scope Confirmation After Significant Changes to Organizational Structure (12.5.3)

  PCI DSS scope must be confirmed after significant changes to organizational structure to ensure continued compliance.

• Formal Security Awareness Program Implementation (12.6.1)

  A formal security awareness program must be implemented to educate personnel on security best practices.

• Periodic Review of Security Awareness Program (12.6.2)

  The security awareness program must be reviewed periodically to ensure its effectiveness.

• Requirements for Personnel Security Awareness Training (12.6.3)

  Personnel must receive security awareness training to understand their responsibilities in protecting the organization.

• Security Awareness Training Includes Awareness of Threats and Vulnerabilities (12.6.3.1)

  Security awareness training must include information on current threats and vulnerabilities.

• Security Awareness Training Includes Acceptable Use of End-user Technologies Awareness (12.6.3.2)

  Security awareness training must include guidance on the acceptable use of end-user technologies.

• Potential Personnel Who Will Have access to the CDE are Screened, within the Constraints of Local Laws, Prior to Hire (12.7.1)

  Personnel who will have access to the Cardholder Data Environment (CDE) must be screened prior to hire, within the constraints of local laws.

• Maintenance of List of All Third-party Service Providers (TPSPs) with which Account Data is Shared (12.8.1)

  A list of all TPSPs with whom account data is shared must be maintained.

• Maintenance of Written Agreements with TPSPs (12.8.2)

  Written agreements with TPSPs must be maintained to define the security responsibilities of each party.

• Established Process Implementation for Engaging TPSP (12.8.3)

  A formal process must be established and implemented for engaging TPSPs.

• Program Implementation to Monitor TPSPs’ PCI DSS Compliance Status Periodically (12.8.4)

  A program must be implemented to periodically monitor the PCI DSS compliance status of TPSPs.

• Maintenance and Review of PCI DSS Requirements and Related System Components for which each TPSP is solely or jointly responsible (12.8.5)

  The organization must maintain and review the PCI DSS requirements and related system components for which each TPSP is responsible.

• TPSPs formal Acknowledgement of their Security Responsibilities to their Customers (12.9.1)

  TPSPs must formally acknowledge their security responsibilities to their customers.

• TPSPs Information Provision as Needed to Support Customers’ PCI DSS Compliance Efforts (12.9.2)

  TPSPs must provide necessary information to support customers’ PCI DSS compliance efforts.

• Maintenance of a Comprehensive Incident Response Plan (12.10.1)

  A comprehensive incident response plan must be maintained to address security incidents.

• Periodic Testing and Review of the Incident Response Plan (12.10.2)

  The incident response plan must be periodically tested and reviewed to ensure its effectiveness.

• Specific Designated Personnel Available to Respond Immediately to Suspected or Confirmed Security Incidents (12.10.3)

  Specific personnel must be designated and available to respond immediately to suspected or confirmed security incidents.

• Personnel Appropriately and Periodically Trained on Incident Response Responsibilities (12.10.4)

  Personnel must be appropriately and periodically trained on their incident response responsibilities.

• Incident Response Personnel Trained at a Frequency that Addresses the Entity’s Risk (12.10.4.1)

  Incident response personnel must be trained at a frequency that addresses the organization's risk.

• Monitoring and Responding to Alerts from Security Monitoring Systems (12.10.5)

  Monitoring and responding to alerts from security monitoring systems must be implemented.

• The Security Incident Response Plan Modification and Evolution (12.10.6)

  The security incident response plan must be modified and evolved based on lessons learned and changes in the threat landscape.

• Established Incident Response Procedures to Quickly Respond, Analyze, and Address Situations (12.10.7)

  Incident response procedures must be established to ensure a quick response, analysis, and resolution of security incidents.

Appendix A1 of PCI DSS v4.0 specifies additional requirements for multi-tenant service providers to ensure the secure management of shared environments, including tenant isolation, access control, monitoring, and incident response, to protect cardholder data across multiple customers.

• Logical Separation Implementation (A1.1.1)

  Logical separation controls must be implemented to ensure segregation of different tenants' data and resources.

• Controls Implementation that Permits Customers to Only Access Their Own Account Data and CDE (A1.1.2)

  Controls must be implemented to ensure customers can only access their own account data and Cardholder Data Environment (CDE).

• Controls Implementation that Permits Customers Can Only Access Resources Allocated to Them (A1.1.3)

  Controls must be implemented to ensure that customers can only access resources allocated specifically to them.

• Periodic Validation of Logical Separation Controls via Penetration Testing (A1.1.4)

  Logical separation controls must be periodically validated through penetration testing.

• Audit Log Capability for Each Customer’s Environment (A1.2.1)

  Each customer’s environment must have audit log capabilities to track and monitor access and activities.

• Processes Implementation to Facilitate Prompt Forensic Investigations (A1.2.2)

  Processes must be implemented to facilitate prompt forensic investigations in case of security incidents.

• Processes Implementation for Reporting and Addressing Security Incidents and Vulnerabilities (A1.2.3)

  Processes must be implemented for reporting and addressing security incidents and vulnerabilities.