SAQ D-Merchant Explained — All 329 Controls

Last updated: 29 May 2026

If you've landed here, you probably already know the bad news: your acquirer or QSA has told you that SAQ D-Merchant is the form you have to complete. We'll be honest — it's the worst of the SAQs to be on. It's the longest, the most expensive to maintain, and it's where most of the contact-centre breaches we read about every quarter end up. The good news is that being on SAQ D isn't a life sentence. We move clients off it routinely, and the engineering to do it is genuinely modest. This guide walks through what SAQ D-Merchant actually covers, why so many UK businesses end up there by accident, and the cleanest route out.

What is SAQ D-Merchant?#

SAQ D-Merchant is the catch-all self-assessment questionnaire under PCI DSS v4.0.1. It exists for merchants who store, process or transmit cardholder data in a way that doesn't fit any of the simpler SAQ types (A, A-EP, B, B-IP, C, C-VT, or P2PE). If your processes don't slot neatly into one of those, you default to D. There's also a separate SAQ D for service providers, which has its own quirks — this post focuses on the merchant version.

The headline number is the one most people remember: SAQ D-Merchant covers around 329 individual controls, spread across all 12 PCI DSS requirements. By contrast, SAQ A (the shortest merchant SAQ) is roughly 22 controls. That gap of about 300 controls is the difference between a few hours of paperwork a year and a near-permanent compliance project. We've laid out the wider context in our SAQ A vs SAQ D guide, which is worth reading alongside this piece if you're still deciding which level applies to you.

For the formal definition, the self-assessment questionnaire glossary entry has the PCI SSC wording. The short version: SAQ D is what you fill in when you can't truthfully tick the eligibility boxes on any of the shorter SAQs.

Who actually has to complete SAQ D-Merchant?#

Most merchants on SAQ D didn't choose to be there — they ended up there because of how they take payments. The common patterns we see in UK contact centres are depressingly familiar.

The first is taking card details over the phone with the agent typing them into a CRM, payment gateway, or virtual terminal. The instant an agent hears or sees a Primary Account Number (PAN), your phone system, call recorder, agent's PC, screen-sharing tool, internal network and any system the agent touches that day are all in scope. That's not pedantry — that's the PCI SSC's own scoping guidance.

The second is taking payments through a hosted page that you've heavily customised, or one where you handle the postback containing card data. If you're sending card data through your servers, even briefly, you're outside SAQ A's eligibility and into SAQ D-Merchant territory.

The third is the surprise category: card-on-file recurring billing where the original capture was done by someone in your team rather than a tokenisation service. If your database holds tokens issued by a PCI-compliant payment tokenisation service, you're probably fine. If it holds the raw PAN — even encrypted — you're on SAQ D, and you should read our piece on moving from SAQ D to SAQ A as a priority.

If you sell into the US as well as the UK, the answer doesn't change — PCI DSS is a global standard, the SAQ types are identical, and the same eligibility rules apply on both sides of the Atlantic. The compliance work doesn't double; it's the same work, audited once.

The 329 controls, by requirement#

The PCI SSC organises SAQ D-Merchant by the twelve top-level PCI DSS requirements. Here's roughly how the control count breaks down by area, so you can see where the weight sits.

Requirement 1 — Install and maintain network security controls. Around 30 controls covering firewalls, network segmentation, change control on rule sets, and documentation of trust boundaries. If you haven't formally segmented your card-data environment from your corporate network, this requirement alone can derail your whole assessment.

Requirement 2 — Apply secure configurations. Around 20 controls. Default passwords removed, hardening standards documented and applied, vendor-supplied accounts disabled. Sounds easy. Isn't, when you've got 150 endpoints in a contact centre.

Requirement 3 — Protect stored account data. Around 35 controls. This is the requirement that catches everyone. If you store full PAN anywhere — a call recording, a CRM note field, an old spreadsheet, a chat transcript — you have to encrypt it, manage the keys, restrict access, and prove all of that on an annual cycle. The cheapest way to pass Requirement 3 is to not store cardholder data at all, which is exactly what tokenisation gets you. Our guide to descoping PCI covers this in more depth.

