Document Comparison

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.

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

Use of this Reporting Template is mandatory for completing a P2PE Report on Validation for a P2PE Application validated as part of a Merchant-Managed Solution that is not being listed.

Tables have been included in this template to facilitate the reporting process for certain lists and other information as appropriate. The tables in this template may be

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

• added if the assessor feels there is relevant information to be included that is not addressed in the current format. However, the assessor must not remove any details from the tables provided in this document. Personalization, such as the addition of company logos, is acceptable but limited to the title page.

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 …

Assessor responses will generally fall into categories such as the following:

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

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

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

• Brief description/short answer

• …

1. Contact Information and Report Date 1.1 Contact Information P2PE Application Vendor contact information Company name: Company URL:

Company contact name: Contact e-mail address:

Contact phone number: Company address:

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:

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

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:

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

Description of application function/purpose:

Description of how the application is designed (for example, as a standalone application, in modules, or as part of a suite of applications):

Description of how application stores, processes and/or transmits account data:

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

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

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

PTS Approval #: Make/ Manufacturer: Model Name/ Number: Hardware #: Firmware #(s):*

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

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

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

• Provide detailed descriptions and/or diagrams to illustrate how the application functions in a typical implementation.

• 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

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

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

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:

• Authentication mechanisms:

• Authentication database:

• Security of authentication data storage:

P2PE Assessor’s Lab Application Vendor’s Lab Address of the lab environment used for this assessment:

Describe the lab environment used for this assessment:

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.

P2PE Application Implementation Guide(s) (IG):

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 (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) Interviewee’s Name Company Job Title

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.

2A-2 The application does not store PAN and/or SAD for any longer than business processes require.

2A-3 The application does not transmit clear-text PAN and/or SAD outside of the POI device, and only uses communication methods included in the scope of the PCI-approved POI device evaluation.

2B Develop and maintain secure applications.

2B-1 The application is developed and tested according to industry-standard software development life cycle practices that incorporate information security.

2B-2 The application is implemented securely, including the secure use of any resources shared between different applications.

2B-3 The application vendor uses secure protocols, provides guidance on their use, and performs integration testing on the final application.

2B-4 Applications do not …

• Model name and number

• Hardware version number

• Hardware version number

• Firmware version number

• Firmware version number

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

• SRED listed as a function provided.

For each POI device type used by the application, describe how the POI device configurations observed verified that all of the POI device characteristics at 2A- 1.1 match the PTS listing:

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

For each …

• How it uses PAN and/or SAD for its application processing.

• How it ensures the application does not store PAN after the payment transaction is complete.

• How it ensures the application does not store SAD after authorization is complete.

<Report Findings Here> 2A-2.2.b Perform a source-code review to verify that the application is designed such that:

• PAN is not stored after the payment transaction is completed.

• PAN is not stored after the payment transaction is completed.

• SAD is not stored after authorization is completed.

• SAD is not stored after authorization is completed.

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 functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to …

<Report Findings Here> 2A-2.4 The application must 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 stored during application processing.

<Report Findings Here> 2A-2.4.b Perform a source-code review and verify that the process provided by the application vendor renders all stored PAN and/or SAD irrecoverable once application processing is completed, in accordance with industry-accepted standards for secure deletion of data.

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 …

<Report Findings Here> 2A-3.1.2 If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, this is ONLY allowable if the application includes the following:

• 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 full PAN where there is a legal or regulatory obligation to do so. 2A-3.1.2.a If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, examine the application’s design documentation and verify …

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

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

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

• A list of the external communication methods included in the POI device vendor’s security guidance.

• A list of which approved external communication methods are used by the application.

• A description of where external communications are used by the application.

POI device vendor’s security guidance documentation reviewed:

<Report Findings Here> Application design documentation reviewed:

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

Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes guidance that the use of any other method for external communication is not allowed:

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

• How to configure the whitelisting 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 perform cryptographic 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 authorized personnel prior to implementation.

• That all new installations or updates to whitelist functionality must include the following:

• Description and justification for the functionality.

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

