Document Diff - PCI Watch

Added p. 2

July 2025 3.2 1.0 This template includes the following updates:

- Updates from the PCI P2PE Standard v3.2

- Updates based on stakeholder feedback

- Errata updates to section 4

Added p. 6

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

This applies for both P2PE Applications intended to be Listed, as well as P2PE Applications that are not intended to be Listed and are assessed only as part of, and allowed for use in, a specific P2PE Solution (Solution-specific P2PE Applications).

Note: Validation of a P2PE Application must be performed by a qualified P2PE Application Assessor Company.

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

Added p. 9

• Brief description/short answer

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

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

P2PE Assessor Company and Lead Assessor Contact Information Company name: Assessor company credentials: P2PE Assessor P2PE Application Assessor Assessor name: Assessor credentials: P2PE Assessor P2PE Application Assessor Assessor phone number: Assessor e-mail address:

QA Primary reviewer phone number:

QA Primary reviewer e-mail address:

• Disclose all services offered to the assessed entity by the P2PE Assessor / P2PE Assessor 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 P2PE Assessor company, or to which the P2PE Assessor company owns the rights or that the P2PE Assessor company has configured or manages:

Added p. 20

• Locations of critical facilities

• Location of systems performing decryption management functions

• Flows and locations of encrypted account data

• Flows and locations of cleartext account data

• Flows and locations of truncated account data

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

• Key Archiving (if applicable)

• Any other relevant information

Added p. 34

The Assessor may use the reference number throughout the reporting section, rather than providing a narrative for each N/A requirement.

Added p. 36

Documented procedure examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here>

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

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

Note: The intent is to ensure the decryption environment can authenticate each unique PTS POI device within a P2PE solution with which it is communicating. This authentication can occur via use of cryptographic keys or certificates, uniquely associated with each PTS POI device and decryption system.

• Capable of detecting tampering or modification

• Conducted by authorized personnel

• Conducted at least quarterly 4B-1.5.a Examine documented procedures, interview personnel, and observe inspections (as needed) to verify:

• Inspections performed are capable of detecting tampering or modification of HSMs used for decryption operations and related processes

• …

Added p. 45

• Changes to cryptographic-related functions

Added p. 54

<Report Findings Here> 4D-1.3 The Host System and HSM must, at a minimum:

• Utilize a secure connection between them

• Utilize a secure connection between them

• Reside within the same CDE as defined in PCI DSS

• Reside within the same CDE as defined in PCI DSS

• Be dedicated to decryption operations and transaction processing in support of a P2PE Solution 4D-1.3.a Examine documentation / network diagrams to verify the Host System(s) and HSM(s), at a minimum:

• Be dedicated to decryption operations and transaction processing in support of a P2PE Solution Documentation / network diagrams examined:

<Report Findings Here> 4D-1.3.b Examine and/or observe network and system configurations to verify 4D1.3.a.

Added p. 62

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

Added p. 65

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

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

Added p. 70

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

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

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

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

Added p. 74

Sample of access control records examined:

Added p. 81

• It is connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room Describe how the physical intrusion-detection system verified that it:

Added p. 85

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

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

Added p. 86

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

• 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/component provider has applied a vendor security patch resulting in an

Added p. 89

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

• updated HSM firmware version, and the PCI SSC or NIST acceptance of that

• updated firmware version has not yet been completed, obtain and examine the vendor documentation and verify it includes confirmation that the update has been submitted for evaluation per the process specified by PCI SSC or NIST (as applicable to the HSM).

Identify the P2PE Assessor who confirms this requirement is in place.

Added p. 95

<Report Findings Here> 6-2.c Where single-purpose computers with an installed SCD or a modified PED are used, examine, observe, and interview as needed to verify that clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device).

Added p. 96

The following sub-requirements are applicable to the printing of key components:

Describe how the interviews performed and processes observed verified that the requirement is satisfied:

Added p. 102

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

Added p. 108

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

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

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.

Added p. 113

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

Added p. 119

• Observe the method used to transport cleartext key components using tamper-evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself

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

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

12-1.a Examine documented procedures, interview personnel, and observe processes as needed to verify the requirement is satisfied for all applicable keys.

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

Describe how the review of …

Added p. 131

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

Added p. 137

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

• Any resources (e.g., passwords/authentication codes and associated hardware) used in the key-loading function must be controlled and managed such that no single individual has the capability to enable key loading of cleartext keys or their components Documented procedures examined: <Report Findings Here> 14-1.b Observe key-loading environments and controls to verify the following:

• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control Describe the observation of key-loading environments and controls and how they verified that:

• All resources (e.g., passwords/authentication codes and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading <Report Findings Here> 14-2 All cable attachments over which cleartext keying material traverses must be examined at the …

Added p. 139

Documented procedures examined: <Report Findings Here> 14-4.b Examine/observe locations and controls for physical tokens to verify that tokens used to enable key loading are not in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control.

Access-control logs examined: <Report Findings Here> 14-4.e Examine documented procedures, interview personnel, and observe processes as needed to reconcile storage contents to access-control logs.

Added p. 142

16-1.a Examine documented procedures and verify they exist for all key- loading operations.

Added p. 145

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

Added p. 156

Identify the P2PE Assessor who confirms that cleartext key components to verify they do not exist in non-secure containers, such as databases or in software programs:

Added p. 164

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

Added p. 167

• 9564 or ISO

•11568.

Added p. 175

• All requirements applicable for the original keys also apply to any backup copies of keys and their components Responsible personnel interviewed: <Report Findings Here> Describe how the backup processes observed verified that:

Added p. 179

Sample of PTS POI device types and other SCDs examined:

Added p. 182

Note: Dual-control mechanisms can include any manner of physical and/or logical means that satisfies the objective.

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

Note: Examples of sensitive functions include but are not limited to: loading of key components, outputting cleartext key components, and altering HSM configuration.

29-4.3 Examine HSM configurations and observe processes to verify that HSMs are not enabled in a sensitive state when connected to online systems.

Describe how the HSM configurations examined and processes observed verified that HSMs are not enabled in a sensitive state when connected to online systems.

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

Added p. 196

• The master key used to generate the DDK is dedicated to generating DDKs Describe how the key-generation processes observed verified that:

Added p. 200

Note: This section (5I-1.1) is ONLY applicable for P2PE component providers undergoing an assessment for subsequent PCI listing of the component provider’s Encryption Management Services. This section is not applicable to, and does not need to be completed by, P2PE solution providers.

5I-1.1 Track status of the deployed key-management services for PTS POI devices and HSMs, and provide reports to solution provider annually and upon significant changes, including at least the following:

• Types/models of PTS POI devices and/or HSMs for which keys have been injected

• For each type/model of PTS POI device and/or HSM: o Number of devices o Type of key(s) injected o Key-distribution method

• Details of any known or suspected compromised keys, per 22-1

Note: Adding, changing, or removing PTS POI devices and/or HSM types, or critical key-management methods may require Delta Change. Please refer to the PCI P2PE Program Guide for details about obligations when adding, changing, or removing …

Added p. 201

• Types/models of POIs for which keys have been injected

• For each type/model of POI: o Number of POI devices o Type of key injected o Key-distribution method

• Details of any known or suspected compromised keys, per 22-1 Solution provider reports reviewed: <Report Findings Here>

Modified p. 1

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

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

Modified p. 5

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

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

Modified p. 5

Solution Assessments: Use of this Reporting Template is mandatory for all P2PE ~~v3.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).

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

Modified p. 5

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

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

Removed p. 6

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.

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 key management service that has not already been assessed as part of the inclusion of a Validated P2PE Component Provider and/or as part of the Domain 1 and Domain 4 assessment scope of the Solution assessment, …

Modified p. 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 ~~PTS-approved~~ 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 PCI-approved PTS POI devices in a P2PE Solution. Validation of P2PE Solutions that do not outsource the entirety of their Encryption Management Services to Listed P2PE Component Providers, either to an EMCP or to BOTH a PDCP AND a PMCP, must include this P-ROV in addition to a Solution P-ROV.

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

Validation of P2PE Solutions that do not outsource the entirety of their Decryption Management Services to a Listed DMCP must include this P-ROV in addition to a Solution P-ROV.

Modified p. 6

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

Validation of P2PE Component services provided by an EMCP, PDCP, or a PMCP must use this P- ROV.

Modified p. 6

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

P2PE Application P2PE Application Validation of a P2PE Application (software on the PCI-approved POI device intended for use in a P2PE Solution that has the potential to access cleartext cardholder data) must use this P-ROV.

Modified p. 6

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.

Decryption Management Services (DMS) P2PE Solution (SP) Decryption Management CP (DMCP) “Decryption Management Services” relates to the management of a decryption environment, including applicable devices (for example, HSMs) used to support a P2PE Solution.

Modified p. 6

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

Validation of P2PE Component services provided by a DMCP must use this P-ROV.

Modified p. 6

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

Key Management Services (KMS) P2PE 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 (POI devices, HSMs, etc.).

Modified p. 6 → 7

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

Validation of P2PE Component services provided by a KIF, KMCP, KLCP, and a CA/RA must complete this P-ROV.

Modified p. 7 → 8

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 …

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

Modified p. 7 → 9

Note: Checkboxes have been added to the “Summary of Assessment Findings” so that the ~~assessor~~ may ~~double click~~ to check the applicable summary result. Hover over the box ~~you’d like~~ to ~~mark~~ and ~~click once~~ to mark with an ‘x.’ To remove a mark, hover over the box and click again. Mac users may instead need to use the space bar to ~~add the mark.~~

Note: Checkboxes have been added to the “Summary of Assessment Findings” so that the Assessor may double-click to check the applicable summary result. Hover over the box to select and single-click to mark with an ‘x.’ To remove a mark, hover over the box and click again. Mac users may instead need to use the space bar to select a box.

Modified p. 8 → 9

“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. 8 → 9

Document name or interviewee reference At section 3.6, “Documentation Reviewed,” and section 3.7, “Individuals Interviewed,” there is a space for a reference number; it is the P2PE Assessor’s choice to use the document name/interviewee job title or the reference number in responses. A listing is sufficient here, no further detail 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. 8 → 9

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.

• 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. 8 → 9

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

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

Modified p. 9 → 10

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

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

Modified p. 9 → 10

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

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

Modified p. 9 → 10

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

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

Modified p. 9 → 10

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

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

Modified p. 9 → 10

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

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

Modified p. 9 → 10

Ensure all parts of the Testing Procedure are ~~addressed.~~

• Ensure all parts of the Testing Procedure are addressed

Modified p. 9 → 10

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

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

Modified p. 9 → 10

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

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

Provide useful, meaningful diagrams, as ~~directed.~~

• Provide useful, meaningful diagrams, as directed

Modified p. 9 → 10

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

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

Modified p. 9 → 10

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

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

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

Modified p. 9 → 10

Don’t copy responses from previous ~~assessments.~~

• Don’t copy responses from previous assessments

Modified p. 9 → 10

Don’t include information irrelevant to the ~~assessment.~~

• Don’t include information irrelevant to the assessment

Modified p. 9 → 10

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

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

Removed p. 10

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:

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

Modified p. 10 → 11

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

Internal P2PE Assessor Company QA Review Affirm that internal QA was fully performed on the entire P2PE submission.

Modified p. 10 → 11

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

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

Modified p. 10 → 11

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

Assessor name: Assessor credentials: P2PE Assessor P2PE Application Assessor Assessor phone number: Assessor e-mail address:

Removed p. 11

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. 11 → 12

(From DD-MMM-YYYY To DD-MMM-YYYY) 1.3 Additional Services Provided by ~~PA-QSA(P2PE) / QSA(P2PE)~~ / P2PE ~~QSA~~ Company The current version of the “Qualification Requirements for Point-to-Point Encryption (P2PE)TM ~~Qualified Security Assessors~~

• ~~QSA (P2PE)~~ and ~~PA-QSA (P2PE)”~~ (P2PE ~~QSA~~ Qualification Requirements), section ~~“Independence”~~ specifies requirements for P2PE ~~QSAs~~ around disclosure of such services and/or offerings that could reasonably be viewed to affect independence of assessment. Complete the sections below after review of this portion of the P2PE ~~QSA~~ Qualification Requirements to ensure …

(From DD-MMM-YYYY To DD-MMM-YYYY) 1.3 Additional Services Provided by P2PE Assessor / P2PE Assessor Company The current version of the “Qualification Requirements for Point-to-Point Encryption (P2PE)TM

• P2PE Assessor and P2PE Application Assessors” (P2PE Qualification Requirements), section “Independence”, specifies requirements for P2PE Assessors around disclosure of such services and/or offerings that could reasonably be viewed to affect independence of assessment. Complete the sections below after review of this portion of the P2PE Qualification Requirements to ensure responses are consistent with documented …

Modified p. 11 → 12

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

• Describe efforts made to ensure no conflict of interest resulted from the above mentioned services provided by the P2PE Assessor / P2PE Assessor company:

Modified p. 13 → 14

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

Modified p. 15 → 16

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

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

Modified p. 16 → 17

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

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

Modified p. 18 → 19

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

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

Modified p. 18 → 19

How the scope of the assessment was confirmed to be accurate and to cover all components and facilities for the 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:

Modified p. 19 → 20

~~Locations of critical facilities Location of systems performing decryption management functions~~ Other necessary components, as applicable to the Decryption Management Services Provide any additional information below that is not adequately captured within the diagram(s). Otherwise, check No Additional Details. No Additional Details <Additional Details, as needed> <Insert Decryption Management Services diagram(s) here>

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

Modified p. 20 → 21

Flows and locations of encrypted account data Flows and locations of clear-text account data Flows and locations of truncated account data Location of critical system components (e.g., HSMs, Host Systems) All entities to which the Decryption Management Services connects for payment transmission or processing, including processors/acquirers

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

Modified p. 21 → 22

~~Key Generation~~ Key Distribution / Loading / Injection activities ~~Key Storage Key Usage Key Archiving (if applicable) Any other relevant information~~

• Key Distribution / Loading / Injection activities

Modified p. 24 → 25

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

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

Modified p. 33 → 34

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

Reference # (optional use) Requirement Document how and why it was determined that the requirement is Not Applicable to the P2PE Product under assessment

Removed p. 34

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

• PCI PTS HSM approved.

4A-1.1.a For all HSMs used in the decryption environment, examine approval documentation (e.g., FIPS certification or PTS approval) and review the list of approved devices to verify that all HSMs used in the solution are either:

• 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 (overall), or higher. Refer to http://csrc.nist.gov.

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

Modified p. 34 → 35

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

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

Removed p. 35

• Model name and number

Removed p. 35

• Device firmware version number

• Device firmware version number

• 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

4A-1.1.1.a For all PCI-approved HSMs used in the solution, examine HSM devices and review the PCI SSC list of Approved PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:

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

<Report Findings Here> 4A-1.1.1.b For all FIPS-approved HSMs used in the solution, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list …

Removed p. 36

