Definition of Payment Card Industry - Data Security Standard (PCI-DSS) for rhel9

based on https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf

1.1.1: All security policies and operational procedures that are identified in Requirement 1 are Documented, Kept up to date, In use and Known to all affected parties.

Description: None

Levels:

Automated: no

No rules selected

1.1.2: Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood.

Description: None

Levels:

Automated: no

No rules selected

1.1: Processes and mechanisms for installing and maintaining network security controls are defined and understood.

Description: None

Levels:

Automated: no

No rules selected

1.2.1: Configuration standards for NSC rulesets are Defined, Implemented and Maintained.

Description: None

Levels:

Automated: yes

Selections:

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.

Description: None

Levels:

Automated: no

No rules selected

1.2.3: An accurate network diagram(s) is maintained that shows all connections between the CDE and other networks, including any wireless networks.

Description: None

Levels:

Automated: no

No rules selected

1.2.4: An accurate data-flow diagram(s) is maintained

Description: An accurate data-flow diagram(s) is maintained that meets the following: - Shows all account data flows across systems and networks - Updated as needed upon changes to the environment

Levels:

Automated: no

No rules selected

1.2.5: All services, protocols, and ports allowed are identified, approved, and have a defined business need.

Description: None

Levels:

Automated: no

No rules selected

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.

Description: None

Levels:

Automated: yes

Selections:

1.2.7: Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.

Description: NSC configurations that allow or restrict access to trusted networks are verified periodically to ensure that only authorized connections with a current business justification are permitted.

Levels:

Automated: no

No rules selected

1.2.8: Configuration files for NSCs are secured from unauthorized access and kept consistent with active network configurations.

Description: None

Levels:

Automated: yes

Selections:

1.2: Network Security Controls (NSCs) are configured and maintained.

Description: None

Levels:

Automated: yes

Selections:

1.3.1: Inbound traffic to the CDE is restricted to only traffic that is necessary

Description: Inbound traffic to the CDE is restricted as follows: - To only traffic that is necessary. - All other traffic is specifically denied.

Levels:

Automated: yes

Selections:

1.3.2: Outbound traffic from the CDE is restricted to only traffic that is necessary

Description: Outbound traffic from the CDE is restricted as follows: - To only traffic that is necessary. - All other traffic is specifically denied.

Levels:

Automated: no

No rules selected

1.3.3: NSCs are installed between all wireless networks and the CDE, regardless of whether the wireless network is a CDE.

Description: NSCs are installed between all wireless networks and the CDE, regardless of whether the wireless network is a CDE, such that: - All wireless traffic from wireless networks into the CDE is denied by default. - Only wireless traffic with an authorized business purpose is allowed into the CDE.

Levels:

Automated: yes

Selections:

1.3: Network access to and from the cardholder data environment is restricted.

Description: None

Levels:

Automated: no

Selections:

1.4.1: NSCs are implemented between trusted and untrusted networks.

Description: Unauthorized traffic cannot traverse network boundaries between trusted and untrusted networks.

Levels:

Automated: yes

Selections:

1.4.2: Inbound traffic from untrusted networks to trusted networks is restricted.

Description: Inbound traffic from untrusted networks to trusted networks is restricted to: - Communications with system components that are authorized to provide publicly accessible services, protocols, and ports. - Stateful responses to communications initiated by system components in a trusted network. - All other traffic is denied.

Levels:

Automated: no

Selections:

1.4.3: Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.

Description: None

Levels:

Automated: no

Selections:

1.4.4: System components that store cardholder data are not directly accessible from untrusted networks.

Description: None

Levels:

Automated: no

No rules selected

1.4.5: The disclosure of internal IP addresses and routing information is limited to only authorized parties.

Description: Internal network information is protected from unauthorized disclosure.

Levels:

Automated: yes

Selections:

1.4: Network connections between trusted and untrusted networks are controlled.

Description: None

Levels:

Automated: no

Selections:

1.5.1: Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks (including the Internet) and the CDE

Description: Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks (including the Internet) and the CDE as follows: - Specific configuration settings are defined to prevent threats being introduced into the entity's network. - Security controls are actively running. - Security controls are not alterable by users of the computing devices unless specifically documented and authorized by management on a case-by-case basis for a limited period.

Levels:

Automated: no

No rules selected

1.5: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

Description: None

Levels:

Automated: no

No rules selected

2.1.1: All security policies and operational procedures that are identified in Requirement 2 are Documented, Kept up to date, In use and Known to all affected parties.

Description: None

Levels:

Automated: no

No rules selected

2.1.2: Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood.

Description: Day-to-day responsibilities for performing all the activities in Requirement 2 are allocated. Personnel are accountable for successful, continuous operation of these requirements.

Levels:

Automated: no

No rules selected

2.1: Processes and mechanisms for applying secure configurations to all system components are defined and understood.

Description: None

Levels:

Automated: no

No rules selected

2.2.1: Configuration standards are developed, implemented, and maintained

Description: Configuration standards are developed, implemented, and maintained to: - Cover all system components. - Address all known security vulnerabilities. - Be consistent with industry-accepted system hardening standards or vendor hardening recommendations. - Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1. - Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.

Levels:

Automated: no

Selections:

2.2.2: Vendor default accounts are managed.

Description: Vendor default accounts are managed as follows: - If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6. - If the vendor default account(s) will not be used, the account is removed or disabled.

Levels:

Automated: yes

Selections:

2.2.3: Primary functions requiring different security levels are managed

Description: None

Levels:

Automated: no

No rules selected

2.2.4: Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled

Description: System components cannot be compromised by exploiting unnecessary functionality present in the system component.

Levels:

Automated: yes

Selections:

2.2.5: If any insecure services, protocols, or daemons are present, business justification is documented and the risk is reduced.

Description: If any insecure services, protocols, or daemons are present: - Business justification is documented. - Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.

Levels:

Automated: no

No rules selected

2.2.6: System security parameters are configured to prevent misuse.

Description: System components cannot be compromised because of incorrect security parameter configuration.

Levels:

Automated: yes

Selections:

2.2.7: All non-console administrative access is encrypted using strong cryptography.

Description: Cleartext administrative authorization factors cannot be read or intercepted from any network transmissions. This includes administrative access via browser-based interfaces and application programming interfaces (APIs).

Levels:

Automated: yes

Selections:

2.2: System components are configured and managed securely.

Description: None

Levels:

Automated: no

Selections:

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.

Description: 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, including but not limited to: - Default wireless encryption keys. - Passwords on wireless access points. - SNMP defaults. - Any other security-related wireless vendor defaults.

Levels:

Automated: no

No rules selected

2.3.2: For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed

Description: For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed

Levels:

Automated: no

No rules selected

2.3: Wireless environments are configured and managed securely.

Description: None

Levels:

Automated: no

No rules selected

3.1.1: All security policies and operational procedures that are identified in Requirement 3 are Documented, Kept up to date, In use and Known to all affected parties.

Description: None

Levels:

Automated: no

No rules selected

3.1.2: Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood.

Description: None

Levels:

Automated: no

No rules selected

3.1: Processes and mechanisms for protecting stored account data are defined and understood.

Description: None

Levels:

Automated: no

No rules selected

3.2.1: Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes.

Description: Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following: - Coverage for all locations of stored account data. - Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization. - Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements. - Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification. - Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy. - A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable.

Levels:

Automated: no

No rules selected

3.2: Storage of account data is kept to a minimum.

Description: None

Levels:

Automated: no

No rules selected

3.3.1.1: The full contents of any track are not stored upon completion of the authorization process.

Description: This requirement is not eligible for the customized approach. In the normal course of business, the following data elements from the track may need to be retained: - Cardholder name. - Primary account number (PAN). - Expiration date. - Service code. To minimize risk, store securely only these data elements as needed for business.

Levels:

Automated: no

Selections:

3.3.1.2: The card verification code is not stored upon completion of the authorization process.

