PCI Watch

Tracking changes across the Payment Card Industry

Document Comparison

PCI-P2PE-APP_ROV-Template_v3_1.pdf → PCI-P2PE-APP-ROV-Template-v3.2.pdf
82% similar
65 → 68 Pages
18938 → 19351 Words
271 Content Changes

Content Changes

271 content changes. 82 administrative changes (dates, page numbers) hidden.

Added p. 2
July 2025 3.2 1.0 This template includes the following updates:

• Updates from the PCI P2PE Standard v3.2

• Updates based on stakeholder feedback

• Errata updates to section 4
Added p. 6
Note: A separate Merchant-Managed Solution P-ROV is used as part of validating MMS.

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

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

Validation of a P2PE Solution that has not satisfied the key management services requirements (Domain 5) either using Listed P2PE Component Providers and/or through the assessment of their Encryption Management Services and/or Decryption Management Services must complete the KMS P-
Added p. 8
• Brief description/short answer

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

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

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

QA Primary reviewer phone number:

QA Primary reviewer e-mail address:

• Disclose all services offered to the assessed entity by the P2PE Application Assessor / P2PE Application Assessor company, including but not limited to whether the assessed entity uses any security-related devices or security-related applications that have been developed or manufactured by the P2PE Application Assessor company, or to which the P2PE Application Assessor company owns the rights or that the P2PE Application Assessor company has configured or manages:
Added p. 17
3. Details and Scope of P2PE Assessment 3.1 Scoping Details The entity is expected to retain documentation to show how P2PE scope was determined. The documentation is retained for assessor review and for reference during the entity’s next P2PE scope confirmation activity. For each P2PE assessment, the assessor validates that the scope of the assessment is accurately defined and documented.
Added p. 21
P2PE Application Assessor Company and/or Application Vendor Address of the lab/test environment(s) used for this assessment:

P2PE Application Assessor Company:

Sample Ref #: (optional) PTS and/or FIPS Approval # Hardware #(s) (comma delimited) Firmware #(s) (comma delimited) Sample Size (x of y) Serial Numbers of Tested Devices / Other Identifiers Sampling Rationale
Added p. 26
Reference # (optional use) Description of Test Transactions performed
Added p. 27
• Reference #: A reference number used to uniquely identify each sample set, for example “Set-1”, “Set-2”, etc.

• Sample Description: A brief description of the items sampled.

• Total Sampled: The number of items included in the sample set.

• Total Population: The total number of possible items available for testing.

• Sample Justification: The assessor’s justification for why the Total Sampled is a fair and accurate representation of the Total Population.

Reference # Sample Description Total Sampled Total Population Sample Justification
Added p. 29
2C-2 Applications are installed and updates are implemented on the PTS POI devices only via trusted and cryptographically authenticated processes using an approved security mechanism evaluated for the PTS POI d i 2C-3 Maintain instructional documentation and training programs for the application’s installation, maintenance/upgrades, and use.

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

• Application (Applic) version number(s)

Note: Refer to the PCI P2PE Technical FAQs - Domain 2, Q4 regarding PTS POI device expiry. Individual PTS POI hardware and firmware must also be assessed and approved to the PTS POI SRED requirements.

2A-1.1 For each PTS POI device type the application is intended to support, examine the PCI SSC list of Approved PTS Devices to verify that all of the following PTS POI device type characteristics match the associated PTS approval listing:

