Document Diff - PCI Watch

Added p. 9

P2PE additional Assessor contact information (add additional rows as needed) Assessor name: Assessor credentials: QSA (P2PE) PA-QSA (P2PE) Assessor phone number: Assessor e-mail address:

Added p. 12

Decryption Management Services Decryption Management Yes No N/A

Added p. 13

If the entities PCI DSS compliance does not cover all environments:

• Describe how the entity has implemented network segmentation to isolate P2PE decryption environments from any non-PCI DSS compliant environments:

• Describe how the P2PE assessor validated the effectiveness of the segmentation:

Added p. 15

• Flows and locations of encrypted account data

• Flows and locations of clear-text account data

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

• All entities the decryption management services connect to 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 Component provider’s decryption environment.

<Insert Decryption Management Services data-flow diagram(s)>

Added p. 19

All documentation reviewed for this P2PE Assessment:

Decryption Management Services: P2PE Validation Requirements Summary of Findings (check one) In Place N/A Not in Place 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-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.

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

Added p. 22

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.

Public keys must be conveyed in a manner that protects their integrity and authenticity.

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

Added p. 22

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. 23

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 18 Procedures must exist to prevent or detect the unauthorized substitution (unauthorized key replacement and key misuse) of one key for another key or the operation of any cryptographic device without legitimate keys.

Added p. 24

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 32-1

• 32-9 are not used in DMS.

Added p. 25

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.

5H-1 Hybrid decryption solutions securely manage the Data decryption Keys (DDKs) that decrypt account data in software on a Host System.

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.

Algorithm

• e.g., TDEA, AES, RSA Cryptographic Mode(s) of Operation (as applicable ) Full Key Length (bits) Purpose/function of the key (including types of devices using key):

P2PE Decryption Management Services

• Reporting Decryption Management Services

• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 4A-1.1 All hardware security modules (HSMs) must be either:

• FIPS140-2 or 140-3 Level 3 (overall) or higher certified, or

• PCI PTS …

Added p. 29

Describe how HSM configurations for all P2PE security functions verified that HSMs are configured to operate according to the security policy that was included as part of the PTS approval:

<Report Findings Here> 4B-1.1 Current documentation must be maintained that describes or illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from POI devices, all systems within the decryption environment, and any outbound connections.

4B-1.1.a Review documentation to verify that a procedure exists to maintain a document that describes/illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from POI devices, all systems within the decryption environment, and any outbound connections.

Documented procedure reviewed: <Report Findings Here> 4B-1.1.b Interview responsible personnel and review solution-provider documentation to verify that it describes/illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction …

Added p. 29

• Console and non-console administration

Added p. 29

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

Added p. 30

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

• Use of HSM commands <Report Findings Here> 4B-1.2.c Observe personnel performing decryption-device administration and examine files/records that assign administrative roles and responsibilities to verify that only authorized and assigned personnel perform decryption-device administration operations.

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).

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 …

Added p. 31

• Physically connected devices 4B-1.5.a Examine documented procedure to verify that inspection of devices is required at least quarterly to detect signs of tampering or modification, and that inspection procedures include:

• Physically connected devices Documented procedures reviewed: <Report Findings Here> 4B-1.5.b Interview personnel performing inspections and observe inspection processes to verify that inspections include:

• Physically connected devices Personnel interviewed: <Report Findings Here> Describe how the inspection processes observed verified that inspections include the device itself, cabling/connection points, and physically connected devices:

Added p. 32

Personnel performing inspections interviewed:

<Report Findings Here> Supporting documentation reviewed: <Report Findings Here> 4B-1.6 Decryption environment must be secured according to PCI DSS.

Note: For merchant-managed solutions, PCI DSS validation of the decryption environment is managed by the merchant in accordance with their acquirer and/or payment brand. This requirement is therefore not applicable to P2PE assessments where merchants are the P2PE solution provider.

Note: The QSA (P2PE) should NOT challenge or re-evaluate the PCI DSS environment (or its compliance) where a completed and current ROC exists.

4B-1.6.a Review the “Description of Scope of Work and Approach Taken” section of the solution provider’s current PCI DSS Report on Compliance (ROC) to verify the PCI DSS assessment scope fully covers the P2PE decryption environment.

PCI DSS Report on Compliance (ROC) reviewed:

<Report Findings Here> 4B-1.6.b Review PCI DSS ROC and/or Attestation of Compliance (AOC) to verify that all applicable PCI DSS requirements are “in place” for the P2PE …

Added p. 33

4B-1.8.a Review documented processes and interview personnel to confirm that any truncated PANs sent back to the encryption environment adhere to the allowable number of digits as specified in PCI DSS and/or related FAQs.

Documented processes reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 4B-1.8.b Observe process flows and data flows to verify that there is no process, application, or other mechanism that sends more digits of truncated PANs back to the encryption environment than is specified in PCI DSS and/or related FAQs.

Describe how process flows and data flows verified that there is no process, application, or other mechanism that sends more digits of truncated PANs back to the encryption environment than is specified in PCI DSS and/or related FAQs:

<Report Findings Here> 4B-1.9 Any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must ensure that the ONLY allowed output of clear-text account data is …

Added p. 34

PCI payment brand account/card data Documented policies and procedures reviewed:

<Report Findings Here> 4B-1.9.1 Any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must allow ONLY the output of clear- text account data for non-PCI payment brand account/card data.

4B-1.9.1.a Observe application and system configurations and interview personnel to verify that whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows the output of clear-text account data for non-PCI payment brand account/card data.

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 clear-text account data for non-PCI payment brand account/card data:

<Report Findings Here> 4B-1.9.1.b Perform test transactions to verify that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows …

Added p. 36

• Changes to any security-sensitive configurations Describe how system configurations and correlating log files verified that any changes to the critical functions of decryption devices are logged, including:

• Changes to any security-sensitive configurations <Report Findings Here> 4C-1.2 Mechanisms must be implemented to detect and respond to suspicious activity, including but not limited to:

Added p. 36

• 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. 36

• 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 reviewed: <Report Findings Here>

• Unauthorized logical alterations (configuration, access controls)

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

• 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:

<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 clear-text account data through some error or misconfiguration.

4C-1.3 Examine documented procedures to verify controls are defined …

Added p. 39

Describe how the implemented processes observed verified that controls are in place to review data sent by any POI devices that are causing an unusually high rate of transaction authorization rejections:

<Report Findings Here> 4C-1.3.4.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections.

Describe the implemented controls and notification mechanisms observed that detect and provide immediate notification upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections:

<Report Findings Here> 4C-1.3.4.c Interview personnel to verify that designated personnel are immediately notified upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections.

Personnel interviewed: <Report Findings Here> 4C-1.4 All suspicious activity must be identified and a record maintained, at a minimum, for a year, to include at least the following:

Added p. 39

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

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

Added p. 39

• 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 reviewed: <Report Findings Here>

Added p. 40

• 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 data was transmitted from the POI device during the time that encryption was malfunctioning or disabled <Report Findings Here> 4C-1.5 Implement mechanisms 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).

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, …

Added p. 41

Indicate whether Host systems are in use within the decryption environment (yes/no).

<Report Findings Here> If “no”, describe how it was verified that Host systems are not in use.

(Leave 4D-1.1 to 5H-1.5.4.b blank) <Report Findings Here> If “yes”, complete 4D-1.1 to 5H-1.5.4.b:

4D-1.1 The solution provider must maintain current documentation that describes, or illustrates, the configuration of the Host System, including the flow of data and interconnectivity between all systems within the decryption environment.

4D-1.1.a Interview responsible personnel and review documentation to verify that a procedure exists to maintain a document that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems within the decryption environment.

Responsible personnel interviewed: <Report Findings Here> Documented procedure reviewed: <Report Findings Here> 4D-1.1.b Interview responsible personnel and review solution provider documentation that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems within that …

Added p. 42

Documented record of services, protocols, daemons required by the Host System reviewed:

<Report Findings Here> 4D-1.3 The Host System and HSM must reside on a network that is dedicated to decryption operations and transaction processing and must be segmented from any other network, or system, that is not performing or supporting decryption operations or transaction processing.

4D-1.3.a Examine network diagram(s) to verify the Host System(s) and HSM(s) are located on a network that is segmented from other networks that are not required for decryption operations or transaction processing.

Network diagram(s) reviewed: <Report Findings Here> 4D-1.3.b Inspect network and system configurations to verify the Host System(s) and HSM(s) are located on a network that is segmented from other networks not required for decryption operations or transaction processing.

Describe how network and system configuration settings verified that the Host System(s) and HSM(s) are located on a network that is segmented from other networks not required for …

Added p. 43

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:

<Report Findings Here> 4D-1.6 The Host System must perform a self-test when it is powered up to ensure its integrity before use. The self-test must include:

• Testing integrity of cryptographic functions.

• Testing integrity of firmware.

• Testing integrity of any security functions critical to the secure operation of the Host System.

4D-1.6.a Inspect Host System configuration settings, and examine vendor/solution provider documentation to verify that the Host …

Added p. 44

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

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

<Report Findings Here> 4D-1.8 The Host System must enter an error state and generate an alert upon any of the following events:

Added p. 44

• 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.

Added p. 45

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

<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 System enters an error state under one of the following conditions:

• Failure of a cryptographic operation, and

• Failure of a system self-test, as described in Requirements 4D-1.6 and 4D-1.7, and

• Failure of a security function or mechanism Personnel interviewed: <Report Findings Here> Logs/records of actual or test alerts examined:

<Report Findings Here> 4D-1.9 Alerts generated from the Host System must be documented and result in notification to authorized personnel and initiate a response procedure.

4D-1.9.a Review documented procedures …

Added p. 46

Sample of documented alert events examined:

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

<Report Findings Here> 4D-1.10 The Host System must not perform any cryptographic operations under any of the following conditions:

Added p. 46

• 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 reviewed: <Report Findings Here> 4D-1.10.b Inspect 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> 4D-1.11 All source code and executable code for cryptographic software and firmware on the Host System must be protected from unauthorized disclosure and unauthorized modification.

4D-1.11.a Inspect configuration documentation to verify that access controls are defined to …

Added p. 47

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 clear-text data-decryption keys must not be accessible to any processes or functions not directly required for decryption operations.

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

<Report Findings Here> 4D-1.12.b Inspect Host System configurations and access controls and to verify that clear-text decryption keys are not accessible to any processes or functions not directly required for decryption operations.

Describe how the Host System configurations and access controls inspected verified that clear-text decryption keys are not accessible to any processes or functions not directly required for decryption operations:

<Report Findings Here> 4D-1.13 The clear-text data-decryption keys must only be accessible to authorized personnel with …

Added p. 48

• Memory swap/page file purposes

• Core dumps of memory required for trouble-shooting Documented configuration procedures reviewed:

<Report Findings Here> 4D-1.14.b Examine Host System configuration settings and interview personnel to verify that clear-text cryptographic keys are not written to persistent storage except in the following circumstances:

• Memory swap/page file purposes.

• Memory swap/page file purposes.

• core dumps of memory required for trouble-shooting Personnel interviewed: <Report Findings Here> Describe how the Host System configuration settings examined verified that clear-text cryptographic keys are not written to persistent storage except in the following circumstances:

• core dumps of memory required for trouble-shooting <Report Findings Here> 4D-1.14.c Verify documented procedures include Requirements 4D-1.14.1 through 4D-1.14.5 below.

4D-1.14.1 The locations must be predefined and documented.

4D-1.14.1.a Review Host System configuration standards to verify that storage locations of any swap/page files and core dumps are defined.

Host System configuration standards reviewed:

<Report Findings Here> 4D-1.14.1.b Examine Host System configuration settings to verify that the …

Added p. 49

Describe how the backup configuration settings for the Host System and storage locations examined verified that swap/page files and core dumps are not backed up:

<Report Findings Here> 4D-1.14.3.b Examine configurations of storage locations to verify that swap/page files and core dumps cannot be copied off the storage locations.

Describe how the configurations of storage locations examined verified that swap/page files and core dumps cannot be copied off the storage locations:

<Report Findings Here> 4D-1.14.4 Access to, and the use of, any tools used for trouble-shooting or forensics must be controlled and authorized by management.

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 trouble- shooting or forensics, are controlled and authorized by management.

Documented procedures reviewed: <Report Findings Here> 4D-1.14.4.b Observe the process for accessing the tools used for trouble- shooting or forensics, and verify that they are controlled and …

Added p. 50

• 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 reviewed: <Report Findings Here> 4D-1.14.5.b Verify, 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 all user roles associated to persons with access to the Host System.

4D-2.1.a Examine documented policies and procedures to verify that the Host System (s) user passwords must be changed at least every 30 days.

<Report Findings Here> 4D-2.1.b Inspect Host System configuration settings to verify that user …

Added p. 50

4D-2.2.a Examine documented policies and procedures to verify that user passwords must:

Describe how the Host System configuration settings inspected verified that user passwords:

<Report Findings Here> 4D-2.3 Where log-on security tokens (e.g., smart cards) are used to access the Host System, the security tokens must have an associated usage-authentication mechanism, such as a biometric or associated PIN or password/passphrase to enable their usage. The PIN or password/passphrase must be at least ten alphanumeric characters in length, or equivalent.

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 …

Added p. 52

• 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 reviewed:

<Report Findings Here> 4D-2.5.b Inspect 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 inspected 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> 4D-2.6 The segregation of duties must be enforced between roles, through automated or manual processes, to ensure that no one person is able to control end-to-end processes; or be in a position …

Added p. 53

Documented procedures reviewed: <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 Review 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 administrator verified they use their operator-level account when performing non-administrative functions:

<Report Findings Here> 4D-2.7 Changes to a Host System user’s account access privileges must be managed:

Added p. 53

4D-2.7.a Examine documented policies and procedures to verify that changes to a user’s access privileges are managed:

Describe how the observed process to change a user’s access privileges verified that it is managed:

<Report Findings Here> 4D-2.7.c Inspect the Host System configuration settings and, for a sample of user accounts, verify that any changes to their access privileges have been formally documented in the audit log.

Sample of user accounts: <Report Findings Here> Describe how the Host System configuration settings inspected verified that for the sample of user accounts, any changes to their access privileges have been formally documented in the audit log:

<Report Findings Here> 4D-2.8 All physical and logical access privileges must be reviewed at least quarterly to ensure that personnel with access to the decryption environment, the Host System and Host System software require that access for their position and job function.

4D-2.8.a Examine documented policies and procedures to verify that access …

Added p. 55

<Report Findings Here> Describe how the observed tamper-detection mechanisms are implemented and include the generation of an alert upon opening of the Host System case, covers and/or doors:

<Report Findings Here> 4D-2.9.c Review records of alerts and interview personnel to verify an alert is generated upon opening of the Host System, covers and/or doors.

Records of alerts reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 4D-3.1 All non-console access to the Host System must use strong cryptography and security protocols.

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

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

<Report Findings …

Added p. 57

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

