Document Diff - PCI Watch

Added p. 2

This document serves as both the Reporting Template and Reporting Instructions document; there are not separate documents for this under P2PE v2 as there are still under P2PE v1 P2PE v3.0 Revision 1.0 This template is for submitting P2PE Reports on Validation for P2PE Solutions assessed against the P2PE v3.0 Standard.

Added p. 5

Note: There is a separate P-ROV for Merchant-managed Solution (MMS) assessments. This Reporting Template provides reporting instructions and the template form for QSA (P2PE) and QSA (PA-P2PE) assessors to provide a more consistent level of reporting.

Solution assessments, at a minimum, must complete this P-ROV template. For every function that is not outsourced to a PCI-listed component provider, EACH applicable P-ROV must be completed and submitted in addition to this P-ROV as per the following diagram and table:

Added p. 6

SP = Solution Provider CP = Component Provider P-ROV Name Used for the Following Assessments Purpose Solution Solution (SP) The Solution P-ROV is mandatory for all P2PE Solution assessments, at a minimum. Additional P-ROVs (below) may be required.

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

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

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

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

P2PE Application P2PE Application Any assessment that utilizes software on the POI devices intended for use …

Added p. 7

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

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

Added p. 11

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

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

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

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

Added p. 13

Additional services provided by PA-QSA(P2PE)/QSA (P2PE)/QSA company The P2PE QSA (P2PE) and PA-QSA (P2PE) Qualification Requirements v2.1, Section 2.2 “Independence” specifies requirements for 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 Validation Requirements, to ensure responses are consistent with documented obligations.

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

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

Added p. 14

Description of Solution will typically be used:

Added p. 15

PCI-Listed Components Additional P- ROV included in submission Included as a Listed Component Component Provider Name Component Name

PCI SSC Reference # Comments If the Solution does not use a PCI-listed EMCP, or only uses either a PDCP or a PMCP, then the Encryption Management Services (EMS) P-ROV must be completed for all applicable requirements and submitted in addition to this Solution P-ROV.

Encryption Management Component Provider (EMCP) Yes No Yes No POI Deployment Component Provider (PDCP) Yes No Yes No POI Management Component Provider (PMCP) Yes No Yes No If the Solution uses applications that can access clear-text account data that are not PCI-listed P2PE Applications, then the P2PE Application P-ROV must be completed and submitted in addition to this Solution P-ROV for each P2PE Application.

P2PE Application Yes No Yes No Please include Applications in Table 2.3 below If the Solution does not use a PCI-listed Decryption Management Component Provider, then …

Added p. 16

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

Tables 2.3 and 2.4 MUST correspond to the P2PE Applications and PTS POI Devices included within the PCI SSC Portal submission for this Solution.

Model Name/ Number: Bluetooth Ethernet Serial USB Mobile Communications Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N

Added p. 19

Manufacturer/ Model Name/ Number: Hardware#(s) Firmware#(s) Location: # of devices per Approved key function(s) & 2.6 Multi-Acquirer and Multi-Solution Implementations Do multiple acquirers or multiple solution providers manage one or more P2PE solutions on the same POI device? If “No,” mark the remainder of Section 2.6 as ‘”N/A.” Yes No Describe how management of the multi-acquirer or multi-provider solutions is divided between entities:

Added p. 20

P2PE Solution Management Yes No N/A Encryption Management Services Encryption Management Yes No N/A POI Deployment Yes No N/A POI Management Yes No N/A P2PE Application Yes No N/A Decryption Management Services Decryption Management Yes No N/A Key Management Services Key Injection Facility Yes No N/A Key Management Yes No N/A Key Loading Yes No N/A Certification Authority / Registration Authority Yes No N/A

Added p. 22

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

Added p. 25

There is no need to duplicate documents that appear in other P-ROVs included unless they are relevant to the Solution Management Controls.

Added p. 26

There is no need to duplicate devices that appear in other P-ROVs included unless they are relevant to the Solution Management Controls.

4. Findings and Observations Where functions are marked as “Additional P-ROV included in submission” in Table 2.2 Summary of Components Consumed by Solution, please ensure the relevant P-ROVs are included with the submission.

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

Added p. 32

3A-3.2 Review documented procedures and interview responsible personnel to verify that upon detection of any suspicious activity defined at 3A-3.1, POI devices are immediately removed, shut down, or taken offline.

Added p. 33

• The merchant has provided written notification (signed by a merchant executive officer) requesting stopping of P2PE encryption services, according to the solution provider’s procedures (as defined in Requirement 3A-4.1).

Added p. 35

• Implementing controls to prevent cause from recurring Responsible personnel interviewed: <Report Findings Here> Documentation reviewed: <Report Findings Here> 3A-3.5.b For a sample of P2PE control failures, interview personnel and review supporting document to verify that:

Sample of P2PE control failures: <Report Findings Here> Supporting document reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 3B-1.1 Solution provider must have formal agreements in place with all third parties that perform P2PE functions on behalf of the solution provider, including:

Added p. 36

<Report Findings Here> 3B-1.2 For all third parties that have been contracted by the solution provider to manage any of the SCD types used in the P2PE solution, the solution provider must establish formal agreements with the third parties to ensure those third parties provide the Solution Provider with the following:

• Updated list of any dependencies included in the Designated Change (e.g., POI devices, P2PE applications, and/or HSMs) used in the solution

• All P2PE applications specified in the PIM are assessed for this solution (per Domain 1).

• All P2PE applications specified in the PIM are assessed for this solution (per Domain 1).

Added p. 39

• All P2PE applications specified in the PIM are either PCI-listed P2PE applications or assessed to Domain 2 as part of this P2PE solution assessment.

<Report Findings Here> 3C-1.1.f Examine the PIM to verify that all P2PE non-payment software specified in the PIM were assessed as part of this P2PE solution assessment (per Requirement 1C-2).

Identify the P2PE Assessor who confirms that all P2PE non-payment software specified in the PIM were assessed as part of this P2PE solution assessment (per Requirement 1C-2):

<Report Findings Here> 3C-1.1.g Configure each POI device type, settings, etc. in accordance with all instructions in the PIM and confirm the following:

• The PIM provides accurate instructions.

• The PIM instructions facilitate a securely installed P2PE solution.

Describe how it was confirmed that by configuring each POI device type, settings, etc. in accordance with all instructions in the PIM, the PIM provides accurate instructions and those instructions facilitate a securely installed P2PE …

Modified p. 1

Payment Card Industry (PCI) Point-to-Point Encryption Template for Report on Validation for use with P2PE ~~v2.0 (Revision 1.2)~~ for P2PE Solution ~~Revision 1.2~~

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

Removed p. 2

Clarify domain applicability for CA/RAs.

Modified p. 2

This document serves as both the Reporting Template and Reporting Instructions document; there are not separate documents for this under P2PE ~~v2 as there are still under P2PE v1~~

This document serves as both the Reporting Template and Reporting Instructions document; there are not separate documents for this under P2PE v3.0.

Modified p. 5

Use of this Reporting Template is mandatory for all P2PE ~~v2 submissions for P2PE Solutions.~~

Use of this Reporting Template is mandatory for all P2PE v3.0 Solution assessments.

Modified p. 5 → 7

Do not delete any content from any place in this document, including this section and the versioning above. These instructions are important for the assessor as they complete reporting, but also provide context for ~~for~~ the report recipient(s). Addition of text or sections is applicable within reason, as noted above.

Do not delete any content from any place in this document, including this section and the versioning above. These instructions are important for the assessor as they complete reporting, but also provide context for the report recipient(s). Addition of text or sections is applicable within reason, as noted above.

Modified p. 5 → 7

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

Modified p. 5 → 8

- Section 1: Contact Information and Report Date

• Section 1: Contact Information and Report Date

Modified p. 5 → 8

- Section 2: Summary Overview

• Section 2: Summary Overview

Modified p. 5 → 8

- Section 3: Details and Scope of P2PE Assessment

• Section 3: Details and Scope of P2PE Assessment

Modified p. 5 → 8

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

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

Modified p. 6 → 9

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

All Not Applicable responses require reporting on testing performed (including interviews conducted and documentation reviewed) and must explain how it was determined that the requirement does not apply. There is no need to repeat lengthy responses where related requirements are not applicable.

Modified p. 7 → 10

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

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

Removed p. 8

• Use the corresponding Reporting Template for v2.0 of the P2PE Standard.

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

Modified p. 9 → 12

P2PE Assessor ~~Company~~ contact information Company name: Assessor ~~Company Credentials:~~ QSA (P2PE) PA-QSA (P2PE) Assessor name: Assessor ~~Credentials:~~ QSA (P2PE) PA-QSA (P2PE) Assessor phone number: Assessor e-mail address:

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

Modified p. 9 → 12

No (if no, this is not in accordance with PCI Program requirements) ~~1.2 Date and timeframe of assessment Date of Report: Timeframe of assessment:~~

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

Removed p. 10

Description of the typical merchant that uses this solution (Include specific industries or channels the solution is intended for):

Modified p. 10 → 14

2. Summary Overview 2.1 P2PE ~~Solution~~ Details P2PE ~~solution name:~~

2. Summary Overview 2.1 P2PE Submission Details P2PE Solution name (and version if applicable):

Modified p. 10 → 14

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

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

Modified p. 10 → 14

PCI SSC Ref # ~~or N/A~~ Description of P2PE ~~solution~~ provider (e.g., payment gateway, acquirer, multi-acquirer payment processor, etc.):

PCI SSC Ref # Description of P2PE Solution provider (e.g., payment gateway, acquirer, multi-acquirer payment processor, etc.):

Removed p. 11

“Other details” is to be used as needed. For example, if there is a third-party service provider providing decryption services but it not a P2PE Component at 2.2, use “Other details” to address data such as P2PE endpoint system identifier (e.g., Host System and HSM). Mark as “n/a” if no other details are needed.

Modified p. 12 → 17

Any additional Applications on POI (add rows as needed to report all applications) Application Name: Version # CHD ~~Access?~~ Note: An Application P-ROV must be submitted and accepted by PCI SSC for all applications with access to clear-text account data and will be identified by the PCI SSC ~~listing number~~ at ~~Section~~ 2.3 ~~above.~~

Any additional Applications on POI devices (add rows as needed to report all applications) Application Name: Version # CHD Access *? (see note below) * Note: A P2PE Application P-ROV must be submitted and accepted by PCI SSC for all applications with access to clear-text account data and will be identified by the PCI SSC Reference # at Table 2.3 above (unless being assessed as part of the submitted Solution, whereby a P2PE Application P- ROV must be included).

Modified p. 12 → 18

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

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

Modified p. 12 → 18

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

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

Removed p. 13

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

Identifier PTS Approval or FIPS #: Manufacturer Model Name/ Number: Model Name/ Number: Location: # of devices per location: Purpose:

Additional details for all HSMs used in the P2PE Solution PTS Approval or Model Name/ Serial Numbers or other identifiers:

Application #(s): Approved Key Function(s):

Removed p. 14

Domain 1

• Encryption Device and Application Management Yes No Domain 2

• Application Security N/A Domain 3

• P2PE Solution Management Yes No Domain 4

• Merchant-managed Solutions N/A Domain 5

• Decryption Environment Yes No Domain 6

• P2PE Cryptographic Key Operations and Device Management Yes No Domain 6

• Annex A1: Symmetric-Key Distribution using Asymmetric Techniques Yes No N/A Domain 6

• Annex A2: Certification and Registration Authority Operations Yes No N/A Domain 6

• Annex B: Key-Injection Facilities Yes No N/A

Modified p. 14 → 19

~~Complete the following where multiple acquirers or multiple solution providers manage one or more P2PE solutions on the same~~ POI ~~device: identifier~~ Identify other P2PE solutions on the POI Is the other solution already listed, currently being assessed in a separate P2PE assessment, or included with this P2PE assessment? If solution is already listed, provide PCI SSC listing number If solution being assessed separately, identify P2PE assessor company performing assessment (if known) ~~2.8 Summary of P2PE Compliance Status P2PE Domain …~~

POI device Model Name/ Number Identify other P2PE solutions on the POI device Is the other solution already listed, currently being assessed in a separate P2PE assessment, or included with this P2PE assessment? If solution is already listed, provide PCI SSC listing number If solution being assessed separately, identify P2PE assessor company performing assessment (if known)

Removed p. 15

If the solution provider’s PCI DSS compliance does not cover all solution provider environments:

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

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

Modified p. 15 → 21

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

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

Modified p. 15 → 21

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

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

Removed p. 16

• All entities the solution connects to for payment transmission or processing, including processors/acquirers. Note: the diagram should identify where merchant entities fit into the data flow, without attempting to identify individual merchants. For example, P2PE- encrypted account data could be illustrated as flowing between an icon that represents all merchant customers and an icon that represents the solution provider’s decryption environment.

Modified p. 16 → 21

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

• Location of systems performing key-management functions

Modified p. 16 → 21

• Other necessary components, as applicable to the particular solution <Insert P2PE Solution network diagram(s)> ~~3.4 Overview of P2PE solution data flow Provide a high-level data flow diagram of the solution that illustrates:~~

• Other necessary components, as applicable to the particular solution <Insert P2PE Solution network diagram(s)>

Modified p. 16 → 22

• Flows and locations of ~~P2PE-encrypted~~ account data

• Flows and locations of encrypted account data

Modified p. 16 → 22

Removed p. 17

Note: A detailed Key Matrix is included in Domain 6.

Modified p. 17 → 23

~~• Key Archiving (if applicable)~~ Note: ~~include~~ both logical and physical components

•e.g., network traffic flows, locations of safes, use of secure couriers, etc.

Note: Include both logical and physical components•e.g., network traffic flows, locations of safes, use of secure couriers, etc.

Modified p. 17 → 23

<Insert applicable diagram(s) showing all ~~key management~~ processes> Description of Cryptographic Keys used in P2PE Solution Provide a brief description* of all types of cryptographic keys used in the solution, as follows:

<Insert applicable diagram(s) showing all key-management processes> Description of Cryptographic Keys used in P2PE Solution Provide a brief description of all types of cryptographic keys used in the solution, as follows:

Modified p. 18 → 24

List of all facilities INCLUDED in this ~~solution~~ assessment Description and purpose of facility included in assessment Address of facility List of facilities used in P2PE ~~solution~~ that were EXCLUDED from this ~~solution~~ assessment* Description and purpose of facility excluded from assessment Address of facility Explanation why the facility was excluded from the assessment Details of any separate assessments performed for the facility, including how the other assessment was verified to cover all components in scope for this ~~solution~~ * …

List of all facilities INCLUDED in this Solution assessment Description and purpose of facility included in assessment Address of facility List of facilities used in P2PE Solution that were EXCLUDED from this Solution assessment* Description and purpose of facility excluded from assessment Address of facility Explanation why the facility was excluded from the assessment Details of any separate assessments performed for the facility, including how the other assessment was verified to cover all components in scope for this Solution * …

Removed p. 19

P2PE Instruction Manual(s) (PIM):

Modified p. 19 → 25

Note: If the PIM or P2PE Application Implementation Guide consists of more than one document, the brief description below should explain the purpose of each document it includes, such as if it is for a different ~~POIs,~~ for different functions, etc.

Note: If the PIM or P2PE Application Implementation Guide consists of more than one document, the brief description below should explain the purpose of each document it includes, such as if it is for different POI devices, for different functions, etc.

Modified p. 19 → 25

Reference # (optional use) Document Name (Title of the PIM) Version Number of the PIM Document date (latest version date) Which ~~POI types are~~ addressed? (Must align with Section ~~2.5)~~ P2PE Application Implementation Guide(s) (IG):

P2PE Instruction Manual (PIM) Reference # (optional use) Document Name (Title of the PIM) Version Number of the PIM Document date (latest version date) Which P2PE Application is addressed? (Must align with Section 2.3) P2PE Application Implementation Guide(s) (IG):

Modified p. 19 → 25

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

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

Modified p. 20 → 26

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

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

Modified p. 20 → 26

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

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

Modified p. 20 → 26

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

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

Removed p. 21

4. Findings and Observations Domain 1: Encryption Device and Application Management

• Summary of Findings Domain 1: P2PE Validation Requirements Summary of Findings (check one) In Place N/A Not in 1A Account data must be encrypted in equipment that is resistant to physical and logical compromise.

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

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

1B Logically secure POI devices.

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

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

1B-3 The solution provider implements procedures to protect POI devices and applications from known vulnerabilities and securely update devices.

1B-4 Solution provider implements procedures to secure account data when troubleshooting 1B-5 The P2PE solution provides auditable logs of …

Removed p. 22

Domain 1: Encryption Device and Application Management

• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1A-1.1 Encryption operations must be performed using a POI device approved per the PCI PTS program (e.g., a PCI-approved PED or SCR), with SRED (secure reading and exchange of data). The PTS approval listing must match the deployed devices in the following characteristics:

Removed p. 22

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

• SRED listed as a function provided For each POI device type used in the solution, describe how the POI device configurations and PCI SSC list of Approved PTS Devices verified that all of the POI device characteristics at 1A-1.1 match the PTS listing:

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

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

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

Removed p. 23

Refer to Section 2.5 “PTS Devices Supported” in the Summary Overview for this documentation. No further reporting required here. 1A-1.2.b For each POI device type used in the solution, examine the device configuration to verify that it is configured by default to use only SRED-validated account-data capture mechanisms for accepting and processing P2PE transactions.

For each POI device type used in the solution, describe how the device configuration verified that each device type is configured by default to use only SRED-validated account-data capture mechanisms for accepting and processing P2PE transactions: <Report Findings Here> 1A-1.2.1 All capture mechanisms on the POI device must be SRED-validated, or must be disabled or otherwise prevented from being used for P2PE transactions such that they cannot be enabled by the merchant. 1A-1.2.1.a Examine POI configuration and deployment procedures to verify they include either:

• Disabling all capture mechanisms that are not SRED validated, or

• Implementing configurations that …

Removed p. 24

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

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

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

Documented transaction processes and data flows reviewed:

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

Identify the sample of transactions <Report Findings Here> Describe the forensic tools and/or other data tracing methods used to inspect the sample of transactions: <Report Findings Here> 1A-2.1 All applications on POI devices with access to clear-text account data must be assessed according to Domain …

Removed p. 25

• Confirmed per 1A-1.1 as a PTS-approved device(s)

• Confirmed per 1A-1.1 as a PTS-approved device(s)

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

1A-2.2.b For applications not on the PCI SSC list of Validated P2PE Applications, review the application P-ROV and verify the POI device types the application is used on are:

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

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

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

Removed p. 25

• Cannot view or access SAD

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

• Cannot enable disabled device interfaces or disabled data-capture mechanisms 1B-1.1.a Examine documented POI device configuration procedures and account privilege assignments to verify that merchant logical access to POI devices is restricted as follows:

Removed p. 25

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

• Cannot enable disabled device interfaces or disabled data-capture mechanisms Documented procedures reviewed:

<Report Findings Here> Describe how account privilege assignments verified that merchant logical access to POI devices is restricted as follows:

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

• Cannot enable disabled device interfaces or disabled data-capture mechanisms <Report Findings Here>

Removed p. 26

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

• Cannot enable disabled device interfaces or disabled data-capture mechanisms Identify the sample of POI devices used:

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

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

• Cannot enable disabled device interfaces or disabled data-capture mechanisms <Report Findings Here> 1B-1.1.c Observe a sample of POI device configurations and interview responsible personnel to verify that the defined merchant-access requirements are configured for all devices used in the solution.

<Report Findings Here> Identify the sample of POI devices used:

<Report Findings Here> Describe how the POI device configurations …

Removed p. 27

Identify any P2PE Applications at 1A-2.1 that facilitate printing of full PANs on merchant receipts:

<Report Findings Here> Refer to Section 2.3 “Listed P2PE Applications used in the P2PE Solution” in the Summary Overview for documentation of the PCI SSC listing of the P2PE Application (if this testing procedure is applicable): 1B-1.2 All solution-provider personnel with logical access to POI devices deployed in merchant encryption environments must be documented in a formal list and authorized by solution provider management. The list of authorized personnel is reviewed at least annually. 1B-1.2.a Examine documented authorizations to verify:

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

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

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

Documented authorizations reviewed:

<Report Findings Here> 1B-1.2.b For a sample of all POI device types, examine account-access configurations to verify that only personnel documented and authorized …

Removed p. 28

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

Describe how remote-access mechanisms and controls verified that either two- factor or cryptographic authentication is configured for all remote access to POI devices: <Report Findings Here> 1B-2.1.c Interview personnel and observe actual remote connection attempts to verify that either two-factor or cryptographic authentication is used for all remote access to POI devices.

Personnel interviewed: <Report Findings Here> Describe how actual remote connection attempts verified that either two-factor or cryptographic authentication is configured for all remote access to POI devices: <Report Findings Here> 1B-2.2 POI devices must be configured to ensure that remote access is only permitted from the solution provider’s authorized systems.

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

Removed p. 29

Documented identification and authentication procedures reviewed:

<Report Findings Here> 1B-2.4.b Verify documented procedures include requirements specified at 1B- 2.4.1 through 1B-2.4.3.

Identify the P2PE Assessor who confirms that documented procedures include requirements specified at 1B-2.4.1 through 1B- 2.4.3:

<Report Findings Here> 1B-2.4.1 Individual authentication credentials for all authorized solution-provider personnel that are unique for each merchant. Note: If a centralized terminal-management system (TMS) is utilized to manage multiple merchant accounts, it is acceptable for the TMS system to only require unique access for each authorized solution-provider employee accessing the TMS instead of requiring unique access per merchant. 1B-2.4.1 Examine device configurations and authentication mechanisms to verify that all authorized solution-provider personnel have individual authentication credentials that are unique for each merchant (or if applicable, per centralized TMS).

