SAQ A Controls Explained — All 22 Requirements

Last updated: 29 May 2026

Most merchants who qualify for SAQ A think they've got six things to do. That hasn't been true since 31 March 2025, when PCI DSS v4.0.1 made the previously "best practice" requirements mandatory. The current saq a controls list runs to 22 items, and two of them — script integrity monitoring and tamper detection on payment pages — catch a lot of teams out because they assume an outsourced checkout means zero technical work. It doesn't.

We help retailers, insurers and contact centres descope their card environment down to SAQ A every week. The good news: 22 controls is still dramatically less work than the 250-odd in SAQ D-Merchant. The bad news: a few of the new ones need real engineering effort, not just a policy document. This post walks through every requirement in the current SAQ A, what it actually means in practice, and where most merchants quietly fail their self-assessment.

What the saq a controls cover (and what they don't)#

SAQ A is the shortest of the merchant self-assessment questionnaires. It exists for merchants who've fully outsourced their card data environment — every cardholder data function is handled by a PCI DSS validated third-party service provider. You're not storing card numbers. You're not processing them through your own systems. You're not transmitting them through any network you operate. If any of that's wrong for you, you need SAQ A-EP or higher instead, not SAQ A. For background on the SAQ itself and how it fits within the wider PCI framework, our pillar guide on SAQ A guide covers the basics.

The 22 controls in SAQ A focus on a narrow but important slice of risk: governance, the security of the redirect or iframe that hands the customer over to your payment processor, the integrity of the scripts running on your payment page, your provider management process, and the basic hygiene around the people in your business who can change those things. They don't cover network segmentation, internal vulnerability scanning, file integrity monitoring on internal servers, encryption key management, or any of the heavy infrastructure stuff that makes SAQ D such a slog. That all stays with your processor.

The 22 saq a controls map to a subset of the full 12 PCI DSS requirements. You'll see references to Requirement 6 (secure software), Requirement 8 (identity and access), Requirement 9 (physical security of any media), Requirement 11 (testing), Requirement 12 (policy and governance), plus the new Appendix A1 and A2 controls that catch e-commerce skimming attacks like Magecart. Each one has a yes/no question on the SAQ form and a corresponding piece of evidence you need to keep on file.

The 6 "classic" SAQ A controls everyone already knew about#

These six were in the old v3.2.1 SAQ A and are still in v4.0.1. Most merchants who've been doing PCI for a while have these in place already, even if the wording's changed slightly. We'll cover them quickly before getting to the new ones that catch people out.

Control 1 — Account data protection (Requirement 3). You can't store cardholder data. Full stop. This sounds obvious but it gets violated by accident more often than you'd think. CRMs auto-save card numbers from email tickets. Customer service notes get pasted into Slack. PDF invoices archive PAN. The control asks you to confirm that you don't store CHD anywhere, ever. Have a written policy, an annual review, and a way of finding accidental storage if it happens (regex searches over your databases and shared drives are the standard tooling).

Control 2 — Strong cryptography on transmission (Requirement 4). If your payment page is HTTPS-only with TLS 1.2 or 1.3, and your payment processor's hosted checkout is too, you're already meeting this. The SAQ form just wants you to confirm it. Use an SSL Labs scan as your evidence. Anything below TLS 1.2 fails the assessment.

Control 3 — Vendor-supplied defaults changed (Requirement 2). Any system used to administer your payment-related infrastructure — your CMS admin, your CDN console, your DNS provider — must not be running on default credentials. This control trips up small teams who installed something three years ago with the default admin/admin and never changed it.

Control 4 — Restrict physical access to cardholder data (Requirement 9). Even in SAQ A, if you ever receive paper forms or media that contain card data (a customer sends a fax, someone leaves a voicemail), you need a process to destroy them securely. Most SAQ A merchants answer "not applicable" here because they never see card data in physical form — but you have to evidence that. A written policy saying "we don't accept card data on paper or media" plus staff training records does the job.

Control 5 — Information security policy (Requirement 12.1). You need a written, dated, annually reviewed information security policy. It doesn't need to be 80 pages. It needs to exist, be signed off by someone senior, and cover the people, systems and processes that touch your payment flow. The most common failure is a policy that hasn't been reviewed in three years — review it annually, even if nothing's changed, and note the review date.

Control 6 — Service provider management (Requirement 12.8). You need a written list of every third-party service provider with whom you share cardholder data or whose services could affect the security of CHD. For SAQ A merchants this typically includes your payment processor, your hosted checkout provider, possibly your CDN, and any analytics scripts running on your payment page. For each one you need a written agreement covering PCI responsibilities, and an annual review of their PCI compliance status (the easiest evidence is their Attestation of Compliance, refreshed each year).

The new v4.0.1 saq a controls — where most merchants get caught#

The 16 additional controls in the current saq a controls list come from PCI DSS v4.0.1's hardening of e-commerce skimming defences and its expansion of governance requirements. These are the ones to focus on if you're updating from a v3.2.1 SAQ A.

Control 7 — Roles and responsibilities documented (Requirement 12.1.2). For every PCI-related task — policy review, provider management, the new script monitoring — you need a named role or person responsible. Not just "the IT team". A specific role title with a specific human attached. Update it when people leave.

Control 8 — Targeted risk analyses (Requirement 12.3.1). v4.0.1 introduces the concept of a "targeted risk analysis" — for any control where the standard gives you flexibility on frequency (like how often you do a particular review), you have to document a risk-based justification for what frequency you picked. Most SAQ A merchants have one or two of these to write up. Keep them short and tied to your actual environment.

Control 9 — Security awareness training (Requirement 12.6). Every person with access to PCI-related systems or processes needs annual security awareness training. Records have to be kept. This includes phishing awareness, password hygiene, and recognising social engineering attempts targeted at payment flows. Off-the-shelf training platforms (KnowBe4, Hoxhunt, etc.) make this easy, but you can run it in-house if you keep good records.

Control 10 — Incident response plan (Requirement 12.10). You need a documented incident response plan that specifies what happens if there's a suspected payment-related breach. It must include who gets called, what gets logged, how you'd notify your acquirer, how you'd preserve evidence. Test it at least annually — a tabletop exercise with the named responders is enough. Keep notes of the test.

Control 11 — Inventory of payment page scripts (Requirement 6.4.3 / A2.1.1). This is one of the new big ones. Every script that loads on a page that includes or redirects to your payment processor must be inventoried, with a documented business justification for why it's there. Analytics scripts, chat widgets, A/B testing tools, marketing pixels — all of them. You also need to confirm that each script's integrity is being monitored (more on that in Control 12).

Control 12 — Script integrity and tamper detection (Requirement 11.6.1). The control that catches the most merchants. On any page that contains or loads a payment page or iframe, you need an automated mechanism to detect unauthorised modifications to HTTP headers and the payment page contents. In practice this means deploying a Content Security Policy (CSP), Subresource Integrity (SRI) hashes for every script, plus a tamper detection service that alerts you when scripts change unexpectedly. This is mandatory now — it's not negotiable, and a simple "we monitor manually" doesn't pass.

Control 13 — Vulnerability identification and risk ranking (Requirement 6.3.1). Even for SAQ A merchants who don't run their own card environment, you're expected to monitor for security vulnerabilities in any third-party scripts and components on your payment pages. A subscription to a vulnerability feed (NVD, GitHub Advisories) plus a documented process for triaging and addressing relevant vulnerabilities does the job. Note "relevant" — you don't have to patch every CVE in the world, just the ones affecting your payment-page components.

Control 14 — Software bill of materials for payment pages (implied across Requirement 6). Strictly this is best practice rather than a hard requirement at SAQ A level, but every QSA we've worked with treats it as expected. Keep a list of every third-party library, script and component loaded on your payment page, with versions. This makes Controls 11, 12 and 13 actually achievable.

Control 15 — Multi-factor authentication on admin access (Requirement 8.4.2). Anyone with administrative access to systems that affect payment page security — your CMS, CDN, DNS, e-commerce platform admin — must authenticate with MFA. Phone-based SMS doesn't cut it any more under v4.0.1; you need TOTP, hardware tokens, or push-based MFA. This is one of the controls where small merchants tend to discover that two people are sharing a login. Fix that before you assess.

Control 16 — Unique user IDs (Requirement 8.2.1). Every person with access to PCI-relevant systems must have their own user account. Shared accounts are out. This sounds obvious but we still see WordPress sites where "admin" is the only login and three people use it.

Control 17 — Account lockout (Requirement 8.3.4). After no more than 10 failed login attempts, accounts on PCI-relevant systems must be locked. Lockout duration must be at least 30 minutes, or until an administrator re-enables the account. Most CMS platforms and SaaS tools have this configurable in admin settings.

Control 18 — Password length and complexity (Requirement 8.3.6). Minimum 12 characters (up from 7 in v3.2.1) containing both alphabetic and numeric characters, OR equivalent complexity if using a password manager-based strategy. Document which approach you've chosen.

Control 19 — Inactive session timeout (Requirement 8.2.8). Sessions on PCI-relevant admin systems must time out after 15 minutes of inactivity, requiring re-authentication. Set this in your CMS, your CDN console, your DNS provider. Many platforms default to much longer — change it.

Control 20 — Penetration testing (Requirement 11.4 — scoped subset). SAQ A merchants don't need full annual penetration testing of their environment, but you do need to confirm that the third-party service provider hosting your payment page does. Get a copy of their pen test summary as evidence each year.

Control 21 — Annual SAQ review and AOC submission (Requirement 12.11). The self-assessment has to be re-done annually, signed by an officer of the business, and submitted to your acquirer. Calendar it. The AOC (Attestation of Compliance) is the cover page on the SAQ — don't lose it.

Control 22 — Change management for payment pages (Requirement 6.5.1). Any change to a page that contains or loads the payment iframe goes through a documented change management process. That means a ticket, a code review or sign-off, and an audit trail. The reason this matters: most Magecart-style attacks happen via a small, unaudited change to a script tag. If your change management catches unauthorised modifications, you've closed the most common attack path.

How saq a controls 11 and 12 actually work in practice#

The two new e-commerce skimming controls — the script inventory and the tamper detection — are the ones we get the most questions about. Here's the practical setup most of our retail and insurance clients use.

For the script inventory (Control 11), you build a spreadsheet or use a payment-page security platform (Jscrambler, Source Defense, Akamai Page Integrity Manager, Cloudflare Page Shield, or similar). The spreadsheet lists every script tag, its source URL, what it does, the business owner, and the date last reviewed. For each one, you record whether it's loaded on a payment page (yes/no) and how you're monitoring its integrity. Update it when scripts change.

For tamper detection (Control 12), you need either a third-party service like the ones above, or a custom implementation using a strict Content Security Policy with the require-sri-for directive, plus a CSP violation reporting endpoint that alerts your security team. The hard truth is that rolling your own is more work than it sounds — getting CSP right on a payment page that loads marketing scripts, analytics and a payment iframe is non-trivial. Most SAQ A merchants we work with opt for one of the dedicated services. Budget around £200-£500/month for a small-merchant tier.

If you'd rather not deal with any of this on your own checkout, our hosted secure web payments approach handles the script integrity controls on the payment page itself, which means it's our environment carrying the burden of Controls 11, 12 and the related parts of 13. Your job becomes vendor management — you point at our AOC and move on.

The most common SAQ A self-assessment failures#

From the SAQs we've reviewed for clients before submission, the same handful of controls fail most often. We'll list them so you can check your own.

The script inventory (Control 11) is the biggest one. Merchants list their payment processor's iframe and call it done, missing the analytics, the chat widget, and the marketing pixels they added six months ago. Walk through your live payment page's HTML and list everything that loads — not just what you think loads.

Service provider AOCs (Control 6) come second. Merchants list their providers but don't have a current AOC on file for each one. Set a calendar reminder to collect new AOCs from each provider every 12 months. If a provider can't supply one, that's a red flag — escalate or find an alternative.

MFA gaps (Control 15) come third. Specifically, MFA is enabled on the production CMS but not on the staging environment, or it's enabled in the admin panel but not on the CDN console where someone could change DNS to redirect the payment page elsewhere. Audit every admin interface that could affect the payment flow.

Password policy on legacy SaaS (Control 18) trips up smaller teams. That ancient CRM or invoicing tool with the 8-character password limit needs to either be upgraded, replaced, or formally excluded from PCI scope with documented evidence that it has no access to or influence over payment-related infrastructure.

And finally, the SAQ itself going stale (Control 21). The SAQ is annual. Year one is hard, year two should be easier, but year three is where people forget. Calendar it on a recurring basis with a named owner.

How saq a controls differ from SAQ A-EP and SAQ D#

If you're trying to figure out which SAQ applies, the cleanest way to think about it is in terms of what touches your servers. SAQ A is for merchants where no payment data ever touches infrastructure you control — the payment page is fully hosted by a PCI-validated provider, and your site just redirects there or embeds an iframe. SAQ A-EP applies when the payment page is hosted by you but the data submission goes directly to the provider (think Stripe.js or similar tokenisation libraries running on your own page). SAQ D is for everyone else — including any merchant whose own systems are involved in transmitting, processing or storing card data.

We've written a full comparison at SAQ A vs SAQ A-EP if you're not sure which one you're eligible for. The control count tells the story: SAQ A has 22, SAQ A-EP has around 145, and SAQ D-Merchant has over 250. The jump from A to A-EP is mostly about taking responsibility for the scripts running on your payment page (since they're now running on a page you serve). The jump from A-EP to D adds back all the network, encryption and infrastructure controls.

