Moving from SAQ D to SAQ A — Pinnacle Group Case Study

Last updated: 29 May 2026

If you're sitting on SAQ D today and you've worked out that SAQ A is on the table, the question stops being "should we descope" and starts being "what does the move actually involve". That's a different conversation, and it's the one we have most often with finance and compliance leads who've just realised their next audit could be 22 questions instead of 300.

The move from SAQ D to SAQ A isn't a paperwork change. It's an architecture change with a paperwork change at the end. You can't just answer SAQ A questions on a SAQ D environment — your assessor will fail the eligibility test on clause one (no storage, processing or transmission of cardholder data) before they get to question two. To file SAQ A honestly, your systems have to stop touching card data. Everything else flows from that.

We've walked dozens of contact centres through this move. Pinnacle Group is the one with the cleanest numbers — 95% scope reduction on a RingCentral stack, no agent retraining beyond a 10-minute briefing, and the SAQ filed within the same financial year the project started. This piece is the walk-through: what comes out of scope, the order to do it in, what your assessor will look at, and where the move usually goes wrong. If you want the side-by-side on the two forms first, our SAQ A vs SAQ D guide covers eligibility, question counts, and the cost-of-controls maths.

What "moving from SAQ D to SAQ A" really means#

The phrase makes it sound like a form swap. It isn't. SAQ A is reserved for merchants whose systems never store, process or transmit cardholder data — full stop. If you're on SAQ D today, at least one of those three is happening somewhere in your environment. Usually all three. Agents hear the digits (processing), call recordings capture them (storage), and the SIP stream carries them between trunk and contact centre (transmission). To file SAQ A, all three have to stop on the merchant's side of the line.

What that means in practice depends on where the card data is entering today. For most phone-payment operators we work with, it's entering through the agent's voice path. The customer reads their card number aloud, the agent types it into a CRM or payment form, and the recording captures the whole exchange. Three SAQ D entry points, one customer interaction. The descope job is to move all three out of the merchant's environment in a single architectural change — which is what DTMF masking with a PCI DSS Level 1 service provider actually does.

The other route is fully outsourced flows — payment links sent by SMS, hosted IVR transfers, click-to-pay handoffs. These work too, and we cover the trade-offs in our why SAQ A beats SAQ D for contact centres piece. The architectural test is the same: does the merchant's environment ever see the PAN? If the answer is no, SAQ A is available. If the answer is "only briefly" or "only in the recording", SAQ D applies and you're back to 300 questions.

The Pinnacle Group story — 95% scope cut on RingCentral#

Pinnacle Group manages over 30,000 homes across the UK on behalf of local authorities, registered providers, and institutional investors. Service charges — the building-maintenance fees apartment owners pay — were being collected partly by bank transfer and partly by phone. The phone payments were the compliance problem.

Alison Wade, Pinnacle's Head of Income and Performance, had run collection operations before and knew the shape of PCI DSS. The team was on SAQ D because the existing setup put card numbers through the agent's voice path, the RingCentral recording, and the CRM payment form. Every contact centre seat that took payments was in scope. Every recording in the archive was in scope. Every analytics platform that touched call audio was in scope. The annual workload of evidencing it all was material — the kind of thing that consumes a finance team for weeks every year and produces no business value.

The brief was simple. Keep RingCentral. Keep the service-charge collection process. Stop the card numbers reaching Pinnacle's systems. Reduce the SAQ. We deployed DTMF masking on the RingCentral inbound path, so the customer keys digits on their handset, the tones get intercepted at the Paytia edge before they reach Pinnacle's network, and the recording captures continuous audio with neutral substitute tones during the digit-entry window. The agent stays on the line, confirms the amount before capture, sees "Approved" or "Declined" with the last four digits afterwards, and continues the call. No screen pop with full PAN. No payment form on the agent's CRM. Nothing for the recording to capture.

The scope move was 95%. Pinnacle went from SAQ D's ~300 questions to SAQ A's ~22 questions in the next audit cycle. The agent population came out of the PCI user group. The recording archive came out of the cardholder data environment. The CRM payment form was removed entirely — the agent now triggers a masking session from a button inside the existing customer record, which calls our API rather than collecting PAN. The acquirer relationship stayed the same. The full case study is up on our customer reviews page if you want Alison's direct words on what changed for her team.

The descope project in seven steps#

Every SAQ D to SAQ A move we've done follows roughly the same seven steps. The order matters. If you skip the scope diagram, you'll discover a payment path nobody knew about three months in. If you skip the recording audit, you'll go live with a QA tap that's still pulling card data. The point of the sequence is to surface every place card data enters today before you change anything.