Solution provider documentation reviewed (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.

• Meet all applicable PCI DSS requirements.

4D-3.5.2 Review 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:

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

4D-3.6.a Examine documented policies and procedures to verify that non- console access to the Host System must only be provided to authorized users.

<Report Findings Here> 4D-3.6.b Examine a sample of access control records and …

Added p. 58

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 be limited to those with a direct need to access that rack.

4D-4.1 Observe the physically secure room where the Host System is located and interview personnel to verify that all systems therein are designated to decryption operations and transaction processing.

Personnel interviewed: <Report Findings Here> Describe how observation …

Added p. 59

• 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 the room from a badge access system

• Access to the room from a badge access system

• Access to the room from a manual sign-in sheet Documented policies and procedures reviewed:

<Report Findings Here> 4D-4.3.b Examine a sample of logs used to record physical access to the secure room to verify the following:

• Logs are being retained for a minimum of three years.

• Access to the room from a manual sign-in sheet Sample of logs reviewed: <Report Findings Here> 4D-4.3.c Interview personnel responsible for reviewing logs used to record physical access to the secure room, to verify the following:

• Logs …

Added p. 60

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

<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 controls verified that physical access to the secure room is only permitted to pre-designated personnel with defined business needs and duties:

<Report Findings Here> 4D-4.6 The secure room must be monitored via CCTV on a 24-hour basis. This must include, at a minimum, the following areas:

Added p. 60

• 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 Inspect 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 reviewed:

<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. 61

Sample of CCTV recordings reviewed:

Sample of CCTV recordings reviewed:

<Report Findings Here> Describe how observed CCTV camera positioning and the sample of recordings verified that CCTV cameras do not monitor any computer screens, PIN pads, keyboards, or other systems which may expose sensitive data:

<Report Findings Here> 4D-4.8 CCTV recorded images must be securely archived for at least 45 days.

If digital-recording mechanisms are used, they must have sufficient storage capacity and redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.

4D-4.8.a Examine a sample of recordings to verify that at least the most recent 45 days of images are securely archived.

<Report Findings Here> 4D-4.8.b If digital-recording mechanisms are used, examine system configurations to verify that the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.

Describe how system configurations observed verified that the systems have …

Added p. 62

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 monitoring of the secure room.

• The physical intrusion-detection must be connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.

Added p. 62

<Report Findings Here> 4D-4.11.b Observe the physical intrusion-detection system to verify that it:

• Provides continuous (24/7) monitoring of the secure room.

• Provides continuous (24/7) monitoring of the secure room.

• It is connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.

• It is connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.

Describe how the physical intrusion-detection system verified that it:

<Report Findings Here> 4D-4.12 Any windows in the secure room must be locked, protected by alarmed sensors, or otherwise similarly secured.

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 …

Added p. 63

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 (UPS) to prevent outages.

4D-4.14 Inspect uninterruptible power source (UPS) system configurations to verify that all access-control and monitoring systems are powered through the UPS.

Describe how the UPS system configurations observed verified that all access-control and monitoring systems are powered through the UPS:

<Report Findings Here> 4D-4.15 All alarm events must be logged.

4D-4.15.a Examine security policies and procedures to verify they require that all alarm events are logged.

<Report Findings Here> 4D-4.15.b Examine security-system configurations and documented alarm events to verify that all alarm events are logged.

Describe how security-system configurations and documented alarm events verified that all alarm events are logged:

<Report Findings Here> 4D-4.16 Documented alarm events must be signed off …

Added p. 64

Describe how security system configurations observed verified that an alarm event is generated upon use of any emergency entry or exit mechanism:

<Report Findings Here> 4D-4.18 Authorized personnel must respond to all physical intrusion alarms within 30 minutes.

4D-4.18.a Examine documented policies and procedures to verify they define that all alarm events are responded to by authorized personnel within 30 minutes.

<Report Findings Here> 4D-4.18.b Examine documented alarm events and interview personnel to verify alarm events were responded by authorized personnel within 30 minutes.

Documented alarm events reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 4D-4.19 A process for synchronizing the time and date stamps of the access-control, intrusion-detection and monitoring (camera) systems must be implemented.

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 reviewed: …

Added p. 65

Records of synchronization examined:

<Report Findings Here> 4D-4.20 The entrance to the secure room must include a mechanism to ensure the door is not left open.

• 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.

• 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.

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 …

Added p. 66

• Providing reports annually and upon significant changes

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

<Report Findings Here> 4E-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:

• 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>

Added p. 67

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 Review 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 reviewed:

<Report Findings Here> Responsible component provider personnel interviewed:

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

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:

<Report Findings Here> Requirements 2, 3 …

Added p. 75

• Other types of displaying or recording (e.g., printer memory, printer drum).

Added p. 76

• 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 clear-text keys or components is destroyed or securely deleted immediately after generation and that the method of destruction is consistent with Requirement 24:

• deleted immediately after the transfer to the device that will use the key pair.

<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> 8-1 Keys must be transferred either encrypted, as two or more full-length clear-text components, key shares, or within an SCD.

• Examine …

Added p. 83

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

• Encrypted Documented procedures reviewed:

Added p. 88

<Report Findings Here> 9-4 Mechanisms must exist to ensure that only authorized custodians:

Added p. 89

• 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 tamper 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.

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

• Records reflect the receipt of the shipped bag and association with subsequent individual bags Identify the P2PE Assessor who determined that if components or shares of multiple are being sent simultaneously between the same sending and receiving custodians, the component/shares for a specific custodian or custodian group can be shipped in the same TEA bag provided that:

• The components inside the tamper- evident and authenticable package are in separate opaque …

Added p. 93

Documented procedures reviewed: <Report Findings Here> 11-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for key transmission and conveyance processing.

12-3.a Identify instances where a key-loading device is used to load clear- text keys. Examine documented procedures for loading of clear-text cryptographic keys to verify:

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

• Expected techniques are used.

• Default passwords/authentications codes are reset.

• Any passwords/authentication codes used are a minimum of five characters.

• Any passwords/authentication codes or tokens are maintained separately.

<Report Findings Here> 12-6 Any other SCD loaded with the same key components must combine all entered key components using the identical process.

Documented procedures reviewed: <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 Domain of this document. For example:

- SCDs are inspected to …

Added p. 105

Documented procedures reviewed: <Report Findings Here> 14-1.b Observe key-loading environments and controls to verify the following:

Added p. 108

<Report Findings Here> 15-3 Not used in DMS 15-4 Not used in DMS 15-5 Not used in DMS 16-1 Documented key-loading procedures must exist for all devices (e.g., HSMs and POI devices), and all parties involved in cryptographic key loading must be aware of those procedures.

Added p. 111

Documented procedures reviewed: <Report Findings Here> 18-1.b Verify that implemented procedures include:

Documented procedures reviewed: <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 Verify documented procedures 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.

Documented procedures reviewed: <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.

<Report Findings Here> 18-4 Not used in DMS 18-5 Not used in DMS 18-6 …

Added p. 114

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

Added p. 115

Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <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

Indicate whether POI devices are intended to interface with multiple entities for decryption (yes/no) <Report Findings Here> If “no,” describe how it was verified that POI devices are not intended to interface with multiple entities for decryption.

(Leave 20-2.a to 20-2.c blank) <Report Findings Here> If “yes”, complete 20-2.a to 20-2.c:

Documented procedures reviewed: <Report Findings Here> 20-2.b Interview personnel and observe key-generation processes to verify that unique keys or sets of keys are generated for each acquiring organization.

Personnel interviewed: <Report Findings Here> 20-2.c Observe processes for generation and injection of keys into a single POI device for more than one acquiring organization, to verify:

• The POI …

Added p. 120

<Report Findings Here> 21-2 Wherever key components/shares are used, they must have the following properties:

21-2 Examine documented procedures and interview responsible personnel to determine all instances where key components/shares are used.

Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 21-2.1 Knowledge of any one key component/share does not convey any knowledge of any part of the actual cryptographic key.

21-2.1 Examine processes for creating key components/shares to verify that knowledge of any one key component/share must not convey any knowledge of any part of the actual cryptographic key.

Describe how the processes observed for creating key components verified that knowledge of any one key component does not convey any knowledge of any part of the actual cryptographic key:

Documented procedures reviewed: <Report Findings Here> 21-2.4.b Examine key-component/share access controls and access logs to verify that authorized custodians cannot access sufficient key components or shares to reconstruct a secret or private …

Added p. 125

• Any systems, devices, or processing involving subordinate keys that have been calculated, derived, or otherwise generated, loaded, or protected using the compromised key are included in the key- replacement process.

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:

• Use of that key is halted, and the key is replaced with a new unique key.

<Report Findings Here> 22-1.4 A documented escalation process and notification to organizations that currently share or have previously shared the key(s), including:

Responsible personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 22-1.4.b Verify notifications include the following:

• 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: …

Added p. 130

24-2.2.a Observe key-destruction process and verify that it is witnessed by a third party other than a key custodian.

<Report Findings Here> 25-1.3 Each key-custodian form provides the following:

Added p. 138

• 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.

• 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 require physical protection of devices from the manufacturer’s facility up to the point of key-insertion and deployment, through one or more of the defined methods.

• both in-service and spare or back-up devices

•throughout their life cycle.

Documented procedures reviewed: <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 …

Added p. 142

31-1.1.a Examine documented procedures for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes.

31-1.4 Interview responsible personnel and examine device-return records to verify that affected entities are notified before devices are returned.

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

Added p. 146

• Key-destruction method Documentation reviewed:

Added p. 147

<Report Findings Here> 5H-1.1 The Data Decryption Keys (DDKs) used in software to decrypt account data must have defined usage limits. This can be achieved through the use of either one of the following approaches:

• 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 further transaction processing and must be securely erased from memory of the Host System.

OR

• DDKs are unique per transaction. Each DDK is erased from the host memory upon completion of the decryption process.

• Each …

Added p. 148

• Upon reaching the defined usage threshold, the DDK must not be used for further transaction processing and must be securely erased from memory of the host processing system.

<Report Findings Here> 5H-1.1.b Observe the key-management methods used to manage DDKs on the Host System to verify they meet one, or both of the above options.

Describe how the key-management methods used to manage DDKs on the Host System meet one, or both, of the above options:

<Report Findings Here> 5H-1.2 DDKs must be erased from the Host System volatile memory via a mechanism that ensures the key cannot be recovered or reconstructed.

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 Verify, through the use of forensic tools and/or methods, that the mechanism used to …

Added p. 149

• 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 must never be generated as a variant of the HSM master file key.

• The master key used to generate the DDK must be dedicated to generating DDKs.

5H-1.3.a Examine key-management policies and procedures to verify that the following is required for any DDKs generated from a master key:

• The master key used to generated the DDK must be dedicated to generating DDKs.

<Report Findings Here> 5H-1.3.b Observe key-generation processes for generating DDKs from a master key to verify:

• A one-way derivation process is used.

• A one-way derivation process is used.

• The DDK is never generated as a variant of the HSM master file key.

• The DDK is never generated as a variant of the HSM master file key.

• The master …

Added p. 151

Describe how the key-management processes observed verified 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 other purpose:

<Report Findings Here> 5H-1.5.4 The encryption key must have a defined cryptoperiod based on the volume of keys it transports and industry recommendations/best practices.

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 …

Modified p. 1

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

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

Modified p. 5 → 4

Use of this Reporting Template is mandatory for all P2PE v3.0 ~~Encryption~~ Management Services Component Provider assessments (i.e., for ~~an EMCP, PDCP, or~~ a ~~PMCP~~ assessment).

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

Modified p. 5 → 4

Use of this Reporting Template is mandatory for all P2PE v3.0 Solution (and MMS) assessments, where the Solution Provider is directly responsible for all or part of the ~~Encryption~~ Management Services requirements (i.e., when they have not outsourced the entirety of their ~~encryption~~ management services to PCI-listed ~~Encryption~~ Management ~~Services~~ Component ~~Providers).~~

Use of this Reporting Template is mandatory for all P2PE v3.0 Solution (and MMS) assessments, where the Solution Provider is directly responsible for all or part of the Decryption Management Services requirements (i.e., when they have not outsourced the entirety of their decryption management services to a PCI-listed Decryption Management Component Provider).

Modified p. 5 → 4

A P2PE compliance 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 …

Modified p. 5 → 4

The table ~~below~~ summarizes the P2PE v3.0 P-ROVs and the applicability of each P-ROV relative to the assessment type. ~~The following acronyms are used: SP = Solution Provider; CP = Component Provider.~~

The table on the following page summarizes the P2PE v3.0 P-ROVs and the applicability of each P-ROV relative to the assessment type.

Modified p. 6 → 5

Key Management Services (KMS) Solution (SP) ~~Key Injection~~ Facility (KIF) Key Management CP (KMCP) Key Loading CP (KLCP) Key Management Services relates to the generation, conveyance, management, and loading of cryptographic keys including the management of associated devices.

Key Management Services (KMS) Solution (SP) Key-injection Facility (KIF) Key Management CP (KMCP) Key Loading CP (KLCP) Key Management Services relates to the generation, conveyance, management, and loading of cryptographic keys including the management of associated devices.

Modified p. 7 → 6

P-ROV Summary of Findings This version of the P2PE Reporting Template reflects an on-going effort to simplify assessor summary reporting. All summary findings for “In Place,” “Not in Place,” and “Not Applicable” are found at the beginning of 4. Findings and Observations and are only addressed at that high-level. A summary of all domain findings is also at ~~“2.7~~ Summary of P2PE Compliance Status.” The following table is a representation when considering which selection to make. Remember, assessors must select …

P-ROV Summary of Findings This version of the P2PE Reporting Template reflects an on-going effort to simplify assessor summary reporting. All summary findings for “In Place,” “Not in Place,” and “Not Applicable” are found at the beginning of 4. Findings and Observations and are only addressed at that high-level. A summary of all domain findings is also at “2.5 Summary of P2PE Compliance Status.” The following table is a representation when considering which selection to make. Remember, assessors must select …

Modified p. 7 → 6

(Not Applicable) The requirement does not apply to the P2PE Product.

N/A (Not Applicable) The requirement does not apply to the P2PE Product.

Modified p. 8 → 7

• Document name or interviewee reference At 3.7, ~~”Documentation~~ Reviewed,” and 3.8, “Individuals Interviewed,” there is a space for a reference number and 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 3.7, “Documentation Reviewed,” and 3.8, “Individuals Interviewed,” there is a space for a reference number and 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 → 9

P2PE Company and Lead Assessor contact information Company name: Assessor company credentials: QSA (P2PE) PA-QSA (P2PE) Company Servicing Markets for P2PE: (see https://www.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_assessors) Assessor name: Assessor credentials: QSA (P2PE) PA-QSA (P2PE) Assessor phone number:

P2PE Company and Lead Assessor contact information Company name: Assessor company credentials: QSA (P2PE) PA-QSA (P2PE) Company Servicing Markets for P2PE: (see https://www.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_assessors) Assessor name: Assessor credentials: QSA (P2PE) PA-QSA (P2PE) Assessor phone number: Assessor e-mail address:

Modified p. 10 → 9

Confirm that internal QA was fully performed on the entire P2PE ~~submission,~~ per requirements in relevant program documentation.

Confirm that internal QA was fully performed on the entire P2PE submission per requirements in relevant program documentation.

Modified p. 10 → 9

~~Yes~~ No (if no, this is not in accordance with PCI Program requirements) QA reviewer name: Assessor credentials: ~~(Leave blank if not applicable) QA reviewer phone number:~~

No (if no, this is not in accordance with PCI Program requirements) QA reviewer name: Assessor credentials:

Modified p. 11 → 10

• Disclose all services offered to the assessed entity by the ~~PA-QSA(P2PE)/QSA~~ (P2PE)/QSA company, including but not limited to whether the assessed entity uses any security-related devices or security-related applications that have been developed or manufactured by the QSA, or to which the QSA owns the rights or that the QSA has configured or manages:

• Disclose all services offered to the assessed entity by the PA- QSA(P2PE)/QSA (P2PE)/QSA company, including but not limited to whether the assessed entity uses any security-related devices or security-related applications that have been developed or manufactured by the QSA, or to which the QSA owns the rights or that the QSA has configured or manages:

Removed p. 12

2. Summary Overview 2.2 Listed P2PE Component Providers used to satisfy Encryption Management Services Requirements Is a PDCP or a PMCP being used as part of this assessment? Yes No If “no,” the remainder of this table (2.2) is not required.

Description of how PCI-listed P2PE Component Providers are used:

If a PCI-listed PDCP or PMCP is being used in the Solution, complete Table 2.2.

PCI SSC Ref # P2PE Component Type. Please select only one of the following:

Encryption Management Component Provider (EMCP) POI Deployment Component Provider (PDCP) POI Management Component Provider (PMCP) Notes: Within Section 4, “Findings and Observations,” applicable requirements are identified by the Component Type (EMCP, PDCP, or PMCP).

Modified p. 12 → 11

~~Type of Component (select one per row) P2PE Component Provider Name P2PE Component Name PCI SSC Reference #~~ 2.1 P2PE Assessment Details Is this P-ROV assessment being submitted as part of a Solution assessment? If Yes, please enter Solution Name.

2. Summary Overview 2.1 P2PE Assessment Details Is this P-ROV assessment being submitted as part of a Solution assessment? If Yes, please enter Solution Name.

Modified p. 12 → 11

<Solution Name> If No (this is a Component Provider assessment ~~ONLY),~~ complete Part A. ~~Also complete Table 2.2 if a PCI-listed PDCP or a PMCP is being used.~~

Solution Name <Solution Name> If No, (this is a Component Provider assessment ONLY) please complete Part A.

Removed p. 13

Note: If the Component uses applications that can access clear-text account data that are not PCI-listed P2PE Applications, then the P2PE Application P-ROV must be completed and submitted in addition to this P-ROV for each P2PE Application that is not already listed.

Modified p. 13 → 11

~~Add more rows as needed Application Vendor Name: Application Name: Application Version #:~~ PCI SSC ~~Reference~~ # ~~2.4~~ Other Third-Party Service Provider entities involved in P2PE Solution/Component This could include ~~Encryption~~ Management Services who have opted NOT to list with PCI SSC as a P2PE Component and therefore must be assessed fully for each P2PE Component in which the service is used. This could also include other third-party service providers in use as applicable.

PCI SSC Ref # P2PE Component Type: Decryption Management 2.2 Other Third-Party Service Provider entities involved in P2PE Solution/Component This could include Decryption Management Services who have opted NOT to list with PCI SSC as a P2PE Component and therefore must be assessed fully for each P2PE Component in which the service is used. This could also include other third-party service providers in use as applicable.

Modified p. 13 → 11

“Other details” is to be used as needed. For example, if there is a third-party service provider providing ~~encryption~~ services ~~but~~ it is not a P2PE Component at ~~2.2,~~ use “Other details” to address data. Mark as ~~“n/a”~~ if no other details are needed.

“Other details” is to be used as needed. For example, if there is a third-party service provider providing decryption management services but, it is not a P2PE Component at 2.1, use “Other details” to address data. Mark as “N/A” if no other details are needed.

Removed p. 14

Any additional Applications on POI device (add rows as needed to report all applications) Application Name: Version # CHD Access? (see note below)

Note: AP2PE Application P-ROV must be submitted and accepted by PCI SSC for all applications with access to clear-text account data and will be identified by the PCI SSC Reference # at Table 2.3. Tables 2.3 and 2.5 MUST correspond to the P2PE Applications and PTS POI devices included within the PCI SSC Portal submission for this assessment.

Note: If there is a different response for PTS Listing compared to P2PE Functionality for account-data capture interfaces provided with the POI device, this will need to be addressed (including at applicable Domain 1 testing procedures) to ensure such functionality is specifically disabled.

Removed p. 14

Model Name/ OP ICCR MSR Contactless PTS Listing P2PE PTS Listing P2PE PTS Listing P2PE PTS Listing P2PE Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N

Removed p. 15

Model Name/ Number: Bluetooth Ethernet Serial USB Mobile Communications Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N 2.6 All other Secure Cryptographic Devices (SCDs) List of all other SCD types used as part of the Encryption Management Services This includes SCDs used to generate or load cryptographic keys, encrypt keys, or sign applications to be loaded onto POI devices. Examples include HSMs, key-injection/loading devices (KLDs), and other devices that generate or load keys or sign applications and/or whitelists.

Encryption Management Services Solution Provider (or MMS as a Solution Provider) Yes No N/A Encryption Management Yes No N/A POI Deployment Yes No N/A POI Management Yes No N/A

Modified p. 15 → 12

Manufacturer/ Model Name/ Number: Hardware#(s) Firmware#(s) Location: # of devices per Approved key function(s) & ~~2.7~~ Summary of P2PE Compliance Status P2PE Function Compliant Comments (optional):

Manufacturer/ Model Name/ Number: Hardware#(s) Firmware#(s) Location: # of devices per Approved key function(s) & 2.4 Summary of P2PE Compliance Status P2PE Function Compliant Comments (optional):

Modified p. 16 → 13

• ~~Describe the~~ methods or processes used to identify all elements in scope of the P2PE assessment:

• The methods or processes used to identify all elements in scope of the P2PE component assessment:

Modified p. 16 → 13

• ~~Describe how~~ the P2PE assessor confirmed that the scope of the assessment is accurate and covers all components and facilities for ~~Encryption~~ Management ~~Services:~~

• How the P2PE assessor confirmed that the scope of the assessment is accurate and covers all components and facilities for Decryption Management services:

Modified p. 16 → 14

• Location of systems performing ~~key~~ management functions <Insert ~~Encryption~~ Management Services high level diagram(s)>

• Location of systems performing decryption management functions <Insert Decryption Management Services high level diagram(s)>

Removed p. 17

• Key Distribution / Loading / Injection onto POI devices

Removed p. 20

Describe the lab environment used for this assessment:

Removed p. 21

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, such as if it is for a different POI device types, for different functions, etc.

P2PE Application Implementation Guide(s) (IG):

Reference # (optional use) Document Name (Title of the IG) Version Number of Document date (latest version date) Which P2PE Application is addressed? (Must align with Section 2.3) All other documentation reviewed for this P2PE Assessment:

Modified p. 21 → 19

Reference # (optional use) Document Name (including version, if applicable) Document date (latest version date) Document Purpose

Reference # (optional use) Document Name (including version, if applicable) Document date (latest version date) Document Purpose 3.8 Individuals Interviewed List of all personnel interviewed for this Component assessment:

Removed p. 22

Reference # (optional use) Interviewee’s Name Company Job Title 3.7 Device Samples for P2PE Assessment Complete for all sampled devices in the P2PE assessment, including for every POI device type at Section 2.5 above and every other SCD type at Section 2.6 above.

Modified p. 22 → 20

Note: Use of the “Sample Reference #” is optional, but if not used here, all of the sample’s serial numbers or other identifiers in the third column will need to be included in the reporting ~~findings Sample Ref #:~~

Note: Use of the “Sample Reference #” is optional, but if not used here, all of the sample’s serial numbers or other identifiers in the third column will need to be included in the reporting findings.

Modified p. 22 → 20

(optional) Sample Size Serial Numbers of Tested Devices/Other Identifiers Sampling Rationale

Sample Ref #: (optional) Sample Size Serial Numbers of Tested Devices/Other Identifiers Sampling Rationale

Removed p. 23

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) EMCP PDCP PMCP SP Requirements In Place N/A Not in Place Applies to: 1A Account data must be encrypted in equipment that is resistant to physical and logical compromise.

   1A-1 PCI-approved POI devices with SRED are used for transaction acceptance.

   1A-2 Applications on POI devices with access to clear-text account data are assessed per P2PE Application P-ROV before being deployed into a P2PE solution.

1B Logically secure POI devices.

   1B-1 Solution/component provider ensures that logical access to POI devices deployed at merchant encryption environment(s) is restricted to authorized personnel.

   1B-2 Solution/component provider secures any remote access to POI devices deployed at merchant encryption environments.

   1B-3 The …

Modified p. 23 → 21

4. Findings and Observations ~~Encryption~~ Management Services

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

4. Findings and Observations Decryption Management Services

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

Removed p. 24

1C Use P2PE applications that protect PAN and SAD.

   1C-1 Applications are implemented securely, including when using shared resources and when updating applications and application functionality.

    1C-2 All applications/software without a business need do not have access to account data.

   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     1-3     1-4 Not used in EMS 1-5

Modified p. 24 → 21

1D Implement ~~secure application-management~~ processes.

4D Implement secure, hybrid decryption processes.

Modified p. 24 → 21

~~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. 24 → 25

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

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

Removed p. 25

Keys are conveyed or transmitted in a secure manner     8-1     8-2     8-3

Modified p. 25 → 22

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. 34

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

• SRED listed as a function provided For each POI device type used in the solution, examine the POI device and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing:

<Report Findings Here> 1A-1.1.1 The POI device’s SRED capabilities must be enabled and active.

1A-1.1.1.a Examine documented procedures and interview personnel to verify that procedures are defined to ensure that SRED capabilities are enabled and active on all POI devices prior to devices being deployed to merchant encryption environments.

Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 1A-1.1.1.b For all POI …

Modified p. 34 → 27

• ~~Firmware~~ version number

• Device firmware version number

Modified p. 34 → 27

• ~~Firmware~~ version number

• Device firmware version number

Removed p. 35

1A-1.2.a For all POI device types intended for use in the P2PE solution, identify and document all account-data capture interfaces.

Refer to Section 2.5 “PTS Devices Supported” in the Summary Overview for this documentation. No further reporting required here.

1A-1.2.b For each POI device type used in the solution, examine the device configuration to verify that it is configured by default to use only SRED-validated account-data capture mechanisms for accepting and processing P2PE transactions.

For each POI device type used in the solution, examine the device configuration to verify that it is configured by default to use only SRED-validated account-data capture mechanisms for accepting and processing P2PE transactions.

<Report Findings Here> 1A-1.2.1 All account data capture mechanisms on the POI device must be SRED-validated, or must be disabled or otherwise prevented from being used for P2PE transactions such that they cannot be enabled by the merchant.

1A-1.2.1.a Examine POI configuration and deployment procedures to verify …

Removed p. 36

• All non-validated capture mechanisms are either disabled or configured to prevent their use for P2PE transactions prior to devices being deployed to merchant encryption environments.

• Disabled capture mechanisms cannot be enabled by the merchant, and/or the configurations that prevent capture mechanisms from being used for P2PE transactions cannot be enabled by the merchant.

Describe the testing methods used to verify that for all POI device types, all non- validated capture mechanisms are either disabled or configured to prevent their use for P2PE transactions, prior to devices being deployed to merchant encryption environments:

<Report Findings Here> Describe the testing methods used to verify that for all POI device types, disabled capture mechanisms cannot be enabled by the merchant, and/or the configurations that prevent capture mechanisms from being used for P2PE transactions cannot be enabled by the merchant.

<Report Findings Here> 1A-1.3 If the POI device implements open protocols as part of the solution, …

Removed p. 37

Identify the sample of transactions <Report Findings Here> Describe the forensic tools and/or other data tracing methods used to inspect the sample of transactions:

<Report Findings Here> 1A-2.1 All applications on POI devices with access to clear-text account data must be assessed according to Domain 2. The assessment must match the application in the following characteristics:

• Version number 1A-2.1.a For applications on the PCI SSC list of Validated P2PE Applications, review the list and compare to applications used in the solution to verify that the applications match the P2PE application listing in the following characteristics:

• Version number Refer to Section 2.3 “Listed P2PE Applications used in the P2PE Solution” in the Summary Overview for this documentation. No further reporting required here.

1A-2.1.b For applications not on the PCI SSC list of Validated P2PE Applications, review the application P-ROV(s) and verify that the applications used in the solution match the application P-ROV in …

Removed p. 37

• Explicitly included in that application’s listing 1A-2.2.a. For applications on the PCI SSC list of Validated P2PE Applications, review the list and verify all POI device types the application is used on are:

• Explicitly included in that application’s listing Refer to Section 2.3 “Listed P2PE Applications used in the P2PE Solution” and Section 2.5 “PTS Devices Supported” in the Summary Overview for this documentation. No further reporting required here.

Removed p. 38

• Explicitly included in that P-ROV as assessed for that application.

Refer to Section 2.5 “PTS Devices Supported” in the Summary Overview for confirmation per 1A-1.1 of PTS-approval (if this testing procedure is applicable).

Identify application P-ROV(s) reviewed:

<Report Findings Here> 1B-1.1 Solution/component provider must ensure merchant logical access to POI devices, if needed, is restricted as follows:

Removed p. 38

• Does not use any POI vendor default device passwords 1B-1.1.a Examine documented POI device configuration procedures and documented account privilege assignment rules to verify that merchant logical access to POI devices is restricted as follows:

• Cannot enable disabled device interfaces or disabled data- capture mechanisms

• Does not use the POI vendor’s default passwords Documented procedures reviewed: <Report Findings Here> Describe how documented POI device configuration procedures and documented account privilege assignment rules verified that merchant logical access to POI devices is restricted as follows:

• Cannot view or access SAD.

• Does not use the POI vendor’s default passwords <Report Findings Here>

• Cannot enable disabled device interfaces or disabled data- capture mechanisms

Removed p. 39

• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear text PAN and/or SAD Only view transaction-related data

• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear text PAN and/or SAD Only view transaction-related data

• Does not use the POI vendor’s default passwords Identify the sample of POI devices used:

<Report Findings Here> Describe how logon to the device using an authorized test merchant account verified that merchant-account logical access meets the following:

• Does not use the POI vendor’s default passwords <Report Findings Here> 1B-1.1.1 Where there is a legal or regulatory obligation in a region for merchants to print full PAN on merchant receipts, it is allowable for the merchant to have access to full PAN for this purpose, but …

Removed p. 40

1B-1.2.a Examine documented authorizations to verify:

All personnel with access to devices are documented in a formal list.

• All personnel with access to devices are authorized by management.

• The list of authorized personnel is reviewed at least annually.

Documented authorizations reviewed: <Report Findings Here> 1B-1.2.b For a sample of all POI device types, examine account- access configurations to verify that only personnel documented and authorized in the formal list have access to POI devices.

Identify the sample of POI devices used:

<Report Findings Here> Describe how account-access configurations for a sample of all POI device types verified that only personnel documented and authorized in the formal list have access to POI devices:

<Report Findings Here> 1B-1.2.1 Solution provider personnel with logical access to POI devices deployed in merchant encryption environments must be granted based on least privilege and need to know.

1B-1.2.1a Examine documented access-control policies and procedures to verify that solution provider personnel with logical …

Removed p. 41

<Report Findings Here> Identify the sample of personnel used: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe how configured accounts and permissions for the sample of all POI devices and personnel verified that the level of logical access granted is according to least privilege and need to know:

<Report Findings Here> 1B-2.1 Solution provider’s authorized personnel must use multi-factor or cryptographic authentication for all remote access to merchant POI devices.

Note: This includes personnel authenticating to a terminal management system (TMS) or other similar systems to gain remote access to POI devices 1B-2.1.a Examine documented procedures to verify that either multi-factor or cryptographic authentication must be used for all remote access to POI devices.

Documented procedures reviewed: <Report Findings Here> 1B-2.1.b Observe remote-access mechanisms and controls to verify that either multi-factor or cryptographic authentication is configured for all remote access to POI devices.

Describe how remote-access mechanisms and controls verified that either …

Removed p. 42

Describe how sampled device configurations for all devices used in the solution verified that remote access is permitted only from the solution provider’s authorized systems:

<Report Findings Here> 1B-2.3 POI devices must be configured such that merchants do not have remote access to the merchant POI devices.

1B-2.3.a Examine documented POI-configuration procedures and interview personnel to verify that devices must be configured to ensure merchants do not have remote access to the POI devices.

Documented POI-configuration procedures reviewed:

<Report Findings Here> Personnel interviewed: <Report Findings Here> 1B-2.3.b For all devices used in the solution, observe a sample of device configurations to verify that merchants do not have remote access to the POI devices.

Describe how sampled device configurations for all devices used in the solution verified that merchants do not have remote access to the POI devices:

<Report Findings Here> 1B-2.4 Solution provider must implement secure identification and authentication procedures for remote access to POI devices …

Removed p. 43

1B-2.5.1.a Examine POI device configurations and authentication mechanisms to verify that all logical access to POI devices by solution-provider personnel can be traced to an individual user.

Describe how the POI device configurations and authentication mechanisms examined, verified that all logical access to POI devices by solution-provider personnel can be traced to an individual user.

<Report Findings Here> 1B-2.5.1.b Observe a sample of authorized logical accesses and examine access records/logs to verify that all logical access is traced to an individual user.

Describe how sampled authorized logical accesses and access records/logs verified that all logical access is traced to an individual user.

<Report Findings Here> 1B-2.5.2 Maintaining audit logs of all logical access to POI devices by solution-provider personnel and retaining access logs for at least one year.

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

Removed p. 44

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

• Model name and number

• Firmware version number(s)

• P2PE Payment Applications

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

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

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

• The inventory includes all POI device system builds.

• The inventory includes all POI device system builds.

• The inventory of POI device system builds is up-to-date.

• The inventory of POI device system builds is up-to-date.

Describe how the documented inventory of devices and inventory of system builds verified that:

<Report Findings Here> 1B-3.3 Critical software security updates must be deployed to POI devices in the field within 30 days of receipt from device vendors or …

Modified p. 44 → 29

Documented procedures reviewed: <Report Findings Here>

• Use of HSM commands Documented procedures reviewed: <Report Findings Here>

Removed p. 45

Responsible solution provider personnel interviewed:

<Report Findings Here> Describe how the security update deployment records and device logs verified that critical security updates are deployed to devices and applications in the field within 30 days of receipt from device and application vendors.

<Report Findings Here> 1B-3.4 The integrity of patch and update code must be maintained during delivery and deployment, as defined by the vendor•e.g., in the POI device vendor's security guidance or in the P2PE application’s Implementation Guide..

1B-3.4.a Examine documented procedures for device updates to verify they follow guidance from the device or application vendor to maintain the integrity of all patch and update code during delivery and deployment.

Documented procedures reviewed: <Report Findings Here> 1B-3.4.b Observe processes for delivering updates and interview responsible personnel to verify that the integrity of patch and update code is maintained during delivery and deployment, and according to guidance from the device or application vendor.

Modified p. 45 → 29

Responsible personnel interviewed: <Report Findings Here> ~~Describe how the processes for delivering updates verified that updates are delivered in a secure manner with a known chain-of-trust and following guidance from the device or application vendor:~~

Responsible personnel interviewed: <Report Findings Here> Solution-provider documentation reviewed:

Removed p. 46

1B-4.1.a Examine the Solution/Component provider’s procedures for troubleshooting customer problems and verify the procedures include:

• PAN and/or SAD is never output to merchant environments

• Collection of PAN and/or SAD only when needed to solve a specific problem

• Storage of such data in a specific, known location with limited access

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

• Encryption of PAN and/or SAD while stored

• Secure deletion of such data immediately after use Documented Solution/Component provider’s procedures for troubleshooting customer problems reviewed:

<Report Findings Here> 1B-4.1.b For a sample of recent troubleshooting requests, observe data collection and storage locations, and interview responsible personnel to verify the procedures identified at 1B- 4.1.a were followed.

Identify the sample of recent troubleshooting requests:

<Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe how the data collection and storage locations for the sample of recent troubleshooting requests verified that procedures identified …

Removed p. 47

• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) Describe how the device and/or system configurations observed 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 POI devices, as follows, and examine log files to verify that all such activities result in a correlating log file:

• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) Describe how observation of authorized personnel performing authorized changes on POI devices, as follows, and examination of log files verified that all such activities result in a correlating log file:

• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) <Report Findings Here> 1B-5.1.c Examine documented procedures and sample …

Modified p. 47 → 31

Documented procedures reviewed:

Documented policies and procedures reviewed:

Removed p. 48

• Implementing whitelisting functionality in accordance with the device vendor's security guidance or the application’s Implementation Guide

• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 1C-1.1.a Review documented policies and procedures and interview personnel to verify that processes for implementing any whitelisting functionality include:

• Following the device vendor's security guidance or the application’s Implementation Guide

Modified p. 48 → 33

• Cryptographic signing (or similar) prior to installation ~~on the POI device~~ by authorized personnel using dual control

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

Modified p. 48 → 33

• Cryptographic authentication by the ~~POI device’s firmware~~

• Cryptographic authentication by the HSM

Modified p. 48 → 33

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

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

Modified p. 48 → 34

• Cryptographic signing (or similar) prior to installation ~~on the POI device~~ by authorized personnel using dual ~~control~~

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

Modified p. 48 → 34

• Cryptographic authentication ~~of whitelisting functionality~~ by the ~~POI device’s firmware~~

• Cryptographic authentication by the HSM

Modified p. 48 → 34

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

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

Modified p. 48 → 34

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

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

Modified p. 48 → 34

• ~~The identity of the authorized person 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 Personnel interviewed: <Report Findings Here> Documented procedures reviewed:~~