Describe how device configurations and authentication mechanisms verified that all authorized solution-provider personnel have individual authentication credentials that are unique for each merchant (or if applicable, per …

Removed p. 30

• Integrity check of update

• Authentication of origin of the update 1B-3.1.a Examine documented procedures to verify secure update processes are defined for all firmware and software updates, and include:

• Integrity checks of update

• Authentication of origin of the update Documented procedures reviewed:

<Report Findings Here> 1B-3.1.b Observe a sample of firmware and software updates, and interview personnel to verify:

• The integrity of the update is checked

• The origin of the update is authenticated Identify sample of firmware and software updates observed:

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

1B-3.2.a Examine documented procedures to verify they include:

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

• Procedures for confirming all builds at least annually and upon any changes to the build Documented procedures reviewed:

<Report Findings Here> …

Removed p. 31

<Report Findings Here> 1B-3.3.b Examine security update deployment records and device logs, and interview responsible solution provider personnel and to verify that critical security updates are deployed to devices and applications in the field within 30 days of receipt from device and application vendors.

Responsible solution provider personnel interviewed:

<Report Findings Here> Describe how the security update deployment records and device logs verified that critical security updates are deployed to devices and applications in the field within 30 days of receipt from device and application vendors. <Report Findings Here> 1B-3.4 Updates must be delivered in a secure manner with a known chain-of-trust, as defined by the vendor•e.g., in the POI device vendor's security guidance or in the P2PE application’s Implementation Guide. 1B-3.4.a Examine documented procedures for device updates to verify they follow guidance from the device or application vendor for delivering updates in a secure manner with a known chain-of-trust.

<Report Findings Here> …

Removed p. 32

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

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

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

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

• Encryption of PAN and/or SAD while stored

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

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

Identify the sample of recent troubleshooting requests:

<Report Findings Here> Describe how the data collection and storage locations for the sample of recent troubleshooting requests verified that procedures identified at 1B-4.1.a were followed: <Report Findings Here> 1B-5.1 Any changes to critical functions of POI devices must be logged•either on the device or …

Removed p. 32

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

• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) <Report Findings Here>

Removed p. 33

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

• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) <Report Findings Here> 1C-1.1 Applications with access to account data must be installed and configured to only use external communication methods specified in the application’s Implementation Guide. Aligns with 2A-3.3 1C-1.1.a Observe application and device configurations and interview personnel to verify that applications with access to account data are installed and configured to only use approved external communication methods, by following guidance in the application’s Implementation Guide.

Personnel interviewed: <Report Findings Here> Describe how application and device configurations observed verified that applications with access to account data are installed and configured to …

Removed p. 33

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

• Description and justification for the functionality

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

• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Aligns with 2A-3.4

Removed p. 34

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

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

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

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

• Documentation for all new installations and updates to whitelist functionality that includes the following: - Description and justification for the functionality - The identity of the authorized person who approved the new installation or updated functionality prior to release - Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Documented policies and procedures reviewed:

<Report Findings Here> Personnel interviewed: <Report Findings Here> 1C-1.2.1 Any whitelisting functionality must only allow the output of clear-text account data for non-PCI payment brand account/card data.

1C-1.2.1.a Observe application and device configurations and interview personnel to verify …

Removed p. 35

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

• Cryptographically authenticated by the POI device firmware, in accordance with the device vendor's security guidance or the application’s Implementation Guide.

Personnel interviewed: <Report Findings Here> Describe how the process for new installations of, or updates to, whitelisting functionality verified they are cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control: <Report Findings Here> Describe how the process for new installations of, or updates to, whitelisting functionality verified they are cryptographically authenticated by the POI device firmware, in accordance with the device vendor's security guidance or the application’s Implementation Guide <Report Findings Here> 1C-1.2.3 Any new installations of, or updates to, whitelisting functionality must follow change-control procedures that include:

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

• Coverage for both new installations …

Removed p. 36

• Review of the application vendor’s documentation to determine all logical interfaces used by the application/software.

• Documenting how the solution provider confirmed that the application has no logical interfaces that allow for storing, processing, or transmitting account data

• Authentication of the application by the POI device’s firmware

• Requiring dual control to authenticate the application

• Following this process both for new installations and for updates.

Documented solution provider’s processes reviewed:

<Report Findings Here> 1C-2.1.1 The application/software does not have any logical interfaces

•e.g., application programming interfaces (APIs)

•that allow for storing, processing, or transmitting account data. 1C-2.1.1 For each POI device type and each application that does not have a business need to access account data, review the solution provider’s documentation to verify it confirms that the application has no logical interfaces that allows for storing, processing, or transmitting account data.

Identify any application(s) without business need to access account data:

<Report Findings Here> Solution provider’s documentation …

Removed p. 36

<Report Findings Here> Describe how the process for new application installations or application updates verified that applications with no need to access clear-text account data are authenticated to the device using an approved security mechanism: <Report Findings Here> 1C-2.1.3 Require dual control for the application-signing process.

1C-2.1.3 Interview solution-provider personnel and observe processes for new application installations or application updates to confirm that application signing is performed under dual control.

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

Removed p. 37

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

• Documented approval for all changes by appropriate personnel.

• Documented reason and impact for all changes.

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

• Documented back-out procedures for application installations/updates. Note that adding a

• changed application or a

• changed POI device to a PCI-listed P2PE Solution requires the Solution Provider to undergo an assessment per PCI’s “Designated Change” process. See the P2PE Program Guide for more information. Aligns with 2C-2.1 1D-1.1.a Review the solution provider’s documented processes for implementing changes to applications, and interview solution-provider personnel, and confirm the following processes are in place:

• Guidance in the Implementation Guide is followed.

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

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

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

• Documentation includes back-out …

Removed p. 38

<Report Findings Here> Describe how the installation and update processes observed verified that new application installations and updates are cryptographically authenticated by the POI device’s firmware: <Report Findings Here> 1D-1.2.2 All applications must be cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.

1D-1.2.2 Confirm the following through interviews with responsible solution provider personnel and by observing an installation/update:

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

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

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

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

<Report Findings Here> Describe how the installation/update verified that:

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

• Cryptographic signing (or similar) …

Removed p. 39

• The solution provider retains a current copy of the Implementation Guide.

• The solution provider distributes the Implementation Guide to any outsourced integrators/resellers the solution provider uses for the P2PE solution upon obtaining updates from the application vendor.

<Report Findings Here> Documentation reviewed, in addition to the current copy of the Implementation Guide from the application vendor:

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

Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain for subsequent PCI listing of the component provider’s device-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 device-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). 1E-1.1 Track status of the encryption-management services and provide reports to solution provider …

Removed p. 39

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

Removed p. 39

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

• Number of devices deployed and change since last report.

• Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated.

Documented component provider’s procedures reviewed:

Removed p. 40

• Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated.

Documented component provider’s procedures reviewed:

Removed p. 40

• Number of devices deployed and changed since last report.

Reports reviewed for this testing procedure:

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

Removed p. 40

• Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change.

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

• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software. Note that adding, changing, or removing POI device types, P2PE applications, and/or P2PE non-payment software may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution. 1E-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:

• Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change.

• Adding, changing, and/or removing P2PE non-payment …

Removed p. 41

• Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change.

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

• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software.

Removed p. 43

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

1B-3 The solution provider implements procedures to protect POI devices and applications from known vulnerabilities and securely update devices.

1B-4 Solution provider implements procedures to secure account data when troubleshooting 1B-5 The P2PE solution provides auditable logs of any changes to critical functions of the POI device(s).

Modified p. 44 → 29

• Identification of P2PE controls covered by each third-party service ~~provider.~~ 3A-1.1.a Interview relevant personnel and review documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the overall P2PE solution.

• Identification of P2PE controls covered by each third-party service provider 3A-1.1.a Interview relevant personnel and review documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the overall P2PE solution.

Modified p. 44 → 29

~~• Identifies all components of the overall solution managed by the solution provider.~~

• Identifies all components of the overall solution that have been outsourced to third-party solution providers.

• Identifies all P2PE controls covered by each third-party service provider.

• Identifies all components of the overall solution that have been outsourced to third-party solution providers

Modified p. 44 → 29

Documented procedures reviewed: <Report Findings Here> Relevant personnel interviewed: <Report Findings Here> 3A-1.2 Current documentation (including a data-flow diagram) must include details of the account-data flow from the POI device (the point the card data is captured and encrypted) through to the point the encrypted card data is decrypted and the clear-text data exits the decryption environment. ~~3A-1.2 Examine the data-flow diagram and interview personnel to verify the diagram:~~

• Identifies all P2PE controls covered by each third-party service provider Documented procedures reviewed: <Report Findings Here> Relevant personnel interviewed: <Report Findings Here> 3A-1.2 Current documentation (including a data-flow diagram) must include details of the account-data flow from the POI device (the point the card data is captured and encrypted) through to the point the encrypted card data is decrypted and the clear-text data exits the decryption environment.

Modified p. 44 → 29

• Shows all account data flows across systems and networks from the point the card data is captured through to the point the card data exits the decryption environment. ~~• Is kept current and updated as needed upon changes to the environment.~~

• Shows all account data flows across systems and networks from the point the card data is captured through to the point the card data exits the decryption environment.

Modified p. 45 → 30

• To which region/country it applies Note that Domain 1 (at 1B-1.1.1) and Domain 2 (at 2A-3.1.2) also include requirements that must be met for any POI device and any P2PE application, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so. 3A-1.3.a Review solution provider’s documentation about the legal/regulatory obligation that requires merchants to have access to full PANs for receipt printing purposes to verify that the documentation includes at …

• To which region/country it applies Note that Domain 1 (at 1B-1.1.1) and Domain 2 (at 2A-3.1.2) also include requirements that must be met for any POI device and any P2PE application, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so.

Modified p. 45 → 30

<Report Findings Here> OR Describe how independent review verified that the exception to facilitate merchants’ access to full PANs is based on a legal/regulatory obligation and not solely for convenience: ~~<Report Findings Here> 3A-2.1 Where P2PE component providers are used, a methodology must be implemented to manage and monitor status reporting from P2PE component providers, including:~~

<Report Findings Here> OR Describe how independent review verified that the exception to facilitate merchants’ access to full PANs is based on a legal/regulatory obligation and not solely for convenience:

Modified p. 45 → 30

• Ensuring reports are received from all P2PE component providers as specified in the “Component ~~providers~~ ONLY: ~~report status~~ to ~~solution providers”~~ sections of Domains 1, 5, and/or 6 (as applicable to the component provider). • Confirming reports include at least the details specified in the “Component providers ONLY: report status to solution providers” sections of Domains 1, 5, and/or 6 (as applicable to the component provider), and any additional details as agreed between a component provider and the solution …

• Ensuring reports are received from all P2PE component providers as specified in the “Component Providers ONLY: Report Status to Solution Providers” sections of Domains 1, 5, and/or 6 (as applicable to the component provider).

Modified p. 46 → 30

~~• Ensuring reports~~ are ~~received~~ from ~~all P2PE component providers as specified in the “Component providers ONLY: report status to solution providers”~~ sections of Domains 1, 5, and/or 6 (as applicable to the component ~~provider).~~

• Confirming reports include at least the details specified in the “Component providers ONLY: report status to solution providers” sections of ~~Domains 1, 5, and/or 6~~ (as applicable to the component provider), and any additional details as agreed between a component provider and the solution ~~provider.~~

• …

<Report Findings Here> 3A-2.1 Where P2PE component providers are used, a methodology must be implemented to manage and monitor status reporting from P2PE component providers, including:

• Confirming reports include at least the details specified in the “Component Providers ONLY: Report Status to Solution Providers” sections of Domains 1, 5, and/or 6 (as applicable to the component provider), and any additional details as agreed between a component provider and the solution provider.

• Following up with the component provider to resolve any …

Modified p. 46 → 31

• Ensuring reports are received from all P2PE component providers as specified in the “Component providers ONLY: report status to solution providers” sections of ~~Domains 1, 5, and/or 6~~ (as applicable to the component provider).

• Confirming reports include at least the details specified in the “Component providers ONLY: report status to solution providers” sections of Domains 1, 5, and/or 6 (as applicable to the component provider), and any additional details as agreed between a component provider and the solution provider.

• …

• Ensuring reports are received from all P2PE component providers as specified in the “Component providers ONLY: report status to solution providers” sections of this Standard (as applicable to the component provider)

Modified p. 46 → 31

Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe the processes observed that verified that the solution provider has implemented a methodology for managing and monitoring status reporting from P2PE component providers, including processes for:

• Following up with the component provider to resolve any questions or changes in expected performance of the component provider Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe the processes observed that verified that the solution provider has implemented a methodology for managing and monitoring status reporting from P2PE component providers, including processes for:

Modified p. 46 → 31

• Changes in overall solution architecture Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> ~~3A-2.2.b For a sample of changes, verify changes were documented and the solution updated accordingly.~~

• Changes in overall solution architecture Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here>

Modified p. 46 → 32

• Encryption/decryption failures Note: ~~“immediate”~~ means promptly or as soon as possible.

• Encryption/decryption failures Note: “Immediate” means promptly or as soon as possible.

Modified p. 47 → 32

• Encryption/decryption failures Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 3A-3.2 Upon detection of any suspicious activity defined at ~~3B-4.1,~~ the POI device must be immediately removed, shut down, or taken offline until the integrity of the device is verified and the P2PE encryption mechanism is restored. 3A-3.2 Review documented procedures and interview responsible personnel to verify that upon detection of any suspicious activity defined at 3A-4.1, POI devices are immediately removed, shut down, or taken …

• Encryption/decryption failures Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 3A-3.2 Upon detection of any suspicious activity defined at 3A-3.1, the POI device must be immediately removed, shut down, or taken offline until the integrity of the device is verified and the P2PE encryption mechanism is restored.

Modified p. 47 → 32

Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> ~~3A-3.2.1 The POI device must not be re-enabled until it is confirmed that either:~~

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

Modified p. 47 → 33

• The merchant has provided written notification (signed by a merchant executive officer) formally requesting stopping of P2PE encryption services, according to the solution provider’s procedures (as defined in Requirement ~~3B-5.1). 3A-3.2.1 Examine documented procedures and interview personnel to verify the POI devices must not be re-enabled until it is confirmed that either:~~

• The merchant has provided written notification (signed by a merchant executive officer) formally requesting stopping of P2PE encryption services, according to the solution provider’s procedures (as defined in Requirement 3A-4.1).

Modified p. 47 → 33

• The issue has been resolved and P2PE encryption functionality is restored and re-enabled, or • The merchant has provided written notification (signed by a merchant executive officer) requesting stopping of P2PE encryption services, according to the solution provider’s procedures (as defined in Requirement 3B-5.1).

• The issue has been resolved and P2PE encryption functionality is restored and re-enabled, or

Modified p. 47 → 33

Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 3A-3.3 The solution provider must maintain a ~~record~~ of all suspicious activity, to include the following:

Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 3A-3.3 The solution provider must maintain a record, at minimum of one year, of all suspicious activity, to include the following:

Modified p. 47 → 33

• Details of whether any account data was transmitted from the POI device(s) 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(s) during the time that encryption was malfunctioning or disabled

Modified p. 48 → 34

• Identification of affected device(s), including make, model, and serial number ~~• Identification of affected merchant, including specific sites/locations if applicable~~

• Identification of affected device(s), including make, model, and serial number

Modified p. 48 → 34

• Details of whether any account data was transmitted from the POI device(s) during the time that encryption was malfunctioning or ~~disabled.~~

• Details of whether any account data was transmitted from the POI device(s) during the time that encryption was malfunctioning or disabled Documented procedures reviewed: <Report Findings Here> Related records reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 3A-3.4 Procedures must incorporate any applicable incident response procedures defined by the PCI payment brands, including timeframes for reporting incidents.

Modified p. 48 → 34

Related records reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 3A-3.4 Procedures must incorporate any applicable incident response procedures defined by the PCI payment brands, including timeframes for reporting incidents. 3A-3.4.a Examine documented incident-response plans to verify they incorporate procedures defined by all applicable PCI payment brands, including timeframes for reporting incidents.

3A-3.4.a Examine documented incident-response plans to verify they incorporate procedures defined by all applicable PCI payment brands, including timeframes for reporting incidents.

Modified p. 48 → 34

<Report Findings Here> ~~3A-3.5.b~~ Interview responsible personnel to verify that any response procedures defined by all applicable PCI payment brands, including timeframes for reporting incidents, are known and implemented.

<Report Findings Here> 3A-3.4.b Interview responsible personnel to verify that any response procedures defined by all applicable PCI payment brands, including timeframes for reporting incidents, are known and implemented.

Modified p. 48 → 34

• Updating the solution and/or controls to prevent cause from recurring ~~3A-3.5.a Interview responsible personnel and review documentation to verify the solution provider has a formal process for any P2PE control failures, including procedures for addressing the following:~~

• Updating the solution and/or controls to prevent cause from recurring

Modified p. 48 → 35

• Identifying and addressing any security issues that occurred during the failure ~~• Implementing controls to prevent cause from recurring Responsible personnel interviewed: <Report Findings Here> Documentation reviewed: <Report Findings Here>~~

• Identifying and addressing any security issues that occurred during the failure

Removed p. 49

Sample of P2PE control failures: <Report Findings Here> Supporting document reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 3A-4.1 If the solution provides an option to allow merchants to stop P2PE encryption of account data, the solution provider must document and implement a process for merchants that includes the following: 3A-4.1 If the solution provides an option to allow merchants to stop P2PE encryption of account data, examine documented procedures to verify the solution provider has a documented process for merchants to follow that includes the requirements specified at 3A-4.1.1 and 3A-4.1.2.

Documented procedures for merchants reviewed:

<Report Findings Here> 3A-4.1.1 P2PE encryption of account data for a merchant is stopped only upon receipt by the solution provider of a formal request from the merchant (signed by a merchant executive officer). 3A-4.1.1 Interview responsible personnel and observe processes to verify that P2PE encryption of account data for a merchant is …

Removed p. 49

• Date request received

• Copy of the formal notification from merchant 3A-4.1.2 Observe implemented processes and interview responsible personnel to verify a record of all received requests is maintained and includes:

• Date initial request received

• Date initial request received

• Copy of the formal notification from merchant Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that a record of all received requests is maintained and includes:

• Copy of the formal notification from merchant <Report Findings Here>

Removed p. 50

Documented procedures reviewed: <Report Findings Here> 3B-1.1.b If the solution provider utilizes any third parties, examine the business agreements and verify the elements delineated in 3C-1.1.a are present and adequately accounted for.

Modified p. 50 → 35

• Agreement to provide reports to solution provider as required in the “Component ~~providers~~ ONLY: ~~report status~~ to ~~solution providers”~~ section of the applicable P2PE Domain. 3B-1.1.a Examine documented procedures to verify the solution provider has a formalized process in place to establish agreements with all third parties performing services or functions governed by any other domain within this standard. The formalized agreement must include:

• Agreement to provide reports to solution provider as required in the “Component Providers ONLY: Report Status to Solution Providers” section of the applicable P2PE Domain.

Modified p. 50 → 36

• Maintaining compliance with applicable P2PE and/or PCI DSS requirements as needed ~~• Agreement to provide proof of compliance with P2PE requirements and/or~~

• Maintaining compliance with applicable P2PE and/or PCI DSS requirements as needed

Modified p. 50 → 36

~~PCI DSS requirements as needed~~

• Agreement to provide reports to solution provider as required in the “Component providers ONLY: report status to solution providers” section of the applicable P2PE ~~Domain.~~

• Agreement to provide reports to solution provider as required in the “Component providers ONLY: report status to solution providers” section of the applicable P2PE Domain Documented procedures reviewed: <Report Findings Here> 3B-1.1.b If the solution provider utilizes any third parties, examine the business agreements and verify the elements delineated in 3B-1.1.a are present and adequately accounted for.

Modified p. 50 → 36

Identify the P2PE Assessor who confirms that the business agreements for third parties utilized by the solution provider were reviewed and verified to have the elements delineated in ~~3C-~~ 1.1.a present and adequately accounted for:

Identify the P2PE Assessor who confirms that the business agreements for third parties utilized by the solution provider were reviewed and verified to have the elements delineated in 3B- 1.1.a present and adequately accounted for:

Modified p. 51 → 36

• Notification of any changes ~~to POI devices,~~ P2PE ~~applications, P2PE non-payment software, and/or HSMs per PCI SSC’s process for P2PE Designated Changes to Solutions~~

• Notification of any changes that require a Designated Change per the P2PE Program Guide

Modified p. 51 → 36

• Details of the change, including reason

• Details of the change, including the reason for the change

Modified p. 51 → 36

• Updated list of POI devices, P2PE applications, ~~P2PE non-payment software,~~ and/or ~~HSMs~~ used in the solution

• Updated list of any dependencies included in the Designated Change (e.g., POI devices, P2PE applications, , and/or HSMs) used in the solution

Modified p. 51 → 36

• Evidence of adherence to PCI’s process for P2PE Designated Changes to Solutions ~~3B-1.2 Verify formal agreements established for all third parties managing SCDs on behalf of the solution provider require:~~

• Evidence of adherence to PCI’s process for P2PE Designated Changes to Solutions

Modified p. 51 → 37

• Details of the change, including reason

• Details of the change, including the reason for the change

Modified p. 51 → 37

• Notification of any changes ~~to POI devices,~~ P2PE ~~applications, P2PE non- payment software, and/or HSMs per PCI SSC’s process for P2PE Designated Changes to Solutions~~

• Notification of any changes that require a Designated Change per the P2PE Program Guide

Modified p. 51 → 37

~~• Updated list of POI devices, P2PE applications, P2PE non-payment software, and/or HSMs used in the solution~~

• Evidence of adherence to PCI’s process for P2PE Designated Changes to Identify the P2PE Assessor who confirms that the business agreements for third parties managing SCDs on behalf of the solution provider were reviewed and verified to require all elements at 3B-1.2:

• Evidence of adherence to PCI’s process for P2PE Designated Changes to Solutions Identify the P2PE Assessor who confirms that the business agreements for third parties managing SCDs on behalf of the solution provider were reviewed and verified to require all elements at 3B-1.2:

Modified p. 51 → 37

<Report Findings Here> 3C-1.1 The PIM must be developed, maintained, distributed to merchants, and provided to merchants upon request. Content for the PIM must be in accordance with the mandatory PIM Template. ~~3C-1.1.a Examine the P2PE Instruction Manual (PIM) to verify it covers all related instructions, guidance and requirements as specified in the PIM Template.~~

<Report Findings Here> 3C-1.1 The PIM must be developed, maintained, distributed to merchants, and provided to merchants upon request. Content for the PIM must be in accordance with the mandatory PIM Template.

Modified p. 51 → 37

Responsible personnel interviewed: <Report Findings Here> Describe processes observed to verify PIM is distributed to all merchants using the P2PE solution and that the PIM is provided to merchants upon request: ~~<Report Findings Here> 3C-1.1.d Examine the PIM to verify that all devices specified in the PIM are PCI-approved POI devices that were assessed as part of this P2PE solution assessment.~~

Responsible personnel interviewed: <Report Findings Here> Describe processes observed to verify PIM is distributed to all merchants using the P2PE solution and that the PIM is provided to merchants upon request:

Modified p. 52 → 38

~~• All P2PE applications specified in the PIM are assessed for this solution (per Domain 1)~~

• All P2PE applications specified in the PIM are either PCI-listed P2PE applications or assessed to Domain 2 as part of this P2PE solution assessment Identify the P2PE Assessor who confirms that all P2PE applications specified in the PIM are assessed for this solution (per Domain 1) and that all P2PE applications specified in the PIM are either PCI-listed P2PE applications or assessed to Domain …

• All P2PE applications specified in the PIM are either PCI-listed P2PE applications or assessed to Domain 2 as part of this P2PE solution assessment.