• Application version number(s) (This refers to PTS POI …
Added p. 32
<Report Findings Here> 2A-2.1 The application vendor must maintain current documentation for all data flows of account data (encrypted and cleartext) and provide a business justification for all uses of account data input into, processed by, and output from the application. Note: It is prohibited for the application to output cleartext account data anywhere other than to the PTS POI firmware per 2A-3.1.

2A-2.1.a Examine the application’s design documentation to verify it documents all data flows (encrypted and cleartext) of account data and justifies all uses of account data input into, processed by, and output from the application.

Application design documentation examined:

Note: If there are technical constraints of the architecture/language, they must be clearly documented, including:

• The extent the account data can be considered to be securely deleted or otherwise inaccessible from working memory

Note: If there are technical constraints of the architecture/language, they must be clearly documented, including:

• The extent the account …
Added p. 35
• Output cleartext account data outside the PTS POI device

• Make cleartext account data externally available (e.g., to a printer, screen, etc.), except as allowed for requirement 2A-3.1.2

• Output cleartext account data outside of the PTS POI device

• Make cleartext account data externally available (e.g., to a printer, screen, etc.), except as allowed for requirement 2A-3.1.2.

<Report Findings Here> 2A-3.1.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. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that truncation of PANs adheres to the allowable number of digits.

• The P2PE application securely deletes the cleartext PAN after completion of printing using industry-accepted methods for secure deletion of data 2A-3.1.2.a Examine the application’s design documentation and verify:

• The P2PE application securely …
Added p. 47
2B-1.3.3.a For each sampled change, examine evidence to verify that functionality testing was performed to verify that the change does not adversely impact the security of the device.
Added p. 54
<Report Findings Here> Change control documentation examined:

<Report Findings Here> 2B-1.9.c Interview personnel and observe processes for each type of change to verify that:
Added p. 62
2B-3.1 Examine/observe the application developer’s system development documentation, to verify the application developer’s process includes full documentation and integration testing of the application and intended platforms, including the following:

• Directly encrypt cleartext account data via its own cryptographic algorithms and cryptographic keys

<Report Findings Here> 2B-4.1.b Examine the application source code to verify that the application functionality facilitating the encryption of account data utilizes the approved cryptographic algorithm(s) and associated key-management functions of the PTS POI device’s SRED firmware and is not implemented within the application itself.
Added p. 67
• Instructions how to use an SCD or HMD with dual control for the application-signing process

• A statement that all applications must be signed via the instructions provided in the Implementation Guide Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2C-2.1.2:
Modified p. 1
Payment Card Industry (PCI) Point-to-Point Encryption P2PE Application Template for Report on Validation for use with P2PE v3.1 for P2PE Application Assessments
Payment Card Industry (PCI) Point-to-Point Encryption (P2PE)® P2PE Application Template for Report on Validation For use with the PCI P2PE Standard v3.2 for P2PE Application Assessments
Modified p. 5
Use of this Reporting Template is mandatory for each P2PE v3.1 P2PE Application assessment.
Use of this Reporting Template is mandatory for each P2PE v3.2 P2PE Application assessment.
Modified p. 5
A P2PE compliance assessment involves thorough testing and assessment activities, from which the assessor will generate detailed work papers. These work papers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file lists, interview notes, documentation excerpts, references, screenshots, and other evidence collected during the course of the assessment. The P-ROV is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor performed the validation activities and how …
A P2PE assessment involves thorough testing and assessment activities, from which the assessor will generate detailed work papers. These work papers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file lists, interview notes, documentation excerpts, references, screenshots, and other evidence collected during the course of the assessment. The P-ROV is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor performed the validation activities and how the …
Removed p. 6
Solution assessments that have not satisfied the entirety of their Decryption Management Services (Domain 4 with Domain 5) with applicable Validated P2PE Component Providers must complete the DMS P-ROV in addition to the Solution P-ROV.

Solution assessments that have not satisfied the entirety of key management services requirements (Domain 5) either through the use of Validated P2PE Component Providers and/or through the assessment of their Encryption Management Services and/or Decryption Management Services must complete the KMS P-ROV. E.g., if the P2PE Solution offers remote key-distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account-data encryption, or the operation of an applicable CA/RA. Or if any other relevant key management service that has not already been assessed as part of the inclusion of a Validated P2PE Component Provider and/or as part of the Domain 1 and Domain 4 assessment scope of the Solution assessment, …
Modified p. 6
Encryption Management Services (EMS) Solution (SP) Encryption Management CP (EMCP) POI Deployment CP (PDCP) POI Management CP (PMCP) Encryption Management Services relates to the distribution, management, and use of POI devices in a P2PE Solution.
Encryption Management Services (EMS) Solution (SP) Encryption Management CP (EMCP) POI Deployment CP (PDCP) POI Management CP (PMCP) “Encryption Management Services” relates to the distribution, management, and use of PCI-approved PTS POI devices in a P2PE Solution. Validation of P2PE Solutions that do not outsource the entirety of their Encryption Management Services to Listed P2PE Component Providers, either to an EMCP or to BOTH a PDCP AND a PMCP, must include this P-ROV in addition to a Solution P-ROV.
Modified p. 6
Solution assessments that have not satisfied the entirety of their Encryption Management Services (Domain 1 with Domain 5) with applicable Validated P2PE Component Providers must complete the EMS P-ROV in addition to the Solution P-ROV.
Validation of P2PE Solutions that do not outsource the entirety of their Decryption Management Services to a Listed DMCP must include this P-ROV in addition to a Solution P-ROV.
Modified p. 6
Component Provider assessments for an EMCP, PDCP, or a PMCP must complete the EMS P-ROV.
Validation of P2PE Component services provided by an EMCP, PDCP, or a PMCP must use this P- ROV.
Modified p. 6
P2PE Application P2PE Application Any assessment that utilizes software on the PTS-approved POI devices intended for use in a P2PE Solution that has the potential to access clear-text account data must complete a P2PE Application P- ROV (one for each application).
P2PE Application P2PE Application Validation of a P2PE Application (software on the PCI-approved POI device intended for use in a P2PE Solution that has the potential to access cleartext cardholder data) must use this P-ROV.
Modified p. 6
Decryption Management Services (DMS) Solution (SP) Decryption Management CP (DMCP) Decryption Management Services relates to the management of a decryption environment, including applicable account-data decryption devices used to support a P2PE Solution.
Decryption Management Services (DMS) P2PE Solution (SP) Decryption Management CP (DMCP) “Decryption Management Services” relates to the management of a decryption environment, including applicable devices (for example, HSMs) used to support a P2PE Solution.
Modified p. 6
Component Provider assessments for a DMCP must complete the DMS P-ROV.
Validation of P2PE Component services provided by a DMCP must use this P-ROV.
Modified p. 6
Key Management Services (KMS) Solution (SP) Key-injection Facility (KIF) Key Management CP (KMCP) Key Loading CP (KLCP) CA/RA Key Management Services relates to the generation, conveyance, management, and loading of cryptographic keys including the management of associated devices.
Key Management Services (KMS) P2PE Solution (SP) Key Injection Facility (KIF) Key Management CP (KMCP) Key Loading CP (KLCP) “Key Management Services” relates to the generation, conveyance, management, and loading of cryptographic keys including the management of associated devices (POI devices, HSMs, etc.).
Modified p. 6 → 7
Component Provider assessments for a KIF, KMCP, KLCP, or a CA/RA must complete the KMS P- ROV.
Validation of P2PE Component services provided by a KIF, KMCP, KLCP, and a CA/RA must complete this P-ROV.
Modified p. 7
Section 1: Contact Information and Report Date
• Section 1: Contact Information and Report Date
Modified p. 7
Section 2: Summary Overview
• Section 2: Summary Overview
Modified p. 7
Section 3: Details and Scope of P2PE Assessment
• Section 3: Details and Scope of P2PE Assessment
Modified p. 7
Section 4: Findings and Observations This Reporting Template includes tables with Reporting Instructions. Details provided should focus on concise quality of detail, rather than lengthy, repeated verbiage.
• Section 4: Findings and Observations This Reporting Template includes tables with Reporting Instructions. Details provided should focus on concise quality of detail, rather than lengthy, repeated verbiage.
Modified p. 7
P-ROV Summary of Findings This version of the P2PE Reporting Template reflects an on-going effort to simplify assessor summary reporting. All summary findings for “In Place,” “Not in Place,” and “Not Applicable” are found at the beginning of section 4 “Findings and Observations” and are only addressed at that high-level. The summary of the overall compliance status is at section 2.8 “Summary of P2PE Assessment Compliance Status.” The following table is a representation when considering which selection to make. Assessors …
P-ROV Summary of Findings All summary findings for “In Place,” “Not in Place,” and “Not Applicable” are found at the beginning of section 4 “Findings and Observations” and are only addressed at that high level. The summary of the overall compliance validation status is at section 2.8 “Summary of P2PE Assessment Compliance Validation Status.” The following table provides guidance for Assessors when considering which selection to make. Assessors must select only one response at the sub- requirement level, and the …
Modified p. 7 → 8
Note: Checkboxes have been added to the “Summary of Assessment Findings” so that the assessor may double click to check the applicable summary result. Hover over the box you’d like to mark and click once to mark with an ‘x.’ To remove a mark, hover over the box and click again. Mac users may instead need to use the space bar to add the mark.
Note: Checkboxes have been added to the “Summary of Assessment Findings” so that the Assessor may double-click to check the applicable summary result. Hover over the box to select and single-click to mark with an ‘x.’ To remove a mark, hover over the box and click again. Mac users may instead need to use the space bar to select a box.
Modified p. 8
“Identify the P2PE Assessor who confirms…” Indicates only an affirmative response where further reporting is deemed unnecessary by PCI SSC. The P2PE Assessor’s name or a Not Applicable response are the two appropriate responses here. A Not Applicable response will require brief reporting to explain how this was confirmed via testing.
• “Identify the P2PE Assessor who confirms…” Indicates only an affirmative response where further reporting is deemed unnecessary by PCI SSC. The P2PE Assessor’s name or a Not Applicable response are the two appropriate responses here. A Not Applicable response will require brief reporting to explain how this was confirmed via testing.
Modified p. 8
Document name or interviewee reference At section 3.6, “Documentation Reviewed,” and section 3.7, “Individuals Interviewed,” there is a space for a reference number; it is the P2PE Assessor’s choice to use the document name/interviewee job title or the reference number in their responses. A listing is sufficient here, no further detail required.
• Document name or interviewee reference At section 3.6, “Documentation Reviewed,” and section 3.7, “Individuals Interviewed,” there is a space for a reference number; it is the P2PE Assessor’s choice to use the document name/interviewee job title or the reference number in their responses. A listing is sufficient here, no further detail required.
Modified p. 8
Sample reviewed Brief list is expected or sample identifier. Where applicable, it is the P2PE Assessor’s choice to list out each sample within the reporting or to utilize sample identifiers from the sampling summary table.
• Sample reviewed Brief list is expected or sample identifier. Where applicable, it is the P2PE Assessor’s choice to list out each sample within the reporting or to utilize sample identifiers from the sampling summary table.
Modified p. 8
Brief description/short answer

• “Describe how…” These responses must be a narrative response that provides explanation as to the observation•both a summary of what was witnessed and how that verified the criteria of the testing procedure.
• “Describe how…” These responses must be a narrative response that provides explanation as to the observation•both a summary of what was witnessed and how that verified the criteria of the testing procedure.
Modified p. 9
Complete all applicable P-ROVs based on the assessment type.
• Complete all applicable P-ROVs based on the assessment type
Modified p. 9
Complete all sections in the order specified, with concise detail.
• Complete all sections in the order specified, with concise detail
Modified p. 9
Read and understand the intent of each Requirement and Testing Procedure.
• Read and understand the intent of each Requirement and Testing Procedure
Modified p. 9
Provide a response for every Testing Procedure, even if N/A.
• Provide a response for every Testing Procedure, even if N/A
Modified p. 9
Provide sufficient detail and information to demonstrate a finding of “in place” or “not applicable.” Describe how a Requirement was verified as the Reporting Instruction directs, not just that it was verified.
• Describe how a Requirement was verified as the Reporting Instruction directs, not just that it was verified
Modified p. 9
Ensure all parts of the Testing Procedure are addressed.
• Ensure all parts of the Testing Procedure are addressed
Modified p. 9
Ensure the response covers all applicable application and/or system components.
• Ensure the response covers all applicable application and/or system components
Modified p. 9
Perform an internal quality assurance review of the P-ROV for clarity, accuracy, and quality.
• Perform an internal quality assurance review of the P-ROV for clarity, accuracy, and quality
Modified p. 9
Perform an internal quality assurance review of all submitted P-ROVs and the details within the PCI SSC Portal.
• Perform an internal quality assurance review of all submitted P-ROVs and the details within the PCI SSC Portal
Modified p. 9
Provide useful, meaningful diagrams, as directed.
• Provide useful, meaningful diagrams, as directed
Modified p. 9
Don’t report items in the “In Place” column unless they have been verified as being “in place.” Don’t include forward-looking statements or project plans in responses.
• Don’t report items in the “In Place” column unless they have been verified as being “in place.”
Modified p. 9
Don’t simply repeat or echo the Testing Procedure in the response.
• Don’t simply repeat or echo the Testing Procedure in the response
Modified p. 9
Don’t copy responses from one Testing Procedure to another.
• Don’t copy responses from one Testing Procedure to another
Modified p. 9
Don’t copy responses from previous assessments.
• Don’t copy responses from previous assessments
Modified p. 9
Don’t include information irrelevant to the assessment.
• Don’t include information irrelevant to the assessment
Modified p. 9
Don’t mark “N/A” without providing an explanation and justification for why it is “N/A”.
• Don’t mark “N/A” without providing an explanation and justification for why it is “N/A”
Removed p. 10
Company name: Assessor company credentials: QSA (P2PE) PA-QSA (P2PE) Company Servicing Markets for P2PE: (see https://www.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_assessors) Assessor name: Assessor credentials: QSA (P2PE) PA-QSA (P2PE) Assessor phone number: Assessor e-mail address:

(Leave blank if not applicable) QA reviewer phone number: QA reviewer e-mail address:
Modified p. 10
Note: P2PE Application Assessments can only be performed by PA-QSA (P2PE) Companies and by PA-QSA(P2PE) assessors of those companies. Refer to the latest P2PE Program Guide for details.
Note: P2PE Application Assessments can only be performed by P2PE Application Assessor Companies and by P2PE Application Assessors of those companies. Refer to the latest P2PE Program Guide for details.
Modified p. 10
Confirm that internal QA was fully performed on the entire P2PE submission, per requirements in the relevant program documentation.
Internal P2PE Assessor Company QA Review Affirm that internal QA was fully performed on the entire P2PE submission.
Modified p. 10
No (If No, this is not in accordance with PCI Program requirements) QA reviewer name: QA reviewer credentials:
Yes (Internal QA on this submission has been performed in accordance with PCI P2PE Program Requirements) QA Primary reviewer name: QA Primary reviewer credentials:
Modified p. 10
Assessor name: Assessor credentials: QSA (P2PE) PA-QSA (P2PE) Assessor phone number: Assessor e-mail address:
Assessor name: Assessor credentials: P2PE Assessor P2PE Application Assessor
Removed p. 11
Disclose all services offered to the assessed entity by the PA-QSA(P2PE) / PA-QSA(P2PE) company, including but not limited to whether the assessed entity uses any security-related devices or security-related applications that have been developed or manufactured by the QSA, or to which the QSA owns the rights or that the QSA has configured or manages:
Modified p. 11
(From DD-MMM-YYYY To DD-MMM-YYYY) 1.3 Additional Services Provided by PA-QSA(P2PE) / PA-QSA(P2PE) Company The current version of the “Qualification Requirements for Point-to-Point Encryption (P2PE)TM Qualified Security Assessors

• QSA (P2PE) and PA-QSA (P2PE)” (P2PE QSA Qualification Requirements), section “Independence”, specifies requirements for P2PE QSAs around disclosure of such services and/or offerings that could reasonably be viewed to affect independence of assessment. Complete the sections below after review of this portion of the P2PE QSA Qualification Requirements to ensure responses are consistent …
(From DD-MMM-YYYY To DD-MMM-YYYY) 1.3 Additional Services Provided by P2PE Application Assessor / P2PE Application Assessor Company The current version of the “Qualification Requirements for Point-to-Point Encryption (P2PE)TM

• P2PE Assessor and P2PE Application Assessors” (P2PE Qualification Requirements), section “Independence”, specifies requirements for P2PE Assessors around disclosure of such services and/or offerings that could reasonably be viewed to affect independence of assessment. Complete the sections below after review of this portion of the P2PE Qualification Requirements to ensure responses are consistent …
Modified p. 11
Describe efforts made to ensure no conflict of interest resulted from the above mentioned services provided by the PA-QSA(P2PE) / PA- QSA(P2PE) company:
• Describe efforts made to ensure no conflict of interest resulted from the above mentioned services provided by the P2PE Application Assessor / P2PE Application Assessor company:
Modified p. 12
Component (read the Note ) Note: It is not possible to submit a P2PE Application assessment with a P2PE Component Assessment. Complete the P2PE Application assessment as a ‘Separately-listed P2PE Application’.
Component (read the Note →) Note: It is not possible to submit a P2PE Application assessment with a P2PE Component Assessment. Complete the P2PE Application assessment as a ‘Separately-listed P2PE Application’.
Modified p. 12
Note: If the application is intended to be separately listed as a Validated P2PE Application, then complete the P2PE Application assessment as a ‘Separately-listed P2PE Application’. If the application is only associated with the P2PE Solution, complete a P2PE Application P-ROV and submit it with all the required P-ROVs as dictated by the scope of the Solution assessment. The application will not be separately listed and is only validated for use in the Solution.
Note: If the application is intended to be separately listed as a Validated P2PE Application, then complete the P2PE Application assessment as a ‘Separately-listed P2PE Application’. If the application is only associated with the P2PE Solution, complete a P2PE Application P-ROV and submit it with all the required P-ROVs as dictated by the scope of the Solution assessment. The application will not be separately listed and is only validated for use in the Solution. This is regarded as a ‘Solution-specific …
Modified p. 15
• List ALL associated hardware (HW) and firmware (FW) versions supported by the Encryption Management Services or Solution and tested as part of the P2PE assessment.
• List ALL associated hardware (HW) and firmware (FW) versions supported by the Application or Solution and tested as part of the P2PE assessment. HW and FW versions MUST be consistent between P-ROV(s), P-AOV and the Portal.
Modified p. 15
Note 1: Be advised there can be POI device approval listings that appear similar/identical on the PCI SSC list of Approved PTS devices, however, they are associated with different major versions of the PTS POI Standard. Be sure the correct listing is being referenced and utilized in the assessment.
Note 1: Be advised there can be POI device approval listings that appear similar/identical on the PCI SSC list of Approved PTS POI devices, however, they are associated with different major versions of the PTS POI Standard. Be sure the correct listing is being referenced and utilized in the assessment.
Modified p. 15
Note 2: Clicking the PTS Approval # on the list of Approved POI Devices will display additional information. Be advised that the designators shown under “Functions Provided” do NOT necessarily apply to every HW and FW version for that PTS approval listing. Ensure that the requisite P2PE requirements are met and satisfied per POI Device Type (refer to the P2PE Glossary) included in the assessment. For each applicable PTS Approval #:
Note 2: Clicking the PTS Approval # on the list of Approved PTS POI Devices will display additional information. Be advised that the designators shown under “Functions Provided” do NOT necessarily apply to every HW and FW version for that PTS approval listing. Ensure that the requisite P2PE requirements are met and satisfied per POI Device Type (refer to the P2PE Glossary) included in the assessment. For each applicable PTS Approval #:
Modified p. 15
• Do NOT infer the account data capture or communication interface designators apply to every HW and/or FW listed. https://www.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices Add additional rows as necessary.
• Do NOT infer the account data capture or communication interface designators apply to every HW and/or FW listed. Note 3: The use of wildcards MUST be consistent with the POI device approval listing. https://www.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices Add additional rows as necessary.
Modified p. 15
PTS Approval # (One unique # per row) Make / Mfr.
PTS Approval # (One unique # per row) PTS Version # Make / Mfr.
Modified p. 17
3. Details and Scope of P2PE Assessment 3.1 Scoping Details Describe how the accuracy of the scope for the P2PE Application assessment was validated, including:
Describe how the accuracy of the scope for the P2PE Application assessment was validated, including:
Modified p. 19
Provide high-level data-flow diagram(s) that shows details of all flows of account data, including:
• Provide high-level data-flow diagram(s) that shows details of all flows of account data, including:
Modified p. 19
− 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). − All flows and locations of truncated account data (including data input, output, and within the POI device).
− All flows and locations of encrypted account data (including data input, output, and within the POI device) − All flows and locations of cleartext account data (including data input, output, and within the POI device) − All flows and locations of truncated account data (including data input, output, and within the POI device)
Modified p. 19
Identify the following for each data flow:
• Identify the following for each data flow:
Removed p. 20
Description and role of each dependency necessary for the application’s function:
Modified p. 22
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? (Enter PTS Approval #s - comma delimited) (Must align with Table 2.5) All other documentation reviewed for this P2PE Application assessment:
Reference # (optional use) Document Name (Title of the IG) Version Number of the IG Document Date (latest version date, DD-MMM-YYYY) Which POI Device Type(s) is Addressed? (Enter PTS Approval #s - comma delimited) (Must align with Table 2.5) All other documentation reviewed for this P2PE Application assessment:
Modified p. 22
Reference # (optional use) Document Name (including version, if applicable) Document Date (latest version date) Document Purpose (brief summary)
Reference # (optional use) Document Name (including version, if applicable) Document Date (latest version date, DD-MMM-YYYY) Document Purpose (brief summary)
Modified p. 23
Reference # (optional use) Interviewee’s Name Job Title Company Summary of Topics Covered (brief summary) 3.8 (Table not currently used)
Reference # (optional use) Interviewee’s Name Job Title Company Summary of Topics Covered (brief summary) 3.8 Devices Sampled for P2PE Assessment Complete for all sampled devices in the P2PE assessment, including every SCD type in Table 2.6. Use of the “Sample Reference #” is optional, but if not used here, all of the sample’s serial numbers or other identifiers will need to be included in the reporting findings.
Removed p. 27
2B Develop and maintain secure applications.

2C-2 Applications are installed and updates are implemented only via trusted and cryptographically authenticated processes using an approved security mechanism evaluated for the PCI-approved POI device.
Modified p. 27 → 29
2A-2 The application does not store PAN and/or SAD for any longer than business processes require.
2A-2 The application does not store account data for any longer than business processes require.
Modified p. 27 → 29
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.
2A-3 The application does not transmit cleartext account data outside of the PTS POI device or to any other co- resident software other than to the PTS POI device firmware, and only uses communication methods included in the scope of the PCI-approved PTS POI device evaluation.
Modified p. 27 → 29
2B-1 The application is developed and tested according to industry-standard software development life cycle practices that incorporate information security.
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.
Modified p. 27 → 29
2B-4 Applications do not implement any encryption functions in lieu of SRED encryption. All such functions are performed by the approved SRED firmware of the POI device.
2B-4 Applications do not implement any encryption functions in lieu of SRED encryption. All such functions are performed by the approved SRED firmware of the PTS POI device.
Modified p. 27 → 29
2C Implement secure application-management processes.
2C Implement secure application-management processes 2C-1 New vulnerabilities are discovered and applications are tested for those vulnerabilities on an ongoing basis.
Modified p. 28 → 30
Requirement Document how it was determined that the requirement is Not Applicable to the P2PE Product under assessment
Reference # (optional use) Requirement Document how and why it was determined that the requirement is Not Applicable to the P2PE Product under assessment
Removed p. 29
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.
Modified p. 29 → 31
• Hardware version number
• Hardware (HW) version number(s)
Modified p. 29 → 31
• Hardware version number
• Hardware (HW) version number(s)
Modified p. 29 → 31
• Firmware version number
• Firmware (FW) version number(s)
Modified p. 29 → 31
• Firmware version number
• Firmware (FW) version number(s)
Modified p. 29 → 31
• SRED listed as a function provided.
• SRED listed as a function provided
Modified p. 29 → 31
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:
• SRED listed as a function provided For each PTS POI device type the application is intended to support, describe how the POI device configurations observed verified that all of the PTS POI device type characteristics at 2A-1.1 match the PTS approval listing:
Modified p. 29 → 31
<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.
<Report Findings Here> 2A-1.2 The application must only use the SRED-validated account-data capture mechanisms of the underlying PTS POI device for accepting and processing P2PE-related transactions.
Modified p. 29 → 31
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.
Describe how the documentation examined verified that the application is designed to use only SRED-validated account-data capture mechanisms on the PTS POI device:
Modified p. 29 → 31
For each POI device type used in the application, describe how the application only uses SRED-validated account-data-capture mechanisms:
2A-1.2.a Examine documentation to verify the application is designed to use only SRED-validated account-data capture mechanisms on the PTS POI device.
Removed p. 30
2A-2.1.a Interview software personnel and examine the application’s design documentation to verify it documents all flows and justifies all uses of PAN and/or SAD input into, processed by, and output from the application.

Software personnel interviewed: <Report Findings Here> Application design documentation reviewed:

<Report Findings Here> 2A-2.2 The application must not store PAN and/or SAD (even if encrypted) as follows:

• How it uses PAN and/or SAD for its application processing.
Modified p. 30 → 32
<Report Findings Here> 2A-2.1.b Perform a source-code review and verify that PAN and/or SAD are only utilized according to the documentation.
<Report Findings Here> 2A-2.1.b Examine the application source code and verify that account data is only utilized by the application according to the documentation.
Modified p. 30 → 32
Describe how the source-code review verified that PAN and/or SAD are only utilized according to the documentation:
Describe how the source-code review verified that account data is only utilized according to the documentation:
Modified p. 30 → 33
• Application must not store PAN data after the payment transaction is complete.
• Application must not store PAN data after the payment transaction is complete
Modified p. 30 → 33
• Application must not store SAD after authorization is complete.
• Application must not store SAD after authorization is complete
Modified p. 30 → 33
• 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.
• 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 Application design documentation examined:
Modified p. 30 → 33
<Report Findings Here> 2A-2.2.b Perform a source-code review to verify that the application is designed such that:
<Report Findings Here> 2A-2.2.b Examine source code to verify that the application is designed such that:
Modified p. 30 → 33
• PAN is not stored after the payment transaction is completed.
• PAN is not stored after the payment transaction is completed
Modified p. 30 → 33
• SAD is not stored after authorization is completed.
• PAN is not stored after the payment transaction is completed
Modified p. 30 → 33
Describe how the source-code review verified that the application is designed such that PAN is not stored after the payment transaction 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:
Modified p. 30 → 33
<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> Describe how the source code review verified that the application is designed such that SAD is not stored after authorization is completed:
Removed p. 31
• PAN is not stored after the payment transaction is completed.

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. 31 → 33
• SAD is not stored after authorization is completed.
• SAD is not stored after authorization is completed Describe test transactions performed (must utilize all functions of the application that handle account data):
Modified p. 31 → 34
<Report Findings Here> 2A-2.3 The application must not retain PAN and/or SAD in working memory any longer than strictly necessary.
<Report Findings Here> 2A-2.3.b Examine the application source code and verify that account data is cleared from all working memory locations after use.
Modified p. 31 → 34
2A-2.3.a Examine the application’s design documentation and verify it contains a detailed description of the function of the application, including how it ensures the application does not retain PAN and/or SAD in working memory any longer than strictly necessary.
• Any additional mechanisms employed to reduce the residual risk incurred by the technical limitation 2A-2.3.a Examine the application’s design documentation and verify it contains a detailed description of the function of how the application is designed to not retain account data in working memory any longer than strictly necessary.
Modified p. 31 → 34
<Report Findings Here> 2A-2.3.b Perform a source-code review and verify that PAN and/or SAD is cleared from all working memory locations after use, including local variables (before exiting the function).
Describe how the source code review verified that account data is cleared from all working memory locations after use:
Modified p. 31 → 34
<Report Findings Here> 2A-2.3.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 the application clears all working memory locations utilized for the temporal retention of PAN and/or SAD during processing.
<Report Findings Here> 2A-2.3.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 the application clears all working memory locations utilized for the temporal retention of account data during processing.
Modified p. 32 → 35
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.
2A-3.1.a Examine the application’s design documentation and verify the application is designed such that it does not:
Modified p. 32 → 35
<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.
<Report Findings Here> 2A-2.4.b Examine the application source code and verify that all stored account data is irrecoverable once application processing is completed, in accordance with industry-accepted methods for secure deletion of data.
Modified p. 32 → 35
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:
Describe how the examination of source code verified that all stored account data is irrecoverable once application processing is completed:
Modified p. 32 → 35
<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 provided by the application renders all PAN and/or SAD data irrecoverable, in accordance with industry-accepted standards for secure deletion of data, once the business process …
<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 application renders all account data irrecoverable, in accordance with industry- accepted methods for secure deletion of data, once the business process of the application is completed.
Modified p. 32 → 35
<Report Findings Here> 2A-3.1 The application must not output clear-text account data outside of the POI device.
<Report Findings Here> 2A-3.1 The application must not:
Modified p. 32 → 35
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 or sharing of cleartext 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.
Modified p. 32 → 36
Describe how the source-code review verified that the application never outputs clear- text account data outside of the POI device:
Describe how the examination of source code verified the application satisfies this requirement:
Modified p. 32 → 37
<Report Findings Here> 2A-3.1.b Perform a source-code review and verify the application never outputs clear-text account data outside of the POI device.
<Report Findings Here> 2A-3.1.2.b Examine the application source code and verify it satisfies the requirement.
Removed p. 33
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.
Modified p. 33 → 36
<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.
<Report Findings Here> 2A-3.1.1 If the application outputs truncated PANs, the truncation must adhere to the allowable number of digits.
Modified p. 33 → 36
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.
Note: Refer to the PCI P2PE Technical FAQs - Domain 2, Q3 regarding the allowable number of digits. 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 Examine the application’s design documentation and verify that any truncation of PANs adheres to the allowable number of digits.
Modified p. 33 → 36
Design documentation examined: <Report Findings Here> 2A-3.1.1.b If the application outputs any truncated PANs, perform a source- code review and verify that any truncation of PANs adheres to the allowable number of digits as specified in PCI DSS and/or related FAQs that specify allowable digits.
Design documentation examined: <Report Findings Here> 2A-3.1.1.b Examine the application source code and verify that truncation of PANs adheres to the allowable number of digits.
Modified p. 33 → 36
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.
Describe how the examination of source code verified that truncation of PANs adheres to the allowable number of digits.
Modified p. 33 → 36
<Report Findings Here> 2A-3.1.1.c If the application outputs any truncated PANs, 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 truncation of PANs adheres to the allowable number of digits as specified in PCI DSS and/or related FAQs.
<Report Findings Here> 2A-3.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), test all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application satisfies this requirement.
Modified p. 33 → 36
Describe how the test transactions performed verified that any truncation of PANs adheres to the allowable number of digits as specified in PCI DSS and/or related FAQs.
Describe how the test transactions performed verified that truncation of PANs adheres to the allowable number of digits <Report Findings Here>
Removed p. 34
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 it contains a description of the application’s function, including that the printing of full PANs on merchant receipts is a legal/regulatory obligation.

Application design documentation reviewed:

<Report Findings Here> 2A-3.1.2.b If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, perform a source-code review and verify the following:

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 …
Modified p. 34 → 37
• 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.
• The application only transmits cleartext PAN internally within the PTS POI device to an integrated printer that is part of the PTS POI device that is not attached via cabling or other networking mechanisms
Modified p. 34 → 37
• 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.

• The P2PE application securely deletes the clear-text PAN after completion of printing.
• The application only transmits cleartext PAN internally within the PTS POI device to an integrated printer that is part of the PTS POI device that is not attached via cabling or other networking mechanisms
Removed p. 35
• 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.
Removed p. 36
Note: The application may be the only POI-resident application at the time of assessment, but other assessed applications may be

• added to a P2PE solution at a later date; or the application may be

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

<Report Findings Here> 2A-3.2.b Perform a source-code review and verify that the application cannot directly facilitate sharing of clear-text account data with other applications via its logical interfaces.

Describe how the source-code review verified that the application cannot directly facilitate sharing of clear-text account data with other applications via its logical interfaces:
Modified p. 36 → 39
• 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 …
• A list of all logical interfaces for the application, and the function/purpose of each

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

• The logical interfaces not intended for sharing of cleartext account data (e.g., those for communication with other applications/software) Examine the logical interfaces used to communicate with other applications and confirm that the application cannot share cleartext account data …
Modified p. 37 → 40
<Report Findings Here> 2A-3.3 The application must only use external communication methods included in the PCI-approved POI device evaluation. For example, the POI device may provide an IP stack approved per the PTS Open Protocols module, or the device may provide serial ports or modems approved by the PTS evaluation to communicate transaction data encrypted by its PCI PTS SRED functions.
Note: For example, the PTS POI device may provide an IP stack approved per the PTS Open Protocols module, or the device may provide serial ports or modems approved by the PTS evaluation to communicate transaction data encrypted by its PCI PTS SRED functions.
Modified p. 37 → 40
Note: Using any external communication methods not included in the PCI-approved POI device evaluation will invalidate the PTS approval and such use is prohibited in P2PE solutions. Security of applications where the POI device implements Open Protocols is covered at Requirement 2B-2.1.
Note: Using any external communication methods not included in the PCI-approved PTS POI device evaluation will invalidate the PTS approval and such use is prohibited in P2PE Solutions. Individual PTS POI device HW/FW may denote a certain interface is excluded for use. This exclusion must be adhered to.
Modified p. 37 → 40
2A-3.3.a Examine the POI device vendor’s security guidance to determine which external communication methods are approved via the PCI-approved POI device evaluation.
2A-3.3.a Examine the PTS POI device vendor’s security guidance to determine which external communication methods are approved via the PTS POI device evaluation.
Modified p. 37 → 40
POI device vendor’s security guidance documentation reviewed:
POI device vendor’s security guidance documentation examined:
Modified p. 37 → 40
<Report Findings Here> Application design documentation reviewed:
<Report Findings Here> Application design documentation examined:
Removed p. 38
• 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.
Modified p. 38 → 41
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:
Describe how the examination of source code review verified that, when configured appropriately, the application design/functionality satisfies the requirement:
Modified p. 38 → 41
<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:
<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), test the PTS POI device interface(s). Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that:
Modified p. 38 → 41
The application uses only the external communication methods included in the POI device vendor's security guidance for all external communications.
• The application uses only the external communication methods included in the POI device vendor's security guidance for all external communications Describe test transactions performed (must utilize all functions of the application that handle account data):
Modified p. 38 → 41
<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:
<Report Findings Here> 2A-3.4 If whitelisting functionality is implemented in the application, the Implementation Guide must include the following:
Modified p. 38 → 41
• 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 configure the whitelisting functionality to ensure the output of cleartext 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 PTS POI device by authorized personnel using dual control