One thing to be careful about: just because you qualify for SAQ A this year doesn't mean you will next year. If you change your e-commerce platform, add a custom checkout flow, or start handling card data in any way you didn't before, you may have pushed yourself into a different SAQ category. Re-check eligibility every year using our SAQ A eligibility checklist.

Documentation you need to keep alongside the SAQ#

The SAQ form itself is just the questionnaire. Behind it you need a set of evidence documents that prove each control is in place. Our SAQ A documentation checklist goes through everything in detail, but the headline list is: written information security policy, incident response plan, payment-page script inventory, list of service providers with current AOCs, MFA configuration screenshots, password policy documentation, training records, change management ticket log, annual risk analysis writeups, and the previous year's signed AOC.

QSAs and acquirers don't usually ask for all of this unless something goes wrong, but if you have a breach or get selected for a focused review, this is what they'll want. The merchants who get through reviews smoothly are the ones who keep this folder up to date as they go, not the ones who scramble to assemble it after a request lands.

Where the SAQ A controls fit in the wider PCI picture#

It's worth understanding why the saq a controls exist the way they do. PCI DSS started life in 2004 as a unified merchant security standard. Over time the council recognised that a tiny e-commerce shop using PayPal had a wildly different risk profile from a major retailer storing millions of card numbers. The SAQs were introduced to let lower-risk merchants self-assess against a relevant subset of controls rather than the full standard.