Requirement 4 — Protect cardholder data with strong cryptography during transmission. Around 12 controls. TLS 1.2 minimum, modern cipher suites, no fallback to weak protocols, certificates managed properly.

Requirement 5 — Protect all systems and networks from malicious software. Around 15 controls covering anti-malware deployment, signature updates, anti-phishing technical controls, and periodic evaluation of systems not commonly affected by malware.

Requirement 6 — Develop and maintain secure systems and software. Around 30 controls. Patching, secure SDLC, code review, change management, vulnerability response timelines. If you build any custom software that touches cardholder data, this is a real workload.

Requirement 7 — Restrict access by business need to know. Around 15 controls. Role-based access, least privilege, documented access matrices, periodic access reviews.

Requirement 8 — Identify users and authenticate access. Around 40 controls. Multi-factor authentication is now mandatory for all access to the cardholder data environment under v4.0.1 — not just remote access. Password length, complexity, rotation, lockout, and session timeout are all here.

Requirement 9 — Restrict physical access to cardholder data. Around 25 controls. CCTV, visitor logs, secure media destruction, point-of-interaction device tampering checks. Yes, this applies to your office too if any device in there can see card data.

Requirement 10 — Log and monitor all access. Around 35 controls. Centralised logging, log retention (one year minimum, 90 days online), daily review, time synchronisation, and alerting on critical events.

Requirement 11 — Test security regularly. Around 35 controls. Quarterly internal and external ASV scans, annual penetration testing, segmentation testing, wireless rogue-AP scans, file integrity monitoring, change detection.

Requirement 12 — Support information security with policies and procedures. Around 35 controls. An information security policy, risk assessment, incident response plan, security awareness training, service provider management, and the targeted risk analyses now required under v4.0.1.

The exact counts shift slightly between v4.0 and v4.0.1 as the standard evolves, and the PCI SSC has been clear that v4.0.1 finalises a few controls that were marked "future-dated" in v4.0. For the official structure see our PCI DSS v4 solutions page, which tracks the requirement-level changes.

The real cost of staying on SAQ D-Merchant#

People focus on the questionnaire itself, but the questionnaire is the cheap bit. The expensive bit is the operational machinery you need to truthfully tick those 329 boxes year after year.

Let's break it down. A QSA-supported SAQ D-Merchant assessment for a mid-sized UK contact centre typically runs £15,000 to £35,000 in fees, depending on environment complexity. Quarterly external ASV scans add £2,000 to £6,000 a year. Annual penetration testing of the cardholder data environment is usually £8,000 to £25,000. Internal tooling — SIEM, file integrity monitoring, vulnerability scanners, password vaults — easily runs £20,000 to £80,000 a year for a contact centre. And that's before you've paid for the security analyst's time to actually do the daily log review, the incident response drills, and the targeted risk analyses.

Add it up and a contact centre on SAQ D-Merchant is comfortably spending £60,000 to £150,000 a year on compliance overhead. That's a recurring cost, every year, just to keep the lights on. And it grows with headcount, because PCI scope grows with every agent who can hear a card number.

Compare that to SAQ A. The annual paperwork is roughly 22 questions you can do in an afternoon. There's no ASV scanning requirement on internal networks for SAQ A merchants (the requirement applies to the externally facing payment pages, which your provider runs). There's no pen testing requirement on the cardholder data environment, because you don't have one. SAQ A merchants typically spend under £5,000 a year on PCI overhead.

That's an annual saving on the order of £50,000 to £140,000. For one client, Pinnacle Group, the move from a heavily-instrumented SAQ D-Merchant posture down to SAQ A took 95% of the in-scope systems out of audit altogether. They didn't fire any security analysts — they redeployed them onto actual security work instead of compliance theatre.

Why so many contact centres end up on SAQ D by accident#

We've audited a lot of contact-centre payment flows over the years, and the path to SAQ D is almost always the same. It starts innocently: someone in operations sets up a process where an agent reads card details into a payment gateway because "that's how we've always done it". The PCI implications aren't discussed because card payments were a tiny slice of revenue when the process was designed.

