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

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

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

Added p. 5

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 in a P2PE Solution that has the potential to access clear-text cardholder data must complete this P-ROV.

Decryption Management Services (DMS) Solution (SP) Decryption Management CP (DMCP) Decryption Management Services relates to the management of a decryption environment, …

Added p. 8

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

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

Additional services provided by PA-QSA(P2PE)/QSA (P2PE)/QSA company The 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. 13

Functionality provided (for all POI device types supported) The columns below represent review of the PTS Listing approval details (to be reported under “PTS Listing”) as well as the observed device configuration (to be reported under “P2PE”). This table will match what functionality was listed for PTS against what is observed as being utilized within 2A-1.2.

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 Y N

Note: If there is a different response for PTS Listing compared to P2PE functionality …

Added p. 15

• Provide high-level data-flow diagram(s) that shows details of all flows of account data, including:

Added p. 20

2A-1.2 For each type of POI device being assessed as part of the application assessment, verify that the application only uses SRED-validated account-data- capture mechanisms.

Added p. 23

<Report Findings Here> 2A-3.1.1 The output of any truncated PANs must adhere to the allowable number of digits as specified in PCI DSS and/or related FAQs.

Note: This requirement does not supersede stricter requirements in place for displays of PAN•e.g., legal or payment card brand requirements for point-of-sale (POS) receipts.

2A-3.1.1.a If the application outputs any truncated PANs, examine the application’s design documentation and verify it contains a description of the application’s function, including that any truncation of PANs adheres to the allowable number of digits as specified in PCI DSS and/or related FAQs.

Design documentation examined: <Report Findings Here>

Added p. 24

Describe how the source code review verified that the output of any truncated PANs adheres to the allowable number of digits as specified in PCI DSS and/or related FAQs.

<Report Findings Here> 2A-3.1.2.c If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), Describe test transactions performed (must utilize all functions of the application that handle account data):

Note: The application may be the only POI-resident application at the time of assessment, but other assessed applications may be

<Report Findings Here> 2A-3.4 Any whitelisting functionality implemented by the application must include guidance in the application’s Implementation Guide that includes the following:

Added p. 29

2B-1.1.1 Examine the software-development and testing procedures and interview responsible personnel to verify that live PANs are not used for testing or development.

Added p. 30

2B-1.1.2 Examine software-development procedures and interview responsible personnel to verify that development, test, and/or custom application data/accounts, user IDs, and passwords are removed before an application is released for production or released to customers.

2B-1.2 Examine software-development procedures and interview responsible personnel to verify the application vendor performs reviews for all application code changes and non-code configuration mechanisms as follows:

Added p. 36

<Report Findings Here> 2B-1.7 The application vendor must document and follow a software-versioning methodology as part of their system-development lifecycle. The methodology must follow the procedures in the P2PE Program Guide for changes to payment applications and include at least the following:

Added p. 37

<Report Findings Here> 2B-1.8.d Select a sample of recent payment application changes and review the change control documentation that specifies the type of application change Sample of recent payment application changes reviewed:

Added p. 41

Software release processes reviewed: <Report Findings Here> 2B-1.13.b For a sample of recent releases of application and application updates, review approval documentation to verify it includes:

Note: POI device vendor security guidance is intended for application developers, system integrators, and end-users of the platform to meet the PCI PTS POI Open Protocol requirements as part of a PCI-approved POI device evaluation.

Added p. 42

2B-2.1.1 Perform a source-code review and verify that the application:

<Report Findings Here> 2B-2.3 Applications do not bypass or render ineffective any application segregation that is enforced by the POI device.

Added p. 44

<Report Findings Here> 2B-2.5 Perform a source-code review and verify that applications do not bypass or render ineffective any OS hardening which is implemented by the POI device, in accordance with the device vendor’s security guidance.

2B-2.5 Perform a source-code review and verify that applications do not bypass or render ineffective any encryption or account-data-security methods implemented by the POI device, in accordance with the device vendor’s security guidance.

2B-3.1.1 Review the application’s Implementation Guide required at 2C-3 of this document, and confirm it includes security guidance for solution providers, describing how cryptographic keys and/or certificates have to be used and managed.

Note: The application may provide additional encryption on the SRED-encrypted account data however it cannot bypass or replace the SRED encryption of the clear-text account data.

<Report Findings Here> 2B-4.2 The application must not be able to decrypt SRED-encrypted account data. I.e., the application must not be able to recover the original …

Added p. 48

<Report Findings Here> 2C-2.1.2 The application developer includes guidance for whoever signs the application, including requirements for using an SCD with dual control for the application- signing process.

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 Application ~~Revision 1.2~~

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

Removed p. 2

Clarify intent of 6C-3.1 and 6D-1.5 (in both Domain 6 and Annex B) with regards to the use of triple-length TDEA keys and align with key table of Annex C.

Clarify domain applicability for CA/RAs.

Modified p. 4

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

Use of this Reporting Template is mandatory for all P2PE v3.0 submissions for P2PE Applications.

Modified p. 4

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

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

Modified p. 4 → 6

- Section 1: Contact Information and Report Date

• Section 1: Contact Information and Report Date

Modified p. 4 → 6

- Section 2: Summary Overview

• Section 2: Summary Overview

Modified p. 4 → 6

- Section 3: Details and Scope of P2PE Assessment

• Section 3: Details and Scope of P2PE Assessment

Modified p. 4 → 6

- 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. 5 → 6

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. 5 → 6

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

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

Modified p. 6 → 7

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

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

Modified p. 8 → 9

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

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

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

Modified p. 9 → 11

2. Summary Overview 2.1 P2PE Application Details P2PE application name:

2. Summary Overview 2.1 P2PE Application Details P2PE application name: Application version:

Modified p. 9 → 11

~~Yes No~~ If yes, provide PCI SSC Ref # or N/A Has the application been developed in-house by the solution provider for use only in their own solution? If ~~‘yes,’~~ complete the two questions to the right of this cell.

If yes, provide PCI SSC Ref # or N/A Has the application been developed in-house by the solution provider for use only in their own solution? If “Yes,” complete the two questions to the right of this cell.

Modified p. 10 → 12

Define what types of changes the vendor includes as a “No Impact” ~~change (refer to the P2PE Program Guide for information on what constitutes a No Impact Change):~~

Define what types of changes the vendor includes as a “No Impact” change:

Removed p. 11

Domain 1

• Encryption Device and Application Management N/A Domain 2

• Application Security Yes No Domain 3

• P2PE Solution Management N/A Domain 4

• Merchant-managed Solutions N/A Domain 5

• Decryption Environment N/A Domain 6

• P2PE Cryptographic Key Operations and Device Management N/A Domain 6

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

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

• Annex B: Key-Injection Facilities N/A

Modified p. 11 → 13

Note: P2PE ~~applications~~ and P2PE non-payment software do not meet the PTS definition of “firmware” and are not reviewed as part of the PTS POI assessment. Additionally, software meeting the PTS definition of “firmware” is not reassessed during a P2PE assessment ~~(PTS~~ firmware is not ~~considered a P2PE payment application,~~ nor ~~is it P2PE non-payment software).~~

