Document Diff - PCI Watch

Added p. 2

July 2014 PCI DSS 3.0, Revision 1.1 Errata

• Minor edits made to address typos and general errors, slight addition of content

Added p. 12

• Identify the types of transactions

• List any specific payment acceptance channels (for example, card present and card not present) the application is designed for

• Describe how the application stores, processes, or transmits cardholder data as part of authorization or settlement

• Describe how the payment application is sold, distributed, or licensed to third parties

Added p. 20

• LAN, WAN or Internet connections

• Host to host software communications

• Communications internal to the host

• Boundaries between trusted and untrusted components

• Connection methods and communication protocol

• Authorization (yes/no)

• Settlement (yes/no)

Added p. 27

• The accountholder’s name,

• Primary account number (PAN),

• Expiration date, and

Added p. 28

• Incoming transaction data

Added p. 28

• Database contents Identify the test transactions observed for this testing procedure.

Aligns with PCI DSS Requirement 3.2.2 1.1.2 Install the payment application and perform numerous test transactions that simulate all Identify the test transactions observed for this testing procedure.

• Incoming transaction data

• Incoming transaction data Identify the test transactions observed for this testing procedure.

• How to remove historical data.

• That such removal is absolutely necessary for PCI DSS compliance.

• Collection of sensitive authentication data only when needed to solve a specific problem

• Storage of such data in a specific, known location with limited access

• Collection of only a limited amount of data needed to solve a specific problem

• Encryption of sensitive authentication data while stored

Added p. 35

• Details of all instances where PAN is displayed, including but not limited to POS devices, screens, logs, and receipts.

• Confirmation that the payment application masks PAN by default on all displays

Added p. 37

• A list of all instances where cardholder data may be output for the customer to store outside of the payment application, and instructions that the customer is responsible for rendering PAN unreadable in all such instances.

• One-way hashes based on strong cryptography.

Added p. 38

• One-way hashes based on strong cryptography

• One-way hashes based on strong cryptography

• Strong cryptography, with associated key-management processes and procedures <Report Findings Here> 2.3.c If the application creates both hashed and truncated versions of the same PAN, examine methods for creating the hashed and truncated versions to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

Indicate whether the application creates both hashed and truncated versions of the same PAN. (yes/no) <Report Findings Here> If yes, describe the methods for created the hashed and truncated versions that were examined to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

• Keys are stored in encrypted format.

• Key-encrypting keys are stored separately from data-encrypting keys.

• Store keys securely in the fewest possible locations and forms.

• A sample Key Custodian form for key custodians to acknowledge that they understand and accept …

Added p. 49

• Advised that, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.

• Advised to assign secure authentication to all default accounts in the environment.

• For any default accounts that won’t be used, assign secure authentication and then disable or do not use that accounts.

• Something you know, such as a password or passphrase

• Something you have, such as a token device or smart card

Added p. 52

• Generic accounts and passwords. <Report Findings Here> Describe the application functionality testing performed to verify that, upon completion of the change, the application does not rely on or use:

• Shared accounts and passwords. <Report Findings Here>

• Require a minimum length of at least seven characters

• Passwords to be at least seven characters in length. <Report Findings Here>

• Passwords to be at least seven characters in length. <Report Findings Here>

Added p. 58

• A unique input variable is concatenated with each password before the cryptographic algorithm is applied.

• A unique input variable is concatenated with each password before the cryptographic algorithm is applied.

• All application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account.

• All application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account.

Added p. 60

• All application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

• How to install the application so that logs are configured and enabled by default upon completion of the installation process.

• How to set PCI DSS-compliant log settings, per PA-DSS Requirements 4.2, 4.3 and 4.4 below, for any logging options that are configurable by the customer after installation.

• Logs should not be disabled and doing so will result in non-compliance with PCI DSS.

• How to configure PCI DSS-compliant log settings for any third-party software components packaged with or required by the payment application, for any logging options that are configurable by the customer after installation.

Added p. 62

<Report Findings Here> 4.2.2 All actions taken by any individual with administrative privileges as assigned in the application ☐ ☐ ☐ 4.2.2 Verify actions taken by any individual with administrative privileges to the payment application are logged.

Added p. 66

• Logging via industry standard log file mechanisms such as Common Log File System (CLFS), Syslog, delimited text, etc.

• A description of which centralized logging mechanisms are supported.

• Incorporating information security throughout the software development life cycle.

• Incorporating information security throughout the software-development life cycle.

• Developing payment applications in accordance with PCI DSS Requirements.

• Developing payment applications in accordance with PA-DSS Requirements.

• Defined security reviews prior to release of an application or application update.

• Defined security reviews during the development process and prior to release of an application or application update.

Added p. 68

• Payment applications are developed in accordance with PCI DSS and PA-DSS Requirements.

• Security reviews are performed prior to release, to ensure that security objectives, including PCI DSS and PA-DSS requirements, are being met.

• Security reviews are performed prior to release, to ensure that security objectives, including PCI DSS and PA-DSS requirements, are being met.

• Payment applications are developed in accordance with PCI DSS Requirements.

• Payment applications are developed in accordance with PA-DSS Requirements.

• Procedures to ensure live PANs are not used for testing.

Added p. 71

• Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code-review techniques and secure coding practices.

• Code reviews ensure code is developed according to secure coding guidelines. (See PA-DSS Requirement 5.2.)

Added p. 71

• Code-review results are reviewed and approved by management prior to release.

• Code-review results are documented including management approval, code author and code reviewer and what Indicate whether the vendor uses a manual or automated process to perform code reviews for all significant application code changes. (manual/automated) <Report Findings Here> Identify the documented software-development processes reviewed and verified to include procedures for the following:

• Code changes are reviewed by individuals other than the originating code author.

• Code changes are reviewed by individuals who are knowledgeable in code review techniques.

• Code changes are reviewed by individuals who are knowledgeable in secure coding practices.

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

• Code-review results are reviewed by management prior to release.

• Code-review results are approved by management prior to release.

• Code changes are reviewed by individuals other than the originating code author.

• Code changes are reviewed by individuals who …

Added p. 73

• Developing with fail-safe defaults (all execution is by default denied unless specified within initial design).

• Developing with fail-safe defaults (all execution is by default denied unless specified within initial design).

• Developing with fail-safe default (all execution is by default denied unless specified within initial design).

• Developing with fail-safe default (all execution is by default denied unless specified within initial design).

• Secure application design

• Managing sensitive data in memory

• Security testing (for example, penetration-testing techniques)

• Risk-assessment techniques

• Utilizing parameterized queries.

• Truncating input strings.

• Prevent cryptographic flaws.

• Use strong cryptographic algorithms and keys.

 Use strong cryptographic algorithms and keys. <Report Findings Here> 5.2.4 Insecure communications ☐ ☐ ☐ 5.2.4 Insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications.

 Validating all parameters before inclusion. <Report Findings Here>  Utilizing context-sensitive escaping. <Report Findings Here> 5.2.8 Improper access control such as insecure direct object references, failure to …

Added p. 87

• 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 recent payment application changes examined. <Report Findings Here> Describe how examination of recent changes verified that internal version mapping to published versioning scheme is updated in accordance with the type of change, as defined in the documented methodology.

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

Added p. 88

• A list of potential threats and vulnerabilities resulting from cardholder data-flow analyses, and assign risk ratings (e.g., high, medium, or low priority) to each.

• A list of potential threats and vulnerabilities resulting from cardholder data-flow analyses, and assign risk ratings (e.g., high, medium, or low priority) to each.

• Confirmation that secure development processes were followed by the vendor.

• Confirmation that all SDLC processes were followed.

• Formal approval and signature by an authorized party.

• Confirmation that that all secure development processes were followed.

• The payment application enforces changes of default encryption keys, passwords and SNMP community strings at installation for all wireless components controlled by the application.

• Procedures for changing wireless encryption keys and passwords, including SNMP strings, anytime anyone with knowledge of the keys/passwords leaves the company or changes positions.

• Instructions for changing default encryption keys, passwords and SNMP community strings on any wireless components provided with, but not …

Added p. 92

• Encryption keys were

• changed from default at installation.

• changed at installation.

• changed at installation.

• Default passwords/passphrases on access points were

• Firmware on wireless devices is

• updated to support strong encryption for authentication and transmission over wireless networks.

• Other security-related wireless vendor defaults were changed, if applicable.

• Change of wireless encryption keys

• Change of passwords/passphrases

• Change of wireless encryption keys

• Change of passwords/passphrases

• How to configure the application to use industry best practices (for example, IEEE 802.11.i) for strong encryption for authentication and transmission, and/or

• How to configure all wireless applications bundled with the payment application to use industry best practices for strong encryption for authentication and transmission.

• Instructions to change all wireless default encryption keys, passwords and SNMP community strings upon installation.

• Instructions to change wireless encryption keys, passwords and SNMP strings anytime anyone with knowledge of the keys/passwords leaves the company or changes positions.

• Instructions to install a …

Added p. 98

• Patches and updates are delivered to customers in a secure manner with a known chain of trust.

• or interfere with the operation of other PCI DSS functions.

• Something you know, such as a password or passphrase

• Something you have, such as a token device or smart card

Added p. 104

• Instructions on how to configure the payment application to use a DMZ to separate the Internet from systems storing cardholder data (for example, installing a web server component in a DMZ and installing a data storage component on an internal different network zone).

• A list of services/ports that the application needs to use in order to communicate across two network zones (so the customer can configure their firewall to open only required ports).

• A description of two-factor authentication mechanisms supported by the application.

• Instructions for configuring the application to support two-factor authentication (two of the three authentication methods described in PA DSS Requirement 3.1.4).

Added p. 107

• Activation of remote-access technologies to customer networks only when needed and immediate deactivation after use.

• If remote access is via VPN or other high- speed connection, the connection is secured according to PCI DSS Requirement 1.

• Change default settings in the remote- access software (for example, change default passwords and use unique passwords for each customer).

• Allow connections only from specific (known) IP/MAC addresses.

• Use strong authentication and complex passwords for logins (See PA-DSS Requirements 3.1.1 through 3.1.11)

• Enable account lockout after a certain number of failed login attempts (See PA- DSS Requirement 3.1.9 through 3.1.10)

• Establish a VPN connection via a firewall before access is allowed.

• Enable the logging function.

• Restrict access to customer environments to authorized personnel.

<Report Findings Here> Describe the software vendor’s remote-access methods observed verify that remote access is implemented securely.

• Only trusted keys and certificates are accepted.

• The protocol in use only supports secure …

Added p. 112

• The protocol is implemented by default to not allow fallback to an insecure version or configuration (e.g. if TLS is used, the application must not allow fallback to SSL).

• Proper encryption strength is implemented for the encryption methodology in use.

 The protocol is implemented by default to not allow fallback to an insecure version or configuration (e.g. if TLS is used, the application must not allow fallback to SSL).

• Renders the PAN unreadable; OR <Report Findings Here>

• Procedures for using the defined solution to render the PAN unreadable or secure the PAN with strong cryptography.

• Clear-text protocols such as Telnet or rlogin must never be used for administrative access.

• SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of, SSL or early TLS. Applications that use or support TLS must not allow fallback to SSL.

Aligns with PCI DSS Requirement 2.3 …

Added p. 116

• The PA-DSS Implementation Guide is disseminated to all customers, resellers, and integrators with the application.

<Report Findings Here> 13.1.1 Provides relevant information specific to the application for customers, resellers, and integrators to use. ☐ ☐ ☐ 13.1.1 Examine the PA-DSS Implementation Guide and verify it:

• Clearly identifies the payment application name and version to which it applies.

• Upon changes to the application

• Upon changes to the application

• At least annually <Report Findings Here>

• Upon changes to the application <Report Findings Here>

• Upon changes to these PA-DSS requirements <Report Findings Here> Identify the personnel interviewed for this testing procedure who confirm the PA-DSS Implementation Guide is reviewed

• Changes to the PA-DSS requirements.

• Provide updated versions as needed.

 Receive training in PA-DSS at least annually. <Report Findings Here>  Receive training in information security at least annually. <Report Findings Here> Identify the personnel interviewed for this testing procedure. <Report Findings Here> For …

Removed p. 2

July 2014 1.1 Errata

• Minor edits made to address typos and general errors, slight addition of content

Modified p. 2

January 2014 ~~1.0~~ To introduce the template for submitting Reports on Validation.

January 2014 PCI DSS 3.0, Revision1.0 To introduce the template for submitting Reports on Validation.

Modified p. 5

Use of this Reporting Template is mandatory for all ~~v3.0 submissions; however, it may NOT be used for 2.0~~ submissions. ~~Refer to the ROV Reporting Instructions for PA-DSS v2.0 for guidance on completing 2.0 submissions.~~

Use of this Reporting Template is mandatory for all v3.1 submissions.

Modified p. 5

Do not delete any content from any place in this document, including this section and the versioning above. These instructions are important for the assessor as the report is written and for the recipient in understanding the context the responses and conclusions are made. Addition of text or sections is applicable within reason, as noted above. Refer to the ~~“ROV~~ Reporting Template for PA-DSS ~~v3.0: Frequently Asked Questions (FAQs)”~~ document on the PCI SSC website for further guidance.

Do not delete any content from any place in this document, including this section and the versioning above. These instructions are important for the assessor as the report is written and for the recipient in understanding the context the responses and conclusions are made. Addition of text or sections is applicable within reason, as noted above. Refer to the “Frequently Asked Questions for use with ROV Reporting Template for PA-DSS v3” document on the PCI SSC website for further guidance.

Modified p. 5

A PA-DSS 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 ROV is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor performed the validation activities and how …

Modified p. 6

Refer to the ~~“ROV~~ Reporting Template for PCI DSS ~~v3.0: Frequently Asked Questions (FAQs)”~~ document on the PCI SSC website for further guidance.

Refer to the “Frequently Asked Questions for use with ROV Reporting Template for PCI DSS v3” document on the PCI SSC website for further guidance.

Modified p. 7

Assessor’s Response Summary of Findings (check one) ~~Not Applicable~~ 1.1 Sample sub-requirement 1.1.a Sample testing procedure  Reporting Instruction <Report Findings Here> 1.1.b Sample testing procedure  Reporting Instruction <Report Findings Here>

PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 1.1 Sample sub-requirement ☐ ☐ ☐ 1.1.a Sample testing procedure Reporting Instruction <Report Findings Here> 1.1.b Sample testing procedure Reporting Instruction <Report Findings Here>

Modified p. 8

 One word (yes/no) Example Reporting Instruction: ~~Identify~~ whether the payment application stores sensitive data after authorization. (yes/no)  Document name or interviewee reference (at 2.7 Documentation Reviewed and 2.8 Individuals Interviewed, there is a space for a reference number and it is the PA-QSA’s choice to use the document name/interviewee job title or the reference number in responses) Example Reporting Instruction: Identify the document that defines vendor software development processes.

 One word (yes/no) Example Reporting Instruction: Indicate whether the payment application stores sensitive data after authorization. (yes/no)  Document name or interviewee reference (at 2.7 Documentation Reviewed and 2.8 Individuals Interviewed, there is a space for a reference number and it is the PA-QSA’s choice to use the document name/interviewee job title or the reference number in responses) Example Reporting Instruction: Identify the document that defines vendor software development processes.

Modified p. 8

The Implementation Guide must be specific to each application and provide instructions on how to implement the application in a PCI DSS compliant manner. It is not sufficient for the Implementation Guide to simply reiterate requirements from the PA-DSS and PCI DSS, and the testing procedures have been made stronger in ~~3.0~~ to give greater assurance that the guidance is accurate and effective.

The Implementation Guide must be specific to each application and provide instructions on how to implement the application in a PCI DSS compliant manner. It is not sufficient for the Implementation Guide to simply reiterate requirements from the PA-DSS and PCI DSS, and the testing procedures have been made stronger in version 3 to give greater assurance that the guidance is accurate and effective.

Modified p. 9

 Use this Reporting Template, if assessing against ~~v3.0~~ of the PA- DSS.

 Use this Reporting Template, if assessing against v3.1 of the PA- DSS.

Modified p. 11

 Describe efforts made to ensure no conflict of interest resulted above mentioned services provided by the PA-QSA/QSAC:

 Describe efforts made to ensure no conflict of interest resulted from the above mentioned services provided by the PA-QSA/QSAC:

Modified p. 12

 The type of application (for example, POS terminal, payment switch, shopping cart, kiosk, etc.)  Application Use and Purpose general description  Identify the types of transactions  List any specific payment acceptance channels (for example, card present and card not present) the application is designed for  Describe how the application stores, processes, or transmits cardholder data as part of authorization or settlement  Describe how the payment application is sold, distributed, or licensed to third parties

 The type of application (for example, POS terminal, payment switch, shopping cart, kiosk, etc.)  Application Use and Purpose general description

Modified p. 15

 The customer is clearly instructed how to implement the payment application in a PCI DSS compliant manner.

• The customer is clearly instructed how to implement the payment application in a PCI DSS compliant manner.

Modified p. 15

 The customer is clearly instructed that certain payment application and environment settings may prohibit their PCI DSS compliance.

• The customer is clearly instructed that certain payment application and environment settings may prohibit their PCI DSS compliance.

Modified p. 15

 Appropriate and accurate guidance is provided even when a specific setting cannot be controlled by the payment application vendor once the application is installed by the customer.

• Appropriate and accurate guidance is provided even when a specific setting cannot be controlled by the payment application vendor once the application is installed by the customer.

Modified p. 15

 Appropriate and accurate guidance is provided even when a specific setting is the responsibility of the customer, not the payment application vendor.

• Appropriate and accurate guidance is provided even when a specific setting is the responsibility of the customer, not the payment application vendor.

Modified p. 17

 Software vendor name:

• Software vendor name:

Modified p. 17

 Product version: (Only one version can be included per submission)  Provide a description of the payment application, including a description of the family of products.

• Product version: (Only one version can be included per submission)  Provide a description of the payment application, including a description of the family of products.

Modified p. 19

 Connections into and out of a customer’s network  All connections into and out of the network  All connections between the payment application and other applications, systems, networks or zones  Components within the customer’s network, including POS devices, systems, databases, and web servers as applicable  All critical components and systems, as well as their locations and the boundaries between them, including POS devices, systems, databases, web servers, and other components as applicable  Other necessary payment …

 Connections into and out of a customer’s network • All connections into and out of the network • All connections between the payment application and other applications, systems, networks or zones  Components within the customer’s network, including POS devices, systems, databases, and web servers as applicable • All critical components and systems, as well as their locations and the boundaries between them, including POS devices, systems, databases, web servers, and other components as applicable  Other necessary payment …

Modified p. 20

~~ LAN, WAN or Internet connections  Host to host software communications  Communications internal to the host ~~ All other connection points applicable to the assessment  Next, provide brief descriptions to illustrate each communication point:

• All other connection points applicable to the assessment  Next, provide brief descriptions to illustrate each communication point:

Modified p. 20

 Identification of the communication endpoints (for example, POS terminal, database server, same-host reporting application, etc.) ~~ Boundaries between trusted and untrusted components  Connection methods and communication protocol~~

• Identification of the communication endpoints (for example, POS terminal, database server, same-host reporting application, etc.)

Modified p. 21

~~ Authorization (yes/no)  Capture (yes/no)  Settlement (yes/no) ~~ Chargeback (yes/no)  List any other data flows present, as applicable:

• Chargeback (yes/no)  List any other data flows present, as applicable:

Modified p. 21

 Describe how cardholder data is transmitted, processed and/or stored.

• Describe how cardholder data is transmitted, processed and/or stored.

Modified p. 21

 Identify the types of cardholder data involved (for example, full track, PAN, expiry date, etc.).

• Identify the types of cardholder data involved (for example, full track, PAN, expiry date, etc.).

Modified p. 21

 Describe any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to the cardholder data.

• Describe any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to the cardholder data.

Modified p. 21

 Identify the components involved in the transmission, processing or storage of cardholder data.

• Identify the components involved in the transmission, processing or storage of cardholder data.

Modified p. 21

 Include all types of data flows, including any involving hard copy / paper media.

• Include all types of data flows, including any involving hard copy / paper media.

Modified p. 24

 Describe the format of the version scheme, such as number of elements, number of digits used for each element, format of separators used between elements and character set used for each element (consisting of alphabetic, numeric and/or alphanumeric characters)  Describe the hierarchy of the elements:

• Describe the format of the version scheme, such as number of elements, number of digits used for each element, format of separators used between elements and character set used for each element (consisting of alphabetic, numeric and/or alphanumeric characters)  Describe the hierarchy of the elements:

Modified p. 24

 Define what each element represents in the version scheme.

• Define what each element represents in the version scheme.

Modified p. 24

 If wildcards are used in the versioning methodology, describe how wildcards are used. Note: All changes impacting security functionality and/or any PA-DSS requirements must result in a change to the version number listed on the PCI SSC website; wildcards are not permitted for changes which impact security functionality and/or any PA-DSS requirements.

• If wildcards are used in the versioning methodology, describe how wildcards are used. Note: All changes impacting security functionality and/or any PA-DSS requirements must result in a change to the version number listed on the PCI SSC website; wildcards are not permitted for changes which impact security functionality and/or any PA-DSS requirements.

Removed p. 26

Assessor’s Response Summary of Findings (check one) Not Applicable 1.1 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

 Identify whether the payment application stores sensitive authentication data (SAD) after authorization (yes/no) If “no,” proceed to 1.1.b.

Modified p. 26

Requirement 1: Do not retain full track data, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data PA-DSS Requirements and Testing Procedures Reporting Instruction ~~ROV~~ Reporting Details:

Requirement 1: Do not retain full track data, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 1.1 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

Modified p. 26

<Report Findings Here>  If “yes,” describe how it was verified that the application is only intended for use by issuers and/or companies that support issuing services.

Indicate whether the payment application stores sensitive authentication data (SAD) after authorization (yes/no) <Report Findings Here> If “yes,” describe how it was verified that the application is only intended for use by issuers and/or companies that support issuing services.

Modified p. 26

 If “no” at 1.1.a, ~~identify~~ whether the payment application stores sensitive authentication data prior to authorization. (yes/no) <Report Findings Here>  Identify the document that defines the methodology for deleting the data such that the data is unrecoverable.

If “no” at 1.1.a, indicate whether the payment application stores sensitive authentication data prior to authorization. (yes/no) <Report Findings Here> Identify the document that defines the methodology for deleting the data such that the data is unrecoverable.

Modified p. 26

<Report Findings Here>  Describe how the documented methodology was tested to confirm that that the data is unrecoverable.

<Report Findings Here> Describe how the documented methodology was tested to confirm that that the data is unrecoverable.

Modified p. 26

<Report Findings Here>  Describe the testing performed to confirm that SAD is not stored by the application.

<Report Findings Here> Describe the testing performed to confirm that SAD is not stored by the application.

Removed p. 27

Assessor’s Response Summary of Findings (check one) Not Applicable 1.1.1 After authorization, do not store the full contents of any track from the magnetic stripe (located on the back of a card, equivalent data contained on a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

Modified p. 27

~~ The accountholder’s name,  Primary account number (PAN),  Expiration date, and ~~ Service code To minimize risk, store only those data elements needed for business.

• Service code To minimize risk, store only those data elements needed for business.

Modified p. 28

<Report Findings Here>  Describe how test transactions observed simulate all functions of the payment application, including generation of error conditions and log entries.

<Report Findings Here> Describe how test transactions observed simulate all functions of the payment application, including generation of error conditions and log entries.

Modified p. 28

<Report Findings Here>  Identify forensic tools and/or methods (commercial tools, scripts, etc.) used to examine all output created by the payment application to verify that the full contents of any track from the magnetic stripe on the back of the card or equivalent data on a chip are not stored after authorization.

<Report Findings Here> Identify forensic tools and/or methods (commercial tools, scripts, etc.) used to examine all output created by the payment application to verify that the full contents of any track from the magnetic stripe on the back of the card or equivalent data on a chip are not stored after authorization.

Modified p. 28

 Incoming transaction data <Report Findings Here>  All logs (for example, transaction, history, debugging error) <Report Findings Here>  History files <Report Findings Here>  Trace files <Report Findings Here>  Non-volatile memory, including ~~non- volatile~~ cache <Report Findings Here>  Database schemas <Report Findings Here> ~~1 Forensic tool or method: A tool or method for uncovering, analyzing and presenting forensic data, which provides a robust way~~ to ~~authenticate, search, and recover computer evidence rapidly and thoroughly. In the …~~

 Incoming transaction data <Report Findings Here>  All logs (for example, transaction, history, debugging error) <Report Findings Here>  History files <Report Findings Here>  Trace files <Report Findings Here>  Non-volatile memory, including non-volatile cache <Report Findings Here>  Database schemas <Report Findings Here>  Database contents <Report Findings Here>  If applicable, any other output observed to be generated by the payment application <Report Findings Here> 1.1.2 After authorization, do not store the card verification value or …

Removed p. 29

Assessor’s Response Summary of Findings (check one) Not Applicable  Database contents <Report Findings Here>  If applicable, any other output observed to be generated by the payment application <Report Findings Here> 1.1.2 After authorization, do not store the card verification value or code (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.

Modified p. 29

~~<Report Findings Here> ~~ Describe how test transactions observed simulate all functions of the payment application, including generation of error conditions and log entries.

• Database contents Describe how test transactions observed simulate all functions of the payment application, including generation of error conditions and log entries.

Modified p. 29

<Report Findings Here>  Identify forensic tools and/or methods (commercial tools, scripts, etc.) used to examine all output created by the payment application to verify that the three-digit or four-digit card-validation code printed on the card (CVV2, CVC2, CID, CAV2 data) is not stored after authorization.

<Report Findings Here> Identify forensic tools and/or methods (commercial tools, scripts, etc.) used to examine all output created by the payment application to verify that the three-digit or four-digit card-validation code printed on the card (CVV2, CVC2, CID, CAV2 data) is not stored after authorization.

Modified p. 29

 Incoming transaction data <Report Findings Here>  All logs (for example, transaction, history, debugging error) <Report Findings Here>  History files <Report Findings Here>  Trace files <Report Findings Here>  Non-volatile memory, including ~~non- volatile~~ cache <Report Findings Here>

 Incoming transaction data <Report Findings Here>  All logs (for example, transaction, history, debugging error) <Report Findings Here>  History files <Report Findings Here>  Trace files <Report Findings Here>  Non-volatile memory, including non-volatile cache <Report Findings Here>  Database schemas <Report Findings Here>  Database contents <Report Findings Here>  If applicable, any other output observed to be generated by the payment application <Report Findings Here> 1.1.3 After authorization, do not store the personal identification number (PIN) …

Removed p. 30

Assessor’s Response Summary of Findings (check one) Not Applicable  Database schemas <Report Findings Here>  Database contents <Report Findings Here>  If applicable, any other output observed to be generated by the payment application <Report Findings Here> 1.1.3 After authorization, do not store the personal identification number (PIN) or the encrypted PIN block.

Modified p. 30 → 29

<Report Findings Here>  Describe how test transactions observed simulate all functions of the payment application, including generation of error conditions and log entries.

<Report Findings Here> Describe how test transactions observed simulate all functions of the payment application, including generation of error conditions and log entries.

Modified p. 30 → 29

<Report Findings Here>  Identify forensic tools and/or methods (commercial tools, scripts, etc.) used to examine all output created by the payment application to verify that the personal identification number (PIN) or the encrypted PIN block is not stored after authorization.

<Report Findings Here> Identify forensic tools and/or methods (commercial tools, scripts, etc.) used to examine all output created by the payment application to verify that the personal identification number (PIN) or the encrypted PIN block is not stored after authorization.

Modified p. 30

~~<Report Findings Here>~~ For each data source type below, summarize the specific examples of each data source type observed to confirm that PIN or encrypted PIN block is never stored after authorization. If that type of data source is not present, indicate that in the space.

• Database contents For each data source type below, summarize the specific examples of each data source type observed to confirm that PIN or encrypted PIN block is never stored after authorization. If that type of data source is not present, indicate that in the space.

Modified p. 30

 Incoming transaction data <Report Findings Here>  All logs (for example, transaction, history, debugging error) <Report Findings Here>  History files <Report Findings Here>  Trace files <Report Findings Here>  Non-volatile memory, including ~~non- volatile~~ cache <Report Findings Here>

 Incoming transaction data <Report Findings Here>  All logs (for example, transaction, history, debugging error) <Report Findings Here>  History files <Report Findings Here>  Trace files <Report Findings Here>  Non-volatile memory, including non-volatile cache <Report Findings Here>  Database schemas <Report Findings Here>  Database contents <Report Findings Here>  If applicable, any other output observed to be generated by the payment application <Report Findings Here> 1.1.4 Securely delete any track data (from the magnetic stripe or …

Removed p. 31

Assessor’s Response Summary of Findings (check one) Not Applicable  Database schemas <Report Findings Here>  Database contents <Report Findings Here>  If applicable, any other output observed to be generated by the payment application <Report Findings Here> 1.1.4 Securely delete any track data (from the magnetic stripe or equivalent data contained on a chip), card verification values or codes, and PINs or PIN block data stored by previous versions of the payment application, in accordance with industry-accepted standards for secure deletion, as defined, for example by the list of approved products maintained by the National Security Agency, or by other State or National standards or regulations.

Modified p. 31 → 30

 Historical data must be removed (track data, card verification codes, PINs, or PIN blocks stored by previous versions of the payment application). ~~ How to remove historical data.  That such removal is absolutely necessary for PCI DSS compliance.~~

• Historical data must be removed (track data, card verification codes, PINs, or PIN blocks stored by previous versions of the payment application).

Modified p. 31 → 30

~~(continued on next page)  Identify~~ whether any previous version of the payment application stored magnetic stripe data, card validation values or codes, and/or PINs or PIN block data. (yes/no) <Report Findings Here> ~~ Describe~~ how it was verified that prior versions do not store magnetic stripe data, card validation values or codes, and/or PINs or PIN block data.

Indicate whether any previous version of the payment application stored magnetic stripe data, card validation values or codes, and/or PINs or PIN block data. (yes/no) <Report Findings Here> If “no,” describe how it was verified that prior versions do not store magnetic stripe data, card validation values or codes, and/or PINs or PIN block data.

Modified p. 31 → 30

<Report Findings Here> ~~Identify~~ the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

<Report Findings Here> If “yes,” identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Modified p. 31 → 30

<Report Findings Here>  Detailed procedures for removing historical data.

<Report Findings Here>  Detailed procedures for removing historical data. <Report Findings Here>

Removed p. 32

Assessor’s Response Summary of Findings (check one) Not Applicable  That such removal is absolutely necessary for PCI DSS compliance.

Modified p. 32 → 31

~~ Describe~~ the secure wipe tool or procedure the vendor provides to remove the data.

Identify the secure wipe tool or procedure the vendor provides to remove the data.

Modified p. 32 → 31

<Report Findings Here>  Identify the payment application software files reviewed to verify the vendor provides a secure wipe tool or procedure to remove the data.

<Report Findings Here> Identify the payment application software files reviewed to verify the vendor provides a secure wipe tool or procedure to remove the data.

Modified p. 32 → 31

<Report Findings Here>  Identify the configuration documentation reviewed to verify the vendor provides a secure wipe tool or procedure to remove the data.

<Report Findings Here> Identify the configuration documentation reviewed to verify the vendor provides a secure wipe tool or procedure to remove the data.

Modified p. 32 → 31

 Identify the forensic tools and/or methods used to verify the tool or procedure securely removes the data.

Identify the forensic tools and/or methods used to verify the tool or procedure securely removes the data.

Modified p. 32 → 31

<Report Findings Here>  Identify the industry-accepted standard(s) for secure deletion of data.

<Report Findings Here> Identify the industry-accepted standard(s) for secure deletion of data.

Modified p. 32 → 31

<Report Findings Here>  Describe how the tool or procedure was observed to verify secure removal of the data, in accordance with the ~~industry-accepted~~ standards.

<Report Findings Here> Describe how the tool or procedure was observed to verify secure removal of the data, in accordance with the industry- accepted standards.

Modified p. 32 → 31

 Sensitive authentication data is collected only when needed to solve a specific problem  Such data is stored in a specific, known location with limited access  The minimum amount of data is collected as needed to solve a specific problem  Sensitive authentication data is encrypted with strong cryptography while stored  Data is securely deleted immediately after use, including from:

• Sensitive authentication data is collected only when needed to solve a specific problem • Such data is stored in a specific, known location with limited access • The minimum amount of data is collected as needed to solve a specific problem • Sensitive authentication data is encrypted with strong cryptography while stored • Data is securely deleted immediately after use, including from:

Removed p. 33

 Collection of sensitive authentication data only when needed to solve a specific problem  Storage of such data in a specific, known location with limited access  Collection of only a limited amount of data needed to solve a specific problem  Encryption of sensitive authentication data while stored  Secure deletion of such data immediately after use (continued on next page)  Identify the document that contains the software vendor’s procedures for troubleshooting customers’ problems.

Modified p. 33 → 31

~~Assessor’s Response Summary of Findings (check one) Not Applicable~~ 1.1.5.a Examine the software vendor’s procedures for troubleshooting customers’ ~~problems and verify~~ the procedures ~~include:~~

1.1.5.a Examine the software vendor’s procedures for troubleshooting customers’ Identify the document that contains the software vendor’s procedures for troubleshooting customers’ problems.

Modified p. 33 → 32

~~<Report Findings Here>  Identify~~ whether the software vendor’s procedures for troubleshooting customers’ problems allow any collection of sensitive authentication data (pre-authorization). (yes/no) If “no,” mark the remainder of 1.1.5.a as “not applicable.” <Report Findings Here> If “yes,” briefly describe how the documented procedures for troubleshooting customers’ problems ensure the following:

• Secure deletion of such data immediately after use Indicate whether the software vendor’s procedures for troubleshooting customers’ problems allow any collection of sensitive authentication data (pre-authorization). (yes/no) If “no,” mark the remainder of 1.1.5.a as “not applicable.” <Report Findings Here> If “yes,” briefly describe how the documented procedures for troubleshooting customers’ problems ensure the following:

Modified p. 33 → 32

<Report Findings Here>  Encryption of sensitive authentication data while stored.

<Report Findings Here>  Encryption of sensitive authentication data while stored. <Report Findings Here>  Secure deletion of such data immediately after use. <Report Findings Here> 1.1.5.b Select a sample of recent troubleshooting requests from customers, and verify each event followed the procedure examined at 1.1.5.a.

Removed p. 34

Assessor’s Response Summary of Findings (check one) Not Applicable 1.1.5.b Select a sample of recent troubleshooting requests from customers, and verify each event followed the procedure examined at 1.1.5.a.

Modified p. 34 → 32

 Identify the sample of customer troubleshooting requests observed for this testing procedure.

Identify the sample of customer troubleshooting requests observed for this testing procedure.

Modified p. 34 → 32

<Report Findings Here>  If collection of SAD is prohibited for troubleshooting, describe how actual events related to the sample of recent troubleshooting requests from customers were examined to verify there is no collection of SAD.

<Report Findings Here> If collection of SAD is prohibited for troubleshooting, describe how actual events related to the sample of recent troubleshooting requests from customers were examined to verify there is no collection of SAD.

Modified p. 34 → 32

<Report Findings Here>  Encryption of sensitive authentication data while stored.

<Report Findings Here>  Encryption of sensitive authentication data while stored. <Report Findings Here>  Secure deletion of such data immediately after use. <Report Findings Here>

Modified p. 34 → 33

~~<Report Findings Here>  Secure deletion of~~ such data immediately after use.

• Securely delete such data immediately after use.

Removed p. 35

Assessor’s Response Summary of Findings (check one) Not Applicable 1.1.5.c Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and integrators/resellers:

Modified p. 35 → 33

 Collect sensitive authentication only when needed to solve a specific problem.  Store such data only in specific, known locations with limited access.  Collect only the limited amount of data needed to solve a specific problem.  Encrypt sensitive authentication data while stored. ~~ Securely delete such data immediately after use.~~

• Collect sensitive authentication only when needed to solve a specific problem. • Store such data only in specific, known locations with limited access. • Collect only the limited amount of data needed to solve a specific problem. • Encrypt sensitive authentication data while stored.

Removed p. 36

Assessor’s Response Summary of Findings (check one) Not Applicable 2.1 Software vendor must provide guidance to customers regarding secure deletion of cardholder data after expiration of customer-defined retention period.

Modified p. 36 → 34

Requirement 2: Protect stored cardholder data PA-DSS Requirements and Testing Procedures Reporting Instruction ~~ROV~~ Reporting Details:

Requirement 2: Protect stored cardholder data PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 2.1 Software vendor must provide guidance to customers regarding secure deletion of cardholder data after expiration of customer-defined retention period.

Modified p. 36 → 34

~~ Cardholder~~ data exceeding the ~~customer-defined~~ retention period must be securely deleted  A list of all locations where the payment application stores cardholder data (so that customer knows the locations of data that needs to be deleted)  Instructions that customers need to securely delete cardholder data when no longer required for legal, regulatory, or business purposes ~~(Continued~~ on ~~next page) Identify~~ the ~~page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and …~~

 Guidance that cardholder data exceeding the customer- defined retention period must be securely deleted <Report Findings Here>  A list of all locations where the payment application stores cardholder data (so that customer knows the locations of data that needs to be deleted) <Report Findings Here>  Instructions that customers need to securely delete cardholder data when no longer required for legal, regulatory, or business purposes <Report Findings Here>  Instructions on how to securely delete cardholder data stored …

Modified p. 36 → 34

~~ Guidance that cardholder~~ data exceeding the ~~customer-defined~~ retention period must be securely deleted ~~<Report Findings Here> ~~ A list of all locations where the payment application stores cardholder data (so that customer knows the locations of data that needs to be deleted) ~~<Report Findings Here> ~~ Instructions that customers need to securely delete cardholder data when no longer required for legal, regulatory, or business purposes ~~<Report Findings Here> ~~ Instructions on how to securely delete cardholder data stored by …

• Cardholder data exceeding the customer- defined retention period must be securely deleted • A list of all locations where the payment application stores cardholder data (so that customer knows the locations of data that needs to be deleted) • Instructions that customers need to securely delete cardholder data when no longer required for legal, regulatory, or business purposes • Instructions on how to securely delete cardholder data stored by the payment application, including data stored on underlying software or …

Removed p. 37

Assessor’s Response Summary of Findings (check one) Not Applicable  Instructions on how to securely delete cardholder data stored by the payment application, including data stored on underlying software or systems (such as OS, databases, etc.).  Instructions for configuring the underlying software or systems (such as OS, databases, etc.) to prevent inadvertent capture or retention of cardholder data•for example, system backup or restore points.

<Report Findings Here>  Describe how the instructions provided in the PA-DSS Implementation Guide for configuring underlying software or systems to prevent inadvertent capture or retention of cardholder data were observed to be effective.

Modified p. 37 → 34

 Describe how all locations where the payment application stores cardholder data were observed to confirm that the list provided in the PA-DSS Implementation Guide is complete.

<Report Findings Here>  Describe how all locations where the payment application stores cardholder data were observed to confirm that the list provided in the PA-DSS Implementation Guide is complete.

Modified p. 38 → 35

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 2.2 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.

<Report Findings Here> 2.2 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.

Modified p. 38 → 35

 Details of all instances where PAN is displayed, including but not limited to POS devices, screens, logs, and receipts.  Confirmation that the payment application masks PAN by default on all displays  Instructions for how to configure the payment application such that only personnel with a legitimate business need can see the full PAN.

• Instructions for how to configure the payment application such that only personnel with a legitimate business need can see the full PAN.

Removed p. 39

 List all displays of PAN data present and examined (including but not limited to POS devices, screens, logs and receipts) to verify PAN is masked when displayed.

Modified p. 39 → 36

~~Assessor’s Response Summary of Findings (check one) Not Applicable 2.2.b Install the payment application and examine~~ all displays of PAN ~~data, including~~ but not limited to POS devices, screens, ~~logs,~~ and ~~receipts. For each instance where PAN is displayed,~~ verify ~~that~~ PAN is masked when displayed.

List all displays of PAN data present and examined (including but not limited to POS devices, screens, logs and receipts) to verify PAN is masked when displayed.

Modified p. 39 → 36

<Report Findings Here>  For each instance where PAN is displayed, describe how observed PAN displays were masked.

<Report Findings Here> For each instance where PAN is displayed, describe how observed PAN displays were masked.

Modified p. 39 → 36

<Report Findings Here>  Provide the name of the PA-QSA who attests that the installed application was tested to confirm that the details of all instances where PAN is displayed documented in the PA-DSS Implementation Guide are complete and accurate.

<Report Findings Here> Provide the name of the PA-QSA who attests that the installed application was tested to confirm that the details of all instances where PAN is displayed documented in the PA-DSS Implementation Guide are complete and accurate.

Modified p. 39 → 36

 Describe the application configurations examined to verify that instructions in the IG for masking PAN are accurate and that only personnel with a legitimate business need can see the full PAN.

Describe the application configurations examined to verify that instructions in the IG for masking PAN are accurate and that only personnel with a legitimate business need can see the full PAN.

Modified p. 39 → 36

<Report Findings Here>  Describe the displays of PAN examined to verify that instructions in the IG for masking PAN are accurate and that only personnel with a legitimate business need can see the full PAN.

<Report Findings Here> Describe the displays of PAN examined to verify that instructions in the IG for masking PAN are accurate and that only personnel with a legitimate business need can see the full PAN.

Removed p. 40

Aligns with PCI DSS Requirement 3.4 2.3.a Review the PA-DSS Implementation Guide prepared by the vendor to verify the documentation includes the following guidance for customers and integrators/resellers:

Modified p. 40 → 36

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 2.3 Render PAN unreadable anywhere it is stored, (including data on portable digital media, backup media, and in logs) by using any of the following approaches:

<Report Findings Here> 2.3 Render PAN unreadable anywhere it is stored, (including data on portable digital media, backup media, and in logs) by using any of the following approaches:

Modified p. 40 → 36

Notes:  It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are generated by a payment application, additional controls ~~should~~ be in place to ensure that hashed and truncated versions cannot be correlated to reconstruct the original PAN.

Notes: • It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are generated by a payment application, additional controls must be in place to ensure that hashed and truncated versions cannot be correlated to reconstruct the original PAN.

Modified p. 40 → 36

 The PAN must be rendered unreadable anywhere it is stored, even outside the payment application (for example, log files output by the application for storage in the ~~merchant~~ environment).

• The PAN must be rendered unreadable anywhere it is stored, even outside the payment application (for example, log files output by the application for storage in the customer environment).

Modified p. 40 → 37

 Details of any configurable options for each method used by the application to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment application (per PA-DSS Requirement 2.1).  A list of all instances where cardholder data may be output for the merchant to store outside of the payment application, and instructions that the merchant is responsible for rendering PAN unreadable in all such instances.

• Details of any configurable options for each method used by the application to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment application (per PA-DSS Requirement 2.1).

Modified p. 40 → 37

<Report Findings Here>  A list of all instances where cardholder data may be output for the ~~merchant~~ to store outside of the payment application.

<Report Findings Here>  A list of all instances where cardholder data may be output for the customer to store outside of the payment application.

Modified p. 40 → 37

<Report Findings Here>  Instructions that the ~~merchant~~ is responsible for rendering PAN unreadable in all such instances.

<Report Findings Here>  Instructions that the customer is responsible for rendering PAN unreadable in all such instances.

Modified p. 41 → 38

~~ One-way hashes based on strong cryptography.  Truncation  Index tokens and pads, with the pads being securely stored ~~ Strong cryptography, with associated ~~key-management~~ processes and procedures  Identify the method(s) below used to protect PAN:

• Strong cryptography, with associated key- management processes and procedures Identify the method(s) below used to protect PAN:

Modified p. 41 → 38

~~ One-way hashes based on strong cryptography  Truncation  Index tokens and pads, with the pads being securely stored ~~ Strong cryptography, with associated key-management processes and procedures <Report Findings Here>  Identify the encryption algorithms (algorithm and key length) used (if applicable).

• Strong cryptography, with associated key-management processes and procedures <Report Findings Here> Identify the encryption algorithms (algorithm and key length) used (if applicable).

Modified p. 41 → 38

<Report Findings Here>  Describe the processes observed to verify PAN is rendered unreadable using any of the following methods:

<Report Findings Here> Describe the processes observed to verify PAN is rendered unreadable using any of the following methods:

Modified p. 41 → 38

 One-way hashes based on strong cryptography  Truncation  Index tokens and pads, with the pads being securely stored  Strong cryptography, with associated key-management processes and procedures <Report Findings Here> ~~2.3.c~~ Examine several tables or files from data repositories created or generated by the application to verify the PAN is rendered unreadable.

<Report Findings Here> 2.3.d Examine several tables or files from data repositories created or generated by the application to verify the PAN is rendered unreadable.

Modified p. 41 → 38

 Identify the sampled tables or files from data repositories created or generated by the application observed to verify the PAN is rendered unreadable.

Identify the sampled tables or files from data repositories created or generated by the application observed to verify the PAN is rendered unreadable.

Modified p. 41 → 38

<Report Findings Here>  For each item in the sample, describe how the tables or files were observed to confirm that PAN is rendered unreadable.

<Report Findings Here> For each item in the sample, describe how the tables or files were observed to confirm that PAN is rendered unreadable.

Removed p. 42

Assessor’s Response Summary of Findings (check one) Not Applicable 2.3.d If the application creates or generates files for use outside the application (for example, files generated for export or backup), including for storage on removable media, examine a sample of generated files, including those generated on removable media (for example, back-up tapes), to confirm that the PAN is rendered unreadable.

<Report Findings Here>  Identify the sample of generated files observed.

 Identify the sample of audit logs observed.

Modified p. 42 → 39

~~ Identify~~ whether there are instances where the application creates or generates files for use outside the application (for example, files generated for export or backup), including for storage on removable media. (yes/no) ~~If “no,” mark the remainder of 2.3.d as “not applicable.”~~ <Report Findings Here> If “yes,” complete the following:

Indicate whether there are instances where the application creates or generates files for use outside the application (for example, files generated for export or backup), including for storage on removable media. (yes/no) <Report Findings Here> If “yes,” complete the following:

Modified p. 42 → 39

 Provide the name of the PA-QSA who attests that the list in the PA-DSS Implementation Guide of all instances where cardholder data may be output for the merchant to store outside of the payment application was observed to be accurate.

Provide the name of the PA-QSA who attests that the list in the PA-DSS Implementation Guide of all instances where cardholder data may be output for the merchant to store outside of the payment application was observed to be accurate.

Modified p. 42 → 39

<Report Findings Here>  Describe how the generated files were observed to confirm that PAN is rendered unreadable. OR  Describe how the generated files were observed to confirm that PAN is removed.

<Report Findings Here> Identify the sample of generated files observed. <Report Findings Here> Describe how the generated files were observed to confirm that PAN is rendered unreadable. OR Describe how the generated files were observed to confirm that PAN is removed.

Modified p. 42 → 39

<Report Findings Here> ~~2.3.e~~ Examine a sample of audit logs created or generated by the application to confirm that the PAN is rendered unreadable or removed from the logs.

<Report Findings Here> 2.3.f Examine a sample of audit logs created or generated by the application to confirm that the PAN is rendered unreadable or removed from the logs.

Modified p. 42 → 39

<Report Findings Here>  Describe how the sample of audit logs was observed to confirm that PAN is rendered unreadable. OR  Describe how the sample of audit logs was observed to confirm that PAN is removed from the logs.

Identify the sample of audit logs observed. <Report Findings Here> Describe how the sample of audit logs was observed to confirm that PAN is rendered unreadable. OR Describe how the sample of audit logs was observed to confirm that PAN is removed from the logs.

Removed p. 43

<Report Findings Here>  Describe the processes observed to confirm PAN is rendered unreadable or removed from audit logs, per PA-DSS Requirement 2.3.e.

Modified p. 43 → 39

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable 2.3.f~~ If the software vendor stores the PAN for any reason (for example, because log files, debugging files, and other data sources are received from customers for debugging or troubleshooting purposes), verify that the PAN is rendered unreadable in accordance with Requirements 2.3.b through ~~2.3.e,~~ above.

<Report Findings Here> 2.3.g If the software vendor stores the PAN for any reason (for example, because log files, debugging files, and other data sources are received from customers for debugging or troubleshooting purposes), verify that the PAN is rendered unreadable in accordance with Requirements 2.3.b through 2.3.f, above.

Modified p. 43 → 39

~~ Identify~~ whether the software vendor stores the PAN for any reason. (yes/no) ~~If “no,” mark the remainder of 2.3.f as “not applicable”~~ <Report Findings Here> If “yes,” describe how it was verified that the PAN is rendered unreadable in accordance with Requirements 2.3.a through ~~2.3.e,~~ as follows:

Indicate whether the software vendor stores the PAN for any reason. (yes/no) <Report Findings Here> If “yes,” describe how it was verified that the PAN is rendered unreadable in accordance with Requirements 2.3.a through 2.3.f, as follows:

Modified p. 43 → 39

 Describe the processes observed to confirm PAN is rendered unreadable using any of the methods defined in PA-DSS Requirement 2.3.b.

Describe the processes observed to confirm PAN is rendered unreadable using any of the methods defined in PA-DSS Requirement 2.3.b.

Modified p. 43 → 39

<Report Findings Here>  Describe the processes observed to confirm PAN is rendered unreadable in several tables or files from data repositories, per PA-DSS Requirement 2.3.c.

<Report Findings Here> Describe the processes observed to confirm PAN is rendered unreadable in several tables or files from data repositories, per PA-DSS Requirement 2.3.c.

Modified p. 43 → 40

<Report Findings Here>  Describe the processes observed to confirm PAN is rendered unreadable ~~in files generated for export~~ or ~~backup, including for storage on removable media,~~ per PA-DSS Requirement ~~2.3.d.~~

<Report Findings Here> Describe the processes observed to confirm PAN is rendered unreadable or removed from audit logs, per PA-DSS Requirement 2.3.e.

Removed p. 44

 Describe the system configuration files observed.

Modified p. 44 → 40

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 2.4 Payment application must protect keys used to secure cardholder data against disclosure and misuse.

<Report Findings Here> 2.4 Payment application must protect keys used to secure cardholder data against disclosure and misuse.

Modified p. 44 → 40

 Identify the product documentation reviewed to verify that controls are in place to restrict access to cryptographic keys used by the application.

Identify the product documentation reviewed to verify that controls are in place to restrict access to cryptographic keys used by the application.

Modified p. 44 → 40

<Report Findings Here>  Identify the responsible personnel interviewed for this testing procedure who confirm that controls are in place that restrict access to cryptographic keys used by the application.

<Report Findings Here> Identify the responsible personnel interviewed for this testing procedure who confirm that controls are in place that restrict access to cryptographic keys used by the application.

Modified p. 44 → 40

~~ Keys are stored in encrypted format.  Key-encrypting~~ keys ~~are stored separately from data-encrypting keys.  Key-encrypting keys are~~ at least as strong as the ~~data encrypting~~ keys they protect.

<Report Findings Here> Describe how key-encrypting keys were verified to be at least as strong as the data-encrypting keys they protect.

Modified p. 44 → 40

<Report Findings Here>  Describe how keys were observed to be stored in encrypted format.

Describe the system configuration files observed. <Report Findings Here> Describe how keys were observed to be stored in encrypted format.

Modified p. 44 → 40

<Report Findings Here>  Describe how key-encrypting keys were observed to be stored separately from data-encrypting keys.

<Report Findings Here> Describe how key-encrypting keys were observed to be stored separately from data-encrypting keys.

Modified p. 44 → 40

~~<Report Findings Here>  Describe how key-encrypting~~ keys ~~were verified to be~~ at least as strong as the ~~data-encrypting~~ keys they protect.

• Key-encrypting keys are at least as strong as the data encrypting keys they protect.

Modified p. 44 → 40

 Restrict access to keys to the fewest number of custodians necessary. ~~ Store keys securely in the fewest possible locations and forms.~~

• Restrict access to keys to the fewest number of custodians necessary.

Removed p. 45

Assessor’s Response Summary of Findings (check one) Not Applicable 2.5 Payment application must implement key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including at least the following:

Modified p. 45 → 41

Aligns with PCI DSS Requirement 3.6 ~~2.5.a~~ Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and integrators/resellers:

Aligns with PCI DSS Requirement 3.6 2.5 Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and integrators/resellers:

Modified p. 45 → 41

 How to securely generate, distribute, protect, change, store, and retire/replace ~~encryption~~ keys, where customers or integrators/resellers are involved in these key-management activities. ~~ A sample Key Custodian form for key custodians to acknowledge that they understand and accept their key-custodian responsibilities.~~

• How to securely generate, distribute, protect, change, store, and retire/replace cryptographic keys, where customers or integrators/resellers are involved in these key-management activities.

Modified p. 45 → 41

~~ Identify~~ whether customers or integrators/resellers are involved in ~~key- management~~ activities for this payment application/able to perform the following key functions. (yes/no) If “no,” mark the remainder of 2.5.x as “not applicable.” <Report Findings Here> Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Indicate whether customers or integrators/resellers are involved in key-management activities for this payment application/able to perform the following key functions. (yes/no) If “no,” mark the remainder of 2.5.x as “not applicable.” <Report Findings Here> Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Modified p. 45 → 41

 How to securely generate, distribute, protect, change, store, and retire/replace ~~encryption~~ keys, where customers or integrators/resellers are involved in these key-management activities.

 How to securely generate, distribute, protect, change, store, and retire/replace cryptographic keys, where customers or integrators/resellers are involved in these key-management activities.

Modified p. 45 → 41

<Report Findings Here> 2.5.1 Generation of strong cryptographic keys 2.5.1.a Review the PA-DSS Implementation Guide and verify it includes instructions for customers and integrators/resellers on how to securely generate cryptographic keys.

<Report Findings Here> 2.5.1 Generation of strong cryptographic keys ☐ ☐ ☐ 2.5.1.a Review the PA-DSS Implementation Guide and verify it includes instructions for customers and integrators/resellers on how to securely generate cryptographic keys.

Modified p. 45 → 41

 Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers on how to securely generate cryptographic keys.

Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers on how to securely generate cryptographic keys.

Modified p. 45 → 41

 Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in the generation of strong cryptographic keys.

Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in the generation of strong cryptographic keys.

Removed p. 46

 Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in the secure distribution of cryptographic keys.

Modified p. 46 → 41

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 2.5.2 Secure cryptographic key distribution 2.5.2.a Review the PA-DSS Implementation Guide and verify it includes instructions for customers and integrators/resellers on how to securely distribute cryptographic keys.

<Report Findings Here> 2.5.2 Secure cryptographic key distribution ☐ ☐ ☐ 2.5.2.a Review the PA-DSS Implementation Guide and verify it includes instructions for customers and integrators/resellers on how to securely distribute cryptographic keys.

Modified p. 46 → 41

 Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers on how to securely distribute cryptographic keys.

Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers on how to securely distribute cryptographic keys.

Modified p. 46 → 42

~~<Report Findings Here> 2.5.2.b Test~~ the ~~application, including the methods used~~ to ~~distribute cryptographic keys, to verify~~ that the instructions in the PA-DSS Implementation Guide result in the secure distribution of cryptographic keys.

Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in the secure distribution of cryptographic keys.

Modified p. 46 → 42

<Report Findings Here> 2.5.3 Secure cryptographic key storage 2.5.3.a Review the PA-DSS Implementation Guide and verify it includes instructions for customers and integrators/resellers on how to securely store cryptographic keys.

<Report Findings Here> 2.5.3 Secure cryptographic key storage ☐ ☐ ☐ 2.5.3.a Review the PA-DSS Implementation Guide and verify it includes instructions for customers and integrators/resellers on how to securely store cryptographic keys.

Modified p. 46 → 42

 Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers on how to securely store cryptographic keys.

Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers on how to securely store cryptographic keys.

Modified p. 46 → 42

 Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in the secure storage of cryptographic keys.

Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in the secure storage of cryptographic keys.

Modified p. 46 → 42

2.5.4.a Review the PA-DSS Implementation Guide and verify it ~~Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include~~ the following instructions for customers and integrators/resellers:

2.5.4.a Review the PA-DSS Implementation Guide and verify it includes the following instructions for customers and integrators/resellers:

Modified p. 47 → 42

~~Assessor’s Response Summary~~ of ~~Findings (check one) Not Applicable includes~~ the following instructions for customers and integrators/resellers:

Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Modified p. 47 → 42

~~ Defined cryptoperiod for each key type used by the application. ~~ Procedures for enforcing key changes at the end of the defined cryptoperiod.

• Procedures for enforcing key changes at the end of the defined cryptoperiod.

Modified p. 47 → 42

<Report Findings Here> 2.5.4.b Test the application, including the methods for changing cryptographic keys, to verify the instructions in the ~~PA- DSS~~ Implementation Guide result in key changes at the end of the defined cryptoperiod.

<Report Findings Here> 2.5.4.b Test the application, including the methods for changing cryptographic keys, to verify the instructions in the PA-DSS Implementation Guide result in key changes at the end of the defined cryptoperiod.

Modified p. 47 → 42

 Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in key changes at the end of the defined cryptoperiod.

Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in key changes at the end of the defined cryptoperiod.

Modified p. 47 → 43

~~(continued on next page)~~ Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Removed p. 48

Assessor’s Response Summary of Findings (check one) Not Applicable  Instructions that keys must be retired or replaced when the integrity of the key has been weakened, or there is a known or suspected compromise of a key.  Procedures for retiring or replacing keys (for example: by archiving, destruction, and/or revocation as applicable).  Procedures for ensuring that retired or replaced cryptographic keys are not used for encryption operations.

Modified p. 48 → 43

<Report Findings Here>  Procedures for ensuring that retired or replaced cryptographic keys are not used for encryption operations.

<Report Findings Here>  Procedures for retiring or replacing keys. <Report Findings Here>  Procedures for ensuring that retired or replaced cryptographic keys are not used for encryption operations.

Modified p. 48 → 43

 Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in the retirement or replacement of keys.

Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in the retirement or replacement of keys.

Modified p. 48 → 43

 Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide ensure the application does not use retired or replaced keys for encryption operations.

Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide ensure the application does not use retired or replaced keys for encryption operations.

Removed p. 49

Assessor’s Response Summary of Findings (check one) Not Applicable 2.5.6.a Review the PA-DSS Implementation Guide and verify it includes the following for customers and integrators/resellers:

Modified p. 49 → 45

 Details of any manual clear-text cryptographic ~~key-management~~ operations supported by the ~~application.  Instructions~~ for ~~enforcing split knowledge~~ and ~~dual control for all such operations.~~

 Details of any manual clear-text cryptographic key- management operations supported by the application for customers and integrators/resellers.

Modified p. 49 → 45

~~ Identify~~ whether the payment application supports manual clear-text cryptographic key-management operations. (yes/no) If “no,” mark the remainder of 2.5.6.a and 2.5.6.b as “not applicable.” <Report Findings Here> If “yes,” identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Indicate whether the payment application supports manual clear-text cryptographic key-management operations. (yes/no) If “no,” mark the remainder of 2.5.6.a and 2.5.6.b as “not applicable.” <Report Findings Here> If “yes,” identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Modified p. 49 → 45

 Details of any manual clear-text cryptographic key-management operations supported by the ~~application for customers and integrators/resellers.~~

• Details of any manual clear-text cryptographic key-management operations supported by the application.

Modified p. 49 → 45

<Report Findings Here> 2.5.6.b Test the application, including all manual clear-text cryptographic ~~key- management~~ operations, to verify that the instructions in the PA-DSS Implementation Guide result in split knowledge and dual control of keys being required for all manual clear-text ~~key-management~~ procedures.

<Report Findings Here> 2.5.6.b Test the application, including all manual clear-text cryptographic key-management operations, to verify that the instructions in the PA-DSS Implementation Guide result in split knowledge and dual control of keys being required for all manual clear-text key- management procedures.

Modified p. 49 → 45

 Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in split knowledge and dual control of keys being required for all manual clear-text key-management procedures.

Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in split knowledge and dual control of keys being required for all manual clear-text key-management procedures.

Modified p. 49 → 45

<Report Findings Here> 2.5.7 Prevention of unauthorized substitution of cryptographic keys 2.5.7.a Review the PA-DSS Implementation Guide and verify it includes instructions for customers and integrators/resellers on how to prevent unauthorized substitution of cryptographic keys  Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers on how to prevent unauthorized substitution of cryptographic keys.

<Report Findings Here> 2.5.7 Prevention of unauthorized substitution of cryptographic keys ☐ ☐ ☐ 2.5.7.a Review the PA-DSS Implementation Guide and verify it includes instructions for customers and integrators/resellers on how to prevent unauthorized substitution of cryptographic keys Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers on how to prevent unauthorized substitution of cryptographic keys.

Modified p. 49 → 45

<Report Findings Here> 2.5.7.b Test the application, including all methods for substituting keys, to verify that the instructions in the ~~PA- DSS~~ Implementation Guide prevent unauthorized substitution of cryptographic keys.

<Report Findings Here> 2.5.7.b Test the application, including all methods for substituting keys, to verify that the instructions in the PA-DSS Implementation Guide prevent unauthorized substitution of cryptographic keys.

Modified p. 49 → 45

 Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in the prevention of unauthorized substitution of cryptographic keys.

Describe the application testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in the prevention of unauthorized substitution of cryptographic keys.

Removed p. 50

Assessor’s Response Summary of Findings (check one) Not Applicable 2.6 Provide a mechanism to render irretrievable any cryptographic key material or cryptogram stored by the payment application, in accordance with industry-accepted standards.

 Procedures detailing how to use the tool or procedure provided with the application to render cryptographic material irretrievable.  That cryptographic key material should be rendered irretrievable whenever keys are no longer used and in accordance with key- management requirements in PCI DSS.  Procedures for re-encrypting historic data with new keys, including procedures for maintaining security of clear-text data during the decryption /re-encryption process.

Modified p. 50 → 46

Note: This requirement applies only if the payment application ~~uses~~ or previous versions of the payment application ~~used~~ cryptographic key materials or cryptograms to encrypt cardholder data.

Note: This requirement applies only if the payment application uses, or previous versions of the payment application used, cryptographic key materials or cryptograms to encrypt cardholder data.

Modified p. 50 → 46

~~ Identify~~ whether the application uses, or previous versions of the payment application used, cryptographic key materials or cryptograms to encrypt cardholder data. (yes/no) If “no,” mark the remainder of 2.6 as “not applicable.” <Report Findings Here>  Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Indicate whether the application uses, or previous versions of the payment application used, cryptographic key materials or cryptograms to encrypt cardholder data. (yes/no) If “no,” mark the remainder of 2.6 as “not applicable.” <Report Findings Here> Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Modified p. 50 → 46

 Procedures detailing how to use the tool or procedure provided with the application to render cryptographic material irretrievable.

• Procedures detailing how to use the tool or procedure provided with the application to render cryptographic material irretrievable.

Modified p. 50 → 46

~~<Report Findings Here> ~~ That cryptographic key material should be rendered irretrievable whenever keys are no longer used and in accordance with key- management requirements in PCI DSS.

• That cryptographic key material should be rendered irretrievable whenever keys are no longer used and in accordance with key- management requirements in PCI DSS.

Modified p. 50 → 46

~~<Report Findings Here> ~~ Procedures for re-encrypting historic data with new keys, including procedures for maintaining security of clear-text data during the decryption /re-encryption process.

• Procedures for re-encrypting historic data with new keys, including procedures for maintaining security of clear-text data during the decryption /re-encryption process.

Removed p. 51

<Report Findings Here>  Identify the industry-accepted standards.

Modified p. 51 → 46

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 2.6.b Examine final application product to verify the vendor provides a tool and/or procedure with the application to render cryptographic material irretrievable.

<Report Findings Here> 2.6.b Examine final application product to verify the vendor provides a tool and/or procedure with the application to render cryptographic material irretrievable.

Modified p. 51 → 46

 Describe how the final application product was examined to verify the vendor provides a tool and/or procedure with the application to render cryptographic material irretrievable <Report Findings Here>  Describe the tool or procedure provided by the vendor for rendering cryptographic material irretrievable.

Describe how the final application product was examined to verify the vendor provides a tool and/or procedure with the application to render cryptographic material irretrievable <Report Findings Here> Describe the tool or procedure provided by the vendor for rendering cryptographic material irretrievable.

Modified p. 51 → 47

 Identify the forensic tools and/or methods used to confirm that the secure wipe tool or procedure renders the cryptographic material irretrievable.

Identify the forensic tools and/or methods used to confirm that the secure wipe tool or procedure renders the cryptographic material irretrievable.

Modified p. 51 → 47

<Report Findings Here>  Describe the application testing performed to confirm the ~~vendor- provided~~ tool or procedure renders the cryptographic material irretrievable.

<Report Findings Here> Describe the application testing performed to confirm the vendor-provided tool or procedure renders the cryptographic material irretrievable.

Modified p. 51 → 47

<Report Findings Here> 2.6.d Test the methods for ~~re- encrypting~~ historic data with new keys, to verify the instructions in the PA-DSS Implementation Guide result in successful re-encryption of historic data with new keys.

<Report Findings Here> Identify the industry-accepted standards. <Report Findings Here> 2.6.d Test the methods for re-encrypting historic data with new keys, to verify the instructions in the PA-DSS Implementation Guide result in successful re-encryption of historic data with new keys.

Modified p. 51 → 47

 Describe the testing performed to confirm that the instructions in the ~~PA- DSS~~ Implementation Guide result in successful re-encryption of historic data with new keys.

Describe the testing performed to confirm that the instructions in the PA-DSS Implementation Guide result in successful re-encryption of historic data with new keys.

Removed p. 52

Requirement 3: Provide secure authentication features PA-DSS Requirements and Testing Procedures Reporting Instruction ROV Reporting Details:

Modified p. 52 → 48

Assessor’s Response Summary of Findings (check one) ~~Not Applicable~~ 3.1 The payment application must support and enforce the use of unique user IDs and secure authentication for all administrative access and for all access to cardholder data. Secure authentication must be enforced to all accounts generated or managed by the application by the completion of installation and for subsequent changes after installation.

Requirement 3: Provide secure authentication features PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 3.1 The payment application must support and enforce the use of unique user IDs and secure authentication for all administrative access and for all access to cardholder data. Secure authentication must be enforced to all accounts generated or managed by the application by the completion of installation and for subsequent changes after installation.

Modified p. 52 → 48

 Provided clear and unambiguous directions on how the payment application enforces strong authentication for all authentication credentials that the application generates or manages, by: - Enforcing secure changes to authentication credentials by the completion of installation per Requirements 3.1.1 through 3.1.11. - Enforcing secure changes for any subsequent changes (after installation) to authentication credentials per Requirements 3.1.1 through 3.1.11.

• Provided clear and unambiguous directions on how the payment application enforces strong authentication for all authentication credentials that the application generates or manages, by: - Enforcing secure changes to authentication credentials by the completion of installation per Requirements 3.1.1 through 3.1.11. - Enforcing secure changes for any subsequent changes (after installation) to authentication credentials per Requirements 3.1.1 through 3.1.11.

Modified p. 52 → 48

~~(continued on next page)~~ Provide the name of the PA-QSA who attests that review of the PA-DSS Implementation Guide confirmed that customers and integrators/resellers are provided clear and unambiguous directions on how the payment application enforces strong authentication for all authentication credentials that the application generates or manages, as follows:

Provide the name of the PA-QSA who attests that review of the PA-DSS Implementation Guide confirmed that customers and integrators/resellers are provided clear and unambiguous directions on how the payment application enforces strong authentication for all authentication credentials that the application generates or manages, as follows:

Modified p. 53 → 49

Assessor’s Response Summary of Findings (check one) Not Applicable  Advised that, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.  Advised to assign secure authentication to any default accounts (even if they won’t be used), and then disable or do not use that accounts.  Provided clear and unambiguous directions for all authentication credentials used by the …

• Provided clear and unambiguous directions for all authentication credentials used by the payment application (but which are not generated or managed by the application), on how, by the completion of installation and for any changes after installation, to change authentication credentials and create strong authentication per Requirements 3.1.1 through 3.1.11 below, for all application level and user accounts with administrative access and for all accounts with access to cardholder data.

Modified p. 53 → 49

 Customers and integrators/resellers are advised that, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.  Secure authentication should be assigned to any default ~~accounts (even if they won’t be used).  Default~~ accounts that won’t be ~~used should be disabled~~ or ~~deleted.~~

 Customers and integrators/resellers are advised that, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.  Secure authentication should be assigned to all default accounts in the environment.  For any default accounts that won’t be used, assign secure authentication and then disable or do not use the account.

Modified p. 53 → 49

<Continue Findings Here> ~~ Identify~~ whether there are any authentication credentials used by the payment application but that are not generated or managed by the application. (yes/no) If “no,” mark the rest of 3.1 as “not applicable.” <Report Findings Here> If “yes,” provide the name of the PA-QSA who attests that review of the PA-DSS Implementation Guide confirmed that that customers and integrators/resellers are provided clear and unambiguous directions on how to change authentication credentials and create strong authentication per …

<Continue Findings Here> Indicate whether there are any authentication credentials used by the payment application but that are not generated or managed by the application. (yes/no) If “no,” mark the rest of 3.1 as “not applicable.” <Report Findings Here> If “yes,” provide the name of the PA-QSA who attests that review of the PA-DSS Implementation Guide confirmed that that customers and integrators/resellers are provided clear and unambiguous directions on how to change authentication credentials and create strong authentication per Requirements …

Modified p. 54 → 49

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 3.1.1 The payment application does not use (or require the use of) default administrative accounts for other necessary software (for example, the payment application must not use the database default administrative account).

<Report Findings Here> 3.1.1 The payment application does not use (or require the use of) default administrative accounts for other necessary software (for example, the payment application must not use the database default administrative account).

Modified p. 54 → 49

Aligns with PCI DSS Requirement 2.1 3.1.1 Install and configure the payment application in accordance with the ~~PA- DSS~~ Implementation Guide, including configuring any ~~administrative accounts for all necessary software. Test~~ the ~~payment application~~ to verify the payment application does not use ~~(or require the use of)~~ default administrative accounts for necessary ~~software.~~

Aligns with PCI DSS Requirement 2.1 3.1.1 Install and configure the payment application in accordance with the PA-DSS Implementation Guide, including configuring any Describe the testing performed to verify that the payment application does not use default administrative accounts for other necessary software <Report Findings Here>

Modified p. 54 → 50

~~ Describe the testing performed to verify that the payment application does not use default administrative accounts for other necessary software <Report Findings Here> ~~ Describe the testing performed to verify that the payment application does not require the use of default administrative accounts for other necessary software <Report Findings Here> 3.1.2 The application must enforce the changing of all default application passwords for all accounts that are generated or managed by the application, by the completion of installation and …

Describe the testing performed to verify that the payment application does not require the use of default administrative accounts for other necessary software <Report Findings Here> 3.1.2 The application must enforce the changing of all default application passwords for all accounts that are generated or managed by the application, by the completion of installation and for subsequent changes after installation. This applies to all accounts, including user accounts, application and service accounts, and accounts used by the vendor for support …

Modified p. 54 → 50

Aligns with PCI DSS Requirement 2.1 3.1.2 For all accounts generated or managed by the application, test the application as follows:

Aligns with PCI DSS Requirement 2.1 3.1.2 For all accounts generated or managed by the application, test the application as follows: ☐ ☐ ☐ 3.1.2.a Install the application in accordance with the PA-DSS Implementation Guide, examine account and password settings and attempt to use all default passwords to verify that the application enforces changes to any default payment application passwords by completion of the installation process.

Modified p. 54 → 50

 Identify account and password settings ~~examined.~~

<Report Findings Here> Identify account and password settings examined for all type of changes performed.

Modified p. 54 → 50

<Report Findings Here>  Describe how attempts to use all default payment application passwords verified the application enforces changes to all default passwords by completion of the ~~installation process.~~

<Report Findings Here> Describe how attempts to use all default payment application passwords verified the application enforces changes to all default passwords upon completion of the change.

Removed p. 55

<Report Findings Here>  Identify account and password settings examined for all type of changes performed.

 Describe how attempts to create different application accounts with the same user ID verified the payment application only assigns unique user IDs by completion of the installation process.

Modified p. 55 → 50

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 3.1.2.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine account and password settings and attempt to use all default passwords to verify that the application enforces changes to all default passwords upon completion of the change.

<Report Findings Here> 3.1.2.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine account and password settings and attempt to use all default passwords to verify that the application enforces changes to all default passwords upon completion of the change.

Modified p. 55 → 50

 Identify the application functionality present that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts.

Identify the application functionality present that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts.

Modified p. 55 → 50

<Report Findings Here>  Describe how attempts to use all default payment application passwords verified the application enforces changes to all default passwords ~~upon~~ completion of the ~~change.~~

Identify account and password settings examined. <Report Findings Here> Describe how attempts to use all default payment application passwords verified the application enforces changes to all default passwords by completion of the installation process.

Modified p. 55 → 50

Aligns with PCI DSS Requirements 8.1.1 3.1.3 For all accounts that are generated or managed by the application, test the application as follows:

Aligns with PCI DSS Requirements 8.1.1 3.1.3 For all accounts that are generated or managed by the application, test the application as follows: ☐ ☐ ☐

Modified p. 55 → 51

~~3.1.3.a Install the payment application in accordance with the PA-DSS Implementation Guide and attempt~~ to create different application accounts with the same user ID ~~to verify that~~ the payment application only assigns unique user IDs by completion of the installation process.

Describe how attempts to create different application accounts with the same user ID verified the payment application only assigns unique user IDs by completion of the installation process.

Modified p. 55 → 51

<Report Findings Here> 3.1.3.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts.

<Report Findings Here> 3.1.3.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine account settings and test application functionality to verify that unique user IDs are assigned for all accounts upon completion of the change.

Removed p. 56

<Report Findings Here>  Describe the application functionality testing performed to verify that unique user IDs are assigned for all accounts upon completion of the change.

 Something you know, such as a password or passphrase  Something you have, such as a token device or smart card  Something you are, such as a biometric Aligns with PCI DSS Requirements 8.2 3.1.4 For all accounts generated or managed by the application, test the application as follows:

 Identify the authentication methods examined.

(continued on next page)  For the testing of all types of changes performed (as identified in 3.1.2.b), identify the authentication methods examined.

Modified p. 56 → 51

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable For all types of changes performed, examine~~ account settings ~~and test application functionality~~ to verify that unique user IDs are assigned for all accounts upon completion of the change.

<Report Findings Here> Describe how account settings were tested to verify that unique user IDs are assigned for all accounts upon completion of the change.

Modified p. 56 → 51

 Describe ~~how account settings were tested~~ to verify that unique user IDs are assigned for all accounts upon completion of the change.

<Report Findings Here> Describe the application functionality testing performed to verify that unique user IDs are assigned for all accounts upon completion of the change.

Modified p. 56 → 51

3.1.4.a Install the payment application in accordance with the PA-DSS Implementation Guide and test authentication methods to verify that the application requires at least one of the defined authentication methods for all accounts by completion of the installation process.

• Something you are, such as a biometric Aligns with PCI DSS Requirements 8.2 3.1.4 For all accounts generated or managed by the application, test the application as follows: ☐ ☐ ☐ 3.1.4.a Install the payment application in accordance with the PA-DSS Implementation Guide and test authentication methods to verify that the application requires at least one of the defined authentication methods for all accounts by completion of the installation process.

Modified p. 56 → 51

<Report Findings Here>  Describe the testing of authentication methods performed to verify that the application requires at least one of the defined authentication methods for all accounts by completion of the installation process.

Identify the authentication methods examined. <Report Findings Here> Describe the testing of authentication methods performed to verify that the application requires at least one of the defined authentication methods for all accounts by completion of the installation process.

Modified p. 56 → 51

<Report Findings Here> 3.1.4.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts.

<Report Findings Here> 3.1.4.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts. For all types of changes performed, test For the testing of all types of changes performed (as identified in 3.1.2.b), identify the authentication methods examined.

Removed p. 57

<Report Findings Here>  Describe the application functionality testing performed to verify that the application requires at least one of the defined authentication methods for all accounts, upon completion of the change.

 Any group accounts and passwords. <Report Findings Here>  Shared account s and passwords. <Report Findings Here>  Generic accounts and passwords. <Report Findings Here>

Modified p. 57 → 51

 Describe how authentication methods were tested to verify that the application requires at least one of the defined authentication methods for all accounts, upon completion of the change.

<Report Findings Here> Describe how authentication methods were tested to verify that the application requires at least one of the defined authentication methods for all accounts, upon completion of the change.

Modified p. 57 → 52

~~Assessor’s Response Summary of Findings (check one) Not Applicable For all types of changes performed, test authentication methods~~ to verify that the application requires at least one of the defined authentication methods for all accounts, upon completion of the change.

Describe the application functionality testing performed to verify that the application requires at least one of the defined authentication methods for all accounts, upon completion of the change.

Modified p. 57 → 52

Aligns with PCI DSS Requirement 8.5 3.1.5 For all accounts generated or managed by the application, test the application as follows:

Aligns with PCI DSS Requirement 8.5 3.1.5 For all accounts generated or managed by the application, test the application as follows: ☐ ☐ ☐ 3.1.5.a Install the payment application in accordance with the PA-DSS Implementation Guide, examine account settings and test application functionality to verify that, by completion of the installation process, the application does not require or use any group, shared, or generic accounts and passwords.

Modified p. 57 → 52

 Identify the account settings examined. <Report Findings Here>  Describe the testing of account settings performed to verify that, by completion of the installation process, the application does not require or use:

Identify the account settings examined. <Report Findings Here> Describe the testing of account settings performed to verify that, by completion of the installation process, the application does not require or use:

Modified p. 57 → 52

~~ Any group accounts and passwords. <Report Findings Here>  Shared account s and passwords. <Report Findings Here> ~~ Generic accounts and passwords. <Report Findings Here>  Describe the testing of application functionality performed to verify that, by completion of the installation process, the application does not require or use:

• Generic accounts and passwords. <Report Findings Here> Describe the testing of application functionality performed to verify that, by completion of the installation process, the application does not require or use:

Removed p. 58

 Any group accounts and passwords. <Report Findings Here>  Shared account s and passwords. <Report Findings Here>  Generic accounts and passwords. <Report Findings Here>  Describe the application functionality testing performed to verify that, upon completion of the change, the application does not rely on or use:

Modified p. 58 → 52

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 3.1.5.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine account settings and test application functionality to verify that the application does not rely on or use any group, shared, or generic accounts and passwords upon completion of the change.

• Generic accounts and passwords. <Report Findings Here> 3.1.5.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine account settings and test application functionality to verify that the application does not rely on or use any group, shared, or generic accounts and passwords upon completion of the change.

Modified p. 58 → 52

<Report Findings Here>  Describe how account settings were tested to verify that, upon completion of the change, the application does not rely on or use:

<Report Findings Here> Describe how account settings were tested to verify that, upon completion of the change, the application does not rely on or use:

Modified p. 58 → 53

~~ Any group accounts and passwords. <Report Findings Here>  Shared accounts and passwords. <Report Findings Here> ~~ Generic accounts and passwords. <Report Findings Here> 3.1.6 The payment application requires that passwords meet the following:

• Generic accounts and passwords. <Report Findings Here> 3.1.6 The payment application requires that passwords meet the following:

Modified p. 58 → 53

~~ Require a minimum length of at least seven characters ~~ Contain both numeric and alphabetic characters Alternatively, the passwords/phrase must have complexity and strength at least equivalent to the parameters specified above.

• Contain both numeric and alphabetic characters Alternatively, the passwords/phrase must have complexity and strength at least equivalent to the parameters specified above.

Removed p. 59

Assessor’s Response Summary of Findings (check one) Not Applicable 3.1.6 For all accounts generated or managed by the application, test the application as follows:

Modified p. 59 → 53

~~ Be at least seven characters in length. ~~ Contain both numeric and alphabetic characters.

• Contain both numeric and alphabetic characters.

Modified p. 59 → 53

~~ Be at least seven characters in length. ~~ Contain both numeric and alphabetic characters.

• Contain both numeric and alphabetic characters.

Modified p. 59 → 53

 Identify the account settings examined. <Report Findings Here>  Describe the testing of account settings performed to verify that by completion of the installation process, the application requires:

Identify the account settings examined. <Report Findings Here> Describe the testing of account settings performed to verify that by completion of the installation process, the application requires:

Modified p. 59 → 53

~~ Passwords to be~~ at least seven characters in length.

• Be at least seven characters in length.

Modified p. 59 → 53

~~ Passwords to be~~ at least seven characters in length.

• Be at least seven characters in length.

Modified p. 59 → 53

<Report Findings Here>  Describe how account settings were tested to verify that upon completion of the change, the application requires:

<Report Findings Here> Describe how account settings were tested to verify that upon completion of the change, the application requires:

Modified p. 59 → 53

<Report Findings Here>  Describe the application functionality testing performed to verify that upon completion of the change, the application requires:

<Report Findings Here> Describe the application functionality testing performed to verify that upon completion of the change, the application requires:

Modified p. 59 → 53

 Passwords to be at least seven characters in length.

• Passwords to be at least seven characters in length. <Report Findings Here>

Removed p. 60

Assessor’s Response Summary of Findings (check one) Not Applicable 3.1.6.c If the application uses a different minimum character set and length for passwords, calculate the entropy of the passwords required by the application, and verify that it is at least equivalent to the parameters specified above (that is, at least as strong as seven characters in length with numeric and alphabetic characters).

Modified p. 60 → 54

 Identify whether the application uses a different minimum character set and length for passwords. (yes/no) ~~If “no,” mark the rest of 3.1.6.c as “not applicable.”~~ <Report Findings Here>  Describe how the entropy of the passwords required by the application was calculated.

Identify whether the application uses a different minimum character set and length for passwords. (yes/no) <Report Findings Here> Describe how the entropy of the passwords required by the application was calculated.

Modified p. 60 → 54

<Report Findings Here>  Describe how the calculated entropy was compared to the parameters specified above (at least as strong as seven characters in length with numeric and alphabetic character) and verified to be at least equivalent.

<Report Findings Here> Describe how the calculated entropy was compared to the parameters specified above (at least as strong as seven characters in length with numeric and alphabetic character) and verified to be at least equivalent.

Modified p. 60 → 54

<Report Findings Here> 3.1.7 The payment application requires changes to user passwords at least every 90 days.

<Report Findings Here> 3.1.7 The payment application requires changes to user passwords at least once every 90 days.

Modified p. 60 → 54

Aligns with PCI DSS Requirement 8.2.4 3.1.7 For all accounts generated or managed by the application, test the application as follows:

Aligns with PCI DSS Requirement 8.2.4 3.1.7 For all accounts generated or managed by the application, test the application as follows: ☐ ☐ ☐ 3.1.7.a Install the payment application in accordance with the PA-DSS Implementation Guide and examine account settings to verify that the application requires user passwords to be changed at least once every 90 days by completion of the installation process.

Modified p. 60 → 54

~~3.1.7.a Install the payment application in accordance with the PA-DSS Implementation Guide and examine~~ account settings to verify that the application requires user passwords to be changed at least every 90 days by completion of the ~~installation process.~~

<Report Findings Here> Describe how account settings were tested to verify that the application requires user passwords to be changed at least once every 90 days upon completion of the change.

Modified p. 60 → 54

 Identify the account settings examined. <Report Findings Here>  Describe the testing of account settings performed to verify that the application requires user passwords to be changed at least every 90 days by completion of the installation process.

Identify the account settings examined. <Report Findings Here> Describe the testing of account settings performed to verify that the application requires user passwords to be changed at least once every 90 days by completion of the installation process.

Modified p. 60 → 54

<Report Findings Here> 3.1.7.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts.

<Report Findings Here> 3.1.7.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine account settings and test application functionality to verify that the application requires user passwords to be changed at least once every 90 days upon completion of the change.

Removed p. 61

Assessor’s Response Summary of Findings (check one) Not Applicable For all types of changes performed, examine account settings and test application functionality to verify that the application requires user passwords to be changed at least every 90 days upon completion of the change.

 Describe how account settings were tested to verify that the application requires user passwords to be changed at least every 90 days upon completion of the change.

Modified p. 61 → 54

<Report Findings Here>  Describe the application functionality testing performed to verify that the application requires user passwords to be changed at least every 90 days upon completion of the change.

<Report Findings Here> Describe the application functionality testing performed to verify that the application requires user passwords to be changed at least once every 90 days upon completion of the change.

Modified p. 61 → 54

Aligns with PCI DSS Requirement 8.2.5 ~~3.1.8 For all accounts generated or managed by the application, test the application as follows:~~

Aligns with PCI DSS Requirement 8.2.5

Modified p. 61 → 55

 Identify the account settings examined. <Report Findings Here>  Describe the testing of account settings performed to verify that, by completion of the installation process, the application keeps password history.

Identify the account settings examined. <Report Findings Here> Describe the testing of account settings performed to verify that, by completion of the installation process, the application keeps password history.

Modified p. 61 → 55

<Report Findings Here>  Describe the testing of account settings performed to verify that, by completion of the installation process, the application requires that a new password is different than any of the last four passwords used.

<Report Findings Here> Describe the testing of account settings performed to verify that, by completion of the installation process, the application requires that a new password is different than any of the last four passwords used.

Modified p. 61 → 55

<Report Findings Here> 3.1.8.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts.

<Report Findings Here> 3.1.8.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine account settings and test application functionality to verify that the application keeps password history and requires that a new password is different than any of the last four passwords used, upon completion of the change.

Modified p. 61 → 55

 Keeps password history. <Report Findings Here>

 Keeps password history. <Report Findings Here>  Requires that a new password is different than any of the last four passwords used.

Removed p. 62

Assessor’s Response Summary of Findings (check one) Not Applicable For all types of changes performed, examine account settings and test application functionality to verify that the application keeps password history and requires that a new password is different than any of the last four passwords used, upon completion of the change.

<Report Findings Here> 3.1.9.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine account settings and test application functionality to verify that the application locks out user accounts after not more than six invalid logon attempts, upon completion of the change.

Modified p. 62 → 55

 Identify the account settings examined. <Report Findings Here>  Describe the testing of account settings performed to verify that, by completion of the installation process, the application locks out user accounts after not more than six invalid logon attempts.

Identify the account settings examined. <Report Findings Here> Describe the testing of account settings performed to verify that, by completion of the installation process, the application locks out user accounts after not more than six invalid logon attempts.

Modified p. 62 → 55

 For the testing of all types of changes performed (as identified in 3.1.2.b), identify the account settings examined.

<Report Findings Here> 3.1.9.b Test all application functionality that results in user accounts reverting to default For the testing of all types of changes performed (as identified in 3.1.2.b), identify the account settings examined.

Modified p. 62 → 56

~~<Report Findings Here> ~~ Describe how account settings were tested to verify that the application locks out user accounts after not more than six invalid logon attempts, upon completion of the change.

Describe how account settings were tested to verify that the application locks out user accounts after not more than six invalid logon attempts, upon completion of the change.

Modified p. 62 → 56

<Report Findings Here>  Describe the application functionality testing performed to verify that the application locks out user accounts after not more than six invalid logon attempts, upon completion of the change.

<Report Findings Here> Describe the application functionality testing performed to verify that the application locks out user accounts after not more than six invalid logon attempts, upon completion of the change.

Modified p. 63 → 56

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 3.1.10 The payment application sets the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.

<Report Findings Here> 3.1.10 The payment application sets the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.

Modified p. 63 → 56

 Identify the account settings examined. <Report Findings Here>  Describe the testing of account settings performed to verify that by completion of the installation process, the application sets the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

Identify the account settings examined. <Report Findings Here> Describe the testing of account settings performed to verify that by completion of the installation process, the application sets the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

Modified p. 63 → 56

<Report Findings Here>  Describe how account settings were tested to verify that the application sets the lockout duration to a minimum of 30 minutes or until administrator enables the user ID, upon completion of the change.

<Report Findings Here> Describe how account settings were tested to verify that the application sets the lockout duration to a minimum of 30 minutes or until administrator enables the user ID, upon completion of the change.

Modified p. 63 → 56

<Report Findings Here>  Describe the application functionality testing performed to verify that the application sets the lockout duration to a minimum of 30 minutes or until administrator enables the user ID, upon completion of the change.

<Report Findings Here> Describe the application functionality testing performed to verify that the application sets the lockout duration to a minimum of 30 minutes or until administrator enables the user ID, upon completion of the change.

Removed p. 64

Assessor’s Response Summary of Findings (check one) Not Applicable 3.1.11 If a payment application session has been idle for more than 15 minutes, the application requires the user to re-authenticate to re-activate the session.

Modified p. 64 → 57

 Identify the account settings examined. <Report Findings Here>  Describe the testing of account settings performed to verify that, by completion of the installation process, the application sets a session idle time out to 15 minutes or less.

Identify the account settings examined. <Report Findings Here> Describe the testing of account settings performed to verify that, by completion of the installation process, the application sets a session idle time out to 15 minutes or less.

Modified p. 64 → 57

<Report Findings Here>  Describe how account settings were tested to verify that the application sets a session idle time out to 15 minutes or less, upon completion of the change.

<Report Findings Here> Describe how account settings were tested to verify that the application sets a session idle time out to 15 minutes or less, upon completion of the change.

Modified p. 64 → 57

<Report Findings Here>  Describe the application functionality testing performed to verify that the application sets a session idle time out to 15 minutes or less, upon completion of the change.

<Report Findings Here> Describe the application functionality testing performed to verify that the application sets a session idle time out to 15 minutes or less, upon completion of the change.

Modified p. 65 → 57

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 3.2 Software vendor must provide guidance to customers that all access to PCs, servers, and databases with payment applications must require a unique user ID and secure authentication.

<Report Findings Here> 3.2 Software vendor must provide guidance to customers that all access to PCs, servers, and databases with payment applications must require a unique user ID and secure authentication.

Modified p. 65 → 57

Aligns with PCI DSS Requirements 8.1 and 8.2 3.2 Examine PA-DSS Implementation Guide created by vendor to verify customers and integrators/resellers are instructed to control access, via unique user ID and PCI ~~DSS-compliant~~ secure authentication, to any PCs, servers, and databases with payment applications and cardholder data.

Aligns with PCI DSS Requirements 8.1 and 8.2 3.2 Examine PA-DSS Implementation Guide created by vendor to verify customers and integrators/resellers are instructed to control access, via unique user ID and PCI DSS- compliant secure authentication, to any PCs, servers, and databases with payment applications and cardholder data.

Modified p. 65 → 57

 Control access to any PCs, servers, and databases with payment applications via unique user ID and PCI ~~DSS-compliant~~ secure authentication.

 Control access to any PCs, servers, and databases with payment applications via unique user ID and PCI DSS- compliant secure authentication.

Modified p. 65 → 57

Aligns with PCI DSS Requirement 8.2.1 ~~3.3 Perform the following:~~

Aligns with PCI DSS Requirement 8.2.1

Modified p. 65 → 58

~~3.3.1.a Examine vendor documentation and~~ application configurations to verify that strong cryptography is used to render all passwords unreadable at all times during transmission.

<Report Findings Here> Identify the application configurations examined to verify that strong cryptography is used to render all passwords unreadable at all times during transmission.

Modified p. 65 → 58

 Identify the vendor documentation reviewed to verify it defines that strong cryptography is used to render all passwords unreadable at all times during transmission.

Identify the vendor documentation reviewed to verify it defines that strong cryptography is used to render all passwords unreadable at all times during transmission.

Modified p. 65 → 58

<Report Findings Here>  Identify the ~~application configurations examined to verify that~~ strong cryptography is used to render ~~all~~ passwords unreadable at all times during transmission.

<Report Findings Here> Identify the strong cryptography verified to be used to render passwords unreadable at all times during transmission.

Removed p. 66

<Report Findings Here>  Describe how strong cryptography was observed to render passwords unreadable at all times during transmission.

Modified p. 66 → 58

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 3.3.1.b For all types of application passwords, examine transmissions of passwords (for example, by logging into the application from another system, and authenticating the application to other systems) to verify strong cryptography is used to render all passwords unreadable at all times during transmission.

<Report Findings Here> 3.3.1.b For all types of application passwords, examine transmissions of passwords (for example, by logging into the application from another system, and authenticating the application to other systems) to verify strong cryptography is used to render all passwords unreadable at all times during transmission.

Modified p. 66 → 58

 Identify the types of application passwords examined during transmission.

Identify the types of application passwords examined during transmission.

Modified p. 66 → 58

<Report Findings Here> ~~ Identify the~~ strong cryptography ~~verified to be used~~ to render passwords unreadable at all times during transmission.

<Report Findings Here> Describe how strong cryptography was observed to render passwords unreadable at all times during transmission.

Modified p. 66 → 58

 Stored passwords are rendered unreadable using a strong, ~~one- way~~ cryptographic algorithm, based on approved standards. ~~ A unique input variable is concatenated with each password before the cryptographic algorithm is applied.~~

• Stored passwords are rendered unreadable using a strong, one-way cryptographic algorithm, based on approved standards.

Modified p. 66 → 58

 Identify the vendor documentation reviewed and verified to define that:

Identify the vendor documentation reviewed and verified to define that:

Modified p. 66 → 58

 Stored passwords are rendered unreadable using a strong, one-way cryptographic algorithm, based on approved standards. ~~ A unique input variable is concatenated with each password before the cryptographic algorithm is applied.~~

• Stored passwords are rendered unreadable using a strong, one-way cryptographic algorithm, based on approved standards.

Modified p. 66 → 58

<Report Findings Here>  Identify the application configurations examined to verify that stored passwords are rendered unreadable using a strong, one-way cryptographic algorithm, based on approved standards.

<Report Findings Here> Identify the application configurations examined to verify that stored passwords are rendered unreadable using a strong, one-way cryptographic algorithm, based on approved standards.

Modified p. 66 → 58

<Report Findings Here>  Identify the application configurations examined to verify that a unique input variable is concatenated with each password before the cryptographic algorithm is applied.

<Report Findings Here> Identify the application configurations examined to verify that a unique input variable is concatenated with each password before the cryptographic algorithm is applied.

Removed p. 67

Assessor’s Response Summary of Findings (check one) Not Applicable 3.3.2.b For all types of application passwords, identify all locations where the application may store passwords, including within the application itself, on underlying systems, log files, registry settings, etc. For all locations and types of passwords, examine stored password files during storage to verify that passwords are rendered unreadable using a strong, one-way cryptographic algorithm, with a unique input variable at all times when stored.

 Identify the settings for built-in accounts examined.

Modified p. 67 → 59

 Identify all locations where the application may store passwords.

Identify all locations where the application may store passwords.

Modified p. 67 → 59

<Report Findings Here>  For all locations and types of passwords, describe how payment application password files were observed during storage to verify passwords are unreadable at all times during storage.

<Report Findings Here> For all locations and types of passwords, describe how payment application password files were observed during storage to verify passwords are unreadable at all times during storage.

Modified p. 67 → 59

<Report Findings Here>  Identify the strong cryptography verified to be used to render passwords unreadable at all times during storage.

<Report Findings Here> Identify the strong cryptography verified to be used to render passwords unreadable at all times during storage.

Modified p. 67 → 59

 By default, all application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account.

• By default, all application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account.

Modified p. 67 → 59

 By default, all application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

• By default, all application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

Modified p. 67 → 59

~~ All application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account. ~~ All application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

• All application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

Modified p. 67 → 59

<Report Findings Here> Describe how settings for built-in accounts were examined to verify that by completion of the installation process, all application/service accounts have:

Identify the settings for built-in accounts examined. <Report Findings Here> Describe how settings for built-in accounts were examined to verify that by completion of the installation process, all application/service accounts have:

Modified p. 67 → 59

<Report Findings Here> 3.4.1.b Test all application functionality that results in changes to built-in For all types of changes performed, describe the account settings tested to verify that, upon completion of the change, all application/service accounts have:

<Report Findings Here> 3.4.1.b Test all application functionality that results in changes to built-in accounts, including those that result in user accounts reverting to default settings, changes to existing account For all types of changes performed, describe the account settings tested to verify that, upon completion of the change, all application/service accounts have:

Removed p. 68

Assessor’s Response Summary of Findings (check one) Not Applicable accounts, including those that result in user accounts reverting to default settings, changes to existing account settings, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine settings for built-in accounts and test application functionality to verify that upon completion of the change:

 All application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account.  All application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

Modified p. 68 → 60

~~<Report Findings Here>~~  Minimum level of privilege assigned for each function/resource as needed for the application/service account.

 Minimum level of privilege assigned for each function/resource as needed for the application/service account.

Removed p. 69

Assessor’s Response Summary of Findings (check one) Not Applicable 4.1 At the completion of the installation process, the “out of the box” default installation of the payment application must log all user access and be able to link all activities to individual users.

 How to install the application so that logs are configured and enabled by default upon completion of the installation process.  How to set PCI DSS-compliant log settings, per PA-DSS Requirements 4.2, 4.3 and 4.4 below, for any logging options that are configurable by the customer after installation.  Logs should not be disabled and doing so will result in non- compliance with PCI DSS.  How to configure PCI DSS- compliant log settings for any third- party software components packaged with or required by the payment application, for any logging options that are configurable by the customer after installation.

Modified p. 69 → 61

~~(continued on next page)~~ Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Modified p. 69 → 61

Requirement 4: Log payment application activity PA-DSS Requirements and Testing Procedures Reporting Instruction ~~ROV~~ Reporting Details:

Requirement 4: Log payment application activity PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 4.1 At the completion of the installation process, the “out of the box” default installation of the payment application must log all user access and be able to link all activities to individual users.

Modified p. 69 → 61

 Describe the testing performed on the installed application to verify that payment application audit trails are automatically enabled upon installation.

Describe the testing performed on the installed application to verify that payment application audit trails are automatically enabled upon installation.

Modified p. 69 → 61

<Report Findings Here>  Logs should not be disabled and doing so will result in ~~non-compliance~~ with PCI DSS.

<Report Findings Here>  Logs should not be disabled and doing so will result in non- compliance with PCI DSS.

Modified p. 69 → 61

<Report Findings Here>  How to configure PCI-compliant log settings for any ~~third-party~~ software components packaged with or required by the payment application, for any logging options that are configurable by the customer after installation.

<Report Findings Here>  How to configure PCI-compliant log settings for any third- party software components packaged with or required by the payment application, for any logging options that are configurable by the customer after installation.

Removed p. 70

<Report Findings Here>  Describe how the PA-DSS Implementation Guide includes instructions on how to facilitate centralized logging, as defined in PA-DSS Requirement 4.4.

Modified p. 70 → 61

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable ~~ Describe how the PA-DSS Implementation Guide includes instructions on how to set PCI ~~DSS- compliant~~ log settings to reconstruct the events defined in PA-DSS Requirements ~~4.2.1-4.2.7.~~

<Report Findings Here> Describe how the PA-DSS Implementation Guide includes instructions on how to set PCI DSS-compliant log settings to reconstruct the events defined in PA-DSS Requirements 4.2.1- 4.2.7.

Modified p. 70 → 62

<Report Findings Here>  Describe how the PA-DSS Implementation Guide includes instructions on how to ~~record at least the audit trail entries identified~~ in PA-DSS ~~Requirements 4.3.1-4.3.6, for each audited event.~~

<Report Findings Here> Describe how the PA-DSS Implementation Guide includes instructions on how to facilitate centralized logging, as defined in PA-DSS Requirement 4.4.

Modified p. 70 → 62

<Report Findings Here>  Describe the audit log output examined. <Report Findings Here>  Describe the testing performed, including examination of audit log settings and audit log output, to verify that all individual access to cardholder data through the payment application is logged.

<Report Findings Here> Describe the audit log output examined. <Report Findings Here> Describe the testing performed, including examination of audit log settings and audit log output, to verify that all individual access to cardholder data through the payment application is logged.

Removed p. 71

Assessor’s Response Summary of Findings (check one) Not Applicable 4.2.2 All actions taken by any individual with administrative privileges as assigned in the application 4.2.2 Verify actions taken by any individual with administrative privileges to the payment application are logged.

Modified p. 71 → 62

<Report Findings Here>  Describe the audit log output examined. <Report Findings Here>  Describe the testing performed, including examination of audit log settings and audit log output, to verify that actions taken by any individual with administrative privileges to the payment application are logged.

<Report Findings Here> Describe the audit log output examined. <Report Findings Here> Describe the testing performed, including examination of audit log settings and audit log output, to verify that actions taken by any individual with administrative privileges to the payment application are logged.

Modified p. 71 → 62

<Report Findings Here> 4.2.3 Access to application audit trails managed by or within the application 4.2.3 Verify access to application audit trails managed by or within the application is logged.

<Report Findings Here> 4.2.3 Access to application audit trails managed by or within the application ☐ ☐ ☐ 4.2.3 Verify access to application audit trails managed by or within the application is logged.

Modified p. 71 → 63

<Report Findings Here> 4.2.4 Invalid logical access attempts 4.2.4 Verify invalid logical access attempts are logged.

<Report Findings Here> 4.2.4 Invalid logical access attempts ☐ ☐ ☐ 4.2.4 Verify invalid logical access attempts are logged.

Modified p. 71 → 63

<Report Findings Here>  Describe the audit log output examined. <Report Findings Here>  Describe the testing performed, including examination of audit log settings and audit log output, to verify that invalid logical access attempts are logged.

<Report Findings Here> Describe the audit log output examined. <Report Findings Here> Describe the testing performed, including examination of audit log settings and audit log output, to verify that invalid logical access attempts are logged.

Modified p. 71 → 64

<Report Findings Here>  Describe the audit log output examined. <Report Findings Here>  Describe the testing performed, including examination of audit log settings and audit log output, to verify that ~~access to application audit trails managed~~ by ~~or within~~ the application is logged.

<Report Findings Here> Describe the audit log output examined. <Report Findings Here> Describe the testing performed, including examination of audit log settings and audit log output, to verify that creation of system-level objects within or by the application is logged.

Modified p. 72 → 63

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 4.2.5 Use of, and changes to the application’s identification and authentication mechanisms (including but not limited to creation of new accounts, elevation of privileges, etc.), and all changes, additions, deletions to application accounts with root or administrative privileges 4.2.5 Verify use of and changes to the payment application’s identification and authentication mechanisms (including but not limited to creation of new accounts, elevation of privileges, etc.), and all changes, additions, deletions to …

<Report Findings Here> 4.2.5 Use of, and changes to the application’s identification and authentication mechanisms (including but not limited to creation of new accounts, elevation of privileges, etc.), and all changes, additions, deletions to application accounts with root or administrative privileges ☐ ☐ ☐ 4.2.5 Verify use of and changes to the payment application’s identification and authentication mechanisms (including but not limited to creation of new accounts, elevation of privileges, etc.), and all changes, additions, deletions to application accounts with …

Modified p. 72 → 63

<Report Findings Here>  Describe the audit log output examined. <Report Findings Here>  Describe the testing performed, including examination of audit log settings and audit log output, to verify that use of the payment application’s identification mechanisms and all changes, additions, deletions to application accounts with root or administrative privileges are logged.

<Report Findings Here> Describe the audit log output examined. <Report Findings Here> Describe the testing performed, including examination of audit log settings and audit log output, to verify that use of the payment application’s identification mechanisms and all changes, additions, deletions to application accounts with root or administrative privileges are logged.

Modified p. 72 → 63

<Report Findings Here>  Describe the testing performed, including examination of audit log settings and audit log output, to verify that changes to the payment application’s authentication mechanisms and all changes, additions, deletions to application accounts with root or administrative privileges are logged.

<Report Findings Here> Describe the testing performed, including examination of audit log settings and audit log output, to verify that changes to the payment application’s authentication mechanisms and all changes, additions, deletions to application accounts with root or administrative privileges are logged.

Modified p. 72 → 63

<Report Findings Here> 4.2.6 Initialization, stopping or pausing of the application audit logs 4.2.6 Verify the following are logged:

<Report Findings Here> 4.2.6 Initialization, stopping or pausing of the application audit logs ☐ ☐ ☐ 4.2.6 Verify the following are logged:

Modified p. 72 → 63

 Initialization of application audit logs. ~~ Stopping or pausing of application audit logs.~~

• Initialization of application audit logs.

Modified p. 72 → 64

~~(continued on next page) ~~ Identify the payment application audit log settings examined.

Identify the payment application audit log settings examined.

Modified p. 72 → 64

<Report Findings Here> ~~ Describe the audit log output examined. <Report Findings Here> ~~ Describe the testing performed, including examination of audit log settings and audit log output, to verify that ~~initialization~~ of application audit logs is logged.

<Report Findings Here> Describe the testing performed, including examination of audit log settings and audit log output, to verify that stopping or pausing of application audit logs is logged.

Removed p. 73

Assessor’s Response Summary of Findings (check one) Not Applicable  Describe the testing performed, including examination of audit log settings and audit log output, to verify that stopping or pausing of application audit logs is logged.

<Report Findings Here>  Describe the audit log output examined. <Report Findings Here>  Describe the testing performed, including examination of audit log settings and audit log output, to verify that creation of system-level objects within or by the application is logged.

Modified p. 73 → 63

 Identify the payment application audit log settings examined.

• Stopping or pausing of application audit Identify the payment application audit log settings examined.

Modified p. 73 → 64

<Report Findings Here> 4.2.7 Creation and deletion of system-level objects within or by the application 4.2.7 Verify the creation and deletion of ~~system-level~~ objects within or by the application is logged.

<Report Findings Here> 4.2.7 Creation and deletion of system-level objects within or by the application ☐ ☐ ☐ 4.2.7 Verify the creation and deletion of system- level objects within or by the application is logged.

Modified p. 73 → 64

<Report Findings Here>  Describe the audit log output examined. <Report Findings Here>  For each auditable event from ~~4.2.1- 4.2.7,~~ describe the testing performed, including examination of audit log settings and audit log output, to verify that user identification is included in log entries.

<Report Findings Here> Describe the audit log output examined. <Report Findings Here> For each auditable event from 4.2.1-4.2.7, describe the testing performed, including examination of audit log settings and audit log output, to verify that user identification is included in log entries.

Modified p. 74 → 64

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 4.3.2 Type of event 4.3.2 Verify type of event is included in log entries.

<Report Findings Here> 4.3.2 Type of event ☐ ☐ ☐ 4.3.2 Verify type of event is included in log entries.

Modified p. 74 → 65

<Report Findings Here>  Describe the audit log output examined. <Report Findings Here>  For each auditable event from ~~4.2.1- 4.2.7,~~ describe the testing performed, including examination of audit log settings and audit log output, to verify that ~~type~~ of event is included in log entries.

<Report Findings Here> Describe the audit log output examined. <Report Findings Here> For each auditable event from 4.2.1-4.2.7, describe the testing performed, including examination of audit log settings and audit log output, to verify that origination of event is included in log entries.

Modified p. 74 → 65

<Report Findings Here> 4.3.3 Date and time 4.3.3 Verify date and time stamp is included in log entries.

<Report Findings Here> 4.3.3 Date and time ☐ ☐ ☐ 4.3.3 Verify date and time stamp is included in log entries.

Modified p. 74 → 65

<Report Findings Here>  Describe the audit log output examined. <Report Findings Here>  For each auditable event from ~~4.2.1- 4.2.7,~~ describe the testing performed, including examination of audit log settings and audit log output, to verify that date and time stamp is included in log entries.

<Report Findings Here> Describe the audit log output examined. <Report Findings Here> For each auditable event from 4.2.1-4.2.7, describe the testing performed, including examination of audit log settings and audit log output, to verify that date and time stamp is included in log entries.

Modified p. 74 → 65

<Report Findings Here> 4.3.4 Success or failure indication 4.3.4 Verify success or failure indication is included in log entries.

<Report Findings Here> 4.3.4 Success or failure indication ☐ ☐ ☐ 4.3.4 Verify success or failure indication is included in log entries.

Modified p. 74 → 65

<Report Findings Here>  Describe the audit log output examined. <Report Findings Here>  For each auditable event from ~~4.2.1- 4.2.7,~~ describe the testing performed, including examination of audit log settings and audit log output, to verify that success or failure indication is included in log entries.

<Report Findings Here> Describe the audit log output examined. <Report Findings Here> For each auditable event from 4.2.1-4.2.7, describe the testing performed, including examination of audit log settings and audit log output, to verify that success or failure indication is included in log entries.

Removed p. 75

<Report Findings Here>  Describe the audit log output examined. <Report Findings Here>  For each auditable event from 4.2.1- 4.2.7, describe the testing performed, including examination of audit log settings and audit log output, to verify that identity or name of affected data, system component, or resources is included in log entries.

Modified p. 75 → 65

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 4.3.5 Origination of event 4.3.5 Verify origination of event is included in log entries.

<Report Findings Here> 4.3.5 Origination of event ☐ ☐ ☐ 4.3.5 Verify origination of event is included in log entries.

Modified p. 75 → 65

<Report Findings Here> 4.3.6 Identity or name of affected data, system component, or resource ~~4.3.6 Verify identity or name of affected data, system component, or resources is included in log entries.~~

<Report Findings Here> 4.3.6 Identity or name of affected data, system component, or resource ☐ ☐ ☐

Modified p. 75 → 66

<Report Findings Here>  Describe the audit log output examined. <Report Findings Here>  For each auditable event from ~~4.2.1- 4.2.7,~~ describe the testing performed, including examination of audit log settings and audit log output, to verify that ~~origination~~ of ~~event~~ is included in log entries.

<Report Findings Here> Describe the audit log output examined. <Report Findings Here> For each auditable event from 4.2.1-4.2.7, describe the testing performed, including examination of audit log settings and audit log output, to verify that identity or name of affected data, system component, or resources is included in log entries.

Modified p. 76 → 66

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 4.4. Payment application must facilitate centralized logging.

<Report Findings Here> 4.4. Payment application must facilitate centralized logging.

Modified p. 76 → 66

~~ Logging via industry standard log file mechanisms such as Common Log File System (CLFS), Syslog, delimited text, etc. ~~ Providing functionality and documentation to convert the application’s proprietary log format into industry standard log formats suitable for prompt, centralized logging.

• Providing functionality and documentation to convert the application’s proprietary log format into industry standard log formats suitable for prompt, centralized logging.

Modified p. 76 → 66

~~ A description of which centralized logging mechanisms are supported. ~~ Instructions and procedures for incorporating the payment application logs into a centralized logging environment.

• Instructions and procedures for incorporating the payment application logs into a centralized logging environment.

Modified p. 76 → 66

<Report Findings Here> 4.4.b Install and configure the payment application according to the PA-DSS Implementation Guide to verify that the instructions are accurate, and that functionality that facilitates a ~~merchant’s~~ ability to assimilate logs into their centralized log server is provided.

<Report Findings Here> 4.4.b Install and configure the payment application according to the PA-DSS Implementation Guide to verify that the instructions are accurate, and that functionality that facilitates a customer’s ability to assimilate logs into their centralized log server is provided.

Modified p. 76 → 66

<Report Findings Here>  Functionality that facilitates a ~~merchant’s~~ ability to assimilate logs into their centralized log server is provided.

<Report Findings Here>  Functionality that facilitates a customer’s ability to assimilate logs into their centralized log server is provided.

Removed p. 77

Assessor’s Response Summary of Findings (check one) Not Applicable 5.1 The software vendor has defined and implemented a formal process for secure development of payment applications, which includes:

 Incorporating information security throughout the software-development life cycle.  Developing payment applications in accordance with PCI DSS Requirements.  Developing payment applications in accordance with PA-DSS Requirements.

Modified p. 77 → 67

Requirement 5: Develop secure payment applications PA-DSS Requirements and Testing Procedures Reporting Instruction ~~ROV~~ Reporting Details:

Requirement 5: Develop secure payment applications PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 5.1 The software vendor has defined and implemented a formal process for secure development of payment applications, which includes:

Modified p. 77 → 67

 Payment applications are developed in accordance with PCI DSS and PA-DSS (for example, secure authentication and logging).  Development processes are based on industry standards and/or best practices.  Information security is incorporated throughout the software development life cycle.  Security reviews are performed prior to release of an application or application update.

• Payment applications are developed in accordance with PCI DSS and PA-DSS (for example, secure authentication and logging). • Development processes are based on industry standards and/or best practices. • Information security is incorporated throughout the software development life cycle. • Security reviews are performed prior to release of an application or application update.

Modified p. 77 → 67

 Identify the document that defines vendor ~~software-development~~ processes.

Identify the document that defines vendor software- development processes.

Modified p. 77 → 67

<Report Findings Here>  Identify the industry standards and/or best practices the processes are verified to be based upon.

<Report Findings Here> Identify the industry standards and/or best practices the processes are verified to be based upon.

Modified p. 77 → 67

<Report Findings Here> 5.1.b Verify documented ~~software- development~~ processes include procedures for the following:

<Report Findings Here> 5.1.b Verify documented software-development processes include procedures for the following:

Modified p. 77 → 67

~~ Incorporating information security throughout the software development life cycle. ~~ Developing payment applications in accordance with PCI DSS and ~~PA- DSS~~ Requirements.

• Developing payment applications in accordance with PCI DSS and PA-DSS Requirements.

Modified p. 77 → 67

 Identify the documented ~~software- development~~ processes reviewed and verified to include procedures for the following:

Identify the documented software-development processes reviewed and verified to include procedures for the following:

Removed p. 78

 Information security is incorporated throughout the software development life cycle.  Payment applications are developed in accordance with PCI DSS and PA-DSS Requirements.  Security reviews are performed at defined intervals throughout the development process and prior to release, to ensure that security objectives, including PCI DSS and PA-DSS requirements, are being met.

 Identify the software developers interviewed for this testing procedure who confirm that documented software development processes from 5.1.a, 5.1.b, and 5.1.c are followed such that:

 Information security is incorporated throughout the software development life cycle.  Payment applications are developed in accordance with PCI DSS Requirements.  Payment applications are developed in accordance with PA-DSS Requirements.  Security reviews are performed prior to release, to ensure that security objectives, including PCI DSS and PA-DSS requirements, are being met.

Modified p. 78 → 67

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 5.1.c Verify documented ~~software- development~~ processes include:

<Report Findings Here> 5.1.c Verify documented software-development processes include:

Modified p. 78 → 67

~~ Defined security reviews prior to release of an application or application update. ~~ Procedures for security reviews to be performed to ensure the security objectives of PCI DSS and PA-DSS are being met.

• Procedures for security reviews to be performed to ensure the security objectives of PCI DSS and PA-DSS are being met.

Modified p. 78 → 67

~~ Defined security reviews during the development process and prior to release of an application or application update. ~~ Procedures for security reviews to be performed, to ensure the security objectives of PCI DSS and PA-DSS are being met.

• Procedures for security reviews to be performed, to ensure the security objectives of PCI DSS and PA-DSS are being met.

Modified p. 78 → 68

~~<Report Findings Here> 5.1.d Interview~~ software developers to confirm that documented processes are followed such that:

Identify the software developers interviewed for this testing procedure who confirm that documented software development processes from 5.1.a, 5.1.b, and 5.1.c are followed such that:

Modified p. 79 → 68

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 5.1.1 Live PANs are not used for testing or development.

<Report Findings Here> 5.1.1 Live PANs are not used for testing or development.

Modified p. 79 → 68

~~ Procedures to ensure live PANs are not used for testing. ~~ Procedures to ensure live PANs are not used for development.

• Procedures to ensure live PANs are not used for development.

Modified p. 79 → 68

 Live PANs are not used for testing. <Report Findings Here> ~~ Live PANs are not used for development.~~

 Live PANs are not used for testing. <Report Findings Here>

Modified p. 79 → 68

~~<Report Findings Here>  Identify the personnel interviewed for this testing procedure who confirm that live PANS are not used for  Testing ~~ Development <Report Findings Here> 5.1.1.c Examine samples of test data to verify live PANs are not used for testing or ~~development.~~

• Development <Report Findings Here> 5.1.1.c Examine samples of test data to verify live PANs are not used for testing or Describe the samples of test data examined to verify that:

Modified p. 79 → 68

 Live PANs are not used for testing. <Report Findings Here>  Live PANs are not used for development.

 Live PANs are not used for testing. <Report Findings Here>  Live PANs are not used for development. <Report Findings Here> Identify the personnel interviewed for this testing procedure who confirm that live PANS are not used for

Removed p. 80

Assessor’s Response Summary of Findings (check one) Not Applicable 5.1.2 Test data and accounts are removed before release to customer.

Modified p. 80 → 69

 To ensure test data is removed before the payment application is released to customers.  To ensure accounts are removed before the payment application is released to customers.

• To ensure test data is • removed before the payment application is released to customers. • To ensure accounts are • removed before the payment application is released to customers.

Modified p. 80 → 69

<Report Findings Here>  Identify the personnel interviewed for this testing procedure who confirm that:

<Report Findings Here> Identify the personnel interviewed for this testing procedure who confirm that:

Modified p. 80 → 69

~~ Test data is~~ removed before the payment application is released to customers. ~~ Test accounts are removed before the payment application is released to customers.~~

• removed before the payment application is released to customers.

Modified p. 81 → 69

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 5.1.3 Custom payment application accounts, user IDs, and passwords are removed before payment applications are released to customers Aligns with PCI DSS Requirement 6.3.1 5.1.3.a Review software-development processes to verify they include procedures to ensure custom payment application accounts, user IDs, and passwords are removed before payment application is released to customers.

<Report Findings Here> 5.1.3 Custom payment application accounts, user IDs, and passwords are removed before payment applications are released to customers Aligns with PCI DSS Requirement 6.3.1

Modified p. 81 → 70

 Identify the documented ~~software- development~~ processes reviewed and verified to include procedures for the following:

Identify the documented software-development processes reviewed and verified to include procedures for the following:

Modified p. 81 → 70

 To ensure custom payment application accounts are removed before payment application is released to customers.  To ensure user IDs are removed before payment application is released to customers.  To ensure passwords are removed before payment application is released to customers.

• To ensure custom payment application accounts are • removed before payment application is released to customers. • To ensure user IDs are • removed before payment application is released to customers. • To ensure passwords are • removed before payment application is released to customers.

Modified p. 81 → 70

~~(continued on next page)~~ Describe the testing processes observed to verify that:

Describe the testing processes observed to verify that:

Modified p. 82 → 70

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable ~~ Identify the personnel interviewed for this testing procedure who confirm that:

<Report Findings Here> Identify the personnel interviewed for this testing procedure who confirm that:

Modified p. 82 → 70

 Custom payment application accounts are

• Custom payment application accounts are

Modified p. 82 → 70

• removed before the payment application is released to customers. ~~ User IDs are~~

• removed before the payment application is released to customers.

Modified p. 82 → 70

• removed before the payment application is released to customers. ~~ Passwords are removed before the payment application is released to customers.~~

• removed before the payment application is released to customers.

Removed p. 83

Assessor’s Response Summary of Findings (check one) Not Applicable 5.1.4 Payment application code is reviewed prior to release to customers after any significant change, to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:

Modified p. 83 → 71

 Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code-review techniques and secure coding practices.  Code reviews ensure code is developed according to secure coding guidelines. (See PA-DSS Requirement 5.2.)  Appropriate corrections are implemented prior to release.  Code-review results are reviewed and approved by management prior to release.  Documented code-review results include management approval, code author, and code reviewer, and what corrections were implemented prior …

• Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code-review techniques and secure coding practices. • Code reviews ensure code is developed according to secure coding guidelines. (See PA-DSS Requirement 5.2.) • Appropriate corrections are implemented prior to release. • Code-review results are reviewed and approved by management prior to release. • Documented code-review results include management approval, code author, and code reviewer, and what corrections were implemented prior …

Removed p. 84

 Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code-review techniques and secure coding practices.  Code reviews ensure code is developed according to secure coding guidelines. (See PA-DSS Requirement 5.2.)  Appropriate corrections are implemented prior to release.  Code-review results are reviewed and approved by management prior to release.  Code-review results are documented including management approval, code author and code reviewer, and what corrections were implemented prior to release.

<Report Findings Here>  Identify the documented software- development processes reviewed and verified to include procedures for the following:

 Code changes are reviewed by individuals other than the originating code author.  Code changes are reviewed by individuals who are knowledgeable in code review techniques.  Code changes are reviewed by individuals who are knowledgeable in secure coding practices.  Code reviews ensure code is developed according to …

Modified p. 84 → 71

~~Assessor’s Response Summary of Findings (check one) Not Applicable~~ 5.1.4.a Examine written ~~software- development~~ procedures and interview responsible personnel to verify the vendor performs code reviews for all significant application code changes (either using manual or automated processes) as follows:

Aligns with PCI DSS Requirement 6.3.2 5.1.4.a Examine written software-development procedures and interview responsible personnel to verify the vendor performs code reviews for all significant application code changes (either using manual or automated processes) as follows:

Modified p. 84 → 72

~~(continued on next page)  Identify whether~~ the vendor uses a manual or automated process to perform code reviews for all significant application code changes.

• Whether the vendor uses a manual or automated process to perform code reviews for all significant application code changes.

Removed p. 85

Assessor’s Response Summary of Findings (check one) Not Applicable  Identify the responsible personnel interviewed for this testing procedure who confirm that vendor performs code reviews for all significant application code changes (either using manual or automated processes) as follows:

 Whether the vendor uses a manual or automated process to perform code reviews for all significant application code changes.  Code changes are reviewed by individuals other than the originating code author.  Code changes are reviewed by individuals who are knowledgeable in code review techniques.  Code changes are reviewed by individuals who are knowledgeable in secure coding practices.  Code reviews ensure code is developed according to secure coding guidelines.  Appropriate corrections are implemented prior to release.  Code-review results are reviewed by management prior to release.  Code-review results are approved by management prior to release.

(continued on next page)  Identify the sample of code changes …

Modified p. 85 → 72

 Code reviews were performed by a knowledgeable individual other than the code author.

• Code reviews were performed by a knowledgeable individual other than the code author.

Modified p. 85 → 72

<Report Findings Here> Describe the code-review results for the sample of code changes observed to verify:

Identify the sample of code changes examined. <Report Findings Here> Describe the code-review results for the sample of code changes observed to verify:

Removed p. 86

Assessor’s Response Summary of Findings (check one) Not Applicable  Code reviews were developed according to secure coding guidelines.  Appropriate corrections were implemented prior to release.  Code-review results were reviewed and approved by management prior to release.

<Report Findings Here>  Appropriate corrections are implemented prior to release.

 Identify the written software- development procedures reviewed to confirm that the vendor maintains secure source control practices to verify integrity of source code during the development process.

Modified p. 86 → 72

 Code changes are reviewed by individuals who are knowledgeable in code review techniques.

<Report Findings Here>  Code changes are reviewed by individuals who are knowledgeable in code review techniques.

Modified p. 86 → 73

<Report Findings Here> 5.1.5 Secure source-control practices are implemented to verify integrity of source code during the development process.

<Report Findings Here> 5.1.5 Secure source-control practices are implemented to verify integrity of source code during the development process. ☐ ☐ ☐ 5.1.5.a Examine written software-development procedures and interview responsible personnel to verify the vendor maintains secure source control practices to verify integrity of source code during the development process.

Modified p. 86 → 73

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

Identify the written software-development procedures reviewed to confirm that the vendor maintains secure source control practices to verify integrity of source code during the development process.

Modified p. 86 → 73

<Report Findings Here>  Identify the responsible personnel interviewed for this testing procedure who confirm that the vendor maintains secure source control practices to verify integrity of source code during the development process.

<Report Findings Here> Identify the responsible personnel interviewed for this testing procedure who confirm that the vendor maintains secure source control practices to verify integrity of source code during the development process.

Modified p. 86 → 73

 Identify the mechanisms for securing source code examined to verify that the integrity of source code is maintained during the development process.

Identify the mechanisms for securing source code examined to verify that the integrity of source code is maintained during the development process.

Modified p. 86 → 73

<Report Findings Here>  Describe the procedures for securing source code observed to verify that the integrity of source code is maintained during the development process.

<Report Findings Here> Describe the procedures for securing source code observed to verify that the integrity of source code is maintained during the development process.

Removed p. 87

 Identify the software development processes reviewed and verified as having secure coding techniques defined that include:

Modified p. 87 → 73

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 5.1.6 Payment applications are developed according to industry best practices for secure coding techniques, including:

<Report Findings Here> 5.1.6 Payment applications are developed according to industry best practices for secure coding techniques, including:

Modified p. 87 → 73

~~ Developing with least privilege for the application environment.  Developing with fail-safe defaults (all execution is by default denied unless specified within initial design). ~~ Developing for all access point considerations, including input variances such as multi-channel input to the application.

• Developing for all access point considerations, including input variances such as multi-channel input to the application.

Modified p. 87 → 74

~~ Developing with least privilege for the application environment.  Developing with fail-safe defaults (all execution is by default denied unless specified within initial design). ~~ Developing for all access point considerations, including input variances such as multi-channel input to the application.

• Developing for all access point considerations, including input variances such as multi-channel input to the application.

Modified p. 87 → 74

~~5.1.6.a Examine software-development~~ processes ~~to verify that~~ secure coding techniques ~~are~~ defined ~~and~~ include:

Identify the software development processes reviewed and verified as having secure coding techniques defined that include:

Modified p. 87 → 74

~~ Developing with least privilege for the application environment.  Developing with fail-safe default (all execution is by default denied unless specified within initial design). ~~ Developing for all access point considerations, including input variances such as multi-channel input to the application.

• Developing for all access point considerations, including input variances such as multi-channel input to the application.

Modified p. 87 → 74

~~ Developing with least privilege for the application environment.  Developing with fail-safe default (all execution is by default denied unless specified within initial design). ~~ Developing for all access point considerations, including input variances such as multi-channel input to the application.

• Developing for all access point considerations, including input variances such as multi-channel input to the application.

Modified p. 87 → 74

<Report Findings Here> For the interview, summarize the relevant details discussed that verify that applications are developed according to industry best practices for secure coding techniques, including:

Identify the developers interviewed for this testing procedure. <Report Findings Here> For the interview, summarize the relevant details discussed that verify that applications are developed according to industry best practices for secure coding techniques, including:

Removed p. 88

 Identify the documented coding techniques reviewed to verify coding techniques document how PAN and/or SAD are handled in memory.

 Identify the documented software- development processes reviewed to verify that processes require training in secure development practices for application developers as applicable for the developer’s job function and technology used.

Modified p. 88 → 74

~~Assessor’s Response Summary of Findings (check one) Not Applicable 5.1.6.1 Coding~~ techniques ~~include documentation of~~ how PAN and/or SAD are handled in memory.

Identify the documented coding techniques reviewed to verify coding techniques document how PAN and/or SAD are handled in memory.

Modified p. 88 → 74

5.1.6.1.a Examine coding techniques to verify they include documentation of how PAN and/or SAD are handled in memory.

<Report Findings Here> 5.1.6.1 Coding techniques include documentation of how PAN and/or SAD are handled in memory. ☐ ☐ ☐ 5.1.6.1.a Examine coding techniques to verify they include documentation of how PAN and/or SAD are handled in memory.

Modified p. 88 → 74

<Report Findings Here>  For the interview, summarize the relevant details discussed that verify that developers consider how PAN/SAD is handled in memory during the application-development process.

Identify the developers interviewed for this testing procedure. <Report Findings Here> For the interview, summarize the relevant details discussed that verify that developers consider how PAN/SAD is handled in memory during the application-development process.

Modified p. 88 → 75

 Identify the developers interviewed for this testing procedure.

Identify the developers interviewed for this testing procedure. <Report Findings Here> For the interview, summarize the relevant details discussed that verify that:

Modified p. 88 → 75

~~<Report Findings Here> 5.1.7 Provide~~ training in secure development practices for application ~~developers,~~ as applicable for the developer’s job function and technology ~~used, for example:~~

5.1.7a 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. 88 → 75

~~ Secure application design ~~ Secure coding techniques to avoid common coding vulnerabilities (for example, vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.) ~~ Managing sensitive data in memory  Code reviews  Security testing (for example, penetration-testing techniques)  Risk-assessment techniques~~

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

Modified p. 88 → 75

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.

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

Modified p. 88 → 75

~~5.1.7a 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.

Identify the documented software-development processes reviewed to verify that processes require training in secure development practices for application developers as applicable for the developer’s job function and technology used.

Removed p. 89

 Identify the training material examined to verify that training is updated as needed to address new development technologies and methods used.

<Report Findings Here>  Identify the developers interviewed for this testing procedure.

<Report Findings Here>  For the interview, summarize the relevant details discussed that verify that training is updated as needed to address new development technologies and methods used.

Modified p. 89 → 75

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 5.1.7.b Interview a sample of developers to verify that they are knowledgeable in secure development practices and coding techniques, as applicable to the technology used.

<Report Findings Here> 5.1.7.b Interview a sample of developers to verify that they are knowledgeable in secure development practices and coding techniques, as applicable to the technology used.

Modified p. 89 → 75

 Identify the sample of records of training examined <Report Findings Here>  Describe how the sample of records of training was examined to verify that all application developers receive training as applicable for their job function and technology used.

Identify the sample of records of training examined <Report Findings Here> Describe how the sample of records of training was examined to verify that all application developers receive training as applicable for their job function and technology used.

Modified p. 89 → 75

<Report Findings Here> 5.1.7.1 Update training as needed to address new development technologies and methods used.

<Report Findings Here> 5.1.7.1 Update training as needed to address new development technologies and methods used. ☐ ☐ ☐ 5.1.7.1 Examine training materials and interview a sample of developers to verify that training is updated as needed to address new development Identify the training material examined to verify that training is updated as needed to address new development technologies and methods used.

Removed p. 90

 Prevent cryptographic flaws.  Use strong cryptographic algorithms and keys.

Modified p. 90 → 76

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 5.2 Develop all payment applications to prevent common coding vulnerabilities in software-development processes:

<Report Findings Here> 5.2 Develop all payment applications to prevent common coding vulnerabilities in software-development processes:

Modified p. 90 → 76

 Validating input to verify user data cannot modify meaning of commands and queries. ~~ Utilizing parameterized queries.~~

• Validating input to verify user data cannot modify meaning of commands and queries.

Modified p. 90 → 76

 For 5.2.1•5.2.10, describe the penetration testing techniques used, including whether manual or automated testing was used.

For 5.2.1•5.2.10, describe the penetration testing techniques used, including whether manual or automated testing was used.

Modified p. 90 → 76

<Report Findings Here>  Describe how the penetration testing results verified that coding techniques have addressed injection flaws, particularly SQL injection.

<Report Findings Here> Describe how the penetration testing results verified that coding techniques have addressed injection flaws, particularly SQL injection.

Modified p. 90 → 76

<Report Findings Here> 5.2.2 Buffer Overflow 5.2.2 Buffer Overflows are addressed by coding techniques that include:

<Report Findings Here> 5.2.2 Buffer Overflow ☐ ☐ ☐ 5.2.2 Buffer Overflows are addressed by coding techniques that include:

Modified p. 90 → 76

 Validating buffer boundaries. ~~ Truncating input strings.~~

• Validating buffer boundaries.

Modified p. 90 → 76

Describe how the penetration testing results verified that buffer overflows are addressed by coding techniques that include  Validating buffer boundaries. <Report Findings Here>  Truncating input strings. <Report Findings Here> 5.2.3 Insecure cryptographic storage 5.2.3 Insecure cryptographic storage is addressed by coding techniques that:

Describe how the penetration testing results verified that buffer overflows are addressed by coding techniques that include  Validating buffer boundaries. <Report Findings Here>  Truncating input strings. <Report Findings Here> 5.2.3 Insecure cryptographic storage ☐ ☐ ☐ 5.2.3 Insecure cryptographic storage is addressed by coding techniques that:

Modified p. 90 → 76

 Prevent cryptographic flaws. <Report Findings Here> ~~ Use strong cryptographic algorithms and keys.~~

 Prevent cryptographic flaws. <Report Findings Here>

Removed p. 91

Assessor’s Response Summary of Findings (check one) Not Applicable 5.2.4 Insecure communications 5.2.4 Insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications.

Modified p. 91 → 77

<Report Findings Here> 5.2.5 Improper error handling 5.2.5 Improper error handling is addressed by coding techniques that do not leak information via error messages (for example, by returning generic rather than specific error details).

 Properly authenticate all sensitive communications. <Report Findings Here>  Properly encrypt all sensitive communications. <Report Findings Here> 5.2.5 Improper error handling ☐ ☐ ☐ 5.2.5 Improper error handling is addressed by coding techniques that do not leak information via error messages (for example, by returning generic rather than specific error details).

Modified p. 91 → 77

 Describe how the penetration testing results verified that improper error handling is addressed by coding techniques that do not leak information via error messages.

Describe how the penetration testing results verified that improper error handling is addressed by coding techniques that do not leak information via error messages.

Modified p. 91 → 77

<Report Findings Here> 5.2.6 All “high risk” vulnerabilities as identified in the vulnerability identification process at PA-DSS Requirement 7.1 5.2.6 Coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PA-DSS Requirement 7.1  Describe how the penetration testing results verified that coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PA-DSS Requirement 7.1.

<Report Findings Here> 5.2.6 All “high risk” vulnerabilities as identified in the vulnerability identification process at PA-DSS Requirement 7.1 ☐ ☐ ☐ 5.2.6 Coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PA-DSS Requirement 7.1 Describe how the penetration testing results verified that coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PA-DSS Requirement 7.1.

Modified p. 91 → 77

~~ Validating all parameters before inclusion ~~ Utilizing context-sensitive escaping ~~ Identify~~ whether the payment application is web-based and/or includes web-based application interfaces (internal or external). (yes/no) If “no,” mark 5.2.7-5.2.10 as “not applicable.” <Report Findings Here> Describe how the penetration testing results verified that cross-site scripting (XSS) is addressed by coding techniques that include:

• Utilizing context-sensitive escaping Indicate whether the payment application is web-based and/or includes web-based application interfaces (internal or external). (yes/no) If “no,” mark 5.2.7-5.2.10 as “not applicable.” <Report Findings Here> Describe how the penetration testing results verified that cross-site scripting (XSS) is addressed by coding techniques that include:

Modified p. 91 → 77

 Validating all parameters before ~~inclusion.~~

• Validating all parameters before inclusion

Removed p. 92

Assessor’s Response Summary of Findings (check one) Not Applicable 5.2.8 Improper access control such as insecure direct object references, failure to restrict URL access, and directory traversal 5.2.8 Improper access control, such as insecure direct object references, failure to restrict URL access, and directory traversal is addressed by coding technique that include:

 Proper authentication of users.  Sanitizing input.  Not exposing internal object. references to users.  User interface does not permit. access to unauthorized functions.

Modified p. 92 → 78

 Proper authentication of users. <Report Findings Here>  Sanitizing input. <Report Findings Here>  Not exposing internal object references to users.

 Proper authentication of users. <Report Findings Here>  Sanitizing input. <Report Findings Here>  Not exposing internal object references to users. <Report Findings Here>  User interface does not permit access to unauthorized functions.

Modified p. 92 → 78

<Report Findings Here> 5.2.9 Cross-site request forgery (CSRF) 5.2.9 Cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers.

<Report Findings Here> 5.2.9 Cross-site request forgery (CSRF) ☐ ☐ ☐ 5.2.9 Cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers.

Modified p. 92 → 78

 Describe how the penetration testing results verified that cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers.

Describe how the penetration testing results verified that cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers.

Modified p. 92 → 78

<Report Findings Here> 5.2.10 Broken Authentication and session management 5.2.10 Broken authentication and session management is addressed via coding techniques that commonly include:

<Report Findings Here> 5.2.10 Broken Authentication and session management ☐ ☐ ☐ 5.2.10 Broken authentication and session management is addressed via coding techniques that commonly include:

Modified p. 92 → 78

~~ Flagging session tokens (for example cookies) as “secure.”  Not exposing session IDs in the URL. ~~ Incorporating appropriate time-outs and rotation of session IDs after a successful login.

• Incorporating appropriate time-outs and rotation of session IDs after a successful login.

Modified p. 92 → 78

 Describe how the penetration testing results verified that broken authentication and session management is addressed.

Describe how the penetration testing results verified that broken authentication and session management is addressed.

Removed p. 93

 Payment applications are developed in accordance with PCI DSS and PA- DSS.  Development processes are based on industry standards and/or best practices.  Information security is incorporated throughout the software development life cycle.  Security reviews are performed prior to release of an application or application update.

Modified p. 93 → 79

Aligns with PCI DSS Requirement 6.4.5 5.3.a Examine the vendor’s ~~change- control~~ procedures for software modifications, and:

Aligns with PCI DSS Requirement 6.4.5 5.3.a Examine the vendor’s change-control procedures for software modifications, and:

Modified p. 93 → 79

 Verify the procedures follow documented software-development processes as defined in Requirement 5.1. ~~ Verify that the procedures require items 5.3.1•5.3.4 below.~~

• Verify the procedures follow documented software-development processes as defined in Requirement 5.1.

Modified p. 93 → 79

 Identify the document that defines the vendor’s ~~change-control~~ procedures for software modifications, and which was verified to follow documented ~~software- development~~ processes as defined in Requirement 5.1:

Identify the document that defines the vendor’s change- control procedures for software modifications, and which was verified to follow documented software-development processes as defined in Requirement 5.1:

Modified p. 93 → 79

<Report Findings Here>  Identify the document that defines the vendor’s ~~change-control~~ procedures for software modifications, and which was verified to require items 5.3.1-5.3.4:

<Report Findings Here> Identify the document that defines the vendor’s change- control procedures for software modifications, and which was verified to require items 5.3.1-5.3.4:

Modified p. 93 → 79

~~ Documentation of impact.  Documented approval of change by appropriate authorized parties. ~~ Functionality testing to verify that the change does not adversely impact the security of the system. ~~ Back-out or product de-installation procedures.~~

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

Modified p. 94 → 79

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 5.3.b Interview developers to determine recent payment application changes. Examine recent payment application changes and trace them back to related change-control documentation. For each change examined, verify the following was documented according to the ~~change-control~~ procedures:

<Report Findings Here> 5.3.b Interview developers to determine recent payment application changes. Examine recent payment application changes and trace them back to related change-control documentation. For each change examined, verify the following was documented according to the change- control procedures:

Modified p. 94 → 79

 Identify recent payment application changes.

Identify the developers interviewed to determine recent payment application changes.

Modified p. 94 → 79

<Report Findings Here>  Identify the recent payment application changes observed for 5.3.1-5.3.4.

<Report Findings Here> Identify the recent payment application changes observed for 5.3.1-5.3.4.

Modified p. 94 → 79

<Report Findings Here>  Describe how each of the recent payment application changes were traced back to related change-control documentation.

<Report Findings Here> Describe how each of the recent payment application changes were traced back to related change-control documentation.

Modified p. 94 → 79

<Report Findings Here> 5.3.1 Documentation of impact ~~5.3.1 Verify that documentation of customer impact is included in the change-control documentation for each change.~~

<Report Findings Here> 5.3.1 Documentation of impact ☐ ☐ ☐

Modified p. 94 → 80

 For each payment application change examined, identify the related ~~change- control~~ documentation that includes customer impact.

For each payment application change examined, identify the related change-control documentation that includes customer impact.

Modified p. 94 → 80

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

<Report Findings Here> 5.3.2 Documented approval of change by appropriate authorized parties ☐ ☐ ☐ 5.3.2 Verify that documented approval by appropriate authorized parties is present for each change.

Modified p. 94 → 80

 For each payment application change examined, identify the related ~~change- control~~ documentation that includes documented approval by appropriate authorized parties.

For each payment application change examined, identify the related change-control documentation that includes documented approval by appropriate authorized parties.

Modified p. 94 → 80

<Report Findings Here> 5.3.3 Functionality testing to verify that the change does not adversely impact the security of the system 5.3.3.a ~~For each sampled change, verify~~ that functionality testing was performed to verify that the change does not adversely impact the security of the system.

<Report Findings Here> 5.3.3 Functionality testing to verify that the change does not adversely impact the security of the system ☐ ☐ ☐ 5.3.3.a Verify that functionality testing was performed to verify that the change does not adversely impact the security of the system.

Modified p. 94 → 80

 For each payment application change examined, identify the related ~~change- control~~ documentation that includes that functionality testing was performed to verify that the change did not adversely impact the security of the system.

For each payment application change examined, identify the related change-control documentation that includes that functionality testing was performed to verify that the change did not adversely impact the security of the system.

Modified p. 95 → 80

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 5.3.3.b Verify that all changes (including patches) are tested for compliance with 5.2 before being released.

<Report Findings Here> 5.3.3.b Verify that all changes (including patches) are tested for compliance with 5.2 before being released.

Modified p. 95 → 80

 For each payment application change examined, identify the related ~~change- control~~ documentation that includes that the change was tested for compliance with 5.2 (that the vulnerabilities in 5.2.1•5.2.9 are addressed) prior to release.

For each payment application change examined, identify the related change-control documentation that includes that the change was tested for compliance with 5.2 (that the vulnerabilities in 5.2.1•5.2.9 are addressed) prior to release.

Modified p. 95 → 80

<Report Findings Here> 5.3.4 Back-out or product de-installation procedures 5.3.4 Verify that back-out or product de- installation procedures are prepared for each change.

<Report Findings Here> 5.3.4 Back-out or product de-installation procedures ☐ ☐ ☐ 5.3.4 Verify that back-out or product de- installation procedures are prepared for each change.

Modified p. 95 → 80

 For each payment application change examined, identify the related ~~change- control~~ documentation that includes that back-out or product de-installation procedures are prepared for each change.

For each payment application change examined, identify the related change-control documentation that includes that back-out or product de-installation procedures are prepared for each change.

Modified p. 95 → 80

<Report Findings Here> 5.4 The payment 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 PA-DSS Program Guide for changes to payment applications and include at least the following:

<Report Findings Here> 5.4 The payment 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 PA-DSS Program Guide for changes to payment applications and include at least the following: ☐ ☐ ☐

Modified p. 95 → 81

 Identify the documented software development processes which were verified to:

Identify the documented software development processes which were verified to:

Modified p. 95 → 81

~~ Include the software vendor’s versioning methodology.  Be in accordance with the PA-DSS Program Guide. ~~ Be required to be followed for the payment application, including all changes to the payment application.

• Be required to be followed for the payment application, including all changes to the payment application.

Removed p. 96

 Details of how the elements of the version numbering scheme are in accordance with requirements specified in the PA- DSS Program Guide.  The format of the version numbering scheme is specified and includes details of number of elements, separators, character set, etc. (e.g., 1.1.1.N, consisting of alphabetic, numeric, and/or alphanumeric characters).  A definition of what each element represents in the version- numbering scheme (e.g., type of change, major, minor, or maintenance release, wildcard, etc.).  Definition of elements that indicate use of wildcards.

Modified p. 96 → 81

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 5.4.1 The versioning methodology must define the specific version elements used, as follows:

<Report Findings Here> 5.4.1 The versioning methodology must define the specific version elements used, as follows:

Modified p. 96 → 81

~~ Details of how the elements of the version scheme are in accordance with requirements specified in the PA-DSS 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 (for example, type of change, major, minor, or maintenance release, wildcard, etc.)  Definition of elements that indicate use of wildcards

• 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 (for example, type of change, major, minor, or maintenance release, wildcard, etc.) • Definition of elements that indicate use of wildcards

Modified p. 96 → 81

Note: Wildcards may only be substituted for elements of the version number that represent non-security impacting changes. Refer to 5.4.3 for additional requirements on the use of wildcards.

Note: Wildcards may only be substituted for elements of the version number that represent non-security impacting changes. Refer to Requirement 5.4.3 for additional requirements on the use of wildcards.

Modified p. 96 → 81

~~Identify the document reviewed that verified the documented versioning methodology includes ~~ Details of how the elements of the version numbering scheme are in accordance with requirements specified in the PA-DSS Program Guide.

• Details of how the elements of the version numbering scheme are in accordance with requirements specified in the PA-DSS Program Guide.

Modified p. 96 → 82

~~<Report Findings Here> ~~ Definition of elements that indicate use of wildcards.

• Definition of elements that indicate use of wildcards.

Modified p. 97 → 82

~~Assessor’s Response Summary~~ of Findings ~~(check one) Not Applicable~~ 5.4.1.b Verify the elements of the version scheme are in accordance with the types of changes specified in the PA-DSS Program Guide.

 Definition of elements that indicate use of wildcards. <Report Findings Here> 5.4.1.b Verify the elements of the version scheme are in accordance with the types of changes specified in the PA-DSS Program Guide.

Modified p. 97 → 82

 Identify the version of the PA-DSS Program Guide that the elements of the version scheme were verified to be in accordance with.

Identify the version of the PA-DSS Program Guide that the elements of the version scheme were verified to be in accordance with.

Modified p. 97 → 82

<Report Findings Here> 5.4.1.c ~~Examine~~ recent payment application changes, the version number 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.

<Report Findings Here> 5.4.1.c Select a sample of recent payment application changes, the version number 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. 97 → 82

 Describe the types of recent payment application changes ~~examined.~~

Describe the types of recent payment application changes sampled.

Modified p. 97 → 82

<Report Findings Here>  Identify the associated change control documentation that specifies the type of application change.

<Report Findings Here> Identify the associated change control documentation that specifies the type of application change.

Modified p. 97 → 82

<Report Findings Here>  For each change examined, describe how the change to the version number is in accordance with their defined methodology.

<Report Findings Here> For each change examined, describe how the change to the version number is in accordance with their defined methodology.

Modified p. 97 → 82

<Report Findings Here> For the interview, summarize the relevant details discussed that verify that they are knowledgeable in:

Identify the developers interviewed for this testing procedure. <Report Findings Here> For the interview, summarize the relevant details discussed that verify that they are knowledgeable in:

Modified p. 97 → 82

 The version scheme. <Report Findings Here>  The acceptable use of wildcards in the version number.

 The version scheme. <Report Findings Here>  The acceptable use of wildcards in the version number. <Report Findings Here>

Removed p. 98

Assessor’s Response Summary of Findings (check one) Not Applicable 5.4.2 The versioning methodology must indicate the type and impact of all application changes in accordance with the PA- DSS Program Guide, including:

Modified p. 98 → 83

 Descriptions of all types and impacts of application changes ~~ Specific identification and definition of changes that:~~

• Descriptions of all types and impacts of application changes

Modified p. 98 → 83

• ~~Have impact to any security functionality or PA-DSS requirement. ~~ How each type of change ties to a specific version number 5.4.2.a Examine the software vendor’s documented versioning methodology to verify the version methodology includes:

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

Modified p. 98 → 83

 Description of all types and impacts of application changes (for example, changes that have no impact, low impact, or high impact to the application) ~~ Specific identification and definition for changes that:~~

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

Modified p. 98 → 83

• Have impact to any security functionality or PA-DSS requirement. ~~ How each type of change ties to a specific version number.~~

• Have impact to any security functionality or PA-DSS requirement.

Modified p. 98 → 83

 Identify the software vendor’s documented versioning methodology that was verified to include:

Identify the software vendor’s documented versioning methodology that was verified to include:

Modified p. 98 → 83

 Description of all types and impacts of application changes. ~~ Specific identification and definition for changes that:~~

• Description of all types and impacts of application changes.

Modified p. 98 → 83

- Have impact to any security functionality or ~~PA-DSS~~ requirement.

- Have impact to any security functionality or PA- DSS requirement.

Modified p. 98 → 83

 How each type of change ties to a specific version number.

• How each type of change ties to a specific version number.

Modified p. 98 → 83

 Provide the name of the PA-QSA attesting that the documented versioning methodology is in accordance with the PA-DSS Program Guide.

Provide the name of the PA-QSA attesting that the documented versioning methodology is in accordance with the PA-DSS Program Guide.

Modified p. 99 → 83

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 5.4.2.c Interview personnel and observe processes for each type of change to verify that the documented methodology is ~~being~~ followed for all types of changes.

<Report Findings Here> 5.4.2.c Interview personnel and observe processes for each type of change to verify that the documented methodology is followed for all types of changes.

Modified p. 99 → 83

 Identify the responsible personnel interviewed who confirm that the documented methodology is followed for all types of changes.

Identify the responsible personnel interviewed who confirm that the documented methodology is followed for all types of changes.

Modified p. 99 → 83

<Report Findings Here>  Describe the processes observed to verify that the documented methodology is followed for all types of changes.

<Report Findings Here> Describe the processes observed to verify that the documented methodology is followed for all types of changes.

Modified p. 99 → 84

<Report Findings Here>  Identify the associated change control documentation that specifies the type of application change.

<Report Findings Here> Identify the associated change control documentation that specifies the type of application change.

Modified p. 99 → 84

 Describe the types of recent payment application changes examined.

Describe the types of recent payment application changes examined.

Modified p. 99 → 84

<Report Findings Here>  For each change examined, identify the category of change for each one, per the PA-DSS Program Guide.

<Report Findings Here> For each change examined, identify the category of change for each one, per the PA-DSS Program Guide.

Modified p. 99 → 84

<Report Findings Here>  For each change examined, describe:

<Report Findings Here> For each change examined, describe:

Modified p. 99 → 84

~~ How the version number changed (what the version number was and what it changed to). ~~ How that version number change matches the category of change made to the payment application, according to the documented methodology.

• How that version number change matches the category of change made to the payment application, according to the documented methodology.

Removed p. 100

Assessor’s Response Summary of Findings (check one) Not Applicable 5.4.3 The versioning methodology must specifically identify if wildcards are used, and if so, how they are used. The following must be included:

 Details of how wildcards are used in the versioning methodology.  Wildcards are never used for any change that has an impact on security or any PA-DSS requirements.  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.  Security-impacting change requires a change to other version-number element that appears “to the left of” the first wildcard element.

 Details of how wildcards are used in the versioning methodology.  Wildcards are never used for any change that has an impact on security or …

Modified p. 100 → 84

 Details of how wildcards are used in the versioning methodology  Wildcards are never used for any change that has an impact on security or any PA-DSS requirements  Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change  Wildcard elements must not precede version elements that could represent security-impacting changes. Any version elements that appear after a wildcard element must not …

• How the version number

• changed (what the version number was and what it

• Details of how wildcards are used in the versioning methodology • Wildcards are never used for any change that has an impact on security or any PA-DSS requirements • 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 …

Modified p. 100 → 85

 Identify the software vendor’s documented versioning methodology that was verified to include:

Identify the software vendor’s documented versioning methodology that was verified to include:

Removed p. 101

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

Modified p. 101 → 85

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 5.4.3.b Verify that any use of wildcards is in accordance with the PA-DSS Program Guide requirements; For example, elements that appear after a wildcard element cannot be used for a security impacting change.

<Report Findings Here> 5.4.3.b Verify that any use of wildcards is in accordance with the PA-DSS Program Guide requirements; For example, elements that appear after a wildcard element cannot be used for a security impacting change.

Modified p. 101 → 85

~~ Identify~~ whether there is any use of wildcards in the vendor’s version methodology. (yes/no) ~~If “no,” mark the rest of 5.4.3.b as “not applicable.”~~ <Report Findings Here>  If ”yes,” describe how use of wildcards is in accordance with the PA-DSS Program Guide requirements.

Indicate whether there is any use of wildcards in the vendor’s version methodology. (yes/no) <Report Findings Here> If ”yes,” describe how use of wildcards is in accordance with the PA-DSS Program Guide requirements.

Modified p. 101 → 86

~~ Wildcards are never used for any change that has an impact on security or any PA-DSS 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.

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

Modified p. 101 → 86

 Identify the responsible personnel interviewed for this testing procedure who confirm that for each type of change:

Identify the responsible personnel interviewed for this testing procedure who confirm that for each type of change:

Modified p. 101 → 86

~~ Wildcards are never used for any change that has an impact on security or any PA-DSS requirements. ~~ Elements of the version number used to represent ~~non-security-impacting~~ changes (including a wildcard element) are never used to represent a security impacting change.

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

Modified p. 101 → 86

<Report Findings Here>  Elements of the version number used to represent ~~non-security-impacting~~ changes (including a wildcard element) are never used to represent a security impacting change.

<Report Findings Here>  Elements of the version number used to represent non- security-impacting changes (including a wildcard element) are never used to represent a security impacting change.

Removed p. 102

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

Modified p. 102 → 86

<Report Findings Here>  Elements of the version number used to represent ~~non-security-impacting~~ changes (including a wildcard element) are never used to represent a security impacting change.

<Report Findings Here>  Elements of the version number used to represent non- security-impacting changes (including a wildcard element) are never used to represent a security impacting change.

Modified p. 102 → 86

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 5.4.3.d Select a sample of recent payment application changes and review the change control documentation that specifies the type of application change. Verify that:

<Report Findings Here> 5.4.3.d Select a sample of recent payment application changes and review the change control documentation that specifies the type of application change. Verify that:

Modified p. 102 → 86

~~ Wildcards are not used for any change that has an impact on security or any PA-DSS 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.

• 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. 102 → 86

 Identify the sample of recent payment application changes examined.

Identify the sample of recent payment application changes examined.

Modified p. 102 → 86

<Report Findings Here>  Identify the associated change-control documentation that specifies the type of application change.

<Report Findings Here> Identify the associated change-control documentation that specifies the type of application change.

Modified p. 102 → 86

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

<Report Findings Here> 5.4.4 The vendor’s published versioning methodology must be communicated to customers and integrators/resellers. ☐ ☐ ☐ 5.4.4 Verify the PA-DSS Implementation Guide includes a description of the vendor’s published versioning methodology for customers and integrators/resellers, and includes the following:

Modified p. 102 → 86

~~(continued on next page)~~ Identify the page number(s)/section of the PA-DSS Implementation Guide that include:

• Details of versioning scheme, including the format of the version scheme (number of Identify the page number(s)/section of the PA-DSS Implementation Guide that include:

Modified p. 102 → 87

~~<Report Findings Here>~~  Details of how security-impacting changes will be indicated by the version scheme.

 Details of how security-impacting changes will be indicated by the version scheme.

Removed p. 103

 Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security- impacting change.

 Identify the software vendor’s documented versioning methodology reviewed to verify it includes a mapping of internal versions to published external versions.

 Identify recent payment application changes examined.

<Report Findings Here>  Describe how examination of recent changes verified that mapping of internal and external version numbers was updated according to the documented methodology.

 Identify the software developers interviewed who confirm application updates are reviewed for conformity with the versioning methodology prior to release.

Modified p. 103 → 87

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable ~~ Details of any wildcard elements that are used, including confirmation that they will never be used to represent a ~~security- impacting~~ change.

<Report Findings Here>  Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security-impacting change.

Modified p. 103 → 87

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

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

Modified p. 103 → 87

~~5.4.5.a Examine~~ the documented ~~version~~ methodology to verify it includes a mapping of internal versions to published external versions.

Identify the software vendor’s documented versioning methodology reviewed to verify it includes a mapping of internal versions to published external versions.

Modified p. 103 → 87

<Report Findings Here> 5.4.5.b Examine recent changes to confirm internal version mapping to published versioning ~~scheme, match according to~~ the type of ~~change.~~

<Report Findings Here> 5.4.5.b Examine recent changes to confirm that internal version mapping to published versioning scheme is updated in accordance with the type of change, as defined in the documented methodology.

Modified p. 103 → 87

<Report Findings Here> 5.4.6 Software vendor must have a process in place to review application updates for conformity with the versioning methodology prior to release.

<Report Findings Here> 5.4.6 Software vendor must have a process in place to review application updates for conformity with the versioning methodology prior to release. ☐ ☐ ☐ 5.4.6.a Examine documented software- development processes and the versioning methodology to verify there is a process in place to review application updates for conformity with the versioning methodology prior to release.

Modified p. 103 → 87

~~5.4.6.a Examine documented software- development processes and~~ the ~~versioning methodology to verify there is a~~ process ~~in place~~ to review application updates for conformity with the versioning methodology prior to release.

Identify the document that includes the process to review application updates for conformity with the versioning methodology prior to release.

Modified p. 103 → 87

<Report Findings Here> 5.4.6.b Interview software developers and observe processes to verify that application updates are reviewed for conformity with the versioning methodology prior to release.

<Report Findings Here> 5.4.6.b Interview software developers and observe processes to verify that application updates are reviewed for conformity with the Identify the software developers interviewed who confirm application updates are reviewed for conformity with the versioning methodology prior to release.

Modified p. 103 → 88

~~ Identify~~ the ~~document~~ that ~~includes the process to review~~ application updates for conformity with the versioning methodology prior to release.

Describe the processes observed to verify that application updates are reviewed for conformity with the versioning methodology prior to release.

Removed p. 104

Assessor’s Response Summary of Findings (check one) Not Applicable  Describe the processes observed to verify that application updates are reviewed for conformity with the versioning methodology prior to release.

Modified p. 104 → 88

 Coverage of all functions of the payment 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 payment application that interact with PAN and/or SAD or the cardholder data environment (CDE), as well as any process-oriented outcomes that could lead to the exposure of cardholder data.  A list of potential threats and vulnerabilities …

• Identification of all areas within the payment application that interact with PAN and/or SAD or the cardholder data environment (CDE), as well as any process-oriented outcomes that could lead to the exposure of cardholder data. • A list of potential threats and vulnerabilities resulting from cardholder data-flow analyses and assign risk ratings (for example, high, medium, or low priority) to each.

Modified p. 105 → 88

~~(continued on next page) ~~ Identify the documented ~~software- development~~ procedures verified to contain risk assessment techniques, and verified to include processes for:

• A list of potential threats and vulnerabilities resulting from cardholder data-flow analyses, and assign risk ratings (e.g., high, medium, or low priority) to each Identify the documented software-development procedures verified to contain risk assessment techniques, and verified to include processes for:

Removed p. 106

Assessor’s Response Summary of Findings (check one) Not Applicable  Identify the software developers interviewed who confirm the vendor uses risk assessment techniques as part of the software-development process, and that the processes include:

Removed p. 107

Assessor’s Response Summary of Findings (check one) Not Applicable 5.6 Software vendor must implement a process to document and authorize the final release of the application and any application updates. Documentation includes:

Modified p. 107 → 90

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

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

Modified p. 107 → 90

 Identify the documented processes reviewed to verify that final release of the application and any application updates must be formally approved and documented, and must include:

Identify the documented processes reviewed to verify that final release of the application and any application updates must be formally approved and documented, and must include:

Modified p. 107 → 90

 Formal approval and signature by an authorized party. ~~ Confirmation that all SDLC processes were followed.~~

• Formal approval and signature by an authorized party.

Modified p. 107 → 90

<Report Findings Here> 5.6.b For a sample of recent releases of application and application updates, review approval documentation to verify it includes ~~ Formal approval and signature by an authorized party.  Confirmation that that all secure development processes were followed.~~

<Report Findings Here> 5.6.b For a sample of recent releases of application and application updates, review approval documentation to verify it includes

Modified p. 107 → 90

 Identify the sample of recent releases of application and application updates reviewed for this testing procedure.

Identify the sample of recent releases of application and application updates reviewed for this testing procedure.

Modified p. 107 → 90

 Formal approval and signature by an authorized party.

 Formal approval and signature by an authorized party. <Report Findings Here>  Confirmation that that all secure development processes were followed.

Removed p. 108

Assessor’s Response Summary of Findings (check one) Not Applicable 6.1 For payment applications using wireless technology, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. The wireless technology must be implemented securely.

 The payment application enforces changes of default encryption keys, passwords and SNMP community strings at installation for all wireless components controlled by the application.  Procedures for changing wireless encryption keys and passwords, including SNMP strings, anytime anyone with knowledge of the keys/passwords leaves the company or changes positions.  Instructions for changing default encryption keys, passwords and SNMP community strings on any wireless components provided with, but not controlled by, the payment application.

Modified p. 108 → 91

Requirement 6: Protect wireless transmissions PA-DSS Requirements and Testing Procedures Reporting Instruction ~~ROV~~ Reporting Details:

Requirement 6: Protect wireless transmissions PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 6.1 For payment applications using wireless technology, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. The wireless technology must be implemented securely.

Modified p. 108 → 91

Aligns with PCI DSS Requirements 1.2.3 & 2.1.1 6.1 For payment applications developed for use with wireless technology, and for all wireless applications bundled with the payment application, verify that the wireless applications do not use vendor default settings, as follows:

Aligns with PCI DSS Requirements 1.2.3 & 2.1.1 6.1 For payment applications developed for use with wireless technology, and for all wireless applications bundled with the payment application, verify that the wireless applications do not use vendor default settings, as follows: ☐ ☐ ☐ 6.1.a Examine the PA-DSS Implementation Guide prepared by the vendor to verify it includes the following instructions for customers and integrators/resellers:

Modified p. 108 → 91

~~(continued on next page)  Identify~~ whether the payment application uses wireless technologies. (yes/no) <Report Findings Here> ~~ Identify~~ whether other applications bundled with the payment application use wireless technologies. (yes/no) <Report Findings Here>  If both are “no,” describe testing performed to verify the application is not developed for use with wireless technology. If both are “no,” mark the remainder of 6.1 and 6.2 as “not applicable” and proceed to 6.3. If either are “yes,” complete the below.

• Instructions to configure firewalls to deny or

•if such traffic is necessary for business Indicate whether the payment application uses wireless technologies. (yes/no) <Report Findings Here> Indicate whether other applications bundled with the payment application use wireless technologies. (yes/no) <Report Findings Here> If both are “no,” describe testing performed to verify the application is not developed for use with wireless technology. If both are “no,” mark the remainder of 6.1 and 6.2 as “not applicable” and proceed to 6.3. If …

Removed p. 109

Assessor’s Response Summary of Findings (check one) Not Applicable  Instructions to install a firewall between any wireless networks and systems that store cardholder data.  Details of any wireless traffic (including specific port information) that the wireless function of the payment application would use.  Instructions to configure firewalls to

•if such traffic is necessary for business purposes

•permit only authorized traffic between the wireless environment and the cardholder data environment.

Modified p. 109 → 91

 Procedures for changing wireless encryption keys and passwords, including SNMP strings, anytime anyone with knowledge of the keys/passwords leaves the company or changes positions.

<Report Findings Here>  Procedures for changing wireless encryption keys and passwords, including SNMP strings, anytime anyone with knowledge of the keys/passwords leaves the company or changes positions.

Modified p. 109 → 92

~~<Report Findings Here>~~  Details of any wireless traffic (including specific port information) that the wireless function of the payment application would use.

 Details of any wireless traffic (including specific port information) that the wireless function of the payment application would use.

Modified p. 109 → 92

<Report Findings Here> 6.1.b Install the application according to the ~~PA-DSS~~ Implementation Guide and test application and wireless settings to verify the following, for all wireless functionality managed by the payment application:

<Report Findings Here> 6.1.b Install the application according to the PA- DSS Implementation Guide and test application and wireless settings to verify the following, for all wireless functionality managed by the payment application:

Modified p. 109 → 92

~~ Encryption keys were changed from default at installation. ~~ Default SNMP community strings on wireless devices were ~~changed at installation.~~

• Default SNMP community strings on wireless devices were

Modified p. 109 → 92

~~(continued on next page)~~ After installing the application according to the PA-DSS Implementation Guide, describe the testing of the application and wireless settings to verify the following for all wireless functionality managed by the payment application:

After installing the application according to the PA-DSS Implementation Guide, describe the testing of the application and wireless settings to verify the following for all wireless functionality managed by the payment application:

Removed p. 110

Assessor’s Response Summary of Findings (check one) Not Applicable  Default passwords/passphrases on access points were changed at installation.  Firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks.  Other security-related wireless vendor defaults were changed, if applicable.

 Change of wireless encryption keys  Change of passwords/passphrases  Change of SNMP strings <Report Findings Here> 6.1.d For all wireless components provided with, but not controlled by, the payment application, follow instructions in the PA-DSS Implementation Guide for changing default encryption keys, passwords/passphrases and SNMP community strings. Verify the PA-DSS Implementation Guide instructions are accurate and result in changed wireless encryption keys, passwords and SNMP strings.

Modified p. 110 → 92

 Default passwords/passphrases on access points were changed at installation.

<Report Findings Here>  Default passwords/passphrases on access points were changed at installation.

Modified p. 110 → 92

 If wireless functionality is managed by the payment application, provide the name of the PA-QSA who attests that the instructions in the PA-DSS Implementation Guide were followed to verify that the instructions are accurate and result in the required change for the following:

If wireless functionality is managed by the payment application, provide the name of the PA-QSA who attests that the instructions in the PA-DSS Implementation Guide were followed to verify that the instructions are accurate and result in the required change for the following:

Modified p. 110 → 92

~~ Change of wireless encryption keys  Change of passwords/passphrases ~~ Change of SNMP strings <Report Findings Here>

• Change of SNMP strings <Report Findings Here>

Modified p. 110 → 93

 If there are wireless components provided with, but not controlled by, the payment application, provide the name of the PA-QSA who attests that the instructions in the PA-DSS Implementation Guide were followed to verify that the instructions are accurate and result in the required change for the following:

If there are wireless components provided with, but not controlled by, the payment application, provide the name of the PA-QSA who attests that the instructions in the PA-DSS Implementation Guide were followed to verify that the instructions are accurate and result in the required change for the following:

Removed p. 111

<Report Findings Here>  Identify the industry best practice(s) used for transmission.

<Report Findings Here>  Identify the industry best practice(s) used for transmission.

Modified p. 111 → 93

~~Assessor’s Response Summary~~ of Findings ~~(check one) Not Applicable~~ 6.1.e Install the application and test wireless functions to verify the wireless traffic and ports used by the application are in accordance with those documented in the PA-DSS Implementation Guide.

• Change of SNMP strings <Report Findings Here> 6.1.e Install the application and test wireless functions to verify the wireless traffic and ports used by the application are in accordance with those documented in the PA-DSS Implementation Guide.

Modified p. 111 → 93

 Strong encryption for authentication <Report Findings Here>  Strong encryption for transmission <Report Findings Here>  Identify the industry best practice(s) used for authentication.

 Strong encryption for authentication <Report Findings Here>  Strong encryption for transmission <Report Findings Here> Identify the industry best practice(s) used for authentication. <Report Findings Here> Identify the industry best practice(s) used for transmission. <Report Findings Here>

Modified p. 111 → 94

 Strong encryption for authentication <Report Findings Here>  Strong encryption for transmission <Report Findings Here>  Identify the industry best practice(s) used for authentication.

 Strong encryption for authentication <Report Findings Here>  Strong encryption for transmission <Report Findings Here> Identify the industry best practice(s) used for authentication. <Report Findings Here> Identify the industry best practice(s) used for transmission. <Report Findings Here> 6.2.c Examine the PA-DSS Implementation Guide prepared by the vendor to verify it includes the following instructions for customers and integrators/resellers:

Removed p. 112

Assessor’s Response Summary of Findings (check one) Not Applicable  How to configure the application to use industry best practices (for example, IEEE 802.11.i) for strong encryption for authentication and transmission, and/or  How to configure all wireless applications bundled with the payment application to use industry best practices for strong encryption for authentication and transmission.

Modified p. 112 → 94

 How to configure the application to use industry best practices for strong encryption for transmission.

<Report Findings Here>  How to configure the application to use industry best practices for strong encryption for transmission.

Removed p. 113

Assessor’s Response Summary of Findings (check one) Not Applicable 6.3 Provide instructions for customers about secure use of wireless technology.

 Instructions to change all wireless default encryption keys, passwords and SNMP community strings upon installation.  Instructions to change wireless encryption keys, passwords and SNMP strings anytime anyone with knowledge of the keys/passwords leaves the company or changes positions.  Instructions to install a firewall between any wireless networks and systems that store cardholder data, and to configure firewalls to deny or, if such traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.  Instructions to use industry best practices (for example, IEEE 802.11.i) to provide strong encryption for authentication and transmission.

Modified p. 113 → 95

Aligns with PCI DSS Requirements 1.2.3, 2.1.1 & 4.1.1 6.3 Examine PA-DSS Implementation Guide prepared by the vendor to verify customers and integrators/resellers are instructed on PCI ~~DSS-compliant~~ wireless settings, ~~including changing wireless vendor defaults and using industry best practices to implement strong encryption for authentication and transmission of cardholder data,~~ as follows:

Aligns with PCI DSS Requirements 1.2.3, 2.1.1 & 4.1.1 6.3 Examine PA-DSS Implementation Guide prepared by the vendor to verify customers and integrators/resellers are instructed on PCI DSS- compliant wireless settings, as follows:

Modified p. 113 → 95

 Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers on PCI DSS-compliant wireless settings, as follows:

Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers on PCI DSS-compliant wireless settings, as follows:

Removed p. 114

Assessor’s Response Summary of Findings (check one) Not Applicable 7.1 Software vendors must establish a process to identify and manage vulnerabilities, as follows:

Modified p. 114 → 96

Requirement 7: Test payment applications to address vulnerabilities and maintain application updates PA-DSS Requirements and Testing Procedures Reporting Instruction ~~ROV~~ Reporting Details:

Requirement 7: Test payment applications to address vulnerabilities and maintain application updates PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 7.1 Software vendors must establish a process to identify and manage vulnerabilities, as follows:

Modified p. 114 → 96

 Identify new security vulnerabilities using reputable sources for obtaining security vulnerability information. ~~ Assign a risk ranking to all identified vulnerabilities.  Test payment applications and updates for the presence of vulnerabilities prior to release.~~

• Identify new security vulnerabilities using reputable sources for obtaining security vulnerability information.

Modified p. 114 → 96

 Identify the vulnerability management process documentation verified to define the following procedures:

Identify the vulnerability management process documentation verified to define the following procedures:

Modified p. 114 → 96

 Identify new security vulnerabilities using reputable sources for obtaining security vulnerability information.  Assign a risk ranking to all identified vulnerabilities.  Test payment applications for the presence of vulnerabilities prior to release.  Test updates for the presence of vulnerabilities prior to release <Report Findings Here> 7.1.b Verify that processes to identify new vulnerabilities and implement corrections into payment application apply to all software provided with or required by the payment application (for example, web servers, third-party libraries …

• Test updates for the presence of vulnerabilities prior to release <Report Findings Here> 7.1.b Verify that processes to identify new vulnerabilities and implement corrections into payment application apply to all software provided with or required by the payment application (for example, web servers, third-party libraries and programs).

Modified p. 114 → 96

 Identify the vulnerability management process documentation verified to include processes to identify new vulnerabilities and implement corrections for all software:

Identify the vulnerability management process documentation verified to include processes to identify new vulnerabilities and implement corrections for all software:

Modified p. 114 → 96

 Provided with the payment application. ~~ Required by the payment application.~~

• Provided with the payment application.

Modified p. 114 → 97

~~<Report Findings Here>  All~~ software required by the payment application.

• In both the payment application and any underlying software or systems provided with or required by the payment application.

Removed p. 115

Assessor’s Response Summary of Findings (check one) Not Applicable Describe the processes observed to implement corrections for:

 Identify the responsible personnel interviewed who confirm new security vulnerabilities are identified:

 In both the payment application and any underlying software or systems provided with or required by the payment application.  Using reputable sources.

Modified p. 115 → 96

<Report Findings Here> 7.1.1 Identify new security vulnerabilities using reputable sources for obtaining security vulnerability information.

 All software provided with the payment application. <Report Findings Here>  All software required by the payment application. <Report Findings Here> 7.1.1 Identify new security vulnerabilities using reputable sources for obtaining security vulnerability information. ☐ ☐ ☐

Modified p. 115 → 97

~~<Report Findings Here>  All~~ software required by the payment application.

• In both the payment application and any underlying software or systems provided with or required by the payment application.

Modified p. 115 → 97

~~ In both the payment application and any underlying software or systems provided with or required by the payment application. ~~ Using reputable sources (such as software/systems vendor websites, NIST’s NVD, MITRE’s CVE, and the DHS’s ~~US-CERT~~ websites).

• Using reputable sources (such as software/systems vendor websites, NIST’s NVD, MITRE’s CVE, and the DHS’s US- CERT websites).

Modified p. 115 → 97

<Report Findings Here>  Identify the outside sources identified as used for security vulnerability information via interview.

<Report Findings Here> Identify the outside sources identified as used for security vulnerability information via interview.

Removed p. 116

<Report Findings Here>  Processes include ranking vulnerabilities in any underlying software or systems provided with or required by the payment application.

Modified p. 116 → 97

 Identify the responsible personnel interviewed who confirm that:

Identify the responsible personnel interviewed who confirm that:

Modified p. 116 → 97

~~ New security vulnerabilities are assigned a risk ranking. ~~ Processes include ranking vulnerabilities in any underlying software or systems provided with or required by the payment application.

• Processes include ranking vulnerabilities in any underlying software or systems provided with or required by the payment application.

Modified p. 116 → 97

 New security vulnerabilities are assigned a risk ranking.

 New security vulnerabilities are assigned a risk ranking. <Report Findings Here>

Modified p. 116 → 98

 Identify the responsible personnel interviewed who confirm that payment applications are tested for the presence of vulnerabilities prior to release.

Identify the responsible personnel interviewed who confirm that payment applications are tested for the presence of vulnerabilities prior to release.

Modified p. 116 → 98

<Report Findings Here>  Describe the processes observed to verify that payment applications are tested for the presence of vulnerabilities prior to release.

<Report Findings Here> Describe the processes observed to verify that payment applications are tested for the presence of vulnerabilities prior to release.

Modified p. 116 → 98

<Report Findings Here> 7.2 Software vendors must establish a process for timely development and deployment of security patches and upgrades.

<Report Findings Here> 7.2 Software vendors must establish a process for timely development and deployment of security patches and upgrades. ☐ ☐ ☐ 7.2 Examine process documentation for the development and distribution of security patches and upgrades to verify the process include procedures for 7.2.1 through 7.2.2:

Removed p. 117

Assessor’s Response Summary of Findings (check one) Not Applicable 7.2 Examine process documentation for the development and distribution of security patches and upgrades to verify the process include procedures for 7.2.1 through 7.2.2:

Modified p. 117 → 98

 Identify the vulnerability management process documentation verified to include procedures for the development and distribution of security patches and upgrades, as follows:

Identify the vulnerability management process documentation verified to include procedures for the development and distribution of security patches and upgrades, as follows:

Modified p. 117 → 98

~~ Patches and updates are delivered to customers in a secure manner with a known chain of trust. ~~ Patches and updates are delivered to customers in a manner that maintains the integrity of the patch and update code.

• Patches and updates are delivered to customers in a manner that maintains the integrity of the patch and update code.

Modified p. 117 → 98

 Identify the responsible personnel interviewed who confirm that patches and updates are delivered to customers in a secure manner with a known chain of trust.

Identify the responsible personnel interviewed who confirm that patches and updates are delivered to customers in a secure manner with a known chain of trust.

Modified p. 117 → 98

<Report Findings Here>  Describe the processes observed to verify that patches and updates are delivered to customers in a secure manner with a known chain of trust.

<Report Findings Here> Describe the processes observed to verify that patches and updates are delivered to customers in a secure manner with a known chain of trust.

Modified p. 117 → 99

~~7.2.2.a Interview~~ responsible personnel ~~and observe processes to verify~~ patches and updates are delivered to customers in a manner that maintains the integrity of the patch and update code.

Identify the responsible personnel interviewed who confirm that patches and updates are delivered to customers in a manner that maintains the integrity of the patch and update code.

Modified p. 117 → 99

~~ Identify~~ the ~~responsible personnel interviewed who confirm~~ that patches and updates are delivered to customers in a manner that maintains the integrity of the patch and update code.

<Report Findings Here> Describe the processes observed to verify that patches and updates are delivered to customers in a manner that maintains the integrity of the patch and update code.

Modified p. 117 → 99

<Report Findings Here>  Describe the processes observed to verify that patches and updates are ~~delivered~~ to ~~customers in a manner that maintains the integrity of the patch and update code.~~

<Report Findings Here> Describe the processes observed to verify that patches and updates are integrity-tested on the target system prior to installation.

Removed p. 118

<Report Findings Here>  Describe the processes observed to verify that patches and updates are integrity-tested on the target system prior to installation.

<Report Findings Here>  Identify the responsible personnel interviewed who confirm release notes are prepared for all updates, including details and impact of the update, and how the version number was changed to reflect the application update.

 Describe the sample of application updates examined.

Modified p. 118 → 99

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 7.2.2.b Interview responsible personnel and observe application update processes to verify patches and updates are integrity-tested on the target system prior to installation.

<Report Findings Here> 7.2.2.b Interview responsible personnel and observe application update processes to verify patches and updates are integrity-tested on the target system prior to installation.

Modified p. 118 → 99

 Identify the responsible personnel interviewed who confirm that patches and updates are integrity-tested on the target system prior to installation.

Identify the responsible personnel interviewed who confirm that patches and updates are integrity-tested on the target system prior to installation.

Modified p. 118 → 99

 Describe how the update process was run with arbitrary code.

Describe how the update process was run with arbitrary code.

Modified p. 118 → 99

<Report Findings Here>  Describe how the testing was run to verify that the system will not allow the update to occur.

<Report Findings Here> Describe how the testing was run to verify that the system will not allow the update to occur.

Modified p. 118 → 99

<Report Findings Here> 7.3 Include release notes for all application updates, including details and impact of the update, and how the version number was changed to reflect the application update.

<Report Findings Here> 7.3 Include release notes for all application updates, including details and impact of the update, and how the version number was changed to reflect the application update. ☐ ☐ ☐ 7.3.a Examine processes for releasing updates and interview personnel to verify release notes are prepared for all updates, including details and impact of the update, and how the version number was changed to reflect the application update.

Modified p. 118 → 99

~~7.3.a Examine processes for releasing updates and interview personnel~~ to verify release notes are prepared for all updates, including details and impact of the update, and how the version number was changed to reflect the application update.

Identify the process documentation reviewed to verify release notes are prepared for all updates, including details and impact of the update, and how the version number was changed to reflect the application update.

Modified p. 118 → 99

 Identify the ~~process documentation reviewed to verify~~ release notes are prepared for all updates, including details and impact of the update, and how the version number was changed to reflect the application update.

<Report Findings Here> Identify the responsible personnel interviewed who confirm release notes are prepared for all updates, including details and impact of the update, and how the version number was changed to reflect the application update.

Modified p. 118 → 99

<Report Findings Here>  Identify the release notes provided with each of the updates examined in the sampling.

Describe the sample of application updates examined. <Report Findings Here> Identify the release notes provided with each of the updates examined in the sampling.

Modified p. 118 → 99

<Report Findings Here>  Describe how the release notes were verified to be provided with the update.

<Report Findings Here> Describe how the release notes were verified to be provided with the update.

Removed p. 119

Assessor’s Response Summary of Findings (check one) Not Applicable 8.1 The payment application must be able to be implemented into a secure network environment. Application must not interfere with use of devices, applications, or configurations required for PCI DSS compliance.

Aligns with PCI DSS Requirement 2.2.2

Modified p. 119 → 100

Requirement 8: Facilitate secure network implementation PA-DSS Requirements and Testing Procedures Reporting Instruction ~~ROV~~ Reporting Details:

Requirement 8: Facilitate secure network implementation PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) 8.1 The payment application must be able to be implemented into a secure network environment. Application must not interfere with use of devices, applications, or configurations required for PCI DSS compliance.

Modified p. 119 → 100

 Describe the testing performed to verify that the payment application can run in a network that is fully compliant with PCI DSS.

Describe the testing performed to verify that the payment application can run in a network that is fully compliant with PCI DSS.

Modified p. 119 → 100

<Report Findings Here>  Provide the name of the PA-QSA who attests that the application was installed in a PCI DSS compliant laboratory environment, according to the PA-DSS Implementation Guide, consistent with Appendix B for confirmation of the configuration and setup of the lab.

<Report Findings Here> Provide the name of the PA-QSA who attests that the application was installed in a PCI DSS compliant laboratory environment, according to the PA-DSS Implementation Guide, consistent with Appendix B for confirmation of the configuration and setup of the lab.

Modified p. 119 → 100

<Report Findings Here> 8.1.b Test the application and underlying systems to verify that the payment application does not preclude the use of or interfere with PCI DSS functions on underlying systems

•for example, the application does not inhibit installation of patches or anti-malware updates ~~•or interfere with the operation of other PCI DSS functions.~~

<Report Findings Here> 8.1.b Test the application and underlying systems to verify that the payment application does not preclude the use of or interfere with PCI DSS functions on underlying systems

•for example, the application does not inhibit installation of patches or anti-malware updates

Modified p. 119 → 100

 Describe the testing performed on the application and underlying systems to verify that the payment application does not preclude the use of PCI DSS functions on underlying systems.

Describe the testing performed on the application and underlying systems to verify that the payment application does not preclude the use of PCI DSS functions on underlying systems.

Modified p. 119 → 100

<Report Findings Here>  Describe the testing performed on the application and underlying systems to verify that the payment application does not interfere with the use of PCI DSS functions on underlying systems.

<Report Findings Here> Describe the testing performed on the application and underlying systems to verify that the payment application does not interfere with the use of PCI DSS functions on underlying systems.

Modified p. 119 → 100

For example, if NetBIOS, file-sharing, Telnet, FTP, etc., are required by the application, they are secured via SSH, S-FTP, ~~SSL,~~ IPSec, or other technology.

For example, if NetBIOS, file-sharing, Telnet, FTP, etc., are required by the application, they are secured via SSH, S-FTP, TLS, IPSec, or other technology.

Modified p. 120 → 100

~~Assessor’s Response Summary of Findings (check one) Not Applicable~~ 8.2.a Examine system services, protocols, daemons, components, and dependent software and hardware enabled or required by the ~~payment application. Verify that only necessary and secure services, protocols, daemons, components, dependent software and hardware are enabled by default “out of the box.” ~~ Identify the system services, protocols, daemons, components, dependent hardware, and dependent software enabled or required by the payment application.

Aligns with PCI DSS Requirement 2.2.3 8.2.a Examine system services, protocols, daemons, components, and dependent software and hardware enabled or required by the Identify the system services, protocols, daemons, components, dependent hardware, and dependent software enabled or required by the payment application.

Removed p. 121

Assessor’s Response Summary of Findings (check one) Not Applicable 8.3 The payment application must not require use of services or protocols that preclude the use of or interfere with normal operation of two-factor authentication technologies for secure remote access (network-level access originating from outside the network) to network resources residing within the CDE).

Modified p. 121 → 102

~~ Something you know, such as a password or passphrase  Something you have, such as a token device or smart card ~~ Something you are, such as a biometric Examples of two-factor technologies include RADIUS with tokens, TACACS with tokens, or other technologies that facilitate two-factor authentication.

• Something you are, such as a biometric Examples of two-factor technologies include RADIUS with tokens, TACACS with tokens, or other technologies that facilitate two-factor authentication.

Modified p. 121 → 102

 Describe the payment application functionality examined to verify that the payment application does not require use of services or protocols that preclude the use of or interfere with normal operation of two-factor authentication technologies for remote access.

Describe the payment application functionality examined to verify that the payment application does not require use of services or protocols that preclude the use of or interfere with normal operation of two-factor authentication technologies for remote access.

Modified p. 121 → 102

 Identify remote access mechanisms (if any) supported by the application.

Identify remote access mechanisms (if any) supported by the application.

Modified p. 121 → 102

<Report Findings Here>  Describe testing performed to verify the remote access mechanisms do not prevent two-factor authentication.

<Report Findings Here> Describe testing performed to verify the remote access mechanisms do not prevent two-factor authentication.

Removed p. 122

Assessor’s Response Summary of Findings (check one) Not Applicable 9.1 The payment application must be developed such that any web server and any cardholder data storage component (for example, a database server) are not required to be on the same server, nor is the data storage component required to be on the same network zone (such as a DMZ) with the web server.

Modified p. 122 → 103

Requirement 9: Cardholder data must never be stored on a server connected to the Internet PA-DSS Requirements and Testing Procedures Reporting Instruction ~~ROV~~ Reporting Details:

Requirement 9: Cardholder data must never be stored on a server connected to the Internet PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 9.1 The payment application must be developed such that any web server and any cardholder data storage component (for example, a database server) are not required to be on the same server, nor is the data storage component required to be on the same network zone …

Modified p. 122 → 103

 Identify all data storage components. <Report Findings Here>  Identify all web servers. <Report Findings Here>  After installing data storage components and web servers on different servers, describe the testing of application functionality across the different servers that verified that the payment application does not require any data storage component to be installed on the same server as a web server.

Identify all data storage components. <Report Findings Here> Identify all web servers. <Report Findings Here> After installing data storage components and web servers on different servers, describe the testing of application functionality across the different servers that verified that the payment application does not require any data storage component to be installed on the same server as a web server.

Modified p. 122 → 103

 After installing data storage components and web servers on different network zones, describe the testing of application functionality across the different network zones that verified that the payment application does not require any data storage component to be installed on the same network zone as a web server.

After installing data storage components and web servers on different network zones, describe the testing of application functionality across the different network zones that verified that the payment application does not require any data storage component to be installed on the same network zone as a web server.

Removed p. 123

 Instructions on how to configure the payment application to use a DMZ to separate the Internet from systems storing cardholder data (for example, installing a web server component in a DMZ and installing a data storage component on an internal different network zone).

 A list of services/ports that the application needs to use in order to communicate across two network zones (so the merchant can configure their firewall to open only required ports).

Modified p. 123 → 103

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 9.1.c Examine PA-DSS Implementation Guide prepared by vendor to verify it includes the following instructions for customers and integrators/resellers:

<Report Findings Here> 9.1.c Examine PA-DSS Implementation Guide prepared by vendor to verify it includes the following instructions for customers and integrators/resellers:

Modified p. 123 → 103

 Instructions not to store cardholder data on public-facing systems (for example, web server and database server must not be on same server).

• Instructions not to store cardholder data on public-facing systems (for example, web server and database server must not be on same server).

Modified p. 123 → 104

~~<Report Findings Here>~~  A list of services/ports that the application needs to use in order to communicate across two network zones.

 A list of services/ports that the application needs to use in order to communicate across two network zones.

Removed p. 124

Assessor’s Response Summary of Findings (check one) Not Applicable 10.1 Two-factor authentication must be used for all remote access to the payment application that originates from outside the customer environment.

Modified p. 124 → 105

Requirement 10: Facilitate secure remote access to payment application PA-DSS Requirements and Testing Procedures Reporting Instruction ~~ROV~~ Reporting Details:

Requirement 10: Facilitate secure remote access to payment application PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 10.1 Two-factor authentication must be used for all remote access to the payment application that originates from outside the customer environment.

Modified p. 124 → 105

Note: Two-factor authentication requires that two of the three authentication methods be used for authentication (see ~~PA- DSS~~ Requirement 3.1.4 for descriptions of authentication methods).

Note: Two-factor authentication requires that two of the three authentication methods be used for authentication (see PA-DSS Requirement 3.1.4 for descriptions of authentication methods).

Modified p. 124 → 105

 Instructions that all remote access originating from outside the customer’s network to the payment application must use two-factor authentication in order to meet PCI DSS requirements.  A description of two-factor authentication mechanisms supported by the application.  Instructions for configuring the application to support two-factor authentication (two of the three authentication methods described in PA DSS Requirement 3.1.4).

• Instructions that all remote access originating from outside the customer’s network to the payment application must use two-factor authentication in order to meet PCI DSS requirements.

Modified p. 124 → 105

<Report Findings Here>  Instructions for configuring the application to support ~~two-factor~~ authentication (two of the three authentication methods described in PA DSS Requirement 3.1.4).

<Report Findings Here>  Instructions for configuring the application to support two- factor authentication (two of the three authentication methods described in PA DSS Requirement 3.1.4).

Modified p. 124 → 106

~~(continued on next page)  Identify whether~~ the ~~application~~ vendor ~~has~~ remote access to a ~~customer’s~~ payment application that originates from outside the customer environment. ~~(yes/no) <Report Findings Here>~~

<Report Findings Here> Describe how it was verified that the vendor does not have remote access to a customer payment application that originates from outside the customer environment.

Removed p. 125

<Report Findings Here>  Describe the two-factor technologies supported by the vendor including which factors are used (something you know, something you are, something you have).

<Report Findings Here>  Describe how it was verified that the vendor does not have remote access to a customer payment application that originates from outside the customer environment.

Modified p. 125 → 105

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable ~~ Identify the vendor policy documentation examined to verify that the vendor supports customer requirements for two-factor authentication for all remote access that originates from outside the customer environment.

Indicate whether the application vendor has remote access to a customer’s payment application that originates from outside the customer environment. (yes/no) <Report Findings Here> Identify the vendor policy documentation examined to verify that the vendor supports customer requirements for two-factor authentication for all remote access that originates from outside the customer environment.

Modified p. 126 → 106

~~Assessor’s Response Summary of Findings (check one) Not Applicable~~ 10.2.1.a If payment application updates are delivered via remote access into customers’ systems, examine PA-DSS Implementation Guide prepared by vendor, and verify it contains:

Aligns with PCI DSS Requirements 1 and 12.3.9 10.2.1.a If payment application updates are delivered via remote access into customers’ systems, examine PA-DSS Implementation Guide prepared by vendor, and verify it contains:

Modified p. 126 → 106

 Instructions for customers and integrators/resellers regarding secure use of remote-access technologies, specifying that remote-access technologies used by vendors and business partners should be activated only when needed and immediately deactivated after use.  Recommendation for customers and integrators/resellers to use a securely configured firewall or a personal firewall product if computer is connected via VPN or other high-speed connection, to secure these “always-on” connections, per PCI DSS Requirement 1.

• Instructions for customers and integrators/resellers regarding secure use of remote-access technologies, specifying that remote-access technologies used by vendors and business partners should be activated only when needed and immediately deactivated after use.

Modified p. 126 → 106

~~ Identify~~ whether payment application updates are delivered via remote access into customers’ systems. (yes/no) If “no,” mark 10.2.1 as not applicable above and proceed to 10.2.2.

• Recommendation for customers and integrators/resellers to use a securely configured firewall or a personal firewall product if computer is connected via VPN or Indicate whether payment application updates are delivered via remote access into customers’ systems. (yes/no) If “no,” mark 10.2.1 as not applicable above and proceed to 10.2.2.

Modified p. 126 → 107

~~<Report Findings Here>~~  Recommendation for customers and resellers/ integrators to use a securely configured firewall or a personal firewall product if computer is connected via VPN or other ~~high-speed~~ connection, to secure these “always-on” connections, per PCI DSS Requirement 1.

 Recommendation for customers and resellers/ integrators to use a securely configured firewall or a personal firewall product if computer is connected via VPN or other high- speed connection, to secure these “always-on” connections, per PCI DSS Requirement 1.

Modified p. 126 → 107

~~ Activation of remote-access~~ Describe the methods observed to verify that:

Describe the methods observed to verify that:

Removed p. 127

Assessor’s Response Summary of Findings (check one) Not Applicable technologies to customer networks only when needed and immediate deactivation after use.  If remote access is via VPN or other high-speed connection, the connection is secured according to PCI DSS Requirement 1.

Modified p. 127 → 107

 The connection is secured according to PCI DSS Requirement 1 (if remote access is via VPN or other ~~high-speed~~ connection).

<Report Findings Here>  The connection is secured according to PCI DSS Requirement 1 (if remote access is via VPN or other high- speed connection).

Modified p. 127 → 107

<Report Findings Here> 10.2.2 If vendors or integrators/resellers can access customers’ payment applications remotely, a unique authentication credential (such as a password/phrase) must be used for each ~~customer environment.~~

<Report Findings Here> 10.2.2 If vendors or integrators/resellers can access customers’ payment applications remotely, a unique authentication credential (such as a password/phrase) must be used for each customer.

Modified p. 127 → 107

Aligns with PCI DSS Requirements 8.5.1 10.2.2 If vendors or integrators/resellers can access customers’ payment applications remotely, examine vendor processes and interview personnel to verify that a unique ~~password~~ is used for each customer ~~environment~~ they have access to.

Aligns with PCI DSS Requirements 8.5.1 ☐ ☐ ☐ 10.2.2 If vendors or integrators/resellers can access customers’ payment applications remotely, examine vendor processes and interview personnel to verify that a unique authentication credential (such as a password/phrase) is used for each customer they have access to.

Modified p. 127 → 107

~~ Identify~~ whether vendors, integrators/resellers, or customers can access customer’s payment applications remotely. (yes/no) If “no,” mark 10.2.2 and 10.2.3 “not applicable.” ~~<Report Findings Here> ~~ If “yes,” ~~identify~~ the ~~vendor policy documentation verified to include that a unique password to be used for each customer environment they have access to.~~

Indicate whether vendors, integrators/resellers, or customers can access customer’s payment applications remotely. (yes/no) If “no,” mark 10.2.2 and 10.2.3 “not applicable.” If “yes,” complete the below:

Modified p. 127 → 107

<Report Findings Here>  Identify the responsible personnel interviewed who verify that a unique ~~password~~ is used for each customer ~~environment~~ the vendor has access to.

<Report Findings Here> Identify the responsible personnel interviewed who verify that a unique authentication credential is used for each customer the vendor has access to.

Modified p. 127 → 107

<Report Findings Here> ~~ Describe how processes observed verify~~ that a unique ~~password is~~ used for each customer ~~environment the vendor has~~ access to.

<Report Findings Here> Identify the vendor policy documentation verified to include that a unique authentication credential to be used for each customer they have access to.

Modified p. 128 → 108

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 10.2.3 Remote access to customers’ payment applications by vendors, integrators/resellers, or customers must be implemented securely, for example:

<Report Findings Here> 10.2.3 Remote access to customers’ payment applications by vendors, integrators/resellers, or customers must be implemented securely, for example:

Modified p. 128 → 108

 Change default settings in the remote-access software (for example, change default passwords and use unique passwords for each customer).  Allow connections only from specific (known) IP/MAC addresses.  Use strong authentication and complex passwords for logins (See PA-DSS Requirements 3.1.1 through 3.1.11).  Enable encrypted data transmission according to PA-DSS Requirement 12.1  Enable account lockout after a certain number of failed login attempts (See PA-DSS Requirement 3.1.9 through 3.1.10.)  Establish a VPN connection via a firewall …

• Change default settings in the remote-access software (for example, change default passwords and use unique passwords for each customer). • Allow connections only from specific (known) IP/MAC addresses. • Use strong authentication and complex passwords for logins (See PA-DSS Requirements 3.1.1 through 3.1.11). • Enable encrypted data transmission according to PA-DSS Requirement 12.1 • Enable account lockout after a certain number of failed login attempts (See PA-DSS Requirement 3.1.9 through 3.1.10.) • Establish a VPN connection via a firewall …

Modified p. 128 → 108

 Change default settings in the remote-access software (for example, change default passwords and use unique passwords for each customer).  Allow connections only from specific (known) IP/MAC addresses.  Use strong authentication and complex passwords for logins (See PA-DSS ~~Requirements 3.1.1 through 3.1.11) (continued on next page) ~~ Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers that all remote access to the payment application must be implemented securely.

• Enable encrypted data transmission according to PA-DSS Requirement 12.1 Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers that all remote access to the payment application must be implemented securely.

Removed p. 129

Assessor’s Response Summary of Findings (check one) Not Applicable  Enable encrypted data transmission according to PA- DSS Requirement 12.1  Enable account lockout after a certain number of failed login attempts (See PA-DSS Requirement 3.1.9-3.1.10)  Establish a VPN connection via a firewall before access is allowed.  Enable the logging function.  Restrict access to customer environments to authorized personnel.

Modified p. 129 → 109

 Describe the PA-DSS Implementation Guide’s instructions for customers and integrators/resellers for secure implementation of remote access to the payment application.

Describe the PA-DSS Implementation Guide’s instructions for customers and integrators/resellers for secure implementation of remote access to the payment application.

Modified p. 129 → 109

~~ Identify~~ whether the software vendor can access customers’ payment applications remotely. (yes/no) If “no,” mark the remainder of 10.2.3.b as “not applicable.” ~~<Report Findings Here>  Describe~~ the ~~software vendor’s remote- access methods observed verify that remote access is implemented securely.~~

Indicate whether the software vendor can access customers’ payment applications remotely. (yes/no) If “no,” mark the remainder of 10.2.3.b as “not applicable.” If “yes,” complete the below:

Modified p. 129 → 109

<Report Findings Here>  Identify the responsible personnel interviewed who confirm that remote access is implemented securely.

<Report Findings Here> Identify the responsible personnel interviewed who confirm that remote access is implemented securely.

Removed p. 130

Requirement 11: Encrypt sensitive traffic over public networks PA-DSS Requirements and Testing Procedures Reporting Instruction ROV Reporting Details:

 Only trusted keys and certificates are accepted.  The protocol in use only supports secure versions or configurations.  The encryption strength is appropriate for the encryption methodology in use Examples of open, public networks include but are not limited to:

 Identify the strong cryptography specified for use.

<Report Findings Here>  Identify the security protocols specified for use.

Modified p. 130 → 110

Assessor’s Response Summary of Findings (check one) ~~Not Applicable~~ 11.1 If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols (for example, SSL/TLSIPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including at least the following:

Requirement 11: Encrypt sensitive traffic over public networks PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 11.1 If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols (for example, SSL/TLSIPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including at least the following:

Modified p. 130 → 110

 The Internet  Wireless technologies, including but not limited to 802.11 and Bluetooth  Cellular technologies, for example, Global System for Mobile Communications (GSM), Code division multiple access (CDMA)  General Packet Radio Service (GPRS)  Satellite communications Aligns with PCI DSS Requirement 4.1 11.1.a If the payment application sends, or facilitates sending, cardholder data over public networks, verify that strong cryptography and security protocols are provided with the application, or that use thereof is specified.

• Satellite communications Aligns with PCI DSS Requirement 4.1 11.1.a If the payment application sends, or facilitates sending, cardholder data over public networks, verify that strong cryptography and security protocols are provided with the application, or that use thereof is specified.

Modified p. 130 → 110

~~(continued on next page)  Identify~~ whether the payment application sends or facilitates sending cardholder data over public networks. (yes/no) <Report Findings Here>  If “no,” describe the testing performed to verify the application cannot facilitate such transmissions.

Indicate whether the payment application sends or facilitates sending cardholder data over public networks. (yes/no) <Report Findings Here> If “no,” describe the testing performed to verify the application cannot facilitate such transmissions.

Modified p. 130 → 110

<Report Findings Here>  Identify the strong cryptography provided with the payment application.

<Report Findings Here> Identify the strong cryptography provided with the payment application.

Modified p. 130 → 110

<Report Findings Here>  Identify the security protocols provided with the payment application.

<Report Findings Here> Identify the security protocols provided with the payment application.

Removed p. 131

Assessor’s Response Summary of Findings (check one) Not Applicable  Describe how the use of strong cryptography is specified.

<Report Findings Here>  Describe how the use of security protocols is specified.

Modified p. 131 → 110

 Instructions that strong cryptography and security protocols must be used if cardholder data is ever transmitted over public networks.  Instructions for verifying that only trusted keys and/or certificates are accepted.  How to configure the payment application to use only secure versions and secure implementations of security protocols.  How to configure the payment application to use the proper encryption strength for the encryption methodology in use.

Identify the strong cryptography specified for use. <Report Findings Here> Identify the security protocols specified for use. <Report Findings Here> Describe how the use of strong cryptography is specified. <Report Findings Here>

• Instructions that strong cryptography and security protocols must be used if cardholder data is ever transmitted over public networks. • Instructions for verifying that only trusted keys and/or certificates are accepted. • How to configure the payment application to use only secure versions and secure implementations of security …

Modified p. 132 → 111

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 11.1.c If strong cryptography and security protocols are provided with the payment application, install and test the application according to instructions in the PA-DSS Implementation Guide, and verify:

<Report Findings Here> 11.1.c If strong cryptography and security protocols are provided with the payment application, install and test the application according to instructions in the PA-DSS Implementation Guide, and verify:

Modified p. 132 → 111

~~ The protocol is implemented by default to use only trusted keys and/or certificates. ~~ The protocol is implemented by default to use only secure configurations and does not support insecure versions or configurations. ~~ Proper encryption strength is implemented for the encryption methodology in use.~~

• The protocol is implemented by default to use only secure configurations and does not support insecure versions or configurations.

Modified p. 132 → 112

~~(continued on next page)  Identify~~ whether the payment application allows and/or facilitates the sending of PANs by end-user messaging technologies. (yes/no) <Report Findings Here>  If “no,” describe how the application was observed to prevent such action.

Indicate whether the payment application allows and/or facilitates the sending of PANs by end-user messaging technologies. (yes/no) <Report Findings Here> If “no,” describe how the application was observed to prevent such action.

Modified p. 132 → 112

<Report Findings Here> If “yes,” either:  Identify and describe the solution provided with the application that:

<Report Findings Here> If “yes,” either: Identify and describe the solution provided with the application that:

Modified p. 132 → 112

 Renders the PAN unreadable; OR <Report Findings Here> ~~ Implements strong cryptography. <Report Findings Here>~~

• Renders the PAN unreadable; OR <Report Findings Here>

Removed p. 133

<Report Findings Here> 11.2.b Examine PA-DSS Implementation Guide prepared by the vendor, and verify the vendor includes directions for customers and integrators/resellers to use a solution provided with or specified for use with the application, including:

Modified p. 133 → 112

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ OR (if “yes”):  Identify and describe the solution specified for use that:

• Implements strong cryptography. <Report Findings Here> OR (if “yes”): Identify and describe the solution specified for use that:

Modified p. 133 → 112

~~ Renders the PAN unreadable; OR <Report Findings Here> ~~ Implements strong cryptography. <Report Findings Here>  Describe how use of the solution is specified.

• Implements strong cryptography. <Report Findings Here> Describe how use of the solution is specified. <Report Findings Here>

Modified p. 133 → 113

~~ Procedures for using the defined solution to render the PAN unreadable or secure the PAN with strong cryptography. ~~ Instruction that PAN must always be rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.

• Instruction that PAN must always be rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.

Modified p. 133 → 113

 The solution renders the PAN unreadable; OR <Report Findings Here>  The solution implements strong cryptography.

 The solution renders the PAN unreadable; OR <Report Findings Here>  The solution implements strong cryptography. <Report Findings Here>

Removed p. 134

Assessor’s Response Summary of Findings (check one) Not Applicable 12.1 If the payment application facilitates non-console administrative access, encrypt all such access with strong cryptography using technologies such as SSH, VPN, or SSL/TLS, for web-based management and other non-console administrative access.

Aligns with PCI DSS Requirement 2.3 12.1.a Install the payment application in a lab and test non-console administration connections to verify that a strong encryption method is invoked before the administrator’s password is requested.

 Identify whether the payment application allows non-console administration. (yes/no) <Report Findings Here>  If “no,” describe testing performed to verify the payment application does not allow non-console administration.

<Report Findings Here>  If “yes,” after installing the payment application in the lab, describe the testing of the non-console administrative connections performed to verify that a strong encryption method is invoked before the administrator’s password is requested.

 Describe payment application configuration settings examined.

<Report Findings Here>  Describe payment …

Modified p. 134 → 114

Requirement 12: Encrypt all non-console administrative access PA-DSS Requirements and Testing Procedures Reporting Instruction ~~ROV~~ Reporting Details:

Requirement 12: Encrypt all non-console administrative access PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 12.1 If the payment application facilitates non-console administrative access, encrypt all such access with strong cryptography using technologies such as SSH, VPN, or TLS, for web-based management and other non-console administrative access.

Removed p. 135

<Report Findings Here> 12.2 Instruct customers to encrypt all non-console administrative access with strong cryptography, using technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

Note: Clear-text protocols such as Telnet or rlogin must never be used for administrative access.

Aligns with PCI DSS Requirement 2.3 12.2 Examine the PA-DSS Implementation Guide prepared by vendor and verify it includes instructions for customers and integrators/resellers to implement strong cryptography, using technologies such as SSH, VPN, or SSL/TLS, for encryption of all non- console administrative access.

 Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers to implement strong cryptography for encryption of all non-console administrative access.

Modified p. 135 → 115

~~Assessor’s Response Summary of Findings (check one) Not Applicable 12.1.c~~ Examine the PA-DSS Implementation Guide prepared by ~~vendor,~~ and verify it includes instructions for customers and integrators/resellers ~~how~~ to ~~configure the application to use~~ strong cryptography, using technologies such as SSH, VPN, or ~~SSL/TLS,~~ for encryption of non-console administrative access.

Aligns with PCI DSS Requirement 2.3 12.2 Examine the PA-DSS Implementation Guide prepared by vendor and verify it includes instructions for customers and integrators/resellers to implement strong cryptography, using technologies such as SSH, VPN, or TLS, for encryption of all non-console administrative access.

Modified p. 135 → 115

 Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include ~~directions~~ for customers and integrators/resellers ~~that define how~~ to ~~configure the application to use~~ strong cryptography for encryption of non-console administrative access.

Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers to implement strong cryptography for encryption of all non-console administrative access.

Modified p. 136 → 116

Requirement 13: Maintain a PA-DSS Implementation Guide for customers, resellers, and integrators PA-DSS Requirements and Testing Procedures Reporting Instruction ~~ROV~~ Reporting Details:

Requirement 13: Maintain a PA-DSS Implementation Guide for customers, resellers, and integrators PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 13.1 Develop, maintain, and disseminate a PA-DSS Implementation Guide(s) for customers, resellers, and integrators that accomplishes the following: ☐ ☐ ☐ 13.1 Examine the PA-DSS Implementation Guide and related vendor processes, and interview personnel to verify:

Modified p. 136 → 116

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable 13.1 Develop, maintain, and disseminate a~~ PA-DSS Implementation ~~Guide(s) for~~ customers, resellers, and integrators ~~that accomplishes the following:~~

<Report Findings Here> Identify the mechanism in place to provide the PA-DSS Implementation Guide to customers, resellers, and integrators upon request.

Modified p. 136 → 116

~~ The PA-DSS Implementation Guide is disseminated to all customers, resellers, and integrators with the application. ~~ The vendor has a mechanism in place to provide the PA-DSS Implementation Guide to customers, resellers, and integrators upon request.

• The vendor has a mechanism in place to provide the PA-DSS Implementation Guide to customers, resellers, and integrators upon request.

Modified p. 136 → 116

~~ The PA-DSS Implementation Guide is disseminated to all customers, resellers, and integrators with the application. ~~ The vendor has a mechanism in place to provide the PA-DSS Implementation Guide to customers, resellers, and integrators upon request.

• The vendor has a mechanism in place to provide the PA-DSS Implementation Guide to customers, resellers, and integrators upon request.

Modified p. 136 → 116

 Identify the related vendor process documents reviewed to verify processes define that:

Identify the related vendor process documents reviewed to verify processes define that:

Modified p. 136 → 116

~~<Report Findings Here>  Identify the mechanism in place to provide the~~ PA-DSS Implementation Guide to customers, resellers, and integrators ~~upon request.~~

• The PA-DSS Implementation Guide is disseminated to all customers, resellers, and integrators with the application.

Modified p. 136 → 116

<Report Findings Here>  Identify the personnel interviewed for this testing procedure.

<Report Findings Here> Identify the personnel interviewed for this testing procedure. <Report Findings Here> For the interview, summarize the relevant details discussed that verify that:

Modified p. 136 → 116

<Report Findings Here>  The vendor has a mechanism in place to provide the ~~PA-DSS~~ Implementation Guide to customers, resellers, and integrators upon request.

<Report Findings Here>  The vendor has a mechanism in place to provide the PA- DSS Implementation Guide to customers, resellers, and integrators upon request.

Removed p. 137

Assessor’s Response Summary of Findings (check one) Not Applicable 13.1.1 Provides relevant information specific to the application for customers, resellers, and integrators to use.

13.1.3.a Examine the PA-DSS Implementation Guide and interview personnel to verify the PA-DSS Implementation Guide is reviewed:

 At least annually <Report Findings Here>  Upon changes to the application <Report Findings Here>  Upon changes to these PA-DSS requirements <Report Findings Here>

Modified p. 137 → 116

~~ Clearly identifies the payment application name and version to which it applies. ~~ Provides details of all application dependencies that are required in order for the application to be configured in a PCI DSS compliant manner.

• Provides details of all application dependencies that are required in order for the application to be configured in a PCI DSS compliant manner.

Modified p. 137 → 116

<Report Findings Here> 13.1.2 Addresses all requirements in this document wherever the PA-DSS Implementation Guide is referenced.

<Report Findings Here> 13.1.2 Addresses all requirements in this document wherever the PA-DSS Implementation Guide is referenced. ☐ ☐ ☐

Modified p. 137 → 117

 Provide the name of the PA-QSA who attests that the ~~PA-DSS~~ Implementation Guide was verified to include all related requirements specifically indicated in Appendix A of the ~~PA-DSS 3.0~~ document.

Provide the name of the PA-QSA who attests that the PA- DSS Implementation Guide was verified to include all related requirements specifically indicated in Appendix A of the PA- DSS 3.1 document.

Modified p. 137 → 117

<Report Findings Here> 13.1.3 Includes a review at least annually and upon changes to the application or to the PA-DSS requirements, and is updated as needed to keep the documentation current with all changes affecting the application, as well as with changes to the requirements in this document.

<Report Findings Here> 13.1.3 Includes a review at least annually and upon changes to the application or to the PA-DSS requirements, and is updated as needed to keep the documentation current with all changes affecting the application, as well as with changes to the requirements in this document. ☐ ☐ ☐ 13.1.3.a Examine the PA-DSS Implementation Guide and interview personnel to verify the PA- DSS Implementation Guide is reviewed:

Modified p. 137 → 117

~~ At least annually,  Upon changes to the application ~~ Upon changes to these PA-DSS requirements ~~(continued on next page) ~~ Describe how the PA-DSS Implementation Guide was examined to verify it is reviewed:

• Upon changes to these PA-DSS requirements Describe how the PA-DSS Implementation Guide was examined to verify it is reviewed:

Removed p. 138

<Report Findings Here>  Describe the mechanism in place to communicate updates to customers, resellers, and integrators.

<Report Findings Here>  Describe the mechanism in place to provide updated versions as needed.

Modified p. 138 → 117

Assessor’s Response Summary of Findings (check one) Not Applicable  Identify the personnel interviewed for this testing procedure who confirm the PA-DSS Implementation Guide is reviewed  At least annually,  Upon changes to the application  Upon changes to these PA-DSS requirements <Report Findings Here> 13.1.3.b Verify the PA-DSS Implementation Guide is updated as needed to keep current with:

• Upon changes to these PA-DSS requirements <Report Findings Here> 13.1.3.b Verify the PA-DSS Implementation Guide is updated as needed to keep current with:

Modified p. 138 → 117

~~ Changes to the PA-DSS requirements. ~~ Changes to the application or its dependencies.

• Changes to the application or its dependencies.

Modified p. 138 → 117

 Changes to the PA-DSS requirements. <Report Findings Here>  Changes to the application or its dependencies.

 Changes to the PA-DSS requirements. <Report Findings Here>  Changes to the application or its dependencies. <Report Findings Here> 13.1.3.c Examine the PA-DSS Implementation Guide and related vendor processes, and interview personnel to verify the vendor has a mechanism in place to communicate updates to customers, resellers, and integrators, and provide updated versions as needed.

Modified p. 138 → 117

<Report Findings Here> ~~13.1.3.c Examine~~ the ~~PA-DSS Implementation Guide and related vendor processes, and interview personnel to verify the vendor has a~~ mechanism in place to communicate updates to customers, resellers, and ~~integrators, and provide updated versions as needed.~~

<Report Findings Here> Describe the mechanism in place to communicate updates to customers, resellers, and integrators.

Modified p. 138 → 117

~~(continued on next page) ~~ Identify the related vendor process documents reviewed to verify processes define that the vendor has a mechanism in place to:

Identify the related vendor process documents reviewed to verify processes define that the vendor has a mechanism in place to:

Modified p. 138 → 117

 Communicate updates to customers, resellers, and integrators. ~~ Provide updated versions as needed.~~

• Communicate updates to customers, resellers, and integrators.

Modified p. 138 → 118

<Report Findings Here>  Identify the personnel interviewed for this testing procedure.

<Report Findings Here> Identify the personnel interviewed for this testing procedure. <Report Findings Here> For the interview, summarize the relevant details discussed that verify that:

Removed p. 139

Assessor’s Response Summary of Findings (check one) Not Applicable For the interview, summarize the relevant details discussed that verify that:

Modified p. 139 → 118

<Report Findings Here>  The vendor provides updated versions as needed.

<Report Findings Here>  The vendor provides updated versions as needed. <Report Findings Here>

Removed p. 140

<Report Findings Here>  Identify the personnel interviewed for this testing procedure.

 Overall accountability for meeting all the requirements in PA-DSS  Keeping up-to-date within any changes in the PA-DSS Program Guide  Ensuring secure coding practices are followed  Ensuring integrators/resellers receive training and supporting materials  Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training

Modified p. 140 → 119

Requirement 14: Assign PA-DSS responsibilities for personnel and maintain training programs for personnel, customers, resellers, and integrators PA-DSS Requirements and Testing Procedures Reporting Instruction ~~ROV~~ Reporting Details:

Requirement 14: Assign PA-DSS responsibilities for personnel and maintain training programs for personnel, customers, resellers, and integrators PA-DSS Requirements and Testing Procedures Reporting Instruction /ROV Reporting Details:

Modified p. 140 → 119

Assessor’s Response Summary of Findings (check one) ~~Not Applicable~~ 14.1 Provide training in information security and PA-DSS for vendor personnel with PA-DSS responsibility at least annually.

Assessor’s Response Summary of Findings (check one) In Place N/A 14.1 Provide training in information security and PA-DSS for vendor personnel with PA-DSS responsibility at least annually. ☐ ☐ ☐ 14.1 Examine training materials and interview responsible personnel to verify that all vendor personnel with PA-DSS responsibility receive training in PA-DSS and information security at least annually.

Modified p. 140 → 119

<Report Findings Here> 14.2 Assign roles and responsibilities to vendor personnel including the following:

 Receive training in PA-DSS at least annually. <Report Findings Here>  Receive training in information security at least annually. <Report Findings Here> 14.2 Assign roles and responsibilities to vendor personnel including the following:

Removed p. 141

 Overall accountability for meeting all the requirements in PA-DSS.  Keeping up-to-date within any changes in the PA-DSS Program Guide.  Ensuring secure coding practices are followed.  Ensuring integrators/resellers receive training and supporting materials.  Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training.

 Overall accountability for meeting all the requirements in PA-DSS.  Keeping up-to-date within any changes in the PA-DSS Program Guide.  Ensuring secure coding practices are followed.  Ensuring integrators/resellers receive training and supporting materials.  Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training.

<Report Findings Here>  Ensuring all vendor personnel with PA- DSS responsibilities, including developers, receive training.

Modified p. 141 → 120

Assessor’s Response Summary of Findings (check one) ~~Not Applicable~~ 14.2.a Examine documented responsibilities to verify that responsibility for the following roles is formally assigned:

Assessor’s Response Summary of Findings (check one) In Place N/A 14.2.a Examine documented responsibilities to verify that responsibility for the following roles is formally assigned:

Modified p. 141 → 120

 Identify the document(s) examined that verify responsibility for the following roles is formally assigned:

Identify the document(s) examined that verify responsibility for the following roles is formally assigned:

Modified p. 141 → 120

 Overall accountability for meeting all the requirements in PA-DSS.  Keeping up-to-date within any changes in the PA-DSS Program Guide.  Ensuring secure coding practices are followed.  Ensuring integrators/resellers receive training and supporting materials.  Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training.

• Overall accountability for meeting all the requirements in PA-DSS. • Keeping up-to-date within any changes in the PA-DSS Program Guide. • Ensuring secure coding practices are followed. • Ensuring integrators/resellers receive training and supporting materials. • Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training.

Modified p. 141 → 120

<Report Findings Here>  Ensuring secure coding practices are followed.

<Report Findings Here>  Ensuring secure coding practices are followed. <Report Findings Here>  Ensuring integrators/resellers receive training and supporting materials.

Modified p. 141 → 120

<Report Findings Here>  Ensuring ~~integrators/resellers~~ receive ~~training and supporting materials.~~

<Report Findings Here>  Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training.

Removed p. 142

 How to implement the payment application and related systems and networks in a PCI DSS-compliant manner  Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A) 14.3.a Examine the training materials for integrators and resellers, and confirm the materials include the following:

Modified p. 142 → 120

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 14.3 Develop and implement training and communication programs for payment application integrators and resellers. Training should include at least the following:

<Report Findings Here> 14.3 Develop and implement training and communication programs for payment application integrators and resellers. Training should include at least the following:

Modified p. 142 → 120

~~ Training on how~~ to implement the payment application ~~in a PCI DSS- compliant manner.  Training on how to implement~~ related systems and networks in a PCI DSS-compliant ~~manner.  Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A).~~

• How to implement the payment application and related systems and networks in a PCI DSS-compliant manner

Modified p. 142 → 121

 Training on how to implement the payment application and related systems and networks in a PCI DSS-compliant manner. ~~ Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A).~~

• Training on how to implement the payment application and related systems and networks in a PCI DSS-compliant manner.

Modified p. 142 → 121

 Identify the training materials verified to include the following:

Identify the training materials verified to include the following:

Modified p. 142 → 121

~~ Training materials are provided to integrators and resellers. ~~ The vendor has a mechanism in place to provide updated materials to integrators and resellers upon request.

• The vendor has a mechanism in place to provide updated materials to integrators and resellers upon request.

Modified p. 142 → 121

~~<Report Findings Here>  Identify the vendor personnel interviewed who confirm that  Training materials are provided to integrators and resellers. ~~ The vendor has a mechanism in place to provide updated materials to integrators and resellers upon request.

• The vendor has a mechanism in place to provide updated materials to integrators and resellers upon request.

Modified p. 142 → 121

 Identify the sample of integrators and resellers interviewed who confirm that they received the training and training materials from the application vendor.

Identify the sample of integrators and resellers interviewed who confirm that they received the training and training materials from the application vendor.

Removed p. 143

<Report Findings Here>  Reviewed upon changes to the PA- DSS requirements.

Modified p. 143 → 121

~~Assessor’s Response Summary of~~ Findings ~~(check one) Not Applicable~~ 14.3.d Examine evidence of integrators and resellers receipt of the training materials from the software vendor.

<Report Findings Here> 14.3.d Examine evidence of integrators and resellers receipt of the training materials from the software vendor.

Modified p. 143 → 121

 Describe evidence examined that verified receipt of the training materials from the software vendor.

Describe evidence examined that verified receipt of the training materials from the software vendor.

Modified p. 143 → 121

14.3.1.a Examine the training materials for integrators and resellers ~~and~~ verify the materials are:

14.3.1.a Examine the training materials for Describe the training materials for integrators and resellers observed to verify the materials are:

Modified p. 143 → 122

~~ Reviewed at least annually and upon changes to the application or to PA-DSS requirements. ~~ Updated as needed to keep the documentation current with new payment application versions and changes to ~~PA-DSS~~ requirements.

• Updated as needed to keep the documentation current with new payment application versions and changes to PA- DSS requirements.

Modified p. 143 → 122

~~Describe the training materials for~~ integrators and resellers ~~observed to~~ verify the materials are:

Assessor’s Response Summary of Findings (check one) In Place N/A integrators and resellers and verify the materials are:

Modified p. 143 → 122

 Reviewed at least ~~annually. <Report Findings Here>  Reviewed~~ upon changes to the ~~application.~~

• Reviewed at least annually and upon changes to the application or to PA-DSS requirements.

Modified p. 143 → 122

<Report Findings Here>  Updated as needed to keep the documentation current with new payment application versions.

 Reviewed at least annually. <Report Findings Here>  Reviewed upon changes to the application. <Report Findings Here>  Reviewed upon changes to the PA-DSS requirements. <Report Findings Here>  Updated as needed to keep the documentation current with new payment application versions.

Modified p. 143 → 122

 Identify the document that includes the distribution process to integrators and resellers for new payment application versions.

Identify the document that includes the distribution process to integrators and resellers for new payment application versions.

Modified p. 143 → 122

<Report Findings Here>  Describe the distribution process observed that verified

<Report Findings Here> Describe the distribution process observed that verified

Modified p. 143 → 122

 Identify the sample of integrators and resellers interviewed who confirm they received updated training materials from the application vendor.

Identify the sample of integrators and resellers interviewed who confirm they received updated training materials from the application vendor.

Modified p. 146 → 125

The following must be provided for customers and integrators/resellers:  Details of any configurable options for each method used by the application to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment application (per PA-DSS Requirement 2.1).  A list of all instances where cardholder data may be output for the ~~merchant~~ to store outside of the payment application, and instructions that the ~~merchant~~ is responsible …

The following must be provided for customers and integrators/resellers:  Details of any configurable options for each method used by the application to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment application (per PA-DSS Requirement 2.1).  A list of all instances where cardholder data may be output for the customer to store outside of the payment application, and instructions that the customer is responsible …

Modified p. 146 → 125

The following must be provided for customers and integrators/resellers:  How to securely generate, distribute, protect, change, store, and retire/replace ~~encryption~~ keys, where customers or integrators/resellers are involved in these key-management activities.  A sample Key Custodian Form for key custodians to acknowledge that they understand and accept their key-custodian responsibilities.

The following must be provided for customers and integrators/resellers:  How to securely generate, distribute, protect, change, store, and retire/replace cryptographic keys, where customers or integrators/resellers are involved in these key-management activities.  A sample Key Custodian Form for key custodians to acknowledge that they understand and accept their key-custodian responsibilities.

Modified p. 148 → 127

 Enforcing secure changes to authentication credentials by the completion of installation per PA-DSS requirements 3.1.1 through 3.1.11.  Enforcing secure changes to authentication credentials for any subsequent changes (after installation) per PA-DSS requirements 3.1.1 through 3.1.11.  That, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.  Assign secure authentication to default accounts ~~(even if not used),~~ …

• Enforcing secure changes to authentication credentials by the completion of installation per PA-DSS requirements 3.1.1 through 3.1.11. • Enforcing secure changes to authentication credentials for any subsequent changes (after installation) per PA-DSS requirements 3.1.1 through 3.1.11.  That, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.  Assign secure authentication to all default accounts in the environment. …

Modified p. 153 → 132

The following instructions must be provided for customers and integrators/resellers:  Instructions not to store cardholder data on public- facing systems (for example, web server and database server must not be on same server).  Instructions on how to configure the payment application to use a DMZ to separate the Internet from systems storing cardholder data.  A list of services/ports that the application needs to use in order to communicate across two network zones (so the ~~merchant~~ can configure …

The following instructions must be provided for customers and integrators/resellers:  Instructions not to store cardholder data on public- facing systems (for example, web server and database server must not be on same server).  Instructions on how to configure the payment application to use a DMZ to separate the Internet from systems storing cardholder data.  A list of services/ports that the application needs to use in order to communicate across two network zones (so the customer can configure …

Modified p. 155 → 134

If the payment application facilitates non-console administrative access, include instructions on how to configure the application to use strong cryptography (such as SSH, VPN, or ~~SSL/TLS)~~ for encryption of all ~~non-console~~ administrative access to payment application or servers in cardholder data environment.

If the payment application facilitates non-console administrative access, include instructions on how to configure the application to use strong cryptography (such as SSH, VPN, or TLS) for encryption of all non- console administrative access to payment application or servers in cardholder data environment.

Modified p. 156 → 135

Include instructions for customers and integrators/resellers to implement strong cryptography, using technologies such as SSH, VPN, or ~~SSL/TLS,~~ for encryption of all non-console administrative access.

Include instructions for customers and integrators/resellers to implement strong cryptography, using technologies such as SSH, VPN, or TLS, for encryption of all non-console administrative access.

Modified p. 157 → 136

 Describe how the PA-QSA validated the clean installation of the remote lab environment to ensure the environment truly simulates a real- world situation.

• Describe how the PA-QSA validated the clean installation of the remote lab environment to ensure the environment truly simulates a real- world situation.

Modified p. 157 → 136

 Describe how the PA-QSA validated the clean installation of the remote lab environment to ensure the vendor has not modified or tampered with the environment in any way.

• Describe how the PA-QSA validated the clean installation of the remote lab environment to ensure the vendor has not modified or tampered with the environment in any way.

Modified p. 158 → 137

 If any of the below were not in place or if there are any other comments or details related to the laboratory the PA-QSA would like to note, please indicate that here.

• If any of the below were not in place or if there are any other comments or details related to the laboratory the PA-QSA would like to note, please indicate that here.

Modified p. 161 → 140

8.b PA-QSA QA personnel verify that all PA-DSS requirements were tested against.

8.b PA-QSA QA personnel verify that all PA-DSS requirements were tested against. ☐ ☐ 8.c The PA-QSA QA personnel verify that PA-QSA laboratory configurations and processes meet requirements and were accurately documented in the report.

Document Comparison

From Revision History

Content Changes