Then revenue grows. Recordings get archived for QA. The CRM gets a notes field that agents start typing PANs into because the gateway is sometimes slow. A team-leader sets up screen recording on the agent desktops for training. Someone enables WebEx or Teams shadowing. A new team is brought in for outbound calls. Each of these is innocent in isolation, and each one drags more systems into PCI scope.

By the time anyone asks the question "what's our PCI status?", the answer is: every system the agent touches is in scope, your call recording platform is in scope, your CRM is in scope, your screen-share tool is in scope, your VPN concentrator is in scope, your Active Directory is in scope, your endpoint management platform is in scope, your IT helpdesk's remote-support tool is in scope, and your office Wi-Fi is in scope. That's SAQ D-Merchant in its purest form: hundreds of controls applied to systems that have nothing to do with payments because card data has bled across your entire estate.

If this sounds familiar, our piece on why SAQ A beats SAQ D for contact centres walks through the financial and operational case in more detail.

The route out: shift to SAQ A by removing card data from your environment#

The cleanest way to escape SAQ D-Merchant is the one PCI SSC themselves recommend: don't store, process or transmit cardholder data if you don't have to. Outsource the moment of capture to a PCI-compliant third party, and you take all the systems they used to touch out of your scope.

For phone payments specifically, the proven technique is DTMF masking. When the buyer reads their card number into the phone, the keypad tones are intercepted by a third-party platform (us, in most of the cases we work on), flattened to a constant tone that your agent and call recorder hear, and routed directly to the payment gateway. Your agent stays on the line and can hear the customer talking the whole time. Your recording captures everything the buyer says, except the moment the digits are pressed. The PAN, expiry and CVV never enter your network, never touch your agent's PC, never sit in your CRM, and never appear in a call recording. There's nothing for an attacker to exfiltrate because the data isn't there.

For web payments, the equivalent is a fully-redirected hosted payment page or an iframe that the card brands recognise as PCI-validated. Our customised web checkout page covers the architectural options. The principle is identical: the buyer's browser talks directly to the PCI-compliant payment platform, your servers never see card data, and your scope shrinks accordingly.

The combination of these two patterns is what gets contact centres from 329 controls down to 22. For the full implementation playbook, see moving from SAQ D to SAQ A.

The five hardest SAQ D-Merchant controls in practice#

If you're going to stay on SAQ D-Merchant, these are the controls our QSA partners tell us cause the most retests and remediation work. Worth knowing about even if you're planning to descope.

3.5.1 — Render PAN unreadable wherever it's stored. Tokenisation is the cleanest answer, but the moment you have a tokenisation service you should be asking whether you need SAQ D at all. Encryption with managed keys is fine but harder to maintain.

8.4.2 — MFA for all access to the cardholder data environment. This was the biggest single change in v4.0.1. Previously MFA was only required for remote and admin access. Now it's universal. If your agents log into their CRM with username and password, and that CRM is in scope, you're failing this control. Read our PCI SAQ levels explained guide for context on how this propagates across SAQ types.

10.4.1.1 — Automated mechanisms for log review. Manual daily log review is technically allowed but practically impossible for any environment with more than a handful of systems. You need a SIEM with proper correlation rules, and someone whose job includes triaging the alerts.

11.6.1 — Change-and-tamper detection on payment pages. New under v4.0.1. If you have any web payment flow, you need a control that detects unauthorised changes to the script content of the payment page. Magecart-style attacks made this a board-level concern, and the PCI SSC responded with a specific control.

12.3.1 — Targeted risk analysis for each PCI-mandated control with flexible frequency. A new v4.0.1 control that asks you to document why your chosen frequency for each periodic activity (scans, reviews, training) is appropriate. It's the most administratively annoying control in the standard — not technically hard, but it generates a lot of paperwork.

What auditors actually look for during an SAQ D-Merchant assessment#