SAQ A was always the "lightest" SAQ because outsourcing card capture genuinely does eliminate most of the merchant-side risk. The v4.0.1 update added back some controls because the threat landscape changed — specifically, attackers stopped trying to break into merchant networks (hard, expensive) and started skimming card data off merchant payment pages by compromising third-party scripts (easy, scalable). The new controls are a direct response to Magecart-style attacks. They're not bureaucratic make-work; they exist because real merchants got real card data stolen from their hosted checkout pages by injected JavaScript.

The same logic explains why telephone payments using channel separation can hit even lighter compliance footprints than SAQ A in some cases. If the merchant never serves any page that touches a card capture interface — because all card capture happens over a separated audio path or through a payment-by-link channel — there's no payment page to skim from in the first place. We help contact centres get to that position regularly.

Walking through a real saq a controls assessment — what an evening with the form actually looks like#

Theory's useful but it doesn't replace knowing what filling in the form feels like. We've sat with a lot of clients while they work through it, and the pattern's predictable enough to map out. Allow yourself an evening with the document open, your password manager unlocked, and your provider AOCs ready in a folder. Here's how a typical run goes.

The first thirty minutes are confidence-building. You answer Control 1 ("we don't store cardholder data") and Control 2 ("yes our transmission is TLS 1.2 minimum") quickly. You feel like this is going to be straightforward. Then you hit the script inventory question and realise you've never actually counted the scripts on your checkout page. Open DevTools, sort the Network tab by domain, list every script source, and look at each one. The average e-commerce site we audit runs between 12 and 30 scripts on its checkout page — not the 3 the marketing team thinks are there.

