Document Diff - PCI Watch

Added p. 2

• Updates from v3.0 P2PE Standard references to v3.1.

• Revisions made within the Introduction through Section 3 to add clarity and consistency, both within this P-ROV and across all v3.1 P-ROVs as applicable.

• Context of “PCI-listed” P2PE Products

• updated to “Validated”.

• Revision to the description for the use of Not Applicable to add clarity and guidance.

• Reformatting and restructuring of tables in Sections 2 and 3 with additional guidance.

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

• Certain tables/context were

• modified into new tables (e.g., 2.4.x)

• Table numbering in sections 1 through 3

• modified as needed to better align across all v3.1 P-ROVs.

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

• New table in section 4 to document all requirements determined to be Not Applicable.

• Updates to section 4 to align with the updates from the P2PE v3.1 Standard, …

Added p. 6

Solution assessments that have not satisfied the entirety of their Encryption Management Services (Domain 1 with Domain 5) via the use of applicable Validated P2PE Component Providers must complete the EMS P-ROV in addition to the Solution P-ROV.

Solution assessments that have not satisfied the entirety of their Decryption Management Services (Domain 4 with Domain 5) with applicable Validated P2PE Component Providers must complete the DMS P-ROV in addition to the Solution P-ROV.

N/A (Not Applicable) ‘Not Applicable’, or ‘N/A’, is only acceptable as a finding where the requirement, through testing and review, is determined to not apply to the P2PE Product.

Note: ‘Not Applicable’ cannot be used by entities that provide only partial aspects of a defined Component Provider service to validate to that Component Provider type. Refer to the “P2PE Applicability of Requirements” in the P2PE Program Guide.

Don’t mark “N/A” without providing an explanation and justification for why it is “N/A”.

Provide …

Added p. 13

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

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

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

Added p. 14

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

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

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

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

Are Third Party entities involved in the scope of Decryption Management Services for this assessment? Yes (If Yes, provide details below - insert additional rows as necessary) No (If No, leave remainder of this table blank) Entity Name Entity Location(s) Role …

Added p. 16

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

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

Added p. 17

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

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

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

DMS Component Assessments: Complete …

Added p. 27

4. Findings and Observations “In Place” may be a mix of “In Place” and “Not Applicable” responses, however it must not include any “Not in Place” responses.

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

Added p. 33

All N/A responses require reporting on testing performed (including interviews conducted and documentation reviewed) and must explain how it was determined that the requirement does not apply within the scope of the assessment for the P2PE Product. Note: ‘Not Applicable’ cannot be used by entities that provide only partial aspects of a defined Component Provider service to validate to that Component Provider type. Refer to the “P2PE Applicability of Requirements” in the P2PE Program Guide.

Every requirement denoted as ‘N/A’ in the reporting section below must be documented in this table and vice versa.

List requirements in the order as they appear in the reporting section below. Insert additional rows if needed.

Requirement Document how it was determined that the requirement is Not Applicable to the P2PE Product under assessment

Added p. 36

• Note that adding any software may invalidate the FIPS approval.

Added p. 54

<Report Findings Here> Hybrid Decryption Environments (where HSMs are required for cryptographic key-management functions but allow for non-SCD “Host Systems” to be used for account-data decryption) must meet the additional requirements specified in 4D and 5H. Refer to the P2PE Standard, P2PE Program Guide, and the P2PE Glossary for additional details.

Does this assessment meet the definition of a Hybrid Decryption Environment and therefore include the use of a Host System(s), Yes or No? Document how you determined whether or not non-SCD Host-System(s) are being used for the decryption of account data.

