Document Comparison
SPoC_ProgramGuide_v1.0_April_2018.pdf
→
SPoC_Program_Guide_v1.1.pdf
64% similar
58 → 64
Pages
17868 → 17988
Words
267
Content Changes
Content Changes
267 content changes. 92 administrative changes (dates, page numbers) hidden.
Added
p. 5
PCI Security Standards Council, LLC (PCI SSC). Use this guide with the documents referenced in Section 1.2, Related Publications. This document is primarily for Vendors who develop and SPoC Laboratories who validate SPoC Solutions. Capitalized terms used but not otherwise defined within this document have the meanings defined in or pursuant to Appendix G of this Program Guide.
• Introduction (Section 1)
• Reporting Considerations (Section 6) 1.1 SPoC Solution Overview A SPoC Solution (or Solution) comprises the following elements, each of which must be evaluated and validated for use in the Solution. Furthermore, the SPoC Solution itself must be evaluated and validated by a SPoC Lab before being submitted to PCI SSC for acceptance and Listing.
• Magnetic Stripe Reader (MSR): Additional requirements apply to MSRs optionally used in SPoC Solutions. For details, refer to the SPoC Magnetic Stripe Readers Annex (SPoC Annex).
Note: PTS Technical FAQs on the Website may also apply …
• Introduction (Section 1)
• Reporting Considerations (Section 6) 1.1 SPoC Solution Overview A SPoC Solution (or Solution) comprises the following elements, each of which must be evaluated and validated for use in the Solution. Furthermore, the SPoC Solution itself must be evaluated and validated by a SPoC Lab before being submitted to PCI SSC for acceptance and Listing.
• Magnetic Stripe Reader (MSR): Additional requirements apply to MSRs optionally used in SPoC Solutions. For details, refer to the SPoC Magnetic Stripe Readers Annex (SPoC Annex).
Note: PTS Technical FAQs on the Website may also apply …
Added
p. 6
• Back-end Processing Environment: The environment where cardholder data and/or PIN data is decrypted and securely processed and, per the note above, must be validated for the following, where applicable:
• PCI DSS validation (ROC and AOC) by a QSA
• PCI PIN validation by a PCI PIN auditor approved by one of the Participating Payment Brands to perform assessments of PIN-processing environments
Figure 1 illustrates the elements of the SPoC Solution and the SPoC Program stakeholder that validates each element. For more detail, see the SPoC Security Requirements, “Overview” and “Software-based PIN Entry on COTS Devices” sections.
• PCI DSS validation (ROC and AOC) by a QSA
• PCI PIN validation by a PCI PIN auditor approved by one of the Participating Payment Brands to perform assessments of PIN-processing environments
Figure 1 illustrates the elements of the SPoC Solution and the SPoC Program stakeholder that validates each element. For more detail, see the SPoC Security Requirements, “Overview” and “Software-based PIN Entry on COTS Devices” sections.
Added
p. 8
PCI SSC provides interim updates to the PCI community through a variety of means, including required Assessor or Lab training, e-mail bulletins and newsletters, frequently asked questions (FAQs), and other communication methods.
Document Name Description Payment Card Industry (PCI) Software-based PIN Entry on COTS Security Requirements (“SPoC Security Requirements”) The SPoC Security Requirements defines the specific technical security requirements for the Solution, including the PIN CVM Application, the supporting Monitoring/Attestation System and Back-end Monitoring Environment.
Payment Card Industry (PCI) Software-based PIN Entry on COTS Test Requirements (“SPoC Test Requirements”) The SPoC Test Requirements lists and defines the specific testing and Evaluation procedures required to evaluate the solution against the SPoC Security Requirements.
Payment Card Industry (PCI) Software-based PIN Entry on COTS (SPoC) Magnetic Stripe Readers Annex ("SPoC Annex") The SPoC Annex is a supplementary document to the SPoC Security Requirements and SPoC Test Requirements applicable to MSRs in listed SPoC Solutions.
SPoC Solution Attestation …
Document Name Description Payment Card Industry (PCI) Software-based PIN Entry on COTS Security Requirements (“SPoC Security Requirements”) The SPoC Security Requirements defines the specific technical security requirements for the Solution, including the PIN CVM Application, the supporting Monitoring/Attestation System and Back-end Monitoring Environment.
Payment Card Industry (PCI) Software-based PIN Entry on COTS Test Requirements (“SPoC Test Requirements”) The SPoC Test Requirements lists and defines the specific testing and Evaluation procedures required to evaluate the solution against the SPoC Security Requirements.
Payment Card Industry (PCI) Software-based PIN Entry on COTS (SPoC) Magnetic Stripe Readers Annex ("SPoC Annex") The SPoC Annex is a supplementary document to the SPoC Security Requirements and SPoC Test Requirements applicable to MSRs in listed SPoC Solutions.
SPoC Solution Attestation …
Added
p. 9
• Section 3, Preparation for the Evaluation
• Section 4, Evaluation and Reporting Processes
• Provide PCI SSC with access to the applicable SPoC Solutions or SPoC Elements
• Provide PCI SSC with access to supporting documentation to its SPoC Lab(s) for validation
• Authorize its SPoC Labs to submit resulting reports and related information to PCI SSC.
Solution Providers Solution Providers (for example, processors, acquirers or payment gateways) have overall responsibility for the design and implementation of specific Solutions. They must ensure that their Solutions satisfy all applicable SPoC Security Requirements, managing Solutions for their customers and/or managing corresponding responsibilities.
• Section 4, Evaluation and Reporting Processes
• Provide PCI SSC with access to the applicable SPoC Solutions or SPoC Elements
• Provide PCI SSC with access to supporting documentation to its SPoC Lab(s) for validation
• Authorize its SPoC Labs to submit resulting reports and related information to PCI SSC.
Solution Providers Solution Providers (for example, processors, acquirers or payment gateways) have overall responsibility for the design and implementation of specific Solutions. They must ensure that their Solutions satisfy all applicable SPoC Security Requirements, managing Solutions for their customers and/or managing corresponding responsibilities.
Added
p. 11
Note: Except as described in the SPoC Annex, only validated SCRP devices that are listed on the PCI PTS Approved Device List are permitted for use in validated SPoC Solutions. For details about the use of MSRs, see the SPoC Annex.
Magstripe Reader (MSR) Device Vendors To protect the Account Data read from magnetic stripe cards and deliver encrypted output to the payment processing systems, the MSR must conform with either:
• PCI PTS POI Modular Security Requirements
Note: The magnetic stripe reader must be listed as an approved PCI PTS device on the
PCI PTS Approved Device list with an SCR Approval Class;
• The security requirements identified in the SPoC Annex. During the SPoC Solution Evaluation process (see sections 3, 4 and 6) a SPoC Lab must validate the MSR against specific requirements in section 4 of the SPoC Annex.
When a MSR is used in a SPoC Solution, only the device(s) included in …
Magstripe Reader (MSR) Device Vendors To protect the Account Data read from magnetic stripe cards and deliver encrypted output to the payment processing systems, the MSR must conform with either:
• PCI PTS POI Modular Security Requirements
Note: The magnetic stripe reader must be listed as an approved PCI PTS device on the
PCI PTS Approved Device list with an SCR Approval Class;
• The security requirements identified in the SPoC Annex. During the SPoC Solution Evaluation process (see sections 3, 4 and 6) a SPoC Lab must validate the MSR against specific requirements in section 4 of the SPoC Annex.
When a MSR is used in a SPoC Solution, only the device(s) included in …
Added
p. 16
• MSRs that are listed by PCI SSC as approved devices (with the Approval Class SCR) in the PCI PTS POI Program and fully meet the Evaluation Module 4 (SRED) of the PCI PTS POI Security Requirements
• MSRs that are not listed by the PCI PTS POI Program but meet the security requirements listed in the SPoC Annex, Section 4, Non-PTS Listed MSR Security Requirements and Derived Test Requirements. Both PTS-listed MSRs (evaluated by a PTS Lab) and non-PTS-approved MSRs (evaluated by a SPoC Lab) must be evaluated using the PCI PTS POI test procedures as identified in the PCI PTS POI Derived Test Requirements. Note that PTS Technical FAQs on the Website may also apply to the MSR evaluation. Details for both PTS-listed and non-PTS approved MSRs are included on the List of Validated SPoC Solutions under “Solution Details” in each Solution for which the MSRs are validated. See …
• MSRs that are not listed by the PCI PTS POI Program but meet the security requirements listed in the SPoC Annex, Section 4, Non-PTS Listed MSR Security Requirements and Derived Test Requirements. Both PTS-listed MSRs (evaluated by a PTS Lab) and non-PTS-approved MSRs (evaluated by a SPoC Lab) must be evaluated using the PCI PTS POI test procedures as identified in the PCI PTS POI Derived Test Requirements. Note that PTS Technical FAQs on the Website may also apply to the MSR evaluation. Details for both PTS-listed and non-PTS approved MSRs are included on the List of Validated SPoC Solutions under “Solution Details” in each Solution for which the MSRs are validated. See …
Added
p. 19
Among other things, the VRA addresses the following topics:
For PCI SSC to review an Evaluation Report, the SPoC Lab must provide the PCI SSC with the following:
• The vendor-signed copy of the VRA
For PCI SSC to review an Evaluation Report, the SPoC Lab must provide the PCI SSC with the following:
• The vendor-signed copy of the VRA
Added
p. 21
8. PCI SCC counter-signs the AOV and sends a copy to the Vendor and the SPoC Lab.
9. PCI SSC adds the Solution to the List of Validated SPoC Solutions on the Website.
9. PCI SSC adds the Solution to the List of Validated SPoC Solutions on the Website.
Added
p. 22
Additionally, the Vendor must provide access to the following:
• All production-level, unobfuscated source code.
• All production-level, obfuscated code for all internally developed function, including bespoke or custom functionality developed by third parties.
Note: In some cases, it may not be possible for a Vendor or SPoC Solution or element to meet a specific requirement as stated. In such cases, the Vendor must clearly explain why the requirement cannot be met. The Vendor must also provide evidence to clearly show that the corresponding security objective is being met and that other functionality or methods are employed to provide similar assurance to that provided by the methods described in the requirement. Vendors should work with their SPoC Lab to determine what evidence is needed to satisfy a specific security objective or associated requirement.
• All production-level, unobfuscated source code.
• All production-level, obfuscated code for all internally developed function, including bespoke or custom functionality developed by third parties.
Note: In some cases, it may not be possible for a Vendor or SPoC Solution or element to meet a specific requirement as stated. In such cases, the Vendor must clearly explain why the requirement cannot be met. The Vendor must also provide evidence to clearly show that the corresponding security objective is being met and that other functionality or methods are employed to provide similar assurance to that provided by the methods described in the requirement. Vendors should work with their SPoC Lab to determine what evidence is needed to satisfy a specific security objective or associated requirement.
Added
p. 25
• Changes have been applied in a way that is consistent with the SPoC Security Requirements.
• The Solution continues to meet all applicable SPoC Security Requirements.
• The Vendor is capable of and demonstrably migrating merchants from unsupported COTS platforms.
• PCI SSC has been advised of any change that requires a change to the Listing on the Website, in accordance with this Program Guide.
• Changes to the documents described in Appendix D, Documentation Required for SPoC Solution Evaluation are provided to the SPoC Lab for review annually (12-month and 24- month checkpoints).
• The operational quality of the Monitoring/Attestation System has been assessed according to SPoC Test Requirements, Appendix B.
The Vendor must consider the impact of external threats and whether updates to the Solution are necessary to address these threats. The SPoC Lab submits the updated AOV, redlined Evaluation Report and any applicable documentation to the PCI SSC SPoC Program Manager using …
• The Solution continues to meet all applicable SPoC Security Requirements.
• The Vendor is capable of and demonstrably migrating merchants from unsupported COTS platforms.
• PCI SSC has been advised of any change that requires a change to the Listing on the Website, in accordance with this Program Guide.
• Changes to the documents described in Appendix D, Documentation Required for SPoC Solution Evaluation are provided to the SPoC Lab for review annually (12-month and 24- month checkpoints).
• The operational quality of the Monitoring/Attestation System has been assessed according to SPoC Test Requirements, Appendix B.
The Vendor must consider the impact of external threats and whether updates to the Solution are necessary to address these threats. The SPoC Lab submits the updated AOV, redlined Evaluation Report and any applicable documentation to the PCI SSC SPoC Program Manager using …
Added
p. 27
Table 2: Changes to Listed Solutions
Table 3: Changes to SPoC Elements within Listed Solutions Change Type Description Administrative Changes made to a listed Solution that have no impact on compliance with any of the SPoC Security Requirements, but where the List of Validated SPoC Solutions is updated to reflect the change. Examples of administrative changes include, but are not limited to, corporate identity changes and changes to Listing details, such as “Description.” For details, see Section 5.2.1, Administrative Changes for SPoC Solution Listings.
• Add/remove a PCI SSC-approved SCRP, MSR approved under the PCI PTS program with SCR Approval Class, or non-PTS approved MSR validated by a SPoC Lab (per the SPoC Annex) for use in the Solution
Change Type Description No Impact Change Any change that does not impact security functions or compliance with the SPoC Security Requirements, such as maintenance patches or routine key rotation. No Impact Changes are not …
Table 3: Changes to SPoC Elements within Listed Solutions Change Type Description Administrative Changes made to a listed Solution that have no impact on compliance with any of the SPoC Security Requirements, but where the List of Validated SPoC Solutions is updated to reflect the change. Examples of administrative changes include, but are not limited to, corporate identity changes and changes to Listing details, such as “Description.” For details, see Section 5.2.1, Administrative Changes for SPoC Solution Listings.
• Add/remove a PCI SSC-approved SCRP, MSR approved under the PCI PTS program with SCR Approval Class, or non-PTS approved MSR validated by a SPoC Lab (per the SPoC Annex) for use in the Solution
Change Type Description No Impact Change Any change that does not impact security functions or compliance with the SPoC Security Requirements, such as maintenance patches or routine key rotation. No Impact Changes are not …
Added
p. 28
Note: Administrative Changes are permissible only for Listed Solutions that have not expired.
Added
p. 28
3. If applicable, the Vendor completes a new VRA.
4. The SPoC Lab completes the change documentation and signs the AOV.
5. The SPoC Lab signs its concurrence on the AOV and forwards it, along with the change documentation (and new VRA if applicable) to PCI SSC.
6. PCI SSC sends the Change Fee invoice to the Vendor.
7. Upon payment of the invoice, PCI SSC reviews the submission.
• Add/remove a validated SCRP device, MSR approved under the PCI PTS program with SCR Approval Class, or non-PTS approved MSR (per the SPoC Annex) used in a Solution; or
2. The Vendor completes and submits a new VRA (if applicable) to the SPoC Lab.
3. The SPoC Lab evaluates the SPoC Security Requirements that are affected by the change.
4. The SPoC Lab completes the corresponding Change Impact template and produces a red-lined Evaluation Report documenting that the testing is complete per PCI SSC requirements.
5. The Vendor prepares …
4. The SPoC Lab completes the change documentation and signs the AOV.
5. The SPoC Lab signs its concurrence on the AOV and forwards it, along with the change documentation (and new VRA if applicable) to PCI SSC.
6. PCI SSC sends the Change Fee invoice to the Vendor.
7. Upon payment of the invoice, PCI SSC reviews the submission.
• Add/remove a validated SCRP device, MSR approved under the PCI PTS program with SCR Approval Class, or non-PTS approved MSR (per the SPoC Annex) used in a Solution; or
2. The Vendor completes and submits a new VRA (if applicable) to the SPoC Lab.
3. The SPoC Lab evaluates the SPoC Security Requirements that are affected by the change.
4. The SPoC Lab completes the corresponding Change Impact template and produces a red-lined Evaluation Report documenting that the testing is complete per PCI SSC requirements.
5. The Vendor prepares …
Added
p. 31
6. Upon payment of the invoice, PCI SSC reviews the submission.
2. The Vendor prepares the change documentation and signs the AOV (and new VRA, if applicable) and sends it to the SPoC Lab;
3. The SPoC Lab completes the Change Impact document and produces a red-lined Evaluation Report and document the testing completed per PCI SSC requirements;
4. The SPoC Lab signs its concurrence on the AOV and forwards it with the completed change documents, VRA (if applicable), and the red-lined Evaluation Report to PCI SSC;
5. PCI SSC sends a Change Fee invoice to the Vendor;
2. The Vendor prepares the change documentation and signs the AOV (and new VRA, if applicable) and sends it to the SPoC Lab;
3. The SPoC Lab completes the Change Impact document and produces a red-lined Evaluation Report and document the testing completed per PCI SSC requirements;
4. The SPoC Lab signs its concurrence on the AOV and forwards it with the completed change documents, VRA (if applicable), and the red-lined Evaluation Report to PCI SSC;
5. PCI SSC sends a Change Fee invoice to the Vendor;
Added
p. 32
Table 4 summarizes the change documentation.
• Current VRA b a The change impact documents in Appendices C1 and C2 are mandatory for the SPoC Lab when submitting administrative, delta and designated changes to PCI SSC on behalf of Solution Providers. b If applicable.
Note: The Vendor pays all SPoC Solution Evaluation fees directly to the SPoC Lab. The SPoC Lab and the Vendor negotiate these fees. PCI SSC sends an invoice to the Vendor for all validation maintenance fees, and the Vendor pays these fees directly to PCI SSC. To accept and list a change, a Solution must already be listed and not have reached the expiry date.
For any change affecting the List of Validated SPoC Solutions, the invoiced fee must be received by PCI SSC before the change can be reviewed, accepted, and added to the List of Validated SPoC Solutions. Upon acceptance, PCI SSC signs and returns a copy …
• Current VRA b a The change impact documents in Appendices C1 and C2 are mandatory for the SPoC Lab when submitting administrative, delta and designated changes to PCI SSC on behalf of Solution Providers. b If applicable.
Note: The Vendor pays all SPoC Solution Evaluation fees directly to the SPoC Lab. The SPoC Lab and the Vendor negotiate these fees. PCI SSC sends an invoice to the Vendor for all validation maintenance fees, and the Vendor pays these fees directly to PCI SSC. To accept and list a change, a Solution must already be listed and not have reached the expiry date.
For any change affecting the List of Validated SPoC Solutions, the invoiced fee must be received by PCI SSC before the change can be reviewed, accepted, and added to the List of Validated SPoC Solutions. Upon acceptance, PCI SSC signs and returns a copy …
Added
p. 36
PCI SSC reviews each Evaluation Report after the vendor pays the acceptance fee. PCI SSC first screens the submission to ensure that it is complete. If the submission is complete,
Added
p. 38
Table 5 describes the Solution Identifier fields.
• MSRs Supported: Identifies the PTS-approved or non-PTS approved MSR that has been validated by the SPoC Lab for use with the Solution, and the expiry date of the approval for this device. If the expiry date is in the past, this will be denoted by a color change. If the device is PTS-approved, a link will be provided to the appropriate entry on the PCI PTS Approved Device List on the Website. The Expiry date for a non-PTS approved MSR is the same as the expiry date of the SPoC Solution in which that non-PTS approved MSR is incorporated, and the non-PTS approved MSR must be re-evaluated each time the SPoC Solution is re-evaluated.
Annual Checkpoint Due Annual Checkpoint Due is the date that the Solution is due for its annual (12- or 24-month) checkpoints by a SPoC Lab. Orange or Red dates in …
• MSRs Supported: Identifies the PTS-approved or non-PTS approved MSR that has been validated by the SPoC Lab for use with the Solution, and the expiry date of the approval for this device. If the expiry date is in the past, this will be denoted by a color change. If the device is PTS-approved, a link will be provided to the appropriate entry on the PCI PTS Approved Device List on the Website. The Expiry date for a non-PTS approved MSR is the same as the expiry date of the SPoC Solution in which that non-PTS approved MSR is incorporated, and the non-PTS approved MSR must be re-evaluated each time the SPoC Solution is re-evaluated.
Annual Checkpoint Due Annual Checkpoint Due is the date that the Solution is due for its annual (12- or 24-month) checkpoints by a SPoC Lab. Orange or Red dates in …
Added
p. 50
Note: For details about required documentation for SPoC Solution submissions that include MSRs, see the SPoC Annex.
Added
p. 52
• Written procedures for manually processed events must exist and be demonstrably in use.
• These procedures must cover events where staff relied upon for such determinations are unavailable.
• Events must be escalated immediately for manual review and actioned within 48 hours.
• Automated systems must be in place to disable any further payment processing from systems when an event has not been actioned for 48 hours.
• These procedures must cover events where staff relied upon for such determinations are unavailable.
• Events must be escalated immediately for manual review and actioned within 48 hours.
• Automated systems must be in place to disable any further payment processing from systems when an event has not been actioned for 48 hours.
Added
p. 53
d) Temporarily stop transaction processing to update obsolete solution components (either internal or third-party dependencies).
Added
p. 55
Incident Response Procedures Physical Security A.5.1 Documented policies and procedures must exist for physically protecting the system components and limiting access to the monitoring environment.
Added
p. 56
• Definition of each element in the version scheme. For example, the type of change can be major, minor, security, or maintenance release.
Added
p. 57
Implementation guide Application Security Requirement D15 Develop, maintain, and disseminate an implementation guide that:
Added
p. 59
Version Number Format The vendor sets the application version number format, which may be comprised of several elements. The versioning method must fully describe the application version number format, including the following:
• Version scheme format
Customers and integrators/resellers must be able to determine what changes are included in the version of the application they are running.
• Version scheme format
Customers and integrators/resellers must be able to determine what changes are included in the version of the application they are running.
Added
p. 61
Table 6 lists the terms used in this Program Guide and their meanings. Terms not listed in
Table 6 may be found in the documents listed in Section 1.2, Related Publications. All of these documents are available on the Website.
• Received the corresponding fee and all documentation required with respect to that SPoC Solution as part of the SPoC Program; and
• The respective compliant Solution Evaluation Report is correct as to form (all applicable documents completed);
• The SPoC Lab determined that the Solution is eligible to be a validated Solution;
• The SPoC Lab reported the compliance of the respective SPoC Solution with SPoC Program requirements; and
MSR Acronym for Magnetic Stripe Reader (or Magstripe Reader). See SPoC Annex for details.
Non-PTS approved MSR A Magnetic Stripe Reader that has not undergone evaluation and approval by a PTS Lab in accordance with the PCI SSC PIN Transaction Security program. Non- PTS approved MSRs are …
Table 6 may be found in the documents listed in Section 1.2, Related Publications. All of these documents are available on the Website.
• Received the corresponding fee and all documentation required with respect to that SPoC Solution as part of the SPoC Program; and
• The respective compliant Solution Evaluation Report is correct as to form (all applicable documents completed);
• The SPoC Lab determined that the Solution is eligible to be a validated Solution;
• The SPoC Lab reported the compliance of the respective SPoC Solution with SPoC Program requirements; and
MSR Acronym for Magnetic Stripe Reader (or Magstripe Reader). See SPoC Annex for details.
Non-PTS approved MSR A Magnetic Stripe Reader that has not undergone evaluation and approval by a PTS Lab in accordance with the PCI SSC PIN Transaction Security program. Non- PTS approved MSRs are …
Added
p. 63
SCRP Acronym for Secure Card Reader
• PIN. A physical card reader that has been assessed compliant to the PCI PTS SCRP Approval Class and is listed on the PTS approval website. See the SPoC Security Requirements for additional details.
• PIN. A physical card reader that has been assessed compliant to the PCI PTS SCRP Approval Class and is listed on the PTS approval website. See the SPoC Security Requirements for additional details.
Added
p. 64
• Testing and validation of the above with optional MSR(s), including evaluation of any non-PTS Approved MSRs used in the SPoC Solution;
Validated SPoC Solution A SPoC Solution that has been assessed by a SPoC Lab to be in scope for the SPoC Program and to have met all of the SPoC Security Requirements and then Accepted by PCI SSC, so long as such Acceptance has not been revoked, suspended, withdrawn, or terminated.
• Makes available on the Website.
Validated SPoC Solution A SPoC Solution that has been assessed by a SPoC Lab to be in scope for the SPoC Program and to have met all of the SPoC Security Requirements and then Accepted by PCI SSC, so long as such Acceptance has not been revoked, suspended, withdrawn, or terminated.
• Makes available on the Website.
Removed
p. 5
• Software-based PIN Entry on COTS (SPoC) Solution Overview (Section 1.1)
• Assessor Quality Management Program (Section 6.3)
• Assessor Quality Management Program (Section 6.3)
Modified
p. 5
• Evaluation and Reporting Process (Section 4)
• Evaluation and Reporting Processes (Section 4)
Modified
p. 5
• Maintaining a Validated SPoC Solution Listing (Section 5)
• Maintaining a Validated Solution Listing (Section 5)
Removed
p. 6
The following diagram illustrates each element of the SPoC Solution and the SPoC Program stakeholder that validates each respective element. See the “Overview” and “Software-based PIN Entry on COTS devices” sections in the SPoC Security Requirements for additional details.
Modified
p. 6 → 5
• PIN (SCRP) devices: Evaluated by a PCI-recognized PTS Laboratory (PTS Lab) per the PCI PTS POI Modular Security Requirements (version 5.1 or later) and separately listed on the list of Approved PTS Devices on the Website.
• Secure Card Reader-PIN (SCRP) device: A physical card reader that has been Evaluated by a PCI-recognized PIN transaction security (PTS) laboratory (PTS Lab) per the PCI PTS POI Modular Security Requirements (version 5.1 or later) and listed separately on the PCI PTS Approved Device List on the Website.
Modified
p. 6
• PIN Cardholder Verification Method (CVM) Application: Evaluated by a PCI-recognized SPoC Laboratory (SPoC Lab) per the SPoC Security Requirements and SPoC Testing Requirements as part of their overall SPoC Solution Evaluation. PIN CVM Applications are listed only as part of the SPoC Solutions in which they have been validated for use under the SPoC Programi.e., PIN CVM Applications are not separately listed on the Website.
• PIN Cardholder Verification Method (CVM) Application: The PIN Cardholder Verification Application that has been Evaluated by a PCI-recognized SPoC Lab per the SPoC Security Requirements and SPoC Testing Requirements as part of their SPoC Solution Evaluation. PIN CVM Applications are listed only as part of the SPoC Solutions in which they have been validated for use under the SPoC ProgramPIN CVM Applications are not listed separately on the Website.
Modified
p. 6
• Monitoring/Attestation System: Evaluated by a SPoC Lab per the SPoC Security Requirements and SPoC Testing Requirements as part of their overall SPoC Solution Evaluation. Monitoring/Attestation Systems are listed only as part of the SPoC Solutions in which they have been validated for use under the SPoC Programi.e., Monitoring/Attestation Systems are not separately listed on the Website.
• Monitoring/Attestation System: Evaluated by a SPoC Lab per the SPoC Security Requirements and SPoC Testing Requirements as part of their SPoC Solution Evaluation. Monitoring/Attestation Systems are listed only as part of the SPoC Solutions in which they have been validated for use under the SPoC Programi.e., Monitoring/Attestation Systems are not separately listed on the Website.
Modified
p. 6
• Back-end Monitoring Environment: The environment in which the Monitoring/Attestation System resides and operates must be assessed by a SPoC Lab for compliance with Appendix A of the SPoC Security Requirements, “Monitoring Environment Basic Protections.”
• Back-end Monitoring Environment: The environment in which the Monitoring/Attestation System resides and operates must be assessed by a SPoC Lab for compliance with SPoC Security Requirements, Appendix A, “Monitoring Environment Basic Protections.” Back-end Monitoring Environments are not listed on the Website.
Modified
p. 6
Note: If PAN or SAD is stored, processed or transmitted in the Back-end Monitoring Environment, that environment is considered a cardholder data environment (CDE) and must be assessed and validated by a QSA Company to PCI DSS, including DSS Appendix A3, “Designated Entities Supplemental Validation (DESV).”
Note: If the Primary Account Number (PAN) or Sensitive Authentication Data (SAD) is stored, processed or transmitted in the Back-end Monitoring Environment, that environment is considered a Cardholder Data Environment (CDE) and must be assessed and validated by a Qualified Security Assessor (QSA) Company to the PCI DSS, including Appendix A3 thereto, “Designated Entities Supplemental Validation (DESV).”
Modified
p. 6
Note: If PIN processing is performed in the Back-end Monitoring Environment, a full PIN audit in accordance with the PCI PIN Security Requirements is also required.
Note: If PIN processing is performed in the Back-end Monitoring Environment, a full PIN audit is required in accordance with the PCI PIN Security Requirements.
Removed
p. 8
Document name Description Payment Card Industry (PCI) Software-based PIN Entry on COTS Security Requirements (“SPoC Security Requirements”) The SPoC Security Requirements defines the specific technical security requirements for the Solution, PIN CVM Application and supporting Monitoring/Attestation System and Back-end Monitoring Environment Payment Card Industry (PCI) Software-based PIN Entry on COTS Test Requirements (“SPoC Test Requirements”) The SPoC Test Requirements lists and defines the specific testing and evaluation procedures, required to evaluate the Solution against the SPoC Security Requirements.
SPoC Solution Attestation of Validation (“AOV”) The AOV is a form for SPoC Labs to attest to the results of a SPoC Solution Evaluation, as documented in the SPoC Solution Attestation of Validation.
SPoC Evaluation Report template The Evaluation Report template is a form for SPoC Labs to document the results of a SPoC Solution Evaluation.
Vendor Release Agreement (“VRA”) The VRA establishes the terms and conditions under which validated Solutions are Accepted and listed …
SPoC Solution Attestation of Validation (“AOV”) The AOV is a form for SPoC Labs to attest to the results of a SPoC Solution Evaluation, as documented in the SPoC Solution Attestation of Validation.
SPoC Evaluation Report template The Evaluation Report template is a form for SPoC Labs to document the results of a SPoC Solution Evaluation.
Vendor Release Agreement (“VRA”) The VRA establishes the terms and conditions under which validated Solutions are Accepted and listed …
Modified
p. 8
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, version 5.1
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, version 5.1 (“PCI PTS POI Security Requirements”)
Modified
p. 8
• Payment Card Industry (PCI) PIN Security Requirements and Test Procedures 1.3 Updates to Documents and Security Requirements This Program Guide may be modified as necessary to align with updates to the SPoC Program. Additionally, PCI SSC provides interim updates to the PCI community through a variety of means, including required Assessor or Lab training, e-mail bulletins and newsletters, frequently asked questions and other communication methods.
• Payment Card Industry (PCI) PIN Security Requirements and Test Procedures 1.3 Updates to Documents and Security Requirements This Program Guide may be modified to reflect updates to the SPoC Program. Additionally,
Modified
p. 8
Technical FAQs are updated on a regular basis to add clarification to SPoC Program requirements and may also address new security threats that have arisen. As such, technical FAQs are generally effective immediately upon publication.
Technical FAQs are updated on a regular basis to clarify the SPoC Program requirements and may also address new security threats. As such, technical FAQs are generally effective immediately upon publication. PCI SSC reserves the right to change, amend, or withdraw security requirements, training, and/or other requirements at any time.
Modified
p. 9
Note: SPoC Vendors are responsible for assuring compliance with all applicable laws, statutes, regulations and rules (including without limitation, privacy laws) applicable to their activities as SPoC Vendors and any related services or products.
Note: SPoC Vendors are responsible for assuring compliance with all applicable laws, statutes, regulations and rules (including without limitation, privacy laws), and any related services or products.
Modified
p. 9 → 10
The Solution Provider submits a Monitoring/Attestation System for evaluation to an independent SPoC Lab. Per the SPoC Security Requirements and SPoC Test Requirements, Monitoring/Attestation System vendors must provide documentation describing the secure operation and administration of such applications.
The Solution Provider submits a Monitoring/Attestation System for Evaluation to an independent SPoC Lab. Per the SPoC Security Requirements and SPoC Test Requirements, Monitoring/Attestation System vendors must provide documentation describing the secure operation and administration of such applications.
Removed
p. 10
Third-Party Service Providers are not eligible for listing in regard to the SPoC Program.
Note: Only validated Secure Card Reader PIN (SCRP) devices listed on the PCI SSC’s list of PTS Approved PTS Device on the Website are permitted for use in validated Solutions
Note: Only validated Secure Card Reader PIN (SCRP) devices listed on the PCI SSC’s list of PTS Approved PTS Device on the Website are permitted for use in validated Solutions
Modified
p. 10
When the Monitoring/Attestation System resides in a Back-end Monitoring Environment provider’s CDE, each must additionally be validated by a QSA Company to PCI DSS, including DSS Appendix A3, “Designated Entities Supplemental Validation (DESV).” If PAN or SAD is not present in the Monitoring/Attestation System’s environment and it is not part of the Back-end Monitoring Environment provider’s existing CDE, a SPoC Lab must validate that the environment complies with the logical and physical security requirements as defined in SPoC Security Requirements …
When a Monitoring/Attestation System resides in a Back-end Monitoring Environment provider’s CDE, each Monitoring/Attestation System must also be validated by a QSA Company according to the PCI DSS, including Appendix A3, “Designated Entities Supplemental Validation (DESV).” If PAN or SAD is not present in the Monitoring/Attestation System’s environment and it is not part of the Back-end Monitoring Environment provider’s existing CDE, a SPoC Lab must validate that the environment complies with the logical and physical security requirements defined in SPoC …
Removed
p. 11
Unless also qualified as a SPoC Lab, a PTS Labs is not authorized by PCI SSC to perform SPoC Solution Evaluations.
Modified
p. 11 → 12
• Performing Evaluations of PIN CVM Applications, Monitoring/Attestation Systems, Back-end Monitoring Environments and overall Solutions in accordance with the SPoC Security Requirements and SPoC Test Requirements.
• Evaluating PIN CVM Applications, Monitoring/Attestation Systems, Back-end Monitoring Environments and overall Solutions in accordance with the SPoC Security Requirements and SPoC Test Requirements
Modified
p. 11 → 12
• Providing an opinion regarding whether the Solution meets the SPoC Security Requirements.
• Providing an opinion regarding whether the Solution meets the SPoC Security Requirements
Modified
p. 11 → 12
• Documenting each such Evaluation in an Evaluation Report using the applicable reporting template(s).
• Documenting each such Evaluation in an Evaluation Report using the applicable reporting template(s)
Modified
p. 11 → 12
• Providing adequate documentation within the Evaluation Report to demonstrate the Solution’s compliance with the SPoC Security Requirements.
• Providing sufficient evidence within the Evaluation Report to demonstrate that the Solution complies with the SPoC Security Requirements
Modified
p. 11 → 12
• Where applicable, submitting the applicable Evaluation Report and/or any change submission documentation to PCI SSC, along with the applicable SPoC Solution Attestation of Validation (AOV) signed by both the SPoC Lab and Vendor.
• Where applicable, submitting the applicable Evaluation Report and/or any change submission documentation to PCI SSC, along with the applicable SPoC Solution Attestation of Validation (AOV) signed by both the SPoC Lab and Vendor
Modified
p. 11 → 12
• Maintaining an internal quality assurance process for their SPoC Solution Evaluation efforts.
• Maintaining an internal quality assurance process for the SPoC Solution Evaluation efforts.
Modified
p. 11 → 13
PTS Labs are authorized by PCI SSC to perform evaluations of SCRP devices; only PTS Labs are authorized by PCI SSC to evaluate SCRP devices used in SPoC Solutions.
PTS Labs are authorized by PCI SSC to perform Evaluations of SCRP devices; only PTS Labs are authorized by PCI SSC to Evaluate SCRP devices used in SPoC Solutions.
Modified
p. 11 → 13
Note: SCRP device evaluation by a PTS Lab is a separate process from the validation of a SPoC Solution; the SPoC Solution Evaluation validates whether or not a given Solution (which may include multiple SCRP devices) is in compliance with the SPoC Security Requirements.
Note: SCRP device Evaluation by a PTS Lab is a separate process from the validation of a SPoC Solution; the SPoC Solution Evaluation validates whether a given Solution (which may include multiple SCRP devices) is in compliance with the SPoC Security Requirements.
Modified
p. 11 → 13
• Documenting each SCRP device evaluation in a report.
• Documenting each SCRP device Evaluation in a report
Modified
p. 11 → 13
• Providing adequate documentation within the applicable report to demonstrate the compliance with the PCI PTS POI Modular Security Requirements.
• Providing adequate documentation within the applicable report to demonstrate compliance with the PCI PTS POI Modular Security Requirements.
Modified
p. 11 → 13
• Where applicable, submitting applicable change submissions to PCI SSC, along with the applicable documentation signed by both the PTS Lab and SCRP device Vendor.
• Where applicable, submitting applicable change submissions to PCI SSC, along with the applicable documentation signed by both the PTS Lab and SCRP device Vendor
Modified
p. 11 → 13
• Maintaining an internal quality assurance process for their evaluation efforts.
• Maintaining an internal quality assurance process for their Evaluation efforts A PTS Lab is not authorized by PCI SSC to perform SPoC Solution Evaluations unless it is also qualified by PCI SSC as a SPoC Lab.
Modified
p. 11 → 13
• Managing compliance enforcement programs (requirements, mandates or dates for compliance)
• Managing compliance enforcement programs (requirements, mandates, or compliance dates)
Removed
p. 12
Note: PCI SSC does not evaluate, assess or validate SPoC Elements or SPoC Solutions for SPoC compliance; evaluation and validation are the roles of the SPoC Labs. Listing of a Solution on the List of Validated SPoC Solutions signifies only that the applicable SPoC Lab has determined that it complies with the SPoC Security Requirements, that the SPoC Lab has submitted a corresponding Evaluation Report to PCI SSC and that the report, as submitted to PCI SSC, has satisfied all requirements of the PCI SSC for Evaluation Reports as of the time of PCI SSC's review.
Modified
p. 12 → 14
• Maintains a centralized repository for all evaluation reports for Solutions listed on the Website;
• Maintains a centralized repository for all Evaluation reports for Solutions listed on the Website;
Removed
p. 13
Element Program Guidance SCRP Secure Card Reader
• PIN (SCRP) is a PTS approval class that supports PIN entry on COTS devices in accordance with the PCI PTS POI Modular Security Requirements (version 5.1 or higher). PTS device approval helps to ensure that the device has been evaluated and meets industry recognized requirements for payment acceptance devices. SCRPs are listed on the list of Approved PTS Devices on the Website.
The Solution must only permit the use of SCRPs listed on the Website.
• Refer to Module 6, “Secure Card Reader (SCRP),” in the SPoC Security Requirements;
• Refer to the PCI PTS POI Modular Security Requirements (version 5.1 or higher) and supporting documentation in the Document Library on the Website.
Obtaining and maintaining PTS Program device approval is the responsibility of the secure-card reader vendor. For those devices required to be approved, such approval is a prerequisite for the devices being evaluated as part …
• PIN (SCRP) is a PTS approval class that supports PIN entry on COTS devices in accordance with the PCI PTS POI Modular Security Requirements (version 5.1 or higher). PTS device approval helps to ensure that the device has been evaluated and meets industry recognized requirements for payment acceptance devices. SCRPs are listed on the list of Approved PTS Devices on the Website.
The Solution must only permit the use of SCRPs listed on the Website.
• Refer to Module 6, “Secure Card Reader (SCRP),” in the SPoC Security Requirements;
• Refer to the PCI PTS POI Modular Security Requirements (version 5.1 or higher) and supporting documentation in the Document Library on the Website.
Obtaining and maintaining PTS Program device approval is the responsibility of the secure-card reader vendor. For those devices required to be approved, such approval is a prerequisite for the devices being evaluated as part …
Removed
p. 14
• SPoC Test Requirements Module 2, “PIN CVM Application Requirements.” A PIN CVM Application (and its supporting Monitoring/Attestation System) may be used in multiple Solutions, but it is considered a SPoC Element of only the specific Solution(s) for which it has been tested and validated in accordance with SPoC Program requirements.
Modified
p. 14 → 16
• SPoC Security Requirements, including Module 2, “PIN Cardholder Verification Method (CVM) Application”;
• SPoC Security Requirements, including Module 2, “PIN Cardholder Verification Method (CVM) Application”
Modified
p. 14 → 16
• SPoC Security Requirements Appendix D, “Application Security Requirements”; and
• SPoC Security Requirements, Appendix D, “Application Security Requirements”
Modified
p. 14 → 16
Monitoring/Atte station System (“Monitoring System”) Monitoring/Attestation Systems must be validated by a SPoC Lab against:
Modified
p. 14 → 16
• Monitoring/Attestation”;
• Monitoring/Attestation”
Modified
p. 14 → 16
• SPoC Security Requirements Module 4, “Solution Integration Requirements”; and
• SPoC Security Requirements, Module 4, “Solution Integration Requirements”
Modified
p. 14 → 16
• SPoC Test Requirements Module 3 “Back-end System Monitoring/Attestation Requirements.” A Monitoring/Attestation System (and the PIN CVM Application it supports) may be used in multiple Solutions, but it is considered a SPoC Element of only the specific Solution(s) for which it has been tested and validated in accordance with SPoC Program requirements.
• SPoC Test Requirements, Module 3, “Back-end System Monitoring/Attestation Requirements” A Monitoring/Attestation System (and the PIN CVM Application it supports) may be used in multiple Solutions. However, the Monitoring/Attestation System is considered a SPoC Element only of the specific Solution(s) for which it has been tested and validated in accordance with SPoC Program requirements.
Modified
p. 14 → 16
Back-end Monitoring Environment The Back-end Monitoring Environment must undergo validation per all requirements in SPoC Security Requirements, including Module 5, “Back-end Systems
• Processing,” and Security Requirements Appendix A, “Monitoring Environment Basic Protections.”
• Processing,” and Security Requirements Appendix A, “Monitoring Environment Basic Protections.”
Back-end Monitoring Environment The Back-end Monitoring Environment must be validated against all requirements in SPoC Security Requirements, including Module 5, “Back-end Systems
• Processing,” and Security Requirements Appendix A, “Monitoring Environment Basic Protections.”
• Processing,” and Security Requirements Appendix A, “Monitoring Environment Basic Protections.”
Modified
p. 14 → 16
• If PAN or SAD is present anywhere in the Back-end Monitoring Environment, then PCI DSS plus DESV compliance as validated by a QSA is instead required. In such cases, the Vendor’s PCI DSS Attestation of Compliance (AOC) would be provided to the SPoC Lab during the SPoC Solution Evaluation as evidence of a compliant Back-end Monitoring Environment.
• If PAN or SAD is present anywhere in the Back-end Monitoring Environment, then PCI DSS plus DESV compliance as validated by a QSA is instead required. In such cases, the Vendor’s PCI DSS Attestation of Compliance (AOC) would be provided to the SPoC Lab during the SPoC Solution Evaluation as evidence of a compliant Back-end Monitoring Environment. Note: If the Solution Provider cannot meet DESV requirements at the point of an initial SPoC Solution validation, the Solution Provider must …
Modified
p. 14 → 16
• If PIN processing (e.g., decryption or translation) is performed in the Back- end Monitoring Environment, a full PIN audit in accordance with the PCI PIN Security Requirements and Test Procedures and PCI PIN Security Test Requirements is also required.
• If PIN processing (e.g., decryption or translation) is performed in the Back-end Monitoring Environment, a full PIN audit in accordance with the PCI PIN Security Requirements and Test Procedures and PCI PIN Security Test Requirements is also required.
Removed
p. 15
Note: The process for developing and testing Solutions
•including guidance for implementing requirements, testing and validating compliance with each requirement
•is defined within the SPoC Security Requirements and SPoC Test Requirements.
•including guidance for implementing requirements, testing and validating compliance with each requirement
•is defined within the SPoC Security Requirements and SPoC Test Requirements.
Modified
p. 15 → 17
• PCI PIN validation by a PCI PIN auditor approved by one of the PCI SSC brands SPoC Labs shall request evidence of such validations, verify they are current and produce evidence during the submission of a SPoC Evaluation Report according to SPoC Test Requirements E1 and E2.
• PCI PIN validation by a PCI PIN auditor approved by one of the Participating Payment Brands to perform assessments of PIN-processing environments SPoC Labs shall request evidence of such validations, verify they are current, and produce evidence when submitting a SPoC Evaluation Report according to SPoC Test Requirements E1 and E2.
Modified
p. 15 → 17
Before starting a SPoC Solution Evaluation (Evaluation), all involved parties involved are encouraged to take the following preparatory actions:
Modified
p. 15 → 17
• Review the requirements of both the SPoC Security Requirements and SPoC Test Requirements, and all related documentation located on the Website.
• Review the SPoC Security Requirements, SPoC Test Requirements, and all related documentation located on the Website.
Modified
p. 15 → 17
• Determine/assess the Solution’s readiness to comply with the SPoC Security Requirements:
• Determine the Solution’s readiness to comply with the SPoC Security Requirements:
Modified
p. 15 → 17
• Perform a gap analysis between security functionality and the SPoC Security Requirements;
• Perform a gap analysis between security function and the SPoC Security Requirements;
Modified
p. 15 → 17
• Solution Providers are responsible for ensuring that the various elements used as parts of their Solutions are each compliant with all applicable SPoC Security Requirements, and that they have appropriate agreements in place with the providers and vendors of such elements to ensure proper information disclosures if required under the Vendor Release Agreement.
• Solution Providers are responsible for ensuring that the various elements used as parts of their Solutions are each compliant with all applicable SPoC Security Requirements; and that the appropriate agreements are in place with the providers and vendors of these elements to ensure proper information disclosures if required under the Vendor Release Agreement.
Modified
p. 15 → 18
Note: All completed Evaluation-related materials such as manuals, install guides, the Vendor Release Agreement and all other materials related to the Evaluation must be delivered to the SPoC Lab performing the Evaluation, not to PCI SSC.
Note: All completed Evaluation materials, such as manuals, install guides, and the Vendor Release Agreement, must be delivered to the SPoC Lab performing the Evaluation•not to PCI SSC.
Removed
p. 16
• If PCI SSC reviews any part of the submission more than once, providing comments back to the SPoC Lab to address each time, this will increase the length of time for the review process.
Modified
p. 16 → 18
• How close the candidate Solution or Element is to being compliant with SPoC Program requirements at the start of the Evaluationcorrections necessary to achieve compliance will delay validation.
• Candidate Solution or element initial level of compliance with the SPoC Program requirements •more corrections means a longer review and validation.
Modified
p. 16 → 18
• Prompt payment of the fees due to PCI SSCPCI SSC will not commence review of the submission until the applicable fee has been paid.
• Prompt payment of fees to PCI SSC
•PCI SSC will not start the review process until the applicable fees are paid.
•PCI SSC will not start the review process until the applicable fees are paid.
Modified
p. 16 → 18
• Quality of the SPoC Lab's submission to PCI SSC:
• Quality of the SPoC Lab's Evaluation Report submitted to PCI SSC. For example:
Modified
p. 16 → 18
• Incomplete submissions or those containing errors
•for example, missing, incomplete or unsigned documents •will result in delays in the review process.
•for
• Incomplete submissions or errors. For example, missing, incomplete or unsigned documents will delay the review and acceptance process.
Modified
p. 16 → 18
Any Evaluation timeframes provided by a SPoC Lab should be considered estimates, since they may be based on the assumption that the candidate Solution or Element is able to successfully meet all SPoC Program requirements quickly. If problems are found during the review or acceptance processes, discussions between the SPoC Lab, the Vendor and/or PCI SSC may be required. Such discussions may significantly impact review times and cause delays and/or may even cause the review to end prematurelyfor example, if …
Any Evaluation completion dates that the SPoC Lab provides should be considered estimates. The SPoC Lab may base the completion date on the assumption that the candidate Solution or Element will meet all SPoC Program requirements quickly. If problems arise during the review or acceptance process, discussions between the SPoC Lab, the Vendor and PCI SSC may delay or end the Evaluation prematurely. For example, an Evaluation may end if the Vendor decides not to make the changes necessary to …
Modified
p. 16 → 18
Note: See Section 6.1, “Evaluation Report Acceptance, Issuance of Approval Overview” for details on PCI SSC review timeframes.
Note: For details about PCI SSC review times, see Section 6.1, Evaluation Report Acceptance, Issuance of Approval Overview.
Modified
p. 16 → 19
• Covers confidentiality issues;
• Confidentiality issues
Modified
p. 16 → 19
• Covers the Vendor’s agreement to SPoC Program requirements, policies and procedures;
• Vendor’s agreement with the SPoC Program requirements, policies, and procedures
Modified
p. 16 → 19
• Gives permission to the Vendor’s SPoC Lab to release Evaluation Reports, AOVs and related materials to PCI SSC for review; and
• Permission for the Vendor’s SPoC Lab to release Evaluation Reports, AOVs, and related materials to PCI SSC for review
Modified
p. 16 → 19
• Requires Vendors to adopt and comply with industry standard Vulnerability Handling Policies.
• Vendor’s agreement to adopt and comply with industry standard Vulnerability Handling Policies.
Removed
p. 17
• The SPoC Lab must provide to PCI SSC the Vendor’s signed copy of the then-current VRA, along with the initial Evaluation Report (and AOV, as applicable) submitted to PCI SSC in connection with that Evaluation.
Modified
p. 17 → 19
• So long as an executed copy of the then-current VRA is on file with PCI SSC for the relevant Vendor, the SPoC Lab is not required to re-submit the same VRA with each subsequent Evaluation Report (or AOV, as applicable) for the same Vendor.
• The initial Evaluation Report (and AOV, if applicable) that was submitted to PCI SSC in connection with that Evaluation While an executed copy of the VRA is on file with PCI SSC for the respective Vendor, the SPoC Lab is not required to resubmit the same VRA with each subsequent Evaluation Report (or AOV, if applicable) for the same Vendor.
Modified
p. 17 → 19
The Portal is also used by PCI SSC to track communications relating to a particular submission.
The Portal is also used by PCI SSC to track communications relating to a submission.
Modified
p. 17 → 20
Note: All Evaluation-related fees are payable directly to the Lab (these fees are negotiated between the Lab and its customers).
Note: All Evaluation-related fees are payable directly to the Lab (these fees are negotiated between the Lab and its customers). PCI SSC will bill the Vendor for all Acceptance Fees, and the Vendor will pay these fees directly to PCI SSC.
Modified
p. 17 → 20
There are no annual recurring PCI SSC fees associated with the Acceptance of a SPoC Solution or SPoC Element. There are, however, PCI SSC fees associated with Vendor delays in annual revalidation of validated Solutions. Please see the Website for more information.
There are no annual recurring PCI SSC fees associated with the Acceptance of a SPoC Solution or SPoC Element. There are, however, PCI SSC fees associated with Vendor delays in annual revalidation of a Validated SPoC Solution. Please see the Website for more information.
Modified
p. 18 → 21
2. The Vendor provides the SPoC Lab with access to all SPoC Elements to be used in the Solution to be evaluated, as well as associated manuals and other required documentation, including but not limited to the SPoC Vendor’s signed Vendor Release Agreement. See Section 3.3 for additional required documentation and materials. The SPoC Lab may also require access to the Back-end Monitoring Environment in order to validate the Monitoring/Attestation System functionality.
2. The Vendor provides the SPoC Lab with access to all SPoC Elements to be used in the Solution to be evaluated, including the VRA, associated manuals, and other required documentation. For information about required documentation and materials, see Section 3.3, Required Documentation for additional required documentation and materials. The SPoC Lab may also require access to the Back-end Monitoring Environment in order to validate the Monitoring/Attestation System functionality.
Modified
p. 18 → 21
If PAN or SAD is not present in the Monitoring/Attestation System’s environmenti.e., it is not part of the Back-end Monitoring Environment provider’s existing CDEthe environment must comply with the logical and physical security requirements as defined in the SPoC Security Requirements Appendix A, “Monitoring Environment Basic Protections.”
If PAN or SAD is not present in the Monitoring/Attestation System’s environment (i.e., it is not part of the Back-end Monitoring Environment provider’s existing CDE), the environment must comply with the logical and physical security requirements defined in the SPoC Security Requirements, Appendix A, “Monitoring Environment Basic Protections.”
Modified
p. 18 → 21
3. The SPoC Lab performs the SPoC Solution Evaluation, including evaluation of security functions and features, to determine whether the candidate Solution and its associated elements comply with the SPoC Security Requirements and are validated in accordance with the SPoC Test Requirements.
3. The SPoC Lab performs the SPoC Solution Evaluation, including Evaluation of security functions and features. The Evaluation determines whether the candidate Solution and its associated elements comply with the SPoC Security Requirements. The Solution and elements are validated in accordance with the SPoC Test Requirements.
Modified
p. 18 → 21
5. If the SPoC Lab determines that the Solution is compliant with the applicable SPoC Security Requirements, the SPoC Lab submits corresponding Evaluation Report and AOV (for each Solution) along with the Vendor’s signed VRA and any other requested documentation to PCI SSC in accordance with applicable PCI templates, guidance and instructions.
5. If the SPoC Lab determines that the Solution complies with the applicable SPoC Security Requirements, the SPoC Lab submits the corresponding Evaluation Report and AOV (for each Solution), the Vendor’s signed VRA, and any other requested documentation to PCI SSC in accordance with applicable PCI SSC templates, guidance and instructions.
Modified
p. 18 → 21
6. If required, remedial activities are performed by the Vendor to address security objectives or requirements that are not in place, or security controls that were not sufficiently evidenced. The SPoC Lab will then perform follow-up testing and provide PCI SSC with an updated Evaluation Report.
6. If required, the Vendor performs remedial activities to address security objectives or requirements that are not in place, or security controls for which there was insufficient evidence. The SPoC Lab then performs follow-up testing and provide PCI SSC with an updated Evaluation Report.
Modified
p. 18 → 21
7. PCI SSC issues an invoice to the Vendor for the applicable Acceptance Fee. After the Vendor has paid the invoice, PCI SSC reviews the Evaluation Report to confirm that it meets the SPoC Program requirements and if confirmed, PCI SSC notifies the SPoC Lab and Vendor that the Solution has successfully completed the process, will counter-sign the AOV and send a copy to the Vendor and the SPoC Lab and will add the Solution to the List of Validated …
7. PCI SSC issues an invoice to the Vendor for the applicable Acceptance Fee. After the Vendor pays the invoice, PCI SSC reviews the Evaluation Report to confirm that it meets the SPoC Program requirements and if confirmed, PCI SSC notifies the SPoC Lab and Vendor that the Solution has successfully completed the process.
Modified
p. 18 → 22
Note: A listed SPoC Solution must at a minimum contain one of each successfully validated SCRP, PIN CVM Application and Monitoring/Attestation System and be implemented in a compliant Back-end Monitoring Environment.
Note: To be listed on the List of Validated SPoC Solutions, a Solution must, at a minimum, contain one of each successfully validated SCRP, PIN CVM Application, and Monitoring/Attestation System and be implemented in a compliant Back-end Monitoring Environment.
Removed
p. 19
Additionally, the Vendor must provide access to (1) all production-level, unobfuscated source code and (2) all production-level, obfuscated code for all internally developed functionality as well as bespoke or custom functionality developed by third parties. Failure to provide adequate access to source code shall be considered a failure to meet applicable security objectives and requirements.
Note: In some cases, it may not be possible for a Vendor or SPoC Solution/SPoC Element to meet a specific requirement as stated. In such cases, the Vendor must provide clear and unambiguous justification for why the requirement cannot be met. The Vendor must also provide evidence to clearly illustrate that the corresponding security objective is still being met and that other functionality or methods are employed to provide similar assurance to that provided by the methods described in the requirement. Vendors should work with their SPoC Lab to determine the evidence required to satisfy a …
Note: In some cases, it may not be possible for a Vendor or SPoC Solution/SPoC Element to meet a specific requirement as stated. In such cases, the Vendor must provide clear and unambiguous justification for why the requirement cannot be met. The Vendor must also provide evidence to clearly illustrate that the corresponding security objective is still being met and that other functionality or methods are employed to provide similar assurance to that provided by the methods described in the requirement. Vendors should work with their SPoC Lab to determine the evidence required to satisfy a …
Modified
p. 19 → 23
Figure 2 shows the SPoC Solution Evaluation and PCI SSC Listing process. Figure 3 shows the SPoC Solution submission and PCI SSC review process.
Removed
p. 20
Figure 1: SPoC Solution Evaluation for PCI SSC Listing
Removed
p. 21
Figure 2: SPoC Solution Submission and PCI SSC Review
Removed
p. 22
1) Changes have been applied in a way that is consistent with the SPoC Security Requirements; 2) The Solution continues to meet all applicable SPoC Security Requirements; 3) The Vendor is capable ofand demonstrablymigrating merchants from unsupported COTS platforms; 4) PCI SSC has been advised of any change that necessitates a change to the Listing on the Website, in accordance with this Program Guide; 5) Changes to the documents described in Appendix D: Documentation Required for SPoC Solution Evaluations are provided to the SPoC Lab for review, annually (i.e., at 12-month and 24-month checkpoints) 6) The operational quality of the Monitoring/Attestation System has been assessed as per Appendix B of the SPoC Test Requirements.
Modified
p. 22 → 25
PCI SSC will typically provide a courtesy reminder via e-mail to the Vendor’s Primary Contact (listed on the AOV) within 90 calendar days of each checkpoint, but it is the sole responsibility of the Vendor to comply with checkpoint requirements and maintain its Listings, regardless of such courtesy reminder(s).
PCI SSC typically provides a courtesy reminder via e-mail to the Vendor’s Primary Contact (listed on the AOV) within 90 calendar days of each checkpoint. However, it is the sole responsibility of the Vendor to comply with checkpoint requirements and maintain its Listings, regardless of courtesy reminders.
Modified
p. 22 → 25
Note: It is strongly recommended that the Vendor submit its annual checkpoint documentation and attestation to the SPoC Lab that performed the last full SPoC Solution Evaluation, as changing SPoC Labs requires a full SPoC Solution Evaluation.
Note: Vendors should submit annual checkpoint documentation and attestation to the SPoC Lab that performed the last full SPoC Solution Evaluation, as changing SPoC Labs requires a full SPoC Solution Evaluation.
Modified
p. 22 → 25
As part of this annual checkpoint process, Vendors are required to confirm whether any changes have been made to the Solution, and that:
As part of the annual checkpoint process, Vendors are must confirm any changes that have been made to the Solution, and that:
Modified
p. 22 → 25
Note: Solutions require full Evaluation every three (3) years.
Note: Solutions require a full Evaluation every three years.
Removed
p. 23
• Once in Red, a full Evaluation (including applicable fees) is required to return the Solution Listing status to good standing.
PCI SSC will, upon receipt of the updated AOV and any applicable documentation: (i) review the submission for completeness; (ii) once completeness is established, sign and return a copy of the updated AOV to the Vendor and SPoC Lab; or (iii) update the annual checkpoint date on the Website.
PCI SSC will, upon receipt of the updated AOV and any applicable documentation: (i) review the submission for completeness; (ii) once completeness is established, sign and return a copy of the updated AOV to the Vendor and SPoC Lab; or (iii) update the annual checkpoint date on the Website.
Removed
p. 23
Table 5.2.a
• Changes to Listed Solutions Change Type Description Administrative Changes made to a listed Solution that have no impact on the compliance with any of the SPoC Security Requirements, but where the List of Validated Solutions is updated to reflect the change.
Examples of administrative changes include, but are not limited to, corporate identity changes and changes to listing details such as “Description.” See Section 5.2.1, “Administrative Changes for SPoC Listings,” for details.
• Add/remove a PCI-approved SCRP
• Changes to Listed Solutions Change Type Description Administrative Changes made to a listed Solution that have no impact on the compliance with any of the SPoC Security Requirements, but where the List of Validated Solutions is updated to reflect the change.
Examples of administrative changes include, but are not limited to, corporate identity changes and changes to listing details such as “Description.” See Section 5.2.1, “Administrative Changes for SPoC Listings,” for details.
• Add/remove a PCI-approved SCRP
Modified
p. 23 → 26
• Fourteen (14) calendar days following the annual checkpoint date, the corresponding Listing will be updated to show the Listing’s annual checkpoint date in Orange for a period of 90 days past the annual checkpoint date.
• Fourteen (14) calendar days following the annual checkpoint date, the corresponding Listing will be updated to show the Listing’s annual checkpoint date in Orange for a period of 90 calendar days past the annual checkpoint date.
Modified
p. 23 → 26
• If the updated and complete AOV is not received within this 90-day period, the corresponding Listing’s annual checkpoint date will be updated to show the date in Red.
• If the updated and complete AOV is not received within this 90-day period, the corresponding Listing’s annual checkpoint date will be updated to show the date in Red. This means that a full Evaluation (including applicable fees) is required to return the Solution Listing status to good standing.
Modified
p. 23 → 26
Note: To avoid early administrative expiry (described below), Vendors should begin the annual checkpoint process in advance of the anniversary date of the Solution’s Acceptance.
Note: To avoid early administrative expiry (described below), Vendors should begin the annual checkpoint process in advance of the Solution Acceptance anniversary date.
Modified
p. 23 → 27
Designated Designated Changes are for changes to the Solution’s website listing:
Designated Designated Changes are for changes to the Solution’s Website Listing:
Modified
p. 23 → 27
• Add/move a validated PIN CVM Application See Section 5.2.2, “Designated Changes for Solutions” for details.
• Add/remove a validated PIN CVM Application For details, see Section 5.2.2, Designated Changes for Solutions.
Removed
p. 24
Table 5.2.b
• Changes to SPoC Elements within Listed Solutions Change Type Description Any change that does not impact security functions or compliance with the SPoC Security Requirementsfor example, maintenance patches or routine key rotation.
See Section 5.2.3, “Delta Changes to PIN CVM Applications and Monitoring/Attestation Systems” for details.
See Section 5.2.4, “High-impact Changes to PIN CVM Applications and Monitoring/Attestation Systems” for details.
• Changes to SPoC Elements within Listed Solutions Change Type Description Any change that does not impact security functions or compliance with the SPoC Security Requirementsfor example, maintenance patches or routine key rotation.
See Section 5.2.3, “Delta Changes to PIN CVM Applications and Monitoring/Attestation Systems” for details.
See Section 5.2.4, “High-impact Changes to PIN CVM Applications and Monitoring/Attestation Systems” for details.
Removed
p. 24
Note: Administrative Changes are only permissible for already- listed Solutions that have not expired.
Modified
p. 24 → 27
Delta Change Delta Changes are limited to non-high-impact changes where the SPoC Lab determines the change has low security risk or low impact on compliance with the SPoC Security Requirements and can be assessed separatelye.g., a full Evaluation is not required in order to validate the change.
Delta Change Delta Changes Care limited to non-high-impact changes where the SPoC Lab determines that the change is a low security risk or has a low impact on compliance with the SPoC Security Requirements. Delta Changes can be assessed separately; that is, a full Evaluation is not required to validate the change. For details, see Section 5.2.3, Delta Changes to PIN CVM and Monitoring/Attestation Systems.
Modified
p. 24 → 27
High-impact High-impact Changes are changes where the SPoC Lab determines that the extent of the changes have high security risk or significant impact on the overall SPoC Solution, and a full Evaluation is required. High-impact Changes are not reported in a Change Impact template because they require a full Evaluation (see Section 4 for details).
High-impact Change High-impact Changes are changes where the SPoC Lab determines that the extent of the changes have a high security risk or a significant impact on the overall SPoC Solution; a full Evaluation is required. High-impact Changes are not reported in a Change Impact template because they require a full Evaluation (see Section 4, Evaluation and Reporting Processes for details). For details, see Section 5.2.4, High-impact Changes to PIN CVM Application and Monitoring/Attestation Systems.
Modified
p. 24 → 28
The Vendor prepares a change analysis using the Change Impact template (Appendix C1 or Appendix C2, as applicable) and submits it to the SPoC Lab for review. The change analysis must contain the following information at a minimum:
The Vendor prepares a change analysis using the Change Impact template (Appendix C1 or Appendix C2, as applicable) and submits it to the SPoC Lab for review. At a minimum, the change analysis must contain the following information:
Modified
p. 24 → 28
• Description of why the change is necessary It is recommended that the Vendor submit change analysis to the same SPoC Lab used for the original SPoC Solution Evaluation, as changing SPoC Labs requires a full Evaluation of the Solution.
• Description of why the change is necessary The Vendor should submit the change analysis to the same SPoC Lab that performed the original SPoC Solution Evaluation, as changing SPoC Labs requires a full Evaluation of the Solution. If the SPoC Lab agrees that the change is eligible as an Administrative Change:
Modified
p. 24 → 28
If the SPoC Lab agrees that the change as documented by the Vendor is eligible as an Administrative Change:
If the SPoC Lab does not agree that the change is eligible as an Administrative Change, the SPoC Lab works with the Vendor to resolve the disagreement.
Modified
p. 24 → 28
2. The Vendor prepares the change documentation, signs the corresponding AOV, and sends the documentation to the SPoC Lab.
Removed
p. 25
If the SPoC Lab does not agree with the Vendor that the change is eligible as an Administrative Change, the SPoC Lab works with the Vendor to consider the actions necessary to address the SPoC Lab’s observations.
1) The SPoC Lab must notify the Vendor that it agrees; 2) If applicable, the Vendor completes a new VRA and submits this to the SPoC Lab; 3) The SPoC Lab performs an evaluation of the applicable SPoC Security Requirements that are affected by the change;
1) The SPoC Lab must notify the Vendor that it agrees; 2) If applicable, the Vendor completes a new VRA and submits this to the SPoC Lab; 3) The SPoC Lab performs an evaluation of the applicable SPoC Security Requirements that are affected by the change;
Modified
p. 25 → 28
Following successful PCI SSC review of the change, PCI SSC will:
Following a successful PCI SSC review of the change, PCI SSC:
Modified
p. 25 → 28
1. Updates the corresponding List of Validated SPoC Solutions on the Website accordingly with the new information.
Modified
p. 25 → 28
The Revalidation date of the updated Listing will be the same as that of the parent Listing.
2. Signs and returns a copy of the corresponding AOV to the Vendor and the SPoC Lab. The Revalidation date of the updated Listing remains the same as that of the parent Listing.
Modified
p. 25 → 29
• Add/remove a validated SCRP device used in a Solution; or
• Add/remove a validated PIN CVM Application used in a Solution.
Modified
p. 25 → 29
The Vendor prepares a change analysis using the Change Impact template (Appendix C1) and submits it to the SPoC Lab for review. At a minimum, the change analysis must contain the following information:
Modified
p. 25 → 29
• Description of why the change is necessary It is recommended that the Vendor submit the change analysis to the same SPoC Lab used for the last full Evaluation, as changing SPoC Labs requires a full Evaluation of the respective Solution.
• Description of why the change is necessary The Vendor should submit the change analysis to the same SPoC Lab that performed the last full Evaluation, as changing SPoC Labs requires a full Evaluation of the respective Solution.
Modified
p. 25 → 29
If the SPoC Lab agrees that the change as documented by the Vendor is eligible as a Designated Change:
If the SPoC Lab agrees that the change is eligible as a Designated Change:
Removed
p. 26
See Section 5.3, “Change Documentation,” for more specific information on the section below.
Modified
p. 26 → 30
If the SPoC Lab does not agree with the Vendor that the change is eligible as a Designated Change, the SPoC Lab works with the Vendor to consider the actions necessary to address the SPoC Lab’s observations.
If the SPoC Lab does not agree that the change is eligible as a Designated Change, the SPoC Lab works with the Vendor to resolve the disagreement.
Modified
p. 26 → 30
Following successful PCI SSC review of the change, PCI SSC will:
Following a successful PCI SSC review of the change, PCI SSC does the following:
Modified
p. 26 → 30
1. Amends the List of Validated SPoC Solutions on the Website with the new information.
Modified
p. 26 → 30
The Revalidation date of the updated Listing will be the same as that of the parent Listing.
2. Signs and returns a copy of the AOV to both the Vendor and the SPoC Lab. The Revalidation date of the updated Listing remains the same as that of the parent Listing.
Modified
p. 26 → 30
Should there be quality issues associated with any aspect of the submission, PCI SSC will communicate them to the SPoC Lab. PCI SSC reserves the right to reject any change submission if it determines that a change described therein and purported to be a Designated Change by the SPoC Lab or Vendor is ineligible for treatment as a Designated Change.
Should there be quality issues associated with any part of the submission, PCI SSC will communicate them to the SPoC Lab. PCI SSC reserves the right to reject any change submission if it determines that the change is ineligible for treatment as a Designated Change.
Modified
p. 26 → 30
Since the number of possible changes and their impact cannot be determined in advance, the type of evaluation required must be considered on a per-case basis. Vendors are encouraged to contact the SPoC Lab that performed the last full Evaluation of the Solution for guidance. The SPoC Lab engaged by the Vendor for this purpose then determines whether a Delta Evaluation or full Evaluation is required, based on the degree to which the changes impact the security and/or SPoC-related functions …
Since the number of possible changes and their impact cannot be determined in advance, the type of Evaluation must be considered on a per-case basis. Vendors should contact the SPoC Lab that performed the last full Solution Evaluation for guidance. The SPoC Lab engaged by the Vendor for this purpose then determines whether a Delta Evaluation or full Evaluation is required based on scope of the changes and the impact on the security and/or SPoC-related functions of the SPoC Element, …
Modified
p. 26 → 30
The Vendor prepares a change analysis using the Change Impact template (Appendix C2) and submits it to the SPoC Lab for review. The change analysis must contain the following information at a minimum:
The Vendor prepares a change analysis using the Change Impact template (Appendix C2) and submits it to the SPoC Lab for review. At a minimum, the change analysis must contain the following information:
Removed
p. 27
1) The SPoC Lab notifies the Vendor that it agrees; 2) The Vendor prepares the change documentation and signs the AOV (and new VRA, if applicable) and sends it to the SPoC Lab; 3) The SPoC Lab completes the corresponding Change Impact document and must produce a red-lined Evaluation Report and document the testing completed per PCI SSC requirements; 4) The SPoC Lab signs its concurrence on the AOV and forwards it along with the completed change documents, VRA (as applicable) and the red-lined Evaluation Report to PCI SSC; 5) PCI SSC invoices the Vendor; upon payment of the invoice, PCI SSC will review the submission.
Since the number of possible changes and their impact cannot be determined in advance, the type of evaluation required must be considered on a per-case basis. Vendors are encouraged to contact the SPoC Lab that performed the last full Evaluation of the Solution for guidance. …
Since the number of possible changes and their impact cannot be determined in advance, the type of evaluation required must be considered on a per-case basis. Vendors are encouraged to contact the SPoC Lab that performed the last full Evaluation of the Solution for guidance. …
Modified
p. 27 → 31
1. Amends the List of Validated SPoC Solutions on the Website with the new information.
Modified
p. 27 → 31
If the SPoC Lab agrees that the change as documented by the Vendor is eligible as a Delta Change:
If the SPoC Lab agrees that the change is eligible as a Delta Change:
Modified
p. 27 → 31
Following successful PCI SSC review of the change, PCI SSC will:
Following a successful review of the change, PCI SSC does the following:
Modified
p. 27 → 31
The Revalidation date of the updated Listing will be the same as that of the parent Listing.
2. Signs and returns a copy of the AOV to the Vendor and the SPoC Lab. The Revalidation date of the updated Listing remains the same as that of the parent Listing.
Modified
p. 27 → 31
Should there be quality issues associated with any aspect of the submission, PCI SSC will communicate them to the SPoC Lab. PCI SSC reserves the right to reject any submission if it determines that a change described therein and purported to be a Delta Change by the SPoC Lab or Vendor is ineligible for treatment as a Delta Change.
Should there be quality issues with any part of the submission, PCI SSC communicates them to the SPoC Lab. PCI SSC reserves the right to reject any submission if it determines that a change described therein and purported to be a Delta Change by the SPoC Lab or Vendor is ineligible for treatment as a Delta Change.
Modified
p. 28 → 32
Administrative Change (All SPoC Elements) Delta Change (Application) Designated Change (Solution) Annual Checkpoint (Solution)
Table 4: Change Documentation Administrative Change (All SPoC Elements) Delta Change (Application) Designated Change (Solution) Annual Checkpoint (Solution)
Modified
p. 28 → 32
• Change Impact document**
• Change Impact document a
Modified
p. 28 → 32
• Change Impact document **
• Change Impact document a
Modified
p. 28 → 32
• Change Impact document **
• Change Impact document a
Removed
p. 29
For any change affecting the Listing of a validated Solution, the applicable fee will be invoiced and must be received by PCI SSC for the changes to be reviewed, Accepted and added to the List of Validated SPoC Solutions. Upon Acceptance, PCI SSC will sign and return a copy of the AOV to both the Vendor and the SPoC Lab.
Note: The Vendor pays all SPoC Solution Evaluation-related fees directly to the SPoC Lab. These fees are negotiated between the Vendor and the SPoC Lab.
PCI SSC will invoice the Vendor for all Validation Maintenance Fees, and the Vendor will pay these fees directly to PCI SSC.
A Solution must already be listed and not yet have expired in order to have a change Accepted and listed.
Note: The Vendor pays all SPoC Solution Evaluation-related fees directly to the SPoC Lab. These fees are negotiated between the Vendor and the SPoC Lab.
PCI SSC will invoice the Vendor for all Validation Maintenance Fees, and the Vendor will pay these fees directly to PCI SSC.
A Solution must already be listed and not yet have expired in order to have a change Accepted and listed.
Modified
p. 29 → 33
• New Validation: If the Vendor wishes the Solution Listing to remain on the List of Validated SPoC Solutions on the Website, the Vendor must engage a SPoC Lab to perform a new full Evaluation against the then-current version of the SPoC Security Requirements prior to the expiry date, resulting in a new Acceptance. This new Evaluation must follow the same process as an initial SPoC Solution Evaluation.
• New Validation: If the Vendor wants the Solution Listing to remain on the List of Validated SPoC Solutions, the Vendor must engage a SPoC Lab to perform a new full Evaluation. The SPoC Lab performs the Evaluation against the current SPoC Security Requirements before the expiry date, resulting in a new Acceptance. A new Evaluation follows the same process as the original SPoC Solution Evaluation.
Modified
p. 29 → 33
• Expiry: Listing of Solution for which a new Acceptance has not occurred on or before the applicable expiry date will appear in Orange for the first 90 days past expiry, and in Red thereafter.
• Expiry: A Solution Listing for which a new Acceptance has not occurred on or before the expiry date appears in Orange for the first 90 days past expiry, and in Red thereafter.
Modified
p. 29 → 33
There is no PCI SSC fee associated with the processing of annual checkpoints.
There is no PCI SSC fee for processing annual checkpoints.
Modified
p. 29 → 33
All SPoC Program fees are posted on the Website. SPoC Program fees are non-refundable and are subject to change upon posting of revised fees on the Website.
All SPoC Program fees are posted on the PCI SSC Website. SPoC Program fees are non- refundable and subject to change upon posting of revised fees on the Website.
Removed
p. 30
For reports on changes to existing Listed Solutionsi.e., Delta Changesthe same process applies, and PCI SSC will post revised information to the Website and issue a revised approval letter upon its determination that no issues or questions remain. Delta reports are prepared using the major requirements the Solution was assessed against when newly approved.
The diagram below provides a high-level illustration of the various processes, evidence (e.g., reports), participants (Lab, QSA, PIN auditor and PCI SSC) and steps involved in a SPoC Solution submission.
The diagram below provides a high-level illustration of the various processes, evidence (e.g., reports), participants (Lab, QSA, PIN auditor and PCI SSC) and steps involved in a SPoC Solution submission.
Modified
p. 30 → 34
When PCI SSC determines that there are no issues or questions, PCI SSC adds the Solution to the List of Validated SPoC Solutions and issues an approval letter.
Modified
p. 30 → 34
Figure 3: SPoC Solution Submittal, Lab Evaluation and PCI SSC Review and Acceptance Process
Figure 4 illustrates the SPoC Solution process including submission, SPoC Lab Evaluation, and PCI SSC review and Acceptance.
Modified
p. 30 → 34
Note: PCI SSC review timeframes should be considered estimates and may vary based on queue and other factors.
Note: PCI SSC review times are estimates and may vary based on work load and other factors.
Removed
p. 31
PCI SSC reviews each Evaluation Report submission after the invoice for the Acceptance Fee has been paid by the Vendor. PCI SSC performs administrative (“pre-screening”) review to ensure that the submission is complete; and if complete, PCI SSC reviews the submission in its entirety.
Modified
p. 31 → 35
Information in the submitted documents must be consistent with the entries in the “Details” fields within the Portal. Common submission errors include inconsistent product names or contact information and incomplete or inconsistent documentation. Incomplete or inconsistent submissions may delay processing of Listing requests or result in the rejection of the submission by PCI SSC.
Modified
p. 31 → 36
PCI SSC reviews the submission to determine whether the candidate Solution is eligible for validation pursuant to SPoC Program requirements, including but not limited to the Program Guide. If there is question as to eligibility, PCI SSC will contact the SPoC Lab for additional information. If the candidate Solution is determined to be ineligible for validation under the SPoC Program, the Evaluation Report will be rejected and the SPoC Lab will receive a letter of rejection with optional instructions for …
PCI SSC reviews the submission to determine whether the candidate Solution is eligible for validation pursuant to SPoC Program requirements, including but not limited to the Program Guide. If there is eligibility question, PCI SSC contacts the SPoC Lab for additional information. If the candidate Solution is ineligible for validation under the SPoC Program, the Evaluation Report is rejected and the SPoC Lab will receive a letter of rejection with instructions for appeal.
Modified
p. 31 → 36
If the candidate Solution is determined to be eligible for validation under the SPoC Program and the submission is complete, PCI SSC will conduct a complete review of the Evaluation Report submission and supporting documentation provided or subsequently requested by PCI SSC. Any comments or feedback from PCI SSC will be made via the Portal, and the SPoC Lab is expected to address all comments and feedback in a timely manner. PCI SSC’s role is to ensure sufficient evidence and …
If the candidate Solution is eligible for validation under the SPoC Program, PCI SSC conducts a complete review of the Evaluation Report and supporting documentation provided or subsequently requested by PCI SSC. Any comments or feedback from PCI SSC will be made through the portal. The SPoC Lab should address all comments and feedback in a timely manner. PCI SSC’s role is to ensure that the SPoC Solution Evaluation was performed in accordance with SPoC Program requirements and quality standards.
Removed
p. 33
An example reference number is 2018-XXXXX.XXX, consisting of the following:
• Solution Details Clicking on this link brings up a list of details specific to this Solution consisting of the following:
• Solution Details Clicking on this link brings up a list of details specific to this Solution consisting of the following:
Modified
p. 33 → 38
Solution Identifier Solution Identifier refers to a subset of fields in the Listing below the “Company” entry used by PCI SSC to denote relevant information for each validated Solution, consisting of the following fields, explained in detail:
Solution Identifier Solution Identifier refers to a subset of fields in the Listing below the Company entry that is used by PCI SSC to denote relevant information for each Validated SPoC Solution.
Modified
p. 33 → 39
Table 5: Solution Identifier Fields Field Detail Solution Name Solution Name is provided by the Solution Provider and is the name by which the Solution is sold.
Modified
p. 33 → 39
PCI SSC assigns the Reference Number once the validated Solution is posted to the Website; this number is unique per Solution Provider and will remain the same for the life of the Listing. An example reference number is 2019-XXXXX.XXX, consisting of the following:
Modified
p. 33 → 39
Field Format Year of listing 4 digits + hyphen Solution Provider # 5 digits + period (assigned alphabetically initially, then as received) Individual Solution Number #
Field Format Year of listing 4 digits + hyphen Solution Provider # 5 digits + period (assigned alphabetically initially, then as received) Individual Solution Number # Solution Clicking on this link brings up a list of details specific to this Solution consisting of the following:
Modified
p. 33 → 39
• SCRP Devices Supported: This section identifies the PCI-approved SCRP devices validated for use with this Solution and will include relevant PCI PTS reference numbers and the expiry date of the PTS approval for this device. If the expiry date is in the past, this will be denoted by a color change. A website link will be provided to the appropriate entry on the list of Approved PTS Devices on the Website.
• SCRP Devices Supported: Identifies the PCI SSC-approved SCRP devices validated for use with this Solution and will include relevant PCI PTS reference numbers and the expiry date of the PTS approval for this device. If the expiry date is in the past, this will be denoted by a color change. A website link will be provided to the appropriate entry on the PCI PTS Approved Device List on the Website.
Modified
p. 33 → 39
• PIN CVM Application(s) Evaluated: This section identifies the PIN CVM Application(s) validated for use with this Solution.
• PIN CVM Application(s) Evaluated: Identifies the PIN CVM Application(s) validated for use with this Solution.
Modified
p. 33 → 39
Note that while a SPoC Solution or SPoC Element may include third- party services (including services such as KIFs), those are not listed within the Solution. Any use of such a component in another SPoC Solution would require Evaluation as part of each SPoC Solution of which the third-party service is a part.
Note that while a SPoC Solution or SPoC Element may include third-party services (including services such as KIFs), those are not listed within the Solution. Any use of such a component in another SPoC Solution would require Evaluation as part of each SPoC Solution of which the third-party service is a part.
Removed
p. 34
Description Provided by Solution Provider This section allows the Vendors to submit a description of the Solution to be used in the List of Validated SPoC Solutions, should the Evaluation Report be Accepted.
Modified
p. 34 → 40
Evaluation Lab This entry denotes the name of the SPoC Lab that performed the Evaluation and validated that the Solution is compliant with all applicable SPoC Security Requirements.
Evaluation Lab Evaluation Lab is the name of the SPoC Lab that performed the Evaluation and validated that the Solution is compliant with all applicable SPoC Security Requirements.
Modified
p. 34 → 40
Reevaluation Date The Reevaluation Date is the date by which the Vendor must have the Solution fully re-evaluated against the current SPoC Security Requirements in order to maintain the Acceptance. Orange- or red-colored indicators next to this field signify that the Solution is overdue for submittal to PCI SSC Annual Checkpoint Due Annual Checkpoint Due indicates the date in which the Solution is due for its annual (12- and 24- month) checkpoints by a SPoC Lab. Orange- or red-colored indicators …
Reevaluation Date Reevaluation Date is the date by which the vendor must have the Solution fully re-evaluated against the current SPoC Security Requirements to maintain the acceptance. Orange or Red dates in this field signify that the Solution is overdue for submission to PCI SSC.
Modified
p. 35 → 41
The Vendor and/or SPoC Lab must complete each section of this document and all other required documents based on the type of change. The SPoC Lab is required to submit this SPoC Change Impact along with supporting documentation to PCI SSC for review.
The vendor and/or SPoC Lab must complete each section of this document and all other required documents based on the type of change. The SPoC Lab is must submit this SPoC Change Impact form with supporting documentation to PCI SSC for review.
Removed
p. 39
The Vendor and/or SPoC Lab must complete each section of this document and all other required documents based on the type of change (see tables in Section 5.2). The SPoC Lab is required to submit this SPoC Change Impact along with supporting documentation to PCI SSC for review.
Part 1. PIN CVM Application or Monitoring/Attestation System Details, Contact Information and Change type SPoC Application Details Application Name PIN CVM Application Monitoring/Attestation System Version # Revised Version # (if applicable) Type of Change (check one) Administrative (Complete Part 2) Delta (Complete Part 3) Submission Date PIN CVM Application or Monitoring/Attestation System Vendor Contact Information Contact Name Title/Role Contact E-mail Contact Phone SPoC Lab Contact Information Contact Name Title/Role Contact E-mail Contact Phone
Part 1. PIN CVM Application or Monitoring/Attestation System Details, Contact Information and Change type SPoC Application Details Application Name PIN CVM Application Monitoring/Attestation System Version # Revised Version # (if applicable) Type of Change (check one) Administrative (Complete Part 2) Delta (Complete Part 3) Submission Date PIN CVM Application or Monitoring/Attestation System Vendor Contact Information Contact Name Title/Role Contact E-mail Contact Phone SPoC Lab Contact Information Contact Name Title/Role Contact E-mail Contact Phone
Modified
p. 41 → 49
Generate a red-lined Evaluation Report review for the changes to the PIN CVM Application or Monitoring/Attestation System (as applicable).
Generate a red-lined Evaluation Report review for the changes to the PIN CVM Application or Monitoring/Attestation System (if applicable).
Modified
p. 42 → 50
Required Artifact Section SR Req. # Requirement Implementation of sensitive services Protection of Sensitive Services 1.1.1 Documentation detailing all sensitive services implemented by the components and solution must exist and be updated as necessary, or at least annually. At a minimum, this must include key loading (for all in-scope areas), signing of applications and SCRP firmware and signing of updates to the monitor services or configuration.
Required Artifact Section SR Req. # Requirement Implementation of sensitive services Protection of Sensitive Services 1.1.1 Documentation detailing all sensitive services implemented by the components and Solution must exist and be updated as necessary, or at least annually. At a minimum, this must include key loading (for all in-scope areas), signing of applications and SCRP firmware, and signing of updates to the monitor services or configuration.
Modified
p. 42 → 50
Random number generation functions and use Random Numbers 1.2.1 Documentation to identify all random number generation functions and reliance on random data used in The Solution must exist and be maintained.
Random number generation functions and use Random Numbers 1.2.1 Documentation to identify all random number generation functions and reliance on random data used in the Solution must exist and be maintained.
Modified
p. 42 → 50
Cryptographic processes and operations Acceptable Cryptography 1.3.1 Documentation must exist to identify cryptographic processes and operations used by The Solution for security services.
Cryptographic processes and operations Acceptable Cryptography 1.3.1 Documentation must exist to identify cryptographic processes and operations used by the Solution for security services. At a minimum, documentation must include the following:
Modified
p. 42 → 50
• Cryptographic algorithms used, and where
• Cryptographic algorithms used and where
Modified
p. 42 → 50
• Identification of all keys, the complete key hierarchy, their purposes and crypto periods
• Identification of all keys, the complete key hierarchy, their purposes, and crypto periods
Modified
p. 42 → 50
• Key-generation or key-agreement processes Key lifecycle management policy and procedures Key Management 1.4.1 Documentation, including procedures, must exist to support all key lifecycle management functions used by The Solution.
• Key-generation or key-agreement processes Key lifecycle management policy and procedures Key Management 1.4.1 Documentation, including procedures, must exist to support all key lifecycle management functions used by the Solution.
Modified
p. 43 → 51
• Protections provided to the application to protect against tampering, side-channel attacks, fault injection and reverse engineering for the various supported platform and protection methods (such as TEE, white-box cryptography).
• Protections provided to the application to protect against tampering, side-channel attacks, fault injection and reverse engineering for the supported platform and protection methods (such as TEE, white-box cryptography).
Modified
p. 43 → 51
• Data-flow diagrams that show how the PIN is entered, processed, encrypted and validated within the application, where the data is transmitted outside of the scope of the application and any assumptions made about these external connections.
• Data-flow diagrams that show how the PIN is entered, processed, encrypted, and validated within the application, where the data is transmitted outside of the scope of the application, and any assumptions made about these external connections.
Modified
p. 43 → 51
• Guidance for merchants regarding how to ensure the PIN is entered in a way that it cannot be observed.
• Guidance for merchants regarding how to ensure that the PIN is entered in a way that it cannot be observed.
Modified
p. 43 → 51
• A policy on how to manage vulnerabilities and perform security testing.
• A policy about how to manage vulnerabilities and perform security testing.
Modified
p. 43 → 51
Acceptable use policy Secure Provisioning 2.2.8 A security policy must exist for acceptable use of the PIN CVM Application and be provided to all users of the PIN CVM Application, and is part of the PIN CVM Application End User License Agreement (EULA).
Acceptable use policy Secure Provisioning 2.2.8 A security policy must exist for acceptable use of the PIN CVM Application. This policy must be provided to all users of the PIN CVM Application and is part of the PIN CVM Application End User License Agreement (EULA).
Modified
p. 44 → 52
System baseline update procedures 3.1.2 Documentation must exist and processes be demonstrably in use that identify methods used for updating the system baseline as new threats are identified.
System baseline update procedures 3.1.2 Documentation must exist, and processes be demonstrably in use that identify methods used for updating the system baseline as new threats are identified.
Modified
p. 44 → 52
Attestation policy for SCRP, COTS, PIN CVM application Attestation Mechanism 3.2.1 A documented attestation policy that defines health-check rules for the SCRP, COTS platform and PIN CVM Application attestation mechanisms must exist.
Attestation policy for SCRP, COTS, PIN CVM Application Attestation Mechanism 3.2.1 A documented attestation policy that defines health-check rules for the SCRP, COTS platform and PIN CVM Application attestation mechanisms must exist.
Modified
p. 44 → 52
• The policy must include detailed response procedures for successful and non-successful results.
• The policy must include detailed response procedures for successful and unsuccessful results.
Modified
p. 44 → 52
• The policy must be maintained and strictly controlled, including reviews and updates as necessary, at least annually.
• The policy must be maintained and strictly controlled, including reviews and updates as necessary (at least annually).
Removed
p. 45
• How such changes are communicated to affected merchants.
This policy must include the methods used to assess ongoing risk of The Solution as well as how and when updates to the system baseline are performed and how such changes are communicated to affected merchants.
This policy must include the methods used to assess ongoing risk of The Solution as well as how and when updates to the system baseline are performed and how such changes are communicated to affected merchants.
Modified
p. 45 → 53
• Decisions are made to remove previously acceptable platforms from the system baseline.
• Decisions are made to remove previously acceptable platforms from the system baseline
Modified
p. 45 → 53
• Such changes will affect the parties using these platforms, so the documentation must also include how communication is handled in these cases.
• Such changes affect the parties using these platforms. Documentation must also include how communication is handled in these cases.
Modified
p. 45 → 53
Risk-assessment policy methodology and procedures 3.5.10 The Solution Provider must have a documented risk-assessment policy and procedures that provide details on:
Risk-assessment policy methodology and procedures 3.5.10 The Solution Provider must have a documented risk-assessment policy and procedures that provide details about:
Modified
p. 45 → 53
• The methods used to assess on-going risk of The Solution;
• The methods used to assess on-going risk of the Solution;
Modified
p. 45 → 53
• How and when updates to the system baseline are performed; and
• How and when updates to the system baseline are performed
Modified
p. 45 → 53
It is not considered acceptable for the policy to require a minimum number of PIN CVM Applications to be using a vulnerable platform before it is removed from the system baseline.
• How such changes are communicated to affected merchants The risk-assessment policy and procedures must be reviewed at least annually. It is not acceptable for the policy to require a minimum number of PIN CVM Applications to be using a vulnerable platform before it is removed from the system baseline.
Removed
p. 46
Security policies 3.7.3 Reviews must be performed at least quarterly to verify operational procedures are being followed.
Documentation must identify how data confidentiality and authenticity is maintained PIN CVM Solution user guide PIN CVM Solution Requirement 4.3.1 A user guide that provides information about the Solution, including identifying control points and security responsibilities for the merchant(s), must exist and be made available to the merchant.
Testing to ensure viability of such plans and procedures must be performed annually at a minimum.
Note: If PAN or SAD is present anywhere in the Back-end Monitoring Environment, a full PCI DSS plus DESV Assessment performed by a QSA is required. In such cases, the Vendor would provide the SPoC Lab with the completed, signed PCI DSS AOC during the SPoC Solution Evaluation as evidence of a compliant Back- end Monitoring Environment.
If PIN data is present anywhere in the Back-end Monitoring Environment, the Vendor must also provide …
Documentation must identify how data confidentiality and authenticity is maintained PIN CVM Solution user guide PIN CVM Solution Requirement 4.3.1 A user guide that provides information about the Solution, including identifying control points and security responsibilities for the merchant(s), must exist and be made available to the merchant.
Testing to ensure viability of such plans and procedures must be performed annually at a minimum.
Note: If PAN or SAD is present anywhere in the Back-end Monitoring Environment, a full PCI DSS plus DESV Assessment performed by a QSA is required. In such cases, the Vendor would provide the SPoC Lab with the completed, signed PCI DSS AOC during the SPoC Solution Evaluation as evidence of a compliant Back- end Monitoring Environment.
If PIN data is present anywhere in the Back-end Monitoring Environment, the Vendor must also provide …
Modified
p. 46 → 54
• Confirmation that personnel are following security policies and operational procedures
•for example, daily log reviews, firewall rule-set reviews, configuration standards for new systems, etc.
•for example,
• Confirmation that personnel are following security policies and operational procedures, such as daily log reviews, firewall rule-set reviews, configuration standards for new systems, etc.
Modified
p. 46 → 54
Secure channel policies and procedures Secure Channels 4.2.4 Documentation must exist and be maintained to identify logical connections between the PIN CVM Application and other components of the system.
Secure channel policies and procedures Secure Channels 4.2.4 Documentation must exist and be maintained to identify logical connections between the PIN CVM Application and other components of the system. Documentation must identify how data confidentiality and authenticity is maintained PIN CVM Solution user guide PIN CVM Solution Requirement 4.3.1 A user guide must exist that provides information about the Solution, including identifying control points and security responsibilities for the merchants. This user guide must be available to the merchant.
Modified
p. 46 → 54
Solution incident response procedures 4.3.6 Plans and procedures must be defined to address interruptions to the Solution due to unplanned business disruption, major disaster or failure of services.
Solution incident response procedures 4.3.6 Plans and procedures must be defined to address interruptions to the Solution due to unplanned business disruption, major disaster, or failure of services. At a minimum, testing to ensure viability of such plans and procedures must be performed annually.
Modified
p. 46 → 54
For Appendix A documentation, the Vendor may provide the SPoC Lab with a copy of their report based on SPoC Security Requirements Appendix A, “Monitoring Environment Basic Protections,” (“Back-end Monitoring Environment Report”) and/or the accompanying AOC (if a different SPoC Lab performed the Appendix A assessment) using the template based on SPoC Security Requirements Appendix A (“Back-end Monitoring Environment Report template”).
For Appendix A documentation, the vendor may provide the SPoC Lab with a copy of their report based on SPoC Security Requirements, Appendix A, “Monitoring Environment Basic Protections,” (“Back-end Monitoring Environment Report”) and/or the accompanying AOC (if a different SPoC Lab performed the Appendix A assessment) using the template based on SPoC Security Requirements, Appendix A “Back-end Monitoring Environment Report template”). Note: If PAN or SAD is present anywhere in the Back-end Monitoring Environment, a full PCI DSS plus Designated …
Modified
p. 47 → 55
Incident Response Procedures Physical Security A.5.5 Implement response procedures to be initiated upon the detection of attempts to remove clear-text data from the Back-end monitoring environment via an unauthorized channel, method or process.
Incident Response Procedures Physical Security A.5.5 Implement response procedures to be initiated upon the detection of attempts to remove clear- text data from the Back-end Monitoring Environment through an unauthorized channel, method, or process. Response procedures must include:
Modified
p. 47 → 55
• Procedures for remediating data leaks or process gaps, as necessary, to prevent any data loss Back-end Monitoring Environment asset management procedures Physical Security A.5.3 Procedures to remove access and return assets such as keys, access cards for terminated personnel or when job duties change must be defined and demonstrably in use.
• Procedures for remediating data leaks or process gaps, as necessary, to prevent data loss Back-end Monitoring Environment asset management procedures Physical Security A.5.3 Procedures to remove access and return assets must be defined and demonstrably in use. Examples include access removal when employee job duties change; or the return of keys and cards when an employee is terminated.
Modified
p. 48 → 55
• Back-up copies of information, software and system images must be created and tested regularly.
• Back-up copies of information, software, and system images must be created and tested regularly.
Modified
p. 48 → 55
• The frequency and retention of backups must be adequate to support day-to-day production activities and sufficient to facilitate recovery and achieve recovery objectives associated with those systems that require a recovery capability.
• The frequency and retention of backups must be adequate to support day-to-day production activities and sufficient to achieve recovery objectives for systems that require them.
Modified
p. 48 → 56
A.6.4 Implement response procedures to initiate upon the detection of attempts to remove clear text data from the Back-end Monitoring Environment through an unauthorized channel, method, or process. Response procedures must include:
Modified
p. 48 → 56
• Procedures for remediating data leaks or process gaps, as necessary, to prevent any data loss Audit Log management policy and procedures Audit Logs A.7.1 Policies and procedures must exist and be demonstrably in use for generating and managing audit logs for all system components.
• Procedures for remediating data leaks or process gaps, as necessary, to prevent data loss Audit Log management policy and procedures Audit Logs A.7.1 Policies and procedures must exist and be demonstrably in use for generating and managing audit logs for all system components.
Modified
p. 48 → 56
• Security reviews performed prior to release of an application or application update At a minimum, the documentation must include quality controls standards and measurements as well as change-control practices to ensure oversight of the development processes.
• Security reviews performed before releasing an application or application update At a minimum, the documentation must include quality control standards and measurements, and change-control practices to ensure oversight of the development processes.
Removed
p. 49
• Developing for all access point considerations, including input variances such as multi-channel input to the application.
Modified
p. 49 → 56
• The format of the version scheme, including number of elements, separators, character set, etc. (consisting of alphabetic, numeric and/or alphanumeric characters).
• The format of the version scheme, including number of elements, separators, character set, and so on (alphabetic, numeric and/or alphanumeric characters).
Modified
p. 49 → 56
Secure coding techniques Application Security Requirement D.5 Applications must be developed according to industry best practices for secure coding techniques, including:
Modified
p. 49 → 56
• Developing with least privilege for the application environment.
• Developing with least privilege for the application environment
Modified
p. 49 → 56
• Developing with fail-safe defaults (all execution is by default denied unless specified within initial design).
• Developing with fail-safe defaults (all execution is by default denied unless specified within initial design)
Modified
p. 49 → 56
• Coding techniques include documentation of how sensitive information (e.g., cryptographic material, certificates, PIN, etc.) is handled in memory.
• Documentation of coding techniques, including how sensitive information (cryptographic material, certificates, PIN, and so on) is handled in memory.
Modified
p. 49 → 57
Change control procedures Application Security Requirement D.8 Software vendor must follow change-control procedures for all application changes. Change-control procedures must follow the same software development processes as new releases, and include the following:
• Developing for all access point considerations, including input variances, such as multi- channel input to the application Change control procedures Application Security Requirement D.8 Software vendor must follow change-control procedures for all application changes. Change- control procedures must follow the same software development processes as new releases, including the following:
Modified
p. 49 → 57
• Documented approval of change by appropriate authorized parties
• Documented approval of change by authorized parties
Modified
p. 49 → 57
• Functionality testing to verify that the change does not adversely impact the security of the system
• Functional testing to verify that the change does not adversely impact the system security
Modified
p. 49 → 57
• Back-out or product de-installation procedures Application Security Requirement D.14 A process must be implemented to document and authorize the final release of the application and any application updates. Documentation includes:
• Back-out or product de-installation procedures Application Security Requirement D.14 A process must be implemented to document and authorize the final release of the application and any updates. Documentation includes:
Modified
p. 49 → 57
• Confirmation that secure development processes were followed by the vendor.
• Confirmation that the vendor followed secure development processes.
Modified
p. 50 → 57
• Provide relevant information specific to the application
• Provides relevant information specific to the application
Modified
p. 50 → 57
• Address all requirements in this document Include a review at least annually and upon changes to the application and is updated as needed to keep the documentation current with all changes affecting the application, as well as to the requirements in this document.
• Addresses all requirements in this document Include a review at least annually, and update the application, its documentation, and the requirements in this document, as needed.
Removed
p. 52
F.1 Version Number Format The format of the application version number is set by the Vendor and may be comprised of several elements. The versioning methodology must fully describe the format of the application version number including the following:
• The hierarchy of the elements
• Definition of what each element represents in the version scheme
• Types of changes made to the application
•e.g., major release, minor release, maintenance release, etc.
• The hierarchy of the elements
• Definition of what each element represents in the version scheme
• Types of changes made to the application
•e.g., major release, minor release, maintenance release, etc.
Modified
p. 52 → 59
For additional information, see SPoC Security Requirements, Appendix D, “Application Security Requirements,” (item 9).
Modified
p. 52 → 59
• The format of the version scheme, including:
• Definition of each element in the version scheme
Modified
p. 52 → 59
• Numbers of digits used for each element
• Numbers of digits for each element
Modified
p. 52 → 59
• Format of separators used between elements
• Format of separators between elements
Modified
p. 52 → 59
• Character set used for each element (consisting of alphabetic, numeric and/or alphanumeric characters)
• Character set for each element (alphabetic, numeric, alphanumeric)
Modified
p. 52 → 60
• Type of change: major, minor, maintenance release, etc.
• Types of changes made to the application, such as major release, minor release, maintenance release, and so on
Modified
p. 52 → 60
The Vendor must document how elements of the application version number are used to identify:
The vendor must document how elements of the application version number are used to
Modified
p. 52 → 60
• Changes that have no impact on the functionality of the application or its dependencies 1 See Table 5.2.b for an overview of the various change types.
• Changes that have no impact on the function of the application or its dependents
Modified
p. 53 → 60
• Changes that have impact on the application functionality but no impact on security or compliance with SPoC Security Requirements
• Changes that impact the application function, but do no impact security or compliance with SPoC Security Requirements
Modified
p. 53 → 60
• Changes that impact any security functionality or compliance with SPoC Security Requirements Elements of the version number used for non-security-impacting changes must never be used for security-impacting changes.
• Changes that impact any security function or compliance with SPoC Security Requirements Elements of the version number used for changes that do not impact security functions must never be used for changes that do impact security functions.
Modified
p. 53 → 60
If the Vendor uses a versioning scheme that involves mapping of internal version numbers to external, published version numbers, all security-impacting changes must result in an update to the external, published version number.
If the vendor uses a versioning scheme that involves mapping of internal version numbers to external, published version numbers, all security-impacting changes must result in an update to the external, published version number.
Modified
p. 53 → 60
Any version number that is accessible to customers and integrator/resellers must be consistent with the versioning policy described in the applicable implementation guides.
Any version number that is accessible to customers and integrators/resellers must be consistent with the versioning policy described in the applicable implementation guides.
Modified
p. 53 → 60
Vendors must ensure traceability between application changes and version numbers such that a customer or integrator/reseller may determine which changes are included in the specific version of the application it is running.
Vendors must ensure traceability between application changes and version numbers.
Removed
p. 54
Note: Additional definitions for PCI terminology are provided in the general PCI Glossary on the PCI SSC website at https://www.pcisecuritystandards.org/pci_security/glossary.
ii. Received the corresponding fee and all documentation required with respect to that SPoC Solution as part of the SPoC Program; and iii. Confirmed that: a. The respective compliant Solution Evaluation Report is correct as to form (all applicable documents completed appropriately/sufficiently); b. The SPoC Lab properly determined that the Solution is eligible to be a validated Solution; c. The SPoC Lab adequately reported the compliance of the respective SPoC Solution with SPoC Program requirements; and d. The detail provided in the Solution Evaluation Report meets
ii. Received the corresponding fee and all documentation required with respect to that SPoC Solution as part of the SPoC Program; and iii. Confirmed that: a. The respective compliant Solution Evaluation Report is correct as to form (all applicable documents completed appropriately/sufficiently); b. The SPoC Lab properly determined that the Solution is eligible to be a validated Solution; c. The SPoC Lab adequately reported the compliance of the respective SPoC Solution with SPoC Program requirements; and d. The detail provided in the Solution Evaluation Report meets
Modified
p. 54 → 61
Term Definition / Source / Document Reference Accepted/Acceptance A SPoC Solution is deemed to have been “Accepted” (and “Acceptance” is deemed to have occurred) and will be listed on the List of Validated SPoC Solutions on the Website when PCI SSC has:
Table 6: PCI SSC Terminology Term Definition / Source / Document Reference Accepted/Acceptance A SPoC Solution is deemed to have been “Accepted” (and “Acceptance” is deemed to have occurred) and will be listed on the List of Validated SPoC Solutions on the Website when PCI SSC has:
Modified
p. 54 → 61
• Received the corresponding compliant Solution Evaluation Report from the SPoC Lab;
Modified
p. 54 → 61
Note: PCI SSC may suspend, withdraw, revoke, cancel or place conditions upon (including without limitation, complying with remediation requirements) Acceptance and listing of any Solution in accordance with applicable SPoC Program policies and procedures.
• The detail provided in the Solution Evaluation Report meets PCI SSC’s reporting requirements. Note: PCI SSC may suspend, withdraw, revoke, cancel or place conditions upon (including without limitation, complying with remediation requirements) Acceptance and Listing of any Solution in accordance with applicable SPoC Program policies and procedures.
Modified
p. 54 → 61
Assessment Assessment of a SPoC Solution’s Back-end Monitoring Environment in order to validate compliance with the SPoC Security Requirements as part of the SPoC Program.
Assessment Assessment of a SPoC Solution’s Back-end Monitoring Environment to validate compliance with the SPoC Security Requirements as part of the SPoC Program.
Modified
p. 54 → 61
Assessor A SPoC Lab or a QSA Company or a PIN auditor.
Assessor A SPoC Lab or a QSA company or a PIN auditor.
Removed
p. 55
In the SPoC Security Requirements and/or SPoC Test Requirements, the “Monitoring/Attestation System” is an implementation that may be shared across different execution environments and which provides a level of validation and assurance of the execution environment in which the PIN CVM Application executes, thereby delivering a level of software-based tamper detection and response.
Modified
p. 55 → 62
List of Validated SPoC Solutions The list on the Website of Solutions that have been Accepted for SPoC Program purposes.
List of Validated SPoC Solutions The list of Solutions on the Website that have been Accepted for SPoC Program purposes.
Modified
p. 55 → 62
Listing The listing and related information regarding a Solution on the List of Validated SPoC Solutions.
Listing (or Listed) The listing and related information regarding a Solution on the List of Validated SPoC Solutions.
Modified
p. 55 → 62
Monitoring/Attestation System An applicationwhich includes any COTS device-side and back-end monitoring and/or attestation software applicationsthat has been evaluated and validated by a SPoC Lab to have met all applicable SPoC Security Requirements, and then Accepted by PCI SSC, so long as such Acceptance has not been revoked, suspended, withdrawn or terminated.
Monitoring/Attestation System An applicationwhich includes any COTS device-side and back-end monitoring and/or attestation software applicationsthat has been evaluated and validated by a SPoC Lab to have met all applicable SPoC Security Requirements, and then Accepted by PCI SSC, so long as such Acceptance has not been revoked, suspended, withdrawn, or terminated. In the SPoC Security Requirements and/or SPoC Test Requirements, the Monitoring/Attestation System is an implementation that may be shared across different execution environments and which provides a level of …
Modified
p. 55 → 62
Participating Payment Brand A global payment card brand or scheme that is also a limited liability company member of PCI SSC (or affiliate thereof).
Participating Payment Brand (or Payment Brand) A global payment card brand or scheme that is also a limited liability company member of PCI SSC (or affiliate thereof).
Removed
p. 56
i. Are installed and executed on the merchant COTS device for the purposes of accepting and processing the cardholder PIN CVM; and
ii. Have been evaluated and validated (along with its supporting Monitoring/Attestation System) by a SPoC Lab to be in scope for the SPoC Program and to have met all applicable SPoC Security Requirements and then Accepted by PCI SSC, so long as such Acceptance has not been revoked, suspended, withdrawn, or terminated.
Additionally, the client-side monitor and/or a payment application may be incorporated into the PIN CVM Application or may be a separate application.
Program Guide The then-current version of (or successor documents to) this document• the Payment Card Industry (PCI) SPoCSoftware-based PIN Entry on COTS Program Guide, as from time to time amended and made available on the Website.
ii. Have been evaluated and validated (along with its supporting Monitoring/Attestation System) by a SPoC Lab to be in scope for the SPoC Program and to have met all applicable SPoC Security Requirements and then Accepted by PCI SSC, so long as such Acceptance has not been revoked, suspended, withdrawn, or terminated.
Additionally, the client-side monitor and/or a payment application may be incorporated into the PIN CVM Application or may be a separate application.
Program Guide The then-current version of (or successor documents to) this document• the Payment Card Industry (PCI) SPoCSoftware-based PIN Entry on COTS Program Guide, as from time to time amended and made available on the Website.
Modified
p. 56 → 62
PIN auditor Entity approved by one of the Payment Card Brands to perform assessments of PIN-processing environments.
PIN auditor Entity approved by one of the Participating Payment Brands to perform assessments of PIN-processing environments.
Modified
p. 56 → 62
PIN CVM Application All parts of the code (regardless of execution environment) that:
PIN CVM Application All parts of the code, regardless of execution environment, that are installed and executed on the merchant COTS device for the purposes of accepting and processing the cardholder’s PIN. See SPoC Security Requirements for additional details.
Modified
p. 56 → 63
PTS Lab (or PCI- recognized Laboratory) A security laboratory qualified by PCI SSC under the PCI SSC PCI- recognized Laboratory program.
PTS Lab (or PCI-recognized Laboratory) A security laboratory qualified by PCI SSC under the PCI SSC PCI-recognized Laboratory program.
Removed
p. 57
A physical, encrypting card reader that has been assessed compliant to the PCI PTS SCRP Approval Class and is listed on the PTS approval website. An SCRP is intended for use with a commercial off-the-shelf (COTS) device such as a mobile phone or tablet.
• A contact chip-card-only reader
• A contactless-only chip card reader
• A reader supporting both contact and contactless chip card functionality SCRPs perform PIN translation from PIN blocks received from the payment application on the COTS device to a PIN block for either conveyance to the processing host or for offline to the contact chip card.
See the PCI PTS POI Modular Security Requirements (version 5.1 or later) and PCI PIN Transaction Security Device Testing and Approval Program Guide for additional details.
• A contact chip-card-only reader
• A contactless-only chip card reader
• A reader supporting both contact and contactless chip card functionality SCRPs perform PIN translation from PIN blocks received from the payment application on the COTS device to a PIN block for either conveyance to the processing host or for offline to the contact chip card.
See the PCI PTS POI Modular Security Requirements (version 5.1 or later) and PCI PIN Transaction Security Device Testing and Approval Program Guide for additional details.
Modified
p. 57 → 63
SPoC Lab (or PCI-recognized SPoC Laboratory) A PCI-recognized Software-based PIN Entry on COTS Laboratory qualified by PCI SSC to perform Evaluations of Solutions, PIN CVM Applications and supporting Monitoring/Attestation Systems for SPoC Program purposes.
SPoC Lab (or PCI-recognized SPoC Laboratory) A PCI-recognized Software-based PIN Entry on COTS Laboratory qualified by PCI SSC to perform Evaluations of Solutions, PIN CVM Applications, supporting Monitoring/Attestation Systems and optional non-PTS Approved MSRs for SPoC Program purposes.
Modified
p. 57 → 63
SPoC Element A PIN CVM Application, Monitoring/Attestation System, Back-end Monitoring Environment, or SCRP, validated for use in a SPoC Solution.
SPoC Element A PIN CVM Application, Monitoring/Attestation System, Back-end Monitoring Environment, SCRP or non-PTS Approved MSR, validated for use in a SPoC Solution.
Modified
p. 57 → 63
SPoC Program Refers to PCI SSC's program and requirements for qualification of Assessors, Labs and applicable employees thereof and validation and Acceptance of SPoC Solutions or SPoC Elements, as further described in this document and related PCI SSC documents, policies and procedures.
SPoC Program PCI SSC's program and requirements for qualification of Assessors, Labs and applicable employees thereof and validation and Acceptance of SPoC Solutions or SPoC Elements, as further described in this document and related PCI SSC documents, policies and procedures.
Modified
p. 57 → 63
SPoC Security Requirements The then-current version of (or successor document(s) to) the Payment Card Industry (PCI) Software-based PIN Entry on COTS Security Requirements, any/all testing procedures, appendices, exhibits, schedules and attachments to the foregoing and all materials incorporated therein, in each case, as from time to time amended and made available on the Website.
SPoC Security Requirements The then-current version of (or successor document(s) to) the Payment Card Industry (PCI) Software-based PIN Entry on COTS Security Requirements, any/all testing procedures, appendices, annexes, exhibits, schedules and attachments to the foregoing and all materials incorporated therein, in each case, as from time to time amended and made available on the Website.
Modified
p. 57 → 63
SPoC Solution (or Solution) The set of elements and processes that support software-based PIN entry on a COTS device, comprising a combination of validated SCRP(s), PIN CVM Application and supporting Monitoring/Attestation System, Back-end Monitoring Environment and related processes, which have been validated separately and as part of an integrated solution by the applicable SPoC Lab(s) and Accepted for listing on the PCI SSC website as part of the SPoC Program. At a minimum, a SPoC Solution must include at least …
SPoC Solution (or Solution) The set of elements and processes that support software-based PIN entry on a COTS device, comprising a combination of validated SCRP(s), PIN CVM Application and supporting Monitoring/Attestation System, Back-end Monitoring Environment and related processes, which have been validated separately and as part of an integrated solution by the applicable SPoC Lab(s) and Accepted for Listing on the PCI SSC Website as part of the SPoC Program. At a minimum, a SPoC Solution must include at least …
Modified
p. 58 → 64
SPoC Solution Evaluation Evaluation of a Solution by a SPoC Lab for purposes of validating compliance against the SPoC Security Requirements as part of the SPoC Program, including but not limited to:
SPoC Solution Evaluation (or Evaluation) Evaluation of a Solution by a SPoC Lab for purposes of validating compliance against the SPoC Security Requirements as part of the SPoC Program, including but not limited to:
Modified
p. 58 → 64
• Testing and validation of the above with the applicable SCRP device;
• Testing and validation of the above with the applicable SCRP device
Modified
p. 58 → 64
SPoC Vendor (or Vendor) Any of the following: SPoC Solution provider, PIN CVM Application and supporting Monitoring/Attestation System vendor, or Back-end Monitoring Environment provider.
SPoC Vendor (or Vendor) Any of the following: SPoC Solution Provider, PIN CVM Application and supporting Monitoring/Attestation System vendor, or Back-end Monitoring Environment provider.
Modified
p. 58 → 64
Third-Party Service Provider An entity that acts on behalf of a Solution Provider to provide a service or function that is incorporated into or utilized by the applicable Solution.
Third-Party Service Provider An entity that acts on behalf of a Solution Provider to provide a service or function that is incorporated into or utilized by the applicable Solution. A Third-Party Service Provider must have its services reviewed during the course of each of its Solution-Provider customers’ SPoC Solution Evaluations.
Modified
p. 58 → 64
• Requires to be executed by SPoC Solution Providers, Monitoring/Attestation System or Back-end Monitoring Environment Providers and/or PIN CVM Application Vendors (as applicable) in connection with the SPoC Program, and