Document Diff - PCI Watch

Added p. 2

May 2019 1.1 Updated to support the use of PCI PTS-approved and non-PTS approved magnetic stripe readers (MSRs) in SPoC Solutions in accordance with the SPoC Magnetic Stripe Readers Annex (SPoC MSR Annex)

Added p. 6

• PIN Cardholder Verification Method (CVM) Application (PIN 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 (SPoC Standard) 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 Program. PIN CVM Applications are not listed separately on the Website. o SPoC Application Programming Interface (SPoC API): An optional software component developed and provided by the Solution Provider to allow third-party developers to interface with the SPoC Solution. SPoC APIs must be Evaluated by a SPoC Lab as part of the Evaluation for each SPoC Solution with which a SPoC API is provided. SPoC APIs are listed only as part of the SPoC Solution in which they have been validated for use under the …

Added p. 12

• 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 the SPoC Standard, Appendix A, “Monitoring Environment Basic Protections.”

The action plan will be reviewed by the SPoC Lab for sufficiency and submitted to PCI SSC as part of the Solution Evaluation process. Failure to meet DESV requirements by the first annual checkpoint may result in revocation of the SPoC Solution.

PCI QPA is also required and evidence submitted to the SPoC Lab as part of the Evaluation.

For details about the use of MSRs, see the SPoC MSR Annex.

Added p. 16

Note: PCI SSC does not assess or validate SPoC Solutions for compliance with the SPoC Standard. PCI SSC acceptance and subsequent listing of a SPoC Solution on the List of Validated SPoC Solutions signifies that the applicable SPoC Lab has determined that the Solution complies with all required criteria of the SPoC Standard and Program Guide, that the SPoC Lab has submitted a corresponding Evaluation Report to PCI SSC, and that the Evaluation Report, as submitted to PCI SSC, has satisfied all applicable quality assurance review requirements as of the time of PCI SSC's review. The SPoC Lab is ultimately accountable for the completeness and accuracy of the materials provided to PCI SSC.

COTS platform and Operating System While evaluation of the COTS device itself (e.g., device model, platform and Operating System (OS)) is out of scope for the purposes of SPoC Evaluation, only COTS OSs supported by the OS vendor …

Added p. 23

Note: If any element of a SPoC Solution is evaluated by an entity other than the SPoC Lab performing the current Evaluation, the evaluating SPoC Lab should have access to all associated report(s) and supporting evidence. If those reports are not available for any reason, the evaluating SPoC Lab must determine the extent of additional work required to properly evaluate and attest to the Solution’s compliance with the SPoC Standard.

If the evaluating SPoC Lab is unable to rely on the information

• whether available or unavailable

• and the SPoC Lab is unable to perform the additional work required to achieve such reliance, PCI SSC will be unable to accept the report.

In all cases, PCI SSC may reject the report if (in the judgment of PCI SSC) the report does not contain adequate information to substantiate the conclusions of compliance with the SPoC Standard.

Note: In cases where a Solution Provider or SPoC …

Added p. 25

Updating a SPoC Solution listing to a minor version of the SPoC Standard (for example, from version 1.0 to version 1.1) may be performed via Delta Evaluation if determined eligible by the SPoC Lab. The SPoC Lab must use their discretion to determine the level of testing that must be performed to gain sufficient assurance that the Solution complies with all applicable SPoC Security Requirements.

Support for different major versions of COTS device operating systems (e.g., 9.x, 10.x, etc.) are permitted in a single SPoC Solution Evaluation and listing on the Website. However, support for different COTS platforms (e.g., Android, iOS, etc.) are considered separate SPoC Solutions, and therefore require separate, full SPoC Evaluation Reports, validation and listings on the Website.

In cases where the SPoC Solution Provider offers a SPoC API or software libraries to allow third parties to interface the Solution, Evaluation and validation by a SPoC Lab is required …

Added p. 31

Note: Adding support for a major version of a COTS operating system may be considered high impact or may be considered as a Delta change, as determined by the SPoC Lab. The SPoC Lab must carefully examine the security relevant changes in the SPoC Solution and the impact it has on the original evaluation outcome. The SPoC Lab may address queries (e.g., clarifications) to PCI SSC prior to submitting the SPoC Evaluation Report.

• Update a validated PIN CVM Application Delta Changes can be assessed separately; that is, a full Evaluation is not required to validate the change. For details, see Section 5.2.2, Delta Changes.

Delta Changes Delta Changes are changes made to a SPoC Solution, PIN CVM Application and/or supporting Monitoring/Attestation System and are limited to changes where the SPoC Lab determines that a partial Evaluation (Delta Evaluation) can be performed, rather than a full Evaluation of the SPoC Solution. For …

Added p. 35

Note: Updating a SPoC Solution to support a different COTS platform (e.g., Android, iOS, etc.) is considered high impact, and therefore requires a full Evaluation of the SPoC Solution.

• Solution Provider’s Back-end Environment AOC(s) b

Prior to Acceptance, the Solution Provider must pay the applicable Acceptance Fee to PCI SSC.

For any change affecting the validated SPoC Solution, the invoiced Change Fee must be received by PCI SSC before the change will be reviewed. Upon Acceptance, PCI SSC signs and returns a copy of the AOV to the Solution Provider and the SPoC Lab and updates the List of Validated SPoC Solutions.

There is no PCI SSC fee for processing of annual checkpoints. All SPoC Program fees are posted on the Website (see Fee Schedule). SPoC Program fees are non-refundable and are subject to change upon posting of revised fees on the Website.

Added p. 36

• New Validation: If the Solution Provider wants the Solution Listing to remain on the List of Validated SPoC Solutions, the Solution Provider must engage a SPoC Lab to perform a new full Evaluation. The SPoC Lab performs the Evaluation against the current SPoC Standard before the expiry date, resulting in a new Acceptance. A new Evaluation follows the same process as the original SPoC Solution Evaluation.

• If the SPoC Solution undergoes a full reevaluation and the submittal is received by PCI SSC within this 90-day period, PCI SSC will update the corresponding Listing’s Reevaluation date with the new date and remove the Orange status.

• If the SPoC Solution is not reevaluated and submitted to PCI SSC within this 90-day period, the corresponding Listing’s Reevaluation date will be updated to show the date in Red for a period of no longer than 90 calendar days, after which time the Solution …

Added p. 39

Ineligible, incomplete or inconsistent submissions may delay processing of Listing requests or result in the rejection of the submission by PCI SSC.

Added p. 42

Solution Name, Solution version Name supplied by the SPoC Solution Provider under which the Solution is sold. This field also includes the version of the SPoC Solution, provided by the SPoC Solution Provider Reference Number A number assigned by PCI SSC when the validated Solution is posted to the Website. This number is unique per SPoC Solution Provider and SPoC Solution and remains the same for the life of the Listing. An example reference number is 2020-XXXXX.XXX, consisting of the following:

• Year of Listing

•4 digits + hyphen

• Solution Provider #

•5 digits + period (assigned alphabetically initially, then as received) Individual Solution Number # SPoC Version The version of the SPoC Standard used to evaluate and validate Solution compliance Evaluation Lab The name of the SPoC Lab that performed the Evaluation and validated that the Solution is compliant with all applicable SPoC Security Requirements.

Reevaluation Date The date by which the Solution …

Added p. 47

Delta Change Revision Refer to the SPoC Program Guide for details about each type of change.

Added p. 52

Appendix D SPoC Solution Provider-offered Libraries or APIs In cases where the SPoC Solution Provider provides an application programing interface (API) or libraries to allow third parties to interface the Solution Provider’s SPoC Solution, the following requirements must be met:

• The SPoC Solution Provider is responsible for the development and validation of the SPoC API and a companion document (“user guidance”) outlining the conditions and how the SPoC API can be used to interface the SPoC Solution. o The user guidance describes the scope of integration, any reporting obligations to

PCI SSC, review periods, actions on changes, updates, resource management, distribution process, etc. o The SPoC Solution Provider is responsible for all terms and conditions in the user guidance and must submit the user guidance to the SPoC Lab as part of each SPoC Solution Evaluation (or applicable change submittal) for which a SPoC API is provided. o The SPoC Solution …

Added p. 56

AOV Acronym for “Attestation of Validation.” As applicable to the SPoC program, the AOV is a form for SPoC Labs and SPoC Solution Providers to attest to the results of a SPoC Evaluation, declaring the SPoC Solution validation status against the SPoC Standard. The AOV, signed by the SPoC Lab and Solution Provider, is used when validating, revalidating or submitting changes to a Solution.

AOC Acronym for “Attestation of Compliance.” As applicable to PCI DSS validation, the AOC is a form for merchants and service providers to attest to the results of a PCI DSS assessment. As applicable to PCI PIN validation, the AOC is a form for merchants and service providers to attest to the results of a PCI PIN assessment.

Added p. 58

Qualified PIN Assessor (QPA or PCI QPA) QPA Company as defined in the QPA Qualification Requirements and qualified by PCI SSC to validate an entity's compliance with the PCI PIN Standard.

SPoC Application Programming Interface (or SPoC API) An optional software component or libraries, developed and provided by the SPoC Solution Provider, to allow third-party developers to interface with the SPoC Solution.

SPoC Solution Expired List The list of SPoC Solutions on the Website that have an expired status for a period of at least 90 days.

SPoC Solution Provider (or Solution Provider) The provider of the overall SPoC Solution (or candidate Solution)

• the SPoC Solution Provider is listed on the SPoC Solution Listing and ultimately accountable for the security and functionality of the SPoC Solution and its SPoC Elements.

SPoC Standard The SPoC Security Requirements and SPoC Test Requirements, including the SPoC MSR Annex as applicable.

SPoC Test Requirements The then-current version of (or …

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

Section 1.2, Related Publications. This document is primarily for Solution Providers who develop and PCI-recognized SPoC Laboratories (SPoC Labs) who validate SPoC Solutions. Capitalized terms used but not otherwise defined within this document have the meanings defined in or pursuant to Appendix F of this Program Guide.

Modified p. 5

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

• 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), is listed on the PCI PTS Approved Device List on the Website with an SCRP Approval Class and can optionally support contact magnetic stripe reading functionality. For additional details, refer to the SPoC Magnetic Stripe Readers Annex (SPoC MSR Annex).

Modified p. 5

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

• 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 MSR Annex).