Yes, this IS a Hybrid Decryption Environment (Complete all of 4D and 5H) No, this is NOT a Hybrid Decryption Environment (Either leave 4D and 5H blank, or denote something commensurate with “N/A

• No Host Systems in Use”.

Added p. 68

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

Added p. 72

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

Added p. 90

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

Added p. 92

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

Added p. 99

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

• 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

Note: Printed key components includes manual (handwritten) capture.

Added p. 100

Describe how the blind mailers or other sealed containers used for key components observed verified that tampering can be detected:

• Printers used for this purpose are not used for other purposes and are used only under dual control.

<Report Findings Here> 6-3.1 The room must have walls made of solid materials. The walls do not have to extend from true floor to true ceiling but do need to extend from floor to ceiling.

6-3.1 Inspect the secure room designated for printing clear-text key components to verify that the walls are made of solid materials and extend from floor to ceiling.

Identify the P2PE Assessor who confirms the walls are made of solid materials and extend from floor to ceiling in the secure room designated for printing clear-text key components:

Added p. 101

6-3.2.a Observe all windows in the secure room to verify they are:

Identify the P2PE Assessor who confirms all windows in the secure room are:

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

Identify the P2PE Assessor who confirms the alarm mechanism is active for the window sensors:

Added p. 102

• Enforces dual-access requirements for entry into the secure room, and anti-pass-back requirements.

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

6-3.3.a Observe authorized personnel entering the secure room to verify that a badge-control system is in place that enforces the following requirements:

• Dual access for entry to the secure room

• Dual access for entry to the secure room

• Anti-pass-back Identify the P2PE Assessor who confirms that a badge-control system is in place that enforces the following requirements for authorized personnel entering the secure room:

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

Identify the P2PE Assessor who confirms through observation and interview of personnel that the badge-control system supports an alarm …

Added p. 103

6-3.5 Inspect configuration of monitoring systems and interview monitoring personnel to verify that monitoring is supported on a continuous (24/7) basis and alarms can be resolved by authorized personnel.

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

<Report Findings Here> 6-3.6 The CCTV server and digital storage must be secured in a separate secure location that is not accessible to personnel who have access to the secure room.

6-3.6.a Inspect location of the CCTV server and digital storage to verify they are located in a secure location that is separate from the secure room.

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

<Report Findings Here> 6-3.6.b Inspect access-control configurations for the CCTV server/storage secure location and the …

Added p. 103

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

Identify the P2PE Assessor who confirms through observation and examination of sample recordings that CCTV cameras are positioned to monitor:

6-3.8 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.

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

<Report Findings Here> 6-3.9 Images recorded from the CCTV system must be securely archived for a period of no less than 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 …

Added p. 113

<Report Findings Here> 8-1.c Where SCDs are used to convey components/shares:

Added p. 127

• 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-2 Not used in P2PE 10-3 Not used in P2PE 10-4 Not used in P2PE 10-5 Not used in P2PE

Added p. 138

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.

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.

Added p. 139

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

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

Added p. 150

• A digital signature computed over that same data, e.g., TR-34;

Added p. 161

<Report Findings Here> 21-3 Key components/shares must be stored as follows:

Added p. 173

Documented procedures reviewed: <Report Findings Here> 24-2.1.b Observe key-destruction processes to verify that keys on all other storage media types in all permissible forms

•physically secured, enciphered, or components

•are destroyed following the procedures outlined in ISO

•9564 or ISO

•11568.

Added p. 179

• Logs are kept whenever keys, key components, or related materials are removed from secure storage or loaded to an SCD.

• Logs are securely stored, for example, in a secure container with the associated key components.

• Logs must be archived for a minimum of two years subsequent to key destruction Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 26-1.b Examine log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:

Added p. 180

• Archived for a minimum of two years subsequent to key destruction

Added p. 183

Note: This applies to SCDs used for key injection or code signing, including display prompts.

Added p. 184

29-1.1 Examine documented procedures to verify controls are defined to protect POI devices and other SCDs from unauthorized access up to point of deployment.

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

Added p. 185

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.2.a Examine documented authorizations for personnel with access to devices to verify that prior to deployment:

• All personnel with access to POI devices and other SCDs are authorized by management in an auditable manner.

• The authorizations are reviewed annually.

Documented authorizations reviewed: <Report Findings Here> 29-1.1.2.b For a sample of POI device types and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in an auditable manner have access to devices.

Identify the P2PE Assessor who verified the access controls ensure only personnel documented and authorized in an auditable manner have access to devices.

<Report Findings Here> Describe how the implemented access controls for the sample of POI device types and …

Added p. 186

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.

Documentation reviewed: <Report Findings Here> 29-1.2.b Observe implemented processes and interview personnel to verify that default keys or passwords are not used.

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

• Upon tamper of the device it becomes infeasible to load any keying material.

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

<Report Findings Here> 29-4.2.c For a sample of HSMs, review the configuration settings to determine that only authorized functions are enabled.

Added p. 193

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

Added p. 201

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

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

Modified p. 1

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

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

Removed p. 4

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.

The following acronyms are used: SP = Solution Provider; CP = Component Provider.

Modified p. 4 → 5

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

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

Modified p. 4 → 5

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

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

Modified p. 4 → 5

• modified to increase/decrease the number of rows, ~~or to change column width.~~ Additional appendices may be

• modified to increase/decrease the number of rows, as necessary. Additional appendices may be

Modified p. 4 → 5

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 …

Removed p. 5

Note: A separate Merchant-Managed Solution P-ROV is used as part of MMS assessments.

Solution assessments that do not outsource the entirety of their Encryption Management Services to PCI-Listed Component Providers, either to an EMCP or to BOTH a PDCP AND a PMCP, must complete this P-ROV in addition to the Solution P-ROV.

Solution assessments that do not outsource the entirety of their Decryption Management Services to a PCI Listed DMCP must complete this P-ROV in addition to the Solution P-ROV.

Modified p. 5 → 6

Encryption Management Services (EMS) Solution (SP) Encryption Management CP (EMCP) POI Deployment CP (PDCP) POI Management CP (PMCP) Encryption Management Services relates to the distribution, management, and use of POI devices in a P2PE Solution.

Encryption Management Services (EMS) Solution (SP) Encryption Management CP (EMCP) POI Deployment CP (PDCP) POI Management CP (PMCP) Encryption Management Services relates to the distribution, management, and use of PTS-approved POI devices in a P2PE Solution.

Modified p. 5 → 6

Component Provider assessments for an EMCP, PDCP, or a PMCP must complete ~~this~~ P-ROV.

Component Provider assessments for an EMCP, PDCP, or a PMCP must complete the EMS P-ROV.

Modified p. 5 → 6

P2PE Application P2PE Application Any assessment that utilizes software on the POI devices intended for use in a P2PE Solution that has the potential to access clear-text ~~cardholder~~ data must complete ~~this P-ROV.~~

P2PE Application P2PE Application Any assessment that utilizes software on the PTS-approved POI devices intended for use in a P2PE Solution that has the potential to access clear-text account data must complete the P2PE Application P- ROV (one for each application).

Modified p. 5 → 6

Decryption Management Services (DMS) Solution (SP) Decryption Management CP (DMCP) Decryption Management Services relates to the management of a decryption environment, including applicable devices ~~(e.g., HSMs)~~ used to support a P2PE Solution.

Decryption Management Services (DMS) Solution (SP) Decryption Management CP (DMCP) Decryption Management Services relates to the management of a decryption environment, including applicable account-data decryption devices used to support a P2PE Solution.

Modified p. 5 → 6

Component Provider assessments for a DMCP must complete ~~this~~ P-ROV.

Component Provider assessments for a DMCP must complete the DMS P-ROV.

Modified p. 5 → 6

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) CA/RA Key Management Services relates to the generation, conveyance, management, and loading of cryptographic keys including the management of associated devices.

Modified p. 5 → 6

Solution assessments that have not satisfied the key management services requirements (Domain 5) either through the use of ~~PCI-listed~~ Component Providers and/or through the assessment of their Encryption Management Services and/or Decryption Management Services must complete the KMS P-ROV. E.g., if the P2PE Solution offers remote key-distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account-data encryption, or the operation of an applicable ~~CA/RA, or~~ any other relevant key management service that …

