PCI Watch

Tracking changes across the Payment Card Industry

Document Comparison

P2PE_RT_Application_v2.0.pdf → P2PE_v2.0_r1.2_Application_P-ROV__Template.pdf
90% similar
40 → 40 Pages
15254 → 15326 Words
80 Content Changes

From Revision History

  • March 2020 For use with P2PE v2.0, Revision 1.2
  • March 2020 © 2020 PCI Security Standards Council, LLC. All Rights Reserved. Page iii Table of Contents

Content Changes

80 content changes. 40 administrative changes (dates, page numbers) hidden.

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

Clarify domain applicability for CA/RAs.
Added p. 6
• 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.
Added p. 12
• Identify any functionality of the application that was not included in the assessment <Insert P2PE Application detailed diagram(s)> 3.2 Overview of P2PE Application data flow For each POI the application was tested on:

• Provide high-level data flow diagram(s) that shows details of all flows of account data, including: o All flows and locations of encrypted account data (including data input, output, and within the POI) o All flows and locations of cleartext account data (including data input, output, and within the POI)
Added p. 17
• Application must not store PAN data after the payment transaction is complete.

• Application must not store SAD after authorization is complete. Note: Storage of encrypted PAN data is acceptable during the business process of finalizing the payment transaction if needed (e.g., offline transactions). However, at all times, SAD is not stored after authorization is complete.

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

• SAD is not stored after authorization is completed.

• SAD is not stored after authorization is completed.
Added p. 24
• Processes are based on industry standards and/or best practices.
Added p. 27
• Developing with least privilege.

• Developing with least privilege.

• Developing with fail-safe exception handling.

• Developing with fail-safe defaults.

• Secure application design.

• Secure coding techniques to avoid common coding vulnerabilities (e.g., vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.).

• Managing sensitive data in memory.

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

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

• Specific identification and definition of changes that:

• How each type of change ties to a specific version number.
Added p. 33
• Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.)

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

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

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

• Formal approval and signature by an authorized party.

• Link Layer protocols

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

• A list of shared resources.
Added p. 38
• Periodic testing of applications for new vulnerabilities.

• Instructions for how to sign the application.

• Any changes to the application (e.g., device changes/upgrades and major and minor software changes).
Modified p. 1
Payment Card Industry (PCI) Point-to-Point Encryption Template for Report on Validation for use with P2PE v2.0 (Revision 1.1) for P2PE Application Revision 1.0
Payment Card Industry (PCI) Point-to-Point Encryption Template for Report on Validation for use with P2PE v2.0 (Revision 1.2) for P2PE Application Revision 1.2
Modified p. 6
“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. 6
Document name or interviewee reference At 3.7 Documentation Reviewed and 3.8 Individuals Interviewed, there is a space for a reference number and it is the P2PE Assessor’s choice to use the document name/interviewee job title or the reference number in responses. A listing is sufficient here, no further detail required.
• Document name or interviewee reference At 3.7 Documentation Reviewed and 3.8 Individuals Interviewed, there is a space for a reference number and it is the P2PE Assessor’s choice to use the document name/interviewee job title or the reference number in responses. A listing is sufficient here, no further detail required.
Modified p. 6
Sample reviewed Brief list is expected or sample identifier. Again, where applicable, it is the P2PE Assessor’s choice to list out each sample within reporting or to utilize sample identifiers from the sampling summary table.
• Sample reviewed Brief list is expected or sample identifier. Again, where applicable, it is the P2PE Assessor’s choice to list out each sample within reporting or to utilize sample identifiers from the sampling summary table.
Modified p. 6
 Brief description/short answer

• “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.
• “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.
Modified p. 7
Use the corresponding Reporting Template for v2.0 of the P2PE Standard.
• Use the corresponding Reporting Template for v2.0 of the P2PE Standard.
Modified p. 7
Complete all sections in the order specified, with concise detail.
• Complete all sections in the order specified, with concise detail.
Modified p. 7
Read and understand the intent of each Requirement and Testing Procedure.
• Read and understand the intent of each Requirement and Testing Procedure.
Modified p. 7
Provide a response for every Testing Procedure, even if N/A.
• Provide a response for every Testing Procedure, even if N/A.
Modified p. 7
 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. 7
