Document Diff - PCI Watch

Added p. 2

• New table 3.10 to capture truncation information relative to requirement 4B-1.8.

Added p. 21

• Flows and locations of encrypted account data

• Flows and locations of cleartext account data

• Flows and locations of truncated account data

• Location of critical system components (e.g., HSMs, Host Systems)

• All entities to which the Decryption Management Services connects for payment transmission or processing, including processors/acquirers

Note: The diagram should identify where merchant entities fit into the data flow without attempting to identify individual merchants. For example, encrypted account data could be illustrated as flowing between an icon that represents all merchant customers and an icon that represents the decryption environment. Document if any intermediate proxies exist between merchant customers and the decryption environment.

Provide any additional information below that is not adequately captured within the diagram(s). Otherwise, check No Additional Details. No Additional Details <Additional Details, as needed> <Insert Decryption Management Services Data Flow diagram(s) here>

Added p. 25

Note: All HSMs (or Host Systems used in hybrid decryption) used for account-data decryption in the decryption environment must be reviewed to verify their secure configuration and therefore cannot be sampled. Refer to the P2PE Standard for additional information.

Added p. 28

Decryption Management Services: P2PE Validation Requirements Summary of Findings (check one) In Place N/A Not in 4A Use approved decryption devices.

4A-1 Use approved decryption devices.

4B Secure the decryption environment.

4B-1 Maintain processes for securely managing the decryption environment.

4C Monitor the decryption environment and respond to incidents.

4C-1 Perform logging and monitor the decryption environment for suspicious activity and implement notification processes.

4D Implement secure, hybrid decryption processes. (Applicable to Hybrid Decryption Environments ONLY) 4D-1 Configure the Host System securely.

4D-2 Access controls for the Host System are configured securely.

4D-3 Non-console access to the Host System is configured securely.

4D-4 The physical environment of the Host System is secured.

Account data is processed using equipment and methodologies that ensure they are kept secure 1 Account data is processed in equipment that conforms to requirements for secure cryptographic devices (SCDs). Account data never appears in the clear outside of an SCD.

Added p. 29

Keys are conveyed or transmitted in a secure manner 8 Secret or private keys must be transferred by: a. Physically forwarding the key as at least two separate key shares or full-length components (hard copy, smart card, SCD) using different communication channels, or b. Transmitting the key in ciphertext form.

It is the responsibility of both the sending and receiving parties to ensure these keys are managed securely during transport.

Sending and receiving locations/entities are equally responsible for the physical protection of the materials involved.

These requirements also apply to keys moved between locations of the same organization.

Added p. 30

Key loading to HSMs and POI devices is handled in a secure manner 12 Secret and private keys must be input into hardware (host) security modules (HSMs) and Point of Interaction (POI) devices in a secure manner: a. Unencrypted secret or private keys must be entered into cryptographic devices using the principles of dual control and split knowledge. b. Key-establishment techniques using public-key cryptography must be implemented securely.

Added p. 30

Keys are used in a manner that prevents or detects their unauthorized usage 17 Unique, secret cryptographic keys must be in use for each identifiable link between host computer systems of two organizations or logically separate systems within the same organization.

Added p. 32

Equipment used to process account data and keys is managed in a secure manner 29 Equipment used to protect account data (e.g., POI devices and HSMs) must be placed into service only if there is assurance that the equipment has not been substituted or subjected to unauthorized modifications or tampering prior to the deployment of the device

•both prior to and subsequent to the loading of cryptographic keys

•and that precautions are taken to minimize the threat of compromise once deployed.

Requirements 30-1 and 30-2 are not used in P2PE Requirement 30-3 is not used in DMS 31 Procedures must be in place and implemented to protect any SCDs

•and ensure the destruction of any cryptographic keys or key material within such devices

•when removed from service, retired at the end of the deployment lifecycle, or returned for repair.

Requirements 32-1

• 32-9 are not used in DMS.

Added p. 32

5A-1 Account data is processed using algorithms and methodologies that ensure they are kept secure 5A-1 Account data is protected with appropriate cryptographic algorithms, key sizes and strengths, and key-management processes.

5H For hybrid decryption solutions: Implement secure hybrid-key management. (Applicable to Hybrid Decryption Environments ONLY)

5I-1 For component providers performing key management in conjunction with device-management or decryption- management services, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.

4A-1.1.a Examine documented procedures and interview personnel to verify that all account-data decryption operations are performed only by the FIPS-approved and/or PTS-approved HSMs identified in 1-3.

Documented procedures examined: <Report Findings Here> Personnel interviewed: <Report Findings Here> 4A-1.1.1 REMOVED 4A-1.1.2 If FIPS-approved HSMs are used for account-data decryption and related processes, the HSM must use the FIPS-approved cryptographic primitives, data-protection mechanisms, and key-management processes for account data decryption and related processes.

Note: Solution providers operating HSMs in non-FIPS mode or …

Added p. 37

Solution-provider documentation examined: <Report Findings Here> 4B-1.2 Procedures must be implemented to provide secure administration of decryption devices by authorized personnel, including but not limited to:

• Assigning administrative roles and responsibilities only to specific, authorized personnel

• Assigning administrative roles and responsibilities only to specific, authorized personnel

Added p. 37

• Console and non-console administration

Added p. 37

• Use of HSM commands 4B-1.2.a Examine documented procedures to verify secure administration by authorized personnel is defined for decryption devices including:

• Management of the user interface

Added p. 37

• Use of HSM commands Documented procedures examined: <Report Findings Here> 4B-1.2.b Observe authorized personnel performing device-administration operations to verify secure administration procedures are implemented for the following:

• Use of HSM commands Describe how the observation verified that secure administration procedures are implemented for the following:

Files/records examined: <Report Findings Here> Describe how the observation verified that only authorized and assigned personnel perform decryption-device administration operations:

<Report Findings Here> 4B-1.3 Only authorized users/processes have the ability to make function calls to the HSM•e.g., via the HSM’s application program interfaces (APIs).

Note: For example, require authentication for use of the HSMs APIs and secure all authentication credentials from unauthorized access. Where an HSM is unable to authenticate use of the API, limit the exposure of the HSM to a trusted host via a dedicated physical link that authorizes access on behalf of the HSM over the trusted channel (e.g., high-speed serial or dedicated Ethernet).

4B-1.3.a …

Added p. 43

• Cryptographic signing (or similar) prior to installation by authorized personnel using dual control

• Cryptographic signing (or similar) prior to installation by authorized personnel using dual control

• Cryptographic authentication by the HSM

• Cryptographic authentication by the HSM

• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data

• Approval of functionality by authorized personnel prior to implementation

• Approval of functionality by authorized personnel prior to implementation

• Documentation for all new installations or updates to whitelist functionality that includes the following:

• Documentation for all new installations or updates to whitelist functionality that includes the following:

Added p. 43

• Who approved the new installation or updated functionality prior to release

• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 4B-1.9.a Examine documented policies and procedures to verify that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment ensures that the ONLY allowed output of cleartext account data is for non-PCI payment brand account/card data, and includes the following:

• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.

• Who approved the new installation or updated functionality prior to release - Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Documented policies and procedures examined:

Added p. 44

Personnel interviewed <Report Findings Here> Describe how application and system configurations observed verified that whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows the output of cleartext account data for non-PCI payment brand account/card data:

<Report Findings Here> 4B-1.9.c Perform test transactions to verify that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows output cleartext account for non- PCI payment brand account/card data.

Describe how test transactions verified that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows output cleartext account for non-PCI payment brand account/card data:

<Report Findings Here> 4B-1.9.1 REMOVED 4B-1.9.2 If whitelisting is supported, new installations of, or updates to, whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must be:

Added p. 44

• Cryptographically authenticated by the HSM 4B-1.9.2 Observe the process for new installations or updates to whitelisting functionality and interview personnel to verify that additions or updates to whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment are performed as follows:

• Cryptographically authenticated by the HSM Personnel interviewed: <Report Findings Here> Describe how the observed process verified that additions or updates to whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment are performed as follows:

• Cryptographically authenticated by the HSM <Report Findings Here>

• Coverage for both new installations and updates to such functionality

• Who approved the new installation or update prior to release

• Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data 4B-1.9.3 Examine records of both new and updated whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment, …

Added p. 46

• Unauthorized logical alterations (e.g., configurations, access controls)

• Unauthorized logical alterations (e.g., configurations, access controls)

• Unauthorized use of sensitive functions (e.g., key-management functions)

• Unauthorized use of sensitive functions (e.g., key-management functions)

Added p. 46

• Unauthorized use of the HSM API 4C-1.2.a Examine documented procedures to verify mechanisms are defined to detect and respond to potential security incidents, including:

• Unauthorized use of the HSM API Documented procedures examined: <Report Findings Here>

• Unauthorized logical alterations (configuration, access controls)

• Unauthorized use of sensitive functions (e.g., key management functions)

<Report Findings Here> 4C-1.3 Mechanisms must be implemented to detect encryption failures, including at least the following.

Note: Although Domain 4 is concerned with the decryption environment, not the encryption environment, all traffic received into the decryption environment must be actively monitored to confirm that the POI devices in the merchant’s encryption environment is not outputting cleartext account data through some error or misconfiguration.

• Procedures are defined to detect encryption failures, and include 4C- 1.3.1 through 4C-1.3.4 below.

• Procedures include immediate notification upon detection of a cryptographic failure, for each 4C-1.3.1 through 4C-1.3.3 below.

4C-1.3.1.a Observe implemented processes to verify controls …

Added p. 50

• Identification of affected merchant, including specific sites/locations if applicable

• Identification of affected merchant, including specific sites/locations if applicable

Added p. 50

• Details of whether any account data was transmitted from the POI device during any identified time that encryption was malfunctioning or disabled 4C-1.4.a Examine documented procedures to verify they include procedures for identifying the source and maintaining a record, of all suspicious activity, to include at least the following:

• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled Documented procedures examined: <Report Findings Here>

• Identification of affected merchant, and specific sites/locations if applicable

• Identification of affected merchant, and specific sites/locations if applicable

• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled Responsible personnel interviewed: <Report Findings Here> Describe how the implemented controls verified that the source of any suspicious activity is identified, and records are maintained to include the following:

• Details of whether any account …

Added p. 52

4C-1.5.a Examine documented procedures to verify mechanisms are defined to provide immediate notification of suspicious activity to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if decryption services are being performed on behalf of other P2PE solution providers).

Documented procedures examined: <Report Findings Here> 4C-1.5.b Interview personnel and observe implemented mechanisms to verify that immediate notification of suspicious activity is provided to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if decryption services are being performed on behalf of other P2PE solution providers).

Personnel interviewed: <Report Findings Here> Describe how the implemented mechanisms observed verified that immediate notification of suspicious activity is provided to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if decryption services are being performed on behalf of other P2PE solution providers):