Solution assessments that have not satisfied the entirety of key management services requirements (Domain 5) either through the use of Validated P2PE Component Providers and/or through the assessment of their Encryption Management Services and/or Decryption Management Services must complete the KMS P-ROV. E.g., if the P2PE Solution offers remote key-distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account-data encryption, or the operation of an applicable CA/RA. Or if any other relevant …

Modified p. 5 → 6

Component Provider assessments for a KIF, KMCP, KLCP, or a CA/RA must complete ~~this P-ROV.~~

Component Provider assessments for a KIF, KMCP, KLCP, or a CA/RA must complete the KMS P- ROV.

Removed p. 6

Response When to use this Response:

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

Modified p. 6 → 7

• Section 4: Findings and Observations This Reporting Template includes tables with Reporting ~~Instructions built in.~~ Details provided should focus on concise quality of detail, rather than lengthy, repeated verbiage.

• Section 4: Findings and Observations This Reporting Template includes tables with Reporting Instructions. Details provided should focus on concise quality of detail, rather than lengthy, repeated verbiage.

Modified p. 6 → 7

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 …

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 section 4 ”Findings and Observations”, and are only addressed at that high-level. The summary of the overall compliance status is at section 2.8 “Summary of P2PE Assessment Compliance Status.” The following table is a representation when considering which selection to make. Assessors …

Modified p. 6 → 7

In Place The expected testing has been performed, and all elements of the requirement have been met as stated. ~~This may be a mix of In Place and Not Applicable responses, but no Not in Place response.~~ Requirements fulfilled by other P2PE Components or Third Parties should be In Place, unless the requirement does not apply.

RESPONSE WHEN TO USE THIS RESPONSE In Place The expected testing has been performed, and all elements of the requirement have been met as stated. Requirements fulfilled by other P2PE Components or Third Parties should be In Place, unless the requirement does not apply.

Modified p. 6 → 7

All ~~Not Applicable~~ responses require reporting on testing performed and must explain how it was determined that the requirement does not ~~apply.~~

All N/A responses require reporting on testing performed (including interviews conducted and documentation reviewed) and must explain how it was determined that the requirement does not apply within the scope of the assessment for the P2PE Product.

Removed p. 7

• Brief description/short answer

Modified p. 7 → 8

• “Identify the P2PE Assessor who confirms…” Indicates only an affirmative response where further reporting is deemed unnecessary by PCI SSC. The P2PE Assessor’s name or a Not Applicable response are the two appropriate responses here. A Not Applicable response will require brief reporting to explain how this was confirmed via testing.

“Identify the P2PE Assessor who confirms…” Indicates only an affirmative response where further reporting is deemed unnecessary by PCI SSC. The P2PE Assessor’s name or a Not Applicable response are the two appropriate responses here. A Not Applicable response will require brief reporting to explain how this was confirmed via testing.

Modified p. 7 → 8

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

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

Modified p. 7 → 8

• Sample reviewed Brief list is expected or sample identifier. ~~Again, where~~ applicable, it is the P2PE Assessor’s choice to list out each sample within reporting or to utilize sample identifiers from the sampling summary table.

Sample reviewed Brief list is expected or sample identifier. Where applicable, it is the P2PE Assessor’s choice to list out each sample within the reporting or to utilize sample identifiers from the sampling summary table.

Modified p. 7 → 8

• “Describe how…” ~~These are the only reporting instructions that will stretch across half of the table; the above are all a quarter-table’s width to serve as a visual indicator of detail expected in response.~~ These responses must be a narrative response that provides explanation as to the observation•both a summary of what was witnessed and how that verified the criteria of the testing procedure.

Brief description/short answer

• “Describe how…” These responses must be a narrative response that provides explanation as to the observation•both a summary of what was witnessed and how that verified the criteria of the testing procedure.

Removed p. 8

• Describe how a Requirement was verified as the Reporting Instruction directs, not just that it was verified.

• Don’t include forward-looking statements or project plans in responses.

Modified p. 8 → 9

• Complete all applicable P-ROVs based on the ~~assessment.~~

Complete all applicable P-ROVs based on the assessment type.

Modified p. 8 → 9

• Complete all sections in the order specified, with concise detail.

Complete all sections in the order specified, with concise detail.

Modified p. 8 → 9

• Read and understand the intent of each Requirement and Testing Procedure.

Read and understand the intent of each Requirement and Testing Procedure.

Modified p. 8 → 9

• Provide a response for every Testing Procedure, even if N/A.

Provide a response for every Testing Procedure, even if N/A.

Modified p. 8 → 9

• Provide sufficient detail and information to demonstrate a finding of “in place” or “not applicable.”

Provide sufficient detail and information to demonstrate a finding of “in place” or “not applicable.” Describe how a Requirement was verified as the Reporting Instruction directs, not just that it was verified.

Modified p. 8 → 9

• Ensure all parts of the Testing Procedure are addressed.

Ensure all parts of the Testing Procedure are addressed.

Modified p. 8 → 9

• Ensure the response covers all applicable application and/or system components.

Ensure the response covers all applicable application and/or system components.

Modified p. 8 → 9

• Perform an internal quality assurance review of the P-ROV for clarity, accuracy, and quality.

Perform an internal quality assurance review of the P-ROV for clarity, accuracy, and quality.

Modified p. 8 → 9

• Perform an internal quality assurance review of all submitted P-ROVs and the details within the PCI SSC Portal.

Perform an internal quality assurance review of all submitted P-ROVs and the details within the PCI SSC Portal.

Modified p. 8 → 9

• Provide useful, meaningful diagrams, as directed.

Provide useful, meaningful diagrams, as directed.

Modified p. 8 → 9

• Don’t report items in the “In Place” column unless they have been verified as being “in place.”

Don’t report items in the “In Place” column unless they have been verified as being “in place.” Don’t include forward-looking statements or project plans in responses.

Modified p. 8 → 9

• Don’t simply repeat or echo the Testing Procedure in the response.

Don’t simply repeat or echo the Testing Procedure in the response.

Modified p. 8 → 9

• Don’t copy responses from one Testing Procedure to another.