Step 1: Build the as-is scope diagram. Map every channel that can carry a PAN into your environment. Inbound voice. Self-service IVR. Scheduled callbacks. Web chat that escalates to phone. SMS-to-call. CRM screen pops. Each path gets a diagram with timestamps and the systems it touches. Requirement 12.5.2 mandates this annually anyway, but for the descope project it's the foundation document. If you can't draw it in an afternoon, that's the first thing to fix.

Step 2: Pick the descoping architecture. For agent-assisted phone payments, that's DTMF masking nine times out of ten. For self-service flows, it's a hosted IVR or payment link. For chat-to-call, it's a click-to-pay handoff. Mixed environments use more than one. The PCI SAQ levels explained guide walks through which architecture matches which SAQ.

Step 3: Choose a PCI DSS Level 1 service provider. The provider's Attestation of Compliance has to cover the services you're outsourcing — not just "PCI DSS Level 1" in general. Read the Services Covered section carefully. A provider whose AoC covers masking but not tokenisation, or covers both but not the integration API your team will use, leaves you with a gap your assessor will find. Our own AoC is available on request and we walk customers through which services are covered before they sign.

Step 4: Run the integration. For a cloud contact-centre stack — RingCentral, Aircall, 3CX, Zoom, Genesys Cloud — this is usually two to four weeks end to end. The work is in three parts: routing the inbound voice through the masking layer, integrating the agent UI (usually a button in the CRM that calls the masking API), and reconciling the captured payment back into your payment gateway and accounting system. Pinnacle's RingCentral integration was on the lower end of that range.

Step 5: Audit the recordings. Most teams forget there are usually two or three places call audio gets recorded. The primary contact-centre recording is obvious. The QA application that taps into the SIP stream often isn't. The transcription tool the marketing team enabled last year usually isn't documented anywhere. Each one is a potential leak point. If any of them captures pre-masking audio, you're back in SAQ D regardless of what the primary recording looks like. Walk through every system that touches call audio and prove it receives the masked stream, not the raw one.

Step 6: Remove the old PAN paths. Take the manual card-entry form off the CRM. Remove the screen pop that displays full PAN after auth. Decommission the fallback "agent-keyed" payment screen. If you leave them in place "just in case", an agent will use one in a busy hour and your descope is done. We see this fail mode often enough that we treat it as a project milestone — old paths gone, not just hidden. Anything other than a manual PAN field on the agent's screen counts as a defensible fallback.

Step 7: Re-run the scope diagram and file the SAQ. The as-is diagram from Step 1 now becomes the to-be diagram. Annotate where masking sits, where the merchant boundary now ends, which systems left scope, and what the responsibility matrix looks like with the provider. Your assessor will ask for this exact document. The descoping explained piece covers what the diagram needs to show.

What comes out of scope when you move to SAQ A#

The headline scope cut isn't the question count — it's the system count. SAQ D drags in everything that could touch cardholder data; SAQ A only covers the boundary between merchant and provider. That difference compounds across the environment.

On Pinnacle's job, the list of systems that left scope ran to about fifteen items. The RingCentral recording archive. Three QA and transcription tools. The CRM payment form. Every agent workstation that previously had a payment screen. The internal SFTP that the QA team used to pull recordings. The analytics platform that ingested transcripts. The backup tier where recordings landed. The Active Directory groups that gated access to the recording archive. The VPN logs for agents connecting to the payment subnet. Each one had its own quarterly evidence requirements under SAQ D — ASV scans on the workstations, MFA on the AD groups, log review on the SFTP, encryption-at-rest checks on the backup tier. All of it gone with the architecture change.

What stays in scope under SAQ A is small. The boundary with the provider, the responsibility matrix that says which controls are theirs versus yours under Requirement 12.8, the annual scope review, the third-party management process, and the residual systems your environment runs that touch payment metadata (not PAN). That's roughly a quarter of the work, with the right architecture.

The recording problem — where SAQ A migrations usually break#

If we had to pick one failure mode that breaks SAQ A descope projects, it's the recording. The masking gets installed, the agent UI gets updated, the assessor signs off the primary path — and then someone notices the QA tooling has been quietly capturing the SIP stream from a tap that sits before the masking point. Every "masked" call is in the QA archive unmasked. Back to SAQ D.

The root cause is almost always architectural rather than malicious. QA teams set up SIP taps years ago for legitimate quality-monitoring reasons. The taps sit at network locations that predate the masking deployment. Nobody asked the QA team during the descope project because the QA team aren't part of the payments function. The tap kept capturing, the masking got installed downstream of it, and the audit caught the gap.