• That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card
Modified p. 38 → 41
• That such functionality must be approved by authorized personnel prior to implementation.
• That such functionality must be approved by authorized personnel prior to implementation
Modified p. 38 → 41
• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data.
• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data
Removed p. 39
• 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 authorized personnel prior to implementation.

• That documentation for all new installations or updates to whitelist functionality includes the following:

• Description and justification for the functionality

• Who approved the new installation or updated functionality prior to
Removed p. 40
Documented software development processes reviewed:

POI device vendor’s security guidance documentation reviewed:

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

Reporting responses at 2B-1.1.1 and 2B-1.1.2; no further reporting required here.
Modified p. 40 → 43
• Processes are based on industry standards and/or best practices.
• Processes are based on industry standards and/or best practices
Modified p. 40 → 43
• 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 Documented software development processes examined:
Modified p. 40 → 43
&lt;Report Findings Here&gt; 2B-1.1.b Examine the POI device vendor’s security guidance, and verify that any specified software development processes are:
<Report Findings Here> 2B-1.1.b Examine the PTS POI device vendor’s security guidance, and verify that any specified software development processes are:
Modified p. 40 → 43
• Incorporated into the application developer’s written software development processes.

• Implemented per the POI device vendor's security guidance.
• Incorporated into the application developer’s written software development processes