Don’t copy responses from one Testing Procedure to another.

Modified p. 8 → 9

• Don’t copy responses from previous assessments.

Don’t copy responses from previous assessments.

Modified p. 8 → 9

• Don’t include information irrelevant to the assessment.

Don’t include information irrelevant to the assessment.

Modified p. 9 → 10

1. Contact Information and Report Date 1.1 Contact Information ~~P2PE~~ Solution/Component Provider ~~contact information~~ Company name: Company URL:

1. Contact Information and Report Date 1.1 Contact Information Solution/Component Provider Contact Information Company name: Company URL:

Modified p. 9 → 10

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:

P2PE Assessor 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. 9 → 10

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 the relevant program documentation.

Modified p. 9 → 10

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

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

Modified p. 9 → 10

(Leave blank if not applicable) QA reviewer phone number: ~~Assessor~~ e-mail address:

(Leave blank if not applicable) QA reviewer phone number: QA reviewer e-mail address:

Modified p. 9 → 10

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

Assessor name: Assessor credentials: QSA (P2PE) PA-QSA (P2PE) Assessor phone number: Assessor e-mail address:

Modified p. 10 → 11

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

Modified p. 10 → 11

• Describe efforts made to ensure no conflict of interest resulted from the above mentioned services provided by the ~~PA-QSA(P2PE)/QSA (P2PE)/QSA company:~~

Describe efforts made to ensure no conflict of interest resulted from the above mentioned services provided by the PA-QSA(P2PE) / QSA(P2PE) / P2PE QSA company.

Removed p. 11

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

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.

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

Entity Name: Role/Function: Entity Location(s): Other Details, if needed:

Modified p. 11 → 12

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

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

Modified p. 11 → 12

P2PE Component Details ~~• Part A~~ P2PE Component ~~name:~~

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

Modified p. 11 → 12