The fix is to push the masking edge as far upstream as it can go — ideally at the SIP trunk, before any internal network leg. That way every downstream recording, QA tap, analytics ingest, or transcription tool receives the masked audio by default, and there's no quiet path that captures unmasked digits. We do this by default on Paytia masking deployments; it's worth confirming with any provider you're evaluating. The wider DTMF masking and PCI compliance piece covers the architecture in detail.

The evidence pack your assessor will ask for#

Whether you're filing SAQ A yourself or sitting with a QSA, the evidence pack is the same six artefacts. Have them on a shared drive with version control and dated sign-offs.

First, the to-be scope diagram updated within the last twelve months. Second, the data-flow diagrams for every channel that can carry card data — even the ones that no longer touch it, because the assessor needs to see what changed. Third, your provider's current Attestation of Compliance with the Services Covered section highlighted, plus the responsibility matrix showing which PCI DSS requirements are theirs versus yours. Fourth, the written confirmation from the provider that they handle the card-data functions you've outsourced — this is the document that satisfies SAQ A clause two of the eligibility test.

Fifth, the most recent quarterly ASV scan report on whatever residual perimeter you still have. Sixth, the incident response plan with the date of the last tabletop exercise on the front page. Pinnacle's pack was about 40 pages when complete. None of it required new tooling — it was a curation exercise. The point isn't to write new documents; it's to gather what already exists into a single, dated, version-controlled bundle the assessor can read in a sitting.

The traps — five things that go wrong#

We've seen the same five mistakes catch out otherwise well-run descope projects. They're worth knowing in advance.

The first is partial outsourcing. A merchant masks during digit entry but lets the agent enter a card manually for callers with disability access needs. The manual path puts PAN into the merchant's environment, the whole environment falls into SAQ D, and the masking work hasn't saved anything. Fix: route accessibility calls through a hosted IVR with screen-reader-compatible audio prompts, or a payment link delivered to the customer's choice of channel.

The second is the recording leak we covered above. Walk every system that touches call audio. Prove it receives masked audio. Don't assume.

The third is the screen-pop pattern. A CRM displays full PAN after authorisation as a "convenience" for the agent to confirm the card to the customer. That display puts PAN inside the merchant's systems and fails SAQ A clause one. Fix: display only the last four digits and the card-scheme name. Every modern gateway returns that by default.

The fourth is hot transfer. A merchant routes the customer to a hosted IVR for the payment leg but keeps the agent on the line for hand-holding. If the agent can hear the DTMF tones during the transfer, those tones are reaching the merchant's environment via the agent's audio path. Fix: either mask the tones at the agent's leg too, or use a true blind transfer where the agent drops off before the payment IVR begins.

The fifth is the fallback path. A team keeps the old manual card-entry form on the CRM "in case the masking fails". It will get used. The descope is done the moment it is. Fix: build the failure path into the architecture too — a payment link sent by SMS as the fallback, or a callback queued for a different agent group that uses a different masking session. Anything other than a manual PAN field on the agent's screen. The DTMF masking solution page covers what a properly designed fallback looks like.

Cost picture — what an SAQ D to SAQ A move actually saves#

The case for descoping isn't only about the form. It's about the annual cost of evidencing SAQ D versus SAQ A. We've put a rough cost model together based on the projects we've run, and the numbers line up consistently.

An SAQ D environment for a mid-size phone-payment operation typically costs £40,000 to £120,000 a year to evidence — internal time on scope reviews, log reviews, scan remediation, MFA rollout, third-party management, and the QA dance with the assessor. SAQ A on the same operation drops that to £8,000 to £20,000. The masking platform sits on top of those savings, so the net cost picture is usually 50-70% better in year one, and it widens further once you stop hiring for the SAQ D headcount.

That's before the soft benefits. Agents who don't hear card numbers can't accidentally repeat them on a hot mic. Recordings without PAN can be used for QA and training without redaction. The recurring scope-review meeting becomes a 30-minute calendar event rather than a two-week project. The channel separation business benefits piece walks through the commercial impact in more detail.

What changes for the agent — and what doesn't#

One of the questions we get asked most often is whether moving to masking changes the agent's job. The short answer is no, beyond a 10-minute briefing on the new flow.

Before masking, the agent confirms the amount, asks the customer to read their card number, types it into a payment form, types the expiry, types the CVV, hits submit, waits for the gateway, and confirms the result to the customer. After masking, the agent confirms the amount, clicks "take payment" inside the customer record, tells the customer they'll hear a tone followed by silence while they key their card details, waits for the "Approved" or "Declined" indicator, and confirms the result. The conversational flow stays the same. The agent stays on the line throughout. The only difference is that nobody — agent, recording, QA team — hears the digits.