<Report Findings Here> Hybrid Decryption Environments (where HSMs are required for cryptographic key-management functions but allow for non-SCD “Host …

Added p. 54

• The necessary services, protocols, daemons etc. must be documented and justified, including description of the enabled security features for these services etc.

• Functions not related to transaction processing must be disabled, or isolated (e.g., using logical partitions), from transaction processing

Note: “Isolated” means that the Host System must not be accessed, modified or intercepted by other processes.

4D-1.2.a Examine network and system configuration settings to verify the host processing system is isolated, or dedicated, to processing payment transactions, with only necessary services, protocols, daemons, etc. enabled.

Describe how network and system configuration settings verified that the host processing system is isolated, or dedicated, to processing payment transactions, with only necessary services, protocols, daemons, etc. enabled:

<Report Findings Here> 4D-1.2.b Examine the documented record of services, protocols, daemons etc. that are required by the Host System and verify that each service includes justification and a description of the enabled security feature.

Documented record of services, …

Added p. 55

4D-1.4.a Examine documented policies and procedures to verify that all application software installed on the Host System must have a business justification and be duly authorized.

<Report Findings Here> 4D-1.4.b Examine change control and system configuration records to verify that all application software installed on the Host System is authorized.

Change control and system configuration records examined:

<Report Findings Here> 4D-1.4.c Examine Host System and compare with system configuration standards to verify that all software installed on the Host System has a defined business justification.

Describe how the Host System and system configuration standards verified that all software installed on the Host System has a defined business justification:

<Report Findings Here> 4D-1.5 A process, either automated or manual, must be in place to prevent and/or detect and alert, any unauthorized changes to applications/software on the Host System.

4D-1.5.a Examine documented policies and procedures to verify that a process is defined to prevent and/or detect and alert …

Added p. 55

<Report Findings Here> 4D-1.5.b Interview personnel and observe system configurations to verify that controls are implemented to prevent and/or detect and alert personnel, upon any unauthorized changes to applications/software.

Personnel interviewed: <Report Findings Here> Describe how the system configurations observed verified that controls are implemented to prevent and/or detect and alert personnel, upon any unauthorized changes to applications/software:

<Report Findings Here> 4D-1.5.c Examine output from the implemented process to verify that any unauthorized changes to applications/software are either prevented or detected with an alert generated that is immediately investigated.

Describe how the output from the implemented process verified that any unauthorized changes to applications/software are either prevented or detected with an alert generated that is immediately investigated:

Added p. 56

• Testing integrity of firmware

• Testing integrity of any security functions critical to the secure operation of the Host System 4D-1.6.a Examine Host System configuration settings, and vendor/solution provider documentation to verify that the Host System performs a self-test when it is powered up to ensure its integrity before use. Verify the self-test includes the following:

• Testing integrity of software/firmware

• Testing integrity of software/firmware

• Testing integrity of any security functions critical to the secure operation of the Host System Vendor/solution provider documentation examined:

<Report Findings Here> Describe how Host System configuration settings and vendor/solution provider documentation verified that the Host System performs a self-test when it is powered up to ensure its integrity before use, and that the self-test includes the following:

• Testing integrity of any security functions critical to the secure operation of the Host System <Report Findings Here> 4D-1.6.b Review logs/audit trails from when the Host System has previously …

Added p. 57

4D-1.7.a Examine Host System configuration settings and vendor/solution provider documentation to verify that the Host system performs a self-test when a security-impacting function or operation is modified.

Vendor/solution provider documentation examined:

<Report Findings Here> Describe how Host System configuration settings and vendor/solution provider documentation verified that the Host system performs a self-test when a security- impacting function or operation is modified:

<Report Findings Here> 4D-1.7.b Interview personnel and examine logs/records for when a security-impacting function, or operation, has been modified to verify that the Host System performs a self-test.

Personnel interviewed: <Report Findings Here> Describe how logs/records verified that the Host System performs a self-test when a security-impacting function or operation is modified:

Added p. 58

• Failure of a security function or mechanism

Note: An “error state” identifies the Host System has encountered an issue that requires a response action. To prevent potential damage or compromise, the system must cease cryptographic operations until the issue is resolved and the host is returned to a normal processing state.

4D-1.8.a Examine Host System configuration settings and documentation to verify that the host enters an error state and generates an alert in the event of the following:

• Failure of a security function or mechanism Vendor/solution provider documentation examined:

<Report Findings Here> Describe how Host System configuration settings and vendor/solution provider documentation verified that the host enters an error state and generates an alert in the event of the following:

• Failure of a security function or mechanism <Report Findings Here> 4D-1.8.b Interview personnel and examine logs/records of actual or test alerts to verify that alerts are generated and received when the Host …

Added p. 59

4D-1.9.a Examine documented procedures to verify alerts generated from the Host System are documented and result in notification to authorized personnel and initiate a response procedure.

Documented procedures examined: <Report Findings Here> 4D-1.9.b Examine system configurations and records of documented alert events to verify alerts generated from the Host System are documented.

Records of documented alert events examined:

<Report Findings Here> Describe how system configurations and records of documented alert events verified that alerts generated from the Host System are documented:

<Report Findings Here> 4D-1.9.c Examine a sample of documented alert events and interview personnel assigned with security-response duties to verify alerts initiate a response procedure.

Sample of documented alert events examined:

Added p. 60

• During diagnostics of cryptographic operations 4D-1.10.a Examine documented procedures to verify that controls/processes are in place to ensure that the Host System does not perform any cryptographic operations:

• During diagnostics of cryptographic operations Documented procedures examined: <Report Findings Here> 4D-1.10.b Examine Host System configuration settings and interview personnel to verify that controls and/or procedures are in place to ensure that the Host System does not perform any cryptographic operations:

• During diagnostics of cryptographic operations Personnel interviewed: <Report Findings Here> Describe how Host System configuration settings verified that controls and/or procedures are in place to ensure that the Host System does not perform any cryptographic operations:

• During diagnostics of cryptographic operations <Report Findings Here>

Added p. 61

4D-1.11.a Examine configuration documentation to verify that access controls are defined to ensure all source code and executable code for cryptographic software and firmware is protected from unauthorized disclosure and unauthorized modification.

Configuration documentation examined: <Report Findings Here> 4D-1.11.b Observe access controls for cryptographic software and firmware to verify that all source code and executable code is protected from unauthorized disclosure and unauthorized modification.

Describe how the access controls for cryptographic software and firmware observed verified that all source code and executable code is protected from unauthorized disclosure and unauthorized modification:

<Report Findings Here> 4D-1.12 The cleartext data-decryption keys must not be accessible to any processes or functions not directly required for decryption operations.

4D-1.12.a Examine documentation, including data-flow diagrams, to verify that cleartext decryption keys are not accessible to any processes or functions not directly required for decryption operations.

Solution provider documentation examined (including data-flow diagrams):

<Report Findings Here> 4D-1.12.b Examine Host System configurations and …

Added p. 62

4D-1.13.a Examine documented key-management policies and procedures to verify cleartext data-decryption keys must only be accessible to authorized personnel with a defined job-related need to access the keys.

Added p. 62

<Report Findings Here> 4D-1.13.b Examine Host System configuration settings and verify that cleartext data-decryption keys are only accessible to authorized personnel with a defined job-related need to access the keys.

Describe how the Host System configuration settings verified that cleartext data-decryption keys are only accessible to authorized personnel with a defined job-related need to access the keys:

<Report Findings Here> 4D-1.14 The Host System must not write cleartext cryptographic keys to persistent storage (e.g., hard drives, removable storage, flash drives etc.) except for the following:

• Memory “swap/page” file purposes

• “Core dumps” of memory required for troubleshooting In the above circumstances, the following conditions apply:

4D-1.14.a Examine documented configuration procedures to verify that the Host System must not write cleartext cryptographic keys to persistent storage (e.g., hard drives, removable storage, flash drives etc.) except for the following:

• Memory swap/page file purposes

<Report Findings Here> 4D-1.14.b Examine Host System configuration settings and interview personnel to verify …

Added p. 64

4D-1.14.4.a Examine documented procedures to verify that controls are defined to ensure that the access to, and use of, any tools used for troubleshooting or forensics, are controlled and authorized by management.

Documented procedures examined: <Report Findings Here> 4D-1.14.4.b Observe the process for accessing the tools used for troubleshooting or forensics, and verify that they are controlled and authorized by management in accordance with the documented procedure.

Describe how the process for accessing the tools used for troubleshooting or forensics verified that they are controlled and authorized by management in accordance with the documented procedure:

<Report Findings Here> 4D-1.14.4.c Observe the process for using the tools used for troubleshooting or forensics, and verify that they are controlled and authorized by management in accordance with the documented procedure.

Describe how the process for using the tools used for troubleshooting or forensics verified that they are controlled and authorized by management in accordance with the documented …

Added p. 65

• Core dumps must be securely deleted immediately after analysis

• Memory swap/page files must be securely deleted upon system shut down or reset 4D-1.14.5.a Examine documented procedures to verify that it defines a process for securely deleting swap/page files and core dumps at the required times:

• Core dumps must be securely

• deleted immediately after analysis

• Memory swap/page files must be securely

• deleted upon system shut down or reset Documented procedures examined: <Report Findings Here> 4D-1.14.5.b Test, through the use of forensic tools and/or methods, that the secure procedure removes swap/page files and core dumps, in accordance with industry-accepted standards for secure deletion of data.

Describe the forensic tools and/or methods used to verify that the secure procedure removes swap/page files and core dumps, in accordance with industry-accepted standards for secure deletion of data:

<Report Findings Here> 4D-2.1 Host user passwords must be changed at least every 30 days.

Note: This requirement applies to …

Added p. 66

• Have equivalent strength/complexity 4D-2.2.a Examine documented policies and procedures to verify that user passwords must:

• Have equivalent strength/complexity Documented policies and procedures examined:

<Report Findings Here> 4D-2.2.b Examine Host System (s) configuration settings to verify that user passwords:

• Have equivalent strength/complexity Describe how the Host System configuration settings verified that user passwords:

• Have equivalent strength/complexity <Report Findings Here>

Added p. 67

4D-2.3.a If log-on security tokens are used, observe the security tokens in use to verify that they have an associated usage-authentication mechanism, such as a biometric or associated PIN or password/passphrase to enable their usage.

Log-on security tokens in use: <Report Findings Here> Describe how log-on security tokens in use verified that an associated usage- authentication mechanism is in place to enable their usage:

<Report Findings Here> 4D-2.3.b Examine token-configuration settings to verify parameters are set to require that PINs or password/passphrases be at least ten alphanumeric characters in length, or equivalent.

Describe how the token-configuration settings examined verified that parameters are set to require that PINs or password/passphrases be at least ten alphanumeric characters in length, or equivalent:

<Report Findings Here> 4D-2.4 User accounts must be locked out of the Host System after not more than five failed attempts.

4D-2.4.a Examine documented policies and procedures to verify that authentication parameters on the Host System …

Added p. 68

• auditing of host functions 4D-2.5.a Examine documented access-control procedures to verify they define, at a minimum, the following roles:

• auditing of host functions Documented access-control procedures examined:

<Report Findings Here> 4D-2.5.b Examine the Host System configuration settings to verify that role-based access control is enforced and, at a minimum, the following roles are defined:

• auditing of host functions Describe how the Host System configuration settings verified that role-based access control is enforced and, at a minimum, the following roles are defined:

• auditing of host functions <Report Findings Here> 4D-2.5.c Interview a sample of users for each role to verify the assigned role is appropriate for their job function.

Sample of users for each role interviewed: <Report Findings Here>

Added p. 69

The following conditions must be applied:

4D-2.6.1 A Host System user must not be permitted to audit their own activity on the Host System.

4D-2.6.1.a Examine documented procedures to verify that a Host System user is not permitted to audit their own activity on the Host System.

Documented procedures examined: <Report Findings Here> 4D-2.6.1.b Interview audit personnel to verify that a Host System user is not permitted to audit their own activity on the Host System.

Audit personnel interviewed: <Report Findings Here> 4D-2.6.2 A Host System administrator must use their operator-level account when performing non-administrative functions.

4D-2.6.2.a Examine documented policies and procedures to verify a Host System administrator is not permitted to use their administrative-level account when performing non-administrative functions.

<Report Findings Here> 4D-2.6.2.b Interview and observe a Host System administrator to verify they use their operator-level account when performing non-administrative functions.

Host System administrator interviewed: <Report Findings Here> Describe how the observation of the Host System …

Added p. 70

• Ensuring all changes to access privileges result in an audit log 4D-2.7.a Examine documented policies and procedures to verify that changes to a user’s access privileges are managed:

• Ensuring all changes to access privileges result in an audit log Documented policies and procedures examined:

<Report Findings Here> 4D-2.7.b Observe the process required to change a user’s access privileges and verify that it is managed:

• Ensuring all changes to access privileges result in an audit log Describe how the observed process to change a user’s access privileges verified that it is managed:

• Using a formal change-control procedure.

• Requiring the participation of at least two persons. Therefore, the party making the change cannot authorize the change on their own.

• Ensuring all changes to access privileges result in an audit log.

<Report Findings Here> 4D-2.7.c Examine the Host System configuration settings and, for a sample of user accounts, verify that any changes to their …

Added p. 71

4D-2.8.a Examine documented policies and procedures to verify that access privileges are reviewed, at a minimum, on a quarterly basis to ensure that the access privileges for personnel authorized to access the decryption environment, the Host System, and Host System software required by their position and job function, are correctly assigned.

<Report Findings Here> 4D-2.8.b Examine records and interview personnel to verify that access privileges are reviewed, at a minimum, on a quarterly basis.

Personnel interviewed: <Report Findings Here> Records examined: <Report Findings Here> 4D-2.9 Tamper-detection mechanisms must be implemented on the host, to include an alert generation upon opening of the Host System case, covers and/or doors.

4D-2.9.a Examine Host System documentation to verify that tamper- detection mechanisms are defined for the Host System, including the generation of an alert upon opening of the Host System case, covers and/or doors.

Host System documentation examined: <Report Findings Here> 4D-2.9.b Observe tamper-detection mechanisms on the …

Added p. 72

4D-3.1.a For a sample of systems that are authorized to connect to the Host System via a non-console connection, examine configuration settings to verify that access to the Host System is provided through the use of strong cryptography and security protocols.

Sample of systems examined: <Report Findings Here> Describe how the configuration settings examined verified that access to the Host System is provided through the use of strong cryptography and security protocols:

<Report Findings Here> 4D-3.1.b Examine the configuration settings of system components to verify that all traffic transmitted over the secure channel uses strong cryptography.

Describe how the configuration settings of system components verified that all traffic transmitted over the secure channel uses strong cryptography:

<Report Findings Here> 4D-3.2 Non-console access to the Host System must not provide access to any other service, or channel, outside of that used to connect to the Host, e.g., “split tunneling.” 4D-3.2.a Examine the configuration settings of …

Added p. 73

4D-3.3.a Inspect the configuration settings of the Host System and/or the device permitted to connect to the Host System, to verify that multi-factor authentication is required for non-console access to the Host System.

Describe how the configuration settings of the Host System and/or the device permitted to connect to the Host System verified that multi-factor authentication is required for non- console access to the Host System:

<Report Findings Here> 4D-3.3.b Observe a Host System administrator log on to the device that provides non-console access to the Host System to verify that multi-factor authentication is required.

Describe how the Host System administrator’s log on to the device that provides non- console access to the Host System verified that multi-factor authentication is required:

<Report Findings Here> 4D-3.4 Non-console connections to the Host System must only be permitted from authorized systems.

4D-3.4.a Examine documented policies and procedures to verify that a process is defined to authorize systems for …

Added p. 74

4D-3.5.1 Examine solution provider documentation, including PCI DSS ROC and/or Attestation of Compliance (AOC), data-flow diagrams, policies and, system configuration standards, to verify that the system authorized for non-console access meets all applicable PCI DSS requirements.

Solution provider documentation examined (including PCI DSS ROC and/or AOC):

<Report Findings Here> 4D-3.5.2 The network/system that facilitates non-console access to the Host System must:

• Originate from and be managed by the solution provider

• Originate from and be managed by the solution provider

• Meet all applicable PCI DSS requirements 4D-3.5.2 Examine solution provider documentation, including PCI DSS ROC and/or Attestation of Compliance (AOC), data-flow diagrams, policies and, system configuration standards, to verify that the network/system that facilitates non-console access to the Host System must:

• Meet all applicable PCI DSS requirements Solution provider documentation examined (including PCI DSS ROC and/or AOC):

<Report Findings Here> 4D-3.6 Users with access to non-console connections to the Host System must be authorized …

Added p. 75

4D-3.7.a Examine documented policies and procedures to verify that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity.

<Report Findings Here> 4D-3.7.b Examine the system configuration settings to verify that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity.

Describe how system configuration settings verified that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity:

<Report Findings Here> 4D-4.1 The Host System must be located within a physically secure room that is dedicated to decryption operations and transaction processing.

Note: Where “secure room” is referred to in this section, these controls can be met at room level, rack level, or a combination of both. Whichever way the requirements are applied, they should ensure that access the Host System is appropriately secured, whether in a secure room or a secure rack. For example, access to systems in a rack should …

Added p. 76

4D-4.2.a Examine documented policies and procedures to verify that all individuals must be identified and authenticated before being granted access to the secure room.

<Report Findings Here> 4D-4.2.b Examine physical access controls to verify that all individuals are identified and authenticated before being granted access to the secure room.

Physical access controls examined: <Report Findings Here> 4D-4.2.c Observe authorized personnel entering the secure room to verify that all individuals are identified and authenticated before being granted access.

Describe how observation of authorized personnel entering the secure room verified that all individuals are identified and authenticated before being granted access:

Added p. 77

• Logs must be retained for a minimum of three years

• Logs must be regularly reviewed by an authorized person who does not have access to the secure room or to the systems therein

• Log reviews must be documented

• Logs must include but not be limited to:

• Logs of access to the room from a badge access system

• Logs of access to the room from a manual sign-in sheet 4D-4.3.a Examine documented policies and procedures to verify all physical access to the secure room must be monitored and logs must be maintained. Policies and procedures must require the following:

• Logs are retained for a minimum of three years

• Logs are regularly reviewed by an authorized person who does not have access to the secure room or to the systems therein

• Log reviews are documented

• Log reviews are documented

• Logs include at a minimum:

• Logs include at a minimum:

• Access to …

Added p. 78

4D-4.4.a Examine physical access controls to verify that dual access is enforced.

Physical access controls examined: <Report Findings Here> 4D-4.4.b Observe authorized personnel entering the secure room to verify that dual access is enforced.

<Report Findings Here> 4D-4.5 Physical access must be only permitted to designated personnel with defined business needs and duties.

4D-4.5.a Examine documented policies and procedures to verify that physical access to the secure room is only permitted to designated personnel with defined business needs and duties.

<Report Findings Here> 4D-4.5.b Examine the list of designated personnel and interview responsible personnel to verify that only personnel with defined business needs and duties are permitted access to the secure room.

Documented list of designated personnel: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 4D-4.5.c Examine physical access controls to verify that physical access to the secure room is only permitted to pre-designated personnel with defined business needs and duties.

Describe how physical access …

Added p. 79

• Access to the Host System and HSM(s)

Note: Motion-activated systems that are separate from the intrusion-detection system may be used.

4D-4.6.a Examine CCTV configuration and review a sample of recordings to verify that CCTV monitoring is in place on a 24 hour basis, and covers, at a minimum, the following areas:

• Access to the Host System and HSM(s) Sample of CCTV recordings examined: <Report Findings Here> Describe how CCTV configurations observed verified that CCTV monitoring is in place on a 24 hour basis, and covers, at a minimum, the following areas:

• Access to the Host System and HSM(s) <Report Findings Here> 4D-4.6.b If CCTV is motion-activated, observe system configurations for the motion-activated systems to verify they are separate from the intrusion- detection system.

Describe how system configurations for the motion-activated systems verified that they are separate from the intrusion-detection systems:

<Report Findings Here> 4D-4.7 Surveillance cameras must not be configured to allow the …

Added p. 81

Note: Visible spectrum lighting may not be necessary if the cameras do not require such lighting to capture images (e.g., when infrared cameras are used).

4D-4.10.a Observe the secure room to verify that continuous or motion- activated lighting is provided for the cameras monitoring the secure room.

Describe how the observed secure room verified that continuous or motion-activated lighting is provided for the cameras monitoring the secure room:

<Report Findings Here> 4D-4.10.b Examine a sample of recorded CCTV images to verify that appropriate lighting is provided when persons are present in the secure room.

Sample of recorded CCTV images examined:

<Report Findings Here> 4D-4.11 A 24/7 physical intrusion-detection system must be in place for the secure room (e.g., motion detectors when unoccupied). This must be connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.

4D-4.11.a Examine security policies and procedures to verify they require:

• Continuous (24/7) physical intrusion-detection …

Added p. 82

4D-4.12.a Observe all windows in the secure room to verify they are locked and protected by alarmed sensors.

Identify the P2PE Assessor who confirms all windows in the observed secure room are locked and protected by alarmed sensors:

<Report Findings Here> 4D-4.12.b Examine configuration of window sensors to verify that the alarm mechanism is active.

Describe how configuration of window sensors verified that the alarm mechanism is active:

<Report Findings Here> 4D-4.13 Any windows must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.

4D-4.13 Observe all windows in the secure areas to verify they are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.

Identify the P2PE Assessor who confirms all windows in the observed secure room are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room:

<Report Findings Here> 4D-4.14 Access-control and monitoring systems must be connected to an uninterruptible power source …

Added p. 84

Note: This may be done by either automated or manual mechanisms.

4D-4.19.a Examine documented procedures to verify that mechanisms are defined for synchronizing the time and date stamps of the access, intrusion-detection, and monitoring (camera) systems.

Documented procedures examined: <Report Findings Here> 4D-4.19.b Examine system configurations for access, intrusion-detection, and monitoring (camera) systems to verify that time and date stamps are synchronized.

Describe how system configurations for access, intrusion-detection, and monitoring (camera) systems verified that time and date stamps are synchronized:

<Report Findings Here> 4D-4.19.c Examine a sample of logs from the access, intrusion-detection, and monitoring (camera) systems to verify log time and date stamps are synchronized.

Sample of logs from the access, intrusion- detection, and monitoring (camera) systems:

<Report Findings Here> 4D-4.19.1 If a manual synchronization process is used, synchronization must occur at least quarterly, and documentation of the synchronization must be retained for at least a one-year period.

4D-4.19.1.a If a manual synchronization process is …

Added p. 85

• A door that is contact monitored and fitted with automatic closing or locking devices

• A door that is contact monitored and fitted with automatic closing or locking devices

• An airlock entrance system 4D-4.20 Observe authorized personnel entering the secure room to verify that a mechanism is in place to ensure the door is not left open.

• An airlock entrance system Describe how the observation of authorized personnel entering the secure room verified that a mechanism is in place to ensure the door is not left open:

<Report Findings Here> 4D-4.21 An audible alarm must sound if the entrance to the secure room remains open for more than 30 seconds.

4D-4.21.a Examine secure room entry mechanisms to verify that an audible alarm is configured to sound if the entrance remains open for more than 30 seconds.

Identify the secure room entry mechanisms examined:

<Report Findings Here> 4D-4.21.b Observe authorized personnel entering the secure room …

Added p. 86

Indicate for this submission, whether the vendor is a P2PE Component Provider. (yes/no).

<Report Findings Here> If “yes”, complete 4E-1.1 to 4E-1.2.b (otherwise leave blank).

Added p. 86

• Providing reports annually and upon significant changes

• Details of any suspicious activity that occurred, per 4C-1.2 Component provider’s documented procedures examined:

• Types/models of HSMs

• Number of HSMs deployed and description of any changes since last report

• Details of any suspicious activity that occurred, per 4C-1.2 Identify reports reviewed: <Report Findings Here> 4E-1.2 Component Providers must manage and monitor changes to decryption-management services and notify solution providers upon occurrence of any of the following:

Added p. 87

Note: Adding or removing HSM types may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution.

4E-1.2.a Examine component provider’s documented procedures and interview responsible component-provider personnel, and confirm that processes include notifying the solution provider upon occurrence of the following:

• Additions and/or removal of HSM types Component provider’s documented procedures examined:

<Report Findings Here> Responsible component provider personnel interviewed:

• Additions and/or removal of HSM types Identify reports reviewed: <Report Findings Here>

For each PCI-approved HSM used in the solution, describe how the HSM device configurations observed verified that all of the device characteristics at 1-4.a match the PTS listing:

Added p. 89

• The FIPS 140 Approval Number For each FIPS-approved HSM used in the solution, describe how the HSM device configurations observed verified that all of the device characteristics at 1-4.b match the FIPS140-2 Level 3 (or higher) approval listing:

• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22.

<Report Findings Here> 6-1 Implement security controls, including dual control and tamper detection, to prevent the unauthorized disclosure of keys or key components.

Added p. 99

<Report Findings Here> 6-3.7 The CCTV cameras must be positioned to monitor:

Added p. 101

• Examine logs of past destructions and deletions to verify that procedures are followed.

Added p. 108

- They define how the details of the package serial number are to be transmitted - There is a requirement that the package serial number is to be sent separately from the package itself - Each component is to be sent to/from only the custodian(s) authorized for the component - At least two communication channels are used to send the components of a given key (not just separation by sending on different days) - Prior to the use of the components, the serial numbers are to be

• The details of the serial number of the package were transmitted separately from the package itself - At least two communication channels were used to send the components of a given key (not just separation by sending on different days) - Each component was sent to/from only the custodian(s) authorized for the component - Prior to the use of the component, the serial …

Added p. 109

<Report Findings Here> Records of key conveyances examined:

• Only designated custodians can send/receive the component or share

Added p. 114

<Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 9-1 During the process to convey it, any single cleartext secret or private key component/share must at all times be either:

• contained within a physically secure SCD Responsible personnel interviewed:

<Report Findings Here> 9-2.b Interview responsible personnel and observe processes to verify that all packaging or mailers containing cleartext key components are examined for evidence of tampering before being opened.

• Any keys encrypted under this (combined) key Responsible personnel interviewed:

• Upon receipt, check the tamper-evident packaging for signs of tamper prior to opening the tamper-evident packaging containing the key component Check the serial number of the tamper-evident packaging upon receipt of a component package.

• Place the key component into pre-numbered tamper-evident packaging for transmittal

• Place the key component into pre-numbered tamper-evident packaging for transmittal

Logs examined: <Report Findings Here> Describe how the implemented mechanisms and processes observed verified that only the authorized key …

Added p. 122

- TDEA keys used for encrypting keys must be at least triple-length keys (have an effective bit strength of 112 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key- encipherment - A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength - TDEA keys are not used to protect AES keys - TDEA keys are not be used to encrypt keys greater in strength than 112 bits - RSA keys encrypting keys greater in strength than 80 bits have a bit strength at least 112 bits Documented procedures examined:

<Report Findings Here> Appropriate personnel interviewed:

<Report Findings Here> Describe how the key-generation processes observed verified that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed, as delineated in Annex C:

Documented procedures observed: <Report Findings Here> 12-1 The loading of …

Added p. 126

• in a key-loading device) have been disabled or changed.

Documented procedures examined: <Report Findings Here> 12-7.b Examine documented procedures to verify that keys are withdrawn from use if they were loaded to a device that has been compromised or gone missing.

Added p. 136

<Report Findings Here> 13-7 Written or printed key component documents must not be opened until immediately prior to use.

Added p. 143

<Report Findings Here> Personnel interviewed: <Report Findings Here> 17-1.b For all keys shared between two organizations or logically separate systems for encrypting account data (including key-encryption keys used to encrypt a data-encryption key) perform the following:

Documented procedures examined: <Report Findings Here> 18-2 To prevent or detect usage of a compromised key, key-component packaging or containers that show signs of tampering must result in the discarding and invalidation of the component and the associated key at all locations where they exist.

18-2.a Examine the documented procedures to verify they require that key- component packaging/containers showing signs of tampering must result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.

Added p. 148

• Key used for production keys must never be present or used in a test system, and

Added p. 156

<Report Findings Here> 21-3.1.d Examine/observe to confirm that start-up instructions and other notes used by service technicians do not contain initialization-key values written in the clear (e.g., at the point in the checklist where the keys are entered).

22-1.2 Interview responsible personnel and observe implemented processes to verify that if unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification.

Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification:

22-1.3 Interview responsible personnel and observe implemented processes to verify that if compromise of the cryptographic key is suspected, an assessment and analysis is performed. If …

Added p. 164

• must not be used external to the (logical) configuration that houses the MFK itself. For example, MFKs and their variants used by host processing systems for encipherment of keys for local storage must not be used for other purposes, such as key conveyance between platforms that are not part of the same logical configuration.

Added p. 174

• Tamper-evident and authenticable package number (if applicable) <Report Findings Here> 27-1 If backup copies of secret and/or private keys exist, they must be maintained in accordance with the same requirements as are followed for the primary keys.

Added p. 178

<Report Findings Here> 29-1.1.1.c Examine implemented access controls to verify that unauthorized individuals cannot access, modify, or substitute any POI device or other SCD.

Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who verified the access controls ensure only personnel documented and authorized in an auditable manner have access to devices.

Documented procedures examined: <Report Findings Here> 29-3.b Interview responsible personnel to verify that one or more of the defined methods are in place to provide physical device protection for devices, from the manufacturer’s facility up to the point of key-insertion and deployment.

29-4.2.a Examine the defined security policy to be enforced by the HSM. Documented security policy examined: <Report Findings Here> 29-4.2.b Examine documentation of the HSM configuration settings to determine that the functions and command authorized to be enabled are in accordance with the security policy.

Added p. 184

Documented procedures examined: <Report Findings Here> 29-4.4.1 Running self-tests to ensure the correct operation of the device 29-4.4.1 Examine records of device inspections and test results to verify that self-tests are run on devices to ensure the correct operation of the device.

Added p. 187

Documented procedures examined: <Report Findings Here> 31-1.1.b Interview personnel and observe demonstration (if HSM is available) of processes for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes.

<Report Findings Here> 31-1.3 SCDs being decommissioned are tested and inspected to ensure keys have been rendered irrecoverable.

Personnel interviewed: <Report Findings Here> Records of testing examined: <Report Findings Here> 32-1 Not used in DMS 32-2 Not used in DMS 32-3 Not used in DMS 32-4 Not used in DMS 32-5 Not used in DMS 32-6 Not used in DMS 32-7 Not used in DMS 32-8 Not used in DMS 32-9 Not used in DMS

Added p. 192

Documentation examined: <Report Findings Here> 5A-1.3.b Observe architecture and key-management operations to verify that the documentation reviewed in 5A-1.3.a is demonstrably in use for all key-management processes.

Added p. 195

• Each DDK must have a defined usage period (cryptoperiod) based on a formal risk assessment and industry guidance as provided in NIST SP800-57, ISO TR 14742 and NIST SP800-131. The cryptoperiod defines the duration of time that the DDK may be used to decrypt account data, defined either as a maximum threshold of transactions, or hours, or both (e.g., 1024 transactions or 24 hours, whichever is reached first)

• Each DDK must have a defined usage period (cryptoperiod) based on a formal risk assessment and industry guidance as provided in NIST SP800-57, ISO TR 14742 and NIST SP800-131. The cryptoperiod defines the duration of time that the DDK may be used to decrypt account data, defined either as a maximum threshold of transactions, or hours, or both (e.g., 1024 transactions or 24 hours, whichever is reached first)

• Upon reaching the defined usage threshold, the DDK must not be used for …

Added p. 196

5H-1.2.a Examine documented key-management policies and procedures to verify that the mechanism used to erase a DDK from the Host System volatile memory is sufficient to ensure the key cannot be recovered or reconstructed.

<Report Findings Here> 5H-1.2.b Test, through the use of forensic tools and/or methods, that the mechanism used to erase the DDK from the host volatile memory, is sufficient to ensure the key cannot be recovered or reconstructed.

Describe the forensic tools and/or other methods used that verified that the mechanism used to erase the DDK from the host volatile memory, is sufficient to ensure the key cannot be recovered or reconstructed:

<Report Findings Here> 5H-1.3 If the DDK is generated from a master key, the following conditions apply:

• A one-way derivation process must be used

• A one-way derivation process must be used

• The DDK must never be generated as a variant of the HSM master file key

• The DDK …

Added p. 197

5H-1.4.a Examine key-management policies and procedures to verify that DDKs must be encrypted between the HSM and the Host System.

<Report Findings Here> 5H-1.4.b Examine HSM and Host System configurations to verify that DDKs are encrypted between the HSM and the Host System.

Describe how the HSM and Host System configurations examined verified that DDKs are encrypted between the HSM and the Host System:

<Report Findings Here> 5H-1.4.c Examine the HSM security policies and observe HSM implementations to verify that the method of encryption used maintains the security policy to which the HSM was approved.

Describe how the HSM security policies and HSM implementations examined verified that the method of encryption used maintains the security policy to which the HSM was approved:

<Report Findings Here> 5H-1.5 The encryption mechanism used to protect the DDK between the HSM and the Host System:

5H-1.5 Examine/observe the encryption mechanism used to protect the DDK between the HSM and the …

Added p. 198

5H-1.5.2.a Examine documented key-management policies and procedures to verify that the encryption mechanism uses an encryption key that is unique for each Host System.

<Report Findings Here> 5H-1.5.2.b Observe key-management processes to verify that the encryption mechanism uses an encryption key that is unique for each Host System.

Describe how the key-management processes observed verified that the encryption mechanism uses an encryption key that is unique for each Host System:

<Report Findings Here> 5H-1.5.3 The encryption key must only be used to encrypt the DDK during transmission between the HSM and the Host System, and not used to encrypt/transmit any other cryptographic key, or for any other purpose.

5H-1.5.3.a Examine documented key-management policies and procedures to verify that the encryption mechanism uses an encryption key that is only used to encrypt the DDK during transmission between the HSM and the Host System, and not used to encrypt/transmit any other cryptographic key, or for any …

Added p. 199

5H-1.5.4.a Examine documented key-management policies and procedures to verify that the encryption mechanism uses an encryption key that has a defined cryptoperiod based on the volume of keys it transports and industry recommendations/best practices.

<Report Findings Here> 5H-1.5.4.b Observe key-management processes to verify that the encryption mechanism uses an encryption key that has a defined cryptoperiod based on the volume of keys it transports and industry recommendations/best practices.

Describe how the key-management processes observed verified that the encryption mechanism uses an encryption key that has a defined cryptoperiod based on the volume of keys it transports and industry recommendations/best practices:

Modified p. 1

Payment Card Industry (PCI) Point-to-Point Encryption (P2PE)® ~~Encryption~~ Management Services Template for Report on Validation For use with the P2PE Standard v3.2 for P2PE ~~Encryption~~ Management Services Assessments

Payment Card Industry (PCI) Point-to-Point Encryption (P2PE)® Decryption Management Services Template for Report on Validation For use with the PCI P2PE Standard v3.2 for P2PE Decryption Management Services Assessments

Modified p. 2

• added where applicable regarding the use of this template for ~~EMS~~ Component assessments vs. Solution assessments.

• added where applicable regarding the use of this template for DMS Component assessments vs. Solution assessments.

Modified p. 2

• Updates from the PCI P2PE Standard v3.2

- Updates from the PCI P2PE Standard v3.2

Modified p. 2

• Updates based on stakeholder feedback

- Updates based on stakeholder feedback

Modified p. 2

• Errata updates to section 4

- Errata updates to section 4

Modified p. 5

~~EMS~~ Component Assessments: Use of this Reporting Template is mandatory for all P2PE v3.2 ~~Encryption~~ Management Services Component Provider ~~assessments.~~

DMS Component Assessments: Use of this Reporting Template is mandatory for all P2PE v3.2 Decryption Management Services Component Provider assessments (i.e., for a DMCP assessment).

Modified p. 5

Solution Assessments: Use of this Reporting Template is mandatory for all P2PE v3.2 Solution (and Merchant-managed Solution) assessments, where the Solution Provider is directly responsible for all or part of the ~~Encryption~~ Management Services requirements (i.e., when they have not completely satisfied the full scope of their ~~encryption~~ management services via the use of Validated ~~Encryption~~ Management Services P2PE Component Providers).

Solution Assessments: Use of this Reporting Template is mandatory for all P2PE v3.2 Solution (and Merchant-managed Solution) assessments, where the Solution Provider is directly responsible for all or part of the Decryption Management Services requirements (i.e., when they have not completely satisfied the full scope of their decryption management services via the use of Validated Decryption Management Services P2PE Component Providers).

Modified p. 5

A P2PE assessment involves thorough testing and assessment activities, from which the assessor will generate detailed work papers. These work papers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file lists, interview notes, documentation excerpts, references, screenshots, and other evidence collected during the course of the assessment. The P-ROV is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor performed the validation activities and how the …

Modified p. 6

Validation of a P2PE Solution that has not satisfied the key management services requirements (Domain 5) either using Listed P2PE Component Providers and/or through the assessment of their Encryption Management Services and/or Decryption Management Services must complete the KMS P-

Validation of a P2PE Solution that has not satisfied the key management services requirements (Domain 5) either using Listed P2PE Component Providers and/or through the assessment of their Encryption Management Services and/or Decryption Management Services must complete the KMS P- ROV. E.g., if the P2PE Solution offers remote key-distribution using asymmetric techniques for the

Modified p. 7 → 8

P-ROV Summary of Findings All summary findings for “In Place,” “Not in Place,” and “Not Applicable” are found at the beginning of section 4 “Findings and Observations” and are only addressed at that high level. The summary of the overall compliance validation status is at section 2.8 “Summary of P2PE Assessment Compliance Validation Status.” The following table provides guidance for Assessors when considering which selection to make. Assessors must select only one response at the ~~sub- requirement~~ level, and the …

P-ROV Summary of Findings All summary findings for “In Place,” “Not in Place,” and “Not Applicable” are found at the beginning of section 4 “Findings and Observations” and are only addressed at that high level. The summary of the overall compliance validation status is at section 2.8 “Summary of P2PE Assessment Compliance Validation Status.” The following table provides guidance for Assessors when considering which selection to make. Assessors must select only one response at the sub-requirement level, and the selected …

Modified p. 8 → 9

• Document name or interviewee reference At section 3.6, ~~”Documentation~~ Reviewed,” and section 3.7, “Individuals Interviewed,” there is a space for a reference number; it is the P2PE Assessor’s choice to use the document name/interviewee job title or the reference number in responses. A listing is sufficient ~~here;~~ no further detail is required.

• Document name or interviewee reference At section 3.6, “Documentation Reviewed,” and section 3.7, “Individuals Interviewed,” there is a space for a reference number; it is the P2PE Assessor’s choice to use the document name/interviewee job title or the reference number in responses. A listing is sufficient here, no further detail required.

Modified p. 10 → 11

~~Yes~~ (Internal QA on this submission has been performed in accordance with PCI P2PE Program Requirements) QA Primary reviewer name: QA Primary reviewer credentials:

(Internal QA on this submission has been performed in accordance with PCI P2PE Program Requirements) QA Primary reviewer name: QA Primary reviewer credentials:

Modified p. 12 → 13

2. Summary Overview 2.1 P2PE Assessment Details Solution or Component Assessment Is this P-ROV being submitted as part of a Solution assessment or for ~~an EMS~~ Component assessment? Solution If Solution, enter the Solution Name: (Complete this P-ROV with the Solution P-ROV) ~~EMS~~ Component If ~~EMS~~ Component, complete the P2PE Component Details below.

2. Summary Overview 2.1 P2PE Assessment Details Solution or Component Assessment Is this P-ROV being submitted as part of a Solution assessment or for a DMS Component assessment? Solution If Solution, enter the Solution Name: (Complete this P-ROV with the Solution P-ROV) DMS Component If DMS Component, complete the P2PE Component Details below.

Modified p. 12 → 13

P2PE Component Details (for ~~EMS~~ Component assessments ONLY) P2PE Component Name:

P2PE Component Details (for DMS Component assessments ONLY) P2PE Component Name:

Modified p. 12 → 13

Is the Component ~~already~~ (or was it previously) listed on the PCI SSC List of Validated P2PE Components? Yes (If Yes, provide listing reference #):

Is the Component currently (or was it previously) listed on the PCI SSC List of Validated P2PE Components? Yes (If Yes, provide listing reference #):

Modified p. 12 → 13

No (If No, the component has never been listed) P2PE ~~EMS~~ Component Type for this ~~assessment. Select one of the following: (Do not check anything for Solution Assessments) Encryption~~ Management Component Provider ~~(EMCP) POI Deployment Component Provider (PDCP) POI Management Component Provider (PMCP)~~

No (If No, the component has never been listed) P2PE Component Type for this assessment: Decryption Management Component Provider (DMCP)

Removed p. 13

For every PDCP and PMCP Component below, document the PTS Approval #s associated with their respective Validated P2PE Component listing that are being included in this assessment. The PTS approval #s here must also be present in Table 2.5. For non-EMS Component Types denote “N/A” in the PTS Approval # column.

Note 3: POI Device Types associated with PDCPs and PMCPs are only assessed to a subset of applicable Domain 1 and Domain 5 requirements. Therefore, only where a POI Device Type is supported by BOTH a Validated PDCP and a PMCP below is it excluded from requiring any additional assessment. Otherwise, each POI Device Type must be assessed to all requirements that were not covered under its associated Component Type assessment. Reference the “P2PE Applicability of Requirements” in the P2PE Program Guide.

Modified p. 13 → 14

~~EMS~~ COMPONENT ASSESSMENTS: Complete this table if Validated P2PE Component Providers are being used to help satisfy applicable requirements for this ~~EMS~~ Component assessment.

DMS COMPONENT ASSESSMENTS: Complete this table if Validated P2PE Component Providers are being used to help satisfy applicable requirements for this DMS Component assessment.

Modified p. 13 → 14

Note 1: It is not permissible to use a PCI-listed P2PE Component Provider of the same type as the entity under assessment. A PCI-listed ~~EMCP~~ cannot be used to satisfy the requirements of ~~an EMCP~~ under assessment. This applies to all Component ~~type~~ assessments.

Note 1: It is not permissible to use a PCI-listed P2PE Component Provider of the same type as the entity under assessment. A PCI-listed DMCP cannot be used to satisfy the requirements of a DMCP under assessment. This applies to all Component Type assessments.

Modified p. 13 → 14

Are Validated P2PE Component Providers being used to help satisfy requirements of this assessment? Yes (If Yes, document below accordingly. Ensure all remaining applicable requirements are assessed and satisfied as they relate to the full scope of the assessment.) No (If No, leave the remainder of this table blank. Ensure all applicable requirements are assessed and satisfied as they relate to the full scope of the assessment.) Type of Validated P2PE Component (select ONLY one Component Type per row) P2PE …

Note 2: The use of PCI-listed P2PE Component Providers must be considered Validated. Refer to the P2PE Program Guide for additional details. https://www.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_components Are Validated P2PE Component Providers being used to help satisfy requirements in scope for this assessment? Yes (If Yes, document below accordingly. Ensure all remaining applicable requirements are assessed and satisfied as they relate to the full scope of the assessment.) No (If No, leave the remainder of this table blank. Ensure all applicable requirements are assessed …

Modified p. 14 → 15

Provide more detail than simply, e.g., “The KIF is satisfying Domain 5 for the ~~EMCP”.~~ Do not leave this blank unless No was checked above.

Provide more detail than simply, e.g., “The KIF is satisfying Domain 5 for the DMCP”. Do not leave this blank unless No was checked above.

Modified p. 15 → 16

Third-party entities are entities that are not ~~PCI-listed~~ P2PE Component Providers. Third-party entities must be assessed as applicable for each P2PE assessment in which the third-party service is used to satisfy applicable P2PE requirements. Refer to the P2PE Standard and the P2PE Program Guide for additional information.

Third-party entities are entities that are not Validated P2PE Component Providers. Third-party entities must be assessed as applicable for each P2PE assessment in which the third-party service is used to satisfy applicable P2PE requirements. Refer to the P2PE Standard and the P2PE Program Guide for additional information.

Modified p. 15 → 16

SOLUTION ASSESSMENTS: Document the use of all Third Parties as they relate to (only) ~~Encryption~~ Management Services here. It is not necessary to duplicate this information in the Solution P-ROV.

SOLUTION ASSESSMENTS: Document the use of all Third Parties as they relate to (only) Decryption Management Services here. It is not necessary to duplicate this information in the Solution P-ROV.

Modified p. 15 → 16

~~EMS~~ COMPONENT ASSESSMENTS: Document the use of all applicable Third Parties.

DMS COMPONENT ASSESSMENTS: Document the use of all applicable Third Parties.

Modified p. 15 → 16

Are Third Party entities involved in the scope of ~~Encryption~~ Management Services for this assessment? Yes (If Yes, provide details below - insert additional rows as necessary) No (If No, leave remainder of this table blank) Entity Name Entity Location(s) Role / Function Provide any additional details regarding the use of Third Parties, as necessary. Otherwise, check No Additional Details. No Additional Details <Additional Details, as needed>

Are Third Party entities involved in the scope of Decryption Management Services for this assessment? Yes (If Yes, provide details below - insert additional rows as necessary) No (If No, leave remainder of this table blank) Entity Name Entity Location(s) Role / Function Provide any additional details regarding the use of Third Parties, as necessary. Otherwise, check No Additional Details. No Additional Details <Additional Details, as needed> 2.4 (Table not currently used) 2.5 (Table not currently used)

Removed p. 16

SOLUTION ASSESSMENTS: All non-payment software used by the Solution must be accounted for and satisfy requirement 1C-2.

EMS COMPONENT ASSESSMENTS: Complete this table as applicable. Note that non-payment software is not listed, and as such, any non-payment software, while it must be accounted for in the scope of the EMS assessment, cannot be used in another Component or Solution without being reassessed.

Non-payment software is any software/files that does not have the potential to access cleartext account data. (Refer to P2PE Glossary)

Note: “P2PE Applications” and “P2PE non-payment software” (refer to P2PE Glossary) do not meet the PTS POI definition of “firmware”, and as such they are not reviewed as part of the POI device’s PTS POI assessment (i.e., they cannot be excluded from the scope of a P2PE assessment). Therefore, any software intended for use in a P2PE Solution that does not meet the PTS POI definition of "firmware" must be assessed …

Removed p. 17

EMS COMPONENT ASSESSMENTS: The use of any non-Validated applications that have the potential to access cleartext account data requires a P2PE Application P-ROV and associated Domain 2 assessment. P2PE Component assessments are not permitted to include non-Validated P2PE Applications (i.e., applications that can access cleartext account data must be listed on the List of Validated P2PE Applications). This table is only for Validated P2PE Applications. ONLY list the PTS Approval #s from each Validated P2PE Application in use that are actually supported by the P2PE Component or Solution under assessment. Each PTS Approval # here must be in Table 2.5 - i.e., all POI Device Types associated with a Validated P2PE Application must have been assessed to all applicable requirements in Domains 1 and 5. As POI Device Types associated with Validated P2PE Applications are only assessed to Domain 2, each POI Device Type supported by a Validated P2PE Application …

Removed p. 19

• Only list each unique PTS Approval # once

• List ALL associated hardware (HW) and firmware (FW) versions supported by the Encryption Management Services or Solution and tested as part of the P2PE assessment. HW and FW versions MUST be consistent between P-ROV(s), P-AOV and the Portal

• Ensure all the information below is correct, accurate, and there are no discrepancies between the information listed here and the information present on the POI device’s associated PTS Approval listing

• Do NOT include POI devices (including HW and/or FW) that are ineligible for P2PE (e.g., non-SRED)

• Do NOT include HW and/or FW on the POI device listing that was NOT tested as part of the P2PE assessment Note 1: Be advised there can be POI device approval listings that appear similar/identical on the PCI SSC list of Approved PTS POI devices, however, they are associated with different major versions of the PTS POI …

Removed p. 20

PTS Approval # (One unique # per row) PTS Version # Make / Mfr. Model Name / Number Hardware (HW) #(s) Tested Firmware (FW) #(s) Tested For each PTS Approval #, denote the manner that the PCI-approved PTS POI Device Types were assessed to all applicable requirements in Domains 1 and 5:

“Entirely through the use of applicable Validated P2PE Components (Only an option for Solution assessments)” “A combination of applicable Validated P2PE Components and an assessment to the remaining requirements in section 4 below” “A complete assessment to all applicable requirements in Domains 1 and 5 in section 4 below”

Removed p. 21

Note: PCI-approved PTS POI device information used for account-data capture and encryption must be entered in Table 2.5. Do not enter it here. Insert additional rows as necessary.

Modified p. 21 → 17

SOLUTION ASSESSMENTS: Document the use of all SCDs as they relate to (only) ~~Encryption~~ Management Services here. It is not necessary to duplicate this information in the Solution P-ROV.

SOLUTION ASSESSMENTS: Document the use of all SCDs as they relate to (only) Decryption Management Services here. It is not necessary to duplicate this information in the Solution P-ROV.

Modified p. 21 → 17

~~EMS~~ COMPONENT ASSESSMENTS: Complete this table as applicable.

DMS COMPONENT ASSESSMENTS: Complete this table as applicable. Insert additional rows as necessary.

Modified p. 21 → 17

Identifier Type PTS and/or FIPS Approval # PTS Version # Manufacturer / Model Name / Number Hardware #(s) ~~(comma delimited)~~ Firmware #(s) ~~(comma delimited)~~ Location Number of Devices per Location Approved Key Function(s) & Purpose

Identifier Type PTS and/or FIPS Approval # PTS Version # Manufacturer / Model Name / Number Hardware #(s) Firmware #(s) Location Number of Devices per Location Approved Key Function(s) & Purpose

Removed p. 22

Note 2: While non-payment software is not permitted to have access to cleartext account data, it might still be involved in supporting additional encryption implementations. Non-payment software detailed below must be able to be cross-referenced to Table 2.4.a in the EMS P-ROV.

Yes (If Yes, provide details below) No (If No, leave details blank) Complete the following information for ONLY the relevant POI devices, P2PE Applications and/or Non-payment software that are involved in supporting additional encryption implementations.

PTS Approval # (One unique # per row) POI Device Firmware(s) (comma delimited) P2PE Application Listing Reference # Non-Payment Software Details (Name, version#) Describe the additional account data encryption implementations and the involvement of the POI device firmware, P2PE Application, and/or non-payment software as detailed above. Where there is more than one implementation, clearly describe each implementation along with the applicable entity (e.g., acquirer / solution provider) managing it.

Modified p. 23 → 18

Mark Yes or No, as applicable to the assessment type and the overall findings, and mark N/A for all other assessment types.

Note: This table must correlate correctly with Table 2.1 for the assessment type. Refer to the “P2PE Applicability of Requirements” in the P2PE Program Guide. Mark Yes or No, as applicable to the assessment type and the overall findings, and mark N/A for all other assessment types.

Modified p. 23 → 18

~~Type of P2PE Assessment Compliant Comments (optional)~~ Solution Provider (or MMS as a Solution Provider) Yes No N/A ~~Encryption~~ Management Component Provider ~~(EMCP)~~ Yes No N/A ~~POI Deployment Component Provider (PDCP) Yes No N/A POI Management Component Provider (PMCP) Yes No N/A~~

Solution Provider (or MMS as a Solution Provider) Yes No N/A Decryption Management Component Provider (DMCP) Yes No N/A

Modified p. 24 → 19

3. Details and Scope of P2PE Assessment INSTRUCTIONS FOR SECTION 3 Solution Assessments: Complete the entirety of section 3 here as it pertains to the scope of ~~Encryption~~ Management Services of the Solution assessment. It is not necessary to duplicate information between this section here and section 3 in the Solution P-ROV. However, while there may be overlap in section 3 between the two P-ROVs, this section here must be completed and satisfied in its entirety within the scope of …

3. Details and Scope of P2PE Assessment INSTRUCTIONS FOR SECTION 3 Solution Assessments: Complete the entirety of section 3 here as it pertains to the scope of Decryption Management Services of the Solution assessment. It is not necessary to duplicate information between this section here and section 3 in the Solution P-ROV. However, while there may be overlap in section 3 between the two P-ROVs, this section here must be completed and satisfied in its entirety within the scope of …

Modified p. 24 → 19

~~EMS~~ Component Assessments: Complete the entirety of Section 3.

DMS Component Assessments: Complete the entirety of Section 3.

Modified p. 24 → 19

• How the scope of the assessment was confirmed to be accurate and to cover all components and facilities for the ~~Encryption~~ Management Services:

• How the scope of the assessment was confirmed to be accurate and to cover all components and facilities for the Decryption Management Services:

Modified p. 25 → 20

• Location of systems performing ~~encryption~~ management functions

• Location of systems performing decryption management functions

Modified p. 25 → 20

• Other necessary components, as applicable to the ~~Encryption~~ Management Services Provide any additional information below that is not adequately captured within the diagram(s). Otherwise, check No Additional Details. No Additional Details <Additional Details, as needed> <Insert ~~Encryption~~ Management Services diagram(s) here>

• Other necessary components, as applicable to the Decryption Management Services Provide any additional information below that is not adequately captured within the diagram(s). Otherwise, check No Additional Details. No Additional Details <Additional Details, as needed> <Insert Decryption Management Services diagram(s) here>

Removed p. 26

• Other Key Distribution / Loading / Injection activities

Modified p. 26 → 22

• Key Distribution / Loading / Injection ~~into POI devices~~

• Key Distribution / Loading / Injection activities

Removed p. 27

P2PE Assessor Company:

Solution/Component Provider:

Describe the lab/test environment(s) used for this assessment. When more than one environment is used, be clear which environment you are describing.

Facilities INCLUDED in the scope of this assessment (insert additional rows as necessary) Were any facilities included in the scope of the assessment? Yes (If Yes, document below) No (If No, leave details blank) Description and purpose of facility included in the assessment Address of facility Relevant facilities EXCLUDED from the scope of this assessment (insert additional rows as necessary) Note: Does not apply to merchant locations.

Removed p. 28

Note: If the P2PE Application Implementation Guide consists of more than one document, the brief description below should explain the purpose of each document it includes, e.g., if it is for different POI Device Types, different functions, different uses of the P2PE Application, etc.

P2PE Application Implementation Guide(s) (IG) Reference # (optional use) Document Name (Title of the IG) Version Number Document Date (latest version date, DD-MMM-YYYY) Which P2PE Application(s) is addressed? (must align with Table 2.4.b) All other documentation reviewed for this P2PE Assessment Reference # (optional use) Document Name (including version, if applicable) Document Date (latest version date, DD-MMM-YYYY) Document Purpose (brief summary)

Modified p. 29 → 25

Sample Ref # (optional) PTS and/or FIPS Approval # Hardware #(s) (comma delimited) Firmware #(s) (comma delimited) Sample Size (x of y) Serial Numbers of Tested Devices / Other Identifiers Sampling Rationale

Sample Ref #: (optional) PTS and/or FIPS Approval # Hardware #(s) (comma delimited) Firmware #(s) (comma delimited) Sample Size (x of y) Serial Numbers of Tested Devices / Other Identifiers Sampling Rationale

Removed p. 30

Identify the vendor-supplied documentation examined to validate the details contained within this table:

Modified p. 30 → 26

Key ID: Retain generic ID or use specific IDs from assessment Key Type: E.g., DEK, MFK, BDK, KEK, IEK, PEK, MAC, Public, Private, etc. Algorithm: E.g., TDEA, AES, RSA, DSA, etc. Key Mgmt: E.g., DUKPT, MK/SK, Fixed, One-time use, etc.

Key ID: Retain generic ID or use specific IDs from assessment Key Type: E.g., DEK, MFK, BDK, KEK, IEK, PEK, MAC, Public, Private, etc. Algorithm: E.g., TDEA, AES, RSA, DSA, ECC, etc. Key Mgmt: E.g., DUKPT, MK/SK, Fixed, One-time use, etc.

Removed p. 31

Encryption Management Services

• Summary of Findings Reference Appendix I: P2PE Applicability of Requirements in the latest P2PE v3.x Program Guide.

EMCP Encryption Management Component Provider PDCP POI Deployment Component Provider PMCP POI Management Component Provider SP Solution Provider (or MMS as a Solution Provider) Encryption Management Services: P2PE Validation Requirements Summary of Findings (check one for EVERY row) EMCP PDCP PMCP SP Requirements In Place N/A Not in Applies to: 1A Account data must be accepted by, processed, and encrypted in PCI-approved PTS POI devices with SRED.

   1A-1 PCI-approved PTS POI devices with SRED are used for payment acceptance in the merchant environment.

1A-2 MOVED TO DOMAIN 3.

1B Secure logical access to PTS POI devices.

   1B-1.1    1B-1.2

Modified p. 31 → 28

NOTE: Entities only meeting a partial set of applicable requirements (where a Validated P2PE Component Provider is not being used to satisfy the remaining applicable requirements) are not eligible for PCI SSC’s Validated P2PE ~~Product~~ listings.

NOTE: Entities only meeting a partial set of applicable requirements (where a Validated P2PE Component Provider is not being used to satisfy the remaining applicable requirements) are not eligible for PCI SSC’s Validated P2PE listings.

Modified p. 31 → 28

Reference Appendix I: P2PE Applicability of Requirements in the latest P2PE v3.x Program Guide.

Decryption Management Services

• Summary of Findings Reference Appendix I: P2PE Applicability of Requirements in the latest P2PE v3.x Program Guide.

Removed p. 32

   1B-3 Solution provider implements procedures to protect PTS POI devices and applications from known vulnerabilities and securely update devices.

   1B-4 Solution provider implements procedures to secure account data when troubleshooting.

   1B-5 The P2PE solution provider maintains auditable logs of any changes to critical functions of the PTS POI device(s).

1C Managing whitelists and Non-payment software    1C-1 Whitelists are managed securely.

    1C-2 All software without a business need does not have access to cleartext account data.

1D Implement secure application-management processes.

   1D-1 Integrity of applications is maintained during installation and updates.

    1D-2 Maintain instructional documentation and training programs for the application’s installation, maintenance/upgrades, and use.

Not used in P2PE 1-1 Not used in EMS 1-2

Modified p. 32 → 28

~~1E-1~~ For component providers of ~~encryption-management~~ services, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.

4E-1 For component providers of decryption-management services, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.

Modified p. 32 → 33

1E Component providers ONLY: Report status to solution providers.

5I Component providers ONLY: Report status to solution providers.

Modified p. 33 → 29

Cryptographic keys used for account-data encryption/decryption and related key management are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys ~~    5-1     6-1     6-2     6-3     6-4     6-5     6-6     7-1     7-2 …~~

Cryptographic keys used for account-data encryption/decryption and related key management are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys 5 All keys, key components, and key shares are generated using an approved random or pseudo-random function.

Removed p. 43

NOTE: Within this domain, the term “solution provider” refers to whichever entity is undergoing the P2PE assessment. This may be a P2PE Solution Provider, a P2PE Component Provider, or a merchant as a solution provider (MMS). Refer to Domain 1 in the P2PE Standard for additional details.

1A-1.1 Account data encryption operations must be performed using a PTS POI device (including the individual hardware and firmware) approved per the PCI PTS program with SRED (secure reading and exchange of data). The PTS approval listing must match the deployed PTS POI devices in the following characteristics:

• Model name and number

• Hardware (HW) version number(s)

• Hardware (HW) version number(s)

• Firmware (FW) version number(s)

• Firmware (FW) version number(s)

• Application (Applic) version number(s)

• SRED listed as a function provided 1A-1.1 For each PTS POI device type intended for use in the solution, examine the PCI SSC list of Approved PTS Devices to verify that all …

Removed p. 44

1A-1.1.1.a Examine documented procedures to verify that SRED capabilities are enabled and active on all PTS POI devices prior to the devices being placed into service for payment acceptance in merchant encryption environments.

1A-1.2.a Examine documented procedures to verify that PTS POI devices must be configured to use only SRED-validated account-data capture mechanisms of the approved hardware/firmware.

Removed p. 44

1A-1.2.b REMOVED 1A-1.2.1 REMOVED 1A-1.3 If the PTS POI device implements Open Protocols (as defined in the PCI PTS POI Standard) , the PTS POI device, including the specific HW and FW, must also be validated to the PCI PTS POI Open Protocols (OP) module. Open protocols include the following:

• Link Layer Protocols

Modified p. 44 → 40

Documented procedures examined: <Report Findings Here> Personnel interviewed: <Report Findings Here> ~~1A-1.1.1.b~~ REMOVED ~~1A-1.2 PTS POI devices must be configured to use only SRED-validated account-data capture mechanisms of its approved hardware/firmware.~~

• Inspections are performed at least quarterly Documented procedures examined: <Report Findings Here> Personnel interviewed: <Report Findings Here> 4B-1.5.b REMOVED 4B-1.5.c REMOVED

Removed p. 45

1A-1.3.b [This testing procedure is only applicable for PTS POI devices where its PTS approval listing denotes that a HW and/or FW version excludes the use of a specific Open Protocol] For all PTS POI device types where the PTS approval denotes the HW and/or FW excludes specific Open Protocols from being used, examine documented procedures to verify that these PTS POI devices must be configured to use only the validated Open Protocols of the approved hardware/firmware through appropriate examination, testing, and/or observation.

1A-1.4 Cleartext account data must not be disclosed to any component or device outside of the PCI-approved PTS POI device.

<Report Findings Here> 1A-1.4.b Using forensic tools and/or other data tracing methods, inspect a sample of transactions to verify that cleartext account data is not disclosed to any component or device outside of the PCI-approved PTS POI device.

Identify the sample of transactions <Report Findings Here> Describe the forensic tools …

Modified p. 45 → 38

Documented ~~transaction~~ processes ~~and data flows~~ examined:

Documented procedures and processes examined:

Modified p. 45 → 42

~~1A-1.4.a~~ Examine documented ~~transaction~~ processes and ~~data flows~~ to ~~verify~~ that cleartext account data is ~~not disclosed~~ to ~~any component or device outside of~~ the ~~PCI-approved PTS POI device.~~

4B-1.7.a Examine documented processes and interview personnel to confirm that cleartext account data is never sent back to the encryption environment.

Removed p. 46

• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or cleartext account data.

• Cannot [re]enable device interfaces or data-capture mechanisms that are required to be disabled.

• Does not use any POI vendor default device passwords.

• Cannot access PTS POI devices remotely 1B-1.1.a Examine documented PTS POI device configuration procedures and documented account privilege assignment rules to verify that merchant logical access (by any means/method) to PTS POI devices is restricted as follows:

Removed p. 46

• Does not use the PTS POI vendor’s default passwords.

• Cannot access PTS POI devices remotely Documented procedures examined: <Report Findings Here> Describe how documented PTS POI device configuration procedures and documented account privilege assignment rules to verify that merchant logical access (by any means/method) to PTS POI devices is restricted as follows:

• Does not use the PTS POI vendor’s default passwords

• Cannot access PTS POI devices remotely <Report Findings Here>

Removed p. 47

• Cannot access PTS POI devices remotely <Report Findings Here>

• Cannot access PTS POI devices remotely Personnel interviewed:: <Report Findings Here> Describe how logon to the device using an authorized test merchant account verified that merchant logical access meets the following:

Removed p. 48

• Documented in a formal list that is reviewed annually

• Authorized by solution provider management

• Based on least privilege and need to know 1B-1.2.a Examine documented access-control policies and procedures for logical access to PTS POI devices by solution provider personnel to verify that all personnel with access:

• Are documented in a formal list that is reviewed annually

• Are authorized by solution provider management

• Are granted access based on least privilege and need to know Documented authorizations examined: <Report Findings Here> 1B-1.2.b Interview personnel and observe the process to logically access PTS POI devices and verify the requirement is satisfied.

Modified p. 48 → 47

Personnel interviewed: <Report Findings Here> Describe ~~how~~ the ~~interviews~~ and ~~observations verified the requirement is satisfied.~~

• Unauthorized use of the HSM API Personnel interviewed: <Report Findings Here> Describe the implemented mechanisms that were observed to be implemented to detect and respond to suspicious activity:

Removed p. 49

1B-2.1.a Examine documented procedures to verify that either multi-factor or cryptographic authentication must be used for all remote access to PTS POI devices.

Documented procedures examined: <Report Findings Here> 1B-2.1.b Interview personnel and observe remote-access mechanisms and controls to verify that either multi-factor or cryptographic authentication is used for all remote access to PTS POI devices.

Personnel interviewed: <Report Findings Here> Describe how remote-access mechanisms and controls verify that either multi-factor or cryptographic authentication is used for all remote access to PTS POI devices:

<Report Findings Here> 1B-2.2 PTS POI devices must be configured to ensure that remote access is only permitted from the solution provider’s authorized systems (which might include a terminal management system (TMS) or similar system).

1B-2.2.a Examine documented PTS POI device-configuration procedures to verify that PTS POI devices must be configured to permit remote access only from the solution provider’s authorized systems.

<Report Findings Here> 1B-2.2.b Interview personnel and observe the …

Modified p. 49 → 39

Documented ~~device-configuration~~ procedures examined:

Documented policies and procedures examined:

Removed p. 50

1B-2.4.a Examine documentation to verify secure identification and authentication procedures are defined for remote access to PTS POI devices deployed at merchant encryption environments.

Documented identification and authentication procedures examined:

Documented identification and authentication procedures examined:

<Report Findings Here> 1B-2.5 Solution Provider must maintain individual authentication credentials for all authorized solution-provider personnel that are unique for each merchant.

Note: If a centralized terminal-management system (TMS) is utilized to manage multiple merchant accounts, it is acceptable for the TMS system to only require unique access for each authorized solution-provider employee accessing the TMS instead of requiring unique access per merchant.

1B-2.5.a Examine documentation to verify that all authorized solution-provider personnel are required to have individual authentication credentials that are unique for each merchant (or if applicable, per centralized TMS).

<Report Findings Here> 1B-2.5.1 Tracing all logical access to PTS POI devices by solution-provider personnel to an individual user.

1B-2.5.1.a Examine documentation to verify that all logical access to …

Removed p. 51

1B-2.5.2.a Examine documentation to verify that access records/logs of all logical access to PTS POI devices by solution-provider personnel are required to be retained for at least one year.

<Report Findings Here> 1B-3.1 REMOVED 1B-3.2 An up-to-date inventory of PTS POI device system builds must be maintained and confirmed at least annually and upon any changes to the build.

Note: A PTS POI system build includes at least the following information:

• Model name and number

• Hardware version number(s)

• Firmware version number(s)

• PTS Application version number(s)

• Procedures for maintaining an up-to-date inventory of PTS POI device system builds

• Procedures for confirming all builds at least annually and upon any changes to the build Documented procedures examined: <Report Findings Here> 1B-3.2.b Examine documented inventory of PTS POI devices and their system builds to verify:

• The inventory includes all PTS POI device system builds.

• The inventory of PTS POI device system builds is up to …

Modified p. 51 → 37

• ~~The inventory~~ of ~~POI device system builds is up to date~~ <Report Findings Here>

• Use of HSM commands <Report Findings Here>

Modified p. 51 → 47

~~• Non-payment Software 1B-3.2.a~~ Examine documented procedures to verify ~~they include:~~

4C-1.3 Examine documented procedures to verify controls are defined for the following:

Removed p. 52

Note: A “critical software security update” is one that addresses an imminent risk to account data, either directly or indirectly.

Note: These security patches can be deployed via “push” from the solution provider or vendor, or via “pull” from the PTS POI device or merchant. In all cases, the solution provider is ultimately responsible to ensure security patches are installed in a timely manner. Aligns with 2C-1.2 1B-3.3.a Examine documented procedures to verify they include defined procedures for deploying critical software security updates to PTS POI devices in the merchant environment within 30 days of receipt from PTS POI device vendors and application/software vendors.

Documented procedures examined: <Report Findings Here> 1B-3.3.b Examine security update deployment records and device logs, and interview responsible solution provider personnel to verify that critical security updates are deployed to PTS POI devices in the merchant environment within 30 days of receipt from PTS POI device vendors and …

Removed p. 53

Responsible personnel interviewed: <Report Findings Here> Describe how processes for delivering updates and interview responsible personnel to verified that the integrity of software is maintained during delivery and deployment, and according to guidance from the PTS POI device or application/software vendor:

<Report Findings Here> 1B-4 Solution/Component provider implements procedures to secure account data when troubleshooting 1B-4.1 Any account data used for debugging or troubleshooting purposes must be securely deleted. These data sources must be collected in limited amounts and collected only when necessary to resolve a problem, encrypted while stored, and deleted immediately after use.

1B-4.1.a Examine documented procedures for troubleshooting customer problems and verify the procedures include the following for account data:

• Never output to merchant environments

• Collection only when needed to solve a specific problem

• Storage in a specific, known location with limited access

• Collection of only a limited amount of data needed to solve a specific problem

• Encrypted while …

Modified p. 53 → 62

• ~~Secure deletion immediately after use Documented procedures~~ for troubleshooting ~~customer problems~~ examined:

• Core dumps of memory required for troubleshooting Documented configuration procedures examined:

Removed p. 54

Note: Critical functions include application and firmware updates as well as changes to security-sensitive configuration options, such as whitelists or debug modes.

1B-5.1.a Examine documented procedures to verify that any changes to the critical functions of the PTS POI devices are logged, including:

• Changes to the applications/software within the device

• Changes to the applications/software within the device

• Changes to the firmware within the device

• Changes to the firmware within the device

• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) Describe how the documented procedures verified that any changes to the critical functions of the POI devices are logged, including:

• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) <Report Findings Here> 1B-5.1.b Observe authorized personnel perform authorized changes on PTS POI devices and examine the log files to verify activities in 1B-5.1.a.

<Report Findings Here> 1B-5.1.1 Examine documented procedures and sample …

Modified p. 54 → 55

Documented procedures examined:

Documented policies and procedures examined:

Modified p. 54 → 78

Describe how observation of authorized personnel ~~performing authorized changes on PTS POI devices and examination of~~ the ~~log files~~ verified ~~activities in 1B-5.1.a.~~

Describe how observation of authorized personnel entering the secure room verified that dual control is enforced:

Removed p. 55

− PTS POI device vendor's security guidance − P2PE Application’s Implementation Guide b) Signing in accordance with the PCI PTS POI Standard requirements that apply to the PTS POI device and its PTS approval prior to installation on the PTS POI device

c) Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data