• Implemented per the PTS POI device vendor's security guidance POI device vendor’s security guidance documentation examined:
Modified p. 40 → 43
&lt;Report Findings Here&gt; 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).
<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 PTS 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).
Modified p. 41 → 44
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.1.2 Examine software-development procedures 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. 41 → 44
Documented software development processes reviewed:
Documented software-development processes examined:
Modified p. 41 → 44
<Report Findings Here> Software developers interviewed: <Report Findings Here> Software-testing personnel interviewed: <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> Describe how the software-development procedures 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:
Removed p. 42
Documented software-development procedures reviewed:
Modified p. 42 → 45
• 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 Documented software-development procedures examined:
Modified p. 42 → 45
Sample of code changes reviewed for 2B-1.2.1 through 1.2.4:
Sample of code changes examined for 2B-1.2.1 through 1.2.4:
Modified p. 43 → 46
Change control documentation reviewed: <Report Findings Here> 2B-1.2.4 Review and approval of review results by management prior to release.
&lt;Report Findings Here&gt; 2B-1.2.4 Review and approval of review results by management prior to release.
Modified p. 43 → 46
Change control documentation reviewed: <Report Findings Here> 2B-1.3 All changes to the application must follow change-control procedures. The procedures must include the following:
&lt;Report Findings Here&gt; 2B-1.3 All changes to the application must follow change-control procedures. The procedures must include the following:
Modified p. 43 → 46
• 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:
• 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 examined:
Modified p. 43 → 46
<Report Findings Here> Related change-control documentation reviewed:
<Report Findings Here> Related change-control documentation examined:
Removed p. 44
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.
Modified p. 44 → 47
<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.2 Documented approval of change by appropriate authorized parties 2B-1.3.2 Examine documentation to verify documented approval by appropriate authorized parties is present for each change Identify the P2PE Assessor who verified that, for each change examined, this was documented according to the change- control procedures:
Modified p. 44 → 47
<Report Findings Here> 2B-1.3.3 Functionality testing to verify that the change does not adversely impact the security of the device.
<Report Findings Here> 2B-1.3.3.b Examine evidence to verify that all changes (including patches) are tested per secure coding guidance before being released.
Modified p. 44 → 47
2B-1.3.4 Verify that back-out, rollback, or application de-installation procedures are prepared for each change.
2B-1.3.4 Examine evidence to verify that back-out, rollback, or application de- installation procedures are prepared for each change.
Removed p. 45
• Developing with defensive (protective) techniques regarding the logical input interfaces of the application.