Removed p. 6

• 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 ProgramPIN CVM Applications are not listed separately on the Website.

• PCI PIN validation by a PCI PIN auditor approved by one of the Participating Payment Brands to perform assessments of PIN-processing environments

Modified p. 6

Note: The PIN CVM Application must be validated along with its supporting Monitoring/Attestation System as part of ~~the~~ Solution in which it is used.

Note: The PIN CVM Application (and/or optional API) must be validated along with its supporting Monitoring/Attestation System as part of each Solution in which it is used.

Modified p. 6

• 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 ~~Programi.e., Monitoring/Attestation Systems~~ are not ~~separately~~ listed on the Website.

• Monitoring/Attestation System: Evaluated by a SPoC Lab per the SPoC Standard 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 Program and are not listed on the Website.

Modified p. 6

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

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, “Designated Entities Supplemental Validation (DESV).”

Modified p. 6

• PCI DSS validation ~~(ROC and AOC)~~ by a QSA

• PCI DSS validation (AOC) within the past 12 months by a QSA

Removed p. 8

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

• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, version 5.1 (“PCI PTS POI Security Requirements”)

• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, version 5.1 or later (“PCI PTS POI Security Requirements”)

Modified p. 8 → 9

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

• Payment Card Industry (PCI) PIN Security Requirements and Testing Procedures 1.3 Updates to Documents and Security Requirements This Program Guide may be modified to reflect 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 (FAQs), and other communication methods.

Modified p. 8 → 9

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.

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 supersede any specifically conflicting provisions of the Program Guide and are generally effective immediately upon 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 …

Modified p. 8 → 9

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.

Payment Card Industry (PCI) Software-based PIN Entry on COTS (SPoC)™ Magnetic Stripe Readers Annex Security and Test Requirements ("SPoC MSR Annex") The SPoC MSR Annex is a supplementary document to the SPoC Security Requirements and SPoC Test Requirements applicable to MSRs in listed SPoC Solutions.

Modified p. 8 → 9

SPoC Solution Evaluation Report Template The SPoC Solution Evaluation Report Template is a form ~~for~~ SPoC Labs to use to document the results of a SPoC Solution Evaluation.

SPoC Solution Evaluation Report Template The SPoC Solution Evaluation Report Template is the mandatory form that SPoC Labs must use to document the results of a SPoC Solution Evaluation.

Removed p. 9

• Section 3, Preparation for the Evaluation

• Section 4, Evaluation and Reporting Processes

• Section 5, Maintaining a Validated Solution Listing 2.1 SPoC Vendors A vendor or provider seeking Acceptance of its candidate SPoC Solution, PIN CVM Application, Monitoring/Attestation System or Back-end Monitoring Environment as part of the SPoC Program, must do the following:

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

Modified p. 9 → 11

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.

Note: SPoC Vendors/Solution Providers are responsible for assuring compliance with all applicable laws, statutes, regulations and rules (including without limitation, privacy laws) that apply to their activities as SPoC Vendors/Solution Providers and any related services or products.

Modified p. 10 → 12

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 Standard, Monitoring/Attestation System vendors must provide documentation describing the secure operation and administration of such applications.

Modified p. 10 → 12