Next you hit Control 12, the tamper-detection one. Either you've already deployed a Content Security Policy with violation reporting and you can answer yes, or you haven't and you can't. There's no middle ground. If you haven't, mark it as a gap and add it to your remediation list — don't tick yes because you "monitor manually". The QSAs we work with explicitly fail merchants who do that and won't accept an attestation of compliance.

The MFA section (Controls 15-17) usually triggers a round of "where else is admin?" conversations. The website CMS is easy. The CDN console, the DNS provider, the staging environment, the analytics platform admin, the email service that sends transaction receipts — all of them need MFA on accounts that could change anything affecting the payment flow. Most teams find at least one gap. Note them, fix them, then complete the answer.

The service-provider section (Control 6) usually goes well if you've kept the AOC folder up to date and badly if you haven't. The fix for "haven't" is to email every provider and ask for their current AOC. Most will reply within 48 hours; the ones that don't are flagging something worth investigating. Once you've collected them, set a calendar reminder 11 months out so you don't get caught again next year.

The last twenty minutes are the policy and training section. Pull up the dated information security policy. Check the review date. Sign off the page. Pull up the training records — KnowBe4, Hoxhunt, whatever your provider is — and confirm everyone covered by PCI has completed the required modules this year. Anyone who hasn't gets scheduled. Then you sign the AOC cover page as an officer of the business, and that's it. The whole assessment takes 2-3 hours if you're set up. If you're not, the gaps you uncovered are your next four to eight weeks of work.

Mapping the saq a controls back to the 12 PCI DSS requirements#