• updated firmware version has not yet been completed, obtain the vendor documentation and verify it includes confirmation that the update has been submitted for evaluation per the process specified by PCI SSC or NIST (as applicable to the HSM).

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

Modified p. 36 → 35

~~Vendor documentation reviewed:~~ <Report Findings Here> 4A-1.1.2 If FIPS-approved HSMs are ~~used,~~ the HSM must use the FIPS-approved cryptographic primitives, data-protection mechanisms, and key-management processes for account data decryption and related processes.

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

Modified p. 36 → 35

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.

• Note that adding any software may invalidate the FIPS approval 4A-1.1.2.a Examine FIPS approval documentation 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. 36 → 35

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:

FIPS approval documentation examined: <Report Findings Here> HSM operational procedures examined: <Report Findings Here>

Removed p. 37

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

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

Modified p. 37 → 36

4A-1.1.3 Examine HSM configurations for all ~~P2PE solution functions~~ to verify that HSMs are configured to operate according to the security policy that was included as part of the PTS approval.

4A-1.1.3 Examine HSM configurations for all account-data decryption and related processes to verify that HSMs are configured to operate according to the security policy that was included as part of the PTS approval. In addition, examine the PCI approval listing(s) for any implementation- specific notes and if present, verify they are accounted for.

Modified p. 37 → 36

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

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

Modified p. 37 → 36

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

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

Modified p. 38 → 37

• Management of user interface

• Management of the user interface

Modified p. 38 → 37

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

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

Modified p. 39 → 38

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

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

Modified p. 39 → 38

Documented procedures and processes ~~reviewed:~~

Documented procedures and processes examined:

Removed p. 40

Note: This authentication can occur via use of cryptographic keys or certificates, uniquely associated with each POI device and decryption system. The intent is to ensure the decryption environment can authenticate each unique POI device within a P2PE solution communicating with it.

Modified p. 40 → 39

4B-1.4.a Examine documented policies and procedures to verify they require POI devices be authenticated upon connection to the decryption environment and upon request by the solution provider.

4B-1.4.a Examine documented policies and procedures to verify they require PTS POI devices be authenticated upon connection to the decryption environment and upon request by the solution provider.

Modified p. 40 → 39

<Report Findings Here> 4B-1.4.b ~~Verify~~ documented procedures are defined for the following:

<Report Findings Here> 4B-1.4.b Examine documented procedures are defined for the following:

Modified p. 40 → 39

• Procedures and/or mechanisms for authenticating POI devices upon connection to the decryption environment

• Procedures and/or mechanisms for authenticating PTS POI devices upon connection to the decryption environment

Modified p. 40 → 39

• Procedures and/or mechanisms for authenticating POI devices upon request by the solution provider Documented policies and procedures ~~reviewed:~~

• Procedures and/or mechanisms for authenticating PTS POI devices upon request by the solution provider Documented policies and procedures examined:

Modified p. 40 → 39

• POI devices are authenticated upon connection to the decryption environment.

• PTS POI devices are authenticated upon connection to the decryption environment.

Modified p. 40 → 39

• POI devices are authenticated upon request by the solution provider.

• PTS POI devices are authenticated upon request by the solution provider.

Modified p. 40 → 39

Responsible personnel interviewed: <Report Findings Here> Describe how sample device authentications verified that POI devices are authenticated upon connection to the decryption environment and upon request by the solution provider:

Responsible personnel interviewed: <Report Findings Here> Describe how sample device authentications verified that PTS POI devices are authenticated upon connection to the decryption environment and upon request by the solution provider:

Removed p. 41

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

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

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

<Report Findings Here> 4B-1.5.c Interview personnel performing inspections and review supporting documentation to verify that inspections are performed at least quarterly.

Personnel performing inspections interviewed:

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

Modified p. 42 → 41

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

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

Modified p. 42 → 41

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

4B-1.6.a Examine the current PCI DSS Report on Compliance (ROC) to verify the PCI DSS assessment scope fully covers the P2PE decryption environment.

Modified p. 42 → 41

PCI DSS Report on Compliance (ROC) ~~reviewed:~~

PCI DSS Report on Compliance (ROC) examined:

Modified p. 42 → 41

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

<Report Findings Here> 4B-1.6.b Examine the PCI DSS ROC and/or AOC to verify that all applicable PCI DSS requirements are “in place” for the P2PE decryption environment.

Modified p. 42 → 41

PCI DSS Report on Compliance (ROC) and/or Attestation of Compliance (AOC) ~~reviewed:~~

PCI DSS Report on Compliance (ROC) and/or Attestation of Compliance (AOC) examined:

Modified p. 42 → 41

PCI DSS Report on Compliance (ROC) and/or Attestation of Compliance (AOC) ~~reviewed:~~

PCI DSS Report on Compliance (ROC) and/or Attestation of Compliance (AOC) examined:

Modified p. 42 → 41

<Report Findings Here> 4B-1.6.c ~~Review~~ PCI DSS ROC and/or ~~Attestation of Compliance (AOC)~~ to verify that the PCI DSS assessment of the P2PE decryption environment was:

<Report Findings Here> 4B-1.6.c Examine the PCI DSS ROC and/or AOC to verify that the PCI DSS assessment of the P2PE decryption environment was:

Modified p. 43 → 42

Note: Output of ~~clear-text~~ data that is verified as being unrelated to any of the PCI payment brands is acceptable. The security of this process when it occurs from the decryption environment is assessed at Requirement 4B-1.9.

Note: Output of cleartext data that is verified as being unrelated to any of the PCI payment brands is acceptable. The security of this process when it occurs from the decryption environment is assessed at Requirement 4B-1.9.

Modified p. 43 → 42

4B-1.7.a ~~Review~~ documented processes and interview personnel to confirm that ~~clear-text~~ account data is never sent back to the encryption environment.

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

Modified p. 43 → 42

Documented processes ~~reviewed:~~ <Report Findings Here> Personnel interviewed: <Report Findings Here> 4B-1.7.b Observe process flows and data flows to verify that there is no process, application, or other mechanism that sends ~~clear-text~~ account data back into the encryption environment.

Documented processes examined: <Report Findings Here> Personnel interviewed: <Report Findings Here> 4B-1.7.b Observe process flows and data flows to verify that there is no process, application, or other mechanism that sends cleartext account data back into the encryption environment.

Modified p. 43 → 42

Describe how process flows and data flows verified that there is no process, application, or other mechanism that sends ~~clear-text~~ account data back into the encryption environment:

Describe how process flows and data flows verified that there is no process, application, or other mechanism that sends cleartext account data back into the encryption environment:

Modified p. 43 → 42

<Report Findings Here> 4B-1.8 ~~Any~~ truncated PANs sent back to the encryption ~~environment~~ must adhere to the allowable number of ~~digits as specified in PCI DSS and/or related FAQs that specify allowable~~ digits.

<Report Findings Here> 4B-1.8 If the decryption environment allows for truncated PANs to be sent back to the encryption environment, they must adhere to the allowable number of digits.

Modified p. 43 → 42

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

4B-1.8.a Examine documented processes and interview personnel to confirm that any truncated PANs sent back to the encryption environment adhere to the allowable number of digits.

Modified p. 43 → 42

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

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

Modified p. 43 → 42

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

Describe how process flows and data flows verified that there is no process, application, or other mechanism that sends more digits of truncated PANs back to the encryption environment than is permitted:

Removed p. 44

Indicate whether any whitelisting functionality has been implemented within the decryption environment (yes/no).

<Report Findings Here> If “no”, describe how it was verified that no whitelisting functionality has been implemented within the decryption environment. (Leave 4B-1.9.1a to 4B-1.9.3 blank) <Report Findings Here> If “yes”, complete 4B-1.9.1.a to 4B-1.9.3:

Modified p. 44 → 43

- 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.a Examine documented policies and procedures to verify that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment ensures that the ONLY allowed output of cleartext account data is for non-PCI payment brand account/card data, and includes the following:

Removed p. 45

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

Modified p. 45 → 43

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

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

Modified p. 45 → 43

- Description and justification for the functionality

• Description and justification for the functionality

Modified p. 45 → 43

- 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-PCI payment brand account/card data Documented policies and procedures examined:

Modified p. 45 → 44

<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.c Perform test transactions to verify that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows output cleartext account for non- PCI payment brand account/card data.

Modified p. 45 → 44

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

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

Modified p. 46 → 44

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

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

Modified p. 46 → 44

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

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

Removed p. 47

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

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

Modified p. 47 → 45

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

• The documentation includes confirmation that it was reviewed prior to release to only output non-PCI payment account/card data Records of new whitelisting functionality examined:

Modified p. 47 → 45

4B-1.9.3 ~~Review~~ records of both new and updated whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment, and confirm the following:

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

Modified p. 47 → 45

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

• Both new installations and updates to whitelisting functionality are documented

Modified p. 47 → 45

• The documentation includes description and ~~justification.~~

• The documentation includes description and justification

Modified p. 47 → 45

• The documentation includes who approved it prior to ~~implementation.~~

• The documentation includes who approved it prior to implementation

Modified p. 47 → 45

Records of ~~new~~ whitelisting functionality ~~reviewed:~~

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

Modified p. 47 → 45

Note: Critical functions include but are not limited to application and firmware updates, ~~key-injection,~~ as well as changes to security-sensitive ~~configurations.~~

Note: Critical functions include but are not limited to application and firmware updates, cryptographic-related functions, as well as changes to security-sensitive configurations/settings.

Modified p. 47 → 45

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

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

Modified p. 47 → 45

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

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

Modified p. 48 → 46

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

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

Modified p. 49 → 47

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

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

Modified p. 49 → 47

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

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

Modified p. 49 → 47

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

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

Modified p. 50 → 48

4C-1.3.1.a Observe implemented processes to verify controls are in place to check for incoming ~~clear-text~~ account data.

4C-1.3.1.a Observe implemented processes to verify controls are in place to check for incoming cleartext account data.

Modified p. 50 → 48

Describe how the implemented processes observed verified that controls are in place to check for incoming ~~clear-text~~ account data:

Describe how the implemented processes observed verified that controls are in place to check for incoming cleartext account data:

Modified p. 50 → 48

<Report Findings Here> 4C-1.3.1.b Observe implemented controls and notification mechanisms to verify mechanisms detect and provide immediate notification upon detection of incoming ~~clear-text~~ account data.

<Report Findings Here> 4C-1.3.1.b Observe implemented controls and notification mechanisms to verify mechanisms detect and provide immediate notification upon detection of incoming cleartext account data.

Modified p. 50 → 48

Describe the implemented controls and notification mechanisms observed that detect and provide immediate notification upon detection of incoming ~~clear-text~~ account data:

Describe the implemented controls and notification mechanisms observed that detect and provide immediate notification upon detection of incoming cleartext account data:

Modified p. 50 → 48

<Report Findings Here> 4C-1.3.1.c Interview personnel to verify that designated personnel are immediately notified upon detection of incoming ~~clear-text~~ account data.

<Report Findings Here> 4C-1.3.1.c Interview personnel to verify that designated personnel are immediately notified upon detection of incoming cleartext account data.

Modified p. 50 → 48

Personnel interviewed: <Report Findings Here> 4C-1.3.2 Detecting and reviewing any cryptographic errors reported by the ~~HSM 4C-1.3.2.a Observe implemented processes to verify controls are in place to detect and review any cryptographic errors reported by the~~ HSM.

Personnel interviewed: <Report Findings Here> 4C-1.3.2 Detecting and reviewing any cryptographic errors reported by the HSM.

Removed p. 51

Personnel interviewed: <Report Findings Here> 4C-1.3.4 Reviewing data sent by any POI devices that are causing an unusually high rate of transaction authorization rejections.

4C-1.3.4.a Observe implemented processes to verify controls are in place to review data sent by any POI devices that are causing an unusually high rate of transaction authorization rejections.

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

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

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

<Report Findings Here> 4C-1.3.4.c Interview personnel …

Modified p. 52 → 50

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

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

Modified p. 54 → 52

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

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

Modified p. 55 → 53

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

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

Modified p. 55 → 53

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

Responsible personnel interviewed: <Report Findings Here> Documented procedure examined: <Report Findings Here> 4D-1.1.b Interview responsible personnel and examine solution provider documentation that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems within that environment, to verify that the document is current.

Modified p. 55 → 53

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.

Responsible personnel interviewed: <Report Findings Here> Solution provider documentation examined: <Report Findings Here> 4D-1.1.c Examine 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. 55 → 53

Solution provider documentation ~~reviewed:~~ <Report Findings Here>

Solution provider documentation examined: <Report Findings Here>

Removed p. 56

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

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

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

Modified p. 56 → 54

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

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

Modified p. 56 → 54

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

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

Modified p. 56 → 54

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

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

Modified p. 56 → 54

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

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

Modified p. 56 → 54

Describe how network and system configuration settings verified ~~that~~ the ~~Host System(s) and HSM(s) are located on a network that is segmented from other networks not required for decryption operations or transaction processing:~~

Describe how network and system configuration settings verified the requirements outlined in 4D-1.3.a:

Modified p. 57 → 55

Change control and system configuration records ~~reviewed:~~

Change control and system configuration records examined:

Modified p. 57 → 55

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

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

Modified p. 57 → 55

4D-1.5.a Examine documented policies and procedures to verify that a process is defined to prevent and/or detect and ~~alert,~~ any unauthorized changes to applications/software.

4D-1.5.a Examine documented policies and procedures to verify that a process is defined to prevent and/or detect and alert of any unauthorized changes to applications/software.

Removed p. 58

4D-1.6.a Inspect Host System configuration settings, and examine vendor/solution provider documentation to verify that the Host System performs a self-test when it is powered up to ensure its integrity before use. Verify the self-test includes the following:

Modified p. 58 → 56

• Testing integrity of cryptographic ~~functions.~~

• Testing integrity of cryptographic functions

Modified p. 58 → 56

• Testing integrity of ~~firmware.~~

• Testing integrity of firmware

Modified p. 58 → 56

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

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

Modified p. 58 → 56

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

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

Modified p. 59 → 57

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

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

Modified p. 59 → 57

Vendor/solution provider documentation ~~reviewed:~~

Vendor/solution provider documentation examined:

Modified p. 59 → 57

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

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

Modified p. 60 → 58

4D-1.8.a ~~Inspect~~ Host System configuration settings and ~~examine vendor/solution provider~~ documentation to verify that the host enters an error state and generates an alert in the event of the following:

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

Modified p. 60 → 58

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

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

Modified p. 61 → 59

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

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

Modified p. 61 → 59

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

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

Modified p. 61 → 59

Records of documented alert events ~~reviewed:~~

Records of documented alert events examined:

Modified p. 62 → 60

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

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

Modified p. 63 → 61

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

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

Modified p. 63 → 61

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

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

Modified p. 63 → 61

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

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

Modified p. 63 → 61

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

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

Modified p. 63 → 61

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

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

Modified p. 63 → 61

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

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

