FAQ #1331 Diff
Can SAQ eligibility criteria be used for determining applicability of PCI DSS requirements for onsite assessments?
Earlier Version
Later Version
Removed
Added
Service providers cannot use SAQ eligibility criteria to determine applicability of PCI DSS requirements for assessments documented in a Report on Compliance.Compliance (ROC). The only acceptable SAQ for service providers is SAQ D for Service Providers. All other SAQs are intended for merchant use only.
Merchants should work withenvironmentstheir QSA to fully understand the merchant’s environment. If they are able to reach agreement that fully meetapplying only the requirements included in an SAQ is an acceptable approach to secure that merchant’s environment, then that SAQ may be used as a relevant guide for applicability of PCI DSS requirements for that environment. If an environment meets some but not all the eligibility criteria definedfor a particular SAQ, then the SAQ should not be considered a relevant guide for applicability of requirements. This approach must be clearly documented by the QSA in a particular SAQ may use that SAQ as a reference to identify the applicable PCI DSS requirements for that environment. This approach must be clearly documented in ?Description"Description of Scope of Work and Approach Taken?Taken" section of the ROC.
For PCI DSS v3.2.1, this includes the following:
Identify the eligibility criteria for the applicable SAQ,
For each criteria, document how the assessor verified that the merchant environment meets the criteria.
For PCI DSS v4.0, this approach is documented as specified in ROC Section 3.1.3.1 of the (ROC).
The assessor will need to perform appropriate testing and validation to verify the non-applicability of any PCI DSS requirements. As an example: If an e-commerce merchant has a webserver using aURLserver-side redirect to(for example, HTTP response with a status code 301 or 302) to a PCI DSS compliant third-party payment processor, the assessor will need to verify that the merchant environment, includingcould consider requirement 6.4.3 and 11.6.1 as not applicable since the redirection method and the configuration of the webserver, meets all the eligibility criteria for SAQ A before they can consider using that SAQ for guidance. mechanism is not susceptible to script-based attacks.
Thiswould include verifying that the merchant accepts only card-not-present transactions, doesapproach must be clearly documented by the QSA in "Description of Scope of Work and Approach Taken" section 3.1 of the ROC. Any PCI DSS requirements verified by the assessor to be not electronically store, process, or transmit any account data on its systems or premises, that all processing of account data is entirely outsourced to PCI DSS validated third-party service providers, and that all the other eligibility criteria for SAQ A are met.
Any PCI DSS requirements verified by the assessor toapplicable should be not applicable should be reported as ?Not Applicable?"Not Applicable" in accordance with instructions in the Report on Compliance (ROC)ROC Template. Assessors should refer to the ROC Template and ROC Template FAQs for the version of the standard being used for relevant guidance.
In all cases, the merchant is still expected to include PCI DSS Requirement 12.5.2 to document and confirm their PCI DSS scope at least once every 12 months. The merchant’s assessor is expected to include an assessment of Requirement 12.5.2 and document results in the merchant’s ROC. See PCI DSS v4.x “Annual PCI DSS Scope Confirmation” for more details.
Merchants should always consult with the organizations that manage compliance programs (for example, payment brands and acquirers) to confirm their PCI DSS validation and reporting method. If a detailed assessment and ROC is the appropriate method, merchants meeting the eligibility criteria from anenvironment meets some but not all eligibility criteria for a particular SAQ, then the SAQ should notalso confirm that the approach outlined above is acceptable. Contact information for the payment brands can be considered a relevant guide for applicability of requirements.
Merchants and service providers should always consult with their compliance accepting entity?such as their acquirer (merchant bank),found in FAQ #1142 How do I contact the payment brand, or other entity?to confirm their PCI DSS validation and reporting method. If a detailed assessment and ROC is the appropriate method, merchants meeting the eligibility criteria from an SAQ should also confirm that the approach outlined above is acceptable. Contact information for the payment brands can be found in FAQ #1142 How do I contact the payment card brands?
Merchants should work with
For PCI DSS v3.2.1, this includes the following:
Identify the eligibility criteria for the applicable SAQ,
For each criteria, document how the assessor verified that the merchant environment meets the criteria.
For PCI DSS v4.0, this approach is documented as specified in ROC Section 3.1.
The assessor will need to perform appropriate testing and validation to verify the non-applicability of any PCI DSS requirements. As an example: If an e-commerce merchant has a webserver using a
This
Any PCI DSS requirements verified by the assessor to
In all cases, the merchant is still expected to include PCI DSS Requirement 12.5.2 to document and confirm their PCI DSS scope at least once every 12 months. The merchant’s assessor is expected to include an assessment of Requirement 12.5.2 and document results in the merchant’s ROC. See PCI DSS v4.x “Annual PCI DSS Scope Confirmation” for more details.
Merchants should always consult with the organizations that manage compliance programs (for example, payment brands and acquirers) to confirm their PCI DSS validation and reporting method. If a detailed assessment and ROC is the appropriate method, merchants meeting the eligibility criteria from an
Merchants and service providers should always consult with their compliance accepting entity?such as their acquirer (merchant bank),
Disclaimer: This FAQ has been processed for display on this website and may contain errors. Please check the original FAQ on the PCI SSC website for the authoritative version.