• Processes are based on industry standards and/or best practices.

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

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

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

• Incorporated into the application developer’s written software development processes.

• Implemented per the POI device vendor's security guidance.

<Report Findings Here> 2B-1.1.c Examine the application’s Implementation Guide required at 2C-3 of this document and verify it provides information from the POI device vendor’s security guidance applicable to the solution provider (e.g., application configuration settings which are necessary for the application to function with the device).

Identify the P2PE Assessor who confirms that the application’s Implementation Guide provides information from the POI device vendor’s security guidance applicable to the solution provider:

<Report Findings Here> 2B-1.1.d Verify each of the items at 2B-1.1.1 through 2B-1.1.3 by performing the following:

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

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

<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 vendor performs reviews for all application code changes and non-code configuration mechanisms as follows:

• Reviews are performed by an individual, other than the code …

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.

2B-1.2.3 Examine change control documentation for a sample of code changes to verify that appropriate corrections are implemented prior to release.

<Report Findings Here> 2B-1.2.4 Review and approval of review results by management prior to release.

2B-1.2.4 Examine change control documentation for a sample of code changes to verify that review results are reviewed and approved by management prior to release.

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

• Documentation of customer impact

• Documented approval of change by appropriate authorized parties

• Functionality testing to verify that the change does not adversely impact the security of the device

• Back-out or application de-installation procedures Documented developer change-control procedures for software modifications reviewed:

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

• Documentation detailing the impact of all changes included in the relevant application release

• …

<Report Findings Here> 2B-1.3.2 Documented approval of change by appropriate authorized parties 2B-1.3.2 Verify that documented approval by appropriate authorized parties is present for each change.

<Report Findings Here> 2B-1.3.3 Functionality testing to verify that the change does not adversely impact the security of the device.

2B-1.3.3.a For each sampled change, verify that functionality testing was performed to verify that the change does not adversely impact the security of the device.

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

<Report Findings Here> 2B-1.3.4 Back-out, rollback, or application de-installation procedures.

2B-1.3.4 Verify that back-out, rollback, or application de-installation procedures are prepared for each change.

<Report Findings Here> 2B-1.4 Applications must be developed according to industry best practices for secure coding techniques, including (but not limited to):

• Developing with least privilege.

• Developing with fail-safe exception handling.

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

• Developing with fail-safe defaults.

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

Software developers interviewed: <Report Findings Here> 2B-1.4.1 Application development processes must include prevention of common coding vulnerabilities.

2B-1.4.1.a Obtain and review software development processes for applications. Verify the process includes prevention of common coding vulnerabilities relevant to the programming languages and platforms in use.

<Report Findings Here> 2B-1.4.1.b Verify that applications are not vulnerable to common coding vulnerabilities by performing manual or automated penetration testing that specifically attempts to exploit vulnerabilities relevant to the application (an example of such a vulnerability would include buffer overflows).

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:

• Coverage of all …

• 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, or low priority) to each.

• Implementation of appropriate corrections and countermeasures during the development process.

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

Responsible personnel interviewed: <Report Findings Here> 2B-1.5 Application vendor must provide training in secure development practices to application developers, as applicable for the developer’s job function and technology used, e.g.:

• Secure application design.

• Secure coding techniques to avoid common coding vulnerabilities (e.g., vendor guidelines, OWASP Top …

Sample of developers interviewed: <Report Findings Here> 2B-1.6 Secure source-control practices must be implemented to verify integrity of source-code during the development process.

2B-1.6.a Examine written software-development procedures and interview responsible personnel to verify the vendor maintains secure source-code control practices to verify integrity of source-code during the development process.

Documented software development procedures reviewed:

Documented software development procedures reviewed:

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

Describe how mechanisms and procedures for securing source-code verified that integrity of source-code is maintained during the development process: <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: 2B-1.7.a Examine documented software-development …

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:

• Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application).

• Specific identification and definition of changes that:

• Have no impact on functionality of the application or its dependencies

• Have no impact on functionality of the application or its dependencies

• Have impact on application functionality but no impact on security or P2PE requirements