Note: P2PE Applications and P2PE non-payment software do not meet the PTS definition of “firmware” and are not reviewed as part of the PTS POI assessment. Additionally, software meeting the PTS definition of “firmware” is not reassessed during a P2PE assessment (Any software intended for use in a P2PE solution that does not meet the PTS definition of "firmware" must be assessed in accordance with the PCI P2PE standard and is subject to all applicable P2PE security requirements. Note that …

Modified p. 12 → 14

3. Details and Scope of P2PE Assessment 3.1 Application details For each POI the application was tested on:

3. Details and Scope of P2PE Assessment 3.1 P2PE Application details For each POI device the application was tested on:

Modified p. 12 → 14

~~• For all application functions, provide the following: o~~ Description of all application processes related to each function o Description of all communication channels, connection methods, and communication protocols used by the application for all internal and external communication channels o Details of any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to account data by the application o Other necessary application functions or processes, as applicable

− Description of all application processes related to each function − Description of all communication channels, connection methods, and communication protocols used by the application for all internal and external communication channels − Details of any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to account data by the application − Other necessary application functions or processes, as applicable

Modified p. 12 → 14

• Identify any functionality of the application that was not included in the assessment <Insert P2PE Application detailed diagram(s)> ~~3.2 Overview of P2PE Application data flow For each POI the application was tested on:~~

• Identify any functionality of the application that was not included in the assessment <Insert P2PE Application detailed diagram(s)>

Modified p. 12 → 15

~~• Provide high-level data flow diagram(s) that shows details of all flows of account data, including: o~~ All flows and locations of encrypted account data (including data input, output, and within the ~~POI) o~~ All flows and locations of ~~cleartext~~ account data (including data input, output, and within the ~~POI)~~

− All flows and locations of encrypted account data (including data input, output, and within the POI device) − All flows and locations of clear-text account data (including data input, output, and within the POI device).

Modified p. 12 → 15

~~• Identify the following for each data flow: o~~ How and where account data is transmitted, processed, and/or stored o The types of account data involved (for example, full track, PAN, expiry date, etc.) o All components involved in the transmission, processing, or storage of account data ~~Note: Include all types of data flows, including any output to hard copy/paper media.~~

− How and where account data is transmitted, processed, and/or stored − The types of account data involved (for example, full track, PAN, expiry date, etc.) − All components involved in the transmission, processing, or storage of account data

Modified p. 12 → 15

Removed p. 13

• Authentication mechanisms:

• Authentication database:

• Security of authentication data storage:

Modified p. 13 → 16

Description of component necessary for application functioning Type of component (for example, software, hardware) Role of component 3.4 Application ~~authentication mechanisms Describe~~ the ~~application’s end-to-end authentication methods, as follows:~~

Description of component necessary for application functioning Type of component (for example, software, hardware) Role of component 3.4 Facilities Lab environment used by the P2PE Assessor for this assessment Identify whether the lab was provided by the P2PE Assessor or the Application Vendor: P2PE Assessor’s Lab Application Vendor’s Lab Address of the lab environment used for this assessment:

Modified p. 15 → 18

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

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

Modified p. 15 → 18

Reference # (optional use) Document Name (Title of the IG) Version Number Document date (latest version date) Which POI device type(s) is addressed? (Must align with Section 2.5) 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 POI device type(s) is addressed? (Must align with Section 2.5) All other documentation reviewed for this P2PE Assessment:

Modified p. 15 → 18

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

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

Modified p. 16 → 19

4. Findings and Observations ~~Domain 2:~~ Application Security

• Summary of Findings ~~Domain 2:~~ P2PE Validation Requirements Summary of Findings (check one) In Place N/A Not in 2A Protect PAN and SAD 2A-1 The application executes on a PCI-approved POI device with SRED enabled and active.

4. Findings and Observations Application Security

• Summary of Findings P2PE Validation Requirements Summary of Findings (check one) In Place N/A Not in Place 2A Protect PAN and SAD 2A-1 The application executes on a PCI-approved POI device with SRED enabled and active.

Modified p. 17 → 20

~~• SRED listed as a function provided.~~ 2A-1.1 For each POI device type used by the application, 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:

2A-1.1 For each POI device type used by the application, 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:

Modified p. 17 → 20

<Report Findings Here> 2A-1.2 The application must only use the PTS SRED-validated ~~account-data capture~~ mechanisms of the underlying POI device for accepting and processing P2PE transactions. ~~2A-1.2 For each type of POI device being assessed as part of the application assessment, verify that the application only uses SRED-validated account data capture mechanisms.~~

<Report Findings Here> 2A-1.2 The application must only use the PTS SRED-validated account-data-capture mechanisms of the underlying POI device for accepting and processing P2PE transactions.

Modified p. 17 → 20

For each POI device type used in the application, describe how the application only uses SRED-validated ~~account data capture~~ mechanisms:

For each POI device type used in the application, describe how the application only uses SRED-validated account-data-capture mechanisms:

Modified p. 17 → 20

<Report Findings Here> 2A-2.1 The application vendor must ~~document~~ all flows and ~~justify~~ all uses of PAN and/or SAD input into, processed by, and output from the application.

<Report Findings Here> 2A-2.1 The application vendor must maintain current documentation for all flows and provide business justification for all uses of PAN and/or SAD input into, processed by, and output from the application.

Modified p. 17 → 20

Describe how the source-code review verified that PAN and/or SAD are only utilized according to the documentation: ~~<Report Findings Here> 2A-2.2 The application must not store PAN and/or SAD (even if encrypted) as follows:~~

Describe how the source-code review verified that PAN and/or SAD are only utilized according to the documentation:

Removed p. 18

<Report Findings Here> 2A-2.3 The application must not retain PAN and/or SAD in working memory any longer than strictly necessary.

Modified p. 18 → 21

Describe how the source-code review verified that the application is designed such that PAN is not stored after the payment transaction is completed: <Report Findings Here> Describe how the source-code review verified that the application is designed such that SAD is not stored after authorization is completed: <Report Findings Here> 2A-2.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all …

<Report Findings Here> 2A-2.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that:

Modified p. 18 → 22

Describe how the source-code review verified that PAN and/or SAD is cleared from all working memory locations after use, including local variables (before exiting the function): ~~<Report Findings Here>~~

Describe how the source-code review verified that PAN and/or SAD is cleared from all working memory locations after use, including local variables (before exiting the function):

Modified p. 19 → 22

<Report Findings Here> 2A-2.4 The application must securely delete any PAN and/or SAD stored during application processing.

<Report Findings Here> 2A-2.4 The application must securely delete any PAN and/or SAD that was stored during application processing.

Modified p. 19 → 22

2A-2.4.a Examine the application’s design documentation and verify it describes the process used by the application to securely delete any PAN and/or SAD stored during application processing.

2A-2.4.a Examine the application’s design documentation and verify it describes the process used by the application to securely delete any PAN and/or SAD that was stored during application processing.

Modified p. 19 → 22

~~Describe how the source-code renders all stored PAN and/or SAD irrecoverable once application processing is completed, in accordance with industry-accepted standards for secure deletion of data:~~ <Report Findings Here> 2A-2.4.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that the …

<Report Findings Here> 2A-2.4.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that the process Describe test transactions performed (must utilize all functions of the application that handle account data):

Modified p. 19 → 22

~~Describe test transactions performed (must utilize all functions of the application that handle account data):~~ <Report Findings Here> Describe forensic tools and/or methods used to inspect the test transactions:

<Report Findings Here> Describe forensic tools and/or methods used to inspect the test transactions:

Modified p. 19 → 23

~~<Report Findings Here> 2A-3.1 The application must not output clear-text account data outside of the POI device.~~ 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 is assessed at Requirement 2A-3.4 2A-3.1.a Examine the application’s design documentation and verify it contains a description of the application’s function, including that the application does not output clear-text account data outside of the POI device.

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 is assessed at Requirement 2A-3.4 2A-3.1.a Examine the application’s design documentation and verify it contains a description of the application’s function, including that the application does not output clear-text account data outside of the POI device.

Modified p. 19 → 23

Describe how the source-code review verified that the application never outputs ~~clear-text~~ account data outside of the POI device: ~~<Report Findings Here>~~

Describe how the source-code review verified that the application never outputs clear- text account data outside of the POI device:

Modified p. 20 → 24

• The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and is not attached via cabling or other networking mechanisms.

• The P2PE application securely deletes the clear-text PAN after completion of printing. Note that Domain 1 (at 1B.1.1) and Domain 3 (at 3A-1.3) also include requirements that must be met for any POI device and for a P2PE solution provider, respectively, that facilitates merchant printing of …

• The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and is not attached via cabling or other networking mechanisms.

• The P2PE application securely deletes the clear-text PAN after completion of printing.

Modified p. 20 → 24

Describe how the source-code review verified that the application only transmits ~~clear-text~~ PAN internally within the POI device to an integrated printer that is part of the ~~PCI-approved~~ POI device and does not include any functionality that sends clear-text PANs to any devices attached via cabling or other networking mechanisms: <Report Findings Here> Describe how the source-code review verified that the P2PE application securely deletes the clear-text PAN after completion of printing: <Report Findings Here> 2A-3.1.2.c If the application facilitates …

Describe how the source-code review verified that the application only transmits clear- text PAN internally within the POI device to an integrated printer that is part of the PCI- approved POI device and does not include any functionality that sends clear-text PANs to any devices attached via cabling or other networking mechanisms:

Modified p. 21 → 25

<Report Findings Here> 2A-3.2 The application must not facilitate, via its own logical interface(s), sharing of clear-text account data directly with other ~~applications.~~ Note: The application is allowed to share clear-text account data directly with the POI device’s SRED-approved firmware. ~~2A-3.2.a Examine the application’s Implementation Guide required at 2C-3 of this document and determine that it includes the following:~~

<Report Findings Here> 2A-3.2 The application must not facilitate, via its own logical interface(s), sharing of clear-text account data directly with other applications (including non-payment software). Note: The application is allowed to share clear-text account data directly with the POI device’s SRED-approved firmware.

Modified p. 21 → 25

• A list of all logical interfaces for the application, and the function/purpose of each.

• The logical interfaces intended for sharing of clear-text account data (e.g., those used to pass clear-text data back to the approved firmware of the POI device).

• The logical interfaces not intended for sharing of clear-text account data (e.g., those for communication with other applications).

• Examine the logical interfaces used to communicate with other applications and confirm that the application cannot share clear-text account data with …

Modified p. 21 → 25

• added to a solution that includes ~~pre- approved~~ applications. The assessor must test this requirement with this point in mind.

• added to a solution that includes pre-approved applications. The assessor must test this requirement with this point in mind.

Modified p. 22 → 26

<Report Findings Here> 2A-3.3.b Examine the application’s Implementation Guide required at 2C-3 of this ~~document~~ and verify it includes guidance that the use of any other method for external communication is not allowed.

<Report Findings Here> 2A-3.3.b Examine the application’s Implementation Guide required at 2C-3 of this document, and verify it includes guidance that the use of any other method for external communication is not allowed.

Modified p. 22 → 27

~~<Report Findings Here> 2A-3.3.c Perform a~~ source-code review ~~and verify~~ that, when configured appropriately, the application only utilizes the external communication methods included in the POI device vendor’s security guidance and does not implement its own external communication ~~methods (e.g., does not implement its own IP stack).~~

Describe how the source-code review verified that, when configured appropriately, the application only utilizes the external communication methods included in the POI device vendor’s security guidance and does not implement its own external communication methods:

Modified p. 22 → 27

Describe how the source-code review verified that, when configured appropriately, the application only utilizes the external communication methods included in the POI device vendor’s security guidance and does not implement its own external communication methods: <Report Findings Here> 2A-3.3.d Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or …

<Report Findings Here> 2A-3.3.d Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that:

Removed p. 23

Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2A-3.4.a:

Modified p. 23 → 27

• Description and justification for the ~~functionality.~~

• Description and justification for the functionality

Modified p. 23 → 27

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

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

Modified p. 23 → 27

• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data. 2A-3.4.a For any whitelisting functionality implemented by the application, examine the application’s Implementation Guide required at 2C-3 of this document and verify it contains details to describe any whitelisting functionality and that it provides instructions as follows:

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

Modified p. 23 → 28

• How to configure the application functionality to ensure the output of clear- text account data is prohibited, except for non-PCI payment brand account/card data

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

• How to establish cryptographically authentication by the POI device’s firmware.

• That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data.

• That such functionality must be approved by …

Modified p. 23 → 28

<Report Findings Here> 2B-1.1 Applications must be developed based on industry best practices and in accordance with the POI device vendor's security guidance, and information security is incorporated throughout the software development life cycle. These processes must include the following:

PCI payment brand account/card data Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2A-3.4 <Report Findings Here> 2B-1.1 Applications must be developed based on industry best practices and in accordance with the POI device vendor's security guidance, and information security is incorporated throughout the software development life cycle. These processes must include the following:

Removed p. 24

<Report Findings Here> 2B-1.1.b Examine the POI device vendor’s security guidance, and verify that any specified software development processes are:

2B-1.1.1 Live PANs are not used for testing or development. Documented software development processes reviewed:

Modified p. 24 → 28

• Information security is included throughout the software development life cycle.

• Applications are developed in accordance with all applicable P2PE requirements. .

• Information security is included throughout the software development life cycle.

• Applications are developed in accordance with all applicable P2PE requirements.

Modified p. 24 → 29

• Examine ~~written~~ software development processes and interview software developers.

• Examine testing documentation and samples of test data, observe testing processes, and interview software-testing personnel.

• Examine the final application product.

• Examine software development processes and interview software developers.

• Examine testing documentation and samples of test data, observe testing processes, and interview software-testing personnel.

• Examine the final application product.

Removed p. 25

• removed before applications are released for production or released to customers. 2B-1.1.2 Examine written software-development procedures and interview responsible personnel to verify that development, test, and/or custom application data/accounts, user IDs, and passwords are

• removed before an application is released for production or released to customers.

Modified p. 25 → 30

<Report Findings Here> Describe how testing documentation samples of test data and the final application product verified that development, test, and/or custom application data/accounts, user IDs, and passwords are removed before an application is released for production or released to customers: <Report Findings Here> 2B-1.2 Application code and any non-code configuration mechanisms must be reviewed prior to every release or update. The review process includes the following: 2B-1.2 Examine written software-development procedures and interview responsible personnel to verify the application …

<Report Findings Here> Describe how testing documentation samples of test data and the final application product verified that development, test, and/or custom application data/accounts, user IDs, and passwords are removed before an application is released for production or released to customers:

Modified p. 25 → 30

• Reviews are performed by an individual, other than the code author, who is knowledgeable in code-review techniques and secure coding practices.

• Changes to code that manages security-sensitive configuration options are reviewed to confirm that they will not result in the exposure of PCI ~~payment-brand~~ accounts/cards.

• Code reviews ensure code is developed according to secure coding guidelines.

• Reviews are performed by an individual, other than the code author, who is knowledgeable in code-review techniques and secure coding practices.

• Changes to code that manages security-sensitive configuration options are reviewed to confirm that they will not result in the exposure of PCI payment- brand accounts/cards.

• Code reviews ensure code is developed according to secure coding guidelines.

Modified p. 25 → 31

<Report Findings Here> Describe how code review results for the sample of code changes confirmed that code reviews are performed by an individual other than the code author who is knowledgeable in code-review techniques and secure coding practices: ~~<Report Findings Here> 2B-1.2.2 Performing code reviews to ensure code is developed according to secure coding guidelines.~~

<Report Findings Here> Describe how code review results for the sample of code changes confirmed that code reviews are performed by an individual other than the code author who is knowledgeable in code-review techniques and secure coding practices:

Removed p. 26

<Report Findings Here> 2B-1.3.b Examine the application’s Implementation Guide required at 2C-3 of this document and verify it includes the following:

Modified p. 26 → 31

Describe how code review results for the sample of code changes verified that code reviews ensure code is developed according to secure coding guidelines: ~~<Report Findings Here> 2B-1.2.3 Confirming that appropriate corrections are implemented prior to release.~~

Describe how code review results for the sample of code changes verified that code reviews ensure code is developed according to secure coding guidelines:

Modified p. 26 → 31

<Report Findings Here> 2B-1.3 All changes to the application must follow change-control procedures. The procedures must include the following: ~~2B-1.3.a Obtain and examine the developer’s change-control procedures for software modifications, and verify that the procedures require the following:~~

<Report Findings Here> 2B-1.3 All changes to the application must follow change-control procedures. The procedures must include the following:

Removed p. 27

<Report Findings Here> 2B-1.3.3.b Verify that all changes (including patches) are tested per secure coding guidance before being released.

Modified p. 27 → 33

• Developing with defensive (protective) techniques regarding the logical input interfaces of the application. ~~2B-1.4 Examine software development processes and interview software developers to verify that secure coding techniques are defined and include:~~

• Developing with defensive (protective) techniques regarding the logical input interfaces of the application.

Modified p. 28 → 34

~~Describe how manual or automated penetrating testing performed verified that applications are not vulnerable to common coding vulnerabilities:~~ <Report Findings Here> 2B-1.4.2 Application risk-assessment techniques (e.g., ~~(application~~ threat-modeling) must be used to identify potential application-security design flaws and vulnerabilities during the software-development process. Risk-assessment processes include the following:

<Report Findings Here> 2B-1.4.2 Application risk-assessment techniques (e.g., application threat-modeling) must be used to identify potential application-security design flaws and vulnerabilities during the software-development process. Risk-assessment processes include the following:

Modified p. 28 → 34

~~• Documentation of application risk-assessment results for management review and approval.~~ 2B-1.4.2 Examine written software development procedures and interview responsible personnel to verify the vendor uses application risk-assessment techniques as part of the software development process, and that the processes include:

2B-1.4.2 Examine written software development procedures and interview responsible personnel to verify the vendor uses application risk-assessment techniques as part of the software development process, and that the processes include:

Modified p. 28 → 34

• Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries.

• Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.

• Identification of all areas within applications that interact with account data, as well as any process-oriented outcomes that could lead to the exposure of account data.

• A list of potential threats and vulnerabilities resulting from account-data flow analyses, and assigned risk ratings (e.g., high, medium, …

• Documentation of application risk-assessment results for management review and approval.

• Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries.

• Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.

• Identification of all areas within applications that interact with account data, as well as any process-oriented outcomes that could lead to the exposure of account data.

• A list of potential threats and vulnerabilities resulting from …

Removed p. 29

• updated as needed to address new development technologies and methods used.

Describe how mechanisms and procedures for securing source-code verified that integrity of source-code is maintained during the development process: <Report Findings Here>

Modified p. 29 → 35

• Secure application ~~design.~~

• Secure application design

Modified p. 29 → 35

• Managing sensitive data in ~~memory.~~

• Managing sensitive data in memory

Modified p. 29 → 35

• Security testing (e.g., penetration testing ~~techniques).~~

• Security testing (e.g., penetration testing techniques)

Modified p. 29 → 35

• Risk-assessment ~~techniques.~~ Note: Training for application developers may be provided in-house or by third parties. Examples of how training may be delivered include on-the-job, ~~instructor- led,~~ and computer-based. 2B-1.5.a Verify documented software development processes require training in secure development practices for application developers, as applicable for the developer’s job function and technology used.

• Risk-assessment techniques Note: Training for application developers may be provided in-house or by third parties. Examples of how training may be delivered include on-the-job, instructor-led, and computer-based.

Modified p. 29 → 35

<Report Findings Here> 2B-1.5.1 Training must be

<Report Findings Here> 2B-1.5.1 Training must be updated as needed to address new development technologies and methods used.

Modified p. 29 → 35

~~• updated as needed to address new development technologies and methods used.~~ 2B-1.5.1 Examine training materials and interview a sample of developers to verify that training is

2B-1.5.1 Examine training materials and interview a sample of developers to verify that training is updated as needed to address new development technologies and methods used.

Modified p. 29 → 35

<Report Findings Here> Responsible personnel interviewed: <Report Findings Here> ~~2B-1.6.b Examine~~ mechanisms and ~~observe~~ procedures for securing ~~source- code to verify~~ integrity of source-code is maintained during the development ~~process.~~

<Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe how mechanisms and procedures for securing source-code verified that integrity of source-code is maintained during the development process:

Modified p. 30 → 36

• Definition of elements that indicate use of wildcards. Note: Wildcards may only be substituted for elements of the version number that represent non-security impacting changes. Refer to 2B-6.3 for additional requirements on the use of wildcards. 2B-1.7.1.a Examine recent application changes, the version numbers assigned, and the change control documentation that specifies the type of application change and verify that the elements in the version number match the applicable change and the parameters defined in the documented versioning methodology.

2B-1.7.1.a Examine recent application changes, the version numbers assigned, and the change control documentation that specifies the type of application change and verify that the elements in the version number match the applicable change and the parameters defined in the documented versioning methodology.

Modified p. 30 → 36

<Report Findings Here> Describe how the recent application changes, version numbers assigned and change control documentation verified that the elements in the version number match the applicable change and the parameters defined in the documented versioning methodology: ~~<Report Findings Here> 2B-1.7.1.b Interview a sample of developers and verify that they are knowledgeable in the version scheme, including the acceptable use of wildcards in the version number.~~

<Report Findings Here> Describe how the recent application changes, version numbers assigned and change control documentation verified that the elements in the version number match the applicable change and the parameters defined in the documented versioning methodology:

Modified p. 30 → 36

Sample of developers interviewed: <Report Findings Here> ~~2B-1.8 The versioning methodology must indicate the type and impact of all application changes in accordance with the P2PE Program Guide, including:~~

Sample of developers interviewed: <Report Findings Here>

Removed p. 31

<Report Findings Here> Change control documentation reviewed:

Modified p. 31 → 37

Personnel interviewed: <Report Findings Here> Describe processes observed that verified that the documented methodology is being followed for all types of changes: <Report Findings Here> 2B-1.8.d Select a sample of recent payment application changes and review the change control documentation that specifies the type of application change to verify that the version assigned to the change matches the type of change according to the documented methodology.

Personnel interviewed: <Report Findings Here> Describe processes observed that verified that the documented methodology is being followed for all types of changes:

Modified p. 31 → 38

~~Sample of recent payment application changes~~ reviewed:

Change control documentation reviewed:

Modified p. 31 → 38

• ~~Details~~ of how wildcards are used in the versioning methodology.

• Provide details of how wildcards are used in the versioning methodology.

Modified p. 31 → 38

• Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change.

• Wildcard elements must not precede version elements that could represent security-impacting changes. Any version elements that appear after a wildcard element must not be used to represent security-impacting changes. ~~Note: Wildcards may only be used in accordance with the P2PE Program Guide.~~

• Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change.

• Wildcard elements must not precede version elements that could represent security-impacting changes. Any version elements that appear after a wildcard element must not be used to represent security-impacting changes.

Removed p. 32

<Report Findings Here> 2B-1.9.c Interview personnel and observe processes for each type of change to verify that:

<Report Findings Here> 2B-1.10 The vendor’s published versioning methodology must be communicated to customers and integrators/ resellers.

Modified p. 32 → 38

• ~~Details~~ of how wildcards are used in the versioning methodology.

• Provide details of how wildcards are used in the versioning methodology.

Modified p. 32 → 39

Personnel interviewed: <Report Findings Here> Describe processes observed that verified that wildcards are never used for any change that has an impact on security or any P2PE requirements and that elements of the version number used to represent non-security-impacting changes (including a wildcard element) are never be used to represent a security impacting change: ~~<Report Findings Here> 2B-1.9.d Select a sample of recent payment application changes and review the change control documentation that specifies the type of application change. Verify …~~

Personnel interviewed: <Report Findings Here> Describe processes observed that verified that wildcards are never used for any change that has an impact on security or any P2PE requirements and that elements of the version number used to represent non-security-impacting changes (including a wildcard element) are never be used to represent a security impacting change:

Modified p. 33 → 40

<Report Findings Here> 2B-1.11 If an internal version mapping to published versioning scheme is used, the versioning methodology must include mapping of internal versions to the external versions. ~~2B-1.11.a Examine the documented version methodology to verify it includes a mapping of internal versions to published external versions.~~

<Report Findings Here> 2B-1.11 If an internal version mapping to published versioning scheme is used, the versioning methodology must include mapping of internal versions to the external versions.

Modified p. 33 → 40

Software developers interviewed: <Report Findings Here> Describe processes observed that verified that application updates are reviewed for conformity with the versioning methodology prior to release: ~~<Report Findings Here> 2B-1.13 Software vendor must implement a process to document and authorize the final release of the application and any application updates. Documentation must include:~~

Software developers interviewed: <Report Findings Here> Describe processes observed that verified that application updates are reviewed for conformity with the versioning methodology prior to release:

Modified p. 33 → 41

~~• Confirmation that secure development processes were followed by the vendor.~~ 2B-1.13.a Examine ~~documented~~ processes to verify that final release of the application and any application updates are formally approved and documented, including a signature by an authorized party to formally approve the release and confirmation that all ~~SDLC~~ processes were ~~followed.~~

2B-1.13.a Examine software release processes to verify that final release of the application and any application updates are formally approved and documented, including a signature by an authorized party to formally approve the release and confirmation that all applicable secure development processes were followed by the vendor.

Modified p. 34 → 41

<Report Findings Here> Approval documentation reviewed: <Report Findings Here> 2B-2.1 Where the application relies on the Open Protocol functionality of the POI device firmware, the application must be developed in accordance with the POI device vendor's security guidance. Note: POI device vendor security guidance is intended for application developers, system integrators, and end-users of the platform to meet requirements in the PCI PTS Open Protocols module as part of a PCI-approved POI device evaluation. 2B-2.1.a Examine documented processes (including design …

<Report Findings Here> Approval documentation reviewed: <Report Findings Here> 2B-2.1 Where the application relies on the Open Protocol functionality of the POI device firmware, the application must be developed in accordance with the POI device vendor's security guidance.

Modified p. 34 → 42

<Report Findings Here> ~~2B-2.1.1 The~~ application ~~must~~ not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI ~~device vendor’s~~ security ~~guidance. This includes the use of:~~

<Report Findings Here> Describe how the source-code review verified that the application does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI device's vendor security guidance:

Modified p. 34 → 42

• Link ~~Layer~~ protocols

• Link layer protocols

Modified p. 34 → 42

~~• IP services~~ Note: The PTS POI Open Protocols ~~module~~ ensures that open protocols and services in POI devices do not have vulnerabilities that can be remotely exploited and yield access to sensitive data or resources in the device. The POI device vendor defines what protocols and services are supported by the device and provides guidance to their use. ~~Adding or enabling additional services or protocols, or failing to follow the issued POI device vendor’s security guidance will invalidate the …~~

Note: The PCI PTS POI Open Protocols requirements ensures that open protocols and services in POI devices do not have vulnerabilities that can be remotely exploited and yield access to sensitive data or resources in the device. The POI device vendor defines what protocols and services are supported by the device and provides guidance to their use.

Removed p. 35

• Does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI device's vendor security guidance. This includes the use of: o Link Layer protocols o IP protocols o Security protocols o IP services Describe how the source-code review verified that the application was developed according to the POI device vendor’s security guidance with respect to the documented Open Protocols: <Report Findings Here> Describe how the source-code review verified that the application does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI device's vendor security guidance: <Report Findings Here> 2B-2.2 The application-development process must include secure integration with any resources shared with or between applications.

• A description of how the application connects to and/or uses shared resources.

• Instructions for …

Modified p. 35 → 42

~~• Was~~ developed according to the POI device vendor’s security guidance with respect to the documented Open ~~Protocols.~~

Describe how the source-code review verified that the application was developed according to the POI device vendor’s security guidance with respect to the documented Open Protocols:

Modified p. 35 → 43

~~2B-2.2.a Review the POI device vendor's security guidance and the application’s Implementation Guide.~~ Confirm that the application’s Implementation Guide required at 2C-3 of this document is in accordance with any applicable information in the POI device vendor's security ~~guidance,~~ and includes the following:

Confirm that the application’s Implementation Guide required at 2C-3 of this document is in accordance with any applicable information in the POI device vendor's security guidance and includes the following:

Modified p. 35 → 43

• A list of shared ~~resources.~~

• A list of shared resources

Modified p. 35 → 43

Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-2.2.a:

• A description of how the application connects to and/or uses shared resources

• Instructions for how the application should be configured to ensure secure integration with shared resources Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-2.2.a:

Modified p. 35 → 43

~~Describe how the source-code review verified that any connection to, or use of, shared resources is done securely and in accordance with the POI device vendor’s security guidance:~~ <Report Findings Here> 2B-2.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify …

<Report Findings Here> 2B-2.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that any connections to, or use of, shared resources are handled securely and in accordance with the POI device vendor’s security guidance.

Removed p. 36

Describe how the source-code review verified that applications do not bypass or render ineffective any encryption or account-data security methods implemented by the POI device: <Report Findings Here> 2B-2.6 If the application provides configuration/update functionality at-the-terminal (e.g., using an on-screen menu system), the application must not bypass or render ineffective any applicable controls contained within this standard. Note: Some applications may provide administrative or other privileged functions at the terminal, such as the ability to load whitelists or change other application configurations. Any such functions provided in this way must meet all applicable P2PE requirements. 2B-2.6 If the application provides configuration/update functionality at the terminal, perform a functional test of the application loaded on each applicable POI device type and verify that the application does not bypass or render ineffective any applicable controls contained within this standard.

Modified p. 36 → 43

Describe how the source-code review verified that applications do not bypass or render ineffective any application segregation that is enforced by the POI device: ~~<Report Findings Here> 2B-2.4 Applications do not bypass or render ineffective any OS hardening implemented by the POI device.~~

Describe how the source-code review verified that applications do not bypass or render ineffective any application segregation that is enforced by the POI device:

Modified p. 36 → 44

Describe how the source-code review verified that applications do not bypass or render ineffective any ~~OS hardening which is~~ implemented by the POI device: <Report Findings Here> 2B-2.4 Perform a source-code review and verify that applications do not bypass or render ineffective any OS hardening which is implemented by the POI device, in accordance with the device vendor’s security guidance. 2B-2.5 Perform a source-code review and verify that applications do not bypass or render ineffective any encryption or account-data security …

Describe how the source-code review verified that applications do not bypass or render ineffective any encryption or account-data-security methods implemented by the POI device:

Modified p. 36 → 44

Describe how functional test of the application loaded on each applicable POI device type verified that the application does not bypass or render ineffective any applicable controls contained within this standard: <Report Findings Here> 2B-3.1 The application developer’s process must include full documentation, and integration testing of the application and intended platforms, including the following: 2B-3.1 Through observation and review of the application developer’s system development documentation, confirm the application developer’s process includes full documentation and integration testing of the …

Describe how functional test of the application loaded on each applicable POI device type verified that the application does not bypass or render ineffective any applicable controls contained within this standard:

Modified p. 37 → 45

<Report Findings Here> 2B-3.1.2 The application developer must perform final integration testing on the device, which includes identification and correction of any residual vulnerabilities stemming from the integration with the vendor’s platform. 2B-3.1.2 Interview application developers to confirm that final integration testing, which includes identification and correction of any residual vulnerabilities stemming from the integration with the vendor’s platform, was performed.

<Report Findings Here> 2B-3.1.2 The application developer must perform final integration testing on the device, which includes identification and correction of any residual vulnerabilities stemming from the integration with the vendor’s platform.

Modified p. 37 → 45

Application developers interviewed: <Report Findings Here> 2B-4.1 The application must not encrypt clear-text account data. ~~This means the~~ application must not implement any encryption functions that bypass or are intended to be used instead of the approved SRED functions of the POI ~~device. 2B-4.1.a Examine the application’s Implementation Guide required at 2C-3 of this document and verify the description of the application’s function includes the following:~~

Application developers interviewed: <Report Findings Here> 2B-4.1 The application must not directly encrypt clear-text account data. The application must not implement any account data encryption functions that bypass or are intended to be used instead of the approved SRED encryption functions of the POI device’s firmware.

Modified p. 37 → 45

• Confirmation that the application does not perform encryption of clear-text account-data, nor does it replace the POI device’s SRED encryption

• A description of the purpose and encryption method for any encryption provided by the application in addition to SRED ~~encryption Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-4.1.a:~~

• Confirmation that the application does not perform encryption of clear-text account-data, nor does it replace the POI device’s SRED encryption

• A description of the purpose and encryption method for any encryption provided by the application in addition to SRED encryption.

Modified p. 37 → 45

Describe how the source-code review verified that any application functionality facilitating the encryption of account data utilizes the approved cryptographic algorithm(s) and associated key-management functions of the POI device’s SRED firmware and is not implemented within the application itself: <Report Findings Here> 2B-4.1.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. …

Describe how the source-code review verified that any application functionality facilitating the encryption of account data utilizes the approved cryptographic algorithm(s) and associated key-management functions of the POI device’s SRED firmware and is not implemented within the application itself:

Removed p. 38

2C-2.1.1 All application installations and updates are cryptographically authenticated using the approved security mechanisms of the POI device’s firmware.

Modified p. 38 → 46

Documented processes reviewed: <Report Findings Here> ~~2C-1.1.b Interview responsible software vendor personnel to confirm the following:~~

Documented processes reviewed: <Report Findings Here>

Modified p. 38 → 47

<Report Findings Here> 2C-1.2 Software vendors must establish and implement a process to develop and deploy critical security updates to address discovered security vulnerabilities in a timely manner. Note: A “critical security update” is one that addresses an imminent risk to account data. 2C-1.2.a Obtain and examine processes to develop and deploy application security upgrades. Verify that processes include the timely development and deployment of critical security updates to customers.

<Report Findings Here> 2C-1.2 Software vendors must establish and implement a process to develop and deploy critical security updates to address discovered security vulnerabilities in a timely manner.

Modified p. 38 → 47

~~2C-2.1 To confirm that all~~ application installations and updates are cryptographically ~~authenticated, verify~~ the ~~following:~~

2C-2.1.1 All application installations and updates on a POI device are cryptographically authenticated using the approved security mechanisms of the POI device’s firmware.

Removed p. 39

<Report Findings Here> 2C-3.1.1 Addresses all requirements in P2PE Domain 2 wherever the Implementation Guide is referenced.

Modified p. 39 → 48

Describe how attempting to perform an installation and an update using ~~non- approved~~ security mechanisms verified that the POI device will not allow the installation or update to occur: <Report Findings Here> 2C-2.1.2 The application developer includes guidance for whoever signs the application, including requirements for dual control over the application-signing process. 2C-2.1.2 Examine the application’s Implementation Guide required at 2C-3 of this document and verify that it includes the following:

Describe how attempting to perform an installation and an update using non-approved security mechanisms verified that the POI device will not allow the installation or update to occur:

Modified p. 39 → 48

• Instructions how to ~~implement the~~ dual control for the application-signing process.

• A statement that all applications must be signed via the instructions provided in the Implementation Guide.

• Instructions how to use an SCD with dual control for the application-signing process.

• A statement that all applications must be signed via the instructions provided in the Implementation Guide.

Modified p. 39 → 48

<Report Findings Here> 2C-3.1 The process to develop, maintain, and disseminate an Implementation Guide for the application’s installation, maintenance, upgrades and general use includes the following: ~~2C-3.1 Examine the Implementation Guide and related processes, and verify the guide is disseminated to all relevant application installers and users (including customers, resellers, and integrators).~~

<Report Findings Here> 2C-3.1 The process to develop, maintain, and disseminate an Implementation Guide for the application’s installation, maintenance, upgrades and general use includes the following:

Modified p. 40 → 49

~~• Any changes to the Implementation Guide requirements in this document.~~ 2C-3.1.2.a Verify the Implementation Guide is reviewed at least annually and upon changes to the application or the P2PE Domain 2 requirements.

2C-3.1.2.a Verify the Implementation Guide is reviewed at least annually and upon changes to the application or the P2PE Domain 2 requirements.

Modified p. 40 → 49

<Report Findings Here> 2C-3.1.3 Distribution to all new and existing application installers (e.g., solution providers, integrator/resellers, etc.), and re-distribution to all existing application installers every time the guide is updated. ~~2C-3.1.3 Verify the Implementation Guide is distributed to new application installers, and re-distributed to all application installers every time the guide is updated.~~

<Report Findings Here> 2C-3.1.3 Distribution to all new and existing application installers (e.g., solution providers, integrator/resellers, etc.), and re-distribution to all existing application installers every time the guide is updated.

Modified p. 40 → 49

<Report Findings Here> 2C-3.2 Develop and implement training and communication programs to ensure application installers (e.g., solution providers or integrators/resellers) know how to implement the application according to the Implementation Guide. ~~2C-3.2 Examine the training materials and communication program, and confirm the materials cover all items noted for the Implementation Guide throughout P2PE Domain 2.~~

<Report Findings Here> 2C-3.2 Develop and implement training and communication programs to ensure application installers (e.g., solution providers or integrators/resellers) know how to implement the application according to the Implementation Guide.

Modified p. 40 → 50

<Report Findings Here> 2C-3.2.1 Review the training materials for application installers on an annual basis and whenever new application versions are released. Update as needed to ensure materials are current with the Implementation Guide. 2C-3.2.1 Examine the training materials for resellers and integrators and verify the materials are reviewed on an annual basis and when new application versions are released, and updated as needed.

2C-3.2.1 Examine the training materials for resellers and integrators and verify the materials are reviewed on an annual basis and when new application versions are released, and updated as needed.

Document Comparison

From Revision History

Content Changes