Document Comparison
SPoC_Technical_FAQs_v1.10_.pdf
→
SPoC_Technical_FAQs_v1.11.pdf
95% similar
20 → 20
Pages
7718 → 7801
Words
39
Content Changes
Content Changes
39 content changes. 18 administrative changes (dates, page numbers) hidden.
Added
p. 1
Payment Card Industry (PCI) Software-based PIN Entry on COTS (SPoC)™ Technical FAQs for use with SPoC 1.1 Version 1.11
Added
p. 8
Q 15 [September 2025] Are there situations where a SPoC Solution does not require full evaluation if changing laboratories for an annual checkpoint or implementation change evaluation? A A full evaluation is not required when changing laboratories during a 3-year listing period if the new laboratory has access to the full SPoC report. The new SPoC Laboratory may still determine aspects of the implementation require re-evaluation, even when a previous full evaluation report is provided.
Modified
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. …
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 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 …
Modified
p. 3
December 2021 1.8 Added Q15 to clarify the term “assessed RNG”. Added Q16 to clarify when the usages of TDES is allowed. Updated Q19 to clarify the scope of WBC keys. Added Q28 to clarify the expected logical and physical testing of COTS devices. Added Q29 to clarify a use-case where back-end attestation and monitoring systems are hosted in multiple environments or hosted by multiple entities. Added Q30 to clarify the onsite assessment requirements. Added Q46 to describe the process …
December 2021 1.8 Added Q15 to clarify the term “assessed RNG”. Added Q16 to clarify when the usage of TDES is allowed. Updated Q19 to clarify the scope of WBC keys. Added Q28 to clarify the expected logical and physical testing of COTS devices. Added Q29 to clarify a use-case where back-end attestation and monitoring systems are hosted in multiple environments or hosted by multiple entities. Added Q30 to clarify the onsite assessment requirements. Added Q46 to describe the process …
Modified
p. 5
Q 3 In the SPoC Test Requirements (TRs), where the attack-costing thresholds are required, there is no minimum number of thresholds. When will the attack-costing threshold values be added, and how should labs evaluate the relative requirements in the interim? A The PCI SSC will work directly with the labs that are qualified to perform solution assessments. Each assessment will be used to contribute relative attack-costing information using actual solution validation data that will be factored into the development of …
Q 3 In the SPoC Test Requirements (TRs), where the attack-costing thresholds are required, there is no minimum number of thresholds. When will the attack-costing threshold values be added, and how should labs evaluate the relative requirements in the interim? A The PCI SSC will work directly with the labs that are qualified to perform solution assessments. Each assessment will be used to contribute relative attack-costing information using actual solution validation data that will be factored into the development of …
Modified
p. 6
Q 7 What is the intent of use of an SPoC solution in an attended versus an unattended environment? A The SPoC Standard is intended for merchant COTS devices in attended environments.
Q 7 What is the intent of use of an SPoC solution in an attended versus an unattended environment? A The SPoC Standard is intended for merchant COTS devices in attended environments. Attended environments are when the merchant makes the COTS device available to the customer during a payment transaction (for example, when the merchant hands the COTS device to the customer). The customer enters a PIN and returns the COTS device to the merchant.
Modified
p. 8
Q 15 [December 2021] What is an assessed or validated RNG, and what is expected from a SPoC lab when evaluating a SPoC solution? A There are two types of RNGs: Deterministic Random Number Generator (DRNG) and Non-deterministic Random Number Generator (NRNG). Typically, DRNG uses an initial seed value from an NRNG to generate deterministic random values.
Q 16 [December 2021] What is an assessed or validated RNG, and what is expected from a SPoC lab when evaluating a SPoC solution? A There are two types of RNGs: Deterministic Random Number Generator (DRNG) and Non-deterministic Random Number Generator (NRNG). Typically, DRNG uses an initial seed value from an NRNG to generate deterministic random values.
Modified
p. 9
Q 16 [December 2021] Can TDES be used in an SPoC solution? A All security services provided by the solution must use only those algorithms and minimum key lengths as outlined in Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms. The only exception is customer PINs transmitted from the SCRP to the PCI PIN-compliant back-end processing environment which may be encrypted using TDES.
Q 17 [December 2021] Can TDES be used in an SPoC solution? A All security services provided by the solution must use only those algorithms and minimum key lengths as outlined in Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms. The only exception is customer PINs transmitted from the SCRP to the PCI PIN-compliant back-end processing environment which may be encrypted using TDES.
Modified
p. 9
Q 17 Is it possible to include an operating system (OS) version in the COTS system baseline of the full solution evaluation that is not supported by the OS vendor at the time of evaluation? A Yes. Although Security Requirement 2.2.2 requires that PIN CVM applications must be developed only for operating systems that are still supported by the OS vendor, PCI Security Standards Council has published an optional SPoC Unsupported OS Annex which outlines additional security controls to allow …
Q 18 Is it possible to include an operating system (OS) version in the COTS system baseline of the full solution evaluation that is not supported by the OS vendor at the time of evaluation? A Yes. Although Security Requirement 2.2.2 requires that PIN CVM applications must be developed only for operating systems that are still supported by the OS vendor, PCI Security Standards Council has published an optional SPoC Unsupported OS Annex which outlines additional security controls to allow …
Modified
p. 9 → 10
Q 18 Does Security Requirement 2.2.3 include OS level or other system applications? A No. This requirement is not intended for OS level or other system applications.
Q 19 Does Security Requirement 2.2.3 include OS level or other system applications? A No. This requirement is not intended for OS level or other system applications.
Modified
p. 10
Q 19 [December 2021] Security Requirement 2.2.5 states that where white-box cryptography is used, white-box keys must be unique for each PIN CVM application instance, and that the reliance upon and use of common white-box keys must be minimized after the secure-provisioning process. Does this requirement apply to all white-box keys as it relates to unique keys per PIN CVM application, or just those used for protecting keys associated with a PIN encryption? A The intent of the requirement is …
Q 20 [December 2021] Security Requirement 2.2.5 states that where white-box cryptography is used, white-box keys must be unique for each PIN CVM application instance, and that the reliance upon and use of common white-box keys must be minimized after the secure-provisioning process. Does this requirement apply to all white-box keys as it relates to unique keys per PIN CVM application, or just those used for protecting keys associated with a PIN encryption? A The intent of the requirement is …
Modified
p. 10
Q 20 Security Requirement 2.4.2 states that the PIN CVM application must detect sensor activation and polling of sensor data. Does this requirement apply to all COTS platforms? A The intent of the requirement is to protect the PIN entry process from manipulation or subversion. Because several attack vectors use COTS platform sensors and hardware for side-channel attacks, detecting when these sensors are activated or used (i.e., polling sensor data) by untrusted applications can reduce the risk of PIN compromise.
Q 21 Security Requirement 2.4.2 states that the PIN CVM application must detect sensor activation and polling of sensor data. Does this requirement apply to all COTS platforms? A The intent of the requirement is to protect the PIN entry process from manipulation or subversion. Because several attack vectors use COTS platform sensors and hardware for side-channel attacks, detecting when these sensors are activated or used (i.e., polling sensor data) by untrusted applications can reduce the risk of PIN compromise.
Modified
p. 10
Q 21 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 22 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 …
Modified
p. 11
Q 22 If an OS vendor issues an update to a COTS OS that was initially listed in the solution system baseline, does the SPoC Standard disallow transactions on COTS devices using the updated OS until the updated SPoC solution is evaluated? A When an OS vendor releases a minor update to the COTS OS included in the SPoC solution system baseline, the solution provider may support the additional COTS OS version as long as it does not increase the …
Q 23 If an OS vendor issues an update to a COTS OS that was initially listed in the solution system baseline, does the SPoC Standard disallow transactions on COTS devices using the updated OS until the updated SPoC solution is evaluated? A When an OS vendor releases a minor update to the COTS OS included in the SPoC solution system baseline, the solution provider may support the additional COTS OS version as long as it does not increase the …
Modified
p. 11
Q 23 Security Requirement 3.2.13 states that for manual updates to the attestation system, any deployment changes to the production environment require dual control. Is dual control necessary for attestation system components associated with the PIN CVM application recognizing that such applications are signed by the OS app store and not under the control of the solution provider? A While it is acknowledged that the signing of a PIN CVM application made available from the OS app stores is not …
Q 24 Security Requirement 3.2.13 states that for manual updates to the attestation system, any deployment changes to the production environment require dual control. Is dual control necessary for attestation system components associated with the PIN CVM application recognizing that such applications are signed by the OS app store and not under the control of the solution provider? A While it is acknowledged that the signing of a PIN CVM application made available from the OS app stores is not …
Modified
p. 12
Q 25 SPoC Security Requirements 3.6.1 and 5.1.2 state that if the back-end monitoring system resides in the CDE, PCI DSS, Appendix A3, “Designated Entities Supplemental Validation (DESV)” will apply. Does an SPoC solution provider have to be fully compliant with DESV when submitting an SPoC solution for initial validation? A If the solution provider cannot meet DESV requirements at the point of an initial SPoC solution validation, the solution provider must provide an action plan to the SPoC lab, …
Q 26 SPoC Security Requirements 3.6.1 and 5.1.2 state that if the back-end monitoring system resides in the CDE, PCI DSS, Appendix A3, “Designated Entities Supplemental Validation (DESV)” will apply. Does an SPoC solution provider have to be fully compliant with DESV when submitting an SPoC solution for initial validation? A If the solution provider cannot meet DESV requirements at the point of an initial SPoC solution validation, the solution provider must provide an action plan to the SPoC lab, …
Modified
p. 12
Q 26 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 27 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. 13
Q 28 [July 2024] Can a Mobile Device Management (MDM) solution be used as an ‘OS- store’ for the distribution of a PIN CVM application? Is additional testing required in such a case? A Yes. An MDM system may be used for the distribution of a PIN CVM application, instead of the official OS store, if the requirements of TR B6 have been validated as part of the Solution listing.
Q 29 [July 2024] Can a Mobile Device Management (MDM) solution be used as an ‘OS- store’ for the distribution of a PIN CVM application? Is additional testing required in such a case? A Yes. An MDM system may be used for the distribution of a PIN CVM application, instead of the official OS store, if the requirements of TR B6 have been validated as part of the Solution listing.
Modified
p. 13
Q 29 [December 2021] What is expected from SPoC labs regarding physical and logical testing of the COTS devices? A While there is no expectation to perform physical or logical testing of a COTS device itself, SPoC labs must confirm whether COTS platforms included in the COTS system baseline have known characteristics, such as physical test, debug, or in-circuit emulation features. For example, some Android mobile devices have an NFC logging service, which is intended to be used for debugging …
Q 30 [December 2021] What is expected from SPoC labs regarding physical and logical testing of the COTS devices? A While there is no expectation to perform physical or logical testing of a COTS device itself, SPoC labs must confirm whether COTS platforms included in the COTS system baseline have known characteristics, such as physical test, debug, or in-circuit emulation features. For example, some Android mobile devices have an NFC logging service, which is intended to be used for debugging …
Modified
p. 13
Q 30 [December 2021] Can back-end attestation and monitoring systems be hosted in multiple environments by more than one entity? A Yes. For each environment that is hosting attestation and monitoring systems, the SPoC solution provider is expected to do either: 1) Provide an Attestation of Compliance (AOC) that has been completed and signed within the previous 12 months demonstrating that the environment complies with the PCI DSS, including the additional controls outlined in PCI DSS Appendix A3 DESV, or; …
Q 31 [December 2021] Can back-end attestation and monitoring systems be hosted in multiple environments by more than one entity? A Yes. For each environment that is hosting attestation and monitoring systems, the SPoC solution provider is expected to do either: 1) Provide an Attestation of Compliance (AOC) that has been completed and signed within the previous 12 months demonstrating that the environment complies with the PCI DSS, including the additional controls outlined in PCI DSS Appendix A3 DESV, or; …
Modified
p. 14
Q 31 [December 2021] Does assessment of back-end systems require a physical onsite presence of the lab personnel? A SPoC solution back-end environments include back-end monitoring and attestation environment, and back-end payment processing environment. The back-end payment processing environment must be compliant with PCI Data Security Standard and PCI PIN Security Requirements, as applicable, and whether remote assessment methods are acceptable is defined by the compliance-accepting entities.
Q 32 [December 2021] Does assessment of back-end systems require a physical onsite presence of the lab personnel? A SPoC solution back-end environments include back-end monitoring and attestation environment, and back-end payment processing environment. The back-end payment processing environment must be compliant with PCI Data Security Standard and PCI PIN Security Requirements, as applicable, and whether remote assessment methods are acceptable is defined by the compliance-accepting entities.
Modified
p. 14
Q 32 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 33 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.
Modified
p. 14
Q 33 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 34 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.
Modified
p. 15
Q 34 [June 2022] Does compliance with the Unsupported OS Annex require that every CVE for all platforms within the SPoC Solution baseline are individually reviewed, categorized, and mitigated by the SPoC Solution provider? A No. The SPoC Unsupported OS Annex requires that there is a robust and mature vulnerability management and mitigation program in effect. The intent of this program is to ensure that vulnerabilities affecting older platforms which may remain unpatched by the platform vendor are mitigated by …
Q 35 [June 2022] Does compliance with the Unsupported OS Annex require that every CVE for all platforms within the SPoC Solution baseline are individually reviewed, categorized, and mitigated by the SPoC Solution provider? A No. The SPoC Unsupported OS Annex requires that there is a robust and mature vulnerability management and mitigation program in effect. The intent of this program is to ensure that vulnerabilities affecting older platforms which may remain unpatched by the platform vendor are mitigated by …
Modified
p. 15
Q 35 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 …
Q 36 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 …
Modified
p. 16
Q 36 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 …
Q 37 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. 16
Q 37 What API or software library implementation options can be supported by the SPoC solution? A Whether an implementation of an API or a software library can be supported by the SPoC Program depends largely on whether an SPoC lab can validate the exposed API or a library to SPoC Security Requirements and SPoC Test Requirements.
Q 38 What API or software library implementation options can be supported by the SPoC solution? A Whether an implementation of an API or a software library can be supported by the SPoC Program depends largely on whether an SPoC lab can validate the exposed API or a library to SPoC Security Requirements and SPoC Test Requirements.
Removed
p. 17
Q 38 Can an SPoC lab reference an approval from another PCI SSC standard, such as
Modified
p. 17
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.
Q 39 Can an SPoC lab reference an approval from another PCI SSC standard, such as 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. 17
Q 39 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 …
Q 40 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 …
Modified
p. 18
Q 41 When does SPoC Standard v1.1 become effective? A SPoC Standard v1.1 (and SPoC Program Guide v1.2) is effective immediately upon publication and becomes mandatory for all new SPoC solution evaluations. In process evaluations can be completed using SPoC Standard v1.0. PCI SSC must be notified in writing by each SPoC lab of the specific SPoC solution they have under evaluation. The final laboratory evaluation reports must be received by PCI no later than sixty calendar days after the …
Q 42 When does SPoC Standard v1.1 become effective? A SPoC Standard v1.1 (and SPoC Program Guide v1.2) is effective immediately upon publication and becomes mandatory for all new SPoC solution evaluations. In process evaluations can be completed using SPoC Standard v1.0. PCI SSC must be notified in writing by each SPoC lab of the specific SPoC solution they have under evaluation. The final laboratory evaluation reports must be received by PCI no later than sixty calendar days after the …
Modified
p. 18
Q 42 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 43 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. 18
Q 43 Can a Delta change be submitted to update a listed SPoC solution between minor versions of the SPoC Standard? A Yes, the change is submitted to an SPoC lab and it is up to the SPoC lab to determine whether the extent of the change(s) can be validated via delta evaluation. If the changes are extensive or highly impactful to the SPoC security requirements, the SPoC lab may determine that a full evaluation is required. Note that all …
Q 44 Can a Delta change be submitted to update a listed SPoC solution between minor versions of the SPoC Standard? A Yes, the change is submitted to an SPoC lab and it is up to the SPoC lab to determine whether the extent of the change(s) can be validated via delta evaluation. If the changes are extensive or highly impactful to the SPoC security requirements, the SPoC lab may determine that a full evaluation is required. Note that all …
Modified
p. 19
Q 44 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 45 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. 19
Q 45 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 46 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. 19
Q 46 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 47 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. 20
Q 47 How often must an SPoC Solution’s Back-end Processing Environment undergo a A The SPoC Solution’s Back-end Processing Environment must be assessed and validated by a PCI-qualified PIN Assessor (QPA) annually (i.e., at least every 12 months). Evidence of the PIN Assessment is verified by the SPoC lab during the annual checkup.
Q 48 How often must an SPoC Solution’s Back-end Processing Environment undergo a PCI PIN Assessment? A The SPoC Solution’s Back-end Processing Environment must be assessed and validated by a PCI-qualified PIN Assessor (QPA) annually (i.e., at least every 12 months). Evidence of the PIN Assessment is verified by the SPoC lab during the annual checkup.
Modified
p. 20
Q 48 [December 2021] Can a SPoC Solution Listing be delayed at a vendor’s request? A Yes, solution providers may choose to delay listing a newly approved SPoC solution for up to a maximum of six calendar months. Written notification to PCI SSC must be submitted by the SPoC solution provider, through the SPoC laboratory performing the evaluation, along with the completed SPoC Evaluation Report. In addition, the SPoC lab must make a notation in the applicable field of the …
Q 49 [December 2021] Can a SPoC Solution Listing be delayed at a vendor’s request? A Yes, solution providers may choose to delay listing a newly approved SPoC solution for up to a maximum of six calendar months. Written notification to PCI SSC must be submitted by the SPoC solution provider, through the SPoC laboratory performing the evaluation, along with the completed SPoC Evaluation Report. In addition, the SPoC lab must make a notation in the applicable field of the …
Modified
p. 20
Q 49 [June 2022] Can a SPoC solution be submitted using an SCRP that is part of a delayed listing, and not yet live on the PCI website? Can the listing of this SPoC solution also be delayed? A Yes, a SPoC evaluation report can include a delayed SCRP listing that is not yet live on the PCI website, and the listing of that SPoC Solution may also be delayed by up to 6 months from the date of Acceptance …
Q 50 [June 2022] Can a SPoC solution be submitted using an SCRP that is part of a delayed listing, and not yet live on the PCI website? Can the listing of this SPoC solution also be delayed? A Yes, a SPoC evaluation report can include a delayed SCRP listing that is not yet live on the PCI website, and the listing of that SPoC Solution may also be delayed by up to 6 months from the date of Acceptance …