PCI Compliance for Insurance Claims — What You Need to Know

Last updated: 29 May 2026

If your claims team takes card payments by phone — a policy excess, a salvage purchase, a third-party recovery, a premium adjustment after a mid-term change — PCI DSS applies the moment a card number reaches an agent's ear. It doesn't matter that the claim itself is the main job. The card data leg is what the PCI Council cares about, and what your acquirer will ask you to evidence. PCI compliance for insurance claims is essentially the same problem as PCI compliance for any voice channel that takes cards: stop the card data touching your people, your phone system and your claims platform, and you collapse the scope of what an assessor has to look at.

We've spent the last decade helping insurers, brokers, MGAs and claims management companies move out of the SAQ D world and into SAQ A by descoping their voice channel. The pattern is consistent. The claims platforms are usually fine — they're vendor-built and don't store PANs. The leak is the human handler taking the digits over the call, the Avaya or Genesys system recording them, and the screen-recording tool capturing the CRM screen mid-payment. Fix those three, and the PCI compliance question shrinks to something a claims operations director can actually live with.

Why PCI compliance for insurance claims is different from retail PCI#

Retail PCI is built around a defined payment moment — customer at a checkout, card on a terminal or a hosted online form. Claims payments don't behave like that. A first notification of loss (FNOL) call can run for forty minutes covering loss details, policy validation, fraud screening and supplier dispatch — and the payment leg pops up at minute thirty-seven because the policyholder needs to settle an excess before the engineer can be booked. That mid-call payment, taken by an agent who's been listening to the customer's whole story, is where the PCI scope explodes.

Three things make it harder than retail. First, claims calls are long and substantive, so the call recordings are valuable evidence — you can't simply switch recording off when payment starts and back on after, because compliance and complaints handling both depend on the full audio. Second, the agent's CRM screen has the policy record open with claim notes, third-party contact details and supplier instructions — if your screen-recording tool grabs that screen during card entry, you've contaminated the recording with cardholder data. Third, claims handlers move between subrogation, salvage, refunds and excess collection multiple times a day, which means they need a payment flow that drops into any of those contexts without a context switch.

The retail playbook of "redirect to a hosted page" doesn't fit because the customer is on the phone with you, not on your website. That's why the contact-centre descoping pattern matters here — it gives the handler a way to take the payment in-call without ever hearing or seeing the card number. The pillar piece, our claims processing guide, sets out the broader claims architecture. This piece is the PCI-specific layer that sits on top.

When PCI applies to a claims operation — and when it doesn't#

PCI DSS applies if you "store, process or transmit" cardholder data. That's the operative wording from the Council, and it's broader than people expect. "Transmit" includes the audio of a card number travelling down a phone line into your contact centre. "Process" includes an agent typing a PAN into any system at all, even briefly, before submitting to the gateway. "Store" includes the inadvertent storage of CVV in a free-text claim note, a Slack message, an email attachment, or a call recording.

So PCI applies to most claims operations the moment they collect card data on any channel. The exceptions are narrow: if every payment leaves the claims handler entirely — a payment link emailed to the claimant which they complete on a hosted page, no card reading aloud, no IVR fallback, no "can you read me the digits if the link doesn't work" — then the claims handler isn't in scope. The moment your fallback option is the agent reading and typing, the agent and their environment are in scope and you're back at the full set of PCI requirements.

This is where the SAQ A conversation gets interesting. SAQ A is the short-form Self-Assessment Questionnaire for merchants who've outsourced the card-handling leg to a PCI-validated third party. It runs to 22 questions versus SAQ D's 300-plus. The PCI Council confirmed in v4.0.1 that a merchant can qualify for SAQ A even with telephone payments, provided the technical controls genuinely remove the merchant's systems from the cardholder data environment. That means call recording, CRM and the handler's own audio have to be demonstrably out of the card data path. Our SAQ A eligibility checklist walks through the exact criteria.

The four claims payment moments where PCI bites#

Inside a claims operation we typically see four distinct payment moments, and each one needs its own PCI answer. Treating them as one big "take a card payment" problem is how teams end up over-engineering the safe ones and under-protecting the risky ones.

The first is excess collection — the policyholder pays their excess before a repair, an inspection or a settlement. It's a relatively small ticket, often £100–£500, and it's usually unplanned (the customer didn't know they'd be paying when they picked up the phone). This is the highest-volume moment in a typical motor or property claims operation, and the one most often taken by voice.