Description: This requirement is not eligible for the customized approach. The card verification code is the three- or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions.

Levels:

Automated: no

No rules selected

3.3.1.3: The personal identification number (PIN) and the PIN block are not stored upon completion of the authorization process.

Description: This requirement is not eligible for the customized approach. PIN blocks are encrypted during the natural course of transaction processes, but even if an entity encrypts the PIN block again, it is still not allowed to be stored after the completion of the authorization process.

Levels:

Automated: no

No rules selected

3.3.1: SAD is not stored after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process.

Description: This requirement is not eligible for the customized approach. This requirement does not apply to issuers and companies that support issuing services (where SAD is needed for a legitimate issuing business need) and have a business justification to store the sensitive authentication data. Refer to Requirement 3.3.3 for additional requirements specifically for issuers. Sensitive authentication data includes the data cited in Requirements 3.3.1.1 through 3.3.1.3.

Levels:

Automated: no

Selections:

3.3.2: SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.

Description: This requirement is not eligible for the customized approach. Whether SAD is permitted to be stored prior to authorization is determined by the organizations that manage compliance programs (for example, payment brands and acquirers). Contact the organizations of interest for any additional criteria. This requirement applies to all storage of SAD, even if no PAN is present in the environment. Refer to Requirement 3.2.1 for an additional requirement that applies if SAD is stored prior to completion of authorization. Issuers and companies that support issuing services, where there is a legitimate and documented business need to store SAD, are not required to meet this requirement. A legitimate business need is one that is necessary for the performance of the function being provided by or for the issuer. Refer to Requirement 3.3.3 for requirements specifically for issuers. This requirement does not replace how PIN blocks are required to be managed, nor does it mean that a properly encrypted PIN block needs to be encrypted again.

Levels:

Automated: no

No rules selected

3.3.3: Additional requirement for issuers and companies that support issuing services and store sensitive authentication data.

Description: Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is: - Limited to that which is needed for a legitimate issuing business need and is secured. - Encrypted using strong cryptography. This bullet is a best practice until until 31 March 2025, after which it will be required as part of Requirement 3.3.3 and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

3.3: Sensitive authentication data (SAD) is not stored after authorization.

Description: None

Levels:

Automated: no

Selections:

3.4.1: PAN is masked when displayed (the BIN and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN.

Description: PAN displays are restricted to the minimum number of digits necessary to meet a defined business need. This requirement does not supersede stricter requirements in place for displays of cardholder data — for example, legal or payment brand requirements for point-of-sale (POS) receipts. This requirement relates to protection of PAN where it is displayed on screens, paper receipts, printouts, etc., and is not to be confused with Requirement 3.5.1 for protection of PAN when stored, processed, or transmitted.

Levels:

Automated: no

No rules selected

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.

Description: PAN cannot be copied or relocated by unauthorized personnel using remote-access technologies. Storing or relocating PAN onto local hard drives, removable electronic media, and other storage devices brings these devices into scope for PCI DSS. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: yes

Selections:

3.4: Access to displays of full PAN and ability to copy PAN is restricted.

Description: None

Levels:

Automated: yes

Selections:

3.5.1.1: Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7.

Description: All Applicability Notes for Requirement 3.5.1 also apply to this requirement. Key-management processes and procedures (Requirements 3.6 and 3.7) do not apply to system components used to generate individual keyed hashes of a PAN for comparison to another system if: - The system components only have access to one hash value at a time (hash values are not stored on the system) AND - There is no other account data stored on the same system as the hashes. This requirement is considered a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. This requirement will replace the bullet in Requirement 3.5.1 for one-way hashes once its effective date is reached.

Levels:

Automated: no

No rules selected

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, it is implemented only on removable electronic media or complemented by another mechanism that meets Requirement 3.5.1

Description: None

Levels:

Automated: yes

Selections:

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, it is managed.

Description: If disk-level or partition-level encryption is used (rather than file-, column-, or field--level database encryption) to render PAN unreadable, it is managed as follows: - Logical access is managed separately and independently of native operating system authentication and access control mechanisms. - Decryption keys are not associated with user accounts. - Authentication factors (passwords, passphrases, or cryptographic keys) that allow access to unencrypted data are stored securely.

Levels:

Automated: no

No rules selected

3.5.1: PAN is rendered unreadable anywhere it is stored

Description: PAN is rendered unreadable anywhere it is stored by using any of the following approaches: - One-way hashes based on strong cryptography of the entire PAN. - Truncation (hashing cannot be used to replace the truncated segment of PAN). - If hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional controls are in place such that the different versions cannot be correlated to reconstruct the original PAN. - Indexes tokens. - Strong cryptography with associated key-management processes and procedures.

Levels:

Automated: no

Selections:

3.5: Primary account number (PAN) is secured wherever it is stored.

Description: None

Levels:

Automated: no

Selections:

3.6.1.1: Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained

Description: Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes: - Details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date. - Preventing the use of the same cryptographic keys in production and test environments. This bullet is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.6.1.1 and must be fully considered during a PCI DSS assessment. - Description of the key usage for each key. - Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, as outlined in Requirement 12.3.4.

Levels:

Automated: no

No rules selected

3.6.1.2: Secret and private keys used to encrypt/decrypt stored account data are stored in secure forms.

Description: Secret and private keys used to encrypt/decrypt stored account data are stored in one (or more) of the following forms at all times: - Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key. - Within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device. - As at least two full-length key components or key shares, in accordance with an industry-accepted method. Secret and private keys are stored in a secure form that prevents unauthorized retrieval or access. It is not required that public keys be stored in one of these forms. Cryptographic keys stored as part of a key management system (KMS) that employs SCDs are acceptable. A cryptographic key that is split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following

Levels:

Automated: no

No rules selected

3.6.1.3: Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary.

Description: Access to cleartext cryptographic key components is restricted to necessary personnel.

Levels:

Automated: no

No rules selected

3.6.1.4: Cryptographic keys are stored in the fewest possible locations.

Description: Cryptographic keys are retained only where necessary.

Levels:

Automated: no

No rules selected

3.6.1: Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse.

Description: Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include: - Access to keys is restricted to the fewest number of custodians necessary. - Key-encrypting keys are at least as strong as the data-encrypting keys they protect. - Key-encrypting keys are stored separately from data-encrypting keys. - Keys are stored securely in the fewest possible locations and forms.

Levels:

Automated: no

No rules selected

3.6: Cryptographic keys used to protect stored account data are secured.

Description: None

Levels:

Automated: no

No rules selected

3.7.1: Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data.

Description: Strong cryptographic keys are generated.

Levels:

Automated: no

No rules selected

3.7.2: Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data.

Description: Cryptographic keys are secured during distribution.

Levels:

Automated: no

No rules selected

3.7.3: Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data.

Description: Cryptographic keys are secured when stored.

Levels:

Automated: no

No rules selected

3.7.4: Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines.

Description: Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines, including the following: - A defined cryptoperiod for each key type in use. - A process for key changes at the end of the defined cryptoperiod.

Levels:

Automated: no

No rules selected

3.7.5: Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data, as deemed necessary.

Description: Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data, as deemed necessary when: - The key has reached the end of its defined cryptoperiod. - The integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known. - The key is suspected of or known to be compromised. - Retired or replaced keys are not used for encryption operations.

Levels:

Automated: no

No rules selected

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.

Description: Cleartext secret or private keys cannot be known by anyone. Operations involving cleartext keys cannot be carried out by a single person. This control is applicable for manual key-management operations or where key management is not controlled by the encryption product. A cryptographic key that is simply split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following

Levels:

Automated: no

No rules selected

3.7.7: Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys.

Description: Cryptographic keys cannot be substituted by unauthorized personnel.

Levels:

Automated: no

No rules selected

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.

Description: Key custodians are knowledgeable about their responsibilities in relation to cryptographic operations and can access assistance and guidance when required.

Levels:

Automated: no

No rules selected

3.7.9: Additional requirement for service providers only: 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.

Description: Customers are provided with appropriate key management guidance whenever they receive shared cryptographic keys. This requirement applies only when the entity being assessed is a service provider.

Levels:

Automated: no

No rules selected

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.

Description: None

Levels:

Automated: no

No rules selected

4.1.1: All security policies and operational procedures that are identified in Requirement 4 are Documented, Kept up to date, In use and Known to all affected parties.

Description: None

Levels:

Automated: no

No rules selected

4.1.2: Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.

Description: None

Levels:

Automated: no

No rules selected

4.1: Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.

Description: None

Levels:

Automated: no

No rules selected

4.2.1.1: An inventory of the entity's trusted keys and certificates used to protect PAN during transmission is maintained.

Description: All keys and certificates used to protect PAN during transmission are identified and confirmed as trusted. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

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.

Description: Cleartext PAN cannot be read or intercepted from wireless network transmissions.

Levels:

Automated: no

No rules selected

4.2.1: Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks.

Description: Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks: - Only trusted keys and certificates are accepted. - Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. This bullet is a best practice until 31 March 2025, after which it will be required as part of Requirement 4.2.1 and must be fully considered during a PCI DSS assessment. - The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations. - The encryption strength is appropriate for the encryption methodology in use.

Levels:

Automated: no

No rules selected

4.2.2: PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.

Description: Cleartext PAN cannot be read or intercepted from transmissions using end-user messaging technologies. This requirement also applies if a customer, or other third-party, requests that PAN is sent to them via end-user messaging technologies. There could be occurrences where an entity receives unsolicited cardholder data via an insecure communication channel that was not intended for transmissions of sensitive data. In this situation, the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or delete the cardholder data and implement measures to prevent the channel from being used for cardholder data.

Levels:

Automated: no

No rules selected

4.2: PAN is protected with strong cryptography during transmission.

Description: None

Levels:

Automated: no

No rules selected

5.1.1: All security policies and operational procedures that are identified in Requirement 5 are Documented, Kept up to date, In use and Known to all affected parties.

Description: None

Levels:

Automated: no

No rules selected

5.1.2: Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood.

Description: None

Levels:

Automated: no

No rules selected

5.1: Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.

Description: None

Levels:

Automated: no

No rules selected

5.2.1: An anti-malware solution(s) is deployed on all system components, except for those system components identified in periodic evaluations per Requirement 5.2.3 that concludes the system components are not at risk from malware.

Description: Automated mechanisms are implemented to prevent systems from becoming an attack vector for malware.

Levels:

Automated: no

No rules selected

5.2.2: The deployed anti-malware solution(s) detects all known types of malware and removes, blocks, or contains all known types of malware.

Description: None

Levels:

Automated: no

No rules selected

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, which is performed according to all elements specified in Requirement 12.3.1.

Description: Systems not known to be at risk from malware are re-evaluated at a frequency that addresses the entity's risk. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

5.2.3: Any system components that are not at risk for malware are evaluated periodically.

Description: Any system components that are not at risk for malware are evaluated periodically to include the following: - A documented list of all system components not at risk for malware. - Identification and evaluation of evolving malware threats for those system components. - Confirmation whether such system components continue to not require anti-malware protection.

Levels:

Automated: no

No rules selected

5.2: Malicious software (malware) is prevented, or detected and addressed.

Description: None

Levels:

Automated: yes

No rules selected

5.3.1: The anti-malware solution(s) is kept current via automatic updates.

Description: Anti-malware mechanisms can detect and address the latest malware threats.

Levels:

Automated: no

No rules selected

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, which is performed according to all elements specified in Requirement 12.3.1.

Description: Scans by the malware solution are performed at a frequency that addresses the entity's risk. This requirement applies to entities conducting periodic malware scans to meet Requirement 5.3.2. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

5.3.2: The anti-malware solution(s) performs periodic scans and active or real-time scans or performs continuous behavioral analysis of systems or processes.

Description: None

Levels:

Automated: no

No rules selected

5.3.3: For removable electronic media, the anti-malware solution(s) 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.

Description: None

Levels:

Automated: no

No rules selected

5.3.4: Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.5.1.

Description: Historical records of anti-malware actions are immediately available and retained for at least 12 months.

Levels:

Automated: no

No rules selected

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.

Description: Anti-malware mechanisms cannot be modified by unauthorized personnel.Anti-malware solutions may be temporarily disabled only if there is a legitimate technical need, as authorized by management on a case-by-case basis. If anti-malware protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period during which anti-malware protection is not active.

Levels:

Automated: no

No rules selected

5.3: Anti-malware mechanisms and processes are active, maintained, and monitored.

Description: None

Levels:

Automated: no

No rules selected

5.4.1: Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.

Description: Mechanisms are in place to protect against and mitigate risk posed by phishing attacks. The focus of this requirement is on protecting personnel with access to system components in-scope for PCI DSS. Meeting this requirement for technical and automated controls to detect and protect personnel against phishing is not the same as Requirement 12.6.3.1 for security awareness training. Meeting this requirement does not also meet the requirement for providing personnel with security awareness training, and vice versa. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

5.4: Anti-phishing mechanisms protect users against phishing attacks.

Description: None

Levels:

Automated: no

No rules selected

6.1.1: All security policies and operational procedures that are identified in Requirement 6 are Documented, Kept up to date, In use and Known to all affected parties.

Description: None

Levels:

Automated: no

No rules selected

6.1.2: Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood.

Description: None

Levels:

Automated: no

No rules selected

6.1: Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.

Description: None

Levels:

Automated: no

No rules selected

6.2.1: Bespoke and custom software are developed securely.

Description: Bespoke and custom software are developed securely, as follows: - Based on industry standards and/or best practices for secure development. - In accordance with PCI DSS (for example, secure authentication and logging). - Incorporating consideration of information security issues during each stage of the software development lifecycle.

Levels:

Automated: no

No rules selected

6.2.2: Software development personnel working on bespoke and custom software are trained at least once every 12 months

Description: Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows: - On software security relevant to their job function and development languages. - Including secure software design and secure coding techniques. - Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.

Levels:

Automated: no

No rules selected

6.2.3.1: If manual code reviews are performed for bespoke and custom software prior to release to production code changes co-reviewed and approved.

Description: 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.

Levels:

Automated: no

No rules selected

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.

Description: Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows: - Code reviews ensure code is developed according to secure coding guidelines. - Code reviews look for both existing and emerging software vulnerabilities. - Appropriate corrections are implemented prior to release.

Levels:

Automated: no

No rules selected

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.

Description: None

Levels:

Automated: no

No rules selected

6.2: Bespoke and custom software are developed securely.

Description: None

Levels:

Automated: no

No rules selected

6.3.1: Security vulnerabilities are identified and managed

Description: None

Levels:

Automated: no

No rules selected

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.

Description: Known vulnerabilities in third-party software components cannot be exploited in bespoke and custom software.This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

6.3.3: All system components are protected from known vulnerabilities by installing applicable security patches/updates.

Description: All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: - Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release. - All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity's assessment of the criticality of the risk to the environment as identified according to the risk ranking process at Requirement 6.3.1.

Levels:

Automated: yes

Selections:

6.3: Security vulnerabilities are identified and addressed.

Description: None

Levels:

Automated: yes

Selections:

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.

Description: For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows: - Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows: - At least once every 12 months and after significant changes. - By an entity that specializes in application security. - Including, at a minimum, all common software attacks in Requirement 6.2.4. - All vulnerabilities are ranked in accordance with requirement 6.3.1. - All vulnerabilities are corrected. - The application is re-evaluated after the corrections OR - Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows: - Installed in front of public-facing web applications to detect and prevent web-based attacks. - Actively running and up to date as applicable. - Generating audit logs. - Configured to either block web-based attacks or generate an alert that is immediately investigated.

Levels:

Automated: no

No rules selected

6.4.2: For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks.

Description: None

Levels:

Automated: no

No rules selected

6.4.3: All payment page scripts that are loaded and executed in the consumer's browser are managed

Description: All payment page scripts that are loaded and executed in the consumer's browser are managed as follows: - A method is implemented to confirm that each script is authorized. - A method is implemented to assure the integrity of each script. - An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.

Levels:

Automated: no

No rules selected

6.4: Public-facing web applications are protected against attacks.

Description: None

Levels:

Automated: no

No rules selected

6.5.1: Changes to all system components in the production environment are made according to established procedures.

Description: None

Levels:

Automated: no

No rules selected

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.

Description: All system components are verified after a significant change to be compliant with the applicable PCI DSS requirements.These significant changes should also be captured and reflected in the entity's annual PCI DSS scope confirmation activity per Requirement 12.5.2.

Levels:

Automated: no

No rules selected

6.5.3: Pre-production environments are separated from production environments and the separation is enforced with access controls.

Description: Pre-production environments cannot introduce risks and vulnerabilities into production environments.

Levels:

Automated: no

No rules selected

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.

Description: Job roles and accountability that differentiate between pre-production and production activities are defined and managed to minimize the risk of unauthorized, unintentional, or inappropriate actions. In environments with limited personnel where individuals perform multiple roles or functions, this same goal can be achieved with additional procedural controls that provide accountability. For example, a developer may also be an administrator that uses an administrator-level account with elevated privileges in the development environment and, for their developer role, they use a separate account with user-level access to the production environment.

Levels:

Automated: no

No rules selected

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.

Description: Live PANs cannot be present in pre-production environments outside the CDE.s

Levels:

Automated: no

No rules selected

6.5.6: Test data and test accounts are removed from system components before the system goes into production.

Description: Test data and test accounts cannot exist in production environments.

Levels:

Automated: no

No rules selected

6.5: Changes to all system components are managed securely.

Description: None

Levels:

Automated: no

No rules selected

7.1.1: All security policies and operational procedures that are identified in Requirement 7 are Documented, Kept up to date, In use and Known to all affected parties.

Description: None

Levels:

Automated: no

No rules selected

7.1.2: Roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood.

Description: None

Levels:

Automated: no

No rules selected

7.1: Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood.

Description: None

Levels:

Automated: no

No rules selected

7.2.1: An access control model is defined and includes granting access

Description: An access control model is defined and includes granting access as follows: - Appropriate access depending on the entity's business and access needs. - Access to system components and data resources that is based on users' job classification and functions. - The least privileges required (for example, user, administrator) to perform a job function.

Levels:

Automated: no

No rules selected

7.2.2: Access is assigned to users, including privileged users, based on job classification and function, and least privileges necessary to perform job responsibilities.

Description: None

Levels:

Automated: no

No rules selected

7.2.3: Required privileges are approved by authorized personnel.

Description: Access privileges cannot be granted to users without appropriate, documented authorization.

Levels:

Automated: no

No rules selected

7.2.4: All user accounts and related access privileges, including third-party/vendor accounts, are reviewed

Description: All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows: - At least once every six months. - To ensure user accounts and access remain appropriate based on job function. - Any inappropriate access is addressed. - Management acknowledges that access remains appropriate.

Levels:

Automated: no

No rules selected

7.2.5.1: All access by application and system accounts and related access privileges are reviewed.

Description: None

Levels:

Automated: no

No rules selected

7.2.5: All application and system accounts and related access privileges are assigned and managed.

Description: All application and system accounts and related access privileges are assigned and managed as follows: - Based on the least privileges necessary for the operability of the system or application. - Access is limited to the systems, applications, or processes that specifically require their use.

Levels:

Automated: no

No rules selected

7.2.6: All user access to query repositories of stored cardholder data is restricted

Description: None

Levels:

Automated: no

No rules selected

7.2: Access to system components and data is appropriately defined and assigned.

Description: None

Levels:

Automated: no

No rules selected

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.

Description: Access rights and privileges are managed via mechanisms intended for that purpose.

Levels:

Automated: no

No rules selected

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.

Description: Individual account access rights and privileges to systems, applications, and data are only inherited from group membership.

Levels:

Automated: no

No rules selected

7.3.3: The access control system(s) is set to "deny all" by default.

Description: Access rights and privileges are prohibited unless expressly permitted.

Levels:

Automated: no

No rules selected

7.3: Access to system components and data is managed via an access control system(s).

Description: None

Levels:

Automated: no

No rules selected

8.1.1: All security policies and operational procedures that are identified in Requirement 8 are Documented, Kept up to date, In use and Known to all affected parties.

Description: None

Levels:

Automated: no

No rules selected

8.1.2: Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood.

Description: None

Levels:

Automated: no

No rules selected

8.1: Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.

Description: None

Levels:

Automated: no

No rules selected

8.2.1: All users are assigned a unique ID before access to system components or cardholder data is allowed.

Description: All actions by all users are attributable to an individual. This requirement is not intended to apply to user accounts within point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals).

