Document Comparison
P2PE_RT_Application_v3.0.pdf
→
PCI-P2PE-APP_ROV-Template_v3_1.pdf
72% similar
50 → 65
Pages
16863 → 18938
Words
127
Content Changes
From Revision History
- September 2021 P2PE v3.1 Revision 1.0 This template includes the following updates:
Content Changes
127 content changes. 86 administrative changes (dates, page numbers) hidden.
Added
p. 2
• Updates from v3.0 P2PE Standard references to v3.1.
• Revisions made within the Introduction through Section 3 to add clarity and consistency, both within this P-ROV and across all v3.1 P-ROVs as applicable.
• Context of “PCI-listed” P2PE Products
• updated to “Validated”.
• Revision to the description for the use of Not Applicable to add clarity and guidance.
• Reformatting and restructuring of tables in Sections 2 and 3 with additional guidance.
• Revised table 2.1 to capture the assessment type utilizing this template.
• Table numbering in sections 1 through 3
• modified as needed to better align across all v3.1 P-ROVs.
• New table 3.9 to capture cryptographic key information.
• New table 3.10 to capture truncation information relative to requirement 2A-3.1.1.
• New table in section 4 to document all requirements determined to be Not Applicable.
• Errata updates to section 4.
• Added check boxes to section 4 to each individual requirement to capture In Place, N/A, …
• Revisions made within the Introduction through Section 3 to add clarity and consistency, both within this P-ROV and across all v3.1 P-ROVs as applicable.
• Context of “PCI-listed” P2PE Products
• updated to “Validated”.
• Revision to the description for the use of Not Applicable to add clarity and guidance.
• Reformatting and restructuring of tables in Sections 2 and 3 with additional guidance.
• Revised table 2.1 to capture the assessment type utilizing this template.
• Table numbering in sections 1 through 3
• modified as needed to better align across all v3.1 P-ROVs.
• New table 3.9 to capture cryptographic key information.
• New table 3.10 to capture truncation information relative to requirement 2A-3.1.1.
• New table in section 4 to document all requirements determined to be Not Applicable.
• Errata updates to section 4.
• Added check boxes to section 4 to each individual requirement to capture In Place, N/A, …
Added
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.
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.
N/A (Not Applicable) ‘Not Applicable’, or ‘N/A’, is only acceptable as a finding where the requirement, through testing and review, is determined to not apply to the P2PE Product.
Note: ‘Not Applicable’ cannot be used by entities that provide only partial aspects of a defined Component Provider service to validate to that Component Provider type. Refer to the “P2PE Applicability of Requirements” in the P2PE Program Guide.
Don’t mark “N/A” without providing an explanation and justification for why it is “N/A”.
P2PE Assessor Company and …
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.
N/A (Not Applicable) ‘Not Applicable’, or ‘N/A’, is only acceptable as a finding where the requirement, through testing and review, is determined to not apply to the P2PE Product.
Note: ‘Not Applicable’ cannot be used by entities that provide only partial aspects of a defined Component Provider service to validate to that Component Provider type. Refer to the “P2PE Applicability of Requirements” in the P2PE Program Guide.
Don’t mark “N/A” without providing an explanation and justification for why it is “N/A”.
P2PE Assessor Company and …
Added
p. 11
(DD-MMM-YYYY) Ex: 01-Jan-2021 Timeframe of Assessment:
No (If No, the application has never been listed) Type of Assessment Check the type of assessment this P2PE Application assessment is associated with:
Separately-listed P2PE Application Complete a P2PE Application P-ROV for each unique P2PE Application (i.e., only one application per P2PE Application P-ROV) intended to be Accepted and Listed on the PCI SSC Validated List of P2PE Applications. If the P2PE Application is to be associated with a Solution or an applicable Component assessment, the P2PE Application must be Accepted and Listed prior to the submission of the Solution or Component such that the Validated P2PE Application listing reference number can be denoted as necessary in the respective P-ROV(s) prior to submission of the Solution or Component.
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 …
No (If No, the application has never been listed) Type of Assessment Check the type of assessment this P2PE Application assessment is associated with:
Separately-listed P2PE Application Complete a P2PE Application P-ROV for each unique P2PE Application (i.e., only one application per P2PE Application P-ROV) intended to be Accepted and Listed on the PCI SSC Validated List of P2PE Applications. If the P2PE Application is to be associated with a Solution or an applicable Component assessment, the P2PE Application must be Accepted and Listed prior to the submission of the Solution or Component such that the Validated P2PE Application listing reference number can be denoted as necessary in the respective P-ROV(s) prior to submission of the Solution or Component.
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 …
Added
p. 15
• Only list each unique PTS Approval # once.
• 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.
• Ensure all the information below is correct, accurate, and there are no discrepancies between the information listed here and the information present on the POI device’s associated PTS Approval listing.
• Do NOT include POI devices (including HW and/or FW) that are ineligible for P2PE (e.g., non-SRED).
• Do NOT include HW and/or FW on the POI device listing that was NOT tested as part of the P2PE assessment.
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 2: …
• 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.
• Ensure all the information below is correct, accurate, and there are no discrepancies between the information listed here and the information present on the POI device’s associated PTS Approval listing.
• Do NOT include POI devices (including HW and/or FW) that are ineligible for P2PE (e.g., non-SRED).
• Do NOT include HW and/or FW on the POI device listing that was NOT tested as part of the P2PE assessment.
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 2: …
Added
p. 16
Yes (If Yes, provide details below) No (If No, leave details blank) Describe the additional account data encryption implementations. Where there is more than one implementation, clearly describe each implementation along with the applicable entity (e.g., acquirer / solution provider) managing it.
• The methods or processes used to identify all elements in scope of the P2PE Application assessment:
• How the scope of the assessment was confirmed to be accurate and to cover all aspects of the P2PE Application:
• The methods or processes used to identify all elements in scope of the P2PE Application assessment:
• How the scope of the assessment was confirmed to be accurate and to cover all aspects of the P2PE Application:
Added
p. 18
• All application processes related to each function:
• All communication channels, connection methods, and communication protocols used by the application for all internal and external communication channels:
• Details of any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to account data by the application:
<Insert P2PE Application architecture diagram(s) here>
Provide any additional information below that is not adequately captured within the diagram(s). Otherwise, check No Additional Details. No Additional Details <Additional Details, as needed> <Insert P2PE Application data-flow diagram(s) here>
Description and role of each dependency necessary for the application’s function:
• All communication channels, connection methods, and communication protocols used by the application for all internal and external communication channels:
• Details of any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to account data by the application:
<Insert P2PE Application architecture diagram(s) here>
Provide any additional information below that is not adequately captured within the diagram(s). Otherwise, check No Additional Details. No Additional Details <Additional Details, as needed> <Insert P2PE Application data-flow diagram(s) here>
Description and role of each dependency necessary for the application’s function:
Added
p. 21
Describe the lab/test environment(s) used for this assessment. When more than one environment is used, be clear which lab environment is being described.
Other facilities INCLUDED in the scope of this assessment (add additional rows as necessary) Were any additional facilities included in the scope of the assessment? Yes (If Yes, document below) No (If No, leave details blank) Description and purpose of facility included in the assessment Address of facility Relevant facilities EXCLUDED from the scope of this assessment (add additional rows as necessary) Were any relevant facilities excluded from the scope of the assessment? Yes (If Yes, document below) No (If No, leave details blank) Description and purpose of facility excluded from assessment Address of facility Explanation why the facility was excluded from the assessment
Other facilities INCLUDED in the scope of this assessment (add additional rows as necessary) Were any additional facilities included in the scope of the assessment? Yes (If Yes, document below) No (If No, leave details blank) Description and purpose of facility included in the assessment Address of facility Relevant facilities EXCLUDED from the scope of this assessment (add additional rows as necessary) Were any relevant facilities excluded from the scope of the assessment? Yes (If Yes, document below) No (If No, leave details blank) Description and purpose of facility excluded from assessment Address of facility Explanation why the facility was excluded from the assessment
Added
p. 24
Key ID: Retain generic ID or use specific IDs from assessment Key Type: E.g., DEK, MFK, BDK, KEK, IEK, PEK, MAC, Session, Transport, Public, Private, etc. Algorithm: E.g., TDEA, AES, RSA, DSA, ECC, etc. Key Length: Full length (include parity bits as applicable) Key Mgmt: E.g., DUKPT, MK/SK, Fixed, One-time use, etc.
Key ID Key Type Algorithm Key Mgmt Key Length (bits) Description & Purpose
Key ID Key Type Algorithm Key Mgmt Key Length (bits) Description & Purpose
Added
p. 26
4. Findings and Observations “In Place” may be a mix of “In Place” and “Not Applicable” responses, however it must not include any “Not in Place” responses.
Added
p. 28
All N/A responses require reporting on testing performed (including interviews conducted and documentation reviewed) and must explain how it was determined that the requirement does not apply within the scope of the assessment for the P2PE Product. Note: ‘Not Applicable’ cannot be used by entities that provide only partial aspects of a defined Component Provider service to validate to that Component Provider type. Refer to the “P2PE Applicability of Requirements” in the P2PE Program Guide.
Every requirement denoted as ‘N/A’ in the reporting section below must be documented in this table and vice versa.
List requirements in the order as they appear in the reporting section below. Insert additional rows if needed.
Requirement Document how it was determined that the requirement is Not Applicable to the P2PE Product under assessment
<Report Findings Here> 2A-2.2 The application must not store PAN and/or SAD (even if encrypted) as follows:
<Report Findings Here> 2A-2.3 The application must not …
Every requirement denoted as ‘N/A’ in the reporting section below must be documented in this table and vice versa.
List requirements in the order as they appear in the reporting section below. Insert additional rows if needed.
Requirement Document how it was determined that the requirement is Not Applicable to the P2PE Product under assessment
<Report Findings Here> 2A-2.2 The application must not store PAN and/or SAD (even if encrypted) as follows:
<Report Findings Here> 2A-2.3 The application must not …
Added
p. 33
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.
<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.
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.
<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.
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.
Added
p. 40
<Report Findings Here> 2B-1.1.b Examine the POI device vendor’s security guidance, and verify that any specified software development processes are:
Added
p. 43
<Report Findings Here> 2B-1.3.b Examine the application’s Implementation Guide required at 2C-3 of this document and verify it includes the following:
Added
p. 44
<Report Findings Here> 2B-1.3.3.b Verify that all changes (including patches) are tested per secure coding guidance before being released.
Added
p. 48
<Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 2B-1.6.b Examine mechanisms and observe procedures for securing source- code to verify integrity of source-code is maintained during the development process.
Added
p. 58
<Report Findings Here> 2B-2.4 Applications do not bypass or render ineffective any OS hardening implemented by the POI device.
<Report Findings Here> 2B-3.1.1 The application developer must provide security guidance describing how cryptographic keys and/or certificates have to be used.
<Report Findings Here> 2B-3.1.1 The application developer must provide security guidance describing how cryptographic keys and/or certificates have to be used.
Added
p. 64
<Report Findings Here> 2C-3.1.1 Addresses all requirements in P2PE Domain 2 wherever the Implementation Guide is referenced.
Modified
p. 1
Payment Card Industry (PCI) Point-to-Point Encryption P2PE Application Template for Report on Validation for use with P2PE v3.0 for P2PE Application Assessments
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
Removed
p. 2
This document serves as both the Reporting Template and Reporting Instructions document; there are not separate documents for this under P2PE v2 as there are still under P2PE v1
Removed
p. 4
The table on the following page summarizes the P2PE v3.0 P-ROVs and the applicability of each P-ROV relative to the assessment type.
The following acronyms are used: SP = Solution Provider; CP = Component Provider.
The following acronyms are used: SP = Solution Provider; CP = Component Provider.
Modified
p. 4 → 5
Use of this Reporting Template is mandatory for all P2PE v3.0 submissions for P2PE Applications.
Use of this Reporting Template is mandatory for each P2PE v3.1 P2PE Application assessment.
Modified
p. 4 → 5
• modified to increase/decrease the number of rows, or to change column width. Additional appendices may be
• modified to increase/decrease the number of rows, as necessary. Additional appendices may be
Modified
p. 4 → 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 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 …
Removed
p. 5
Note: A separate Merchant-Managed Solution P-ROV is used as part of MMS assessments.
Solution assessments that do not outsource the entirety of their Encryption Management Services to PCI-Listed Component Providers, either to an EMCP or to BOTH a PDCP AND a PMCP, must complete this P-ROV in addition to the Solution P-ROV.
Solution assessments that do not outsource the entirety of their Decryption Management Services to a PCI Listed DMCP must complete this P-ROV in addition to the Solution P-ROV.
Solution assessments that do not outsource the entirety of their Encryption Management Services to PCI-Listed Component Providers, either to an EMCP or to BOTH a PDCP AND a PMCP, must complete this P-ROV in addition to the Solution P-ROV.
Solution assessments that do not outsource the entirety of their Decryption Management Services to a PCI Listed DMCP must complete this P-ROV in addition to the Solution P-ROV.
Modified
p. 5 → 6
Component Provider assessments for an EMCP, PDCP, or a PMCP must complete this P-ROV.
Component Provider assessments for an EMCP, PDCP, or a PMCP must complete the EMS P-ROV.
Modified
p. 5 → 6
P2PE Application P2PE Application Any assessment that utilizes software on the POI devices intended for use in a P2PE Solution that has the potential to access clear-text cardholder data must complete this P-ROV.
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).
Modified
p. 5 → 6
Decryption Management Services (DMS) Solution (SP) Decryption Management CP (DMCP) Decryption Management Services relates to the management of a decryption environment, including applicable devices (e.g., HSMs) used to support a P2PE Solution.
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.
Modified
p. 5 → 6
Component Provider assessments for a DMCP must complete this P-ROV.
Component Provider assessments for a DMCP must complete the DMS P-ROV.
Modified
p. 5 → 6
Key Management Services (KMS) 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.
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.
Modified
p. 5 → 6
Solution assessments that have not satisfied the key management services requirements (Domain 5) either through the use of PCI-listed Component Providers and/or through the assessment of their Encryption Management Services and/or Decryption Management Services must complete the KMS P-ROV. E.g., if the P2PE Solution offers remote key-distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account-data encryption, or the operation of an applicable CA/RA, or any other relevant key management service that …
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 …
Modified
p. 5 → 6
Component Provider assessments for a KIF, KMCP, KLCP, or a CA/RA must complete this P-ROV.
Component Provider assessments for a KIF, KMCP, KLCP, or a CA/RA must complete the KMS P- ROV.
Removed
p. 6
Response When to use this Response:
(Not Applicable) The requirement does not apply to the P2PE Product.
(Not Applicable) The requirement does not apply to the P2PE Product.
Modified
p. 6 → 7
Section 1: Contact Information and Report Date
Modified
p. 6 → 7
Section 2: Summary Overview
Modified
p. 6 → 7
Section 3: Details and Scope of P2PE Assessment
Modified
p. 6 → 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.
Modified
p. 6 → 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 4. Findings and Observations and are only addressed at that high-level. A summary of all findings is also at “2.6 Summary of P2PE Compliance Status.” The following table is a representation when considering which selection to make. Remember, assessors must select only …
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 …
Modified
p. 6 → 7
In Place The expected testing has been performed, and all elements of the requirement have been met as stated. This may be a mix of In Place and Not Applicable responses, but no Not in Place response. Requirements fulfilled by other P2PE Components or Third Parties should be In Place, unless the requirement does not apply.
RESPONSE WHEN TO USE THIS RESPONSE In Place The expected testing has been performed, and all elements of the requirement have been met as stated. Requirements fulfilled by other P2PE Components or Third Parties should be In Place, unless the requirement does not apply.
Modified
p. 6 → 7
All Not Applicable responses require reporting on testing performed (including interviews conducted and documentation reviewed) and must explain how it was determined that the requirement does not apply. There is no need to repeat lengthy responses where related requirements are not applicable.
All N/A responses require reporting on testing performed (including interviews conducted and documentation reviewed) and must explain how it was determined that the requirement does not apply within the scope of the assessment for the P2PE Product.
Removed
p. 7
• Brief description/short answer
Modified
p. 7 → 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.
Modified
p. 7 → 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.
Modified
p. 7 → 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.
Modified
p. 7 → 8
• “Describe how…” These are the only reporting instructions that will stretch across half of the table; the above are all a quarter-table’s width to serve as a visual indicator of detail expected in response. 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.
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.
Removed
p. 8
• Describe how a Requirement was verified as the Reporting Instruction directs, not just that it was verified.
• Don’t include forward-looking statements or project plans in responses.
• Don’t include forward-looking statements or project plans in responses.
Modified
p. 8 → 9
Complete all applicable P-ROVs based on the assessment type.
Modified
p. 8 → 9
Complete all sections in the order specified, with concise detail.
Modified
p. 8 → 9
Read and understand the intent of each Requirement and Testing Procedure.
Modified
p. 8 → 9
Provide a response for every Testing Procedure, even if N/A.
Modified
p. 8 → 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.
Modified
p. 8 → 9
Ensure all parts of the Testing Procedure are addressed.
Modified
p. 8 → 9
Ensure the response covers all applicable application and/or system components.
Modified
p. 8 → 9
Perform an internal quality assurance review of the P-ROV for clarity, accuracy, and quality.
Modified
p. 8 → 9
Perform an internal quality assurance review of all submitted P-ROVs and the details within the PCI SSC Portal.
Modified
p. 8 → 9
Provide useful, meaningful diagrams, as directed.
Modified
p. 8 → 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.
Modified
p. 8 → 9
Don’t simply repeat or echo the Testing Procedure in the response.
Modified
p. 8 → 9
Don’t copy responses from one Testing Procedure to another.
Modified
p. 8 → 9
Don’t copy responses from previous assessments.
Modified
p. 8 → 9
Don’t include information irrelevant to the assessment.
Modified
p. 9 → 10
1. Contact Information and Report Date 1.1 Contact Information P2PE Application Vendor contact information Company name: Company URL:
1. Contact Information and Report Date 1.1 Contact Information P2PE Application Vendor Contact Information Company name: Company URL:
Modified
p. 9 → 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:
Modified
p. 9 → 10
Confirm that internal QA was fully performed on the entire P2PE submission, per requirements in relevant program documentation.
Confirm that internal QA was fully performed on the entire P2PE submission, per requirements in the relevant program documentation.
Modified
p. 9 → 10
No (If No, this is not in accordance with PCI Program requirements) QA reviewer name: QA reviewer credentials:
Modified
p. 9 → 10
Assessor name: Assessor credentials: QSA (P2PE) PA-QSA (P2PE) Assessor phone number: Assessor e-mail address:
Modified
p. 10 → 11
Additional services provided by PA-QSA(P2PE)/QSA (P2PE)/QSA company The PA-QSA (P2PE) Qualification Requirements v2.1, Section 2.2 “Independence” specifies requirements for QSAs around disclosure of such services and/or offerings that could reasonably be viewed to affect independence of assessment. Complete the sections below after review of this portion of the Validation Requirements, to ensure responses are consistent with documented obligations.
(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 …
• 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 …
Modified
p. 10 → 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. 10 → 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:
Removed
p. 11
If yes, provide PCI SSC Ref # or N/A Has the application been developed in-house by the solution provider for use only in their own solution? If “Yes,” complete the two questions to the right of this cell.
Is this application to be listed on the PCI SSC List of Validated P2PE Applications? Identify the specific P2PE solution the application is intended for use with (Include solution provider company name and solution name):
Description of application function/purpose:
Is this application to be listed on the PCI SSC List of Validated P2PE Applications? Identify the specific P2PE solution the application is intended for use with (Include solution provider company name and solution name):
Description of application function/purpose:
Modified
p. 11 → 12
2. Summary Overview 2.1 P2PE Application Details P2PE application name: Application version:
2. Summary Overview 2.1 P2PE Application Assessment Details Application Name: Application Version #:
Modified
p. 11 → 12
Is the application already listed on the PCI SSC List of Validated P2PE Applications?
Is the P2PE Application currently (or was it previously) listed on the PCI SSC List of Validated P2PE Applications? Yes (If Yes, provide listing reference #):
Modified
p. 11 → 13
Describe how the application is sold, distributed, or licensed to third parties (indicate N/A if this does not apply, e.g., for MMS):
Modified
p. 11 → 13
Description of how the application is designed (for example, as a standalone application, in modules, or as part of a suite of applications):
Description of how the application is designed (e.g., as a standalone application, in modules, or as part of a suite of applications):
Removed
p. 12
Define what types of changes the vendor includes as a “No Impact” change:
(Refer to the P2PE Program Guide for information on what constitutes a No Impact Change.) 2.3 Other Third-Party Service Provider entities involved in P2PE Application This could include third-party service providers in use as applicable, including authorized Integrator/Resellers and such.
“Other details” is to be used as needed. For example, if there is a third-party service provider providing decryption services but it not a P2PE Component at 2.2, use “Other details” to address data such as P2PE endpoint system identifier (e.g., Host System and HSM). Mark as “n/a” if no other details are needed.
Entity Name: Role/Function: Entity Location(s): Other Details, if needed:
(Refer to the P2PE Program Guide for information on what constitutes a No Impact Change.) 2.3 Other Third-Party Service Provider entities involved in P2PE Application This could include third-party service providers in use as applicable, including authorized Integrator/Resellers and such.
“Other details” is to be used as needed. For example, if there is a third-party service provider providing decryption services but it not a P2PE Component at 2.2, use “Other details” to address data such as P2PE endpoint system identifier (e.g., Host System and HSM). Mark as “n/a” if no other details are needed.
Entity Name: Role/Function: Entity Location(s): Other Details, if needed:
Removed
p. 13
PTS Approval #: Make/ Manufacturer: Model Name/ Number: Hardware #: Firmware #(s):*
Note: P2PE Applications and P2PE non-payment software do not meet the PTS definition of “firmware” and are not reviewed as part of the PTS POI assessment. Additionally, software meeting the PTS definition of “firmware” is not reassessed during a P2PE assessment (Any software intended for use in a P2PE solution that does not meet the PTS definition of "firmware" must be assessed in accordance with the PCI P2PE standard and is subject to all applicable P2PE security requirements. Note that reassessing the PTS firmware as part of the P2PE assessment is not required nor allowed.).
Functionality provided (for all POI device types supported) The columns below represent review of the PTS Listing approval details (to be reported under “PTS Listing”) as well as the observed device configuration (to be reported under “P2PE”). This table will match what functionality was listed …
Note: P2PE Applications and P2PE non-payment software do not meet the PTS definition of “firmware” and are not reviewed as part of the PTS POI assessment. Additionally, software meeting the PTS definition of “firmware” is not reassessed during a P2PE assessment (Any software intended for use in a P2PE solution that does not meet the PTS definition of "firmware" must be assessed in accordance with the PCI P2PE standard and is subject to all applicable P2PE security requirements. Note that reassessing the PTS firmware as part of the P2PE assessment is not required nor allowed.).
Functionality provided (for all POI device types supported) The columns below represent review of the PTS Listing approval details (to be reported under “PTS Listing”) as well as the observed device configuration (to be reported under “P2PE”). This table will match what functionality was listed …
Modified
p. 13 → 16
Application Security Yes No
Application Security (Domain 2) Yes No
Removed
p. 14
• Provide detailed descriptions and/or diagrams to illustrate how the application functions in a typical implementation.
− Description of all application processes related to each function − Description of all communication channels, connection methods, and communication protocols used by the application for all internal and external communication channels − Details of any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to account data by the application − Other necessary application functions or processes, as applicable
− Description of all application processes related to each function − Description of all communication channels, connection methods, and communication protocols used by the application for all internal and external communication channels − Details of any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to account data by the application − Other necessary application functions or processes, as applicable
Modified
p. 14 → 17
3. Details and Scope of P2PE Assessment 3.1 P2PE Application details For each POI device the application was tested on:
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:
Modified
p. 14 → 18
• For all application functions, provide the following:
• Other necessary application functions or processes, as applicable:
Modified
p. 14 → 18
Identify any features of the application that were not included in the scope of the assessment and explain why, otherwise mark “N/A”:
Removed
p. 15
<Insert P2PE Application data-flow diagram(s)>
Modified
p. 15 → 19
Provide high-level data-flow diagram(s) that shows details of all flows of account data, including:
Modified
p. 15 → 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 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).
Modified
p. 15 → 19
Identify the following for each data flow:
Removed
p. 16
Description of component necessary for application functioning Type of component (for example, software, hardware) Role of component 3.4 Facilities Lab environment used by the P2PE Assessor for this assessment Identify whether the lab was provided by the P2PE Assessor or the Application Vendor: P2PE Assessor’s Lab Application Vendor’s Lab Address of the lab environment used for this assessment:
Describe the lab environment used for this assessment:
List of all application vendor facilities INCLUDED in this Application assessment Description and purpose of facility included in assessment Address of facility
Describe the lab environment used for this assessment:
List of all application vendor facilities INCLUDED in this Application assessment Description and purpose of facility included in assessment Address of facility
Modified
p. 18 → 22
If the P2PE Application Implementation Guide consists of more than one document, the brief description below should explain the purpose of each document it includes, such as for a different POI Device Types, for different functions, for different uses of the P2PE Application, etc. If an IG covers ALL the POI devices detailed in Table 2.5, denote ‘ALL’ in the last column, otherwise denote only the specific PTS Approval #s specific to the IG.
Modified
p. 18 → 22
P2PE Application Implementation Guide(s) (IG):
P2PE Application Implementation Guide(s) (IGs):
Modified
p. 18 → 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? (Must align with Section 2.5) All other documentation reviewed for this P2PE Assessment:
Reference # (optional use) Document Name (Title of the IG) Version Number of the IG Document Date (latest version date) Which POI Device Type(s) is Addressed? (Enter PTS Approval #s - comma delimited) (Must align with Table 2.5) All other documentation reviewed for this P2PE Application assessment:
Modified
p. 18 → 22
Reference # (optional use) Document Name (including version, if applicable) Document date (latest version date) Document Purpose 3.6 Individuals Interviewed List of all personnel interviewed for this Application assessment:
Reference # (optional use) Document Name (including version, if applicable) Document Date (latest version date) Document Purpose (brief summary)
Modified
p. 18 → 23
Reference # (optional use) Interviewee’s Name Company Job Title
Reference # (optional use) Interviewee’s Name Job Title Company Summary of Topics Covered (brief summary) 3.8 (Table not currently used)
Removed
p. 19
4. Findings and Observations Application Security
• Summary of Findings P2PE Validation Requirements Summary of Findings (check one) In Place N/A Not in Place 2A Protect PAN and SAD 2A-1 The application executes on a PCI-approved POI device with SRED enabled and active.
• Summary of Findings P2PE Validation Requirements Summary of Findings (check one) In Place N/A Not in Place 2A Protect PAN and SAD 2A-1 The application executes on a PCI-approved POI device with SRED enabled and active.
Modified
p. 20 → 29
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.
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.
Removed
p. 22
<Report Findings Here> 2A-2.4 The application must securely delete any PAN and/or SAD that was stored during application processing.
Modified
p. 22 → 32
<Report Findings Here> 2A-2.4.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that the process Describe test transactions performed (must utilize all functions of the application that handle account data):
<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 …
Removed
p. 24
<Report Findings Here> 2A-3.1.2.c If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), Describe test transactions performed (must utilize all functions of the application that handle account data):
Modified
p. 25 → 35
Describe forensic tools and/or methods used to inspect the test transactions:
<Report Findings Here> Describe forensic tools and/or methods used to inspect the test transactions:
Modified
p. 26 → 37
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.
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.
Modified
p. 27 → 38
• 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 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.
Modified
p. 28 → 39
PCI payment brand account/card data Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2A-3.4 <Report Findings Here> 2B-1.1 Applications must be developed based on industry best practices and in accordance with the POI device vendor's security guidance, and information security is incorporated throughout the software development life cycle. These processes must include the following:
PCI payment brand account/card data Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2A-3.4 <Report Findings Here>
Modified
p. 29 → 41
<Report Findings Here> Software developers interviewed: <Report Findings Here> Software-testing personnel interviewed:
<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 live PANs are not used for testing or development:
Removed
p. 30
<Report Findings Here> 2B-1.2 Application code and any non-code configuration mechanisms must be reviewed prior to every release or update.
Modified
p. 30 → 41
<Report Findings Here> Software developers interviewed: <Report Findings Here> Software-testing personnel interviewed:
<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:
Modified
p. 30 → 42
<Report Findings Here> Responsible personnel interviewed: <Report Findings Here>
<Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 2B-1.2.1 Review of code changes by individuals other than the originating author, and by individuals who are knowledgeable in code-review techniques and secure coding practices.
Removed
p. 31
<Report Findings Here> 2B-1.2.3 Confirming that appropriate corrections are implemented prior to release.
Modified
p. 31 → 43
<Report Findings Here> 2B-1.2.4 Review and approval of review results by management prior to release.
Change control documentation reviewed: <Report Findings Here> 2B-1.2.4 Review and approval of review results by management prior to release.
Modified
p. 31 → 43
<Report Findings Here> 2B-1.3 All changes to the application must follow change-control procedures. The procedures must include the following:
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:
Removed
p. 32
<Report Findings Here> 2B-1.3.1 Documentation of impact 2B-1.3.1 Verify that documentation of customer impact is included in the change-control documentation for each change.
Removed
p. 33
<Report Findings Here> 2B-1.4 Applications must be developed according to industry best practices for secure coding techniques, including (but not limited to):
Modified
p. 34 → 46
• 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.
• 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. 35 → 47
Identify training materials examined: <Report Findings Here> Sample of developers interviewed: <Report Findings Here> 2B-1.6 Secure source-control practices must be implemented to verify integrity of source-code during the development process.
Identify training materials examined: <Report Findings Here> Sample of developers interviewed: <Report Findings Here>
Modified
p. 35 → 48
Describe how mechanisms and procedures for securing source-code verified that integrity of source-code is maintained during the development process:
Removed
p. 36
<Report Findings Here> 2B-1.7.1 The vendor’s software versioning methodology must define the specific version elements used, including at least the following:
Modified
p. 36 → 48
<Report Findings Here> 2B-1.7 The application vendor must document and follow a software-versioning methodology as part of their system-development lifecycle. The methodology must follow the procedures in the P2PE Program Guide for changes to payment applications and include at least the following:
<Report Findings Here> 2B-1.7 The application vendor must document and follow a software-versioning methodology as part of their system- development lifecycle. The methodology must follow the procedures in the P2PE Program Guide for changes to payment applications and include at least the following:
Modified
p. 36 → 49
• Details of how the elements of the version scheme are in accordance with requirements specified in the P2PE Program Guide.
• 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.
• 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. 36 → 49
<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:
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:
Removed
p. 37
<Report Findings Here> 2B-1.8.d Select a sample of recent payment application changes and review the change control documentation that specifies the type of application change Sample of recent payment application changes reviewed:
Modified
p. 37 → 50
• Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application).
• Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application). • Specific identification and definition of changes that:
Modified
p. 38 → 51
<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:
<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:
Modified
p. 39 → 52
Sample of recent payment applications reviewed:
Sample of recent payment application changes reviewed:
Modified
p. 39 → 52
<Report Findings Here> Change control documentation reviewed:
<Report Findings Here> Change control documentation reviewed: <Report Findings Here>
Modified
p. 40 → 53
Sample of recent changes reviewed: <Report Findings Here> 2B-1.12 Software vendor must have a process in place to review application updates for conformity with the versioning methodology prior to release.
Sample of recent changes reviewed: <Report Findings Here>
Modified
p. 41 → 54
<Report Findings Here> Approval documentation reviewed: <Report Findings Here> 2B-2.1 Where the application relies on the Open Protocol functionality of the POI device firmware, the application must be developed in accordance with the POI device vendor's security guidance.
<Report Findings Here> Approval documentation reviewed: <Report Findings Here>
Removed
p. 43
<Report Findings Here> 2B-2.3 Applications do not bypass or render ineffective any application segregation that is enforced by the POI device.
Modified
p. 45 → 60
<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.
<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.
Modified
p. 46 → 62
Documented processes reviewed: <Report Findings Here>
Documented processes reviewed: <Report Findings Here> 2C-1.1.b Interview responsible software vendor personnel to confirm the following:
Removed
p. 47
<Report Findings Here> 2C-2.1 Ensure that all application installations and updates are cryptographically authenticated as follows:
Modified
p. 49 → 65
<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 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.