• Who approved the new installation or updated functionality prior to release - Confirmation that it was reviewed prior to release to only output non-

Removed p. 49

1C-1.1.1.a Observe application and device configurations and interview personnel to verify that whitelisting functionality only allows for the output of non-PCI payment brand accounts/cards, by following guidance in either the device vendor's security guidance or the application’s Implementation Guide.

Describe how the application and device configurations observed verified that whitelisting functionality only allows for the output of non-PCI payment brand accounts/cards.

<Report Findings Here> Personnel interviewed <Report Findings Here> 1C-1.1.1.b For all device types with whitelisting functionality, perform test transactions to verify output of clear text account data is only enabled for non-PCI payment brand account/card data.

Describe how the test transactions performed, verified that any output of clear text account data is only enabled for non-PCI payment brand account/card data.

<Report Findings Here> 1C-1.1.2 Any new installations of, or updates, to whitelisting functionality must be:

• Cryptographically authenticated by the POI device’s firmware in accordance with the device vendor's security guidance or the application’s …

Modified p. 49 → 35

• Cryptographically signed (or similar) prior to installation ~~on the POI device~~ only by authorized personnel using dual ~~control.~~

• Cryptographically signed (or similar) prior to installation only by authorized personnel using dual control

Modified p. 49 → 35

~~1C-1.1.2.a~~ Observe the process for new installations ~~of,~~ or updates ~~to,~~ whitelisting functionality and interview personnel to verify ~~they~~ are performed as follows:

• 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:

Modified p. 49 → 35

• Cryptographically signed (or similar) prior to installation ~~on the POI device~~ only by authorized personnel using dual control

• Cryptographically signed (or similar) prior to installation only by authorized personnel using dual control

Removed p. 50

• Description and justification for the functionality.

• The identity of the person who approved the new installation or update prior to release

<Report Findings Here> 1C-2.1 Processes must be documented and implemented to ensure that, prior to new installations or updates, any non-payment software:

• Does not have any logical interfaces (e.g., application programming interfaces (APIs)) that allow for the storing, processing, or transmitting of clear text account data

• Is cryptographically authenticated by the POI device’s firmware

• Requires an SCD with dual control for the application-signing process PDCP PMCP EMCP 1C-2.1 Review the solution provider’s documented processes and interview responsible personnel to confirm the processes include:

• Review of the non-payment software vendor’s documentation to determine all logical interfaces used by the non-payment software do not allow for the storing, processing, or transmitting of clear text account data

• Documenting how the Solution/Component provider confirmed that the non-payment software has no logical interfaces that …

Modified p. 50 → 35

• ~~The identity of the person who~~ approved the new installation or update prior to release

• Who approved the new installation or update prior to release

Modified p. 50 → 35

• Confirmation that it was reviewed prior to release to only output non-PCI payment account/card ~~data 1C-1.1.3.a Review records of both new installations and updated whitelisting functionality, and confirm they include the following:~~

• Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.

Modified p. 50 → 35

• ~~Coverage for both~~ new installations and updates to ~~such~~ functionality

• Both new installations and updates to whitelisting functionality are documented.

Modified p. 50 → 35

• ~~Confirmation~~ that it was reviewed prior to release to only output non-PCI payment account/card ~~data Identify sampled records of updated whitelisting functionality:~~

• The documentation includes confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.

Removed p. 51

PDCP PMCP EMCP 1C-2.1.1 For each POI device type and each non-payment software intended for that POI device type that does not have a business need to access clear text account data, review the non- payment software vendor’s documentation to verify that the non-payment software has no logical interfaces that allow for storing, processing, or transmitting clear text account data.

<Report Findings Here> 1C-2.1.2 The non-payment software is authenticated within the POI device using an approved security mechanism of the POI device.

PDCP PMCP EMCP 1C-2.1.2 Interview Solution/Component-provider personnel and observe the process for new installations or updates of non- payment software to verify that it is authenticated to the POI device using an approved security mechanism of the POI device.

Describe how the process for new application installations or application updates verified that applications with no need to access clear-text account data are authenticated to the device using an approved security mechanism:

<Report …

Modified p. 51 → 41

~~Solution/Component provider’s~~ documentation reviewed:

Solution provider documentation reviewed:

Modified p. 51 → 44

Personnel interviewed: <Report Findings Here> Describe how ~~the process for new application installations or application updates~~ verified that ~~application signing~~ is ~~performed under dual control:~~

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:

Removed p. 52

• Following vendor guidance in the application’s Implementation Guide.

• Documented reason and impact for all changes.

• Functionality testing of all changes on the intended device(s).

• Documented back-out procedures for application installations/updates.

• changed POI device to a PCI-listed P2PE Component requires the Component Provider to undergo an assessment per PCI’s “Delta-Change” process. See the P2PE Program Guide for more information.

Aligns with 2C-2.1 1D-1.1.a Review the Solution/Component provider’s documented processes for implementing changes to applications, and interview Solution/Component-provider personnel, and confirm the following processes are in place:

• Guidance in the Implementation Guide is followed.

• All changes to applications include documented approval by appropriate authorized Solution/Component-provider personnel.

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

• Functionality testing of all changes on the intended devices is performed.

• Documentation includes back-out procedures for application installations/updates.

• Documentation includes back-out procedures for application installations/updates.

<Report Findings Here> Identify the sample of records …

Modified p. 52 → 35

• The documentation includes ~~reason~~ and ~~impact of the change.~~

• The documentation includes description and justification.

Modified p. 52 → 36

• ~~changed application or a~~

• Changes to the applications

Modified p. 52 → 44

~~Solution/Component~~ provider ~~personnel interviewed:~~

Vendor/solution provider documentation reviewed:

Modified p. 52 → 50

<Report Findings Here> ~~1D-1.1.b Review records of changes to applications and confirm~~ the following:

<Report Findings Here> 4D-2.2 User passwords must meet the following:

Modified p. 52 → 55

Identify the ~~sample of records of changes to applications:~~

Identify the tamper-detection mechanisms observed:

Modified p. 52 → 60

• Documented ~~approval for all changes by appropriate personnel.~~

Documented list of designated personnel:

Removed p. 53

1D-1.2.a Review the Solution/Component provider’s documentation and confirm their documented processes include using the guidance in the application’s Implementation Guide for any application installations and updates.

<Report Findings Here> 1D-1.2.1 All applications must be cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.

1D-1.2.1.a Confirm the following through interviews with responsible Solution/Component provider personnel and by observing an installation/update:

• Cryptographic signing processes for applications are followed as specified in the Implementation Guide.

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

• All new installations and updates to applications are signed prior to installation on the device.

• Cryptographic signing for new installations and updates to applications is done under dual control..

Responsible Personnel interviewed: <Report Findings Here> Describe how the installation and update processes observed verified that new application installations and updates are cryptographically authenticated by the POI …

Modified p. 53 → 47

~~Solution/Component provider’s~~ documentation ~~reviewed:~~

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

Modified p. 53 → 49

Describe how ~~configuration processes observed~~ verified that ~~applications~~ are ~~integrated with any shared resources~~ in accordance with the ~~Implementation Guide:~~

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

Removed p. 54

Solution/Component provider personnel interviewed:

Solution/Component provider personnel interviewed:

<Report Findings Here> 1D-1.4.b Interview Solution/Component-provider personnel to confirm that they follow key-management security guidance in accordance with the Implementation Guide.

<Report Findings Here> 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:

• 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.

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

Note: This section (1E-1) is ONLY applicable for P2PE component providers undergoing …

Modified p. 54 → 35

<Report Findings Here> ~~Current Application Vendor Implementation Guide(s)~~ reviewed:

<Report Findings Here> Records of updated whitelisting functionality reviewed:

Modified p. 54 → 41

<Report Findings Here> ~~Current Application Vendor Implementation Guide(s)~~ reviewed:

Responsible personnel interviewed: <Report Findings Here> Solution provider documentation reviewed:

Removed p. 55

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

<Report Findings Here> Reports reviewed for this testing procedure:

<Report Findings Here> PMCP PDCP EMCP 1E-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:

• Types/models of POI devices

• Number of devices deployed and changed since last report

• Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated Reports reviewed 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. 55

• Addition and/or removal of POI device types

Removed p. 55

• Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change

• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software Note that adding, changing, or removing 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 P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution.

Modified p. 55 → 66

• Types/models of ~~POI devices~~

• Types/models of HSMs

Modified p. 55 → 66

• Types/models of ~~POI devices~~

• Types/models of HSMs

Modified p. 55 → 66

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

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

Modified p. 55 → 66

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

Modified p. 55 → 66

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

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

Removed p. 56

• Addition and/or removal of POI device types

• Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change

• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software Documented component provider’s procedures reviewed:

• Adding, changing, and/or removing P2PE non-payment software (without access to clear-text account data), including description of change

• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software Reports reviewed for this testing procedure:

Modified p. 56 → 67

<Report Findings Here> ~~PMCP PDCP EMCP 1E-1.2.b~~ Observe 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. 56 → 67

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

• Addition and/or removal of HSM types.

Removed p. 57

Algorithm

• e.g., TDEA, AES, RSA Cryptographic Mode(s) of Operation (as applicable) Full Key Length (bits) Purpose/function of the key (including types of devices using key):

Modified p. 57 → 67

~~Encryption Management Services - Reporting Applies to Requirements and Testing Procedures Reporting Instructions and Assessor’s~~ Findings 1-1 Not used in P2PE 1-2 Not used in ~~EMS~~ 1-3 All hardware security modules (HSMs) must be either:

• Additions and/or removal of HSM types Identify reports reviewed: <Report Findings Here> 1-1 Not used in P2PE 1-2 Not used in DMS 1-3 All hardware security modules (HSMs) must be either:

Modified p. 57 → 67

• ~~FIPS140-2~~ or 140-3 Level 3 or higher certified, or

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

Modified p. 58 → 68

• Listed on the PCI SSC website, with a valid SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” Refer to https://www.pcisecuritystandards.org.

Listed on the PCI SSC website, with a valid SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” Refer to https://www.pcisecuritystandards.org.

Modified p. 58 → 68

Approval documentation ~~examined:~~

Approval documentation reviewed:

Modified p. 58 → 68

• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment 1-4.a For all PCI-approved HSMs used, examine HSM devices and examine the PCI SSC list of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:

• The PCI PTS HSM or FIPS 140 Approval Number For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment 1-4.a For all PCI-approved HSMs used, examine HSM devices and examine the PCI SSC list of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:

Modified p. 58 → 68

• 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 6A-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.