Back-end Monitoring Environment Providers A Back-end Monitoring Environment provider must strictly maintain secure facilities to host Monitoring/Attestation Systems. To be used as part of a valid Solution, Back-end Monitoring Environments must be evaluated and validated by a SPoC Lab in accordance with SPoC ~~Security Requirements, Appendix A, “Monitoring Environment Basic Protections,” to ensure requirements are in place to protect systems and data in this environment.~~

Back-end Monitoring Environment Providers A Back-end Monitoring Environment provider must strictly maintain secure facilities to host Monitoring/Attestation Systems. To be used as part of a valid Solution, Back-end Monitoring Environments must have been evaluated within the preceding 12 months and validated by a SPoC Lab in accordance with the SPoC Standard.

Modified p. 10 → 12

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 …

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

Removed p. 11

PCI PTS Approved Device list with an SCR Approval Class;

Modified p. 11 → 12

Note: If PIN processing 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 Derived Test Requirements is also required and evidence submitted to the applicable payment brand(s).~~

Note: If PIN processing is performed in the Back-end Monitoring Environment, a full PIN audit in accordance with the PCI PIN Security Requirements and Testing Procedures performed by a

Modified p. 11 → 13

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

Note: Except as described in the SPoC MSR Annex, only validated SCRP devices that are listed on the PCI PTS Approved Device List are permitted for use in validated SPoC Solutions.

Modified p. 11 → 13

• PCI PTS POI Modular Security Requirements

• PCI PTS POI Modular Security Requirements with an SCR Approval Class

Modified p. 11 → 13

Note: The magnetic stripe reader must be listed as an approved PCI PTS device on the

Note: The magnetic stripe reader must be listed as an approved PCI PTS device on the PCI PTS Approved Device list.

Modified p. 11 → 13

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

• The security requirements identified in the SPoC MSR 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 MSR Annex.

Modified p. 11 → 13

When a MSR is used in a SPoC Solution, only the device(s) included in the Solution Listing are validated/permitted for use in that Solution.

When an MSR is used in a SPoC Solution, only the device(s) included in the Solution Listing are validated/permitted for use in that Solution.

Removed p. 12

A Third-Party Service Provider must have its third-party services reviewed during each SPoC Solution Evaluation in which its service is used. Note that Third-Party Service Provider services that load key materials must comply with all applicable PCI PIN Security Requirements. Third-Party Service Providers are not eligible for Listing with regard to the SPoC Program.

Modified p. 12 → 14

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

• Evaluating PIN CVM Applications, Monitoring/Attestation Systems, Back-end Monitoring Environments and overall SPoC Solutions in accordance with the SPoC Standard

Modified p. 12 → 14

• Evaluating conformance of non-PTS approved MSRs to the SPoC Annex.

• Evaluating conformance of non-PTS approved MSRs to the SPoC MSR Annex.

Modified p. 12 → 14

• Providing ~~an opinion regarding whether~~ the Solution meets the SPoC ~~Security Requirements~~

• Providing evidence to validate how the Solution meets the SPoC Standard

Modified p. 12 → 14

• Providing sufficient evidence within the Evaluation Report to demonstrate that the Solution complies with the SPoC ~~Security Requirements~~

• Providing sufficient evidence within the Evaluation Report to demonstrate that the Solution complies with the SPoC Standard

Modified p. 12 → 14

• 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 Solution Provider

Modified p. 12 → 14

A PCI-recognized PTS Laboratory interested in becoming a SPoC Lab should contact PCI ~~SSC.~~

A PCI-recognized PTS Laboratory interested in becoming a SPoC Lab should contact PCI SSC for additional information.

Modified p. 13 → 15

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, PCI approved MSRs and magnetic stripe readers not currently classified as SCR; only PTS Labs are authorized by PCI SSC to Evaluate such devices used in SPoC Solutions.

Modified p. 13 → 15

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

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) complies with the SPoC Standard.

Modified p. 13 → 15

In addition to the ~~above,~~ and for the purposes of the SPoC Program, PTS Labs are responsible ~~for:~~

In addition to the above and for the purposes of the SPoC Program, PTS Labs are responsible

Modified p. 13 → 15

• Documenting each SCRP device Evaluation in a report

• Documenting each SCRP device or magnetic stripe reader Evaluation in a report

Modified p. 13 → 15

• Providing adequate documentation within the applicable report to demonstrate 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 (or SPoC MSR Annex).

Modified p. 13 → 15

• 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 (or MSR, as applicable) device Vendor

Modified p. 13 → 15

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

Note: 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. 14 → 16

PCI SSC is the standards body that maintains the PCI SSC ~~standards.~~ In relation to the SPoC ~~Security Requirements,~~ PCI SSC:

PCI SSC is the standards body that maintains the PCI SSC Standards. In relation to the SPoC Standard, PCI SSC:

Modified p. 14 → 16

• 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

Modified p. 14 → 16

• Hosts the List of Validated SPoC Solutions on the ~~Website;~~

• Hosts the List of Validated SPoC Solutions on the Website

Modified p. 14 → 16

• Qualifies SPoC Labs to evaluate and validate SPoC Solutions and SPoC Elements for compliance with the SPoC ~~Security Requirements;~~

• Qualifies SPoC Labs to evaluate and validate SPoC Solutions and SPoC Elements for compliance with the SPoC Standard

Modified p. 14 → 16

• Maintains and updates the SPoC ~~Security Requirements, SPoC Test Requirements~~ and related documentation including FAQs; and

• Maintains and updates the SPoC Standard and related documentation including FAQs; and

Modified p. 14 → 16

• Reviews all Solution Evaluation Reports submitted to PCI SSC ~~and related change submissions~~ for quality assurance and compliance with baseline quality standards.

• Reviews all Solution Evaluation Reports and related change submissions submitted to PCI SSC for quality assurance and compliance with baseline quality standards.

Modified p. 14 → 16

• The SPoC Lab has determined that the Solution complies with the SPoC ~~Security Requirements.~~

• The SPoC Lab has determined that the Solution complies with the SPoC Standard

Modified p. 14 → 16

• The SPoC Lab has submitted a corresponding Solution Evaluation Report to PCI ~~SSC.~~

• The SPoC Lab has submitted a corresponding Solution Evaluation Report to PCI SSC

Modified p. 14 → 16

• The Solution Evaluation ~~report~~ satisfied all PCI SSC requirements as of the time of the review.

• The Solution Evaluation Report satisfied all PCI SSC requirements as of the time of the review.

Removed p. 15

The SPoC Security Requirements and SPoC Test Requirements also contain requirements for Solutions and SPoC Elements (SCRPs, optional MSRs, PIN CVM Applications, Monitoring/Attestation Systems and Back-end Monitoring Environments) that are used in the Solution.

Modified p. 15 → 17

