How to Complete SAQ A: Step-by-Step for UK Businesses (2026)

SAQ A is the questionnaire every online business hopes it qualifies for: around 30 questions, no vulnerability scans, and for most UK merchants an afternoon's work at most. But 'short' is not the same as 'self-explanatory'. The form is written in security language, the eligibility rules were tightened under PCI DSS v4.0.1, and the mistakes people make — picking the wrong SAQ, forgetting the attestation, never actually filing the thing — can leave you paying non-compliance fees despite having done the work. This guide walks through the whole process step by step. If you are new to PCI DSS entirely, our complete PCI DSS compliance guide covers the background first.

Who qualifies for SAQ A?

SAQ A is for merchants who have fully outsourced the handling of cardholder data to PCI DSS compliant third parties. In practice, that means two groups. The first is e-commerce businesses using a fully hosted checkout: when your customer pays, they are either redirected to a payment page hosted by your provider, or they type their card details into an iframe that your provider delivers — so the card number goes straight from the customer's browser to the provider, never touching your website or server. The second is mail order and telephone order businesses that have passed all card handling to a compliant third party, such as an outsourced call centre.

The word doing the heavy lifting is 'fully'. If your own website serves the payment form, or your page's code collects card details before passing them to the gateway, you are outside SAQ A territory and looking at the much longer SAQ A-EP. And if card data reaches your server or is stored electronically anywhere in your business, you are into SAQ D. Our comparison of SAQ A vs SAQ D explains where those boundaries sit, and our guide to PCI compliance for e-commerce covers how different checkout setups affect your scope.

What are the SAQ A eligibility criteria under v4.0.1?

Before you answer a single question, the form asks you to confirm you are eligible to use it at all. Under PCI DSS v4.0.1, the criteria boil down to the following:

• You accept only card-not-present payments — e-commerce, mail order or telephone order.
• All processing of cardholder data is entirely outsourced to third-party service providers that are themselves PCI DSS compliant.
• Your systems do not store, process or transmit any cardholder data electronically. Any card data you retain is on paper — printed reports, for example — and was not received electronically.
• For e-commerce: every element of the payment page that appears in your customer's browser comes from your payment provider or another compliant third party, via a full redirect or a provider-hosted iframe.
• You have confirmed that your website is not susceptible to attacks from scripts that could affect your e-commerce system.

That last criterion deserves a moment of context, because it is the newest. PCI DSS v4.0 introduced two requirements aimed squarely at online card-skimming attacks: requirement 6.4.3, which asks merchants to keep an inventory of the scripts running on their payment pages and confirm each one is authorised, and requirement 11.6.1, which asks for a mechanism that detects tampering with those pages. Both initially appeared in SAQ A. The January 2025 revision of the SAQ A form for v4.0.1 then removed them as explicit questions — but replaced them with the eligibility confirmation above.

In plain terms: you no longer work through detailed script-management questions inside SAQ A, but you must still be able to say, honestly, that your checkout is protected against script attacks. For most small merchants the practical route is a fully hosted payment page or provider iframe, plus a line of written confirmation from your provider describing how it protects the payment page. If you cannot get comfortable making that confirmation, treat it as a sign your setup needs a closer look before you sign anything.

What does the SAQ A form actually contain?

The document has three sections, and all three matter.

Section 1: assessment information

This is the administrative part: your business details, a description of how you take payments, which third-party providers you use, and the eligibility confirmations covered above. It is worth being precise here — this section tells your acquirer which rules you have assessed yourself against, and a sloppy description of your payment channels is the first thing that gets queried.

Section 2: the questionnaire

Around 30 questions drawn from a small subset of the twelve PCI DSS requirements. In plain English, they ask whether you: use strong passwords and multi-factor authentication on the accounts that manage your website, hosting and payment services; avoid storing card data; keep any paper records containing card data secure and destroy them when no longer needed; maintain a list of your third-party providers, with written agreements, and check their compliance once a year; and know what you would do if you suspected a breach. Each question is answered 'In Place', 'Not in Place' or 'Not Applicable' — and 'Not Applicable' answers need a short justification.

Section 3: the Attestation of Compliance

The Attestation of Compliance, or AoC, is the signed declaration at the end confirming the assessment is accurate and complete. It is also the part your acquirer actually wants to see. An SAQ without a completed, signed AoC is unfinished — submitting the questionnaire but skipping the attestation is one of the most common reasons merchants stay flagged as non-compliant after doing all the hard work.

What evidence should you gather before you start?

You can complete SAQ A far faster if you collect the paperwork first. Aim to have:

• A written list of every third party involved in taking payments — payment gateway, e-commerce platform, and any outsourced call handling — with a note of what each one does.
• Evidence of each provider's PCI DSS compliance: their Attestation of Compliance or an official compliance page. Most major providers publish these or supply them on request.
• A short description (or screenshots) of your checkout showing that customers are redirected to the provider, or that every card field sits in the provider's iframe.
• A list of who in your business has administrative access to the website and payment accounts, and confirmation that multi-factor authentication is switched on for those accounts.
• A note of your policy on paper card data — ideally, that card numbers are never written down at all.
• Last year's SAQ and AoC, if this is a renewal, so you can check what has changed.

What are the most common SAQ A mistakes?

• Completing the wrong SAQ. If your checkout is a direct-post or JavaScript integration rather than a redirect or provider iframe, SAQ A is not valid for you — and an invalid SAQ can be rejected later, taking your compliant status with it.
• Skipping the Attestation of Compliance. The questionnaire without the signed AoC does not count.
• Never filing it. Completing the form and leaving it in a drawer still shows as non-compliant on your acquirer's records — and the monthly fees continue.
• Ticking 'In Place' without checking. If a breach later shows an answer was wrong, a false attestation makes your position considerably worse.
• Missing the annual renewal. Compliance lapses twelve months after your attestation date, and most acquirers restart non-compliance fees automatically.

The first mistake is the expensive one in both directions. Merchants who qualify for SAQ A sometimes slog through SAQ D because nobody told them a simpler form existed; merchants who do not qualify sometimes file SAQ A in good faith and have it challenged after the fact. Five minutes checking your checkout integration before you start saves both.

Where do you file your completed SAQ A?

Your completed SAQ and AoC go to your acquirer — the bank or payment company that settles your card takings — usually through an online compliance portal they run or a programme partner they nominate. Log in, upload the documents or re-key the answers, and make sure your status actually changes to compliant before you close the tab. Keep your own copy of the SAQ and AoC, and put the renewal date in your diary: validation is annual, not one-off.

Filing promptly has a direct cash value. Most acquirers charge a monthly non-compliance fee — typically £5 to £25 — while your status sits unvalidated. At £14.95 a month, that is £179.40 a year for having filed nothing. Our guide to the PCI fee on your statement explains how to spot these charges. By contrast, Fraud Defence First's fully managed PCI compliance service completes the correct SAQ with you, produces the AoC, files everything with your acquirer and handles the renewal — for a flat £100 + VAT a year.

Key takeaways

• SAQ A is the shortest questionnaire — around 30 questions — for merchants whose card handling is fully outsourced.
• Under v4.0.1 you must confirm your site is not susceptible to script attacks; a hosted checkout or provider iframe, backed by your provider's confirmation, is the usual route.
• Gather provider AoCs, checkout evidence and access lists before you start — the form goes much faster.
• The questionnaire alone is not enough: sign the Attestation of Compliance and file both with your acquirer.
• Renew every twelve months, or non-compliance fees of £5 to £25 a month restart.