Removed p. 59

<Report Findings Here> 1-5 Not used in EMS Requirements 2, 3 and 4 are not used in P2PE.

• approved HSM or POI device

Modified p. 59 → 69

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

• Firmware version number 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:

Modified p. 59 → 69

5-1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Generation of cryptographic keys or key components must occur within an SCD. They must be generated by one of the following:

<Report Findings Here> 1-5 Not used in DMS 2, 3, and 4 not used in P2PE 5-1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Generation of cryptographic keys or key components must occur within an SCD. They must be generated by one of the following:

Modified p. 59 → 69

• An approved key-generation function of a PCI

•approved HSM or POI device

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

Modified p. 59 → 69

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

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

Modified p. 59 → 69

• 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 POI configuration and deployment procedures 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.

Removed p. 60

• approved HSM or POI device

Modified p. 60 → 70

• An approved key-generation function of a PCI

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

Modified p. 60 → 70

• 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 reviewed:

Modified p. 60 → 70

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

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

Modified p. 60 → 70

~~Identify~~ the ~~P2PE Assessor who confirms that~~ devices used for ~~key-~~ generation are ~~those~~ noted above, including validation of ~~firmware used.~~

Describe how the reviewed devices used for key generation verified that devices are as noted above, including validation of the firmware:

Modified p. 60 → 70

6-1.1 Any clear-text 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 clear-text output is limited to the individual component(s)/share(s) assigned to that custodian, and not to the entire key.

6-1.1 Any clear-text 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 clear-text output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key.

Modified p. 60 → 70

• Each custodian’s access to clear-text 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>~~

• Each custodian’s access to clear-text output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key.

Removed p. 61

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 clear-text key or all the components for a key:

Key-generation logs reviewed:

Modified p. 61 → 71

~~• Each custodian’s access to clear-text 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 clear-text 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 clear-text 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. 61 → 71

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 clear-text 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 clear-text key or all the components for a key.

Modified p. 61 → 71

<Report Findings Here> 6-1.3 Devices used for the generation of clear-text key components that are output in the clear must either be powered off when not in use or require re-authentication whenever key generation is invoked.

Key-generation logs examined: <Report Findings Here> 6-1.3 Devices used for the generation of clear-text key components that are output in the clear must either be powered off when not in use or require re-authentication whenever key generation is invoked. Logically partitioned devices used concurrently for other processes

•e.g., providing services simultaneously to host systems, such as for transaction processing

•must have key-generation capabilities disabled when not in use and other activities are continuing.

Modified p. 62 → 72

<Report Findings Here> 6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (e.g., unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a clear-text key or key component (e.g., a tapping device) between the key-generation device and the device or medium receiving the key or key component.

<Report Findings Here> 6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (e.g., unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a clear-text key or key component (e.g., a tapping device) between the key-generation device and the device or medium receiving the key or key component. Note: This does not apply to logically partitioned devices located in data centers …

Modified p. 62 → 72

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 clear-text 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 clear-text key or key component (e.g., a tapping device).

Removed p. 63

Documentation examined: <Report Findings Here> 6-1.5.b During the demonstration for 6-1.1.b, observe the physical security controls (e.g., partitions or barriers) used, and validate that they ensure the key-generation process cannot be observed or accessed by unauthorized personnel directory or via camera monitoring (including those on cellular devices).

Note: See Requirement 5 and Requirement 13.

Modified p. 63 → 73

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. 63 → 73

6-2.a Examine documented procedures to verify that multi-purpose computing systems are not permitted for key generation where any ~~clear-text~~ secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.

Note: See Requirement 5 and Requirement 13 6-2.a Examine documented procedures to verify that multi-purpose computing systems are not permitted for key generation where any clear- text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.

Modified p. 63 → 73

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

Documented procedures reviewed:

Removed p. 64

<Report Findings Here> 6-2.c Where single-purpose computers with an installed SCD or a modified PED are used, verify that either:

• Where clear keying material passes through memory of the PC, the PC requirements of Requirement 13 are met.

Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) or Where clear keying material passes through unprotected memory of the PC, the PC requirements of Requirement 13 are met.

Modified p. 64 → 73

<Report Findings Here> Describe how the generation process observed for each type of key verified that ~~multi-purpose~~ computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory:

<Report Findings Here> Describe how the generation process observed for each type of key verified that multi- purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory:

Modified p. 64 → 74

• Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) or

• Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) or where clear keying material passes through memory of the PC, the PC requirements of Requirement 13 are met.

Modified p. 64 → 74

Describe how the single-purpose computers with an installed SCD verified that either:

Describe how the single-purpose computers with an installed SCD verified that either: Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) or where clear keying material passes through memory of the PC, the PC requirements of Requirement 13 are met.

Modified p. 64 → 74

Only approved key custodians can observe the key component.

• Only approved key custodians can observe the key component.

Modified p. 64 → 74

Tampering can be visually detected.

• Tampering can be visually detected.

Modified p. 65 → 74

• Only approved key custodians can observe ~~their~~ the key component.

• Only approved key custodians can observe the key component.

Modified p. 65 → 74

• Printers used for this purpose are not used for other purposes, are managed under dual control in a secure room that meets the requirements of 32-9 and are not networked.

Printers used for this purpose are not used for other purposes, are managed under dual control in a secure room that meets the requirements of 32-9 and are not networked.

Modified p. 65 → 74

Documented procedures for printed key components ~~examined:~~

Documented procedures for printed key components reviewed:

Modified p. 65 → 74

<Report Findings Here> 6-3.b Observe processes for printing key components to verify ~~that :~~

<Report Findings Here> 6-3.b Observe processes for printing key components to verify that:

Modified p. 65 → 74

• Key components are printed within blind mailers or sealed in ~~tamper-evident~~ and authenticable packaging (that is able to be authenticated) immediately after printing, such that no one but the authorized custodian ever has physical access to the output;

• Key components are printed within blind mailers or sealed in tamper- evident and authenticable packaging (that is able to be authenticated) immediately after printing, such that no one but the authorized custodian ever has physical access to the output;

Removed p. 66

Documented procedures examined: <Report Findings Here> 6-4.b Observe the destruction process of each identified type of key residue and verify the following:

• If a key is generated in a separate device before being exported into the end-use device, confirm that Describe how the destruction process of the identified key residue observed verified that any residue that may contain clear-text keys or components is destroyed or securely deleted immediately after generation:

<Report Findings Here> Identify the P2PE Assessor who confirms that the method of destruction is consistent with Requirement 24.

Modified p. 66 → 75

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. 66 → 75

~~• Other types of displaying or recording (e.g., printer memory, printer drum)~~ 6-4.a Examine documented procedures to identify all locations where key residue may exist. Verify procedures ensure the following:

6-4.a Examine documented procedures to identify all locations where key residue may exist. Verify procedures ensure the following:

Modified p. 67 → 76

If a key is generated in a separate device before being exported into the end-use device, describe how the destruction process of the identified key residue observed verified that the key and all related critical security parameters are deleted from the generation and/or injection device immediately after the transfer to the device that will use the key:

<Report Findings Here> If a key is generated in a separate device before being exported into the end-use device, describe how the destruction process of the identified key residue observed verified that the key and all related critical security parameters are deleted from the generation and/or injection device immediately after the transfer to the device that will use the key:

Modified p. 67 → 76

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

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. 67 → 76

Documented procedures for asymmetric-key generation ~~examined:~~

Documented procedures for asymmetric-key generation reviewed:

Modified p. 67 → 76

• If generated externally, the key pair and all related critical security parameters are ~~deleted 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 are

Modified p. 68 → 77

• Writing key or component values in procedure manual Documented policy and procedures ~~examined:~~

• Writing key or component values in procedure manual Documented policy and procedures reviewed:

Modified p. 69 → 78

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

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

Modified p. 69 → 78

~~Responsible personnel interviewed: <Report Findings Here> PDCP~~ Describe how the observation of actual or demonstrative key-generation ceremonies verified that the documented procedures are demonstrably in use:

Describe how the observation of actual or demonstrative key-generation ceremonies verified that the documented procedures are demonstrably in use:

Removed p. 70

<Report Findings Here> 7-2 Logs must exist for the generation of higher-level keys, such as KEKs exchanged with other organizations, and MFKs and BDKs. The minimum log contents include date and time, object name/identifier, purpose, name and signature of individual(s) involved, and tamper-evident package number(s) and serial number(s) of device(s) involved.

Modified p. 70 → 79

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. 70 → 79

<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. 71 → 79

Where key components are transmitted in ~~clear text~~ using pre-numbered, tamper-evident, authenticable mailers:

• Where key components are transmitted in clear-text using pre-numbered, tamper-evident, authenticable mailers:

Modified p. 71 → 79

Components/shares must be conveyed using at least two separate communication channels, such as different courier services. Components/shares sufficient to form the key must not be conveyed using the same communication channel.

- Components/shares must be conveyed using at least two separate communication channels, such as different courier services. Components/shares sufficient to form the key must not be conveyed using the same communication channel. - Details of the serial number of the package are conveyed separately from the package itself. - Documented procedures exist and are followed to require that the serial numbers be verified prior to the usage of the keying material.

Modified p. 71 → 79

Where SCDs are used for conveying components/shares, the mechanisms or data (e.g., PIN) to obtain the key component/share from the SCD must be conveyed using a separate communication from the SCD channel, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.

• Where SCDs are used for conveying components/shares, the mechanisms or data (e.g., PIN) to obtain the key component/share from the SCD must be conveyed using a separate communication from the SCD channel, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.

Modified p. 71 → 79

Where an SCD (i.e., HSM or KLD) is conveyed with pre-loaded secret and/or private keys, the SCD must require dual control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.

• Where an SCD (i.e., HSM or KLD) is conveyed with pre-loaded secret and/or private keys, the SCD must require dual control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.

Modified p. 71 → 79

Identify the P2PE Assessor who determined whether keys are transmitted encrypted, or as ~~clear- text~~ components, or within an SCD:

Identify the P2PE Assessor who determined whether keys are transmitted encrypted, or as clear-text components, or within an SCD:

Modified p. 71 → 80

<Report Findings Here> Responsible personnel interviewed:

Removed p. 72

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

• 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 confirmed.

• The package serial number was transmitted as prescribed.

<Report Findings Here> Describe how the observed method to transport clear-text 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. 72 → 80

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

• The package serial number was transmitted as prescribed

Modified p. 72 → 80

• Each component was sent to/from only the custodian(s) authorized for the ~~component.~~

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

Modified p. 72 → 80

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

Modified p. 73 → 81

• Examine documented procedures to verify that the SCD requires ~~dual-control~~ mechanisms to become operational.

• Examine documented procedures to verify that the SCD requires dual- control mechanisms to become operational.

Modified p. 74 → 81