Is the Component ~~already~~ listed on the PCI SSC List of Validated P2PE Components? Yes ~~(if yes,~~ provide ~~ref #) No~~

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

Removed p. 12

Identifier PTS Approval or FIPS #:

Decryption Management Services Decryption Management Yes No N/A

Modified p. 12 → 16

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

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

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

Modified p. 13 → 18

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

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

Modified p. 13 → 18

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

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

Removed p. 14

• Locations of critical facilities

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

Removed 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

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

Modified p. 15 → 20

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.

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

Removed p. 16

• Other Key Distribution / Loading / Injection activities

• Key Archiving (if applicable)

< Insert applicable diagram(s) showing all key-management processes >

Removed p. 17

Key type/description Purpose/function of the key * Note: A detailed Key Matrix is included in Findings and Observations, below.

Removed p. 19

All documentation reviewed for this P2PE Assessment:

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:

Reference # (optional use) Interviewee’s Name Company Job Title

Modified p. 20 → 24

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

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

Modified p. 20 → 24

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

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

Modified p. 21 → 27

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

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

Decryption Management Services

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

Modified p. 21 → 27

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

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

Modified p. 21 → 27

4D Implement secure, hybrid decryption processes.

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

Modified p. 23 → 29

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.

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.

Modified p. 25 → 31

5H For hybrid decryption solutions: Implement secure hybrid-key management.

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

Modified p. 25 → 32

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

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

Removed p. 26

Table 4.1

• Key Matrix. List of all cryptographic keys (by type) used in P2PE Solution/Component Key type/ description:

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

How key is distributed

• e.g., manually via courier, and/or via remote key distribution (RKD).

Types of media used for key storage:

Method of key destruction:

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:

Modified p. 26 → 34

• Listed on the PCI SSC website, with a valid PCI SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” Approval documentation reviewed: <Report Findings Here>

• Listed on the PCI SSC website, with a valid PCI SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” Approval documentation reviewed: <Report Findings Here> 4A-1.1.b Examine documented procedures and interview personnel to verify that all account-data decryption operations are performed only by the FIPS-approved and/or PTS-approved HSMs identified in 4A-1.1.a.

Modified p. 27 → 34

Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> ~~4A-1.1.1 The approval listing must match the deployed devices in the following characteristics:~~

Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here>

Modified p. 27 → 35

• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment

• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment Note: If the solution provider has applied a vendor security patch resulting in an

Modified p. 28 → 36

• added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements ~~Note that adding any software may invalidate the FIPS approval.~~

• added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements

Modified p. 28 → 36

4A-1.1.2.a Examine FIPS approval documentation (security policy) and HSM operational procedures to verify that the FIPS approval covers the cryptographic primitives, data-protection mechanisms, and ~~key-management~~ used for account data decryption and related processes.

4A-1.1.2.a Examine FIPS approval documentation (security policy) and HSM operational procedures to verify that the FIPS approval covers the cryptographic primitives, data-protection mechanisms, and key- management used for account data decryption and related processes.

Modified p. 28 → 36

<Report Findings Here> 4A-1.1.2.b If the HSM is operated in non-FIPS mode or non-FIPS validated software has been added to the HSM, review the solution provider’s written confirmation and confirm that it includes the following:

FIPS approval documentation reviewed: <Report Findings Here> HSM operational procedures reviewed: <Report Findings Here> 4A-1.1.2.b If the HSM is operated in non-FIPS mode or non-FIPS validated software has been added to the HSM, review the solution provider’s written confirmation and confirm that it includes the following:

Removed p. 29

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

Modified p. 29 → 37

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

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

Modified p. 29 → 38

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

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

Removed p. 30

<Report Findings Here> 4B-1.4 POI devices must be authenticated by the decryption environment and upon request by the solution provider.

Removed p. 32

<Report Findings Here> 4B-1.7 Processes are implemented to ensure that clear-text account data is never sent back to the encryption environment.

Modified p. 32 → 41

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

<Report Findings Here> Supporting documentation reviewed: <Report Findings Here>

Modified p. 33 → 44

• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 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 for non-PCI payment brand account/card data.

- Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 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 for non-PCI payment brand account/card data.

Modified p. 34 → 45

• Description and justification for the functionality

- Description and justification for the functionality

Modified p. 34 → 45

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

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

Modified p. 34 → 45

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

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

Modified p. 36 → 47

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

• Changes to any security-sensitive configurations <Report Findings Here>

Modified p. 37 → 49

Documented procedures reviewed: <Report Findings Here> ~~4C-1.3.1 Checking for incoming clear-text account data.~~

Documented procedures reviewed: <Report Findings Here>

Modified p. 38 → 50

Personnel interviewed: <Report Findings Here> ~~4C-1.3.3 Detecting and reviewing any unexpected transaction data received.~~

Personnel interviewed: <Report Findings Here>

Modified p. 38 → 51

Describe how the implemented processes observed verified that controls are in place to detect and review ~~and~~ unexpected transaction data received:

Describe how the implemented processes observed verified that controls are in place to detect and review any unexpected transaction data received:

Modified p. 39 → 51

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

Personnel interviewed: <Report Findings Here>

Modified p. 40 → 53

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

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

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

<Report Findings Here> 4D-1.2 The Host System must be isolated, or dedicated, to processing payment transactions, with only necessary services, protocols, daemons etc. enabled:

Modified p. 41 → 55

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

Responsible personnel interviewed: <Report Findings Here> Solution provider documentation reviewed: <Report Findings Here> 4D-1.1.c Review the solution provider documentation that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems, to verify that it accurately represents the decryption environment.

Modified p. 41 → 55

Solution provider documentation reviewed:

Solution provider documentation reviewed: <Report Findings Here>

Removed p. 42

<Report Findings Here> 4D-1.4 All application software installed on the Host System must be authorized and have a business justification.

Removed p. 43

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

Modified p. 43 → 58

Personnel interviewed: <Report Findings Here> Describe how logs/audit trails verified that the Host System performs a self-test to ensure its integrity before use and that the self-tests included the tests described in ~~4D- 1.6.a:~~

Personnel interviewed: <Report Findings Here> Describe how logs/audit trails verified that the Host System performs a self-test to ensure its integrity before use and that the self-tests included the tests described in 4D-1.6.a:

Removed p. 44

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

Removed p. 46

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

Modified p. 46 → 61

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

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

Modified p. 46 → 62

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

• During diagnostics of cryptographic operations <Report Findings Here>

Modified p. 48 → 64

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

• core dumps of memory required for trouble-shooting <Report Findings Here>

Removed p. 49

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

<Report Findings Here> 4D-1.14.5 All files must be securely deleted in accordance with industry-accepted standards for secure deletion of data:

Removed p. 50

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

• Have equivalent strength/complexity.

Modified p. 50 → 68

• Consist of a combination of numeric, alphabetic, and special characters, or

• Consist of a combination of numeric, alphabetic, and special characters, or Have equivalent strength/complexity.

Modified p. 52 → 70

Sample of users for each role interviewed:

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

Removed p. 53

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

Modified p. 53 → 71

<Report Findings Here> Describe how the observation of the Host System administrator verified 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:

Modified p. 54 → 73

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

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

Modified p. 55 → 73

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

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

Modified p. 56 → 75

4D-3.5 Verify that non-console access to the Host System is only permitted from a PCI DSS compliant environment, including 4D-3.5.1 through ~~4D-3.5.2~~ Review solution provider documentation, including data-flow diagrams, and perform the following:

4D-3.5 Verify that non-console access to the Host System is only permitted from a PCI DSS compliant environment, including 4D-3.5.1 through 4D- 3.5.2 Review solution provider documentation, including data-flow diagrams, and perform the following:

Removed p. 57

<Report Findings Here> 4D-3.7 Non-console sessions to the Host System must be terminated after 15 minutes of inactivity.

Modified p. 57 → 76

<Report Findings Here> Describe how the sample of access control records compared to Host System settings verified that non-console access to the Host System is only provided to authorized users:

Sample of access control records reviewed: <Report Findings Here> Describe how the sample of access control records compared to Host System settings verified that non-console access to the Host System is only provided to authorized users:

Removed p. 58

<Report Findings Here> 4D-4.3 All physical access to the secure room must be monitored and logs must be maintained as follows:

Modified p. 59 → 79

Responsible personnel interviewed: <Report Findings Here> ~~4D-4.4 Dual access must be required for the secure room housing the Host System.~~

Responsible personnel interviewed: <Report Findings Here>

Removed p. 60

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

Modified p. 60 → 80

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

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

Modified p. 60 → 81

~~• Access to the Host System and HSM(s)~~ Note: Motion-activated systems that are separate from the intrusion-detection system may be used.

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

Modified p. 60 → 81

• Access to the Host System and HSM(s) Sample of CCTV recordings reviewed:

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

Removed p. 61

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

<Report Findings Here> 4D-4.10 Continuous or motion-activated, appropriate lighting must be provided for the cameras.

Modified p. 61 → 81

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

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:

Modified p. 61 → 82

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

Sample of CCTV recordings reviewed: <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.

Removed p. 62

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

Modified p. 63 → 84

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

Modified p. 64 → 85

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

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

Modified p. 64 → 86

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

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

Modified p. 64 → 86

Responsible personnel interviewed: <Report Findings Here> Records of synchronization examined:

Responsible personnel interviewed: <Report Findings Here> Records of synchronization examined: <Report Findings Here> 4D-4.19.1.b Examine records of the synchronization process to verify that documentation is retained for at least one year.

Removed p. 65

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

Modified p. 65 → 86

Records of synchronization examined:

Records of synchronization examined: <Report Findings Here>

Modified p. 67 → 89

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

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

Modified p. 67 → 90

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

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

Modified p. 67 → 90

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

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 FIPS 140-3 certificate (i.e., the FIPS 140 HSM certificates must not be listed as historical or revoked).

Removed p. 68

<Report Findings Here> 1-4 The approval listing must match the deployed devices in the following characteristics:

<Report Findings Here> Requirements 2, 3 and 4 are not used in P2PE.

Modified p. 68 → 90

• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 or 140-3 Level 3, or higher. Refer to http://csrc.nist.gov.

• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 or FIPS 140-3 Level 3, or higher. Refer to http://csrc.nist.gov.

Modified p. 68 → 90

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

<Report Findings Here> 6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the area during ~~key-generation~~ processes where clear-text keying material is in use. It must not be feasible to observe any clear-text keying material either directly or via camera monitoring.

<Report Findings Here> 6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the area during key- generation processes where clear-text keying material is in use. It must not be feasible to observe any clear-text keying material either directly or via camera monitoring.

Modified p. 73 → 98

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

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

Modified p. 73 → 98

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.

SCDs used for key generation must meet Requirement 5-1. 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.

Removed p. 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 are used only under dual control and only within a secure room that meets the requirements of 32-9; and

Modified p. 74 → 99

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

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

Modified p. 74 → 99

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.

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

Modified p. 74 → 99

Printers used for this purpose must not be used for other purposes, must not be networked (i.e., locally ~~connected),~~ and must be managed under dual ~~control, including use of~~ a secure room that meets the ~~requirements of 32-9.~~

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

Modified p. 74 → 99

• Tampering can be ~~visually~~ detected.

• Tampering can be detected.

Modified p. 74 → 100

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

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

Modified p. 74 → 100

• Printers are not ~~networked.~~

• Printers are not networked; and

Modified p. 74 → 100

Describe how processes observed for printing key components verified ~~that key components are printed within blind mailers or sealed immediately after printing, such that no one but~~ the ~~authorized custodian ever has physical access to~~ the ~~output:~~

Describe how processes observed for printing key components verified the criteria in the test procedure:

Removed p. 75

Describe how the blind mailers or other sealed containers used for key components observed verified that tampering can be visually detected:

Modified p. 75 → 105

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

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

Removed p. 76

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

Modified p. 76 → 106

<Report Findings Here> ~~6-5 Asymmetric-key pairs must either be:~~

Modified p. 76 → 107

• If generated externally, the key pair and all related critical security parameters are

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

Modified p. 77 → 108

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

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

Removed p. 79

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

Modified p. 80 → 112

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

- They define how the details of the package serial number are to be transmitted. - There is a requirement that the package serial number is to be sent separately from the package itself. - Each component is to be sent to/from only the custodian(s) authorized for the component.

Modified p. 80 → 112

• Confirm through observation, interview, and inspection of the records of past key transfers that the process used to transport clear-text key ~~components using pre-numbered, tamper-evident, authenticable packaging, is sufficient to ensure:~~

• Confirm through observation, interview, and inspection of the records of past key transfers that the process used to transport clear-text key Documented procedures reviewed:

Removed p. 81

<Report Findings Here> 8-1.d Where an SCD is conveyed with pre-loaded secret and/or private keys, perform the following:

Modified p. 81 → 115

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 …

Removed p. 84

<Report Findings Here> 8-4 Public keys must be conveyed in a manner that protects their integrity and authenticity.

Modified p. 85 → 119

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

<Report Findings Here> Responsible personnel interviewed: <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. 87 → 121

<Report Findings Here> 9-2.d Interview responsible personnel and observe processes to verify that if a package shows signs of tampering indicating a component was potentially compromised, processes are implemented to identify the tampering, report/escalate it, ~~and~~ ultimately result in the destruction and replacement of both:

<Report Findings Here> 9-2.d Interview responsible personnel and observe processes to verify that if a package shows signs of tampering indicating a component was potentially compromised, processes are implemented to identify the tampering, report/escalate it, and, if compromise is confirmed, ultimately result in the destruction and replacement of both:

Modified p. 87 → 121

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

• Any keys encrypted under this (combined) key <Report Findings Here> 9-2.e Examine records related to any escalated transmittal events. Verify that if compromise is confirmed it resulted in the destruction and replacement of both:

Removed p. 88

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

Modified p. 91 → 125

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

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

Modified p. 92 → 127

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

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

Removed p. 94

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

Removed p. 97

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

Modified p. 97 → 132

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.

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

Modified p. 99 → 134

<Report Findings Here> 12-9 Not used in DMS ~~13-1 Clear-text secret and private keys and key components must be transferred into an SCD only when it can be ensured that:~~

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

Modified p. 100 → 135

- SCDs are inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading. - An SCD transfers a plaintext secret or private key only when at least two authorized individuals are identified by the device. - There is not any mechanism at the interface (including cabling) between the conveyance medium and the SCD that might disclose the transferred keys. - The SCD is inspected to ensure it has not been subject to any …

- SCDs are inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading. - An SCD transfers a plaintext secret or private key only when at least two authorized individuals are identified by the device.

Modified p. 103 → 140

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

<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. 103 → 140

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.

Key-injection personnel interviewed: <Report Findings Here> Logs examined: <Report Findings Here>

Modified p. 104 → 142

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

<Report Findings Here> 13-9 Not used in DMS 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 …

Removed p. 105

• Effective 1 January 2023, the same restriction applies to entities engaged in key injection of devices for which they are the processors.

Modified p. 106 → 143

<Report Findings Here> 14-3 Key-loading equipment usage must be ~~monitored~~ and a log of all key-loading and application-signing activities maintained for audit ~~purposes, containing~~ at a ~~minimum~~ date, time, personnel involved, and the number of devices keys are loaded to.

<Report Findings Here> 14-3 Key-loading equipment usage must be monitored, and a log of all key-loading and application-signing activities maintained for audit purposes must contain, at a minimum, date, time, personnel involved, and the number of devices keys are loaded to.

Modified p. 107 → 145

Note: Check values are computed by encrypting an ~~all-zero~~ block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). ~~Either this~~ method ~~must be used for TDEA or TDEA must use, and AES must use a technique where~~ the KCV is calculated by MACing an ~~all-zero~~ block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP 800-38B). The …