• Have impact to any security functionality or P2PE requirement.

• How each type of change ties to a specific version number. 2B-1.8.a Examine the software vendor’s documented versioning methodology to verify the version methodology includes:

• Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the …

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

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

• Wildcards are never used for any change that has an impact on the security of the application and/or the POI device.

• 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. 2B-1.9.a Examine the software vendor’s documented versioning methodology to verify that it includes specific identification of how wildcards are used, including:

• Wildcards are never used for any change that has an impact on the security of the application and/or the …

• Wildcards are not used for any change that has an impact on security or any P2PE requirements.

• Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are not used to represent a security impacting change.

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

2B-1.10 Verify the application’s Implementation Guide required at 2C-3 of this document includes a description of the vendor’s published versioning methodology for customers and integrators/resellers, and includes the following:

• Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.)

• Details of how security-impacting changes will be indicated by the version

• Details of how other types of changes will affect the version

• Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security-impacting change Identify the P2PE Assessor …

• Signature by an authorized party to formally approve release of the application or application update.

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

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

• Formal approval and signature by an authorized party.

• Confirmation that that all secure development processes were followed.

Sample of recent releases of application and application updates reviewed:

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

• Link Layer protocols

• 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 approval status of that device for that implementation. 2B-2.1.1. Perform a source-code review and verify that the application:

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

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

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

2B-2.3 Perform a source-code review and verify that applications do not bypass or render ineffective any application segregation that is enforced by the POI device, in accordance with the POI device vendor’s security guidance.

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.

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.

Describe how the source-code review verified that applications do not bypass or render ineffective any OS hardening which is implemented by the POI …

<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 application and intended platforms, including the following:

Application developer’s system development documentation reviewed:

<Report Findings Here> 2B-3.1.1 The application developer must provide key-management security guidance describing how cryptographic keys and certificates have to be used. Examples of guidance include which cryptographic certificates to load, how to load account-data keys (through the firmware of the device), when to roll keys, etc. 2B-3.1.1 Review the application’s Implementation Guide required at 2C-3 of this document, and confirm it includes key-management security guidance for solution providers, describing how cryptographic keys and certificates have to be used and managed.

Identify the P2PE Assessor who confirms that the application’s Implementation …

<Report Findings Here> 2C-1.1 Software developers must establish and implement a process to identify and test their applications for security vulnerabilities and implementation errors prior to every release (including updates or patches) using manual or automated vulnerability assessment processes. 2C-1.1.a Obtain and examine processes to identify new vulnerabilities and test applications for vulnerabilities that may affect the application. Verify the processes include the following:

• Using outside sources for security vulnerability information.

• Periodic testing of applications for new vulnerabilities.

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

• New vulnerabilities are identified using outside sources of security vulnerability information.

• All applications are tested for vulnerabilities.

Responsible software vendor personnel interviewed:

Responsible software vendor personnel interviewed:

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

• A description of how the application is cryptographically authenticated using the approved security mechanisms of the POI device’s firmware for any application installations and updates.

• Instructions for how to use the approved security mechanisms to perform application installations and updates.

• A statement that application installations and updates cannot occur except by using the approved security mechanisms of the POI device’s firmware.

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

<Report Findings Here> 2C-2.1.1.b Perform a source-code review to verify that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware.

Describe how the source-code review verified that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware: <Report Findings Here> 2C-2.1.1.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Use forensic tools …

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

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

Documented processes for dissemination reviewed:

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

2C-3.1.1 Verify the Implementation Guide covers all related requirements in P2PE Domain 2.

<Report Findings Here> 2C-3.1.2 Review of the Implementation Guide at least annually and upon changes to the application or the P2PE Domain 2 requirements, and update as needed to keep the documentation current with:

• Any changes to the application (e.g., device changes/upgrades and major and minor software changes).

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

<Report Findings Here> 2C-3.1.2.b Verify the Implementation Guide is updated as needed to keep the documentation current with:

• Any changes to the application (e.g., device changes/upgrades and major and minor software changes).

• Any changes to the Implementation Guide requirements …