Note: An m-of-n scheme is a component- or share-allocation scheme where m is the number of shares or components necessary to form the key, and n is the number of the total set of shares or components related to the key. Management of the shares or components must be sufficient to ensure that no one person can gain access to enough of the item to form the key alone E.g., in an m-of-n scheme (which must use a recognized secret-sharing …

Modified p. 74 → 82

Documented ~~device- configuration~~ procedures ~~examined:~~

Documented procedures reviewed:

Modified p. 75 → 83

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

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

Modified p. 75 → 83

• There is a clear understanding that 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~~

• There is a clear understanding that 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. 75 → 83

• 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.

Modified p. 75 → 83

• 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. 75 → 83

• 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.~~

• 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.

Removed p. 76

PDCP Documented procedures examined:

Modified p. 76 → 84

• Examples of acceptable methods include:

Examples of acceptable methods include:

Modified p. 76 → 84

• 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. 76 → 84

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. 76 → 84

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. 77

Identify the P2PE Assessor who attests that self-signed certificates must not be used as the sole method of authentication:

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

Modified p. 77 → 85

~~• Encrypted~~ <Report Findings Here> 8-4.b Validate that procedures dictate that self-signed certificates must not be used as the sole method of authentication.

<Report Findings Here> 8-4.b Validate that procedures dictate that self-signed certificates must not be used as the sole method of authentication.

Modified p. 77 → 85

Responsible personnel interviewed:

<Report Findings Here> Responsible personnel interviewed: <Report Findings Here>

Modified p. 77 → 85

~~<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:

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. 78 → 86

• Under the continuous supervision of a person with authorized access to this ~~component,~~

• Under the continuous supervision of a person with authorized access to this component

Modified p. 78 → 86

• 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. 78 → 86

• 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.~~

• 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. 78 → 86

• ~~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. 78 → 86

• ~~Contained~~ within a physically secure SCD.

• contained within a physically secure SCD.

Modified p. 79 → 87

• The set of ~~components, and~~

• The set of components

Modified p. 79 → 87

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

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

Modified p. 79 → 87

• Any keys encrypted under this (combined) key

• Any keys encrypted under this (combined) key <Report Findings Here>

Modified p. 80 → 88

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

• Any keys encrypted under this (combined) key Records related to escalated transmital events examined:

Modified p. 80 → 88

<Report Findings Here> 9-3 Only an authorized key ~~custodian and~~ designated ~~backup(s) must~~ have physical access to a key component prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.

<Report Findings Here> 9-3 Only an authorized key custodian⎯and designated backup(s)⎯must have physical access to a key component prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.

Modified p. 80 → 88

9-3.a Verify the existence of a 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 Verify the existence of a 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. 80 → 88

~~Documented reviewed:~~ <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. 80 → 88

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. 81

• 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.

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

PDCP Documented procedures reviewed:

Modified p. 81 → 88

• 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. 81 → 89

~~Documented~~ reviewed: <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:

Logs reviewed: <Report Findings Here> Describe how the implemented mechanisms and processes observed verified that only the authorized key custodians can perform the following:

Modified p. 81 → 89

• 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. 82 → 90

Responsible personnel interviewed:

<Report Findings Here> Responsible personnel interviewed:

Removed p. 83

• Records reflect the receipt of the shipped bag and association with subsequent individual bags.

Modified p. 83 → 91

Logs reviewed: <Report Findings Here> 10-1 All key-encryption keys used to encrypt for transmittal or conveyance of other cryptographic keys must be at least as strong as the key being sent, as delineated in Annex C., except as noted below for RSA keys used for key transport.

• Records reflect the receipt of the shipped bag and association with subsequent individual bags <Report Findings Here> 9-6.b Examine logs to verify that procedures are followed. Logs reviewed: <Report Findings Here> 10-1 All key-encryption keys used to encrypt for transmittal or conveyance of other cryptographic keys must be at least as strong as the key being sent, as delineated in Annex C., except as noted below for RSA keys used for key transport.

Modified p. 83 → 91

• RSA keys encrypting keys greater in strength than 80 bits ~~shall~~ must have a bit strength of at least 112 bits.

• RSA keys encrypting keys greater in strength than 80 bits must have a bit strength of at least 112 bits.

Modified p. 84 → 92

<Report Findings Here> 10-1.b Using the network schematic and the summary listing of cryptographic keys and through interview of personnel, identify keys that protect other keys for transmission. Consider keys manually transferred (e.g., cryptograms sent to an 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 Using the network schematic and the summary listing of cryptographic keys and through interview of personnel, identify keys that protect other keys for transmission. Consider keys manually transferred (e.g., cryptograms sent to an ESO) as well as those that are system- generated and transferred (e.g., KEK or TMK encrypting working keys).

Modified p. 84 → 92

<Report Findings Here> 10-1.c Observe key-generation processes for the key types identified above. Verify that all keys used to transmit or convey other cryptographic keys are at least as strong as any key ~~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.c Observe key-generation processes for the key types identified above. Verify that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed, except as noted for RSA keys. To verify this:

Removed p. 85

• 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.

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

System documentation examined:

Modified p. 85 → 92

• 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.~~

- 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 …

Modified p. 85 → 92

<Report Findings Here> ~~11-1 Written~~ procedures ~~must exist and be known to all affected parties.~~

<Report Findings Here> Documented procedures reviewed:

Modified p. 86 → 93

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

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

Modified p. 86 → 93

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

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

Modified p. 86 → 93

<Report Findings Here> 12-1 The loading of secret or private keys, when from the individual key components or shares, must be performed using the principles of dual control and split knowledge.

Documented procedures reviewed: <Report Findings Here> 12-1 The loading of secret or private keys, when from the individual key components or shares, must be performed using the principles of dual control and split knowledge.

Modified p. 86 → 93

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

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

Modified p. 86 → 93

Appropriate personnel interviewed:

Appropriate personnel interviewed: <Report Findings Here>

Removed p. 87

Describe how the review of locations where keys may have been recorded verified there are no key or component values recorded.

Modified p. 87 → 94

<Report Findings Here> 12-2 Procedures must be established that will prohibit any one person from having access to components sufficient to form an encryption key when components are removed from and returned to storage for key loading.

Documents reviewed: <Report Findings Here> 12-2 Procedures must be established that will prohibit any one person from having access to components sufficient to form an encryption key when components are removed from and returned to storage for key loading.

Modified p. 88 → 94

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. 88 → 94

Access logs examined:

Access logs examined: <Report Findings Here>

Modified p. 88 → 95

• Dual control must be implemented using one or more of, but not limited to, the following techniques:

Dual control must be implemented using one or more of, but not limited to, the following techniques:

Modified p. 88 → 95

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. 89 → 95

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

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

Modified p. 89 → 95

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

There is a requirement that if passwords/authentication codes or tokens are used, they are maintained separately.

Modified p. 89 → 96

Describe how the observed processes for loading clear-text cryptographic keys for all types of production SCDs verified that dual control is required to authorized any key- loading sessions, expected techniques are used, any passwords used are a minimum of five characters (default passwords/authentication codes are reset) and any passwords/authentication codes or tokens are maintained separately:

Describe how the observed processes for loading clear-text cryptographic keys for all types of production SCDs verified that

Modified p. 90 → 96

<Report Findings Here> 12-4 Key components for symmetric keys must be combined using a process such that no active bit of the key can be determined without knowledge of the remaining ~~components e.g.,~~ via XOR‘ing of full-length components. ~~The resulting key must only exist within the SCD.~~

<Report Findings Here> 12-4 Key components for symmetric keys must be combined using a process such that no active bit of the key can be determined without knowledge of the remaining components⎯e.g., via XOR‘ing of full-length components.

Modified p. 90 → 96

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. 90 → 97

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. 90 → 97

<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. 90 → 97

~~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 double- or triple-length TDEA for existing 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 double- or triple-length TDEA for existing 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. 90 → 97

<Report Findings Here> Identify the P2PE Assessor who corroborated how the HSM MFK is created:

Vendor documentation reviewed: <Report Findings Here> Identify the P2PE Assessor who corroborated how the HSM MFK is created:

Removed p. 91

<Report Findings Here> 12-7 The initial terminal master key (TMK) or initial DUKPT key must be loaded to the device using either asymmetric key-loading techniques or manual techniques• e.g., the device keypad, IC cards, key-loading device, etc. Subsequent loading of the terminal master key or an initial DUKPT key may use techniques described in this document such as:

Modified p. 91 → 97

~~12-6.a~~ Thorough examination of documented procedures, interviews, and observation, confirm that any devices that are loaded with the same key components use the same mathematical process to derive the final key.

12-6 Thorough examination of documented procedures, interviews, and observation, confirm that any devices that are loaded with the same key components use the same mathematical process to derive the final key.

Modified p. 91 → 97

<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 reviewed: <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:

Modified p. 91 → 98

• Asymmetric ~~techniques~~

• Asymmetric techniques;

Modified p. 91 → 98

• The existing TMK to encrypt the replacement TMK for ~~download~~

• The existing TMK to encrypt the replacement TMK for download;

Modified p. 91 → 98

• Keys must not be reloaded by any methodology in the event of a compromised device and must be withdrawn from use.

Keys must not be reloaded by any methodology in the event of a compromised device and must be withdrawn from use.

Modified p. 91 → 98

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

Documented procedures reviewed: <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.

Modified p. 92 → 98

• A public-key technique for the distribution of symmetric secret keys must:

A public-key technique for the distribution of symmetric secret keys must:

Removed p. 93

<Report Findings Here> Describe how the demonstration verified that:

• SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading.

• An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device.

• There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys.

• The SCD is inspected to ensure it has not been subject to any prior tampering that could lead to the disclosure of clear-text keying material.

Modified p. 93 → 100

• 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 clear-text keying material.

• The SCD is inspected to ensure it has not been subject to any prior tampering, which could lead to the disclosure of clear-text keying material.

Removed p. 94

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

Modified p. 94 → 100

Note: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. If a PED that has been modified to perform these functions has not been validated and approved to the KLD approval class, ~~they~~ must be managed in accordance with Requirement 13-9.

Note: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. If a PED that has been modified to perform these functions has not been validated and approved to the KLD approval class, the PED must be managed in accordance with Requirement 13-9.

Modified p. 94 → 101

~~<Report Findings Here> 13-2.b Observe a demonstration of~~ key loading ~~to verify~~ that only SCDs are used in the loading of clear-text 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 clear-text secret or private keys or their components outside of a secure key- loading facility.

Modified p. 94 → 101

<Report Findings Here> 13-3 The loading of clear-text secret or private key components or shares from an electronic medium

•e.g., smart card, thumb drive, fob, or other device used for data transport

•directly into a cryptographic device (and verification of the correct receipt of the component, if applicable) results in either of the ~~following:~~

<Report Findings Here> 13-3 The loading of clear-text secret or private key components or shares from an electronic medium

•e.g., smart card, thumb drive, fob, or other device used for data transport

•directly into a cryptographic device (and verification of the correct receipt of the component, if applicable) results in either of the following

Removed p. 95

• All traces of the component are erased or otherwise destroyed from the electronic medium.

Logs examined: <Report Findings Here> 13-4 For secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device:

Modified p. 95 → 101

<Report Findings Here> 13-3.b Observe key-loading processes to verify that the injection process results in one of the following:

Documented procedures reviewed: <Report Findings Here> 13-3.b Observe key-loading processes to verify that the injection process results in one of the following:

Modified p. 95 → 101

• 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.

Modified p. 96 → 102

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. 96 → 102

~~13-4.1 Verify~~ 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 reviewed: <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. 96 → 102

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

<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. 96 → 102

~~13-4.2 Verify~~ 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 reviewed: <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:

Removed p. 97

<Report Findings Here> 13-4.3.b Verify that both authorized personnel involved in key- loading activity inspect the key-loading device prior to use to ensure that a key-recording device has not been inserted between the SCDs.

<Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that authorized personnel inspect the key-loading device prior to use to ensure that a key- recording device has not been inserted between the SCDs:

13-4.4 Verify 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. For example, attempt to output the same value more than one time from the device or cause the device to display check values for its contents both before and after injection and compare.

Modified p. 97 → 102

<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 reviewed: <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. 97 → 102

<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 reviewed: <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. 98 → 103

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 clear-text to anyone who is not a designated custodian for that component.

Modified p. 98 → 103

<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).

Documented procedures reviewed: <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. 98 → 103

<Report Findings Here> ~~PDCP~~ 13-5.d Interview key-injection personnel and examine logs for the removal of media/devices from secure storage to verify they ~~Key-injection personnel interviewed:~~

Designated component holder(s) interviewed: <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. 99 → 103

Logs examined: <Report Findings Here> 13-6 If the component is in human-readable form it must be visible only to the designated component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.

Key-injection personnel interviewed: <Report Findings Here> Logs examined: <Report Findings Here> 13-6 If the component is in human-readable form it must be visible only to the designated component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.

Modified p. 99 → 104

<Report Findings Here> 13-7.b Observe key-loading processes and verify that printed/written key component documents are not opened until immediately prior to use.

Documented procedures reviewed: <Report Findings Here> 13-7.b Observe key-loading processes and verify that printed/written key component documents are not opened until immediately prior to use.

Modified p. 99 → 104

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. 100

Note: Where key-loading is performed for POI devices, the secure environment as defined in Requirement 32-9 must additionally be met.

Modified p. 100 → 104

<Report Findings Here> 13-8.b Examine key-component access controls and access logs to verify that any single authorized custodian can and has only had access to their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key.

Documented procedures reviewed: <Report Findings Here> 13-8.b Examine key-component access controls and access logs to verify that any single authorized custodian can and has only had access to their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key.

Modified p. 100 → 104

<Report Findings Here> ~~13-9 Not used in EMS~~ 14-1 Any hardware and passwords/authentication codes used in the key-loading function or for the signing of authenticated applications must be controlled and maintained in a secure environment under dual control. Resources (e.g., passwords/authentication codes and associated hardware) must be managed such that no single individual has the capability to enable key loading of clear-text keys or their components. This is not to imply that individual access authentication mechanisms must be managed under …

<Report Findings Here> 14-1 Any hardware and passwords/authentication codes used in the key-loading function or for the signing of authenticated applications must be controlled and maintained in a secure environment under dual control. Resources (e.g., passwords/authentication codes and associated hardware) must be managed such that no single individual has the capability to enable key loading of clear-text keys or their components. This is not to imply that individual access authentication mechanisms must be managed under dual control.

Modified p. 100 → 105

• Any resources (e.g., passwords/authentication codes and associated hardware) used in the key-loading function or for the signing of authenticated applications must be controlled and managed such that no single individual has the capability to enable key loading of ~~clear-text~~ keys or their components.

• Any resources (e.g., passwords/authentication codes and associated hardware) used in the key-loading function or for the signing of authenticated applications must be controlled and managed such that no single individual has the capability to enable key loading of clear- text keys or their components.

Removed p. 101

The secure room for key injection must include the following:

Note: This does not apply to key components entered into the keypad of a secure cryptographic device, such as a device approved against the PCI PTS POI Security Requirements. It does apply to all other methods of loading of clear-text keying material for POI v3.0 and higher devices.

Modified p. 101 → 105

• 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. 101 → 105

<Report Findings Here> 14-2 All cable attachments over which clear-text keying material traverses must be examined at the beginning of an entity’s key activity operations (system power on/authorization) or ~~application signing~~ operations to ensure they have not been tampered with or compromised.

<Report Findings Here> 14-2 All cable attachments over which clear-text keying material traverses must be examined at the beginning of an entity’s key activity operations (system power on/authorization) or application-signing operations to ensure they have not been tampered with or compromised.

Modified p. 101 → 105

14-2.a Examine documented procedures to ensure they require that cable attachments are examined at the beginning of an entity’s key-activity operations (system power on/authorization) or ~~application signing~~ operations.

14-2.a Examine documented procedures to ensure they require that cable attachments are examined at the beginning of an entity’s key-activity operations (system power on/authorization) or application-signing operations.

Modified p. 102 → 106

<Report Findings Here> 14-4 Any physical tokens (e.g., brass keys or chip cards) used to enable key loading or the signing of authenticated applications must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control. These tokens must be secured in a manner similar to key components, including tamper-evident, authenticable packaging and the use of access-control logs for when removed or …

Logs of key-loading activities reviewed: <Report Findings Here> 14-4 Any physical tokens (e.g., brass keys or chip cards) used to enable key loading or the signing of authenticated applications must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control. These tokens must be secured in a manner similar to key components, including tamper-evident, authenticable packaging and the use of access-control …

Modified p. 103 → 107

<Report Findings Here> 14-5 Default passwords/authentication codes used to enforce dual-control mechanisms must be changed, and documented procedures must exist to require that these password/PINs be ~~changed,~~ when assigned personnel change.

<Report Findings Here> 14-5 Default passwords/authentication codes used to enforce dual-control mechanisms must be changed, and documented procedures must exist to require that these password/PINs be changed when assigned personnel change.

Modified p. 104 → 107

<Report Findings Here> 14-5.b Verify that documented procedures exist to require that these passwords/authentication codes be changed when assigned personnel change.

Documented procedures reviewed: <Report Findings Here> 14-5.b Verify that documented procedures exist to require that these passwords/authentication codes be changed when assigned personnel change.

Modified p. 104 → 107

<Report Findings Here> 15-1 A cryptographic-based validation mechanism must be in place to ensure the authenticity and integrity of keys and/or their components (e.g., testing key-check values, hashes, or other similar unique values that are based upon the keys or key components being loaded). See ISO 11568. Where check values are used, recorded, or displayed key-component check values and key-check values must be generated by a cryptographic process such that all portions of the key or key component are involved …

Documented procedures reviewed: <Report Findings Here> 15-1 A cryptographic-based validation mechanism must be in place to ensure the authenticity and integrity of keys and/or their components (e.g., testing key-check values, hashes, or other similar unique values that are based upon the keys or key components being loaded). See ISO 11568. Where check values are used, recorded, or displayed key-component check values and key-check values must be generated by a cryptographic process such that all portions of the key or key …

Modified p. 104 → 107

15-1.a Examine documented procedures to verify a ~~cryptographic- based~~ validation mechanism is in place to ensure the authenticity and integrity of keys and/or components.

15-1.a Examine documented procedures to verify a cryptographic-based validation mechanism is in place to ensure the authenticity and integrity of keys and/or components.

Modified p. 104 → 108

Describe how the key-loading processes observed verified that the defined ~~cryptographic-based~~ validation mechanism used to ensure the authenticity and integrity of keys and components is being used and is verified by the applicable key custodians:

Describe how the key-loading processes observed verified that the defined cryptographic- based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and is verified by the applicable key custodians:

Removed p. 105

15-3 not used in EMS 15-4 not used in EMS 15-5 not used in EMS

Removed p. 106

<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. 106 → 108

16-1.a Verify documented procedures exist for all key-loading operations.

16-1.a Verify documented procedures exist for all key-loading operations. Documented procedures reviewed: <Report Findings Here>

Modified p. 106 → 109

<Report Findings Here> 16-1.c Observe the key-loading process for keys loaded as components and verify that the documented procedures are demonstrably in use. This may be done as necessary on test equipment•e.g., for HSMs.

Responsible personnel interviewed: <Report Findings Here> 16-1.c Observe the key-loading process for keys loaded as components and verify that the documented procedures are demonstrably in use. This may be done as necessary on test equipment•e.g., for HSMs.

Removed p. 107

<Report Findings Here> Documented operational procedures <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:

Modified p. 107 → 109

• Be unique to those two entities or logically separate ~~systems, and~~

• Be unique to those two entities or logically separate systems

Modified p. 107 → 109

Documented key matrix reviewed:

Documented key matrix reviewed: <Report Findings Here> Documented operational procedures reviewed:

Modified p. 107 → 110

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:

Describe how the generation of (or otherwise obtaining) key check values for any key- encipherment keys (KEKs) verified key uniqueness between the two organizations:

Modified p. 108 → 110

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. 108 → 110

Compare ~~key check~~ values against those for known or default keys to verify that known or default key values are not used.

• Compare key-check values against those for known or default keys to verify that known or default key values are not used.

Removed p. 109

• Proactive safeguards that shut down the source of any synchronization errors and start an investigative process to determine the true cause of the event.

<Report Findings Here> 18-2 To prevent or detect usage of a compromised key, key-component packaging or containers that show signs of 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 discarding and invalidation of the component and the associated key at all locations where they exist.

18-2.a Verify that documented procedures 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 …

Modified p. 109 → 111

• 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.

Modified p. 109 → 111

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

Removed p. 110

<Report Findings Here> Where key blocks are not implemented, describe how the examined project plans verified that key block implementation is in accordance with the prescribed timeline(s).

<Report Findings Here> 18-4 Not used in EMS 18-5 Not used in EMS 18-6 Not used in EMS 18-7 Not used in EMS

Modified p. 110 → 112

• A MAC computed over the concatenation of the clear-text attributes and the enciphered portion of the key block, which includes the key itself ~~e.g.~~ TR-31;

• A MAC computed over the concatenation of the clear-text attributes and the enciphered portion of the key block, which includes the key itself e.g., TR-31;

Modified p. 110 → 112

• An integrity check that is an implicit part of the key-encryption process such as that which is used in the AES key-wrap process specified in ANSI X9.102.

• A digital signature computed over that same data; An integrity check that is an implicit part of the key-encryption process such as that which is used in the AES key-wrap process specified in ANSI X9.102.

Modified p. 110 → 112

Describe how the ~~documented procedures examined and the~~ key operations ~~observed~~ verified that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of the acceptable methods or an ~~equivalent.~~

Documented procedures reviewed: <Report Findings Here> Describe how the observed key operations verified that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of the acceptable methods or an equivalent, or where key blocks are not implemented, identify and examine project plans to implement in accordance with the prescribed timeline.

Removed p. 111

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.

Key-management documentation examined:

Modified p. 111 → 113

~~Key-management documentation~~ <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

<Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Modified p. 111 → 113

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

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 or PIN encipherment are not used for any other purpose:

Removed p. 112

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. 112 → 113

Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

<Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Modified p. 112 → 114

Key-management documentation ~~examined:~~

Key-management documentation reviewed:

Modified p. 112 → 114

Key-management documentation ~~examined:~~

Key-management documentation reviewed:

Modified p. 112 → 114

<Report Findings Here> 19-4 Keys must never be shared or substituted between production and test/development ~~systems.~~

<Report Findings Here> 19-4 Keys must never be shared or substituted between production and test/development systems:

Modified p. 112 → 114

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. 112 → 114

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.

Removed p. 113

<Report Findings Here> 19-5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be

Modified p. 113 → 114

<Report Findings Here> 19-4.d Compare 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 Compare 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. 113 → 115

• 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. 113 → 115

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. 113 → 115

~~Note: This~~ does not apply to HSMs that are never intended to be used for production.

Note this does not apply to HSMs that are never intended to be used for production.

Removed p. 114

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. 114 → 115

• 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. 114 → 116

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.

Removed p. 115

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

Modified p. 115 → 116

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 POI devices~~ to verify that unique keys are generated and used for each POI device.

Documented procedures reviewed: <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. 115 → 116

<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. 115 → 116

<Report Findings Here> 20-2 If a POI device directly interfaces with more than one entity for decryption of account data (e.g., different acquiring ~~organizations),~~ the POI ~~device~~ must have a completely different and unique key or set of keys for each ~~acquirer.~~ These different keys, or sets of keys, must be totally independent and not variants of one another.

<Report Findings Here> 20-2 If a POI device directly interfaces with more than one entity for decryption of account data (e.g., a different acquiring organization), the POI must have a completely different and unique key or set of keys for each acquiring organization. These different keys, or sets of keys, must be totally independent and not variants of one another.

Modified p. 115 → 117

20-2.a Examine documented procedures for generating all types of keys and verify procedures ~~exist to~~ ensure that unique ~~keys~~ or sets of ~~keys~~ are used for each acquiring organization and totally independent and ~~are~~ not variants of one another.

20-2.a Examine documented procedures for generating all types of keys and verify the procedures ensure that unique keys, or sets of keys, are used for each acquiring organization and are totally independent and not variants of one another.

Removed p. 116

<Report Findings Here> Key generation logs examined:

<Report Findings Here> 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:

• Unique data is used for the derivation process such that all transaction-originating POI devices receive unique secret keys.

• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI.

Modified p. 116 → 118

This requirement refers to the use of a single “base” key to derive initial keys for many different 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 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. 116 → 118

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 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 POI device:

Modified p. 117 → 119

• Different BDKs for each financial ~~institution~~

• Different BDKs for each financial institution;

Modified p. 117 → 119

• Different BDKs for each financial ~~institution~~

• Different BDKs for each financial institution;

Modified p. 117 → 119

• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal ~~model~~

• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model;

Modified p. 117 → 119

• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal ~~model~~

• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model;

Modified p. 117 → 119

~~• Different BDKs by geographic region, market segment, processing platform, or sales unit~~ COMPONENT PROVIDERS ONLY: Must use at least one unique Base Derivation Key (BDK) per acquiring organization and must be able to support segmentation of multiple BDKS of acquiring organizations.

COMPONENT PROVIDERS ONLY: Must use at least one unique Base Derivation Key (BDK) per acquiring organization and must be able to support segmentation of multiple BDKS of acquiring organizations.

Modified p. 117 → 119

• 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. 117 → 119

<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 21-1 Secret or private keys must only exist in one or more of the following forms:

Removed p. 118

Note: Key-injection facilities may have clear-text keying material outside of a SCD when used within a secure room in accordance with Requirement 32.

Note for hybrid decryption solutions: Clear-text Data Decryption Keys (DDKs) may temporarily be retained by the Host System in volatile memory for the purpose of decrypting account data.

<Report Findings Here> Describe how the key stores observed verified that secret or private keys only exist in one or more approved forms at all times when stored:

<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).