d) Documentation for all new installations and updates to whitelist functionality that includes the following (at a − Description and justification for the functionality − The identity of the authorized person who approved the new installation or updated functionality prior to release

Note: The entity being assessed, which includes either the Component Provider or the Solution Provider, is expected to have documented processes to securely manage whitelists should they be utilized in the solution.

Modified p. 56 → 48

Personnel interviewed: <Report Findings Here> ~~Documented procedures examined:~~

Personnel interviewed: <Report Findings Here>

Removed p. 57

a) Is confirmed to not have any logical interfaces (e.g., application programming interfaces [APIs]) that allow for receiving, storing, processing, or transmitting of cleartext account data

b) Is signed in accordance with the PCI PTS POI Standard requirements that apply to the PTS POI device and its PTS approval

c) Documentation for all new installations and updates to non-payment software that includes the following (at a minimum):

− The identity of the authorized person who approved the new installation or updated functionality prior to release.

Note: The entity being assessed, which includes either the Component Provider or the Solution Provider, is expected to have documented processes to securely manage non-payment should it be utilized in the solution.

PDCP PMCP EMCP 1C-2.1 Examine documented processes and interview responsible personnel (as needed) to confirm the stated processes are documented and established.

Modified p. 57 → 83

~~Documentation~~ examined: <Report Findings Here> ~~Responsible personnel~~ interviewed: <Report Findings Here>