Levels:

Automated: no

Selections:

8.2.2: Group, shared, or generic IDs, or other shared authentication credentials are only used when necessary on an exception basis, and are managed.

Description: - ID use is prevented unless needed for an exceptional circumstance. - Use is limited to the time needed for the exceptional circumstance. - Business justification for use is documented. - Use is explicitly approved by management. - Individual user identity is confirmed before access to an account is granted. - Every action taken is attributable to an individual user.

Levels:

Automated: yes

Selections:

8.2.3: Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises.

Description: None

Levels:

Automated: no

No rules selected

8.2.4: Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed

Description: None

Levels:

Automated: no

No rules selected

8.2.5: Access for terminated users is immediately revoked.

Description: The accounts of terminated users cannot be used.

Levels:

Automated: no

No rules selected

8.2.6: Inactive user accounts are removed or disabled within 90 days of inactivity.

Description: Inactive user accounts cannot be used.

Levels:

Automated: yes

Selections:

8.2.7: Accounts used by third parties to access, support, or maintain system components via remote access are managed.

Description: None

Levels:

Automated: no

No rules selected

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.

Description: A user session cannot be used except by the authorized user. This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). This requirement is not meant to prevent legitimate activities from being performed while the console/PC is unattended.

Levels:

Automated: yes

Selections:

8.2: User identification and related accounts for users and administrators are strictly managed throughout an account's lifecycle.

Description: None

Levels:

Automated: no

Selections:

8.3.1: All user access to system components for users and administrators is authenticated.

Description: None

Levels:

Automated: yes

Selections:

8.3.2: Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.

Description: Cleartext authentication factors cannot be obtained, derived, or reused from the interception of communications or from stored data.

Levels:

Automated: yes

Selections:

8.3.3: User identity is verified before modifying any authentication factor.

Description: Unauthorized individuals cannot gain system access by impersonating the identity of an authorized user.

Levels:

Automated: no

No rules selected

8.3.4: Invalid authentication attempts are limited.

Description: - Locking out the user ID after not more than 10 attempts. - Setting the lockout duration to a minimum of 30 minutes or until the user's identity is confirmed.

Levels:

Automated: yes

Selections:

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.

Description: - Set to a unique value for first-time use and upon reset. - Forced to be changed immediately after the first use.

Levels:

Automated: yes

Selections:

8.3.6: If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the minimum level of complexity.

Description: - A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters). - Contain both numeric and alphabetic characters. A guessed password/passphrase cannot be verified by either an online or offline brute force attack.

Levels:

Automated: yes

Selections:

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.

Description: A previously used password cannot be used to gain access to an account for at least 12 months.

Levels:

Automated: yes

Selections:

8.3.8: Authentication policies and procedures are documented and communicated to all users.

Description: None

Levels:

Automated: no

No rules selected

8.3.9: If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) they should have a limited lifetime.

Description: If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either: - Passwords/passphrases are changed at least once every 90 days, OR - The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.

Levels:

Automated: yes

Selections:

8.3.10.1: Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) they should have a limited lifetime.