Note: SPoC ~~Vendors,~~ SPoC Labs and Assessors are expected to be acutely familiar with each module within the SPoC ~~Security Requirements and SPoC Test Requirements~~ before commencing an Evaluation.

Note: SPoC Solution Providers, SPoC Labs and Assessors are expected to be acutely familiar with each module within the SPoC Standard before commencing an Evaluation.

Modified p. 15 → 17

• See the SPoC ~~Security Requirements to~~ Module 6, “Secure Card Reader (SCRP)”

• See the SPoC Standard Module 6, “Secure Card Reader (SCRP)”

Modified p. 15 → 17

• See the PCI PTS POI Modular Security Requirements (version 5.1 or later) and supporting documentation in the Document Library on the Website. The secure-card reader vendor is responsible for obtaining and maintaining PTS Program device approval. For devices that require approval, such approval is a prerequisite for the devices that are part of a SPoC Solution Evaluation. As part of a Solution Evaluation, SPoC Labs request evidence that PTS Program device approvals are current. Device vendors who seek device …

• See the PCI PTS POI Modular Security Requirements (version 5.1 or later) and supporting documentation in the Document Library on the Website. The secure-card reader vendor is responsible for obtaining and maintaining PTS Program device approval. For devices that require approval, such approval is a prerequisite for the devices that are part of a SPoC Solution Evaluation. As part of a Solution Evaluation, SPoC Labs request evidence that PTS Program device approvals are current. SPoC Labs shall obtain all …

Modified p. 16 → 18

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

• MSRs that are not listed by the PCI PTS POI Program but meet the security requirements listed in the SPoC MSR 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 …

Modified p. 16 → 18

• SPoC ~~Security Requirements,~~ including Module 2, “PIN Cardholder Verification Method (CVM) Application”

• SPoC Standard, including Module 2, “PIN Cardholder Verification Method (CVM) Application”

Modified p. 16 → 18

• SPoC ~~Security Requirements,~~ Appendix D, “Application Security Requirements”

• SPoC Standard, Appendix D, “Application Security Requirements”

Modified p. 16 → 18

• 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. However, the Application 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. Note: If the PIN CVM Application and/or the supporting Monitoring/Attestation System requires any additional software to be installed on the SCRP device, that software must also be tested …

• 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. However, the PIN CVM Application 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. Note: If the PIN CVM Application and/or the supporting Monitoring/Attestation System requires any additional software to be installed on the SCRP device, that software must also …

Modified p. 16 → 18

~~Monitoring/Atte station~~ System (“Monitoring System”) Monitoring/Attestation Systems must be validated by a SPoC Lab against:

Monitoring/ Attestation System (“Monitoring System”) Monitoring/Attestation Systems must be validated by a SPoC Lab against:

Modified p. 16 → 18

• SPoC ~~Security Requirements,~~ including Module 3, “Back-end Systems

• SPoC Standard, including Module 3, “Back-end Systems

Modified p. 16 → 18

• SPoC ~~Security Requirements,~~ Module 4, “Solution Integration Requirements”

• SPoC Standard, Module 4, “Solution Integration Requirements”

Modified p. 16 → 19

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

