Skip to main content

πŸ’Ό PCI DSS v4.0

  • ID: /frameworks/pci-dss-v4.0

Description​

Empty...

Similar​

  • Internal
    • ID: dec-a-6a7452e1

Sub Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
πŸ’Ό 1 Install and Maintain Network Security Controls52495no data
γ€€πŸ’Ό 1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood.28no data
γ€€γ€€πŸ’Ό 1.1.1 All security policies and operational procedures identified in Requirement 1 are documented, kept up to date, in use, and known to all affected parties.8no data
γ€€γ€€πŸ’Ό 1.1.2 Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood.no data
γ€€πŸ’Ό 1.2 Network security controls (NSCs) are configured and maintained.82439no data
γ€€γ€€πŸ’Ό 1.2.1 Configuration standards for NSC rulesets are defined, implemented, maintained.2434no data
γ€€γ€€πŸ’Ό 1.2.2 All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process defined at Requirement 6.5.1.no data
γ€€γ€€πŸ’Ό 1.2.3 An accurate network diagram(s) is maintained that shows all connections between the CDE and other networks, including any wireless networks.no data
γ€€γ€€πŸ’Ό 1.2.4 An accurate data-flow diagram(s) is maintained.no data
γ€€γ€€πŸ’Ό 1.2.5 All services, protocols, and ports allowed are identified, approved, and have a defined business need.1527no data
γ€€γ€€πŸ’Ό 1.2.6 Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated.627no data
γ€€γ€€πŸ’Ό 1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.9no data
γ€€γ€€πŸ’Ό 1.2.8 Configuration files for NSCs are secured from unauthorized access and kept consistent with active network configurations.no data
γ€€πŸ’Ό 1.3 Network access to and from the cardholder data environment is restricted.3765no data
γ€€γ€€πŸ’Ό 1.3.1 Inbound traffic to the CDE is restricted.765no data
γ€€γ€€πŸ’Ό 1.3.2 Outbound traffic from the CDE is restricted.65no data
γ€€γ€€πŸ’Ό 1.3.3 NSCs are installed between all wireless networks and the CDE, regardless of whether the wireless network is a CDE.no data
γ€€πŸ’Ό 1.4 Network connections between trusted and untrusted networks are controlled.5741no data
γ€€γ€€πŸ’Ό 1.4.1 NSCs are implemented between trusted and untrusted networks.719no data
γ€€γ€€πŸ’Ό 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted.728no data
γ€€γ€€πŸ’Ό 1.4.3 Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.no data
γ€€γ€€πŸ’Ό 1.4.4 System components that store cardholder data are not directly accessible from untrusted networks.15no data
γ€€γ€€πŸ’Ό 1.4.5 The disclosure of internal IP addresses and routing information is limited to only authorized parties.1no data
γ€€πŸ’Ό 1.5 Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.18no data
γ€€γ€€πŸ’Ό 1.5.1 Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks and the CDE.8no data
πŸ’Ό 2 Apply Secure Configurations to All System Components31447no data
γ€€πŸ’Ό 2.1 Processes and mechanisms for applying secure configurations to all system components are defined and understood.28no data
γ€€γ€€πŸ’Ό 2.1.1 All security policies and operational procedures identified in Requirement 2 are documented, kept up to date, in use, and known to all affected parties.8no data
γ€€γ€€πŸ’Ό 2.1.2 Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood.no data
γ€€πŸ’Ό 2.2 System components are configured and managed securely.71447no data
γ€€γ€€πŸ’Ό 2.2.1 Configuration standards are developed, implemented, and maintained.13no data
γ€€γ€€πŸ’Ό 2.2.2 Vendor default accounts are managed.11no data
γ€€γ€€πŸ’Ό 2.2.3 Primary functions requiring different security levels are managed.no data
γ€€γ€€πŸ’Ό 2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.3no data
γ€€γ€€πŸ’Ό 2.2.5 If any insecure services, protocols, or daemons are present, business justification is documented.3no data
γ€€γ€€πŸ’Ό 2.2.6 System security parameters are configured to prevent misuse.1216no data
γ€€γ€€πŸ’Ό 2.2.7 All non-console administrative access is encrypted using strong cryptography.410no data
γ€€πŸ’Ό 2.3 Wireless environments are configured and managed securely.22no data
γ€€γ€€πŸ’Ό 2.3.1 For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure.2no data
γ€€γ€€πŸ’Ό 2.3.2 For wireless environments connected to the CDE or transmitting account data, wireless encryption keys that are changed.2no data
πŸ’Ό 3 Protect Stored Account Data7816no data
γ€€πŸ’Ό 3.1 Processes and mechanisms for protecting stored account data are defined and understood.25no data
γ€€γ€€πŸ’Ό 3.1.1 All security policies and operational procedures identified in Requirement 3 are documented, kept up to date, in use, and known to all affected parties.5no data
γ€€γ€€πŸ’Ό 3.1.2 Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood.no data
γ€€πŸ’Ό 3.2 Storage of account data is kept to a minimum.1no data
γ€€γ€€πŸ’Ό 3.2.1 Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes.no data
γ€€πŸ’Ό 3.3 Sensitive authentication data (SAD) is not stored after authorization.3813no data
γ€€γ€€πŸ’Ό 3.3.1 SAD is not retained after authorization, even if encrypted.35no data
γ€€γ€€γ€€πŸ’Ό 3.3.1.1 The full contents of any track are not retained upon completion of the authorization process.no data
γ€€γ€€γ€€πŸ’Ό 3.3.1.2 The card verification code is not retained upon completion of the authorization process.no data
γ€€γ€€γ€€πŸ’Ό 3.3.1.3 The personal identification number (PIN) and the PIN block are not retained upon completion of the authorization process.no data
γ€€γ€€πŸ’Ό 3.3.2 SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.813no data
γ€€γ€€πŸ’Ό 3.3.3 Any storage of sensitive authentication data is limited to that which is needed for a legitimate issuing business need, is secured and encrypted using strong cryptography.5no data
γ€€πŸ’Ό 3.4 Access to displays of full PAN and ability to copy cardholder data are restricted.2no data
γ€€γ€€πŸ’Ό 3.4.1 PAN is masked when displayed, such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN.no data
γ€€γ€€πŸ’Ό 3.4.2 When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need.no data
γ€€πŸ’Ό 3.5 Primary account number (PAN) is secured wherever it is stored.113no data
γ€€γ€€πŸ’Ό 3.5.1 PAN is rendered unreadable anywhere it is stored.313no data
γ€€γ€€γ€€πŸ’Ό 3.5.1.1 Hashes used to render PAN unreadable are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures.no data
γ€€γ€€γ€€πŸ’Ό 3.5.1.2 If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable.5no data
γ€€γ€€γ€€πŸ’Ό 3.5.1.3 If disk-level or partition-level encryption is used (rather than file-, column-, or field--level database encryption) to render PAN unreadable.12no data
γ€€πŸ’Ό 3.6 Cryptographic keys used to protect stored account data are secured.11no data
γ€€γ€€πŸ’Ό 3.6.1 Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse.31no data
γ€€γ€€γ€€πŸ’Ό 3.6.1.1 A documented description of the cryptographic architecture is maintained.no data
γ€€γ€€γ€€πŸ’Ό 3.6.1.2 Secret and private keys used to encrypt/decrypt stored account data are stored in one (or more) of the described forms at all times.no data
γ€€γ€€γ€€πŸ’Ό 3.6.1.3 Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary.no data
γ€€πŸ’Ό 3.7 Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.91no data
γ€€γ€€πŸ’Ό 3.7.1 Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data.no data
γ€€γ€€πŸ’Ό 3.7.2 Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data.no data
γ€€γ€€πŸ’Ό 3.7.3 Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data.no data
γ€€γ€€πŸ’Ό 3.7.4 Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod.1no data
γ€€γ€€πŸ’Ό 3.7.5 Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data.no data
γ€€γ€€πŸ’Ό 3.7.6 Where manual cleartext cryptographic key-management operations are performed by personnel, key-management policies and procedures are implemented include managing these operations using split knowledge and dual control.no data
γ€€γ€€πŸ’Ό 3.7.7 Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys.no data
γ€€γ€€πŸ’Ό 3.7.8 Key management policies and procedures are implemented to include that cryptographic key custodians formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities.no data
γ€€γ€€πŸ’Ό 3.7.9 Where a service provider shares cryptographic keys with its customers for transmission or storage of account data, guidance on secure transmission, storage and updating of such keys is documented and distributed to the service provider's customers.no data
πŸ’Ό 4 Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks2928no data
γ€€πŸ’Ό 4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.21no data
γ€€γ€€πŸ’Ό 4.1.1 All security policies and operational procedures identified in Requirement 4 are documented, kept up to date, in use, and known to all affected parties.1no data
γ€€γ€€πŸ’Ό 4.1.2 Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.no data
γ€€πŸ’Ό 4.2 PAN is protected with strong cryptography during transmission.2928no data
γ€€γ€€πŸ’Ό 4.2.1 Strong cryptography and security protocols are implemented to safeguard PAN during transmission over open, public networks.2928no data
γ€€γ€€γ€€πŸ’Ό 4.2.1.1 An inventory of the entity's trusted keys and certificates used to protect PAN during transmission is maintained.no data
γ€€γ€€γ€€πŸ’Ό 4.2.1.2 Wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission.1no data
γ€€γ€€πŸ’Ό 4.2.2 PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.34no data
πŸ’Ό 5 Protect All Systems and Networks from Malicious Software4413no data
γ€€πŸ’Ό 5.1 Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.2no data
γ€€γ€€πŸ’Ό 5.1.1 All security policies and operational procedures identified in Requirement 5 are documented, kept up to date, in use, and known to all affected parties.no data
γ€€γ€€πŸ’Ό 5.1.2 Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood.no data
γ€€πŸ’Ό 5.2 Malicious software (malware) is prevented, or detected and addressed.344no data
γ€€γ€€πŸ’Ό 5.2.1 An anti-malware solution(s) is deployed on all system components.44no data
γ€€γ€€πŸ’Ό 5.2.2 The deployed anti-malware solution(s) detects, removes, blocks, or contains all known types of malware.no data
γ€€γ€€πŸ’Ό 5.2.3 Any system components that are not at risk for malware are evaluated periodically.1no data
γ€€γ€€γ€€πŸ’Ό 5.2.3.1 The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity's targeted risk analysis.no data
γ€€πŸ’Ό 5.3 Anti-malware mechanisms and processes are active, maintained, and monitored.59no data
γ€€γ€€πŸ’Ό 5.3.1 The anti-malware solution(s) is kept current via automatic updates.9no data
γ€€γ€€πŸ’Ό 5.3.2 The anti-malware solution performs periodic scans and active or real-time scans or performs continuous behavioral analysis of systems or processes.19no data
γ€€γ€€γ€€πŸ’Ό 5.3.2.1 If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity's targeted risk analysis.no data
γ€€γ€€πŸ’Ό 5.3.3 For removable electronic media, the anti-malware solution performs automatic scans of when the media is inserted, connected, or logically mounted, or performs continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted.no data
γ€€γ€€πŸ’Ό 5.3.4 Audit logs for the anti-malware solution(s) are enabled and retained.9no data
γ€€γ€€πŸ’Ό 5.3.5 Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented, and authorized by management on a case-by-case basis for a limited time period.no data
γ€€πŸ’Ό 5.4 Anti-phishing mechanisms protect users against phishing attacks.1no data
γ€€γ€€πŸ’Ό 5.4.1 Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.no data
πŸ’Ό 6 Develop and Maintain Secure Systems and Software527no data
γ€€πŸ’Ό 6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.2no data
γ€€γ€€πŸ’Ό 6.1.1 All security policies and operational procedures identified in Requirement 6 are documented, kept up to date, in use, and known to all affected parties.no data
γ€€γ€€πŸ’Ό 6.1.2 Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood.no data
γ€€πŸ’Ό 6.2 Bespoke and custom software are developed securely.48no data
γ€€γ€€πŸ’Ό 6.2.1 Bespoke and custom software are developed securely.3no data
γ€€γ€€πŸ’Ό 6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months.no data
γ€€γ€€πŸ’Ό 6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities.11no data
γ€€γ€€γ€€πŸ’Ό 6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices reviewed and approved by management prior to release.1no data
γ€€γ€€πŸ’Ό 6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software.5no data
γ€€πŸ’Ό 6.3 Security vulnerabilities are identified and addressed.38no data
γ€€γ€€πŸ’Ό 6.3.1 Security vulnerabilities are identified and managed.2no data
γ€€γ€€πŸ’Ό 6.3.2 An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.no data
γ€€γ€€πŸ’Ό 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates6no data
γ€€πŸ’Ό 6.4 Public-facing web applications are protected against attacks.313no data
γ€€γ€€πŸ’Ό 6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks.11no data
γ€€γ€€πŸ’Ό 6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks.10no data
γ€€γ€€πŸ’Ό 6.4.3 All payment page scripts that are loaded and executed in the consumer's browser are managed.1no data
γ€€πŸ’Ό 6.5 Changes to all system components are managed securely.6no data
γ€€γ€€πŸ’Ό 6.5.1 Changes to all system components in the production environment are made according to established procedures.no data
γ€€γ€€πŸ’Ό 6.5.2 Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable.no data
γ€€γ€€πŸ’Ό 6.5.3 Pre-production environments are separated from production environments and the separation is enforced with access controls.no data
γ€€γ€€πŸ’Ό 6.5.4 Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.no data
γ€€γ€€πŸ’Ό 6.5.5 Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements.no data
γ€€γ€€πŸ’Ό 6.5.6 Test data and test accounts are removed from system components before the system goes into production.no data
πŸ’Ό 7 Restrict Access to System Components and Cardholder Data by Business Need to Know316no data
γ€€πŸ’Ό 7.1 Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood.2no data
γ€€γ€€πŸ’Ό 7.1.1 All security policies and operational procedures identified in Requirement 7 are documented, kept up to date, in use, and known to all affected parties.no data
γ€€γ€€πŸ’Ό 7.1.2 Roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood.no data
γ€€πŸ’Ό 7.2 Access to system components and data is appropriately defined and assigned.66no data
γ€€γ€€πŸ’Ό 7.2.1 An access control model is defined and includes granting appropriate access.1no data
γ€€γ€€πŸ’Ό 7.2.2 Access is assigned to users, including privileged users, based on job classification, function, and least privileges.5no data
γ€€γ€€πŸ’Ό 7.2.3 Required privileges are approved by authorized personnel.no data
γ€€γ€€πŸ’Ό 7.2.4 All user accounts and related access privileges, including third-party/vendor accounts, are reviewed.no data
γ€€γ€€πŸ’Ό 7.2.5 All application and system accounts and related access privileges are assigned and managed.1no data
γ€€γ€€γ€€πŸ’Ό 7.2.5.1 All access by application and system accounts and related access privileges are reviewed.no data
γ€€γ€€πŸ’Ό 7.2.6 All user access to query repositories of stored cardholder data is restricted.no data
γ€€πŸ’Ό 7.3 Access to system components and data is managed via an access control system(s).311no data
γ€€γ€€πŸ’Ό 7.3.1 An access control system(s) is in place that restricts access based on a user's need to know and covers all system components.11no data
γ€€γ€€πŸ’Ό 7.3.2 The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function.no data
γ€€γ€€πŸ’Ό 7.3.3 The access control system(s) is set to β€œdeny all” by default.no data
πŸ’Ό 8 Identify Users and Authenticate Access to System Components61029no data
γ€€πŸ’Ό 8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.2no data
γ€€γ€€πŸ’Ό 8.1.1 All security policies and operational procedures identified in Requirement 8 are documented, kept up to date, in use, and known to all affected parties.no data
γ€€γ€€πŸ’Ό 8.1.2 Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood.no data
γ€€πŸ’Ό 8.2 User identification and related accounts for users and administrators are strictly managed throughout an account's lifecycle.826no data
γ€€γ€€πŸ’Ό 8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.2no data
γ€€γ€€πŸ’Ό 8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis.22no data
γ€€γ€€πŸ’Ό 8.2.3 Service providers with remote access to customer premises use unique authentication factors for each customer premises.no data
γ€€γ€€πŸ’Ό 8.2.4 Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed.1no data
γ€€γ€€πŸ’Ό 8.2.5 Access for terminated users is immediately revoked.no data
γ€€γ€€πŸ’Ό 8.2.6 Inactive user accounts are removed or disabled within 90 days of inactivity.2no data
γ€€γ€€πŸ’Ό 8.2.7 Accounts used by third parties to access, support, or maintain system components via remote access are managed.no data
γ€€γ€€πŸ’Ό 8.2.8 If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session.no data
γ€€πŸ’Ό 8.3 Strong authentication for users and administrators is established and managed.11820no data
γ€€γ€€πŸ’Ό 8.3.1 All user access to system components for users and administrators is authenticated.11no data
γ€€γ€€πŸ’Ό 8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.614no data
γ€€γ€€πŸ’Ό 8.3.3 User identity is verified before modifying any authentication factor.no data
γ€€γ€€πŸ’Ό 8.3.4 Invalid authentication attempts are limited.no data
γ€€γ€€πŸ’Ό 8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user.no data
γ€€γ€€πŸ’Ό 8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the minimum level of complexity.13no data
γ€€γ€€πŸ’Ό 8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.3no data
γ€€γ€€πŸ’Ό 8.3.8 Authentication policies and procedures are documented and communicated to all users.no data
γ€€γ€€πŸ’Ό 8.3.9 If passwords/passphrases are used as the only authentication factor for user access then either passwords/passphrases are changed at least once every 90 days, or the security posture of accounts is dynamically analyzed.3no data
γ€€γ€€πŸ’Ό 8.3.10 If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data, then guidance is provided to customer users.114no data
γ€€γ€€γ€€πŸ’Ό 8.3.10.1 If passwords/passphrases are used as the only authentication factor for customer user access then either passwords/passphrases are changed at least once every 90 days, or the security posture of accounts is dynamically analyzed.1no data
γ€€γ€€πŸ’Ό 8.3.11 Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used factors are assigned to an individual user and not shared among multiple users, and physical and/or logical controls ensure only the intended user can use that factor to gain access.11no data
γ€€πŸ’Ό 8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE.313no data
γ€€γ€€πŸ’Ό 8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access.13no data
γ€€γ€€πŸ’Ό 8.4.2 MFA is implemented for all access into the CDE.13no data
γ€€γ€€πŸ’Ό 8.4.3 MFA is implemented for all remote network access originating from outside the entity's network that could access or impact the CDE.11no data
γ€€πŸ’Ό 8.5 Multi-factor authentication (MFA) systems are configured to prevent misuse.1no data
γ€€γ€€πŸ’Ό 8.5.1 MFA systems are implemented.no data
γ€€πŸ’Ό 8.6 Use of application and system accounts and associated authentication factors is strictly managed.33no data
γ€€γ€€πŸ’Ό 8.6.1 If accounts used by systems or applications can be used for interactive login, they are managed.no data
γ€€γ€€πŸ’Ό 8.6.2 Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.1no data
γ€€γ€€πŸ’Ό 8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse.2no data
πŸ’Ό 9 Restrict Physical Access to Cardholder Data57no data
γ€€πŸ’Ό 9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood.2no data
γ€€γ€€πŸ’Ό 9.1.1 All security policies and operational procedures identified in Requirement 9 are documented, kept up to date, in use, and known to all affected parties.no data
γ€€γ€€πŸ’Ό 9.1.2 Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood.no data
γ€€πŸ’Ό 9.2 Physical access controls manage entry into facilities and systems containing cardholder data.4no data
γ€€γ€€πŸ’Ό 9.2.1 Appropriate facility entry controls are in place to restrict physical access to systems in the CDE.1no data
γ€€γ€€γ€€πŸ’Ό 9.2.1.1 Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access control mechanisms.no data
γ€€γ€€πŸ’Ό 9.2.2 Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility.no data
γ€€γ€€πŸ’Ό 9.2.3 Physical access to wireless access points, gateways, networking/communications hardware, and telecommunication lines within the facility is restricted.no data
γ€€γ€€πŸ’Ό 9.2.4 Access to consoles in sensitive areas is restricted via locking when not in use.no data
γ€€πŸ’Ό 9.3 Physical access for personnel and visitors is authorized and managed.4no data
γ€€γ€€πŸ’Ό 9.3.1 Procedures are implemented for authorizing and managing physical access of personnel to the CDE.1no data
γ€€γ€€γ€€πŸ’Ό 9.3.1.1 Physical access to sensitive areas within the CDE for personnel is controlled.no data
γ€€γ€€πŸ’Ό 9.3.2 Procedures are implemented for authorizing and managing visitor access to the CDE.no data
γ€€γ€€πŸ’Ό 9.3.3 Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration.no data
γ€€γ€€πŸ’Ό 9.3.4 A visitor log is used to maintain a physical record of visitor activity within the facility and within sensitive areas.no data
γ€€πŸ’Ό 9.4 Media with cardholder data is securely stored, accessed, distributed, and destroyed.76no data
γ€€γ€€πŸ’Ό 9.4.1 All media with cardholder data is physically secured.2no data
γ€€γ€€γ€€πŸ’Ό 9.4.1.1 Offline media backups with cardholder data are stored in a secure location.no data
γ€€γ€€γ€€πŸ’Ό 9.4.1.2 The security of the offline media backup location(s) with cardholder data is reviewed at least once every 12 months.no data
γ€€γ€€πŸ’Ό 9.4.2 All media with cardholder data is classified in accordance with the sensitivity of the data.no data
γ€€γ€€πŸ’Ό 9.4.3 Media with cardholder data sent outside the facility is secured.no data
γ€€γ€€πŸ’Ό 9.4.4 Management approves all media with cardholder data that is moved outside the facility.no data
γ€€γ€€πŸ’Ό 9.4.5 Inventory logs of all electronic media with cardholder data are maintained.16no data
γ€€γ€€γ€€πŸ’Ό 9.4.5.1 Inventories of electronic media with cardholder data are conducted at least once every 12 months.no data
γ€€γ€€πŸ’Ό 9.4.6 Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons.no data
γ€€γ€€πŸ’Ό 9.4.7 Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons.no data
γ€€πŸ’Ό 9.5 Point of interaction (POI) devices are protected from tampering and unauthorized substitution.11no data
γ€€γ€€πŸ’Ό 9.5.1 POI devices that capture payment card data via direct physical interaction with the payment card form factor are protected from tampering and unauthorized substitution.31no data
γ€€γ€€γ€€πŸ’Ό 9.5.1.1 An up-to-date list of POI devices is maintained.1no data
γ€€γ€€γ€€πŸ’Ό 9.5.1.2 POI device surfaces are periodically inspected to detect tampering and unauthorized substitution.1no data
γ€€γ€€γ€€γ€€πŸ’Ό 9.5.1.2.1 The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity's targeted risk analysis.no data
γ€€γ€€γ€€πŸ’Ό 9.5.1.3 Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices.no data
πŸ’Ό 10 Log and Monitor All Access to System Components and Cardholder Data7242no data
γ€€πŸ’Ό 10.1 Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.2no data
γ€€γ€€πŸ’Ό 10.1.1 All security policies and operational procedures identified in Requirement 10 are documented, kept up to date, in use, and known to all affected parties.no data
γ€€γ€€πŸ’Ό 10.1.2 Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood.no data
γ€€πŸ’Ό 10.2 Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.2132no data
γ€€γ€€πŸ’Ό 10.2.1 Audit logs are enabled and active for all system components and cardholder data.7132no data
γ€€γ€€γ€€πŸ’Ό 10.2.1.1 Audit logs capture all individual user access to cardholder data.114no data
γ€€γ€€γ€€πŸ’Ό 10.2.1.2 Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts.16no data
γ€€γ€€γ€€πŸ’Ό 10.2.1.3 Audit logs capture all access to audit logs.9no data
γ€€γ€€γ€€πŸ’Ό 10.2.1.4 Audit logs capture all invalid logical access attempts.114no data
γ€€γ€€γ€€πŸ’Ό 10.2.1.5 Audit logs capture all changes to identification and authentication credentials.16no data
γ€€γ€€γ€€πŸ’Ό 10.2.1.6 Audit logs capture all initialization of new audit logs, starting, stopping, or pausing of the existing audit logs.9no data
γ€€γ€€γ€€πŸ’Ό 10.2.1.7 Audit logs capture all creation and deletion of system-level objects.9no data
γ€€γ€€πŸ’Ό 10.2.2 Audit logs record the described details for each auditable event.9no data
γ€€πŸ’Ό 10.3 Audit logs are protected from destruction and unauthorized modifications.426no data
γ€€γ€€πŸ’Ό 10.3.1 Read access to audit logs files is limited to those with a job-related need.no data
γ€€γ€€πŸ’Ό 10.3.2 Audit log files are protected to prevent modifications by individuals.24no data
γ€€γ€€πŸ’Ό 10.3.3 Audit log files, including those for external-facing technologies, are promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify.2no data
γ€€γ€€πŸ’Ό 10.3.4 File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts.22no data
γ€€πŸ’Ό 10.4 Audit logs are reviewed to identify anomalies or suspicious activity.39no data
γ€€γ€€πŸ’Ό 10.4.1 The audit logs are reviewed at least once daily.12no data
γ€€γ€€γ€€πŸ’Ό 10.4.1.1 Automated mechanisms are used to perform audit log reviews.2no data
γ€€γ€€πŸ’Ό 10.4.2 Logs of all other system components are reviewed periodically.19no data
γ€€γ€€γ€€πŸ’Ό 10.4.2.1 The frequency of periodic log reviews for all other system components is defined in the entity's targeted risk analysis.2no data
γ€€γ€€πŸ’Ό 10.4.3 Exceptions and anomalies identified during the review process are addressed.2no data
γ€€πŸ’Ό 10.5 Audit log history is retained and available for analysis.11no data
γ€€γ€€πŸ’Ό 10.5.1 Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.1no data
γ€€πŸ’Ό 10.6 Time-synchronization mechanisms support consistent time settings across all systems.3no data
γ€€γ€€πŸ’Ό 10.6.1 System clocks and time are synchronized using time-synchronization technology.no data
γ€€γ€€πŸ’Ό 10.6.2 Systems are configured to the correct and consistent time.no data
γ€€γ€€πŸ’Ό 10.6.3 Time synchronization settings and data are protected.no data
γ€€πŸ’Ό 10.7 Failures of critical security control systems are detected, reported, and responded to promptly.3no data
γ€€γ€€πŸ’Ό 10.7.1 Failures of critical security control systems are detected, alerted, and addressed promptly.no data
γ€€γ€€πŸ’Ό 10.7.2 Failures of critical security control systems are detected, alerted, and addressed promptly.no data
γ€€γ€€πŸ’Ό 10.7.3 Failures of any critical security controls systems are responded to promptly.no data
πŸ’Ό 11 Test Security of Systems and Networks Regularly6820no data
γ€€πŸ’Ό 11.1 Processes and mechanisms for regularly testing security of systems and networks are defined and understood.2no data
γ€€γ€€πŸ’Ό 11.1.1 All security policies and operational procedures identified in Requirement 11 are documented, kept up to date, in use, and known to all affected parties.no data
γ€€γ€€πŸ’Ό 11.1.2 Roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood.no data
γ€€πŸ’Ό 11.2 Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.21no data
γ€€γ€€πŸ’Ό 11.2.1 Authorized and unauthorized wireless access points are managed.1no data
γ€€γ€€πŸ’Ό 11.2.2 An inventory of authorized wireless access points is maintained, including a documented business justification.1no data
γ€€πŸ’Ό 11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.22no data
γ€€γ€€πŸ’Ό 11.3.1 Internal vulnerability scans are performed.32no data
γ€€γ€€γ€€πŸ’Ό 11.3.1.1 All other applicable vulnerabilities (those not ranked as high-risk or critical) are managed.no data
γ€€γ€€γ€€πŸ’Ό 11.3.1.2 Internal vulnerability scans are performed via authenticated scanning.no data
γ€€γ€€γ€€πŸ’Ό 11.3.1.3 Internal vulnerability scans are performed after any significant change.no data
γ€€γ€€πŸ’Ό 11.3.2 External vulnerability scans are performed.1no data
γ€€γ€€γ€€πŸ’Ό 11.3.2.1 External vulnerability scans are performed after any significant change.no data
γ€€πŸ’Ό 11.4 External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.7no data
γ€€γ€€πŸ’Ό 11.4.1 A penetration testing methodology is defined, documented, and implemented by the entity.no data
γ€€γ€€πŸ’Ό 11.4.2 Internal penetration testing is performed.no data
γ€€γ€€πŸ’Ό 11.4.3 External penetration testing is performed.no data
γ€€γ€€πŸ’Ό 11.4.4 Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected.no data
γ€€γ€€πŸ’Ό 11.4.5 If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls.no data
γ€€γ€€πŸ’Ό 11.4.6 If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls.no data
γ€€γ€€πŸ’Ό 11.4.7 Multi-tenant service providers support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4.no data
γ€€πŸ’Ό 11.5 Network intrusions and unexpected file changes are detected and responded to.2817no data
γ€€γ€€πŸ’Ό 11.5.1 Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or prevent intrusions into the network.1813no data
γ€€γ€€γ€€πŸ’Ό 11.5.1.1 Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels.813no data
γ€€γ€€πŸ’Ό 11.5.2 A change-detection mechanism (for example, file integrity monitoring tools) is deployed.4no data
γ€€πŸ’Ό 11.6 Unauthorized changes on payment pages are detected and responded to.113no data
γ€€γ€€πŸ’Ό 11.6.1 A change- and tamper-detection mechanism is deployed.13no data
πŸ’Ό 12 Support Information Security with Organizational Policies and Programs103no data
γ€€πŸ’Ό 12.1 A comprehensive information security policy that governs and provides direction for protection of the entity's information assets is known and current.4no data
γ€€γ€€πŸ’Ό 12.1.1 An overall information security policy is established, published, maintained, and disseminated to all relevant personnel, as well as to relevant vendors and business partners.no data
γ€€γ€€πŸ’Ό 12.1.2 The information security policy is reviewed at least once every 12 months, and updated as needed to reflect changes to business objectives or risks to the environment.no data
γ€€γ€€πŸ’Ό 12.1.3 The security policy clearly defines information security roles and responsibilities for all personnel, and all personnel are aware of and acknowledge their information security responsibilities.no data
γ€€γ€€πŸ’Ό 12.1.4 Responsibility for information security is formally assigned to a Chief Information Security Officer or other information security knowledgeable member of executive management.no data
γ€€πŸ’Ό 12.2 Acceptable use policies for end-user technologies are defined and implemented.1no data
γ€€γ€€πŸ’Ό 12.2.1 Acceptable use policies for end-user technologies are documented and implemented.no data
γ€€πŸ’Ό 12.3 Risks to the cardholder data environment are formally identified, evaluated, and managed.41no data
γ€€γ€€πŸ’Ό 12.3.1 Each PCI DSS requirement that provides flexibility for how frequently it is performed is supported by a targeted risk analysis that is documented.no data
γ€€γ€€πŸ’Ό 12.3.2 A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach.no data
γ€€γ€€πŸ’Ό 12.3.3 Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months.no data
γ€€γ€€πŸ’Ό 12.3.4 Hardware and software technologies in use are reviewed at least once every 12 months.1no data
γ€€πŸ’Ό 12.4 PCI DSS compliance is managed.2no data
γ€€γ€€πŸ’Ό 12.4.1 Responsibility is established by executive management for the protection of cardholder data and a PCI DSS compliance program.no data
γ€€γ€€πŸ’Ό 12.4.2 Reviews are performed at least once every three months to confirm that personnel are performing their tasks in accordance with all security policies and operational procedures1no data
γ€€γ€€γ€€πŸ’Ό 12.4.2.1 Reviews conducted in accordance with Requirement 12.4.2 are documented.no data
γ€€πŸ’Ό 12.5 PCI DSS scope is documented and validated.31no data
γ€€γ€€πŸ’Ό 12.5.1 An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current.1no data
γ€€γ€€πŸ’Ό 12.5.2 PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment.1no data
γ€€γ€€γ€€πŸ’Ό 12.5.2.1 PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment.no data
γ€€γ€€πŸ’Ό 12.5.3 Significant changes to organizational structure result in a documented (internal) review of the impact to PCI DSS scope and applicability of controls, with results communicated to executive management.no data
γ€€πŸ’Ό 12.6 Security awareness education is an ongoing activity.3no data
γ€€γ€€πŸ’Ό 12.6.1 A formal security awareness program is implemented to make all personnel aware of the entity's information security policy and procedures, and their role in protecting the cardholder data.no data
γ€€γ€€πŸ’Ό 12.6.2 The security awareness program is reviewed at least once every 12 months, and updated to address any new threats and vulnerabilities.no data
γ€€γ€€πŸ’Ό 12.6.3 Personnel receive security awareness training.2no data
γ€€γ€€γ€€πŸ’Ό 12.6.3.1 Security awareness training includes awareness of threats and vulnerabilities that could impact the security of the CDE.no data
γ€€γ€€γ€€πŸ’Ό 12.6.3.2 Security awareness training includes awareness about the acceptable use of end-user technologies.no data
γ€€πŸ’Ό 12.7 Personnel are screened to reduce risks from insider threats.1no data
γ€€γ€€πŸ’Ό 12.7.1 Potential personnel who will have access to the CDE are screened, within the constraints of local laws, prior to hire to minimize the risk of attacks from internal sources.no data
γ€€πŸ’Ό 12.8 Risk to information assets associated with third-party service provider (TPSP) relationships is managed.5no data
γ€€γ€€πŸ’Ό 12.8.1 A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.no data
γ€€γ€€πŸ’Ό 12.8.2 Written agreements with TPSPs are maintained.no data
γ€€γ€€πŸ’Ό 12.8.3 An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.no data
γ€€γ€€πŸ’Ό 12.8.4 A program is implemented to monitor TPSPs' PCI DSS compliance status at least once every 12 months.no data
γ€€γ€€πŸ’Ό 12.8.5 Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.no data
γ€€πŸ’Ό 12.9 Third-party service providers (TPSPs) support their customers' PCI DSS compliance.2no data
γ€€γ€€πŸ’Ό 12.9.1 TPSPs acknowledge in writing to customers that they are responsible for the security of account data the TPSP possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer's CDE.no data
γ€€γ€€πŸ’Ό 12.9.2 TPSPs support their customers' requests for information to meet Requirements 12.8.4 and 12.8.5.no data
γ€€πŸ’Ό 12.10 Suspected and confirmed security incidents that could impact the CDE are responded to immediately.71no data
γ€€γ€€πŸ’Ό 12.10.1 An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident.no data
γ€€γ€€πŸ’Ό 12.10.2 At least once every 12 months, the security incident response plan is reviewed and the content is updated as needed, and tested.no data
γ€€γ€€πŸ’Ό 12.10.3 Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.no data
γ€€γ€€πŸ’Ό 12.10.4 Personnel responsible for responding to suspected and confirmed security incidents are appropriately and periodically trained on their incident response responsibilities.1no data
γ€€γ€€γ€€πŸ’Ό 12.10.4.1 The frequency of periodic training for incident response personnel is defined in the entity's targeted risk analysis.no data
γ€€γ€€πŸ’Ό 12.10.5 The security incident response plan includes monitoring and responding to alerts from security monitoring systems.1no data
γ€€γ€€πŸ’Ό 12.10.6 The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.no data
γ€€γ€€πŸ’Ό 12.10.7 Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected.no data