Note: Check values may be computed by two methods. TDEA may use either method. AES must only use the CMAC method. In the first method, check values are computed by encrypting an all binary zeros block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). In the second method the KCV is calculated by MACing an all binary zeros block using the …

Modified p. 108 → 146

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

<Report Findings Here> 15-3 Not used in DMS 15-4 Not used in DMS 15-5 Not used in DMS

Modified p. 108 → 147

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

16-1.a Verify documented procedures exist for all key-loading operations. Documented procedures reviewed: <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. 112 → 150

• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 ~~June 2021.~~

• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 January 2023.

Modified p. 112 → 150

• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 ~~June 2023.~~

• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 January 2025.

Modified p. 112 → 150

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

• 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. 113 → 151

<Report Findings Here> ~~19-2 Private keys:~~

Modified p. 113 → 152

• Must be used only for a single purpose

•a private key must only be used for either decryption or for creating digital signatures, but not both (except for ~~transaction- originating~~ POI devices).

• Must be used only for a single purpose

•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices).

Removed p. 114

<Report Findings Here> 19-4 Keys must never be shared or substituted between production and test/development systems:

Modified p. 116 → 155

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.

This means that not only the account-data-encryption key(s), but also keys that are used to protect other keys: firmware- authentication keys, payment application authentication, and display prompt control keys. As stated in the requirement, this does not apply to public keys resident in the device.

