Document Comparison
Secure-Software-Program-Guide-v1.0.1.pdf
→
PCI-Secure-Software-Program-Guide-v1_1.pdf
56% similar
46 → 45
Pages
13993 → 14110
Words
153
Content Changes
From Revision History
- June 2019 1.0 Initial release
Content Changes
153 content changes. 62 administrative changes (dates, page numbers) hidden.
Added
p. 2
June 2019 1.0 Initial release
April 2021 1.1 Program updates to accommodate addition of the Terminal Software Module; errata updates for grammatical corrections and readability.
April 2021 1.1 Program updates to accommodate addition of the Terminal Software Module; errata updates for grammatical corrections and readability.
Added
p. 5
Definition: For purposes of this document: "Assessor" refers to either a Secure Software Assessor Company or Secure Software Assessor, as the context requires.
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.
Vendors that have qualified under the PCI Secure SLC Program (“Secure SLC Qualified Vendors”) have demonstrated to a Secure SLC Assessor that their validated secure software development life cycle processes, procedures, and practices comply with the PCI Secure SLC Standard.
Refer to the PCI Secure Software Lifecycle Program Guide on the Website for more information about the program.
Creating PCI Secure Software Standard compliant Payment Software; …
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.
Vendors that have qualified under the PCI Secure SLC Program (“Secure SLC Qualified Vendors”) have demonstrated to a Secure SLC Assessor that their validated secure software development life cycle processes, procedures, and practices comply with the PCI Secure SLC Standard.
Refer to the PCI Secure Software Lifecycle Program Guide on the Website for more information about the program.
Creating PCI Secure Software Standard compliant Payment Software; …
Added
p. 10
Performing Secure Software Assessments in accordance with the PCI Secure Software Standard, this Program Guide, the SSF Qualification Requirements, and the SSF Agreement; 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;
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 …
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 …
Added
p. 14
Whether the Implementation Guidance meets all PCI Secure Software Requirements at the start of the Assessment; − Extensive rewrites of the Implementation Guidance will delay validation; Prompt payment of the fees due to PCI SSC; − PCI SSC will not commence the review of the ROV until the applicable fee has been paid.
Quality of the Secure Software Assessor Company's submission to PCI SSC; Delays resulting from incomplete submissions or those containing errors•for example, missing or unsigned documents, incomplete or inconsistent submissions; 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.
Have been qualified by PCI SSC; Have at least one Secure Software Assessor employee; Ensure that both the Secure Software Assessor Company and Secure Software Assessor(s) remain in good standing with the Program; and Ensure that all Secure Software …
Quality of the Secure Software Assessor Company's submission to PCI SSC; Delays resulting from incomplete submissions or those containing errors•for example, missing or unsigned documents, incomplete or inconsistent submissions; 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.
Have been qualified by PCI SSC; Have at least one Secure Software Assessor employee; Ensure that both the Secure Software Assessor Company and Secure Software Assessor(s) remain in good standing with the Program; and Ensure that all Secure Software …
Added
p. 17
Providing guidance on designing Payment Software in accordance with the PCI Secure Software Standard; Reviewing a 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 are noted during the assessment.
Added
p. 19
Full Software Assessments; Delta Assessments.
The Core Requirements of the PCI Secure Software Standard; and Each module of the PCI Secure Software Standard that applies to that type of software.
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. 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 the software continues to meet applicable PCI Secure Software Requirements. Additional details regarding the Delta Assessment process can be found …
The Core Requirements of the PCI Secure Software Standard; and Each module of the PCI Secure Software Standard that applies to that type of software.
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. 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 the software continues to meet applicable PCI Secure Software Requirements. Additional details regarding the Delta Assessment process can be found …
Added
p. 19
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.
Note: Validation of a software product is not dependent on the software vendor being Secure SLC Qualified.
Note: Validation of a software product is not dependent on the software vendor being Secure SLC Qualified.
Added
p. 20
PCI SSC issues an invoice to the Vendor for review of the submission and the Vendor pays the invoice received from PCI SSC in a timely fashion.
PCI SSC reviews the submission (including the ROV, all test results, Vendor evidence and Assessor opinions and conclusions) to determine whether the submission demonstrates reasonable assurance that testing was performed satisfactorily and that the requirements have been met.
Upon and subject to successful completion of the submission review process and final acceptance and approval of the ROV by PCI SSC (“Acceptance”), PCI SSC will: − Add a listing for the assessed Payment Software to its List of Validated Payment Software on the PCI SSC website (each a “Listing”).
− Countersign the AOV and send a copy to the Vendor and Secure Software Assessor Company.
Validated Payment Software listings are generally valid for a period of up to three years (subject to removal from the list and expiration …
PCI SSC reviews the submission (including the ROV, all test results, Vendor evidence and Assessor opinions and conclusions) to determine whether the submission demonstrates reasonable assurance that testing was performed satisfactorily and that the requirements have been met.
Upon and subject to successful completion of the submission review process and final acceptance and approval of the ROV by PCI SSC (“Acceptance”), PCI SSC will: − Add a listing for the assessed Payment Software to its List of Validated Payment Software on the PCI SSC website (each a “Listing”).
− Countersign the AOV and send a copy to the Vendor and Secure Software Assessor Company.
Validated Payment Software listings are generally valid for a period of up to three years (subject to removal from the list and expiration …
Added
p. 21
Figure 1. Full Secure Software Assessment and Listing Process 5.3 Annual Revalidation Subject to early expiry and the terms of the VRA, the version of the Payment Software that was successfully validated by the Secure Software Assessor Company and Accepted by PCI SSC will be listed as Validated Payment Software for a period of three years from the date of Acceptance of that version.
Added
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; 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 (of the operating system, databases, dependent software, etc.) continues to maintain and provide updates for any security vulnerabilities identified.
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 (of the operating system, databases, dependent software, etc.) continues to maintain and provide updates for any security vulnerabilities identified.
Added
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 and any modules which are then applicable for the Payment Software.
− Use of the Low Impact or Administrative Change process to achieve this goal is not permitted.
− Once the expiring Payment Software successfully completes the Secure 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.5.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.
− Use of the Low Impact or Administrative Change process to achieve this goal is not permitted.
− Once the expiring Payment Software successfully completes the Secure 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.5.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.
Added
p. 23
Expiry: Upon expiration of the Payment Software’s listing on the Website, the Payment Software must be resubmitted for a Full Software Assessment to retain its validation. 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
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.5.1, Administrative Changes for details.
Process Details by Change Type The following sections provide details about changes to Validated Payment Software, the supporting documentation that must be generated, and the processes to be followed to make changes to the List of Validated …
Figure 2a & b. Secure Software Annual Revalidation and Renewing Expiring Payment Software Processes
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.5.1, Administrative Changes for details.
Process Details by Change Type The following sections provide details about changes to Validated Payment Software, the supporting documentation that must be generated, and the processes to be followed to make changes to the List of Validated …
Added
p. 25
− Software Name, version, and reference number; − Description of the change; − “Type of Change” selected on the template is “Administrative”.
Administrative Change submission process if the Vendor is a Secure SLC Qualified Vendor:
1. Vendor completes a self-assessment to confirm the change type.
2. Vendor completes and submits an Attestation of Validation (AOV) to PCI SSC for review.
− “Part 2: Submission Type” of the AOV is the value “Administrative Change (is a Secure SLC Qualified Vendor),” with the listed subsections completed.
3. The Vendor details the amendments to the List of Validated Payment Software via the Portal accordingly; and
4. PCI SSC will then sign and return a copy of the AOV to the Vendor.
Administrative Change submission process if the Vendor is not a Secure SLC Qualified Vendor:
1. Vendor prepares a Change Impact Template and submits it to the Secure Software Assessor Company for review.
2. The Secure Software Assessor reviews the request and …
Administrative Change submission process if the Vendor is a Secure SLC Qualified Vendor:
1. Vendor completes a self-assessment to confirm the change type.
2. Vendor completes and submits an Attestation of Validation (AOV) to PCI SSC for review.
− “Part 2: Submission Type” of the AOV is the value “Administrative Change (is a Secure SLC Qualified Vendor),” with the listed subsections completed.
3. The Vendor details the amendments to the List of Validated Payment Software via the Portal accordingly; and
4. PCI SSC will then sign and return a copy of the AOV to the Vendor.
Administrative Change submission process if the Vendor is not a Secure SLC Qualified Vendor:
1. Vendor prepares a Change Impact Template and submits it to the Secure Software Assessor Company for review.
2. The Secure Software Assessor reviews the request and …
Added
p. 26
The Vendor prepares a change analysis using the Secure Software Change Impact Template.
Delta Assessment Submission process if the Vendor is a Secure SLC Qualified Vendor:
1. Perform a self-assessment to confirm the change type, then submit an AOV to PCI SSC for − “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.
Delta Assessment Submission process if the Vendor is a Secure SLC Qualified Vendor:
1. Perform a self-assessment to confirm the change type, then submit an AOV to PCI SSC for − “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.
Added
p. 27
2. Vendor then submits this with an AOV to the Secure Software Assessor Company for review.
− “Part 2: Submission Type” of the AOV is the value “Low Impact (Delta) Change (is not a Secure SLC Qualified Vendor),” with the listed subsections completed.
− Notifies the Vendor that it agrees; − Performs a delta assessment of the Payment Software for the PCI Secure Software Requirements affected by the Low Impact change; − Tests the Payment Software’s functionality; − Completes the Change Impact Template and makes redline changes to the original ROV as appropriate; − Signs its concurrence on the AOV and forwards it•along with the “redline” version of the ROV, the Payment Software‘s updated Implementation Guidance, and the completed Change Impact Template to PCI SSC.
4. PCI SSC will then:
− Upon successful review of all submitted documentation, amend the List of Validated Payment Software accordingly with the new information; and − Sign and …
− “Part 2: Submission Type” of the AOV is the value “Low Impact (Delta) Change (is not a Secure SLC Qualified Vendor),” with the listed subsections completed.
− Notifies the Vendor that it agrees; − Performs a delta assessment of the Payment Software for the PCI Secure Software Requirements affected by the Low Impact change; − Tests the Payment Software’s functionality; − Completes the Change Impact Template and makes redline changes to the original ROV as appropriate; − Signs its concurrence on the AOV and forwards it•along with the “redline” version of the ROV, the Payment Software‘s updated Implementation Guidance, and the completed Change Impact Template to PCI SSC.
4. PCI SSC will then:
− Upon successful review of all submitted documentation, amend the List of Validated Payment Software accordingly with the new information; and − Sign and …
Added
p. 28
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.
The Vendor performs an initial self-assessment to confirm 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.
The Vendor performs an initial self-assessment to confirm 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.
Added
p. 28
• Fee (Non-Secure SLC Qualified Vendors Only)
• Fee (Non-Secure SLC Qualified Vendors Only)
• Vendor Release Agreement (one per Vendor) **
• 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.
Figure 3. Updates to Listed Payment Software
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 Company Vendor Self- Submission using Initial/Full software validation √ Three years from date of PCI SSC Acceptance High Impact change √ Upon implementation of change Annual Revalidation for Validated Payment Software √ Annually Administrative change √ Upon implementation of change Low Impact change (Delta) √
Table 2. Software Validation for Vendors who are not Secure SLC Qualified Vendors Type of Software Submission Software Validation Methods Frequency of submission Assessment …
• Fee (Non-Secure SLC Qualified Vendors Only)
• Vendor Release Agreement (one per Vendor) **
• 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.
Figure 3. Updates to Listed Payment Software
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 Company Vendor Self- Submission using Initial/Full software validation √ Three years from date of PCI SSC Acceptance High Impact change √ Upon implementation of change Annual Revalidation for Validated Payment Software √ Annually Administrative change √ Upon implementation of change Low Impact change (Delta) √
Table 2. Software Validation for Vendors who are not Secure SLC Qualified Vendors Type of Software Submission Software Validation Methods Frequency of submission Assessment …
Added
p. 33
PCI Secure Software Standard version Payment Software Status (Validated or Expired) Revalidation Date Expiry Date Secure Software Assessor Company
Added
p. 35
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 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.
Figure 4. Secure Software Assessor Company QA Programs for Report Reviews
Payment Software Name Payment Software Version # Payment Software Type Reference Number The following shows an example of a Payment Software Identifier:
Figure 4. Secure Software Assessor Company QA Programs for Report Reviews
Payment Software Name Payment Software Version # Payment Software Type Reference Number The following shows an example of a Payment Software Identifier:
Added
p. 40
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).
- Numbers of digits used for each element;
- Format of separators used between elements;
- Character set used for each element (consisting of alphabetic, numeric, and/or alphanumeric characters); The hierarchy of the elements; Definition of what each element represents in the version scheme; Type of change: High, Low, Admin.
- Numbers of digits used for each element;
- Format of separators used between elements;
- Character set used for each element (consisting of alphabetic, numeric, and/or alphanumeric characters); The hierarchy of the elements; Definition of what each element represents in the version scheme; Type of change: High, Low, Admin.
Added
p. 42
Types of changes made to the Payment Software•e.g., major release, minor release, maintenance release, etc.; Changes that have no impact on the functionality of the Payment Software or its dependencies; Changes that have an impact on the Payment Software functionality but no impact on security or any Secure Software Requirement; Changes that impact any security functionality or any Secure Software Requirement.
Modified
p. 2
June 2020 1.0.1 Aligned language (regarding use of wildcards) in Appendix B "Payments Software Versioning Methodology" and section 3.1 "Vendors" with language in the Secure Software Report on Validation (ROV) report template.
Modified
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” or “Assessors”), and their employees who are qualified by PCI SSC to perform such Assessments (“Secure Software Assessor-Employees”).
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”).
Modified
p. 5
Companies and individuals wishing 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 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”).
Removed
p. 6
PCI SSC Programs Fee Schedule Lists the current fees for specific qualifications, tests, retests, training, and other services.
Modified
p. 6
Document name Description Payment Card Industry (PCI) Secure Software Standard (“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 2.1 and 4 below).
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).
Modified
p. 6
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 SLC Qualified Vendors.
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.
Modified
p. 6
Secure Software Attestation of Validation A template document provided by PCI SSC and required to be used by Secure Software Assessor Companies and Vendors to attest to the results of Secure Software Assessments.
Secure Software Attestation of Validation (“Secure Software AOV”) A template document provided by PCI SSC and required to be used by Secure Software Assessor Companies and Vendors to attest to the results of Secure Software Assessments.
Modified
p. 6
Payment Card Industry (PCI) Software Security Framework Qualification Requirements for Assessors (“SSF Qualification Requirements”) Defines the baseline set of requirements that must be met by SSF Assessor Companies and their Assessor- Employees 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 must be met by SSF Assessor Companies and their Assessor-Employees to perform Secure Software Assessments or Secure SLC Assessments.
Removed
p. 7
Vendors that are successfully validated under the PCI Secure SLC Standard Program (“Secure SLC Qualified Vendors”) to have demonstrated to the applicable Secure SLC Assessor Company that their validated secure payment software development life cycle processes, procedures, and practices are in compliance with the PCI Secure SLC Standard. Secure SLC Qualified Vendors are:
• Identified on PCI SSC’s list of Secure SLC Qualified Vendors on the Website; and
• Identified on PCI SSC’s list of Secure SLC Qualified Vendors on the Website; and
Modified
p. 7
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 and (b) was developed and managed under processes that are identified for that Vendor on PCI SSC’s list of Secure SLC Qualified Vendors.
Modified
p. 7
Note: Vendors of Validated Payment Software are not required to be Secure SLC Qualified Vendors in order to submit their Payment Software for Secure Software Assessment.
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.
Removed
p. 8
• Creating PCI Secure Software Standard compliant Payment Software;
• 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, “Secure Software Requirements”), including but not limited to successfully passing a Secure Software Assessment as specified in PCI Secure Software Requirements and Validation Procedures;
• Complying with the Vendor Release Agreement including the adoption and implementation of Vulnerability Handling Policies (defined in the VRA) consistent with industry best practices;
• Creating security guidance (as required by Control Objective 12, “Vendor Security Guidance” in the PCI Secure Software Standard) for each Payment Software product submitted for validation under the Program (“Security Guidance”). In addition to general instruction, the Security Guidance must specifically detail the steps required to ensure the secure implementation, configuration, and operation of the applicable Payment Software in accordance with the requirements …
• 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, “Secure Software Requirements”), including but not limited to successfully passing a Secure Software Assessment as specified in PCI Secure Software Requirements and Validation Procedures;
• Complying with the Vendor Release Agreement including the adoption and implementation of Vulnerability Handling Policies (defined in the VRA) consistent with industry best practices;
• Creating security guidance (as required by Control Objective 12, “Vendor Security Guidance” in the PCI Secure Software Standard) for each Payment Software product submitted for validation under the Program (“Security Guidance”). In addition to general instruction, the Security Guidance must specifically detail the steps required to ensure the secure implementation, configuration, and operation of the applicable Payment Software in accordance with the requirements …
Modified
p. 8 → 9
PCI SSC is the standards body that maintains the PCI SSC standards. In relation to Secure Software Program, PCI SSC:
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:
Modified
p. 8 → 9
Maintains a centralized repository for all Reports on Validation (ROVs) for Validated Payment Software listed on the Website; Hosts the List of Validated Payment Software on the Website;
Removed
p. 9
• Provides training for and qualifies Secure Software Assessor Companies and Secure Software Assessor Employees to perform Secure Software Assessments.
• Reviews all ROVs and related change submissions to confirm that:
• Performing Secure Software Assessments in accordance with the PCI Secure Software Standard, this Program Guide, the SSF Qualification Requirements, and the SSF Agreement;
• Providing an opinion in the applicable ROV regarding whether the Payment Software meets the intent and requirements of 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 …
• Reviews all ROVs and related change submissions to confirm that:
• Performing Secure Software Assessments in accordance with the PCI Secure Software Standard, this Program Guide, the SSF Qualification Requirements, and the SSF Agreement;
• Providing an opinion in the applicable ROV regarding whether the Payment Software meets the intent and requirements of 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 …
Modified
p. 9 → 10
Lists Secure Software Assessor Companies on the Website.
Modified
p. 9 → 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:
Modified
p. 9 → 10
− Submissions (including ROVs, updates and Annual Revalidations) 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.
− 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.
Modified
p. 9 → 10
Note: PCI SSC does not perform Assessments of or validate Payment Software for compliance with the PCI Secure Software Standard; Assessment and validation are the roles of the Secure Software Assessor Company and its Secure Software Assessor Employees. Listing of Payment Software on the List of Validated Payment Software signifies that the applicable Secure Software Assessor Company has determined that the applicable Payment Software complies with the PCI Secure Software Standard, that the Secure Software Assessor Company has submitted a …
Note: PCI SSC does not perform Assessments of or validate Payment Software for compliance with the PCI Secure Software Standard; Assessment and validation are the roles of the Secure Software Assessor Company and its Secure Software Assessors. Listing of Payment Software on the List of Validated Payment Software signifies that the applicable Secure Software Assessor Company has determined that the applicable Payment Software complies with the PCI Secure Software Standard, that the Secure Software Assessor Company has submitted a corresponding …
Modified
p. 9 → 10
Note: PCI SSC reserves the right to reject or delist any Payment Software determined to be ineligible for the Secure Software Program.
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.
Removed
p. 10
• 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 Security 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.
• Implementing such software within a PCI DSS compliant environment;
• Configuring the Payment Software (where configuration options are provided) according to the associated Security 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.
Modified
p. 10 → 11
Customers and others can find the List of Validated Payment Software on the Website along with other reference materials. PCI SSC’s List of Validated Payment Software is the authoritative listing of Validated Payment Software.
Customers and others can find the List of Validated Payment Software on the Website along with other reference materials.
Removed
p. 11
• Full Software Assessments
• Interim or “Delta” Assessments All software submitted for Secure Software Assessment must be validated against both:
• The Core Requirements of the PCI Secure Software Standard; and
• EACH module of the PCI Secure Software Standard that applies to that type of software.
• Interim or “Delta” Assessments All software submitted for Secure Software Assessment must be validated against both:
• The Core Requirements of the PCI Secure Software Standard; and
• EACH module of the PCI Secure Software Standard that applies to that type of software.
Removed
p. 11
• 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 Secure Software Program 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 requirements of the PCI Secure Software Standard.
Note: Validation of a software product is not dependent on the software vendor being Secure SLC Qualified unless otherwise directed by a payment brand.
• If the Secure Software Assessor Company determines that the Vendor’s Payment Software satisfies all applicable requirements, it prepares a corresponding Report on Validation …
• 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 Secure Software Program 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 requirements of the PCI Secure Software Standard.
Note: Validation of a software product is not dependent on the software vendor being Secure SLC Qualified unless otherwise directed by a payment brand.
• If the Secure Software Assessor Company determines that the Vendor’s Payment Software satisfies all applicable requirements, it prepares a corresponding Report on Validation …
Removed
p. 15
Figure 3a: Updates to Listed Payment Software
• Not a Secure SLC Qualified Vendor
• Not a Secure SLC Qualified Vendor
Removed
p. 16
The PCI Secure Software Standard is not intended for Payment Software developed in- house for the sole use of the company that developed the software, nor is it intended for Payment Software developed and sold to a single customer for the sole use of that customer.
• that may be in the same environment as the Payment Software but are not integrated components of the Payment Software.
• that may be in the same environment as the Payment Software but are not integrated components of the Payment Software.
Modified
p. 16 → 12
Examples of Payment Software ELIGIBLE for Validation Under the Secure Software Program INELIGIBLE for Validation Under the Secure Software Program
Examples of Payment Software Eligible for Validation Under the Secure Software Program Ineligible for Validation Under the Secure Software Program
Modified
p. 16 → 12
• Software products involved in or directly supporting or facilitating payment transactions that store, process, or transmit clear-text account data.
• Software products involved in or directly supporting or facilitating payment transactions that store, process, or transmit clear-text account data;
Modified
p. 16 → 12
• Software products developed by the vendor that are commercially available for sale to multiple organizations.
• Software products developed by the vendor that are commercially available for sale to multiple organizations;
Modified
p. 16 → 12
• In-house developed Payment Software that is used only by the company that developed it.
• In-house developed Payment Software that is used only by the company that developed it;
Modified
p. 16 → 12
• Payment Software that operates on any consumer electronic mobile device that is not solely dedicated to payment acceptance for transaction processing.
• Payment Software that operates on any consumer electronic mobile device that is not solely dedicated to payment acceptance for transaction processing;
Modified
p. 16 → 12
• Payment Software intended for use on hardware terminals (e.g., PTS POI devices).
• Payment Software intended for use on PCI- approved PTS POI devices.
Modified
p. 16 → 12
• Commercial operating systems onto which Payment Software may be installed, unless the operating system is an integrated component of the Payment Software itself.
• Commercial operating systems onto which Payment Software may be installed, unless the operating system is an integrated component of the Payment Software itself;
Modified
p. 16 → 12
• Commercial database applications that Payment Software may utilize for storage of account data, unless the database is an integrated component of the Payment Software itself.
• Commercial database applications that Payment Software may utilize for storage of account data, unless the database is an integrated component of the Payment Software itself;
Modified
p. 16 → 12
• Other types of commercial software developed for purposes unrelated to transaction processing or Payment Software security characteristics, controls, features, and functionalities
•for example, system monitoring or network management services
•for example, system monitoring or network management services
• Other types of commercial software developed for purposes unrelated to transaction processing or Payment Software security characteristics, controls, features, and functionalities
•for example, system monitoring or network management services •that may be in the same environment as the Payment Software but are not integrated components of the Payment Software.
•for example, system monitoring or network management services •that may be in the same environment as the Payment Software but are not integrated components of the Payment Software.
Removed
p. 17
• Determine/assess the Payment Software’s readiness to comply with the PCI Secure Software Standard:
• Determine whether the Vendor’s Security Guidance meets the corresponding requirements of the PCI Secure Software Standard and make any necessary revisions.
1. The Payment Software;
• Determine whether the Vendor’s Security Guidance meets the corresponding requirements of the PCI Secure Software Standard and make any necessary revisions.
1. The Payment Software;
Modified
p. 17 → 13
Determine/assess the PCI Secure Software Standard for modules applicable to the Payment Software; Determine/assess the Payment Software’s readiness to comply with the PCI Secure Software Standard:
Modified
p. 17 → 13
− Perform a gap analysis between the Payment Software’s security functionality and the 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
− 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 …
Modified
p. 17 → 13
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.
Modified
p. 17 → 13
Examples of software, documentation, and other items to submit to the Secure Software Assessor Company include, but are not limited to:
Examples of software, documentation, and other items the Vendor must submit to the Secure Software Assessor Company include, but are not limited to:
Modified
p. 17 → 13
The Payment Software; The necessary hardware and software accessories to perform:
Modified
p. 17 → 13
− Simulated payment transactions; and − Operational support functions on the Payment Software
− Simulated payment transactions; and − Operational support functions on the Payment Software.
Modified
p. 17 → 13
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.
Removed
p. 18
4. Documentation that relates to installing, configuring, and operation of the Payment Software, or that provides information about the Payment Software. Such documentation includes but is not limited to:
− Software Implementation guidance − Software Installation Guide or instructions (as provided to customers); − Vendor’s software versioning methodology for the Payment Software; − Vendor’s Vulnerability Handling Policies; and − Change control documentation that shows how changes are illustrated to customers
6. The Vendor’s executed VRA (if PCI SSC does not already have a copy of the then-current version of the VRA signed by the Vendor).
• Delays resulting from necessary Payment Software corrections to achieve compliance.
• Whether the Vendor’s Security Guidance meets all Secure Software Requirements at the start of the Assessment.
− Extensive rewrites of the Security Guidance will delay validation.
• Prompt payment of the fees due to PCI SSC.
• Quality of the Secure Software Assessor Company's submission to PCI SSC
• Delays resulting …
− Software Implementation guidance − Software Installation Guide or instructions (as provided to customers); − Vendor’s software versioning methodology for the Payment Software; − Vendor’s Vulnerability Handling Policies; and − Change control documentation that shows how changes are illustrated to customers
6. The Vendor’s executed VRA (if PCI SSC does not already have a copy of the then-current version of the VRA signed by the Vendor).
• Delays resulting from necessary Payment Software corrections to achieve compliance.
• Whether the Vendor’s Security Guidance meets all Secure Software Requirements at the start of the Assessment.
− Extensive rewrites of the Security Guidance will delay validation.
• Prompt payment of the fees due to PCI SSC.
• Quality of the Secure Software Assessor Company's submission to PCI SSC
• Delays resulting …
Modified
p. 18 → 14
Additional documentation, such as diagrams and flowcharts, that will aid in the Assessment review; and The Vendor’s executed VRA (if PCI SSC does not already have a copy of the then-current version of the VRA signed by the Vendor).
Modified
p. 18 → 14
Note: The Secure Software Assessor Company may request additional Vendor materials as necessary.
Note: The Secure Software Assessor Company may request additional Vendor materials, as necessary.
Modified
p. 18 → 14
How close the Payment Software is to being PCI Secure Software Standard compliant at the start of the Assessment; Delays resulting from necessary Payment Software corrections to achieve compliance.
Modified
p. 18 → 14
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-Employee, 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 …
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 …
Removed
p. 19
• Have been qualified by PCI SSC;
• Have at least one Secure Software Assessor Employee;
• Ensure that both the Secure Software Assessor Company and Secure Software Assessor Employee remain in good standing; and
• Ensure that all Secure Software Assessor Employees complete all required Secure Software Assessor Employee training.
• Have at least one Secure Software Assessor Employee;
• Ensure that both the Secure Software Assessor Company and Secure Software Assessor Employee remain in good standing; and
• Ensure that all Secure Software Assessor Employees complete all required Secure Software Assessor Employee training.
Modified
p. 19 → 15
PCI SSC qualifies Secure Software Assessor Companies and their Secure Software Assessor Employees to assess and validate Payment Software for compliance with the PCI Secure Software Standard. Additionally, PCI SSC provides required training for Secure Software Assessor Employees. In order to perform Secure Software Assessments, a Secure Software Assessor Company must:
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. To perform Secure Software Assessments, a Secure Software Assessor Company must:
Modified
p. 19 → 15
All recognized Secure Software Assessor Companies are listed on the Website. Only Secure Software Assessor Employees of a Secure Software Assessor Company that meets the above criteria are recognized by PCI SSC as qualified to perform Secure Software Assessments.
All recognized Secure Software Assessor Companies are listed on the Website. Only Secure Software Assessors of a Secure Software Assessor Company that meet the above criteria are recognized by PCI SSC as qualified to perform Secure Software Assessments.
Modified
p. 19 → 15
For each Secure Software Assessment, the resulting Assessment report must follow the ROV Report Template and corresponding instructions outlined in the ROV Report Template.
Modified
p. 19 → 15
The Secure Software Assessor Company must prepare each ROV based on evidence obtained by following the PCI Secure Software Standard.
Modified
p. 19 → 15
Each ROV must be accompanied by a Secure Software Attestation of Validation (AOV):
Modified
p. 19 → 15
− In the form available through the Website; − Signed by a duly authorized officer of the Secure Software Assessor Company; − Summarizing whether the evaluated Payment Software is in compliance or is not in compliance with the PCI Secure Software Standard, along with any related findings.
− In the form available through the Website; − Signed by a duly authorized officer of the Secure Software Assessor Company; − Summarizing whether the evaluated Payment Software complies with the PCI Secure Software Standard, along with any related findings.
Removed
p. 20
• Using the Vendor’s installation manual, training provided, and the Security 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 is capable of simulating the “real world” use of the Payment Software, including:
• Confirming that the testing environment is capable of simulating and validating all functions of the Payment Software, including the testing environment’s capability to exploit software vulnerabilities.
• Use of the Secure Software Assessor Company’s Testing Environment requires the submission of the Testing Environment Configuration for Secure Software Assessments, found in ROV Reporting Template Appendix B, with each Secure Software Assessment. This form …
• 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 is capable of simulating the “real world” use of the Payment Software, including:
• Confirming that the testing environment is capable of simulating and validating all functions of the Payment Software, including the testing environment’s capability to exploit software vulnerabilities.
• Use of the Secure Software Assessor Company’s Testing Environment requires the submission of the Testing Environment Configuration for Secure Software Assessments, found in ROV Reporting Template Appendix B, with each Secure Software Assessment. This form …
Modified
p. 20 → 16
− Ensuring that production data (live PAN) is not used for testing and development − Confirming that the testing environment is capable of running authorization and/or settlement functions and that processes include examination of output from all functions.
− 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.
Removed
p. 21
• Providing guidance on designing Payment Software in accordance with the PCI Secure Software Standard.
• Reviewing a Vendor’s software design, response to questions via e-mail or phone, and participation in conference calls to clarify requirements.
• Providing guidance on preparing the Security 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 are noted during the assessment.
• Reviewing a Vendor’s software design, response to questions via e-mail or phone, and participation in conference calls to clarify requirements.
• Providing guidance on preparing the Security 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 are noted during the assessment.
Modified
p. 21 → 17
Note: When arranging for other Software Assessment services with a Secure Software Assessor Company, care should be taken by both the Vendor and the Secure Software Assessor Company to ensure that the Secure Software Assessor Company maintains all independence requirements as set forth in the SSF Qualification Requirements⎯for example, that a Secure Software Assessor Company does not, as part of the Secure Software Assessment, assess its own work product previously provided to the applicable customer. Conflicts of interest may result …
Note: When arranging for other Software Assessment services with a Secure Software Assessor Company, care should be taken by both the Vendor and the Secure Software Assessor Company to ensure that the Secure Software Assessor Company maintains all independence requirements as set forth in the SSF Qualification Requirements
• for example, that a Secure Software 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 …
• for example, that a Secure Software 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 …
Removed
p. 23
As part of this annual process, Vendors are required to confirm whether any changes have been made to the software, and:
• Confirm that Validated Payment Software continues to meet all applicable Secure Software requirements; and
• Confirm that changes made apply in a way that is consistent with the documented software versioning methodology for that Validated Payment Software product; and
• Notify PCI SSC of any changes made to the Payment Software that necessitate a change to its listing on the Website.
The Vendor is required to 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. For Validated Payment Software, Vendors are required to confirm that all tested platforms, operating systems, and dependencies upon which the Validated Payment Software relies remain supported•for example, that the Vendor (of the operating system, …
• Confirm that Validated Payment Software continues to meet all applicable Secure Software requirements; and
• Confirm that changes made apply in a way that is consistent with the documented software versioning methodology for that Validated Payment Software product; and
• Notify PCI SSC of any changes made to the Payment Software that necessitate a change to its listing on the Website.
The Vendor is required to 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. For Validated Payment Software, Vendors are required to confirm that all tested platforms, operating systems, and dependencies upon which the Validated Payment Software relies remain supported•for example, that the Vendor (of the operating system, …
Modified
p. 23 → 21
Note: PCI SSC reserves the right to withdraw Acceptance as indicated in Section 2.5.
Note: PCI SSC reserves the right to withdraw Acceptance as indicated in Section 3.2, PCI Security Standards Council.
Modified
p. 23 → 21
Note: Annual Attestations will be accepted no more than 90 days prior to revalidation date.
Note: Annual Revalidation submissions will be accepted no more than 90 days prior to the revalidation date noted for the Listed Payment Software.
Modified
p. 23 → 22
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 requalification date; and (iii) sign and return a copy of the updated AOV to the applicable Vendor.
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.
Modified
p. 23 → 22
The process flow for annual revalidation is detailed in Figure 2.
The process flow for Annual Revalidation is detailed in Figure 2a.
Removed
p. 24
Change Type Description Administrative Changes to the Validated Payment Software listing or changes to how the Payment Software is described in the List of Validated Payment Software, for example, corporate identity or application name changes.
See Section 6.2.1.1, “Administrative Changes,” for details.
Low Impact changes may be eligible for partial or “delta” assessment.
See Section 6.2.1.2, “Low Impact Changes,” for details.
See Section 6.2.1.3, “High Impact Changes,” for details.
See Section 6.2.1.1, “Administrative Changes,” for details.
Low Impact changes may be eligible for partial or “delta” assessment.
See Section 6.2.1.2, “Low Impact Changes,” for details.
See Section 6.2.1.3, “High Impact Changes,” for details.
Modified
p. 24
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 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.5.2, Low Impact Changes for details.
Modified
p. 24
High Impact changes require the Vendor to submit the new version of the Payment Software for a full Secure Software assessment.
High Impact changes require the Payment Software to undergo a Full Software Assessment. See Section 5.5.3, High Impact Changes for details.
Modified
p. 24
The process flow for changes to listings for Validated Payment Software is detailed in Figure 4.
The process flow for changes to the List of Validated Payment Software is detailed in Figure 3.
Removed
p. 25
• Completion of a Self-Assessment to confirm the change type and submission of a Self-Attestation to PCI SSC for review;
• The Vendor amends the List of Validated Payment Software accordingly with the new information; and
• PCI SSC will then sign and return a copy of the Self- Attestation to the Vendor.
If the Vendor is not a Secure SLC Qualified Vendor, the following steps are used to update the List of Validated Payment Software.
• Completion of a Self-Assessment to confirm the change type and submission of a Self- Attestation to PCI SSC for review.
• The Vendor amends the List of Validated Payment Software accordingly with the new information; and
• PCI SSC will then sign and return a copy of the Self- Attestation to the Vendor.
If the Vendor is not a Secure SLC Qualified Vendor, the following steps are used to update the List of Validated Payment Software.
• Completion of a Self-Assessment to confirm the change type and submission of a Self- Attestation to PCI SSC for review.
Removed
p. 25
Vendors are afforded some flexibility for Delta Assessments, depending upon the type of update made to the Payment Software. If the Vendor of the Validated Payment Software is not a Secure SLC Qualified Vendor, all updates to the Validated Payment Software must be reviewed by a Secure Software Assessor to confirm the scope of the change. Vendors who have been validated to the PCI Secure SLC Standard through a Secure SLC Assessment are afforded greater flexibility during the Delta Assessment process.
Modified
p. 25 → 24
Note: Secure SLC Qualified Vendors are only allowed to update the List of Validated Payment Software for software developed using their PCI SSC-qualified software lifecycle management practices.
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.
Modified
p. 25
− Amend the List of Validated Payment Software on the Website accordingly with the new information; and − Sign and return a copy of the AOV to the Vendor (copy sent to the Assessor).
Modified
p. 25
Note: The update process does not alter the Expiry Date (See Section A.9 of Appendix A below) of updated Payment Software, which is set at three years after the date on which the applicable version of the product was first Accepted.
Note: The Administrative Change process does not alter the Expiry Date (See Appendix A, A.8 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.
Modified
p. 25
PCI SSC reserves the right to reject any Change Impact document 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 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.
Removed
p. 26
• Include verification that all other Requirements are not affected by the change;
• Include details about how, for all Requirements not included in the Delta Assessment:
• Include Payment Software functionality testing; and
• Include details about how, for all Requirements not included in the Delta Assessment:
• Include Payment Software functionality testing; and
Modified
p. 26
Include all requirements of the PCI Secure Software Standard (“Requirements”) affected by the change in the Change Impact Template; Include verification that all other Requirements are not affected by the change; Include details about how, for all Requirements not included in the Delta Assessment:
Modified
p. 26
− The Secure Software Assessor verified that those Requirements were not affected by the change, OR − The Secure SLC Qualified Vendor verified that those Requirements were not affected by the change;
− The Secure Software Assessor verified that those Requirements were not affected by the change, OR − The Secure SLC Qualified Vendor verified that those Requirements were not affected by the change.
Modified
p. 26
Note: In all Delta Change cases that require assessment or review by a Secure Software Assessor, the Vendor must ensure that these activities are performed by the same company that performed the last Full Assessment and validation of the Payment Software.
Note: In all software change cases that require assessment or review by a Secure Software Assessor, the Vendor must, if possible, ensure that these activities are performed by the same company that performed the last Full Assessment and validation of the Payment Software.
Modified
p. 26
•for
Include Payment Software functionality testing; and Be completed using the same version of the PCI Secure Software Standard, and any and all applicable appendices, as were used for the full validation•for example, a Validated Payment Software product originally validated against PCI Secure Software Standard v1.0 cannot have a delta assessment performed using PCI Secure Software Standard v2.0, and vice-versa.
Modified
p. 26 → 28
The Process flow for each change type for both Secure SLC Qualified Vendors and Vendors that are not Secure SLC Qualified is illustrated in Figure 3.
Removed
p. 27
Figure 4: Software Validation Workflow If the Vendor is a Secure SLC Qualified Vendor, the Vendor must perform the following actions to update the List of Validated Payment Software (see Table 1):
• Perform a Self-Assessment to confirm the change type, then submits a Self-Attestation to PCI SSC for review;
If the Vendor is not a Secure SLC Qualified Vendor, the Vendor must perform the following actions to update the List of Validated Payment Software (see Table 2):
• Notifies the Vendor that it agrees;
• Perform a Self-Assessment to confirm the change type, then submits a Self-Attestation to PCI SSC for review;
If the Vendor is not a Secure SLC Qualified Vendor, the Vendor must perform the following actions to update the List of Validated Payment Software (see Table 2):
• Notifies the Vendor that it agrees;
Modified
p. 27 → 26
2. Amend the List of Validated Payment Software accordingly in the Portal with the new information; and
Modified
p. 27 → 26
PCI SSC will then sign and return a copy of the Self-Attestation to the Vendor.
3. PCI SSC will then sign and return a copy of the AOV to the Vendor.
Modified
p. 27
1. Vendor performs a self-assessment to confirm the change type and prepares a Change Impact Template to provide change analysis information to the Secure Software Assessor Company.
Modified
p. 27
If the Secure Software Assessor Company agrees that the change (as documented by the Vendor in the Vendor Change Analysis) meets the Low Impact change criteria and is eligible for a delta assessment, the Secure Software Assessor Company:
3. If the Secure Software Assessor Company agrees that the change (as documented by the Vendor in the Change Impact Template) meets the Low Impact change criteria and is eligible for a Delta Assessment, the Secure Software Assessor Company:
Removed
p. 28
• Tests the Payment Software’s functionality;
• Completes a Vendor Change Impact document in Appendix C and makes redline changes to the original ROV as appropriate;
• Signs its concurrence on the Attestation of Validation and forwards it
•along with the “redline” version of the ROV, the Payment Software‘s updated installation guidance, and the Vendor Change Impact document to PCI SSC.
• Issue an invoice to the Vendor for the applicable change fee;
• Amend the List of Validated Payment Software accordingly with the new information; and
• Sign and return a copy of the Self-Attestation to the Vendor and the Secure Software Assessor.
PCI SSC reserves the right to reject any Change Impact document if it determines that a change described therein and purported to be a Low Impact Change by the Vendor is ineligible for treatment as a Low Impact Change.
• Completes a Vendor Change Impact document in Appendix C and makes redline changes to the original ROV as appropriate;
• Signs its concurrence on the Attestation of Validation and forwards it
•along with the “redline” version of the ROV, the Payment Software‘s updated installation guidance, and the Vendor Change Impact document to PCI SSC.
• Issue an invoice to the Vendor for the applicable change fee;
• Amend the List of Validated Payment Software accordingly with the new information; and
• Sign and return a copy of the Self-Attestation to the Vendor and the Secure Software Assessor.
PCI SSC reserves the right to reject any Change Impact document if it determines that a change described therein and purported to be a Low Impact Change by the Vendor is ineligible for treatment as a Low Impact Change.
Removed
p. 28
• Any changes to the software architecture, source code, or components that handle or interact with Sensitive Data, Sensitive Functions, or Sensitive Resources.
• The addition of a tested platform/operating system to include on the List of Validated Payment Software.
The Vendor performs an initial Self-Assessment to confirm the change type is a High Impact Change. If High Impact, the Vendor must seek a full software validation as described in Section 4.2, “Initial Validation and Listing.”
• The addition of a tested platform/operating system to include on the List of Validated Payment Software.
The Vendor performs an initial Self-Assessment to confirm the change type is a High Impact Change. If High Impact, the Vendor must seek a full software validation as described in Section 4.2, “Initial Validation and Listing.”
Modified
p. 28 → 27
− Issue an invoice to the Vendor for the applicable change fee; − Upon payment of the invoice, review the AOV, the “redline” version of the ROV and the Change Impact Template for quality assurance purposes.
Modified
p. 28 → 27
For quality issues associated with any aspect of the submission, PCI SSC communicates those issues to the Secure Software Assessor Company, and those issues are resolved according to the process depicted in Figure 1.
− For quality issues associated with any aspect of the submission, PCI SSC communicates those issues to the Secure Software Assessor Company, and those issues are resolved according to the process depicted in Figure 1.
Modified
p. 28 → 27
Note: The update process does not alter 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.
Note: The Delta Assessment process does not alter 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.
Modified
p. 28
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 for further details.
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 Assessments for further details.
Removed
p. 29
Table 1: 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 Company Vendor Self- Assessment and Self-Attestation Vendor Self-Assessment with Delta Review and Testing by PCI-qualified Secure Software Assessor Company Initial/Full software validation √ Every three years (after initial validation) High Impact change √ Upon implementation Annual attestation for Validated Payment √ Annually Administrative change √ Upon implementation of change Low Impact change
Table 2: 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 √ Three years from date of PCI SSC Acceptance.
Table 2: 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 √ Three years from date of PCI SSC Acceptance.
Removed
p. 30
Note: The Secure Software Change Impact document in Appendix C is mandatory for the Secure Software Assessor Company for submitting Administrative, No Impact, Low Impact and High Impact changes to PCI SSC but may also be used by Secure SLC Qualified Vendors as a Vendor Change Analysis.
Removed
p. 30
• 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 have the Payment Software fully re-evaluated against the then-current version of the PCI Secure Software Standard and any modules which are then applicable for the Payment Software. Use of the Low or Administrative Change process to achieve this goal is not permitted.
Note: Vendors are allowed to voluntarily elect to move Payment Software to an “expired” status by submitting an Attestation and request.
Secure SLC Qualified Vendors may make this change themselves on the Portal and submitting the Attestation to PCI SSC.
• Expiry: Upon expiration of the Payment Software’s listing on the Website, the Payment Software must be resubmitted for a Full Software Assessment in order to retain its validation. Payment Software that is not resubmitted for revalidation will be identified on the …
Note: Vendors are allowed to voluntarily elect to move Payment Software to an “expired” status by submitting an Attestation and request.
Secure SLC Qualified Vendors may make this change themselves on the Portal and submitting the Attestation to PCI SSC.
• Expiry: Upon expiration of the Payment Software’s listing on the Website, the Payment Software must be resubmitted for a Full Software Assessment in order to retain its validation. Payment Software that is not resubmitted for revalidation will be identified on the …
Removed
p. 30
• Vendor Release Agreement (one per Vendor) *
• Fee*
• Secure Software Implementation Guidance
• Vendor Release Agreement (one per Vendor) *
• Fee*
• Fee*
• Secure Software Implementation Guidance
• Vendor Release Agreement (one per Vendor) *
• Fee*
Modified
p. 30 → 28
Administrative Change Low Impact Change High Impact Change or New Payment Software Software Vendor
Required Documentation by Change Type Administrative Change Low Impact Change High Impact Change or New Payment Software
Modified
p. 30 → 28
• Vendor Release Agreement (one per Vendor) *
• Fee
• Fee
• Vendor Release Agreement (one per Vendor) **
Removed
p. 31
The process flow for renewing expiring Payment Software is detailed in Figure 2.
Modified
p. 31 → 30
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 listing maintenance fees and the Vendor will pay these fees directly to PCI SSC.
Modified
p. 31 → 30
Secure SLC Qualified Vendors are not required to pay validation maintenance fees for Administrative and Low Impact changes.
Secure SLC Qualified Vendors are not required to pay listing maintenance fees for Administrative and Low Impact changes they perform directly using the Portal.
Modified
p. 32
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 30 calendar days of payment of invoice, and determines whether it is acceptable. Subsequent iterations will also be responded to, typically within 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 …
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 30 calendar days of payment of invoice, and determines whether it is acceptable. Subsequent iterations will also be responded to, typically within 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 …
Modified
p. 32
ROVs that have been returned to the Secure Software Assessor Company for correction must be resubmitted to the PCI SSC within 30 days of the preceding submittal. If this is not possible, the Secure Software Assessor Company must inform the PCI SSC of the timeline for response and PCI SSC may grant an extension. Lack of response on ROVs returned to the Secure Software Assessor Company for correction may result in the submission being closed. Submissions that have been closed …
ROVs that have been returned to the Secure Software Assessor Company for correction must be resubmitted to PCI SSC within 30 days of the preceding submittal. If this is not possible, the Secure Software Assessor Company must inform PCI SSC of the timeline for response and PCI SSC may grant an extension. Lack of response on ROVs returned to the Secure Software Assessor Company for correction may result in the submission being closed. Submissions that have been closed will not …
Modified
p. 32
The ROV Review and Acceptance process flows are detailed in Figure 1.
The ROV Review and Acceptance process flows are illustrated in Figure 1.
Removed
p. 33
• Payment Software Vendor
• Description provided by Vendor
• Tested platforms/operating systems
• Required dependencies
• Validation notes (PCI Secure Software Standard version)
• Secure Software Assessor Company 7.3 Assessor Quality Management Program Secure Software Assessor Companies are required to meet all QA standards set by PCI SSC. The various phases of the PCI SSC Assessor Quality Management (AQM) program for Secure Software Assessor Companies are described below.
• Description provided by Vendor
• Tested platforms/operating systems
• Required dependencies
• Validation notes (PCI Secure Software Standard version)
• Secure Software Assessor Company 7.3 Assessor Quality Management Program Secure Software Assessor Companies are required to meet all QA standards set by PCI SSC. The various phases of the PCI SSC Assessor Quality Management (AQM) program for Secure Software Assessor Companies are described below.
Modified
p. 33
Access to the Portal Access to the Portal is granted to qualified Secure Software Assessor Companies. Secure Software Assessor Employees receive log-on instructions upon passing the Secure Software Assessor- Employee training exam. The Primary Contact for a Secure Software Assessor Company must be a Secure Software Assessor-Employee and receive higher-level access to the Portal than Secure Software Assessor Employees who are not the Primary Contact, in order to enable the Primary Contact to manage Secure Software Assessor Company-related tasks. Access …
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 granted to …
Modified
p. 33
Payment Software Vendor Payment Software Identifier − Payment Software Name − Payment Software Version Number − Payment Software Type Reference Number Tested platforms/operating systems Required dependencies
Modified
p. 35
If administrative or non-severe quality problems are detected, PCI SSC will generally recommend participation in the Remediation program. Remediation provides an opportunity for Secure Software Assessor Companies (and/or their Secure Software Assessor Employees) to improve performance by working closely with PCI SSC staff. Additionally, Remediation helps to assure that the baseline standard of quality for Secure Software Assessor Companies and/or Secure Software Assessor Employees is maintained.
If administrative or non-severe quality problems are detected, PCI SSC will generally recommend participation in the Remediation program. Remediation provides an opportunity for Secure Software Assessor Companies (and/or their Secure Software Assessors) to improve performance by working closely with PCI SSC staff. Additionally, Remediation helps to assure that the baseline standard of quality for Secure Software Assessor Companies and/or Secure Software Assessors is maintained.
Modified
p. 35
Note: If Validated Payment Software is compromised due to Secure Software Assessor Company and/or Secure Software Assessor Employee error, that Secure Software Assessor Company and/or Secure Software Assessor Employee may immediately be placed into Remediation or its status revoked.
Note: If Validated Payment Software is compromised due to Secure Software Assessor Company and/or Secure Software Assessor error, that Secure Software Assessor Company and/or Secure Software Assessor may immediately be placed into Remediation or its status revoked.
Modified
p. 35
The Secure Software Assessor Company may appeal Revocation. However, unless otherwise approved by PCI SSC in writing in each instance, the Secure Software Assessor Company (and its Secure Software Assessor Employees) is not permitted to perform Secure Software Assessments, process ROVs, or otherwise participate in the Secure Software Program. The Secure Software Assessor Company may reapply one year after revocation, so long as it has demonstrated to PCI SSC's satisfaction that it meets all applicable Program requirements.
The Secure Software Assessor Company may appeal Revocation. However, unless otherwise approved by PCI SSC in writing in each instance, the Secure Software Assessor Company (and its Secure Software Assessors) is not permitted to perform Secure Software Assessments, process ROVs, or otherwise participate in the Secure Software Program. The Secure Software Assessor Company may reapply one year after revocation, so long as it has demonstrated to PCI SSC's satisfaction that it meets all applicable Program requirements.
Removed
p. 37
• Payment Software Name
• Payment Software Version #
• Payment Software Type
• Reference Number Example of a Payment Software Identifier:
• Payment Software Version #
• Payment Software Type
• Reference Number Example of a Payment Software Identifier:
Modified
p. 37
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 Identifier: Detail
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 The following sections describe the payment software identifier details.
Modified
p. 37
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.
Modified
p. 37
Payment Software Version # Payment Software Version # represents the Payment Software version reviewed in the Secure Software Assessment. The format of the version number:
Modified
p. 37
Is set by the Vendor; May consist of alphanumeric characters.
Modified
p. 37
Note: See Appendix B: Payment Software Version Methodology for details about content to include in the Vendor’s versioning methods.
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
Removed
p. 38
• validated as part of a Secure Software Assessment.
Modified
p. 38
Payment Software Type The Vendor must choose the option that best describes the primary function of the Payment Software from the list below:
Modified
p. 38
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.
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
A.6 Deployment Notes Deployment Notes are used by PCI SSC to identify the current status of Validated Payment Software for Program purposes. See table under “Expiry Date” below for examples.
• Validated Payment Software: All newly Accepted Validated Payment Software is initially denoted as “Validated Payment Software” and will retain this designation until denoted as “Expired Payment Software.”
• Expired Payment Software: This deployment note 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).
• Validated Payment Software: All newly Accepted Validated Payment Software is initially denoted as “Validated Payment Software” and will retain this designation until denoted as “Expired Payment Software.”
• Expired Payment Software: This deployment note 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).
Modified
p. 40 → 39
A.5 Validation Notes Validation Notes are used by PCI SSC to denote what standard, and the specific version of the standard, was used to assess the compliance of a Validated Payment Software.
A.5 Secure Software Standard Version Secure Software Standard Version is used by PCI SSC to denote what standard, and the specific version of the standard, was used to assess the compliance of a Validated Payment Software.
Modified
p. 40
Assigned deployment notes are 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).
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).
Modified
p. 40
Validated Payment Software is denoted with one of the following Deployment Notes:
Validated Payment Software is denoted with one of the following Payment Software Statuses:
Modified
p. 40
A.7 Annual Attestation Date Validated Payment Software must be revalidated annually. The Annual Attestation Date is used by PCI SSC to indicate when the Vendor’s annual Attestation of Validation is due. The Revalidation Date is specified on the Attestation of Validation.
A.7 Revalidation Date Validated Payment Software must be revalidated annually. The Revalidation Date indicates when the Vendor’s annual Attestation of Validation (AOV) is due. The Revalidation Date is specified on the Attestation of Validation.
Modified
p. 40
A.8 Expiry Date The Expiry Date for Validated Payment Software is the date by which a Vendor must have the Payment Software re-evaluated against the then-current version of the PCI Secure Software Standard in order to maintain Acceptance.
A.8 Expiry Date The Expiry Date for Validated Payment Software is the date by which a Vendor must have the Payment Software re-evaluated against the then-current version of the PCI Secure Software Standard to maintain Acceptance.
Modified
p. 40
Note: Each payment card brand develops and enforces its own compliance program for usage of Validated Payment Software, including, but not limited to requirements, mandates, and/or dates for use of Validated Payment Software; fines or penalties related to use of non-compliant Payment Software; and other requirements for using Payment Software. Questions on how the use of products denoted as Expired Payment Software may affect PCI DSS compliance should be addressed to the merchant’s acquirer and/or the affected payment card brands.
Note: Each payment card brand develops and enforces its own compliance programs for usage of Validated Payment Software, including, but not limited to requirements, mandates, and/or dates for use of Validated Payment Software; fines or penalties related to use of non-compliant Payment Software; and other requirements for using Payment Software. Questions on how the use of products denoted as Expired Payment Software may affect PCI DSS compliance should be addressed to the merchant’s acquirer and/or the affected payment card brands.
Removed
p. 42
− 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)
• Definition of what each element represents in the version scheme
• Types of changes made to the Payment Software
•e.g., major release, minor release, maintenance release, etc.
• Changes that have no impact on the functionality of the Payment Software or its dependencies
• Changes that have an impact on the Payment Software functionality but no impact on security or any Secure Software Requirement
• Definition of what each element represents in the version scheme
• Types of changes made to the Payment Software
•e.g., major release, minor release, maintenance release, etc.
• Changes that have no impact on the functionality of the Payment Software or its dependencies
• Changes that have an impact on the Payment Software functionality but no impact on security or any Secure Software Requirement
Modified
p. 42 → 41
The format of the version scheme, including:
Modified
p. 42 → 41
- Number of elements;
Modified
p. 42 → 41
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 …
Modified
p. 44 → 43
Secure Software Assessors or 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 Secure Software Change Impact along with supporting documentation to PCI SSC for review.
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.
Modified
p. 46 → 45
Indicate which Secure Software Requirements are impacted by the change:
Indicate which PCI Secure Software Requirements are impacted by the change:
Modified
p. 46 → 45
Change Number Detailed description of the change Description of why the change is necessary Description of how CHD is impacted Description of how the change impacts Payment Software functionality
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