The second is premium adjustments after a mid-term change — a new driver, a change of address, a vehicle upgrade. The customer is mid-policy, not mid-claim, but the same handlers often field these calls. The ticket size is variable. The third is salvage and recovery payments — a third party buying back a written-off vehicle, a contractor paying for materials advanced by the insurer. These are B2B-flavoured but still hit consumer cards often enough that the same PCI scope applies. The fourth is refunds, which mostly flow back to the original card on file via the gateway with no card data needed from the claimant — but become PCI-relevant when the original card has expired and the agent needs a new PAN.

For all four, the PCI-compliant answer is the same: the agent stays on the call, the customer enters their card details on their phone keypad, and the digits flow direct to the acquirer without touching the agent, the recording or the CRM. That's what DTMF masking does, and our DTMF masking solution page covers the technical detail. The claimant hears flat tones instead of digits, your agent hears the same flat tones, the call recording captures only flat tones, and the claim payment reconciles back to the claim reference in your platform.

SAQ A is the realistic 2026 target for insurance claims teams#

SAQ A is the prize. It's not a fiction — our customer base is dominated by contact-centre operators including insurers and brokers who run on SAQ A today after descoping. The reason it matters is workload: SAQ D requires you to evidence operating effectiveness of nearly the entire PCI DSS standard across firewalls, system hardening, vulnerability management, secure development, access control, monitoring, incident response and physical security. SAQ A skips most of that because none of it touches cardholder data in your environment.

