Document Diff - PCI Watch

Added p. 2

January 2026 2.0 This revision is a new Program Guide to support v2.x of the PCI Secure Software Standard. To assist in understanding the changes from v1.x, the following high-level change information is provided: Overall restructure of the entire document Significant updates throughout entire document, with notable sections/context being: - Updated Terminology - Updated Related Publications - Updated/new diagrams throughout - Program Eligibility - Assessment Scope - New Section 1.6 Technical FAQs - Changes (Refer to new Section 5 and Delta Changes) + Low and High Impact Change context removed and replaced with Tier 1 and Tier 2 Delta Change context. Wildcard context added. - Lifecycle (Refer to new Section 6) + New context of Administrative Expiry and Reassessment vs. New Assessment - New Section 8 re Security Issue Notification - Revised Appendix A, of note: + Removal of Tested Platforms + Revised context for Required Dependencies + Revised context …

Added p. 5

Term Definition Accepted, Acceptance A Validated Secure Software Product is deemed to have been “Accepted” (and “Acceptance” is deemed to have occurred), so long as such Acceptance has not been revoked, suspended, withdrawn, or terminated, when PCI SSC has: (i) received the corresponding Validated Secure Software Product submission in the Portal, including the completed ROV, AOV, and all other documentation and information as required by the PCI Secure Software Standard and Program Requirements, from the Secure Software Assessor and SSF Assessor Company qualified to perform the Secure Software Assessment; (ii) received the corresponding Secure Software Program fee for the submission; and (iii) confirmed that:

- the Validated Secure Software Product submission to the Portal is complete (all applicable documents completed appropriately/sufficiently), and - the Secure Software Assessor properly determined that the Software Product satisfies the PCI Secure Software Standard and Program Requirements for a Validated Secure Software Product.

Administrative Change A change …

Added p. 6

- Administrative Change, or a - Delta Change. A New Assessment and a Reassessment both require a Full Assessment. See also: New Assessment, Reassessment.

List of Validated Secure Software The Council’s authoritative list of Validated Secure Software Products appearing on the Website. This list also identifies Expired Secure Software Products.

Listed A Validated Secure Software Product published on the Website after corresponding Acceptance has occurred, so long as such Acceptance has not been revoked, suspended, withdrawn, terminated, or expired and such product is not an Expired Secure Software Product. See also: List of Validated Secure Software, Acceptance Listing A unique record for a Validated Secure Software Product appearing on the List of Validated Secure Software after Acceptance has occurred that contains information as described in Appendix A herein.

New Assessment A Full Assessment of an eligible Software Product where that Software Product:

- Is not already Listed and Validated, or - Is an Expired …

Added p. 7

Secure SLC Standard The then-current version of (or successor document to) the Payment Card Industry (PCI) Secure Software Lifecycle Standard as from time to time amended and made available on the Website.

Secure Software Program (Program) The PCI SSC program for Secure Software Products whereby an entity can choose to have their Software Product validated by a qualified Secure Software Assessor and subsequently submitted to PCI SSC for consideration of being Accepted and Listed for purposes of demonstrating compliance with the PCI Secure Software Standard and Program Requirements.

Secure Software Program Documents (Program Documents) The Secure Software Standard and Secure Software Program Guide, all written agreements executed between PCI SSC and Secure Software Vendors, SSF Assessor Companies, or Secure Software Assessors in connection with the Secure Software Program, all other materials, requirements, obligations, policies, and procedures published from time to time by PCI SSC on the Website or elsewhere relating to the …

Added p. 9

ii. Related Publications This Program Guide is intended for use in conjunction with the latest versions of (or successor documents to) the following PCI SSC publications, each as available on the Website.

Note: The ‘PCI Software Security Framework

• Glossary of Terms, Abbreviations, and Acronyms’ does not apply to the PCI Secure Software Standard v2.x, this Program Guide, or to any related Program Documents.

Payment Card Industry (PCI) Software Security Framework - Secure Software Standard (PCI Secure Software Standard, Secure Software Standard, the Standard) Defines a baseline set of specific security requirements and test requirements against which an eligible Software Product must be successfully validated to be qualified by PCI SSC as a Validated Secure Software Product.

Payment Card Industry (PCI) Software Security Framework - Secure Software Lifecycle Standard (PCI Secure SLC Standard, SSLC Standard) Defines a baseline set of specific security requirements and test requirements against which vendors must be successfully assessed to …

Added p. 11

§ The security requirements and test requirements (sourced from the Standard) for validating Software Products for Program purposes can be found in the corresponding PCI Secure Software Report on Validation (ROV) template found on the Website.

§ For each Validated Secure Software Product to be considered for Acceptance by PCI SSC and subsequently Listed on the Website as a Validated Secure Software Product, the Vendor must also submit an Attestation of Validation (AOV), associated fees per the Fee Schedule, Vendor Release Agreement (VRA), and all other supporting documents and information as applicable and described herein as part of the Program.

§ Listed and Validated Secure Software Products are subject to the Annual Vendor Attestation process. Refer to Section 6.1 Annual Attestation Process.

§ Changes to a Listed and Validated Secure Software Product may require a Delta Change. Refer to Section 5.2 Delta Changes.

§ A Listed and Validated Secure Software Product is eligible for …

Added p. 12

PCI SSC may provide interim updates to the PCI community through a variety of means, including required training, bulletins and newsletters, frequently asked questions (which may include technical FAQs), the Website, and other communication methods.

If changes to the Secure Software Program are required, PCI SSC endeavors to work closely with stakeholders to help minimize the impact.

Added p. 13

Note: The decision to undergo an assessment of a Software Product in pursuit of Acceptance by PCI SSC and subsequent Listing of the Validated Secure Software Product on the Website is a business decision of the Software Vendor.

Software Vendors (Vendors) seeking Acceptance and subsequent Listing of their Validated Secure Software Product as part of the Program are entities that are responsible for:

§ Providing access to their Software Product and supporting documentation to an SSF Assessor Company for validation; and § Ensuring the Software Products submitted for validation under the Program satisfy all applicable requirements of the Standard and Program; and § Complying with the VRA, including the adoption and implementation of Vulnerability Handling Policies (defined in the VRA) consistent with industry best practices; and § Authorizing the SSF Assessor Company to submit the resulting ROV, an AOV, and all other required information and documentation for the submission to PCI SSC; …

Added p. 13

§ Performing Secure Software Assessments in accordance with the Standard, the Program, the SSF Qualification Requirements, and the SSF Agreement; § Documenting each Secure Software Assessment using the available and current ROV Template in unmodified form; § Providing adequate documentation within the completed ROV to demonstrate the Software Product is in accordance with the Standard and Program;

Added p. 14

§ Selecting a Validated Secure Software Product from the List of Validated Secure Software on the Website; § Configuring and maintaining the Validated Secure Software Product according to the associated implementation guidance provided by the Vendor

Note: PCI Security Standards Council (PCI SSC) does not manage compliance programs and does not impose any consequences for non-compliance. Whether an entity is required to comply with or validate compliance to a PCI SSC standard is at the discretion of organizations that manage compliance programs, such as a Payment Brand, acquirer, or other entity.

§ Hosts the List of Validated Secure Software on the Website; § Provides training for and qualifies SSF Assessor Companies and Secure Software Assessors to perform Secure Software Assessments; § Lists SSF Assessor Companies on the Website; § Maintains and updates the Standard and Program, and related documentation according to a standards lifecycle management process; and § Reviews all Program submissions …

Added p. 15

The Standard and Program provide support for a broad range of software types, technologies, implementations, and development methodologies, in part due to the objective nature of the associated security requirements and the flexibility of the testing requirements as part of the validation process.

Note: Only eligible Software Products validated by a Secure Software Assessor can be submitted to PCI SSC and considered for Acceptance and Listing as a Validated Secure Software Product as per the Standard and Program.

Added p. 15

§ Core

• All Software: Minimum baseline of security objectives and security requirements that apply to all software that satisfies the definition of Sensitive Assets. All software assessed to the Standard is required to be assessed to this section.

§ Modules: Supporting sets of requirements that are in addition to the Core

• All Software requirements. Module requirements do not replace or supersede any Core

• All Software requirements, and vice-versa. PCI SSC may add, amend, or otherwise change modules based on updates to the Standard.

Added p. 16

The addendum must be completed for each Assessment in which an on-site activity is performed remotely that the Secure Software Assessor determines has the potential to warrant additional consideration to achieve an equivalent confidence level.

One of the most relevant examples is a physical in-person inspection of a physical environment, or in- person observation of processes being conducted within a physical environment. Remote methods in this context warrant the use of the addendum.

However, the following activities in and of themselves do not necessarily warrant the use of the addendum, unless the Secure Software Assessor determines the activity has the potential to warrant additional consideration to achieve an equivalent confidence level as stated prior:

§ Documentation review § Vendor personnel interviews § Testing software in an appropriate assessor company testing environment 4 Overview of the Validation Processes The following sections provide a general overview of the validation processes for Software Products. A general …

Added p. 17

§ Thoroughly review the latest PCI Secure Software Standard (the Standard), the PCI Secure Software Standard

• Sensitive Asset Identification, associated Secure Software Technical FAQs and this Program Guide, all available on the Website.

§ Determine if the software intended to be assessed is eligible as a Software Product that can be validated as per the Program. Refer, in part, to Section 3 Secure Software Assessment Considerations.

§ Determine the readiness of the Software Product to satisfy the Standard and Program Requirements. This may include the following:

• Perform a gap analysis between the Software Product and the Standard’s security objectives and security requirements;

• Remediate identified gaps; and

• If desired, an SSF Assessor Company may perform a pre-assessment or gap analysis of a Vendor’s Software Product to help identify deficiencies that require remediation.

- Ensure all the required documentation for the Assessment is accurate and complete.

Added p. 17

Note: The Software Vendor does not submit any documentation directly to PCI SSC as part of a Software Assessment, with exception being the VRA, and under defined circumstances for Tier 1 Delta Change submissions by SSLC-Qualified Vendors.

§ The degree that the Software Product satisfies the Standard and Program Requirements at the start of the Secure Software Assessment; Corrections to the Software Product, including required documentation, to remediate gaps will delay the Assessment and validation.

§ The scope of the Secure Software Assessment and validation effort. E.g., based on the size/complexity of the software, or the applicability of modules.

§ The greater the scope of the Secure Software Assessment, the greater the Assessment and validation time, as well as the submission review time.

Any Assessment timeframes provided by PCI SSC or an SSF Assessor Company should be considered estimates. Issues found during the review or Acceptance process, discussions required between the Secure Software Assessor, …

Added p. 19

Note: When considering other services with an SSF Assessor Company, care must be taken by both the Vendor and the SSF Assessor Company to ensure that the SSF Assessor Company maintains all independence requirements as set forth in the SSF Qualification Requirements

• for example, that a SSF Assessor Company does not, as part of the Secure Software Assessment, assess its own work product. Conflicts of interest may result in a Vendor’s Secure Software Assessment being rejected by PCI SSC.

Added p. 19

§ If PCI SSC does not have a copy of the Vendor’s signed, then-current VRA on file, the SSF Assessor Company must provide such VRA to PCI SSC.

§ If PCI SSC does have a copy of the Vendor’s signed, then-current VRA on file, the SSF Assessor Company is not required to re-submit the same VRA to PCI SSC at that time.

Generally, the Vendor provides its signed VRA to the SSF Assessor Company, along with access to their Software Product and other documents and materials, at the beginning of the applicable assessment and validation process.

§ Covers confidentiality issues; § Covers the Vendor’s agreement to Secure Software Program Requirements, policies, and procedures; § Gives permission to the Vendor’s chosen SSF Assessor Company to release the completed ROV and related materials to PCI SSC for review; and § Requires Vendors to adopt and comply with industry standard Vulnerability Handling Policies.

Note: A submission will …

Added p. 19

Restricted access to the Portal is granted to all Vendor’s with a Listed and Validated Secure Software Product. This restricted access allows:

Added p. 20

§ SSLC-Qualified Vendors to submit eligible Tier 1 Delta Change submissions.

Note: Vendor use of the Portal is subject to payment of applicable Program fees specified in the Fee Schedule for the submission type or activity being performed.

Added p. 20

PCI SSC will pre-screen Portal submissions to ensure that all required documentation has been included and the submission requirements per the Program are satisfied.

There must be consistency between the information provided in the Portal and the submitted documents. Inconsistencies may result in delays to the submission review process by PCI SSC, or potential rejection of the submission if the inconsistencies cannot be resolved, either entirely or in a timely manner.

Added p. 20

• Changes are permissible only for Listed and Validated Secure Software Products.

• Any change to a Listed and Validated Secure Software Product that is not an Administrative Change and not a Delta Change is accounted for by the Vendor as part of the Annual Vendor Attestation process.

• Administrative Changes and Delta Changes do not have any impact on Annual Vendor Attestation dates or Reassessment dates of Listed Secure Software Products.

• Changes are not permissible on Expired Secure Software Products.

Added p. 20

• The Change Impact Template in the form provided on the Website must be used to document Administrative Changes and be provided via the Portal as part of the Administrative Change submission. An AOV in the form provided on the Website is also required.

• All Vendors with Listed and Validated Secure Software Products are eligible to self-submit Administrative Changes using the Portal. They can also leverage a Secure Software Assessor to submit it on their behalf. In all cases the Program Requirements must be satisfied and all applicable fees per the Fee Schedule on the Website apply.

• Administrative Changes are not permitted on Expired Secure Software Products.

An Administrative Change is used to update the following information on a Listed and Validated Secure Software Product:

Added p. 21

6) Update the Validated Secure Software Product Listing details accordingly based on the Administrative Change submission; and 7) Sign and return a copy of the corresponding AOV to the Vendor (and the SSF Assessor Company, if applicable).

An Administrative Change does not change the associated Annual Attestation dates or Reassessment date.

• The assessment of Delta Changes to a Listed and Validated Secure Software Product must be performed using the same major version of the PCI Secure Software Standard and Program Requirements as were used for the Full Assessment.

• The Change Impact Template must be used to document Delta Changes and be provided via the Portal as part of the Delta Change submission.

• Delta Changes are not permitted on Expired Secure Software Products.

Delta Changes are generally security-impacting changes (not Administrative Changes) made to a Listed and Validated Secure Software Product as defined and accounted for in the Change Impact Template that affect …

Added p. 23

Figure 2: Delta Change Determination 5.2.1 Delta Change Submission Process Overview The Vendor, or as required, the Vendor and the SSF Assessor Company, prepare and complete the Change Impact Template. For Delta Changes requiring an SSF Assessor Company, it is recommended that the Vendor submit the Delta Change request to the same SSF Assessor Company used for the last Full Assessment of the Listed and Validated Secure Software Product.

For changes eligible as a Delta Change under the Program:

1) The Vendor completes a new VRA, if applicable; 2) The Vendor, or the Vendor and SSF Assessor Company where required, determine if the changes qualify as a Tier 1 or Tier 2 Delta Change and complete the Change Impact Template for the Listed and Validated Secure Software Product, including all required [re]testing and [re]validation; 3) Additional documents, such as a redlined ROV, are completed as instructed in and required by the Change …

Added p. 24

8) Amend the Validated Secure Software Product Listing details accordingly based on the Accepted Delta Change submission; and 9) Sign and return a copy of the corresponding AOV to the Vendor (and the SSF Assessor Company as applicable). A Delta Change does not change the associated Annual Attestation dates or the Reassessment date. PCI SSC reserves the right to reject any submission if it determines that a change described therein and purported to be an eligible Delta Change by the SSF Assessor Company and/or the Vendor is ineligible for a Delta Change.

Added p. 24

Note: Wildcards may only be substituted for elements of the version number that represent non- security-impacting changes. The use of wildcards for any change that has an impact on security, or any PCI Secure Software Standard requirement, is prohibited.

Only those Validated Secure Software Products that have had the Vendor’s wildcard versioning methodology for that Software Product validated to the PCI Secure Software Standard and Program Requirements by an SSF Assessor Company are eligible for wildcard usage and inclusion of the version number on the Website with wildcards.

Validated Secure Software Product changes within the scope and allowance of wildcard usage are not required to be reported to PCI SSC; therefore, any such changes will not result in an update to the Validated Secure Software Product Listing on the Website. Refer to Appendix B for additional information regarding the use of wildcards.

Added p. 24

Once Listed, a Validated Secure Software Product is required to satisfy the Annual Vendor Attestation process at year 1 and year 2 based on the date of the most recent Acceptance.

At the end of the 3-year lifecycle, Vendors have the option of undergoing a Reassessment as described herein to renew the Listing for their Validated Secure Software Product.

Figure 3: Listed and Validated Secure Software Product 3-Year Lifecycle 6.1 Annual Attestation Process The Annual Vendor Attestation (Annual Attestation) process requires the Vendor to attest to and account for their Listed and Validated Secure Software Product continuing to adhere to the PCI Secure Software Standard (the Standard) and Program Requirements via their submittal of an AOV.

The first Annual Attestation is required one calendar year after the most recent date of Acceptance based on the last Full Assessment. If the Vendor satisfied all applicable Program Requirements for the first Annual Attestation, then the …

Added p. 27

§ If the Vendor satisfies the Annual Attestation requirements of the Program and the AOV is received by PCI SSC within the 45-day Administrative Expiry Period, PCI SSC will, upon Acceptance, remove the orange status from the Validated Secure Software Product Listing.

Added p. 27

§ An Expired Secure Software Product is not eligible for Reassessment. To reinstate a Listing, a New Assessment of the Software Product is required.

Added p. 27

As a Listed and Validated Secure Software Product approaches its 3-year Listing Reassessment date, PCI SSC will provide a courtesy notification to the Vendor of the pending Listing expiration. However, it is the sole responsibility of the Vendor to initiate a Reassessment of their Validated Secure Software Product regardless of any such courtesy reminder(s). The Vendor can choose to perform a Reassessment, otherwise, the Validated Secure Software Product will become an Expired Secure Software Product, which is no longer considered as being validated.

Figure 6: Reassessment Timeline and Listing Expiry 6.2.1 Listing Expiry A Listed and Validated Secure Software Product for which a new Acceptance based on a Full Assessment has not occurred on or before its applicable 3-year Listing Reassessment date will immediately appear in orange for up to 45 consecutive calendar days.

If a new Acceptance has not occurred within the 45 consecutive calendar days following the Listed and Validated …

Added p. 28

Program fees must be received by PCI SSC for a submission to be reviewed and Accepted (provided the submission satisfies the PCI Secure Software Standard and Program Requirements).

There is a Program ‘late’ fee associated with the processing of AOVs received as part of the Annual Attestation process for a Listed and Validated Secure Software Product if the AOV is not received by PCI SSC on or before the respective Annual Vendor Attestation date.

Added p. 28

§ The name, PCI SSC approval (Reference) number, and any other relevant identifiers of each of the Vendor’s Product(s) affected by the Security Issue; § 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); and § Assurance that the Vendor is following its Vulnerability Handling Policies

Added p. 29

§ Notify Participating Payment Brands that a Security Issue has occurred § Request a copy of the latest version of the Vendor’s Vulnerability Handling Policies § Communicate with the Vendor about the Security Issue and, where possible and permitted, share information relating to the Security Issue § Support the Vendor’s efforts to mitigate or prevent further Security Issues § Support the Vendor’s efforts to correct any Security Issues § Work with the Vendor to communicate and cooperate with appropriate law enforcement agencies to help mitigate or prevent further Security Issues 8.5 Withdrawal of Acceptance

PCI SSC reserves the right to suspend, withdraw, revoke, cancel or place conditions upon its Acceptance of (and accordingly, remove from the List of Validated Secure Software) any Software Product in accordance with the VRA, in instances including but not limited to, if PCI SSC reasonably determines that (a) the Software Product does not provide sufficient protection …

Added p. 30

A.2 Validated Secure Software Product Name The name provided by the Vendor and the name by which the Validated Secure Software Product is known. The name cannot contain any variable or special characters.

A.3 Validated Secure Software Product Version Number Represents the specific version number of the Validated Secure Software Product. The format of the version number:

- Is set by the Vendor, in accordance with Program Requirements; - May consist of a combination of alphanumeric characters; and - Must be consistent with the Vendor’s published versioning methodology as documented in the implementation guidance.

A.4 Listing Reference Number

PCI SSC assigns the unique Reference Number upon Acceptance of the Validated Secure Software Product as a result of a Full Assessment; An example reference number is 2025-xxxxx.yyy, consisting of the following:

Field Format Year of listing 4 digits + hyphen Vendor Identifier 5 digits + period This value uniquely identifies the Vendor.

Validated Secure Software Product Identifier …

Added p. 31

The categories of required dependencies are detailed below.

The status of an underlying Required Dependency may be reflected on the Validated Secure Software Product Listing, e.g., if an underlying dependency has transitioned to being expired.

Note: Required Dependencies are considered a part of the Validated Secure Software Product’s approval, as by definition they are used to satisfy Program Requirements applicable to the validation process for that Software Product. As such, any deployment, operation, or equivalent of the Validated Secure Software Product that is not in accordance with its Listing, including the use of the noted Required Dependencies, is considered to result in that instance invalidating, or otherwise not being in accordance with, the Listed and Validated Secure Software Product.

PCI-Listed Secure Software Required Dependencies Additional Listed and Validated Secure Software required for use with the Validated Secure Software Product.

- New Assessment: A Software Product under assessment as a New Assessment is only permitted …

Added p. 33

A.12 Modules included in Validation Denotes the modules from the Standard that were included in the Assessment and validation of the Software Product. Refer to the Standard for details of modules.

Added p. 34

Version Number Format The format of the Software Product version number is set by the Vendor and may be comprised of several elements. The versioning methodology must fully describe the format of the version number including the following:

• Numbers of digits used for each element;

• Format of separators used between elements;

• Type of change: major, minor, maintenance release, wildcard, etc.

§ The definition of elements that indicate any use of wildcards.

§ The specific details of how wildcards are used in the versioning methodology.

Version Number Usage All changes to a Validated Secure Software Product must result in a new version number.

However, whether this affects the version number on a Validated Secure Software Product Listing depends on the nature of the change and the Vendor’s published versioning methodology (refer to Section B.3, “Wildcards,” below).

§ Changes that have no impact on the functionality of the software or its dependencies § Changes that have an …

Added p. 36

Versioning Separators The following separators may be used (as defined in the ASCII Table) within a Validated Secure Software Product version. Use of any other characters (e.g., spaces, commas, etc.) are not permitted.

Description Symbol (Separator) Dec Hex Hyphen, Minus - 45 2D Period, Dot . 46 2E Underscore _ 95 5F

Modified p. 1

Payment Card Industry (PCI) ~~Software Security Framework~~ Secure Software Program Guide Version ~~1.2~~

Payment Card Industry (PCI) Secure Software Program Guide Version 2.0 For use with the PCI Secure Software Standard v2.x

Modified p. 2

December 2022 1.2 Updates to accommodate the addition of the Secure Software Standard: ~~Web~~ Software Module, address errata, provide further clarifications, improve document readability, and incorporate new guidance regarding remote assessments.

December 2022 1.2 Updates to accommodate the addition of the Secure Software Standard: Web- based Software Module, address errata, provide further clarifications, improve document readability, and incorporate new guidance regarding remote assessments.

Removed p. 5

The PCI Secure Software Standard is part of the PCI Software Security Framework (“SSF”). This Program Guide details information pertinent to the roles of SSF Assessor Companies authorized by PCI SSC to perform Secure Software Assessments under the Program (“Secure Software Assessor Companies”), and their employees who are qualified by PCI SSC to perform such Assessments (“Secure Software Assessors”).

Definition: For purposes of this document, the term "Assessor" refers to either a Secure Software Assessor Company or Secure Software Assessor, as the context requires.

Modified p. 5

Capitalized terms used but not otherwise defined ~~herein~~ have the meanings set forth in the SSF Qualification ~~Requirements or SSF Glossary,~~ as applicable.

i. Terminology Capitalized terms used but not otherwise defined in this document have the meanings set forth or referenced below, or in the SSF Qualification Requirements, as applicable.

Modified p. 5 → 11

Companies and individuals ~~wanting to become~~ qualified by PCI SSC to perform Secure Software Assessments should first consult the Payment Card Industry (PCI) Software Security Framework Qualification Requirements for Assessors on the Website (the “SSF Qualification Requirements”).

Companies and individuals interested in becoming qualified by PCI SSC to perform Secure Software Assessments should first consult the most current version of (or successor document(s) to) the Payment Card Industry (PCI) Software Security Framework Qualification Requirements for Assessors appearing on the Website (the “SSF Qualification Requirements”).

Removed p. 6

Document Name Description Payment Card Industry (PCI) Software Security Framework Secure Software Requirements and Assessment Procedures (“PCI Secure Software Standard”) Defines a baseline set of specific technical requirements and assessment procedures against which Payment Software must be successfully validated to be qualified by PCI SSC as Validated Payment Software (See Sections 0 and 2.4 below).

Payment Card Industry (PCI) Software Security Framework Secure Software Lifecycle Requirements and Assessment Procedures (“PCI Secure SLC Standard”) Defines a baseline set of specific technical requirements and assessment procedures against which vendors must be successfully assessed to be qualified by PCI SSC as Secure Software Lifecycle (SLC) Qualified Vendors.

Payment Card Industry (PCI) Software Security Framework Glossary of Terms, Abbreviations, and Acronyms (“SSF Glossary”) A glossary of terms used within the Software Security Framework.

Secure Software Attestation of Validation (“Secure Software AOV”) A template document provided by PCI SSC that Secure Software Assessor Companies and Vendors are required …

Modified p. 6

PCI SSC Programs Fee Schedule The current ~~lists~~ of PCI SSC Program fees for specific qualifications, tests, retests, ~~training,~~ and other services available at: ~~https://www.pcisecuritystandards.org/program_training_and_qu alification/fees Secure Software Assessor Feedback Form Template document made available by~~ PCI SSC ~~and required~~ to ~~be provided by Secure Software Assessors to their vendor customers to solicit feedback regarding such Secure Software Assessors and their Secure Software Assessment process.~~

PCI SSC Programs Fee Schedule (Fee Schedule) The current list of PCI SSC Program fees for specific qualifications, tests, retests, training and other services available at: https://www.pcisecuritystandards.org/program_training_and_qualification/fees Participating Payment Brand (Payment Brand) A payment card brand that, as of the time in question, is then formally admitted as (or an affiliate of) a member of PCI SSC pursuant to its governing documents.

Modified p. 6 → 9

Payment Card Industry (PCI) Secure Software Template for Report on Validation ~~(“ROV Report Template”)~~ The template document provided by PCI SSC that ~~Secure Software Assessors~~ Companies are required to use to prepare a PCI Secure Software Standard Report on Validation (“ROV”). The ROV ~~Report~~ Template includes details on how to document the findings of a Secure Software Assessment.

Payment Card Industry (PCI) Secure Software Template for Report on Validation (ROV Template) The template document provided by PCI SSC that SSF Assessor Companies are required to use to prepare a PCI Secure Software Standard Report on Validation (“ROV”). The ROV Template includes details on how to document the findings of a Secure Software Assessment.

Modified p. 6 → 9

Payment Card Industry (PCI) Software Security Framework Qualification Requirements for Assessors ~~(“SSF~~ Qualification ~~Requirements”)~~ Defines the baseline set of requirements that SSF Assessor Companies and their Assessor-Employees must meet to perform Secure Software Assessments or Secure SLC Assessments.

Payment Card Industry (PCI) Software Security Framework Qualification Requirements for Assessors (SSF Qualification Requirements) Defines the baseline set of requirements that SSF Assessor Companies and their Assessor-Employees must meet to perform Secure Software Assessments or Secure SLC Assessments.

Modified p. 6 → 9

PCI SSC Remote Assessment Guidelines and Procedures Detailed guidelines and procedures for performing ~~PCI SSC~~ Assessments remotely.

PCI SSC Remote Assessment Guidelines and Procedures Detailed guidelines and procedures for performing PCI-related Assessments remotely.

Removed p. 7

Secure SLC Qualified Vendors are:

• Identified on PCI SSC’s list of Secure SLC Qualified Vendors on the Website; and

• Authorized to perform certain types of Delta Assessments (See Section 5.1.2) of their own Validated Payment Software under the Program with reduced Secure Software Assessor participation, where the Payment Software (a) is Validated Payment Software; (b) the security requirements assessed were previously assessed by a Secure Software Assessor, and (c) the Validated Payment Software is developed and managed under processes that are identified for that Vendor on PCI SSC’s list of Secure SLC Qualified Vendors.

Modified p. 7 → 12

• Refer to the PCI Secure Software Lifecycle ~~(Secure SLC)~~ Program Guide on the Website for more information about the ~~program.~~

Refer to the PCI Secure Software Lifecycle Program Guide and SSF Qualification Requirements on the Website for more information about the PCI Secure SLC Program.

Modified p. 7 → 12

Note: Vendors of ~~Validated Payment~~ Software are not required to be Secure SLC Qualified Vendors to submit their ~~Payment~~ Software for Secure Software Assessment. Similarly, it is not necessary for a Vendor to have software ~~listed~~ (or in the process of being validated to the PCI Secure Software Standard) to successfully complete assessment and qualification to the PCI Secure SLC Standard.

Note: Vendors of Software Products are not required to be Secure SLC Qualified Vendors to submit their Software Product for a Secure Software Assessment. Similarly, it is not necessary for a Vendor to have software Listed (or in the process of being validated to the PCI Secure Software Standard) to successfully complete assessment and qualification to the PCI Secure SLC Standard.

Modified p. 8 → 12

PCI SSC reserves the right to add, change, or withdraw ~~any security, qualification,~~ training, ~~and/or~~ other requirements at any time.

PCI SSC reserves the right to add, change, amend, or withdraw security requirements, test requirements, guidance, training, or other requirements at any time.

Removed p. 9

• Ensuring they, and the Payment Software products they submit for validation under the Program, satisfy all applicable requirements of the PCI Secure Software Standard (and modules thereof) and Program (collectively for the purposes of this document, “PCI Secure Software Requirements”), including but not limited to successfully passing a Secure Software Assessment as specified in the PCI Secure Software Standard;

• Complying with the Vendor Release Agreement (VRA) including the adoption and implementation of Vulnerability Handling Policies (defined in the VRA) consistent with industry best practices;

• Creating implementation guidance (as required by Control Objective 12, “Software Vendor Implementation Guidance” in the PCI Secure Software Standard) for each Payment Software product submitted for validation under the Program (“Software Vendor Implementation Guidance” or “Implementation Guidance”). In addition to general instruction, the Implementation Guidance must specifically detail the steps required to ensure the secure implementation, configuration, and operation of the applicable Payment Software in …

Modified p. 9 → 7

~~• Lists~~ Secure Software Assessor ~~Companies on the Website.~~

Secure Software Assessor Defined in Section 1 below.

Modified p. 9 → 14

PCI Security Standards Council (PCI SSC) is the standards body that maintains the PCI ~~SSC standards.~~ In relation to the Secure Software Program, PCI SSC:

PCI Security Standards Council (PCI SSC) is the standards body that maintains the PCI Standards. In relation to the Secure Software Program, PCI SSC:

Removed p. 10

• Maintains and updates the PCI Secure Software Standard and related documentation according to a standards lifecycle management process; and

• Reviews all ROVs and related change submissions to confirm that:

− Submissions (including ROVs, updates and Annual Revalidations (as defined in Section 5.3)) are correct as to form; − Secure Software Assessor Companies properly determine whether candidate Payment Software is eligible for validation under the Secure Software Program; and − Detail provided in such submissions (ROVs, updates, and Annual Revalidations) meets PCI SSC’s reporting requirements.

• As part of the quality assurance (“QA”) process for the Program, Secure Software Assessor Companies must demonstrate to PCI SSC that they meet PCI SSC‘s QA and Program qualification requirements, and PCI SSC assesses whether Secure Software Assessor Company operations appear to conform to PCI SSC's QA and Program qualification requirements.

Note: PCI SSC does not perform Assessments of or validate Payment Software for compliance with the …

Removed p. 10

• Providing an opinion in the applicable ROV regarding whether the Payment Software meets the intent and requirements of the PCI Secure Software Standard;

• Documenting each Secure Software Assessment in a ROV using the ROV Report Template;

• Providing adequate documentation within the ROV to demonstrate the Payment Software’s compliance with the PCI Secure Software Standard;

• Submitting each ROV and/or any change submissions to PCI SSC, along with the completed Secure Software Attestation of Validation (“AOV”), each signed by the Secure Software Assessor Company and Vendor, and the Vendor’s executed VRA, if applicable;

• Maintaining an internal quality assurance process for their Secure Software Assessment efforts;

• Staying up to date with PCI SSC statements and guidance, industry trends, and best practices;

Note: PCI SSC reserves the right to reject or remove from the List of Validated Payment Software (i.e., withdraw Acceptance) any software determined to be ineligible for the Secure Software Program.

Modified p. 10 → 18

~~• Performing Secure Software Assessments~~ in accordance with the PCI Secure Software ~~Standard, this Program Guide,~~ the ~~SSF Qualification Requirements, and the SSF Agreement;~~

§ Providing guidance on designing software in accordance with the PCI Secure Software Standard; § Reviewing the Vendor’s software design, responding to inquiries, clarifying requirements, etc.;

Removed p. 11

• Satisfying all applicable SSF and Program requirements at all times, including but not limited to the successful completion of Annual Revalidation, adhering to the applicable SSF Qualification Requirements, and ensuring that Secure Software Assessors have completed all required training and training examinations.

It is the Secure Software Assessor Company’s responsibility to assess a Vendor’s Payment Software for compliance with the PCI Secure Software Standard as of the date of the Secure Software Assessment and document its findings and opinions on compliance in the applicable ROV using the ROV Report Template. PCI SSC does not approve ROVs from a technical compliance perspective; it performs quality assurance to confirm that the ROVs adequately document the Secure Software Assessor Company’s validation and attestation of compliance.

Removed p. 11

• Selecting Validated Payment Software from the Website and ensuring that the Payment Software’s version information is consistent with that indicated on the Website;

• Implementing such software within a PCI DSS compliant environment;

• Configuring the Payment Software (where configuration options are provided) according to the associated Implementation Guidance provided by the Vendor;

• Configuring such Payment Software in a PCI DSS compliant manner; and

• Maintaining the PCI DSS compliant status of both the environment and the Payment Software’s configuration.

Customers and others can find the List of Validated Payment Software on the Website along with other reference materials.

Removed p. 12

• Secure Software Standard Requirements Applicability: Defines the criteria for determining whether the security requirements stated in the Secure Software Standard are applicable to a given software application or use case, and whether the software is eligible for validation to the Secure Software Standard by a PCI Qualified Software Security Framework (SSF) Assessor Company.

• Secure Software Program Listing Eligibility: Defines the criteria that software must meet for it to be eligible for listing on the PCI SSC’s List of Validated Payment Software.

To better understand the differences, it is important to understand the following key terms and definitions (as documented in the SSF Glossary):

• Software that stores, processes, or transmits Payment Data.

• Data created, captured, or exchanged for the explicit purpose of conducting an electronic payment transaction.

The following matrix summarizes the criteria used to differentiate Secure Software Standard requirement applicability and Secure Software Program listing eligibility:

Software Criteria Standard Applicability Program Listing …

Removed p. 13

• Determine/assess the PCI Secure Software Standard for requirements modules applicable to the Payment Software;

• Determine/assess the Payment Software’s readiness to comply with the PCI Secure Software Standard and applicable requirements modules:

− Perform a gap analysis between the Payment Software’s security functionality and the PCI Secure Software Requirements; − Correct any gaps; and − If desired, the Secure Software Assessor Company may perform a pre-assessment or gap analysis of a Vendor’s Payment Software. If the Secure Software Assessor Company notes deficiencies that would prevent a compliant result, it may provide to the Vendor a list of Payment Software features to be addressed before the formal review process begins; and − Determine whether Vendor Implementation Guidance meets the corresponding requirements of the PCI Secure Software Standard and make any necessary revisions.

Modified p. 13 → 15

At a minimum, Vendors seeking validation of their ~~Payment~~ Software to the ~~PCI Secure~~ Software ~~Standard must assess their software~~ to ~~the~~ Core ~~Module.~~ Additional modules should be assessed ~~in conjunction with the Core Module~~ as deemed applicable by the Vendor and a Secure Software ~~Assessor.~~

At a minimum, Vendors seeking validation of their Software Product to the Standard and Program are required to have the Software Product assessed to Core • All Software. Additional modules should be assessed as deemed applicable by the Vendor and a Secure Software Assessor based on the applicability criteria of the module as defined in the Standard.

Removed p. 14

The vendor must submit all completed Payment Software-related materials, such as install media (if applicable), manuals, the Implementation Guidance, the Vendor Release Agreement, and all other materials related to the Assessment, to the Secure Software Assessor Company performing the Assessment. No Vendor documentation supporting the assessment is sent directly to PCI SSC.

Examples of software, documentation, and other items the Vendor must submit to the Secure Software Assessor Company include, but are not limited to:

• The Payment Software;

• The necessary hardware and software accessories to perform:

• Simulated payment transactions; and

• Operational support functions on the Payment Software.

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

• Documentation that relates to the installation, …

Modified p. 14 → 17

• Prompt payment of ~~any~~ applicable fees due to PCI ~~SSC;~~

§ Prompt payment of applicable fees due to PCI SSC for the Validated Secure Software Product submission;

Modified p. 14 → 17

• PCI SSC will not commence the review of the ~~ROV~~ until the applicable ~~fee has~~ been paid.

PCI SSC will not commence the review of the submission until the applicable fees have been paid.

Removed p. 15

Any Assessment timeframes provided by a Secure Software Assessor Company should be considered estimates. Problems found during the review or acceptance process, discussions required between the Secure Software Assessor, the Vendor, and/or PCI SSC, or other matters may significantly impact review times and cause delays and/or may even cause the review to end prematurely (for example, if the Vendor decides it does not want to make the necessary changes to achieve compliance or it is determined that the software is not eligible for PCI Secure Software Standard validation).

PCI SSC qualifies Secure Software Assessor Companies and their Secure Software Assessors to assess and validate Payment Software for compliance with the PCI Secure Software Standard. Additionally, PCI SSC provides required training for Secure Software Assessors. Secure Software Assessors are qualified to perform PCI Secure Software Assessments only to the version(s) of the PCI SSC Standard(s) for which they have successfully completed training.

To …

Modified p. 15 → 17

• Quality of the ~~Secure Software~~ Assessor Company's submission to PCI SSC;

§ Quality of the SSF Assessor Company's submission to PCI SSC;

Modified p. 15 → 18

• ~~Delays resulting from~~ incomplete ~~submissions~~ or ~~those containing~~ errors

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

• Submissions that are incomplete or contain errors

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

•will result in delays in the review process.

Modified p. 15 → 18

• ~~More than one~~ PCI SSC ~~review and comment cycle of~~ the ROV ~~with~~ the ~~Secure Software~~ Assessor Company will increase the length of time ~~it takes to complete~~ the review process.

• If PCI SSC reviews the ROV more than once, providing comments back to the SSF Assessor Company to address each time will increase the length of time for the review process.

Modified p. 15 → 18

• The ~~Secure Software~~ Assessor Company must prepare each ROV based on evidence obtained by following the PCI Secure Software ~~Standard.~~

§ The SSF Assessor Company must prepare and complete each ROV based on evidence obtained by following the PCI Secure Software Standard and Program Requirements.

Removed p. 16

Note: Remote access

•using multi-factor authentication

•to the testing environment is acceptable.

For each Secure Software Assessment, Secure Software Assessor Company testing environment processes must include:

• Using the Vendor’s installation manual, training provided, and the Implementation Guidance to perform the default installation of the Payment Software;

• Confirming that all implementations of the Payment Software (including region/country specific versions) to be listed were tested in the testing environment;

• Confirming that all Payment Software versions and platforms to be listed were tested, including all necessary system components and dependencies;

• Confirming that all critical Payment Software functionalities were tested;

• Confirming that the testing environment can simulate the “real world” use of the Payment Software, including:

− Ensuring that production data (live PAN) is not used for testing and development; − Confirming that the testing environment can run authorization and/or settlement functions and that processes include examination of output from all functions.

• Confirming that the testing environment is …

Removed p. 17

Other Software Assessment Services Offered by Secure Software Assessor Companies Subject to compliance with the independence requirements specified in the SSF Qualification Requirements, a Secure Software Assessor Company may provide a broad range of other services to their customers. These services are neither required nor recommended by PCI SSC. If these services are of interest to your company, please contact the Secure Software Assessor Companies for availability and pricing. Examples of other Software Assessment services include:

• Providing guidance on designing Payment Software in accordance with the PCI Secure Software Standard;

• Reviewing the Vendor’s software design, responding to questions via e-mail or phone, and participating in conference calls to clarify requirements;

• Providing recommendations on preparing the Implementation Guidance;

• Providing pre-assessment (gap analysis) services prior to beginning formal Secure Software Assessment;

• Providing guidance for bringing the Payment Software into compliance with the PCI Secure Software Standard if gaps or areas of non-compliance …

Removed p. 18

Note: A ROV will not be reviewed by PCI SSC without the then-current VRA on file from the relevant Vendor. However, so long as the executed current VRA is on file with 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. 18

There are no annual recurring PCI SSC fees associated with the Acceptance of a Validated Payment Software product. Late fees may apply, however, for annual AOVs received after the software’s listed revalidation date.

It should also be noted that there are PCI SSC fees associated with updates to Validated Payment Software products for non-Secure SLC Qualified Vendors and Secure SLC Qualified Vendors that choose to use the non-Secure SLC Qualified Vendor process for submission. Please see the Website for fee information.

Modified p. 18 → 28

Note: The Vendor pays all ~~Secure Software~~ Assessment-related fees directly to the ~~Secure Software~~ Assessor Company (these fees are negotiated between the Vendor and the ~~Secure Software~~ Assessor Company).

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

Modified p. 18 → 28

PCI SSC will ~~bill~~ the Vendor for all ~~Payment Software Acceptance Fees~~ and the Vendor ~~will~~ pay these fees directly to PCI SSC.

PCI SSC will invoice the Vendor for all associated Program fees for a submission, and the Vendor is required to pay these fees directly to PCI SSC.

Removed p. 19

• Full Software Assessments

• Delta Assessments Full Software Assessments “Full Software Assessments” involve a detailed technical analysis of the entire scope of the Payment Software and are intended to independently validate that the software meets all applicable requirements of the PCI Secure Software Standard, including the security requirements within applicable requirement modules. Full Software Assessments are performed by a PCI-qualified Secure Software Assessor of a Secure Software Assessor Company. Refer to Section 5.2, Full Software Assessment and Listing Process for more information.

Delta Assessments “Delta Assessments,” as the name suggests, are required upon changes to Validated Payment Software that occur between Full Secure Software Assessments. Delta Assessments confirm that software updates do not introduce new vulnerabilities and that the software continues to meet applicable PCI Secure Software Requirements. Additional details regarding the Delta Assessment process can be found in Section 5.5, Changes to Listed Payment Software.

Removed p. 19

• The Vendor initiates the process by selecting a Secure Software Assessor Company from the Website and negotiates any costs and agreements necessary for the Secure Software Assessor Company to perform the Assessment with the Secure Software Assessor Company.

• The Vendor and the Secure Software Assessor Company determine the scope of the Assessment, including identifying all Program requirements and applicable materials necessary to perform the Assessment in accordance with the PCI Secure Software Requirements.

• The Secure Software Assessor Company assesses the Payment Software, including its security functions and features, to determine whether the software complies with all applicable modules and requirements of the PCI Secure Software Standard.

• If the Secure Software Assessor Company determines that the Vendor’s Payment Software satisfies all applicable requirements, it prepares a corresponding Report on Validation (ROV) including all test results, opinions, and conclusions of the Secure Software Assessor Company, along with a completed Secure Software …

Removed p. 21

Annually, by the revalidation date noted on the List of Validated Payment Software, the Vendor is required to submit an updated Secure Software Attestation of Validation (AOV) to PCI SSC in accordance with this section and applicable Program requirements (“Annual Revalidation”). The Vendor must perform the Annual Revalidation steps as indicated in Part 2 of the AOV.

Note: Annual Revalidation submissions will be accepted no more than ninety (90) days prior to the revalidation date noted for the Listed Payment Software.

Modified p. 21 → 6

~~Note:~~ PCI SSC ~~reserves~~ the ~~right~~ to ~~withdraw Acceptance as indicated in Section 3.2,PCI~~ Security Standards ~~Council.~~

PCI SSC (or the Council) Refers to the PCI Security Standards Council, LLC.

Removed p. 22

• Confirm whether any changes have been made to the software;

• Confirm that Validated Payment Software continues to meet all applicable PCI Secure Software Requirements for the major version of the Secure Software Standard to which the Payment Software was originally validated (e.g., Version 1.x, 2.x, etc.);

• Confirm that changes made apply in a way that is consistent with the documented software versioning methodology for that Validated Payment Software product;

• Notify PCI SSC of any changes made to the Payment Software that necessitate a change to its listing on the Website.

• Consider the impact of external threats, including changes to the environment in which the Payment Software operates. This includes the tested platforms, operating systems, and any required dependencies the software may have; and

• For Validated Payment Software, confirm that all tested platforms, operating systems, and dependencies upon which the Validated Payment Software relies remain supported

•for example, that the Vendor …

Removed p. 22

• New Validation: If the Vendor wishes the Payment Software to remain on the List of Validated Payment Software, the Vendor must contact a Secure Software Assessor Company to perform a Full Software Assessment of the Payment Software against the then-current version of the PCI Secure Software Standard.

− Use of the Administrative Change, Low Impact, or Delta Assessment process to achieve this goal is not permitted.

− Once the expiring Payment Software successfully completes the Full Software Assessment process again, the re-validated Payment

Note: Vendors may voluntarily elect to move Payment Software to an “expired” status by following the Administrative Change process described in Section 5.6.1 and specifying this intent in the description of the change.

Secure SLC Qualified Vendors may make this change themselves using the Portal to submit the request.

Modified p. 22 → 25

~~PCI SSC will, upon receipt of the updated AOV: (i)~~ review the submission for completeness; ~~(ii) once~~ completeness is established, ~~update the List of Validated Payment Software with the new revalidation date; and (iii)~~ sign and return a copy of the ~~updated~~ AOV to the ~~applicable~~ Vendor.

i. review the submission for completeness; and ii. if completeness is established, sign and return a copy of the AOV to the Vendor.

Removed p. 23

• Expiry: Upon expiration of the Payment Software’s listing on the Website, Payment Software that is not resubmitted for Full Software Assessment will be identified on the PCI SSC website as “expired.” The process flow for renewing expiring Payment Software is detailed in Figure 2b.

Figure 2a & b. Secure Software Annual Revalidation and Renewing Expiring Payment Software Processes

Removed p. 24

The table below provides a summary of the three types of change scenarios from a Secure Software Program perspective:

Change Type Description Administrative Administrative changes to the Payment Software listing include any changes to how the Payment Software is described in the List of Validated Payment Software, for example, corporate identity or software name changes. See Section 5.6.1, Administrative Changes for details.

Low Impact Low Impact changes to the Payment Software include any changes to the software architecture, source code, or components that do not trigger High-impact Change criteria. Low Impact changes may be eligible for partial or Delta Assessment. See Section 5.6.2, Low Impact Changes and Delta Assessment for details.

High Impact High Impact changes to the Payment Software include any changes to the software architecture, source code, or components that handle or interact with Sensitive Data, Sensitive Functions, or Sensitive Resources. High Impact changes require the Payment Software to undergo a …

Removed p. 24

The process flow for changes to the List of Validated Payment Software is detailed in Figure 3.

Note: Secure SLC Qualified Vendors are only permitted to submit updates to the List of Validated Payment Software for software developed using their PCI SSC-qualified software lifecycle management practices. Any Payment Software developed using other practices may only be updated according to steps outlined for Vendors who are not Secure SLC Qualified Vendors.

Administrative Changes Administrative changes are limited to updates where no software changes have occurred, but the Vendor wants to make a change to the corresponding listing on the List of Validated Payment Software. Administrative changes include, but are not limited to, changes to the Payment Software name or Vendor’s corporate entity name.

• The Vendor prepares a change analysis using the Secure Software Change Impact Template (“Change Impact Template”).

• Minimum required information:

− Software Name, version, and reference number; − Description of the change; …

Modified p. 25 → 21

3. Following successful PCI SSC review of the ~~change~~ submission, PCI SSC will:

Following successful PCI SSC quality assurance review of the Administrative Change submission, PCI SSC will:

Modified p. 25 → 21

PCI SSC reserves the right to reject any ~~change~~ submission if it determines that a change described therein and purported to be an Administrative Change by the Vendor is ineligible for ~~treatment as~~ an Administrative Change.

PCI SSC reserves the right to reject any submission if it determines that a change described therein and purported to be an Administrative Change by the SSF Assessor Company and/or the Vendor is ineligible for an Administrative Change.

Removed p. 26

If the Vendor of the Validated Payment Software is not a Secure SLC Qualified Vendor, all updates to the Validated Payment Software must involve a Secure Software Assessor to perform specific Delta Assessment process steps.

Secure SLC Qualified Vendors are afforded greater flexibility during the Delta Assessment process and may perform some types of Delta Assessments themselves as follows:

• Where the Delta Assessment involves only PCI Secure Software Standard requirements that were previously assessed by a Secure Software Assessor as part of Validated Software’s current listing, Secure SLC Qualified Vendors may perform these Delta Assessment steps themselves.

• Where the Payment Software is being assessed to a new PCI Secure Software Standard requirements module or to requirements not previously assessed by a Secure Software Assessor as part of Validated Software’s current listing, the Delta Assessment must be performed by a Secure Software Assessor.

In all cases, the Vendor prepares a change analysis using …

Modified p. 26 → 21

~~Note:~~ Delta ~~Assessments~~ must be performed by a Secure Software ~~Assessor~~ where requirements that were not previously assessed by a Secure Software Assessor are to be ~~included in the Delta Assessment.~~

• The assessment of Delta Changes must be performed by a Secure Software Assessor, where security requirements that were not previously assessed by a Secure Software Assessor are to be included.

Removed p. 27

1. Vendor confirms the change type.

4. PCI SSC will then sign and return a copy of the AOV to the Vendor.

Removed p. 27

Delta Assessment submission process if the Vendor is a Secure SLC Qualified Vendor

− If the Delta Assessment involves new or different PCI Secure Software Standard requirements than those that were previously assessed by a Secure Software Assessor as part of the Validated Software’s current listing, then follow the steps outlined in Section 5.6.2.2.

− If the Delta Assessment involves only PCI Secure Software Standard requirements that were previously assessed by a Secure Software Assessor as part of the Validated Software’s current listing, then follow the remaining steps in this section.

2. Submit an AOV to PCI SSC for review.

− “Part 2: Submission Type” of the AOV is the value “Low Impact (Delta) Change (is a Secure SLC Qualified Vendor),” with the listed sub sections completed.

3. Amend the List of Validated Payment Software accordingly in the Portal with the new information; and

Delta Assessment submission process if the Vendor is not a Secure SLC …

Removed p. 29

• Any changes to the software architecture, source code, or components that handle or interact with sensitive data, sensitive functions, or sensitive resources;

• The addition or removal of a tested platform/operating system included in the listing on the List of Validated Payment Software;

• The addition or removal of support for specific Secure Software modules.

A Full Software Assessment for a High Impact Change does not affect the Expiry Date of updated Payment Software, which is set at three years after the date on which the applicable version of the product was first Accepted.

The Vendor confirms the change type is a High Impact Change. If High Impact, the Vendor must seek a Full Software Assessment as described in Section 5.2, Full Software Assessment and Listing Process.

Note: In all cases, Validation of a High Impact Change requires that the Vendor work with a PCI Secure Software Assessor Company. See Section 5.1.1, Full Software …

Removed p. 29

• Vendor Release Agreement (one per Vendor) **

• Vendor Release Agreement (one per Vendor) **

Removed p. 29

• Fee (Non-Secure SLC Qualified Vendors Only)

• Fee (Non-Secure SLC Qualified Vendors Only)

• Report on Validation (Redline version)

• Report on Validation

• Vendor Release Agreement (one per Vendor) ** * The Change Impact Template in Appendix C is mandatory when submitting Administrative, Low Impact and High Impact Changes to PCI SSC. ** If applicable.

Removed p. 30

Figure 3. Updates to Listed Payment Software

Removed p. 31

Table 1. Software Validation for Secure SLC Qualified Vendors Type of Software Submission Software Validation Methods Frequency of Submission Assessment by PCI- qualified Secure Software Assessor Vendor Self- Assessment and Self-Attestation Initial / Full software validation X Three years from date of PCI SSC Acceptance High Impact change X Upon implementation of change Annual Revalidation for Validated Payment Software X Annually Administrative change X Upon implementation of change Low Impact / Delta change to previously validated requirements X Upon implementation of change Low Impact / Delta change involving new requirements X Upon implementation of change

Table 2. Software Validation for Vendors who are not Secure SLC Qualified Vendors Type of Software Submission Software Validation Methods Frequency of submission Assessment by PCI- qualified Secure Software Assessor Vendor Self- Assessment and Self- Attestation Initial/Full software validation X Every three years (after initial validation) High Impact change X Upon implementation of Annual Revalidation for …

Removed p. 33

For any change affecting the listing of Validated Payment Software, the applicable fee will be invoiced and must be received by PCI SSC for the changes to be Accepted and added to the List of Validated Payment Software. Upon Acceptance, PCI SSC will sign and return a copy of the AOV to both the Vendor and the Secure Software Assessor Company.

There is no PCI SSC fee associated with the processing of Annual Revalidations.

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

Note: The Vendor pays all Secure Software Assessment-related fees directly to the Secure Software Assessor Company (these fees are negotiated between the Vendor and the Secure Software Assessor Company).

PCI SSC will invoice the Vendor for all applicable listing maintenance fees and the Vendor will pay these fees directly to PCI SSC.

Secure SLC …

Removed p. 33

Where remote assessment methods are used, the Secure Software Assessor must complete Appendix A “Addendum for ROC/ROV: Remote Assessments” of the PCI SSC Remote Assessment Guidelines and Procedures and submit it to PCI SSC along with the Secure Software Report on Validation (ROV). Refer to the PCI SSC Remote Assessment Guidelines and Procedures for more information on remote assessments.

Removed p. 34

Once PCI SSC receives the ROV and all other required materials and applicable fees, PCI SSC reviews the ROV from a quality assurance perspective, typically within thirty (30) calendar days of payment of invoice, and determines whether it is acceptable. Subsequent iterations will also be responded to, typically within thirty (30) calendar days of receipt. If the ROV meets all applicable quality assurance requirements (as documented in the SSF Qualification Requirements and related Program materials), PCI SSC sends a countersigned AOV to both the Vendor and the Secure Software Assessor Company and adds the Validated Payment Software to the List of Validated Payment Software.

Note: It is common for submissions to require several iterations before the Payment Software is Accepted. Adequate QA review of the submission as part of the Secure Software Assessor Company’s internal QA process will help minimize the number of iterations required. Each iteration will be responded to …

Removed p. 35

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 Payment Software names or contact information, incomplete or inconsistent documentation, Payment Software dependencies being insufficiently explained, and tested platforms/operating systems being insufficiently explained. Incomplete or inconsistent submissions may result in significant delays in processing submissions and/or may not be Accepted for review by PCI SSC.

Access to the Portal Access to the Portal is granted to qualified Secure Software Assessor Companies. Secure Software Assessors receive log-on instructions upon passing the Secure Software Assessor training exam. The Primary Contact for a Secure Software Assessor Company must be a Secure Software Assessor and receive higher-level access to the Portal than Secure Software Assessors who are not the Primary Contact, in order to enable the Primary Contact to manage Secure Software Assessor Company-related tasks. Access is …

Removed p. 36

The process flow for the AQM Program is detailed in Figure 4.

ROV Submission Reviews

PCI SSC’s AQM program 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.

If the Payment Software is determined to be eligible for validation under the Secure Software Program and the submission is complete, the AQM analyst will complete a full review of the ROV submission and all supporting documentation provided or requested as part of the initial submission or subsequently thereafter. Any comments or feedback from the AQM analyst will be made via the Portal, and the Secure Software Assessor Company is expected to address all comments and feedback in a timely manner. The AQM analyst’s role is to ensure sufficient evidence and detail is present in the …

Removed p. 37

In Good Standing Secure Software Assessor Companies are expected to maintain a status of In Good Standing while participating in the Secure Software Program. Reviews of each submission and the overall quality of the submissions will be monitored by PCI SSC to detect any deterioration of quality levels over time. The Secure Software Assessor Company may also be subject to periodic audit by PCI SSC at any time.

Remediation A Secure Software Assessor Company may be placed into Remediation for various reasons, including quality concerns or administrative issues (such as failure to meet applicable requalification requirements, failure to submit required information or documentation). Secure Software Assessor Companies in Remediation are listed on the Website in red, indicating their Remediation status without further explanation as to why the designation is warranted.

If administrative or non-severe quality problems are detected, PCI SSC will generally recommend participation in the Remediation program. Remediation provides an opportunity …

Removed p. 39

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

• Payment Software Name

• Payment Software Version #

• Payment Software Type

• Reference Number The following shows an example of a Payment Software Identifier, and the subsequent sections describe the payment software identifier details:

Component Description Payment Software Name Acme Payment 600 Payment Software Version # PCI 4.53.x Payment Software Type POS Suite Reference # 09-01.00111.001 Payment Software Name Payment Software Name is provided by the Vendor and is the name by which the Validated Payment Software is sold. The Payment Software Name cannot contain any variable characters.

Payment Software Version # Payment Software Version # represents the Payment Software version reviewed in the Secure Software Assessment. The format of the version number:

• Is set by the Vendor;

• May consist …

Modified p. 39 → 30

Use of PCI SSC’s name, standards, program names and/or associated acronyms (e.g., PCI DSS, SLC, Secure Software, PTS, etc.) in ~~Payment Software Names~~ is strictly prohibited. PCI SSC reserves the right to reject any ~~Payment~~ Software violating this naming policy.

Note: Use of PCI SSC’s name, standards, program names and/or associated acronyms (e.g., PCI DSS, SLC, Secure Software, PTS, etc.) in software names is strictly prohibited. PCI SSC reserves the right to reject any Software Product violating this naming policy.

Modified p. 39 → 30

Note: See Appendix ~~B, Payment~~ Software Versioning Methodology for details about content to include in the Vendor’s versioning methods. Customers are strongly advised to deploy only that ~~Payment Software~~ with the ~~Payment Software Version #~~ whose characters are consistent with the ~~Payment Software Version #~~ shown on the List of Validated ~~Payment~~ Software.

Note: See 0, Appendix B

• Secure Software Versioning Methodology for details about content to include in the Vendor’s versioning methods. Customers are strongly advised to deploy only that software with the version number whose characters are consistent with the version number shown on the List of Validated Secure Software.

Removed p. 40

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

Removed p. 40

• validated as part of a Secure Software Assessment.

Removed p. 41

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

An example reference number is 08-XX.XXXXX.XXX.AAA, consisting of the following:

Field Format Year of listing 2 digits + hyphen Payment Software Type (see above) 2 digits + period Vendor # 5 digits + period (assigned alphabetically initially, then as received) Vendor App # 3 digits + period (assigned as received) Minor change reference 3 alpha characters (assigned as received) A.3 Tested Platforms/Operating Systems Identify the specific operating system type and version and any other platform components on which the Payment Software was tested.

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

A.4 Required Dependencies Identify specific dependencies that the submitted Payment Software has to other Validated Payment Software, …

Removed p. 42

Assigned status is determined based on the Payment Software’s Expiry Date and/or the Vendor’s timely completion of annual revalidation (whether or not the particular version of the Payment Software is still being supported by the Vendor).

Validated Payment Software is denoted with one of the following Payment Software Statuses:

• Validated Payment Software: All newly Accepted Validated Payment Software is initially denoted as “Validated” and will retain this designation until denoted as “Expired.”

• Expired Payment Software: The status of “Expired” is assigned to Validated Payment Software when either (i) annual revalidation requirements are not satisfied by the Vendor, causing early administrative expiry, or (ii) the Validated Payment Software reaches its Expiry Date (based on the version of the PCI Secure Software Standard under which it was validated).

Please refer to specific payment card brand requirements for questions or information regarding usage of Validated Payment Software and Expired Payment Software.

A.7 Revalidation Date Validated Payment …

Removed p. 43

B.1 Version Number Format The format of the Payment Software version number is set by the Vendor and may be comprised of several elements. The versioning methodology must fully describe the format of the Payment Software version number including the following:

• Type of change: High, Low, Admin.

B.2 Version Number Usage All changes to a given Validated Payment Software product or application must result in a new Payment Software version number. However, whether this affects the version number listed on the Website depends on the nature of the change and the Vendor’s published versioning methodology. All changes that impact security functionality and/or any Secure Software Requirement must result in a change to the version number listed on the Website; use of wildcards is not permitted on the List of Validated Payment Software.

• Changes that have no impact on the functionality of the Payment Software or its dependencies;

• Changes that have an …

Modified p. 43 → 34

• The format of the version scheme, including:

§ The format of the version scheme, including:

Modified p. 43 → 34

~~− Number of elements; − Numbers of digits used for each element; − Format of separators used between elements; −~~ Character set used for each element (consisting of alphabetic, numeric, and/or alphanumeric characters);

• Character set used for each element (consisting of alphabetic, numeric, and/or alphanumeric characters); § The hierarchy of the elements;

Modified p. 43 → 34

• ~~The hierarchy~~ of ~~the~~ elements;

• Number of elements;

Modified p. 43 → 34

The Vendor must document how elements of the ~~Payment~~ Software version number are used to identify:

The Vendor must document how elements of the Software version number are used to identify:

Modified p. 43 → 34

• Types of changes made to the Payment Software

•e.g., major release, minor release, maintenance release, ~~etc.;~~

§ Types of changes made to the software•e.g., major release, minor release, maintenance release, wildcard, etc.

Removed p. 44

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

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

Removed p. 45

Secure Software Assessors and Secure SLC Qualified Vendors must complete each section of this document, and all required documents based on the type of change (see “Required Documents” section below). The Secure Software Assessor or Secure SLC Qualified Vendor is required to submit this Change Impact Template along with supporting documentation to PCI SSC for review.

Always refer to the Secure Software Program Guide for information on Payment Software changes.

Payment Software Details Name of Payment Software Payment Software Version

PCI Secure Software Standard Version Validated Listing Reference # Date of Change Submission Type of Change (please check) Administrative Low Impact (Delta) High Impact Payment Software Vendor Contact Information Vendor Name Contact Name Title/Role Contact E-mail Contact Phone Secure Software Assessor Company Contact Information Secure Software Assessor Company Name Contact Name Title/Role Contact E-mail Contact Phone

Removed p. 47

Indicate which PCI Secure Software Requirements are impacted by the change:

Core Requirements 1 2 3 4 5 6 7 8 9 10 11 12 Module Requirement(s) Module A: Account Data Protection Control Objective A.1 A.2 Module B: Terminal Software B.1 B.2 B.3 B.4 B.5 Module C: Web Software C.1 C.2 C.3 C.4 If any PCI Secure Software Requirements were excluded from the assessment, provide a description of the testing performed to validate that excluded PCI Secure Software Requirements are not impacted (for example, comparing code, details from developer interviews, details from functionality testing, etc.):

Change Number Detailed description of the change, including why the change is necessary Describe how cardholder data is Describe how the change impacts Payment Software functionality

Document Comparison

Content Changes