Under PCI DSS v4.0.1, a call centre takes card numbers by phone: which systems are in scope, and what must segmentation prove?
answer
- store, process, transmit, or impact
- unrestricted connectivity joins the CDE
- voice paths and recordings count
- could not impact even if compromised
- pen test segmentation every 12 months
basics
~20 sUnder PCI DSS v4.0.1, scope covers systems that store, process or transmit card data, anything with unrestricted connectivity to them, and anything that could impact them. Segmentation removes a system only if its compromise could not impact card data.
solid answer
~50 sPCI DSS v4.0.1 scopes the **CDE**: system components, people and processes that store, process or transmit CHD or SAD, plus components with unrestricted connectivity to them, and additionally anything that could impact their security. For a call centre that means agent desktops where PANs are keyed, the VoIP devices and telephony servers carrying the calls, call recordings (audio is storage), and the authentication, logging and admin systems around them. Segmentation is **not required**, but without it the whole flat network is in scope. To take a system out, it must be isolated so that even if compromised it could not impact card data security; the entity documents that justification in its scope confirmation (Requirement 12.5.2, at least every 12 months) and penetration-tests the segmentation at least every 12 months and after changes (11.4.5; six months for service providers under 11.4.6).
go deeper
Recall the three ways a system enters scope: it touches card data, it has unrestricted connectivity to something that does, or it could impact its security.
Walk a call centre's data flow and place each component, including telephony and recordings, and explain what segmentation must demonstrate to remove a system.
Expect scope creep: pasted PANs, recordings with codes, new tooling. Show how the 12.5.2 confirmation and 11.4.5 penetration tests catch it before the assessor does.
Argue scope reduction as a business case: removing the PAN from the agent path may cost more up front but shrinks every recurring assessment and the blast radius of a breach.
## The scoping rule in PCI DSS v4.0.1 Section 4 of **PCI DSS v4.0.1** defines what the requirements apply to. Two groups are in scope: 1. **The cardholder data environment (CDE)**, which is made of - system components, people and processes that **store, process or transmit** cardholder data (CHD) or sensitive authentication data (SAD), and - system components that do none of that but have **unrestricted connectivity** to components that do. 2. **Anything that could impact the security** of CHD or SAD, even if it never sees a card number - authentication servers, logging servers, remote-access servers, name resolution and the tools that deploy to the CDE. "System components" is deliberately broad: the standard lists network devices including **VoIP network devices**, servers, end-user devices, virtual and cloud components, software, and **storage of account data in any format**, naming paper, data files and **audio files**. ## Applying it to a call centre A telephone order desk is a card-not-present channel, and the standard says those channels must be evaluated and protected. Walk the data flow the caller's card number takes: | Component | Why it is in scope | |---|---| | Agent workstation and the order application | The agent keys the PAN: it processes and transmits CHD | | Telephony servers, VoIP phones and voice network | The spoken PAN transits them: they transmit CHD | | Call recordings and their storage | Audio files are storage of account data | | Directory, MFA, logging and patching servers | They could impact the security of the CDE | | Admin workstations for any of the above | Connected to, or able to impact, the CDE | Recordings deserve special care. The guidance to **Requirement 3.2.1** names audio recordings among the storage locations that are often overlooked, and **Requirement 3.3.1.2** says the card verification code is not stored after authorization - so a recording that keeps the spoken code after authorization violates it, and Requirement 3.3.1 adds that encryption does not change this. If card numbers arrive through a channel never meant for them - a chat window, an email - the standard gives two options: bring the channel into the CDE and secure it, or securely delete the data and stop the channel being used that way again. ## Shrinking scope The strongest scope reduction is **keeping the PAN away from people and systems** in the first place. A common design has the caller key digits on the phone keypad into a third-party service provider's system, so neither the agent's desktop nor the recording ever holds the PAN. The standard's rule still decides the outcome: a system that no longer stores, processes or transmits the PAN leaves the CDE only if it also lacks unrestricted connectivity to it and could not impact it. The merchant keeps its **Requirement 12.8** duties to manage that provider, including the record of which requirements each party owns (12.8.5). ## What segmentation must prove - **It is optional.** Segmentation of the CDE "is not a PCI DSS requirement", but without adequate segmentation - a *flat network* - the entire network is in scope. - **The test is impact, not location.** A component is out of scope only if properly isolated so it "could not impact the security" of CHD or SAD **even if that component was compromised**. A separate VLAN or subnet on its own proves nothing. - **The assessor must verify it.** If segmentation is used to reduce scope, the assessor must verify that it is adequate. - **It is tested.** **Requirement 11.4.5**: penetration tests on segmentation controls at least once every 12 months and after any change to segmentation controls or methods, covering all of them and confirming they isolate the CDE from all out-of-scope systems. **Requirement 11.4.6** raises this to at least once every six months for service providers. - **It is documented.** **Requirement 12.5.2**: the entity confirms its scope at least once every 12 months and upon significant change, identifying data flows, account-data locations, every segmentation control and the justification for each environment being out of scope; service providers do this every six months (12.5.2.1). How to *build* the segmentation - firewall rules, microsegmentation, allow-lists - is network engineering and belongs outside this question; PCI DSS cares about the proof.
- Under PCI DSS v4.0.1, does a separate VLAN for the agent floor take the corporate network out of scope?Not by itself. Out of scope requires that a component could not impact CHD or SAD security even if compromised, and the assessor must verify the segmentation is adequate. A VLAN with open routes into the CDE fails that test. Whatever isolates it must be penetration-tested under 11.4.5 and justified in the 12.5.2 scope confirmation.
- Under PCI DSS v4.0.1, what happens to scope if agents paste card numbers into a ticketing tool?The ticketing tool now stores the PAN, so it joins the CDE, along with anything connected to it without restriction. The entity can either secure it to PCI DSS or securely delete the data and stop that use. The annual 12.5.2 confirmation exists to find such locations outside the defined CDE.
Scoping a call centre is like deciding who needs a security badge in a bank vault: not only the tellers who touch cash, but anyone who holds a door key, runs the cameras or can open the ventilation shaft. A wall only counts if nobody on the other side could open it.
saying these in an interview costs you the question
- Systems that never store card numbers are automatically out of PCI DSS scope.
- Putting the CDE in its own VLAN is enough to scope out the rest of the network.
- PCI DSS requires every merchant to segment its cardholder data environment.
- Call recordings are fine to keep because audio is not structured data.
- Segmentation is proven once at the first assessment and never retested.