Modified p. 63 → 61

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

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

Modified p. 64 → 62

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

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

Modified p. 64 → 62

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

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

Modified p. 64 → 62

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

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

Modified p. 64 → 62

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

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

Modified p. 64 → 62

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

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

Modified p. 64 → 62

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

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

Modified p. 64 → 62

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

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

Modified p. 64 → 62

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

• core dumps of memory required for troubleshooting <Report Findings Here>

Modified p. 65 → 63

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

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

Modified p. 65 → 63

Host System configuration standards ~~reviewed:~~

Host System configuration standards examined:

Modified p. 65 → 63

<Report Findings Here> 4D-1.14.2 Storage ~~can~~ only be made to a dedicated hard drive (on its own bus) within the host.

<Report Findings Here> 4D-1.14.2 Storage must only be made to a dedicated hard drive (on its own bus) within the host.

Modified p. 66 → 64

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

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

Modified p. 66 → 64

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

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

Modified p. 66 → 64

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

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

Modified p. 66 → 64

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

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

Modified p. 66 → 64

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

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

Removed p. 67

Memory swap/page files must be securely deleted upon system shut down or reset.

4D-1.14.5.a Review documented procedures to verify that it defines a process for securely deleting swap/page files and core dumps at the required times:

• deleted upon system shut down or reset.

Modified p. 67 → 65

Core dumps must be securely deleted immediately after ~~analysis.~~

• Core dumps must be securely deleted immediately after analysis

Modified p. 67 → 65

• deleted immediately after ~~analysis.~~

• deleted immediately after analysis

Modified p. 67 → 65

Documented procedures ~~reviewed:~~ <Report Findings Here> 4D-1.14.5.b ~~Verify,~~ through the use of forensic tools and/or methods, that the secure procedure removes swap/page files and core dumps, in accordance with industry-accepted standards for secure deletion of data.

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

Modified p. 67 → 65

<Report Findings Here> 4D-2.1.b ~~Inspect~~ Host System configuration settings to verify that user password parameters are set to require users to change passwords at least every 30 days.

<Report Findings Here> 4D-2.1.b Examine Host System configuration settings to verify that user password parameters are set to require users to change passwords at least every 30 days.

Removed p. 68

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

• Consist of eight characters in length,

Documented policies and procedures reviewed:

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

Modified p. 68 → 66

• Have equivalent ~~strength/complexity.~~

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

Modified p. 68 → 66

• Have equivalent ~~strength/complexity.~~

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

Modified p. 68 → 66

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

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

Modified p. 68 → 66

• Have equivalent ~~strength/complexity.~~

• Have equivalent strength/complexity <Report Findings Here>

Modified p. 69 → 67

<Report Findings Here> 4D-2.4.b ~~Inspect~~ Host System configuration settings to verify that authentication parameters are set to require that a user’s account be locked out after not more than five invalid logon attempts.

<Report Findings Here> 4D-2.4.b Examine Host System configuration settings to verify that authentication parameters are set to require that a user’s account be locked out after not more than five invalid logon attempts.

Modified p. 70 → 68

• auditing of host functions Documented access-control procedures ~~reviewed:~~

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

Modified p. 70 → 68

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

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

Modified p. 70 → 68

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

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

Modified p. 71 → 69

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

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

Modified p. 71 → 69

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

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

Removed p. 72

Documented policies and procedures reviewed:

Removed p. 72

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

Modified p. 72 → 70

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

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

Modified p. 73 → 71

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

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

Modified p. 73 → 71

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 Examine Host System documentation to verify that tamper- detection mechanisms are defined for the Host System, including the generation of an alert upon opening of the Host System case, covers and/or doors.

Modified p. 73 → 71

Host System documentation ~~reviewed:~~ <Report Findings Here> 4D-2.9.b Observe tamper-detection mechanisms on the Host System to verify that a tamper-detection mechanism is implemented and includes the generation of an alert upon opening of the Host System case, covers and/or doors.

Host System documentation examined: <Report Findings Here> 4D-2.9.b Observe tamper-detection mechanisms on the Host System to verify that a tamper-detection mechanism is implemented and includes the generation of an alert upon opening of the Host System case, covers and/or doors.

Modified p. 73 → 71

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

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

Modified p. 73 → 71

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

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

Modified p. 74 → 72

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

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

Modified p. 74 → 72

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

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

Modified p. 74 → 72

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

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

Modified p. 74 → 72

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

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

Modified p. 75 → 73

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

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

Modified p. 75 → 73

Sample of systems ~~reviewed:~~ <Report Findings Here> Describe how device configurations for the sample of systems verified that non-console access is permitted only from the authorized systems:

Sample of systems examined: <Report Findings Here> Describe how device configurations for the sample of systems verified that non-console access is permitted only from the authorized systems:

Modified p. 75 → 73

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 Examine, Interview, Observe, and/or test as needed to 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. 76

• Meet all applicable PCI DSS requirements.

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

Modified p. 76 → 74

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

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

Modified p. 76 → 74

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

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

Modified p. 76 → 74

• Originate from and be managed by the solution ~~provider.~~

• Originate from and be managed by the solution provider

Modified p. 76 → 74

• Originate from and be managed by the solution ~~provider.~~

• Originate from and be managed by the solution provider

Modified p. 76 → 74

• Meet all applicable PCI DSS ~~requirements.~~

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

Modified p. 76 → 74

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

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

Modified p. 76 → 74

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

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

Modified p. 77 → 75

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

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

Modified p. 77 → 75

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

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

Modified p. 79 → 77

• Logs must be retained for a minimum of three ~~years.~~

• Logs must be retained for a minimum of three years

Modified p. 79 → 77

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

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

Modified p. 79 → 77

• Log reviews must be ~~documented.~~

• Log reviews must be documented

Modified p. 79 → 77

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

• Logs are retained for a minimum of three years

Modified p. 79 → 77

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

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

Modified p. 79 → 77

• Log reviews are ~~documented.~~

• Log reviews are documented

Modified p. 79 → 77

• Log reviews are ~~documented.~~

• Log reviews are documented

Modified p. 79 → 77

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

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

Modified p. 79 → 77

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

• Logs are being retained for a minimum of three years

Modified p. 79 → 77

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

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

Modified p. 79 → 77

• Logs are regularly ~~reviewed.~~

• Logs are regularly reviewed

Modified p. 79 → 77

• The person performing the review does not have access to the secure room or to the systems ~~therein.~~

• The person performing the review does not have access to the secure room or to the systems therein Responsible personnel interviewed: <Report Findings Here>

Modified p. 80 → 78

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

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

Modified p. 80 → 78

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

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

Modified p. 81 → 79

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

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

Modified p. 81 → 79

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

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

Modified p. 81 → 79

<Report Findings Here> 4D-4.7 Surveillance cameras must not be configured to allow the monitoring of computer screens, keyboards, PIN pads, or other systems ~~which~~ may expose sensitive data.

<Report Findings Here> 4D-4.7 Surveillance cameras must not be configured to allow the monitoring of computer screens, keyboards, PIN pads, or other systems that may expose sensitive data.

Modified p. 81 → 79

4D-4.7 Observe CCTV camera positioning and examine a sample of recordings to verify that CCTV cameras do not monitor any computer screens, PIN pads, keyboards, or other systems ~~which~~ may expose sensitive data.

4D-4.7 Observe CCTV camera positioning and examine a sample of recordings to verify that CCTV cameras do not monitor any computer screens, PIN pads, keyboards, or other systems that may expose sensitive data.

Modified p. 81 → 79

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:

Sample of CCTV recordings examined: <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 that may expose sensitive data:

Modified p. 82 → 80

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.

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

Modified p. 82 → 80

<Report Findings Here> 4D-4.9.b Examine access lists for the secure room as well as access controls to the media containing surveillance data, to verify that personnel with access to the secure room do not have access to the media containing recorded surveillance data Describe how access lists for the secure room as well as access controls to the media containing surveillance data verified that personnel with access to the secure room do not have access to the media containing recorded …

<Report Findings Here> 4D-4.9.b Examine access lists for the secure room as well as access controls to the media containing surveillance data, to verify that personnel with access to the secure room do not have access to the media containing recorded surveillance data.

Removed p. 83

Documented security policies and procedures reviewed:

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

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

Modified p. 83 → 81

• Continuous (24/7) physical intrusion-detection monitoring of the secure ~~room.~~

• Continuous (24/7) physical intrusion-detection monitoring of the secure room

Modified p. 83 → 81

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

• The physical intrusion-detection must be connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room Documented security policies and procedures examined:

Modified p. 84 → 82

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

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

Modified p. 85 → 83

Documented security policies and procedures ~~reviewed:~~

Documented security policies and procedures examined:

Modified p. 85 → 83

Documented security policies and procedures ~~reviewed:~~

Documented security policies and procedures examined:

Modified p. 85 → 83

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

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

Modified p. 86 → 84

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

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

Modified p. 86 → 84

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

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

Removed p. 87

• An airlock entrance system.

• An airlock entrance system.

Indicate for this submission, whether the vendor is a component provider. (yes/no).

Modified p. 87 → 85

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

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

Modified p. 87 → 85

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

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

Modified p. 87 → 85

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

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

Modified p. 87 → 85

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

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

Modified p. 87 → 86

~~<Report Findings Here> 4E-1.1 Determine whether,~~ for this submission, the vendor is a ~~component provider.~~

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

Modified p. 88 → 86

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

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

Modified p. 88 → 86

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

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

Modified p. 88 → 87

• Details of any suspicious activity that occurred, per 4C-1.2 Identify reports reviewed: <Report Findings Here>

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

Modified p. 89 → 87

• Addition and/or removal of HSM ~~types.~~

• Addition and/or removal of HSM types

Modified p. 89 → 87

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

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

Modified p. 89 → 87

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

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

Removed p. 90

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

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

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.

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

Modified p. 91 → 88

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

1-4.a For all PCI-approved HSMs used, examine HSM devices and the PCI SSC list of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:

Modified p. 91 → 89

• The PCI PTS ~~HSM~~ number

• The PCI PTS approval number

Modified p. 92 → 89

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

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

Modified p. 92 → 89

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

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

Removed p. 93

Documented key management policies and procedures reviewed:

Modified p. 93 → 90

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

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

Modified p. 93 → 90

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

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

Modified p. 93 → 90

• An approved key-generation function of a PCI

•approved HSM or POI device

• An approved key-generation function of a PCI

•approved HSM or PTS POI device

Modified p. 93 → 90

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

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

Modified p. 94 → 91

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

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

Modified p. 94 → 91

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

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

Modified p. 94 → 91

• Any key-generation process with ~~clear-text~~ output is performed under dual control

• Any key-generation process with cleartext output is performed under dual control

Modified p. 94 → 91

• Any output of a ~~clear-text~~ component or share is overseen by only the assigned key custodian(s) for that component/share

• Any output of a cleartext component or share is overseen by only the assigned key custodian(s) for that component/share

Modified p. 94 → 91

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

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

Modified p. 95 → 92

• Any key-generation process with ~~clear-text~~ output is performed under dual ~~control.~~

• Any key-generation process with cleartext output is performed under dual control

Modified p. 95 → 92

• Any output of ~~clear-text~~ component or share is overseen by only the assigned key custodian(s) for the ~~component/share.~~

• Any output of cleartext component or share is overseen by only the assigned key custodian(s) for the component/share

Modified p. 95 → 92

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

• Each custodian’s access to cleartext output is limited to the individual component(s)/share(s) assigned to that custodian and not the entire key Responsible personnel interviewed:

Modified p. 95 → 92

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

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

Modified p. 95 → 92

<Report Findings Here> Describe how the key-generations processes observed verified that there is no mechanism (including connectivity) that might disclose a ~~clear-text~~ key or key component between the key-generation device and the device or medium receiving the key or key component:

<Report Findings Here> Describe how the key-generations processes observed verified that there is no mechanism (including connectivity) that might disclose a cleartext key or key component between the key-generation device and the device or medium receiving the key or key component:

Modified p. 95 → 92

<Report Findings Here> 6-1.2 There must be no point in the key-generation process where a single individual has the ability to determine, obtain, or ascertain any part of a ~~clear-text~~ key or all the components for a key.

<Report Findings Here> 6-1.2 There must be no point in the key-generation process where a single individual has the ability to determine, obtain, or ascertain any part of a cleartext key or all the components for a key.

Modified p. 95 → 92

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

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

Modified p. 95 → 92

Describe how the end-to-end process verified that there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a ~~clear-text~~ key or all the components for a key:

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

Modified p. 95 → 92

• At least two individuals performed the key-generation ~~processes.~~

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

Modified p. 96 → 93

• Key-generation devices that generate ~~clear-text~~ key components are powered off when not in use or require re-authentication whenever key generation is invoked; or

• Key-generation devices that generate cleartext key components are powered off when not in use or require re-authentication whenever key generation is invoked; or

Modified p. 96 → 93

• If the device used for key generation is logically partitioned for concurrent use in other processes, the key-generation capabilities are enabled for execution of the procedure and disabled when the procedure is ~~complete.~~

• If the device used for key generation is logically partitioned for concurrent use in other processes, the key-generation capabilities are enabled for execution of the procedure and disabled when the procedure is complete Documented key-generation procedures examined:

Removed p. 97

Documented key-generation procedures reviewed:

Modified p. 97 → 94

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

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

Modified p. 97 → 94

<Report Findings Here> 6-1.4.b Observe key-generation set-up processes for all key types to verify that key-generation equipment is inspected prior to use, to ensure equipment does not show any signs of tampering. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a ~~clear-text~~ key or key component (e.g., a tapping device).

<Report Findings Here> 6-1.4.b Observe key-generation set-up processes for all key types to verify that key-generation equipment is inspected prior to use, to ensure equipment does not show any signs of tampering. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a cleartext key or key component (e.g., a tapping device).

Modified p. 97 → 94

<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 cleartext keying material is in use. It must not be feasible to observe any cleartext keying material either directly or via camera monitoring.

Modified p. 97 → 94

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

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

Modified p. 97 → 94

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

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

Removed p. 98

For example, it is not permitted for the cryptographic key to be passed through the memory of a computer unless it has been specifically tasked for the sole purpose of key generation/loading. Computers that have been specifically purposed and used solely for key generation/loading are permitted for use if all other requirements can be met, including those of Requirement 5 and the controls defined in Requirement 13.

Modified p. 98 → 95

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

Modified p. 98 → 95

Single-purpose computers with an installed SCD or a modified PED where clear keying material is injected directly from a secure port on the key-generating SCD to the target (e.g., a POI device) meet this requirement. ~~Where the components pass through memory of the PC, Requirement 13 must be met.~~

Single-purpose computers with an installed SCD or a modified PED where clear keying material is injected directly from a secure port on the key-generating SCD to the target (e.g., a POI device) meet this requirement.

Modified p. 98 → 95

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

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

Modified p. 98 → 95

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

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

Modified p. 98 → 95

