Document Diff - PCI Watch

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

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

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

Added p. 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 the entire industry, the current version of which is available on the PCI SSC website (Website). Key to the success of the PCI DSS is merchant and service provider compliance. When implemented appropriately, PCI DSS Requirements provide rigorous defense against data exposure and compromise. Ensuring Payment Applications meet PCI DSS Requirements and are installed into merchant or service-provider environments in a manner that supports compliance is important to the effectiveness …

Added p. 6

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

 The AOV is a declaration of a Payment Application’s validation status with the PA- DSS.

 The PA-QSA Qualification Requirements define the requirements that must be met by PA-QSA Companies and PA-QSA Employees in order to perform PA-DSS Assessments.

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

Added p. 7

PA-DSS The then-current version of (or successor documents to) the Payment Card Industry (PCI) Payment Application Data Security Standard and Security Assessment Procedures, as from time to time amended and made available on the Website.

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.

Added p. 8

PA-DSS Validated Payment Application A Payment Application that has been assessed and validated by a PA- QSA Company as being compliant with the PA-DSS, then Accepted by PCI SSC, so long as such Acceptance has not been revoked, suspended, withdrawn or terminated.

PA-QSA Acronym for "Payment Application

• Qualified Security Assessor" Company, a company then qualified by PCI SSC to perform PA-DSS Assessments.

PA-QSA Company A data security firm that has been qualified, and continues to be qualified, by PCI SSC to perform PA-DSS Assessments for PA-DSS Program purposes.

PA-QSA Company Testing Laboratory (or Laboratory) A laboratory environment maintained by the PA-QSA Company to perform testing of Payment Applications that Vendors provide for validation.

PA-QSA Employee An individual who is employed by a PA-QSA Company and has satisfied, and continues to satisfy, all QSA and PA-QSA Requirements applicable to employees of PA-QSA Companies who will conduct PA-DSS Assessments, as described in further detail herein.

PA-QSA Qualification …

Added p. 9

Vendor (or vendor) A vendor of a Payment Application.

Vendor Release Agreement (or VRA) The then-current version of (or successor document to) the Payment Card Industry Vendor Release Agreement on the form then approved by PCI SSC for Vendors participating in the PA-DSS Program, as from time to time amended and made available on the Website.

Website The then-current PCI SSC Website (and its accompanying web pages), which is currently available at www.pcisecuritystandards.org.

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

Added p. 10

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:

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

Added p. 11

 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: o Submissions (including ROVs, Minor Updates and Annual Revalidations) are correct as to form; o PA-QSA Companies properly determine whether candidate Payment Applications meet baseline eligibility criteria for validation under the PA-DSS Program (PCI SSC reserves the right to reject or de-list any Payment Application determined to be ineligible for the PA-DSS Program); o PA-QSA Companies adequately report the PA-DSS compliance of candidate Payment Applications in their associated submissions; and …

Added p. 12

 Performing PA-DSS Assessments of Payment Applications in accordance with the PA-DSS and the PA-QSA Qualification Requirements;  Providing an opinion regarding whether the Payment Application meets PA-DSS Requirements;  Providing adequate documentation within the ROV to demonstrate the Payment Application’s PA-DSS compliance;  Submitting the ROV and/or any application change submissions to PCI SSC, along with the Attestation of Validation, signed by both PA-QSA Company and Vendor);  Submitting the Payment Application’s PA-DSS Implementation Guide to PCI SSC;  Maintaining an internal quality assurance process for their PA-DSS Assessment efforts;  Staying up to date with Council statements and guidance, industry trends and best practices;  Properly determining whether or not Payment Applications are eligible for PA-DSS validation;  Satisfying all applicable PA-QSA Qualification Requirements at all times, including but not limited to successful completion of annual revalidation and all required training and training examinations.

Added p. 13

PCI Qualified Integrators and Resellers (QIRs) are trained by the Council in PCI DSS and PA-DSS in order to help ensure that they securely implement Payment Applications. For more information on the PCI QIR program, please see www.pcisecuritystandards.org.

Added p. 13

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

PCI SSC website;  Implementing such applications into a PCI DSS compliant environment;  Configuring each such application (where configuration options are provided) according to the Payment Application’s PA-DSS Implementation Guide provided by the Vendor;  Configuring each such application in a PCI DSS-compliant manner; and  Maintaining the PCI DSS-compliant status of both the environment and the Payment Application configuration.

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.

 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 …

Added p. 18

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 it relies. These applications should not be assessed separately from other applications they rely upon since all PA-DSS Requirements are not met within a single application.

 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 …

Added p. 21

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

Added p. 22

 Prompt payment of the fees due to PCI SSC  PCI SSC will not commence review of the ROV until the applicable fee has been paid.

 Quality of the PA-QSA Company's submission to PCI SSC  Incomplete submissions or those containing errors

•for example, missing or unsigned documents, incomplete or inconsistent submissions

•will result in delays in the review process.

 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 …

Added p. 23

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.

Added p. 24

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.

3. High Impact Changes are changes made to a listed Payment Application that affect the PA-DSS related functions of the Payment Application and have a high impact on the PA-DSS Requirements. In this case, for the new version to be listed, the Vendor submits the new version of the Payment Application for a full PA-DSS review•see Section 4.2.4, “High Impact Changes,” for specifics.

Added p. 27

 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 …

Added p. 28

 Administrative Changes are limited to updates where no application changes have occurred but the Vendor wishes to request a change to the way their application is currently listed. Administrative changes include, but are not limited to, changes to the application name or corporate entity name changes.

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

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

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;

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

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

If the PA-QSA Company does not agree with the Vendor that the change, as documented …

Added p. 30

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;

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

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

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

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

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 …

Added p. 31

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

Added p. 31

For any change affecting the listing of a validated Payment Application, the applicable fee will be invoiced and must be received by PCI SSC for the changes to be Accepted and added to the PCI SSC List of Validated Payment Applications. Upon Acceptance, PCI SSC will sign and return a copy of the Attestation of Validation to both the Vendor and the PA-QSA Company.

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.

 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);  …

Added p. 36

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.

The AQM analyst will review the application first to determine whether it is eligible for validation as described in the PA-DSS Program Guide. If there is question as to eligibility, the AQM analyst will contact the PA-QSA Company for additional information. If the Payment Application is determined to be ineligible for validation under the PA-DSS Program, the ROV will be rejected. The PA-QSA Company will receive a letter of rejection with optional instructions for appealing the rejection.

If the Payment Application is determined to be eligible for validation under the PA-DSS Program and the submission is complete, the AQM analyst will complete a full review of the …

Added p. 36

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.

Added p. 36

Note: These status designations are not necessarily progressive: Any PA-QSA Company’s status may be revoked or its PA-QSA Addendum terminated in accordance with the PA-QSA Addendum; and accordingly, if warranted, a PA-QSA Company may move directly from “In Good Standing” to “Revocation.” Nonetheless, in the absence of severe quality concerns, PA-QSA Companies with quality issues are generally first addressed through the Remediation process in order to promote improved performance.

Added p. 37

If non-severe quality problems are detected, PCI SSC will typically recommend participation in the Remediation program. While participation is optional, Remediation provides an opportunity for PA-QSA Companies and/or Employees to improve performance by working closely with PCI SSC staff; and in the absence of participation, quality issues may increase. Additionally, Remediation helps to assure that the baseline standard of quality for PA-QSA Companies and/or Employees is upheld. Refer to the QSA Qualification Requirements for further detail on the Remediation Process.

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 …

Added p. 42

 Contradict any PCI SSC program or requirement (e.g., the application must not claim to store sensitive authentication data after authorization).

 Make misleading claims about the application (e.g., that usage of the application reduces the scope of a PCI DSS Assessment).

 Claim the application is valid under another PCI SSC program or standard.

PCI SSC recommends keeping the description concise and including only pertinent information about the application.

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

Only the specific operating systems and platforms on which the application was tested will be listed on the Website.

A.5 Required Dependencies Identify specific dependencies that the submitted Payment Application has to other PA-DSS Validated Payment Applications, Approved Point of Interaction Devices, other hardware environments, or broader software environments. Such dependencies must include specific version/firmware and/or hardware identifiers and any relevant PA-DSS or PTS reference numbers.

Please refer …

Modified p. 1

Payment Card Industry (PCI) Payment Application Data Security Standard (PA-DSS) Program Guide Version ~~2.0~~

Payment Card Industry (PCI) Payment Application Data Security Standard (PA-DSS) Program Guide Version 2.1

Removed p. 2

Description Pages Updated list of references. 3 Additional terminology added. 3-4 Roles & Responsibilities have been updated to create a more consistent message on how different organizations participate in the PA-DSS program.

All process diagrams have been updated with amended processes. 10-13 PA-DSS applicability to payment applications on hardware terminals has been updated to reflect new text of the PA-DSS v2.0.

Changes to the fee structure. 19, 25 Update to the annual revalidation process. 20 Update to the process for acceptance of minor changes, including a new allowance for changes that have low impact on the PA-DSS requirements.

New payment application types added. 38-39 Information on expiry updated to reflect new 3-year lifecycle of PA- DSS.

The PA-DSS Attestations of Validation have been combined into a single document that combines new assessments, annual revalidations, & minor changes. In addition, it has been segregated into its own document.

New information added in the following areas:

 Portal …

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. ~~Specific changes include:~~

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.

Removed p. 4

Note:  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-QSAs to validate the payment application’s compliance and document the review.  The ROV Reporting Instructions provide detail on how to document the findings of a PA-DSS assessment.  The AOV is a declaration of a payment application’s validation status with the PA-DSS.  The QSA Qualification Requirements and PA-QSA Supplement together define the requirements that must be met by a PA-QSA in order to perform PA- DSS assessments.  The PA-DSS VRA establishes the terms and conditions under which validation of a payment applications are accepted by PCI SSC. PCI DSS provides the foundation for all the afore-mentioned.

Modified p. 4 → 6

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

• ~~Requirements and Security Assessment Procedures (―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 ~~(―AOV‖)~~ The following additional documents are used in conjunction with the aforementioned:

• 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:

Modified p. 4 → 6

 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 ~~QSA~~ Qualification Requirements ~~(―QSA~~ Qualification ~~Requirements‖)~~  Payment Card Industry (PCI) Data Security Standard QSA Qualification Requirements

• Supplement for Payment Application Qualified Security Assessors (PA- QSAs) (―PA-QSA Supplement‖)  Payment Card Industry PA-DSS Vendor Release …

 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 …

Modified p. 4 → 6

All of the above documents are available in electronic form on ~~www.pcisecuritystandards.org (the ―PCI SSC website‖).~~

All of the above documents are available in electronic form on the Website.

Modified p. 4 → 6

PCI SSC reserves the right to change, ~~amend~~ or withdraw security requirements at any time. If such ~~a change is~~ required, PCI SSC will endeavor to work closely with PCI SSC‘s community of Participating Organizations and ~~software vendors~~ to help minimize the impact of any changes.

PCI SSC reserves the right to change, amend, or withdraw security requirements at any time. If such changes are required, PCI SSC will endeavor to work closely with PCI SSC‘s community of Participating Organizations and Vendors to help minimize the impact of any changes.

Removed p. 5

PCI SSC Refers to the PCI Security Standards Council LLC 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.

Payment brands and Each refers to the payment card brands that are statutory members of PCI SSC, currently the following or affiliates thereof: American Express, Discover, JCB, MasterCard Worldwide, and Visa.

Payment Applications Refer broadly to all payment applications that store, process, or transmit cardholder data as part of authorization or settlement, where these payment applications are sold, distributed, or licensed to third parties.

Modified p. 5 → 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;~~ (ii) confirmed that the ROV is correct as to form, the PA-QSA properly determined that the ~~payment application~~ is eligible to be a PA-DSS Validated Payment Application, the PA-QSA adequately reported the PA-DSS compliance of the ~~payment application~~ in accordance with ~~PA-DSS~~ Program …

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

List of Validated Payment Applications Refers to the ~~Council‘s~~ authoritative list of PA-DSS Validated Payment Applications appearing on the ~~PCI SSC website.~~

List of Validated Payment Applications Refers to the authoritative list of PA-DSS Validated Payment Applications appearing on the Website.

Modified p. 5 → 7

Listing or listing Refers to the listing and related information regarding a ~~payment application~~ on the List of Validated Payment Applications.

Listing or listing Refers to the listing and related information regarding a Payment Application on the List of Validated Payment Applications.

Modified p. 5 → 7

PA-DSS 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- QSAs and validation and Acceptance of Payment Applications, as further described in this document and related PCI SSC documents, policies and procedures.

Removed p. 6

Depending on the circumstances, a vendor that does not store, process, or transmit cardholder data may not be directly required to comply with the PCI DSS since only entities that do store, process, or transmit cardholder data are required to comply with the PCI DSS. However, since payment applications are used by customers to store, process, and transmit cardholder data, and customers are required to be PCI DSS compliant, payment applications should facilitate, and not prevent, the customers' PCI DSS compliance. Examples of how payment applications can prevent PCI DSS compliance include:

Modified p. 6 → 7

~~ROV A ―PA-DSS Report on Validation‖ provided by~~ a ~~PA-QSA to PCI SSC~~ for purposes of ~~demonstrating~~ compliance with the PA-DSS as part of the PA-DSS Program.

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.

Modified p. 6 → 9

PCI SSC reflects a desire among constituents of the Payment Card Industry ~~(PCI)~~ at all levels for a ~~single,~~ standardized set of security requirements, security assessment procedures, and processes for recognizing ~~payment applications~~ validated by a ~~PA-QSA.~~ The PA-DSS and related PCI SSC standards define a common security assessment framework that is recognized by ~~all payment brands.~~

PCI SSC reflects a desire among constituents of the Payment Card Industry at all levels for a standardized set of security requirements, security assessment procedures, and processes for recognizing Payment Applications validated by a PA-QSA Company. The PA-DSS and related PCI SSC standards define a common security assessment framework that is recognized by the Payment Card Brands.

Modified p. 6 → 9

 Customers benefit from a broader selection of secure ~~payment applications.~~

 Customers benefit from a broader selection of secure Payment Applications.

Modified p. 6 → 9

 Customers are assured that they will be using products that have been validated to meet the ~~PA- DSS requirements by a PA-QSA  Vendors will only need to validate their payment application against the~~ PA-DSS ~~Program in order for their payment applications to be recognized by all participating payment brands.~~

 Customers are assured that they will be using products that have been validated by a PA-QSA Company to meet the PA-DSS Requirements.

Modified p. 6 → 9

For more information regarding PCI SSC, see the ~~PCI SSC website.~~

For more information regarding PCI SSC, see the Website.

Modified p. 6 → 10

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

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

Modified p. 6 → 10

1. ~~Magnetic-stripe~~ data stored in the customer's network after authorization;

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

Modified p. 6 → 10

2. Applications ~~that require~~ customers to disable other features required by the PCI DSS, like ~~anti- virus~~ software or firewalls, in order to get the ~~payment application~~ to work properly; and

2. Applications requiring customers to disable other features required by the PCI DSS, like anti-virus software or firewalls, in order to get the Payment Application to work properly; and

Removed p. 7

 Any requirements, mandates, or dates for use of PA-DSS compliant payment applications; and  Any fines or penalties related to use of non-compliant payment applications.

The payment brands define their own related compliance programs, mandates, dates, etc., as well as other requirements for using PA-DSS and PA-DSS Validated Payment Applications.

Removed p. 7

 Is a centralized repository for all ROVs;  Hosts the List of PA-DSS Validated Payment Applications on the PCI SSC website;  Qualifies and provides required training for PA-QSAs to assess and validate payment applications for PA-DSS compliance;  Maintains and updates the PA-DSS standard and related documentation according to a standards lifecycle management process; and  Performs Quality Assurance (QA) reviews of PA-DSS ROVs to confirm report consistency and quality, including but not limited to the following:

 Submissions (including ROVs, Minor Updates and Annual Revalidations) are correct as to form;  The PA-QSA properly determined that the candidate payment applications is eligible to be a PA-DSS Validated Payment Application (PCI SSC reserves the right to reject or de-list any payment application determined to ineligible for the PA-DSS Program);  The PA-QSA adequately reported the PA-DSS compliance of candidate payment applications in their associated Submissions; and

Modified p. 7 → 10

Secure ~~payment applications,~~ when implemented into a PCI DSS-compliant environment, will help to minimize the potential for security breaches leading to compromises of full ~~magnetic stripe~~ data, card validation codes and values (CAV2, CID, CVC2, CVV2), PINs and PIN blocks, and the damaging fraud resulting from these breaches.

Secure Payment Applications, when implemented into a PCI DSS-compliant environment, will help to minimize the potential for security breaches leading to compromises of primary account numbers (PAN), full track data, card validation codes and values (CAV2, CID, CVC2, CVV2), PINs and PIN blocks, and the damaging fraud resulting from these breaches.

Modified p. 7 → 11

PCI SSC is the standards body that maintains the ~~payment card industry~~ standards, including the PCI ~~DSS~~ 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:

Removed p. 8

 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);  Creating a PA-DSS Implementation Guide, specific to each application, in accordance with the requirements in the Payment Application Data Security Standard;  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 review as specified in PCI PA-DSS Requirements and Security Assessment Procedures; and  Providing their customers (either directly or indirectly through their resellers and integrators) with a copy of the validated payment application‘s PA-DSS Implementation Guide. This includes any …

Modified p. 8 → 11

~~Additionally, as~~ part of the ~~above QA~~ process, PCI SSC assesses whether overall, PA-QSA Company operations appear to conform to PCI SSC‘s quality assurance and qualification requirements.

As part of the quality assurance (QA) process, PCI SSC assesses whether overall, PA-QSA Company operations appear to conform to PCI SSC‘s quality assurance and qualification requirements.

Modified p. 8 → 11

Please Note: PCI SSC does not assess or validate ~~payment applications~~ for PA-DSS ~~compliance. As described further below,~~ assessment and validation is the role of the ~~PA-QSA.~~ Listing of a ~~payment application~~ on the List of Validated Payment Applications signifies that the applicable PA-QSA has determined that the application complies with the PA-DSS, that the PA-QSA has submitted a corresponding ROV to PCI SSC, and that the ROV, as submitted to PCI SSC, has satisfied all ~~applicable QA ROV review~~ …

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. 8 → 12

Vendors submit their ~~payment applications~~ and supporting documentation to the PA-QSA for ~~review. Any agreements~~ and ~~costs associated with the PA-QSA‘s assessment are negotiated between the vendor and the PA-QSA. Vendors provide permission for~~ their PA-QSA to submit resulting ROVs and related information to PCI SSC.

Vendors submit their Payment Applications and supporting documentation to the PA-QSA Company for review and authorize their PA-QSA Company to submit resulting ROVs and related information to PCI SSC.

Modified p. 8 → 12

Note: Not all ~~QSAs~~ are ~~PA- QSAs•there~~ are additional qualification requirements that must be met for a QSA to become a ~~PA-QSA.~~

Note: Not all QSA Companies are PA-QSA Companies•there are additional qualification requirements that must be met for a QSA Company to become a PA-QSA Company.

Modified p. 9 → 12

It is the ~~PA-QSA‘s~~ responsibility to assess a ~~payment application‘s compliance to the PA-DSS,~~ as of the date of the ~~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.

Modified p. 9 → 13

 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. 9 → 13

Resellers ~~and integrators do~~ not submit ~~payment applications~~ for ~~assessment.~~ Products can only be submitted by the ~~software 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.

Removed p. 10

 Ensuring that the payment application‘s version information matches what is indicated on the PCI SSC website;  Implementing such applications into a PCI DSS compliant environment;  Configuring each such application (where configuration options are provided) according to the payment application‘s PA-DSS Implementation Guide provided by the vendor;  Configuring each such application in a PCI DSS-compliant manner; and  Maintaining the PCI DSS-compliant status of both the environment and the payment application configuration.

Modified p. 10 → 13

A PA-DSS Validated Payment Application alone is not a guarantee of PCI DSS compliance.

Note: A PA-DSS Validated Payment Application alone is not a guarantee of PCI DSS compliance.

Modified p. 10 → 13

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 ~~Council’s~~ authoritative source for ~~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 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.

Removed p. 11

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

2. The vendor then provides to the PA-QSA 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 then assesses the payment application‘s security functions and features to determine whether the application complies with PA-DSS security requirements;

4. If the PA-QSA determines that the payment application is in compliance with the PA-DSS, the PA- QSA submits a corresponding ROV to PCI SSC, opining to compliance and setting forth the results, opinions and conclusions of the PA-QSA on all test procedures along with the vendor‘s signed PA- DSS VRA;

5. PCI SSC then reviews the ROV to confirm that it meets the PA-DSS Program requirements, and if …

Modified p. 11 → 14

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 detail the following components of the PA-DSS Program:

Removed p. 16

The following guide can be used to determine whether PA-DSS applies to a given payment application:

 PA-DSS does not apply to non-payment applications that are part of a payment application suite. 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 it relies. These applications should not be assessed separately from other applications they rely upon since all PA-DSS requirements are not met within a single application.

Modified p. 16 → 18

 PA-DSS does apply to ~~payment applications~~ that are typically sold and installed ~~―off~~ the ~~shelf‖~~ without much customization by ~~software vendors.~~

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

Modified p. 16 → 18

 PA-DSS does apply to ~~payment applications~~ provided in modules, ~~which~~ typically ~~includes~~ 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).~~ If other modules also perform payment functions, PA-DSS applies to those modules as well. Note that it is considered a ~~―best practice‖~~ for ~~software vendors~~ to isolate …

 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 …

Modified p. 16 → 18

 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:

 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:

Modified p. 16 → 18

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; 2) 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 3) The application is not sold, distributed, or licensed to third parties.

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

Modified p. 16 → 18

Examples of these ~~―software~~ as a ~~service‖ payment applications~~ include:

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

Modified p. 16 → 18

1) 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 third-party site, and the application was not covered by the ~~ASP‘s~~ PCI DSS review.

 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 third-party site, and the application was not covered by the ASP’s PCI DSS review.

Modified p. 16 → 18

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

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

Modified p. 17 → 19

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

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

Modified p. 17 → 19

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.

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.

Modified p. 17 → 19

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 applications~~ for purposes of PA-DSS (and therefore are not eligible for independent assessment under PA-DSS):

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 Applications for purposes of PA-DSS (and therefore are not eligible for independent assessment under PA-DSS):

Modified p. 17 → 19

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

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

Modified p. 17 → 19

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

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

Modified p. 17 → 19

There are two ways for a resident ~~payment application~~ on a hardware terminal to achieve PA-DSS validation:

There are two ways for a resident Payment Application on a hardware terminal to achieve PA-DSS validation:

Modified p. 17 → 19

1. The resident ~~payment application~~ directly meets all PA-DSS ~~requirements~~ and is validated according to standard PA-DSS ~~procedures.~~

1. The resident Payment Application directly meets all PA-DSS Requirements and is validated according to standard PA-DSS procedures; or

Modified p. 17 → 19

2. The resident ~~payment application~~ does not meet all PA-DSS ~~requirements,~~ but the hardware ~~that~~ the application ~~is resident on~~ 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. 18

1. 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 it has been validated to run on;

2. Enabled by default to support a customer‘s PCI DSS compliance;

3. Include ongoing support and updates to maintain PCI DSS compliance; and

4. If the application is separately sold, distributed or licensed to customers, the vendor must provide details of the dependant hardware required for use with the application, in accordance with its PA- DSS validation listing.

Modified p. 18 → 20

When conducting the PA-DSS ~~assessment,~~ the PA-QSA must fully test the ~~payment application~~ with its ~~dependant~~ hardware against all PA-DSS ~~requirements.~~ If the PA-QSA determines that one or more ~~PA- DSS requirements~~ cannot be met by the resident ~~payment application,~~ but they are met by controls validated under PCI PTS, the PA-QSA must:

When conducting the PA-DSS Assessment, the PA-QSA Company must fully test the Payment Application with its dependent hardware against all PA-DSS Requirements. If the PA-QSA Company determines that one or more PA-DSS Requirements cannot be met by the resident Payment Application, but they are met by controls validated under PCI PTS, the PA-QSA Company must:

Modified p. 18 → 20

1. Clearly document which ~~requirements~~ are met as stated per PA-DSS (as usual);

1. Clearly document which Requirements are met as stated per PA-DSS (as usual);

Modified p. 18 → 20

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 in the “In Place” box for that Requirement;

Modified p. 18 → 20

3. Include a thorough explanation as to why the ~~payment application~~ could not meet the PA-DSS ~~requirement;~~

3. Include a thorough explanation as to why the Payment Application could not meet the PA-DSS Requirement;

Modified p. 18 → 20

4. Document the procedures that were conducted to determine how that ~~requirement~~ was fully met through a PCI PTS validated control; and

4. Document the procedures that were conducted to determine how that Requirement was fully met through a PCI PTS validated control; and

Modified p. 18 → 20

Once the ~~PA-QSA‘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 Applications.

Modified p. 18 → 20

Resident ~~payment applications~~ on hardware terminals that are validated through a combination of PA- DSS and PCI PTS controls must meet the following criteria:

Resident Payment Applications on hardware terminals that are validated through a combination of PA- DSS and PCI PTS controls must meet the following criteria:

Removed p. 19

 Perform a ―gap‖ analysis between how the payment application subject to PA-DSS functions compared to PA-DSS requirements;  Correct any gaps; and  If desired, the PA-QSA may perform a pre-assessment or ―gap‖ analysis of a vendor‘s payment application. If the PA-QSA notes deficiencies that would prevent a clean opinion, the PA-QSA will provide to the software 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.

Modified p. 19 → 21

 Review both PCI DSS and PA-DSS ~~requirements~~ and related documentation located at the PCI SSC website;  Determine/assess ~~your payment application‘s~~ readiness to comply with PA-DSS:

 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:

Modified p. 19 → 21

All 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 listed on the PCI SSC website, not to PCI SSC.

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.

Modified p. 19 → 21

Examples of ~~documents~~ and items to submit to the PA-QSA include, but 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. 19 → 21

1. The ~~payment application;~~

1. The Payment Application;

Modified p. 19 → 21

 Simulated payment transactions; and  Operational support functions on the ~~payment application;~~

 Simulated payment transactions; and  Operational support functions on the Payment Application;

Modified p. 19 → 21

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. 19 → 21

4. Documentation that relates to installing and configuring the application, or which provides information about the application. ~~Examples of such~~ documentation ~~include:~~

4. Documentation that relates to installing and configuring the application, or which provides information about the application. Such documentation includes but is not limited to:

Modified p. 19 → 21

 PA-DSS Implementation Guide (note that this must be submitted to the ~~PA-QSA);~~  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;

 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. 19 → 21

5. Additional documentation

•such as diagrams and flowcharts

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

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

Removed p. 20

 Whether the PA-QSA prepares and submits a high-quality PA-DSS ROV to PCI SSC  If PCI SSC reviews the ROV more than once, providing comments back to the PA-QSA to address each time, this will increase the length of time.

Any review timeframes provided by a PA-QSA 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, the software 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 (if, for example, 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. 20 → 21

6. The ~~vendor‘s~~ executed ~~PA-DSS~~ VRA.

6. The Vendor’s executed VRA.

Modified p. 20 → 22

 How close is the application to being PA-DSS compliant at the start of the ~~review~~  Corrections to the ~~payment application~~ to achieve compliance will ~~increase the length of time.~~

 How close the application is to being PA-DSS compliant at the start of the Assessment  Corrections to the Payment Application to achieve compliance will delay validation.

Modified p. 20 → 22

 ~~How ready~~ the ~~payment application‘s~~ PA-DSS Implementation Guide is at the start of the ~~review~~  Extensive rewrites of the PA-DSS Implementation Guide will ~~increase the length of time.~~

 Whether the Payment Application‘s PA-DSS Implementation Guide meets all PA-DSS Requirements at the start of the Assessment  Extensive rewrites of the PA-DSS Implementation Guide will delay validation.

Modified p. 20 → 22

PCI SSC qualifies and provides required training for Payment Application Qualified Security ~~Assessors (PA-QSAs)~~ to assess and validate ~~payment applications~~ for PA-DSS compliance. In order to perform ~~PA- DSS assessments, a~~ PA-QSA must have been qualified by PCI SSC and remain in good standing as both a QSA and ~~PA-QSA,~~ and complete all required PA-QSA training. All recognized ~~PA-QSAs~~ are listed on the ~~PCI SSC website.~~ These are the only assessors recognized by PCI SSC as qualified to perform PA-DSS …

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 …

Modified p. 20 → 22

The prices and fees charged by ~~PA-QSAs~~ are not set by PCI SSC. These fees are negotiated between the PA-QSA and ~~their~~ customer. Before deciding on a ~~PA-QSA,~~ it is recommended that a prospective customer should check PCI SSC's list of recognized ~~PA-QSAs,~~ talk to several PA-QSA ~~firms,~~ and follow their own ~~vendor selection~~ processes.

The prices and fees charged by PA-QSA Companies are not set by PCI SSC. These fees are negotiated between the PA-QSA Company and its customer. Before deciding on a PA-QSA Company, it is recommended that a prospective customer should check PCI SSC's list of recognized PA-QSA Companies, talk to several PA-QSA Companies, and follow their own vendor-selection processes.

Modified p. 20 → 22

 Guidance on designing ~~payment applications~~ in accordance with PA-DSS  Review of a ~~software vendor‘s~~ software design, response to questions via e-mail or phone, and participation in conference calls to clarify requirements ~~ Guidance on preparing the PA-DSS Implementation Guide  Pre-assessment (―gap‖ analysis) services prior to beginning formal PA-DSS assessment~~

 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

Modified p. 21 → 23

It should be noted that a ROV ~~cannot~~ be reviewed by ~~the~~ PCI SSC without ~~a current PA-DSS~~ VRA on file from the relevant ~~vendor.~~

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.

Modified p. 21 → 23

So long as a current ~~PA-DSS~~ VRA is on file with the PCI SSC for the relevant ~~vendor,~~ it is not required to re-submit the ~~PA-DSS~~ VRA with each subsequent ~~ROV.~~

So long as an executed current VRA is on file with the PCI SSC for the relevant Vendor, it is not required to re-submit the same VRA with each subsequent ROV for the same Vendor.

Removed p. 22

Vendors are also required to pay a PA-DSS Payment Application Acceptance Fee (all PA-DSS Program Fees are posted on the PCI SSC website) to PCI SSC immediately prior to Acceptance of each new payment application. For each new payment application, the PA-DSS Payment Application Acceptance Fee will be invoiced immediately prior to Acceptance, and must be received by PCI SSC for the application to be Accepted and added to the PCI SSC‘s List of Validated Payment Applications. Upon Acceptance, the PCI SSC will sign and return a copy of the Attestation of Validation to both the vendor and the PA-QSA.

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

Modified p. 22 → 24

There are no annual recurring PCI SSC fees associated with the Acceptance of a PA-DSS Validated Payment Application. There are, however, PCI SSC fees associated with ~~vendor~~ updates to PA-DSS Validated Payment Applications. Please see the ~~section on Validation Maintenance Fees~~ for more information.

There are no annual recurring PCI SSC fees associated with the Acceptance of a PA-DSS Validated Payment Application. There are, however, PCI SSC fees associated with Vendor updates to PA-DSS Validated Payment Applications. Please see the Website for more information.

Modified p. 22 → 24

The ~~vendor~~ pays all PA- ~~QSA assessment~~ related fees directly to the PA- QSA (these fees are negotiated between the ~~vendor~~ and the ~~PA-QSA).~~

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

Removed p. 23

3. High-Impact Changes - are changes made to a listed payment application that affect the PA- DSS related functions of the payment application and have a high impact on the PA-DSS

Modified p. 23 → 25

This annual process has been adopted to encourage ~~software 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 …

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 …

Modified p. 23 → 25

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 ~~―Only acceptable~~ for ~~pre-existing deployments.‖~~ As there are no specific fees associated with Annual Revalidations, ~~the~~ PCI SSC will upon receipt of the

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 are no specific fees associated with Annual Revalidations, PCI SSC will upon receipt of the

Modified p. 23 → 25

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

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

Modified p. 23 → 25

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

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

Modified p. 23 → 25

1. ~~No-Impact~~ Changes are minor changes (either administrative or software) made to a listed ~~payment application~~ that have no impact on the PA-DSS ~~requirements.~~ In this case, for the new version to be listed, the ~~software vendor~~ documents the change for the ~~PA-QSA‘s~~ review•see ~~the No-Impact Changes section~~ for specifics. Examples of minor updates include, but are not limited to, corporate identity changes or software changes to a graphical user interface or to supporting modules that perform no ~~payment application~~ …

1. No Impact Changes are minor changes (either administrative or software) made to a listed Payment Application that have no impact on the PA-DSS Requirements. In this case, for the new version to be listed, the Vendor documents the change for the PA-QSA Company’s review•see Section 4.2.2, “No Impact Changes,” for specifics. Examples of minor updates include, but are not limited to, corporate identity changes or software changes to a graphical user interface or to supporting modules that perform no …

Modified p. 23 → 25

2. ~~Low-Impact~~ Changes are minor changes made to a listed ~~payment application~~ that touch upon PA-DSS related functions of the ~~payment application~~ and have limited impact on the PA-DSS ~~requirements.~~ In this case, for the new version to be accepted, the ~~software vendor~~ submits the new version of the ~~payment application~~ for a partial or ―delta‖ review

• see Low-Impact Changes section for specifics.

2. Low Impact Changes are minor changes made to a listed Payment Application that touch upon PA-DSS related functions of the Payment Application and have limited impact on the PA-DSS Requirements. In this case, for the new version to be accepted, the Vendor submits the new version of the Payment Application for a partial or “delta” review•see Section 4.2.3, “Low Impact Changes,” for specifics.

Removed p. 24

 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);

Modified p. 24 → 26

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,~~ preferably to the ~~PA- QSA~~ that originally reviewed the ~~payment application.~~

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.

Modified p. 24 → 26

The PA-QSA 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.~~

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.

Modified p. 24 → 26

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 revised, the ~~vendor~~ must submit proper change documentation to the PA-QSA to determine whether a full evaluation needs to be performed.

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 revised, the Vendor must submit proper change documentation to the PA-QSA Company to determine whether a full evaluation needs to be performed.

Modified p. 24 → 26

Minor Changes ~~(No-~~ Impact or Low Impact) are only permissible to previously listed ~~payment applications~~ that have yet to expire.

Minor Changes (No Impact or Low Impact) are only permissible to previously listed Payment Applications that have yet to expire.

Modified p. 24 → 26

The process flow for changes to listed applications is detailed in Figure 4.

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

Removed p. 25

 A high-level description of each change that has been made to the Validated Payment Application  Citations of:

 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  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:

 A description of the change;  Identification of the amended configuration item or items (system files, modules, etc.) that is/are impacted by the change;  A high-level assessment by the PA-QSA of the security impact of the change;  Identification of the PA-DSS requirements or test procedures that are impacted by the change;  Indication whether or not the impacted PA-DSS requirements necessitated an …

Removed p. 26

(i) The PA-QSA must so notify the software vendor; (ii) The vendor prepares and signs an Attestation of Validation, and sends it to the PA-QSA; (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; and (iv) PCI SSC will then review the Attestation of Validation and Vendor Change Analysis for quality assurance purposes.

 An invoice for the applicable No-Impact Change Fee will be issued to the vendor.

 Upon payment of the invoice to PCI SSC as described in Validation Maintenance Fees below, the PCI SSC will: (i) amend the List of PA-DSS Validated Payment Applications on the PCI SSC website accordingly with the new information and (ii) sign and return a copy of the PA-DSS Attestation of Validation to both the software vendor and the PA-QSA. The expiry …

Modified p. 26 → 28

 Payment Application Changes ~~• includes~~ revisions to previously listed ~~payment application,~~ but that revision is deemed to have no impact on PA-DSS ~~requirements.~~

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

Modified p. 26 → 28

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

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. 26 → 28

If the PA-QSA 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 in the Vendor Change Analysis by the Vendor has no impact on the PA-DSS related functions of the Payment Application:

Modified p. 26 → 28

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

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

Modified p. 26 → 30

If the PA-QSA does not agree with the ~~vendor~~ that the change, as documented in the Vendor Change Analysis, has no impact on the PA-DSS related functions of the ~~payment application,~~ the PA-QSA 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‘s~~ observations.

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.

Removed p. 27

(i) The PA-QSA must so notify the software vendor; (ii) The PA-QSA 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; (iii) The vendor prepares and signs an Attestation of Validation, and sends it to the PA-QSA; (iv) The PA-QSA 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; and

Modified p. 27 → 29

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

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

Modified p. 27 → 29

1. Inclusion of minor updates or patches to ~~validated~~ OS versions upon which the ~~payment application~~ was previously validated;

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

Modified p. 27 → 29

2. Inclusion of minor updates or patches to supported ~~3rd party~~ databases with which the ~~payment application~~ was previously validated;

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

Modified p. 27 → 29

3. Updates to reporting modules;

iii. Updates to reporting modules;

Modified p. 27 → 29

4. Additions or deletions of supported payment processors;

iv. Additions or deletions of supported payment processors;

Modified p. 27 → 29

5. Inclusion of minor updates or patches to supported middleware with which the ~~payment application~~ was previously validated; and

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

Modified p. 27 → 29

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

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

Modified p. 27 → 29

Except for the specific types of changes identified immediately above, all other changes that have an impact on PA-DSS related functions of a Validated Payment Application are deemed to be ~~High-Impact~~ Changes and must be assessed by a PA-QSA through a full review.

Except for the specific types of changes identified immediately above, all other changes that have an impact on PA-DSS related functions of a Validated Payment Application are deemed to be High Impact Changes and must be assessed by a PA-QSA Company through a full review.

Modified p. 27 → 29

In addition to the limitation detailed above, on the specific types of changes that may be considered by Vendors and ~~PA-QSAs~~ as ~~Low-Impact~~ Changes, there are critical requirements for the protection of cardholder data within PA-DSS that, if impacted by a change, are deemed to be ~~High-Impact~~ Changes and, accordingly, necessitate a full review of the amended ~~payment application.~~ The critical requirements of the PA-DSS that result in changes being automatically classified as ~~High-Impact~~ include the following areas:

In addition to the limitation detailed above, on the specific types of changes that may be considered by Vendors and PA-QSA Companies as Low Impact Changes, there are critical requirements for the protection of cardholder data within PA-DSS that, if impacted by a change, are deemed to be High Impact Changes and, accordingly, necessitate a full review of the amended Payment Application. The critical requirements of the PA-DSS that result in changes being automatically classified as High Impact include the …

Modified p. 27 → 29

 Sensitive Authentication Data;  Remote Access;  Default Passwords; and  Protection of Stored PAN.

 Sensitive Authentication Data;  Remote Access;  Default Passwords; and  Protection of Stored PAN.

Modified p. 27 → 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.

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.

Modified p. 27 → 29

If the PA-QSA 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‘s~~ review of the criteria above):

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

Removed p. 28

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 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‘s observations.

 An invoice for the Low-Impact Change Fee will be issued to the vendor.

 Upon payment of the invoice to PCI SSC as described in Validation Maintenance Fees below, PCI SSC will: (i) amend the List of PA-DSS Validated Payment Applications on the PCI SSC website accordingly with the new information; and (ii) sign and return a copy of the Attestation of Validation to both the software vendor and the PA-QSA. The expiry date of this newly listed application and version number will be the same as that of the …

Modified p. 28 → 30

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

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

Modified p. 28 → 30

For quality issues associated any aspect of the submission, PCI SSC communicates those issues to the ~~PA-QSA,~~ and those issues are resolved according to the process depicted in Figure 2. 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 ~~Low-Impact~~ Change by the PA-QSA 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 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.

Modified p. 28 → 31

Note that if the ~~vendor chooses to continue selling the application, once the~~ application successfully ~~passes through~~ 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 ~~expiration~~ date.

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.

Modified p. 28 → 31

The process flow for renewing expired applications is detailed in Figure 4.

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

Removed p. 29

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

Removed p. 29

If a listed payment application is revised, but the revision is minor and does not impact PA-DSS requirements, the vendor is required to pay the applicable No-Impact Change Fee (all PA-DSS Program Fees are posted on the PCI SSC website) to PCI SSC immediately prior to Acceptance of each such change.

If a listed payment application is revised, but the revision is minor with only a low impact on PA-DSS requirements, the vendor is required to pay the applicable Low-Impact Change Fee (all PA-DSS Program Fees are posted on the PCI SSC website) to PCI SSC immediately prior to Acceptance of each such change.

Note that all types of Minor Changes will be added as a child of the parent application already on the List of Validated Payment Applications For any Minor Change to a PA-DSS Validated Payment Application, the applicable fee will be invoiced immediately prior to Acceptance, and must be …

Modified p. 29 → 31

The ~~vendor~~ pays all ~~PA- QSA assessment~~ related fees directly to the ~~PA- QSA~~ (these fees are negotiated between the ~~vendor~~ and the ~~PA-QSA).~~

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. 29 → 31

PCI SSC will invoice the ~~vendor~~ for all Validation Maintenance Fees and the ~~vendor~~ will pay these fees directly to PCI SSC.

PCI SSC will invoice the Vendor for all Validation Maintenance Fees and the Vendor will pay these fees directly to PCI SSC.

Modified p. 29 → 32

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, may have, or will have.

Modified p. 29 → 32

Notification must take place no later than 24 hours after the ~~vendor~~ first ~~discovers~~ the Security Issue.

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

Removed p. 30

 The number of compromised accounts (if known);  Any reports detailing the security breach or compromise (Do not include any compromised entities‘ names);  Any reports or evaluations performed to investigate the security breach or compromise (Do not include any compromised entities‘ names); and  The exact nature of the payment application‘s vulnerability.

PCI SSC, as provided in the PA-DSS VRA, may share certain information as required to support or enable an evaluation of the Security Issue to be performed to mitigate or prevent further security breaches or compromises.

 Attempt to obtain the forensics report to evaluate exactly how the Security Issue occurred.

 Support the vendor‘s efforts to 1) correct any Security Issues, and 2) produce a guideline document to be issued to that vendor‘s customers, informing them of any potential vulnerability and detailing what actions should be taken in order to mitigate or prevent further Security Issues.

 Support and/or …

Modified p. 30 → 32

 Notify ~~all payment brands~~ that a Security Issue has occurred.

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

Modified p. 30 → 32

 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 of the application in question about the Security Issue and, where possible, share information relating to the Security Issue.

Modified p. 30 → 32

 Support the ~~vendor‘s~~ efforts to ~~try and~~ mitigate or prevent further Security Issues.

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

Modified p. 30 → 32

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

Removed p. 31

PCI SSC receives the ROV and reviews it 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), and the vendor has paid the applicable Acceptance or Minor Change fee for the corresponding application, then PCI SSC sends a PA-DSS Attestation of Validation, countersigned by the PCI SSC, to both the vendor and the PA-QSA, and the adds the application to the List of Validated Payment Applications. For quality issues associated with ROVs, PCI SSC communicates those issues with the PA-QSA. It is then the responsibility of the PA-QSA 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-QSAs decisions. However, if the issues require that the PA- QSA perform more testing, then the PA-QSA …

Modified p. 31 → 33

The process ~~flow~~ for ROV Acceptance and ROV Review Process are detailed in Figure ~~1 and 2 respectively.~~

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

Modified p. 31 → 33

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

Removed p. 32

 Vendor Release Agreement (VRA) signed by the Vendor  ROVs completed in accordance with the ROV Reporting Instructions which contains the following information:

 PA-QSA‘s Change Impact document; 

• Updated PA-DSS Implementation Guide for the assessed payment application; 

• Updated ROV which contains the following:

Modified p. 32 → 34

 Executive Summary (Includes Reseller/Integrator List)  Requirements

• Testing Procedures  Appendix B

• Laboratory ~~Confirmation ~~ Attestation of Validation (AOV) signed by both the Vendor and the PA-QSA 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 must submit ROV versions that include tracking of cumulative changes within the document.

 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 …

Modified p. 32 → 34

 Vendor Change Analysis document;  Updated PA-DSS Implementation Guide for the assessed ~~payment application;~~ and  Attestation of Validation signed by both the Vendor and the ~~PA-QSA.~~

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

Modified p. 32 → 34

 Summary of requirements assessed and any resulting changes;  Updated Executive Summary and Requirement with edits clearly identified (i.e. ~~―redlined‖);~~ and  Confirmation of Testing Laboratory ~~(PA-DSS,~~ Appendix B); and

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

 If no issues or questions to the PA-QSA are identified, PCI SSC shall bill the vendor for the applicable Acceptance or Minor Update fee. Once the fee is received, PCI SSC will issue the Attestation of Validation, countersigned by PCI SSC, post the payment application and vendor‘s information to the PCI SSC website, and the application is thereby Accepted.

 ROVs that have been returned to the PA-QSA for correction must be resubmitted to the PCI SSC within 30 days. If this is not possible, the PA-QSA must inform the PCI SSC of the timeline for response. Lack of response on ROVs returned to the PA-QSA 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 submission.

Modified p. 33 → 35

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 will base Acceptance of a Payment Application primarily on the results documented in the ROV. Upon receipt of the ROV, the following will apply:

Modified p. 33 → 35

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

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

Modified p. 33 → 35

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

 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

Modified p. 33 → 35

• revised ROV or response ~~(―Revised ROV‖)~~ from the ~~PA-QSA.~~ 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 until receipt of an 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 until receipt of an acceptable

Modified p. 33 → 35

 Should additional questions or issues arise, the cycle repeats until a satisfactory Revised ROV is received, at which time, ~~subject to receipt of the applicable Acceptance or Minor Change fee,~~ PCI SSC will issue the Attestation of Validation, post the information to the PCI SSC website, and the application is thereby Accepted. Additional issues or questions may be raised at any time prior to Acceptance.

 Should additional questions or issues arise, the cycle repeats until a satisfactory Revised ROV is received, at which time, PCI SSC will issue the Attestation of Validation, post the information to the PCI SSC website, and the application is thereby Accepted. Additional issues or questions may be raised at any time prior to Acceptance.

Modified p. 33 → 35

For reports related to minor updates to existing listed application versions, based on the ~~vendor‘s~~ Attestation of Validation, the above PA-DSS ROV Acceptance process is the same, and PCI SSC shall issue a

For reports related to minor updates to existing listed application versions, based on the Vendor’s Attestation of Validation, the above PA-DSS ROV Acceptance process is the same, and PCI SSC shall issue a

Modified p. 33 → 35

The listing on the List of Validated Payment Applications will contain, at minimum, the information specified below. Each characteristic is detailed in ~~―Appendix~~ A: ~~Application~~ Elements for the Attestation of Validation and ~~the~~ List of Validated Payment Applications.‖  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

The listing on the List of Validated Payment Applications will contain, at minimum, the information specified below. Each characteristic is detailed in Appendix A: Elements for the Attestation of Validation and List of Validated Payment Applications.

Modified p. 33 → 35

PCI SSC will not grant any ~~―partial approvals‖~~ based upon the ability of a ~~payment application~~ to meet some

•but not all

•of the requirements.

PCI SSC will not grant any “partial approvals” based upon the ability of a Payment Application to meet some

•but not all

•of the requirements.

Removed p. 34

PCI SSC reviews ROVs and PA-QSA performance for quality assurance purposes. As stated in the QSA Validation Requirements and the PA-QSA Agreement, PA-QSAs are required to meet all quality assurance standards set by PCI SSC. The various phases of the QA program are described below.

Removed p. 34

 The payment application is determined to be ineligible for validation under the PA-DSS Program and the ROV will not be Accepted; or  The payment application is determined to be eligible for Acceptance under the PA-DSS Program and therefore the ROV will be reviewed and determined to either:

 Meet the requirements of the PA-DSS Program; or  Not meet the requirements of the PA-DSS Program in which case all identified issues with the ROV must be resolved before the ROV review can be completed.

Removed p. 34

PCI SSC places emphasis on ―Critical Test Procedures (i.e. specific ROV testing procedures) that are considered critical to the protection of cardholder data in PA-DSS compliant payment applications. These areas have historically been targeted by attackers attempting to compromise payment applications. Critical Test Procedures cover areas such as; Sensitive Authentication Data, Remote Access, Default Passwords, Protection of Stored PAN, Logging and Wireless.

If any Critical Test Procedure is not properly addressed by the PA-QSA, the ROV under review will be returned for correction.

Details of the specific PA-DSS requirements that are to be considered as Critical Test Procedures are maintained in the ROV Reporting Instructions.

Modified p. 34 → 36

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

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

Removed p. 35

Each calendar year all PA-QSA organizations submitting reports to the SSC are subject to an audit of their submissions.

The audit process is a more formalized method of review. The normal review practice (pro forma) is to evaluate the submission for completeness. The audit process however, is a more robust evaluation of the PA-QSA work. The audit will evaluate the work product of the PA-QSA for a set of reports. The audit process will encompass the report submissions, along with an evaluation of work papers and the PA- QSA‘s internal QA manual. This will help to ensure the organization‘s internal QA processes are being followed. Additionally, the PA-DSS Implementation Guide and/or other supporting documents pertaining to the payment application under audit will be reviewed. Finally, the PCI SSC may at its discretion conduct an onsite audit.

Removed p. 35

These levels are not progressive, for example it is possible for a PA-QSA Company to move from ―PA- QSA In Good Standing‖ to ―Remediation‖ without being through ―Oversight.‖ A PA-QSA Company may even move directly from ―PA-QSA In Good Standing‖ to ―Revocation‖ if issues found with work quality are significant enough to warrant this.

At any of these status levels, PCI SSC may require an onsite visit with the PA-QSA Company to audit their internal QA program, at the expense of the PA-QSA Company.

The PA-QSA quality status levels used by the Council are as follows:

Modified p. 35 → 37

~~Note that if~~ a ~~payment application~~ included on the PCI SSC List of PA-DSS Validated Payment Applications is compromised due to PA-QSA error, then that PA-QSA may immediately be placed into ~~Remediation.~~

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.

Removed p. 36

There are no external indications on the PCI SSC website that a PA-QSA Company is in New PA-QSA status.

Removed p. 36

Additional detail is communicated to the PA-QSA Company as to what corrective actions need to be taken to improve the overall quality of submissions. The PA-QSA is required to develop and submit an Oversight action plan to the Council. This document will include information on ways the PA-QSA intends to rectify outstanding quality issues. Lessons learned throughout the Oversight program should be incorporated into the PA-QSAs future work product thereby showing significant improvement in quality.

Oversight should be completed within 90 days. Oversight may be extended only if the PA-QSA has been able to demonstrate positive progress. Failure to demonstrate improved quality may lead to remediation or revocation.

PCI SSC will charge a Detailed ROV Review Fee (see Appendix B) for all reports submitted and resubmitted during oversight.

There are no external indications on the PCI SSC website that a PA-QSA Company is in Oversight status.

Removed p. 37

If the PA-QSA Company makes sufficient improvement during the Remediation process their status will be altered to Oversight or ―PA-QSA In Good Standing.‖ If the PA-QSA Company fails to meet quality standards during remediation, then the PA-QSA enters into Revocation.

Remediation is expected to be completed within 90 days. In the event that the goals of the Remediation program cannot be achieved within this period, Remediation may be extended once by an additional 90 days, only if the PA-QSA has been able to demonstrate positive progress to the satisfaction of the PCI SSC.

PCI SSC will charge a PA-QSA Remediation Program Fee for entry into the Remediation Program and a Detailed ROV Review Fee for all reports submitted and resubmitted during Remediation. See Appendix B for details of all applicable fees.

The PCI SSC website will be updated to show that the PA-QSA Company is in Remediation status.

Removed p. 39

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

PCI SSC Acceptance signifies that (i) a PA-QSA has determined that 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 PCI SSC‘s QA review, but such Acceptance does not under any circumstances include or imply any endorsement or warranty by PCI SSC or any payment brand regarding the payment application vendor or the functionality, quality, or performance of the payment application or any other product or service. PCI SSC does not warrant any products or services provided by third parties. PCI SSC Acceptance does not, under any circumstances, include or imply any product warranties from PCI SSC, including, without limitation, any implied warranties of merchantability, fitness for purpose or …

Modified p. 39

• even if the different ~~payment application~~ or version (the ~~―Alternate Version‖)~~ conforms to the basic product description of the Accepted Version

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

Modified p. 39

No ~~vendor~~ or other third party may refer to a ~~payment application~~ as ~~―PCI Approved,‖~~ or ~~―PCI~~ SSC ~~Approved‖~~ 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 …

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 …

Modified p. 40

A.2 Payment Application Identifier The Payment Application Identifier is used by PCI SSC to denote relevant information for each validated ~~payment application,~~ consisting of the following fields (fields are explained in detail below):

A.2 Payment Application Identifier The Payment Application Identifier is used by PCI SSC to denote relevant information for each validated Payment Application, consisting of the following fields (fields are explained in detail below):

Modified p. 40

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

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:

Modified p. 40

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

Modified p. 40

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.

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

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.

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.

Modified p. 41

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

Modified p. 42

 Target Market, if applicable The Target Market denotes a target market for the ~~payment application.~~ For example, the target market may be one of the following:

 Target Market, if applicable The Target Market denotes a target market for the Payment Application. For example, the target market may be one of the following:

Modified p. 42

~~ Retail~~  Processors ~~ Gas/oil~~  E-commerce  Small/medium merchants

 Processors  E-commerce  Small/medium merchants

Modified p. 42

Note: This is intended to indicate if the ~~payment application~~ is designed specifically for a certain market, not for ~~software vendor~~ marketing purposes.

Note: This is intended to indicate if the Payment Application is designed specifically for a certain market, not for Vendor marketing purposes.

Modified p. 42

~~ Reference Number~~ 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. 42

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

Removed p. 43

Please see table under Expiry Date below for examples.

A.8 Revalidation Date The Revalidation Date is used by PCI SSC to indicate when the software vendor‘s annual Attestation of Validation is due. The Annual Revalidation is part of the Attestation of Validation form.

Modified p. 43

As much as any ~~payment application~~ may have required dependencies, some of the Payment Application Types defined above (for example POS Face-to-Face/POI and Payment Module) are expected to have defined dependencies.

As much as any Payment Application may have required dependencies, some of the Payment Application Types defined above (for example POS Face-to-Face/POI and Payment Module) are expected to have defined dependencies.

Modified p. 43

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

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

Modified p. 43

 Acceptable for ~~new deployment~~

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

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.

Modified p. 43

~~ Only acceptable~~ 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. ~~Validated~~ Payment Applications that have expired should ~~not~~ be ~~purchased for new implementations but may continue~~ to ~~be used on systems where they were …~~

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.

Modified p. 43

These deployment notes are used by the Council to note the status of a Validated Payment Application is relation to its Expiry Date. ~~Please refer to any specific brand requirements~~ for ~~usage of Validated Payment Applications.~~

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.

Modified p. 44

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

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.

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

Note: For future consideration While certified ~~payment application~~ builds are not a requirement at this time, we encourage ~~software 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-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.

Modified p. 45

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 ~~software 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 …

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 …

Document Comparison

Content Changes