Modified p. 118 → 157

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.

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. 119 → 158

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

<Report Findings Here> 20-5 Not used in DMS 20-6 Not used in DMS

Removed p. 120

<Report Findings Here> 21-2.3 Each key component/share must have one or more specified authorized custodians.

Modified p. 122 → 161

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.

Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here>

Modified p. 123 → 163

<Report Findings Here> 21-4 Not used in DMS ~~22-1 Procedures for known or suspected compromised keys must include the following:~~

<Report Findings Here> 21-4 Not used in DMS

Removed p. 124

<Report Findings Here> 22-1.3 A secret or private cryptographic key must be

Modified p. 124 → 165

Note: The compromise of a key must result in the replacement and destruction of that key and all variants and ~~non-reversible~~ transformations of that key, as well as all keys encrypted under or derived from that key.

Note: The compromise of a key must result in the replacement and destruction of that key and all variants and non- reversible transformations of that key, as well as all keys encrypted under or derived from that key.

Removed p. 125

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

Modified p. 126 → 168

<Report Findings Here> 22-3 Not used in DMS

<Report Findings Here> 22-3 Not used in DMS 22-4 Not used in DMS 22-5 Not used in DMS

Modified p. 127 → 169

Note: Exposure of keys that are created using reversible transforms of another (key-generation) key can result in the exposure of all keys that have been generated under that key-generation key. To limit this risk posed by reversible key calculation, such as key variants, the reversible transforms of a key must be secured in the same way as the original ~~key-generation~~ key.

Note: Exposure of keys that are created using reversible transforms of another (key-generation) key can result in the exposure of all keys that have been generated under that key-generation key. To limit this risk posed by reversible key calculation, such as key variants, the reversible transforms of a key must be secured in the same way as the original key- generation key.

Modified p. 128 → 171

Note: Using transformations of keys across different levels of a key hierarchy

•e.g., generating a DEK from a ~~key-encrypting~~ key

•increases the risk of exposure of each of those keys.

Note: Using transformations of keys across different levels of a key hierarchy

•e.g., generating a DEK from a key- encrypting key

•increases the risk of exposure of each of those keys.

Modified p. 128 → 171

It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single ~~key- encrypting~~ key. However, it is not acceptable to generate working keys from key-encrypting keys.

It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single key-encrypting key. However, it is not acceptable to generate working keys from key-encrypting keys.

Modified p. 128 → 172

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

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 responsible personnel and examine key-history logs and key-destruction logs to verify that all keys have been destroyed.

Modified p. 129 → 172

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.

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

Modified p. 129 → 173

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

<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. 130 → 173

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

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>

Modified p. 130 → 174

The third-party witness must sign an affidavit of ~~destruction.~~

The third-party witness must sign an affidavit of destruction, and this affidavit is retained for a minimum of two years.

Removed p. 131

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

Modified p. 131 → 175

Completed key-custodian forms reviewed:

Completed key-custodian forms reviewed: <Report Findings Here>

Modified p. 131 → 175

<Report Findings Here> 25-1.2.b Examine completed key-custodian forms to verify that backup custodians sign the form.

Completed key-custodian forms reviewed: <Report Findings Here> 25-1.2.b Examine completed key-custodian forms to verify that backup custodians sign the form.

Modified p. 131 → 176

• Signature of management authorizing the access

• Signature of management authorizing the access 25-1.3 Examine all key-custodian forms to verify that they include the following:

Modified p. 132 → 176

• Signature of management authorizing the access Completed key-custodian forms reviewed:

• Signature of management authorizing the access Completed key-custodian forms reviewed: <Report Findings Here>

Modified p. 132 → 177

For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized ~~secret- sharing~~ scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to form the key must not report to the same individual.

For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to form the key must not report to the same individual.

Modified p. 132 → 177

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.

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. 132 → 177

<Report Findings Here> Documented organization charts reviewed:

<Report Findings Here> Documented organization charts reviewed: <Report Findings Here>

Modified p. 133 → 178

Documented procedures reviewed: <Report Findings Here> 25-2 Not used in DMS 25-3 Not used in DMS 25-4 Not used in DMS 25-5 Not used in DMS 25-6 Not used in DMS 25-7 Not used in DMS 25-8 Not used in DMS 25-9 Not used in DMS ~~26-1 Logs must be kept whenever keys, key components, or related materials are removed from secure storage or loaded to an SCD. These logs must be archived for a minimum of two years subsequent …~~

Documented procedures reviewed: <Report Findings Here> 25-2 Not used in DMS 25-3 Not used in DMS 25-4 Not used in DMS 25-5 Not used in DMS 25-6 Not used in DMS 25-7 Not used in DMS 25-8 Not used in DMS 25-9 Not used in DMS

