Document Comparison
SPoC_Program_Guide_v1.2_June_2020.pdf
→
SPoC_Program_Guide_v1.3.pdf
87% similar
60 → 59
Pages
17622 → 18104
Words
27
Content Changes
Content Changes
27 content changes. 56 administrative changes (dates, page numbers) hidden.
Added
p. 7
• PCI PIN validation AOC(s) for any key-injection facility(s) (KIF) involved in injecting keys for the SCRP, issued within the past 12 months of the SPoC Evaluation Report submission, by a PCI Qualified PIN Assessor (QPA), qualified by PCI SSC and listed on the Website as a QPA
In addition to the documents listed in the table, see the current versions of the following documents, each of which is available on the Website:
Payment Card Industry (PCI) Software-based PIN Entry on COTS (SPoC)™ SPoC Unsupported OS Annex (“SPoC Unsupported OS Annex”) The SPoC Unsupported OS Annex is a supplementary document to the SPoC Security Requirements and SPoC Test Requirements applicable to unsupported operating systems used in listed SPoC Solutions.
In addition to the documents listed in the table, see the current versions of the following documents, each of which is available on the Website:
Payment Card Industry (PCI) Software-based PIN Entry on COTS (SPoC)™ SPoC Unsupported OS Annex (“SPoC Unsupported OS Annex”) The SPoC Unsupported OS Annex is a supplementary document to the SPoC Security Requirements and SPoC Test Requirements applicable to unsupported operating systems used in listed SPoC Solutions.
Added
p. 10
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 publication. PCI SSC reserves the right to change, amend, or withdraw security requirements, training, and/or other requirements at any time.
Added
p. 17
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 at the time of the Evaluation, or SPoC Solutions evaluated and validated to security requirements in the SPoC Unsupported OS Annex will be accepted for approval and listing by PCI SSC. Multiple major versions of a vendor-supported OS (e.g., 8.x, 9.x, etc.) are permitted for inclusion in a single SPoC Evaluation Report. The SPoC Lab will test and report on each major OS version, for each test requirement, and all major versions of the OS submitted and validated will be listed as part of the SPoC Solution in which they are included. Support for different COTS platforms (e.g., Android, iOS, etc.) are considered separate SPoC Solutions, and therefore require separate Evaluation reports, …
Added
p. 20
• While SPoC Security Requirement 2.2.2 requires that PIN CVM Applications must be developed only for operating systems (OS) that are supported by the OS vendor, PCI SSC has published an optional SPoC Unsupported OS Annex which outlines additional security controls to allow SPoC Solution providers to support COTS devices with unsupported operating systems. Otherwise, all new SPoC Solutions must operate only on supported platforms and the COTS System Baseline (see the SPoC Standard) must only include versions of a COTS OS that is supported by the OS vendor at the time of Evaluation.
Added
p. 29
Note: In cases where the SPoC Solution Provider wants to allow COTS devices with unsupported OS, the SPoC Lab must perform additional testing to confirm security objectives outlined in the SPoC Unsupported OS Annex are met.
Added
p. 37
If evaluation per the SPoC Unsupported OS Annex is not performed or the implemented security controls and processes are not accepted by the SPoC Lab, the SPoC Standard requires (Security Requirement 4.3.7) that merchants who are using the PIN CVM Application on affected platforms be notified by the SPoC Solution Provider, and the listed SPoC Solution will be shown on the Website listing as expired within the Solution Details portion of the SPoC listing.
Added
p. 56
Participating Payment Brand (or Payment Brand) A payment card brand that, as of the time in question, is then formally admitted as (or an affiliate of) a member of PCI SSC pursuant to its governing documents. Note: At the time of this publication, Participating Payment Brands include PCI SSC’s Founding Members and Strategic Members.
Removed
p. 6
• PCI DSS validation (AOC) within the past 12 months by a QSA
Modified
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 …
• 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 …
Modified
p. 6 → 7
• PCI PIN validation (AOC) within the past 12 months by a PCI Qualified PIN Assessor (QPA), qualified by PCI SSC and listed on the Website as a QPA.
• PCI PIN validation (AOC), issued within the past 12 months of the SPoC Evaluation Report submission by a PCI Qualified PIN Assessor (QPA), qualified by PCI SSC and listed on the Website as a QPA
Removed
p. 9
• 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. 9
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, version 5.1 or later (“PCI PTS POI Security Requirements”)
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements (“PCI PTS POI Security Requirements”)
Modified
p. 9
• Payment Card Industry (PCI) PIN Security Requirements and Testing Procedures 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.
Removed
p. 17
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 at the time of the Evaluation will be accepted for approval and listing by PCI SSC. See SPoC Security Requirement 2.2.2 for additional details. Multiple major versions of a vendor-supported OS (e.g., 8.x, 9.x, etc.) are permitted for inclusion in a single SPoC Evaluation Report. The SPoC Lab will test and report on each major OS version, for each test requirement, and all major versions of the OS submitted and validated will be listed as part of the SPoC Solution in which they are included. Support for different COTS platforms (e.g., Android, iOS, etc.) are considered separate SPoC Solutions, and therefore require separate Evaluation reports, validation and listings on the Website.
Modified
p. 18
• 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 …
• 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. 19
• PCI PIN validation (AOC) by a PCI QPA SPoC Labs shall obtain the AOC(s) as evidence, verify they are current (i.e., issued within the past 12 months of the SPoC Evaluation Report submission), and submit the AOC(s) via the Portal with the SPoC Evaluation Report according to SPoC Test Requirements E1 and E2.
• Key-injection facility(s) (KIF) validation AOC(s) by a PCI QPA for any key-injection facility(s) (KIF) involved in injecting keys for the SCRP SPoC Labs shall obtain the AOC(s) as evidence, verify they are current (i.e., issued within the past 12 months of the SPoC Evaluation Report submission), and submit the AOC(s) via the Portal with the SPoC Evaluation Report according to SPoC Test Requirements E1 and E2.
Removed
p. 20
• SPoC Security Requirement 2.2.2 requires that PIN CVM Applications must be developed only for operating systems (OS) that are supported by the OS vendor. All new Solutions must operate only on supported platforms. The initial COTS System Baseline (see the SPoC Standard) must not include any version of a COTS OS that is not supported by the OS vendor at the time of Evaluation. Evaluation Reports for SPoC Solutions using unsupported OSs will not be accepted by PCI SSC.
Modified
p. 33
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 example, addition/removal of a validated SCRP device, MSR approved under the PCI PTS program with SCR Approval Class, or non-PTS approved MSR (per the SPoC MSR Annex) used in a Solution, addition/removal or …
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 example, addition/removal of a validated SCRP device, MSR approved under the PCI PTS program with SCR Approval Class, or non-PTS approved MSR (per the SPoC MSR Annex) used in a Solution, addition/removal or …
Modified
p. 35
Table 4 summarizes the change documentation.
Table 3 summarizes the change documentation.
Removed
p. 37
Note: Validated SPoC Solutions must only use vendor-supported COTS OSs. Any major version(s) (e.g., v7.x) of a COTS OS that becomes unsupported by the OS vendor will be shown on the website listing as expired within the Solution Details portion of the SPoC listing.
Modified
p. 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, unsupported COTS operating systems and incomplete or inconsistent documentation.
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. Ineligible, incomplete or inconsistent submissions may delay processing of Listing requests or result in the rejection of the submission by PCI SSC.
Modified
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 …
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 2021-XXXXX.XXX, consisting of the …
Modified
p. 56 → 55
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).
Table 4 lists the terms used in this Program Guide and their meanings. Terms not listed in Table 4 may be found in the documents listed in Section 1.2, Related Publications (each document is available on the Website).
Modified
p. 56 → 55
• The detail provided in the Solution Evaluation Report meets PCI SSC’s reporting requirements. Note: PCI SSC may suspend, withdraw, revoke, cancel or place conditions upon (including without limitation, complying with remediation requirements) Acceptance and Listing of any Solution in accordance with applicable SPoC Program policies and procedures.
• The respective compliant Solution Evaluation Report is correct as to form (all applicable documents completed);
• The SPoC Lab determined that the Solution is eligible to be a validated Solution;
• The SPoC Lab reported the compliance of the respective SPoC Solution with SPoC Program requirements; and
• The detail provided in the Solution Evaluation Report meets PCI SSC’s reporting requirements. Note: PCI SSC may suspend, withdraw, revoke, cancel or place conditions upon (including without limitation, complying with remediation requirements) Acceptance and …
• The SPoC Lab determined that the Solution is eligible to be a validated Solution;
• The SPoC Lab reported the compliance of the respective SPoC Solution with SPoC Program requirements; and
• The detail provided in the Solution Evaluation Report meets PCI SSC’s reporting requirements. Note: PCI SSC may suspend, withdraw, revoke, cancel or place conditions upon (including without limitation, complying with remediation requirements) Acceptance and …
Removed
p. 57
Participating Payment Brand (or Payment Brand) A global payment card brand or scheme that is also a limited liability company member of PCI SSC (or affiliate thereof).
Modified
p. 59 → 58
SPoC Standard The SPoC Security Requirements and SPoC Test Requirements, including the SPoC MSR Annex as applicable.
SPoC Standard The SPoC Security Requirements and SPoC Test Requirements, including any Annexes to the SPoC Standard as applicable.
Modified
p. 59 → 58
SPoC user guidance document (or SPoC API user guidance or user guidance) A companion document
SPoC user guidance document (or SPoC API user guidance, or user guidance) A companion document