Vendor documentation ~~reviewed~~ for each type of key:

Vendor documentation examined for each type of key:

Modified p. 98 → 95

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

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

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

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

<Report Findings Here> 6-3 Printed key components must be printed within blind mailers or sealed in tamper-evident and authenticable packaging immediately after printing or transcription to ensure that:

• Only approved key custodians can observe the key component.

• Only approved key custodians can observe the key component.

• Tampering can be visually detected.

• Tampering can be detected.

Modified p. 99 → 95

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

Describe how the single-purpose computers with an installed SCD verified that clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device).

Modified p. 99 → 96

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

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

Modified p. 99 → 96

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

Note: This requirement includes manual (handwritten) capture.

Modified p. 99 → 96

6-3.a Examine documented procedures for printed key components and verify ~~that they require printed key components to be printed within blind mailers or sealed in tamper-evident and authenticable packaging immediately after printing such that:~~

6-3.a Examine documented procedures for printed key components and verify the requirement is satisfied.

Modified p. 99 → 96

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

Documented procedures for printed key components examined:

Removed p. 100

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

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

• Printers are not networked; and

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

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

Modified p. 100 → 96

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

<Report Findings Here> 6-3.b Interview personnel and observe processes to verify the requirement is satisfied.

Modified p. 100 → 96

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

<Report Findings Here> 6-3.c REMOVED 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.

Modified p. 100 → 96

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.

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

Modified p. 100 → 96

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:

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 cleartext key components:

Modified p. 101 → 97

• Locked and protected by alarmed ~~sensors.~~

• Locked and protected by alarmed sensors

Modified p. 101 → 97

• Locked and protected by alarmed ~~sensors.~~

• Locked and protected by alarmed sensors

Modified p. 101 → 97

• Covered, rendered opaque, or positioned to prevent unauthorized observation of the secure ~~room.~~

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

Modified p. 101 → 97

• Covered, rendered opaque, or positioned to prevent unauthorized observation of the secure ~~room.~~

• Covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room <Report Findings Here> 6-3.2.b Examine configuration of window sensors to verify that the alarm mechanism is active.

Modified p. 102 → 98

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

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

Modified p. 102 → 98

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

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

Modified p. 102 → 98

6-3.4 ~~Inspect~~ CCTV configuration and examine a sample of recordings to verify that CCTV monitoring includes the ability to record events during dark periods, and verify that, if motion-activated, recording continues for at least a minute after the last pixel of activity subsides.

6-3.4 Examine CCTV configuration and examine a sample of recordings to verify that CCTV monitoring includes the ability to record events during dark periods, and verify that, if motion-activated, recording continues for at least a minute after the last pixel of activity subsides.

Modified p. 102 → 98

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

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

Removed p. 103

• Any equipment that is used.

• Any equipment that is used.

Modified p. 103 → 99

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.

6-3.5 Examine 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.

Modified p. 103 → 99

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

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

Modified p. 103 → 99

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.

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

Modified p. 103 → 99

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

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

Modified p. 103 → 99

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

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

Modified p. 103 → 99

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

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

Modified p. 103 → 99

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

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

Modified p. 103 → 99

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

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

Modified p. 103 → 99

• Any equipment that is ~~used.~~

• Any equipment that is used <Report Findings Here>

Modified p. 104 → 100

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.

6-3.8 Observe 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.

Modified p. 104 → 100

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

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

Modified p. 104 → 100

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

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

Modified p. 104 → 100

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

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

Modified p. 105 → 101

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

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

Modified p. 105 → 101

• Any residue that may contain ~~clear-text~~ keys or components is destroyed or securely

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

Removed p. 106

Describe how the destruction process of the identified key residue observed verified that any residue that may contain clear-text keys or components is destroyed or securely deleted immediately after generation and that the method of destruction is consistent with Requirement 24:

Modified p. 106 → 102

• Any residue that may contain ~~clear-text~~ keys or components is destroyed or securely deleted immediately after ~~generation.~~

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

Modified p. 106 → 102

• The method of destruction is consistent with Requirement ~~24.~~

• The method of destruction is consistent with Requirement 24

Modified p. 106 → 102

• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the ~~key.~~

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

Removed p. 107

Documented procedures for asymmetric-key generation reviewed:

Modified p. 107 → 103

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

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

Modified p. 107 → 103

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

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

Modified p. 107 → 103

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

• If generated externally, the key pair and all related critical security parameters are deleted (e.g., zeroized) immediately after the transfer to the device that will use the key pair Describe how the key-generation processes observed verified that asymmetric-key pairs are either:

Modified p. 107 → 103

• If generated externally, the key pair and all related critical security parameters are deleted immediately after the transfer to the device that will use the key ~~pair.~~

• If generated externally, the key pair and all related critical security parameters are deleted immediately after the transfer to the device that will use the key pair <Report Findings Here>

Modified p. 108 → 104

• Faxing, e-mailing, or otherwise electronically conveying ~~clear-text~~ private or secret keys or components

• Faxing, e-mailing, or otherwise electronically conveying cleartext private or secret keys or components

Modified p. 108 → 104

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

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

Modified p. 108 → 104

• Writing key or component values in procedure manuals 6-6.a Examine documented policy and procedures to verify that they include language that prohibits transmitting ~~clear-text~~ private or secret keys or their components/shares across insecure channels, including but not limited to:

• Writing key or component values in procedure manuals 6-6.a Examine documented policy and procedures to verify that they include language that prohibits transmitting cleartext private or secret keys or their components/shares across insecure channels, including but not limited to:

Modified p. 108 → 104

• Faxing, e-mailing, or otherwise electronically conveying ~~clear-text~~ keys or components

• Faxing, e-mailing, or otherwise electronically conveying cleartext keys or components

Modified p. 108 → 104

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

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

Modified p. 108 → 104

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

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

Modified p. 109 → 105

• Faxing, e-mailing, or otherwise electronically conveying ~~clear-text~~ keys or components

• Faxing, e-mailing, or otherwise electronically conveying cleartext keys or components

Modified p. 109 → 105

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

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

Modified p. 109 → 105

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

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

Modified p. 109 → 105

• Faxing, e-mailing, or otherwise conveying ~~clear-text~~ keys or components

• Faxing, e-mailing, or otherwise conveying cleartext keys or components

Removed p. 111

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

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

Modified p. 111 → 107

~~Clear-text~~ key components/shares must be conveyed in SCDs or using tamper-evident, authenticable ~~packaging.~~

• Cleartext key components/shares must be conveyed in SCDs or using tamper-evident, authenticable packaging

Modified p. 111 → 107

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

• If key components are transmitted in clear text using pre-numbered, tamper-evident, authenticable mailers: o Components/shares must be conveyed using at least two separate communication channels, such as different courier services o Components/shares sufficient to form the key must not be conveyed using the same communication channel o Details of the serial number of the package are conveyed separately from the package itself o Documented procedures exist and are followed to require that the serial numbers be verified prior to …

Modified p. 111 → 107

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

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

Modified p. 111 → 107

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

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

Modified p. 111 → 107

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

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

Modified p. 111 → 107

~~8-1.a Determine whether~~ keys are ~~transmitted~~ encrypted, as ~~clear-text components/shares, or~~ within an ~~SCD.~~

Describe how keys are transmitted, i.e., encrypted, or as cleartext components, and/or within an SCD:

Removed p. 112

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

Modified p. 112 → 108

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

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

Modified p. 112 → 108

- At least two communication channels ~~are~~ used to send the components of a given key (not just separation by sending on different ~~days).~~ - Prior to the use of the ~~components,~~ the serial ~~numbers are to be confirmed.~~

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

Modified p. 112 → 108

<Report Findings Here> Describe how the observed method to ~~transport clear-text~~ key components using tamper- evident mailers verified that:

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

Modified p. 112 → 108

• The details of the serial number of the package were transmitted separately from the package ~~itself.~~

• The details of the serial number of the package were transmitted separately from the package itself

Modified p. 112 → 108

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

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

Removed p. 113

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

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

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

Modified p. 113 → 109

• Examine documented procedures to verify that the mechanism to obtain the keying material (e.g., PIN) is conveyed using a separate communication channel from the associated ~~SCD.~~

• Examine documented procedures to verify that the mechanism to obtain the keying material (e.g., PIN) is conveyed using a separate communication channel from the associated SCD

Modified p. 113 → 109

• Examine documented procedures to verify that each SCD is inspected to ensure that there are not any signs of ~~tampering.~~

• Examine documented procedures to verify that each SCD is inspected to ensure that there are not any signs of tampering

Modified p. 113 → 109

• Examine the chain-of-custody document for the SCDs and any transport logs to ensure the movement of each device is tracked and that there is evidence that the SCDs and dual-control mechanisms were separated sufficiently to ensure that no one person gained access to the SCDs and both SCD ~~enablers.~~

• Examine the chain-of-custody document for the SCDs and any transport logs to ensure the movement of each device is tracked and that there is evidence that the SCDs and dual-control mechanisms were separated sufficiently to ensure that no one person gained access to the SCDs and both SCD enablers Documented procedures examined:

Modified p. 114 → 109

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

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

Modified p. 114 → 109

• Examine the documented procedures to ensure the method of shipment of the SCD and dual-control mechanisms (e.g., smart cards or passphrases) are separated in a way that ensures there is no opportunity for one person to gain access to the SCD and both authorization mechanisms (e.g., both smartcards, ~~etc.).~~

• Examine the documented procedures to ensure the method of shipment of the SCD and dual-control mechanisms (e.g., smart cards or passphrases) are separated in a way that ensures there is no opportunity for one person to gain access to the SCD and both authorization mechanisms (e.g., both smartcards, etc.)

Modified p. 114 → 109

• Examine documented procedures to verify that the SCD is inspected to ensure there are no signs of ~~tampering.~~

• Examine documented procedures to verify that the SCD is inspected to ensure there are no signs of tampering

Modified p. 114 → 109

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

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

Modified p. 115 → 110

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 …

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

Modified p. 115 → 110

• Designation of person(s) permitted to convey/receive ~~keys.~~

• Designation of person(s) permitted to convey/receive keys

Modified p. 115 → 110

• Reminder that any person with access to one component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component or shares sufficient to form the necessary threshold to derive the ~~key.~~

• Reminder that any person with access to one component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component or shares sufficient to form the necessary threshold to derive the key

Modified p. 115 → 110

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

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

Modified p. 116 → 111

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

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

Modified p. 116 → 111

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

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

Modified p. 116 → 111

• There is a clear understanding that an individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the ~~key.~~

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

Modified p. 116 → 111

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

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

Modified p. 116 → 111

<Report Findings Here> Describe how the observed ~~key-transfer~~ processes verified that:

<Report Findings Here> Describe how the observed key transfer processes verified that:

Modified p. 116 → 111

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

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

Modified p. 116 → 111

• Any person with access to the media conveying a key component or key share could not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key without ~~detection.~~

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

Modified p. 116 → 111

<Report Findings Here> 8-3 E-mail must not be used for the conveyance of secret or private keys or their components/shares, even if encrypted, unless the key (or component/share) has already been encrypted in accordance with these requirements•i.e., in an SCD. This is due to the existence of these key values in memory just prior to encryption or subsequent to decryption. In addition, corporate e-mail systems allow the recovery by support staff of the ~~clear-text~~ of any encrypted text or files …

<Report Findings Here> 8-3 E-mail must not be used for the conveyance of secret or private keys or their components/shares, even if encrypted, unless the key (or component/share) has already been encrypted in accordance with these requirements•i.e., in an SCD. This is due to the existence of these key values in memory just prior to encryption or subsequent to decryption. In addition, corporate e-mail systems allow the recovery by support staff of the cleartext of any encrypted text or files …

Modified p. 116 → 111

Other similar mechanisms, such as SMS, fax, or telephone must not be used to convey ~~clear-text~~ key values.

Other similar mechanisms, such as SMS, fax, or telephone must not be used to convey cleartext key values.

Modified p. 117 → 112

Personnel interviewed: <Report Findings Here> Logs ~~reviewed:~~ <Report Findings Here> Describe the observations that confirmed that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components:

Personnel interviewed: <Report Findings Here> Logs examined: <Report Findings Here> Describe the observations that confirmed that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components:

Modified p. 118 → 113

• Encrypted Documented procedures ~~reviewed:~~

• Encrypted Documented procedures examined:

Modified p. 118 → 113

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

<Report Findings Here> 8-4.b Examine documentation, interview personnel, and observe processes as needed to verify that self-signed certificates are not used as the sole method of authentication.

Modified p. 119 → 114

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

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

Modified p. 119 → 114

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

• Contained within a physically secure SCD

Modified p. 119 → 114

9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single ~~clear- text~~ secret or private key component/share must at all times be either:

9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single cleartext secret or private key component/share must at all times be either:

Removed p. 120

• contained within a physically secure SCD.

Modified p. 120 → 115

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

• contained within a physically secure SCD Responsible personnel interviewed:

Modified p. 120 → 115

<Report Findings Here> Describe how the key-management processes observed verified that processes are implemented to ensure that any single ~~clear-text~~ secret or private key component/share is at all times either:

<Report Findings Here> Describe how the key-management processes observed verified that processes are implemented to ensure that any single cleartext secret or private key component/share is at all times either:

Modified p. 120 → 115

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

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

Modified p. 120 → 115

• Any keys encrypted under this (combined) key 9-2.a ~~Verify~~ documented procedures include requirements for all packaging or mailers containing ~~clear-text~~ key components to be examined for evidence of tampering before being opened.

• Any keys encrypted under this (combined) key 9-2.a Examine documented procedures to verify they include requirements for all packaging or mailers containing cleartext key components to be examined for evidence of tampering before being opened.

Modified p. 120 → 115

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

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

Modified p. 120 → 115

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

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

Modified p. 121 → 116

• Any keys encrypted under this (combined) key Documented procedures ~~reviewed:~~

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

Modified p. 121 → 116

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

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

Modified p. 122 → 117

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

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

Modified p. 122 → 117

Documentation ~~reviewed:~~

Documentation examined:

Modified p. 123 → 118

Documentation ~~reviewed:~~

Documentation examined:

Modified p. 123 → 118

9-4.a ~~Verify that a~~ list(s) of key custodians authorized to perform the following activities is defined and documented:

9-4.a Examine the list(s) of key custodians authorized to perform the following activities is defined and documented:

Modified p. 123 → 118

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

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

Modified p. 123 → 118

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

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

Modified p. 123 → 118

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

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

Modified p. 123 → 118

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

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

Modified p. 123 → 118

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

• Check the serial number of the tamper-evident packaging upon receipt of a component package <Report Findings Here>

Removed p. 124

• Observe the method used to transport clear-text key components using tamper-evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself.

Modified p. 124 → 119

9-5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of ~~clear-text~~ key components and perform the following:

9-5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of cleartext key components and perform the following:

Modified p. 124 → 119

• Examine documented procedures to verify they define how details of the serial number are transmitted separately from the package ~~itself.~~