Ensure all parts of the Testing Procedure are addressed.
• Ensure all parts of the Testing Procedure are addressed.
Modified p. 7
Ensure the response covers all applicable application and/or system components.
• Ensure the response covers all applicable application and/or system components.
Modified p. 7
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. 7
Provide useful, meaningful diagrams, as directed.
• Provide useful, meaningful diagrams, as directed.
Modified p. 7
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. 7
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. 7
Don’t copy responses from one Testing Procedure to another.
• Don’t copy responses from one Testing Procedure to another.
Modified p. 7
Don’t copy responses from previous assessments.
• Don’t copy responses from previous assessments.
Modified p. 7
Don’t include information irrelevant to the assessment.
• Don’t include information irrelevant to the assessment.
Modified p. 12
Provide detailed descriptions and/or diagrams to illustrate how the application functions in a typical implementation.
• Provide detailed descriptions and/or diagrams to illustrate how the application functions in a typical implementation.
Modified p. 12
For all application functions, provide the following: o Description of all application processes related to each function o Description of all communication channels, connection methods, and communication protocols used by the application for all internal and external communication channels o Details of any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to account data by the application o Other necessary application functions or processes, as applicable  Identify any functionality of the application that was not included in …
• For all application functions, provide the following: o Description of all application processes related to each function o Description of all communication channels, connection methods, and communication protocols used by the application for all internal and external communication channels o Details of any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to account data by the application o Other necessary application functions or processes, as applicable
Modified p. 12
 Provide high-level data flow diagram(s) that shows details of all flows of account data, including: o All flows and locations of encrypted account data (including data input, output, and within the POI) o All flows and locations of cleartext account data (including data input, output, and within the POI)  Identify the following for each data flow: o How and where account data is transmitted, processed, and/or stored o The types of account data involved (for example, full track, …
• Identify the following for each data flow: o How and where account data is transmitted, processed, and/or stored o The types of account data involved (for example, full track, PAN, expiry date, etc.) o All components involved in the transmission, processing, or storage of account data Note: Include all types of data flows, including any output to hard copy/paper media.
Modified p. 13
Authentication mechanisms:
• Authentication mechanisms:
Modified p. 13
Authentication database:
• Authentication database:
Modified p. 13
Security of authentication data storage:
• Security of authentication data storage:
Removed p. 17
 Application must not store PAN data after the payment transaction is complete.  Application must not store SAD after authorization is complete. Note: Storage of encrypted PAN data is acceptable during the business process of finalizing the payment transaction if needed (e.g., offline transactions). However, at all times, SAD is not stored after authorization is complete.
Modified p. 17
 Model name and number  Hardware version number  Firmware version number  SRED listed as a function provided. 2A-1.1 For each POI device type used by the application, examine the POI device configurations and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing:
• SRED listed as a function provided. 2A-1.1 For each POI device type used by the application, examine the POI device configurations and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing:
Modified p. 17
Model name/number  Hardware version number Firmware version number SRED listed as a function provided.
• Model name and number

• Hardware version number • Firmware version number • Hardware version number

• Firmware version number

• SRED listed as a function provided.
Modified p. 18
 How it uses PAN and/or SAD for its application processing.  How it ensures the application does not store PAN after the payment transaction is complete. How it ensures the application does not store SAD after authorization is complete.
• 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.
Modified p. 18
PAN is not stored after the payment transaction is completed.  SAD is not stored after authorization is completed.
• PAN is not stored after the payment transaction is completed.
Modified p. 18
PAN is not stored after the payment transaction is completed.  SAD is not stored after authorization is completed.
• PAN is not stored after the payment transaction is completed.
Modified p. 20
The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and is not attached via cabling or other networking mechanisms. The P2PE application securely deletes the clear-text PAN after completion of printing. Note that Domain 1 (at 1B.1.1) and Domain 3 (at 3A-1.3) also include requirements that must be met for any POI device and for a P2PE solution provider, respectively, that facilitates merchant printing …
• The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and is not attached via cabling or other networking mechanisms. • The P2PE application securely deletes the clear-text PAN after completion of printing. Note that Domain 1 (at 1B.1.1) and Domain 3 (at 3A-1.3) also include requirements that must be met for any POI device and for a P2PE solution provider, respectively, that facilitates merchant printing …
Modified p. 20
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 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.
Modified p. 21
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 clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and is not attached via cabling or other networking mechanisms. • The P2PE application securely deletes the clear-text PAN after completion of printing.
Modified p. 21
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 …
• 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 …
Modified p. 22
A list of the external communication methods included in the POI device vendor’s security guidance. A list of which approved external communication methods are used by the application. A description of where external communications are used by the application.
• A list of the external communication methods included in the POI device vendor’s security guidance. • A list of which approved external communication methods are used by the application. • A description of where external communications are used by the application.
Modified p. 23
How to configure the whitelisting functionality to ensure the output of clear-text account data is prohibited, except for non-PCI payment brand account/card data. How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control. How to perform cryptographic authentication by the POI device’s firmware. That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data. That such functionality must …
• How to configure the whitelisting functionality to ensure the output of clear-text account data is prohibited, except for non-PCI payment brand account/card data. • How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control. • How to perform cryptographic authentication by the POI device’s firmware. • That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data. • That such functionality must …
Modified p. 23
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 …
• 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 …
Modified p. 24
 Processes are based on industry standards and/or best practices.  Information security is included throughout the software development life cycle. Applications are developed in accordance with all applicable P2PE requirements. .
• Information security is included throughout the software development life cycle. • Applications are developed in accordance with all applicable P2PE requirements. .
Modified p. 24
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 POI device vendor's security guidance.
Modified p. 24
Examine written software development processes and interview software developers. Examine testing documentation and samples of test data, observe testing processes, and interview software-testing personnel. Examine the final application product.
• Examine written software development processes and interview software developers. • Examine testing documentation and samples of test data, observe testing processes, and interview software-testing personnel. • Examine the final application product.
Modified p. 25
Reviews are performed by an individual, other than the code author, who is knowledgeable in code-review techniques and secure coding practices. Changes to code that manages security-sensitive configuration options are reviewed to confirm that they will not result in the exposure of PCI payment-brand accounts/cards. Code reviews ensure code is developed according to secure coding guidelines.
• Reviews are performed by an individual, other than the code author, who is knowledgeable in code-review techniques and secure coding practices. • Changes to code that manages security-sensitive configuration options are reviewed to confirm that they will not result in the exposure of PCI payment-brand accounts/cards. • Code reviews ensure code is developed according to secure coding guidelines.
Modified p. 26
Documentation of customer impact Documented approval of change by appropriate authorized parties Functionality testing to verify that the change does not adversely impact the security of the device Back-out or application de-installation procedures Documented developer change-control procedures for software modifications reviewed:
• Documentation of customer impact • Documented approval of change by appropriate authorized parties • Functionality testing to verify that the change does not adversely impact the security of the device • Back-out or application de-installation procedures Documented developer change-control procedures for software modifications reviewed:
Modified p. 26
Documentation detailing the impact of all changes included in the relevant application release Instructions detailing back-out or de-installation procedures for the application Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-1.3.b:
• Documentation detailing the impact of all changes included in the relevant application release • Instructions detailing back-out or de-installation procedures for the application Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-1.3.b:
Modified p. 27
 Developing with least privilege.  Developing with fail-safe exception handling.  Developing with defensive (protective) techniques regarding the logical input interfaces of the application. 2B-1.4 Examine software development processes and interview software developers to verify that secure coding techniques are defined and include:
• Developing with defensive (protective) techniques regarding the logical input interfaces of the application. 2B-1.4 Examine software development processes and interview software developers to verify that secure coding techniques are defined and include:
Modified p. 27
 Developing with least privilege.  Developing with fail-safe defaults.  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.
Modified p. 28
Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries. Assessment of application decision points, process flows, data flows, data storage, and trust boundaries. Identification of all areas within 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 …
• Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries. • Assessment of application decision points, process flows, data flows, data storage, and trust boundaries. • Identification of all areas within applications that interact with account data, as well as any process-oriented outcomes that could lead to the exposure of account data. • A list of potential threats and vulnerabilities resulting from account-data flow analyses, and assigned risk ratings …
Modified p. 28
Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries. Assessment of application decision points, process flows, data flows, data storage, and trust boundaries. Identification of all areas within applications that interact with account data, as well as any process-oriented outcomes that could lead to the exposure of account data. A list of potential threats and vulnerabilities resulting from account-data flow analyses, and assigned risk ratings …
• Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries. • Assessment of application decision points, process flows, data flows, data storage, and trust boundaries. • Identification of all areas within 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 …
Modified p. 29
 Secure application design.  Secure coding techniques to avoid common coding vulnerabilities (e.g., vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.).  Managing sensitive data in memory.  Code reviews.  Security testing (e.g., penetration testing techniques).  Risk-assessment techniques. Note: Training for application developers may be provided in-house or by third parties. Examples of how training may be delivered include on-the-job, instructor- led, and computer-based. 2B-1.5.a Verify documented software development processes require training …
• Risk-assessment techniques. Note: Training for application developers may be provided in-house or by third parties. Examples of how training may be delivered include on-the-job, instructor- led, and computer-based. 2B-1.5.a Verify documented software development processes require training in secure development practices for application developers, as applicable for the developer’s job function and technology used.
Modified p. 30
 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. Note: Wildcards may only be substituted …
• Definition of elements that indicate use of wildcards. Note: Wildcards may only be substituted for elements of the version number that represent non-security impacting changes. Refer to 2B-6.3 for additional requirements on the use of wildcards. 2B-1.7.1.a Examine recent application changes, the version numbers assigned, and the change control documentation that specifies the type of application change and verify that the elements in the version number match the applicable change and the parameters defined in the documented versioning methodology.
Modified p. 30
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:
• Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application).
Modified p. 30
• Have impact to any security functionality or P2PE requirement.  How each type of change ties to a specific version number.
• Have impact to any security functionality or P2PE requirement.
Modified p. 31
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:
• 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. 31
• 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.
Modified p. 31 → 32
 Details of how wildcards are used in the versioning methodology.  Wildcards are never used for any change that has an impact on the security of the application and/or the POI device. Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change.  Wildcard elements must not precede version elements that could represent security-impacting changes. Any version elements that appear after a …