Documented alarm events examined: <Report Findings Here> Personnel interviewed: <Report Findings Here>

Removed p. 58

a) Implemented in accordance with the following, as applicable:

− PTS POI device vendor's security guidance − P2PE Application’s Implementation Guide

b) Signed in accordance with the PCI PTS POI Standard requirements that apply to the PTS POI device and its PTS approval.

c) Documented to include the identity of the authorized person(s) who approved the installation.

Note: The entity being assessed, which includes either the Component Provider or the Solution Provider, is expected to have documented processes to securely manage P2PE Applications used in the solution.

1D-1.1 Examine documented processes and interview responsible personnel (as needed) to confirm the stated processes are documented and established.

Relevant personnel interviewed: <Report Findings Here> Documented processes examined: <Report Findings Here> 1D-1.2 Processes must be documented and implemented to manage all changes to applications, including:

• Documented approval for all changes by appropriate personnel

• Documented reason and impact for all changes

• Documented back-out procedures for application installations/updates

Note: Adding P2PE Applications …

Removed p. 59

• All changes to applications include documented approval by appropriate authorized solution-provider personnel

• All changes to applications are documented as to reason and impact of the change

• Documentation includes back-out procedures for application installations/updates Documented processes examined: <Report Findings Here> Relevant personnel interviewed: <Report Findings Here> 1D-1.2.1 REMOVED 1D-1.3 REMOVED 1D-2.1 Upon receipt from the application vendor, a current copy of the application vendor’s Implementation Guide must be retained and distributed to any outsourced integrators/resellers used for the P2PE Solution/Component.

Aligns with 2C-3.1.3 PDCP PMCP EMCP 1D-2.1 Interview Solution/Component-provider personnel and examine documentation (including a current copy of the Implementation Guide from the application vendor) to confirm the following:

Documentation examined, in addition to the current copy of the Implementation Guide from the application vendor:

Modified p. 59 → 71

<Report Findings Here> ~~Responsible~~ Personnel interviewed: <Report Findings Here>

Records of alerts examined: <Report Findings Here> Personnel interviewed: <Report Findings Here>

Removed p. 60

• The Solution/Component provider retains a current copy of the Implementation Guide

• The Solution/Component provider distributes the Implementation Guide to any outsourced integrators/resellers the Solution/Component provider uses for the P2PE Solution/Component upon obtaining updates from the application vendor Current Application Vendor Implementation Guide(s) examined:

Removed p. 60

• Date list of personnel with logical remote access to deployed merchant PTS POI devices was last reviewed/updated Responsible component provider personnel interviewed:

Modified p. 60 → 59

<Report Findings Here> ~~Reports examined for this testing procedure:~~

<Report Findings Here> Personnel assigned with security-response duties interviewed:

Modified p. 60 → 85

Note: This section ~~(1E-1)~~ is ONLY applicable for P2PE component providers undergoing an assessment for subsequent PCI listing of the ~~validated~~ component provider’s ~~Encryption-Management Services.~~ This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include ~~encryption-management~~ functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties).

Note: This section is ONLY applicable for P2PE component providers undergoing an assessment for subsequent PCI listing of the component provider’s decryption-management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include decryption-management functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties).

Modified p. 60 → 86

~~1E-1.1 Track~~ status of the ~~encryption-management services~~ and provide reports to solution ~~provider~~ annually and upon significant changes, including at least the ~~following (per merchant location):~~

4E-1.1 Component Providers must track the status of the decryption-management service and provide reports to solution providers annually and upon significant changes, including at least the following:

Modified p. 60 → 86

• Types/models of ~~PTS POI devices~~

• Types/models of HSMs

Modified p. 60 → 86

• Types/models of ~~PTS POI devices~~

• Types/models of HSMs

Modified p. 60 → 86

• Number of ~~PTS POI devices~~ deployed and any change in numbers since last report

• Number of HSMs deployed and any change in numbers since last report

Modified p. 60 → 86

• ~~Date list~~ of ~~personnel with logical remote access to deployed merchant PTS POI devices was last reviewed/updated PDCP PMCP EMCP 1E-1.1.a~~ Examine component provider’s documented procedures for providing required reporting to applicable solution ~~providers~~ and interview responsible component-provider ~~personnel,~~ to confirm that the following processes are documented and implemented:

• Details of any suspicious activity that occurred, per 4C-1.2 4E-1.1.a Examine component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel to confirm that the following processes are documented and implemented:

Modified p. 60 → 86

• Number of ~~PTS POI devices~~ deployed and ~~change~~ since last report

• Number of HSMs deployed and description of any changes since last report

Removed p. 61

• Types/models of PTS POI devices

• Number of PTS POI devices deployed and changed since last report

• Date list of personnel with logical remote access to deployed merchant PTS POI devices was last reviewed/updated Reports examined for this testing procedure:

<Report Findings Here> 1E-1.2 Manage and monitor changes to encryption-management services and notify the solution provider upon occurrence of any of the following:

Removed p. 61

• Addition and/or removal of PTS POI device types

• Adding, changing, and/or removing P2PE Applications on PTS POI devices including description of change

• Adding, changing, and/or removing P2PE Non-payment Software on PTS POI devices, including description of change

• Updated list of PTS POI devices, P2PE Applications, and/or P2PE Non-payment Software

Note: Adding, changing, or removing PTS POI device types, P2PE Applications, and/or P2PE Non-payment Software may require adherence to PCI SSC’s process for making changes. Please refer to the PCI P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE Solution.

Removed p. 62

• Addition and/or removal of PTS POI device types

• Adding, changing, and/or removing P2PE Non-payment Software on PTS POI devices, including description of change