If you've ever read PCI DSS itself, you'll know it's organised around 12 high-level requirements. The 22 SAQ A controls aren't laid out the same way — they're grouped by SAQ section. Mapping them back to the source requirements helps if you're cross-referencing your own internal documentation, or if you've worked through a SAQ D in the past and want to understand what's been carved out.

Requirement 3 (Protect stored cardholder data): Control 1 only. Because you don't store CHD, the bulk of this requirement isn't applicable.

Requirement 4 (Protect cardholder data in transit): Control 2 only. You're confirming TLS coverage on any page that touches payment data.

Requirement 6 (Develop and maintain secure systems): Controls 11, 13, 14, 22. This is where the new e-commerce skimming controls live. Script inventory, vulnerability tracking, software bill of materials, change management on payment pages.

Requirement 8 (Identify and authenticate access): Controls 15, 16, 17, 18, 19. The full access-management quintet — MFA, unique user IDs, lockout, password strength, session timeout.

Requirement 9 (Restrict physical access): Control 4. Mostly "not applicable" for SAQ A merchants, but you still answer it.

Requirement 11 (Test security systems): Controls 12 and 20. Tamper detection on payment pages, plus confirmation that your provider tests their environment.

Requirement 12 (Maintain an information security policy): Controls 5, 7, 8, 9, 10, 21. The full governance suite — policy, roles, risk analyses, training, incident response, annual SAQ.

Requirement 2 (Vendor defaults): Control 3.

Service provider management: Control 6 lives under Requirement 12.8.

What's notably absent from the SAQ A controls: Requirement 1 (firewall and network segmentation), Requirement 5 (anti-malware), Requirement 7 (need-to-know access restrictions for CHD — because there's no CHD in your environment), and large chunks of Requirements 10 (logging) and 11 (testing). That's the carve-out you're earning by outsourcing card capture properly. Don't take it for granted — it's the reason the form is 22 controls long and not 250.

What changes between v4.0.1 and a future v4.1 — should you future-proof?#

PCI DSS v4.0.1 is the version in force as of 2026. There's no v4.1 announced yet, and the council typically gives merchants 18-24 months of overlap between versions before mandatory transition. That said, the direction of travel is clear: every recent revision has tightened controls around e-commerce skimming, script integrity, and authentication. None of those areas are likely to get easier in the next version.

The practical advice we give clients is to treat any "best practice" recommendation in v4.0.1 as if it's already mandatory. If the council is recommending something today, it's likely to become a hard requirement in the next major version. That includes things like more granular logging on admin access to payment-page infrastructure, stronger session-management controls, and tighter restrictions on what scripts can run on a payment page. Doing those things now means you won't have a scramble in 2027 or 2028 when the next version lands.

The merchants who suffer most through PCI version changes are the ones who treat each year as a one-off assessment rather than a continuous compliance posture. The ones who do well are the ones who build the controls into business-as-usual — script changes go through review, training is scheduled annually, policies get reviewed on a calendar, AOCs get refreshed on a calendar. None of it's exciting, but it makes the annual SAQ a confirmation rather than an investigation.

Why the 22 saq a controls still beat the alternative#

22 controls feels like a lot. It is more than the 6 most merchants assumed. But compare it to the 250+ controls in SAQ D-Merchant, the requirement for annual penetration testing of your environment, quarterly external vulnerability scans, file integrity monitoring across your entire network, formal segmentation testing, written cryptographic key management procedures, and the rest. SAQ A is still by an enormous margin the cheapest, fastest path to PCI compliance for a merchant who can use it.

If you're currently on SAQ D and you've been quoted £15,000+ a year in PCI assessment fees, plus another £10,000+ in tooling, plus engineering time to maintain it, the path down to SAQ A pays for itself in months. The trigger is removing card data from your environment. For e-commerce that usually means moving to a hosted checkout or proper tokenisation. For contact centres it means DTMF masking or full channel separation so agents never hear or type PANs. Our client Pinnacle Group cut PCI scope by 95% this way and dropped from SAQ D to SAQ A within 12 weeks of going live.

Next steps#

If you're not sure whether you currently qualify for SAQ A, start with the eligibility checklist. If you do qualify but you're worried about the new v4.0.1 controls (especially the script integrity ones), book a 15-minute call with our compliance team — we'll walk through your payment page and tell you exactly what you'd need to add. If you'd rather skip the script-monitoring overhead entirely by moving card capture off your website altogether, the interactive demo shows how channel separation works in 90 seconds. Either way, the 22 saq a controls are very achievable — the merchants who struggle are the ones who get caught by surprise when their assessor asks for the new ones.