• 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 required. In such cases, the Solution Provider’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. SPoC Labs shall obtain the AOC as evidence, verify it is current (i.e., issued within the past 12 months of the SPoC …

Modified p. 16 → 19

• 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 Testing Procedures performed by a PCI QPA is also required. SPoC Labs shall obtain the AOC as evidence, verify it is current (i.e., issued within the past 12 months of the SPoC Evaluation Report submission) and submit the AOC via the Portal with the SPoC Evaluation Report.

Removed p. 17

• 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. 17 → 19

• PCI DSS validation ~~(ROC and AOC)~~ by a QSA

• PCI DSS validation (AOC) by a QSA

Modified p. 17 → 19

Note: The Solution development and test process is defined in the SPoC ~~Security Requirements and SPoC Test Requirements. These documents include~~ guidance for implementing requirements, ~~testing,~~ and validating compliance with each requirement.

Note: The Solution development and test process is defined in the SPoC Standard. This document(s) includes guidance for implementing requirements, testing and validating compliance with each requirement.

Modified p. 17 → 19

• Review the SPoC ~~Security Requirements, SPoC Test Requirements,~~ and all related documentation ~~located~~ on the Website.

• Review the SPoC Standard, technical FAQs and all related documentation on the Website.

Modified p. 17 → 19

• Determine the Solution’s readiness to comply with the SPoC ~~Security Requirements:~~

• Determine the Solution’s readiness to comply with the SPoC Standard:

Modified p. 17 → 19

• Perform a gap analysis between security ~~function~~ and the SPoC ~~Security Requirements;~~

• Perform a gap analysis between the candidate solution’s security functions and the SPoC Standard;

Modified p. 17 → 19

• If desired, the SPoC Lab may perform a pre-Evaluation or gap analysis of a candidate SPoC Element or candidate SPoC Solution. If the SPoC Lab notes deficiencies that would prevent a compliant result, the SPoC Lab may provide a list of issues to the ~~Vendor~~ to be addressed before the formal Evaluation process begins.

• If desired, the SPoC Lab may perform a pre-Evaluation or gap analysis of a candidate SPoC Element or candidate SPoC Solution. If the SPoC Lab notes deficiencies that would prevent a compliant result, the SPoC Lab may provide a list of issues to the Solution Provider to be addressed before the formal Evaluation process begins.

Modified p. 17 → 20

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

• SPoC 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. 18 → 20

• Candidate Solution or element initial level of compliance with the SPoC Program requirements

•more corrections ~~means~~ a longer review and ~~validation.~~

• Candidate Solution or element initial level of compliance with the SPoC Standard and Program requirements

•more corrections mean a longer review and validation

Modified p. 18 → 20

• Prompt payment of fees to PCI SSC

•PCI SSC will not start the review process until the applicable fees are ~~paid.~~

• Prompt payment of fees to PCI SSC

•PCI SSC will not start the review process until the applicable fees are paid

Modified p. 18 → 20

• Incomplete submissions or errors. For example, missing, incomplete or unsigned documents will delay the review and acceptance ~~process.~~

• Incomplete submissions or errors. For example, missing, incomplete or unsigned documents will delay the review and acceptance process

Removed p. 19

• The vendor-signed copy of the VRA

The Portal is also used by PCI SSC to track communications relating to a submission.

Modified p. 19 → 21

• ~~Vendor’s~~ agreement with the SPoC Program requirements, policies, and procedures

• Solution Provider’s agreement with the SPoC Program requirements, policies, and procedures

Modified p. 19 → 21

• Permission for the ~~Vendor’s~~ SPoC Lab to release Evaluation Reports, AOVs, and related materials to PCI SSC for review

• Permission for the Solution Provider’s SPoC Lab to release Evaluation Reports, AOVs, and related materials to PCI SSC for review

Modified p. 19 → 21

• ~~Vendor’s~~ agreement to adopt and comply with industry standard ~~Vulnerability Handling Policies.~~

• Solution Provider’s agreement to adopt and comply with industry standard vulnerability handling policies.

Modified p. 19 → 21

For PCI SSC to review an Evaluation Report, the SPoC Lab must provide ~~the~~ PCI SSC with the ~~following:~~

For PCI SSC to review an Evaluation Report, the SPoC Lab must provide PCI SSC with the Solution Provider-signed copy of the VRA.

Modified p. 19 → 21

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

While an executed copy of the then most current version of the VRA (available on the Website) is on file with PCI SSC for the respective Solution Provider, the SPoC Lab is not required to resubmit the same VRA with each subsequent Evaluation Report for the same Solution Provider.

Modified p. 20 → 22

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.

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 Solution Provider for all Acceptance Fees, and the Solution Provider will pay these fees directly to PCI SSC.

Modified p. 20 → 22

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.

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 Solution Provider delays in annual revalidation of a Validated SPoC Solution. See the Fee Schedule on the Website for more information.

Modified p. 21 → 23

1. The SPoC ~~Vendor (or Vendor)~~ contracts with a SPoC Lab to perform an Evaluation of the Solution and negotiates the cost and any associated confidentiality and ~~non-disclosure~~ agreements with the SPoC Lab.

1. The SPoC Solution Provider contracts with a SPoC Lab to perform an Evaluation of the candidate Solution and negotiates the cost and any associated confidentiality and non- disclosure agreements with the SPoC Lab.

Modified p. 21 → 23

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.

2. The Solution Provider 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 and access to systems (including onsite access if required) as the SPoC Lab must perform appropriate testing and cannot rely solely on evidence submitted by the Solution Provider. For information about required documentation and materials, see Section 3.3, Required Documentation. The SPoC Lab may also require access to …

Modified p. 21 → 23

When the Monitoring/Attestation System resides in a ~~Back-end Monitoring Environment provider’s~~ cardholder data environment (CDE), ~~each of these~~ must adhere to PCI DSS, including DSS Appendix A3: Designated Entities Supplemental Validation (DESV).

Note: When the Monitoring/Attestation System resides in a cardholder data environment (CDE), the environment must adhere to PCI DSS, including DSS Appendix A3: Designated Entities Supplemental Validation (DESV).

Modified p. 21 → 23

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

If PAN or SAD is not present in the Monitoring/Attestation System’s environment (i.e., it is not part of a CDE), the environment must comply with the logical and physical security requirements defined in the SPoC Standard, Appendix A, “Back-end Monitoring Environment Basic Protections.”

Modified p. 21 → 23

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.

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 Standard. The Solution and elements are validated in accordance with the SPoC Test Requirements.

Modified p. 21 → 24

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.

5. If the SPoC Lab determines that the Solution complies with the SPoC Standard, the SPoC Lab submits the corresponding Evaluation Report and AOV (for each Solution), the Solution Provider’s signed VRA, Solution Provider’s Back-end Environment AOC(s), if applicable, and any other requested documentation to PCI SSC via the Portal in accordance with applicable PCI SSC templates, guidance and instructions.

Modified p. 21 → 24

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.

6. If required, the Solution Provider 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 provides PCI SSC with an updated Evaluation Report.

Modified p. 21 → 24

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.

7. PCI SSC issues an invoice to the Solution Provider for the applicable Acceptance Fee. After the Solution Provider 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 Solution Provider that the Solution has successfully completed the process.

Modified p. 21 → 24

8. PCI SCC ~~counter-signs~~ the AOV and sends a copy to the ~~Vendor~~ and the SPoC Lab.

8. PCI SCC countersigns the AOV and sends a copy to the Solution Provider and the SPoC Lab.

Removed p. 22

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.

Modified p. 22 → 24

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

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 Back-end Monitoring Environment that meets all applicable requirements.

Modified p. 22 → 24

Additionally, the ~~Vendor~~ must provide access to the following:

Additionally, the Solution Provider must provide access to the following:

Removed p. 25

• The Vendor is capable of and demonstrably migrating merchants from unsupported COTS platforms.

Modified p. 25 → 29

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.

PCI SSC typically provides a courtesy reminder via e-mail to the Solution Provider’s Primary Contact (listed on the AOV) within 90 calendar days of each checkpoint. However, it is the sole responsibility of the Solution Provider to comply with checkpoint requirements and maintain its Listings, regardless of courtesy reminders.

Modified p. 25 → 29

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.

Note: Solution Providers 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. 25 → 29

As part of the annual checkpoint process, ~~Vendors are~~ must confirm any changes that have been made to the Solution, and that:

As part of the annual checkpoint process, the Solution Provider must confirm any changes that have been made to the Solution, and that:

Modified p. 25 → 29

• Changes have been applied in a way that is consistent with the SPoC ~~Security Requirements.~~

• Changes have been applied in a way that is consistent with the SPoC Standard.

Modified p. 26 → 30

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

• Changes to the documents described in the SPoC Standard are provided to the SPoC Lab for review annually (12-month and 24-month checkpoints).

Modified p. 26 → 30

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

The Solution Provider 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, Solution Provider’s Back-end Environment AOC(s), if applicable, and any applicable documentation to PCI SSC using the Portal.

Modified p. 26 → 30

An updated AOV and redlined Evaluation Report must be submitted to PCI SSC ahead of the annual checkpoint date. PCI SSC has 30 calendar days to review and accept the submission. If PCI SSC does not receive the submission before the annual checkpoint date, the Listing will be subject to early administrative expiry, as follows:

An updated AOV and redlined Evaluation Report must be submitted to PCI SSC up to 60 calendar days ahead of the annual checkpoint date. PCI SSC has 30 calendar days to review and accept the submission. If PCI SSC does not receive the submission before the annual checkpoint date, the Listing will be subject to early administrative expiry, as follows:

Modified p. 26 → 30

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

• 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 for a period of no longer than 90 calendar days, after which time the Solution will be moved to the SPoC Solution Expired List. A full Evaluation (including applicable fees) is required to return the Solution Listing status to good standing.

Modified p. 26 → 30

2. When completeness is established, sign and return a copy of the updated AOV to the ~~Vendor~~ and SPoC Lab.

2. When completeness is established, sign and return a copy of the updated AOV to the Solution Provider and SPoC Lab.

Removed p. 27

Designated Designated Changes are for changes to the Solution’s Website Listing:

Modified p. 27 → 31

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.

Table 2: Changes to 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.

Modified p. 27 → 31

• 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

• 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 MSR Annex) for use in the Solution

Modified p. 27 → 31

• Add/remove a validated PIN CVM Application ~~For details, see Section 5.2.2, Designated Changes for Solutions.~~

• Add/remove a validated PIN CVM Application (or optional SPoC API)