Documented software processes reviewed:
Modified p. 45 → 48
• Developing with least privilege.
• Developing with least privilege
Modified p. 45 → 48
• Developing with least privilege.
• Developing with least privilege
Modified p. 45 → 48
• Developing with fail-safe exception handling.
• Developing with fail-safe exception handling
Modified p. 45 → 48
• Developing with defensive (protective) techniques regarding the logical input interfaces of the application.
• Developing with defensive (protective) techniques regarding the logical input interfaces of the application Documented software processes examined:
Modified p. 45 → 48
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 2B-1.4 Examine software development processes and interview software developers to verify that secure coding techniques are defined and include:
Modified p. 45 → 48
• Developing with fail-safe defaults.
• Developing with fail-safe defaults
Modified p. 45 → 48
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.
2B-1.4.1.a Examine software development processes for applications. Verify the process includes prevention of common coding vulnerabilities relevant to the programming languages and platforms in use.
Modified p. 45 → 48
Documented software processes reviewed:
Documented software processes examined:
Modified p. 45 → 48
<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).
<Report Findings Here> 2B-1.4.1.b Test to verify that the application is 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).
Removed p. 46
• Documentation of application risk-assessment results for management review and approval.

Documented software development procedures reviewed:
Modified p. 46 → 49
• Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries.
• Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries
Modified p. 46 → 49
• Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries.
• Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries
Modified p. 46 → 49
• Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.
• Assessment of application decision points, process flows, data flows, data storage, and trust boundaries
Modified p. 46 → 49
• Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.
• Assessment of application decision points, process flows, data flows, data storage, and trust boundaries
Modified p. 46 → 49
• Identification of all areas within the application 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.
• Identification of all areas within the application 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
Modified p. 46 → 49
• Implementation of appropriate corrections and countermeasures during the development process.
• Implementation of appropriate corrections and countermeasures during the development process
Modified p. 46 → 49
• Implementation of appropriate corrections and countermeasures during the development process.
• Implementation of appropriate corrections and countermeasures during the development process
Modified p. 46 → 49
• Documentation of application risk-assessment results for management review and approval.
• Documentation of application risk-assessment results for management review and approval Documented software development procedures examined:
Modified p. 46 → 49
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:
• 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:
Modified p. 46 → 49
• 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.
• 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
Modified p. 46 → 49
• 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.
• 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
Modified p. 47 → 50
• Secure coding techniques to avoid common coding vulnerabilities (e.g., vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.).
• Secure coding techniques to avoid common coding vulnerabilities (e.g., vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.)
Modified p. 47 → 50
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.
2B-1.5.a Examine documented software development processes to verify they require training in secure development practices for application developers, as applicable for the developer’s job function and technology used.
Modified p. 48 → 51
Documented software development procedures reviewed:
Documented software development procedures examined:
Modified p. 48 → 51
Documented software development procedures reviewed:
Documented software development procedures examined:
Modified p. 49 → 52
• Details of how the elements of the version scheme are in accordance with requirements specified in the P2PE Program Guide.