Modified p. 52 → 38

• The PIM instructions ~~result in~~ a securely installed P2PE solution.

• The PIM instructions facilitate a securely installed P2PE solution.

Modified p. 52 → 38

Describe how it was confirmed that by configuring each POI device type, settings, etc. in accordance with all instructions in the PIM, the PIM provides accurate instructions and those instructions ~~result in~~ a securely installed P2PE solution: <Report Findings Here> 3C-1.2 Review P2PE Instruction Manual (PIM) at least annually and upon changes to the solution or the P2PE requirements. Update PIM as needed to keep the documentation current with:

Describe how it was confirmed that by configuring each POI device type, settings, etc. in accordance with all instructions in the PIM, the PIM provides accurate instructions and those instructions facilitate a securely installed P2PE solution:

Modified p. 52 → 38

• Any changes to the requirements in this document. ~~3C-1.2.a Examine documented procedures to verify they include:~~

• Any changes to the requirements in this document.

Modified p. 52 → 40

• PIM must be reviewed at least annually and upon changes to the solution or changes to the P2PE requirements ~~• PIM must be updated as needed to keep the document current with:~~

• PIM must be reviewed at least annually and upon changes to the solution or changes to the P2PE requirements

Modified p. 52 → 40

Documented procedures reviewed: <Report Findings Here>

Documented procedures reviewed: <Report Findings Here> 3C-1.2.b Observe processes for reviewing and updating the PIM, and interview responsible personnel to verify:

Modified p. 53 → 40

• PIM is reviewed at least annually and upon changes to the solution or changes to the PCI P2PE requirements ~~• PIM is updated as needed to keep the document current with:~~

• PIM is reviewed at least annually and upon changes to the solution or changes to the PCI P2PE requirements

Modified p. 53 → 40

- Any changes to the P2PE solution (including additions or removals of POI device types, P2PE applications, and/or P2PE non-payment software), and - Any changes to the P2PE ~~requirements.~~

- Any changes to the P2PE solution (including additions or removals of POI device types, P2PE applications, and/or P2PE non-payment software), and - Any changes to the P2PE requirements Responsible personnel interviewed: <Report Findings Here> Describe how processes for reviewing and updating the PIM verified that the PIM is updated at least annually, upon changes to the solution or changes to the PCI P2PE requirements, and as needed to keep the document current with any changes to the P2PE solution …

Modified p. 53 → 40

~~Responsible personnel interviewed: <Report Findings Here> Describe how processes for reviewing and updating the PIM verified that the~~ PIM is updated ~~at least annually, upon changes to the solution or changes to the PCI P2PE requirements, and~~ as needed to keep the document current ~~with any changes to the P2PE solution and any changes to the P2PE requirements:~~ <Report Findings Here> 3C-1.2.1 Communicate PIM updates to affected merchants, and provide merchants with an updated PIM as needed.

• PIM is updated as needed to keep the document current with: <Report Findings Here> 3C-1.2.1 Communicate PIM updates to affected merchants, and provide merchants with an updated PIM as needed.

Modified p. 53 → 40

Responsible personnel interviewed: <Report Findings Here> Describe how processes for reviewing and updating the PIM verified that PIM updates are communicated to affected merchants and an updated PIM is provided to merchants as needed: ~~<Report Findings Here>~~

Responsible personnel interviewed: <Report Findings Here> Describe how processes for reviewing and updating the PIM verified that PIM updates are communicated to affected merchants and an updated PIM is provided to merchants as needed:

Removed p. 55

5A-1 Use approved decryption devices 5B Secure the decryption environment.

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

5C Monitor the decryption environment and respond to incidents.

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

5D Implement secure, hybrid decryption processes.

5D-1 Configure the Host System securely.

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

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

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

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

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

Removed p. 56

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

• PCI PTS HSM approved. 5A-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 Level 3 (overall), or higher. Refer to http://csrc.nist.gov.

• 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> 5A-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 5A-1.1.a.

<Report Findings Here> Personnel interviewed: <Report Findings Here> 5A-1.1.1 The approval listing must match the deployed devices in the …

Removed p. 57

• Firmware version 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 5A-1.1.1.b match the FIPS140-2 Level 3 (or higher) approval listing: <Report Findings Here> 5A-1.1.1.c If the solution provider has applied a vendor security patch that resulted in an

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

Vendor documentation reviewed: <Report Findings Here> 5A-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. Note: Solution providers operating HSMs in non-FIPS mode or adding non-FIPS validated software must complete a written confirmation that includes the following:

• Description of why …

Removed p. 58

Describe how HSM configurations for all P2PE security functions verified that HSMs are configured to operate according to the security policy that was included as part of the PTS approval: <Report Findings Here> 5B-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. 5B-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 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> Documented procedure reviewed: <Report Findings Here> 5B-1.1.b Interview responsible personnel and review solution-provider documentation that describes/illustrates the configuration of the decryption environment, including the flow of …

Removed p. 58

• Console and non-console administration

Removed p. 58

• Use of HSM commands

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

Removed p. 59

• Use of HSM commands Documented procedures reviewed:

<Report Findings Here> 5B-1.2.b Observe authorized personnel performing device-administration operations to verify secure administration procedures are implemented for the following:

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

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

Files/records examined: <Report Findings Here> Describe how the observation verified that only authorized and assigned personnel perform decryption-device administration operations: <Report Findings Here> 5B-1.3 Only authorized users/processes have the ability to make function calls to the HSM

•e.g., via the HSM’s application program interfaces (APIs). For example, require authentication for use of the HSMs APIs and secure all authentication credentials from unauthorized access. Where an HSM is unable to authenticate use of the …

Removed p. 60

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

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

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

<Report Findings Here> 5B-1.4.c Interview responsible personnel and observe a sample of device authentications to verify the following:

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

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

<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: <Report Findings Here> 5B-1.5 Physical inspections of decryption devices by authorized personnel must be performed at least quarterly to detect tampering or modification of devices. Inspections to include:

Removed p. 60

• Physically connected devices 5B-1.5.a Examine documented procedure to verify that physical 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> 5B-1.5.b Interview personnel performing physical 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> 5B-1.5.c Interview personnel performing inspections and review supporting documentation to verify that physical inspections are performed at least quarterly.

Personnel performing inspections interviewed:

<Report Findings Here> Supporting documentation reviewed:

Removed p. 61

PCI DSS Report on Compliance (ROC) reviewed:

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

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

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

• Performed within the previous 12 months

<Report Findings Here> 5B-1.7 Processes are implemented to ensure that clear-text account data is never sent back to the encryption environment. 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 5B-1.9 5B-1.7.a Review documented processes and …

Removed p. 62

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

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

• Cryptographic authentication by the HSM

• Cryptographic authentication by the HSM

• Documentation for all new installations or updates to whitelist functionality that includes the following: o Description and justification for the functionality o Who approved the new installation or updated functionality prior to release o Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 5B-1.9 Review documented policies and procedures to verify that that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment ensures the that the ONLY allowed output of clear-text account data is for non-PCI payment brand account/card data, and includes the following:

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

Removed p. 63

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

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

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

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

• Cryptographically authenticated by the HSM Personnel interviewed: <Report Findings Here> Describe how the observed process verified that additions …

Removed p. 64

• Changes to the applications

• Changes to the applications

• Changes to the firmware

• Changes to the firmware

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

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

Removed p. 64

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

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

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

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

Removed p. 64

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

• Unauthorized use of the HSM API Documented procedures reviewed:

<Report Findings Here> 5C-1.2.b Interview personnel and observe implemented mechanisms to verify mechanisms are implemented to detect and respond to suspicious activity, including:

• Unauthorized logical alterations (configuration, access controls)

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

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

Removed p. 65

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

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

<Report Findings Here> 5C-1.3.1 Checking for incoming clear-text account data.

5C-1.3.1.a Observe implemented processes to verify 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 clear-text account data: <Report Findings Here> 5C-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.

Describe the implemented controls and notification mechanisms observed that detect and provide immediate notification upon detection of incoming clear-text account data: <Report Findings Here> 5C-1.3.1.c Interview personnel to verify that designated personnel are immediately notified upon detection of incoming clear-text account data.

Personnel interviewed: <Report Findings Here> 5C-1.3.2 Detecting and reviewing any cryptographic errors …

Removed p. 66

Describe how the implemented processes observed verified that controls are in place to detect and review and unexpected transaction data received: <Report Findings Here> 5C-1.3.3.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification for any unexpected transaction data received.

Describe the implemented controls and notification mechanisms observed that detect and provide immediate notification for any unexpected transaction data received: <Report Findings Here> 5C-1.3.3.c Interview personnel to verify that designated personnel are immediately notified upon detection of any unexpected transaction data received.

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

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

Removed p. 66

• Details of whether any account data was transmitted from the POI device during any identified time that encryption was malfunctioning or disabled

Removed p. 67

• 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> 5C-1.4.b Observe implemented controls and interview responsible personnel to verify that the source of any suspicious activity is identified, and records are maintained to include the following:

• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled Responsible personnel interviewed:

<Report Findings Here> Describe how the implemented controls verified that the source of any suspicious activity is identified, and records are maintained to include the following:

• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled <Report Findings Here> 5C-1.5 Implement mechanisms to provide immediate notification of suspicious activity to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if …

Removed p. 68

Personnel interviewed: <Report Findings Here> Describe how the implemented mechanisms observed verified that immediate notification of suspicious activity is provided to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if decryption services are being performed on behalf of other P2PE solution providers): <Report Findings Here> 5D-1.1 The solution provider must maintain current documentation that describes, or illustrates, the configuration of the Host System, including the flow of data and interconnectivity between all systems within the decryption environment. 5D-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.

<Report Findings Here> Documented procedure reviewed: <Report Findings Here> 5D-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 …

Removed p. 69

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

Describe how network and system configuration settings verified that the Host System(s) and HSM(s) are located on a network that is segmented from other networks not required for decryption operations or transaction processing: <Report Findings Here> 5D-1.4 All application software installed on the Host System must be authorized and have a business justification.

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

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

Change control and system configuration records reviewed:

<Report Findings Here> 5D-1.4.c Inspect Host System …

Removed p. 69

• Testing integrity of firmware.

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

Removed p. 70

• Testing integrity of software/firmware.

• Testing integrity of software/firmware.

Vendor/solution provider documentation reviewed:

Vendor/solution provider documentation reviewed:

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

• Testing integrity of any security functions critical to the secure operation of the Host System. <Report Findings Here> 5D-1.6.b Review logs/audit trails from when the Host System has previously been powered-up and interview personnel, to verify that the Host System performs a self-test to ensure its integrity before use. Verify the self-tests included the tests described in 5D-1.6.a.

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

Removed p. 70

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

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

Removed p. 71

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

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

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

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

• Failure of a security function or mechanism <Report Findings Here> 5D-1.8.b Interview personnel and examine logs/records of actual or test alerts to verify that alerts are generated and received when the Host System enters an error state under one of the following conditions:

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

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

<Report Findings Here> 5D-1.9 Alerts generated from the …

Removed p. 71

• During self-tests, as described in Requirements 5D-1.6 and 5D-1.7

Removed p. 72

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

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

• During diagnostics of cryptographic operations <Report Findings Here> 5D-1.11 All source code and executable code for cryptographic software and firmware on the Host System must be protected from unauthorized disclosure and unauthorized modification. 5D-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.

Configuration documentation inspected:

<Report Findings Here> 5D-1.11.b Observe access controls for cryptographic software and firmware to verify that all source code and executable code …

Removed p. 73

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

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

Removed p. 73

• ‘Core dumps’ of memory required for troubleshooting. In the above circumstances, the following conditions apply: 5D-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:

• Core dumps’ of memory required for trouble-shooting.

Documented configuration procedures reviewed:

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

• ‘Core dumps’ of memory required for trouble-shooting.

Personnel interviewed: <Report Findings Here> Describe how the Host System configuration settings examined verified that clear-text cryptographic keys are not written to persistent storage except in the following circumstances:

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

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

5D-1.14.1.a Review Host …

Removed p. 74

Describe how the Host System configuration settings and storage locations examined verified that ‘swap/page’ files and ‘core dumps’ are written to a dedicated hard drive on its own bus on the Host System: <Report Findings Here> 5D-1.14.3 The swap/page files and/or core dumps must never be backed up or copied.

5D-1.14.3.a Examine backup configuration settings for the Host System and storage locations to verify that ‘swap/page’ files and ‘core dumps’ are not backed up.

Describe how the backup configuration settings for the Host System and storage locations examined verified that ‘swap/page’ files and ‘core dumps’ are not backed up: <Report Findings Here> 5D-1.14.3.b Examine configurations of storage locations to verify that ‘swap/page’ files and ‘core dumps’ cannot be copied off the storage locations.

Describe how the configurations of storage locations examined verified that ‘swap/page’ files and ‘core dumps’ cannot be copied off the storage locations: <Report Findings Here> 5D-1.14.4 Access to, and the …

Removed p. 75

Describe the forensic tools and/or methods used to verify that the secure procedure removes ‘swap/page’ files and ‘core dumps’, in accordance with industry-accepted standards for secure deletion of data: <Report Findings Here> 5D-2.1 Host user passwords must be

• changed at least every 30 days. Note: This requirement applies to all user roles associated to persons with access to the Host System. 5D-2.1.a Examine documented policies and procedures to verify that the Host System (s) user passwords must be

• changed at least every 30 days.

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

Describe how the Host System configuration settings inspected verified that user password parameters are set to require users to change passwords at least every 30 days: <Report Findings Here> 5D-2.2 User passwords must meet the following:

Removed p. 75

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

• Have equivalent strength/complexity.

• Have equivalent strength/complexity.

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

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

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

Log-on security tokens in use: <Report Findings Here> Describe how log-on …

Removed p. 76

Describe how the token-configuration settings examined verified that parameters are set to require that PINs or password/passphrases be at least ten alphanumeric characters in length, or equivalent: <Report Findings Here> 5D-2.4 User accounts must be locked out of the Host System after not more than five failed attempts.

5D-2.4.a Examine documented policies and procedures to verify that authentication parameters on the Host System must be set to require that a user’s account be locked out after not more than five invalid logon attempts.

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

Describe how the Host System configuration settings inspected verified 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> 5D-2.5 The Host …

Removed p. 76

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

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

Removed p. 77

• auditing of host functions.

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

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

Sample of users for each role interviewed:

<Report Findings Here> 5D-2.6 The segregation of duties must be enforced between roles, through automated or manual processes, to ensure that no one person is able to control end- to-end processes; or be in a position to compromise the security of the Host System. The following conditions must be applied: 5D-2.6.1 A Host System user must not be permitted to audit their own activity on the Host System.

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

<Report …

Removed p. 77

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

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

Removed p. 78

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

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

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

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

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

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

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

• Ensuring all changes to access privileges result in an audit log. <Report Findings Here> 5D-2.7.c Inspect the Host System configuration settings and, for a sample of user accounts, verify that …

Removed p. 79

Identify the tamper-detection mechanisms observed:

<Report Findings Here> Describe how the observed tamper-detection mechanisms are implemented and include the generation of an alert upon opening of the Host System case, covers and/or doors: <Report Findings Here> 5D-2.9.c Review records of alerts and interview personnel to verify an alert is generated upon opening of the Host System, covers and/or doors.

Records of alerts reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 5D-3.1 All non-console access to the Host System must use strong cryptography and security protocols 5D-3.1.a For a sample of systems that are authorized to connect to the Host System via a non-console connection, inspect configuration settings to verify that access to the Host System is provided through the use of strong cryptography and security protocols Sample of systems reviewed: <Report Findings Here> Describe how the configuration settings inspected verified that access to the Host System is provided through the use …

Removed p. 80

Describe how the configuration settings of the Host System and/or the device permitted to connect to the Host System verified that two-factor authentication is required for non-console access to the Host System: <Report Findings Here> 5D-3.3.b Observe a Host System administrator log on to the device that provides non-console access to the Host System to verify that two-factor authentication is required.

Describe how the Host System administrator’s log on to the device that provides non-console access to the Host System verified that two-factor authentication is required: <Report Findings Here> 5D-3.4 Non-console connections to the Host System must only be permitted from authorized systems.

5D-3.4.a Examine documented policies and procedures to verify that a process is defined to authorize systems for non-console access, and not permit access until such times that authorization has been granted.

<Report Findings Here> 5D-3.4.b For a sample of systems, examine device configurations to verify that non-console access is permitted …

Removed p. 81

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

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

<Report Findings Here> 5D-3.6.b Examine a sample of access control records and compare them to Host System settings to verify that non-console access to the Host System is only provided to authorized users.

Sample of access control records reviewed:

<Report Findings Here> Describe how the sample of access control records compared to Host System settings verified that non-console access to the Host System is only provided to authorized users: <Report Findings Here> 5D-3.7 Non-console sessions to the Host System must be terminated after 15 minutes of inactivity.

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

<Report Findings …

Removed p. 82

Physical access controls examined:

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

Describe how observation of authorized personnel entering the secure room verified that all individuals are identified and authenticated before being granted access: <Report Findings Here> 5D-4.3 All physical access to the secure room must be monitored and logs must be maintained as follows:

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

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

• Log reviews must be documented.

• Logs must include but not be limited to:

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

• Logs of access to the room from a manual sign-in sheet 5D-4.3.a Examine documented policies and procedures to verify all physical access to the …

Removed p. 83

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

Describe how observation of authorized personnel entering the secure room verified that dual control is enforced: <Report Findings Here> 5D-4.5 Physical access must be only permitted to designated personnel with defined business needs and duties.

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

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

Documented list of designated personnel:

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

Describe how physical access controls verified that physical access to …

Removed p. 83

• Access to the Host System and HSM(s) Note: Motion-activated systems that are separate from the intrusion-detection system may be used. 5D-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, as a minimum, the following areas:

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

<Report Findings Here> Describe how CCTV configurations observed verified that CCTV monitoring is in place on a 24 hour basis, and covers, as a minimum, the following areas:

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

Describe how system configurations for the motion-activated systems verified that they are separate from the intrusion-detection systems: <Report Findings Here> 5D-4.7 Surveillance cameras must not be configured to …

Removed p. 84

Sample of CCTV recordings reviewed:

Sample of CCTV recordings reviewed:

<Report Findings Here> Describe how observed CCTV camera positioning and the sample of recordings verified that CCTV cameras do not monitor any computer screens, PIN pads, keyboards, or other systems which may expose sensitive data: <Report Findings Here> 5D-4.8 CCTV recorded images must be securely archived for at least 45 days. If digital-recording mechanisms are used, they must have sufficient storage capacity and redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period. 5D-4.8.a Examine a sample of recordings to verify that at least the most recent 45 days of images are securely archived.

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

Describe how system configurations observed verified …

Removed p. 85

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

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

Removed p. 85

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

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

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

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

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

• It is connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room. <Report Findings Here> 5D-4.12 Any windows in the secure room must be locked, protected by alarmed sensors, or otherwise similarly secured.

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

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

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

Describe how configuration …

Removed p. 86

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

Describe how security-system configurations and documented alarm events verified that all alarm events are logged: <Report Findings Here> 5D-4.16 Documented alarm events must be signed off by an authorized person who was not involved in the event.

5D-4.16.a Examine security policies and procedures to verify alarm events must be signed off by an authorized person other than the individual who was involved in the event.

<Report Findings Here> 5D-4.16.b For a sample of documented alarm events, interview personnel who signed off on the event to verify that person was not involved in the event.

Sample of documented alarm events reviewed:

<Report Findings Here> Signing personnel interviewed: <Report Findings Here> 5D-4.17 Use of an emergency entry or exit mechanism must cause an alarm event.

5D-4.17 Examine security system configurations to verify that an alarm event is generated upon …

Removed p. 87

Describe how system configurations for access, intrusion-detection, and monitoring (camera) systems verified that time and date stamps are synchronized: <Report Findings Here> 5D-4.19.c Examine a sample of logs from the access, intrusion-detection, and monitoring (camera) systems to verify log time and date stamps are synchronized.

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

<Report Findings Here> 5D-4.19.1 If a manual synchronization process is used, synchronization must occur at least quarterly, and documentation of the synchronization must be retained for at least a one-year period. 5D-4.19.1.a If a manual synchronization process is implemented, interview responsible personnel and examine records of synchronization to verify the mechanism is performed at least quarterly.

<Report Findings Here> Records of synchronization examined:

<Report Findings Here> 5D-4.19.1.b Examine records of the synchronization process to verify that documentation is retained for at least one year.

Records of synchronization examined:

<Report Findings Here> 5D-4.20 The entrance to the secure room must include …

Removed p. 88

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

Removed p. 88

• Details of any suspicious activity that occurred, per 5C-1.2 5E-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:

• Providing reports annually and upon significant changes

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

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

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

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

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

• Addition and/or removal of HSM types.

Removed p. 88

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

Removed p. 89

• Changes to PCI DSS compliance status

• Changes to PCI DSS compliance status

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

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

• Additions and/or removal of HSM types.

Identify reports reviewed: <Report Findings Here>

Removed p. 90

6A-1 Account data is protected with appropriate cryptographic algorithms, key sizes and strengths, and key-management processes.

6B Account-data keys and key-management methodologies are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.

6B-1 All keys and key components are generated using an approved random or pseudo-random process.

6B-2 Compromise of the key generation process must not be possible without collusion between at least two trusted individuals.

6B-3 Documented procedures must exist and must be demonstrably in use for all key-generation processing.

6C Keys are conveyed or transmitted in a secure manner.

6C-1 Secret or private keys shall be transferred by:

a) Physically forwarding the key as at least two separate key shares or full-length components (hard copy, smart card, SCD) using different communication channels, or

b) Transmitting the key in ciphertext form.

Public keys must be conveyed in a manner that protects their integrity …

Removed p. 90

6C-4 Documented procedures must exist and must be demonstrably in use for all key transmission and conveyance processing.

Removed p. 91

6D-1 Secret and private keys must be input into hardware (host) security modules (HSMs) and Point of Interaction (POI) devices in a secure manner.

a) Unencrypted secret or private keys must be entered into cryptographic devices using the principles of dual control and split knowledge.

b) Key-establishment techniques using public-key cryptography must be implemented securely.

6D-2 The mechanisms used to load secret and private keys•such as terminals, external PIN pads, key guns, or similar devices and methods•must be protected to prevent any type of monitoring that could result in the unauthorized disclosure of any component.

6D-3 All hardware and access/authentication mechanisms (e.g., passwords) used for key loading or the signing of authenticated applications (e.g., for “whitelists”) must be managed under dual control.

Removed p. 91

6D-5 Documented procedures must exist and be demonstrably in use (including audit trails) for all key-loading activities.

Removed p. 91

6E-1 Unique, secret cryptographic keys must be in use for each identifiable link between host computer systems of two organizations or logically separate systems within the same organization.