• Wildcards are never used for any change that has an impact on the security of the application and/or the POI device. • Any element of the version number used to represent a non-security- impacting change (including a wildcard element) must never be used to represent a security impacting change. • Any elements to the right of a wildcard cannot be used for a security- impacting change. Version elements reflecting a security-impacting change must appear “to the left of” the …
Modified p. 32 → 31
Details of how wildcards are used in the versioning methodology. Wildcards are never used for any change that has an impact on the security of the application and/or the POI device. Any element of the version number used to represent a non-security- impacting change (including a wildcard element) must never be used to represent a security impacting change. Any elements to the right of a wildcard cannot be used for a security- impacting change. Version elements …
• Details of how wildcards are used in the versioning methodology. • Wildcards are never used for any change that has an impact on the security of the application and/or the POI device. • Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change. • Wildcard elements must not precede version elements that could represent security-impacting changes. Any version elements that appear after a …
Modified p. 32
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.
Modified p. 32
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.
• 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.
Modified p. 33
 Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.)  Details of how security-impacting changes will be indicated by the version scheme  Details of how other types of changes will affect the version  Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security-impacting change Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details …
• Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security-impacting change Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-1.10:
Modified p. 33
 Signature by an authorized party to formally approve release of the application or application update.  Confirmation that secure development processes were followed by the vendor. 2B-1.13.a Examine documented processes to verify that final release of the application and any application updates are formally approved and documented, including a signature by an authorized party to formally approve the release and confirmation that all SDLC processes were followed.