• The format of the version scheme, including number of elements, separators, character set, etc. (consisting of alphabetic, numeric, and/or alphanumeric characters).

• Definition of what each element represents in the version scheme (e.g., type of change, major, minor, or maintenance release, wildcard, etc.).

• Definition of elements that indicate use of wildcards.
• Details of how the elements of the version scheme are in accordance with requirements specified in the P2PE Program Guide

• The format of the version scheme, including number of elements, separators, character set, etc. (consisting of alphabetic, numeric, and/or alphanumeric characters)

• Definition of what each element represents in the version scheme (e.g., type of change, major, minor, or maintenance release, wildcard, etc.)

• Definition of elements that indicate use of wildcards
Modified p. 49 → 52
Change control documentation reviewed: <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:
&lt;Report Findings Here&gt; 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:
Removed p. 50
Documented versioning methodology reviewed:
Modified p. 50 → 53
• Have impact to any security functionality or P2PE requirement.
• Have impact to any security functionality or P2PE requirement
Modified p. 50 → 53
• How each type of change ties to a specific version number.
• 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:
Modified p. 50 → 53
• 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.
• 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 Documented versioning methodology examined:
Modified p. 50 → 53
<Report Findings Here> 2B-1.8.b Verify that the versioning methodology is in accordance with the P2PE Program Guide requirements.
<Report Findings Here> 2B-1.8.b Examine documentation to verify that the versioning methodology is in accordance with the P2PE Program Guide requirements.
Modified p. 51 → 54
Sample of recent payment application changes reviewed:
Sample of recent payment application changes examined:
Modified p. 51 → 54
<Report Findings Here> Change control documentation reviewed: <Report Findings Here> 2B-1.9 The versioning methodology must specifically identify whether wildcards are used and, if so, how they are used. The following must be included:
&lt;Report Findings Here&gt; 2B-1.9 The versioning methodology must specifically identify whether wildcards are used and, if so, how they are used. The following must be included:
Modified p. 51 → 54
• Provide details of how wildcards are used in the versioning methodology.
• Provide details of how wildcards are used in the versioning methodology
Modified p. 51 → 54
• Wildcards are never used for any change that has an impact on the security of the application and/or the POI device.
• Wildcards are never used for any change that has an impact on the security of the application and/or the POI device
Modified p. 51 → 54
• 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.
• 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
Modified p. 51 → 54
Documented versioning methodology reviewed:
Documented versioning methodology examined:
Removed p. 52
• 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.

