.svg){kind=icon}
.svg)
In this blog installment, I want to provide you with an SAQ A policy set that would cover those merchants that have outsourced all of their processing to a PCI-compliant third party. (Note that there is a significant difference between SAQ A and SAQ A-EP. We will look to discuss the difference in the next blog installment.)
Eligibility Requirements for SAQ A
To validate against Self-Assessment Questionnaire (SAQ) A, your organization must be able to affirm the following:
- You are validating as a merchant. If you are a Service Provider, you will need to validate with an SAQ D or with a Report on Compliance (ROC) Remember, the SAQ A will only cover the merchant aspect of your organization, if you are both a merchant and a service provider.
- Your Acquiring entity will accept you validating using the SAQ A validation instrument. Remember, it’s your acquiring bank that determines your merchant levels and validation instruments. If you have any questions, please reach out to your contact; they will be happy to assist you.
- Your company ONLY accepts card-not-present transactions. Card-not-present translates to those transactions that are e-commerce or mail-order/telephone order.
- ALL of your cardholder data processing is handled and outsourced to a PCI compliant service provider. As part of your due diligence, you can ask them for a current Attestation of Compliance (AOC) for the services that they are providing you. When you review their AOC, make sure that the scope of the document clearly defines those services you are consuming. (Also, remember that you will need to re-confirm their compliance on an annual basis.)
- Your company does not ELECTRONICALLY store, process, or transmit cardholder on your systems or premise. All of this must be outsourced to a PCI complaint services provider as noted in item 4. You may have printed or handwritten material onsite; however, you may not have electronic information or have received that information in an electronic format.
If your organization cannot affirm each one of the above items, then you will need to validate your compliance with something other than SAQ A.
Understanding SAQ A
The core belief behind the use of SAQ A is that you do not have any electronic data in storage, nor do you interact with electronic data in any way. Therefore, all the requirements that we find in the PCI DSS that look to protect electronic cardholder data have been removed from being a compliance obligation. Even if they had not provided a documented reprieve from these controls, validating against the full PCI DSS would have resulted in numerous non-applicable controls. The remaining controls would likely be those that we find in SAQ A.
The technology-based controls that we find in SAQ A are those intended to ensure that changes cannot be made to the systems to, as an example, redirect cardholder data flows (i.e. a URL redirect hack) or generally impact cardholder data.
The SAQ A policy, then, amounts to making sure that systems cannot be accessed by unauthorized individuals (authentication controls, patching systems). The residual controls are intended to protect the physical cardholder data and manage your vendors.
Getting Started with Your SAQ A policy.
This post is part of a series of blogs, each of which includes a free PCI policy template that you can use to meet your compliance efforts. However, please note that you will still have to develop your own procedures and standards to meet the obligations documented in your policy.
.webp)