• Confirmation that secure development processes were followed by the vendor. 2B-1.13.a Examine documented processes to verify that final release of the application and any application updates are formally approved and documented, including a signature by an authorized party to formally approve the release and confirmation that all SDLC processes were followed.
Modified p. 34
 Formal approval and signature by an authorized party.  Confirmation that that all secure development processes were followed.
• Confirmation that that all secure development processes were followed.
Modified p. 34
Any instructions on how to securely configure any configurable options, as applicable to the application’s specific business processing Any guidance that the POI device vendor intended for integrators/ resellers, solution providers, and/or end-users Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-2.1.b:
• Any instructions on how to securely configure any configurable options, as applicable to the application’s specific business processing • Any guidance that the POI device vendor intended for integrators/ resellers, solution providers, and/or end-users Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-2.1.b:
Modified p. 34
 Link Layer protocols  IP protocols  Security protocols  IP services Note: The PTS POI Open Protocols module ensures that open protocols and services in POI devices do not have vulnerabilities that can be remotely exploited and yield access to sensitive data or resources in the device. The POI device vendor defines what protocols and services are supported by the device and provides guidance to their use. Adding or enabling additional services or protocols, or failing to follow …
• IP services Note: The PTS POI Open Protocols module ensures that open protocols and services in POI devices do not have vulnerabilities that can be remotely exploited and yield access to sensitive data or resources in the device. The POI device vendor defines what protocols and services are supported by the device and provides guidance to their use. Adding or enabling additional services or protocols, or failing to follow the issued POI device vendor’s security guidance will invalidate the …
Modified p. 35
 Was developed according to the POI device vendor’s security guidance with respect to the documented Open Protocols.  Does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI device's vendor security guidance. This includes the use of: o Link Layer protocols o IP protocols o Security protocols o IP services Describe how the source-code review verified that the application was developed according to …