Description: None

Levels:

Automated: yes

No rules selected

8.3.10: Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single-factor authentication implementation) then guidance is provided to customer users.

Description: None

Levels:

Automated: no

No rules selected

8.3.11: Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used, factors are not shared among multiple users and the usage is controlled.'

Description: None

Levels:

Automated: no

No rules selected

8.3: Strong authentication for users and administrators is established and managed.

Description: None

Levels:

Automated: no

Selections:

8.4.1: MFA is implemented for all non-console access into the CDE for personnel with administrative access.

Description: None

Levels:

Automated: no

No rules selected

8.4.2: MFA is implemented for all non-console access into the CDE.

Description: Access into the CDE cannot be obtained by the use of a single authentication factor.

Levels:

Automated: no

No rules selected

8.4.3: MFA is implemented for all remote access originating from outside the entity's network that could access or impact the CDE.

Description: None

Levels:

Automated: no

No rules selected

8.4: Multi-factor authentication (MFA) is implemented to secure access into the CDE.

Description: None

Levels:

Automated: no

No rules selected

8.5.1: MFA systems are properly implemented.

Description: - The MFA system is not susceptible to replay attacks. - MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period. - At least two different types of authentication factors are used. - Success of all authentication factors is required before access is granted.

Levels:

Automated: no

No rules selected

8.5: Multi-factor authentication (MFA) systems are configured to prevent misuse.

Description: None

Levels:

Automated: no

No rules selected

8.6.1: If accounts used by systems or applications can be used for interactive login, they are managed.

Description: - Interactive use is prevented unless needed for an exceptional circumstance. - Interactive use is limited to the time needed for the exceptional circumstance. - Business justification for interactive use is documented. - Interactive use is explicitly approved by management. - Individual user identity is confirmed before access to account is granted. - Every action taken is attributable to an individual user.

Levels:

Automated: yes

Selections:

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.

Description: Passwords/passphrases used by application and system accounts cannot be used by unauthorized personnel.

Levels:

Automated: no

No rules selected

8.6.3: Passwords/passphrases for any application and system accounts are protected against misuse.

Description: - Passwords/passphrases are changed periodically (at the frequency defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise. - Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.

Levels:

Automated: yes

No rules selected

8.6: Use of application and system accounts and associated authentication factors is strictly managed.

Description: None

Levels:

Automated: yes

Selections:

9.1.1: All security policies and operational procedures that are identified in Requirement 9 are Documented, Kept up to date, In use and Known to all affected parties.

Description: None

Levels:

Automated: no

No rules selected

9.1.2: Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood.

Description: None

Levels:

Automated: no

No rules selected

9.1: Processes and mechanisms for restricting physical access to cardholder data are defined and understood.

Description: None

Levels:

Automated: no

No rules selected

9.2.1.1: Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access control mechanisms (or both).

Description: None

Levels:

Automated: no

No rules selected

9.2.1: Appropriate facility entry controls are in place to restrict physical access to systems in the CDE.

Description: System components in the CDE cannot be physically accessed by unauthorized personnel.

Levels:

Automated: no

No rules selected

9.2.2: Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility.

Description: Unauthorized devices cannot connect to the entity's network from public areas within the facility.

Levels:

Automated: no

No rules selected

9.2.3: Physical access to wireless access points, gateways, networking/communications hardware, and telecommunication lines within the facility is restricted

Description: Physical networking equipment cannot be accessed by unauthorized personnel.

Levels:

Automated: no

No rules selected

9.2.4: Access to consoles in sensitive areas is restricted via locking when not in use.

Description: Physical consoles within sensitive areas cannot be used by unauthorized personnel.

Levels:

Automated: no

No rules selected

9.2: Physical access controls manage entry into facilities and systems containing cardholder data.

Description: None

Levels:

Automated: no

No rules selected

9.3.1.1: Physical access to sensitive areas within the CDE for personnel is controlled

Description: None

Levels:

Automated: no

No rules selected

9.3.1: Procedures are implemented for authorizing and managing physical access of personnel to the CDE.

Description: None

Levels:

Automated: no

No rules selected

9.3.2: Procedures are implemented for authorizing and managing visitor access to the CDE.

Description: None

Levels:

Automated: no

No rules selected

9.3.3: Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration.

Description: Visitor identification or badges cannot be reused after expiration.

Levels:

Automated: no

No rules selected

9.3.4: Visitor logs are used to maintain a physical record of visitor activity both within the facility and within sensitive areas.

Description: None

Levels:

Automated: no

No rules selected

9.3: Physical access for personnel and visitors is authorized and managed.

Description: None

Levels:

Automated: no

No rules selected

9.4.1.1: Offline media backups with cardholder data are stored in a secure location.

Description: Offline backups cannot be accessed by unauthorized personnel.

Levels:

Automated: no

No rules selected

9.4.1.2: The security of the offline media backup location(s) with cardholder data is reviewed at least once every 12 months.

Description: The security controls protecting offline backups are verified periodically by inspection.

Levels:

Automated: no

No rules selected

9.4.1: All media with cardholder data is physically secured.

Description: Media with cardholder data cannot be accessed by unauthorized personnel.

Levels:

Automated: no

No rules selected

9.4.2: All media with cardholder data is classified in accordance with the sensitivity of the data.

Description: Media are classified and protected appropriately.

Levels:

Automated: no

No rules selected

9.4.3: Media with cardholder data sent outside the facility is secured.

Description: Media is secured and tracked when transported outside the facility. - Media sent outside the facility is logged. - Media is sent by secured courier or other delivery method that can be accurately tracked. - Offsite tracking logs include details about media location.

Levels:

Automated: no

No rules selected

9.4.4: Management approves all media with cardholder data that is moved outside the facility (including when media is distributed to individuals).

Description: Media cannot leave a facility without the approval of accountable personnel. Individuals approving media movements should have the appropriate level of management authority to grant this approval. However, it is not specifically required that such individuals have "manager" as part of their title.

Levels:

Automated: no

No rules selected

9.4.5.1: Inventories of electronic media with cardholder data are conducted at least once every 12 months.

Description: Media inventories are verified periodically.

Levels:

Automated: no

No rules selected

9.4.5: Inventory logs of all electronic media with cardholder data are maintained.

Description: Accurate inventories of stored electronic media are maintained.

Levels:

Automated: no

No rules selected

9.4.6: Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons.

Description: None

Levels:

Automated: no

No rules selected

9.4.7: Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons.

Description: - The electronic media is destroyed. - The cardholder data is rendered unrecoverable so that it cannot be reconstructed.

Levels:

Automated: no

No rules selected

9.4: Media with cardholder data is securely stored, accessed, distributed, and destroyed.

Description: None

Levels:

Automated: no

No rules selected

9.5.1.1: An up-to-date list of POI devices is maintained.

Description: None

Levels:

Automated: no

No rules selected

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, which is performed according to all elements specified in Requirement 12.3.1.

Description: POI devices are inspected at a frequency that addresses the entity's risk. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

9.5.1.2: POI device surfaces are periodically inspected to detect tampering and unauthorized substitution.

Description: Point of Interaction Devices cannot be tampered with, substituted without authorization, or have skimming attachments installed without timely detection.

Levels:

Automated: no

No rules selected

9.5.1.3: Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices.

Description: None

Levels:

Automated: no

No rules selected

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.

Description: None

Levels:

Automated: no

No rules selected

9.5: Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution.

Description: None

Levels:

Automated: no

No rules selected

10.1.1: All security policies and operational procedures that are identified in Requirement 10 are Documented, Kept up to date, In use and Known to all affected parties.

Description: None

Levels:

Automated: no

No rules selected

10.1.2: Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood.

Description: None

Levels:

Automated: no

No rules selected

10.1: Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.

Description: None

Levels:

Automated: no

No rules selected

10.2.1.1: Audit logs capture all individual user access to cardholder data.

Description: Records of all individual user access to cardholder data are captured.

Levels:

Automated: no

No rules selected

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.

Description: Records of all actions performed by individuals with elevated privileges are captured.

Levels:

Automated: no

Selections:

10.2.1.3: Audit logs capture all access to audit logs.

Description: Records of all access to audit logs are captured.

Levels:

Automated: yes

Selections:

10.2.1.4: Audit logs capture all invalid logical access attempts.

Description: Records of all invalid access attempts are captured.

Levels:

Automated: yes

Selections:

10.2.1.5: Audit logs capture all changes to identification and authentication credentials.

Description: None

Levels:

Automated: yes

Selections:

10.2.1.6: Audit logs capture the initialization of new audit logs, and starting, stopping, or pausing of the existing audit logs.

Description: None

Levels:

Automated: no

No rules selected

10.2.1.7: Audit logs capture all creation and deletion of system-level objects.

Description: Records of alterations that indicate a system has been modified from its intended functionality are captured.

Levels:

Automated: no

Selections:

10.2.1: Audit logs are enabled and active for all system components and cardholder data.

Description: Records of all activities affecting system components and cardholder data are captured.

Levels:

Automated: yes

Selections:

10.2.2: Audit logs record sufficient details for each auditable event.

Description: - User identification. - Type of event. - Date and time. - Success and failure indication. - Origination of event. - Identity or name of affected data, system component, resource, or service (for example, name and protocol).

Levels:

Automated: yes

Selections:

10.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.

Description: None

Levels:

Automated: no

Selections:

10.3.1: Read access to audit logs files is limited to those with a job-related need.

Description: Stored activity records cannot be accessed by unauthorized personnel.

Levels:

Automated: yes

Selections:

10.3.2: Audit log files are protected to prevent modifications by individuals.

Description: Stored activity records cannot be modified by personnel.

Levels:

Automated: yes

Selections:

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.

Description: Stored activity records are secured and preserved in a central location to prevent unauthorized modification.

Levels:

Automated: no

Selections:

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.

Description: Stored activity records cannot be modified without an alert being generated.

Levels:

Automated: yes

Selections:

10.3: Audit logs are protected from destruction and unauthorized modifications.

Description: None

Levels:

Automated: no

Selections:

10.4.1.1: Automated mechanisms are used to perform audit log reviews.

Description: Potentially suspicious or anomalous activities are identified via a repeatable and consistent mechanism. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

10.4.1: The audit logs are reviewed at least once daily.

Description: - All security events. - Logs of all system components that store, process, or transmit CHD and/or SAD. - Logs of all critical system components. - Logs of all servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers).

