Document Comparison
PCI-Secure-Software-Program-Guide-v1_1.pdf
→
PCI-Secure-Software-Program-Guide-v1_2.pdf
78% similar
45 → 47
Pages
14110 → 15047
Words
119
Content Changes
Content Changes
119 content changes. 53 administrative changes (dates, page numbers) hidden.
Added
p. 2
December 2022 1.2 Updates to accommodate the addition of the Secure Software Standard: Web Software Module, address errata, provide further clarifications, improve document readability, and incorporate new guidance regarding remote assessments.
Added
p. 6
PCI SSC Remote Assessment Guidelines and Procedures Detailed guidelines and procedures for performing PCI SSC Assessments remotely.
• Identified on PCI SSC’s list of Secure SLC Qualified Vendors on the Website; and
• Hosts the List of Validated Payment Software on the Website;
• Provides training for and qualifies Secure Software Assessor Companies and Secure Software Assessors to perform Secure Software Assessments.
• Reviews all ROVs and related change submissions to confirm that:
• Satisfying all applicable SSF and Program requirements at all times, including but not limited to the successful completion of Annual Revalidation, adhering to the applicable SSF Qualification Requirements, and ensuring that Secure Software Assessors have completed all required training and training examinations.
• Identified on PCI SSC’s list of Secure SLC Qualified Vendors on the Website; and
• Hosts the List of Validated Payment Software on the Website;
• Provides training for and qualifies Secure Software Assessor Companies and Secure Software Assessors to perform Secure Software Assessments.
• Reviews all ROVs and related change submissions to confirm that:
• Satisfying all applicable SSF and Program requirements at all times, including but not limited to the successful completion of Annual Revalidation, adhering to the applicable SSF Qualification Requirements, and ensuring that Secure Software Assessors have completed all required training and training examinations.
Added
p. 12
• Secure Software Standard Requirements Applicability: Defines the criteria for determining whether the security requirements stated in the Secure Software Standard are applicable to a given software application or use case, and whether the software is eligible for validation to the Secure Software Standard by a PCI Qualified Software Security Framework (SSF) Assessor Company.
• Secure Software Program Listing Eligibility: Defines the criteria that software must meet for it to be eligible for listing on the PCI SSC’s List of Validated Payment Software.
To better understand the differences, it is important to understand the following key terms and definitions (as documented in the SSF Glossary):
• Software that stores, processes, or transmits Payment Data.
• Data created, captured, or exchanged for the explicit purpose of conducting an electronic payment transaction.
The following matrix summarizes the criteria used to differentiate Secure Software Standard requirement applicability and Secure Software Program listing eligibility:
Software Criteria Standard Applicability Program Listing …
• Secure Software Program Listing Eligibility: Defines the criteria that software must meet for it to be eligible for listing on the PCI SSC’s List of Validated Payment Software.
To better understand the differences, it is important to understand the following key terms and definitions (as documented in the SSF Glossary):
• Software that stores, processes, or transmits Payment Data.
• Data created, captured, or exchanged for the explicit purpose of conducting an electronic payment transaction.
The following matrix summarizes the criteria used to differentiate Secure Software Standard requirement applicability and Secure Software Program listing eligibility:
Software Criteria Standard Applicability Program Listing …
Added
p. 15
• 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;
• Delays resulting from incomplete submissions or those containing errors
•for example, missing or unsigned documents, incomplete or inconsistent submissions;
Added
p. 15
• Have been qualified by PCI SSC;
• Have at least one Secure Software Assessor employee;
• Ensure that all Secure Software Assessors complete all required Secure Software Assessor training.
• In the form available through the Website;
• Signed by a duly authorized officer of the Secure Software Assessor Company;
• Have at least one Secure Software Assessor employee;
• Ensure that all Secure Software Assessors complete all required Secure Software Assessor training.
• In the form available through the Website;
• Signed by a duly authorized officer of the Secure Software Assessor Company;
Added
p. 18
It should also be noted that there are PCI SSC fees associated with updates to Validated Payment Software products for non-Secure SLC Qualified Vendors and Secure SLC Qualified Vendors that choose to use the non-Secure SLC Qualified Vendor process for submission. Please see the Website for fee information.
• If the Secure Software Assessor Company determines that the Vendor’s Payment Software satisfies all applicable requirements, it prepares a corresponding Report on Validation (ROV) including all test results, opinions, and conclusions of the Secure Software Assessor Company, along with a completed Secure Software Attestation of Validation (AOV) and submits them to PCI SSC for review.
• 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.
Note: PCI SSC reserves the right to remove Validated Payment Software from the PCI SSC’s List of Validated Payment Software, for …
• If the Secure Software Assessor Company determines that the Vendor’s Payment Software satisfies all applicable requirements, it prepares a corresponding Report on Validation (ROV) including all test results, opinions, and conclusions of the Secure Software Assessor Company, along with a completed Secure Software Attestation of Validation (AOV) and submits them to PCI SSC for review.
• 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.
Note: PCI SSC reserves the right to remove Validated Payment Software from the PCI SSC’s List of Validated Payment Software, for …
Added
p. 25
• Minimum required information:
Secure SLC Qualified Vendors are afforded greater flexibility during the Delta Assessment process and may perform some types of Delta Assessments themselves as follows:
• Where the Delta Assessment involves only PCI Secure Software Standard requirements that were previously assessed by a Secure Software Assessor as part of Validated Software’s current listing, Secure SLC Qualified Vendors may perform these Delta Assessment steps themselves.
• Where the Payment Software is being assessed to a new PCI Secure Software Standard requirements module or to requirements not previously assessed by a Secure Software Assessor as part of Validated Software’s current listing, the Delta Assessment must be performed by a Secure Software Assessor.
• 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
Note: Delta Assessments may only be performed within the same …
Secure SLC Qualified Vendors are afforded greater flexibility during the Delta Assessment process and may perform some types of Delta Assessments themselves as follows:
• Where the Delta Assessment involves only PCI Secure Software Standard requirements that were previously assessed by a Secure Software Assessor as part of Validated Software’s current listing, Secure SLC Qualified Vendors may perform these Delta Assessment steps themselves.
• Where the Payment Software is being assessed to a new PCI Secure Software Standard requirements module or to requirements not previously assessed by a Secure Software Assessor as part of Validated Software’s current listing, the Delta Assessment must be performed by a Secure Software Assessor.
• 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
Note: Delta Assessments may only be performed within the same …
Added
p. 29
• The addition or removal of a tested platform/operating system included in the listing on the List of Validated Payment Software;
• The addition or removal of support for specific Secure Software modules.
A Full Software Assessment for a High Impact Change does not affect the Expiry Date of updated Payment Software, which is set at three years after the date on which the applicable version of the product was first Accepted.
• The addition or removal of support for specific Secure Software modules.
A Full Software Assessment for a High Impact Change does not affect the Expiry Date of updated Payment Software, which is set at three years after the date on which the applicable version of the product was first Accepted.
Added
p. 33
Where remote assessment methods are used, the Secure Software Assessor must complete Appendix A “Addendum for ROC/ROV: Remote Assessments” of the PCI SSC Remote Assessment Guidelines and Procedures and submit it to PCI SSC along with the Secure Software Report on Validation (ROV). Refer to the PCI SSC Remote Assessment Guidelines and Procedures for more information on remote assessments.
Added
p. 39
• Payment Software Name
• Payment Software Version #
• Payment Software Type
• Reference Number The following shows an example of a Payment Software Identifier, and the subsequent sections describe the payment software identifier details:
• Is set by the Vendor;
• validated as part of a Secure Software Assessment.
• Payment Software Version #
• Payment Software Type
• Reference Number The following shows an example of a Payment Software Identifier, and the subsequent sections describe the payment software identifier details:
• Is set by the Vendor;
• validated as part of a Secure Software Assessment.
Added
p. 43
• Definition of what each element represents in the version scheme;
• Type of change: High, Low, Admin.
• 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.
• Type of change: High, Low, Admin.
• 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. 1
Payment Card Industry (PCI) Software Security Framework Secure Software Program Guide Version 1.1
Payment Card Industry (PCI) Software Security Framework Secure Software Program Guide Version 1.2
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.
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 Template for Report on Validation (ROV).
Modified
p. 5
Capitalized terms used but not otherwise defined herein have the meanings set forth in the SSF Qualification Requirements, as applicable.
Capitalized terms used but not otherwise defined herein have the meanings set forth in the SSF Qualification Requirements or SSF Glossary, as applicable.
Modified
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.
Definition: For purposes of this document, the term "Assessor" refers to either a Secure Software Assessor Company or Secure Software Assessor, as the context requires.
Modified
p. 6
Payment Card Industry (PCI) Software Security Framework Glossary of Terms, Abbreviations, and Acronyms A glossary of terms used within the Software Security Framework.
Payment Card Industry (PCI) Software Security Framework Glossary of Terms, Abbreviations, and Acronyms (“SSF Glossary”) A glossary of terms used within the Software Security Framework.
Modified
p. 6
Payment Card Industry (PCI) Report on Validation Reporting Template for Secure Software Standard (“ROV Report Template”) The template document provided by PCI SSC and required to be used by Assessors to prepare PCI Secure Software Standard Reports on Validation (“ROVs”). The ROV Report Template includes details on how to document the findings of a Secure Software Assessment.
Payment Card Industry (PCI) Secure Software Template for Report on Validation (“ROV Report Template”) The template document provided by PCI SSC that Secure Software Assessors Companies are required to use to prepare a PCI Secure Software Standard Report on Validation (“ROV”). The ROV Report Template includes details on how to document the findings of a Secure Software Assessment.
Modified
p. 6
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.
Secure Software Attestation of Validation (“Secure Software AOV”) A template document provided by PCI SSC that Secure Software Assessor Companies and Vendors are required to use 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 SSF Assessor Companies and their Assessor-Employees must meet to perform Secure Software Assessments or Secure SLC Assessments.
Modified
p. 7
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.
Vendors qualified under the PCI Secure SLC Program (“Secure SLC Qualified Vendors”) have demonstrated to a Secure SLC Assessor that their validated software development life cycle processes, procedures, and practices comply with the PCI Secure SLC Standard.
Modified
p. 7
• Authorized to perform certain types of Delta Assessments (See Section 5.1.2) of their own Validated Payment Software under the Program with reduced Secure Software Assessor participation, where the Payment Software (a) is Validated Payment Software; (b) the security requirements assessed were previously assessed by a Secure Software Assessor, and (c) the Validated Payment Software is developed and managed under processes that are identified for that Vendor on PCI SSC’s list of Secure SLC Qualified Vendors.
Modified
p. 7
Refer to the PCI Secure Software Lifecycle Program Guide on the Website for more information about the program.
• Refer to the PCI Secure Software Lifecycle (Secure SLC) Program Guide on the Website for more information about the program.
Modified
p. 7
Note: Vendors of Validated Payment Software are not required to be Secure SLC Qualified Vendors to submit their Payment Software for Secure Software Assessment. Similarly, it is not necessary for a vendor to have software listed (or in the process of being validated to the PCI Secure Software Standard) to successfully complete assessment and qualification to the PCI Secure SLC Standard.
Note: Vendors of 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.
Modified
p. 9
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 for the purposes of this document, “PCI Secure Software Requirements”), including but not limited to successfully passing a Secure Software Assessment as specified in the PCI Secure Software Standard; Complying with the Vendor Release Agreement (VRA) including the adoption and implementation of …
• 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 for the purposes of this document, “PCI Secure Software Requirements”), including but not limited to successfully passing a Secure Software Assessment as specified in the PCI Secure Software Standard; • Complying with the Vendor Release Agreement (VRA) including the adoption …
Modified
p. 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;
• Maintains a centralized repository for all Reports on Validation (ROVs) for Validated Payment Software listed on the Website;
Modified
p. 10 → 9
Lists Secure Software Assessor Companies on the Website.
• Lists Secure Software Assessor Companies on the Website.
Modified
p. 10
Maintains and updates the PCI Secure Software Standard and related documentation according to a standards lifecycle management process; and Reviews all ROVs and related change submissions to confirm that:
• Maintains and updates the PCI Secure Software Standard and related documentation according to a standards lifecycle management process; and
Modified
p. 10
As part of the quality assurance (“QA”) process for the Program, Secure Software Assessor Companies must demonstrate to PCI SSC that they meet PCI SSC‘s QA and Program qualification requirements, and PCI SSC assesses whether Secure Software Assessor Company operations appear to conform to PCI SSC's QA and Program qualification requirements.
• As part of the quality assurance (“QA”) process for the Program, Secure Software Assessor Companies must demonstrate to PCI SSC that they meet PCI SSC‘s QA and Program qualification requirements, and PCI SSC assesses whether Secure Software Assessor Company operations appear to conform to PCI SSC's QA and Program qualification requirements.
Modified
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 …
• 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 …
Modified
p. 11
Selecting Validated Payment Software from the Website and ensuring that the Payment Software’s version information is consistent with that indicated on the Website; Implementing such software within a PCI DSS compliant environment; Configuring the Payment Software (where configuration options are provided) according to the associated Implementation Guidance provided by the Vendor; Configuring such Payment Software in a PCI DSS compliant manner; and Maintaining the PCI DSS compliant status of both the environment and the Payment Software’s configuration.
• Selecting Validated Payment Software from the Website and ensuring that the Payment Software’s version information is consistent with that indicated on the Website; • Implementing such software within a PCI DSS compliant environment; • Configuring the Payment Software (where configuration options are provided) according to the associated Implementation Guidance provided by the Vendor; • Configuring such Payment Software in a PCI DSS compliant manner; and • Maintaining the PCI DSS compliant status of both the environment and the Payment …
Removed
p. 12
Examples of Payment Software Eligible for Validation Under the Secure Software Program Ineligible for Validation Under the Secure Software Program
• Software products involved in or directly supporting or facilitating payment transactions that store, process, or transmit clear-text account data;
• Software products developed by the vendor that are commercially available for sale to multiple organizations;
• Payment Software intended for use on PCI- approved PTS POI devices.
• In-house developed Payment Software that is used only by the company that developed it;
• Payment Software that operates on any consumer electronic mobile device that is not solely dedicated to payment acceptance for transaction processing;
• Commercial operating systems onto which Payment Software may be installed, unless the operating system 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;
• Other types …
• Software products involved in or directly supporting or facilitating payment transactions that store, process, or transmit clear-text account data;
• Software products developed by the vendor that are commercially available for sale to multiple organizations;
• Payment Software intended for use on PCI- approved PTS POI devices.
• In-house developed Payment Software that is used only by the company that developed it;
• Payment Software that operates on any consumer electronic mobile device that is not solely dedicated to payment acceptance for transaction processing;
• Commercial operating systems onto which Payment Software may be installed, unless the operating system 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;
• Other types …
Modified
p. 12
Note: PCI SSC will only Accept (defined in the VRA) and list Payment Software that is eligible for Secure Software Assessment, as determined by PCI SSC. Eligibility requirements will change as new modules are added to the PCI Secure Software Standard.
Note: PCI SSC will only Accept (defined in the VRA) and list Payment Software that meets the listing eligibility criteria, as determined by PCI SSC. Eligibility requirements may change as new modules are added to the PCI Secure Software Standard.
Modified
p. 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:
• Determine/assess the PCI Secure Software Standard for requirements modules applicable to the Payment Software;
Modified
p. 13
− 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 …
− 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. 13 → 14
• The necessary hardware and software accessories to perform:
Modified
p. 13 → 14
• Operational support functions on the Payment Software.
Modified
p. 13 → 14
Documentation that describes all functions used for data input and output that can be used by third-party software developers. Specifically, functions associated with authorization, settlement, and chargeback flows (if applicable to the software) must be described. A manual is an example of documentation that could fulfil this requirement.
• Documentation that 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.
Modified
p. 13 → 14
Documentation that relates to the installation, configuration, and operation of the Payment Software, or that provides information about the Payment Software. Such documentation includes but is not limited to:
• Documentation that relates to the installation, configuration, and operation of the Payment Software, or that provides information about the Payment Software. Such documentation includes but is not limited to:
Modified
p. 13 → 14
• Software Implementation Guidance or instructions (as provided to customers);
Removed
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.
Modified
p. 14
• 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. 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.
• How close the Payment Software is to being PCI Secure Software Standard compliant at the start of the Assessment;
Modified
p. 14 → 15
• 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.
Modified
p. 15
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:
PCI SSC qualifies Secure Software Assessor Companies and their Secure Software Assessors to assess and validate Payment Software for compliance with the PCI Secure Software Standard. Additionally, PCI SSC provides required training for Secure Software Assessors. Secure Software Assessors are qualified to perform PCI Secure Software Assessments only to the version(s) of the PCI SSC Standard(s) for which they have successfully completed training.
Modified
p. 15
• Ensure that both the Secure Software Assessor Company and Secure Software Assessor(s) remain in good standing with the Program; and
Modified
p. 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.
• 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. 15
The Secure Software Assessor Company must prepare each ROV based on evidence obtained by following the PCI Secure Software Standard.
• The Secure Software Assessor Company must prepare each ROV based on evidence obtained by following the PCI Secure Software Standard.
Modified
p. 15
Each ROV must be accompanied by a Secure Software Attestation of Validation (AOV):
• Each ROV must be accompanied by a Secure Software Attestation of Validation (AOV):
Modified
p. 15
• Summarizing whether the evaluated Payment Software complies with the PCI Secure Software Standard, along with any related findings.
Removed
p. 16
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 includes a description for the environment configuration as part of each Secure Software Assessment; If the Secure Software Assessor Company Testing Environment is not capable of properly and fully testing all functions of the Payment Software, an alternative environment may be used. Testing Payment Software in an alternative environment also requires completion of ROV Reporting Template, Appendix B: Testing Environment Configuration for Secure Software Assessments, for each Secure Software Assessment where an alternative environment is used.
Modified
p. 16
Using the Vendor’s installation manual, training provided, and the Implementation Guidance to perform the default installation of the Payment Software; Confirming that all implementations of the Payment Software (including region/country specific versions) to be listed were tested in the testing environment; Confirming that all Payment Software versions and platforms to be listed were tested, including all necessary system components and dependencies; Confirming that all critical Payment Software functionalities were tested; Confirming that the testing environment can simulate the “real world” …
• Using the Vendor’s installation manual, training provided, and the Implementation Guidance to perform the default installation of the Payment Software; • Confirming that all implementations of the Payment Software (including region/country specific versions) to be listed were tested in the testing environment; • Confirming that all Payment Software versions and platforms to be listed were tested, including all necessary system components and dependencies; • Confirming that all critical Payment Software functionalities were tested; • Confirming that the testing environment …
Modified
p. 16 → 17
Other Software Assessment Services Offered by Secure Software Assessor Companies Subject to compliance with the independence requirements specified in the SSF Qualification Requirements, a Secure Software Assessor Company may provide a broad range of other services to their customers. These services are neither required nor recommended by PCI SSC. If these services are of interest to your company, please contact the Secure Software
Other Software Assessment Services Offered by Secure Software Assessor Companies Subject to compliance with the independence requirements specified in the SSF Qualification Requirements, a Secure Software Assessor Company may provide a broad range of other services to their customers. These services are neither required nor recommended by PCI SSC. If these services are of interest to your company, please contact the Secure Software Assessor Companies for availability and pricing. Examples of other Software Assessment services include:
Modified
p. 17 → 16
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.
• 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 includes a description for the environment configuration as part of each Secure Software Assessment;
• If the Secure Software …
• 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 includes a description for the environment configuration as part of each Secure Software Assessment;
• If the Secure Software …
Modified
p. 18
There are no annual recurring PCI SSC fees associated with the Acceptance of a Validated Payment Software product. There are, however, PCI SSC fees associated with updates to Validated Payment Software products. Please see the Website for more information.
There are no annual recurring PCI SSC fees associated with the Acceptance of a Validated Payment Software product. Late fees may apply, however, for annual AOVs received after the software’s listed revalidation date.
Removed
p. 19
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.
Note: Additional modules for the PCI Secure Software Standard are expected to be added to the standard in the future.
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.
Note: Additional modules for the PCI Secure Software Standard are expected to be added to the standard in the future.
Modified
p. 19
Full Software Assessments; Delta Assessments.
• Full Software Assessments
Modified
p. 19
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 Full Software Assessments “Full Software Assessments” involve a detailed technical analysis of the entire scope of the Payment Software and are intended to independently validate that the software meets all applicable requirements of the PCI Secure Software Standard, including the security requirements within applicable requirement modules. Full Software Assessments are performed by a PCI-qualified Secure Software Assessor of a Secure Software Assessor Company. Refer to Section 5.2, Full Software Assessment and Listing Process for more information.
Modified
p. 19
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 in Section 5.5, Changes to Listed Payment Software.
Delta Assessments “Delta Assessments,” as the name suggests, are required upon changes to Validated Payment Software that occur between Full Secure Software Assessments. Delta Assessments confirm that software updates do not introduce new vulnerabilities and that the software continues to meet applicable PCI Secure Software Requirements. Additional details regarding the Delta Assessment process can be found in Section 5.5, Changes to Listed Payment Software.
Modified
p. 19
The Vendor initiates the process by selecting a Secure Software Assessor Company from the Website and negotiates any costs and agreements necessary for the Secure Software Assessor Company to perform the Assessment with the Secure Software Assessor Company.
• The Vendor 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.
Modified
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.
• 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.
Modified
p. 19
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.
• The Secure Software Assessor Company assesses the Payment Software, including its security functions and features, to determine whether the software complies with all applicable modules and requirements of the PCI Secure Software Standard.
Modified
p. 20
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.
• PCI SSC reviews the submission (including the ROV, all test results, 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.
Modified
p. 20
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”).
• 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:
Modified
p. 20
Validated Payment Software listings are generally valid for a period of up to three years (subject to removal from the list and expiration in accordance with the VRA and Program requirements and rules).
Validated Payment Software listings are generally valid for a period of up to three (3) years.
Removed
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.
Modified
p. 21
Note: PCI SSC reserves the right to withdraw Acceptance as indicated in Section 3.2, PCI Security Standards Council.
Note: PCI SSC reserves the right to withdraw Acceptance as indicated in Section 3.2,PCI Security Standards Council.
Modified
p. 21
Note: Annual Revalidation submissions will be accepted no more than 90 days prior to the revalidation date noted for the Listed Payment Software.
Note: Annual Revalidation submissions will be accepted no more than ninety (90) days prior to the revalidation date noted for the Listed Payment Software.
Removed
p. 22
Confirm whether any changes have been made to the software; Confirm that Validated Payment Software continues to meet all applicable PCI Secure Software Requirements; 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.
Modified
p. 22
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
Modified
p. 22
If any tested platform, operating system, or dependency is no longer supported at the time of the Annual Revalidation, this must be reflected in the Vendor’s response to PCI SSC and will result in an updated listing on the Website to indicate the validation has expired.
• If any tested platform, operating system, or dependency is no longer supported at the time of the Annual Revalidation, this must be reflected in the Vendor’s response to PCI SSC and will result in an updated listing on the Website to indicate the validation has expired.
Modified
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.
• 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.
Modified
p. 22
− Use of the Low Impact or Administrative Change process to achieve this goal is not permitted.
− Use of the Administrative Change, Low Impact, or Delta Assessment process to achieve this goal is not permitted.
Modified
p. 22
− Once the expiring Payment Software successfully completes the Secure Software Assessment process again, the re-validated Payment
− Once the expiring Payment Software successfully completes the Full Software Assessment process again, the re-validated Payment
Modified
p. 22
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.
Note: Vendors may voluntarily elect to move Payment Software to an “expired” status by following the Administrative Change process described in Section 5.6.1 and specifying this intent in the description of the change.
Modified
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.
• Expiry: Upon expiration of the Payment Software’s listing on the Website, Payment Software that is not resubmitted for Full Software Assessment will be identified on the PCI SSC website as “expired.” The process flow for renewing expiring Payment Software is detailed in Figure 2b.
Removed
p. 24
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
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.
Change Type Description Administrative Administrative changes to the Payment Software listing include any changes to how the Payment Software is described in the List of Validated Payment Software, for example, corporate identity or software name changes. See Section 5.6.1, Administrative Changes for details.
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 changes may be eligible for partial or Delta Assessment. See Section 5.5.2, Low Impact Changes for details.
Low Impact Low Impact changes to the Payment Software include any changes to the software architecture, source code, or components that do not trigger High-impact Change criteria. Low Impact changes may be eligible for partial or Delta Assessment. See Section 5.6.2, Low Impact Changes and Delta Assessment for details.
Modified
p. 24
High Impact High Impact changes to the Payment Software include any changes to the software architecture, source code, or components that handle or interact with Sensitive Data, Sensitive Functions, or Sensitive Resources.
High Impact High Impact changes to the Payment Software include any changes to the software architecture, source code, or components that handle or interact with Sensitive Data, Sensitive Functions, or Sensitive Resources. High Impact changes require the Payment Software to undergo a Full Software Assessment. See Section 5.6.3, High Impact Changes for details.
Modified
p. 24
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.
Note: Secure SLC Qualified Vendors are only permitted to submit updates to the List of Validated Payment Software for software developed using their PCI SSC-qualified software lifecycle management practices. Any Payment Software developed using other practices may only be updated according to steps outlined for Vendors who are not Secure SLC Qualified Vendors.
Modified
p. 24
The Vendor prepares a change analysis using the Secure Software Change Impact Template (“Change Impact Template”).
• The Vendor prepares a change analysis using the Secure Software Change Impact Template (“Change Impact Template”).
Modified
p. 25
1. Vendor completes a self-assessment to confirm the change type.
1. Vendor confirms the change type.
Modified
p. 25
− “Part 2:Submission Type” of the AOV is the value “Administrative Change (is not a Secure SLC Qualified Vendor)”, with the listed sub sections completed; − PCI SSC will then issue an invoice to the Vendor for the applicable change fee; and − Upon payment of the invoice, review the Administrative Change submission.
− “Part 2: Submission Type” of the AOV is the value “Administrative Change (is not a Secure SLC Qualified Vendor)”, with the listed sub sections completed; − PCI SSC will then issue an invoice to the Vendor for the applicable change fee; and − Upon payment of the invoice, review the Administrative Change submission.
Removed
p. 26
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
In all cases, the Vendor prepares a change analysis using the Secure Software Change Impact Template.
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:
• Include all requirements of the PCI Secure Software Standard (“Requirements”) affected by the change in the Change Impact Template;
Modified
p. 26
• Be completed using the most current minor version of the PCI Secure Software Standard to which the software was originally validated, including all applicable appendices and associated Technical FAQs. For example, a Validated Payment Software product originally validated against PCI Secure Software Standard v1.x cannot have a Delta Assessment performed using PCI Secure Software Standard v2.x, and vice-versa. However, a Validated
Modified
p. 26 → 27
Delta Assessment Submission process if the Vendor is a Secure SLC Qualified Vendor:
Delta Assessment submission process if the Vendor is a Secure SLC Qualified Vendor
Modified
p. 26 → 27
− “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.
Modified
p. 26 → 27
3. Amend the List of Validated Payment Software accordingly in the Portal with the new information; and
Modified
p. 26 → 27
4. 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.
1. Vendor confirms the change type and prepares a Change Impact Template to provide change analysis information to the Secure Software Assessor Company.
Modified
p. 27
− 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 …
− 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 …
Modified
p. 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.
− Issue an invoice to the Vendor for the applicable change fee;
Modified
p. 28 → 29
Any changes to the software architecture, source code, or components that handle or interact with sensitive data, sensitive functions, or sensitive resources; The addition or removal of a tested platform/operating system included in the listing on the List of Validated Payment Software; The addition or removal of support for specific Secure Software modules.
• Any changes to the software architecture, source code, or components that handle or interact with sensitive data, sensitive functions, or sensitive resources;
Modified
p. 28 → 29
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 confirms the change type is a High Impact Change. If High Impact, the Vendor must seek a Full Software Assessment as described in Section 5.2, Full Software Assessment and Listing Process.
Modified
p. 29 → 31
Table 1. Software Validation for Secure SLC Qualified Vendors Type of Software Submission Software Validation Methods Frequency of submission Assessment by PCI-qualified Secure Software Assessor 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 1. Software Validation for Secure SLC Qualified Vendors Type of Software Submission Software Validation Methods Frequency of Submission Assessment by PCI- qualified Secure Software Assessor Vendor Self- Assessment and Self-Attestation Initial / Full software validation X Three years from date of PCI SSC Acceptance High Impact change X Upon implementation of change Annual Revalidation for Validated Payment Software X Annually Administrative change X Upon implementation of change Low Impact / Delta change to previously validated requirements X Upon implementation …
Modified
p. 30 → 32
Table 2. Software Validation for Vendors who are not Secure SLC Qualified Vendors Type of Software Submission Software Validation Methods Frequency of submission Assessment by PCI-qualified Secure Software Assessor Company Vendor Self- Assessment and Self- Attestation Vendor Self- Assessment with Review/Testing by PCI- qualified Secure Software Assessor Initial/Full software validation √ Every three years (after initial validation) High Impact change √ Upon implementation Annual Revalidation for Validated Payment √ Annually Administrative change √ Upon implementation of change Low Impact change …
Table 2. Software Validation for Vendors who are not Secure SLC Qualified Vendors Type of Software Submission Software Validation Methods Frequency of submission Assessment by PCI- qualified Secure Software Assessor Vendor Self- Assessment and Self- Attestation Initial/Full software validation X Every three years (after initial validation) High Impact change X Upon implementation of Annual Revalidation for Validated Payment Software X Annually Administrative change X Upon implementation of Low Impact / Delta change to previously validated requirements X Upon implementation of …
Modified
p. 30 → 33
PCI SSC will invoice the Vendor for all listing maintenance fees and the Vendor will pay these fees directly to PCI SSC.
PCI SSC will invoice the Vendor for all applicable listing maintenance fees and the Vendor will pay these fees directly to PCI SSC.
Modified
p. 30 → 33
Secure SLC Qualified Vendors are not required to pay listing maintenance fees for Administrative and Low Impact changes they perform directly using the Portal.
Secure SLC Qualified Vendors are not required to pay listing maintenance fees for Administrative and Low Impact changes they perform directly using the Portal. However, Secure SLC Qualified Vendors choosing to use the non-Secure SLC Qualified Vendor process for Administrative and Low Impact changes are subject to the maintenance fees associated with that process.
Modified
p. 32 → 34
Once PCI SSC receives the ROV and all other required materials and applicable fees, PCI SSC reviews the ROV from a quality assurance perspective, typically within 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 thirty (30) calendar days of payment of invoice, and determines whether it is acceptable. Subsequent iterations will also be responded to, typically within thirty (30) calendar days of receipt. If the ROV meets all applicable quality assurance requirements (as documented in the SSF Qualification Requirements and related Program materials), PCI SSC sends a countersigned …
Modified
p. 32 → 34
Note: It is common for submissions to require several iterations before the Payment Software is Accepted. Adequate QA review of the submission as part of the Secure Software Assessor Company’s internal QA process will help minimize the number of iterations required. Each iteration will be responded to typically within 30 days from the time that iteration was received in the Portal.
Note: It is common for submissions to require several iterations before the Payment Software is Accepted. Adequate QA review of the submission as part of the Secure Software Assessor Company’s internal QA process will help minimize the number of iterations required. Each iteration will be responded to typically within thirty (30) days from the time that iteration was received in the Portal.
Modified
p. 32 → 34
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 …
ROVs that have been returned to the Secure Software Assessor Company for correction must be resubmitted to PCI SSC within thirty (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 …
Modified
p. 33 → 35
• Payment Software Identifier − Payment Software Name − Payment Software Version Number − Payment Software Type
Modified
p. 33 → 35
PCI Secure Software Standard version Payment Software Status (Validated or Expired) Revalidation Date Expiry Date Secure Software Assessor Company
• Payment Software Vendor
• Tested platforms/operating systems
• Required dependencies
• PCI Secure Software Standard version • Payment Software Status (Validated or Expired) • Secure Software Assessor Company
• Tested platforms/operating systems
• Required dependencies
• PCI Secure Software Standard version • Payment Software Status (Validated or Expired) • Secure Software Assessor Company
Modified
p. 35 → 37
In Good Standing Secure Software Assessor Companies are expected to maintain a status of In Good Standing while participating in the Secure Software Program. Reviews of each submission and the overall quality of 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.
In Good Standing Secure Software Assessor Companies are expected to maintain a status of In Good Standing while participating in the Secure Software Program. Reviews of each submission and the overall quality of the submissions will be monitored by PCI SSC to detect any deterioration of quality levels over time. The Secure Software Assessor Company may also be subject to periodic audit by PCI SSC at any time.
Modified
p. 35 → 37
Revocation Serious quality concerns, issues or problems may result in revocation of Secure Software Assessor Company and/or Secure Software Assessor qualification and termination of the SSF Agreement. When a Secure Software Assessor Company’s qualification is revoked, it and its Secure Software Assessors are removed from the corresponding Program lists on the Website.
Revocation Serious quality concerns, issues, or problems may result in revocation of Secure Software Assessor Company and/or Secure Software Assessor qualification and termination of the SSF Agreement. When a Secure Software Assessor Company’s qualification is revoked, it and its Secure Software Assessors are removed from the corresponding Program lists on the Website.
Removed
p. 37
Payment Software Name Payment Software Version # Payment Software Type Reference Number The following shows an example of a Payment Software Identifier:
Modified
p. 37 → 39
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.
Component Description Payment Software Name Acme Payment 600 Payment Software Version # PCI 4.53.x Payment Software Type POS Suite Reference # 09-01.00111.001 Payment Software Name Payment Software Name is provided by the Vendor and is the name by which the Validated Payment Software is sold. The Payment Software Name cannot contain any variable characters.
Modified
p. 37 → 39
• May consist of alphanumeric characters.
Modified
p. 37 → 39
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
Note: See Appendix B, Payment Software Versioning Methodology for details about content to include in the Vendor’s versioning methods. Customers are strongly advised to deploy only that Payment Software with the Payment Software Version # whose characters are consistent with the Payment Software Version # shown on the List of Validated Payment Software.
Modified
p. 38 → 40
Type Function Description 01 POS Suite/General Point-of-sale software that can be used by merchants for numerous payment channels, including face-to-face, mail-order/telephone order (MOTO, including call centers), Interactive Voice Response (IVR), Web (for manually entered e- commerce, MOTO, etc., transactions), and EFT/check authentication.
Type Function Description 01 POS Suite/General Point-of-sale software that can be used by merchants for numerous payment channels, including face-to-face, mail-order/telephone order (MOTO, including call centers), Interactive Voice Response (IVR), Web (for manually entered e-commerce, MOTO, etc., transactions), and EFT/check authentication.
Modified
p. 40 → 42
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).
• 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).
Modified
p. 41 → 43
The format of the version scheme, including:
• The format of the version scheme, including:
Modified
p. 41 → 43
• The hierarchy of the elements;
Modified
p. 41 → 43
− 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);
Removed
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. 43 → 45
PCI Secure Software Standard Version Validated Listing Reference # Submission Date Type of Change (please check) Administrative Low Impact (Delta) High Impact Payment Software Vendor Contact Information Vendor Name Contact Name Title/Role Contact E-mail Contact Phone Secure Software Assessor Company Contact Information Secure Software Assessor Company Name Contact Name Title/Role Contact E-mail Contact Phone
PCI Secure Software Standard Version Validated Listing Reference # Date of Change Submission Type of Change (please check) Administrative Low Impact (Delta) High Impact Payment Software Vendor Contact Information Vendor Name Contact Name Title/Role Contact E-mail Contact Phone Secure Software Assessor Company Contact Information Secure Software Assessor Company Name Contact Name Title/Role Contact E-mail Contact Phone
Modified
p. 45 → 47
Core Requirements 1 2 3 4 5 6 7 8 9 10 11 12 Module Requirement(s) Module A: Account Data Protection Control Objective A.1 A.2 Module B: Terminal Software B.1 B.2 B.3 B.4 B.5 If any PCI Secure Software Requirements were excluded from the assessment, provide a description of the testing performed to validate that excluded PCI Secure Software Requirements are not impacted (for example, comparing code, details from developer interviews, details from functionality testing, etc.):
Core Requirements 1 2 3 4 5 6 7 8 9 10 11 12 Module Requirement(s) Module A: Account Data Protection Control Objective A.1 A.2 Module B: Terminal Software B.1 B.2 B.3 B.4 B.5 Module C: Web Software C.1 C.2 C.3 C.4 If any PCI Secure Software Requirements were excluded from the assessment, provide a description of the testing performed to validate that excluded PCI Secure Software Requirements are not impacted (for example, comparing code, details from developer interviews, details …