Modified p. 27 → 31

~~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 reported in detail but are addressed by the ~~Vendor~~ during the annual checkpoint.

No impact Change Any change that does not impact security functions or compliance with the SPoC Standard, such as maintenance patches or routine key rotation. No impact Changes are not reported in detail but are addressed by the Solution Provider during the annual checkpoint.

Modified p. 27 → 31

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.

Delta Change Limited to non-high-impact changes where the SPoC Lab determines that the change has a low security risk or has a low impact on compliance with the SPoC Standard, for example:

Modified p. 27 → 31

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

High impact Change High impact Changes are changes where the SPoC Lab determines that the extent of the change has a high security risk or a significant impact on the overall SPoC Solution; a full Evaluation of the SPoC Solution 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). Note: Adding support for a major version of a COTS operating system …

Modified p. 28 → 32

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:

The Solution Provider prepares a change analysis using the Change Impact template (Appendix C) and submits it to the SPoC Lab for review. At a minimum, the change analysis must contain the following information:

Modified p. 28 → 32

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

• Description of why the change is necessary The Solution Provider 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. 28 → 32

1. The SPoC Lab notifies the ~~Vendor~~ that the change is eligible.

1. The SPoC Lab notifies the Solution Provider that the change is eligible.

Modified p. 28 → 32

2. The ~~Vendor~~ prepares the change documentation, signs the corresponding AOV, and sends the documentation to the SPoC Lab.

2. The Solution Provider prepares the change documentation, signs the corresponding AOV, and sends the documentation to the SPoC Lab.

Modified p. 28 → 32

3. If applicable, the ~~Vendor~~ completes a new VRA.

3. If applicable, the Solution Provider completes a new VRA.

Modified p. 28 → 32

6. PCI SSC sends the Change Fee invoice to the ~~Vendor.~~

6. PCI SSC sends the Change Fee invoice to the Solution Provider.

Modified p. 28 → 32

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.

If the SPoC Lab does not agree that the change is eligible as an Administrative Change, the SPoC Lab works with the Solution Provider to resolve the disagreement.

Modified p. 28 → 32

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.

2. Signs and returns a copy of the corresponding AOV to the Solution Provider and the SPoC Lab. The Revalidation date of the updated Listing remains the same as that of the parent Listing.

Removed p. 29

Designated Changes for Solutions Designated Changes are intended to keep the Website Listing up-to-date. Designated Changes are amendments made only to a listed Solution’s current Website Listing to do one of the following:

• 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

• Add/remove a validated PIN CVM Application used in a Solution.

If the SPoC Lab agrees that the change is eligible as a Designated Change:

1. The SPoC Lab notifies the Vendor that the change is eligible.

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 …

Modified p. 29 → 33

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:

The Solution Provider prepares a change analysis using the Change Impact template (Appendix C) and submits it to the SPoC Lab for review. At a minimum, the change analysis must contain the following information:

Modified p. 29 → 33

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

• Description of why the change is necessary The Solution Provider should submit the change analysis to the same SPoC Lab that performed the previous full Evaluation, as changing SPoC Labs requires a full Evaluation of the SPoC Solution. If the SPoC Lab does not agree that the change is eligible as a Delta Change, the SPoC Lab works with the Solution Provider to resolve the disagreement.

Removed p. 30

7. PCI SSC sends a Change Fee invoice to the Vendor.

8. Upon payment of the invoice, PCI SSC reviews the Designated Change submission.

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.

Following a successful PCI SSC review of the change, PCI SSC does the following:

1. Amends the List of Validated SPoC Solutions on the Website with the new information.

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.

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 …

Modified p. 31 → 33

1. The SPoC Lab notifies the ~~Vendor~~ that the change is ~~eligible.~~

1. The SPoC Lab notifies the Solution Provider that the change is eligible,

Modified p. 31 → 34

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

3. The SPoC Lab completes the Change Impact document and produces a red-lined Evaluation Report and documents the testing completed per PCI SSC requirements,

Modified p. 31 → 34

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

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,

Modified p. 31 → 34

5. PCI SSC sends a Change Fee invoice to the ~~Vendor;~~

5. PCI SSC sends a Change Fee invoice to the Solution Provider,

Modified p. 31 → 34

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.

2. Signs and returns a copy of the AOV to the Solution Provider and the SPoC Lab. The Revalidation date of the updated Listing remains the same as that of the parent Listing.

Modified p. 31 → 34

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.

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 Solution Provider is ineligible for treatment as a Delta Change.

Modified p. 31 → 34

~~High-impact~~ Changes ~~to PIN CVM Application and Monitoring/Attestation Systems High-impact~~ Changes are those affecting a PIN CVM Application and/or supporting Monitoring/Attestation System where the SPoC Lab determines that the magnitude of the change is greater than what can be validated by a Delta Evaluation. Therefore, a full Evaluation of the entire SPoC Solution is necessary. For example, a ~~High-impact~~ Change might impact multiple modules of the SPoC ~~Security Requirements~~ and cannot be tested or validated separately from the Solution. ~~High-impact~~ …

High impact Changes High impact Changes are those affecting a SPoC Solution, PIN CVM Application and/or supporting Monitoring/Attestation System where the SPoC Lab determines that the magnitude of the change is greater than what can be validated by a Delta Evaluation. Therefore, a full Evaluation of the entire SPoC Solution is necessary. For example, a High impact Change might impact multiple modules of the SPoC Standard and cannot be tested or validated separately from the Solution. High impact Changes are …

Removed p. 32

• Change Impact document a

• Solution Attestation of Validation (AOV)

• Red-lined Evaluation Report

Modified p. 32 → 35

Table 4: Change Documentation Administrative Change ~~(All SPoC Elements)~~ Delta Change ~~(Application) Designated Change (Solution)~~ Annual Checkpoint ~~(Solution)~~

Table 3: Change Documentation Administrative Change Delta Change Annual Checkpoint

Modified p. 32 → 35

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

• Current VRA b a The Change Impact document in Appendix C is mandatory for the SPoC Lab when submitting changes to PCI SSC on behalf of Solution Providers. b If applicable.

Removed p. 33

• 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. 33 → 36

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

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

Modified p. 33 → 36

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

Note: The Solution Provider pays all SPoC Solution Evaluation fees directly to the SPoC Lab. The SPoC Lab and the Solution Provider negotiate these fees. PCI SSC sends an invoice to the Solution Provider for all Acceptance and change fees, and the Solution Provider pays these fees directly to PCI SSC.

Modified p. 33 → 37

~~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 of the AOV to the ~~Vendor~~ and the SPoC Lab.

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 of the AOV to the Solution Provider and the SPoC Lab.

Modified p. 34 → 38

Note: PCI SSC review times are estimates and may vary based on ~~work load~~ and other factors.

Note: PCI SSC review times are estimates and may vary based on workload and other factors.