Whether you self-attest or bring in a QSA, the underlying expectation is the same: evidence, not assertions. Saying "yes, we patch monthly" without producing the patch logs is a fail. Saying "yes, we review access quarterly" without producing dated review records is a fail. The questionnaire is just the index; the work is in the evidence pack.

The most common evidence-pack gaps we see, in order of frequency: missing or out-of-date network diagrams; no documented data flow showing where cardholder data enters, moves through and leaves the environment; missing key management procedures (or procedures that nobody actually follows); inconsistent log retention because someone changed a retention policy and forgot to update the other tools; pen test reports older than 12 months; risk register that hasn't been touched since the previous assessment.

None of these are intellectually hard. They're all just administrative discipline, and they all eat time. That's the underlying truth about SAQ D: it's not impossible, but the operational cost of doing it well, every year, in perpetuity, is the reason most contact centres look at descoping the moment they understand the maths.

What changed under PCI DSS v4.0.1 that matters for SAQ D-Merchant#

v4.0.1 became the only valid version on 1 January 2025. v3.2.1 is retired. v4.0 is also superseded. So when you submit an SAQ D-Merchant today, you're submitting against v4.0.1, full stop. A few things moved that are worth flagging.

The customised approach is now formalised. You can meet a stated control objective via a method other than the prescribed one, provided you document the rationale, demonstrate equivalent risk reduction, and have a QSA validate it. Most merchants stick with the defined approach because it's simpler, but it's there if you need it.

MFA universality (control 8.4.2) is the change with the widest operational impact. Pretty much every SAQ D-Merchant environment we look at needs SSO and MFA rolled out to every system in scope, not just the privileged accounts.

Phishing-resistant authentication is now expected for administrative access in some configurations. FIDO2 hardware keys are the canonical answer. SMS-based one-time passwords are explicitly called out as not phishing-resistant.

Targeted risk analysis (12.3.1) and the script tamper-detection control (11.6.1) are both new. Both create real administrative load.

Read our PCI DSS v4 solutions page for the full v4.0.1 picture, including the controls that became mandatory on 31 March 2025.

SAQ D-Merchant vs SAQ D for service providers#

There are two SAQ D documents, and they're not the same. SAQ D-Merchant is for merchants. SAQ D-Service Provider is for entities that store, process or transmit cardholder data on behalf of other organisations. The service provider version has additional controls around shared infrastructure, multi-tenancy, and customer-segregation reporting. If you're not sure which you are, the test is straightforward: are you taking payment for goods or services you sell, or are you taking payment on behalf of someone else? The former is a merchant; the latter is a service provider.

Most of our clients are merchants, but if you happen to be a service provider, your reporting obligations also include providing customers with appropriate documentation — typically an Attestation of Compliance or, for higher tiers, a full Report on Compliance.

Common myths about SAQ D-Merchant#

We hear the same misunderstandings from operations leaders almost every week. Worth tackling them head-on.

Myth 1: "Our call recordings are fine because we pause-and-resume during the payment." Pause-and-resume was the dominant compliance pattern in the 2010s, and it's now widely considered insufficient by acquirers and QSAs. The reasons: agents forget to pause, the system fails to pause, the system pauses then resumes early, and even when it works the agent has still heard the card number with their own ears (so they're in scope as a person). Pause-and-resume keeps you on SAQ D-Merchant — it doesn't get you to SAQ A. The PCI SSC's own scoping guidance is explicit on this.

Myth 2: "We use a tokenisation service so we're already SAQ A." Tokenisation only descopes you if the tokenisation happens before card data reaches your environment. If your agent types the PAN into a form that then tokenises it, the PAN entered your environment first, and you're still on SAQ D-Merchant. The technical test: from the moment the buyer's fingers hit the keypad to the moment the gateway returns an auth response, does the card data ever touch a system you control? If yes, you're on SAQ D.

Myth 3: "SAQ D doesn't apply to us because we process fewer than 6 million transactions." That's a confusion between SAQ type and merchant level. The 6-million figure is the threshold for Level 1 reporting (which requires a full Report on Compliance rather than an SAQ). SAQ D-Merchant applies based on how you process payments, not how many you process. A merchant doing 50,000 transactions a year can absolutely be on SAQ D-Merchant if their flow doesn't qualify for a shorter SAQ.