What changes is the agent's exposure. Before masking, an agent who took 80 payments a day was exposed to 80 PANs a day. Some of those got mis-typed, mis-heard, or accidentally repeated. After masking, the agent is exposed to none. The risk of mis-keyed amounts goes up slightly because the customer enters the digits rather than the agent re-reading them — but well-designed masking platforms confirm the amount with the customer before the capture window opens, which is how Pinnacle's flow works today.

The QSA conversation — what to expect#

If you're using a QSA for either a SAQ D Report on Compliance today or for the SAQ A migration, the conversation has a predictable shape. The first hour is the scope diagram. The second hour is the data-flow diagrams. The third is the provider AoC and responsibility matrix. Then they walk a live call through your masked flow with a member of your team, look at the resulting recording to confirm it's truly silent during digit entry, and pull a sample of payment logs from the masking provider to confirm those match the gateway records.

The questions that come up most often are about the QA tooling and the fallback path. The QSA will ask which systems can ingest call audio and how each one receives masked audio. They'll ask what happens if the masking platform is unavailable and what the documented agent procedure is in that case. They'll ask about the integration API — who can call it, how authentication works, where the logs go. None of these are hard if the architecture is right; all of them are hard if it isn't. The AoC guide covers what "covered services" really means, and the DTMF masking glossary entry covers the tone mechanics if that's useful background.

Pinnacle's project plan — week by week#

The Pinnacle Group project is worth walking through in detail because it's representative of how a clean descope plays out. Week one was the as-is scope diagram and the recording audit. The compliance lead and the RingCentral admin spent two afternoons mapping every system that touched call audio — the primary recording archive, the QA workspace, the analytics dashboard, the SFTP that pulled recordings for the supervisor team. The diagram was the single most useful artefact of the whole project; it was the document the QSA opened first when sign-off came round.

Week two was vendor confirmation. We sat with Pinnacle's compliance lead and walked through our Attestation of Compliance line by line — which services we cover, where the responsibility boundary sits, what they're filing under their SAQ A clause two evidence. The written confirmation that we handle the card-data capture, transmission and tokenisation went into their evidence pack the same week. The third-party management process under Requirement 12.8 had a Paytia row added; nothing else changed at that layer.

Weeks three and four were the technical integration. RingCentral inbound routing was reconfigured to send the voice leg through our masking edge before it reached the contact-centre platform. The agent UI got a single new button inside the existing customer record — "Take payment" — which called our API with the amount and a reference. The CRM payment form was removed in the same release. We tested with the contact-centre team on a parallel queue for a few days before cutting the live traffic across; no calls went through the new flow until we'd confirmed the recording captured silence during digit entry on a sample of dozens of test transactions.

Week five was the evidence-pack curation. The to-be scope diagram replaced the as-is. The responsibility matrix was finalised. The provider AoC went on the file. The retention policy for the legacy SAQ D recordings was documented — they aged out under the existing 12-month retention rule, so no special cleanup was needed. Week six was the QSA review. The questions ran exactly as I described earlier — scope diagram, data flows, AoC, walk a live call through, look at the resulting recording, pull payment-log samples. Sign-off came the same week. Pinnacle filed SAQ A on the next audit cycle.

Industries where descope projects move fastest#

The SAQ D to SAQ A move plays out differently by sector, mostly because of how the supporting environment is wired. Pinnacle's housing-management background made the project unusually clean — collections were already isolated to a specific team, the RingCentral footprint was well-understood, and there was a single CRM with a single payment screen to modify. We've seen the same pattern in housing-management firms generally.

Charities and non-profits tend to move quickly too — outbound donation flows are well-defined, the agent population is small, and there's usually leadership appetite to cut admin burden. Energy and utilities collections teams take a little longer because the platforms are bigger and the agent populations larger, but the savings are correspondingly bigger too. Insurance brokers running renewal-payment flows tend to be in the middle — straightforward architecturally, slowed by procurement.

What slows projects down across all sectors is internal politics around who owns the masking decision — payments, IT, compliance, or finance. The cleanest projects we've run have a single owner with the budget and authority to commission the change. The slowest have three teams holding pieces of the decision. If you're scoping a descope project, sort that ownership question out first.

Frequently asked questions#

Is moving from SAQ D to SAQ A worth it for a small contact centre?

