PCI DSS inside an Indian contact centre or BPO

If your agents take card numbers over the phone on somebody else's behalf, PCI DSS reaches you as a third-party service provider, not as a merchant. Three consequences recur in Indian contact centres and BPOs. The segmentation test is scheduled annually when Requirement 11.4.6 asks for six months. An Attestation of Compliance is sent to a client in the belief that it satisfies Requirement 12.9.1, which it explicitly does not. And a recording carrying an audible PAN, or an unsuppressed DTMF tone, is managed as a quality-assurance asset rather than as stored cardholder data.

The standard names you

You do not have to infer your status. The examples under Requirement 12.8.1 list third-party service providers that "Manage system components included in the entity's PCI DSS assessment (such as providers of network security control services … contact and call centers; web-hosting companies; and IaaS, PaaS, SaaS, and FaaS cloud providers)."

Your obligations arrive by contract, not from a payment brand. No card scheme will tell you your level or your deadline; your client's acquirer sets both and passes them down, which is why who assigns your level is worth settling before you accept a date. If the client is an RBI-regulated payment aggregator, its own audit obligations travel down the same contract — see PCI DSS and the RBI Payment Aggregator Directions.

Subcontracted rather than engaged directly, you are a nested provider. Requirement 12.8.5's guidance is explicit: "it is the responsibility of the primary TPSP to manage and monitor any secondary TPSPs." Contractually the primary's burden; practically, the evidence request lands on you, on their timetable.

And where the acquirer permits self-assessment, the choice is already made: "For service providers eligible to conduct a self-assessment, the only applicable SAQ is SAQ D for Service Providers." The SAQ eligibility table closes every other door.

Everything moves onto a six-month clock

Requirement 11.4.5 sets the general floor at 12 months. Requirement 11.4.6 is the service-provider addition and it halves the interval — "At least once every six months and after any changes to segmentation controls/methods." The Council's stated reason reads like a description of a BPO: "The probability of segmentation controls failing in complex and dynamic networks is greater in service-provider environments."

The change clause bites harder than the calendar. Campaigns are won and lost, agent VLANs are cut and re-cut, a seasonal ramp puts 200 temporary seats on a floor scoped for 60. Each is a change to segmentation controls or methods, and each restarts the clock.

Run one platform across several clients and Appendix A1 attaches too: A1.1.4 requires logical separation between customer environments to be confirmed six-monthly by penetration testing, "in addition to the penetration tests specified in Requirement 11.4.6." The matching duty to let customers test you is Requirement 11.4.7.

On who may perform any of it, the standard uses one sentence and repeats it: the testing is "Performed by a qualified internal resource or qualified external third party" and "Organizational independence of the tester exists (not required to be a QSA or ASV)."

The responsibility matrix, and the thing it is not

Requirement 12.9.2 obliges you, on customer request, to supply your compliance status and information about which requirements are yours, which are the customer's and which are shared. The instrument is a responsibility matrix, and the guidance is specific about granularity: for shared items the customer must understand "specifics about how the requirements are shared and which entity is responsible for meeting each sub-requirement." Requirement 8, split between your agent identities and the client's application accounts, is several matrix lines; "Requirement 8 — shared" is a gap with a tick next to it.

Requirement 12.9.1 is a different artefact, and the one most often assumed to be covered already: written agreements to customers acknowledging your responsibility for the security of account data you hold or could affect. Its applicability note closes the shortcut in terms — "a PCI DSS Attestation of Compliance (AOC), a declaration on a company's website, a policy statement, a responsibility matrix, or other evidence not included in a written agreement is not a written acknowledgment."

The teeth are on the client's side. Under Requirement 12.8.4's applicability note, "If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also 'not in place' for the entity." A gap on your floor is a gap in their assessment — which is why their assessor wants evidence, not assurances.

A call recording is a storage location

PCI DSS puts in scope the "Storage of account data in any format (for example, paper, data files, audio files, images, and video recordings)", and the guidance under Requirement 3.2.1 says it again from the other side: "Storage locations that are often overlooked include … paper-based media, and audio recordings."

The card verification code cannot survive the call. Requirement 3.3.1.2: "The card verification code is not stored upon completion of the authorization process." It "is not eligible for the customised approach", so there is no alternative-control route to a design that keeps it. And 3.3.2's applicability note removes the other escape: "This requirement applies to all storage of SAD, even if no PAN is present in the environment." A clip capturing nothing but three spoken digits is stored sensitive authentication data.

DTMF is not a masking control. A DTMF digit is a pair of audible tones mapped to a keypad key, so a recording of the tones is a recording of the digits, recoverable with software anyone can download. If suppression runs on the primary recorder but not on the QA stream, the speech-analytics feed or the dispute-evidence export, the digits are in the archive. If it depends on an agent pressing a button, it fails at whatever rate agents forget.

The archive is the part most programmes find. The copies are what six-monthly scope confirmation exists to find: QA samples on a shared drive, recordings attached to chargeback correspondence, transcripts — a transcript of a read-back is the PAN in text — and anything a home-working agent can pull down. Requirement 3.4.2 governs that last one — "technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need" — and names the technology: "A virtual desktop is an example of a remote-access technology." Mandatory since 31 March 2025.

One point runs the other way. The glossary definition of a sensitive area — the trigger for the heavier physical controls at 9.2.1.1 and 9.3.1.1 — excludes "the areas where only point-of-sale terminals are present, such as the cashier areas in a retail store or call centers where agents are taking payments." The agent floor is inside the cardholder data environment; on this wording it is not, by that fact alone, a sensitive area, which puts individual entry and exit monitoring on the rooms housing the telephony, recording and CDE infrastructure instead. Few claim it. Put it to your assessor as a documented scoping position rather than finding the disagreement in the report.

What it has to look like as evidence

Two dated segmentation tests a year, each covering every segmentation control in use and confirming isolation from all out-of-scope systems. A change log showing the tests campaign changes triggered, not only the ones the calendar did. A scope confirmation on the same cadence. A matrix at sub-requirement level. A data-flow map treating the recording platform, its archive and every downstream consumer as account data stores. The gaps that get a report sent back are almost always scope gaps, not testing gaps.

Security Brigade runs Requirement 11.4 and segmentation testing on the six-month service-provider cadence, packaged as evidence your assessor can rely on.