Myth 4: "We only take card payments occasionally, so the rules are lighter." They aren't. PCI DSS doesn't have a "small volume" carve-out. One transaction a year is enough to put you in scope. The financial maths obviously changes — running £80,000 of controls to take £10,000 of card revenue is absurd — but the rules are the same.

Myth 5: "Our acquirer hasn't asked, so we must be fine." Acquirers don't always notice gaps until something goes wrong. The first time most merchants get serious attention from their acquirer's risk team is after a chargeback spike, a customer complaint about data handling, or an industry-wide breach alert that triggers a portfolio review. By then the remediation timeline is set by someone else.

How SAQ D-Merchant interacts with UK and EU data law#

PCI DSS is a card-industry standard, not a law. But the controls it requires overlap heavily with what the UK GDPR and the Data Protection Act 2018 require for personal data, and the ICO has been increasingly clear that payment card details are personal data deserving of strong protection. So an SAQ D-Merchant breach typically becomes a GDPR incident as well, with a separate set of obligations: 72-hour notification to the ICO, individual notifications where there's high risk to data subjects, and the prospect of administrative penalties.

The interaction works in your favour when you descope. Removing card data from your environment doesn't just reduce PCI scope — it reduces the personal-data footprint that GDPR cares about. Fewer systems hold sensitive personal data, fewer audit trails need to be maintained for data-subject rights requests, and the impact assessment for any new system gets simpler. The compliance dividend compounds.

The same logic applies to the EU's PSD2 strong customer authentication rules. PSD2 isn't directly an SAQ D issue, but it shapes how you handle card-on-file and recurring transactions. If you've descoped properly, your tokenised card-on-file flow runs through your payment provider's PSD2-compliant infrastructure, and you inherit the SCA work rather than having to do it yourself.

A worked example: contact centre on SAQ D-Merchant, year by year#

Let's make the cost real with a worked example based on a typical client engagement.

Company: UK-based subscription business, contact centre of 60 agents handling inbound customer service and outbound retention calls. About 40% of calls involve a card payment, either taking a new payment or updating a card-on-file. Annual card revenue around £18 million across 220,000 transactions.

Year 1 on SAQ D-Merchant. They engage a QSA to scope and assess. QSA fees £22,000. Initial remediation work (network segmentation, MFA rollout, log centralisation, FIM deployment): £180,000 in capital costs plus 6 months of project management. Quarterly ASV scans, annual pen test, ongoing SIEM tuning: £58,000. Total Year 1: £260,000. Two full-time-equivalent staff doing nothing but PCI work.

Year 2 and onward. QSA renewal £15,000. SIEM, FIM, vulnerability scanning, MFA platform licensing: £42,000. ASV scans and pen test: £18,000. One full-time-equivalent security analyst doing PCI work plus a half-FTE compliance manager: £95,000. Total annual run rate: £170,000. That's the cost of keeping the lights on, year after year.

Now imagine they descope. Project to roll out DTMF masking across the contact centre: about 8 weeks of work and £35,000 of professional services. Acquirer notification and SAQ A submission: 2 weeks of administrative work. New annual run rate: £4,500 in compliance fees, no FTE allocated to PCI specifically. Net annual saving: £165,000. Payback period on the descoping project: less than 3 months.

The numbers are deliberately conservative — we've seen larger savings where the contact centre was running 24/7 with more security tooling, and smaller savings where the existing PCI estate was already lean. But the shape of the picture is consistent. Staying on SAQ D-Merchant when you don't have to is one of the most expensive operational decisions a contact centre can quietly make.

What you should do this week if you're on SAQ D-Merchant#

Three concrete steps, in order.

First, find your current SAQ submission and check the date. If it's more than 12 months old, you have an immediate compliance issue regardless of any descoping conversation. SAQ submissions are annual. An expired SAQ is not a small deal.