Modified p. 118 → 120

~~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).~~

Documented procedures reviewed: <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. 118 → 120

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. 119 → 121

~~Key-management documentation~~ <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

<Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Modified p. 119 → 121

<Report Findings Here> 21-2.3.b Observe key-component access controls and ~~key- custodian~~ authorizations/assignments to verify that all individuals with access to key components or shares are designated as key custodians for those particular components/shares.

<Report Findings Here> 21-2.3.b Observe key-component access controls and key-custodian authorizations/assignments to verify that all individuals with access to key components or shares are designated as key custodians for those particular components/shares.

Modified p. 119 → 121

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. 119 → 121

<Report Findings Here> 21-2.4 Procedures must exist to ensure that no custodian ever has access to sufficient key components or shares ~~to reconstruct~~ a secret or private key cryptographic key.

<Report Findings Here> 21-2.4 Procedures must exist to ensure that no custodian ever has access to sufficient key components or shares of a secret or private key to reconstruct a cryptographic key.

Modified p. 119 → 121

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.

Removed p. 120

<Report Findings Here> 21-3 Key components/shares must be stored as follows:

Note: Tamper-evident authenticable packaging

•opacity may be envelopes within tamper-evident packaging

Modified p. 120 → 121

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:

Modified p. 120 → 122

<Report Findings Here> 21-3.1 Key components that exist in clear text outside of an SCD must be sealed in individual opaque, ~~pre-numbered,~~ tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging.

Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 21-3.1 Key components that exist in clear text outside of an SCD must be sealed in individual opaque, pre-numbered tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging.

Modified p. 120 → 122

• 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. 120 → 122

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. 120 → 122

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. 120 → 122

<Report Findings Here> 21-3.1.b Inspect any 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 Inspect any 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.

Modified p. 120 → 122

Identify the P2PE Assessor who confirms that ~~tamper- evident~~ packaging prevents the determination of the key component without visible damage to the packaging:

Identify the P2PE Assessor who confirms that tamper-evident packaging prevents the determination of the key component without visible damage to the packaging:

Modified p. 121 → 122

<Report Findings Here> 21-3.1.d 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).

Responsible personnel interviewed: <Report Findings Here> 21-3.1.d 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).

Modified p. 121 → 123

Identify the P2PE Assessor who confirms that for each key ~~component~~ storage container:

Identify the P2PE Assessor who confirms that for each key component/share storage container:

Modified p. 121 → 123

• Key ~~components~~ for different custodians are stored in separate secure containers.

• Key components/shares for different custodians are stored in separate secure containers.

Removed p. 122

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.

Modified p. 122 → 123

<Report Findings Here> Describe how the implemented processes observed verified that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner

•or designated backup(s)

•has possession of both the token and its access code:

Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner

•or designated backup(s)

•has possession of both the token and its access code:

Modified p. 122 → 123

<Report Findings Here> 21-4 Not used in ~~EMS~~ 22-1 Procedures for known or suspected compromised keys must include the following:

<Report Findings Here> 21-4 Not used in DMS 22-1 Procedures for known or suspected compromised keys must include the following:

Modified p. 122 → 123

22-1 Verify documented procedures exist for replacing known or suspected compromised keys that ~~includes~~ all of the following (22-1.1 through 22-1.5 below):

22-1 Verify documented procedures exist for replacing known or suspected compromised keys that include all of the following (22-1.1 through 22-1.5 below):

Modified p. 122 → 123

<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 reviewed: <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. 122 → 124

<Report Findings Here> Describe how the implemented processes observed verified that 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:

Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified 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. 122 → 124

<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. 123

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

• Processing with that key is halted, and the key is replaced with a new unique key.

• Any systems, devices, or processing involving subordinate keys that have been calculated, derived, or otherwise generated, loaded, or protected using the compromised key are included in the key-replacement process.

Modified p. 123 → 124

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

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:

Modified p. 123 → 124

<Report Findings Here> ~~22-1.3.~~ A secret or private cryptographic key must be

<Report Findings Here> 22-1.3 A secret or private cryptographic key must be

Modified p. 123 → 124

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.

Removed p. 124

<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):

<Report Findings Here> 22-1.4.b A documented escalation process and notification to organizations that currently share or have previously shared the key(s), including:

• Identification of key personnel

• Host System tamper-detection mechanism has been activated, for hybrid decryption solutions PDCP 22-1.5 Interview responsible personnel and review documented procedures to verify that specific events that may indicate a Responsible personnel interviewed:

Modified p. 124 → 125

• A damage assessment including, where necessary, the engagement of outside ~~consultants~~

• A damage assessment including, where necessary, the engagement of outside consultants.

Modified p. 124 → 125

• ~~Specific~~ actions to be taken with system software and hardware, encryption keys, encrypted data, etc.

• Details of specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.

Modified p. 124 → 126

• 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. 125

• Host System tamper-detection mechanism has been activated, for hybrid decryption solutions Documented procedures examined:

22-2 Interview responsible personnel and observe implemented processes to verify that 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 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).

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 …

Modified p. 125 → 126

<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 or otherwise destroyed in the original KLD or POI ~~device (or Host System).~~

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:

Modified p. 125 → 126

<Report Findings Here> 22-3 Not used in ~~EMS 22-4 Not used in EMS~~

<Report Findings Here> 22-3 Not used in DMS

Removed p. 126

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. 126 → 127

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.

Modified p. 126 → 127

~~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. 126 → 127

Vendor documentation reviewed: <Report Findings Here>

Removed p. 127

Vendor documentation examined:

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:

Modified p. 127 → 128

~~<Report Findings Here> 23-2.c Via~~ examination of the network schematic detailing transaction flows with the associated key usage and identification of the sources of the keys ~~used, determine~~ 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. 127 → 128

• 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. 127 → 128

<Report Findings Here> Describe how the implemented processes observed verified that reversible key transformations are not used across different levels of the key hierarchy, as follows:

Documented procedures reviewed: <Report Findings Here> Describe how the implemented processes observed verified that reversible key transformations are not used across different levels of the key hierarchy, as follows:

Modified p. 128

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

Modified p. 128

<Report Findings Here> 24-1.b Identify a sample of keys and key components that are no longer used or have been replaced. For each item in the sample, interview ~~responsible personnel~~ and ~~examine key- history logs and key-destruction logs to verify~~ that ~~all keys~~ have been ~~destroyed.~~

Documented procedures reviewed: <Report Findings Here> 24-1.b Identify a sample of keys and key components that are no longer used or have been replaced. For each item in the sample, interview Sample of keys and key components that are no longer used or have been replaced reviewed:

Modified p. 128

~~Sample of keys~~ and key components that are no longer used or have been replaced ~~reviewed:~~

24-1.a Verify documented procedures are in place for destroying secret or private keys, and their key components that are no longer used or that have been replaced by a new key.

Modified p. 128 → 129

<Report Findings Here> Key-history logs examined: <Report Findings Here> Key-destruction logs examined: <Report Findings Here> 24-1.c Examine storage locations for the sample of destroyed keys to verify they are no longer kept.

Responsible personnel interviewed: <Report Findings Here> Key-history logs examined: <Report Findings Here> Key-destruction logs examined: <Report Findings Here> 24-1.c Examine storage locations for the sample of destroyed keys to verify they are no longer kept.

Removed p. 129

<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

Modified p. 129

<Report Findings Here> 24-2.1 Keys on all other storage media types in all permissible forms

•physically secured, enciphered (except for electronic ~~database~~ backups of cryptograms), or components

•must be destroyed following the procedures outlined in ISO

•9564 or ISO

•11568.

<Report Findings Here> 24-2.1 Keys on all other storage media types in all permissible forms

•physically secured, enciphered (except for electronic DB backups of cryptograms), or components

•must be destroyed following the procedures outlined in ISO

•9564 or ISO

•11568.

Modified p. 129

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. 129

• physically secured, enciphered, or component

•are destroyed following the procedures outlined in ISO

•9564 or ISO

•11568.

• physically secured, enciphered, or components

•must be destroyed following the procedures outlined in ISO

•9564 or ISO

•11568.

Modified p. 129 → 130

Describe how the key-destruction processes observed verified that keys on all other storage media types in all permissible forms

•physically secured, enciphered, or component

•are destroyed following the procedures outlined in ISO

•9564 or ISO <Report Findings Here> 24-2.2 The key-destruction process must be observed by a third party other than the ~~custodians of any component of that key•i.e., the third party must not be a key custodian for any part of the key being destroyed.~~

Describe how the key-destruction processes observed verified that keys on all other storage media types in all permissible forms

•physically secured, enciphered, or component

•are destroyed following the procedures outlined in ISO

•9564 or ISO <Report Findings Here> 24-2.2 The key-destruction process must be observed by a third party other than the custodian.

Modified p. 130

<Report Findings Here> 24-2.2.b Inspect 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 Inspect 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. 130

24-2.3.a Verify documented procedures exist for destroying key components of ~~keys~~ once the keys are successfully loaded and validated as operational.

24-2.3.a Verify documented procedures exist for destroying key components of keys, once the keys are successfully loaded and validated as operational.

Modified p. 130

<Report Findings Here> 24-2.3.b Observe key-conveyance/loading processes to verify that any key components are destroyed once the keys are successfully loaded and validated as operational.

Documented procedures reviewed: <Report Findings Here> 24-2.3.b Observe key-conveyance/loading processes to verify that any key components are destroyed once the keys are successfully loaded and validated as operational.

Modified p. 130 → 131

~~PDCP~~ Key custodians interviewed: <Report Findings Here>

Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Removed p. 131

• Key custodian(s) are designated for each component.

Modified p. 131

~~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. 131

• Assigned key custodians are employees or contracted ~~personnel.~~

• Assigned key custodians are employees or contracted personnel Describe how the key-custodian assignments observed for each component verified that:

Modified p. 131

~~Describe how the key-custodian assignments reviewed~~ for each ~~component verified that:~~

• A primary and a backup key custodian are designated for each component.

Modified p. 131

Completed key-custodian forms ~~examined:~~

Completed key-custodian forms reviewed:

Modified p. 131

Completed key-custodian forms ~~examined:~~

Completed key-custodian forms reviewed:

Modified p. 132 → 131

• An effective date ~~and time~~ for the custodian’s access

• An effective date for the custodian’s access

Modified p. 132 → 131

• Signature of management authorizing the access ~~25-1.3 Examine all key-custodian forms to verify that they include the following:~~