• Examine documented procedures to verify they define how details of the serial number are transmitted separately from the package itself

Modified p. 124 → 119

• Examine logs to verify that procedures are ~~followed.~~

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

Modified p. 124 → 119

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

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

Removed p. 125

9-6.a If components or shares of multiple keys are being sent simultaneously between the same sending and receiving custodians, the component/shares for a specific custodian or custodian group can be shipped in the same TEA bag provided that:

• The components inside the tamper- evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or within PIN mailers) to prevent confusion and/or inadvertent observation when the package is opened.

• 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. 125 → 120

• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or PIN mailers) to prevent confusion and/or inadvertent observation when the package is ~~opened.~~

• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or PIN mailers) to prevent confusion and/or inadvertent observation when the package is opened

Modified p. 125 → 120

• The components are repackaged at receipt into separate tamper-evident and authenticable packages for storage at the receiving location. Records reflect the receipt of the shipped bag and association with subsequent individual ~~bags.~~

• The components are repackaged at receipt into separate tamper-evident and authenticable packages for storage at the receiving location. Records reflect the receipt of the shipped bag and association with subsequent individual bags 9-6.a Examine documents, interview personnel, and observe processes as needed to verify that:

Modified p. 125 → 120

• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or within PIN mailers) to prevent confusion and/or inadvertent observation when the package is ~~opened.~~

• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or within PIN mailers) to prevent confusion and/or inadvertent observation when the package is opened

Modified p. 125 → 120

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

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

Modified p. 125 → 120

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

• Records reflect the receipt of the shipped bag and association with subsequent individual bags Documented procedures examined: <Report Findings Here> Personnel interviewed: <Report Findings Here>

Removed p. 126

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

Modified p. 126 → 121

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

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

Modified p. 126 → 121

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

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

Modified p. 126 → 121

• TDEA keys must not be used to protect AES ~~keys.~~

• TDEA keys must not be used to protect AES keys

Modified p. 126 → 121

• TDEA keys must not be used to encrypt keys greater in strength than 112 ~~bits.~~

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

Modified p. 126 → 121

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

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

Modified p. 126 → 121

~~Document(s) reviewed:~~ <Report Findings Here> ~~Responsible personnel interviewed:~~ <Report Findings Here> Keys identified that protect other keys for ~~transmission.~~

Personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> Keys identified that protect other keys for transmission:

Removed 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

Modified p. 127 → 122

• Interview appropriate personnel and examine documented procedures for the creation of these ~~keys.~~

• Interview appropriate personnel and examine documented procedures for the creation of these keys

Modified p. 127 → 122

• Using the table in Annex C, validate the respective key sizes relative to the algorithms used for key ~~encryption.~~

• Using the table in Annex C, validate the respective key sizes relative to the algorithms used for key encryption

Modified p. 127 → 122

