Document Comparison
SPoC_Technical_FAQs_v1.6.pdf
→
SPoC_Technical_FAQs_v1.7.pdf
85% similar
15 → 17
Pages
5079 → 5946
Words
23
Content Changes
Content Changes
23 content changes. 20 administrative changes (dates, page numbers) hidden.
Added
p. 2
May 2021 1.7 Added Q26 and 26 to clarify when SPoC Unsupported OS Annex apply and usage of “objective-based” approach. Added Q30 to clarify API or software library integration options can be supported by SPoC solution. Added Q40 to clarify the frequency the required frequency of PCI PIN Assessment. Updated Q28 to clarify the API or software libraries implementations that can supported by SPoC solution. Updated Q15, Q19 and Q39 to align with the publication of SPoC Unsupported OS Annex. Renumbered questions and answers.
Added
p. 8
Otherwise, SPoC solutions must operate only on supported platforms, and the COTS system baseline must not include any version of a COTS OS that is not supported by the OS vendor at the time of the full evaluation.
Added
p. 11
SPoC Unsupported OS Annex
Q 26 [May 2021] When does the SPoC Unsupported OS Annex apply? A The security objectives outlined in the SPoC Unsupported OS Annex are optional, and the security controls are required only for solutions that include unsupported OSes in their COTS system baseline. For example, a solution provider may decide to include an unsupported COTS OS in the COTS system baseline of its initial evaluation, or to retain a previously supported COTS OS that became unsupported during the annual checkpoint.
Q 26 [May 2021] When does the SPoC Unsupported OS Annex apply? A The security objectives outlined in the SPoC Unsupported OS Annex are optional, and the security controls are required only for solutions that include unsupported OSes in their COTS system baseline. For example, a solution provider may decide to include an unsupported COTS OS in the COTS system baseline of its initial evaluation, or to retain a previously supported COTS OS that became unsupported during the annual checkpoint.
Added
p. 12
Q 27 [May 2021] Can an “objective-based” approach be used for security requirements and test requirements in the SPoC Standard? A The objective-based approach is intended only for evaluating security controls and processes implemented by an SPoC solution provider, as outlined in the SPoC Unsupported OS Annex, to protect the integrity and confidentiality of a PIN entered on COTS devices running an unsupported operating system.
Q 28 [May 2021] Can APIs (i.e., software libraries allowing third parties to interface with the SPoC solution) be validated and listed as part of an SPoC solution? A Yes. In cases where the SPoC solution provider offers libraries or APIs to allow third parties to interface to the solution, evaluation and validation by a SPoC Lab is required as part of each SPoC solution in which such APIs are provided in order to validate that usage of the API can be done without violating or …
Q 28 [May 2021] Can APIs (i.e., software libraries allowing third parties to interface with the SPoC solution) be validated and listed as part of an SPoC solution? A Yes. In cases where the SPoC solution provider offers libraries or APIs to allow third parties to interface to the solution, evaluation and validation by a SPoC Lab is required as part of each SPoC solution in which such APIs are provided in order to validate that usage of the API can be done without violating or …
Added
p. 14
Q 31 Can an SPoC lab reference an approval from another PCI SSC standard, such as
Added
p. 16
• Back-end Processing Environment remains compliant with PCI PIN,
Modified
p. 7
Q 13 Can a SPoC solution provider compose a SPoC solution from third-party elements? A The SPoC Standard does not prohibit using a third-party service provider or elements developed by a third-party, as long as the SPoC solution in its entirety and as a whole solution is evaluated by the SPoC laboratory. Regardless of whether the SPoC solution, including a PIN CVM application, has been developed in-house or by a third-party, each SPoC solution provider is ultimately responsible for ensuring …
Q 13 Can an SPoC solution provider compose an SPoC solution from third-party elements? A The SPoC Standard does not prohibit using a third-party service provider or elements developed by a third-party, as long as the SPoC solution in its entirety and as a whole solution is evaluated by the SPoC laboratory. Regardless of whether the SPoC solution, including a PIN CVM application, has been developed in-house or by a third-party, each SPoC solution provider is ultimately responsible for ensuring …
Modified
p. 9
Q 19 If a version of the COTS OS initially listed in the solution system baseline reaches end-of-life such that it is no longer supported by the original OS vendor, does the SPoC Standard disallow transactions on affected COTS devices until the OS on those devices is updated to a supported OS? A Yes. Security Requirement 2.2.2 mandates that PIN CVM Applications are developed only for supported COTS platforms, and Security Requirement 3.1.6 mandates that COTS devices using unsupported OS …
Q 19 [May 2021] If a version of the COTS OS initially listed in the solution system baseline reaches end-of-life such that it is no longer supported by the original OS vendor, does the SPoC Standard disallow transactions on affected COTS devices until the OS on those devices is updated to a supported OS? A Yes. Security Requirement 2.2.2 mandates that PIN CVM Applications are developed only for supported COTS platforms, and Security Requirement 3.1.6 mandates that COTS devices using …
Modified
p. 9
However, if an OS becomes unsupported after the initial evaluation, it can continue to be used until an annual checkpoint. If, as part of the annual checkpoint, the SPoC solution provider is able to provide evidence that the use of such a platform will not increase the risk of PIN exposure or subversion of the payment process, and the evidence is accepted by the laboratory, the unsupported platform may continue to be used. Such evidence must be evaluated and accepted …
However, if an OS becomes unsupported by the OS vendor after the initial evaluation, it can continue to be used until an annual checkpoint. As part of annual checkpoint, the SPoC lab need to perform additional testing to confirm security objectives outlined in the SPoC Unsupported OS Annex are met, and that the use of such a platform will not increase PIN exposure or subversion of the payment process.
Modified
p. 9
If such evidence is not provided or is not accepted by the laboratory, 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 expire in accordance with the process outlined in the SPoC Program Guide.
If evaluation SPoC Unsupported OS Annex is not performed or the implemented security controls and processes are not accepted by the laboratory, 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 expire in accordance with the process outlined in the SPoC Program Guide.
Modified
p. 11
Q 24 Test Requirement TB2.5 calls for the disabling of on-device sensors during PIN entry. Does this requirement apply to all COTS platforms? A The SPoC Standard does not require on-device sensors to be disabled during PIN entry. This requirement applies only if the solution provider implemented programmatic methods, manual processes (for example, prompting the end-user to disable a sensor), or a combination of both to disable on-device sensors.
Q 24 Test Requirement TB2.5 calls for the disabling of on-device sensors during PIN entry. Does this requirement apply to all COTS platforms? A The SPoC Standard does not require on-device sensors to be disabled during PIN entry. This requirement applies only if the solution provider implemented programmatic methods, manual processes (for example, prompting the end-user to disable a sensor), or a combination of both, to disable on-device sensors.
Modified
p. 12
Q 27 What is expected from a SPoC Lab when evaluating a SPoC solution that offers APIs or software libraries to allow third-party developers to interface with the SPoC solution? A The evaluation and validation of the APIs (together with the SPoC user guidance document described and defined in the SPoC Program Guide) by a SPoC Lab are required as part of each SPoC solution in which such libraries or APIs are provided. It is expected the SPoC Lab validates …
Q 29 What is expected from an SPoC lab when evaluating an SPoC solution that offers APIs or software libraries to allow third-party developers to interface with the SPoC solution? A The evaluation and validation of the APIs (together with the SPoC user guidance document described and defined in the SPoC Program Guide) by an SPoC lab are required as part of each SPoC solution in which such libraries or APIs are provided. It is expected the SPoC lab validates …
Modified
p. 12
It is expected that the SPoC Lab evaluates the SPoC user guidance, provided by the SPoC solution provider, which describes how the API is used to interface the SPoC solution.
It is expected that the SPoC lab evaluates the SPoC user guidance, provided by the SPoC solution provider, which describes how the API is used to interface the SPoC solution.
Modified
p. 12 → 14
PCI Contactless Payments on COTS (CPoC™), to meet objectives in the SPoC Standard without performing the required testing? A No. With the exception of references to the PCI DSS AOC for back-end environments, each SPoC evaluation report must demonstrate that the SPoC solution under review was evaluated and meets the security and the test requirements of the SPoC Standard.
Modified
p. 12 → 14
Q 29 [July 2020] Can testing results be reused from one evaluation to another of the same vendor? A Yes. Testing from one SPoC evaluation can be reused in another SPoC evaluation from the same vendor. This situation occurs commonly when two SPoC solutions with similar characteristics are evaluated by the same laboratory in parallel or in close succession. The reused data must be current (less than 12 months old) and must have been completed under the same major version …
Q 32 Can testing results be reused from one evaluation to another of the same vendor? A Yes. Testing from one SPoC evaluation can be reused in another SPoC evaluation from the same solution provider. This situation occurs commonly when two SPoC solutions with similar characteristics are evaluated by the same laboratory in parallel or in close succession. The reused data must be current (less than 12 months old) and must have been completed under the same major version of …
Removed
p. 13
The final laboratory evaluation reports must be received by PCI no later than sixty-day after the SPoC Standard and the associated SPoC Program Guide publication date.
Modified
p. 13 → 14
Q 30 [July 2020] Can a SPoC lab rely on testing performed by a different SPoC lab without further testing or validation? A If any element of a SPoC solution was evaluated by an entity other than the SPoC lab performing the evaluation under review, the evaluating SPoC lab must have access to all associated reports and supporting evidence. If those reports are not available for any reason, the evaluating SPoC lab must determine the additional work required to properly …
Q 33 Can an SPoC lab rely on testing performed by a different SPoC lab without further testing or validation? A If any element of an SPoC solution was evaluated by an entity other than the SPoC lab performing the evaluation under review, the evaluating SPoC lab must have access to all associated reports and supporting evidence. If those reports are not available for any reason, the evaluating SPoC lab must determine the additional work required to properly evaluate and …
Modified
p. 13 → 15
Existing SPoC solutions are not affected and remain validated per the date on the listing on the PCI SSC website. However, SPoC solution provider may choose to engage a SPoC Lab to perform a delta or a full evaluation, as determined by the SPoC lab, to update a listed SPoC solution on the PCI SSC website.
Existing SPoC solutions are not affected and remain validated per the date on the listing on the PCI SSC website. However, SPoC solution provider may choose to engage an SPoC lab to perform a delta or a full evaluation, as determined by the SPoC lab, to update a listed SPoC solution on the PCI SSC website.
Modified
p. 13 → 15
Q 32 How does a minor update to the SPoC Standard affect the expiry date of listed SPoC solutions? A Minor updates of the SPoC Standard (e.g., from version 1.0 to version 1.1) do not change the expiry dates for listed SPoC solutions; they remain as three years from the initial acceptance/listing date shown on the PCI SSC website.
Q 35 How does a minor update to the SPoC Standard affect the expiry date of listed SPoC solutions? A Minor updates of the SPoC Standard (e.g., from version 1.0 to version 1.1) do not change the expiry dates for listed SPoC solutions; they remain as three years from the initial acceptance/listing date shown on the PCI SSC website.
Modified
p. 14 → 15
Q 34 Can an Administrative change be submitted to transition a listed SPoC solution from SPoC Standard? A No, Administrative changes cannot be used to transition between versions of the SPoC Standard - a full or delta change evaluation, as determined by the SPoC lab, must be performed.
Q 37 Can an Administrative change be submitted to transition a listed SPoC solution from SPoC Standard? A No, Administrative changes cannot be used to transition between versions of the SPoC Standard - a full or delta change evaluation, as determined by the SPoC lab, must be performed.
Modified
p. 14 → 15
Q 35 What happened to “Designated Change” in the SPoC Program Guide? A Designated changes have been incorporated into the delta change process in SPoC Program Guide version 1.2 to help simplify the change and listing process.
Q 38 What happened to “Designated Change” in the SPoC Program Guide? A Designated changes have been incorporated into the delta change process in SPoC Program Guide version 1.2 to help simplify the change and listing process.
Modified
p. 14 → 16
Q 36 [July 2020] What testing and reporting are expected to be performed by SPoC lab as part of an annual checkpoint? A The annual checkpoint confirms that the SPoC solution continues to meet the security and test requirements of the SPoC Standard. The amount of testing that is required will vary. At a minimum, however, the SPoC lab must confirm that:
Q 39 [May 2021] What testing and reporting are expected to be performed by SPoC lab as part of an annual checkpoint? A The annual checkpoint confirms that the SPoC solution continues to meet the security and test requirements of the SPoC Standard. The amount of testing that is required will vary. At a minimum, however, the SPoC lab must confirm that:
Modified
p. 14 → 16
The SPoC lab may need to perform additional testing, depending on the extent to which the SPoC solution has changed. For example, if an operating system (OS) vendor no longer supports an OS that was included in the SPoC solution system baseline, the SPoC lab must verify that the SPoC solution provider has updated its system baseline and is actively working with its merchants to migrate them to a supported version of the OS.
The SPoC lab may need to perform additional testing, depending on the extent to which the SPoC solution has changed. For example, if an OS vendor no longer supports an OS that was included in the SPoC solution system baseline, the SPoC lab must verify that the SPoC solution provider has updated its system baseline and is actively working with its merchants to migrate them to a supported version of the OS. If SPoC solution providers want to continue to …