Every agent who hears a card number, and every system that touches one, has to meet PCI DSS. In a contact center that can mean hundreds of desktops, a phone platform, call recorders, speech analytics and home offices. Descoping shrinks that list by keeping card data out of the contact center entirely. This checklist walks through the work in the order most teams do it.
What is PCI DSS descoping?
PCI DSS descoping is the practice of removing payment card data from as many people, processes and systems as possible, so fewer of them fall under PCI DSS requirements. A system is in scope if it stores, processes or transmits cardholder data, or if it connects to or can affect the security of systems that do.
Encryption alone does not descope a system. PCI DSS v4.0.1 states that encryption "is generally insufficient to render the cardholder data out of scope" when the environment can still reach the data or the keys (PCI DSS v4.0.1). Real descoping means the card data never arrives.
Why descope instead of securing everything?
Descoping is usually cheaper and safer than bringing every agent, desktop and recorder up to PCI DSS, because each in-scope component needs its own controls, evidence and testing. Since 31 March 2025, the 51 future-dated requirements in PCI DSS v4.x are in force (PCI SSC). One example is multi-factor authentication for all access into the cardholder data environment, Requirement 8.4.2 (PCI SSC summary of changes). Every system you remove from scope is one less system to cover.
Remote and hybrid agents make the case stronger. A home office with a card number on a sticky note or a smart speaker in the room is hard to audit. A home office where card data never reaches the agent is much easier.
The contact center descoping checklist
Work through these steps in order. Each one builds on the one before.
1. Map every path card data takes
List every way a card number can enter your operation: phone calls, IVR, voicemail, chat, email, web forms, SMS and paper. For each one, note who hears or sees the data and which systems capture it, including the ACD, softphones, call recorders, quality monitoring tools, speech analytics, transcription, CRM notes and screen recordings.
2. Choose how card data will bypass the contact center
Pick a method that sends card details straight to a PCI-validated service provider:
- Automated IVR payment. The caller pays in self-service, before or instead of talking to an agent.
- Transfer to IVR. The agent hands the caller to a payment IVR, which returns the caller or ends the call.
- Agent-assisted DTMF masking. The agent stays on the line while the caller keys digits that reach the agent only as flat tones.
Pause and resume recording is not a descoping method. PCI SSC notes that with pause and resume "the agent will hear all of the CHD and SAD" (PCI SSC telephone guidance).
3. Confirm masking covers every tone
If you use DTMF masking, test for "DTMF bleed," where the first part of a tone passes through before masking begins. PCI SSC says a masking solution must make sure no part of the original tones reaches the environment, and that replacement tones must not be linked to the original digits (PCI SSC telephone guidance). The agent's screen should show only placeholder characters, such as asterisks, while the caller types.
4. Stop spoken card numbers
Prompt callers to key card numbers instead of saying them. Script agents to stop a caller who starts reading a card aloud and move them to the secure method. If you use speech recognition for card entry, the transcripts and audio it produces need the same review as recordings.
5. Clean recordings, transcripts and logs
PCI DSS forbids keeping sensitive authentication data, including the card security code, after authorization, "even if encrypted" (Requirement 3.3.1). Search existing recordings, transcripts and IVR logs for card data, decide how to remove it, and set retention rules so new captures cannot pile up.
6. Segment what remains
Systems that still handle card data, or that connect to systems that do, stay in scope. Separate them from the rest of the network so the boundary is clear. PCI SSC's scoping and network segmentation guidance in the Document Library explains how assessors judge segmentation.
7. Get your provider's attestation and responsibility matrix
Requirement 12.8 covers managing third-party service providers. Collect each payment provider's Attestation of Compliance, confirm it covers the services you use, and keep a written split of which requirements the provider meets and which stay with you.
8. Train agents and write the exception process
Agents need to know what to do when a caller reads a card number aloud, emails a card image or asks the agent to "just type it in." Write the steps down, include them in training and review them with your QA team.
9. Test before launch and after every change
Place test calls with test card numbers, never real ones. Then check recordings, transcripts, desktop screens and logs to confirm no card data appears. Repeat after any change to the call flow, telephony, recording settings or integrations. Our guide to IVR testing and monitoring covers automated test calls.
10. Confirm your scope every 12 months
PCI DSS v4.x requires merchants to document and confirm their PCI DSS scope at least every 12 months and after significant changes (Requirement 12.5.2, per the PCI SSC summary of changes). Put the review on the calendar and repeat step 1 each time.
What stays in scope after descoping?
Descoping reduces your PCI DSS obligations but does not remove them. Your acquiring bank still decides how you validate compliance (PCI SSC).
| Component | Typical status after descoping | Why |
|---|---|---|
| Agent desktops and CRM | Can be out of scope | No card data is displayed, typed or stored |
| Phone system and call recorders | Can be out of scope for data storage | Only flat tones pass through, though connected systems may still face some requirements |
| Payment IVR or masking service | In scope, managed by the provider | It receives and transmits card data |
| Systems that connect to the payment service | Usually in scope | Connected-to systems can affect card data security |
| Policies, training and vendor oversight | Always in scope | These requirements apply to every merchant |
PCI SSC's telephone guidance notes that recording systems holding only flat tones may still be in scope for other requirements if they connect to systems where cardholder data is present (PCI SSC telephone guidance). Confirm the final picture with your Qualified Security Assessor.
How Plum Voice supports a descoped payment flow
Plum Voice runs payment applications built in Plum Fuse or Plum DEV on PCI-compliant servers, on a network separate from its non-PCI servers (Plum docs). Card data goes from the caller to the IVR and on to your processor over HTTPS, and Plum does not store caller financial data (Plum docs). Fuse's "Private" setting keeps sensitive input out of logs and reports (Plum docs), and Plum's customer responsibility matrix shows which controls stay with you.
For the full picture of automated phone payments, read IVR payments: how pay-by-phone works and stays PCI compliant, or see the payment processing use case.