OK, an apology to start with: This post is about SAQs (and ROCs) but I thought that a sparkling, witty headline might get better engagement.
Apologies if you’re here for landscaping supplies.
Now, on with the post!
Using SAQ A to reduce your PCI DSS reporting load
We’ve written about the PCI DSS (Payment Card Industry Data Security Standard) on many occasions, so you’ll know that is a standard (one of a set of standards, actually) that is designed to ensure that all companies that accept, process, store or transmit credit card information maintain a secure environment.
The PCI DSS applies to:
– Merchants – businesses that accept card payments from customers (online, in-store, mobile, or otherwise)
– Third-party service providers (TSPs) – organisations that handle or could impact the security of cardholder data on behalf of merchants.
The PCI covers two kinds of sensitive data:
– Cardholder data – primary account number (PAN), cardholder name, expiration date
– Sensitive authentication data – PINs, security codes, etc.
If you handle this data, or if your service provider does (on behalf of your organisation), you are bound by PCI DSS requirements. And in this post, we’ll help you to understand how to reduce your PCI DSS-compliance reporting load.
A merchant is an organisation that accepts payment from a cardholder when the cardholder purchases goods or services. This isn’t just limited to online businesses. It includes businesses with point-of-sale (POS) terminals as well. Whether transactions occur online, in a physical store, or via a mobile device, the organisation accepting payment is considered a merchant.
Each of the PCI DSS card-brands (Visa, Mastercard, etc.) categorises merchants into four groups depending on how many transactions the merchant processes per year, and the amount of compliance work that needs to be done by the merchant in order to be compliant with the DSS depends on how many transactions the merchant processes.
Level 1.
Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa region.
Compliance requirements:
– Annual Report on Compliance (ROC) by Qualified Security Assessor (QSA)
– Quarterly network scan by Approved Scan Vendor (ASV)
– Attestation of Compliance Form
Level 2.
Merchants processing 1 million to 6 million Visa transactions annually (all channels).
Compliance requirements:
– Annual Self-Assessment Questionnaire (SAQ)
– Quarterly network scan by ASV
– Attestation of Compliance Form
Level 3.
Merchants processing 20,000 to 1 million Visa e-commerce transactions annually.
Compliance requirements:
– Annual Self-Assessment Questionnaire (SAQ)
– Quarterly network scan by ASV
– Attestation of Compliance Form
Level 4.
Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually.
Compliance requirements:
– Annual Self-Assessment Questionnaire (SAQ)
– Quarterly network scan by ASV, if applicable
– Compliance validation requirements set by acquirer
Acquirers, merchant agreements and reporting
First up, let’s talk about acquirers. An acquirer is generally a bank that provides merchants with the ability to accept card payments. They also settle transactions, which means they transfer money to the merchant after a transaction is completed. While acquirers are often banks, it’s worth noting that other parties can also act as acquirers or at least function in a similar capacity.
In the world of PCI DSS, each merchant and it’s acquirer (or payment processor) are bound by a merchant agreement. The merchant agreement outlines the obligations of both parties, particularly regarding the protection of customer cardholder data. If you’re a merchant who has access to or stores card details in any format, it’s your responsibility to ensure those payment details remain secure. Many merchant agreements point to the PCI DSS guidelines for more detailed information on compliance requirements. However, they often provide some initial guidance on what level of compliance the merchant falls under and how they need to report their compliance
Reporting requirements
Generally speaking, all merchants have reporting requirements, irrespective of their level. However, the specific requirements differ. Most merchants, except for the highest level (Level 1), are typically required to complete a Self-Assessment Questionnaire (SAQ). Level 1 merchants, on the other hand, usually need to undergo an annual assessment by a Qualified Security Assessor (QSA).
For the bulk of merchants, the key to PCI DSS compliance is the Self-Assessment Questionnaire (SAQ). Different SAQs exist, each tailored to different types of payment processing environments. The specific SAQ a merchant needs to complete depends on how they process card payments.
All merchants except Level 1 merchants need to complete an SAQ. Level 1 merchants need to undergo a QSA annual assessment and produce a report on compliance (ROC).
Side note: If you’re a Level 1 merchant, this post is not for you because you cannot report using a SAQ. (We can of course provide your QSA-led assessment, AOC and ROC, but that’s not part of this post).
For all other merchants: You want to reduce your SAQ reporting requirements as much as possible (because that will save you time and money) and this post is most definitely for you!
An important question arises: Must merchants voluntarily submit their SAQs, or do they only need to have them available if requested? The answer depends on the acquirer. Some acquirers have portals through which merchants must submit their SAQs. This makes the submission process easier for merchants, as it often involves a wizard format to fill in the information. However, some acquirers may not actively ask for the SAQ.
Regardless, merchants are still required to complete an SAQ and an Attestation of Compliance annually, even if no one asks for it. The merchant should have it ready if and when requested.
Selecting the right SAQ to reduce your reporting load
Selecting the correct SAQ is crucial unless you want to waste money and time on unnecessary reporting. Merchants need to (and yes, dotSec can help here) determine which SAQ applies to them based on their cardholder data flow and review their data flow against the eligibility criteria in each SAQ. The SAQs themselves have the eligibility criteria listed before the questionnaire. So in general, we can determine which SAQ applies to a merchant based on their cardholder data flow and by reviewing the data flow against the eligibility criteria in the SAQs.
Aside: When discussing SAQs, it’s important to distinguish between questions and controls. A control is a security measure designed to protect cardholder data. A question in the SAQ is used to verify whether a particular control is in place. You might think that the number of questions would equal the number of controls, but that’s not necessarily the case. A single control may relate to multiple questions.
For example, a control related to access controls and identity management may require answering multiple questions to ensure full compliance. Conversely, to comply with a single control may mean answering a number of questions.
The golden prize: Reporting under SAQ A!
SAQ A (Self-Assessment Questionnaire A) is the leanest of the PCI DSS reporting paths, meaning that it can be used (in general) with very little effort or time.
Merchants prefer SAQ A because there are only 26 controls (and some of those might be non-applicable) and it’s often possible for the merchant to offload many of it’s PCI DSS responsibilities to third-party providers such as payment gateways or security service providers, as long as those third parties are themselves PCI DSS compliant.
To be eligible for SAQ A, all cardholder data functions must be fully outsourced to PCI DSS-compliant TSPs, and merchants must:
- Not store, process, or transmit cardholder data on their systems
- Use only redirects, iframes, or hosted payment pages
- Confirm their ecommerce site is not susceptible to script-based attacks.
So what are the steps to reporting under SAQ A? Not a real lot as it happens:
1) Check your transaction volume
If you process fewer than 6 million transactions annually, you’re probably not Level 1 and that’s good news! You might be eligible to self-assess (i.e. Report using a SAQ, preferably SAQ A)
2) Confirm your eligibility for SAQ A
Check the following:
– Have you confirmed that any account data the merchant might retain is on paper and these documents are not received electronically.
– Do you fully outsource payment functions to PCI DSS-compliant third parties?
– Can you confirm that your system does not store, process, or transmit cardholder data?
– Have you taken steps to ensure that your ecommerce site is not susceptible to script-based attacks? There are two ways to do this: Either get written confirmation from your third-party provider that scripts are secure, or implement SAQ A controls 6.4.3 (secure management of scripts on payment pages) and 11.6.1 (tamper detection for payment-page scripts).
You’ll need to answer “Yes” to all of these if you want to report under SAQ A.
3) Get evidence from your providers
4) Complete the SAQ A
Conclusions
If you’re aiming to report under SAQ A, don’t wait for your acquirer to come knocking. Your obligation to maintain PCI DSS compliance is defined in your merchant agreement; not in a reminder email. The sooner you assess your eligibility, confirm your third-party dependencies, and secure your ecommerce environment, the smoother and less costly your compliance journey will be.
Need help figuring out your eligibility or navigating SAQ A?
Contact us today for expert guidance and support in navigating SAQ A and beyond. We can help you map your data flows, check your third-party evidence, and make sure your SAQ stands up to scrutiny so you’re prepared when the bank comes knocking.