Levels:

Automated: no

No rules selected

10.4.2.1: The frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) is defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1

Description: Log reviews for lower-risk system components are performed at a frequency that addresses the entity's risk. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

10.4.2: Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically.

Description: Potentially suspicious or anomalous activities for other system components (not included in 10.4.1) are reviewed in accordance with the entity's identified risk. This requirement is applicable to all other in-scope system components not included in Requirement 10.4.1.

Levels:

Automated: no

No rules selected

10.4.3: Exceptions and anomalies identified during the review process are addressed.

Description: Suspicious or anomalous activities are addressed.

Levels:

Automated: no

No rules selected

10.4: Audit logs are reviewed to identify anomalies or suspicious activity.

Description: None

Levels:

Automated: no

No rules selected

10.5.1: Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.

Description: Historical records of activity are available immediately to support incident response and are retained for at least 12 months.

Levels:

Automated: yes

Selections:

10.5: Audit log history is retained and available for analysis.

Description: None

Levels:

Automated: yes

Selections:

10.6.1: System clocks and time are synchronized using time-synchronization technology.

Description: Common time is established across all systems. Keeping time-synchronization technology current includes managing vulnerabilities and patching the technology according to PCI DSS Requirements 6.3.1 and 6.3.3.

Levels:

Automated: yes

Selections:

10.6.2: Systems are configured to the correct and consistent time.

Description: - One or more designated time servers are in use. - Only the designated central time server(s) receives time from external sources. - Time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC). - The designated time server(s) accept time updates only from specific industry-accepted external sources. - Where there is more than one designated time server, the time servers peer with one another to keep accurate time. - Internal systems receive time information only from designated central time server(s).

Levels:

Automated: yes

Selections:

10.6.3: Time synchronization settings and data are protected.

Description: - Access to time data is restricted to only personnel with a business need. - Any changes to time settings on critical systems are logged, monitored, and reviewed.

Levels:

Automated: yes

Selections:

10.6: Time-synchronization mechanisms support consistent time settings across all systems.

Description: None

Levels:

Automated: yes

Selections:

10.7.1: Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly.

Description: It includes but is not limited to failure of the following critical security control systems: - Network security controls. - IDS/IPS. - FIM. - Anti-malware solutions. - Physical access controls. - Logical access controls. - Audit logging mechanisms. - Segmentation controls (if used).

Levels:

Automated: no

No rules selected

10.7.2: Failures of critical security control systems are detected, alerted, and addressed promptly.

Description: It includes but is not limited to failure of the following critical security control systems: - Network security controls. - IDS/IPS. - Change-detection mechanisms. - Anti-malware solutions. - Physical access controls. - Logical access controls. - Audit logging mechanisms. - Segmentation controls (if used). - Audit log review mechanisms. - Automated security testing tools (if used).

Levels:

Automated: no

Selections:

10.7.3: Failures of any critical security controls systems are responded to restore security functions, ensure documentation, address security issues and prevent other failures.

Description: It includes but is not limited to: - Restoring security functions. - Identifying and documenting the duration (date and time from start to end) of the security failure. - Identifying and documenting the cause(s) of failure and documenting required remediation. - Identifying and addressing any security issues that arose during the failure. - Determining whether further actions are required as a result of the security failure. - Implementing controls to prevent the cause of failure from reoccurring. - Resuming monitoring of security controls.

Levels:

Automated: no

No rules selected

10.7: Failures of critical security control systems are detected, reported, and responded to promptly.

Description: None

Levels:

Automated: no

Selections:

11.1.1: All security policies and operational procedures that are identified in Requirement 11 are Documented, Kept up to date, In use and Known to all affected parties.

Description: None

Levels:

Automated: no

No rules selected

11.1.2: Roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood.

Description: None

Levels:

Automated: no

No rules selected

11.1: Processes and mechanisms for regularly testing security of systems and networks are defined and understood.

Description: None

Levels:

Automated: no

No rules selected

11.2.1: Authorized and unauthorized wireless access points are managed.

Description: None

Levels:

Automated: no

No rules selected

11.2.2: An inventory of authorized wireless access points is maintained, including a documented business justification.

Description: Unauthorized wireless access points are not mistaken for authorized wireless access points.

Levels:

Automated: no

No rules selected

11.2: Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.

Description: None

Levels:

Automated: no

No rules selected

11.3.1.1: All other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity's vulnerability risk rankings defined at Requirement 6.3.1) are managed.

Description: None

Levels:

Automated: no

No rules selected

11.3.1.2: Internal vulnerability scans are performed via authenticated scanning.

Description: None

Levels:

Automated: no

No rules selected

11.3.1.3: Internal vulnerability scans are performed after any significant change.

Description: None

Levels:

Automated: no

No rules selected

11.3.1: Internal vulnerability scans are performed.

Description: None

Levels:

Automated: no

No rules selected

11.3.2.1: External vulnerability scans are performed after any significant change.

Description: None

Levels:

Automated: no

No rules selected

11.3.2: External vulnerability scans are performed.

Description: None

Levels:

Automated: no

No rules selected

11.3: External and internal vulnerabilities are regularly identified, prioritized, and addressed.

Description: None

Levels:

Automated: no

No rules selected

11.4.1: A penetration testing methodology is defined, documented, and implemented by the entity.

Description: None

Levels:

Automated: no

No rules selected

11.4.2: Internal penetration testing is performed.