- TDEA keys used for encrypting keys must be at least triple-length keys (have an effective bit strength of 112 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key- ~~encipherment.~~ - A triple-length TDEA key must not be encrypted with a TDEA key of lesser ~~strength.~~

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

Modified p. 127 → 122

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

<Report Findings Here> Documented procedures examined:

Removed p. 128

12-1.a Using the summary of cryptographic keys, identify keys that are loaded from components and examine documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required.

Modified p. 128 → 122

11-1.a ~~Verify~~ documented procedures exist for all key transmission and conveyance processing.

11-1.a Observe documented procedures exist for all key transmission and conveyance processing.

Modified p. 128 → 122

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

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

Modified p. 128 → 122

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

Responsible personnel interviewed: <Report Findings Here>

Modified p. 128 → 123

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

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

Modified p. 128 → 123

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

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

Modified p. 128 → 123

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

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

Modified p. 128 → 123

Appropriate personnel interviewed: <Report Findings Here> 12-1.c ~~Witness a structured walk-through/demonstration of various key- loading~~ processes for all key types (MFKs, AWKs, TMKs, ~~PEKs,~~ etc.). Verify the number and length of the key components against information provided through verbal discussion and written documentation.

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

Modified p. 128 → 123

Describe how the ~~structured walk-through/demonstration~~ verified that the number and length of the key components is consistent with information provided through verbal discussion and written documentation:

Describe how the observed key-loading processes verified that the number and length of the key components is consistent with information provided through verbal discussion and written documentation:

Modified p. 129 → 123

Describe how ~~the structured walk-through/demonstration~~ verified that the process includes the entry of individual key components by the designated key custodians:

Describe how observations verified that the process includes the entry of individual key components by the designated key custodians:

Modified p. 129 → 123

<Report Findings Here> 12-1.e ~~Ensure~~ key-loading devices can only be accessed and used under dual control.

<Report Findings Here> 12-1.e Observe key-loading devices can only be accessed and used under dual control.

Modified p. 129 → 123

Describe how ~~the structured walk-through/demonstration~~ verified that key-loading devices can only be accessed and used under dual control:

Describe how observations verified that key-loading devices can only be accessed and used under dual control:

Modified p. 129 → 124

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

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

Modified p. 130 → 125

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

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

Modified p. 130 → 125

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

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

Removed p. 131

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

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

Modified p. 131 → 126

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

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

Modified p. 131 → 126

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

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

Modified p. 131 → 126

• Expected techniques are ~~used.~~

• Expected techniques are used

Modified p. 131 → 126

• Expected techniques are ~~used.~~

• Expected techniques are used

Modified p. 131 → 126

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

• Default passwords/authentications codes are reset

Modified p. 131 → 126

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

• Default passwords/authentications codes are reset

Modified p. 131 → 126

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

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

Modified p. 131 → 126

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

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

Modified p. 131 → 126

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

• Any passwords/authentication codes or tokens are maintained separately Describe how the observed processes for loading cleartext cryptographic keys for all sampled production POI device verified that

Modified p. 131 → 126

<Report Findings Here> 12-3.c Examine documented records of key-loading to verify the presence of two authorized persons during each type of key-loading activity.

• Any passwords/authentication codes or tokens are maintained separately <Report Findings Here> 12-3.c Examine documented records of key-loading to verify the presence of two authorized persons during each type of key-loading activity.

Modified p. 131 → 126

Documented records of key-loading processes ~~reviewed:~~

Documented records of key-loading processes examined:

Modified p. 131 → 126

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

•usually printed in the vendor's manual

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

•usually printed in the vendor's manual

Modified p. 131 → 126

Describe how default dual-control mechanisms ~~were verified to~~ have been disabled or changed:

Describe how the observed processes verified that default dual-control mechanisms have been disabled or changed:

Modified p. 132 → 127

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

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

Modified p. 132 → 127

Documented procedures ~~reviewed:~~ <Report Findings Here> 12-4.b ~~Confirm key-component lengths through interview and examination of blank component forms and documented procedures.~~ Examine device configuration settings and interview personnel to verify that key components used to create a key are the same length as the resultant key.

Documented procedures examined: <Report Findings Here> 12-4.b Examine device configuration settings and interview personnel to verify that key components used to create a key are the same length as the resultant key.

Modified p. 132 → 127

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

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

Modified p. 133 → 128

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

12-6.a Examine documented procedures, interview personnel, and observe processes as needed to confirm that any devices that are loaded with the same key components use the same mathematical process to derive the final key.

Modified p. 133 → 128

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

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

Modified p. 133 → 128

• Asymmetric ~~techniques;~~

• Asymmetric techniques

Modified p. 133 → 128

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

• The existing TMK to encrypt the replacement TMK for download

Modified p. 133 → 128

• For AES DUKPT, using the option to derive a key-encryption key called the DUKPT Update Key so that the host can send a device a new initial key encrypted under that key. Note this also requires that a new initial key ID is also ~~sent.~~

• For AES DUKPT, using the option to derive a key-encryption key called the DUKPT Update Key so that the host can send a device a new initial key encrypted under that key. Note this also requires that a new initial key ID is also sent Keys must not be reloaded by any methodology in the event of a compromised device and must be withdrawn from use.

Modified p. 133 → 128

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

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

Modified p. 134 → 129

• Use public and private key lengths that are in accordance with Annex C for the algorithm in ~~question.~~

• Use public and private key lengths that are in accordance with Annex C for the algorithm in question

Modified p. 134 → 129

• Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in ~~question.~~

• Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question

Modified p. 134 → 129

• Provide for mutual device authentication for both the host and the POI device or host-to-host if applicable, including assurance to the host that the POI device has (or can compute) the session key, and that no entity other than the POI device specifically identified can possibly compute the session ~~key.~~

• Provide for mutual device authentication for both the host and the POI device or host-to-host if applicable, including assurance to the host that the POI device has (or can compute) the session key, and that no entity other than the POI device specifically identified can possibly compute the session key 12-8.a For techniques involving public-key cryptography, examine documentation to illustrate the process, including the size and sources of the parameters involved, and the mechanisms utilized for mutual device authentication …

Modified p. 134 → 129

Documentation ~~reviewed:~~ <Report Findings Here> 12-8.b If key-establishment protocols using public-key cryptography are used to remotely distribute secret keys, verify that the applicable requirements detailed in this Domain are met, including:

Documentation examined: <Report Findings Here> 12-8.b If key-establishment protocols using public-key cryptography are used to remotely distribute secret keys, examine documented procedures, interview personnel, and observe processes as needed to verify that the applicable requirements detailed in this Domain are met, including:

Modified p. 134 → 129

• Use of public and private key lengths that are in accordance with Annex C for the algorithm in ~~question.~~

• Use of public and private key lengths that are in accordance with Annex C for the algorithm in question

Modified p. 134 → 129

• Use of key-generation techniques that meet the current ANSI and ISO standards for the algorithm in ~~question.~~

• Use of key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question

Modified p. 134 → 129

• Providing for mutual device authentication for both the host and the POI device or host-to-host if ~~applicable.~~

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

Removed p. 135

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

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

Modified p. 135 → 130

• Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of ~~clear-text~~ key ~~components.~~

• Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of cleartext key components

Modified p. 135 → 130

• There is not any mechanism at the interface between the conveyance medium and the SCD that might disclose the transferred ~~keys.~~

• There is not any mechanism at the interface between the conveyance medium and the SCD that might disclose the transferred keys

Modified p. 135 → 130

• The sending and receiving SCDs must be inspected prior to key loading to ensure that they have not been subject to any prior tampering or unauthorized modification that could lead to the disclosure of ~~clear-text~~ keying ~~material.~~

• The sending and receiving SCDs must be inspected prior to key loading to ensure that they have not been subject to any prior tampering or unauthorized modification that could lead to the disclosure of cleartext keying material

Modified p. 135 → 130

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

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

Modified p. 135 → 130

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

• An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are uniquely identified by the device 13-1 Observe key-loading environments, processes, and mechanisms (e.g., terminals, PIN pads, key guns, etc.) used to transfer keys and key components. Perform the following:

Modified p. 135 → 130

• ~~Ensure~~ cameras are positioned to ensure they cannot monitor the entering of ~~clear-text~~ key components.

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

Modified p. 135 → 130

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

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

Modified p. 135 → 130

- 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 prior tampering or unauthorized modification, which could lead to the disclosure of clear-text keying material.~~

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

Modified p. 135 → 130

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

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

Modified p. 135 → 130

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

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

Modified p. 135 → 130

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

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

Removed p. 136

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

Modified p. 136 → 131

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

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

Modified p. 136 → 131

13-2.a Examine documentation to verify that only SCDs are used in the loading of ~~clear-text~~ secret or private keys or their components outside of a secure key-loading facility, as delineated in this requirement. For example, computer keyboards or keyboards attached to an HSM must never be used for the loading of ~~clear-text~~ secret or private keys or their components.

13-2.a Examine documentation to verify that only SCDs are used in the loading of cleartext secret or private keys or their components outside of a secure key-loading facility, as delineated in this requirement. For example, computer keyboards or keyboards attached to an HSM must never be used for the loading of cleartext secret or private keys or their components.

Modified p. 136 → 131

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

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

Removed p. 137

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

Modified p. 137 → 132

• All traces of the component are erased or otherwise destroyed from the electronic medium in accordance with Requirement ~~24.~~

• All traces of the component are erased or otherwise destroyed from the electronic medium in accordance with Requirement 24 13-3.a Examine documented procedures for the loading of secret or private key components from electronic medium to a cryptographic device. Verify that procedures define specific instructions to be followed as a result of key injection, including:

Modified p. 137 → 132

• Instructions to erase or otherwise destroy all traces of the component from the electronic medium, including the method to ~~use.~~

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

Modified p. 137 → 132

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

• All traces of the component are erased or otherwise destroyed from the electronic medium Describe how the observed key-loading processes verified that the injection process results in one of the following:

Modified p. 137 → 132

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

• All traces of the component are erased or otherwise destroyed from the electronic medium in accordance with Requirement ~~24.~~

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

• All traces of the component are erased or otherwise destroyed from the electronic medium in accordance with Requirement 24 <Report Findings Here> 13-3.c Examine records/logs of erasures to confirm that:

Modified p. 137 → 132

• The documented procedure was ~~followed.~~

• The documented procedure was followed

Modified p. 137 → 132

• The method used was in accordance with Requirement ~~24.~~

• The method used was in accordance with Requirement 24 Records examined: <Report Findings Here>

Modified p. 138 → 133

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.1 Examine documented procedures, interview personnel, and observe processes as needed to 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.

Modified p. 138 → 133

Documented procedures ~~reviewed:~~ <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected:

Documented procedures examined: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected:

Modified p. 138 → 133

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.

13-4.2 Examine documented procedures, interview personnel, and observe processes as needed to 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.

Modified p. 138 → 133

Documented procedures ~~reviewed:~~ <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it:

Documented procedures examined: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it:

Modified p. 139 → 134

Documented procedures ~~reviewed:~~ <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD. Such personnel must ensure that a key-recording device is not inserted between the SCDs.

Documented procedures examined: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD. Such personnel must ensure that a key-recording device is not inserted between the SCDs.

Modified p. 139 → 134

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

<Report Findings Here> 13-4.3.b Examine documented procedures, interview personnel, and observe processes as needed to 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.

Modified p. 139 → 134

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:

Documented procedures examined: <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:

Modified p. 139 → 134

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.

13-4.4 Examine documented procedures, interview personnel, and observe processes as needed to verify the key-loading device does not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred. For example, attempt to output the same value more than one time from the device or cause the device to display check values for its contents both before and after injection and compare.

Modified p. 139 → 134

Documented procedures ~~reviewed:~~ <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device does not retain any information that might disclose the key (e.g., allow replay of the key for injection into a non-SCD) that was installed in the device or a key that it has successfully ~~transferred.~~

Documented procedures examined: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device does not retain any information that might disclose the key (e.g., allow replay of the key for injection into a non-SCD) that was installed in the device or a key that it has successfully transferred:

Removed p. 140

Documented procedures reviewed: <Report Findings Here> 13-5.c Interview designated component holder(s) and examine key- management logs to verify that media or devices removed from secure storage are in the physical possession of only the designated component holder(s).

Modified p. 140 → 135

Key components that can be read (e.g., those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in ~~clear-text~~ to anyone who is not a designated custodian for that component.

Key components that can be read (e.g., those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in cleartext to anyone who is not a designated custodian for that component.

Modified p. 140 → 135

• Requirement that media/devices be in the physical possession of only the designated component ~~holder(s).~~

• Requirement that media/devices be in the physical possession of only the designated component holder(s)

Modified p. 140 → 135

• The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading ~~process.~~

• The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading process Documented procedures examined: <Report Findings Here> 13-5.c Interview designated component holder(s) and examine key- management logs to verify that media or devices removed from secure storage are in the physical possession of only the designated component holder(s).

Modified p. 141 → 136

13-6 ~~Validate through interview and observation that if~~ components are in human-readable form, they are visible only to designated component custodians and only for the duration of time required for this person to privately enter the key component into an SCD.

13-6 If components are in human-readable form, examine documented procedures, interview personnel, and observe processes as needed to verify that they are visible only to designated component custodians and only for the duration of time required for this person to privately enter the key component into an SCD.

Modified p. 141 → 136

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

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

Removed p. 142

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

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

• All hardware used in the key-loading function or for the signing of authenticated applications is controlled and maintained in a secure environment under dual control.

• All resources (e.g., passwords/authentication codes and associated hardware) used for key-loading functions and for the signing of authenticated applications are controlled and managed such that no single individual has the capability to enable key loading.

Describe how the observation of key-loading environments and controls verified that:

Modified p. 142 → 137

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

<Report Findings Here> 13-9 REMOVED 14-1 Any hardware and passwords/authentication codes used in the key-loading function 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 cleartext keys or their components. This is not to imply that individual access authentication mechanisms must be managed under dual control.

Modified p. 142 → 137

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

• Any hardware used in the key-loading function must be controlled and maintained in a secure environment under dual control

Modified p. 142 → 137

• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual ~~control.~~

• All resources (e.g., passwords and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key ~~loading.~~

• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control

• All resources (e.g., passwords and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading

Modified p. 143 → 138

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

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

Modified p. 143 → 138

Documented procedures ~~reviewed:~~ <Report Findings Here> 14-2.b Observe key-loading processes to verify that all cable attachments are properly examined at the beginning of an entity’s key-activity operations (system power ~~on/authorization) or application-signing operations.~~

Documented procedures examined: <Report Findings Here> 14-2.b Observe key-loading processes to verify that all cable attachments are properly examined at the beginning of an entity’s key-activity operations (system power on/authorization).

Modified p. 143 → 138

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

<Report Findings Here> 14-3 Key-loading equipment usage must be monitored, and a log of all key-loading 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. 143 → 138

14-3.a Observe key-loading ~~and application-signing~~ activities to verify that key-loading equipment usage is monitored.

14-3.a Observe key-loading activities to verify that key-loading equipment usage is monitored.

Modified p. 143 → 138

<Report Findings Here> 14-3.b ~~Verify~~ logs of all key-loading and ~~application-signing activities~~ are maintained and contain all required information.

<Report Findings Here> 14-3.b Examine logs of all key-loading activities and verify that they are maintained and contain all required information.

Modified p. 143 → 138

Logs of key-loading activities ~~reviewed:~~ <Report Findings Here>

Logs of key-loading activities examined: <Report Findings Here>

Removed p. 144

Documented procedures reviewed: <Report Findings Here> 14-4.b Inspect locations and controls for physical tokens to verify that tokens used to enable key loading or the signing of authenticated applications are not in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control.

Modified p. 144 → 139

14-4.a Examine documented procedures for the use of physical tokens (e.g., brass keys or chip cards) to enable key ~~loading or the signing of authenticated applications.~~ Verify procedures require that physical tokens must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control.

14-4.a Examine documented procedures for the use of physical tokens (e.g., brass keys or chip cards) to enable key loading. Verify procedures require that physical tokens must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control.

Modified p. 144 → 139

Identify the P2PE Assessor who confirms adequacy of ~~reviewed~~ storage locations for physical tokens to ensure that only the authorized custodian(s) can access their specific tokens:

Identify the P2PE Assessor who confirms adequacy of examined storage locations for physical tokens to ensure that only the authorized custodian(s) can access their specific tokens:

Modified p. 144 → 139

<Report Findings Here> 14-4.d ~~Verify~~ that access-control logs exist and are in use including notation of tamper-evident, authenticable bag numbers.

<Report Findings Here> 14-4.d Examine that access-control logs exist and are in use including notation of tamper-evident, authenticable bag numbers.

Modified p. 144 → 139

~~Access-control logs reviewed: <Report Findings Here> 14-4.e Reconcile storage contents to access-control logs.~~ Identify the P2PE Assessor who reconciled storage contents to access-control logs:

Identify the P2PE Assessor who reconciled storage contents to access-control logs:

Modified p. 145 → 140

14-5.a ~~Verify that~~ documented procedures require default passwords/authentication codes used to enforce dual-control mechanisms are changed.

14-5.a Examine documented procedures to verify they require default passwords/authentication codes used to enforce dual-control mechanisms are changed.

Modified p. 145 → 140

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

Documented procedures examined: <Report Findings Here> 14-5.b Examine documented procedures to verify they require that the passwords/authentication codes be changed when assigned personnel change.

Modified p. 145 → 140

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

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

Modified p. 145 → 140

Documented procedures ~~reviewed:~~ <Report Findings Here> 15-1.b Observe the key-loading processes to verify that the defined cryptographic-based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and is verified by the applicable key custodians.

Documented procedures examined: <Report Findings Here> 15-1.b Observe the key-loading processes to verify that the defined cryptographic-based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and is verified by the applicable key custodians.

Modified p. 146 → 141

• Have a MAC (message authentication code) created using the algorithm defined in ISO ~~16609.~~

• Have a MAC (message authentication code) created using the algorithm defined in ISO 16609 15-2.a Interview personnel and review documented procedures to verify that all public keys exist only in an approved form.

Modified p. 146 → 141

Personnel interviewed: <Report Findings Here> Documented procedures ~~reviewed:~~ <Report Findings Here> 15-2.b Observe public-key stores and mechanisms to verify that public keys exist only in an approved form.

Personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> 15-2.b Observe public-key stores and mechanisms to verify that public keys exist only in an approved form.

Modified p. 147 → 142

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

Documented procedures examined: <Report Findings Here> 16-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for all key- loading operations.

Removed p. 148

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

Modified p. 148 → 143

• Not be given to any other entity or logically separate ~~systems.~~

• Not be given to any other entity or logically separate systems

Modified p. 148 → 143

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

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

Modified p. 148 → 143

• ~~Generate~~ or otherwise obtain key-check values for any ~~key- encipherment~~ keys (KEKs) to verify key uniqueness between the two organizations. A random sample may be used where more than 10 zone connections are in use. This is not intended to be based on values retained on paper or otherwise sent as part of the original conveyance of the keying material, but rather on values generated from stored zone production keys from the production host database. Cryptograms may be used …

• Observe and/or test to generate or otherwise obtain key-check values for any key-encipherment keys (KEKs) to verify key uniqueness between the two organizations. A random sample may be used where more than 10 zone connections are in use. This is not intended to be based on values retained on paper or otherwise sent as part of the original conveyance of the keying material, but rather on values generated from stored zone production keys from the production host database. Cryptograms …

Modified p. 148 → 143

• If a remote key-establishment and distribution scheme is implemented between networks, examine public keys and/or hash values and/or fingerprints of the keys to verify key uniqueness of the ~~asymmetric-key pairs.~~

• If a remote key-establishment and distribution scheme is implemented between networks, examine public keys and/or hash values and/or fingerprints of the keys to verify key uniqueness of the asymmetric- key pairs

Modified p. 148 → 143

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

• Observe key-check values against those for known or default keys to verify that known or default key values are not used Describe how the generation of (or otherwise obtaining) key check values for any key- encipherment keys (KEKs) verified key uniqueness between the two organizations:

Modified p. 149 → 144

18-1.a ~~Verify~~ procedures have been implemented for monitoring and alerting to the presence of multiple cryptographic synchronization errors.

18-1.a Examine documented procedures to verify they have been implemented for monitoring and alerting to the presence of multiple cryptographic synchronization errors.

Modified p. 149 → 144

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

Documented procedures examined: <Report Findings Here> 18-1.b Examine and/or observe the implemented procedures include:

Modified p. 149 → 144

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

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

Modified p. 149 → 144

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

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

Modified p. 149 → 144

Documented procedures ~~reviewed:~~ <Report Findings Here> 18-2.b Interview personnel and observe processes to verify procedures are implemented to require that key-component packaging/containers showing signs of tampering result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.

Documented procedures examined: <Report Findings Here> 18-2.b Interview personnel and observe processes to verify procedures are implemented to require that key-component packaging/containers showing signs of tampering result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.

Modified p. 150 → 145

• this would include all applications and databases connected to hardware security modules (HSM). Effective date: 1 June 2019 ~~(past).~~

• this would include all applications and databases connected to hardware security modules (HSM). Effective date: 1 June 2019 (past)

Modified p. 150 → 145

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

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

Modified p. 150 → 145

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

• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 January 2025 (past) Acceptable methods of implementing the integrity requirements include, but are not limited to:

Modified p. 150 → 145

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

• A MAC computed over the concatenation of the cleartext attributes and the enciphered portion of the key block, which includes the key itself

Modified p. 150 → 145

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

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

Modified p. 150 → 145

• 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 18-3 Using the cryptographic-key summary to identify secret keys conveyed or stored, examine documented procedures and observe key operations to verify that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of the acceptable methods or an …

Modified p. 150 → 145

Documented procedures ~~reviewed:~~ <Report Findings Here> Describe how the ~~observed~~ key operations verified that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of the acceptable methods or an ~~equivalent, or where key blocks are not implemented, identify and examine project plans to implement in accordance with the prescribed timeline.~~

Documented procedures examined: <Report Findings Here> Describe how the documented procedures examined and the key operations observed verified that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of the acceptable methods or an equivalent.

Modified p. 150 → 145

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

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

Modified p. 151 → 146

Key-management documentation ~~reviewed:~~ <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Key-management documentation examined: <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Modified p. 151 → 146

<Report Findings Here> 19-1.b Using a sample of device types, ~~validate via examination of~~ check values, terminal definition files, etc. that keys used for key ~~encipherment or PIN~~ encipherment are not used for any other purpose.

<Report Findings Here> 19-1.b Using a sample of device types, examine/observe check values, terminal definition files, etc. to verify that keys used for key encipherment are not used for any other purpose.

Modified p. 151 → 146

Sample of device types ~~reviewed:~~ <Report Findings Here> Describe how review of check values, terminal definition files, etc. verified that keys used for key encipherment or PIN encipherment are not used for any other purpose:

Sample of device types examined: <Report Findings Here> Describe how review of check values, terminal definition files, etc. verified that keys used for key encipherment or PIN encipherment are not used for any other purpose:

Removed p. 152

Key-management documentation reviewed: <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Key-management documentation reviewed: <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Modified p. 152 → 147

• Must be used only for a single purpose

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

• Must be used only for a single purpose

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

Modified p. 152 → 147

• Must never be used to encrypt other ~~keys.~~

• Must never be used to encrypt other keys

Modified p. 152 → 147

• When used for remote key distribution, must not be used in connection with any other ~~purpose.~~

• When used for remote key distribution, must not be used in connection with any other purpose

Modified p. 152 → 147

• Used only to create digital signatures or to perform decryption ~~operations.~~

• Used only to create digital signatures or to perform decryption operations

Modified p. 152 → 147

• Used only for a single purpose

•a private key must only be used for either decryption or for creating digital signatures, but not ~~both.~~

• Used only for a single purpose

•a private key must only be used for either decryption or for creating digital signatures, but not both

Modified p. 152 → 147

• Never used to encrypt other ~~keys.~~

• Never used to encrypt other keys

Modified p. 152 → 147

• Not used in connection with any other purpose when used for remote key ~~distribution.~~

• Not used in connection with any other purpose when used for remote key distribution Key-management documentation examined: <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Modified p. 152 → 147

• To perform encryption operations or to verify digital ~~signatures.~~

• To perform encryption operations or to verify digital signatures

Modified p. 152 → 147

• For a single purpose

•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for POI ~~devices).~~

• For a single purpose

•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for POI devices) Key-management documentation examined: <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Modified p. 153 → 148

Key-management documentation ~~reviewed:~~ <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Key-management documentation examined: <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Modified p. 153 → 148

<Report Findings Here> 19-4.d ~~Compare~~ check, hash, cryptogram, or fingerprint values for production and test/development keys for higher-level keys (e.g., MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.

<Report Findings Here> 19-4.d Examine/observe check, hash, cryptogram, or fingerprint values for production and test/development keys for higher-level keys (e.g., MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.

Removed p. 154

• split knowledge as stated in these requirements.

Modified p. 154 → 149

~~Note this~~ does not apply to HSMs that are never intended to be used for production.

Note: This does not apply to HSMs that are never intended to be used for production.

Modified p. 154 → 149

• deleted from the HSM(s) and the server /computer platforms prior to ~~testing.~~

• deleted from the HSM(s) and the server /computer platforms prior to testing

Modified p. 154 → 149

• deleted and the server/computer platforms must be wiped and rebuilt from read-only ~~media.~~

• deleted and the server/computer platforms must be wiped and rebuilt from read-only media

Modified p. 154 → 149

• Prior to reuse for production purposes the HSM is returned to factory ~~state.~~

• Prior to reuse for production purposes the HSM is returned to factory state

Modified p. 154 → 149

Personnel interviewed: <Report Findings Here> Documented procedures ~~reviewed:~~ <Report Findings Here> 19-6 Not used in DMS 19-7 Not used in DMS 19-8 Not used in DMS 19-9 Not used in DMS 19-10 Not used in DMS 19-11 Not used in DMS 19-12 Not used in DMS

• split knowledge as stated in these requirements Personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> 19-6 Not used in DMS 19-7 Not used in DMS 19-8 Not used in DMS 19-9 Not used in DMS 19-10 Not used in DMS 19-11 Not used in DMS 19-12 Not used in DMS

Removed p. 155

Documented procedures reviewed: <Report Findings Here> 20-1.b Observe HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POIs to verify that unique keys are generated and used for each POI device.

Modified p. 155 → 150

• Known only to HSMs at the minimum number of facilities consistent with effective system ~~operations.~~

• Known only to HSMs at the minimum number of facilities consistent with effective system operations Documented procedures examined: <Report Findings Here> 20-1.b Observe HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POIs to verify that unique keys are generated and used for each POI device.

Removed p. 156

20-2 Determine whether POI devices are intended to interface with multiple entities for decryption.

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

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

20-2.a Examine documented procedures for generating all types of keys and verify the procedures ensure that unique keys, or sets of keys, are used for each acquiring organization and are totally independent and not variants of one another.

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

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

Modified p. 157 → 151

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 PTS POI devices, using a key-derivation process as described above. This requirement does not preclude multiple unique keys being loaded on a single device, or for the device to use a unique key for the derivation of other keys once loaded•e.g., as done with DUKPT.

Modified p. 157 → 151

• Unique data is used for the derivation process such that all transaction- originating POI devices receive unique secret ~~keys.~~

• Unique data is used for the derivation process such that all transaction- originating PTS POI devices receive unique secret keys

Modified p. 157 → 151

• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI ~~device.~~

• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating PTS POI device

Modified p. 157 → 151

• Examine key-generation/injection logs to ensure that sequential values included in unique key derivation are not ~~repeated.~~

• Examine key-generation/injection logs to ensure that sequential values included in unique key derivation are not repeated Documented procedures examined: <Report Findings Here> Key generation logs examined: <Report Findings Here> Describe how the observed processes for generating master keys verified that the following is implemented where master keys are generated by a derivation process and derived from the same Base Derivation Key:

Modified p. 157 → 151

• Unique data is used for the derivation process such that all transaction-originating POI devices receive unique secret ~~keys.~~

• Unique data is used for the derivation process such that all transaction-originating PTS POI devices receive unique secret keys

Modified p. 157 → 151

• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI device.

• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating PTS POI device <Report Findings Here> 20-3.b Examine/observe to verify that derivation keys used to generate keys for multiple devices are never loaded into a PTS POI device.

Modified p. 157 → 151

~~<Report Findings Here> 20-3.b Verify~~ that derivation keys used to generate keys for multiple devices are never loaded into a POI ~~device.~~

Describe how the processes for generating master keys verified that derivation keys used to generate keys for multiple devices are never loaded into a PTS POI device:

Modified p. 158 → 152

• Different BDKs for each financial ~~institution;~~

• Different BDKs for each financial institution

Modified p. 158 → 152

• Different BDKs for each financial ~~institution;~~

• Different BDKs for each financial institution

Modified p. 158 → 152

• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal ~~model;~~

• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model

Modified p. 158 → 152

• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal ~~model;~~

• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model

Modified p. 158 → 152

• Different BDKs by geographic region, market segment, processing platform, or sales ~~unit.~~

• Different BDKs by geographic region, market segment, processing platform, or sales unit COMPONENT PROVIDERS ONLY: Must use at least one unique Base Derivation Key (BDK) per acquiring organization and must be able to support segmentation of multiple BDKS of acquiring organizations.

Modified p. 158 → 152

• Different BDKs by geographic region, market segment, processing platform, or sales ~~unit;~~ FOR COMPONENT PROVIDERS ONLY: Examine documented key- generation and injection procedures to verify that key-injection vendors use at least one unique Base Derivation Key (BDK) per acquiring organization and are able to support segmentation of multiple BDKs of acquiring organizations.

• Different BDKs by geographic region, market segment, processing platform, or sales unit FOR COMPONENT PROVIDERS ONLY: Examine documented key- generation and injection procedures to verify that key-injection vendors use at least one unique Base Derivation Key (BDK) per acquiring organization and are able to support segmentation of multiple BDKs of acquiring organizations.

Modified p. 158 → 152

Documented procedures ~~reviewed:~~ <Report Findings Here> Personnel interviewed: <Report Findings Here> Describe how the observed key-injection processes for devices associated with different acquiring organizations verified that Base Derivation Key(s) unique to each organization are used:

Documented procedures examined: <Report Findings Here> Personnel interviewed: <Report Findings Here> Describe how the observed key-injection processes for devices associated with different acquiring organizations verified that Base Derivation Key(s) unique to each organization are used:

Modified p. 159 → 153

Documented procedures ~~reviewed:~~ <Report Findings Here> 21-1.b Observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when stored.

Documented procedures examined: <Report Findings Here> 21-1.b Observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when stored.

Modified p. 159 → 153

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

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

Modified p. 160 → 154

~~Key-management documentation reviewed:~~ <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Documented procedures examined: <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed:

Modified p. 161 → 155

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

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

Modified p. 161 → 155

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

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

Modified p. 162 → 156

<Report Findings Here> 21-3.1.b ~~Inspect any~~ tamper-evident packaging used to secure key components e.g., is the package sufficiently opaque to prevent reading of a component and ensure that it prevents the determination of the key component without visible damage to the packaging.

<Report Findings Here> 21-3.1.b Examine tamper-evident packaging used to secure key components e.g., is the package sufficiently opaque to prevent reading of a component and ensure that it prevents the determination of the key component without visible damage to the packaging.

Modified p. 162 → 156

<Report Findings Here> 21-3.1.c ~~Interview responsible personnel to determine that clear-text~~ key components do not exist in non-secure containers, such as databases or in software programs.

<Report Findings Here> 21-3.1.c Examine/observe cleartext key components to verify they do not exist in non-secure containers, such as databases or in software programs.

Modified p. 162 → 156

~~Responsible personnel interviewed:~~ <Report Findings Here> 21-3.1.d ~~Confirm~~ that start-up instructions and other notes used by service technicians do not contain initialization-key values written in the clear (e.g., at the point in the checklist where the keys are entered).

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

Removed p. 163

• Each secure container is accessible only by the custodian and/or designated backup(s).

Modified p. 163 → 157

21-3.2 ~~Inspect~~ each key component/share storage container and verify the following:

21-3.2 Examine/observe each key component/share storage container and verify the following:

Modified p. 163 → 157

• Key components/shares for different custodians are stored in separate secure ~~containers.~~

• Key components/shares for different custodians are stored in separate secure containers

Modified p. 163 → 157

• Key components/shares for different custodians are stored in separate secure ~~containers.~~

• Key components/shares for different custodians are stored in separate secure containers

Modified p. 163 → 157

• Each secure container is accessible only by the custodian and/or designated ~~backup(s).~~

• Each secure container is accessible only by the custodian and/or designated backup(s) Identify the P2PE Assessor who confirms that for each key component/share storage container:

Modified p. 163 → 157

<Report Findings Here> 21-3.3 If a key component/share is stored on a token, and an access code (e.g., a PIN or similar access-control mechanism) is used to access the token, only that token’s owner or designated backup(s) must have possession of both the token and its access code.

• Each secure container is accessible only by the custodian and/or designated backup(s) <Report Findings Here> 21-3.3 If a key component/share is stored on a token, and an access code (e.g., a PIN or similar access-control mechanism) is used to access the token, only that token’s owner or designated backup(s) must have possession of both the token and its access code.

Modified p. 164 → 158

22-1 ~~Verify~~ documented procedures ~~exist~~ for replacing known or suspected compromised keys ~~that~~ include all of the following (22-1.1 through 22-1.5 below):

22-1 Examine documented procedures for replacing known or suspected compromised keys to verify they include all of the following (22-1.1 through 22-1.5 below):

Modified p. 164 → 158

Documented procedures ~~reviewed:~~ <Report Findings Here> 22-1.1 Key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.

Documented procedures examined: <Report Findings Here> 22-1.1 Key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.

Modified p. 164 → 158

Responsible personnel interviewed: <Report Findings Here> ~~Describe how~~ the ~~implemented processes observed verified~~ that key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been ~~compromised:~~

Responsible personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.

Removed p. 165

• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key.

Modified p. 165 → 159

• Processing with that key is halted, and the key is replaced with a new unique ~~key.~~

• Processing with that key is halted, and the key is replaced with a new unique key

Modified p. 165 → 159

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

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

Modified p. 165 → 159

• The replacement key must not be a variant of the original key, or an irreversible transformation of the original ~~key.~~

• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key <Report Findings Here>

Modified p. 165 → 159

Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if compromise of the cryptographic key is suspected, an assessment and analysis is performed. If compromise is confirmed, all the following are performed:

• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if compromise of the cryptographic key is suspected, an assessment and analysis is performed. If compromise is confirmed, all the following are performed:

Modified p. 165 → 159

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

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

Modified p. 165 → 159

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

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

Modified p. 166 → 160

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

Responsible personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> 22-1.4.b Examine/observe notifications to verify they include the following:

Modified p. 166 → 160

• A damage assessment including, where necessary, the engagement of outside ~~consultants.~~

• A damage assessment including, where necessary, the engagement of outside consultants

Modified p. 167 → 161

• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation Responsible personnel interviewed: <Report Findings Here> Documented procedures ~~reviewed:~~ <Report Findings Here>

• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation Responsible personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here>

Modified p. 169 → 163

Documented procedures ~~reviewed:~~ <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 23-1.b Observe processes to verify that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge.

Documented procedures examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 23-1.b Observe processes to verify that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge.

Modified p. 170 → 164

Vendor documentation ~~reviewed:~~ <Report Findings Here> 23-2.c ~~Via examination of the~~ network ~~schematic~~ detailing transaction flows with the associated key usage and identification of the sources of the keys ~~used, determine~~ that variants of the MFK are not used external to the logical configuration that houses the MFK.

Vendor documentation examined: <Report Findings Here> 23-2.c Examine network schematics detailing transaction flows with the associated key usage and identification of the sources of the keys used to verify that variants of the MFK are not used external to the logical configuration that houses the MFK.

Removed p. 171

Documented procedures reviewed: <Report Findings Here> Describe how the implemented processes observed verified that reversible key transformations are not used across different levels of the key hierarchy, as follows:

Modified p. 171 → 165

• Variants of working keys must only be calculated from other working ~~keys.~~

• Variants of working keys must only be calculated from other working keys Documented procedures examined: <Report Findings Here> Describe how the implemented processes observed verified that reversible key transformations are not used across different levels of the key hierarchy, as follows:

Modified p. 171 → 165

• Variants of working keys must only be calculated from other working ~~keys.~~

• Variants of working keys must only be calculated from other working keys <Report Findings Here>

Modified p. 172 → 166

24-1.a ~~Verify~~ documented procedures are in place for destroying secret or private keys, and their key components that are no longer used or that have been replaced by a new key.

24-1.a Examine documented procedures to verify they are in place for destroying secret or private keys, and their key components that are no longer used or that have been replaced by a new key.

Modified p. 172 → 166

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.

Documented procedures examined: <Report Findings Here> 24-1.b Observe a sample of keys and key components to verify that they 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. 173 → 167

Documented procedures ~~reviewed:~~ <Report Findings Here> 24-2.b Observe key-destruction processes to verify that no part of the key or component can be recovered.

Documented procedures examined: <Report Findings Here> 24-2.b Observe key-destruction processes to verify that no part of the key or component can be recovered.

Modified p. 173 → 167

<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

Modified p. 173 → 167

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.

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

•physically secured, enciphered, or components

•are destroyed following the procedures outlined in ISO

•9564 or ISO

•11568.

Modified p. 174 → 168

<Report Findings Here> 24-2.2.b ~~Inspect~~ key-destruction logs and verify that a third-party, ~~non-key- custodian~~ witness signs an affidavit as a witness to the key-destruction process.

<Report Findings Here> 24-2.2.b Examine key-destruction logs and verify that a third-party, non- key-custodian witness signs an affidavit as a witness to the key-destruction process.

Modified p. 174 → 168

Key-destruction logs ~~inspected:~~ <Report Findings Here> 24-2.3 Key components for keys other than the HSM or KLD MFKs that have been successfully loaded and confirmed as operational must also be destroyed, unless the HSM does not store the encrypted values on a database but only stores the subordinate keys internal to the HSM. BDKs used in KLDs may also be stored as components where necessary to reload the KLD.

Key-destruction logs examined: <Report Findings Here> 24-2.3 Key components for keys other than the HSM or KLD MFKs that have been successfully loaded and confirmed as operational must also be destroyed, unless the HSM does not store the encrypted values on a database but only stores the subordinate keys internal to the HSM. BDKs used in KLDs may also be stored as components where necessary to reload the KLD.

Modified p. 174 → 168

24-2.3.a ~~Verify~~ documented procedures ~~exist for~~ destroying key components of ~~keys,~~ once the keys are successfully loaded and validated as operational.

24-2.3.a Examine documented procedures to verify they include destroying key components of keys once the keys are successfully loaded and validated as operational.

Modified p. 174 → 168

Documented procedures ~~reviewed:~~ <Report Findings Here> 24-2.3.b Observe key-conveyance/loading processes to verify that any key components are destroyed once the keys are successfully loaded and validated as operational.

Documented procedures examined: <Report Findings Here> 24-2.3.b Observe key-conveyance/loading processes to verify that any key components are destroyed once the keys are successfully loaded and validated as operational.

Modified p. 175 → 169

• Key custodian(s) are designated for each ~~component.~~

• Key custodian(s) are designated for each component

Modified p. 175 → 169

• The fewest number of key custodians is assigned as necessary to enable effective key ~~management.~~

• The fewest number of key custodians is assigned as necessary to enable effective key management

Modified p. 175 → 169

• The fewest number of key custodians is assigned as necessary to enable effective key ~~management.~~

• The fewest number of key custodians is assigned as necessary to enable effective key management

Modified p. 175 → 169

• A primary and a backup key custodian are designated for each ~~component.~~

• A primary and a backup key custodian are designated for each component

Modified p. 175 → 169

• Assigned key custodians are employees or contracted ~~personnel.~~

• Assigned key custodians are employees or contracted personnel <Report Findings Here> 25-1.2 Document this designation by having each custodian and backup custodian sign a key-custodian form.

Modified p. 175 → 169

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.

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

Modified p. 175 → 169

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

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

Modified p. 176 → 170

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

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

Removed p. 177

Documented key-custodian assignments reviewed:

Modified p. 177 → 171

• Key custodians that form the necessary threshold to create a key do not directly report to the same ~~individual.~~

• Key custodians that form the necessary threshold to create a key do not directly report to the same individual

Modified p. 177 → 171

• Neither direct reports nor the direct reports in combination with their immediate supervisors possess the necessary threshold of key components sufficient to form any given ~~key.~~

• Neither direct reports nor the direct reports in combination with their immediate supervisors possess the necessary threshold of key components sufficient to form any given key

Modified p. 177 → 171

• Key custodians are not and have not been a custodian for another component/share of a key where that collectively would constitute a quorum to form the actual ~~key.~~

• Key custodians are not and have not been a custodian for another component/share of a key where that collectively would constitute a quorum to form the actual key Documented key-custodian assignments examined:

Removed p. 178

• Ensure training includes procedures to report any violations.

Modified p. 178 → 172

• Ensure key custodians do not report to each ~~other.~~

• Ensure key custodians do not report to each other

Modified p. 178 → 172

• Receive explicit training to instruct them from sharing key components with their direct ~~manager.~~

• Receive explicit training to instruct them from sharing key components with their direct manager

Modified p. 178 → 172

• Sign key-custodian agreement that includes an attestation to the ~~requirement.~~

• Sign key-custodian agreement that includes an attestation to the requirement

Modified p. 178 → 172

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

• Ensure training includes procedures to report any violations Documented procedures examined: <Report Findings Here> 25-2 Not used in DMS 25-3 Not used in DMS 25-4 Not used in DMS 25-5 Not used in DMS 25-6 Not used in DMS 25-7 Not used in DMS 25-8 Not used in DMS 25-9 Not used in DMS

Modified p. 179 → 173

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

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

Modified p. 179 → 173

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

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

Modified p. 179 → 173

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

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

Modified p. 179 → 173

• Loaded to an SCD Log files ~~reviewed:~~ <Report Findings Here> Describe how the audit log settings observed verified that logs are kept for any time that keys, key components, or related materials are:

• Loaded to an SCD Log files examined: <Report Findings Here> Describe how the audit log settings observed verified that logs are kept for any time that keys, key components, or related materials are:

Modified p. 180 → 174

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

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

Modified p. 180 → 174

• Tamper-evident and authenticable package number (if applicable) Log files ~~reviewed:~~ <Report Findings Here> Describe how the audit log settings observed verified that logs include the following:

• Tamper-evident and authenticable package number (if applicable) Log files examined: <Report Findings Here> Describe how the audit log settings observed verified that logs include the following:

Modified p. 180 → 174

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.

Documented procedures examined: <Report Findings Here> Personnel interviewed: <Report Findings Here> Backup records examined: <Report Findings Here> 27-1.b Observe backup processes to verify backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys.

Removed p. 181

• The creation of any backup copies requires at least two authorized individuals to enable the process.

• All requirements applicable for the original keys also apply to any backup copies of keys and their components.

Modified p. 181 → 175

• All requirements applicable for the original keys also apply to any backup copies of keys and their ~~components.~~

• All requirements applicable for the original keys also apply to any backup copies of keys and their components <Report Findings Here>

Modified p. 182 → 176

• Management of personnel changes, including revocation of access control and other privileges when personnel move Documented procedures ~~reviewed:~~ <Report Findings Here> 28-1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.

• Management of personnel changes, including revocation of access control and other privileges when personnel move Documented procedures examined: <Report Findings Here> 28-1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.

Removed p. 183

• POI devices have not been substituted or subjected to unauthorized modifications or tampering.

• SCDs used for key injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.

Modified p. 183 → 177

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

Note: This also applies to SCDs used for key injection.

Modified p. 183 → 177

• POI devices have not been substituted or subjected to unauthorized modifications or ~~tampering.~~

• POI devices have not been substituted or subjected to unauthorized modifications or tampering

Modified p. 183 → 177

• POI devices have not been substituted or subjected to unauthorized modifications or ~~tampering.~~

• POI devices have not been substituted or subjected to unauthorized modifications or tampering

Modified p. 183 → 177

• SCDs used for ~~key-injection/loading or code signing~~ have not been substituted or subjected to unauthorized modifications or ~~tampering.~~

• SCDs used for key injection/loading have not been substituted or subjected to unauthorized modifications or tampering <Report Findings Here>

Modified p. 183 → 177

Documented processes ~~reviewed:~~ <Report Findings Here> 29-1.b Observe processes and interview personnel to verify that processes are followed to provide the following assurances prior to the loading of cryptographic keys:

• SCDs used for key-injection/loading have not been substituted or subjected to unauthorized modifications or tampering Documented processes examined: <Report Findings Here> 29-1.b Observe processes and interview personnel to verify that processes are followed to provide the following assurances prior to the loading of cryptographic keys:

Modified p. 183 → 177

• ~~SCDs used for key-injection/loading or code signing~~ have not been substituted or subjected to unauthorized modifications or ~~tampering.~~

• POI devices have not been substituted or subjected to unauthorized modifications or tampering

Modified p. 183 → 177

Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that processes are followed to provide the following assurances prior to the loading of cryptographic keys:

• SCDs used for key-injection/loading have not been substituted or subjected to unauthorized modifications or tampering Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that processes are followed to provide the following assurances prior to the loading of cryptographic keys:

Modified p. 184 → 178

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.

Documented procedures examined: <Report Findings Here> 29-1.1.1 Access to all PTS POI devices and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection. The minimum log contents include date and time, object name/identifier, purpose, name of individual(s) involved, signature or electronic capture (e.g., badge) of individual involved and, if applicable, tamper-evident package number(s) and serial number(s) of device(s) involved. Electronic logging⎯e.g., using bar codes⎯is acceptable for device tracking.

Modified p. 184 → 178

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.

29-1.1.1.a Examine access-control documentation and device configurations to verify that access to all PTS POI devices and key- injection/loading devices is defined and documented.

Modified p. 184 → 178

Access-control documentation ~~reviewed:~~ <Report Findings Here> Describe how access-control documentation and device configurations observed verified that access to all POI devices and key injection/loading devices is defined and documented:

Access-control documentation examined: <Report Findings Here> Describe how access-control documentation and device configurations observed verified that access to all POI devices and key injection/loading devices is defined and documented:

Modified p. 184 → 178

<Report Findings Here> 29-1.1.1.b For a sample of POI device types and other SCDs, observe authorized personnel accessing devices and examine access logs to verify that access to all POI devices and other SCDs is logged.

<Report Findings Here> 29-1.1.1.b For a sample of PTS POI device types and other SCDs, observe authorized personnel accessing devices and examine access logs to verify that access to all PTS POI devices and other SCDs is logged.

Modified p. 184 → 178

<Report Findings Here> Access logs ~~reviewed:~~ <Report Findings Here> Describe how observation of authorized personnel accessing devices and access logs verified that access to all POI devices and other SCDs is logged:

<Report Findings Here> Access logs examined: <Report Findings Here> Describe how observation of authorized personnel accessing devices and access logs verified that access to all PTS POI devices and other SCDs is logged:

Modified p. 184 → 178

Describe how the implemented access controls examined verified that unauthorized individuals cannot access, modify, or substitute any POI device or other SCD:

Describe how the implemented access controls examined verified that unauthorized individuals cannot access, modify, or substitute any PTS POI device or other SCD:

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

• The authorizations are reviewed annually.

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

Modified p. 185 → 179

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

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

Modified p. 185 → 179

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.

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

Modified p. 185 → 179

<Report Findings Here> Describe how the implemented access controls for the sample of POI device types and other SCDs examined verified that 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 PTS POI device types and other SCDs examined verified that only personnel documented and authorized in an auditable manner have access to devices:

Modified p. 186 → 180

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.

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

Modified p. 187 → 181

• 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. 187 → 181

• Physically secure and trackable packaging (e.g., pre-serialized, counterfeit-resistant, tamper-evident packaging) is in use. The devices are then stored in such packaging, or in secure storage, until key-insertion ~~occurs.~~

• Physically secure and trackable packaging (e.g., pre-serialized, counterfeit-resistant, tamper-evident packaging) is in use. The devices are then stored in such packaging, or in secure storage, until key-insertion occurs

Modified p. 187 → 181

• 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. 187 → 181

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

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

Modified p. 187 → 181

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

• 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. 187 → 181

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

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

Modified p. 187 → 181

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

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

Modified p. 188 → 182

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.

Documented procedures examined: <Report Findings Here> 29-4.b Interview responsible personnel and physically verify the dual- control mechanism used to prevent substitution or tampering of HSMs

Modified p. 188 → 182

Responsible personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who physically verified the dual-control mechanism used to prevent substitution or tampering of HSMs

Responsible personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who physically verified the dual-control mechanism used to prevent substitution or tampering of HSMs •both in service and spare or back- up devices

•throughout their life cycle:

Modified p. 188 → 182

• 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. 188 → 182

~~Documented procedures reviewed:~~ <Report Findings Here> 29-4.1.b For a sample of received devices, examine sender documentation sent via a different communication channel than the devices shipment (e.g., the manufacturer’s invoice or similar documentation) used to verify device serial numbers. Examine the record of serial-number validations to confirm the serial number for the received device was verified to match that documented by the sender.

Responsible personnel interviewed: <Report Findings Here> 29-4.1.b For a sample of received devices, examine sender documentation sent via a different communication channel than the devices shipment (e.g., the manufacturer’s invoice or similar documentation) used to verify device serial numbers. Examine the record of serial-number validations to confirm the serial number for the received device was verified to match that documented by the sender.

Modified p. 188 → 182

Sample of received devices: <Report Findings Here> Sender documentation/record of serial- number validations ~~reviewed:~~

Sample of received devices: <Report Findings Here> Sender documentation/record of serial- number validations examined:

Removed p. 189

29-4.2.a Obtain and review the defined security policy to be enforced by the HSM.

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

Modified p. 189 → 183

HSM configuration settings documentation ~~reviewed:~~

HSM configuration settings documentation examined:

Modified p. 189 → 183

• Configuration settings are defined, signed and dated by personnel responsible for ~~implementation.~~

• Configuration settings are defined, signed and dated by personnel responsible for implementation

Modified p. 189 → 183

• It includes identifying information for the HSM, such as serial number and/or asset ~~identifiers.~~

• It includes identifying information for the HSM, such as serial number and/or asset identifiers

Modified p. 189 → 183

• The documentation is retained and updated anytime configuration setting impacting security occur for each affected ~~HSM.~~

• The documentation is retained and updated anytime configuration setting impacting security occur for each affected HSM Documented procedures examined: <Report Findings Here>

Modified p. 190 → 184

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

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

Modified p. 190 → 184

Records of device inspections ~~reviewed:~~ <Report Findings Here> Describe how records of device inspections and test results verified that self-tests are run on devices to ensure the correct operation of the device:

Records of device inspections examined: <Report Findings Here> Describe how records of device inspections and test results verified that self-tests are run on devices to ensure the correct operation of the device:

Modified p. 191 → 186

Documented procedures ~~reviewed:~~ <Report Findings Here> 29-5.b Observe a sample of received devices to verify they are maintained in tamper-evident packaging until ready for installation.

Documented procedures examined: <Report Findings Here> 29-5.b Observe a sample of received devices to verify they are maintained in tamper-evident packaging until ready for installation.

Modified p. 192 → 187

• Procedures require that all secret and private keys and key material stored within the device be securely ~~destroyed.~~

• Procedures require that all secret and private keys and key material stored within the device be securely destroyed

Modified p. 192 → 187

• Procedures cover all devices removed from service or for ~~repair.~~

• Procedures cover all devices removed from service or for repair

Modified p. 192 → 187

• Procedures cover requirements at 31-1.1 through 31-1.6 ~~below.~~

• Procedures cover requirements at 31-1.1 through 31-1.6 below Documented procedures reviewed: <Report Findings Here> 31-1.1 HSMs require dual control (e.g., to invoke the system menu) to implement for all critical decommissioning processes.

Modified p. 192 → 187

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

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

Modified p. 195 → 190

33-1.a Examine documented procedures/processes and interview responsible personnel to verify that all affected parties are aware of required processes and are provided suitable guidance on procedures for devices placed into service, initialized, deployed, used, and decommissioned, Documented procedures ~~reviewed:~~ <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 33-1.b ~~Verify~~ that written records exist for the tests and inspections performed on devices before they are placed into service, as well as devices being decommissioned.

33-1.a Examine documented procedures/processes and interview responsible personnel to verify that all affected parties are aware of required processes and are provided suitable guidance on procedures for devices placed into service, initialized, deployed, used, and decommissioned, Documented procedures examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 33-1.b Examine/observe that written records exist for the tests and inspections performed on devices before they are placed into service, as well as devices being decommissioned.

Modified p. 195 → 190

Documented records ~~reviewed:~~ <Report Findings Here>

Documented records examined: <Report Findings Here>

Removed p. 196

Documented key-management procedures reviewed:

<Report Findings Here> 5A-1.2.b Through observation of key-management operations and inspection of SCDs, verify that crypto-periods are defined for every type of key in use.

SCDs inspected: <Report Findings Here> Describe how the observed key-management operations and the inspected SCDs verified that crypto-periods are defined for every type of key in use:

Modified p. 196 → 191

• Crypto-periods are defined for every type of key in ~~use.~~

• Crypto-periods are defined for every type of key in use

Modified p. 196 → 191

• Crypto-periods are based on industry best practices and guidelines (e.g., NIST Special Publication ~~800-57).~~

• Crypto-periods are based on industry best practices and guidelines (e.g., NIST Special Publication 800-57)

Modified p. 196 → 191

• A process/methodology is in place to determine when the ~~crypto-period~~ is reached for each cryptographic ~~key.~~

• A process/methodology is in place to determine when the crypto- period is reached for each cryptographic key

Modified p. 196 → 191

• Cryptographic key changes are implemented whenever a key reaches the end of its defined ~~crypto-period.~~

• Cryptographic key changes are implemented whenever a key reaches the end of its defined crypto-period Documented key-management procedures examined:

Modified p. 196 → 191

<Report Findings Here> 5A-1.2.b REMOVED

Modified p. 197 → 192

5A-1.3.a ~~Verify~~ documentation ~~exists describing~~ the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key-management solution.

5A-1.3.a Examine documentation to verify it describes the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key-management solution.

Modified p. 197 → 192

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.

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

Modified p. 199 → 194

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

Removed p. 200

OR

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

OR

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

Documented key-management policies and procedures reviewed:

Modified p. 200 → 195

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

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

Modified p. 200 → 195

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

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

Modified p. 200 → 195

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

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

• DDKs are unique per transaction. Each DDK is erased from the host memory upon completion of the decryption process Documented key-management policies and procedures examined:

Modified p. 200 → 195

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

• Upon reaching the defined usage threshold, the DDK must not be used for further transaction processing and must be securely erased from memory of the Host System OR

• DDKs are unique per transaction. Each DDK is erased from the host memory upon completion of the decryption process 5H-1.1.a Examine documented key-management policies and procedures to verify that DDKs managed on the Host System meet one or both of the following:

Removed p. 201

Documented key-management policies and procedures reviewed:

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

• A one-way derivation process is used.

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

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

Modified p. 201 → 196

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

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

Modified p. 201 → 196

• A one-way derivation process must be ~~used.~~

• A one-way derivation process must be used

Modified p. 201 → 196

• A one-way derivation process must be ~~used.~~

• A one-way derivation process must be used

Modified p. 201 → 196

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

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

Modified p. 201 → 196

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

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

Modified p. 201 → 196

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

• The master key used to generated the DDK must be dedicated to generating DDKs Documented key-management policies and procedures examined:

Modified p. 201 → 196

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

• The master key used to generate the DDK must be dedicated to generating DDKs 5H-1.3.a Examine key-management policies and procedures to verify that the following is required for any DDKs generated from a master key:

Modified p. 202 → 197

5H-1.5 ~~Verify~~ the encryption mechanism used to protect the DDK between the HSM and the Host System, includes 5H-1.5.1 through 5H-1.5.2 Perform the following:

5H-1.5 Examine/observe the encryption mechanism used to protect the DDK between the HSM and the Host System, includes 5H-1.5.1 through 5H-1.5.2 Perform the following:

Document Comparison

From Revision History

Content Changes