Second, document your card data flow — even roughly. A sketch on a whiteboard is enough to start. Where does card data enter the environment? Where does it move to? Where does it leave? Every system that appears on that diagram is in PCI scope. Most clients are genuinely surprised by how many systems show up. That diagram is the artefact that drives every other conversation about descoping.

Third, get a baseline cost of your current PCI compliance posture. Add up QSA fees, scanning tools, SIEM, FIM, MFA platform, pen testing, and the proportion of FTE time spent on PCI. Compare that to what an SAQ A posture would cost. If the gap is bigger than the cost of a descoping project, you have a clear business case to take to your finance director.

SAQ D-Merchant and your call recording obligations#

One of the trickier parts of SAQ D-Merchant for contact centres is what to do about historical call recordings. Most contact centres are required by FCA rules, Ofcom rules, or internal quality programmes to retain call recordings for a fixed period — often six years for financial services calls, often two years for general customer service. If those recordings contain spoken card numbers, the recordings themselves are cardholder data and they sit inside the PCI scope until the retention period expires.

That has two practical consequences. First, your recording platform is in scope right now, even if you've never thought of it that way. The storage, the access controls, the search interface, the export mechanism — all of it. Second, even if you descope from today by deploying DTMF masking tomorrow, the historical recordings remain in scope until they age out. That's a transition cost you need to plan for.

The usual approach is to keep the existing recordings in a separately segmented vault with hardened access controls for the duration of the retention period, while the live recording flow moves to a no-card-data architecture. It's manageable, but it needs designing in from the start of the descoping project. We've helped several clients structure this — happy to walk you through what the transition looks like in practice.

What good evidence looks like for SAQ D-Merchant#

If you're staying on SAQ D-Merchant, the single most valuable thing you can do is invest in evidence quality. QSAs and acquirers have seen every flavour of poor documentation, and a well-organised evidence pack genuinely shortens an assessment by weeks.

The pack should include: a current network diagram showing every system in the cardholder data environment and every connection between them; a current data flow diagram showing where card data enters, where it moves, where it's stored, and where it leaves; a risk assessment dated within the last 12 months; an information security policy approved at board level; a documented incident response plan with named roles and contact details; service provider inventories with current AOC dates for each provider in scope; quarterly ASV scan reports for the last 12 months; the most recent annual pen test report with all findings either fixed or risk-accepted with sign-off; targeted risk analyses for each periodic activity covered by control 12.3.1; and dated records of access reviews, log reviews, change approvals, and security awareness training completion.

If you can produce all of that within an hour of a QSA asking, your assessment will go smoothly. If you can't, expect remediation and retest cycles that consume weeks of your team's time.

How Paytia removes the need for SAQ D-Merchant in the first place#

The pitch is simple. We take the moment of card capture out of your environment entirely. Your buyers still call your agents, your agents still take the order, your CRM still gets the transaction outcome — but the card number, expiry and CVV never enter your network. The technical mechanics use a combination of DTMF masking, secure IVR collection, and tokenised callbacks. The compliance outcome is that your acquirer accepts SAQ A, not SAQ D-Merchant, and your annual control count drops by around 300.

We've taken clients off SAQ D-Merchant in as little as two weeks, including the acquirer notification and SAQ paperwork. For Pinnacle Group, the project removed 95% of their previously in-scope systems from audit. For Warby Parker, it normalised PCI compliance across their UK contact centre to match the eyewear retailer's web-side posture. For InsureandGo, it took the entire telephone-payments flow out of scope while keeping their existing agent workflow intact.

If you'd like to see what's involved for your environment, the next steps section below has the relevant links.

Next steps#

If you're on SAQ D-Merchant today and the cost is starting to bite, the fastest way to find out whether you can descope is a short conversation with our team. Get in touch via our contact page and we'll walk through your current flows. If you'd rather see the technology working first, our live demo shows DTMF masking on a real call with a real agent and a real card capture, so you can hear exactly what the buyer hears and what the recording captures.

Want the wider picture before you commit? Start with the SAQ A vs SAQ D pillar guide and the contact centre cost analysis.