Modified p. 34 → 38

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

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 a countersigned AOV.

Modified p. 34 → 38

For reports on changes to existing Listed Solutions, such as Delta Changes, the same process applies. Upon determining that no issues or questions remain, PCI SSC posts revised information to the Website and issues a ~~revised approval letter.~~ Delta reports are prepared using the same major requirements that were used during the original Solution Evaluation.

For reports on changes to existing Listed Solutions, such as Delta Changes, the same process applies. Upon determining that no issues or questions remain, PCI SSC posts revised information to the Website and issues a countersigned AOV. Delta reports are prepared using the same major requirements that were used during the original Solution Evaluation.

Modified p. 35 → 39

Figure 4: SPoC Solution Process 6.2 Delivery of the Evaluation Report and Related Materials To list a Solution on the Website, the SPoC Lab (on behalf of the ~~Vendor)~~ must submit all Solution-validation-related documents to PCI SSC through PCI SSC’s secure website (Portal). PCI SSC pre-screens the submissions in the Portal to ensure that all required documentation has been included, and the basic submission requirements have been satisfied.

Figure 4: SPoC Solution Process 6.2 Delivery of the Evaluation Report and Related Materials To list a Solution on the Website, the SPoC Lab (on behalf of the Solution Provider) must submit all Solution-validation-related documents to PCI SSC through PCI SSC’s secure website (Portal). PCI SSC pre-screens the submissions in the Portal to ensure that all required documentation has been included, and the basic submission requirements have been satisfied.

Modified p. 35 → 39

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

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, unsupported COTS operating systems and incomplete or inconsistent documentation.

Modified p. 36 → 40

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,

PCI SSC reviews each Evaluation Report after the Solution Provider pays the acceptance fee. PCI SSC first screens the submission to ensure that it is complete. If the submission is complete, PCI SSC reviews the submission in its entirety.

Modified p. 36 → 40

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

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

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.

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.

Modified p. 37 → 41

No SPoC ~~Vendor~~ or other third party may refer to a SPoC Solution or SPoC Element as “PCI Approved,” or “PCI SSC Approved” or otherwise state or imply that PCI SSC has, in whole or part, approved any aspect of a SPoC ~~Vendor~~ or its SPoC Solution or SPoC Element, except to the extent and subject to the terms and restrictions expressly set forth in a written agreement with PCI SSC, or in a corresponding AOV provided by PCI SSC. …

No SPoC Solution Provider or other third party may refer to a SPoC Solution or SPoC Element as “PCI Approved,” or “PCI SSC Approved” or otherwise state or imply that PCI SSC has, in whole or part, approved any aspect of a SPoC Solution Provider or its SPoC Solution or SPoC Element, except to the extent and subject to the terms and restrictions expressly set forth in a written agreement with PCI SSC, or in a corresponding AOV provided by …

Modified p. 37 → 41

When granted, PCI SSC Acceptance is provided to ensure certain security and operational characteristics important to the achievement of PCI SSC’s goals, but such acceptance does not under any circumstances include or imply any endorsement or warranty regarding the applicable SPoC ~~Vendor~~ or the functionality, quality or performance of the SPoC Solution or SPoC Element or any other product or service. PCI SSC does not warrant any products or services provided by third parties. PCI SSC acceptance does not, under …

When granted, PCI SSC Acceptance is provided to ensure certain security and operational characteristics important to the achievement of PCI SSC’s goals, but such acceptance does not under any circumstances include or imply any endorsement or warranty regarding the applicable SPoC Solution Provider or the functionality, quality or performance of the SPoC Solution or SPoC Element or any other product or service. PCI SSC does not warrant any products or services provided by third parties. PCI SSC acceptance does not, …

Removed p. 38

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.

Table 5 describes the Solution Identifier fields.

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

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:

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:

• PIN CVM Application(s) Evaluated: Identifies the PIN CVM Application(s) validated for use with this Solution.

Modified p. 39 → 43

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 service in another SPoC Solution would require Evaluation as part of each SPoC Solution of which the third-party service is a part.

Removed p. 40

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.

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.

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 this field signify that the Solution is overdue for submission to PCI SSC.

Modified p. 41 → 45

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.

The Solution Provider and/or SPoC Lab must complete each applicable section of this document and all other required documents based on the type of change (see Table 2). The SPoC Lab submits this SPoC Change Impact form with supporting documentation to PCI SSC for review.

Removed p. 49

Delta Change

• Change Summary Change # Detailed description of the change Description of the purpose of the change Description of how SPoC security is impacted Additional details, as applicable:

Generate a red-lined Evaluation Report review for the changes to the PIN CVM Application or Monitoring/Attestation System (if applicable).

Note: For details about required documentation for SPoC Solution submissions that include MSRs, see the SPoC Annex.

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.

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 …

Removed p. 51

• Development procedures

• Protection mechanisms

• Vulnerability management and security testing Development 2.1.2 Documentation must exist and be maintained to detail the following:

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

• Details of all areas where functions provided by the application are executed. This should include the main processing environment of the COTS device but may also include other local execution environments (such as a TEE or embedded security processor).

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

• Block diagram that indicates where all sensitive data is available in clear text on the merchant- side systems. This includes, but may not be limited …

Removed p. 52

• Process that is demonstrably in use for the discovery and remediation of bugs and vulnerabilities in the system.

• Methodology used to address vulnerabilities

• Roles and responsibilities COTS System Baseline 3.1.1 Documentation must exist and be maintained for the following:

• Implemented processes to determine the system baseline for acceptance of COTS devices (for example whitelist, blacklist, or hybrid approach)

• How these processes account for known and potential vulnerabilities in systems.

• Clear identification of roles and responsibilities for which aspects of the system baseline validation process are performed by the PIN CVM Application itself, and which are performed by other systems or execution environments.

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.

Attestation policy for SCRP, COTS, PIN CVM Application Attestation Mechanism 3.2.1 A documented attestation policy that defines health-check rules for the …

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

Attestation update policy and procedures Attestation Mechanism 3.2.12 Attestation mechanism changes must adhere to formal change-control procedures.

Removed p. 52

• There must be documented procedures.

• Deployment of changes to the production environment must require dual control.

Removed p. 53

d) Temporarily stop transaction processing to update obsolete solution components (either internal or third-party dependencies).

Removed p. 53

• Decisions are made to remove previously acceptable platforms from the system baseline

• Such changes affect the parties using these platforms. Documentation must also include how communication is handled in these cases.

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:

• The methods used to assess on-going risk of the Solution;

• How and when updates to the system baseline are performed

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

Back-end Monitoring Environment Operational Procedures Operational Management 3.7.1 Documented procedures to support the operation of the Back-end Monitoring Environment must exist and be demonstrably in use.

Removed p. 54

• Confirmation that all operation-management processes are being performed

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

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.

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 …