Sample of recent payment application changes reviewed:
Modified p. 52 → 55
• Wildcards are never 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 never be used to represent a security impacting change.
• Wildcards are never 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 never be used to represent a security impacting change 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 …
Modified p. 52 → 55
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:
• 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 Sample of recent payment application changes examined:
Modified p. 52 → 55
<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 that:
<Report Findings Here> 2B-1.9.d Select a sample of recent payment application changes and examine the change control documentation that specifies the type of application change. Verify that:
Modified p. 52 → 55
<Report Findings Here> Change control documentation reviewed: <Report Findings Here>
<Report Findings Here> Change control documentation examined:
Modified p. 53 → 56
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:
2B-1.10 Examine the application’s Implementation Guide required at 2C-3 of this document to verify it includes a description of the vendor’s published versioning methodology for customers and integrators/resellers, and includes the following:
Modified p. 53 → 56
Sample of recent changes reviewed: <Report Findings Here>
Sample of recent changes examined: <Report Findings Here>
Removed p. 54
• Confirmation that that all secure development processes were followed.

Sample of recent releases of application and application updates reviewed:
Modified p. 54 → 57
• Signature by an authorized party to formally approve release of the application or application update.
• Signature by an authorized party to formally approve release of the application or application update
Modified p. 54 → 57
• Confirmation that secure development processes were followed by the vendor.
• Confirmation that all secure development processes were followed Sample of recent releases of application and application updates examined:
Modified p. 54 → 57
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.
• Confirmation that secure development processes were followed by the vendor 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. 54 → 57
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:
Software release processes examined: <Report Findings Here> 2B-1.13.b For a sample of recent releases of application and application updates, examine approval documentation to verify it includes:
Modified p. 54 → 57
• Formal approval and signature by an authorized party.
• Formal approval and signature by an authorized party
Modified p. 54 → 57
<Report Findings Here> Approval documentation reviewed: <Report Findings Here>
<Report Findings Here> Approval documentation examined: <Report Findings Here>
Modified p. 55 → 58
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.
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 PTS POI device evaluation.
Modified p. 55 → 58
Documented processes reviewed (including design documentation):
Documented processes examined (including design documentation):
Modified p. 55 → 58
<Report Findings Here> 2B-2.1.b Review the application’s Implementation Guide required at 2C-3 of this document and confirm that it includes the following in accordance with the POI device vendor's security guidance:
<Report Findings Here> 2B-2.1.b Examine the application’s Implementation Guide required at 2C-3 to verify that it includes the following in accordance with the PTS POI device vendor's security guidance:
Modified p. 56 → 59
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.
Adding or enabling additional services or protocols, or failing to follow the issued PTS POI device vendor’s security guidance will invalidate the approval status of that device for that implementation.
Modified p. 56 → 59
2B-2.1.1 Perform a source-code review and verify that the application:
2B-2.1.1 Examine the application source code and verify that the application:
Modified p. 56 → 59
• 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&#x27;s vendor security guidance. This includes the use of:
• Was developed according to the PTS 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 PTS POI device firmware as approved and documented in the POI device's vendor security guidance. This includes the use of:
Modified p. 57 → 60
2B-2.2.a Review the POI device vendor's security guidance and the application’s Implementation Guide.
2B-2.2.a Examine the PTS POI device vendor's security guidance and the application’s Implementation Guide.
Modified p. 57 → 60
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&#x27;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 PTS POI device vendor's security guidance and includes the following:
Modified p. 57 → 60
<Report Findings Here> 2B-2.2.b Perform a source-code review and verify 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.b Examine the application source code and verify that any connection to, or use of, shared resources is done securely and in accordance with the POI device vendor’s security guidance.
Modified p. 57 → 60
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:
Describe how the examination of source code verified that any connection to, or use of, shared resources is done securely and in accordance with the POI device vendor’s security guidance:
Modified p. 58 → 61
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.
2B-2.3 Examine the application source code 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.
Modified p. 58 → 61
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:
Describe how the examination of application source code verified that applications do not bypass or render ineffective any application segregation that is enforced by the POI device:
Modified p. 58 → 61
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.4 Examine the application source code 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.
Modified p. 58 → 61
<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.
<Report Findings Here> 2B-2.5 Applications do not bypass or render ineffective any encryption or account-data security methods implemented by the POI device.
Modified p. 58 → 61
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-2.5 Examine the application source code 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.
Modified p. 58 → 61
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.
2B-2.6 Test the application loaded on each applicable PTS POI device type and verify that the application does not bypass or render ineffective any applicable controls contained within this standard.
Removed p. 59
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:
Modified p. 59 → 62
Application developer’s system development documentation reviewed:
Application developer’s system development documentation examined:
Modified p. 59 → 62
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.
2B-3.1.1 Examine 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.
Removed p. 60
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:
Modified p. 60 → 63
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.
• Implement any account-data encryption functions that bypass or are intended to be used instead of the approved SRED encryption functions of the PTS POI device’s SRED firmware and associated cryptographic keys exclusively for account data encryption Note: The application may provide additional encryption on the SRED-encrypted account data; however it cannot bypass or replace the SRED encryption of the cleartext account data.
Modified p. 60 → 63
• 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.
• Confirmation that the application does not perform encryption of cleartext 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:
Modified p. 60 → 63
<Report Findings Here> 2B-4.1.b Perform a source-code review to verify 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.
Describe how the examination of application source code verified that the application functionality facilitating the encryption of account data utilizes the approved cryptographic algorithm(s) and associated key-management functions of the PTS POI device’s SRED firmware and is not implemented within the application itself:
Modified p. 60 → 63
<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. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application does not perform encryption of account data nor does it replace the SRED encryption performed by the underlying POI device’s firmware.
<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. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application satisfies the requirement.
Modified p. 61 → 64
Confirmation that the application is not capable of decrypting any clear-text account data encrypted by the SRED functions of the underlying POI firmware.
Confirmation that the application is not capable of decrypting any cleartext account data encrypted by the SRED functions of the underlying POI firmware.
Modified p. 61 → 64
<Report Findings Here> 2B-4.2.b Perform a source-code review to verify that the application is not capable of decrypting any clear-text account data encrypted by the SRED functions of the underlying POI firmware.
<Report Findings Here> 2B-4.2.b Examine the application source code to verify that the application is not capable of decrypting cleartext account data encrypted by the SRED functions of the underlying PTS POI firmware.
Modified p. 61 → 64
Describe how the source-code review verified that the application is not capable of decrypting any clear-text account data encrypted by the SRED functions of the underlying POI firmware.
Describe how the examination of source code verified that the application is not capable of decrypting cleartext account data encrypted by the SRED functions of the underlying PTS POI firmware.
Modified p. 61 → 64
<Report Findings Here> 2B-4.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 the application is not capable of decrypting any clear-text account data encrypted by the SRED functions of the underlying POI firmware.
<Report Findings Here> 2B-4.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 the application is not capable of decrypting any cleartext account data encrypted by the SRED functions of the underlying POI firmware.
Removed p. 62
Documented processes reviewed: <Report Findings Here> 2C-1.1.b Interview responsible software vendor personnel to confirm the following:
Modified p. 62 → 65
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:
2C-1.1.a Examine processes to identify new vulnerabilities and test applications for vulnerabilities that may affect the application. Verify the processes include the following:
Modified p. 62 → 65
• Using outside sources for security vulnerability information.
• Using outside sources for security vulnerability information
Modified p. 62 → 65
• Periodic testing of applications for new vulnerabilities.
• Periodic testing of applications for new vulnerabilities Documented processes examined: <Report Findings Here> 2C-1.1.b Interview responsible software vendor personnel to confirm the following:
Modified p. 62 → 65
• New vulnerabilities are identified using outside sources of security vulnerability information.