Modified p. 133 → 179

• Tamper-evident package number (if applicable)

• Tamper-evident package number (if applicable) 26-1.a Interview responsible personnel and examine documented procedures to determine the following:

Modified p. 134 → 180

• ~~Loaded to an SCD~~ <Report Findings Here> ~~26-1.b~~ Examine log files and audit log settings to verify that logs include the following:

• Securely stored Log files reviewed: <Report Findings Here> 26-1.d Examine log files and audit log settings to verify that logs include the following:

Modified p. 134 → 180

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.

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

• Management of personnel changes, including revocation of access control and other privileges when personnel move

• Management of personnel changes, including revocation of access control and other privileges when personnel move 28-1.a Examine documented procedures for key-administration operations to verify they include:

Modified p. 136 → 182

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.

Responsible HR personnel interviewed: <Report Findings Here> 28-2 Not used in DMS 28-3 Not used in DMS 28-4 Not used in DMS 28-5 Not used in DMS

Modified p. 137 → 186

<Report Findings Here> ~~29-3~~ Not used in DMS

<Report Findings Here> 29-2 Not used in DMS

Removed p. 138

• Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and

• Can be verified by the initial key-loading facility, but that cannot feasibly be determined by unauthorized personnel.

• Controls exist and are in use to ensure that all physical and logical controls and anti-tamper mechanisms used are not modified or removed.

Modified p. 138 → 187

• Transportation uses a trusted courier service (e.g., via bonded carrier). The devices are then securely stored until ~~key-insertion~~ occurs.

• Transportation uses a trusted courier service (e.g., via bonded carrier). The devices are then securely stored until key- insertion occurs.

Modified p. 138 → 187

• A secret, device-unique “transport-protection token” is loaded into the secure storage area of each device at the manufacturer’s facility. The SCD used for ~~key- insertion~~ verifies the presence of the correct “transport-protection token” before overwriting this value with the initial key, and the device is further protected until deployment.

• A secret, device-unique “transport-protection token” is loaded into the secure storage area of each device at the manufacturer’s facility. The SCD used for key-insertion verifies the presence of the correct “transport-protection token” before overwriting this value with the initial key, and the device is further protected until deployment.

Modified p. 138 → 187

• Each cryptographic device is carefully inspected and tested immediately prior to key-insertion and deployment using due diligence. This is done to provide reasonable assurance that it is the legitimate device and that it has not been subject to any unauthorized modifications.

• Shipped and stored containing a secret that: o Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and o Can be verified by the initial key-loading facility, but that cannot feasibly be determined by unauthorized personnel.

• Each cryptographic device is carefully inspected and tested immediately prior to key-insertion and deployment using due diligence. This is done to provide reasonable assurance that it is the legitimate device and that it has not been …

Modified p. 138 → 187

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

Note: Unauthorized access includes that by customs officials. o Devices incorporate self-tests to ensure their correct operation. Devices must not be re-installed unless there is assurance they have not been tampered with or compromised. (Note: this control must be used in conjunction with one of the other methods.) o Controls exist and are in use to ensure that all physical and logical controls and anti-tamper mechanisms used are not modified or removed.

Removed p. 139

• throughout their life cycle:

Modified p. 139 → 188

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

•throughout their life ~~cycle.~~

• both in service and spare or back-up devices

•throughout their life cycle:

Modified p. 139 → 188

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

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

Modified p. 140 → 189

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.

Documented procedures reviewed: <Report Findings Here>

Modified p. 140 → 190

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

<Report Findings Here> 29-4.4.2 Installing (or re-installing) devices only after confirming that the device has not been tampered with or compromised 29-4.4.2 Observe inspection processes and interview responsible personnel to verify that devices are installed, or reinstalled, only after confirming that the device has not been tampered with or compromised.

Removed p. 141

<Report Findings Here> 29-4.3.3 Physical and/or functional tests and visual inspection to confirm that physical and logical controls and anti-tamper mechanisms are not modified or removed 29-4.3.3 Observe inspection processes and interview responsible personnel to confirm 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. 141 → 190

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:

Responsible personnel interviewed: <Report Findings Here> 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. 142 → 192

• removed from service can retain cryptographic keys in ~~battery-backed~~ RAM for days or weeks. Likewise, host/hardware security modules (HSMs) can also retain keys

•and more critically, the Master File Key

•resident within these devices. Proactive key-removal procedures must be in place to delete all such keys from any SCD being

• removed from service can retain cryptographic keys in battery- backed RAM for days or weeks. Likewise, host/hardware security modules (HSMs) can also retain keys

•and more critically, the Master File Key

•resident within these devices. Proactive key-removal procedures must be in place to delete all such keys from any SCD being

Modified p. 143 → 193

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

Responsible personnel interviewed: <Report Findings Here> Device-return records examined: <Report Findings Here>

Modified p. 143 → 194

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

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

Modified p. 144 → 195

Documented records reviewed:

Documented records reviewed: <Report Findings Here>

Modified p. 144 → 196

Documented ~~key- management~~ policies and procedures examined:

Documented key-management policies and procedures examined:

Removed p. 145

<Report Findings Here> 5A-1.3.1 Maintain documentation of all cryptographic keys managed as part of the P2PE solution, including:

Modified p. 145 → 196

• 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. 145 → 196

Documented ~~key- management~~ procedures reviewed:

Documented key-management procedures reviewed:

Modified p. 145 → 197

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

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

Removed p. 146

<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. 146 → 198

• Key-destruction method Documented ~~key- management~~ policies and procedures examined:

• Key-destruction method Documented key-management policies and procedures examined:

Modified p. 146 → 198

• Key-destruction method Documentation reviewed:

• Key-destruction method Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here>

Modified p. 146 → 199

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22)

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

Modified p. 147 → 199

• 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. 147 → 199

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documentation reviewed:

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here>

Removed p. 148

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

Removed p. 150

<Report Findings Here> 5H-1.5.2 The encryption key must be unique for each Host System.

Document Comparison

From Revision History

Content Changes