• Adding, changing, and/or removing P2PE Applications on PTS POI devices, (including description of change

• Updated list of PTS POI devices, P2PE Applications, and/or P2PE Non-payment Software Documented component provider’s procedures examined:

• Adding, changing, and/or removing P2PE Applications on PTS POI devices, including description of change

• Adding, changing, and/or removing P2PE Non- payment Software, including description of change

• Updated list of PTS POI devices, P2PE Applications, and/or P2PE Non-payment Software Reports examined for this testing procedure:

Modified p. 62 → 87

<Report Findings Here> ~~PDCP PMCP EMCP 1E-1.2.b Examine~~ reports provided to applicable solution providers, and confirm at least the following are reported upon occurrence:

<Report Findings Here> 4E-1.2.b Observe reports provided to applicable solution providers, and confirm at least the following are reported upon occurrence:

Modified p. 62 → 87

• Addition and/or removal of ~~PTS POI device~~ types

• Addition and/or removal of HSM types

Removed p. 63

• FIPS 140-2 or FIPS 140-3 Level 3 or higher certified, or

• PCI approved Note 1: HSM approval listings must be current⎯HSMs must have a non-expired PCI PTS HSM approval or a non-expired FIPS 140-2 or FIPS 140-3 certificate (i.e., the FIPS 140 HSM certificates must not be listed as historical or revoked).

Note 2: PCI-approved HSMs may have their approvals restricted whereby the approval is valid only when the HSM is deployed in controlled environments or more robust (e.g., secure) environments as defined in ISO 13491-2 and in the device’s PCI HSM Security Policy. This information is noted in the Additional Information column of approved PTS devices.

Note 3: Key-injection platforms and systems must include hardware devices for managing (e.g., generating and storing) the keys that conform to the requirements for SCDs. This includes SCDs used in key-injection facilities (e.g., modified PEDs). A PED used for key injection must be validated …

Modified p. 64 → 89

• Any applications, including application version number, resident within the device which were included in the PTS assessment ~~For each PCI-approved HSM used, describe how~~ the ~~observed HSM device configurations verified that all of the device characteristics at 1.4.a match the PTS listing:~~

• Any applications, including application version number, resident within the device which were included in the PTS assessment Review the PCI approval listing(s) for any implementation-specific notes and if present, verify they are accounted for.

Modified p. 64 → 89

<Report Findings Here> 1-4.b For all FIPS-approved HSMs used, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the ~~For each FIPS-approved HSM used, describe how the observed HSM device configurations verified that all of the~~ device characteristics ~~at 1.4.b~~ match the ~~FIPS140-2~~ Level 3 (or higher) approval ~~listing:~~

<Report Findings Here> 1-4.b For all FIPS-approved HSMs used, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS 140-2 or 140-3 Level 3 (or higher) approval listing for each HSM:

Modified p. 65 → 89

~~• The FIPS 140 Approval Number~~ <Report Findings Here> 1-4.c If the solution/component provider has applied a vendor security patch that resulted in an

<Report Findings Here> 1-4.c If the solution/component provider has applied a vendor security patch that resulted in an

Modified p. 65 → 89

1-5 Not used in ~~EMS~~ Requirements 2, 3 and 4 ~~are~~ not used in ~~P2PE.~~

1-5 Not used in DMS Requirements 2, 3, and 4 not used in P2PE

Modified p. 65 → 90

• An approved key-generation function of a PCI

•approved HSM or ~~PTS~~ POI device

• An approved key-generation function of a PCI-approved HSM or POI device

Removed p. 66

• approved HSM or PTS POI device

• An approved key-generation function of a FIPS 140- 2 or FIPS 140-3 Level 3 (or higher) HSM

<Report Findings Here> 5-1.c Examine procedures to be used for future generations and/or logs of past key generation to verify devices used for key-generation are those as noted above, including validation of firmware used.

Modified p. 66 → 90

• An approved key-generation function of a ~~PCI~~

• An approved key-generation function of a PCI-approved HSM or PTS POI device

Modified p. 66 → 90

• approved HSM or PTS POI device

• An approved key-generation function of a PCI

•approved HSM or PTS POI device

Modified p. 66 → 90

• An approved key-generation function of a FIPS ~~140- 2~~ or FIPS 140-3 Level 3 (or higher) HSM

• An approved key-generation function of a FIPS 140-2 or FIPS 140-3 Level 3 (or higher) HSM

Modified p. 66 → 90

~~• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22~~ Documented procedures examined: <Report Findings Here> 5-1.b Examine certification letters or technical documentation to verify that all devices used to generate cryptographic keys or key components meet one of the following:

Documented procedures examined: <Report Findings Here> 5-1.b Examine certification letters or technical documentation to verify that all devices used to generate cryptographic keys or key components meet one of the following:

Modified p. 66 → 90

• An approved key-generation function of a ~~PCI~~

• An approved key-generation function of a FIPS 140-2 or FIPS 140-3 Level 3 (or higher) HSM

Modified p. 66 → 90

• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 Certification ~~Letters/technical~~ documentation examined:

• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 Certification letters/technical documentation examined:

Modified p. 67 → 91

6-1.1 Any cleartext output of the key-generation process must be managed under dual control. Only the assigned custodian can have direct access to the ~~clear text~~ of any key component/share. Each custodian’s access to cleartext output is limited to the individual component(s)/share(s) assigned to that custodian, and not to the entire key.

6-1.1 Any cleartext output of the key-generation process must be managed under dual control. Only the assigned custodian can have direct access to the cleartext of any key component/share. Each custodian’s access to cleartext output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key.

Modified p. 67 → 91

• Each custodian’s access to cleartext output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key Documented procedures examined: ~~<Report Findings Here> 6-1.1.b Observe key-generation process demonstration and interview responsible personnel to verify:~~

• Each custodian’s access to cleartext output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key Documented procedures examined:

Modified p. 67 → 92

~~• Each custodian’s access to cleartext output is limited to the individual component(s)/share(s) assigned to that custodian and not the entire key Responsible personnel interviewed:~~ <Report Findings Here> Describe how the ~~key generation~~ processes observed verified that any cleartext output of the key-generation process is overseen by only the assigned key custodian(s) for that component/share and is limited to those individual components and not the entire key:

<Report Findings Here> Describe how the key-generations processes observed verified that any cleartext output of the key-generation process is overseen by only the assigned key custodian(s) for that component/share and is limited to those individual components and not the entire key:

Modified p. 68 → 92

6-1.2.a Examine documented procedures for all ~~key- generation~~ methods and observe demonstrations of the key-generation process from ~~end-to-end~~ to verify there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a cleartext key or all the components for a key.

6-1.2.a Examine documented procedures for all key-generation methods and observe demonstrations of the key-generation process from end-to- end to verify there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a cleartext key or all the components for a key.

Modified p. 68 → 92

Documented procedures examined: <Report Findings Here> Describe how the end-to-end process ~~observed~~ verified that there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a cleartext key or all the components for a key:

Documented procedures examined: <Report Findings Here> Describe how the end-to-end process verified that there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a cleartext key or all the components for a key:

Modified p. 68 → 92

• At least two individuals performed the key-generation processes Key-generation logs examined:

• At least two individuals performed the key-generation processes Key-generation logs examined: <Report Findings Here>

Modified p. 69 → 93

~~6-1.3.a~~ Examine documented procedures for all ~~key- generation~~ methods. Verify procedures require that:

6-1.3 Examine documented procedures for all key-generation methods. Verify procedures require that:

Modified p. 70 → 94

6-1.4.a Examine documented procedures for all ~~key- generation~~ methods to verify they include inspections of the key-generation equipment for evidence of tampering prior to use. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a cleartext key or key component (e.g., a tapping device).

6-1.4.a Examine documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment for evidence of tampering prior to use. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a cleartext key or key component (e.g., a tapping device).

Modified p. 71 → 94

Describe how the physical security controls observed verified that key-component/key- generation process cannot be observed or accessed by unauthorized personnel:

Describe how the physical security controls observed verified that the key-component/key- generation process cannot be observed or accessed by unauthorized personnel:

Modified p. 72 → 95

Additionally, this requirement excludes from its scope computers used only for administration of SCDs, or ~~key-generation~~ devices that do not have the ability to access cleartext cryptographic keys or components.

Additionally, this requirement excludes from its scope computers used only for administration of SCDs, or key- generation devices that do not have the ability to access cleartext cryptographic keys or components.

Modified p. 72 → 95

~~Documented procedures examined:~~ <Report Findings Here> 6-2.b Observe the generation process and examine documentation for each type of key to verify that ~~multi- purpose~~ computing systems are not used for key generation where any cleartext secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD except where Requirement 5 and Requirement 13 are met.

<Report Findings Here> 6-2.b Observe the generation process and examine documentation for each type of key to verify that multi-purpose computing systems are not used for key generation where any cleartext secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD except where Requirement 5 and Requirement 13 are met.

Modified p. 73 → 96

~~Printers~~ used for this purpose must not be used for other purposes, must not be networked (i.e., locally connected only), and must be managed under dual control. Location must be a secure room that meets requirements 6.3.1 through 6.3.9.

.Printers used for this purpose must not be used for other purposes, must not be networked (i.e., locally connected only), and must be managed under dual control. Location must be a secure room that meets requirements 6.3.1 through 6.3.9.

Removed p. 74

<Report Findings Here> 6-3.2 Any windows into the secure room must be:

Modified p. 75 → 98

• Enforces dual-access (i.e., the presence of at least two individuals) requirements for entry into the secure room, and anti-pass-back ~~requirements.~~

• Enforces dual-access (i.e., the presence of at least two individuals) requirements for entry into the secure room, and anti-pass-back requirements

Modified p. 75 → 98

• Supports generation of an alarm when one person remains alone in the secure room for more than 30 ~~seconds.~~

• Supports generation of an alarm when one person remains alone in the secure room for more than 30 seconds 6-3.3.a Observe authorized personnel entering the secure room to verify that a badge-control system is in place that enforces the following requirements:

Modified p. 75 → 98

• Anti-pass-back <Report Findings Here> 6-3.3.b Examine alarm mechanisms and interview ~~alarm- response~~ personnel to verify that the badge-control system supports generation of an alarm when one person remains alone in the secure room for more than 30 seconds.

• Anti-pass-back <Report Findings Here> 6-3.3.b Examine alarm mechanisms and interview alarm-response personnel to verify that the badge-control system supports generation of an alarm when one person remains alone in the secure room for more than 30 seconds.

Modified p. 75 → 98

Identify the P2PE Assessor who confirms that CCTV monitoring includes the ability to record events during dark periods, and verify that, if motion-activated, recording continues for at least a minute after the last pixel of activity ~~subsides.~~

Identify the P2PE Assessor who confirms that CCTV monitoring includes the ability to record events during dark periods, and verify that, if motion-activated, recording continues for at least a minute after the last pixel of activity subsides:

Modified p. 76 → 99

Identify the P2PE Assessor who confirms through observation and interview of personnel that monitoring is supported on a continuous (24/7) basis and alarms can be resolved by authorized ~~personnel.~~

Identify the P2PE Assessor who confirms through observation and interview of personnel that monitoring is supported on a continuous (24/7) basis and alarms can be resolved by authorized personnel:

Modified p. 76 → 99

Identify the P2PE Assessor who confirms the CCTV server and digital storage are located in a secure location that is separate from the secure ~~room.~~

Identify the P2PE Assessor who confirms the CCTV server and digital storage are located in a secure location that is separate from the secure room:

Modified p. 76 → 99

<Report Findings Here> 6-3.6.b Examine access-control configurations for the CCTV server/storage secure location and the ~~key- injection~~ secure room to identify all personnel who have access to each area. Compare access lists to verify that personnel with access to the secure room do not have access to the CCTV server/storage secure location.

<Report Findings Here> 6-3.6.b Examine access-control configurations for the CCTV server/storage secure location and the key-injection secure room to identify all personnel who have access to each area. Compare access lists to verify that personnel with access to the secure room do not have access to the CCTV server/storage secure location.

Modified p. 76 → 99

Identify the P2PE Assessor who confirms all personnel who have access to the access- control configurations for the CCTV server/storage secure location and the key-injection secure room do not have access to the CCTV server/storage secure ~~location.~~

Identify the P2PE Assessor who confirms all personnel who have access to the access- control configurations for the CCTV server/storage secure location and the key-injection secure room do not have access to the CCTV server/storage secure location:

Removed p. 77

• Any equipment that is used.

Modified p. 77 → 99

6-3.7 Observe CCTV positioning and examine a sample of recordings to verify that CCTV cameras are positioned to monitor:

• Any equipment that is used 6-3.7 Observe CCTV positioning and examine a sample of recordings to verify that CCTV cameras are positioned to monitor:

Modified p. 77 → 99

• Any equipment that is used <Report Findings Here> ~~6-3.8 CCTV cameras must be positioned so they do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.~~

• Any equipment that is used <Report Findings Here>

Modified p. 77 → 100

Identify the P2PE Assessor who confirms through observation and examination of sample recordings that CCTV cameras do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication ~~credentials.~~

Identify the P2PE Assessor who confirms through observation and examination of sample recordings that CCTV cameras do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials:

Modified p. 78 → 100

Identify the P2PE Assessor who confirms digital-recording system configurations have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day ~~period.~~

Identify the P2PE Assessor who confirms digital-recording system configurations have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period:

Modified p. 78 → 100

Identify the P2PE Assessor who confirms at least the most recent 45 days of images are securely archived from captured ~~recordings.~~

Identify the P2PE Assessor who confirms at least the most recent 45 days of images are securely archived from captured recordings:

Modified p. 79 → 101

Examples of where such key residue may exist include (but are not limited to):

Examples of where such key residue may exist include (but are not limited to): • Printing material, including ribbons and paper waste

Modified p. 79 → 101

• deleted immediately after ~~generation~~

• deleted immediately after generation.

Modified p. 79 → 101

• Specific direction as to the method of destruction is included in the ~~procedure~~

• Specific direction as to the method of destruction is included in the procedure.

Modified p. 79 → 101

• deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the ~~key Examine logs of past destructions and deletions to verify that procedures are followed.~~

• deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the key.

Modified p. 79 → 101

Documented procedures examined: ~~<Report Findings Here>~~

Documented procedures examined:

Removed p. 80

• deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the key Describe how the destruction process of the identified key residue observed verified that any residue that may contain cleartext keys or components is destroyed or securely deleted immediately after generation:

Modified p. 80 → 102

• Any residue that may contain cleartext keys or components is destroyed or securely

• Any residue that may contain cleartext keys or components is destroyed or securely deleted immediately after generation

Modified p. 80 → 102

• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are

• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the key Describe how the destruction process of the identified key residue observed verified that any residue that may contain cleartext keys or components is destroyed or securely deleted immediately after …

Removed p. 81

6-5.a Examine documented procedures for asymmetric- key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either:

Modified p. 81 → 103

• If generated externally, the key pair and all related critical security parameters (e.g., secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key ~~pair.~~

• If generated externally, the key pair and all related critical security parameters (e.g., secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key pair 6-5.a Examine documented procedures for asymmetric-key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either:

Modified p. 81 → 103

• If generated externally, the key pair and all related critical security parameters are deleted (zeroized) immediately after the transfer to the device that will use the key pair Documented procedures for ~~asymmetric-key~~ generation examined:

• If generated externally, the key pair and all related critical security parameters are deleted (zeroized) immediately after the transfer to the device that will use the key pair Documented procedures for asymmetric- key generation examined:

Modified p. 83 → 105

• Conveying cleartext private or secret key components without containing them within ~~tamper- evident,~~ authenticable packaging

• Conveying cleartext private or secret key components without containing them within tamper-evident, authenticable packaging

Modified p. 84 → 106

~~Responsible personnel interviewed:~~ <Report Findings Here> 7-1.c Observe key-generation ceremonies, whether actual or for demonstration purposes, and verify that the documented procedures are demonstrably in use.

<Report Findings Here> 7-1.c Observe key-generation ceremonies, whether actual or for demonstration purposes, and verify that the documented procedures are demonstrably in use.

Modified p. 85 → 106

7-2.a Examine documented key-generation procedures to verify that ~~key-generation~~ events for higher-level keys (e.g., KEKs shared with other organizations or otherwise manually loaded as components and MFKs and BDKs) are logged.

7-2.a Examine documented key-generation procedures to verify that key- generation events for higher-level keys (e.g., KEKs shared with other organizations or otherwise manually loaded as components and MFKs and BDKs) are logged.

Modified p. 85 → 106

<Report Findings Here> 7-2.c Examine logs of key generation to verify that exchanges of ~~higher-level~~ keys with other organizations have been recorded and that all required elements were captured.

<Report Findings Here> 7-2.c Examine logs of key generation to verify that exchanges of higher- level keys with other organizations have been recorded and that all required elements were captured.

Modified p. 86 → 107

Note: Components/shares of encryption keys must be conveyed using different communication channels, such as different courier services. It is not sufficient to send key components/shares for a specific key on different days using the same communication ~~channel.~~

Note: Components/shares of encryption keys must be conveyed using different communication channels, such as different courier services. It is not sufficient to send key components/shares for a specific key on different days using the same communication channel 8-1.a Examine documentation and interview personnel (as needed) to determine whether keys are transmitted encrypted, as cleartext components/shares, and/or within an SCD. Carry out the additional testing procedures as applicable.

Removed p. 87

• There is a requirement that the package serial number is to be sent separately from the package itself

• Each component is to be sent to/from only the custodian(s) authorized for the component

• At least two communication channels are used to send the components of a given key (not just separation by sending on different days)

Modified p. 87 → 108

Examine documented procedures for sending components in ~~tamper-evident,~~ authenticable packaging to verify that:

• Examine documented procedures for sending components in tamper- evident, authenticable packaging to verify that:

Modified p. 87 → 108

• ~~They define how the details of the~~ package serial number ~~are to be~~ transmitted

• The package serial number was transmitted as prescribed

Modified p. 87 → 108

• ~~Prior to the use of the components, the serial numbers are to be confirmed~~ Examine documentation (e.g., record of past key transfers), interview personnel and observe as needed to verify that the process used to convey cleartext key ~~Documented procedures examined:~~

• Examine documentation (e.g., record of past key transfers), interview personnel and observe as needed to verify that the process used to convey cleartext key components using pre-numbered, tamper- evident, authenticable packaging, is sufficient to ensure:

Modified p. 87 → 108

~~<Report Findings Here> Responsible personnel interviewed:~~ <Report Findings Here> Describe how the observed method to convey cleartext key components using ~~tamper-evident~~ mailers verified ~~that details of the serial number of the package are transmitted separately from the package itself:~~

<Report Findings Here> Describe how the observed method to convey cleartext key components using tamper- evident mailers verified that:

Modified p. 88 → 108

• Prior to the use of the component, the serial number was ~~confirmed <Report Findings Here> 8-1.c If SCDs are used to convey components/shares:~~

• Prior to the use of the component, the serial number was confirmed.

Modified p. 89 → 109

• Examine records of key transfers and interview responsible personnel to verify the mechanisms that make the SCD operational are conveyed using separate communication channels ~~Records of key conveyances~~ examined:

• Examine records of key transfers and interview responsible personnel to verify the mechanisms that make the SCD operational are conveyed using separate communication channels Documented procedures examined:

Modified p. 90 → 110

E.g., in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such that any three key components or shares (i.e., m = 3) can be used to derive the key, no single individual can have access to more than two ~~components/shares.~~

E.g., in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such that any three key components or shares (i.e., m = 3) can be used to derive the key, no single individual can have access to more than two components/shares 8-2.a Examine documented procedures to verify they include controls to ensure that no single person can gain access to components or shares of this key or to any other medium containing other components or shares …

Modified p. 90 → 110

• Steps to ensure any person with access to the media conveying a component/share of a key could not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is sufficient to form the necessary threshold to derive the key, without detection Documented ~~device-configuration~~ procedures examined:

• Steps to ensure any person with access to the media conveying a component/share of a key could not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is sufficient to form the necessary threshold to derive the key, without detection Documented procedures examined:

Modified p. 91 → 111

• There is sufficient evidence to show that a person with access to the media conveying a key component or key share could not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key without detection Personnel interviewed: ~~<Report Findings Here> Describe how the observed key transfer processes verified that:~~

• There is sufficient evidence to show that a person with access to the media conveying a key component or key share could not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key without detection Personnel interviewed:

Modified p. 91 → 111

• An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying other components or shares of this key that are sufficient to form the necessary threshold to derive the key

• An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key

Modified p. 91 → 111

• Any person with access to the media conveying a key component or key share ~~must~~ not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key <Report Findings Here> 8-2.c Examine records of past key transfers to verify that the method used did not allow for any personnel to have access to components or shares …

• Any person with access to the media conveying a key component or key share could not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key without detection <Report Findings Here> 8-2.c Examine records of past key transfers to verify that the method used did not allow for any personnel to have access to components …

Modified p. 93 → 113

• Use of public-key certificates as defined in within this Domain that are created by a trusted CA that meets the applicable requirements of this Domain

• Use of public-key certificates as defined within this Domain that are created by a trusted CA that meets the applicable requirements of this Domain

Modified p. 93 → 113

Self-signed root certificates protect the integrity of the data within the certificate but do not guarantee the authenticity of the data. The authenticity of the root ~~certificate~~ is based on the use of secure procedures to distribute them. Specifically, they must be directly installed into the PIN pad of the ATM or POS device and not remotely loaded to the device subsequent to manufacture.

Self-signed root certificates protect the integrity of the data within the certificate but do not guarantee the authenticity of the data. The authenticity of the root certificates is based on the use of secure procedures to distribute them. Specifically, they must be directly installed into the PIN pad of the ATM or POS device and not remotely loaded to the device subsequent to manufacture.

Modified p. 93 → 113

For all methods used to convey public keys, perform the following:

8-4 For all methods used to convey public keys, perform the following:

Removed p. 94

Responsible personnel interviewed: <Report Findings Here> Describe how the observed process for conveying public keys verified that all methods ensure public keys are conveyed in a manner that protects their integrity and authenticity:

Modified p. 94 → 114

~~<Report Findings Here> 8-4.c Observe~~ the process for conveying public ~~keys, associated logs, and interview responsible personnel to verify~~ that ~~the implemented method ensures~~ public keys are conveyed in a manner that protects their integrity and ~~authenticity.~~

Describe how the observed process for conveying public keys verified that all methods ensure public keys are conveyed in a manner that protects their integrity and authenticity:

Modified p. 95 → 114

• Sealed in a security container or courier mailer (including ~~pre-numbered,~~ tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or

• Sealed in a security container or courier mailer (including pre- numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or

Modified p. 95 → 114

• Contained within a physically secure ~~SCD Documented procedures examined:~~

• Contained within a physically secure SCD.

Modified p. 96 → 115

Documented procedures examined: ~~<Report Findings Here>~~

Documented procedures examined:

Modified p. 96 → 115

• Sealed in a security container or courier mailer (including ~~pre-numbered~~ tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or ~~contained within a physically secure SCD Responsible personnel interviewed:~~

• Sealed in a security container or courier mailer (including pre- numbered tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or

Modified p. 96 → 115

• ~~Locked~~ in a security container (including pre-numbered ~~tamper-evident,~~ authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, ~~unauthorized access to it would be detected,~~ or

• Sealed in a security container or courier mailer (including pre-numbered tamper- evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or

Modified p. 96 → 115

• ~~Contained~~ within a physically secure SCD <Report Findings Here> 9-2 Packaging or mailers (i.e., pre-numbered, tamper-evident packaging) containing cleartext key components must be examined for evidence of tampering before being opened. Any sign of package tampering indicating a component was potentially compromised must be assessed and the analysis formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the destruction and replacement of:

• contained within a physically secure SCD <Report Findings Here> 9-2 Packaging or mailers (i.e., pre-numbered, tamper-evident packaging) containing cleartext key components must be examined for evidence of tampering before being opened. Any sign of package tampering indicating a component was potentially compromised must be assessed and the analysis formally documented. If a compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the destruction and replacement of:

Removed p. 97

<Report Findings Here> 9-2.c Examine documented procedures require that any sign of package tampering is identified, reported, and, if compromise is confirmed, ultimately results in the destruction and replacement of both:

Modified p. 97 → 115

~~Responsible personnel interviewed:~~ <Report Findings Here> Describe how the processes observed verified that all packaging or mailers containing cleartext key components are examined for evidence of tampering before being opened:

<Report Findings Here> Describe how the processes observed verified that all packaging or mailers containing cleartext key components are examined for evidence of tampering before being opened:

Modified p. 97 → 116

• The set of ~~components, and~~

• The set of components

Modified p. 97 → 116

~~• Any keys encrypted under this (combined) key Responsible personnel interviewed :~~ <Report Findings Here> Describe how the process observed verified that if a package shows signs of tampering, processes are implemented that result in the destruction and replacement of both:

<Report Findings Here> Describe how the process observed verified that if a package shows signs of tampering, processes are implemented that result in the destruction and replacement of both:

Modified p. 97 → 116

• Any keys encrypted under this (combined) key Documented records examined: ~~<Report Findings Here>~~

• Any keys encrypted under this (combined) key Documented records examined:

Modified p. 98 → 117

9-3.a Examine the list(s) of key ~~custodians and~~ designated ~~backup(s) authorized~~ to have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.

9-3.a Examine the list(s) of key custodians⎯and designated backup(s)⎯authorized to have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.

Modified p. 98 → 117

~~Documentation examined:~~ <Report Findings Here> 9-3.b Observe implemented access controls and processes to verify that only those authorized key ~~custodians and~~ designated ~~backup(s) have~~ physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.

<Report Findings Here> 9-3.b Observe implemented access controls and processes to verify that only those authorized key custodians⎯and designated backup(s)⎯have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.

Modified p. 98 → 117

Describe the implemented access controls and processes observed that verified that only those authorized key custodians (and designated backup(s)) have physical access to key components prior to being secured in transmittal ~~packaging:~~

Describe the implemented access controls and processes observed that verified that only those authorized key custodians (and designated backup(s)) have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging <Report Findings Here> 9-3.c Examine physical access logs (e.g., to security containers for key components) to verify that only the authorized individual(s) have access to each component.

Removed p. 99

• Place the key component into pre-numbered tamper- evident packaging for transmittal

• Place the key component into pre-numbered tamper- evident packaging for transmittal

• Upon receipt, check the tamper-evident packaging for signs of tampering prior to opening the tamper- evident packaging containing the key component

• Upon receipt, check the tamper-evident packaging for signs of tampering prior to opening the tamper- evident packaging containing the key component

• Check the serial number of the tamper-evident packaging upon receipt of a component package Documented examined: <Report Findings Here> 9-4.b Observe implemented mechanisms and processes and examine logs to verify that only the authorized key custodians can perform the following:

• Check the serial number of the tamper-evident packaging upon receipt of a component package Describe how the implemented mechanisms and processes observed verified that only the authorized key custodians can perform the following:

Modified p. 99 → 118

• Check tamper-evident packaging upon receipt for signs of ~~tampering~~ prior to opening tamper-evident authenticable packaging containing key components.

• Check tamper-evident packaging upon receipt for signs of tamper prior to opening tamper-evident authenticable packaging containing key components.

Modified p. 99 → 118

• Check the serial number of the tamper-evident packaging upon receipt of a component package.

Check the serial number of the tamper-evident packaging upon receipt of a component package.

Modified p. 99 → 118

• Upon receipt, check the tamper-evident packaging for signs of ~~tampering~~ prior to opening the tamper-evident packaging containing the key component

• Upon receipt, check the tamper-evident packaging for signs of tamper prior to opening the tamper-evident packaging containing the key component

Modified p. 100 → 119

• Examine logs to verify that procedures are followed Documented procedures examined: ~~<Report Findings Here> Responsible personnel interviewed:~~

• Examine logs to verify that procedures are followed Documented procedures examined:

Modified p. 100 → 119

<Report Findings Here> Describe how the observed method used to transport cleartext key components using ~~tamper- evident~~ mailers verified that details of the serial number of the package are transmitted separately from the package itself:

<Report Findings Here> Describe how the observed method used to transport cleartext key components using tamper-evident mailers verified that details of the serial number of the package are transmitted separately from the package itself:

Modified p. 101 → 120

• The components are repackaged at receipt into separate ~~tamper-evident~~ and authenticable packages for storage at the receiving location

• The components are repackaged at receipt into separate tamper- evident and authenticable packages for storage at the receiving location

Modified p. 102 → 121

• RSA keys encrypting keys greater in strength than 80 bits must have a bit strength of at least 112 bits 10-1.a Examine documented procedures to verify there is a requirement that all keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed, as delineated in Annex C. (except as noted for RSA keys).

• RSA keys encrypting keys greater in strength than 80 bits must have a bit strength of at least 112 bits 10-1.a Examine documented procedures to verify there is a requirement that all keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed, as delineated in Annex C (except as noted for RSA keys).

Modified p. 102 → 121

~~Documented procedures examined:~~ <Report Findings Here> 10-1.b Examine documented procedures and interview personnel as needed to verify the requirement is satisfied for all applicable keys. Consider keys manually transferred (e.g., cryptograms sent to an Encryption and Support Organisation (ESO)) as well as those that are system-generated and transferred (e.g., KEK or TMK encrypting working keys).

<Report Findings Here> 10-1.b Examine documented procedures and interview personnel as needed to verify the requirement is satisfied for all applicable keys. Consider keys manually transferred (e.g., cryptograms sent to an Encryption and Support Organisation (ESO)) as well as those that are system-generated and transferred (e.g., KEK or TMK encrypting working keys).

Removed p. 103

• TDEA keys used for encrypting keys must be at least triple-length keys (have an effective bit strength of 112 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment

• A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength

• TDEA keys are not used to protect AES keys.

• TDEA keys are not used to encrypt keys greater in strength than 112 bits

• RSA keys encrypting keys greater in strength than 80 bits have a bit strength at least 112 bits Describe how the key-generation processes observed verified that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed, as delineated in Annex C.

<Report Findings Here> 10-1.d Examine system documentation and configuration files to validate the above, including HSM settings.

Modified p. 103 → 122

<Report Findings Here> 10-2 to 10-5 Not used in P2PE

<Report Findings Here> 10-2 to 10-5 Not used in P2PE 11-1 Written procedures must exist and be known to all affected parties.

Modified p. 104 → 122

Responsible personnel interviewed: <Report Findings Here> ~~11-2 Methods used for the conveyance or receipt of keys must be documented.~~

Responsible personnel interviewed: <Report Findings Here>

Modified p. 104 → 123

~~11-2.a~~ Observe documented procedures include all methods used for the conveyance or receipt of keys.

11-2 Observe documented procedures include all methods used for the conveyance or receipt of keys.

Modified p. 105 → 123

Documented ~~procedures~~ examined: <Report Findings Here> 12-1.b Interview appropriate personnel to determine the number of key components for each manually loaded key.

Documented process examined: <Report Findings Here> 12-1.b Interview appropriate personnel to determine the number of key components for each manually loaded key.

Modified p. 105 → 123

Appropriate personnel interviewed: <Report Findings Here> 12-1.c Observe the key-loading processes for all key types ~~(e.g.,MFKs,~~ AWKs, TMKs, DEKs, etc.). Verify the number and length of the key components against information provided through verbal discussion and written documentation.

Appropriate personnel interviewed: <Report Findings Here> 12-1.c Observe the key-loading processes for all key types (MFKs, AWKs, TMKs, DEKs, etc.). Verify the number and length of the key components against information provided through verbal discussion and written documentation.

Modified p. 105 → 123

<Report Findings Here> 12-1.d Observe that the process ~~to verify it~~ includes the entry of individual key components by the designated key custodians.

<Report Findings Here> 12-1.d Observe that the process includes the entry of individual key components by the designated key custodians.

Modified p. 106 → 124

12-2.a. Examine logs of access to security containers for key components/shares to verify that only the authorized custodian(s) have ~~accessed them.~~ Compare the number on the current tamper-evident and authenticable package for each component to the last log entry for that component.

12-2.a. Examine logs of access to security containers for key components/shares to verify that only the authorized custodian(s) have accessed. Compare the number on the current tamper-evident and authenticable package for each component to the last log entry for that component.

Modified p. 106 → 124

Trace historical movement of higher-order keys (MFK, KEK, and BDK) in and out of secure storage to ensure there is no break in the ~~package-number~~ chain that would call into question authorized handling and sufficient storage of the component or share. This must address at a minimum the time frame from the date of the prior audit.

Trace historical movement of higher-order keys (MFK, KEK, and BDK) in and out of secure storage to ensure there is no break in the package- number chain that would call into question authorized handling and sufficient storage of the component or share. This must address at a minimum the time frame from the date of the prior audit.

Modified p. 106 → 124

Access logs examined:

Access logs examined: <Report Findings Here>

Removed p. 107

• There is a requirement that if passwords/authentication codes or tokens are used, they be maintained separately Documented procedures examined:

Modified p. 107 → 125

Note: Passwords/authentication codes to the same object may be assigned to a custodian group ~~team e.g.,~~ custodian team for component A.

Note: Passwords/authentication codes to the same object may be assigned to a custodian group team⎯e.g., custodian team for component A.

Modified p. 107 → 125

12-3.a Examine documented procedures for loading of cleartext cryptographic keys to ~~verify that:~~

12-3.a Examine documented procedures for loading of cleartext cryptographic keys to verify:

Modified p. 107 → 125

• Procedures require dual control to authorize any ~~key- loading session~~

• Procedures require dual control to authorize any key-loading session.

Modified p. 107 → 125

• The techniques to be used to achieve dual control are ~~identified~~

• The techniques to be used to achieve dual control are identified.

Modified p. 107 → 125

• There is a requirement to change any default passwords/authentication codes and set passwords/authentication codes that have at least five characters

• There is a requirement to change any default passwords/authentication codes and set passwords/authentication codes that have at least five characters There is a requirement that if passwords/authentication codes or tokens are used, they are maintained separately.

Modified p. 107 → 125

Documented procedures examined: <Report Findings Here>

Modified p. 108 → 126

• Dual control is necessary to authorize the ~~key- loading~~ session

• Dual control is necessary to authorize the key-loading session

Modified p. 108 → 126

• Default passwords/authentications codes are ~~reset.~~

• Default passwords/authentications codes are reset

Modified p. 108 → 126

<Report Findings Here> 12-3.d Observe that any default dual-control mechanisms (e.g., default passwords/authentication codes

•usually printed in the vendor's manual ~~•in a key-loading device) have been disabled or changed.~~

<Report Findings Here> 12-3.d Observe that any default dual-control mechanisms (e.g., default passwords/authentication codes

•usually printed in the vendor's manual

Modified p. 109 → 127

12-4.a Examine documented procedures for combining symmetric-key components and observe processes to verify that key components are combined using a process such that no active bit of the key can be determined without knowledge of the remaining ~~components e.g.,~~ only within an SCD.

12-4.a Examine documented procedures for combining symmetric-key components and observe processes to verify that key components are combined using a process such that no active bit of the key can be determined without knowledge of the remaining components−e.g., only within an SCD.

Modified p. 109 → 127

Describe how ~~the~~ key-component lengths or device configuration settings ~~observed~~ verified that key components used to create a key are the same length as the resultant key:

Describe how key-component lengths or device configuration settings verified that key components used to create a key are the same length as the resultant key:

Modified p. 109 → 127

<Report Findings Here> 12-5 Hardware security module (HSM) Master File ~~Keys (MFK),~~ including those generated internal to the HSM and never exported, must use AES with a key size of at least 128 bits.

<Report Findings Here> 12-5 Hardware security module (HSM) Master File Keys, including those generated internal to the HSM and never exported, must use AES with a key size of at least 128 bits.

Modified p. 109 → 127

~~12-5.a~~ Examine vendor documentation describing options for how the HSM MFK is created and verify the current MFK was created using AES (or triple-length TDEA for existing P2PE implementations only). Corroborate this via observation of processes, with information gathered during the interview process, and procedural documentation provided by the entity under review.

12-5 Examine vendor documentation describing options for how the HSM MFK is created and verify the current MFK was created using AES (or triple-length TDEA for existing P2PE implementations only). Corroborate this via observation of processes, with information gathered during the interview process, and procedural documentation provided by the entity under review.

Modified p. 110 → 128

Documented procedures examined: <Report Findings Here> Personnel interviewed: <Report Findings Here> Describe ~~how it was~~ confirmed that any devices that are loaded with the same key components use the same mathematical process to derive the final key:

Documented procedures examined: <Report Findings Here> Personnel interviewed: <Report Findings Here> Describe the observations that confirmed that any devices that are loaded with the same key components use the same mathematical process to derive the final key:

Removed p. 111

<Report Findings Here> 12-8 If key-establishment protocols using public-key cryptography are used to remotely distribute secret keys, these must meet the applicable requirements detailed in this document. For example:

Modified p. 112 → 129

• Providing for mutual device authentication for both the host and the POI device or host-to-host if applicable Identify the P2PE Assessor who confirms that requirements detailed in this document are met where key-establishment protocols using ~~public- key~~ cryptography are used to remotely distribute secret keys:

• Providing for mutual device authentication for both the host and the POI device or host-to-host if applicable Identify the P2PE Assessor who confirms that requirements detailed in this document are met where key-establishment protocols using public-key cryptography are used to remotely distribute secret keys:

Modified p. 112 → 129

<Report Findings Here> ~~12.9~~ Not used in ~~EMS~~

<Report Findings Here> 12-9 Not used in DMS

Modified p. 113 → 130

• Observe cameras are positioned to ensure they cannot monitor the entering of cleartext key ~~components~~

• Observe cameras are positioned to ensure they cannot monitor the entering of cleartext key components.

Modified p. 114 → 130

• The SCD is inspected to ensure it has not been subject to any prior ~~tampering or unauthorized modification,~~ which could lead to the disclosure of cleartext keying material <Report Findings Here>

• The SCD is inspected to ensure it has not been subject to any prior tampering, which could lead to the disclosure of cleartext keying material <Report Findings Here>

Modified p. 115 → 131

<Report Findings Here> 13-2.b Observe a demonstration of key loading to verify that only SCDs are used in the loading of cleartext secret or private keys or their components outside of a secure key-loading facility.

Documented procedures examined: <Report Findings Here> 13-2.b Observe a demonstration of key loading to verify that only SCDs are used in the loading of cleartext secret or private keys or their components outside of a secure key-loading facility.

Modified p. 115 → 131

Describe how the ~~observed~~ demonstration verified that only SCDs are used in the loading of cleartext secret or private keys or their components outside of a secure ~~key-loading~~ facility.

Describe how the key loading demonstration verified that only SCDs are used in the loading of cleartext secret or private keys or their components outside of a secure key- loading facility.

Removed p. 116

• All traces of the component are erased or otherwise destroyed from the electronic medium <Report Findings Here>

Modified p. 116 → 132

• Instructions for the medium to be placed into secure storage and managed under dual control (only if there is a possibility it will be required for future ~~re- loading~~ of the component into the cryptographic device); or

• Instructions for the medium to be placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or

Modified p. 116 → 132

• Instructions to erase or otherwise destroy all traces of the component from the electronic medium, including the method to use Documented procedures examined:

• Instructions to erase or otherwise destroy all traces of the component from the electronic medium, including the method to use Documented procedures examined: <Report Findings Here> 13-3.b Observe key-loading processes to verify that the injection process results in one of the following:

Modified p. 116 → 132

• The medium used for key injection is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or

• The medium used for key injection is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or • All traces of the component are erased or otherwise destroyed from the electronic medium in accordance with Requirement 24 <Report Findings Here> 13-3.c Examine records/logs of erasures to confirm that:

Removed p. 117

Logs examined: <Report Findings Here> 13-4 Secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device must meet the following requirements (13-4.1 through 13-4.8):

Modified p. 117 → 132

• The documented procedure was ~~followed.~~

• The documented procedure was followed

Modified p. 117 → 132

• The method used was in accordance with Requirement ~~24.~~

• The method used was in accordance with Requirement 24 Records examined: <Report Findings Here>

Modified p. 117 → 133

13-4.1 The key-loading device must be a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.

13-4.1 The key-loading device must be a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected. Note: A PCI-approved KLD meets this requirement for an SCD.

Modified p. 117 → 133

<Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the ~~key- loading~~ device is a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected:

Documented procedures examined: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected:

Modified p. 118 → 133

Note: Furniture-based locks or containers with a limited set of unique keys

•e.g., desk drawers

•are not sufficient to meet this requirement.

<Report Findings Here> 13-4.2 The key-loading device must be under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it. Note: Furniture-based locks or containers with a limited set of unique keys

•e.g., desk drawers

•are not sufficient to meet this requirement.

Modified p. 118 → 133

<Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the ~~key- loading~~ device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it:

Documented procedures examined: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it:

Modified p. 118 → 134

<Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the ~~key- loading~~ device is designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another ~~SCD:~~

Documented procedures examined: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD. Such personnel must ensure that a key-recording device is not inserted between the SCDs.

Modified p. 119 → 134

Documented procedures examined: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the ~~key- loading~~ device does not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred:

Documented procedures examined: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device does not retain any information that might disclose the key (e.g., allow replay of the key for injection into a non-SCD) that was installed in the device or a key that it has successfully transferred:

Modified p. 120 → 135

Key components that can be read (e.g., those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in ~~clear text~~ to anyone who is not a designated custodian for that component.

Key components that can be read (e.g., those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in cleartext to anyone who is not a designated custodian for that component.

Modified p. 120 → 135

• The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading process Documented procedures examined:

• The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading process Documented procedures examined: <Report Findings Here> 13-5.c Interview designated component holder(s) and examine key- management logs to verify that media or devices removed from secure storage are in the physical possession of only the designated component holder(s).

Modified p. 121 → 135

<Report Findings Here> 13-5.d Interview key-injection personnel and examine logs for the removal of media/devices from secure storage to verify they are removed only for the minimum practical time necessary to complete the key-loading process.

<Report Findings Here> Key-management logs examined: <Report Findings Here> 13-5.d Interview key-injection personnel and examine logs for the removal of media/devices from secure storage to verify they are removed only for the minimum practical time necessary to complete the key-loading process.

Modified p. 121 → 135

Key-injection personnel interviewed:

Key-injection personnel interviewed: <Report Findings Here> Logs examined: <Report Findings Here>

Modified p. 122 → 136

Describe how the observed key-loading processes verified that printed/written ~~key-component~~ documents are not opened until immediately prior to use:

Describe how the observed key-loading processes verified that printed/written key component documents are not opened until immediately prior to use:

Removed p. 124

• All resources (e.g., passwords and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading <Report Findings Here>

Modified p. 124 → 137

• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control

• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control Describe the observation of key-loading environments and controls and how they verified that:

Modified p. 124 → 137

• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control

• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control • All resources (e.g., passwords and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading

Modified p. 124 → 138

• All resources (e.g., passwords/authentication codes and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading ~~Describe~~ the ~~observation~~ of ~~key-loading environments and controls and how~~ they ~~verified that:~~

• All resources (e.g., passwords/authentication codes and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading <Report Findings Here> 14-2 All cable attachments over which cleartext keying material traverses must be examined at the beginning of an entity’s key activity operations (system power on/authorization) to ensure they have not been tampered with or compromised.

Modified p. 126 → 138

14-3.a Observe key-loading activities to verify that ~~key- loading~~ equipment usage is monitored.

14-3.a Observe key-loading activities to verify that key-loading equipment usage is monitored.

Modified p. 127 → 139

Identify the P2PE Assessor who confirms adequacy of ~~reviewed~~ storage locations for physical tokens to ensure that only the authorized custodian(s) can access their specific tokens:

Identify the P2PE Assessor who confirms adequacy of examined storage locations for physical tokens to ensure that only the authorized custodian(s) can access their specific tokens:

Modified p. 127 → 139

<Report Findings Here> 14-4.d Examine access-control logs and ~~verify they~~ are in use including notation of tamper-evident, authenticable bag numbers.

<Report Findings Here> 14-4.d Examine that access-control logs exist and are in use including notation of tamper-evident, authenticable bag numbers.

Modified p. 127 → 139

Access-control logs examined: <Report Findings Here>

Access-control logs examined: <Report Findings Here> 14-4.e Examine documented procedures, interview personnel, and observe processes as needed to reconcile storage contents to access-control logs.

Modified p. 130 → 141

<Report Findings Here> 15-3 ~~not~~ used in ~~EMS~~ 15-4 ~~not~~ used in ~~EMS~~ 15-5 ~~not~~ used in ~~EMS~~

<Report Findings Here> 15-3 Not used in DMS 15-4 Not used in DMS 15-5 Not used in DMS

Modified p. 131 → 142

16-1.a Examine documented procedures and verify they exist for all ~~key-loading~~ operations.

16-1.a Examine documented procedures and verify they exist for all key- loading operations.

Modified p. 131 → 142

Documented procedures examined: <Report Findings Here> 16-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for all ~~key-loading~~ operations.

Documented procedures examined: <Report Findings Here> 16-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for all key- loading operations.

Modified p. 131 → 142

Log files examined: <Report Findings Here> Describe how the logging processes observed verified that audit trails are in place for all ~~key- loading~~ events:

Log files examined: <Report Findings Here> Describe how the logging processes observed verified that audit trails are in place for all key-loading events:

Modified p. 132 → 143

• Be unique to those two entities or logically separate ~~systems, and~~

• Be unique to those two entities or logically separate systems

Modified p. 132 → 143

Documented key matrix examined: <Report Findings Here> Documented operational procedures examined: ~~<Report Findings Here> Personnel interviewed: <Report Findings Here>~~

Documented key matrix examined: <Report Findings Here> Documented operational procedures examined:

Modified p. 133 → 143

• Observe and/or test to generate or otherwise obtain ~~key check~~ values for any ~~key- encipherment~~ keys (KEKs) to verify key uniqueness between the two organizations. A random sample may be used where more than 10 zone connections are in use. This is not intended to be based on values retained on paper or otherwise sent as part of the original conveyance of the keying material, but rather on values generated from stored zone production keys from the production host …

• Observe and/or test to generate or otherwise obtain key-check values for any key-encipherment keys (KEKs) to verify key uniqueness between the two organizations. A random sample may be used where more than 10 zone connections are in use. This is not intended to be based on values retained on paper or otherwise sent as part of the original conveyance of the keying material, but rather on values generated from stored zone production keys from the production host database. Cryptograms …

Modified p. 133 → 143

• If a remote key-establishment and distribution scheme is implemented between networks, examine public keys and/or hash values and/or fingerprints of the keys to verify key uniqueness of the ~~asymmetric-key~~ pairs

• If a remote key-establishment and distribution scheme is implemented between networks, examine public keys and/or hash values and/or fingerprints of the keys to verify key uniqueness of the asymmetric- key pairs

Modified p. 133 → 143

• Observe ~~key check~~ values against those for known or default keys to verify that known or default key values are not used Describe how the generation of (or otherwise obtaining) key check values for any key- encipherment keys ~~(KEKs), public keys, and/or hash values and/or fingerprints (where a remote key-establishment and distribution scheme is implemented)~~ verified key uniqueness between the two organizations:

• Observe key-check values against those for known or default keys to verify that known or default key values are not used Describe how the generation of (or otherwise obtaining) key check values for any key- encipherment keys (KEKs) verified key uniqueness between the two organizations:

Removed p. 134

• Proactive safeguards that shut down the source of any synchronization errors and start an investigative process to determine the true cause of the event Documented procedures examined: <Report Findings Here>

Modified p. 134 → 144

• Specific actions that determine whether the legitimate value of the cryptographic key has changed. (For example, encryption of a known value to determine whether the resulting cryptogram matches the expected ~~result)~~

Specific actions that determine whether the legitimate value of the cryptographic key has changed. (For example, encryption of a known value to determine whether the resulting cryptogram matches the expected result.) Proactive safeguards that shut down the source of any synchronization errors and start an investigative process to determine the true cause of the event.

Removed p. 135

18-2.a Examine the documented procedures to verify they require that key-component packaging/containers showing signs of tampering indicating a component was potentially compromised are assessed and the analysis is formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.

Modified p. 135 → 144

Documented procedures examined: <Report Findings Here> 18-2.b Interview personnel and observe processes to verify procedures are implemented to require that ~~key- component~~ packaging/containers showing signs of tampering ~~indicating a component was potentially compromised are assessed and the analysis is formally documented. If compromise is confirmed, and the~~ result ~~is that one person could have knowledge of the key, it results~~ in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they …

Documented procedures examined: <Report Findings Here> 18-2.b Interview personnel and observe processes to verify procedures are implemented to require that key-component packaging/containers showing signs of tampering result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.

Modified p. 135 → 144

<Report Findings Here> Describe how the processes observed verified that procedures are implemented to require that key-component packaging/containers showing signs of tampering result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist:

Personnel interviewed: <Report Findings Here> Describe how the processes observed verified that procedures are implemented to require that key-component packaging/containers showing signs of tampering result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist:

Modified p. 136 → 145

<Report Findings Here> 18-4 Not used in ~~EMS~~

<Report Findings Here> 18-4 Not used in DMS

Modified p. 137 → 146

19-1.a Examine key-management documentation (e.g., the ~~cryptographic-key~~ inventory) and interview key custodians and key-management supervisory personnel to verify that cryptographic keys are defined for a specific purpose.

19-1.a Examine key-management documentation (e.g., the cryptographic- key inventory) and interview key custodians and key-management supervisory personnel to verify that cryptographic keys are defined for a specific purpose.

Modified p. 137 → 146

Key-management documentation <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Key-management documentation examined: <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Modified p. 137 → 146

Sample of device types ~~reviewed:~~ <Report Findings Here> Describe how review of check values, terminal definition files, etc. verified that keys used for key encipherment are not used for any other purpose:

Sample of device types examined: <Report Findings Here> Describe how review of check values, terminal definition files, etc. verified that keys used for key encipherment or PIN encipherment are not used for any other purpose:

Modified p. 138 → 147

• Must be used only for a single purpose

•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI ~~devices).~~

• Must be used only for a single purpose

•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices)

Modified p. 138 → 147

• Must never be used to encrypt other ~~keys.~~

• Must never be used to encrypt other keys

Modified p. 138 → 147

• When used for remote key distribution, must not be used in connection with any other ~~purpose.~~

• When used for remote key distribution, must not be used in connection with any other purpose

Removed p. 139

Note: For logically partitioned HSMs and computing platforms, if one or more logical partitions of a physical device are used for production and one or more other logical partitions are used for testing, including QA or similar, the entire configuration that is impacted

•computing platform(s) and networking equipment

•must be managed and controlled as production.

Modified p. 139 → 148

Keys used for ~~production~~ must y present or used in a production system.

• Keys used for testing keys must never be present or used in a production system.

Modified p. 139 → 148

19-4.a Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that cryptographic keys are never shared or substituted between production and ~~test/development~~ systems.

19-4.a Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that cryptographic keys are never shared or substituted between production and development systems.

Modified p. 139 → 148

<Report Findings Here> 19-4.b Observe processes for generating and loading keys into production systems to ensure that they are in no way associated with test or development keys.

<Report Findings Here> 19-4.b Observe processes for generating and loading keys into in production systems to ensure that they are in no way associated with test or development keys.

Modified p. 139 → 148

<Report Findings Here> 19-4.d Examine/observe check, hash, cryptogram, or fingerprint values for production and test/development keys ~~with~~ higher-level keys ~~(MFKs,~~ KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.

<Report Findings Here> 19-4.d Examine/observe check, hash, cryptogram, or fingerprint values for production and test/development keys for higher-level keys (e.g., MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.

Modified p. 140 → 149

• deleted from the HSM(s) and the server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and

• deleted from the HSM(s) and the key-injection server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and

Modified p. 140 → 149

At all ~~times,~~ the HSMs and servers/computers must be physically and logically secured in accordance with these requirements.

At all times the HSMs and servers/computers must be physically and logically secured in accordance with these requirements.

Modified p. 140 → 149

• Prior to reuse for production ~~purposes,~~ the HSM is returned to factory state

• Prior to reuse for production purposes the HSM is returned to factory state

Modified p. 140 → 149

• split knowledge as stated in these requirements Personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> 19-6 Not used in ~~EMS~~ 19-7 Not used in ~~EMS~~ 19-8 Not used in ~~EMS~~

• split knowledge as stated in these requirements Personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> 19-6 Not used in DMS 19-7 Not used in DMS 19-8 Not used in DMS 19-9 Not used in DMS 19-10 Not used in DMS 19-11 Not used in DMS 19-12 Not used in DMS

Removed p. 141

POI device private keys must not exist anywhere but the specific POI device they belong to, except where generated external to the POI device and prior to the injection into the POI device.

Modified p. 141 → 150

This means not only the account-data-encryption key(s), but also keys that are used to protect other ~~keys,~~ firmware- authentication keys, ~~payment-application authentication~~ and ~~display-prompt~~ control keys. As stated in the requirement, this does not apply to public keys resident in the device.

This means that not only the account-data-encryption key(s), but also keys that are used to protect other keys: firmware- authentication keys, payment application authentication, and display prompt control keys. As stated in the requirement, this does not apply to public keys resident in the device.

Modified p. 141 → 150

20-1.a Examine documented procedures for the ~~loading~~ and usage of all keys used in transaction-originating POI devices. Verify the procedures ensure that all private and secret keys used in ~~transaction-originating~~ POI devices are:

20-1.a Examine documented procedures for the generation, loading, and usage of all keys used in transaction-originating POI devices. Verify the procedures ensure that all private and secret keys used in transaction- originating POI devices are:

Modified p. 141 → 150

• Known only to HSMs at the minimum number of facilities consistent with effective system ~~operations.~~

• Known only to HSMs at the minimum number of facilities consistent with effective system operations Documented procedures examined: <Report Findings Here> 20-1.b Observe HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POIs to verify that unique keys are generated and used for each POI device.

Modified p. 141 → 150

~~Documented procedures examined: <Report Findings Here> 20-1.b Observe HSM functions and procedures for generating and loading secret and private keys for use in~~ Describe how the observed HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POI devices verified that unique keys are generated and used for each POI device:

Describe how the observed HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POI devices verified that unique keys are generated and used for each POI device:

Modified p. 142 → 150

<Report Findings Here> 20-1.c Examine check values, ~~hash,~~ or fingerprint values for a sample of cryptographic keys from different POI devices to verify private and secret keys are unique for each POI device. This can include comparing a sample of POI public keys (multiple devices for each POI ~~device~~ vendor used) to determine that the associated private keys stored in the POI devices are unique per ~~device• i.e.,~~ the public keys are unique.

<Report Findings Here> 20-1.c Examine check values, hashes, or fingerprint values for a sample of cryptographic keys from different POI devices to verify private and secret keys are unique for each POI device. This can include comparing a sample of POI public keys (multiple devices for each POI vendor used) to determine that the associated private keys stored in the POI devices are unique per device•i.e., the public keys are unique.

Modified p. 142 → 151

This requirement refers to the use of a single “base” key to derive initial keys for many different PTS POI devices, using a key-derivation process as described above. This requirement does not preclude multiple unique keys being loaded on a single device, or for the device to use a unique key for derivation of other keys once loaded•e.g., as done with DUKPT.

This requirement refers to the use of a single “base” key to derive initial keys for many different PTS POI devices, using a key-derivation process as described above. This requirement does not preclude multiple unique keys being loaded on a single device, or for the device to use a unique key for the derivation of other keys once loaded•e.g., as done with DUKPT.

Modified p. 142 → 151

20-3.a Examine documented procedures and observe processes for generating initial keys. Verify the following is implemented where initial keys are generated by a ~~Documented procedures examined: <Report Findings Here> Key generation logs examined: <Report Findings Here>~~

20-3.a Examine documented procedures and observe processes for generating initial keys. Verify the following is implemented where initial keys are generated by a derivation process and derived from the same Base Derivation Key:

Removed p. 143

Describe how the processes observed for generating master keys verified that the following is implemented where master keys are generated by a derivation process and derived from the same Base Derivation Key:

Describe how the processes observed for generating master keys verified that derivation keys used to generate keys for multiple devices are never loaded into a PTS POI device:

<Report Findings Here> 20-4 Entities processing or injecting DUKPT or other key-derivation methodologies on behalf of multiple acquiring organizations must incorporate a segmentation strategy in their environments. Segmentation must use one or more of the following techniques:

Modified p. 143 → 151

• Unique data is used for the derivation process such that all ~~transaction-originating~~ PTS POI devices receive unique secret ~~keys.~~

• Unique data is used for the derivation process such that all transaction- originating PTS POI devices receive unique secret keys

Modified p. 143 → 151

• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating PTS POI ~~device.~~

• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating PTS POI device

Modified p. 143 → 151

• Examine key-generation/injection logs to ensure that sequential values included in unique key derivation are not ~~repeated.~~

• Examine key-generation/injection logs to ensure that sequential values included in unique key derivation are not repeated Documented procedures examined: <Report Findings Here> Key generation logs examined: <Report Findings Here> Describe how the observed processes for generating master keys verified that the following is implemented where master keys are generated by a derivation process and derived from the same Base Derivation Key:

Modified p. 143 → 151

• Unique data is used for the derivation process such that all transaction-originating PTS POI devices receive unique secret ~~keys.~~

• Unique data is used for the derivation process such that all transaction-originating PTS POI devices receive unique secret keys

Modified p. 143 → 151

• Key derivation is performed prior to a key being loaded/sent to the recipient ~~transaction- originating~~ PTS ~~POI.~~

• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating PTS POI device <Report Findings Here> 20-3.b Examine/observe to verify that derivation keys used to generate keys for multiple devices are never loaded into a PTS POI device.

Modified p. 143 → 151

~~<Report Findings Here> 20-3.b Examine/observe to verify~~ that derivation keys used to generate keys for multiple devices are never loaded into a PTS POI ~~device.~~

Describe how the processes for generating master keys verified that derivation keys used to generate keys for multiple devices are never loaded into a PTS POI device:

Modified p. 143 → 152

20-4 Examine documented key-generation and injection procedures to verify that entities processing or injecting DUKPT or other key-derivation methodologies ~~Documented procedures examined: <Report Findings Here>~~

20-4 Examine documented key-generation and injection procedures to verify that entities processing or injecting DUKPT or other key-derivation methodologies incorporate a segmentation strategy in their environments using one or more of the following techniques:

Modified p. 144 → 152

• Different BDKs by geographic region, market segment, processing platform, or sales unit FOR COMPONENT PROVIDERS ONLY: Examine documented ~~key-generation~~ and injection procedures to verify that key-injection vendors use at least one unique Base Derivation Key (BDK) per acquiring organization and are able to support segmentation of multiple BDKs of acquiring organizations.

• Different BDKs by geographic region, market segment, processing platform, or sales unit FOR COMPONENT PROVIDERS ONLY: Examine documented key- generation and injection procedures to verify that key-injection vendors use at least one unique Base Derivation Key (BDK) per acquiring organization and are able to support segmentation of multiple BDKs of acquiring organizations.

Modified p. 144 → 152

Personnel interviewed: <Report Findings Here> Describe how the observed key-injection processes for devices associated with different acquiring organizations verified that Base Derivation Key(s) unique to each organization are used:

Documented procedures examined: <Report Findings Here> Personnel interviewed: <Report Findings Here> Describe how the observed key-injection processes for devices associated with different acquiring organizations verified that Base Derivation Key(s) unique to each organization are used:

Modified p. 144 → 152

<Report Findings Here> 20-5 Not used in ~~EMS~~ 20-6 Not used in ~~EMS~~

<Report Findings Here> 20-5 Not used in DMS 20-6 Not used in DMS

Removed p. 145

Note: Key-injection facilities may have cleartext keying material outside of a SCD when used within a secure room in accordance with Requirement 32.

Note for hybrid decryption solutions: Cleartext Data Decryption Keys (DDKs) may temporarily be retained by the Host System in volatile memory for the purpose of decrypting account data.

Modified p. 145 → 153

21-1.a Examine documented procedures for key storage and usage to verify that secret or private keys only exist in one or more approved forms at all times when ~~stored (with the exception of DDKs used on the Host System for hybrid decryption solutions).~~

• Contained within a secure cryptographic device 21-1.a Examine documented procedures for key storage and usage to verify that secret or private keys only exist in one or more approved forms at all times when stored.

Modified p. 145 → 153

<Report Findings Here> 21-1.b Observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when ~~stored (with the exception of DDKs used on the Host System for hybrid decryption solutions).~~

Documented procedures examined: <Report Findings Here> 21-1.b Observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when stored.

Modified p. 145 → 153

21-2 Examine documented procedures and interview personnel to determine all instances where key components/shares are used.

21-2 Examine documented procedures and interview responsible personnel to determine all instances where key components/shares are used.

Removed p. 146

<Report Findings Here> 21-2.3 Each key component/share must have one or more specified authorized custodians.

Modified p. 146 → 153

21-2.2 Construction of the cryptographic key must require the use of at least two key components/shares.

<Report Findings Here> 21-2.2 Construction of the cryptographic key must require the use of at least two key components/shares.

Modified p. 146 → 153

Describe how the processes observed for constructing keys verified that at least two key ~~components~~ are required for each key construction:

Describe how the processes observed for constructing keys verified that at least two key components/shares are required for each key construction:

Modified p. 146 → 154

Describe how the ~~key-component~~ access controls and key-custodian authorizations/assignments observed verified that all individuals with access to key ~~components~~ are designated as key custodians for those particular ~~components:~~

Describe how the key-component/share access controls and key-custodian authorizations/assignments observed verified that all individuals with access to key components/shares are designated as key custodians for those particular components/shares:

Modified p. 147 → 155

In an m-of-n scheme where n=5, where three shares are required to reconstruct the cryptographic key, a single custodian may be permitted to have access to two of the key shares (e.g., share A and share ~~B);~~ and a second custodian (with, in this example, share C) would be required to reconstruct the final key, ensuring that dual control is maintained.

In an m-of-n scheme where n=5, where three shares are required to reconstruct the cryptographic key, a single custodian may be permitted to have access to two of the key shares (e.g., share A and share B), as; and a second custodian (with, in this example, share C) would be required to reconstruct the final key, ensuring that dual control is maintained.

Modified p. 147 → 155

Describe how the ~~key-component~~ access controls and access logs observed verified that authorized custodians cannot access sufficient key components or shares to reconstruct a secret or private cryptographic key:

Describe how the key-component/share access controls and access logs observed verified that authorized custodians cannot access sufficient key components or shares to reconstruct a secret or private cryptographic key:

Removed p. 148

Note: Tamper-evident authenticable packaging

•opacity may be envelopes within tamper-evident packaging

Modified p. 148 → 156

• used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must be given to any embossing or other possible methods to “read” the component without opening of the packaging. Similarly, if the component is stored on a magnetic ~~card,~~ or other media that can be read without direct physical contact, the packaging should be designed to prevent such access to the key component.

Note: Tamper-evident, authenticable packaging (opacity may be envelopes within tamper-evident packaging) used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must be given to any embossing or other possible methods to “read” the component without opening of the packaging. Similarly, if the component is stored on a magnetic card or other media that can be read without direct physical contact, the packaging should be …

Modified p. 148 → 156

21-3.1.a Examine key components and storage locations to verify that components are stored in individual opaque, ~~pre-numbered, tamper-evident, authenticable~~ packaging that prevents the determination of the key component without noticeable damage to the packaging.

21-3.1.a Examine key components and storage locations to verify that components are stored in individual opaque, pre-numbered tamper-evident packaging that prevents the determination of the key component without noticeable damage to the packaging.

Modified p. 148 → 156

Describe how the key components and storage locations observed verified that components are stored in opaque, pre-numbered tamper-evident packaging that prevents the determination of the key component without noticeable damage to the packaging:

Describe how the key components and storage locations observed verified that components are stored in individual opaque, pre-numbered tamper-evident packaging that prevents the determination of the key component without noticeable damage to the packaging:

Modified p. 148 → 156

<Report Findings Here> 21-3.1.b Examine tamper-evident packaging used to secure key components ~~•e.g.,~~ is the package sufficiently opaque to prevent reading of a component ~~•and~~ ensure that it prevents the determination of the key component without visible damage to the packaging.

<Report Findings Here> 21-3.1.b Examine tamper-evident packaging used to secure key components e.g., is the package sufficiently opaque to prevent reading of a component and ensure that it prevents the determination of the key component without visible damage to the packaging.

Removed p. 149

<Report Findings Here> 21-3.2 Key components/shares for each specific custodian must be stored in a separate secure container that is accessible only by the custodian and/or designated backup(s).

Modified p. 149 → 156

Identify the P2PE Assessor who confirms that start-up instructions and other notes used by service technicians do not contain ~~initialization- key~~ values written in the clear:

Identify the P2PE Assessor who confirms that start-up instructions and other notes used by service technicians do not contain initialization-key values written in the clear:

Modified p. 149 → 157

• Each secure container is accessible only by the custodian and/or designated backup(s) Identify the P2PE Assessor who confirms that for each key ~~component~~ storage container:

• Each secure container is accessible only by the custodian and/or designated backup(s) Identify the P2PE Assessor who confirms that for each key component/share storage container:

Modified p. 149 → 157

• Key ~~components~~ for different custodians are stored in separate secure containers

• Key components/shares for different custodians are stored in separate secure containers

Modified p. 149 → 157

<Report Findings Here> 21-4 Not used in DMS

Removed p. 150

22-1.2 Interview responsible personnel and observe implemented processes to verify that if unauthorized alteration is suspected, new keys are not installed until the SCD (or, for hybrid decryption solutions, the Host System) has been inspected and assurance reached that Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if unauthorized alteration is suspected, new keys are not installed until the SCD (or, for hybrid decryption solutions, the Host System) has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification:

Modified p. 150 → 158

Documented procedures examined: <Report Findings Here> 22-1.1 Key ~~components~~ are never reloaded when there is any suspicion that either the originally loaded key or the SCD ~~(or, for hybrid decryption solutions, the Host System)~~ has been compromised.

Documented procedures examined: <Report Findings Here> 22-1.1 Key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.

Modified p. 150 → 158

22-1.1 Interview responsible personnel and observe implemented processes to verify key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD ~~(or, for hybrid decryption solutions, the Host System)~~ has been compromised.

22-1.1 Interview responsible personnel and observe implemented processes to verify key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.

Modified p. 150 → 158

<Report Findings Here> Identify the P2PE Assessor who confirms that key components/shares are never reloaded when there is a suspicion that either the originally loaded key or the SCD ~~(or, for hybrid decryption solutions, the Host System)~~ has been compromised.

Responsible personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.

Modified p. 150 → 158

<Report Findings Here> 22-1.2 If unauthorized alteration is suspected, new keys are not installed until the SCD ~~(or, for hybrid decryption solutions, the Host System)~~ has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification.

<Report Findings Here> 22-1.2 If unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification.

Removed p. 151

<Report Findings Here> 22-1.3. A secret or private cryptographic key must be

Modified p. 151 → 159

Known or suspected substitution of a secret key must result in the replacement of that key and based on an analysis of how the key was substituted, any associated key-encipherment keys that may have been compromised 22-1.3 Interview responsible personnel and observe implemented processes to verify that if compromise of the cryptographic key is suspected, an assessment and analysis is performed. If compromise is confirmed, and all the following are performed:

Known or suspected substitution of a secret key must result in the replacement of that key and based on an analysis of how the key was substituted, any associated key-encipherment keys that may have been compromised.

Modified p. 151 → 159

• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if compromise of the cryptographic key is suspected, an assessment and analysis is performed. If compromise is confirmed, the following are performed:

• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if compromise of the cryptographic key is suspected, an assessment and analysis is performed. If compromise is confirmed, all the following are performed:

Modified p. 151 → 159

• ~~Processing with~~ that key is halted, and the key is replaced with a new unique key

• Use of that key is halted, and the key is replaced with a new unique key

Removed p. 152

<Report Findings Here> 22-1.5 Identification of specific events that would indicate a compromise may have occurred. Such events must include but are not limited to:

• Host System tamper-detection mechanism has been activated, for hybrid decryption solutions

Modified p. 152 → 160

Responsible personnel interviewed: <Report Findings Here> ~~Describe how~~ the implemented processes observed verified that key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s):

Responsible personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> 22-1.4.b Examine/observe notifications to verify they include the following:

Modified p. 152 → 161

• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation

• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 22-1.5 Interview responsible personnel and examine documented procedures to verify that specific events that may indicate a compromise are identified. This must include, at a minimum, the following events:

Removed p. 153

PDCP Responsible personnel interviewed: <Report Findings Here>

Modified p. 153 → 161

• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation

• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation Responsible personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here>

Modified p. 153 → 162

~~• Host System tamper-detection mechanism has been activated, for hybrid decryption solutions~~ Responsible personnel interviewed: <Report Findings Here> ~~Documented procedures examined: <Report Findings Here> 22-2 If~~ attempts to load a secret key or key component into an KLD or POI device ~~(or a Host System, for hybrid decryption solutions)~~ fail, the same key or component ~~must~~ not be loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from …

Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if attempts to load a secret key or key component into an KLD or POI device fail, the same key or component is not loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI device:

Removed p. 154

Describe how the implemented processes observed verified that if attempts to load a secret key or key component into an KLD or POI device fail, the same key or component is not loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI device (or Host System):

Modified p. 154 → 162

<Report Findings Here> 22-3 Not used in ~~EMS~~ 22-4 Not used in ~~EMS~~ 22-5 Not used in ~~EMS~~

<Report Findings Here> 22-3 Not used in DMS 22-4 Not used in DMS 22-5 Not used in DMS

Modified p. 155 → 163

23-1.a Examine documented procedures and interview responsible personnel to determine whether keys are generated using reversible ~~key-calculation~~ methods.

23-1.a Examine documented procedures and interview responsible personnel to determine whether keys are generated using reversible key- calculation methods.

Removed p. 156

A logical configuration is defined as one where all the components form a system used to undertake a particular task and are managed and controlled under a single operational and security policy.

Modified p. 156 → 164

~~23-2.a~~ Interview responsible personnel to determine which host MFKs keys exist as variants.

23-2 Interview responsible personnel to determine which host MFKs keys exist as variants.

Modified p. 156 → 164

Describe how the ~~review~~ of the network schematic detailing transaction flows with the associated key usage and identification of the sources of the keys used verified that variants of the MFK are not used external to the logical configuration that houses the MFK:

Describe how the examination of the network schematic detailing transaction flows with the associated key usage and identification of the sources of the keys used verified that variants of the MFK are not used external to the logical configuration that houses the MFK:

Modified p. 157 → 165

• Variants used as KEKs must only be calculated from other ~~key-encrypting~~ keys

• Variants used as KEKs must only be calculated from other key- encrypting keys

Modified p. 157 → 165

• Variants of working keys must only be calculated from other working keys <Report Findings Here> ~~24-1 Instances of secret or private keys, and their key components, that are no longer used or that have been replaced by a new key must be destroyed.~~

• Variants of working keys must only be calculated from other working keys <Report Findings Here>

Modified p. 158 → 167

24-2.a Examine documented procedures for destroying keys and confirm they are sufficient to ensure that no part of the key or component can be recovered. ~~Documented procedures examined: <Report Findings Here> 24-2.b Observe key-destruction processes to verify that no part of the key or component can be recovered.~~

24-2.a Examine documented procedures for destroying keys and confirm they are sufficient to ensure that no part of the key or component can be recovered.

Modified p. 159 → 167

24-2.1.a Examine documented procedures for destroying keys and confirm that keys on all other storage media types in all permissible forms •physically secured, enciphered, or components

•must be destroyed following the procedures outlined in ISO

•9564 or ISO

• 11568.

24-2.1.a Examine documented procedures for destroying keys and confirm that keys on all other storage media types in all permissible forms

Modified p. 159 → 167

Documented procedures examined: <Report Findings Here> 24-2.1.b Observe key-destruction processes to verify that keys on all other storage media types in all permissible forms

•physically secured, enciphered, or ~~component~~

Documented procedures examined: <Report Findings Here> 24-2.1.b Observe key-destruction processes to verify that keys on all other storage media types in all permissible forms

•physically secured, enciphered, or components

•are destroyed following the procedures outlined in ISO

•9564 or ISO

•11568.

Modified p. 159 → 167

• ~~are~~ destroyed following the procedures outlined in ISO

• physically secured, enciphered, or components

•must be destroyed following the procedures outlined in ISO •9564 or ISO

•11568.

Modified p. 160 → 168

24-2.2.a Observe key-destruction process and verify that it is witnessed by a third party other than a key ~~custodian for any component of that key.~~

24-2.2.a Observe key-destruction process and verify that it is witnessed by a third party other than a key custodian.

Modified p. 160 → 168

<Report Findings Here> 24-2.2.b Examine key-destruction logs and verify that a third-party, ~~non-key-custodian~~ witness signs an affidavit as a witness to the ~~key destruction~~ process.

<Report Findings Here> 24-2.2.b Examine key-destruction logs and verify that a third-party, non- key-custodian witness signs an affidavit as a witness to the key-destruction process.

Modified p. 162 → 169

~~25-1.1.a~~ Examine key-custodian assignments for each component to verify that:

25-1.1 Examine key-custodian assignments for each component to verify that:

Modified p. 162 → 169

• Assigned key custodians are employees or contracted personnel Describe how the key-custodian assignments ~~reviewed~~ for each component verified that:

• Assigned key custodians are employees or contracted personnel Describe how the key-custodian assignments observed for each component verified that:

Modified p. 162 → 169

• ~~Key custodian(s)~~ are designated for each component

• A primary and a backup key custodian are designated for each component

Modified p. 163 → 170

• An effective date ~~and time~~ for the custodian’s access

• An effective date for the custodian’s access

Modified p. 163 → 170

• An effective date ~~and time~~ for the custodian’s access

• An effective date for the custodian’s access

Removed p. 164

Organizations that are of insufficient size that they cannot support the reporting-structure requirement must:

Modified p. 164 → 171

The components collectively held by an individual and his or her direct reports must not constitute a quorum (or must not provide any information about the value of the key that is not derivable from a single component).

The components collectively held by an individual and his or her direct reports must not constitute a quorum (or must not provide any information about the value of the key that is not derivable from a single component). Custodians must not become a custodian for a component/share of a key where the custodian has previously been or is currently a custodian for another component/share of that key if that would collectively constitute a quorum to form the actual key.

Modified p. 164 → 171

~~Ensure~~ key custodians do not report to each other (i.e., the manager cannot also be a key ~~custodian); Receive~~ explicit training to instruct them from sharing key components with their direct ~~manager; Sign~~ key-custodian agreements that ~~include~~ an attestation to the ~~requirement; and Receive training that includes procedures to report any violations.~~

Organizations that are of such insufficient size that they cannot support the reporting-structure requirement must ensure key custodians do not report to each other (i.e., the manager cannot also be a key custodian), receive explicit training to instruct them from sharing key components with their direct manager and must sign key-custodian agreements that includes an attestation to the requirement.

Modified p. 165 → 171

<Report Findings Here> Documented organization charts ~~examined:~~ <Report Findings Here> ~~25-1.4.b For organizations that are such a small, modest size that they cannot support the reporting-structure requirement, examine documented procedures and observe they are followed to:~~

<Report Findings Here> Documented organization charts reviewed: <Report Findings Here>

Modified p. 165 → 172

• Ensure training includes procedures to report any violations Documented procedures examined: <Report Findings Here> 25-2 Not used in ~~EMS~~ 25-3 Not used in ~~EMS~~ 25-4 Not used in ~~EMS~~

• Ensure training includes procedures to report any violations Documented procedures examined: <Report Findings Here> 25-2 Not used in DMS 25-3 Not used in DMS 25-4 Not used in DMS 25-5 Not used in DMS 25-6 Not used in DMS 25-7 Not used in DMS 25-8 Not used in DMS 25-9 Not used in DMS

Modified p. 166 → 173

• Tamper-evident ~~and authenticable~~ package number (if applicable) 26-1.a Interview responsible personnel and examine documented procedures to determine the following:

• Tamper-evident package number (if applicable) 26-1.a Interview responsible personnel and examine documented procedures to determine the following:

Modified p. 166 → 173

• Logs must be archived for a minimum of two years subsequent to key destruction Personnel interviewed:

• Logs must be archived for a minimum of two years subsequent to key destruction Personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> 26-1.b Examine log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:

Removed p. 167

• Tamper-evident package number (if applicable) <Report Findings Here>

Modified p. 167 → 173

• Loaded to an SCD Log files examined: <Report Findings Here> Describe how ~~log files and~~ audit log settings verified that logs are kept for any time that keys, key components, or related materials are:

• Loaded to an SCD Log files examined: <Report Findings Here> Describe how the audit log settings observed verified that logs are kept for any time that keys, key components, or related materials are:

Modified p. 167 → 173

• Loaded to an SCD <Report Findings Here> ~~26-1.c Examine log files to verify they are:~~

• Loaded to an SCD <Report Findings Here>

Modified p. 167 → 174

• Archived for a minimum of two years subsequent to key ~~destruction.~~

• Archived for a minimum of two years subsequent to key destruction

Modified p. 167 → 174

• Securely stored Log files examined: <Report Findings Here> ~~Describe how the~~ log files ~~examined verified~~ that ~~they are archived for a minimum of two years subsequent to key destruction.~~

• Securely stored Log files examined: <Report Findings Here> 26-1.d Examine log files and audit log settings to verify that logs include the following:

Modified p. 167 → 174

• ~~Key component~~ identifier

• Key-component identifier

Modified p. 167 → 174

• ~~Key component~~ identifier

• Key-component identifier

Modified p. 167 → 174

• Tamper-evident and authenticable package number (if applicable) Log files examined: <Report Findings Here> Describe how ~~log files and~~ audit log settings verified that logs include the following:

• Tamper-evident and authenticable package number (if applicable) Log files examined: <Report Findings Here> Describe how the audit log settings observed verified that logs include the following:

Modified p. 168 → 174

27-1.a Interview responsible personnel and examine documented procedures and backup records to determine whether any backup copies of keys or their components exist. ~~Perform the following:~~

27-1.a Interview responsible personnel and examine documented procedures and backup records to determine whether any backup copies of keys or their components exist.

Modified p. 168 → 174

~~Responsible personnel interviewed:~~ <Report Findings Here> ~~Documented procedures examined:~~ <Report Findings Here> Backup records examined: <Report Findings Here> 27-1.b Observe backup processes to verify backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys.

Documented procedures examined: <Report Findings Here> Personnel interviewed: <Report Findings Here> Backup records examined: <Report Findings Here> 27-1.b Observe backup processes to verify backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys.

Modified p. 168 → 175

• Subject to at least the same level of security control as operational keys as specified in this document ~~Documented procedures examined: <Report Findings Here> Personnel interviewed: <Report Findings Here>~~ Describe how backup storage locations verified that backups are maintained as follows:

• Subject to at least the same level of security control as operational keys as specified in this document Describe how the backup storage locations observed verified that backups are maintained as follows:

Modified p. 168 → 175

• Subject to at least the same level of security control as operational keys as specified in this document <Report Findings Here>

• Subject to at least the same level of security control as operational keys as specified in this document <Report Findings Here> 27-2 If backup copies are created, the following must be in place:

Modified p. 169 → 175

• Creation (including cloning) of top-level keys

•e.g., MFKs

•must require a minimum of two authorized individuals to enable the process.

• Creation (including cloning) must require a minimum of two authorized individuals to enable the process.

Modified p. 169 → 175

• The creation of any backup copies ~~for top-level keys~~ requires at least two authorized individuals to enable the process

• The creation of any backup copies requires at least two authorized individuals to enable the process

Modified p. 169 → 175

• The creation of any backup copies ~~for top-level keys~~ requires at least two authorized individuals to enable the process

• The creation of any backup copies requires at least two authorized individuals to enable the process

Modified p. 170 → 176

• Management of personnel changes, including revocation of access control and other privileges when personnel move 28-1.a Examine documented procedures for ~~key- administration~~ operations to verify they ~~cover all activities related to key administration, and~~ include:

• Management of personnel changes, including revocation of access control and other privileges when personnel move 28-1.a Examine documented procedures for key-administration operations to verify they include:

Modified p. 170 → 176

• Background checks for personnel (within the constraints of local ~~laws)~~

• Background checks for personnel (within the constraints of local laws

Modified p. 170 → 176

• Management of personnel changes, including revocation of access control and other privileges when personnel move Documented procedures examined: <Report Findings Here> 28-1.b Interview personnel responsible for ~~key- administration~~ operations to verify that the documented procedures are known and understood.

• Management of personnel changes, including revocation of access control and other privileges when personnel move Documented procedures examined: <Report Findings Here> 28-1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.

Modified p. 170 → 176

Responsible personnel interviewed: <Report Findings Here>

Responsible personnel interviewed: <Report Findings Here> 28-1.c Interview personnel to verify that security-awareness training is provided for the appropriate personnel.

Modified p. 171 → 176

<Report Findings Here> 28-2 Not used in ~~EMS~~ 28-3 Not used in ~~EMS~~ 28-4 Not used in ~~EMS~~ 28-5 Not used in ~~EMS~~

Responsible HR personnel interviewed: <Report Findings Here> 28-2 Not used in DMS 28-3 Not used in DMS 28-4 Not used in DMS 28-5 Not used in DMS

Modified p. 172 → 177

• SCDs used for ~~key injection/loading~~ have not been substituted or subjected to unauthorized modifications or tampering Documented ~~procedures~~ examined: <Report Findings Here> 29-1.b Observe processes and interview personnel to verify that processes are followed to provide the following assurances prior to the loading of cryptographic keys:

• SCDs used for key-injection/loading have not been substituted or subjected to unauthorized modifications or tampering Documented processes examined: <Report Findings Here> 29-1.b Observe processes and interview personnel to verify that processes are followed to provide the following assurances prior to the loading of cryptographic keys:

Modified p. 172 → 177

• SCDs used for ~~key injection/loading~~ have not been substituted or subjected to unauthorized modifications or tampering Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that processes are followed to provide the following assurances prior to the loading of cryptographic keys:

• SCDs used for key-injection/loading have not been substituted or subjected to unauthorized modifications or tampering Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that processes are followed to provide the following assurances prior to the loading of cryptographic keys:

Modified p. 172 → 177

• SCDs used for key injection/loading have not been substituted or subjected to unauthorized modifications or tampering

• SCDs used for key injection/loading have not been substituted or subjected to unauthorized modifications or tampering <Report Findings Here>

Removed p. 173

The minimum log contents include date and time, object name/identifier, purpose, name of individual(s) involved, signature or electronic capture (e.g., badge) of individual involved, and if applicable, tamper-evident package number(s) and serial number(s) of device(s) involved. Electronic logging e.g., using bar codes is acceptable for device tracking.

Modified p. 173 → 178

29-1.1 Examine documented procedures to verify controls are defined to protect POI ~~devices,~~ and other SCDs from unauthorized access up to point of deployment.

29-1.1 Examine documented procedures to verify controls are defined to protect POI devices and other SCDs from unauthorized access up to point of deployment.

Modified p. 173 → 178

Documented procedures examined: <Report Findings Here> 29-1.1.1 Access to all PTS POI ~~devices,~~ and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.

Documented procedures examined: <Report Findings Here> 29-1.1.1 Access to all PTS POI devices and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection. The minimum log contents include date and time, object name/identifier, purpose, name of individual(s) involved, signature or electronic capture (e.g., badge) of individual involved and, if applicable, tamper-evident package number(s) and serial number(s) of device(s) involved. Electronic logging⎯e.g., using bar codes⎯is acceptable for device tracking.

Modified p. 173 → 178

29-1.1.1.a Examine access-control documentation and device configurations to verify that access to all PTS POI devices and ~~key~~ injection/loading devices is defined and documented.

29-1.1.1.a Examine access-control documentation and device configurations to verify that access to all PTS POI devices and key- injection/loading devices is defined and documented.

Modified p. 174 → 179

• All personnel with access to PTS POI devices and other SCDs are ~~documented in a formal list~~ authorized by management in an auditable ~~manner.~~

• All personnel with access to PTS POI devices and other SCDs are authorized by management in an auditable manner

Modified p. 174 → 179

• The authorizations are reviewed annually Documented authorizations examined: <Report Findings Here> 29-1.1.2.b For a sample of ~~PTS~~ POI device types and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in an auditable manner have access to devices.

• The authorizations are reviewed annually Documented authorizations examined: <Report Findings Here> 29-1.1.2.b For a sample of POI device types and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in an auditable manner have access to devices.

Modified p. 174 → 179

Sample of PTS POI device types and other SCDs ~~reviewed:~~

Sample of PTS POI device types and other SCDs examined:

Modified p. 175 → 180

~~Documented procedures~~ examined: <Report Findings Here> 29-1.2.b Observe implemented processes and interview personnel to verify that default keys or passwords are not used.

Documentation examined: <Report Findings Here> 29-1.2.b Observe implemented processes and interview personnel to verify that default keys or passwords are not used.

Modified p. 175 → 180

~~Responsible personnel interviewed:~~ <Report Findings Here> 29-2 Not used in ~~EMS~~

<Report Findings Here> 29-2 Not used in DMS

Modified p. 176 → 181

• Physically secure and trackable packaging (e.g., pre-serialized, counterfeit-resistant, tamper-evident packaging) is ~~used.~~ The devices are then stored in such packaging, or in secure storage, until key-insertion occurs

• Physically secure and trackable packaging (e.g., pre-serialized, counterfeit-resistant, tamper-evident packaging) is in use. The devices are then stored in such packaging, or in secure storage, until key-insertion occurs

Modified p. 176 → 181

Note: Unauthorized access includes that by customs officials. o Devices incorporate self-tests to ensure their correct operation. Devices must not be re-installed unless there is assurance they have not been tampered with or compromised (Note: this control must be used in conjunction with one of the other methods) o Controls exist and are in use to ensure that all physical and logical controls and anti-tamper mechanisms used are not modified or removed 29-3.a Examine documented procedures to ~~verify~~ they require …

Note: Unauthorized access includes that by customs officials. o Devices incorporate self-tests to ensure their correct operation. Devices must not be re-installed unless there is assurance they have not been tampered with or compromised (Note: this control must be used in conjunction with one of the other methods) o Controls exist and are in use to ensure that all physical and logical controls and anti-tamper mechanisms used are not modified or removed 29-3.a Examine documented procedures to confirm that they …

Modified p. 176 → 181

~~Documented procedures examined:~~ <Report Findings Here>

Responsible personnel interviewed: <Report Findings Here>

Removed p. 177

Responsible personnel interviewed: <Report Findings Here> 29-4 Dual-control mechanisms must exist to prevent substitution or tampering of HSMs

•both deployed and spare or backup devices

•throughout their lifecycle. Procedural controls, which may be a combination of physical barriers and logical controls, may exist to support the prevention and detection of substituted HSMs, but cannot supplant the implementation of dual-control mechanisms.

• throughout their life cycle:

Modified p. 177 → 182

29-4.a Examine documented procedures to ~~verify~~ that dual-control mechanisms exist to prevent substitution or tampering of HSMs

•both deployed and spare or ~~back- up~~ devices

•throughout their life cycle.

29-4.a Examine documented procedures to confirm that dual-control mechanisms exist to prevent substitution or tampering of HSMs

•both deployed and spare or back-up devices

•throughout their life cycle.

Modified p. 177 → 182

Documented procedures examined: <Report Findings Here> 29-4.b Interview responsible personnel and physically verify the ~~dual-control~~ mechanism used to prevent substitution or tampering of HSMs •both in service and spare or back-up devices

•throughout their life cycle.

Documented procedures examined: <Report Findings Here> 29-4.b Interview responsible personnel and physically verify the dual- control mechanism used to prevent substitution or tampering of HSMs

Modified p. 177 → 182

Responsible personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who physically verified the dual-control mechanism used to prevent substitution or tampering of HSMs

Responsible personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who physically verified the dual-control mechanism used to prevent substitution or tampering of HSMs •both in service and spare or back- up devices

•throughout their life cycle:

Modified p. 177 → 182

• both ~~in service~~ and spare or back-up devices

• both in-service and spare or back-up devices •throughout their life cycle.

Modified p. 178 → 182

Note: Documents used for this process must be received via a different communication channel•i.e., the control document used must not have arrived with the equipment. An example of how serial numbers may be documented by the sender includes but is not limited to manufacturer’s invoice or similar document.

Note: Documents used for this process must be received via a different communication channel•i.e., the control document used must not have arrived with the equipment. An example of how serial numbers may be documented by the sender includes but is not limited to the manufacturer’s invoice or similar document.

Modified p. 178 → 182

Responsible personnel interviewed: <Report Findings Here> 29-4.1.b For a sample of received devices, examine sender documentation sent by a different communication channel than the ~~device’s~~ shipment (e.g., the manufacturer’s invoice or similar documentation) used to verify device serial numbers. Examine the record of serial-number validations to confirm the serial number for the received device was verified to match that documented by the sender.

Responsible personnel interviewed: <Report Findings Here> 29-4.1.b For a sample of received devices, examine sender documentation sent via a different communication channel than the devices shipment (e.g., the manufacturer’s invoice or similar documentation) used to verify device serial numbers. Examine the record of serial-number validations to confirm the serial number for the received device was verified to match that documented by the sender.

Modified p. 178 → 182

Sample of received devices: <Report Findings Here> Sender documentation/record of ~~serial~~ number validations examined:

Sample of received devices: <Report Findings Here> Sender documentation/record of serial- number validations examined:

Removed p. 179

Documented security policy examined: <Report Findings Here> 29-4.2.b Examine documentation of the HSM configuration settings from past commissioning events to determine that the functions and commands enabled are in accordance with the security policy.

Modified p. 179 → 183

<Report Findings Here> 29-4.2.c For a sample of HSMs, ~~examine~~ the configuration settings to determine that only authorized functions are enabled.

<Report Findings Here> 29-4.2.c For a sample of HSMs, review the configuration settings to determine that only authorized functions are enabled.

Modified p. 179 → 183

Sample of HSMs ~~examined:~~ <Report Findings Here> Describe how the HSM configuration settings observed verified that only authorized functions are enabled:

Sample of HSMs reviewed: <Report Findings Here> Describe how the HSM configuration settings observed verified that only authorized functions are enabled:

Modified p. 179 → 183

<Report Findings Here> 29-4.2.d Not used in P2PE 29-4.2.e Not used in P2PE

<Report Findings Here> 29-4.2.d Not used in P2PE 29-4.2.e Not used in P2PE 29-4.2.f Examine documentation to verify:

Modified p. 180 → 183

• The documentation is retained and updated anytime configuration setting impacting security occur for each affected HSM ~~Documentation~~ examined: <Report Findings Here> ~~29-4.3 When HSMs are connected to online systems, controls are in place to prevent the use of an HSM to perform privileged or sensitive functions that are not available during routine HSM operations.~~

• The documentation is retained and updated anytime configuration setting impacting security occur for each affected HSM Documented procedures examined: <Report Findings Here>

Modified p. 180 → 184

Describe how the HSM configurations examined and processes observed verified that HSMs are not enabled in a sensitive state when connected to online ~~systems:~~

Describe how the HSM configurations examined and processes observed verified that HSMs are not enabled in a sensitive state when connected to online systems.

Modified p. 180 → 184

Processes must ~~include :~~

Processes must include:

Modified p. 180 → 184

~~29-4.4.Examine~~ documented procedures to verify they require inspection and testing of HSMs prior to installation to verify the integrity of the device and include requirements specified at 29-4.4.1 through 29-4.4.4 below.

29-4.4 Examine documented procedures to verify they require inspection and testing of HSMs prior to installation to verify the integrity of the device and include requirements specified at 29-4.4.1 through 29-4.4.4 below.

Removed p. 181

Records of device inspections examined: <Report Findings Here> Describe how the records of device inspections and test results examined verified that self- tests are run on devices to ensure the correct operation of the device:

Modified p. 181 → 184

~~29-.4.4.1 Examine~~ records of device inspections and test results ~~to verify~~ that self-tests are run on devices to ensure the correct operation of the ~~device.~~

Records of device inspections examined: <Report Findings Here> Describe how records of device inspections and test results verified that self-tests are run on devices to ensure the correct operation of the device:

Modified p. 181 → 184

<Report Findings Here> 29-4.4.2 Installing (or re-installing) devices only after confirming that the device has not been tampered with or compromised.

<Report Findings Here> 29-4.4.2 Installing (or re-installing) devices only after confirming that the device has not been tampered with or compromised 29-4.4.2 Observe inspection processes and interview responsible personnel to verify that devices are installed, or reinstalled, only after confirming that the device has not been tampered with or compromised.

Modified p. 182 → 186

29-4.4.4.a Examine records of inspections and interview responsible personnel to verify records of the tests and inspections are maintained.

<Report Findings Here> 29-4.4.4 Maintaining records of the tests and inspections, and retaining records for at least one year 29-4.4.4.a Examine records of inspections and interview responsible personnel to verify records of the tests and inspections are maintained.

Modified p. 182 → 186

Records of inspections examined: <Report Findings Here> 29-5 Maintain HSMs in tamper-evident packaging or in secure storage until ready for installation.

Records of inspections examined: <Report Findings Here> 29-5 Maintain HSMs in tamper-evident packaging or in secure storage until ready for installation 29-5.a Examine documented procedures to verify they require devices be maintained in tamper-evident packaging until ready for installation.

Modified p. 182 → 186

Sample of received devices ~~examined:~~ <Report Findings Here> 30-1 Not used in P2PE 30-2 Not used in P2PE

Sample of received devices reviewed: <Report Findings Here> 30-1 Not used in P2PE 30-2 Not used in P2PE 30-3 Not used in DMS

Removed p. 183

Documented procedures examined: <Report Findings Here> PDCP Personnel interviewed: <Report Findings Here>

Modified p. 183 → 187

• Procedures require that all secret and private ~~keys,~~ key ~~material, and all account data~~ stored within the device be securely destroyed

• Procedures require that all secret and private keys and key material stored within the device be securely destroyed

Modified p. 183 → 187

• Procedures cover all devices removed from service ~~permanently~~ or for repair

• Procedures cover all devices removed from service or for repair

Modified p. 183 → 187

• Procedures cover requirements at 31-1.1 through ~~31- 1.6~~ below Documented procedures ~~examined:~~ <Report Findings Here> 31-1.1 HSMs require dual control (e.g., to invoke the system menu) to implement all critical decommissioning processes.

• Procedures cover requirements at 31-1.1 through 31-1.6 below Documented procedures reviewed: <Report Findings Here> 31-1.1 HSMs require dual control (e.g., to invoke the system menu) to implement for all critical decommissioning processes.

Modified p. 183 → 187

31-1.1.a Examine documented procedures for removing ~~HSMs~~ from service to verify that dual control is implemented for all critical decommissioning processes.

31-1.1.a Examine documented procedures for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes.

Removed p. 184

<Report Findings Here> 31-1.2 Keys and account data are rendered irrecoverable (e.g., zeroized) for SCDs. If data cannot be rendered irrecoverable, devices must be physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.

Modified p. 184 → 187

Describe how the demonstration ~~observed~~ verified that dual control is implemented for all critical decommissioning ~~processes.~~

Personnel interviewed: <Report Findings Here> Describe how the demonstration verified that dual control is implemented for all critical decommissioning processes:

Modified p. 184 → 188

31-1.2 Interview personnel and observe demonstration of processes for removing SCDs from service to verify that all keying material ~~and account data are~~ rendered irrecoverable (e.g., zeroized), or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.

31-1.2 Interview personnel and observe demonstration of processes for removing SCDs from service to verify that all keying material is rendered irrecoverable (e.g., zeroized), or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.

Modified p. 184 → 188

Personnel interviewed: <Report Findings Here> Describe how the demonstration verified that all keying material and account data ~~are~~ rendered irrecoverable, or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data or keys:

Personnel interviewed: <Report Findings Here> Describe how the demonstration verified that all keying material and account data is rendered irrecoverable, or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data or keys:

Modified p. 185 → 188

31-1.3 Interview personnel and observe processes for removing SCDs from service to verify that tests and inspections of devices are performed to confirm that keys ~~and account data~~ have been rendered ~~irrecoverable.~~

31-1.3 Interview personnel and observe processes for removing SCDs from service to verify that tests and inspections of devices are performed to confirm that keys have been rendered irrecoverable or the devices are physically destroyed.

Removed p. 186

Personnel interviewed: <Report Findings Here> Records of testing examined: <Report Findings Here> 32-1 For HSMs and other SCDs used for the generation or loading of cryptographic keys for use in POI devices, procedures must be documented and implemented to protect against unauthorized access and use.

Required procedures and processes include the following:

32-1.a Examine documented procedures to confirm that they specify protection against unauthorized access and use for HSMs and other devices used for the generation or loading of cryptographic keys for use in POI devices.

Documented procedures examined: <Report Findings Here> 32-1.b Verify that documented procedures cover requirements 32-1.1 through 32-1.5 below.

Removed p. 187

Note: Dual control consists of logical and/or physical characteristics. For example, dual control may be implemented for logical access via two individuals with two different passwords/authentication codes (at least five characters in length), or for physical access via a physical lock that requires two individuals each with a different high-security key.

For devices that do not support two or more passwords/authentication codes, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian. Each half must be a minimum of five characters.

Physical keys, authorization codes, passwords/authentication codes, or other enablers must be managed so that no one person can use both the enabler(s) and the device, which can create cryptograms of known keys or key components under a key-encipherment key used in production.

32-1.1 Observe dual-control mechanisms and device- authorization processes to confirm that logical and/or physical characteristics are …

Removed p. 188

• To enable any manual key-encryption functions and any key-encryption functions that occur outside of normal transaction processing

Removed p. 188

• For all access to key-loading devices (KLDs) and authenticated application-signing devices 32-1.3 Examine dual-control mechanisms and observe authorized personnel performing the defined activities to confirm that dual control is implemented for the following:

• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing

• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing

• For all access to KLDs and authenticated application-signing devices Dual-control mechanisms examined: <Report Findings Here> Describe how the observation of authorized personnel performing the defined activities verified that dual control is implemented for the following:

• For all access to KLDs and authenticated application-signing devices <Report Findings Here>

Removed p. 189

32-1.4.a Examine password policies and documented procedures to confirm default passwords/authentication codes must not be used for HSMs, KLDs, and other SCDs used to generate or load cryptographic keys, or to sign applications or whitelists.

Documented procedures and password policies examined:

<Report Findings Here> 32-1.4.b Observe device configurations and interview device administrators to verify that HSMs, KLDs and other SCDs used to generate or load cryptographic keys, or to sign applications or whitelists, do not use default passwords /authentication codes.

Device administrators interviewed: <Report Findings Here> Describe how the device configurations observed verified that HSMs, KLDs and other SCDs used to generate or load cryptographic keys, or to sign applications or whitelists, do not use default passwords:

Removed p. 190

• Locked in a secure cabinet and/or sealed in tamper-evident packaging, or

• Under the continuous supervision of at least two authorized people who ensure that any unauthorized use of the device would be detected.

Note: For key-injection facilities, or applicable entities providing key-management services, POI devices may be secured by storage in the dual-control access key injection room.

32-1.5.a Examine and confirm documented procedures require devices are within a secure room and are either:

• Locked in a secure cabinet and/or sealed in tamper- evident packaging at all times, or

• Locked in a secure cabinet and/or sealed in tamper- evident packaging at all times, or

• Under the continuous supervision of at least two authorized people at all times Documented procedures examined: <Report Findings Here> 32-1.5.b Interview responsible personnel and observe devices and processes to confirm that devices are at all times within a secure room and either:

• Under the continuous supervision of at …

Modified p. 191 → 190

33-1.a Examine documented procedures/processes and interview responsible personnel to verify that all affected parties are aware of required processes and are provided suitable guidance on procedures for ~~account-data processing~~ devices placed into service, initialized, deployed, used, and decommissioned.

33-1.a Examine documented procedures/processes and interview responsible personnel to verify that all affected parties are aware of required processes and are provided suitable guidance on procedures for devices placed into service, initialized, deployed, used, and decommissioned, Documented procedures examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 33-1.b Examine/observe that written records exist for the tests and inspections performed on devices before they are placed into service, as well as devices being decommissioned.

Removed p. 193

5A-1.3.a Examine documentation to verify it describes the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key- management solution.

Modified p. 193 → 191

• Crypto-periods are based on industry best practices and guidelines (e.g., NIST Special Publication ~~800- 57)~~

• Crypto-periods are based on industry best practices and guidelines (e.g., NIST Special Publication 800-57)

Modified p. 193 → 191

• A process/methodology is in place to determine when the ~~crypto-period~~ is reached for each cryptographic key

• A process/methodology is in place to determine when the crypto- period is reached for each cryptographic key

Modified p. 193 → 191

• Cryptographic key changes are implemented whenever a key reaches the end of its defined ~~crypto-period.~~

• Cryptographic key changes are implemented whenever a key reaches the end of its defined crypto-period Documented key-management procedures examined:

Modified p. 193 → 192

~~<Report Findings Here> 5A-1.2.b REMOVED 5A-1.3 Documentation describing~~ the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key-management ~~solution must exist and must be demonstrably in use for all key-management processes.~~

5A-1.3.a Examine documentation to verify it describes the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key-management solution.

Removed p. 194

<Report Findings Here> 5A-1.3.1 Maintain documentation of all cryptographic keys managed as part of the P2PE solution, including:

Modified p. 195 → 193

• Key-destruction method Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> ~~5A-1.3.2 Maintain a list of all devices used to generate keys or key components managed as part of the P2PE solution, including:~~

• Key-destruction method Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here>

Modified p. 196 → 194

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documentation reviewed: <Report Findings Here> Personnel interviewed:

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here>

Modified p. 196 → 195

<Report Findings Here> ~~5H-1 Not used in EMS~~

Modified p. 196 → 200

• For each type/model of PTS POI device and/or HSM: o Number of devices o Type of key(s) injected o Key-distribution method

• Details of any known or suspected compromised keys, per 22-1 Note: Adding, changing, or removing PTS POI devices and/or HSM types, or critical key-management methods may require Delta Change. Please refer to the PCI P2PE Program Guide for details about obligations when adding, changing, or removing elements of a Listed P2PE Product.

• For each type/model of PTS POI device and/or HSM: o Number of devices o Type of key(s) injected o Key-distribution method

• Details of any known or suspected compromised keys, per 22-1

Document Comparison

From Revision History

Content Changes