The bar for SAQ A under v4.0.1 is roughly this: card data never enters your network. The audio path is masked. The CRM doesn't display PANs. Your screen-recording tool doesn't capture the payment screen (or there isn't one). The agent doesn't write PANs into any system. The acquirer or PCI-validated service provider receives the digits direct from the customer. You retain a tokenised reference — useful for reconciliation, refunds and recurring premium charges — but the underlying PAN lives in the service provider's vault. If you meet that bar, you're answering 22 questions, not 300.

The cost difference is meaningful. We've written up the realistic numbers in our cost of PCI compliance guide, but the short version: a claims operation on SAQ D typically spends £50k–£150k a year on PCI when you total up the QSA, the segmentation work, the staff time, the remediation, the policy updates and the annual penetration testing. The same operation on SAQ A spends a fraction of that — in many cases under £10k a year once the descoping is done. That's the commercial case for getting the technical architecture right.

What "in scope" actually means inside a claims platform#

Claims platforms — Guidewire ClaimCenter, Duck Creek Claims, Sapiens, Insurity, Salesforce Financial Services Cloud configured for claims, the in-house builds plenty of insurers still run — are usually fine from a PCI scope perspective on their own. They don't store PANs, they don't process card data, and they don't transmit it to acquirers. The PCI scope problem comes from the human and telephony layer wrapped around them, not the platform itself.

The bits that drag the platform back into scope are: free-text fields where an agent might paste a PAN into a claim note ("customer paid £250 excess on Visa 4485..."); case attachments with screenshots of payment confirmations that include partial or full PAN; email integrations where a customer emails their card details into a case (yes, customers still do this); and screen-recording or session-replay tools that capture the agent's screen including any payment entry form. Each of those is a leak that pulls the entire claims platform into your cardholder data environment, even if the platform itself was designed to stay out.

The fix isn't to rip out free-text fields — you need them for case notes. The fix is policy plus technical control: agents are trained never to write PANs into the platform, regex-based DLP scans free-text fields on save to catch accidents, and the payment flow itself is built so there's no PAN visible to the agent in the first place. Combined with masked audio capture, that takes the platform back out of scope. If you also use the platform for fraud screening on claims payments, our insurance fraud detection piece covers how to keep that work separated from PCI scope.

Reconciliation: how claims payments link back to the claim record#

One of the practical worries claims operations directors raise: "if my agents never see the card number, how do we reconcile a payment back to a claim?" Fair question, because reconciliation is non-negotiable — finance needs to match cash to claim reference, and the platform needs the payment recorded against the case for the customer's next interaction.

The answer is the claim reference travels with the payment. When the agent triggers the secure payment flow, they pass the claim number (or policy number, or both) as metadata. The acquirer captures the payment with that reference attached. The confirmation comes back — success or fail, transaction ID, last four digits, card type, no PAN — and writes against the case in the claims platform via API. The reconciliation file from the acquirer at end-of-day matches claim reference to transaction amount, which finance loves because it removes the manual matching they used to do against partial PANs in spreadsheets.

For refunds and recurring premium changes, the same architecture works in reverse. The original payment generated a token (an alphanumeric reference that means nothing outside the acquirer's vault but maps back to the original PAN). The agent triggers a refund or a top-up charge using the token, not the card number. The customer doesn't need to read their card again. The token lives in your environment — useful for finance, useless to an attacker — and the actual card data lives in the acquirer's PCI-validated vault. Tokenisation is what makes this whole pattern work, and our piece on claims payment integration walks through the API specifics.

Call recording: the place most claims operations leak#

Call recording is the single most common PCI failure mode we see in insurance claims operations. The pattern is depressingly consistent: the operation has invested in DTMF masking or a hosted payment link to keep audio clean during payment — but then their call recording platform (NICE, Verint, Calabrio, an Avaya integration) captures the audio before the masking takes effect, or the masking pauses recording for the wrong window, or the agent reads back the last four digits aloud and the operation didn't realise the last four are still partial PAN under the standard.

The clean architecture is: the masking happens at the carrier level, before the audio reaches your recording platform at all. Your recording platform receives audio with flat tones already substituted. You don't trust the recording vendor to pause and resume — you remove the cardholder data from the audio stream entirely before it gets there. That way it doesn't matter what the recording vendor does next, because there's no card data in the stream for them to mishandle.

The same logic applies to screen recording. If your QA team uses screen recording for agent coaching, the screen-recording tool needs to be aware of the payment flow and stop capturing the agent's screen for the duration of the payment — or, better, the payment flow needs to never show the PAN on the agent's screen in the first place. Our pause-and-resume glossary entry covers why "pause and resume" alone is no longer considered sufficient by most acquirers, and why upstream masking has become the expected control.

MFA, access control and the bits of v4.0.1 that still apply on SAQ A#

SAQ A drops most of the PCI control surface, but it doesn't drop everything. There's a short list of controls that apply even to outsourced merchants, and they hit insurance claims teams in specific ways. The big one is multi-factor authentication for any administrative access into the systems that touch the payment flow — your agent desktop, your telephony admin console, your service-provider portal. MFA isn't new, but v4.0.1 tightened the rules around shared accounts and role-based credentials.

Practical translation for a claims operation: the supervisor account that lets a team leader retrieve a recording, refund a payment or change an agent's permissions must be MFA-protected and individually attributed. Shared "supervisor" logins are out. The reporting account your finance team uses to pull reconciliation files from the acquirer portal is similarly individually attributed and MFA-protected. The same goes for any "break-glass" account you keep for the rare case of a manually-keyed payment — if that account exists, the assessor will want to see when it was last used and by whom.

The other v4.0.1 area that catches insurance teams out is script integrity on any customer-facing payment page. If you offer a payment link as a fallback to the voice flow, the page the claimant lands on falls under Requirement 6.4.3 — every third-party script on that page must be inventoried and integrity-checked. Most insurers fail this on their general-purpose web pages because of analytics, tag managers and chat widgets. The fix is to host the payment page somewhere clean: either with your PCI-validated service provider, or on a sub-domain that's stripped of all the marketing scripts your main site runs.

The PCI DSS 4.0.1 changes that hit claims operations hardest#

PCI DSS v4.0.1 is the current version. v3.2.1 retired in March 2024 and v4.0's future-dated requirements became mandatory in March 2025. For a claims operation renewing compliance in 2026, the assessor is judging against v4.0.1 outright. There's no transition window left.

Three v4.0.1 areas typically catch claims teams: the targeted risk analysis requirement, which says that for any control where you've adopted the "customised approach" (rather than the prescriptive default) you have to document a formal risk analysis showing your control achieves the same security outcome; the script integrity rules under 6.4.3 mentioned above; and the authentication tightening in Requirement 8, which includes the MFA changes and a new minimum password length of 12 characters (up from 7).

None of those are deal-breakers on their own. They become deal-breakers when a claims operation tries to stay on SAQ D and run their own cardholder data environment — because suddenly the risk analyses, the script inventories and the access reviews are a meaningful chunk of work, year on year. The same controls on SAQ A are a tenth of the effort. That's why the descoping conversation always comes back to the same answer for claims: take the audio out of scope and you take most of v4.0.1 off your desk.

Vendor responsibility matrices: the document your QSA will ask for#

If you outsource the card-handling leg to a PCI-validated service provider, you need a written responsibility matrix that says "these controls are theirs, these are ours, these are shared." The Council formalised this expectation in v4.0 and your QSA will ask for it on day one of the assessment. It's not a hard document to produce — your service provider should give you a draft, and you adjust it to reflect what your operation actually does — but a lot of insurance teams haven't got round to writing one and it slows the assessment.

The matrix should cover each of the 12 PCI requirements and for each one nominate which party owns the control. For an insurance claims operation using a descoped voice payment flow, the service provider will typically own most of Requirements 1–6 and 9–11 because the cardholder data environment is theirs. You'll own most of Requirements 7, 8 and 12 because those are about your people, your access control and your policies. Requirements 3 (data protection) and 4 (encryption in transit) are usually shared because some of the technical work is theirs and some is yours.

The matrix is also useful internally. It gives your IT and compliance teams a single document that answers "who's responsible for this control?" when a question comes up mid-year. We provide a template matrix to every Paytia customer at onboarding because it removes a chunk of friction in the first QSA visit.

Common mistakes we see in insurance claims PCI projects#

Three mistakes come up repeatedly. The first is treating PCI as an IT problem when it's really a contact-centre operations problem. The technical work is one component, but the harder bit is the agent workflow change — retraining handlers who've been reading card numbers aloud for years, updating call scripts, removing the "can you just give me the long number on the front of your card" muscle memory. A claims operation that gets the technology right but doesn't address the human workflow ends up with a partial solution: the masked payment flow works, but agents revert to reading PANs aloud when the flow occasionally fails, and the recording captures it.

The second mistake is over-trusting the existing telephony vendor. Avaya, Genesys, Cisco — each has a "PCI module" of some flavour. Some of them are genuinely PCI-validated as service providers, some aren't. The pattern we see most often is the telephony vendor saying "we support PCI" (true — they have a feature) and the insurer assuming that means they're descoped (not necessarily true — depends on how the feature is implemented and whether the vendor is on the PCI Council's registered list of service providers). Always check the AOC (Attestation of Compliance). If the vendor can't give you one, they're not a PCI-validated service provider, regardless of what the sales deck says.

The third mistake is letting the project drag. We've seen insurance claims PCI descoping projects stretch to nine months because the operation tries to handle every edge case before going live with anything. The faster pattern: pick the highest-volume payment moment (usually excess collection), implement the descoped flow for that moment first, prove it works, then roll the same pattern to the other moments. Six weeks to first live payment is achievable. Nine months to nothing is also achievable, and a lot more common.

What insurance claims operations look like on the other side#

For context on what "done" looks like: a typical mid-sized UK insurer running 100 claims handlers, taking around 8,000 voice card payments a month (excess, premium adjustment, salvage), can move from SAQ D to SAQ A in eight to twelve weeks. The agent workflow looks identical to the customer (they're still on a call with a handler, the handler still asks for payment, the handler still confirms when payment lands) but is fundamentally different from a PCI standpoint. The audio path is masked. The CRM doesn't display PANs. Call recordings are clean. Screen recordings are clean. The handler never sees the card number at any point.

The annual compliance cost drops by roughly the difference between SAQ D and SAQ A: in our customer base, typically a 70–85% reduction once the QSA, segmentation costs and remediation cycles are accounted for. The conversion rate on payment attempts usually goes up rather than down, because the customer types their own card on their own phone (a familiar action) rather than reading it aloud (which they often don't enjoy, particularly for higher-value excess payments). The agent's average handle time on the payment leg drops by around 30–60 seconds because the read-back-and-retype loop is gone.

Pinnacle Group cut their PCI scope by 95% with this pattern — they're not insurance but the architecture is identical. Several of our insurance clients have done the same. The pattern is repeatable because the underlying problem (handler-mediated voice payment) is the same problem across industries; insurance just has more of those payment moments per agent than most.

IVR and self-service: where claims operations get tempted to over-engineer#

A reasonable question we hear: "why not just push everything to an IVR — let the customer call a number, key their claim reference, key their card, done?" The answer depends on what kind of payment moment you're solving. For predictable, planned payments — recurring premium charges where the customer knows the amount and the reference in advance — IVR is fine, and it genuinely removes the agent from the flow. For unplanned, in-call payments triggered mid-conversation, IVR adds friction without solving the PCI problem any better than in-call masking does.

The trap is the transfer step. If the agent transfers the customer to an IVR mid-call, the customer has to re-establish context: which claim, which excess, which case reference. They often drop off or call back, and your conversion rate on payments dips. The in-call masking pattern avoids this by keeping the agent on the line throughout — the customer pays without leaving the conversation, the agent confirms the payment landed, and the call closes cleanly. For self-service payments ("customer pays online or via app whenever they want") the answer is a hosted payment page or a payment link sent by SMS, both of which keep PCI scope clean and don't require a live agent at all.

Some claims operations end up with a mixed model: in-call masking for excess and salvage payments, IVR for recurring premiums, payment links for delayed payments where the customer needs time to find their card or get a partner's authorisation. All three are PCI-compliant if implemented correctly, and they cover the realistic spectrum of claims payment moments. The thing they share is that none of them put cardholder data through your CRM, your claims platform or your agent's audio path.

How acquirer choice affects PCI compliance insurance claims architecture#

Your choice of acquirer (Worldpay, Adyen, Stripe, Barclaycard, Elavon and the rest) doesn't change whether you need PCI compliance — you always do — but it does change the integration shape. Some acquirers offer their own descoping flows. Others rely on a service provider in front of them. Some have direct integrations with major claims platforms, others don't. Insurance teams renewing their acquirer contract sometimes assume the acquirer will sort PCI for them, and then discover the acquirer's PCI offering covers only the cardholder data handover, not the agent workflow side.

The clean architecture treats the acquirer as the destination for tokens and the source of reconciliation files, and uses a PCI-validated service provider (like Paytia) for the agent-facing workflow. The acquirer doesn't have to know or care that the card data is reaching them via a masked voice flow rather than a card-present terminal. The service provider produces the AOC that lets your claims operation file SAQ A. The acquirer produces the reconciliation files that let your finance team match payments to claims.

If you're mid-procurement on either layer, the practical advice is: lock in the descoped workflow first (the service provider), then choose the acquirer based on commercial terms and integration fit. Acquirer switching is rare and painful once it's done; service provider integrations are designed to be acquirer-agnostic and you can change one without forcing a change to the other. Stripe is the only acquirer we publicly state we're partnered with — our wider documentation covers the integration patterns for the others on a case-by-case basis.

What changes when claims payments cross borders#

International claims operations — UK insurers handling EU policyholders, US claims with global SOS components, travel insurance with point-of-loss payments in any country — add a layer to PCI thinking. The PCI standard itself is global; the AOC from a PCI-validated service provider is recognised by acquirers worldwide. The complication is the data residency question that often gets bundled with PCI in customer conversations: "is our card data leaving the UK?"

For pure PCI purposes, the answer is that card data location is governed by your service provider's vault location, not by your CRM or claims platform location. If your service provider operates UK or EU data centres, the card data stays there, regardless of where your agent is sitting or where the policyholder is calling from. That matters for GDPR-aligned customer communications and for regulated insurance lines that have data-residency clauses — but it doesn't change the PCI scope question. PCI scope is about your network and your systems, not the geographic location of the encrypted card data.

The cross-border case where things get interesting is when claims handlers in one country handle payments for policyholders in another, with reconciliation flowing to a finance team in a third. The service provider sees that as a single payment flow with metadata about the parties involved. Your operations team sees it as three locations needing coordinated reporting. The reconciliation file format and the timezone alignment usually matter more than the PCI question — but it's the PCI question that comes up first in vendor selection. A simple rule of thumb: if your service provider can produce a single AOC covering all the geographies your claims team operates in, you've got one less compliance project per region.

The 12-month PCI calendar for an insurance claims operation#

For a descoped claims operation on SAQ A, the realistic PCI calendar across a year is lighter than most teams expect. It looks roughly like this. Q1: review the responsibility matrix with your service provider, confirm nothing changed in their AOC (services covered, validation date, listing on the PCI Council's registered service providers list). Update your own internal documentation if any of that shifted.

Q2: refresh agent training on the payment workflow — particularly the never-write-PANs-in-the-CRM rule. This is also a good moment to audit your claims platform for any new free-text fields that might have been added during the year and could become PAN-pasting hotspots. New starters who joined since the last refresh need the full induction; existing handlers need a 30-minute refresher.

Q3: dry-run the SAQ A questions with your compliance lead. There are 22 of them; none of them are gotchas if your architecture is right; the answers should mostly be "yes, here's the evidence" with a couple of "not applicable" for controls that genuinely don't apply. If any answer is uncertain, you've got a quarter to fix it before the formal filing window.

Q4: file SAQ A with your acquirer, submit the AOC from your service provider as supporting evidence, and renew. Total internal time across the year: typically 10-15 working days spread across the four quarters, which is a long way from the 80-120 days a typical SAQ D operation spends. The reduction in workload is most of the commercial argument for descoping, alongside the direct reduction in QSA fees.

Next steps#

If you're running an insurance claims operation that takes voice card payments, the first move is mapping which of the four claims payment moments your team actually handles, on which channels, and where the card data goes today. That's a half-day exercise and it usually surfaces one or two scope leaks the compliance team didn't know about. We can run that mapping with you on a discovery call — book a conversation with us via the contact page and we'll pull together a scoped proposal within a week. If you want to see the descoped voice flow in action before the conversation, the live demo shows the customer experience and the agent experience side-by-side with the audio masked in real time.