Removed p. 92

6F-3 Keys generated using reversible key-calculation methods, such as key variants, must only be used in SCDs that possess the original key.

Keys generated using reversible key-calculation methods must not be used at different levels of the key hierarchy. For example, a variant of a key-encryption key used for key exchange must not be used as a working key or as a Master File Key for local storage.

Keys generated with a non-reversible process, such as key derivation or transformation process with a base key using an encipherment process, are not subject to these requirements.

6F-4 Secret and private keys and key components that are no longer used or have been replaced must be securely destroyed.

Removed p. 92

a) Limited to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use; and

b) Protected such that no other person (not similarly entrusted with that component) can observe or otherwise contain the component.

6F-6 Logs must be kept for any time that keys, key components or related materials are removed from storage or loaded to an SCD.

6F-7 Backups of secret and private keys must exist only for the purpose of reinstating keys that are accidentally destroyed or are otherwise inaccessible. The backups must exist only in one if the allowed storage forms for that key.

Note: It is not a requirement to have backup copies of key components or keys.

Removed p. 93

6G-1 Equipment used to protect account data (e.g., POI devices and HSMs) must be placed into service only if there is assurance that the equipment has not been substituted or subjected to unauthorized modifications or tampering prior to the deployment of the device

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

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

6G-2 Not used in Domain 6 but is used in Annex B 6G-3 Procedures must be in place and implemented to protect and SCDs•and endure the destruction of any cryptographic keys or key material within such devices•when removed from service, retired at the end of the deployment lifecycle, or returned for repair.

6G-4 Any SCD capable of encrypting a key and producing cryptograms (i.e., and HSM or key-injection/loading device) of that key, or signing applications to be loaded onto a POI device, must be protected against unauthorized …

Removed p. 95

<Report Findings Here> 6A-1.1.b Observe key-management operations and devices to verify that all cryptographic algorithms and key sizes are in accordance with Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.

Describe how observed key-management operations and devices verified that all cryptographic algorithms and key sizes are in accordance with Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms: <Report Findings Here> 6A-1.2 Cryptographic-key changes must be implemented for keys that have reached the end of their crypto-period (e.g., after a defined period of time and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (e.g., NIST Special Publication 800-57). See Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms. 6A-1.2.a Examine documented key-management procedures to verify:

• …

Removed p. 96

• Key-destruction method 6A-1.3.1.a Examine key management policies and procedures and verify documentation of all cryptographic keys managed as part of the P2PE solution is required, and includes:

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

<Report Findings Here> 6A-1.3.1.b Observe documentation and interview personnel and confirm that documentation of all cryptographic keys managed as part of the P2PE solution exists, and includes:

• Key-destruction method Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 6A-1.3.2 Maintain a list of all devices used to generate keys or key components managed as part of the P2PE solution, including:

Removed p. 96

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

Removed p. 97

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documented key management policies and procedures reviewed:

<Report Findings Here> 6A-1.3.2.b Observe documentation and interview personnel and confirm that a list of all devices used to generate keys managed as part of the P2PE solution exists, and includes:

• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 6B-1.1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Cryptographic keys or key components must be generated by one of the following:

• An approved key-generation function of a PCI

•approved HSM or POI device;

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

• An approved random number generator that has been certified by an independent laboratory …

Removed p. 98

• An approved key-generation function of a PCI

•approved HSM or POI device;

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

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

<Report Findings Here> 6B-1.1.c Observe devices performing key-generation functions, including validation of firmware used.

Describe how the reviewed devices used for key generation verified that devices are as noted above, including validation of the firmware: <Report Findings Here> 6B-2.1 Implement security controls, including dual control and tamper protection to prevent the unauthorized disclosure of keys/key components. [Applies to CA/RA assessments] 6B-2.1 Perform the following:

6B-2.1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation …

Removed p. 99

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

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

Responsible personnel interviewed: <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 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> …

Removed p. 99

<Report Findings Here> 6B-2.1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (e.g., unnecessary cables). [Applies to CA/RA assessments]

Removed p. 100

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

Describe how the key-generation set-up processes observed verified that key- generation equipment is inspected prior to use to ensure equipment does not show any signs of tampering: <Report Findings Here> 6B-2.1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the key-generation area It must not be feasible to observe the key-component/key-generation process whereby clear-text keying material is observable either directly or via camera monitoring [Applies to CA/RA assessments] 6B-2.1.5.a Examine documentation to verify that physical security controls are defined to ensure the key component/key-generation process cannot be observed or accessed by unauthorized personnel.

Documentation reviewed: <Report Findings Here> 6B-2.1.5.b Observe the physical security controls to verify that key- component/key-generation process cannot be observed or accessed by …

Removed p. 101

• Tampering can be visually detected. Printers used for this purpose must not be used for other purposes. 6B-2.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 immediately after printing such that:

• Tampering can be visually detected.

Documented procedures for printed key components reviewed:

<Report Findings Here> 6B-2.3.b Observe processes for printing key components to verify that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output.

Describe how the processes observed for printing key components verified that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output: <Report Findings Here> 6B-2.3.c Observe blind mailers or other sealed containers used for key components to …

Removed p. 102

Describe how the destruction process of the identified key residue verified that any residue that may contain clear-text keys or components is destroyed or securely deleted immediately after generation: <Report Findings Here> If a key is generated in a separate device before being exported into the end- use device, describe how the destruction process of the identified key residue verified that the key and all related critical security parameters are deleted from the generation and/or injection device immediately after the transfer to the device that will use the key: <Report Findings Here> 6B-2.5 Asymmetric-key pairs must either be:

• Generated by the device that will use the key pair; or

• 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 [Applies to CA/RA assessments] 6B-2.5.a Examine documented procedures for …

Removed p. 102

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

<Report Findings Here> 6B-2.5.b Observe key-generation processes to verify that asymmetric-key pairs are either:

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

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

Removed p. 103

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

Removed p. 103

• Writing key or component values in procedure manuals [Applies to CA/RA assessments] 6B-2.6.a Examine documented policy and procedures to verify that clear-text private or secret keys or their components are prohibited from being transmitted across insecure channels, including but not limited to:

Removed p. 103

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

<Report Findings Here> 6B-2.6.b From observation of key-management processes verify that key components are not transmitted across insecure channels, including but not limited to:

• Writing key or component values in procedure manual Describe how the key-management processes observed verified that key components are not transmitted across insecure channels, including but not limited to:

• Writing key or component values in procedure manual <Report Findings Here> 6B-3.1 Written key-generation procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of these procedures. Procedures for creating all keys must be documented. [Applies to CA/RA assessments]

Removed p. 104

<Report Findings Here> 6B-3.1.b Interview those responsible for the key-generation processes (including key custodians, supervisory staff, technical management, etc.) to verify that the documented procedures are known and understood by all affected parties.

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

Describe how the actual or demonstrative key-generation ceremonies verified that the documented procedures are demonstrably in use: <Report Findings Here> 6B-3.2 Logs must exist for the generation of higher-level keys, such as KEKs exchanged with other organizations, and MFKs and BDKs. [Applies to CA/RA assessments] 6B-3.2.a Examine documented key-generation procedures to verify that key- generation events for higher-level keys (e.g., KEKs shared with other organizations or otherwise manually loaded as components and MFKs and BDKs) are logged.

<Report Findings Here> 6B-3.2.b Observe demonstrations for the generation of higher-level keys to verify that all key-generation …

Removed p. 105

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

<Report Findings Here> 6C-1.1.b If key components are ever transmitted in clear-text using pre- numbered, tamper-evident, authenticable mailers, perform the following:

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

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

• Examine documented procedures to verify that cryptographic-key components are transferred using different communications channels.

• Examine records of key conveyances and interview responsible personnel to verify that cryptographic key components are transferred using different communications channels.

• Examine documented procedures to verify that serial numbers are verified prior to the usage of the keying material.

Removed p. 105

<Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe how the 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> 6C-1.1.b Where an SCD is used, perform the following:

• Examine documented procedures to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.

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

• Examine records of key transfers and interview responsible personnel to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.

Documented procedures reviewed: <Report Findings Here> Records of key transfers examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6C-1.2 A person with access to one component or share of a secret or private key, …

Removed p. 106

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

• Any person with access to the media conveying a 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 of this key that is sufficient to form the necessary threshold to derive the key.

Documented procedures reviewed: <Report Findings Here> 6C-1.2.b Observe key-transfer processes and interview personnel to verify that controls are implemented to ensure that no single person can ever have access to components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. Verify …

Removed p. 107

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: <Report Findings Here> 6C-1.4 Public keys must be conveyed in a manner that protects their integrity and authenticity. Examples of acceptable methods include:

• Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A

Removed p. 107

• Using a MAC (message authentication code) created using the algorithm defined in ISO 16609

• Within an SCD Note: Self-signed certificates must not be used as the sole method of authentication. [Applies to CA/RA assessments] 6C-1.4.a For all methods used to convey public keys, perform the following: Identify the P2PE Assessor who verified all methods used to convey public keys:

<Report Findings Here> 6C-1.4.b Examine documented procedures for conveying public keys to verify that methods are defined to convey public keys in a manner that protects their integrity and authenticity, such as:

• Use of public-key certificates created by a trusted CA that meets the requirements of Annex A

• Using a MAC (message authentication code) created using the algorithm defined in ISO 16609

• Within an SCD Documented procedures reviewed: <Report Findings Here> 6C-1.4.c Observe the process for conveying public keys and interview responsible personnel to verify that self-signed certificates are not be …

Removed p. 108

Responsible personnel interviewed: <Report Findings Here> Describe how the process for conveying public keys verified that the implemented method ensures public keys are conveyed in a manner that protects their integrity and authenticity: <Report Findings Here> 6C-2.1 Any single clear-text secret or private key component/share must at all times be either:

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

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

• Contained within a physically secure SCD. Note: No single person shall be able to access or use all components or a quorum of shares of a single secret or private cryptographic key. [Applies to CA/RA assessments] 6C-2.1.a Examine documented procedures for transmission, conveyance, or movement of keys between any …

Removed p. 109

• Any keys encrypted under this (combined) key [Applies to CA/RA assessments] 6C-2.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.

Documented procedures reviewed: <Report Findings Here> 6C-2.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.

Responsible personnel interviewed: <Report Findings Here> Describe how the observed processes verified that all packaging or mailers containing clear-text key components are examined for evidence of tampering before being opened: <Report Findings Here> 6C-2.2.c Verify documented procedures require that any sign of package tampering results in the destruction and replacement of both:

• Any keys encrypted under this (combined) key Documented procedures reviewed: <Report Findings Here> 6C-2.2.d Interview responsible personnel and observe processes to verify that if a package shows signs of tampering, …

Removed p. 110

Physical access logs examined: <Report Findings Here> 6C-2.4 Mechanisms must exist to ensure that only authorized custodians:

• Place key components into pre-numbered tamper-evident, authenticable packaging for transmittal.

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

• Check the serial number of the tamper-evident packaging upon receipt of a component package. [Applies to CA/RA assessments] 6C-2.4.a Verify that a list(s) of key custodians authorized to perform the following activities is defined and documented:

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

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

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

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

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

Removed p. 111

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

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

• TDEA keys shall not be used to protect AES keys.

• TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.

• RSA keys encrypting keys greater in strength than 80 bits shall have bit strength of at least 112 bits. 6C-3.1.a Examine documented procedures to verify 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.

Documented procedures reviewed: <Report Findings Here> 6C-3.1.b Observe key-generation processes to verify that all keys used to transmit or convey other cryptographic keys are at …

Removed p. 112

Responsible personnel interviewed: <Report Findings Here> 6C-4.2 Methods used for the conveyance or receipt of keys must be documented. [Applies to CA/RA assessments] 6C-4.2 Verify documented procedures include all methods used for the conveyance or receipt of keys.

Documented procedures reviewed: <Report Findings Here> 6D-1.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. Note: Manual key loading may involve the use of media such as paper, smart cards, or other physical tokens. [Applies to CA/RA assessments] 6D-1.1.a Review documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and

• split knowledge are required.

Documented process reviewed: <Report Findings Here> 6D-1.1.b Interview appropriate personnel to determine the number of key components for each manually loaded key, the length of the key components, and the methodology used to …

Removed p. 113

• Two or more passwords of five characters or more (vendor default values must be changed)

• Multiple cryptographic tokens (such as smartcards), or physical keys

• Physical access controls Note that for devices that do not support two or more passwords, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian. [Applies to CA/RA assessments] 6D-1.3.a Examine documented procedures for loading of clear-text cryptographic keys to verify they require dual control to authorize any key- loading session.

Documented procedures reviewed: <Report Findings Here> 6D-1.3.b For all types of production SCDs, observe processes for loading clear- text cryptographic keys to verify that dual control is required to authorize any key-loading session. Verify that any passwords used are a minimum of five characters.

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

Removed p. 114

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

<Report Findings Here> 6D-1.6 Any other SCD loaded with the same key components must combine all entered key components using the identical process. [Applies to CA/RA assessments] 6D-1.6 Through 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.

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: <Report Findings Here> 6D-1.7 The initial terminal master key (TMK) must be loaded to the device using either asymmetric key-loading techniques or manual techniques•e.g., the device keypad, IC cards, key-loading device, etc. Subsequent loading of the terminal master key …

Removed p. 115

Documentation reviewed: <Report Findings Here> 6D 1.8.b If key-establishment protocols using public-key cryptography are used to remotely distribute secret keys, verify that the requirements detailed in Annex A of this document are met, including:

• Use of public and private key lengths that are in accordance with Annex C for the algorithm in question.

• Use of key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.

• 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 Annex A of this document are met where key-establishment protocols using public-key cryptography are used to remotely distribute secret keys:

<Report Findings Here> 6D-2.1 Clear-text secret and private keys and key components must be transferred into an SCD only when it can be ensured that:

• Any cameras present in the environment must be positioned to …

Removed p. 116

Identify the P2PE Assessor who confirms 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:

<Report Findings Here> 6D-2.3 The loading of secret or private key components from electronic medium

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

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

• The medium 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 6F-4. [Applies to CA/RA assessments] 6D-2.3.a Examine documented procedures for the loading of secret or private key components from …

Removed p. 117

Documented procedures reviewed: <Report Findings Here> Describe how 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: <Report Findings Here> 6D-2.4.2 The key-loading device must be under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it. [Applies to CA/RA assessments] 6D-2.4.2 Verify the key-loading device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it.

Documented procedures reviewed: <Report Findings Here> Describe how 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 …

Removed p. 118

Documented procedures reviewed: <Report Findings Here> Describe how processes for the use of key-loading devices verified that the key-loading device does not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred: <Report Findings Here> 6D-2.5 Any media (electronic or otherwise) containing secret or private key components used for loading cryptographic keys must be maintained in a secure location and accessible only to authorized custodian(s). When

• removed from the secure storage location, media or devices containing key components or used for the injection of clear-text cryptographic keys must be in the physical possession of only the designated component holder(s), and only for the minimum practical time necessary to complete the key-loading process. The media upon which a component resides must be physically safeguarded at all times when

• removed from secure storage. Key components that can be read (e.g., …

Removed p. 119

Personnel interviewed: <Report Findings Here> Describe how it was verified 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: <Report Findings Here> 6D-2.7 Written or printed key component documents must not be opened until immediately prior to use. [Applies to CA/RA assessments] 6D-2.7.a Review documented procedures and confirm that printed/written key component documents are not opened until immediately prior to use.

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

Describe how the key-loading processes observed verified that printed/written key component documents are not opened until immediately prior to use: <Report Findings Here> 6D-2.8 A person with access to any component or share of a secret or private key, or …

Removed p. 120

• 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 resources (e.g., passwords 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> 6D-3.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 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 key-loading environments and …

Removed p. 121

Documented procedures reviewed: <Report Findings Here> 6D-3.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.

Identify the P2PE Assessor who inspected locations and controls for physical tokens and confirms 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:

<Report Findings Here> 6D-3.4.c Review storage locations for physical tokens to determine adequacy to ensure that only the authorized custodian(s) can access their specific tokens.

Identify the P2PE Assessor who confirms adequacy of reviewed storage locations for physical tokens …

Removed p. 122

Documented procedures reviewed: <Report Findings Here> 6D-4.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.

Describe how key-loading processes observed verified that the defined cryptographic-based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and is verified by the applicable key custodians: <Report Findings Here> 6D-4.1.c Verify that the methods used for key validation are consistent with ISO 11568•e.g., when check values are used, they should return a value of no more than six hexadecimal characters.

Describe how the key-loading processes observed verified that the methods used for key validation are consistent with ISO 11568: <Report Findings Here> 6D-4.2 The public key must have its authenticity and integrity ensured. In order to ensure authenticity and integrity, a public key …

Removed p. 123

Log files examined: <Report Findings Here> Describe how the logging processes observed verified that audit trails are in place for all key-loading events: <Report Findings Here> 6E-1.1 Where two organizations or logically separate systems share a key to encrypt account data (including a key-encipherment key used to encrypt a data- encryption key) communicated between them, that key must:

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

• Not be given to any other entity or logically separate systems. 6E-1.1.a Examine the documented key matrix and operational procedures and interview personnel to determine whether any keys are shared between organizations or logically separate systems. For all keys shared between two organizations or logically separate systems for encrypting account data (including key-encryption keys used to encrypt a data- encryption key) perform the following:

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

<Report Findings Here> Personnel interviewed: <Report Findings Here> …

Removed p. 124

• Specific actions that determine whether the legitimate value of the cryptographic key has changed. (For example, encryption of a known value to determine whether the resulting cryptogram matches the expected result.)

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

Documented procedures reviewed: <Report Findings Here> 6E-2.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. [Applies to CA/RA assessments] 6E-2.2.a Verify documented procedures require that key-component packaging/containers showing signs of tampering must result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.

Documented procedures reviewed: <Report Findings Here> 6E-2.2.b Interview personnel and observe processes …

Removed p. 124

<Report Findings Here> 6E-3.1.b Using a sample of device types, validate via review of check values, terminal definition files, etc. that keys used for key encipherment or PIN encipherment are not used for any other purpose.

Sample of device types reviewed: <Report Findings Here> Describe how review of check values, terminal definition files, etc. verified that keys used for key encipherment or PIN encipherment are not used for any other purpose:

Removed p. 125

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

• Private keys must never be used to encrypt other keys. [Applies to CA/RA assessments] 6E-3.2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are only used as follows:

• To create digital signatures or to perform decryption operations.

• For a single purpose

•a private key must only be used for either decryption or for creating digital signatures, but not both.

• Private keys are never used to encrypt other keys.

<Report Findings Here> 6E-3.3 Public keys must only be used for a single purpose•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for transaction-originating POI devices). [Applies to CA/RA assessments] 6E-3.3 Examine key-management documentation and interview key custodian and …

Removed p. 126

Describe how the observed processes for generating and loading keys into test systems verified that they are in no way associated with production keys: <Report Findings Here> 6E-3.4.d Compare check, hash, cryptogram, or fingerprint values for production and test/development keys with higher-level keys (MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.

Describe how the compared check, hash, cryptogram, or fingerprint values for production and test/development keys with higher-level keys (MFKs, KEKs shared with other network nodes, and BDKs) verified that development and test keys have different key values: <Report Findings Here> 6E-3.5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be

• deleted from the HSM(s) and the server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, …

Removed p. 126

Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6E-4.1 POI devices must each implement unique secret and private keys for any function directly or indirectly related to account-data protection. These keys must be known only in that device and in hardware security modules (HSMs) at the minimum number of facilities consistent with effective system operations. Disclosure of the key in one such device must not provide any information that could be feasibly used to determine the key in any other such device. This means not only the account-data-encryption key(s), but also keys that are used to protect other keys, firmware-authentication keys, payment-application authentication and display-prompt control keys. As stated in the requirement, this does not apply to public keys resident in the device. POI device private keys must not exist anywhere but the specific POI device they belong to, except where generated external to the POI device …

Removed p. 127

• Known only to a single POI device, and

• Known only to HSMs at the minimum number of facilities consistent with effective system operations.

Documented procedures reviewed: <Report Findings Here> 6E-4.1.b Observe HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POI devices to verify that unique keys are generated and used for each POI device.

Describe how the observed HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POI devices verified that unique keys are generated and used for each POI device: <Report Findings Here> 6E-4.1.c Examine check values, hash, or fingerprint values for a sample of cryptographic keys from different POI devices to verify private and secret keys are unique for each POI device. This can include comparing a sample of POI public keys (multiple devices for each POI device vendor used) to determine that the …

Removed p. 128

• Unique data is used for the derivation process such that all transaction- originating POI devices receive unique secret keys.

• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI device.

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

• Unique data is used for the derivation process such that all transaction- originating POI devices receive unique secret keys.

• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI device. <Report Findings Here> 6E-4.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 key4s used to generate keys for multiple devices are never …

Removed p. 129

Documented procedures reviewed: <Report Findings Here> Describe how the observed key stores verified that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions): <Report Findings Here> 6F-1.1.b Observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions).

Describe how the observed key stores verified that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions): <Report Findings Here> 6F-1.2 Wherever key components are used, they have the following properties: [Applies to CA/RA assessments] 6F-1.2 Examine documented procedures and interview responsible personnel …

Removed p. 130

Describe how the observed key-component access controls and key-custodian authorizations/assignments verified that all individuals with access to key components are designated as key custodians for those particular components: <Report Findings Here> 6F-1.2.4 Procedures exist to ensure any custodian never has access to sufficient key components or shares to reconstruct a secret or private key cryptographic key. For example, in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), where only two of any three components are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one component. If a custodian was previously assigned component A, which was then reassigned, the custodian must not then be assigned component B or C, as this would give them knowledge of two components, which gives them ability to recreate the key. In an m-of-n scheme where n=5, where three components are …

Removed p. 131

Identify the P2PE Assessor who confirms that tamper-evident packaging prevents the determination of the key component without visible damage to the packaging:

<Report Findings Here> 6F-1.3.1.c Ensure clear-text key components do not exist in any other locations, including in non-secure containers, in databases, on floppy disks, or in software programs.

Identify the P2PE Assessor who confirms that clear-text key components do not exist in any other locations.

<Report Findings Here> 6F-1.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).

Identify the P2PE Assessor who confirms that start-up instructions and other notes used by service technicians do not contain initialization- key values written in the clear:

<Report Findings Here> 6F-1.3.2 Key components for each specific custodian must be stored in a separate secure container that is accessible only by the custodian and/or …

Removed p. 131

Identify the P2PE Assessor who confirms that for each key component storage container:

<Report Findings Here> 6F-1.3.3 If a key 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. [Applies to CA/RA assessments] 6F-1.3.3 Interview responsible personnel and observe implemented processes to verify that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner

•or designated backup(s)

•has possession of both the token and its access code.

Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner

•or …

Removed p. 132

6F-2.1 Verify documented procedures exist for replacing known or suspected compromised keys that includes all of the following (6F-2.1.1 through 6F-2.1.5 below):

Documented procedures reviewed: <Report Findings Here> 6F-2.1.1 Key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD (or, for hybrid decryption solutions, the Host System) has been compromised. 6F-2.1.1 Interview responsible personnel and observe implemented processes to verify key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD (or, for hybrid decryption solutions, the Host System) has been compromised.

Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD (or, for hybrid decryption solutions, the Host System) has been compromised: <Report Findings Here> 6F-2.1.2 If unauthorized alteration is suspected, …

Removed p. 133

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

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

• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key.

Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if compromise of the cryptographic key is suspected, an assessment and analysis is performed. If compromise is confirmed, the following are performed:

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

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

• The replacement key must …

Removed p. 134

• Missing secure cryptographic devices

• Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries

• Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate

• Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities

• 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

• Host System tamper-detection mechanism has been activated, for hybrid decryption solutions 6F-2.1.5 Interview responsible personnel and review documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:

• Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries

• Tamper-evident seals or authenticable envelopes that have been opened without authorization or show …

Removed p. 135

Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6F-3.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.

Describe how the observed processes verified that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge: <Report Findings Here> 6F-3.2 An MFK used by host processing systems for encipherment of keys for local storage

•and variants of the MFK

•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 shall not be used for other purposes, such as key conveyance between platforms that are not part of the same logical configuration. A logical configuration is defined as one where all …

Removed p. 136

• Variants used as KEKs must only be calculated from other key-encrypting keys

• Variants of working keys must only be calculated from other working keys.

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:

• Variants used as KEKs must only be calculated from other key-encrypting keys

• Variants of working keys must only be calculated from other working keys. <Report Findings Here> 6F-4.1 Instances of secret or private keys, and their key components, that are no longer used or that have been

• replaced by a new key must be destroyed. [Applies to CA/RA assessments] 6F-4.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.

Documented procedures reviewed: <Report Findings Here> 6F-4.1.b Identify …

Removed p. 137

Documented procedures reviewed: <Report Findings Here> 6F-4.2.b Observe key-destruction processes to verify that no part of the key or component can be recovered.

Describe how the key-destruction processes observed verified that no part of the key or component can be recovered: <Report Findings Here> 6F-4.2.1 Keys on all other storage media types in all permissible forms

•physically secured, enciphered (except for electronic database backups of cryptograms), or components

•must be destroyed following the procedures outlined in ISO

•9564 or ISO

•11568. For example, keys (including components or shares) maintained on paper must be burned, pulped, or shredded in a crosscut shredder. [Applies to CA/RA assessments] 6F-4.2.1.a Examine documented procedures for destroying keys and confirm that keys on all other storage media types in all permissible forms

•physically secured, enciphered, or components

•must be destroyed following the procedures outlined in ISO

•9564 or ISO

•11568.

Documented procedures reviewed: <Report Findings Here> 6F-4.2.1.b Observe key-destruction processes to verify that keys on all …

Removed p. 138

Documented procedures reviewed: <Report Findings Here> 6F-4.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.

Describe how the key-conveyance/loading processes observed verified that any key components are destroyed once the keys are successfully loaded and validated as operational: <Report Findings Here> 6F-5.1 To reduce the opportunity for key compromise, limit the number of key custodians to a minimum required for operational efficiency. For example: [Applies to CA/RA assessments] 6F-5.1 Interview key custodians and key-management supervisory personnel and observe implemented processes to verify the following:

Removed p. 138

<Report Findings Here> 6F-5.1.1 Designate key custodian(s) for each component, such that the fewest number (e.g., a primary and a backup) of key custodians are assigned as necessary to enable effective key management. . Key custodians must be employees or contracted personnel. [Applies to CA/RA assessments] 6F-5.1.1 Review key-custodian assignments for each component to verify that:

• A primary and a backup key custodian are designated for each component.

• The fewest number of key custodians is assigned as necessary to enable effective key management.

• Assigned key custodians are employees or contracted personnel.

Describe how the key-custodian assignments reviewed for each component verified that:

• A primary and a backup key custodian are designated for each component.

• The fewest number of key custodians is assigned as necessary to enable effective key management.

• Assigned key custodians are employees or contracted personnel. <Report Findings Here> 6F-5.1.2 Document this designation by having each custodian and backup custodian …

Removed p. 138

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

<Report Findings Here> 6F-5.1.3 Each key-custodian form provides the following:

Removed p. 138

• An effective date and time for the custodian’s access

• Signature of management authorizing the access [Applies to CA/RA assessments]

• An effective date and time for the custodian’s access

Removed p. 139

• Signature of management authorizing the access.

<Report Findings Here> 6F-5.1.4 In order for key custodians to be free from undue influence in discharging their custodial duties, key custodians sufficient to form the necessary threshold to create a key must not directly report to the same individual except as noted below for organizations of insufficient size. For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to form the key must not report to the same individual. The components collectively held by an individual and his or her direct reports shall not constitute a quorum (or shall not provide any information about the value of the key that is not derivable …

Removed p. 140

• Tamper-evident package number (if applicable) [Applies to CA/RA assessments] 6F-6.1.a Review log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:

Removed p. 140

• Loaded to an SCD Log files reviewed: <Report Findings Here> Describe how log files and audit log settings verified that logs are kept for any time that keys, key components, or related materials are:

• Loaded to an SCD <Report Findings Here> 6F-6.1.b Review log files and audit log settings to verify that logs include the following:

• Key component identifier

• Key component identifier

• Tamper-evident package number (if applicable) Log files reviewed: <Report Findings Here> Describe how log files and audit log settings verified that logs include the following:

• Tamper-evident package number (if applicable) <Report Findings Here> 6F-7.1 If backup copies of secret and/or private keys exist, they must be maintained in accordance with the same requirements as are followed for the primary keys. [Applies to CA/RA assessments] 6F-7.1 Interview responsible personnel and examine documented procedures and backup records to determine whether any backup copies of keys or their components exist. …

Removed p. 141

Describe how the backup processes observed verified that backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys: <Report Findings Here> 6F-7.1.b Inspect backup storage locations and access controls or otherwise verify through examination of documented procedures and interviews of personnel that backups are maintained as follows:

Removed p. 141

• Subject to at least the same level of security control as operational keys as specified in this document Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> OR Describe how backup storage locations verified that backups are maintained as follows:

• Subject to at least the same level of security control as operational keys as specified in this document <Report Findings Here> 6F-7.2 If backup copies are created, the following must be in place:

• Creation (including cloning) of top-level keys

•e.g., MFKs

•must require a minimum of 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. [Applies to CA/RA assessments] 6F-7.2 Interview responsible personnel and observe backup processes to verify the following:

• The creation of any backup copies for top-level keys requires at least two authorized individuals to enable the process

• All requirements applicable …

Removed p. 141

• Management of personnel changes, including revocation of access control and other privileges when personnel move [Applies to CA/RA assessments]

Removed p. 142

• Management of personnel changes, including revocation of access control and other privileges when personnel move Documented procedures reviewed: <Report Findings Here> 6F-8.1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.

Responsible personnel interviewed: <Report Findings Here> 6F-8.1.c Interview personnel to verify that security-awareness training is provided for the appropriate personnel.

Personnel interviewed: <Report Findings Here> 6F-8.1.d Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws).

Responsible HR personnel interviewed:

<Report Findings Here> 6G-1.1 Secure cryptographic devices

•such as HSMs and POI devices

•must be placed into service only if there is assurance that the equipment has not been subjected to unauthorized modifications, substitution, or tampering and has not otherwise been subject to misuse prior to deployment. [Applies to CA/RA assessments] 6G-1.1.a Review documented procedures to confirm that processes are defined to provide the following assurances prior to the loading …

Removed p. 142

Documented procedures reviewed: <Report Findings Here> 6G-1.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:

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:

Removed p. 143

Documented procedures reviewed: <Report Findings Here> 6G-1.1.1.b Verify that documented procedures include 6G-1.1.1.1 through 6G- 1.1.1.3 below.

Documented procedures reviewed: <Report Findings Here> 6G-1.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. [Applies to CA/RA assessments] 6G-1.1.1.1.a Examine access-control documentation and device configurations to verify that access to all POI devices and key injection/loading devices is defined and documented.

Access-control documentation reviewed:

<Report Findings Here> Describe how access-control documentation and device configurations observed verified that access to all POI devices and key injection/loading devices is defined and documented: <Report Findings Here> 6G-1.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.

Sample of POI device types and other SCDs:

<Report Findings Here> Access …

Removed p. 144

• All personnel with access to POI devices and other SCDs are documented in a formal list.

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

• The authorizations are reviewed annually.

Documented authorizations reviewed: <Report Findings Here> 6G-1.1.1.3.b For a sample of POI device types and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in the formal list have access to devices.

Sample of POI device types and other SCDs reviewed:

<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 the formal list have access to devices: <Report Findings Here> 6G-1.3 Implement physical protection of devices from the manufacturer’s facility up to the point of key-insertion or inspection, through one or more of the following.

• Transportation using a trusted courier service (e.g., via …

Removed p. 145

Documented procedures reviewed: <Report Findings Here> 6G-1.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.

Responsible personnel interviewed: <Report Findings Here> 6G-1.4 Dual-control mechanisms must exist to prevent substitution or tampering of HSMs

•both deployed and spare or backup devices

•throughout their lifecycle. Procedural controls, which may be a combination of physical barriers and logical controls, may exist to support the prevention and detection of substituted HSMs, but cannot supplant the implementation of dual-control mechanisms. [Applies to CA/RA assessments] 6G-1.4.a Examine documented procedures to verify that dual-control mechanisms exist to prevent substitution or tampering of HSMs

•both deployed and spare or back-up devices

•throughout their life cycle.

Documented procedures reviewed: <Report Findings Here> 6G-1.4.b Interview responsible personnel and physically verify the dual-control mechanism used to prevent substitution or tampering …

Removed p. 146

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> 6G-1.4.4 Inspect and test all HSMs

•either new or retrieved from secure storage

•prior to installation to verify devices have not been tampered with or compromised. Processes must include: [Applies to CA/RA assessments] 6G-1.4.4.a Examine documented procedures to verify they require inspection and testing of HSMs prior to installation to verify integrity of device and include requirements specified at 6G-1.4.4.1 through 6G-1.4.4.4 below.

Documented procedures reviewed: <Report Findings Here> 6G-1.4.4.1 Running self-tests to ensure the correct operation of the device. [Applies to CA/RA assessments] 6G-1.4.4.1 Examine records of device inspections and test results to verify that self-tests are run on devices to ensure the correct operation of the device.

Records of device inspections reviewed:

<Report Findings Here> Describe how the records of device inspections and test results examined …

Removed p. 147

Records of inspections examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6G-1.4.4.4.b Examine records of inspections to verify records are retained for at least one year.

Records of inspections examined: <Report Findings Here> 6G-1.4.5 Maintain HSMs in tamper-evident packaging or in secure storage until ready for installation. [Applies to CA/RA assessments] 6G-1.4.5.a Examine documented procedures to verify they require devices be maintained in tamper-evident packaging until ready for installation.

Documented procedures reviewed: <Report Findings Here> 6G-1.4.5.b Observe a sample of received devices to verify they are maintained in tamper-evident packaging until ready for installation.

Sample of received devices reviewed: <Report Findings Here> 6G-3.1 Procedures are in place to ensure that any SCDs to be

• removed from service

•e.g., retired or returned for repair

•are not intercepted or used in an unauthorized manner, including that all keys, key material, and account data stored within the device must be rendered irrecoverable. Processes must include the …

Removed p. 148

Describe how the demonstration of processes for removing HSMs from service verified that dual control is implemented for all critical decommissioning processes: <Report Findings Here> 6G-3.1.2 Keys and account data are rendered irrecoverable (e.g., zeroized) for SCDs. If data cannot be rendered irrecoverable, devices must be physically destroyed under dual control to prevent the disclosure of any sensitive data or keys. [Applies to CA/RA assessments] 6G-3.1.2 Interview personnel and observe demonstration of processes for removing SCDs from service to verify that all keying material and account data are rendered irrecoverable (e.g., zeroized), or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.

Personnel interviewed: <Report Findings Here> Describe how the demonstration of processes for removing SCDs from service verified that all keying material and account data are rendered irrecoverable, or that devices are physically destroyed under dual control to prevent the disclosure …

Removed p. 149

Personnel interviewed: <Report Findings Here> Records of testing examined: <Report Findings Here> 6G-4.1 For HSMs and other SCDs used for the generation or loading of cryptographic keys for use in POI devices, or for signing applications and/or whitelists to be loaded into POI devices, procedures must be documented and implemented to protect against unauthorized access and use. Required procedures and processes include the following: 6G-4.1.a Examine documented procedures to confirm that they specify protection against unauthorized access and use for HSMs and other devices used for the generation or loading of cryptographic keys for use in POI devices, or for signing applications and/or whitelists to be loaded into POI devices.

Documented procedures reviewed: <Report Findings Here> 6G-4.1.b Verify that documented procedures cover requirements 6G-4.1.1 through 6G-4.1.5 below.

Documented procedures reviewed: <Report Findings Here> 6G-4.1.1 Devices must not be authorized for use except under the dual control of at least two authorized people. …

Removed p. 149

• To place the device into a state that allows for the input or output of clear-text key components;

• For all access to key-loading devices (KLDs) and authenticated application-signing devices.

Removed p. 150

• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing;

• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing;

• To place the device into a state that allows for the input or output of clear- text key components;

• For all access to KLDs and authenticated application-signing devices.

Dual-control mechanisms examined: <Report Findings Here> Describe how the observation of authorized personnel performing the defined activities verified that dual control is implemented for the following:

• To place the device into a state that allows for the input or output of clear- text key components;

• For all access to KLDs and authenticated application-signing devices. <Report Findings Here> 6G-4.1.3 Devices must not use default passwords.

6G-4.1.3.a Examine password policies and documented procedures to confirm default passwords must not be used for HSMs, KLDs, and other SCDs used to generate or …

Removed p. 151

Responsible personnel interviewed: <Report Findings Here> Describe how devices are at all times within a secure room and either:

• Locked in a secure cabinet and/or sealed in tamper-evident packaging at all times, or

• Under the continuous supervision of at least two authorized people at all times. <Report Findings Here> 6G-5.1 Written procedures must exist, and all affected parties must be aware of those procedures. Records must be maintained of the tests and inspections performed on account-data processing devices before they are placed into service, as well as devices being decommissioned. [Applies to CA/RA assessments] 6G-5.1.a Examine documented procedures/processes and interview responsible personnel to verify that all affected parties are aware of required processes and are provided suitable guidance on procedures for account-data processing devices placed into service, initialized, deployed, used, and decommissioned Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6G-5.1.b Verify that written records exist …

Removed p. 152

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

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

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

Describe how the key-management methods used to manage DDKs on the Host System meet one, or both, of the above options: <Report Findings Here> 6H-1.2 DDKs must …

Removed p. 153

• A one-way derivation process is used.

• A one-way derivation process is used.

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

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

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

Describe how the key-generation processes observed verified that:

• The master key used to generate the DDK is dedicated to generating DDKs. <Report Findings Here> 6H-1.4 The DDK must be encrypted between the HSM and the Host System, e.g., using a fixed transport key or a cryptographic protocol. The method of encryption used must maintain the security policy to which the HSM was approved (either FIPS140-2, Level 3 or higher, or approved to the PCI HSM standard). 6H-1.4.a Examine key-management policies and procedures to verify that DDKs must be encrypted between the HSM and the Host System.

<Report Findings …

Removed p. 154

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

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

Describe how the key-management processes observed verified that the encryption mechanism uses an encryption key that is unique for each Host System: <Report Findings Here> 6H-1.5.3 The encryption key must only be used to encrypt the DDK during transmission between the HSM and the Host System, and not used to encrypt/transmit any other cryptographic key, or for any other purpose. 6H-1.5.3.a Examine documented key-management policies and procedures to verify that the encryption mechanism uses an encryption key that is only used to encrypt the DDK during transmission between the HSM and the Host System, and not used to encrypt/transmit any other cryptographic key, or …

Removed p. 155

• Type of key(s) injected

Removed p. 155

• Details of any known or suspected compromised keys, per 6F-2.1 Note that adding, changing, or removing POI and/or HSM types, or critical key-management methods may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution. 6I-1.1.a Review 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:

Removed p. 155

• Details of any known or suspected compromised keys, per 6F-2.1 Documented component provider procedures reviewed:

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

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

• For each type/model of POI:

• Number of POI devices

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

Removed p. 156

6D Key loading is handled in a secure manner.

6F Keys are administered in a secure manner.

Table 6A.1

• List of symmetric keys (by type) distributed using asymmetric techniques Key type/description:* Purpose/function of the key (including types of devices using key):

Description/identifier of asymmetric techniques use for key distribution:

Entity performing remote key distribution:

* Note: Must include all keys from Table 6.1 identified as being distributed via remote key distribution techniques.

Domain 6: Normative Annex A, A1 Remote Key Distribution Using Asymmetric Techniques Operations

• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 6C-3.2 All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed except as noted in the main body of Domain 6 at Requirement 6C-3.1. 6C-3.2 Examine documented procedures to verify that all asymmetric keys used to transmit or convey other cryptographic keys must be (at least) as strong …

Removed p. 158

• POI devices validate authentication credentials of KDHs immediately prior to any key transport, exchange, or establishment with that device.

• KDHs validate authentication credentials of POIs immediately prior to any key transport, exchange, or establishment with that device.

Applicable personnel interviewed: <Report Findings Here> 6D-4.4 Key-establishment and distribution procedures must be designed such that:

• Within an implementation design, there shall be no means available for “man-in-the-middle” attacks

•e.g., through binding of the KDH certificate upon the initial communication.

• System implementations must be designed and implemented to prevent replay attacks

•e.g., through the use of random nonces. 6D-4.4 Examine system and process documentation to verify that key- establishment and distribution procedures are designed such that:

• There are no means available in the implementation design for “man-in- the-middle” attacks.

• System implementations are designed to prevent replay attacks.

System and process documentation reviewed:

<Report Findings Here> 6D-4.5 Key pairs generated external to the device that uses the key …

Removed p. 159

• POIs only communicate with CAs for the purpose of certificate signing, or for key-injection where the certificate issuing authority generates the key pair on behalf of the device;

• POIs only communicate with KDHs or key management, normal transaction processing, and certificate (entity) status checking.

Describe how the POI configurations observed verified that POIs only communicate with CAs for the purpose of certificate signing, or for key-injection where the certificate issuing authority generates the key pair on behalf of the device: <Report Findings Here> Describe how the POI configurations observed verified that POIs only communicate with KDHs or key management, normal transaction processing, and certificate (entity) status checking: <Report Findings Here> 6E-2.5 KDHs shall only communicate with POIs for the purpose of key management and normal transaction processing, and with CAs for the purpose of certificate signing and certificate (entity) status checking. 6E-2.5.a Examine documented procedures to verify that:

• KDHs only …

Removed p. 160

• Certificates are replaced by generating a new key pair and requesting a new certificate.

• Each key pair generated results in only one certificate.

Describe how the observed certificate issuing and replacement processes verified that:

• Certificates are replaced by generating a new key pair and requesting a new certificate.

• Each key pair generated results in only one certificate. <Report Findings Here> 6E-3.7 KDH private keys must not be shared between devices except for load balancing and disaster recovery.

6E-3.7 Examine documented processes to verify that KDH private keys are not permitted to be shared between devices, except for load balancing and disaster recovery.

Documented processes reviewed: <Report Findings Here> 6E-3.8 POI private keys must not be shared between devices.

6E-3.8.a Examine documented processes to verify that POI private keys are not permitted to be shared between devices.

Documented processes reviewed: <Report Findings Here> 6E-3.8.b Inspect public key certificates on the host processing system to confirm …

Removed p. 161

a) Limited to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use; and b) Protected such that no other person (not similarly entrusted with that component) can observe or otherwise contain the component.

6G Equipment used to process account data and keys is managed in a secure manner.

6G-3 Procedures must be in place and implemented to protect and SCDs•and endure the destruction of any cryptographic keys or key material within such devices•when removed from service, retired at the end of the deployment lifecycle, or returned for repair.

• deleted from the HSM(s) and the server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and

Documented procedures reviewed: <Report Findings Here> 6C-3.3 Key sizes …

Removed p. 163

• All keying material is deleted from the HSM(s) and the server/computer platforms prior to testing.

• Subsequent to completion of testing, all keying materials must be deleted and the server/computer platforms must be wiped and rebuilt from read- only media.

Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6E-3.6 Key pairs must not be reused for certificate renewal or replacement•i.e., new key pairs must be generated. Each key pair must result in only one certificate. 6E-3.6.a Examine documented procedures for requesting certificate issue, renewal, and replacement to verify procedures include generation of a unique key pair for each:

• Each key pair generated results in only one certificate Documented procedures reviewed: <Report Findings Here> 6E-3.6.b Interview responsible personnel and observe certificate issuing and replacement processes to verify that:

Responsible personnel interviewed: <Report Findings Here> Describe how the certificate issuing and replacement processes observed verified that:

• Certificates are replaced by generating …

Removed p. 164

Vendor documentation reviewed: <Report Findings Here> Describe how the vendor documentation and device configuration settings observed verified that the device mechanisms are implemented that preclude the use of a key for other than its designated and intended purpose: <Report Findings Here> 6E-3.9.1 CA certificate signature keys, certificate (entity) status checking (e.g., Certificate Revocation Lists) signature keys, or signature keys for updating valid/authorized host lists in encryption devices must not be used for any purpose other than subordinate entity certificate requests, certificate status checking, and self-signed root certificates. Note: The keys used for certificate signing and certificate (entity) status checking (and if applicable, self-signed roots) may be for combined usage or may exist as separate keys dedicated to either certificate-signing or certificate (entity) status checking. 6E-3.9.1.a Examine certificate policy and documented procedures to verify that:

Removed p. 164

• Certificate status checking (e.g., Certificate Revocation Lists) signature keys, or

• Signature keys for updating valid/authorized host lists in POIs Must not be used for any purpose other than:

Removed p. 164

• Self-signed root certificates.

• Self-signed root certificates.

Certificate policy and documented procedures reviewed:

<Report Findings Here> 6E-3.9.1.b Interview responsible personnel and observe demonstration to verify that:

• Status checking (e.g., Certificate Revocation Lists) signature keys, or

• Status checking (e.g., Certificate Revocation Lists) signature keys, or

• Signature keys for updating valid/authorized host lists in POIs Are not used for any purpose other than:

• Signature keys for updating valid/authorized host lists in POIs Are not used for any purpose other than:

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

• Self-signed root certificates. <Report Findings Here> 6E-3.9.2 CAs that issue certificates to other CAs must not be used to issue certificates to POIs.

6E-3.9.2 If a CA issues certificates to other CAs, examine the CA certificate policy and documented procedures to verify that the CA does not also issue certificates to POI devices.

CA certificate policy and documented procedures reviewed:

Documented key-management procedures reviewed:

• Within a …

Removed p. 165

Documented procedures reviewed: <Report Findings Here> 6E-3.11 CA private keys must not be shared between devices except for load balancing and disaster recovery.

6E-3.11 Examine CA’s documented processes to verify that CA private keys are not permitted to be shared between devices, except for load balancing and disaster recovery.

CA’s documented processes reviewed: <Report Findings Here> 6E-3.12 The PKI used for remote key distribution must not be used for any other purpose, e.g., cannot be used for firmware or application authentication.

6E-3.12.a Interview responsible personnel to verify that the PKI is operated solely for the purposes of remote key distribution:

Responsible personnel interviewed: <Report Findings Here> 6E-3.12.b Examine the documented certificate policy to verify that the CA is operated solely for the purposes of remote key distribution.

Documented certificate policy reviewed:

<Report Findings Here> 6F-1.4 Private keys used to sign certificates, certificate status lists, messages, or for key protection must exist only in one or more …

Removed p. 166

Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> Describe the observations that confirmed that Root CAs provide for segmentation of risk to address key compromise: <Report Findings Here> 6F-2.7 Mechanisms must be in place to respond to address compromise of a CA due to, for example, key compromise or mismanagement. This must include procedures to revoke or otherwise invalidate the usage of subordinate certificates, and notification of affected entities. 6F-2.7.a Examine documented procedures to verify that mechanisms are defined to respond to compromise of a CA. Verify the mechanisms include procedures to:

• Revoke subordinate certificates, and

• Revoke subordinate certificates, and

• Notify affected entities.

• Notify affected entities.

Documented procedures reviewed: <Report Findings Here> 6F-2.7.b Interview responsible personnel to verify that the defined mechanisms to respond to compromise of a CA are in place and include:

Responsible personnel interviewed: <Report Findings Here> 6F-2.7.1 The CA must cease issuance of certificates if …

Removed p. 166

• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred.

• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred.

Documented procedures reviewed: <Report Findings Here> 6F-2.7.1.b Interview responsible personnel and observe process to verify that in the event a compromise is known or suspected:

Responsible personnel interviewed: <Report Findings Here> Describe how the observed process verified that in the event a compromise is known or suspected:

• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred <Report Findings Here> 6F-2.7.2 In the event of confirming a compromise, the CA must determine whether to revoke and reissue all signed certificates with a newly generated signing key.

Removed p. 167

Documented procedures reviewed: <Report Findings Here> 6F-2.7.2.b Interview responsible personnel to verify procedures are followed for the CA to determine whether to revoke and reissue all signed certificates with a newly generated signing key.

Responsible personnel interviewed: <Report Findings Here> 6F-2.7.3 Mechanisms (e.g., time stamping) must exist to prevent the usage of fraudulent certificates, once identified.

6F-2.7.3.a Examine documented procedures to verify that mechanisms are defined to prevent the usage of fraudulent certificates.

Documented procedures reviewed: <Report Findings Here> 6F-2.7.3.b Interview responsible personnel and observe implemented mechanisms to verify the prevention of the use of fraudulent certificates Responsible personnel interviewed: <Report Findings Here> Describe how the implemented mechanisms observed verified the prevention of the use of fraudulent certificates: <Report Findings Here> 6F-2.7.4 The compromised CA must notify any superior or subordinate CAs of the compromise. The compromise damage analysis must include a determination of whether subordinate CAs and KDHs must have their certificates …

Removed p. 168

Appropriate personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6F-2.8.b Verify that the following minimum key sizes exist for RSA keys or the equivalent for the algorithm used as defined in Annex C:

• 1024 for KDHs and POI devices Appropriate personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6F-2.8.c Verify that KDH keys expire every five years unless another mechanism exists to prevent the use of a compromised KDH private key.

Appropriate personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6F-5.2 All user access to material that can be used to construct secret and private keys (such as key components) must be directly attributable to an individual user (e.g., through the use of unique IDs). 6F-5.2.a Examine documented procedures to confirm that access to material that can be used to construct secret and private keys is directly attributable to an individual user …

Removed p. 169

• CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment).

• The network is only used for certificate issuance, revocation, or both certificate issuance and revocation.

• Outside network access shall exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).

Network diagrams reviewed: <Report Findings Here> Describe how the network diagrams and network and system configurations observed verified that:

• CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment).

• The network is only used for certificate issuance, revocation, or both certificate issuance and revocation.

• Outside network access shall exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs) <Report Findings Here> 6F-5.3.2 CA or Registration Authority (RA) software updates must not be done over the network (local console access …

Removed p. 170

Documented certificate security policy and certification practice statement reviewed:

<Report Findings Here> 6F-5.3.5.b Observe certificate-signing processes to verify that signing keys are enabled only under at least dual control.

Describe how the certificate-signing processes observed verified that signing keys are enabled only under at least dual control: <Report Findings Here> 6F-5.4 The CA shall require a separation of duties for critical CA functions to prevent one person from maliciously using a CA system without detection, the practice referred to as “dual control.” At a minimum, there shall be multi-person control for operational procedures such that no one person can gain control over the CA signing key(s). 6F-5.4.a Examine documented procedures to verify they include following:

Removed p. 170

• Separation of duties to prevent one person from maliciously using a CA system without detection

• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) Documented procedures reviewed: <Report Findings Here> 6F-5.4.b Observe CA operations and interview responsible personnel to verify:

• Separation of duties to prevent one person from maliciously using a CA system without detection

• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) Responsible personnel interviewed: <Report Findings Here> Describe how the CA operations observed verified:

• Separation of duties to prevent one person from maliciously using a CA system without detection

• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) <Report Findings Here> 6F-5.5 All CA systems that are not operated strictly offline must be hardened to prevent insecure network access, …

Removed p. 171

• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, etc., commands in UNIX) are removed or disabled.

• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, etc., commands in UNIX) are removed or disabled.

• Unnecessary ports are disabled.

• Unnecessary ports are disabled.

• There is documentation to support all active services and ports.

Sample of systems reviewed: <Report Findings Here> Documentation reviewed: <Report Findings Here> Describe how the observed system configurations observed verified that:

• There is documentation to support all active services and ports. <Report Findings Here> 6F-5.5.1 All vendor-default IDs must be changed, removed, or disabled unless necessary for a documented and specific business reason. Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades must only be enabled when required and otherwise must be disabled from login. 6F-5.5.1.a Examine documented procedures to …

Removed p. 172

Responsible personnel interviewed: <Report Findings Here> Describe how the system configurations observed verified that vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step are changed, removed, or disabled before installing a system on the network: <Report Findings Here> 6F-5.6 Audit trails must include but not be limited to the following:

• All key-management operations, such as key generation, loading, transmission, backup, recovery, compromise, and destruction and certificate generation or revocation

Removed p. 172

• The identities of all persons handling any key material (such as key components or keys stored in portable devices or media)

• Protection of the logs from alteration and destruction 6F-5.6.a Examine system configurations and audit trails to verify that all key- management operations are logged.

Describe how the system configurations and audit trails observed verified that all key-management operations are logged: <Report Findings Here> 6F-5.6.b For a sample of key-management operations, examine audit trails to verify they include:

• The identities of all persons handling any key material

• The identities of all persons handling any key material

• Mechanisms exist to protect logs from alteration and destruction Sample of key-management operations reviewed:

<Report Findings Here> Describe how the examined audit trails for a sample of key-management operations verified they include:

• Mechanisms exist to protect logs from alteration and destruction <Report Findings Here> 6F-5.6.1 Audit logs must be archived for a minimum of two …

Removed p. 173

Sample of certificate revocations reviewed:

<Report Findings Here> Audit records examined: <Report Findings Here> 6F-5.6.3 Logical events are divided into operating-system and CA application events. For both, the following must be recorded in the form of an audit record:

Removed p. 173

• Success or failure of the event. 6F-5.6.3.a Examine audit trails to verify that logical events are divided into operating-system and CA application events.

Describe how the examined audit trails verified that logical events are divided into operating system and CA application events: <Report Findings Here> 6F-6.3.b Examine a sample of operating-system logs to verify they contain the following information:

• Success or failure of the event.

• Success or failure of the event.

Sample of operating-system logs reviewed:

<Report Findings Here> 6F-5.6.3.c Examine a sample of application logs to verify they contain the following information:

Sample of application logs reviewed: <Report Findings Here> 6F-5.7 CA application logs must use a digital signature or a symmetric MAC (based on one of the methods stated in ISO 16609

• Requirements for message authentication using symmetric techniques) mechanism for detection of alteration. The signing/MACing key(s) used for this must be protected using a secure cryptographic device in accordance with …

Removed p. 174

• Requirements for message authentication using symmetric techniques) mechanism for detection of alteration.

Describe how log security controls verified that CA application logs use a digital signature or a symmetric MAC (based on one of the methods stated in ISO 16609

• Requirements for message authentication using symmetric techniques) mechanism for detection of alteration: <Report Findings Here> 6F-5.7.b Review documentation and interview personnel and observe to verify that signing/MACing key(s) used for this are protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document.

Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> Describe how the observation of signing/MACing keys used for this verified they are protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document: <Report Findings Here> 6F-5.7.1 Certificate-processing system components operated online must be protected by a firewall(s) from all unauthorized access, including casual browsing and deliberate …

Removed p. 174

• Not accept traffic on its external interfaces that appears to be coming from internal network addresses.

• Notify the firewall administrator in near real time of any item that may need immediate attention such as a break-in, little disk space available, or other related messages so that an immediate action can be taken.

• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled. 6F-5.7.1.a Examine network and system configurations to verify that certificate- processing system components operated online are protected from unauthorized access by firewall(s).

Describe how the observed network and system configurations verified that certificate-processing system components operated online are protected from unauthorized access by firewall(s): <Report Findings Here>

Removed p. 175

• Not accept traffic on its external interfaces that appears to be coming from internal network addresses.

• Notify the firewall administrator in near real time of any item that may need immediate attention such as a break-in, little disk space available, or other related messages so that an immediate action can be taken.

• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled.

Describe how the observed firewall configurations verified they are configured to:

• Not accept traffic on its external interfaces that appears to be coming from internal network addresses.

• Notify the firewall administrator in near real time of any item that may need immediate attention such as a break-in, little disk space available, or other related messages so that an immediate action can be taken.

• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications …

Removed p. 176

6F-5.8.2.a For a sample of system components, examine user ID lists to verify the following:

• Generic user IDs and accounts are disabled or removed.

• Generic user IDs and accounts are disabled or removed.

• Shared user IDs for system administration activities and other critical functions do not exist.

• Shared and generic user IDs are not used.

Removed p. 176

<Report Findings Here> Describe how user ID lists verified that:

• Shared user IDs for system administration activities and other critical functions do not exist.

• Shared and generic user IDs are not used <Report Findings Here> 6F-5.8.2.b Examine authentication policies/procedures to verify that group and shared passwords or other authentication methods are explicitly prohibited.

Documented authentication policies/ procedures reviewed:

<Report Findings Here> 6F-5.8.2.c Interview system administrators to verify that group and shared passwords or other authentication methods are not distributed, even if requested.

System administrators interviewed: <Report Findings Here> 6F-5.8.3 If passwords are used, system-enforced expiration life must not exceed 30 days and a minimum life at least one day.

6F-5.8.3 For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 30 days and have a minimum life of at least one day.

<Report Findings Here> Describe …

Removed p. 177

<Report Findings Here> Describe how the observed system configuration settings verified 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> 6F-5.8.6 Authentication parameters must require a system-enforced passphrase history, preventing the reuse of any passphrase used in the last 12 months.

6F-5.8.6 For a sample of system components, obtain and inspect system configuration settings to verify that authentication parameters are set to require a system-enforced passphrase history, preventing the reuse of any passphrase used in the last 12 months.

<Report Findings Here> Describe how the observed system configuration settings verified that authentication parameters are set to require a system-enforced passphrase history, preventing the reuse of any passphrase used in the last 12 months: <Report Findings Here> 6F-5.8.7 Passwords are not stored on any of the systems except in encrypted form or as part of a proprietary …

Removed p. 178

Describe how the observed devices in use verified that the security tokens have an associated usage-authentication mechanism, such as a biometric or associated PIN/passphrase to enable their usage: <Report Findings Here> 6F-5.8.9.b Examine token-configuration settings to verify parameters are set to require PINs/passwords be at least eight decimal digits in length, or equivalent.

Describe how the observed token-configuration settings verified that parameters are set to require PINs/passwords be at least eight decimal digits in length, or equivalent: <Report Findings Here> 6F-5.9 Implement a method to synchronize all critical system clocks and times for all systems involved in key-management operations.

6F-5.9.a Examine documented procedures and system configuration standards to verify a method is defined to synchronize all critical system clocks and times for all systems involved in key-management operations.

Documented procedures and system configuration standards reviewed:

<Report Findings Here> 6F-5.9.b For a sample of critical systems, review the time-related system parameters to verify that system …

Removed p. 179

Describe how the observed system and network configurations and physical access controls verified that all physical and logical CA system components are separated from key-distribution systems: <Report Findings Here> 6F-8.3 Each CA operator must develop a certification practice statement (CPS). (See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.)

• The CPS must be consistent with the requirements described within this document.

• The CA shall operate in accordance with its CPS. Note: This may take the form of a declaration by the CA operator of the details of its trustworthy system and the practices it employs in its operations and in support of the issuance of certificates. A CPS may take the form of either a specific, single document or a collection of specific documents. The CPS must be consistent with the requirements described within this document. The CA shall operate …

Removed p. 180

Documented procedures reviewed: <Report Findings Here> 6F-8.5.b Observe certificate-issuing processes to verify that the identities of the certificate requestor and recipient are validated before issuing a digital certificate for the recipient’s associated public key.

Describe how the certificate-issuing processes observed verified that the identities of the certificate requestor and recipient are validated before issuing a digital certificate for the recipient’s associated public key: <Report Findings Here> 6F-8.5.1 For CA and KDH certificate-signing requests, including certificate or key-validity status changes

•e.g., revocation, suspension, replacement

•verification must include validation that:

Removed p. 180

• The entity submitting the request is authorized to submit the request on behalf of the certificate request’s originating entity.

• The entity submitting the request has a valid business relationship with the issuing authority (e.g., the vendor) consistent with the certificate being requested.

• The certificate-signing request has been transferred from the certificate request’s originating entity to the RA in a secure manner. 6F-8.5.1.a Examine documented procedures to verify that certificate-signing requests, including certificate or key-validity status changes, require validation that:

• The entity submitting the request is authorized to submit the request on behalf of the certificate request’s originating entity.

• The entity submitting the request has a valid business relationship with the issuing authority (e.g., the vendor) consistent with the certificate being requested.

• The certificate-signing request has been transferred from the certificate request’s originating entity to the RA in a secure manner.

• The entity submitting the request is authorized to submit …

Removed p. 181

• For all certificates issued

• For all certificates issued

• For all certificates whose status had changed Documentation reviewed: <Report Findings Here> Describe how the observation of audit trails verified that the identification of entities is retained for the life of the associated certificates:

• For all certificates whose status had changed <Report Findings Here> 6G-3.2.1 The certificate-processing operations center must implement a three-tier physical security boundary, as follows:

• Consists of the entrance to the facility.

• Secures the entrance beyond the foyer/reception area to the CA facility.

Removed p. 181

• Provides access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices. 6G-3.2.1.a Examine physical security policies to verify three tiers of physical security are defined as follows:

Removed p. 181

• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Documented physical security policies reviewed:

<Report Findings Here> 6G-3.2.1.b Observe the physical facility to verify three tiers of physical security are implemented as follows:

• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Describe how the physical facility observed verified that three tiers of physical security are implemented as follows:

• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices <Report Findings Here> Level 1 Barrier 6G-3.2.2 The entrance to the CA facility/building must include the following controls:

6G-3.2.2.1 The facility entrance only allows authorized personnel to enter the facility.

Removed p. 182

<Report Findings Here> 6G-3.2.2.1.b Observe the facility entrance and observe personnel entering the facility to verify that only authorized personnel are allowed to enter the facility.

Identify the P2PE Assessor who confirms that only authorized personnel are allowed to enter the facility:

<Report Findings Here> 6G-3.2.2.2 The facility has a guarded entrance or a foyer with a receptionist. No entry is allowed for visitors if the entryway is not staffed•i.e., only authorized personnel who badge or otherwise authenticate themselves can enter when entryway is unstaffed. 6G-3.2.2.2.a Examine physical-security procedures and policies to verify they require that the facility have a guarded entrance or a foyer with a receptionist or the entryway prevents access to visitors.

<Report Findings Here> 6G-3.2.2.2.b Observe the facility entrance to verify it has a guarded entrance or a foyer with a receptionist.

Identify the P2PE Assessor who confirms that the facility entrance has a guarded entrance or a foyer with …

Removed p. 183

Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that visitors entering the Level 2 environment are authorized and escorted at all times:

<Report Findings Here> 6G-3.2.3.2 Access logs must record all personnel entering the Level 2 environment. Note: The logs may be electronic, manual, or both. 6G-3.2.3.2.a Examine documented policies and procedures to verify that access logs are required to record all personnel entering the Level 2 environment.

<Report Findings Here> 6G-3.2.3.2.b Observe personnel entering the Level 2 barrier and review corresponding access logs to verify that all entry through the Level 2 barrier is logged.

Describe how the observation of personnel entering the Level 2 barrier and the corresponding access logs verified that all entry through the Level 2 barrier is logged: <Report Findings Here> 6G-3.2.4 The Level 2 entrance must be monitored by a video-recording system.

6G-3.2.4.a Observe the Level 2 entrance to verify that a video-recording system is …

Removed p. 184

Identify the P2PE Assessor who confirms that all doors to the Level 3 environment have locking mechanisms:

<Report Findings Here> 6G-3.2.5.2 The Level 3 environment must be enclosed on all sides (including the ceiling and flooring areas) using techniques such as true floor-to-ceiling (slab-to- slab) walls, steel mesh, or bars. For example, the Level 3 environment may be implemented within a “caged” environment. 6G-3.2.5.2.a Examine physical security documentation for the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such as have true floor-to- ceiling (slab-to-slab) walls, steel mesh, or bars Physical security documentation reviewed:

<Report Findings Here> 6G-3.2.5.2.b Examine the physical boundaries of the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such as true floor-to-ceiling (slab-to-slab) walls, steel mesh, or bars and protection from entry …

Removed p. 185

• Be assigned resources of the CA operator with defined business needs and duties.

<Report Findings Here> 6G-4.2.6.1.b Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws) on CA personnel prior such personnel being authorized for access through the Level 3 barrier.

Responsible HR personnel interviewed: <Report Findings Here> 6G-3.2.6.1.c Interview a sample of personnel authorized for access through the Level 3 barrier to verify that they are assigned resources of the CA with defined business needs and duties.

Sample of personnel authorized for access through the Level 3 barrier interviewed:

<Report Findings Here> 6G-3.2.6.2 Other personnel requiring entry to this level must be accompanied by two (2) authorized and assigned resources at all times.

6G-3.2.6.2.a Examine documented policies and procedures to verify that personnel requiring entry to this level must be accompanied by two (2) authorized and assigned resources at all times.

<Report Findings Here> 6G-3.2.6.2.b Interview …

Removed p. 186

6G-3.2.7.2.a Examine documented policies and procedures to verify that the system is required to enforce anti-pass-back.

<Report Findings Here> 6G-3.2.7.2.b Observe mechanisms in use and authorized personnel within the environment to verify that anti-pass-back is enforced by the conduct of a test.

Describe how the observed mechanisms in use and authorized personnel within the environment verified that anti-pass-back is enforced by the conduct of a test: <Report Findings Here> 6G-3.2.7.3 Dual occupancy requirements are managed using electronic (e.g., badge and/or biometric) systems.

6G-3.2.7.3.a Examine documented policies and procedures to verify that dual occupancy requirements are defined to be managed using electronic (e.g., badge and/or biometric) systems.

<Report Findings Here> 6G-3.2.7.3.b Observe mechanisms in use and authorized personnel within the environment to verify that dual-occupancy requirements are managed using electronic systems.

Identify the P2PE Assessor who confirms the dual-occupancy requirements are managed using electronic systems:

<Report Findings Here> 6G-3.2.7.4 Any time a single occupancy exceeds 30 seconds, …

Removed p. 187

Correlating audit logs reviewed: <Report Findings Here> Describe how the observation of authorized personnel entering the environment and correlating audit logs verified that access to the Level 3 room creates an audit log event: <Report Findings Here> 6G-3.2.8.1 Invalid access attempts to the Level 3 room must create audit records, which must be followed up by security personnel 6G-3.2.8.1 Observe an invalid access attempt and examine correlating audit logs to verify that invalid access attempts to the Level 3 room create an audit log event.

Correlating audit logs reviewed: <Report Findings Here> Describe how the observation of an invalid access attempt and correlating audit logs verified that invalid access attempts to the Level 3 room create an audit log event: <Report Findings Here> 6G-3.2.9 The Level 3 environment must be monitored as follows:

6G-3.2.9.1 A minimum of one or more cameras must provide continuous monitoring (e.g., CCTV system) of the Level 3 …

Removed p. 188

Identify the P2PE Assessor who confirms that continuous or motion- activated lighting is provided for each camera monitoring the Level 3 physical environment:

<Report Findings Here> 6G-3.2.9.3.b Examine a sample of captured footage from different days and times to ensure that the lighting is adequate.

Sample of captured footage reviewed: <Report Findings Here> 6G-3.2.9.4 Surveillance cameras must be configured to prevent the monitoring of computer screens, keyboards, PIN pads, or other systems that may expose sensitive data. Cameras must not be able to be remotely adjusted to zoom in or otherwise observe the aforementioned. 6G-3.2.9.4.a Observe each camera locations in the Level 3 environment to verify they are not set to monitor computer screens, keyboards, PIN pads, or other systems that may expose sensitive data.

Identify the P2PE Assessor who confirms that observed camera locations in the Level 3 environment are not set to monitor computer screens, keyboards, PIN pads, or other systems …

Removed p. 189

Describe how the system configurations observed verified that where digital- recording mechanisms are in use, the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period: <Report Findings Here> 6G-3.2.9.7 CCTV images must be backed up daily. The backup recording must be stored in a separate, secure location within the facility and must ensure segregation of duties between the users (personnel accessing the secure area) and administrators of the system. Alternatively, backups may be stored in other facilities via techniques such as disk mirroring, provided the storage is secure in accordance with these requirements. 6G-3.2.9.7 Examine backup techniques utilized to ensure that:

• Backups are securely stored in a separate location from the primary.

• Backups are securely stored in a separate location from the primary.

• Ensure that segregation is maintained between users and administrators of the system.

Describe how the observed backup …

Removed p. 190

Describe how the testing of at least one window verified that the alarms function appropriately: <Report Findings Here> 6G-3.3.2 Any windows or glass walls must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure area.

6G-3.3.2 Observe all windows and glass walls in the secure areas to verify they are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure area.

Describe how observation of the windows and glass walls in the secure areas verified that they are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure area: <Report Findings Here> 6G-3.3.3 The intrusion-detection system(s) must be connected to the alarm system and automatically activated every time all authorized personnel have performed an authenticated exit of the secure area. The system must be configured to activate within 30 seconds. 6G-3.3.3.a Examine security system configurations to verify:

• The intrusion-detection system(s) is connected to the …

Removed p. 191

<Report Findings Here> 6G-3.4.b On the escorted entry into the secure area, observe that all personnel appropriately sign the access logbook and that all escorted visitors are required to sign the access logbook.

Identify the P2PE Assessor who confirms that upon escorted entry into the secure area, all personnel appropriately sign the access logbook and all escorted visitors are required to sign the access logbook:

<Report Findings Here> 6G-3.4.1 The access log must include the following details:

Removed p. 191

• Reason for access or purpose of visit

• Reason for access or purpose of visit

• For visitor access, the initials of the person escorting the visitor 6G-3.4.1 Examine the access logbook to verify it contains the following information:

• For visitor access, the initials of the person escorting the visitor Identify the P2PE Assessor who confirms the access logbook contains the following:

• Reason for access or purpose of visit

• For visitor access, the initials of the person escorting the visitor <Report Findings Here> 6G-3.4.2 The logbook must be maintained within the Level 3 secure environment.

6G-3.4.2 Observe the location of the access logbook and verify that it is maintained within the Level 3 secure environment.

Identify the P2PE Assessor who confirms the location of the access logbook is maintained within the Level 3 secure environment:

<Report Findings Here> 6G-3.5 All access-control and monitoring systems (including intrusion-detection systems) are powered through an uninterruptible power source …

Removed p. 192

6G-3.6.a Examine security policies and procedures to verify they require that all alarm events be logged.

<Report Findings Here> 6G-3.6.b Examine security-system configurations and documented alarm events to verify that all alarm events are logged.

Documented alarm events reviewed: <Report Findings Here> Describe how the observed system-configurations and documented alarm events verified that all alarm events are logged: <Report Findings Here> 6G-3.6.1 An individual must not sign off on an alarm event in which they were involved.

6G-3.6.1.a Examine documented procedures for responding to alarm events to verify that the procedure does not permit a person who was involved in an alarm event to sign-off on that alarm event.

Documented procedures reviewed: <Report Findings Here> 6G-3.6.1.b Determine who is authorized to sign off on alarm events. Identify the P2PE Assessor who determined who is authorized to sign off on alarm events:

<Report Findings Here> 6G-3.6.1.c For a sample of documented alarm events, review the record …

Removed p. 193

Sample of alarm events reviewed: <Report Findings Here> Personnel assigned with security- response duties interviewed:

<Report Findings Here> 6G-3.6.3.c Conduct a test to verify the appropriate response occurs. Describe the testing performed that verified the appropriate response occurs:

<Report Findings Here> 6G-3.7 A process must be implemented for synchronizing the time and date stamps of the access, intrusion-detection, and monitoring (camera) systems to ensure accuracy of logs. It must be ensured that synchronization errors between CCTV, intrusion detection, and access control cannot exceed one minute. Note: This may be done by either automated or manual mechanisms. 6G-3.7.a Examine documented procedures to verify that mechanisms are defined (may be automated or manual) for synchronizing the time and date stamps of the access, intrusion-detection, and monitoring (camera) systems to ensure accuracy of logs.

Documented procedures reviewed: <Report Findings Here> 6G-3.7.b Examine system configurations for access, intrusion-detection, and monitoring (camera) systems to verify that time and …

Removed p. 194

6A-1 Account data is processed in equipment that conforms to requirements for secure cryptographic devices (SCDs). Account data never appears in the clear outside of an SCD.

6B Cryptographic keys used for account-data encryption/decryption and related key management are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.

a) Physically forwarding the key as at least two separate key shares or full-length components (hard copy, smart card, SCD) using different communication channels, or b) Transmitting the key in ciphertext form. Public keys must be conveyed in a manner that protects their integrity and authenticity.

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

Removed p. 195

6D-1 Secret and private keys must be input into hardware (host) security modules (HSMs) and Point of Interaction (POI) devices in a secure manner.

a) Unencrypted secret or private keys must be entered into cryptographic devices using the principles of dual control and split knowledge.

b) Key-establishment techniques using public-key cryptography must be implemented securely.

6D-2 The mechanisms used to load secret and private keys•such as terminals, external PIN pads, key guns, or similar devices and methods•must be protected to prevent any type of monitoring that could result in the unauthorized disclosure of any component.

6D-3 All hardware and access/authentication mechanisms (e.g., passwords) used for key loading or the signing of authenticated applications (e.g., for “whitelists”) must be managed under dual control.

6D-5 Documented procedures must exist and be demonstrably in use (including audit trails) for all key-loading activities.

Removed p. 196

6F-3 Keys generated using reversible key-calculation methods, such as key variants, must only be used in SCDs that possess the original key.

Keys generated using reversible key-calculation methods must not be used at different levels of the key hierarchy. For example, a variant of a key-encryption key used for key exchange must not be used as a working key or as a Master File Key for local storage.

Keys generated with a non-reversible process, such as key derivation or transformation process with a base key using an encipherment process, are not subject to these requirements.

6F-4 Secret and private keys and key components that are no longer used or have been replaced must be securely destroyed.

6F-6 Logs must be kept for any time that keys, key components or related materials are removed from storage or loaded to an SCD.

6F-7 Backups of secret and private keys must exist only for the purpose of reinstating …

Removed p. 197

6G-1 Equipment used to protect account data (e.g., POI devices and HSMs) must be placed into service only if there is assurance that the equipment has not been substituted or subjected to unauthorized modifications or tampering prior to the deployment of the device

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

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

6G-4 Any SCD capable of encrypting a key and producing cryptograms (i.e., and HSM or key-injection/loading device) of that key, or signing applications to be loaded onto a POI device, must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following:

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

6G-3 Procedures must be in place and implemented to protect and SCDs•and endure the destruction of any cryptographic keys or key material within …

Removed p. 199

Personnel interviewed: <Report Findings Here> 6A-1.4 The approval listing must match the deployed devices in the following characteristics:

Removed p. 199

• The PCI PTS or FIPS 140 Approval Number

• The PCI PTS 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 6A-1.4.a For all PCI-approved HSMs used, examine HSM devices and review 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:

• Any applications, including application version number, resident within the device which were included in the PTS assessment For each PCI-approved HSM used, describe how the observed HSM device configurations verified that all of the device characteristics at 6A-1.4.a match the PTS listing: <Report Findings Here> 6A-1.4.b For all FIPS-approved HSMs used, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS140-2 …

Removed p. 200

Documented procedures reviewed: <Report Findings Here> 6A-1.5.b Interview relevant personnel and review documentation that describes and/or illustrates the architecture of the KIF to verify that all KIF components, key-management flows, and personnel interaction with key-management flows are identified and documented.

Relevant personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6A-1.5.c Examine the key-management flows and interview personnel to verify:

• Documentation shows all key-management flows across functions and networks from the point the key is generated through to the point the key is injected into the POI.

• Documentation is kept current and updated as needed upon changes to the KIF architecture Personnel interviewed: <Report Findings Here> Documented key-management flows reviewed:

<Report Findings Here> 6B-1.1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Cryptographic keys or key components must be generated …

Removed p. 201

6B-2.1 Perform the following:

6B-2.1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation SCD and the device or medium receiving the key or key component. 6B-2.1.1.a Examine documented procedures to verify the following:

Documented procedures reviewed: <Report Findings Here> 6B-2.1.1.b Observe key-generation processes and interview responsible personnel to verify:

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

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

Responsible personnel interviewed: <Report Findings Here> Describe how the key generation processes …

Removed p. 202

Key-generation logs reviewed: <Report Findings Here> 6B-2.1.3 Devices used for generation of clear-text key components that are output in the clear must be powered off when not in use. Logically partitioned devices used concurrently for other processes

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

•must have key-generation capabilities disabled when not in use and other activities are continuing. 6B-2.1.3 Examine documented procedures for all key-generation methods. Verify procedures require that:

• Key-generation devices that generate clear-text key components be powered off when not in use; or

• If logically partitioned for concurrent use in other processes, the key- generation capabilities are disabled when not in use and other activities are continuing.

<Report Findings Here> 6B-2.1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (e.g., unnecessary cables).

6B-2.1.4.a Review documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment …

Removed p. 203

Documented procedures reviewed: <Report Findings Here> 6B-2.2.b Observe generation process and review vendor 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 unprotected memory.

<Report Findings Here> Describe how the generation process observed for each type of key verified that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory: <Report Findings Here> 6B-2.2.c Where single-purpose computers with an installed SCD are used, verify that either:

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

• Where clear keying material passes through unprotected memory of the PC, the PC requirements of 6D-2 of this Annex B are met.

Describe how the single-purpose computers with an installed SCD …

Removed p. 204

Describe how processes observed for printing key components verified that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output: <Report Findings Here> 6B-2.3.c Observe blind mailers or other sealed containers used for key components to verify that tampering can be visually detected.

Describe how the blind mailers or other sealed containers used for key components observed verified that tampering can be visually detected: <Report Findings Here> 6B-2.4 Any residue that may contain clear-text keys or components must be destroyed or securely deleted

•depending on media

•immediately after generation of that key, to prevent disclosure of a key or the disclosure of a key component to an unauthorized individual. Examples of where such key residue may exist include (but are not limited to):

• Memory storage of a key-loading device, after loading the key to a different …

Removed p. 205

• If generated externally, the private key of 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. 6B-2.5.a Examine documented procedures for asymmetric-key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either:

• If generated externally, the key pair and all related critical security parameters 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 are deleted immediately after the transfer to the device that will use the key pair. <Report Findings Here> 6B-2.6 Policy and procedures must exist to ensure that clear-text private or secret keys or their components are prohibited from being transmitted across insecure channels. These include but are not limited to:

• Faxing, e-mailing, …

Removed p. 206

• Writing key or component values in procedure manual <Report Findings Here> 6B-3.1 Written key-creation procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of those procedures. All key-creation events performed by a key-injection facility must be documented. Procedures for creating all keys must be documented. 6B-3.1.a Examine documented key-generation procedures to confirm that they include all aspects of key-generation operations.

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

Describe how the observation of actual or demonstrative key-generation ceremonies verified that the documented procedures are demonstrably in use: <Report Findings Here> 6B-3.2 Logs must exist for the generation of higher-level keys such as KEKs exchanged with other organizations and MFKs and BDKs.

Removed p. 207

<Report Findings Here> 6B-3.2.b Observe demonstrations for all types of key-generation events to verify that all key-generation events are logged.

Describe how the demonstrations for all types of key-generation events observed verified that all key-generation events are logged: <Report Findings Here> 6B-3.2.c Examine logs of key generation to verify that exchanges of higher- level keys with other organizations have been recorded.

Key generation logs examined: <Report Findings Here> 6C-1.1 Keys must be transferred either encrypted or within an SCD. If clear text outside of an SCD, keys must be transferred as two or more key shares or full- length components using different communication channels, or within an SCD. Clear-text key components may be transferred in SCDs or using tamper-evident, authenticable packaging.

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

- Components/shares must be conveyed using at least two separate communication channels, such as different courier services. Components/shares sufficient to …

Removed p. 208

Describe how the observed method to transport clear-text key components using tamper-evident mailers verified that details of the serial number of the package are transmitted separately from the package itself: <Report Findings Here> 6C-1.1.c Where SCDs are used to convey components, perform the following:

<Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6C-1.1.d Where SCDs are conveyed with pre-loaded secret and/or private keys, perform the following:

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

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

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

<Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6C-1.2 A person with access to one component or share of a secret or private key, or …

Removed p. 209

• 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 components or shares sufficient to form the necessary threshold to derive the key.

• Any person with access to the media conveying a 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 of this key that is 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 other components or shares of this key that are sufficient to form the necessary threshold to derive the key.

• Any person with access to the media conveying a key component or key share must …

Removed p. 210

• Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A.

• Be within an SCD Note: Self-signed certificates must not be used as the sole method of authentication. 6C-1.4 For all methods used to convey public keys, perform the following:

• Examine documented procedures for conveying public keys to verify that methods are defined to convey public keys in a manner that protects their integrity and authenticity such as: - Use of public-key certificates created by a trusted CA that meets the requirements of Annex A - A hash of the public key sent by a separate channel (e.g., mail) - Using a MAC (message authentication code) created using the algorithm defined in ISO 16609 - Be within an SCD

• Observe the process for conveying public keys and interview responsible personnel to verify that self-signed certificates must not …

Removed p. 211

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

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

• Contained within a physically secure SCD. <Report Findings Here> 6C-2.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 must result in the destruction and replacement of:

• Any keys encrypted under this (combined) key 6C-2.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.

Responsible personnel interviewed: <Report Findings Here> Describe how the processes observed verified that all packaging or mailers containing clear-text key components are examined for evidence of …

Removed p. 212

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

• Any keys encrypted under this (combined) key <Report Findings Here> 6C-2.3 Only the authorized key custodian (and designated backup(s)) shall have physical access to a key component prior to transmittal or upon receipt of a component. 6C-2.3.a Verify that a list(s) of key custodians (and designated backup(s)) authorized to have physical access to key components prior to transmittal or upon receipt of a component is defined and documented.

Describe the implemented access controls and processes observed that verified that only those authorized key custodians (and designated backup(s)) have physical access to key components prior to transmittal or upon receipt: <Report Findings Here> 6C-2.3.c Examine physical access logs (e.g., to security containers …

Removed p. 213

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

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

• Check the serial number of the tamper-evident packaging upon receipt of a component package. <Report Findings Here> 6C-2.5 Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers. Note: Numbered courier bags are not sufficient for this purpose 6C-2.5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following:

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

Removed p. 214

Documented procedures reviewed: <Report Findings Here> Describe how the key-generation processes observed verified that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed, as delineated in Annex C: <Report Findings Here> 6C-3.1.c Examine system documentation and configuration files to validate the above, including HSM settings.

System documentation reviewed: <Report Findings Here> Describe how the observed configuration files validated the above, including HSM settings: <Report Findings Here> 6C-4.1 Written procedures must exist and be known to all affected parties.

6C-4.1.a Verify documented procedures exist for all key transmission and conveyance processing.

Documented procedures reviewed: <Report Findings Here> 6C-4.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.

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

6C-4.2 Verify documented procedures …

Removed p. 215

Documented procedures reviewed: <Report Findings Here> 6D-1.1.b Interview appropriate personnel to determine the number of key components for each manually loaded key, and the methodology used to form the key.

Appropriate personnel interviewed: <Report Findings Here> 6D-1.1.c Witness a structured walk-through/demonstration of various key- loading processes for all key types (MFKs, TMKs, PEKs. etc.). Verify the number and length of the key components to information provided through verbal discussion and written documentation.

Describe how the structured walk-through/demonstration verified that key- loading devices can only be accessed and used under dual control: <Report Findings Here> 6D-1.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. 6D-1.2 Examine logs of access to security containers for key components to verify that only the authorized custodian(s) have accessed. Compare the number on …

Removed p. 216

Describe how default dual-control mechanisms were verified to have been disabled or changed: <Report Findings Here> 6D-1.4 Key components for symmetric keys must be combined using a process such that no active bit of the key can be determined without knowledge of the remaining components•e.g., via XOR‘ing of full-length components. Note that concatenation of key components together to form the key is unacceptable; e.g., concatenating two 8-hexadecimal character halves to form a 16- hexadecimal secret key. The resulting key must only exist within the SCD. 6D-1.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.

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

Removed p. 217

• The existing TMK to encrypt the replacement TMK for download. Keys shall not be reloaded by any methodology in the event of a compromised device, and must be withdrawn from use. 6D-1.7.a Examine documented procedures for the loading of TMKs to verify that they require asymmetric key-loading techniques or manual techniques for initial loading.

• 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 actually has (or actually can) compute the session key and that no entity other than the POI device specifically identified can possibly compute the session key. 6D-1.8.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including the size and sources of the parameters involved, and the mechanisms utilized for mutual device authentication for both the host and the POI.

Documented procedures reviewed: …

Removed p. 218

• Physical dual access controls that electronically provide for restricted entry and egress from a room dedicated to key injection such that the badge-access system enforces the presence of at least two authorized individuals at all times in the room so no one person can singly access the key-loading equipment. Access is restricted to only appropriate personnel involved in the key-loading process

• Logical dual control via multiple logins with unique user IDs to the key-injection platform application such that no one person can operate the application to singly inject cryptographic keys into devices

• Key-injection platform applications that force the entry of multiple key components and the implementation of procedures that involve multiple key custodians who store and access key components under dual-control and split-knowledge mechanisms

• Demonstrable procedures that prohibit key custodians from handing their components to any other individual for key entry 6D-1.9.a Examine documented key-injection procedures to verify that …

Removed p. 219

• Ensure that any cameras that are present are positioned to ensure they cannot monitor the entering of clear-text key components.

• Review documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that: - SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading. - An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device. - There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys. - The SCD is inspected to ensure it has not been subject to any prior tampering that could lead to the disclosure of clear-text …

Removed p. 220

• The medium used for key loading 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.

Describe how the observed key-loading processes verified that the injection process results in one of the following:

• 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. <Report Findings Here> 6D-2.4 For secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device:

6D-2.4 Review documented procedures and observe processes for the …

Removed p. 221

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: <Report Findings Here> 6D-2.4.3.b Verify 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 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: <Report Findings Here> 6D-2.4.4 The key-loading device must not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred. 6D-2.4.4 Verify the key-loading device …

Removed p. 222

• Requirement that media/devices are in the physical possession of only the designated component holder(s).

• The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading process.

Documented procedures reviewed: <Report Findings Here> 6D-2.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.

Key-injection personnel interviewed: <Report Findings Here> Logs examined: <Report Findings Here> 6D-2.6 If the component is in human-readable form, it must be visible only to the designated component custodian and only for the duration of time required for this person to privately enter the key component into an SCD. 6D-2.6 Validate through interview and observation that, if components are in human-readable form, they are visible only to the designated key-component custodian and only for the duration of time required for this …

Removed p. 223

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

Describe how the observed key-component access controls and access logs verified that any single authorized custodian can only access their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key: <Report Findings Here> 6D-2.9 Key-injection facilities that use PC-based key-loading software platforms or similar devices (e.g., modified PEDs) that allow clear-text secret and/or private keys and/or their components to exist in unprotected memory outside the secure boundary of an SCD must minimally implement the following additional controls: 6D-2.9 Interview appropriate personnel and review documentation to determine the procedures for key loading to POIs, key-loading devices, and HSMs that are part of the key-loading platform. Review any logs of key loading.

Appropriate …

Removed p. 224

• All hardware used in key loading (including the PC) is managed under dual control.

• Key-injection cannot occur unless there are minimally two individuals in the key-injection room at all times during the process.

• Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals.

Personnel interviewed: <Report Findings Here> Describe how observation of the facilities verified that:

• All hardware used in key loading (including the PC) is managed under dual control.

• Key-injection cannot occur unless there are minimally two individuals in the key-injection room at all times during the process.

• Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals <Report Findings Here> 6D-2.9.3 PC access and use must be monitored, and logs of all key loading must be maintained. These logs must be retained for a minimum of three years. …

Removed p. 225

• Regularly reviewed by an authorized person who does not have access to the room or to the PC.

• The reviews are documented.

• Logs include a minimum of:

• Access to the room from a badge access system,

• Access to the room from a manual sign-in sheet,

• User sign-on logs on the PC at the operating system level,

• User sign-on logs on the PC at the application level,

• Logs of the device IDs and serial numbers that are loaded along with the date and time and the individuals performing the key-injection, - Video surveillance logs with a minimum retention period of 45 days.

Personnel interviewed: <Report Findings Here> Logs of key-loading activities reviewed: <Report Findings Here> 6D-2.9.4 Additionally:

6D-2.9.4 Verify through interviews and observation that: Personnel interviewed for 6D-2.9.4.x: <Report Findings Here> 6D-2.9.4.1 Cable attachments and the key-loading device must be examined before each use to ensure the equipment is free from tampering.

6D-2.9.4.1 …

Removed p. 226

Describe how it was verified that personnel responsible for the systems administration of the PC do not have authorized access into the room and do not have user IDs or passwords to operate the key-injection application: <Report Findings Here> 6D-2.9.4.6 The key-injection personnel must not have system-administration capability at either the O/S or the application level on the PC.

6D-2.9.4.6 Key-injection personnel do not have system-administration capability at either the O/S or the application level on the PC.

Describe how it was verified that key-injection personnel do not have system- administration capability at either the O/S or the application level on the PC: <Report Findings Here> 6D-2.9.4.7 The PC must not be able to boot from external media (e.g., USB devices or CDs). It must boot from the hard drive only.

6D-2.9.4.7 The PC is not able to boot from external media (e.g., USB devices or CDs). It must boot from the hard …

Removed p. 227

• split knowledge. Note: For DUKPT implementations, the BDK should be loaded from components each time and this requires manual tracking of the device ID counter and serial numbers from the previous key-loading session. Key-injection facilities with PC applications that require passwords to be used to initiate decryption of keys on portable electronic media (e.g., smart cards) must ensure the passwords are maintained under dual control and

• split knowledge. 6D-2.9.4.9 If the PC application stores keys (e.g., BDKs or TMKs) on portable electronic media (e.g., smart cards), the media is secured as components under dual control when not in use. The key components are manually entered at the start of each key-injection session from components that are maintained under dual control and

Describe how it was verified that if the PC application stores keys on portable electronic media:

• The media is secured as components under dual control when not in use.

• …

Removed p. 228

Documented procedures reviewed: <Report Findings Here> 6D-3.2.b Observe key-loading processes to verify that all cable attachments are properly examined prior to a key-loading function.

Describe how the key-loading processes observed verified that all cable attachments are properly examined prior to key-loading functions: <Report Findings Here> 6D-3.3 Key-loading equipment usage must be monitored and a log of all key-loading activities maintained for audit purposes containing at a minimum date, time, personnel involved, and number of devices keys are loaded to. 6D-3.3.a Observe key-loading activities to verify that key-loading equipment usage is monitored.

Describe how the key-loading activities observed verified that key-loading equipment usage is monitored: <Report Findings Here> 6D-3.3.b Verify logs of all key-loading activities are maintained and contain all required information.

Logs of key-loading activities reviewed: <Report Findings Here> 6D-3.4 Any physical tokens (e.g., brass keys or chip cards) used to enable key-loading must not be in the control or possession of any …

Removed p. 229

<Report Findings Here> 6D-3.5 Default password or PINs used to enforce dual-control must be changed, and documented procedures must exist to require that these password/PINs be changed when assigned personnel change. 6D-3.5.a Verify that documented procedures require default passwords or PINs used to enforce dual control are changed.

Documented procedures reviewed: <Report Findings Here> 6D-4.1 A cryptographic-based validation mechanism must be is 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 shall not exceed six hexadecimal characters in length. 6D-4.1.a Examine documented procedures to verify a cryptographic-based validation mechanism is in place to ensure the authenticity and integrity of keys and/or components.

Documented procedures reviewed: <Report Findings Here> …

Removed p. 230

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

<Report Findings Here> 6D-5.2 All key-loading events must be documented. Audit trails must be in place for all key-loading events.

6D-5.2 Examine log files and observe logging processes to verify that audit trails are in place for all key-loading events.

Log files examined: <Report Findings Here> Describe how the logging processes observed verified that audit trails are in place for all key-loading events: <Report Findings Here> 6E-2.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. 6E-2.2.a Verify documented procedures require that key-component packaging/containers showing signs of tampering …

Removed p. 231

Responsible personnel interviewed: <Report Findings Here> Describe how the key-loading processes and controls observed verified that controls are implemented to prevent and detect the loading of keys by any one single person: <Report Findings Here> 6E-2.5 Key-injection facilities must implement controls to protect against unauthorized substitution of keys and to prevent the operation of devices without legitimate keys. Examples include but are not limited to:

• All devices loaded with keys must be tracked at each key-loading session by serial number.

• Key-injection facilities must use something unique about the POI (e.g., logical identifiers) when deriving the key (e.g., DUKPT, TMK) injected into it. 6E-2.5.a Examine documented procedures to verify they include:

• Controls to protect against unauthorized substitution of keys, and

• Controls to prevent the operation of devices without legitimate keys.

Documented procedures reviewed: <Report Findings Here> 6E-2.5.b Interview responsible personnel and observe key-loading processes and controls to verify that:

• Controls are implemented …

Removed p. 232

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: <Report Findings Here> 6E-3.2 Private keys must only be used as follows:

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

• Private keys shall never be used to encrypt other keys. 6E-3.2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are only used:

• For a single purpose

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

• Private keys are never used to encrypt other keys.

<Report Findings Here> 6E-3.3 Public keys must only be used for a single purpose•a …

Removed p. 233

Describe how the observed processes for generating and loading keys into production systems verified that they are in no way associated with test or development keys: <Report Findings Here> 6E-3.4.c Observe processes for generating and loading keys into test systems to ensure that they are in no way associated with production keys.

Describe how the observed processes for generating and loading keys into test systems verified that they are in no way associated with production keys: <Report Findings Here> 6E-3.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.

Describe how the observed compared check, hash, cryptogram, or fingerprint values for production and test/development keys with higher-level keys (MFKs, KEKs shared with other network nodes, and BDKs) verified that development and test keys have different …

Removed p. 234

Documented procedures reviewed: <Report Findings Here> 6E-4.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.

Describe how the observed HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POI devices verified that unique keys are generated and used for each POI device: <Report Findings Here> 6E-4.1.c Examine check values, hashes, or fingerprint values for a sample of cryptographic keys from different POI devices to verify private and secret keys are unique for each POI device. This can include comparing a sample of POI public keys (multiple devices for each POI vendor used) to determine that the associated private keys stored in the POI devices are unique per device•i.e., the public keys are unique.

Describe how the examined check values, hash, or fingerprint …

Removed p. 235

• Unique data is used for the derivation process such that all transaction- originating POIs receive unique secret keys.

• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI.

Documented procedures reviewed: <Report Findings Here> Describe how the processes observed for generating master keys verified that the following is implemented where master keys are generated by a derivation process and derived from the same Base Derivation Key:

• Unique data is used for the derivation process such that all transaction- originating POI devices receive unique secret keys.

• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI. <Report Findings Here> 6E-4.3.b Verify that derivation keys used to generate keys for multiple devices are never loaded into a POI device.

Describe how the processes observed for generating master keys verified that derivation keys used to generate keys for multiple devices are never loaded into …

Removed p. 236

Documented procedures reviewed: <Report Findings Here> 6E-4.5.b Observe key-loading processes for a sample of terminal types used by a single entity, to verify that separate BDKs are used for each terminal type.

Sample of terminal types used by a single entity reviewed:

<Report Findings Here> Describe how the key-loading processes observed verified that separate BDKs are used for each terminal type: <Report Findings Here> 6E-4.6 Remote Key-Establishment and Distribution Applications The following requirements apply to key-injection facilities participating in remote key-establishment and distribution applications:

• Keys must be uniquely identifiable in all hosts and POI Devices (e.g., EPPs/PEDs). Keys must be identifiable via cryptographically verifiable means (e.g., through the use of digital signatures or key check values).

• Key pairs must be unique per POI device (e.g., EPPs and PEDs). 6E-4.6.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including:

• The size and sources of the …

Removed p. 237

Describe how the key stores observed verified that secret or private keys only exist in one or more approved forms at all times when stored: <Report Findings Here> 6F-1.2 Wherever key components are used, they have the following properties:

6F-1.2 Examine documented procedures and interview responsible personnel to determine all instances where key components are used.

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

6F-1.2.1 Review processes for creating key components to verify that knowledge of any one key component does not convey any knowledge of any part of the actual cryptographic key.

Describe how the processes observed for creating key components verified that knowledge of any one key component does not convey any knowledge of any part of the actual cryptographic key: <Report Findings Here> 6F-1.2.2 Construction of the …

Removed p. 238

Describe how the key-component access controls and access logs observed verified that authorized custodians cannot access sufficient key components or shares to reconstruct a secret or private cryptographic key: <Report Findings Here> 6F-1.3 Key components must be stored as follows:

6F-1.3 Examine documented procedures, interview responsible personnel and inspect key-component storage locations to verify that key components are stored as outlined in Requirements 6F-1.3.1 through 6F-1.3.3 below:

Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6F-1.3.1 Key components that exist in clear text clear-text outside of an SCD must be sealed in opaque, pre-numbered tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging. Note: Tamper-evident, authenticable packaging (opacity may be envelopes within tamper-evident packaging) used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must …

Removed p. 239

Responsible personnel interviewed: <Report Findings Here> 6F-1.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).