Description: None

Levels:

Automated: no

No rules selected

11.4.3: External penetration testing is performed.

Description: None

Levels:

Automated: no

No rules selected

11.4.4: Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected

Description: None

Levels:

Automated: no

No rules selected

11.4.5: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls.

Description: None

Levels:

Automated: no

No rules selected

11.4.6: Additional requirement for service providers only: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls.

Description: None

Levels:

Automated: no

No rules selected

11.4.7: Additional requirement for multi-tenant service providers only: Multi-tenant service providers support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4.

Description: Multi-tenant service providers support their customers' need for technical testing either by providing access or evidence that comparable technical testing has been undertaken.

Levels:

Automated: no

No rules selected

11.4: External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.

Description: None

Levels:

Automated: no

No rules selected

11.5.1.1: Additional requirement for service providers only: Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels.

Description: Mechanisms are in place to detect and alert/prevent covert communications with command-and-control systems. Alerts generated by these mechanisms are responded to by personnel, or by automated means that ensure that such communications are blocked. This requirement applies only when the entity being assessed is a service provider. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

11.5.1: Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or prevent intrusions into the network.

Description: None

Levels:

Automated: no

No rules selected

11.5: Network intrusions and unexpected file changes are detected and responded to.

Description: None

Levels:

Automated: yes

No rules selected

11.5.2: A change-detection mechanism (for example, file integrity monitoring tools) is deployed.

Description: None

Levels:

Automated: yes

Selections:

11.6.1: A change- and tamper-detection mechanism is deployed.

Description: None

Levels:

Automated: no

No rules selected

11.6: Unauthorized changes on payment pages are detected and responded to.

Description: None

Levels:

Automated: no

No rules selected

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.

Description: None

Levels:

Automated: no

No rules selected

12.1.2: The information security policy is updated and reviewed at least once every 12 months.

Description: None

Levels:

Automated: no

No rules selected

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.

Description: Personnel understand their role in protecting the entity's cardholder data.

Levels:

Automated: no

No rules selected

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.

Description: A designated member of executive management is responsible for information security.

Levels:

Automated: no

No rules selected

12.1: A comprehensive information security policy that governs and provides direction for protection of the entity's information assets is known and current.

Description: None

Levels:

Automated: no

No rules selected

12.2.1: Acceptable use policies for end-user technologies are documented and implemented.

Description: None

Levels:

Automated: no

No rules selected

12.2: Acceptable use policies for end-user technologies are defined and implemented.

Description: None

Levels:

Automated: no

No rules selected

12.3.1: For each PCI DSS requirement that specifies completion of a targeted risk analysis, the analysis is documented.

Description: None

Levels:

Automated: no

No rules selected

12.3.2: A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach

Description: None

Levels:

Automated: no

No rules selected

12.3.3: Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months.

Description: None

Levels:

Automated: no

No rules selected

12.3.4: Hardware and software technologies in use are reviewed at least once every 12 months.

Description: None

Levels:

Automated: no

No rules selected

12.3: Risks to the cardholder data environment are formally identified, evaluated, and managed.

Description: None

Levels:

Automated: no

No rules selected

12.4.1: Additional requirement for service providers only: Responsibility is established by executive management for the protection of cardholder data and a PCI DSS compliance program.

Description: None

Levels:

Automated: no

No rules selected

12.4.2.1: Additional requirement for service providers only: Reviews conducted in accordance with Requirement 12.4.2 are documented.

Description: None

Levels:

Automated: no

No rules selected

12.4.2: Additional requirement for service providers only: 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 procedures.

Description: Reviews are performed by personnel other than those responsible for performing the given task.

Levels:

Automated: no

No rules selected

12.4: PCI DSS compliance is managed.

Description: None

Levels:

Automated: no

No rules selected

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.

Description: All system components in scope for PCI DSS are identified and known.

Levels:

Automated: no

No rules selected

12.5.2.1: Additional requirement for service providers only: 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. At a minimum, the scoping validation includes all the elements specified in Requirement 12.5.2.

Description: The accuracy of PCI DSS scope is verified to be continuously accurate by comprehensive analysis and appropriate technical measures. This requirement applies only when the entity being assessed is a service provider. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

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.

Description: None

Levels:

Automated: no

No rules selected

12.5.3: Additional requirement for service providers only: 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.

Description: PCI DSS scope is confirmed after significant organizational change. This requirement applies only when the entity being assessed is a service provider. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

12.5: PCI DSS scope is documented and validated.

Description: None

Levels:

Automated: no

No rules selected

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.

Description: Personnel are knowledgeable about the threat landscape, their responsibility for the operation of relevant security controls, and are able to access assistance and guidance when required.

Levels:

Automated: no

No rules selected

12.6.2: The security awareness program is updated and reviewed at least once every 12 months.

Description: None

Levels:

Automated: no

No rules selected

12.6.3.1: Security awareness training includes awareness of threats and vulnerabilities that could impact the security of the CDE.

Description: None

Levels:

Automated: no

No rules selected

12.6.3.2: Security awareness training includes awareness about the acceptable use of end-user technologies in accordance with Requirement 12.2.1.

Description: Personnel are knowledgeable about their responsibility for the security and operation of end-user technologies and are able to access assistance and guidance when required. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

12.6.3: Personnel receive security awareness training upon hire and at least once every 12 months via multiple methods of communication.

Description: None

Levels:

Automated: no

No rules selected

12.6: Security awareness education is an ongoing activity.

Description: None

Levels:

Automated: no

No rules selected

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.

Description: The risk related to allowing new members of staff access to the CDE is understood and managed. For those potential personnel to be hired for positions such as store cashiers, who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only.

Levels:

Automated: no

No rules selected

12.7: Personnel are screened to reduce risks from insider threats.

Description: None

Levels:

Automated: no

No rules selected

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.

Description: Records are maintained of TPSPs and the services provided. The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entit's responsibility for its own PCI DSS compliance.

Levels:

Automated: no

No rules selected

12.8.2: Written agreements with TPSPs are maintained

Description: None

Levels:

Automated: no

No rules selected

12.8.3: An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.

Description: The capability, intent, and resources of a prospective TPSP to adequately protect account data are assessed before the TPSP is engaged.

Levels:

Automated: no

No rules selected

12.8.4: A program is implemented to monitor TPSPs' PCI DSS compliance status at least once every 12 months.

Description: The PCI DSS compliance status of TPSPs is verified periodically. Where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for example, via a firewall service), the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also "not in place" for the entity.

Levels:

Automated: no

No rules selected

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.

Description: Records detailing the PCI DSS requirements and related system components for which each TPSP is solely or jointly responsible, are maintained and reviewed periodically.

Levels:

Automated: no

No rules selected

12.8: Risk to information assets associated with third-party service provider (TPSP) relationships is managed.

Description: None

Levels:

Automated: no

No rules selected

12.9.1: Additional requirement for service providers only: TPSPs provide written agreements to customers that include acknowledgments that TPSPs 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 the TPSP could impact the security of the customer's cardholder data and/or sensitive authentication data.

Description: TPSPs formally acknowledge their security responsibilities to their customers. This requirement applies only when the entity being assessed is a service provider. The exact wording of an agreement will depend on the details of the service being provided, and the responsibilities assigned to each party. The agreement does not have to include the exact wording provided in this requirement.

Levels:

Automated: no

No rules selected

12.9.2: Additional requirement for service providers only: TPSPs support their customers' requests for information to meet Requirements 12.8.4 and 12.8.5.

Description: None

Levels:

Automated: no

No rules selected

12.9: Third-party service providers (TPSPs) support their customers' PCI DSS compliance.

Description: None

Levels:

Automated: no

No rules selected

12.10.1: An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident.

Description: None

Levels:

Automated: no

No rules selected

12.10.2: At least once every 12 months, the security incident response plan is reviewed, updated, and tested.

Description: None

Levels:

Automated: no