• All applications are tested for vulnerabilities.
• New vulnerabilities are identified using outside sources of security vulnerability information

• All applications are tested for vulnerabilities Responsible software vendor personnel interviewed:
Modified p. 62 → 65
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.
2C-1.2.a Examine processes to develop and deploy application security upgrades. Verify that processes include the timely development and deployment of critical security updates to customers.
Modified p. 62 → 65
Documented processes reviewed: <Report Findings Here> 2C-1.2.b Interview responsible software-vendor personnel to confirm that application security updates are developed and critical security updates are deployed in a timely manner.
Documented processes examined: <Report Findings Here> 2C-1.2.b Interview responsible software-vendor personnel to confirm that application security updates are developed and critical security updates are deployed in a timely manner.
Modified p. 63 → 66
• 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.
• 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:
Modified p. 63 → 66
<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.
<Report Findings Here> 2C-2.1.1.b Examine the application source code to verify that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware.
Modified p. 63 → 66
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:
Describe how the examination of source code verified that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware:
Modified p. 63 → 66
<Report Findings Here> 2C-2.1.1.d After the application is installed and configured in accordance with the Implementation Guide, attempt to perform an installation and an update using non-approved security mechanisms, and verify that the POI device will not allow the installation or update to occur.
<Report Findings Here> 2C-2.1.1.d After the application is installed and configured in accordance with the Implementation Guide, test in order to perform an installation and an update using non-approved security mechanisms, and verify that the PTS POI device will not allow the installation or update to occur.
Modified p. 63 → 66
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:
Describe how testing verified that the PTS POI device will not allow the installation or update to occur:
Removed p. 64
• 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.

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

Documented processes for dissemination reviewed:
Modified p. 64 → 67
• Instructions for how to sign the application.
• Instructions for how to sign the application
Modified p. 64 → 67
<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:
<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 must include the following:
Modified p. 64 → 67
<Report Findings Here> 2C-3.1.1 Addresses all requirements in P2PE Domain 2 wherever the Implementation Guide is referenced.
2C-3.1 REMOVED 2C-3.1.1 Addresses all requirements in P2PE Domain 2 wherever the Implementation Guide is referenced.
Modified p. 64 → 67
2C-3.1.1 Verify the Implementation Guide covers all related requirements in P2PE Domain 2.
2C-3.1.1 Examine the Implementation Guide to verify it covers all related requirements in P2PE Domain 2.
Removed p. 65
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. 65 → 68
• Any changes to the application (e.g., device changes/upgrades and major and minor software changes).
• Any changes to the application (e.g., device changes/upgrades, and major and minor software changes)
Modified p. 65 → 68
• Any changes to the Implementation Guide requirements in this document.
• Any changes to the Implementation Guide requirements in this document 2C-3.1.2.a Examine documented procedures to verify the Implementation Guide is reviewed at least annually and upon changes to the application or the P2PE Domain 2 requirements.
Modified p. 65 → 68
<Report Findings Here> 2C-3.1.2.b Verify the Implementation Guide is updated as needed to keep the documentation current with:
<Report Findings Here> 2C-3.1.2.b Examine documented procedures to verify the Implementation Guide is updated as needed to keep the documentation current with:
Modified p. 65 → 68
• 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.
• 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 Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2C-3.1.2.b:
Modified p. 65 → 68
<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.
<Report Findings Here> 2C-3.1.3 Distribution to all new 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. 65 → 68
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.
2C-3.1.3 Examine documented procedures to verify the Implementation Guide is distributed to new application installers, and re-distributed to all application installers every time the guide is updated.
Modified p. 65 → 68
Training materials and communication program documentation reviewed:
Training materials and communication program documentation examined:
Modified p. 65 → 68
Training materials and communication program documentation reviewed:
Training materials and communication program documentation examined: