Document Diff - PCI Watch

Added p. 5

Document name Description

PCI Payment Application Data Security Standard

• Requirements and Security Assessment Procedures (“PA-DSS”) The PA-DSS and the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms list and define the specific technical requirements and provide the assessment procedures used by PA-QSA Companies to validate the Payment Application’s compliance.

Added p. 6

PCI Report on Validation Reporting Template for PA-DSS (“ROV Reporting Template”) The ROV Reporting Template is mandatory for completing a Report on Validation and includes detail on how to document the findings of a PA-DSS Assessment.

Payment Application Data Security Standard (PA-DSS) Attestation of Validation (“AOV”) AOV is a form for PA-QSA Companies to attest to the results of a PA-DSS Assessment, as documented in the PA-DSS Report on Validation.

Payment Card Industry (PCI) Data Security Standard Qualification Requirements for Qualified Security Assessors (QSAs) (“QSA Qualification Requirements”); and Payment Card Industry (PCI) Qualification Requirements for Payment Application Qualified Security Assessors (PA-QSAs) (“PA-QSA Qualification Requirements”) The QSA Qualification Requirements and PA-QSA Qualification Requirements together define the baseline set of requirements that must be met by a PA-QSA Company and QSA Employees in order to perform PA-DSS Assessments.

The most current versions of the following additional documents are used in conjunction with the aforementioned:

Delta Assessment …

Added p. 8

PA-QSA Addendum The then-current version of (or successor document to) the Addendum to Qualified Security Assessor (QSA) Agreement for Payment Application QSAs, the current version of which is attached as Appendix A to the PA-QSA Qualification Requirements.

PA-QSA Change Impact The document template set forth as Appendix D hereto used to describe Administrative, No Impact, and Low Impact changes to a Payment Application; use is mandatory for the PA-QSA Company to submit said changes to PCI SSC, but may also be used by Vendors as a Vendor Change Analysis.

PA-QSA List The then-current list of PA-QSA Companies published by PCI SSC on the Website.

PA-QSA Requirements With respect to a given PA-QSA Company or PA-QSA Employee, the requirements and obligations thereof pursuant to the PA-QSA Qualification Requirements, the PA-QSA Addendum, the PA-DSS Program Guide, each addendum, supplement, and other agreement entered into between such PA-QSA Company or PA-QSA Employee and PCI SSC, and …

Added p. 12

 Creating PA-DSS compliant Payment Applications that facilitate and do not prevent their customers‘ PCI DSS compliance (the application cannot require an implementation or configuration setting that violates or negatively impacts a PCI DSS Requirement);  Following the best practices of the PCI DSS Requirements whenever the Vendor stores, processes, or transmits cardholder data (for example, during customer troubleshooting);  Educating customers, integrators, and resellers on how to install and configure the Payment Applications in a PCI DSS-compliant manner;  Ensuring their Payment Applications meet PA-DSS Requirements by successfully passing a PA- DSS Assessment as specified in PCI PA-DSS Requirements and Security Assessment Procedures;  Complying with the Vendor Release Agreement including the adoption and implementation of Vulnerability Handling Policies consistent with industry best practices;  Creating a PA-DSS Implementation Guide, specific to each application, in accordance with the requirements in the PA-DSS;  Adhering to their defined software versioning …

Added p. 14

Note: Not all integrators and resellers are QIRs•there are additional qualification requirements that must be met for an integrator and reseller to become a QIR.

Customers are merchants, service providers, or others who buy or receive a third-party Payment Application to store, process, or transmit cardholder data as part of authorizing or settling of payment transactions. Customers who want to use PA-DSS Validated Payment Applications to facilitate their PCI DSS compliance are responsible for:

1. The Vendor selects a PA-QSA Company from the Council‘s list of recognized PA-QSA Companies and negotiates the cost and any associated PA-QSA Company confidentiality and non-disclosure agreement with the PA-QSA Company;

2. The Vendor then provides to the PA-QSA Company the Payment Application software, corresponding PA-DSS Implementation Guide, and all associated manuals and other required documentation, including but not limited to the Vendor's signed Vendor Release Agreement;

3. The PA-QSA Company then assesses the Payment Application, including its security …

Added p. 20

 Table 4.1a provides a description and program guidance regarding Payment Applications to which PA-DSS does apply.

 Table 4.1b provides a description and program guidance regarding Payment Applications to which PA-DSS does not apply.

PA-DSS applies to Payment Applications that do not require re-compilation after merchant- or environment-specific changes. For example, entering or changing parameters such as database names, store locations, etc., during or after installation

•but without modification to the executable modules or application code

•would not be considered "customizations." However, customer- or environment-specific changes that require modification to the source code and/or re- compilation of the executable (or other payment- processing modules) on a per-merchant basis, prior to installation in the merchant environment, are likely considered to be "customized." Payment Applications provided in modules, typically including a baseline module and other modules specific to customer types or functions, or customized per customer request. PA-DSS may only apply to the baseline module …

Added p. 22

If one or more PA-DSS Requirements cannot be met by the Payment Application directly, they may be satisfied indirectly by controls tested as part of the PCI PTS validation. For a hardware device to be considered for inclusion in a PA-DSS Assessment, the hardware device MUST be validated as a PCI PTS approved POI device and be listed on the PCI SSC‘s Approved PTS Devices List. The PTS validated POI device, which provides a trusted computing environment, will become a required dependency for the Payment Application, and the combination of application and hardware will be listed together on the PA-DSS List of Validation Payment Applications.

1. Be provided together to the customer (both hardware terminal and application), OR, if provided separately, the Vendor and/or the integrator/reseller must package the application for distribution such that it will only operate on the hardware terminal on which it has been validated to run;

2. Enabled …

Added p. 24

 PA-DSS Implementation Guide;  Software Installation Guide or Instructions (as provided to customers);  Vendor‘s software versioning methodology for the application;  Vendor’s Vulnerability Handling Policies; and  Change control documentation that shows how changes are illustrated to customers;

Note: The PA-QSA Company may request additional material as necessary.

 If PCI SSC reviews the ROV more than once, providing comments back to the PA- QSA Company to address each time, this will increase the length of time for the review process.

Added p. 25

 For each PA-DSS Assessment, the resulting PA-QSA report must follow the PA-DSS Report on Validation (ROV) template and instructions, as outlined in the PA-DSS ROV Template and PA- DSS ROV Reporting Instructions.

 The PA-QSA Company must prepare each ROV based on evidence obtained by following the PA-DSS.

 Each ROV must be accompanied by an Attestation on Validation (AOV) in the form available through the Website, signed by a duly authorized officer of the PA-QSA Company, that summarizes whether the entity is in compliance or is not in compliance with PCI PA-DSS, and any related findings, as well as the PA-DSS Implementation Guide.

Added p. 25

Note: Remote access

•using two-factor authentication

•to the testing laboratory for Payment Application validation is acceptable.

For each PA-DSS Assessment, PA-QSA testing laboratory processes must include:

 Using the Vendor’s installation manual, training provided and the PA-DSS Implementation Guide to perform the default installation of the Payment Application.

 Confirming that all implementations of the Payment Application (including region/country specific versions) to be listed were tested in the testing laboratory.

Added p. 26

 Confirming that all critical Payment Application functionalities were tested.

 Confirming that the testing laboratory is capable of simulating the “real world” use of the Payment Application, including:

 Confirming that the testing laboratory uses only test card numbers.

 Confirming that the testing laboratory is capable of running authorization and/or settlement functions and that processes include examination of output from all functions.

 Confirming that the testing laboratory is capable of simulating and validating all functions of the Payment Application, which includes that the testing laboratory is capable of exploiting application vulnerabilities.

Use of the PA-QSA Company’s Testing Laboratory requires the submission of the Testing Laboratory Configuration for PA-DSS Assessments, found in ROV Reporting Template Appendix B, with each PA-DSS Assessment. This form includes a description for the laboratory configuration as part of each PA-DSS Assessment.

In the event that the PA-QSA Company Testing Laboratory is not capable of properly and fully testing all …

Added p. 31

Note: Wildcards may only be substituted for elements of the version number that represent non- security impacting changes; the use of wildcards for any change that has an impact on security or any PA-DSS Requirements is prohibited.

Only those applications that have had the Vendor’s wildcard versioning methodology assessed to PA-DSS v3.0 by a PA-QSA Company are eligible for wildcard usage, and listing on the PCI SSC website with wildcards. Changes falling within the scope of wildcard usage are not required to be advised to PCI SSC; therefore, any such changes will not result in an update to the application listing on the Website. See Appendix B, Payment Application Software Version Methodology for additional information regarding the use of wildcards.

Added p. 31

Note: Only Low Impact and No Impact changes are eligible for delta assessment.

See “Change Types” section for additional information.

As part of the delta assessment process, the entire Payment Application must be evaluated to determine which PA-DSS Requirements are affected by the change. Delta assessments involve the PA-QSA Company assessing the changes documented in the Vendor Change Analysis against the applicable subset of PA-DSS Requirements.

Delta assessments must:

 Be performed by the PA-QSA Company that performed the last Full Assessment and validation of the application;  Include all PA-DSS Requirements affected by the change;  Include verification that all other PA-DSS Requirements are not affected by the change;

Note: Due to the likelihood that technical changes to the Payment Application may also impact PA- DSS Requirements 13 and 14, the impact to PA-DSS Requirements 13 and 14 must be considered for every delta assessment.

 Include details about how, for all PA-DSS Requirements not …

Added p. 32

 Only PA-DSS Requirements 1, 7, 10, 13 and 14 are affected by the change;  All other PA-DSS Requirements are not affected by the change;  Less than half the Payment Application’s functionality is affected, and less than half of the Payment Application’s code-base is changed.

The PA-QSA performs a full assessment of PA-DSS Requirements 1, 7, 10, 13 and 14, performs Payment Application functionality testing, and completes the process in accordance with the Low Impact Changes section of this Program Guide.

Added p. 32

Note: The determination of what constitutes a change’s type depends on the nature of the change and its impact on the Payment Application or related processes, or PA-DSS Requirements. Working with the Vendor, PA-QSAs have an understanding of the Payment Application and are empowered to determine the change type that represents the proposed change.

The table on the following page summarizes wildcard usage and delta assessment eligibility for the various change types.

Added p. 33

The Vendor prepares a Vendor Change Analysis (for example, using the PA-QSA Change Impact in Appendix D is acceptable) and submits it to the PA-QSA Company for review.

If the PA-QSA Company agrees with the Vendor Change Analysis:

iii. If applicable, the Vendor modifies the PA-DSS Implementation Guide and/or completes a new VRA;

iv. The PA-QSA Company completes the PA-QSA Change Impact in Appendix D;

Added p. 34

If the Vendor has chosen to use a wildcard versioning methodology for managing No Impact changes, the wildcard usage must adhere to the requirements in this Program Guide, be consistent with that documented as part of the Vendor’s versioning methodology and be validated by the PA-QSA Company as part of the PA-DSS Assessment (PA-DSS v3.0 or above only). Changes falling within the scope of wildcard usage are not required to be advised to PCI SSC, nor will the changes result in any update to the application listing on the PCI SSC website.

If the Vendor has chosen not to use a wildcard versioning methodology for managing No Impact changes, the Vendor prepares and submits a Vendor Change Analysis (for example, using the PA-QSA Change Impact template in Appendix D is acceptable) to the PA-QSA Company that performed the last full validation of the application.

iii. The PA-QSA Company completes the PA-QSA Change …

Added p. 35

vi. Upon payment of the invoice, PCI SSC reviews the Attestation of Validation and PA-QSA Change Impact document for quality assurance purposes.

If the PA-QSA Company does not agree with the Vendor that the No Impact change (as documented in the Vendor Change Analysis) meets the No Impact change criteria, the PA- QSA Company will return the Vendor Change Analysis to the Vendor and work with the Vendor to consider the necessary actions to address the PA-QSA Company‘s observations.

ii. Sign and return a copy of the PA-DSS Attestation of Validation to both the Vendor and the PA-QSA Company. The expiry date of the newly listed Payment Application will be the same as that of the parent Payment Application.

Added p. 35

Low Impact changes are limited to changes to the Payment Application where all of the following conditions are met:

 Three or fewer high-level PA-DSS Requirements are affected, not including Requirements 13 and 14;  Less than half of all PA-DSS Requirements/sub-Requirements are affected, not including Requirements 13 and 14; and  Less than half the Payment Application’s functionality is affected and less than half the Payment Application’s code-base is changed.

While Low Impact changes are not eligible for wildcard versioning, they are eligible for delta assessment. Examples of Low Impact changes to PA-DSS related functions of a Validated Payment Application include, but are not limited to:

Note: It is strongly recommended that the Vendor uses the PA-QSA Company that performed the last full Payment Application assessment, as changing PA- QSA Companies requires a full assessment.

Added p. 36

Since the number of possible Payment Application changes and their impacts cannot be determined in advance, the type of assessment performed for Low Impact changes may be considered on a per-case basis. Vendors should contact the PA-QSA Company that performed the last full validation of the Payment Application for guidance. The PA-QSA Company determines whether a full assessment or delta assessment of the Payment Application is required, based on the degree to which the changes impact the security and/or PA-DSS related functions of the Payment Application, the impact to PA-DSS Requirements and/or the scope of the changes being made.

The Vendor prepares and submits a Vendor Change Analysis (for example, using the PA- QSA Change Impact document in Appendix D is acceptable) to the PA-QSA Company that performed the last Full validation of the application.

i. The PA-QSA Company must notify the Vendor that they agree;

ii. The PA-QSA Company performs a delta …

Added p. 37

If changes to the Payment Application meet any of the following criteria, the Payment Application must undergo a full PA-DSS Assessment:

 Four or more high-level PA-DSS Requirements are affected, not including Requirements 13 and 14;  Half or more of all PA-DSS Requirements/sub-Requirements are affected, not including Requirements 13 and 14;  Half or more of the Payment Application’s functionality is affected, or half or more of the Payment Application’s code-base is changed;  Addition of tested platform/operating system to include on the List of Validated Payment Applications; or  The change is otherwise ineligible for treatment as a Low Impact change.

Added p. 37

Note: The PA-QSA Change Impact document in Appendix D is mandatory for the PA-QSA Company for submitting Administrative, No Impact and Low Impact changes to PCI SSC but may also be used by Vendors as a Vendor Change Analysis.

Added p. 41

ROVs that have been returned to the PA-QSA Company for correction must be resubmitted to the PCI SSC within 30 days of the preceding submittal. If this is not possible, the PA-QSA Company must inform the PCI SSC of the timeline for response. Lack of response on ROVs returned to the PA-QSA Company for correction may result in the submission being closed. Submissions that have been closed will not be reopened and must be resubmitted as if they are new ROV submissions.

Note: All descriptions must be acceptable to PCI SSC, which reserves the right to modify any description at any time.

 Deployment Notes  Revalidation Date  Expiry Date  PA-QSA Company 6.3 Assessor Quality Management Program As stated in the QSA Qualification Requirements and the PA-QSA Addendum, PA-QSA Companies are required to meet all quality assurance standards set by PCI SSC. The various phases of the assessor quality management …

Added p. 46

No Vendor or other third party may refer to a Payment Application as “PCI Approved” or “PCI SSC Accepted,” nor otherwise state or imply that PCI SSC has, in whole or part, approved any aspect of a Vendor or its Payment Applications, except that to the extent PCI SSC has actually issued an Attestation of Validation with respect to the Approved Version of a Payment Application, such Approved Version may be referred to as PCI SSC Accepted or listed. All other references to PCI SSC‘s Acceptance or approval of a Payment Application or version thereof are strictly and actively prohibited by PCI SSC.

The PCI SSC’s various Program names and/or acronyms (e.g., PCI DSS, PA-DSS, PTS, etc.) are strictly prohibited from use in Vendor Payment Application Names. PCI SSC reserves the right to reject any Payment Application of which any such Program name or acronym is a part.

 Is set by …

Added p. 51

Payment Card Brands have their own compliance programs for the usage of PA-DSS Validated Payment Applications. Questions on how using an application listed as Acceptable only for Pre-Existing Deployments affects PCI DSS compliance must be addressed to the merchant’s acquirer and/or the Payment Card Brands involved.

Added p. 52

B.1 Version Number Format The format of the application version number is set by the Vendor and may be comprised of several elements. The versioning methodology and the PA-DSS Implementation Guide must fully describe the format of the application version number including the following:

 The format of the version scheme, including:

 Number of elements  Numbers of digits used for each element  Format of separators used between elements  Character set used for each element (consisting of alphabetic, numeric, and/or alphanumeric characters)  The hierarchy of the elements  Definition of what each element represents in the version scheme  Type of change: major, minor, maintenance release, wildcard, etc.

 The definition of elements that indicate any use of wildcards  The specific details of how wildcards are used in the versioning methodology B.2 Version Number Usage All changes to the Payment Application must result in a new application version …

Added p. 53

If the Vendor uses a versioning scheme that involves mapping of internal version numbers to external, published version numbers, all security-impacting changes must result in an update to the external, published version number.

Any version number that is accessible to customers and integrator/resellers must be consistent with the versioning methodology described in the PA-DSS Implementation Guide.

Vendors must ensure traceability between application changes and version numbers such that a customer or integrator/reseller may determine which changes are included in the specific version of the application they are running.

B.3 Wildcards A “wildcard” element is a variable character that may be substituted for a defined subset of possible characters in an application versioning scheme. In the context of PA-DSS, wildcards can optionally be used to represent non-security-impacting changes between each version represented by the wildcard element. A wildcard is the only variable element of the Vendor’s version scheme. Use of a wildcard element in …

Added p. 55

PA-QSA must complete each section of this document, and all required documents based on the type of change (see “Required Documents” section below). The PA-QSA is required to submit this PA-QSA Change Impact along with supporting documentation to PCI SSC for review.

Always refer to the applicable PA-DSS Program Guide for information on Payment Application changes.

Added p. 57

Indicate which PA-DSS Requirements are impacted by the change:

Added p. 57

Note: At a minimum, PA-DSS Requirements 13 & 14 must be assessed.

If any PA-DSS Requirements were excluded from the assessment, provide a description of the testing performed to validate that excluded PA-DSS Requirements are not impacted (for example, comparing code, Vendor Change Analysis, details from developer interviews, details from functionality testing, etc.):

Change Number Detailed description of the Description of why the change is necessary Description of how CHD is Description of how the change impacts application functionality

Removed p. 2

 Addition of “Qualified Integrators and Resellers” section to explain how the new QIR Program aligns with the PA-DSS Program.

 Minor change to the process for submitting a ROV to allow PCI SSC to invoice the Vendor upon receipt of a ROV and receive payment prior to reviewing the ROV.

 Clarify Vendor requirements in Appendix A for Payment Application description.

Modified p. 2

The PA-DSS Program Guide has been completely reorganized to address the needs of the different types of readers that are intended to use this document to facilitate their search for pertinent program information.

January 2012 2.0 The PA-DSS Program Guide has been completely reorganized to address the needs of the different types of readers that are intended to use this document to facilitate their search for pertinent program information.

Modified p. 2

~~ Change~~ “Quality Assurance Program” section to “Assessor Quality Management Program” and ~~update processes accordingly.~~

• Changed “Quality Assurance Program” section to “Assessor Quality Management Program” and

Modified p. 4 → 5

 Program Background  Program Roles and Responsibilities  Program Overview  Preparation for the Review  Reporting Considerations  Post-Validation Activities  Assessor Quality Management Program 1.1 Program Background In response to requests from merchants and other members of the Payment Card Industry (PCI) for a unified set of payment account data security requirements, ~~the~~ PCI SSC has adopted and maintains the ~~Payment Card Industry~~ Data Security Standard (PCI DSS), a set of requirements for cardholder data protection across …

 Program Background  Program Roles and Responsibilities  Program Overview  Preparation for the Review  Reporting Considerations  Post-Validation Activities  Assessor Quality Management Program 1.1 Program Background In response to requests from merchants and other members of the Payment Card Industry (PCI) for a unified set of payment account data security requirements, PCI SSC has adopted and maintains the PCI Data Security Standard (PCI DSS), a set of requirements for cardholder data protection across the entire industry, …

Modified p. 4 → 5

To help merchants and service providers achieve this goal, PCI SSC manages the ~~PA-DSS~~ Program. The Program promotes the development, implementation and maintenance of secure Payment Applications that help support compliance with the PCI DSS.

To help merchants and service providers achieve this goal, PCI SSC manages the Program. The Program promotes the development, implementation and maintenance of secure Payment Applications that help support compliance with the PCI DSS.

Modified p. 4 → 5

Organizations qualified by PCI SSC to validate PA-DSS Payment Applications on behalf of Vendors are referred to as Payment Application Qualified Security Assessor Companies (PA-QSA ~~Companies)~~ further described below. The quality, reliability, and consistency of a PA-QSA Company’s work provide confidence that the application has been validated for PA-DSS compliance.

Organizations qualified by PCI SSC to validate PA-DSS Payment Applications on behalf of Vendors are referred to as Payment Application Qualified Security Assessor Companies (PA-QSA Companies), further described below. The quality, reliability, and consistency of a PA-QSA Company’s work provide confidence that the application has been validated for PA-DSS compliance.

Removed p. 5

 Payment Card Industry (PCI) Payment Application Data Security Standard

• Requirements and Security Assessment Procedures v2.0 (“PA-DSS”)  Payment Card Industry (PCI) Data Security Standard

• Report on Validation Reporting Instructions for PA-DSS v2.0 (“ROV Reporting Instructions”)  Payment Application Data Security Standard (PA-DSS) Attestation of Validation v2.02 (“AOV”) The latest versions of the following additional documents are used in conjunction with the aforementioned:

 Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures (“PCI DSS”)  Payment Card Industry (PCI) Data Security Standard and Payment Application Data Security Standard Glossary of Terms, Abbreviations, and Acronyms (the “Glossary”)  Payment Card Industry (PCI) Data Security Standard Qualification Requirements for PA- QSAs (“PA-QSA Qualification Requirements”)  The PA-DSS Requirements and Security Assessment Procedures and the Glossary list and define the specific technical requirements and provide the assessment procedures and template used by PA-QSA Companies to validate the Payment Application’s compliance …

Modified p. 5 → 6

 The VRA establishes the terms and conditions under which ~~validation of a~~ Payment Applications are accepted by PCI SSC.

Vendor Release Agreement (“VRA”) The VRA establishes the terms and conditions under which validated Payment Applications are accepted and listed by PCI SSC.

Removed p. 6

PA-DSS Assessment Review of a Payment Application for purposes of validating the compliance of such Payment Application with the PA-DSS as part of the PA-DSS Program.

PA-DSS Program (or Program) Refers to PCI SSC's program and requirements for qualification of PA-QSA Companies and PA-QSA Employees, and validation and Acceptance of Payment Applications, as further described in this document and related PCI SSC documents, policies and procedures.

Modified p. 6 → 7

Term Meaning Accepted, or listed A Payment Application is deemed to have been ”Accepted” or "listed" (and ”Acceptance” is deemed to have occurred) when PCI SSC has: (i) received the corresponding Report on Validation from the PA-QSA Company; (ii) received the fee and all documentation required with respect to the Payment Application as part of the Program; (iii) confirmed that the ROV is correct as to form, the PA-QSA Company properly determined that the Payment Application is eligible to be …

Modified p. 6 → 8

PA-DSS Program (or Program) Refers to PCI SSC's program and requirements for qualification of PA- ~~QSAs~~ and validation and Acceptance of Payment Applications, as further described in this document and related PCI SSC documents, policies and procedures.

PA-DSS Program (or Program) Refers to PCI SSC's program and requirements for qualification of PA- QSA Companies and PA-QSA Employees, and validation and Acceptance of Payment Applications, as further described in this document and related PCI SSC documents, policies and procedures.

Modified p. 7 → 9

PA-QSA Qualification Requirements The then-current version of (or successor documents to) the Payment Card Industry (PCI) ~~QSA Validation Requirements, PA- QSA Supplement, or successor document (including if applicable, the PCI QSA~~ Qualification ~~Requirements)~~ as ~~published~~ on the Website.

PA-QSA Qualification Requirements The then-current version of (or successor documents to) the Payment Card Industry (PCI) Qualification Requirements for Payment Application Qualified Security Assessors (PA-QSAs), as from time to time amended and made available on the Website.

Modified p. 7 → 9

PABP Refers to ~~Visa’s~~ former Payment Application Best Practices program, upon which the Payment Application Data Security Standard ~~(“PA- DSS”)~~ was based. Payment Applications that were transitioned from the PABP program are identified on the PCI ~~SSC’s~~ List of Validated Payment Applications and specifically notated as being validated under the PABP requirements.

PABP Refers to Visa‘s former Payment Application Best Practices program, upon which the Payment Application Data Security Standard (PA- DSS) was based. Payment Applications that were transitioned from the PABP program are identified on the PCI SSC‘s List of Validated Payment Applications and specifically notated as being validated under the PABP requirements.

Modified p. 7 → 9

Payment Application A software application that stores, processes, or transmits cardholder data as part of authorization or settlement, where the ~~software~~ application is sold, distributed, or licensed to third parties.

Payment Application A software application that stores, processes, or transmits cardholder data as part of authorization or settlement, where the payment application is sold, distributed, or licensed to third parties.

Modified p. 7 → 9

PCI SSC Refers to the PCI Security Standards Council, LLC

PCI SSC Refers to the PCI Security Standards Council, LLC ROV Report containing details documenting results from an entity's PA-DSS Assessment for purposes of the PA-DSS Program.

Modified p. 8 → 10

 Vendors will only need to have their Payment Applications validated and accepted in accordance with the PA-DSS Program in order for their Payment Applications to be recognized by the Payment Card Brands.

 Vendors will only need to have their Payment Applications validated and accepted in accordance with the PA-DSS Program in order for their Payment Applications to be recognized by the participating Payment Card Brands.

Modified p. 9 → 11

 Payment Application security requirements and assessment procedures  Processes for recognizing PA-DSS validated ~~payment applications~~  Quality assurance processes for PA-QSA Companies

 Payment Application security requirements and assessment procedures  Processes for recognizing PA-DSS validated Payment Applications  Quality assurance processes for PA-QSA Companies

Modified p. 9 → 11

Entities that store, process, or transmit cardholder data are required ~~by the Payment Card Brands~~ to comply with the PCI DSS. Since Payment Applications are used to store, process, and transmit cardholder data, and entities are required to be PCI DSS compliant, validated Payment Applications must facilitate •and not prevent

•PCI DSS compliance. Examples of how Payment Applications may prevent PCI DSS compliance include:

Entities that store, process, or transmit cardholder data are required to comply with the PCI DSS. Since Payment Applications are used to store, process, and transmit cardholder data, and entities are required by the Payment Card Brands to be PCI DSS compliant, validated Payment Applications must facilitate

Modified p. 9 → 11

1. Track data and/or equivalent data on the chip ~~being~~ stored in the customer's network after authorization;

1. Track data and/or equivalent data on the chip stored in the customer's network after authorization;

Modified p. 9 → 12

 Requirements, mandates, or dates for use of PA-DSS compliant Payment Applications;  Fines or penalties related to use of non-compliant Payment Applications; and  Other requirements for using PA-DSS Validated Payment Applications.

 Requirements, mandates, or dates for use of PA-DSS compliant Payment Applications;  Fines or penalties related to use of non-compliant Payment Applications; and  Other requirements for using PA-DSS Validated Payment Applications.

Removed p. 10

 Creating PA-DSS compliant Payment Applications that facilitate and do not prevent their customers’ PCI DSS compliance (the application cannot require an implementation or configuration setting that violates a PCI DSS requirement);  Following the best practices of the PCI DSS requirements whenever the Vendor stores, processes, or transmits cardholder data (for example, during customer troubleshooting);  Educating customers, resellers, and integrators on how to install and configure the Payment Applications in a PCI DSS compliant manner;  Ensuring their Payment Applications meet PA-DSS Requirements by successfully passing a PA-DSS Assessment as specified in PCI PA-DSS Requirements and Security Assessment Procedures;  Complying with the Vendor Release Agreement;  Creating a PA-DSS Implementation Guide, specific to each application, in accordance with the requirements in the Payment Application Data Security Standard; and

Modified p. 10 → 13

PCI SSC is the standards body that maintains the PCI SSC standards, including the PCI DSS, ~~Point-to-Point~~ Encryption (P2PE) standard, PTS, and PA-DSS. In relation to PA-DSS, PCI SSC:

PCI SSC is the standards body that maintains the PCI SSC standards, including the PCI DSS, Point-to- Point Encryption (P2PE) standard, PTS, and PA-DSS. In relation to PA-DSS, PCI SSC:

Modified p. 10 → 13

 Maintains a centralized repository for all ROVs;  Hosts the List of Validated Payment Applications on the Website;  Provides required training for and qualifies PA-QSA Companies and Employees to assess and validate Payment Applications for PA-DSS compliance;  Maintains and updates the PA-DSS and related documentation according to a standards lifecycle management process; and  Reviews all submissions of PA-DSS ROVs and related change submissions for compliance with baseline quality standards, including but not limited to, confirmation that: …

 Maintains a centralized repository for all ROVs;  Hosts the List of Validated Payment Applications on the Website;  Provides required training for and qualifies PA-QSA Companies and Employees to assess and validate Payment Applications for PA-DSS compliance;  Maintains and updates the PA-DSS and related documentation according to a standards lifecycle management process; and  Reviews all submissions of PA-DSS ROVs and related change submissions for compliance with baseline quality standards, including but not limited to, confirmation that:

Modified p. 10 → 13

Please Note: PCI SSC does not assess or validate Payment Applications for PA-DSS compliance; assessment and validation is the role of the PA-QSA Company. Listing of a Payment Application on the List of Validated Payment Applications signifies that the applicable PA-QSA Company has determined that the application complies with the PA-DSS, that the PA-QSA Company has submitted a corresponding ROV to PCI SSC, and that the ROV, as submitted to PCI SSC, has satisfied all requirements of the PCI SSC …

Modified p. 11 → 13

PA-QSA Companies are QSA Companies that are qualified by PCI SSC to perform PA-DSS Assessments. PA-QSA Companies are responsible for:

PA-QSA Companies are QSA Companies that are additionally qualified by PCI SSC to perform PA-DSS Assessments. PA-QSA Companies are responsible for:

Modified p. 11 → 14

It is the PA-QSA ~~Employee’s~~ responsibility to assess a Payment ~~Application’s~~ PA-DSS ~~compliance,~~ as of the date of the PA-DSS Assessment, and document their findings and opinions on compliance. As indicated above, PCI SSC does not approve ROVs from a technical compliance perspective, but performs quality assurance to confirm that the ROVs adequately document the demonstration of compliance.

It is the PA-QSA Employee‘s responsibility to assess a Payment Application‘s PA-DSS compliance as of the date of the PA-DSS Assessment, and document their findings and opinions on compliance. As indicated above, PCI SSC does not approve ROVs from a technical compliance perspective, but performs quality assurance to confirm that the ROVs adequately document the demonstration of compliance.

Removed p. 12

 Ensuring that the Payment Application’s version information matches what is indicated on the

Note: Not all integrators and resellers are QIRs. There are additional qualification requirements that must be met for an integrator and reseller to become a QIR.

Modified p. 12 → 14

 Implementing PA-DSS Validated Payment Applications into a PCI DSS compliant environment (or instructing the merchant to do so);  Configuring such Payment Applications (where configuration options are provided) according to the Payment ~~Application’s~~ PA-DSS Implementation Guide provided by the Vendor;  Configuring such Payment Applications (or instructing the merchant to do so) in a PCI DSS compliant manner;  Servicing such Payment Applications (for example, troubleshooting, delivering remote updates, and providing remote support) according to the PA-DSS Implementation Guide …

 Implementing PA-DSS Validated Payment Applications into a PCI DSS compliant environment (or instructing the merchant to do so);  Configuring such Payment Applications (where configuration options are provided) according to the Payment Application‘s PA-DSS Implementation Guide provided by the Vendor;  Configuring such Payment Applications (or instructing the merchant to do so) in a PCI DSS compliant manner;  Servicing such Payment Applications (for example, troubleshooting, delivering remote updates, and providing remote support) according to the PA-DSS Implementation Guide …

Modified p. 12 → 14

Integrators and ~~Resellers~~ are not permitted to submit Payment Applications to PA-QSA Companies for PA-DSS Assessment. Products can only be submitted by the Vendor.

Integrators and resellers are not permitted to submit Payment Applications to PA-QSA Companies for PA-DSS Assessment. Products can only be submitted by the Vendor.

Modified p. 12 → 15

Customers and others can find the List of Validated Payment Applications on the ~~PCI SSC website~~ along with other reference materials. PCI ~~SSC’s~~ List of Validated Payment Applications is the authoritative source for validated Payment Applications that may be used to facilitate a Customer's PCI DSS compliance requirements.

Customers and others can find the List of Validated Payment Applications on the Website along with other reference materials. PCI SSC‘s List of Validated Payment Applications is the authoritative source for validated Payment Applications that may be used to facilitate a Customer's PCI DSS compliance requirements.

Removed p. 13

 The Vendor selects a PA-QSA Company from the Council’s list of recognized PA-QSA Companies and negotiates the cost and any associated PA-QSA Company confidentiality and non-disclosure agreement with the PA-QSA Company;  The Vendor then provides to the PA-QSA Company the Payment Application software, corresponding PA-DSS Implementation Guide, and all associated manuals and other required documentation, including but not limited to the Vendor's signed Vendor Release Agreement;  The PA-QSA Company then assesses the Payment Application, including its security functions and features, to determine whether the application complies with PA-DSS;  If the PA-QSA Company determines that the Payment Application is in compliance with the PA-DSS, the PA-QSA Company submits a corresponding ROV to PCI SSC, attesting to compliance and setting forth the results, opinions and conclusions of the PA-QSA Company on all test procedures along with the Vendor’s signed VRA and the Attestation of Validation;  PCI SSC …

Modified p. 13 → 16

The illustrations and descriptions on the following pages explain in detail the ~~following~~ components of the PA-DSS Program:

The illustrations and descriptions on the following pages explain in further detail the components of the PA-DSS Program:

Removed p. 17

 PA-DSS does apply to Payment Applications provided in modules, typically including a “baseline” module and other modules specific to customer types or functions, or customized per customer request. PA-DSS may only apply to the baseline module if that module is the only one performing payment functions (once confirmed by a PA-QSA Company). If other modules also perform payment functions, PA-DSS applies to those modules as well. Note that it is considered a “best practice” for Vendors to isolate payment functions into a single or small number of baseline modules, reserving other modules for non-payment functions. This best practice (though not a requirement) can limit the number of modules subject to PA-DSS.

 Those offered by application service providers (ASP) who host a Payment Application on their site for their customers’ use. Note that PA-DSS would apply, however, if the ASP’s Payment Application were also sold to, and implemented on, a …

Modified p. 17 → 20

 PA-DSS ~~does apply to~~ Payment Applications that are typically sold and installed “off the shelf” without ~~much~~ customization by Vendors.

Table 4.1a PA-DSS Applies to: Program Guidance Commercial Payment Applications that are typically sold and installed “off the shelf” without pre-installation customization by Vendors.

Modified p. 17 → 21

~~ PA-DSS does not apply to~~ Payment Applications ~~offered~~ by ~~application~~ or service providers only as a ~~service (unless such applications are also sold, licensed, or distributed to~~ third ~~parties) because:~~

Payment Applications developed by merchants or service providers used only in-house (not sold, distributed, or licensed to a third party).

Modified p. 17 → 21

 The application is a service offered to customers (typically merchants) and the customers do not have the ability to manage, install, or control the application or its environment;  The application is covered by the application or service provider’s own PCI DSS review (this coverage should be confirmed by the customer); and/or  The application is not sold, distributed, or licensed to third parties.

1. The application is a service offered to customers (typically merchants) and the customers do not have the ability to manage, install, or control the application or its environment;

Modified p. 17 → 21

Examples of ~~these “software as a service”~~ Payment Applications ~~include:~~

Examples of such service-type Payment Applications include (but are not limited to):

Modified p. 17 → 21

~~ Virtual terminal applications that reside on a service providers’ site and are used by merchants to enter their payment transactions. Note that~~ PA-DSS would apply if the virtual terminal application has a portion that is distributed ~~to,~~ and implemented ~~on,~~ the ~~merchant’s site, and was not covered by the virtual terminal provider’s PCI DSS review.~~

Note: PA-DSS would apply if the virtual terminal application has a portion that is distributed to and implemented on the merchant‘s site.

Modified p. 17 → 21

Such ~~applications (for example, a fraud-monitoring, scoring, or detection application included in a suite). These~~ applications can be, but are not required to be, covered by PA-DSS if the whole suite is assessed together. However, if a Payment Application is part of a suite that relies on ~~PA- DSS~~ Requirements being met by controls in other applications in the suite, a single PA-DSS Assessment should be performed for the Payment Application and all other applications in the suite upon which …

Such applications can be, but are not required to be, covered by PA-DSS if the whole suite is assessed together. However, if a Payment Application is part of a suite that relies on PA-DSS Requirements being met by controls in other applications in the suite, a single PA-DSS Assessment should be performed for the Payment Application and all other applications in the suite upon which it relies. These applications should not be assessed separately from other applications they rely upon …

Removed p. 18

 PA-DSS does NOT apply to Payment Applications developed by merchants and service providers if used only in-house (not sold, distributed, or licensed to a third party), since this in-house developed Payment Application would be covered as part of the merchant’s or service provider’s normal PCI DSS compliance.

For example, for the last two bullets above, whether the in-house developed or “bespoke” Payment Application stores prohibited sensitive authentication data or allows complex passwords would be covered as part of the merchant’s or service provider’s normal PCI DSS compliance efforts and would not require a separate PA-DSS assessment.

Further guidance from the Council may be provided as new technologies or uses emerge. To provide direction in this area, the Council maintains a document entitled Applications Eligible for PA-DSS Validation. This document can be found on the PCI SSC website. The following list, while not all- inclusive, illustrates other applications that are NOT Payment …

Modified p. 18 → 22

~~ Operating systems onto which a Payment Application is installed (for example, Windows, Unix)  Database systems that store cardholder data (for example, Oracle)~~  Back-office systems that store cardholder data (for example, for reporting or customer service ~~purposes)~~

 Back-office systems that store cardholder data (for example, for reporting or customer service purposes).

Modified p. 18 → 22

PCI SSC will ~~ONLY Accept~~ and list Payment Applications that are eligible for a PA-DSS ~~assessment,~~ as defined by the PCI SSC.

Note: PCI SSC will only accept and list Payment Applications that are eligible for PA-DSS Assessment, as defined by the PCI SSC.

Modified p. 18 → 22

2. The resident Payment Application does not meet all PA-DSS Requirements, but the hardware on which the application resides is listed on the PCI ~~SSC’s~~ Approved PIN Transaction Security (PTS) Devices List as a current PCI PTS approved Point of Interaction (POI) device. In this scenario, it may be possible for the application to satisfy PA-DSS Requirements through a combination of the PA-DSS and PTS validated controls.

2. The resident Payment Application does not meet all PA-DSS Requirements, but the hardware on which the application resides is listed on the PCI SSC‘s Approved PIN Transaction Security (PTS) Devices List as a current PCI PTS approved Point of Interaction (POI) device. In this scenario, it may be possible for the application to satisfy PA-DSS Requirements through a combination of the PA-DSS and PTS validated controls.

Removed p. 19

 Be provided together to the customer (both hardware terminal and application), OR, if provided separately, the application Vendor and/or the reseller/integrator must package the application for distribution such that it will only operate on the hardware terminal on which it has been validated to run;  Enabled by default to support a customer’s PCI DSS compliance;  Include ongoing support and updates to maintain PCI DSS compliance; and  If the application is separately sold, distributed or licensed to customers, the Vendor must provide details of the dependent hardware required for use with the application, in accordance with its PA-DSS validation listing.

Modified p. 19 → 22

2. Clearly document which Requirement was met via PCI PTS ~~in the “In Place” box~~ for that Requirement;

2. Clearly document which Requirement was met via PCI PTS for that Requirement;

Modified p. 19 → 23

Once the PA-QSA ~~Company’s~~ validation of the Payment Application is complete and is subsequently accepted by the PCI SSC, the PTS validated hardware device will be listed as a dependency for the Payment Application on the PA-DSS List of Validated Applications.

Once the PA-QSA Company‘s validation of the Payment Application is complete and is subsequently accepted by the PCI SSC, the PTS validated hardware device will be listed as a dependency for the Payment Application on the PA-DSS List of Validated Payment Applications.

Removed p. 20

 Perform a “gap” analysis between how the Payment Application subject to PA-DSS functions compared to PA-DSS Requirements;  Correct any gaps;  If desired, the PA-QSA Company may perform a pre-assessment or “gap” analysis of a Vendor’s Payment Application. If the PA-QSA Company notes deficiencies that would prevent a clean opinion, the PA-QSA Company will provide to the Vendor a list of Payment Application features to be addressed before the formal review process begins; and  Determine whether the Payment Application’s PA-DSS Implementation Guide meets PA-DSS Implementation Guide requirements and correct any gaps.

 PA-DSS Implementation Guide (note that this must be submitted to the PA-QSA Company);  Software Installation Guide or Instructions (as provided to customers);  Vendor’s version-numbering scheme; and  Change control documentation that shows how changes are illustrated to customers;

Modified p. 20 → 23

 Review both PCI DSS and PA-DSS Requirements and related documentation located at the ~~PCI SSC website;~~  Determine/assess the Payment ~~Application’s~~ readiness to comply with PA-DSS:

 Review both PCI DSS and PA-DSS Requirements and related documentation located at the  Determine/assess the Payment Application‘s readiness to comply with PA-DSS:

Modified p. 20 → 23

All published PCI SSC information and documents relevant to PA-DSS ~~can be downloaded from~~ the ~~PCI SSC website.~~ All completed Payment Application related materials such as install CDs, manuals, the PA-DSS Implementation Guide, the Vendor Release Agreement and all other materials related to the ~~review~~ and participation in the PA-DSS Program must be delivered to a PA-QSA Company ~~listed on~~ the ~~PCI SSC website,~~ not to PCI SSC.

All published PCI SSC information and documents relevant to PA-DSS are available on the Website. All completed Payment Application related materials such as install CDs, manuals, the PA-DSS Implementation Guide, the Vendor Release Agreement and all other materials related to the Assessment and participation in the PA-DSS Program must be delivered to the PA-QSA Company performing the assessment, not to PCI SSC.

Modified p. 20 → 23

Examples of ~~software documentation~~ and other items to submit to the PA-QSA Company include, but are not limited to:

Examples of software, documentation, and other items to submit to the PA-QSA Company include, but are not limited to:

Modified p. 20 → 24

3. Documentation that describes all functions used for data input and output that can be used by third-party application developers. Specifically, functions associated with capture, authorization, settlement and chargeback flows (if applicable to the application) must be described. (A manual is an example of documentation that could fulfill this ~~requirement.);~~

3. Documentation that describes all functions used for data input and output that can be used by third-party application developers. Specifically, functions associated with capture, authorization, settlement and chargeback flows (if applicable to the application) must be described. (A manual is an example of documentation that could fulfill this requirement);

Modified p. 20 → 24

5. Additional documentation

•such as diagrams and flowcharts

•that will aid in the Payment Application ~~review (the PA-QSA Company may request additional material when necessary.);~~ and

5. Additional documentation

•such as diagrams and flowcharts

•that will aid in the Payment Application review; and

Modified p. 20 → 24

6. The ~~Vendor’s~~ executed VRA.

6. The Vendor‘s executed VRA.

Removed p. 21

 If PCI SSC reviews the ROV more than once, providing comments back to the PA-QSA Company to address each time, this will increase the length of time for the review process. Any Assessment timeframes provided by a PA-QSA Company should be considered estimates, since they may be based on the assumption that the Payment Application is able to successfully meet all PA- DSS Requirements quickly. If problems are found during the review or acceptance processes, discussions between the PA-QSA Company, the Vendor, and/or PCI SSC will be required. Such discussions may significantly impact review times and cause delays and/or may even cause the review to end prematurely (for example, if the Vendor decides they do not want to make the necessary Payment Application changes to achieve compliance or it is determined that the application is not eligible for PA-DSS validation).

Modified p. 21 → 25

PCI SSC qualifies and provides required training for ~~Payment Application Qualified Security Assessor~~ Companies and PA-QSA Employees to assess and validate Payment Applications for PA-DSS compliance. In order to perform PA-DSS Assessments, ~~the~~ PA-QSA Company must have been qualified by PCI SSC and remain in good standing as both a QSA Company and PA-QSA Company, and complete all required PA-QSA training. All recognized PA-QSA Companies are listed on the Website. These are the only assessors recognized by PCI SSC as …

PCI SSC qualifies and provides required training for PA-QSA Companies and PA-QSA Employees to assess and validate Payment Applications for PA-DSS compliance. In order to perform PA-DSS Assessments, a PA-QSA Company must have been qualified by PCI SSC and remain in good standing as both a QSA Company and PA-QSA Company, and complete all required PA-QSA training. All recognized PA-QSA Companies are listed on the Website. These are the only assessors recognized by PCI SSC as qualified to perform PA-DSS …

Modified p. 21 → 26

~~ Guidance on designing Payment Applications in accordance with PA-DSS ~~ Review of a ~~Vendor’s~~ software design, response to questions via e-mail or phone, and participation in conference calls to clarify ~~requirements~~

 Review of a Vendor‘s software design, response to questions via e-mail or phone, and participation in conference calls to clarify requirements.

Removed p. 22

The Portal maintains a first-in-first-out order to all submissions while they await review by the Council. Should a new submission be intended as a replacement for a previous version of a Validated Payment Application with known vulnerabilities, the Portal allows such submissions to be brought forward for immediate review.

The Portal is also used by the Council to track all communications relating to a particular submission.

Modified p. 22 → 26

Note: When arranging for non-PA-DSS Assessment services with a PA-QSA Company, care should be taken by both the Vendor and the PA-QSA Company to ensure that the PA-QSA Employee does not assess its own work product as part of the actual PA-DSS Assessment. Conflicts of interest may result in a Payment Application’s Assessment being rejected by PCI SSC.

Note: When arranging for non-PA-DSS Assessment services with a PA-QSA Company, care should be taken by both the Vendor and the PA-QSA Company to ensure that the PA- QSA maintains all independence requirements as set forth in the QSA Qualification Requirements, for example, that a PA-QSA Employee does not assess its own work product as part of the actual PA-DSS Assessment. Conflicts of interest may result in a Payment Application’s PA-QSA Assessment being rejected by PCI SSC.

Modified p. 22 → 27

It should be noted that a ROV will not be reviewed by PCI SSC without the ~~then-current~~ VRA on file from the relevant Vendor.

It should be noted that a ROV will not be reviewed by PCI SSC without the then most current VRA on file from the relevant Vendor.

Modified p. 23 → 28

The Vendor pays all PA- DSS ~~Assessment related~~ fees directly to the PA- QSA Company (these fees are negotiated between the Vendor and the PA-QSA Company).

The Vendor pays all PA- DSS Assessment-related fees directly to the PA- QSA Company (these fees are negotiated between the Vendor and the PA-QSA Company).

Modified p. 23 → 28

PCI SSC will bill the Vendor for all PA-DSS Payment Application Acceptance Fees and the Vendor will pay these fees directly to PCI SSC. ~~PA-DSS Program fees are posted on the Website. PA-DSS Program fees are non-refundable and are subject to change upon posting of revised fees on the Website.~~

PCI SSC will bill the Vendor for all PA-DSS Payment Application Acceptance Fees and the Vendor will pay these fees directly to PCI SSC.

Removed p. 24

This annual process has been adopted to encourage Vendors to not only reaffirm that there have been no updates to the PA-DSS Validated Payment Application (if applicable), but also to encourage Vendors to periodically consider whether updates to the PA-DSS Validated Payment Application are necessary to address changes to the external threat environment in which the Payment Application operates. If changes to the threat environment do necessitate changes to the Payment Application, the product should be updated accordingly and reassessed by a PA-QSA Company, preferably the PA-QSA Company that originally validated the Payment Application for PA-DSS compliance.

If an updated Attestation of Validation is not submitted for a listed Payment Application, that application will be deemed to have suffered an early administrative expiry. As such, the “Deployment Notes” on the List of Validated Applications will be amended to identify that the Payment Application is “Acceptable only for Pre-Existing Deployments.” As there …

Modified p. 24 → 29

• updated Attestation of Validation to ~~both~~ the ~~Vendor and the PA-QSA.~~

• updated Attestation of Validation to the Vendor.

Modified p. 24 → 29

The process flow for annual revalidation is detailed in ~~Section 2.2,~~ Figure 2.

The process flow for annual revalidation is detailed in Figure 2.

Removed p. 25

In such cases where updates are made to previously listed applications and the Vendor desires that the updated Payment Application information is reflected on the List of Validated Payment Applications, the Vendor must submit the details of those changes to the PA-QSA Company, preferably to the PA-QSA Company that originally reviewed the Payment Application.

The PA-QSA Company then determines whether a full or partial re- assessment of the Payment Application is required. This decision is based on the degree to which the changes made to the application impact the security of the application, and/or the scope or depth of the changes being made. For example, the change may only impact auxiliary functionality and does not impact the core Payment Application.

If a listed Payment Application has undergone changes that may potentially affect PA-DSS Requirements, and/or if the Vendor wants the information in its Attestation of Validation and/or on the PCI SSC website …

Modified p. 25 → 33

The process flow for changes to listed ~~applications~~ is detailed in ~~Section 2.3,~~ Figure 3.

The process flow for changes to listed Payment Applications is detailed in Figure 3.

Removed p. 26

 Name of the Payment Application;  Payment Application version number;  Related Payment Application name and version number currently on the List of Validated Payment Applications;  Description of the change;  Indication of whether this is a No Impact Change or a Low Impact Change (see below);  Description of why the change is necessary;  Details of whether cardholder data and payment functions are impacted and what the impact is;  Description of how the change functions;  Description of testing performed by Vendor to validate that PA-DSS security requirements are not negatively impacted;  Explanation of how and why PA-DSS Requirements are not negatively impacted;  Description of how this change fits into Vendor’s versioning methodology, including how this version number indicates that this is a “minor” change;  If applicable, description of use of programming practices/module approaches and how such use prevents a negative impact …

Removed p. 26

 A high-level description of each change that has been made to the Validated Payment Application  Citations of: o The original ROV that and any subsequent Minor Changes (including No Impact and Low Impact Changes) upon which the current Minor Change is based; and o Any supporting documentation used to substantiate the findings represented in the Vendor Change Analysis;  A table that depicts the following information about every change that is embodied in the Minor Change to the Validated Payment Application from the previously approved version: o A description of the change; o Identification of the amended configuration item or items (system files, modules, etc.) that is/are impacted by the change; o A high-level assessment by the PA-QSA Company of the security impact of the change;

Removed p. 27

 Payment Application Changes include revisions to a previously listed Payment Application, but that revision is deemed to have no impact on PA-DSS Requirements.

In both cases, the Vendor prepares documentation of the change (a “Vendor Change Analysis”) and submits the Vendor Change Analysis to the PA-QSA Company for review. It is strongly recommended that the Vendor submit the Vendor Change Analysis to the same PA-QSA Company used for the original assessment.

Modified p. 27 → 33

i. The PA-QSA Company must so notify the ~~Vendor;~~

i. The PA-QSA Company must notify the Vendor that they agree;

Modified p. 27 → 33

ii. The Vendor prepares and signs an Attestation of Validation, and sends it to the ~~PA-QSA~~

ii. The Vendor prepares and signs an Attestation of Validation, and sends it to the PA- QSA Company;

Modified p. 27 → 33

~~iii.~~ The PA-QSA signs their concurrence on the Attestation of Validation and forwards it, along with the ~~Vendor~~ Change ~~Analysis and the Payment Application’s updated PA-DSS Implementation Guide,~~ to PCI SSC;

v. The PA-QSA Company signs their concurrence on the Attestation of Validation and forwards it, along with the PA-QSA Change Impact document to PCI SSC;

Modified p. 27 → 33

v. Upon payment of the invoice PCI SSC will review the Attestation of Validation and ~~Vendor~~ Change ~~Analysis~~ for quality assurance purposes.

vii. Upon payment of the invoice PCI SSC will review the Attestation of Validation and PA-QSA Change Impact document for quality assurance purposes.

Modified p. 27 → 34

If the PA-QSA Company agrees that the change as documented in the Vendor Change ~~Analysis by~~ the ~~Vendor has no impact on the PA-DSS related functions of the Payment Application:~~

If the PA-QSA Company agrees that the change (as documented by the Vendor in the Vendor Change Analysis) meets the No Impact change criteria:

Modified p. 27 → 34

Following successful PCI SSC quality assurance review of ~~a No Impact Change,~~ PCI SSC will:

Following successful PCI SSC quality assurance review of the change, PCI SSC will:

Modified p. 27 → 34

i. Amend the List of PA-DSS Validated Payment Applications on the ~~PCI SSC website~~ accordingly with the new ~~information and;~~

i. Amend the List of PA-DSS Validated Payment Applications on the Website accordingly with the new information; and

Modified p. 27 → 34

ii. Sign and return a copy of the PA-DSS Attestation of Validation to both the Vendor and the PA-QSA Company. The expiry date of ~~this~~ newly listed application and version number will be the same as that of the ~~“parent”~~ Payment Application.

ii. Sign and return a copy of the PA-DSS Attestation of Validation to both the Vendor and the PA-QSA Company. The expiry date of the newly listed application and version number will be the same as that of the parent Payment Application.

Modified p. 27 → 35

~~iv.~~ PCI SSC ~~then~~ issues an invoice to the Vendor for the applicable ~~Change Fee;~~ and

v. PCI SSC issues an invoice to the Vendor for the applicable change fee; and

Removed p. 28

Low Impact Changes are expressly limited to the following specific types of changes to PA-DSS related functions of a Validated Payment Application:

i. Inclusion of minor updates or patches to supported OS versions upon which the Payment Application was previously validated;

iii. Updates to reporting modules;

iv. Additions or deletions of supported payment processors;

v. Inclusion of minor updates or patches to supported middleware with which the Payment Application was previously validated;

vi. Recompilation of unchanged code base with either the same compiler using different flags or with a completely different compiler; and

vii. Updates to transmission protocols to meet PCI SSC’s definition of strong cryptography.

Note: In order to qualify as a low impact change, the change may only impact PA-DSS requirements applicable to secure transmission protocols (for example, PA-DSS requirements 6, 8.2, 10.2.3, 11, 12). In order to qualify for this change, the payment application must only support secure protocols; support for vulnerable protocols (e.g., …

Modified p. 28 → 35

~~ii.~~ Inclusion of ~~minor~~ updates or patches to supported ~~third-party~~ databases with which the Payment Application was previously validated;

 Inclusion of updates or patches to validated OS versions upon which the Payment Application was previously validated;  Inclusion of updates or patches to supported third- party databases with which the Payment Application was previously validated;  Additions or deletions of supported payment processors;

Removed p. 29

A list of the specific critical PA-DSS Requirements, that if impacted necessitate a full review, is maintained in the table of Critical Test Procedures in the ROV Reporting Instructions document.

If the PA-QSA does not agree with the Vendor that the change, as documented in the Vendor Change Analysis, has only a low impact on the PA-DSS related functions of the Payment Application, the PA-QSA Company should return the Vendor Change Analysis to the Vendor and work with the Vendor to consider what actions are necessary to address the PA-QSA Company’s observations.

Modified p. 29 → 33

v. PCI SSC then ~~issues~~ an invoice to the Vendor for the applicable ~~Change Fee;~~ and

vi. PCI SSC will then issue an invoice to the Vendor for the applicable change fee; and

Modified p. 29 → 34

i. The PA-QSA Company must so notify the ~~Vendor;~~

i. The PA-QSA Company must notify the Vendor that they agree;

Modified p. 29 → 34

~~iii.~~ The Vendor prepares and signs an Attestation of ~~Validation~~ and sends it to the PA-QSA

ii. The Vendor prepares and signs an Attestation of Validation, and sends it to the PA-QSA Company;

Modified p. 29 → 35

Following successful PCI SSC quality assurance review of ~~a Low Impact Change,~~ PCI SSC will:

Following successful PCI SSC quality assurance review of the change PCI SSC will:

Modified p. 29 → 35

i. Amend the List of PA-DSS Validated Payment Applications on the ~~PCI SSC website~~ accordingly with the new information; and

i. Amend the List of PA-DSS Validated Payment Applications on the Website accordingly with the new information; and

Modified p. 29 → 35

For quality issues associated any aspect of the submission, PCI SSC communicates those issues to the PA-QSA Company, and those issues are resolved according to the process depicted in ~~Section 2.1,~~ Figure 1. PCI SSC reserves the right to reject any PA-QSA ~~Company~~ Change Impact document if it determines that a change described therein and purported to be a ~~Low~~ Impact ~~Change~~ by the PA-QSA Company or Vendor is ineligible for treatment as a ~~Low~~ Impact ~~Change.~~

For quality issues associated any aspect of the submission, PCI SSC communicates those issues to the PA-QSA Company, and those issues are resolved according to the process depicted in Figure 1. PCI SSC reserves the right to reject any PA-QSA Change Impact document if it determines that a change described therein and purported to be a No Impact change by the PA-QSA Company or Vendor is ineligible for treatment as a No Impact change.

Modified p. 29 → 36

If the PA-QSA Company agrees that the change as documented in the Vendor Change ~~Analysis by~~ the ~~Vendor only have~~ a ~~low impact on PA-DSS Requirements (based on the PA-QSA Company’s review of the criteria above):~~

If the PA-QSA Company agrees that the change (as documented by the Vendor in the Vendor Change Analysis) meets the Low Impact change criteria and is eligible for a delta assessment:

Modified p. 29 → 36

~~ii.~~ The PA-QSA Company ~~must perform an assessment of the PA-DSS Requirements affected by the Low Impact Change and produces~~ a PA-QSA Change Impact document and ~~make “redline”~~ changes to the original ROV as appropriate;

iv. The PA-QSA Company completes a PA-QSA Change Impact document in Appendix D and makes redline changes to the original ROV as appropriate;

Modified p. 29 → 36

~~iv.~~ The PA-QSA Company signs ~~its~~ concurrence on the Attestation of Validation and forwards ~~it, along~~ with the ~~“Redline”~~ version of the ROV, the Payment ~~Application’s~~ updated ~~PA- DSS~~ Implementation Guide, and the PA-QSA ~~Company~~ Change Impact ~~document, to~~ PCI SSC; ~~and~~

vi. The PA-QSA Company signs their concurrence on the Attestation of Validation and forwards it

•along with the “redline” version of the ROV, the Payment Application‘s updated PA-DSS Implementation Guide, and the PA-QSA Change Impact document

•to PCI SSC;

Modified p. 29 → 36

~~vi.~~ Upon payment of the ~~invoice~~ PCI SSC will review the Attestation of Validation, the ~~“Redline”~~ version of the ROV and the PA-QSA ~~Company~~ Change Impact document for quality assurance purposes.

viii. Upon payment of the invoice, PCI SSC will review the Attestation of Validation, the “redline” version of the ROV and the PA-QSA Change Impact document for quality assurance purposes.

Modified p. 29 → 36

ii. Sign and return a copy of the Attestation of Validation to both the Vendor and the PA-QSA Company. The expiry date of this newly listed application ~~and version number~~ will be the same as that of the ~~“parent”~~ Payment Application.

ii. Sign and return a copy of the Attestation of Validation to both the Vendor and the PA-QSA Company. The expiry date of this newly listed application will be the same as that of the parent Payment Application.

Modified p. 30 → 38

 New Validation: If the Vendor wishes the application to remain on the Acceptable for New Deployments List on the Website, the Vendor must contact a PA-QSA Company to have the Payment Application fully re-evaluated against the then-current version of the PA-DSS. Use of the ~~Minor~~ Change process to achieve this goal is not permitted.

1. New Validation: If the Vendor wishes the application to remain on the Acceptable for New Deployments List on the Website, the Vendor must contact a PA-QSA Company to have the Payment Application fully re-evaluated against the then-current version of the PA-DSS. Use of the Low/No Impact or Administrative Change process to achieve this goal is not permitted.

Modified p. 30 → 38

 Expiry: In all other situations where the Vendor fails to submit the application for full ~~re-assessment~~ by the expiry date, PCI SSC will change the listed status of the Payment Application to “Only ~~acceptable~~ for Pre-Existing Deployments” after the expiry date.

2. Expiry: In all other situations where the Vendor fails to submit the application for full re- assessment by the expiry date, PCI SSC will change the listed status of the Payment Application to “Only Acceptable for Pre-Existing Deployments” after the expiry date.

Modified p. 30 → 38

Note that if the expiring application successfully completes the PA-DSS Assessment process again, it retains its status on the List of Validated Applications as ~~“Acceptable~~ for New ~~Deployments”~~ and is assigned a new expiry date.

Note that if the expiring application successfully completes the PA-DSS Assessment process again, the re-validated application retains its status on the List of Validated Payment Applications as Acceptable for New Deployments and is assigned a new expiry date.

Modified p. 30 → 38

The process flow for renewing ~~expired~~ applications is detailed in ~~Section 2.3,~~ Figure 3.

The process flow for renewing expiring applications is detailed in Figure 2.

Modified p. 30 → 38

All PA-DSS Program fees posted on the Website. Program fees are non-refundable and are subject to change upon posting of revised fees on the Website.

All PA-DSS Program fees are posted on the Website. Program fees are non-refundable and are subject to change upon posting of revised fees on the Website.

Modified p. 30 → 38

The Vendor pays all PA-DSS ~~Assessment related~~ fees directly to the PA-QSA ~~Company~~ (these fees are negotiated between the Vendor and the PA-QSA Company).

Note: The Vendor pays all PA-DSS Assessment-related fees directly to the PA-QSA (these fees are negotiated between the Vendor and the PA-QSA Company).

Modified p. 31 → 39

The Vendor must also provide prompt feedback about any potential impact (possible or actual) the breach or vulnerability has ~~had,~~ may ~~have,~~ or will have.

The Vendor must also provide prompt feedback about any potential impact (possible or actual) the breach or vulnerability has had or may or will have.

Modified p. 31 → 39

Notification must take place no later than 24 hours after the Vendor first becomes aware of the Security Issue.

Note: Notification must take place no later than 24 hours after the Vendor first becomes aware of the Security Issue.

Modified p. 31 → 39

 The name, PCI SSC reference number, and any other relevant identifiers of the Payment Application;  A description of the general nature of the Security Issue;  The Vendor’s good-faith assessment, to its knowledge at the time, as to the scope and severity of the vulnerability or vulnerabilities associated with the Security Issue (using CVSS or other industry accepted standard scoring);  Assurance that the Vendor is following their Incident Response and/or Vulnerability Handling Policies.

 The name, PCI SSC reference number, and any other relevant identifiers of the Payment Application;  A description of the general nature of the Security Issue;  The Vendor’s good-faith assessment, to its knowledge at the time, as to the scope and severity of the vulnerability or vulnerabilities associated with the Security Issue (using CVSS or other industry accepted standard scoring);  Assurance that the Vendor is following their Incident Response and/or Vulnerability Handling Policies.

Modified p. 31 → 39

 Notify participating Payment Card Brands that a Security Issue has occurred.

 Notify participating Payment Card Brands that a Security Issue has occurred.

Modified p. 31 → 39

 Request a copy of the latest version of the Vendor’s Vulnerability Handling Policies.

 Request a copy of the latest version of the Vendor’s Vulnerability Handling Policies.

Modified p. 31 → 39

 Communicate with the Vendor ~~of the application in question~~ about the Security Issue and, where possible, share information relating to the Security Issue.

 Communicate with the Vendor about the Security Issue and, where possible, share information relating to the Security Issue.

Modified p. 31 → 39

 Support the ~~Vendor’s~~ efforts to mitigate or prevent further Security Issues.

 Support the Vendor‘s efforts to mitigate or prevent further Security Issues.

Modified p. 31 → 39

 Support the ~~Vendor’s~~ efforts to correct any Security Issues.

 Support the Vendor‘s efforts to correct any Security Issues.

Modified p. 31 → 39

 Work with the Vendor to communicate and cooperate with appropriate law enforcement agencies to help mitigate or prevent further Security Issues.

 Work with the Vendor to communicate and cooperate with appropriate law enforcement agencies to help mitigate or prevent further Security Issues.

Modified p. 31 → 40

PCI SSC reserves the right to suspend, ~~withdraw~~ revoke, ~~cancel~~ or place conditions upon its Acceptance of (and accordingly, remove from the List of PA-DSS Validated Payment Applications) any listed Payment Application in accordance with the VRA, in instances ~~including~~ but not limited to, if PCI SSC reasonably determines that (a) the Payment Application does not offer sufficient protection against current threats and does not conform to PA-DSS Requirements, (b) the continued Acceptance of the Payment Application represents a significant …

PCI SSC reserves the right to suspend, withdraw, revoke, cancel, or place conditions upon its Acceptance of (and accordingly, remove from the List of PA-DSS Validated Payment Applications) any listed Payment Application in accordance with the VRA, in instances including, but not limited to, if PCI SSC reasonably determines that (a) the Payment Application does not offer sufficient protection against current threats and does not conform to PA-DSS Requirements, or (b) the continued Acceptance of the Payment Application represents a …

Removed p. 32

The Portal maintains a first-in-first-out order to all submissions while they await review by the Council. Should a new submission be intended as a replacement for a previous version of a Validated Payment Application with known vulnerabilities, the Portal allows such submissions to be brought forward for immediate review.

The Portal is also used by the Council to track all communications relating to a particular submission.

Modified p. 32 → 41

~~Note:~~ All ROVs and other materials must be submitted to PCI SSC in English or with certified English translation.

All ROVs and other materials must be submitted to PCI SSC in English or with certified English translation.

Modified p. 32 → 41

Once PCI SSC receives the ~~ROV,~~ all other required ~~materials,~~ and applicable fees, PCI SSC reviews the ROV from a quality assurance perspective. If the ROV meets all applicable quality assurance requirements (as documented in the QSA Qualification Requirements and related ~~PA-DSS Program~~ materials), PCI SSC ~~will send~~ a PA-DSS Attestation of ~~Validation, countersigned by PCI SSC,~~ to both the Vendor and the PA-QSA Company, and ~~then~~ adds the application to the List of Validated Payment Applications.

Once PCI SSC receives the ROV and all other required materials and applicable fees, PCI SSC reviews the ROV from a quality assurance perspective. If the ROV meets all applicable quality assurance requirements (as documented in the QSA Qualification Requirements and related program materials), PCI SSC sends a countersigned PA-DSS Attestation of Validation to both the Vendor and the PA-QSA Company, and adds the application to the List of Validated Payment Applications.

Modified p. 32 → 41

~~For~~ quality issues associated with ~~ROVs, PCI SSC communicates those issues with~~ the PA-QSA Company. It is ~~then~~ the responsibility of the PA-QSA Company to resolve the issues with PCI SSC and/or the Vendor, as applicable. Such issues may be limited to updating the ROV to reflect adequate documentation to support the PA-QSA Company’s ~~decisions. However, if~~ the ~~issues require that~~ the PA- QSA Company ~~perform more testing, the PA-QSA Company must~~ notify the Vendor that re-testing is needed and …

PCI SSC communicates any quality issues associated with ROVs to the PA-QSA Company. It is the responsibility of the PA-QSA Company to resolve the issues with PCI SSC and/or the Vendor, as applicable. Such issues may be limited or more extensive; limited issues may simply require updating the ROV to reflect adequate documentation to support the PA-QSA Company’s decisions, whereas more extensive issues may require the PA-QSA Company to perform further testing, requiring the PA- QSA Company to notify the …

Modified p. 32 → 41

The process flows for ROV Acceptance and ROV Review Process are detailed in ~~Section 2.1,~~ Figure 1.

The process flows for ROV Acceptance and ROV Review Process are detailed in Figure 1.

Modified p. 32 → 41

There must be consistency between the information in documents submitted for review via the portal and the ~~‘Details’~~ fields within the Portal. Common errors in submissions include inconsistent application names or contact ~~information and~~ incomplete or inconsistent ~~documentation.~~ Incomplete or inconsistent submissions may result in a significant delay in the processing of requests for listing and/or may not be ~~accepted~~ for review by the PCI SSC.

There must be consistency between the information in documents submitted for review via the portal and the “Details” fields within the Portal. Common errors in submissions include inconsistent application names or contact information, incomplete or inconsistent documentation, application dependencies being insufficiently explained, and tested platforms/operating systems being insufficiently explained. Incomplete or inconsistent submissions may result in a significant delay in the processing of requests for listing and/or may not be Accepted for review by the PCI SSC.

Removed p. 33

 Vendor Release Agreement signed by the Vendor  ROVs completed in accordance with the ROV Reporting Instructions which contains the following information: o Executive Summary (Includes Reseller/Integrator List) o Requirements

• Testing Procedures o PA-DSS v2.0, Appendix B: Confirmation of Testing Laboratory Configuration Specific to PA-DSS Assessment o Attestation of Validation (AOV) signed by both the Vendor and the PA-QSA Company of Record  Implementation Guide for the Payment Application assessed 5.2.3 Resubmissions For subsequent reviews, if multiple iterations of a ROV are required before PCI SSC accepts an application; the PA-QSA Company must submit ROV versions that include tracking of cumulative changes within the document.

Removed p. 33

 Vendor Change Analysis document;  Updated Vendor Release Agreement, if applicable;  Updated PA-DSS Implementation Guide for the assessed Payment Application; and  Attestation of Validation signed by both the Vendor and the PA-QSA Company.

Removed p. 33

 PA-QSA Company’s Change Impact document;  Updated PA-DSS Implementation Guide for the assessed Payment Application;  Updated ROV which contains the following: o Summary of requirements assessed and any resulting changes; o Updated Executive Summary and Requirement with edits clearly identified (i.e. “redlined”); and o Confirmation of Testing Laboratory (PA-DSS Appendix B); and  Attestation of Validation signed by both the Vendor and the PA-QSA Company.

Removed p. 34

PCI SSC will base Acceptance of a Payment Application primarily on the results documented in the ROV. Upon receipt of the ROV, the following will apply:

 PCI SSC shall review the ROV (generally within 30 calendar days of payment of invoice) and determine if it is acceptable.

 If no issues or questions to the PA-QSA Company are identified, PCI SSC will issue the Attestation of Validation, countersigned by PCI SSC, post the Payment Application and Vendor’s information to the Website, and the application is thereby Accepted.

 If questions or issues are identified and sent to the PA-QSA Company, the process described above will restart upon receipt of a complete and acceptable

• revised ROV or response (“Revised ROV”) from the PA-QSA Company. PCI SSC reserves the right to ask for additional supporting documentation that may be necessary to substantiate the findings documented in the ROV. The process re-start does not occur …

Modified p. 34 → 42

 Payment Application Vendor  Payment Application Identifier  Payment Application Name  Payment Application Version Number  Application Type  Target Market, if applicable  Reference Number  Description Provided by Vendor  Tested Platforms/Operating Systems  Required dependencies  Validation Notes ~~(PABP or PA-DSS~~ version) ~~ Deployment Notes  Revalidation Date  Expiry Date  PA-QSA Company~~

 Payment Application Vendor  Payment Application Identifier  Payment Application Name  Payment Application Version Number  Application Type  Target Market, if applicable  Reference Number  Description Provided by Vendor  Tested Platforms/Operating Systems  Required dependencies  Validation Notes (PA-DSS version)

Modified p. 35 → 42

The process flow for the QA program is detailed in ~~Section 5.5,~~ Figure 4.

The process flow for the QA program is detailed in Figure 4.

Modified p. 35 → 42

PCI SSC’s Assessor Quality Management Team (“AQM”) reviews each ROV submission after the invoice has been paid by the Vendor. Administrative review will be performed in ~~“pre-screening”~~ to ensure that the submission is complete, then an AQM analyst will review the submission in its entirety.

PCI SSC’s Assessor Quality Management Team (“AQM”) reviews each ROV submission after the invoice has been paid by the Vendor. Administrative review will be performed in “pre- screening” to ensure that the submission is complete, then an AQM analyst will review the submission in its entirety.

Modified p. 35 → 43

QSA Company audits are addressed in the QSA Qualification Requirements, and PA-QSA Companies may be subject to audits of their work under the QSA Qualification Requirements at any time. This may include, but not be limited to, review of completed reports, work papers and onsite visits with PA-QSA Companies to audit internal QA programs, at the expense of the ~~PA-QSA~~ Companies. Refer to the QSA Qualification Requirements for information on PCI SSC’s audit process.

QSA Company audits are addressed in the QSA Qualification Requirements, and PA-QSA Companies may be subject to audits of their work under the QSA Qualification Requirements at any time. This may include, but not be limited to, review of completed reports, work papers and onsite visits with PA-QSA Companies to audit internal QA programs, at the expense of the PA- QSA Companies. Refer to the QSA Qualification Requirements for information on PCI SSC’s audit process.

Modified p. 36 → 44

If a Payment Application included on the PCI SSC List of PA-DSS Validated Payment Applications is compromised due to PA-QSA Company and/or Employee error, ~~then~~ that PA-QSA Company and/or Employee may immediately be placed into Remediation or its status revoked.

If a Payment Application included on the PCI SSC List of PA-DSS Validated Payment Applications is compromised due to PA-QSA Company and/or Employee error, that PA-QSA Company and/or Employee may immediately be placed into Remediation or its status revoked.

Modified p. 36 → 44

The PA-QSA Company and/or Employee may appeal the Revocation, but unless otherwise approved by PCI SSC in writing in each instance, will not be permitted to perform PA-DSS Assessments, process ROVs, or otherwise participate in the PA-DSS Program. The ~~PA-QSA~~ Company and/or Employee may reapply at a later date of one year after revocation, so long as it has demonstrated to PCI SSC's satisfaction that it meets all applicable QSA and PA-QSA Requirements as documented in the QSA Qualification Requirements, …

The PA-QSA Company and/or Employee may appeal the Revocation, but unless otherwise approved by PCI SSC in writing in each instance, will not be permitted to perform PA-DSS Assessments, process ROVs, or otherwise participate in the PA-DSS Program. The PA- QSA Company and/or Employee may reapply at a later date of one year after revocation, so long as it has demonstrated to PCI SSC's satisfaction that it meets all applicable QSA and PA-QSA Requirements as documented in the QSA Qualification …

Removed p. 38

• even if the different Payment Application or version (the Alternate Version) conforms to the basic product description of the Accepted Version

•the Alternate Version should not be considered Accepted by PCI SSC, nor promoted as Accepted by PCI SSC.

No Vendor or other third party may refer to a Payment Application as “PCI Approved,” or “PCI SSC Accepted” nor otherwise state or imply that PCI SSC has, in whole or part, approved any aspect of a Vendor or its Payment Applications, except that to the extent PCI SSC has issued an Attestation of Validation provided by PCI SSC. All other references to PCI SSC’s Acceptance or Approval of a Payment Application or version thereof are strictly and actively prohibited by PCI SSC.

Modified p. 38 → 46

PCI SSC Acceptance signifies that (i) a PA-QSA has determined that the Accepted Version of a Payment Application complies with the PA-DSS and therefore implements certain security and operational characteristics important to the achievement of PCI ~~SSC’s~~ goals and (ii) the corresponding ROV has successfully completed AQM review, but such Acceptance does not under any circumstances include or imply any endorsement or warranty by PCI SSC or any Payment Card Brand regarding the Payment Application Vendor or the functionality, quality, …

PCI SSC Acceptance signifies that (i) a PA-QSA Company has determined that the Accepted Version of a Payment Application complies with the PA-DSS and therefore implements certain security and operational characteristics important to the achievement of PCI SSC‘s goals and (ii) the corresponding ROV has successfully completed AQM review, but such Acceptance does not under any circumstances include or imply any endorsement or warranty by PCI SSC or any Payment Card Brand regarding the Payment Application Vendor or the functionality, …

Removed p. 39

In PA-DSS, see Instructions and Content for Report on Validation section for details about content to include in the PA-DSS ROV for Vendor’s versioning methods.

Modified p. 39 → 47

Component Description Application Name Acme Payment 600 Application Version # PCI ~~4.53~~ Application Type POS Suite Target Market (None noted) Reference # 09-01.00111.001 ~~Example of a~~ Payment Application Identifier:

Component Description Application Name Acme Payment 600 Application Version # PCI 4.53.x Application Type POS Suite Target Market (None noted) Reference # 09-01.00111.001 Payment Application Identifier: Detail  Payment Application Name Payment Application Name is provided by the Vendor and is the name by which the Payment Application is sold. The Payment Application Name cannot contain any variable characters.

Modified p. 39 → 47

 Payment Application Version # Payment Application Version # represents the ~~specific~~ application version reviewed in the ~~PA- DSS~~ Assessment. The format ~~is set by~~ the ~~Vendor and may consist of a combination of fixed and variable alphanumeric characters.~~

 Payment Application Version # Payment Application Version # represents the application version reviewed in the PA-DSS Assessment. The format of the version number:

Modified p. 39 → 48

 Payment Application ~~Name~~ Payment ~~Application Name is provided by~~ the ~~Vendor, and is~~ the ~~name by which~~ the ~~Payment Application is sold.~~

 Payment Application Type Payment Applications can have many functions. The Vendor must choose the option which best describes the primary function of the application from the list below.

Modified p. 39 → 48

Customers are strongly advised to ~~purchase and~~ deploy only those Payment Applications with the Application Version # whose characters ~~match exactly~~ the Application Version # shown on the List of Validated Payment Applications.

Note: See Appendix B: Payment Application Software Version Methodology for details about content to include in the ROV and PA-DSS Implementation Guide for Vendor’s versioning methods. Customers are strongly advised to deploy only those Payment Applications with the Application Version # whose characters are consistent with the Application Version # shown on the List of Validated Payment Applications.

Modified p. 40 → 48

Type Function Description 01 POS Suite/General Point of sale software ~~which~~ can be used by merchants for numerous payment channels, including face-to-face, mail-order/telephone order (MOTO, including call centers), Interactive Voice Response (IVR), Web (for manually entered e-commerce, MOTO, etc., transactions), and EFT/check authentication.

Type Function Description 01 POS Suite/General Point of sale software that can be used by merchants for numerous payment channels, including face-to-face, mail-order/telephone order (MOTO, including call centers), Interactive Voice Response (IVR), Web (for manually entered e-commerce, MOTO, etc., transactions), and EFT/check authentication.

Modified p. 41 → 49

PCI SSC assigns the Reference number once the application is posted to the Website; this number is unique per Vendor and will remain the same for the life of the ~~application’s~~ listing.

PCI SSC assigns the Reference number once the application is posted to the Website; this number is unique per Vendor and will remain the same for the life of the application‘s listing.

Modified p. 41 → 49

Field Format Year of listing 2 digits + hyphen Payment Application Type (see above) 2 digits + period Vendor # 5 digits + period (assigned alphabetically initially, then as received) Vendor App # 3 digits + period (assigned as received) Minor ~~version~~ 3 alpha characters (assigned as received) A.3 Description Provided by Vendor This section allows for the submission of a description of the Payment Application that is to be used in the List of Validated Payment ~~Application~~ should the …

Field Format Year of listing 2 digits + hyphen Payment Application Type (see above) 2 digits + period Vendor # 5 digits + period (assigned alphabetically initially, then as received) Vendor App # 3 digits + period (assigned as received) Minor change reference 3 alpha characters (assigned as received) A.3 Description Provided by Vendor This section allows for the submission of a description of the Payment Application that is to be used in the List of Validated Payment Applications, should …

Modified p. 42 → 50

A.6 Validation Notes Validation Notes are used by PCI SSC to denote what standard, and the specific version thereof, was used to assess the compliance of a Validated Payment Application. Please see table under ~~“Expiry Date”~~ below for examples.

A.6 Validation Notes Validation Notes are used by PCI SSC to denote what standard, and the specific version thereof, was used to assess the compliance of a Validated Payment Application. Please see table under Expiry Date below for examples.

Modified p. 42 → 50

A.7 Deployment Notes Deployment Notes are used by PCI SSC to denote the scenarios in which Validated Payment Applications are recommended for use. Assigned deployment notes are determined by the ~~Vendor’s~~ active participation in annual ~~re-validation,~~ whether or not the particular version of the Payment Application is still being supported by the Vendor, or by the Payment ~~Application’s~~ Expiration Date (noted below).

A.7 Deployment Notes Deployment Notes are used by PCI SSC to denote the scenarios in which Validated Payment Applications are recommended for use. Assigned deployment notes are determined by the Vendor‘s active participation in annual revalidation, whether or not the particular version of the Payment Application is still being supported by the Vendor, or by the Payment Application‘s Expiration Date (noted below).

Modified p. 42 → 50

1. Acceptable for New Deployments

• All newly Accepted PA-DSS Validated Payment Applications are initially put into this state and will maintain this state until such time that (i) annual revalidation requirements are not maintained by the Vendor causing an administrative ~~early~~ expiry, or (ii) the Validated Payment Application expires as a matter of course based on the version of the PA-DSS under which it was validated.

 Acceptable for New Deployments: All newly Accepted PA-DSS Validated Payment Applications are initially put into this state and will maintain this state until such time that either (i) annual revalidation requirements are not maintained by the Vendor causing an early administrative expiry, or (ii) the Validated Payment Application expires as a matter of course based on the version of the PA-DSS under which it was validated.

Modified p. 42 → 50

2. Acceptable only for Pre-Existing Deployments

• This deployment note is assigned to Validated Payment Applications where either (i) annual revalidation requirements are not maintained by the Vendor causing an administrative ~~early~~ expiry, or (ii) the Validated Payment Application expires as a matter of course based on the version of the PA-DSS under which it was validated. Questions about continued use of validated Payment Applications that have expired should be referred to the Payment Card Brands.

 Acceptable only for Pre-Existing Deployments: This deployment note is assigned to Validated Payment Applications where either (i) annual revalidation requirements are not maintained by the Vendor causing an early administrative expiry, or (ii) the Validated Payment Application expires as a matter of course based on the version of the PA-DSS under which it was validated. Questions about continued use of validated Payment Applications that have expired should be referred to the Payment Card Brands.

Modified p. 42 → 50

These deployment notes are used by the Council to note the status of a Validated Payment Application is relation to its Expiry Date. See table under “Expiry Date” below for examples.

These deployment notes are used by the Council to note the status of a Validated Payment Application in relation to its Expiry Date. See table under “Expiry Date” below for examples.

Removed p. 43

There is currently no sunset date for PA-DSS Validated Payment Applications that were on the List of Validated Payment Applications at the time of deployment. Deployed Payment Applications that expire may continue to be used. The expiration timeframe is associated with new purchases/deployments, not existing deployments.

Modified p. 43 → 51

A.9 Expiry Date The Expiry Date for PA-DSS Validated Payment Applications is the date by which a Vendor must ~~get~~ the application re-evaluated against the current PA-DSS Requirements in order to maintain the acceptance. The Expiry Date is related to the Deployment Notes, noted above.

A.9 Expiry Date The Expiry Date for PA-DSS Validated Payment Applications is the date by which a Vendor must have the application re-evaluated against the current PA-DSS Requirements in order to maintain the acceptance. The Expiry Date is related to the Deployment Notes, noted above.

Modified p. 43 → 51

PCI SSC will endeavor to update the PA-DSS on a 36-month cycle, in conjunction with updates to PCI DSS. Acceptance for PA-DSS ~~validated~~ Payment Applications expires three years past the effective date of a subsequent update of the PA-DSS Requirements. The objective is a three-year minimum approval life expectancy, barring a severe threat that may require immediate changes.

PCI SSC will endeavor to update the PA-DSS on a 36-month cycle, in conjunction with updates to PCI DSS. Acceptance for PA-DSS Validated Payment Applications expires three years past the effective date of a subsequent update of the PA-DSS Requirements. The objective is a three-year minimum approval life expectancy, barring a severe threat that may require immediate changes.

Modified p. 44 → 54

Note: For future consideration While certified Payment Application builds are not a requirement at this time, we encourage Vendors and ~~PA-QSAs~~ to work together to develop methods to certify and digitally sign Payment Application builds. PCI SSC reserves the right to require certified application builds in the future.

Note: For future consideration While certified Payment Application builds are not a requirement at this time, we encourage Vendors and PA-QSA Companies to work together to develop methods to certify and digitally sign Payment Application builds. PCI SSC reserves the right to require certified application builds in the future.

Modified p. 44 → 54

Vendors clearly identify a certified build for general release. Ideally, a build certified by a PA-QSA as ~~PA- DSS~~ compliant should be fingerprinted

•digitally signed (code-signed)

•by both the Vendor and the QSA when packaged for delivery. At the very least, the delivery should be identified unambiguously by name, version, build number, and date-time stamp, and verifiable with an MD5 digest and corresponding build header. In this manner, PA-DSS Requirement 7.2 for delivery assurance via "known ~~chain-of-trust"~~ is strengthened. Also, this could …

Vendors clearly identify a certified build for general release. Ideally, a build certified by a PA-QSA Company as PA-DSS compliant should be fingerprinted

•digitally signed (code-signed)

•by both the Vendor and the QSA when packaged for delivery. At the very least, the delivery should be identified unambiguously by name, version, build number, and date-time stamp, and verifiable with an MD5 digest and corresponding build header. In this manner, PA-DSS Requirement 7.2 for delivery assurance via "known chain of trust" is strengthened. Also, …

Document Comparison

Content Changes