Usually yes, if you take more than a few hundred phone payments a month. The economics are driven less by transaction volume and more by the annual cost of evidencing SAQ D — scope reviews, MFA, log reviews, scan remediation, third-party management. Even a small SAQ D environment costs £30,000 to £50,000 a year to evidence honestly. SAQ A drops that to roughly £5,000 to £15,000. The masking platform sits on top of those savings.

How long does the SAQ D to SAQ A move take end to end?

For a typical cloud contact-centre stack it's two to four weeks of integration plus a few weeks of evidence-pack curation, so six to eight weeks calendar time. Pinnacle's project ran at the lower end of that range. On-prem PBX and Genesys deployments take longer because the SIP routing is more involved. If a provider quotes six months for a cloud-only environment, they're either underbuilt or padding the timeline.

Do we need to retrain our agents?

A 10-minute briefing covers it. The conversational flow stays the same — the agent confirms the amount, triggers the payment, stays on the line during capture, confirms the result. The only new behaviour is telling the customer they'll hear a tone followed by silence during digit entry. We've never seen this require formal retraining at any of the contact centres we've deployed to.

What if the masking platform is unavailable — what's the fallback?

The right fallback is another out-of-scope payment route — a payment link sent by SMS, a queued callback for a different agent group, or a hosted IVR transfer. The wrong fallback is a manual PAN-entry form on the CRM, because the existence of that form puts your environment in scope regardless of how often it's used. Build the fallback into the architecture from day one.

Will SAQ A reduce our acquirer's processing rates?

No, the SAQ change doesn't directly affect interchange or acquirer fees. What it does affect is the acquirer's view of you as a merchant — a Level 1 service provider in the payment path means the acquirer sees the architecture as lower risk, which over time can support better pricing on contract renewal. The immediate saving is on the SAQ D evidence burden, not the per-transaction cost.

Can we move to SAQ A if we have any recorded calls with card data in them today?

The historical recordings don't block the move to SAQ A — your forward architecture is what the assessor looks at. They will ask what you're doing about the legacy archive. The defensible answer is a documented retention policy with deletion dates, a justification for why you're keeping the data until those dates (legal or regulatory hold, for instance), and access controls that limit who can pull pre-masking recordings until they age out. Cleaning the archive in one go is rarely practical and rarely necessary.

What if we use a third-party gateway — does the masking provider have to replace it?

The right architecture keeps your existing gateway and acquirer relationship intact. The masking provider captures the PAN, passes it to your existing gateway, and returns the auth result. Some masking vendors try to make themselves your gateway as well, which adds friction at switching time and locks you into their commercials. The cleaner pattern — what we run on Paytia — is masking-as-a-layer on top of whatever gateway you already use.

Does SAQ A cover IVR payments too, or only agent-assisted calls?

SAQ A covers fully outsourced flows of either kind, as long as the merchant's systems never store, process or transmit cardholder data. A hosted IVR run by a Level 1 provider — the customer is transferred and pays without an agent — fits SAQ A on the same logic as agent-assisted masking. Mixed environments file the same SAQ A as long as every path keeps card data out of the merchant's systems.

What's the difference between SAQ A and SAQ A-EP for this kind of project?

SAQ A is for merchants whose systems never touch cardholder data. SAQ A-EP applies when the merchant's systems redirect or partially handle the flow without storing data — usually relevant for e-commerce, occasionally for phone-to-link flows where a hosted page is iframed inside merchant-controlled chrome. For pure DTMF masking on agent-assisted calls, SAQ A is the right form. Always confirm with your acquirer and QSA — they make the call.

Can we do this without help from a QSA?

Yes, if your merchant level allows self-assessment. Level 1 merchants always need a QSA-led Report on Compliance. Levels 2 to 4 can self-assess, which is the common path for phone-payment operators moving from SAQ D to SAQ A. A good masking provider will hand you the evidence pack you need for self-assessment — provider AoC, responsibility matrix, written confirmation of services covered — without a separate QSA engagement.

Next steps#

If your environment looks anything like Pinnacle's — agents on a cloud contact-centre stack, recordings on by default, a CRM payment form somewhere in the agent's workflow — the SAQ D to SAQ A move is on the table. The shape of the project is predictable, the timeline is six to eight weeks, and the saving compounds every year afterwards.

We're a PCI DSS Level 1 service provider with our own AoC available on request, ten years of contact centre integrations behind us, and a working-demo call we run on real customer phone systems rather than slide decks. Book a 15-minute call and we'll walk a real payment through your stack so you can see the masking work end to end, or drop us a line and we'll talk through your specific scope picture.