Identify the P2PE Assessor who confirms that start-up instructions and other notes used by service technicians do not contain initialization-key values written in the clear:

<Report Findings Here> 6F-1.3.2 Key components for each specific custodian must be stored in a separate secure container that is accessible only by the custodian and/or designated backup(s). Note: Furniture-based locks or containers with a limited set of unique keys

•e.g., desk drawers

•are not sufficient to meet this requirement. Components for a specific key that are stored in separate envelopes, but within the same secure container, place reliance upon procedural controls and do not meet the requirement for physical barriers. 6F-1.3.2 Inspect each key component storage container and verify …

Removed p. 240

Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised: <Report Findings Here> 6F-2.1.2 If unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification. 6F-2.1.2 Interview responsible personnel and observe implemented processes to verify that if unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification.

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

Removed p. 241

• Specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc. 6F-2.1.4.a Interview responsible personnel and review documented procedures to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).

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

• A damage assessment including, where necessary, the engagement of outside consultants.

• Details of specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.

<Report Findings Here> 6F-2.1.5 Identification of specific events that would indicate a compromise may have occurred. Such events must include but are not limited to:

• 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 6F-2.1.5 Interview responsible personnel and review documented …

Removed p. 242

Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if attempts to load a secret key or key component into an KLD or POI device fail, the same key or component is not loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI device: <Report Findings Here> 6F-3.1 Any key generated with a reversible process (such as a variant of a key) of another key must be protected in the same manner as the original key•that is, under the principles of dual control and split knowledge. Variants of the same key may be used for different purposes, but must not be used at different levels of the key hierarchy. For example, reversible transformations must not generate key-encipherment keys from PIN keys. Note: Exposure of …

Removed p. 243

• Variants used as KEKs must only be calculated from other key-encrypting keys.

• Variants of working keys must only be calculated from other working keys.

• Variants used as KEKs must only be calculated from other key-encrypting keys

• Variants of working keys must only be calculated from other working keys. <Report Findings Here> 6F-4.1 Instances of secret or private keys, and their key components, that are no longer used or that have been replaced by a new key must be destroyed 6F-4.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.

Describe how the storage locations observed verified that the sample of destroyed keys are no longer kept: <Report Findings Here>

Documented procedures reviewed: <Report Findings Here> 6F-4.2.b Observe key-destruction processes to verify that no part of the key or component can …

Removed p. 244

Describe how the key-destruction processes observed verified that no part of the key or component can be recovered: <Report Findings Here> 6F-4.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. For example, keys (including components or shares) maintained on paper must be burned, pulped, or shredded in a crosscut shredder. 6F-4.2.1.a Examine documented procedures for destroying keys and confirm that keys on all other storage media types in all permissible forms

•physically secured, enciphered, or components

•must be destroyed following the procedures outlined in ISO

•9564 or ISO

•11568.

Documented procedures reviewed: <Report Findings Here> 6F-4.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.

Describe how the key-destruction processes observed …

Removed p. 245

Describe how the key-conveyance/loading processes observed verified that any key components are destroyed once the keys are successfully loaded and validated as operational: <Report Findings Here> 6F-5.1 To reduce the opportunity for key compromise, limit the number of key custodians to the minimum required for operational efficiency. For example: 6F-5.1 Interview key custodians and key-management supervisory personnel and observe implemented processes to verify the following:

<Report Findings Here> 6F-5.1.1 Designate key custodian(s) for each component, such that the fewest number (e.g., a primary and a backup) of key custodians are assigned as necessary to enable effective key management. Key custodians must be employees or contracted personnel 6F-5.1.1 Review key-custodian assignments for each component to verify that:

• The fewest number of key custodians is assigned as necessary to enable effective key management.

• Assigned key custodians are employees or contracted personnel Describe how the key-custodian assignments observed for each component verified that:

• A …

Removed p. 246

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

<Report Findings Here> 6F-5.1.4 In order for key custodians to be free from undue influence in discharging their custodial duties, key custodians sufficient to form the necessary threshold to create a key must not directly report to the same individual except as noted below for organizations of insufficient size. For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to form the key must not report to the same individual. The components collectively held by an individual and his or her direct reports shall not constitute a quorum (or shall not provide any information about the value of the key …

Removed p. 247

• Tamper-evident package number (if applicable) 6F-6.1.a Review log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:

• Loaded to an SCD Log files reviewed: <Report Findings Here> Describe how the audit log settings observed verified that logs are kept for any time that keys, key components, or related materials are:

• Tamper-evident 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 package number (if applicable) <Report Findings Here> 6F-7.1 If backup copies of secret and/or private keys exist, they must be maintained in accordance with the same requirements as are followed for the primary keys.

• Subject to at least the same level of security control as operational keys as specified in this document <Report Findings Here> 6F-7.2 If backup copies are created, …

Removed p. 248

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

• Inspect backup storage locations and access controls or otherwise verify through examination of documented procedures and interviews of personnel that backups are maintained as follows: - Securely stored with proper access controls - Under at least dual control - Subject to at least the same level of security control as operational keys as specified in this document Documented procedures reviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> Backup records reviewed: <Report Findings Here> Describe how the backup processes observed verified that backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys: <Report Findings Here> Describe how the backup storage locations observed verified that backups are maintained as follows:

• …

Removed p. 249

• Background checks for personnel (within the constraints of local laws

Responsible HR personnel interviewed: <Report Findings Here> 6G-1.1 Secure cryptographic devices

•such as HSMs and POI devices

•must be placed into service only if there is assurance that the equipment has not been subject to unauthorized modification, substitution, or tampering and has not otherwise been subject to misuse prior to deployment. 6G-1.1.a Review documented procedures to confirm that processes are defined to provide the following assurances prior to the loading of cryptographic keys:

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

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

Access-control documentation reviewed:

Vendor documentation or other information source …

Removed p. 250

Documented procedures reviewed: <Report Findings Here> 6G-1.1.1.1 Access to all POIs and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection. 6G-1.1.1.1.a Examine access-control documentation and device configurations to verify that access to all POIs and key-injection/loading devices is defined and documented.

<Report Findings Here> Describe how the device configurations observed verified that access to all POIs and key injection/loading devices is defined and documented: <Report Findings Here> 6G-1.1.1.1.b For a sample of POIs and other SCDs, observe authorized personnel accessing devices and examine access logs to verify that access to all POIs and other SCDs is logged.

Sample of POIs and other SCDs: <Report Findings Here> Access logs reviewed: <Report Findings Here> Describe how the observation of authorized personnel accessing devices and access logs verified that access to all POIs and other SCDs is logged: <Report Findings Here> 6G-1.1.1.1.c …

Removed p. 251

• All personnel with access to POIs and other SCDs are documented in a formal list.

• All personnel with access to POIs and other SCDs are authorized by management.

• The authorizations are reviewed annually.

Documented authorizations reviewed: <Report Findings Here> 6G-1.1.1.3.b For a sample of POIs and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in the formal list have access to devices.

Sample of POIs and other SCDs reviewed:

Sample of POIs and other SCDs reviewed:

<Report Findings Here> Describe how the implemented access controls observed verified that only personnel documented and authorized in the formal list have access to devices: <Report Findings Here> 6G-1.2 Implement a documented “chain of custody” to ensure that all devices are controlled from receipt through to placement into service. The chain of custody must include records to identify responsible personnel for each interaction with the devices. 6G-1.2.a Examine documented processes to …

Removed p. 252

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

• Use of physically secure and trackable packaging (e.g., pre-serialized, counterfeit-resistant, tamper-evident packaging). The devices are then stored in such packaging, or in secure storage, until key insertion and deployment occurs.

• A secret, device-unique “transport-protection token” is loaded into the secure storage area of each device at the manufacturer’s facility. Before key-insertion, 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.

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

Removed p. 253

Documented procedures reviewed: <Report Findings Here> 6G-1.4.1.b For a sample of received devices, review 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.

<Report Findings Here> 6G-1.4.2 The security policy enforced by the HSM must not allow unauthorized or unnecessary functions. HSM API functionality and commands that are not required in account data-processing equipment to support specified functionality must be disabled before the equipment is commissioned. 6G-1.4.2.a Obtain and review the defined security policy to be enforced by the HSM Documented security policy reviewed: <Report Findings Here> 6G-1.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 …

Removed p. 254

• removed 6G-1.4.3.3 Observe inspection processes and interview responsible personnel to confirm processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti-tamper mechanisms are not

Responsible personnel interviewed: <Report Findings Here> Describe how the inspection processes observed verified that processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti-tamper mechanisms are not modified or removed: <Report Findings Here> 6G-1.4.3.4 Maintaining records of the tests and inspections, and retaining records for at least one year 6G-1.4.3.4.a Examine records of inspections and interview responsible personnel to verify records of the tests and inspections are maintained.

Records of inspections examined: <Report Findings Here> 6G-1.4 Maintain HSMs in tamper-evident packaging or in secure storage until ready for installation.

6G-1.4.a Examine documented procedures to verify they require devices be maintained in tamper-evident packaging until ready for installation.

Documented procedures reviewed: <Report Findings Here> …

Removed p. 255

• Each production run must be associated with a predefined inventory of identified POI devices to be injected or initialized with keys.

• Unauthorized personnel must not be able to modify this inventory without detection.

• All POI devices to be initialized with keys on a production run must be identified and accounted for against the inventory.

• Unauthorized POI devices submitted for injection or initialized must be rejected by the injection platform and investigated.

• Once processed by the KIF, whether successfully initialized with keys or not, all submitted POI devices must be identified and accounted for against the inventory. Note: The KIF platform must ensure that only authorized devices can ever be injected or initialized with authorized keys. Processes must prevent (1) substitution of an authorized device with an unauthorized device, and (2) insertion of an unauthorized device into a production run. 6G-2.3.a Obtain and review documentation of inventory control and monitoring …

Removed p. 256

Documented procedures reviewed: <Report Findings Here> 6G-3.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 Personnel interviewed: <Report Findings Here> Describe how the demonstration verified that dual control is implemented for all critical decommissioning processes: <Report Findings Here> 6G-3.1.2 Keys are rendered irrecoverable (e.g., zeroized) for SCDs. If data cannot be rendered irrecoverable, devices must be physically destroyed under dual control to prevent the disclosure of any sensitive data or keys. 6G-3.1.2 Interview personnel and observe demonstration of processes for removing SCDs from service to verify that all keying material is rendered irrecoverable (e.g., zeroized), or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.

Personnel interviewed: <Report Findings Here> Describe how the demonstration verified that all keying material and account data …

Removed p. 257

Personnel interviewed: <Report Findings Here> Records of testing examined: <Report Findings Here> 6G-4.1 For HSMs and other SCDs used for the generation or loading of cryptographic keys for use in POI devices, procedures must be documented and implemented to protect against unauthorized access and use. Required procedures and processes include the following: 6G-4.1 Examine documented procedures to confirm that they specify protection against unauthorized access and use for HSMs and other devices used for the generation or loading of cryptographic keys for use in POI devices, and that they cover the requirements at 6G-4.1.1 through 6G-4.1.5 below.

Documented procedures reviewed: <Report Findings Here> 6G-4.1.1 Devices must not be authorized for use except under the dual control of at least two authorized people. Note: Dual control consists of logical and/or physical characteristics. For example, dual control may be implemented for logical access via two individuals with two different passwords at least five …

Removed p. 258

• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing;

• To place the device into a state that allows for the input or output of clear- text key components;

• For all access to KLDs Dual-control mechanisms examined: <Report Findings Here> Describe how the observation of authorized personnel performing the defined activities verified that dual control is implemented for the following:

• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing;

• To place the device into a state that allows for the input or output of clear- text key components;

• For all access to KLDs. <Report Findings Here> 6G-4.1.4 Devices must not use default passwords.

6G-4.1.4.a Examine password policies and documented procedures to confirm default passwords must not be used for HSMs, KLDs, and other SCDs used to generate or load cryptographic keys.

<Report Findings Here> 6G-4.1.4.b Observe …

Removed p. 259

Responsible personnel interviewed: <Report Findings Here> Describe how the devices and processes observed verified that devices are at all times within a secure room and either:

• Locked in a secure cabinet and/or sealed in tamper-evident packaging at all times, or

• Under the continuous supervision of at least two authorized people at all times. <Report Findings Here> 6G-4.9 Distributed functionality of the KIF that is used for generation and transfer of keys must communicate via mutually authenticated channels. All key transfers between distributed KIF functions must meet the requirements of 6C. 6G-4.9.1 The KIF must ensure that keys are transmitted between KIF components in accordance with 6C.

6G-4.9.1.a Examine documented procedures for key conveyance or transmittal to verify that keys used between KIF components are addressed in accordance with applicable criteria in 6C.

Documented procedures reviewed: <Report Findings Here> 6G-4.9.1.b Interview responsible personnel and observe conveyance processes to verify that the documented procedures …

Removed p. 260

Responsible personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that the documented procedures are followed for key conveyance or transmittal for keys used between KIF components:

<Report Findings Here> 6G-4.9.5 The KIF must implement a mutually authenticated channel for establishment of enciphered secret or private keys between POI devices and an HSM at the KIF. 6G-4.9.5 Examine documented procedures to confirm they specify the establishment of a mutually authenticated channel for establishment of enciphered secret or private keys between sending and receiving devices• e.g., POI devices and HSMs.

Documented procedures reviewed: <Report Findings Here> 6G-4.9.6 Mutual authentication of the sending and receiving devices must be performed.

• KIFs must validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device.

• POI devices must validate authentication credentials of KDHs prior to any key transport, exchange, or establishment with that device.

• When a KLD is used …

Removed p. 261

Identify the P2PE Assessor who confirms that the secure area designated for key injections is constructed with extended walls from the real floor to the real ceiling using sheetrock or wire mesh:

<Report Findings Here> 6G-4.10.2 Any windows into the secure room must be locked and protected by alarmed sensors.

6G-4.10.2.a Observe all windows in the secure room to verify they are locked and protected by alarmed sensors.

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

<Report Findings Here> 6G-4.10.3 Any windows must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure area.

6G-4.10.3 Observe all windows in the secure room to verify they are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.

Describe how the observation of windows and glass walls in the secure areas verified that they are covered, rendered opaque, or positioned to …

Removed p. 262

• Dual-access for entry to the secure area

• Dual-access for entry to the secure area

• Anti-pass-back Describe how the observation of authorized personnel entering the secure area verified that a badge-control system is in place that enforces the following requirements:

• Anti-pass-back <Report Findings Here> 6G-4.10.6 The badge-control system must support generation of an alarm when one person remains alone in the secure area for more than 30 seconds. Note: Examples of alarm-generation mechanisms include but are not limited to motion detectors, login/logout controls, biometrics, badge sensors, etc. 6G-4.10.6 Examine alarm mechanisms and interview alarm-response personnel to verify that the badge-control system supports generation of an alarm when one person remains alone in the secure area for more than 30 seconds.

Alarm-response personnel interviewed: <Report Findings Here> Describe how the alarm mechanisms observed verified that the badge-control system supports generation of an alarm when one person remains alone in the secure area …

Removed p. 263

Identify the P2PE Assessor who confirms the location of the CCTV server and digital-storage are located in a secure area that is separate from the key-injection area:

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

Identify the P2PE Assessor who identified all personnel with access to the CCTV server/storage area and the key-injection area, and who confrms that personnel with access to the key- injection area do not have access to the CCTV server/storage area:

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

• SCDs, both pre and post key injection,

• SCDs, both pre and post key injection,

• Any safes that are present, and

• Any safes that are present, …

Removed p. 264

Documented records reviewed: <Report Findings Here> 6I-1.1 Track status of key-management services for POIs and HSMs and provide reports to solution provider annually and upon significant changes, including at least the following:

• Details of any known or suspected compromised keys, per 6F-2.1 Note that adding, changing, or removing POI device and/or HSM types, or critical key management methods may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding or removing elements of a P2PE solution. 6I-1.1.a Review 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:

<Report Findings Here> Responsible component-provider personnel interviewed:

Document Comparison

From Revision History

Content Changes