• Does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI device's vendor security guidance. This includes the use of: o Link Layer protocols o IP protocols o Security protocols o IP services Describe how the source-code review verified that the application was developed according to the POI device vendor’s security guidance with respect to the documented Open Protocols: <Report Findings Here> Describe how …
Modified p. 35
 A list of shared resources.  A description of how the application connects to and/or uses shared resources. Instructions for how the application should be configured to ensure secure integration with shared resources.
• A description of how the application connects to and/or uses shared resources. • Instructions for how the application should be configured to ensure secure integration with shared resources.
Modified p. 37
Confirmation that the application does not perform encryption of clear-text account-data, nor does it replace the POI device’s SRED encryption A description of the purpose and encryption method for any encryption provided by the application in addition to SRED encryption Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-4.1.a:
• Confirmation that the application does not perform encryption of clear-text account-data, nor does it replace the POI device’s SRED encryption • A description of the purpose and encryption method for any encryption provided by the application in addition to SRED encryption Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-4.1.a:
Modified p. 38
Using outside sources for security vulnerability information.  Periodic testing of applications for new vulnerabilities.
• Using outside sources for security vulnerability information.
Modified p. 38
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.
Modified p. 38
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.
Modified p. 39
 Instructions for how to sign the application.  Instructions how to implement the dual control for the application-signing process. A statement that all applications must be signed via the instructions provided in the Implementation Guide.
• Instructions how to implement the dual control for the application-signing process. • A statement that all applications must be signed via the instructions provided in the Implementation Guide.
Modified p. 40
 Any changes to the application (e.g., device changes/upgrades and major and minor software changes).  Any changes to the Implementation Guide requirements in this document. 2C-3.1.2.a Verify the Implementation Guide is reviewed at least annually and upon changes to the application or the P2PE Domain 2 requirements.
• Any changes to the Implementation Guide requirements in this document. 2C-3.1.2.a Verify the Implementation Guide is reviewed at least annually and upon changes to the application or the P2PE Domain 2 requirements.
Modified p. 40
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.