Removed p. 55

Back-end Monitoring Environment investigation and response procedures A2.3 Alerts must be generated for action by responsible personnel upon detection of suspicious activity or anomalies. Establish and follow procedures for investigation and response.

Vulnerability Management policy and procedures Vulnerability Management A3.2 Procedures to identify and rate vulnerabilities based on their criticality must exist and be in use. Procedures must align with industry-accepted practices.

Access control procedures Access Controls A.4.2 Documented procedures for granting and managing access must exist and be in use.

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.

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:

• Procedures for the timely investigation of alerts by responsible personnel

• …

Removed p. 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:

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

Software Development policy and procedures including change control practices.

Application Security Requirement The software development process must be based on a formal process for secure development of applications, which includes:

• Development processes based on industry standards and/or best practices

• Information security incorporated throughout the software development life cycle

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

Removed p. 57

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

• Documentation of impact

• Documented approval of change by authorized parties

• Functional testing to verify that the change does not adversely impact the system security

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

• Signature by an authorized party to formally approve release of the application or application update

• Confirmation that the vendor followed secure development processes.

Implementation guide Application Security Requirement D15 Develop, maintain, and disseminate an implementation guide that:

• Provides relevant information specific to the application

• Addresses all requirements …

Modified p. 59 → 54

For additional information, see SPoC ~~Security Requirements,~~ Appendix D, “Application Security Requirements,” (item 9).

For additional information, see the SPoC Standard, Appendix D, “Application Security Requirements,” (item 9).

Modified p. 59 → 54

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 Number Format The Solution Provider 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:

Modified p. 60 → 55

The ~~vendor~~ must document how elements of the application version number are used to

The Solution Provider must document how elements of the application version number are used to identify:

Modified p. 60 → 55

• Changes that impact the application function, but do no impact security or compliance with SPoC ~~Security Requirements~~

• Changes that impact the application function, but do no impact security or compliance with the SPoC Standard

Modified p. 60 → 55

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

• Changes that impact any security function or compliance with the SPoC Standard 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. 60 → 55

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 Solution Provider 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. 60 → 55

~~Vendors~~ must ensure traceability between application changes and version numbers.

Solution Providers must ensure traceability between application changes and version numbers.

Removed p. 61

Table 6 may be found in the documents listed in Section 1.2, Related Publications. All of these documents are available on the Website.

AOV See SPoC Solution Attestation of Validation.

Modified p. 61 → 56

Table 6 lists the terms used in this Program Guide and their meanings. Terms not listed in

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 (each document is available on the Website).

Modified p. 61 → 56

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:

Table 4: 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. 61 → 56

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.

Assessment Assessment of a SPoC Solution’s Back-end Monitoring Environment to validate compliance with the SPoC Standard as part of the SPoC Program.

Modified p. 61 → 56

Assessor A SPoC Lab or a QSA company or a ~~PIN auditor.~~

Assessor A SPoC Lab or a QSA company or a PCI QPA.

Modified p. 61 → 56

Back-end Monitoring Environment The secure facility or environment assessed by a SPoC Lab (or QSA Company or PIN auditor, as applicable) in accordance with SPoC ~~Security Requirements~~ Appendix A, “Monitoring Environment Basic Protections,” which includes (but is not limited to) network infrastructure, physical and logical security controls, access controls, vulnerability management and governance and security ~~policiesin~~ which a Monitoring/Attestation System is hosted.

Back-end Monitoring Environment The secure facility or environment assessed by a SPoC Lab (or QSA Company or PIN auditor, as applicable) in accordance with the SPoC Standard Appendix A, “Monitoring Environment Basic Protections,” which includes (but is not limited to) network infrastructure, physical and logical security controls, access controls, vulnerability management and governance and security policies in which a Monitoring/Attestation System is hosted.

Modified p. 61 → 56

COTS Acronym for commercial off-the-shelf ~~device.~~

COTS Acronym for commercial off-the-shelf [device].

Removed p. 62

PIN auditor Entity approved by one of the Participating Payment Brands to perform assessments of PIN-processing environments.

Modified p. 62 → 57

List of Validated SPoC Solutions The list of Solutions on the Website that have been Accepted for SPoC Program purposes.

List of Validated SPoC Solutions The list of SPoC Solutions on the Website that have been Accepted for SPoC Program purposes.

Modified p. 62 → 57

MSR Acronym for Magnetic Stripe Reader (or Magstripe Reader). See SPoC Annex for details.

MSR Acronym for Magnetic Stripe Reader (or Magstripe Reader). See SPoC MSR Annex for details.

Modified p. 62 → 57

Monitoring/Attestation System An ~~applicationwhich~~ includes any COTS device-side and back-end monitoring and/or attestation software ~~applicationsthat~~ 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 …

Monitoring/Attestation System An application which includes any COTS device-side and back-end monitoring and/or attestation software applications that 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 Standard, the Monitoring/Attestation System is an implementation that may be shared across different execution environments and which provides a level of validation and assurance …

Modified p. 62 → 57

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 not listed on the PCI PTS Approved Device list.

Non-PTS approved MSR A Magnetic Stripe Reader that has not undergone evaluation and approval by a PTS Lab in accordance with the PCI PIN Transaction Security POI Standard. Non-PTS approved MSRs are not listed on the PCI PTS Approved Device list.

Modified p. 62 → 57

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.

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 the SPoC Standard for additional details.

Modified p. 63 → 58

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.

Modified p. 63 → 58

~~QSA~~ A QSA Employee or QSA Company as defined in the QSA Qualification Requirements.

Qualified Security Assessor (QSA) A QSA Employee or QSA Company as defined in the QSA Qualification Requirements.

Modified p. 63 → 58

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.

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 Standard for additional details.

Removed p. 64

SPoC Test Requirements Requirements that dictate the set of tests that must be performed to confirm compliance with the SPoC Security Requirements.

Modified p. 64 → 59

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:

SPoC Solution Evaluation (or Evaluation) Evaluation of a Solution by a SPoC Lab for purposes of validating compliance against the SPoC Standard as part of the SPoC Program, including but not limited to:

Modified p. 64 → 59

• Evaluation of the PIN CVM Application and supporting Monitoring/Attestation System incorporated ~~therein;~~

• Evaluation of the PIN CVM Application and supporting Monitoring/Attestation System incorporated therein

Modified p. 64 → 59

• Testing and validation of the above with optional MSR(s), including evaluation of any non-PTS Approved MSRs used in the SPoC ~~Solution;~~

• Testing and validation of the above with optional MSR(s), including evaluation of any non-PTS Approved MSRs used in the SPoC Solution

Modified p. 64 → 59

• Back-end Monitoring Environment and all other elements of the ~~Solution;~~ and

• Back-end Monitoring Environment and all other elements of the Solution, and

Document Comparison

Content Changes