No rules selected

12.10.3: Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.

Description: Incidents are responded to immediately where appropriate.

Levels:

Automated: no

No rules selected

12.10.4.1: The frequency of periodic training for incident response personnel is defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.

Description: Incident response personnel are trained at a frequency that addresses the entity's risk. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

12.10.4: Personnel responsible for responding to suspected and confirmed security incidents are appropriately and periodically trained on their incident response responsibilities.

Description: Personnel are knowledgeable about their role and responsibilities in incident response and are able to access assistance and guidance when required.

Levels:

Automated: no

No rules selected

12.10.5: The security incident response plan includes monitoring and responding to alerts from security monitoring systems.

Description: None

Levels:

Automated: no

No rules selected

12.10.6: The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.

Description: The effectiveness and accuracy of the incident response plan is reviewed and updated after each invocation.

Levels:

Automated: no

No rules selected

12.10.7: Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected.

Description: None

Levels:

Automated: no

No rules selected

12.10: Suspected and confirmed security incidents that could impact the CDE are responded to immediately.

Description: None

Levels:

Automated: no

No rules selected

A1.1.1: Logical separation is implemented.

Description: - The provider cannot access its customers' environments without authorization. - Customers cannot access the provider's environment without authorization.

Levels:

Automated: no

No rules selected

A1.1.2: Controls are implemented such that each customer only has permission to access its own cardholder data and CDE.

Description: Customers cannot access other customers' environments.

Levels:

Automated: no

No rules selected

A1.1.3: Controls are implemented such that each customer can only access resources allocated to them.

Description: Customers cannot impact resources allocated to other customers.

Levels:

Automated: no

No rules selected

A1.1.4: The effectiveness of logical separation controls used to separate customer environments is confirmed at least once every six months via penetration testing.

Description: Segmentation of customer environments from other environments is periodically validated to be effective. The testing of adequate separation between customers in a multi-tenant service provider environment is in addition to the penetration tests specified in Requirement 11.4.6. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Levels:

Automated: no

No rules selected

A1.1: Multi-tenant service providers protect and separate all customer environments and data.

Description: None

Levels:

Automated: no

No rules selected

A1.2.1: Audit log capability is enabled for each customer's environment that is consistent with PCI DSS Requirement 10.

Description: None

Levels:

Automated: no

No rules selected

A1.2.2: Processes or mechanisms are implemented to support and/or facilitate prompt forensic investigations in the event of a suspected or confirmed security incident for any customer.

Description: Forensic investigation is readily available to all customers in the event of a suspected or confirmed security incident.

Levels:

Automated: no

No rules selected

A1.2.3: Processes or mechanisms are implemented for reporting and addressing suspected or confirmed security incidents and vulnerabilities.

Description: None

Levels:

Automated: no

No rules selected

A1.2: Multi-tenant service providers facilitate logging and incident response for all customers.

Description: None

Levels:

Automated: no

No rules selected

A2.1.1: Where POS POI terminals at the merchant or payment acceptance location use SSL and/or early TLS, the entity confirms the devices are not susceptible to any known exploits for those protocols.

Description: None

Levels:

Automated: no

No rules selected

A2.1.2: Additional requirement for service providers only: All service providers with existing connection points to POS POI terminals that use SSL and/or early TLS as defined in A2.1 have a formal Risk Mitigation and Migration Plan in place.

Description: None

Levels:

Automated: no

No rules selected

A2.1.3: Additional requirement for service providers only: All service providers provide a secure service offering.

Description: This requirement is not eligible for the customized approach. This requirement applies only when the entity being assessed is a service provider.

Levels:

Automated: no

No rules selected

A2.1: POI terminals using SSL and/or early TLS are confirmed as not susceptible to known SSL/TLS exploits.

Description: Appendix A2: Additional PCI DSS Requirements for Entities Using SSL/Early TLS for Card-Present POS POI Terminal Connections.

Levels:

Automated: no

No rules selected

A3.1.1: Responsibility is established by executive management for the protection of account data and a PCI DSS compliance program.

Description: None

Levels:

Automated: no

No rules selected

A3.1.2: A formal PCI DSS compliance program is in place.

Description: None

Levels:

Automated: no

No rules selected

A3.1.3: PCI DSS compliance roles and responsibilities are specifically defined and formally assigned to one or more personnel.

Description: None

Levels:

Automated: no

No rules selected

A3.1.4: Up-to-date PCI DSS and/or information security training is provided at least once every 12 months to personnel with PCI DSS compliance responsibilities (as identified in A3.1.3).

Description: None

Levels:

Automated: no

No rules selected

A3.1: A PCI DSS compliance program is implemented.

Description: Appendix A3: Designated Entities Supplemental Validation (DESV)

Levels:

Automated: no

No rules selected

A3.2.1: PCI DSS scope is documented and confirmed for accuracy at least once every three months and upon significant changes to the in-scope environment.

Description: None

Levels:

Automated: no

No rules selected

A3.2.2.1: Upon completion of a change, all relevant PCI DSS requirements are confirmed to be implemented on all new or changed systems and networks, and documentation is updated as applicable.

Description: None

Levels:

Automated: no

No rules selected

A3.2.2: PCI DSS scope impact for all changes to systems or networks is determined, including additions of new systems and new network connections.

Description: None

Levels:

Automated: no

No rules selected

A3.2.3: Changes to organizational structure result in a formal (internal) review of the impact to PCI DSS scope and applicability of controls.

Description: None

Levels:

Automated: no

No rules selected

A3.2.4: If segmentation is used, PCI DSS scope is confirmed.

Description: None

Levels:

Automated: no

No rules selected

A3.2.5.1: Data discovery methods are confirmed.

Description: None

Levels:

Automated: no

No rules selected

A3.2.5.2: Response procedures are implemented to be initiated upon the detection of cleartext PAN outside the CDE.

Description: None

Levels:

Automated: no

No rules selected

A3.2.5: A data-discovery methodology is implemented.

Description: None

Levels:

Automated: no

No rules selected

A3.2.6.1: Response procedures are implemented to be initiated upon the detection of attempts to remove cleartext PAN from the CDE via an unauthorized channel, method, or process.

Description: None

Levels:

Automated: no

No rules selected

A3.2.6: Mechanisms are implemented for detecting and preventing cleartext PAN from leaving the CDE via an unauthorized channel, method, or process.

Description: None

Levels:

Automated: no

No rules selected

A3.2: PCI DSS scope is documented and validated.

Description: None

Levels:

Automated: no

No rules selected

A3.3.1.2: Failures of any critical security control systems are responded to promptly.

Description: None

Levels:

Automated: no

No rules selected

A3.3.1: Failures of critical security control systems are detected, alerted, and addressed promptly.

Description: None

Levels:

Automated: no

No rules selected

A3.3.2: Hardware and software technologies are reviewed at least once every 12 months to confirm whether they continue to meet the organization's PCI DSS requirements.

Description: None

Levels:

Automated: no

No rules selected

A3.3.3: Reviews are performed at least once every three months to verify BAU activities are being followed.

Description: Reviews are performed by personnel assigned to the PCI DSS compliance program (as identified in A3.1.3).

Levels:

Automated: no

No rules selected

A3.3: PCI DSS is incorporated into business-as-usual (BAU) activities.

Description: None

Levels:

Automated: no

No rules selected

A3.4.1: User accounts and access privileges to in-scope system components are reviewed at least once every six months to ensure user accounts and access privileges remain appropriate based on job function, and that all access is authorized.

Description: None

Levels:

Automated: no

No rules selected

A3.4: Logical access to the cardholder data environment is controlled and managed.

Description: None

Levels:

Automated: no

No rules selected

A3.5.1: A methodology is implemented for the prompt identification of attack patterns and undesirable behavior across systems.

Description: None

Levels:

Automated: no

No rules selected

A3.5: Suspicious events are identified and responded to.

Description: None

Levels:

Automated: no

No rules selected