• Signature of management authorizing the access

Modified p. 132

• An effective date ~~and time~~ for the custodian’s access

• An effective date for the custodian’s access

Modified p. 132

• Signature of management authorizing the access Completed key-custodian forms ~~examined:~~

• Signature of management authorizing the access Completed key-custodian forms reviewed:

Removed p. 133

Organizations that are of insufficient size that they cannot support the reporting-structure requirement must:

Modified p. 133 → 132

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. 133 → 132

~~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. 133 → 132

Documented key-custodian assignments ~~examined:~~

Documented key-custodian assignments reviewed:

Modified p. 133 → 132

<Report Findings Here> Documented organization charts ~~examined:~~

<Report Findings Here> Documented organization charts reviewed:

Removed p. 135

• Tamper-evident and authenticable package number (if applicable) 26-1.a Examine log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:

• Tamper-evident package number (if applicable) <Report Findings Here> PDCP Audit trail files examined: <Report Findings Here>

Modified p. 135 → 134

• 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 reviewed: <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. 135 → 134

• ~~Key component~~ identifier

• Key-component identifier

Modified p. 135 → 134

• ~~Key component~~ identifier

• Key-component identifier

Modified p. 135 → 134

• 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 reviewed: <Report Findings Here> Describe how the audit log settings observed verified that logs include the following:

Removed p. 136

Describe how the audit train files examined verified that they are archived for a minimum of two years subsequent to key destruction.

<Report Findings Here> Documented procedures examined:

<Report Findings Here> Personnel interviewed: <Report Findings Here> OR Describe how backup storage locations verified that backups are maintained as follows:

Modified p. 136 → 134

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

• 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.

Modified p. 136 → 134

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. 136 → 134

<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 reviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> Backup records reviewed: <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. 136 → 135

• Subject to at least the same level of security control as operational keys as specified in this document ~~Documented procedures examined:~~

• 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. 136 → 135

• 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. 137 → 135

• 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. 137 → 135

• 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. 137 → 135

Responsible personnel interviewed:

Responsible personnel interviewed: <Report Findings Here> Describe how the backup processes observed verified that:

Modified p. 137 → 135

• 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. 137 → 135

<Report Findings Here> 28-1 Written procedures must ~~exist~~ and all affected parties must be aware of those procedures. All activities related to key administration must be documented. This includes all aspects of key administration, as well as:

<Report Findings Here> 28-1 Written procedures must exist, and all affected parties must be aware of those procedures. All activities related to key administration performed by a key-injection facilities must be documented. This includes all aspects of key administration, as well as:

Modified p. 137 → 135

• 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

Modified p. 137 → 136

• Background checks for personnel (within the constraints of local ~~laws)~~

• Background checks for personnel (within the constraints of local laws

Modified p. 137 → 136

• Management of personnel changes, including revocation of access control and other privileges when personnel move Documented procedures ~~examined:~~

• Management of personnel changes, including revocation of access control and other privileges when personnel move Documented procedures reviewed: <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. 138 → 136

<Report Findings Here> 28-1.c Interview personnel to verify that security-awareness training is provided for the appropriate personnel.

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. 138 → 136

<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~~ 29-1 Secure cryptographic devices

•such as HSMs and POI devices

•must be placed into service only if there is assurance that the equipment has not been subjected to unauthorized modifications, substitution, or tampering and has not otherwise been subject to misuse prior to deployment.

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 29-1 Secure cryptographic devices

•such as HSMs and POI devices

•must be placed into service only if there is assurance that the equipment has not been subjected to unauthorized modifications, substitution, or tampering and has not otherwise been subject to misuse prior to deployment.

Removed p. 139

29-1.1 All POI devices and other SCDs must be protected against compromise. Any compromise must be detected. Loading and use of any financial keys after the compromise must be prevented. Controls must include the following:

Modified p. 139 → 137

• SCDs used for ~~key injection/loading~~ or code signing have not been substituted or subjected to unauthorized modifications or tampering.

• SCDs used for key-injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.

Modified p. 139 → 137

• SCDs used for ~~key injection/loading~~ or code signing have not been substituted or subjected to unauthorized modifications or tampering.

• SCDs used for key-injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.

Modified p. 139 → 137

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

Documented processes reviewed: <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:

Removed p. 140

<Report Findings Here> 29.1.1.b Verify that documented procedures include 29-1.1.1 through 29-1.1.3 below.

<Report Findings Here> 29-1.1.1 Access to all 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.

29-1.1.1.a Examine access-control documentation and device configurations to verify that access to all POI devices and key injection/loading devices is defined and documented.

Access-control documentation reviewed:

<Report Findings Here> Describe how access-control documentation and device configurations observed verified that access to all POI devices and key injection/loading devices is defined and documented:

<Report Findings Here> 29-1.1.1.b For a sample of POI device types and other …

Removed p. 141

Describe how the implemented access controls examined verified that unauthorized individuals cannot access, modify, or substitute any POI device or other SCD:

29-1.1.3 All personnel with access to POI devices and other SCDs prior to deployment are documented in a formal list and authorized by management. A documented security policy must exist that requires the specification of personnel with authorized access to all secure cryptographic devices. This includes documentation of all personnel with access to POI devices and other SCDs as authorized by management. The list of authorized personnel is reviewed at least annually.

Note: “Prior to deployment” for this requirement means prior to the solution provider (or component provider) sending POI devices to either a distribution channel or the end merchant who will use the POI device to process payment transactions.

29-1.1.3.a Examine documented authorizations for personnel with access to devices to verify that prior to deployment:

• All personnel with access to …

Modified p. 141 → 137

<Report Findings Here> ~~29-1.1.2 Intentionally left blank.~~

<Report Findings Here> 29-3 Not used in DMS

Removed p. 142

29-1.2.a Examine vendor documentation or other information sources to identify default keys (such as keys that are pre- installed for testing purposes), passwords, or data.

<Report Findings Here> 29-1.2.b Observe implemented processes and interview personnel to verify that default keys or passwords are not used.

<Report Findings Here> 29-2 Not used in EMS 29-3 Implement physical protection of devices from the manufacturer’s facility up to the point of key-insertion or inspection, through one or more of the following:

Modified p. 142 → 138

• 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.

Removed p. 143

Responsible personnel interviewed: 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. 143 → 138

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

Documented procedures reviewed: <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.

Modified p. 143 → 138

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

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 back-up devices

•throughout their life cycle. 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 must not supplant the implementation of dual-control mechanisms.

Modified p. 143 → 138

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

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. 143 → 139

• throughout their life ~~cycle.~~

• throughout their life cycle:

Modified p. 143 → 139

<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.~~

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

Removed p. 144

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

Documented security policy examined:

Modified p. 144 → 139

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. 144 → 139

Sample of received devices: <Report Findings Here> Sender documentation/record of ~~serial~~ number validations reviewed:

Sample of received devices: <Report Findings Here> Sender documentation/record of serial- number validations reviewed:

Modified p. 144 → 139

<Report Findings Here> 29-4.2 The security policy enforced by the HSM must not allow unauthorized or unnecessary functions. HSM API functionality and commands that are not required to support specified functionality must be disabled before the equipment is commissioned.

<Report Findings Here> 29-4.2 The security policy enforced by the HSM must not allow unauthorized or unnecessary functions. HSM API functionality and commands that are not required in account-data-processing equipment to support specified functionality must be disabled before the equipment is commissioned. Documentation (e.g., a checklist or similar suitable to use as a log) of configuration settings must exist and be signed and dated by personnel responsible for the implementation. This documentation must include identifying information for the HSM, such …

Modified p. 144 → 139

29-4.2.a Obtain and ~~examine~~ the defined security policy to be enforced by the HSM.

29-4.2.a Obtain and review the defined security policy to be enforced by the HSM.

Removed p. 145

<Report Findings Here> 29-4.2.c For a sample of HSMs, examine the configuration settings to determine that only authorized functions are enabled.

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.

Note: Examples of sensitive functions include but are not limited to: loading of key components, outputting clear-text key components, and altering HSM configuration.

PDCP 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. 145 → 139

HSM configuration settings documentation ~~examined:~~

HSM configuration settings documentation reviewed:

Removed p. 146

<Report Findings Here> 29-4.4.1 Running self-tests to ensure the correct operation of the device.

Records of device inspections examined:

Modified p. 146 → 140

<Report Findings Here> 29-4.4 Inspect and test all HSMs

•either new or retrieved from secure storage

•prior to installation to verify devices have not been tampered with or compromised.

Documented procedures reviewed: <Report Findings Here> 29-4.4 Inspect and test all HSMs

•either new or retrieved from secure storage

•prior to installation to verify devices have not been tampered with or compromised.

Modified p. 146 → 140

Processes must ~~include :~~

Processes must include:

Modified p. 146 → 140

~~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.

Modified p. 146 → 140

~~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.

Documented procedures reviewed: <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.

Modified p. 146 → 140

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

Records of device inspections reviewed: <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. 146 → 140

<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 Responsible personnel interviewed: <Report Findings Here>

Modified p. 146 → 141

~~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.~~

Describe how the inspection processes observed verified that devices are installed, or reinstalled, only after confirming that the device has not been tampered with or compromised:

Modified p. 147 → 141

<Report Findings Here> Describe how the inspection processes observed verified that processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti-tamper mechanisms are not modified or removed:

Responsible personnel interviewed: <Report Findings Here> Describe how the inspection processes observed verified that processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti-tamper mechanisms are not modified or removed:

Modified p. 147 → 141

<Report Findings Here> 29-4.4.4 Maintaining records of the tests and inspections, and retaining records for at least one ~~year.~~

<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. 147 → 141

<Report Findings Here> 29-4.4.4.b Examine records of inspections to verify records are retained for at least one year.

Records of inspections examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 29-4.4.4.b Examine records of inspections to verify records are retained for at least one year.

Modified p. 147 → 141

<Report Findings Here> ~~29-5 Maintain HSMs~~ in tamper-evident packaging ~~or in secure storage~~ until ready for installation.

Documented procedures reviewed: <Report Findings Here> 29-5.b Observe a sample of received devices to verify they are maintained in tamper-evident packaging until ready for installation.

Modified p. 147 → 141

29-5.a Examine documented procedures to verify they require devices be maintained in tamper-evident packaging 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.

Removed p. 148

<Report Findings Here> 30-1 Not used in P2PE 30-2 Not used in P2PE 30-3 Not used in EMS 31-1 Procedures must be in place to ensure that any SCDs to be removed from service

•e.g., retired or returned for repair

•are not intercepted or used in an unauthorized manner, including rendering all secret and private keys, key material, and account data stored within the device irrecoverable.

• Procedures require that all secret and private keys, key material, and all account data stored within the device be securely destroyed.

• Procedures cover all devices removed from service permanently or for repair.

• Procedures cover requirements at 31-1.1 through 31-1.6 below.

Modified p. 148 → 141

Sample of received devices reviewed:

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

Modified p. 148 → 142

• 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. 148 → 142

• Procedures cover all devices removed from service ~~permanently~~ or for repair.

• Procedures cover all devices removed from service or for repair.

Modified p. 148 → 142

<Report Findings Here> 31-1.1 HSMs require dual control (e.g., to invoke the system menu) to implement all critical decommissioning processes.

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.

Removed p. 149

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

Modified p. 149 → 142

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

Documented procedures reviewed: <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.

Modified p. 149 → 142

Personnel interviewed: <Report Findings Here> 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. 149 → 142

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

<Report Findings Here> 31-1.2 Keys 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. 149 → 142

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. 149 → 142

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. 149 → 143

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. 150

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, or for signing applications and/or whitelists to be loaded into 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, or for signing applications and/or whitelists to be loaded into POI devices.

Modified p. 150 → 143

<Report Findings Here> Device-return records examined: <Report Findings Here> 31-1.5 Devices are tracked during the return process.

Responsible personnel interviewed: <Report Findings Here> Device-return records examined: <Report Findings Here> 31-1.5 Devices are tracked during the return process.

Modified p. 150 → 143

31-1.5 Interview responsible personnel and examine ~~device- return~~ records to verify that devices are tracked during the return process.

31-1.5 Interview responsible personnel and examine device-return records to verify that devices are tracked during the return process.

Modified p. 150 → 143

<Report Findings Here> Device-return records examined: <Report Findings Here> 31-1.6 Records of the tests and inspections ~~are~~ maintained for at least one year.

Responsible personnel interviewed: <Report Findings Here> Device-return records examined: <Report Findings Here> 31-1.6 Records of the tests and inspections maintained for at least one year.

Modified p. 150 → 144

Documented ~~procedures~~ reviewed:

Documented records reviewed:

Removed p. 151

<Report Findings Here> 32-1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.

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, 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 …

Removed p. 152

• To enable any manual key-encryption functions and any key-encryption functions that occur outside of normal transaction processing;

• To enable application-signing functions;

• To place the device into a state that allows for the input or output of clear-text key components;

• 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

• To enable application-signing functions

• To enable application-signing functions

• To place the device into a state that allows for the input or output of clear-text key components

• To place the device into a state that allows for the input or output of clear-text key components

• …

Removed p. 153

• 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 documented procedures to confirm that they require devices are at all times within a secure room and either:

Removed p. 153

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

<Report Findings Here> Describe how devices are at all times within a secure room and either:

<Report Findings Here> 32-2 Not used in EMS 32-3 Not used in EMS 32-4 Not used in EMS 32-5 Not used in EMS 32-6 Not used in EMS 32-7 Not used in EMS

Modified p. 154 → 144

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 reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 33-1.b Verify that written records exist for the tests and inspections performed on devices before they are placed into service, as well as devices being decommissioned.

Modified p. 154 → 144

~~Documented records reviewed:~~ <Report Findings Here> 5A-1.1 Only approved encryption algorithms and key sizes must be used to protect account data and cryptographic keys, as listed in Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.

<Report Findings Here> 5A-1.1 Only approved encryption algorithms and key sizes must be used to protect account data and cryptographic keys, as listed in Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.

Modified p. 154 → 144

Documented ~~key-management~~ policies and procedures examined:

Documented key- management policies and procedures examined:

Modified p. 155 → 145

• 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. 155 → 145

Documented ~~key-management~~ procedures reviewed:

Documented key- management procedures reviewed:

Modified p. 155 → 145

5A-1.3.a Verify documentation exists describing the architecture (including all participating devices and cryptographic protocols), set-up and operation of the ~~key- management~~ solution.

5A-1.3.a Verify documentation exists describing the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key-management solution.

Modified p. 155 → 145

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

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

Modified p. 156 → 146

• Key-destruction method Documented ~~key-management~~ policies and procedures examined:

• Key-destruction method Documented key- management policies and procedures examined:

Modified p. 156 → 146

• Description of level in the key hierarchy ~~Documentation reviewed: <Report Findings Here>~~

• Description of level in the key hierarchy

Modified p. 157 → 146

~~• Key-destruction method 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:

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

Modified p. 157 → 146

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) ~~5A-1.3.2.a Examine key-management policies and procedures and verify a list of all devices used to generate keys managed as part of the P2PE solution is required, and includes:~~

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22)

Modified p. 157 → 147

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documented ~~key-management~~ policies and procedures reviewed:

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documented key- management policies and procedures reviewed:

Modified p. 157 → 147

~~• Device location Documentation reviewed:~~ <Report Findings Here> Personnel interviewed: ~~<Report Findings Here>~~

<Report Findings Here> Personnel interviewed:

Removed p. 158

<Report Findings Here> 5H-1 Not used in EMS 5I-1 Not used in EMS

Modified p. 158 → 147

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) ~~Responsible component provider personnel interviewed:~~

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documentation reviewed:

Document Comparison

From Revision History

Content Changes