DPDP for IT Services and BPOs: Where the Exemption Ends and the Real Work Begins
The first DPDP question a delivery centre faces rarely comes from a regulator. It comes from a client's vendor-risk team, and it is usually one line long.
It lands on a Monday. A client in Chicago, with 900 seats of your voice and chat support, has asked every Indian supplier to confirm how India's new data protection law affects the services you provide. The delivery head forwards it to Legal. Legal replies in four words: "We're exempt. Section 17."
That answer is half right, which is the most dangerous kind of right.
I have spent a long career on operations floors, running processes, sitting through client audits, and answering security questionnaires at 11 p.m. before a steering committee. Compliance programmes in this industry rarely fail because someone misread the statute. They fail because the floor was never part of the conversation. This article walks through what the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 actually say for IT services and BPO businesses, where the real challenges sit, and what to do about them.
Why this law lands differently on a delivery floor
Most industries hold personal data as a by-product. Ours holds it as the product. A 500-seat process touches thousands of individuals a day through voice, chat, email, screens, recordings and ticket notes, across three shifts, with attrition high enough that a meaningful share of the people holding that data will have left within the year. Add client-mandated tools, seat-leasing partners and hybrid work, and data travels everywhere the operation travels.
Parliament did notice this. The Act carries a specific carve-out for outsourcing. But the carve-out is narrower than the hallway version of it, and the parts it leaves untouched are exactly the parts clients examine.
You are three different entities under one roof
The Act sorts everyone into three roles. The Data Principal is the individual. The Data Fiduciary decides why and how personal data is processed. The Data Processor processes it on a fiduciary's behalf. A BPO is rarely just one of these.
| Data stream | Whose data | Your role | What applies |
|---|---|---|---|
| Overseas client's customers | Individuals outside India, processed under a contract with a person outside India | Processor to an overseas client | Outsourcing exemption in Section 17(1)(d). Sections 8(1) and 8(5) stay; most other duties switch off |
| Indian client's customers (bank, telco, insurer, retailer) | Individuals in India | Processor to an Indian Data Fiduciary | Client needs a valid contract (Section 8(2)) and remains answerable; safeguards, breach and deletion duties flow down to you |
| Your employees, candidates, contractors, visitors | People in India | Data Fiduciary | The full Act applies |
| Your prospects, client contacts, website visitors | Mixed | Data Fiduciary | The full Act applies to data of people in India |
Most delivery heads think about the first row. Most of the exposure sits in the other three.
The phrase I hear most in steering meetings is "we're only a processor." It is true for client data and false for your own workforce, your candidate pipeline and your marketing list. Those belong to you, and the Act treats you accordingly.
The outsourcing exemption: read the whole sentence
Section 17(1)(d) disapplies a large block of the Act where personal data of individuals outside India is processed in India under a contract with a person outside India. Specifically, it switches off Chapter II (grounds, notice, consent, accuracy, erasure, breach intimation, children's data, Significant Data Fiduciary duties), Chapter III (data principal rights and grievance) and the cross-border rules in Section 16. It carves two provisions back in: Section 8(1) and Section 8(5).

Five catches, each of which I have seen trip up a capable team:
- Both conditions must be true. The individuals must be outside India and the contract must be with a person outside India. Miss either and the exemption is gone.
- Mixed processes leak. A campaign dialling US numbers will still reach some NRIs living in India. A global client's India customers sit outside the exemption entirely. Segregate by data subject location, not by client name.
- Section 8(5) survives. Reasonable security safeguards remain your obligation, and that carries the highest penalty ceiling in the Act.
- Your client's own law still travels by contract. GDPR, CCPA, HIPAA and PCI DSS obligations arrive through the master services agreement. The Indian exemption does not excuse any of them.
- Interpretation is unsettled in places. Commentators differ on how far breach and processor-governance duties reach the exempt stream, and on how liability splits between an Indian processor and an overseas client. Behave as though they apply.
The calendar, and the one already running
The Rules were notified on 13 November 2025, and the Data Protection Board is already constituted. Consent Manager provisions apply from 13 November 2026. The substantive obligations (notice, consent, security safeguards, breach intimation, retention, rights) apply from 13 May 2027, roughly six and a half months from today.

Meanwhile, CERT-In's 2022 directions on six-hour incident reporting and 180-day log retention are already live, and clients are already rewriting contracts. For a BPO, the commercial deadline passed some time ago. The statutory one is the second deadline, not the first.
What clients will ask you, starting now
Whatever the statute says, the questions are already arriving, and they are practical. Which of our data streams do you treat as exempt, and on what basis? Where do recordings and transcripts sit, and for how long? Who are your sub-processors, and where do they operate? How quickly will you tell us about an incident, and who will make the call? Can you show access reviews from the last quarter? What happens to our data, including backups, when the contract ends? None of these needs a law degree to answer. All of them need dated evidence.
Seven real challenges from the floor
Here is where data actually lives in a delivery operation, and where each stage collides with the law.

1. The agent desktop sees everything, and everyone knows it
A customer reads out a card number, a date of birth, a diagnosis. The agent types it into a free-text notes field because the form has no better place. Every veteran has seen this, and the fix is not a policy circular. Rule 6 names the controls that "reasonable security safeguards" are expected to include: encryption, obfuscation or masking, access control, logging and monitoring, and tested backups. On the floor that means masked fields by default, pause-and-resume payment capture so card digits never reach the agent, role-based screens, no personal phones on the production floor, and a work-from-home set-up that does not turn every kitchen table into a data centre. Section 8(5) survives the exemption, so this is where your exposure concentrates.
2. Recordings, transcripts and the retention collision
Call content is the most sensitive and most over-kept asset in the building. Recordings are retained "in case of a dispute" with no end date, and QA exports sit in spreadsheets long after the audit that needed them. DPDP pulls in two directions at once, and CERT-In adds a third.
| Source | What it asks | Practical result |
|---|---|---|
| Section 8(7) and Rule 8 | Erase personal data once the purpose is served, unless law requires retention | No recordings kept "just in case" |
| Rule 6 (log retention) | Keep logs, and associated personal data, for one year unless other law says otherwise | Twelve months of access and activity logs |
| CERT-In directions, 2022 | Keep ICT system logs for 180 days, within India | Hold whichever period is longer for logs |
| Client contract | Often a fixed, short window for call content | The contract period governs call content, with the reason documented |
My working approach: keep access and activity logs for the long period, minimise personal content inside those logs, and take a documented, legally reviewed position on call content, because the Rule's wording on "associated" personal data is where interpretations differ.
3. Sub-processors and the fourth parties nobody listed
A modern delivery centre runs on a dialler, CRM connectors, speech analytics, AI summarisation, a quality platform, seat-leasing partners and cloud hosting. Each is a processor to you and a sub-processor to your client. Section 8(1) keeps the fiduciary answerable for processing done on its behalf, and Section 8(2) requires a valid contract. Your overseas client has no wish to carry that exposure, so it will push it down to you on paper. And then there is the shadow stack: the agent pasting a transcript into a free AI chatbot to summarise it. No contract covers that, and no questionnaire answer will survive it. Approve the tools people may use, block the ones they may not, and write down which is which.
| Clause | What it covers | Why it matters in a BPO |
|---|---|---|
| Instructions-only processing | Use data only as the client directs | Stops "analytics" reuse of call data |
| Named security controls | Rule 6 measures spelled out | Replaces "industry standard" promises |
| Sub-processor approval and list | Who else touches the data | Clients ask for this first |
| Breach notice timing | Shorter than your own downstream clocks | Your clock depends on your vendor's |
| Deletion or return at exit | Including backups | Old data outliving the contract |
| Processing location | Where data and tools sit | Links to sector localisation rules |
| Evidence and audit rights | Right to see proof, not assurances | Feeds your own client audits |
4. Cross-border flows: a different question for each stream
For overseas-stream data, Section 16 does not apply because of the exemption, yet client contracts frequently restrict where processing may occur, which is why many agreements name approved locations. For Indian-stream data, Section 16 and Rule 15 take a negative-list approach: transfers are permitted unless the Central Government restricts a country, and stricter sectoral rules, such as those of the RBI, continue to apply alongside. An Indian bank's collections process routed through a global contact-centre platform hosted abroad is where this bites. Rule 13(4) localisation applies only if an entity is notified as a Significant Data Fiduciary, a status the Central Government assigns by looking at the volume and sensitivity of the data handled. Large providers should find out early whether their Indian entity could plausibly fall into that category, because the extra duties, including annual audits and impact assessments, take time to build.
5. Your own people are the largest data set you control
Attrition at BPO scale means a permanent stream of candidates, joiners and leavers: résumés, background verification, bank details, biometric attendance, CCTV, call monitoring and performance data. Here you are plainly a Data Fiduciary, and the exemption does nothing for you. Section 7 allows processing without consent for employment purposes, but it does not relax security, retention or grievance duties, and candidate databases held for "future openings" are arguably a consent question. The CV folder from 2019 with tens of thousands of résumés is the example every HR head recognises.
6. Breach response on a 24x7 operation
Rule 7 requires intimation to each affected individual and to the Board without delay, followed by a detailed report to the Board within 72 hours. CERT-In wants six hours. Client contracts are set by negotiation and are frequently shorter than 72 hours. Meanwhile the incident is noticed by a team leader at 3 a.m. whose shift ends at 4. Who declares it? Who calls the client? Who owns the log pull?

Design for the shortest clock. You will meet the longer ones by default.
7. Evidence fatigue
A mid-sized provider may answer dozens of client questionnaires a year, each asking some version of the same dozen questions. Every one ends with "attach evidence." If your answers live in people's heads and old emails, every audit is a fire drill. Build one evidence base and serve every client from it. The practical test is simple: pick any client, any month, and ask whether you can produce the access review, the retention run and the training record for that process within an hour. Teams that can do this spend two days on an audit. Teams that cannot spend two weeks, and the client notices the difference.
What the penalties actually attach to
The Schedule to the Act sets ceilings, not tariffs. The Board considers the nature, gravity and duration of a breach, and what the organisation did to mitigate it.

For a BPO, the instructive bar is the longest one. The ₹250 crore ceiling attaches to failing to take reasonable security safeguards under Section 8(5), the very provision the outsourcing exemption does not remove.
A defensible programme in ninety days
You will not finish in ninety days. You will become defensible, which is what clients are testing for.
| Days | Focus | What you produce |
|---|---|---|
| 1 to 30: Map | Classify each client and process by data stream. List every system, tool and sub-processor | Stream register, system inventory, sub-processor list |
| 31 to 60: Control | Mask fields at the agent desktop. Review access. Set log and recording retention per client. Paper your top sub-processors | Retention schedule, access review records, signed vendor terms |
| 61 to 90: Prove | Run a breach tabletop against all three clocks. Build the evidence file. Draft one master client response | Tabletop report, dated evidence file, standard questionnaire pack |
Train by role. Show agents what a masked field is for, show QA teams what they may export, and show HR what happens to a rejected candidate's file. A generic slide deck changes nothing.
Where VaultDef fits
VaultDef does not mask your agent desktop or retrain your floor. That is operations work, and process comes before tooling. What it does is make the process provable and sustainable once you have it, which is exactly what client audits demand.
- Know where the data is. Automated data discovery and classification across your systems, and a record of processing you can split by client and by data stream.
- Keep the sub-processor and location picture current. Vendor and cross-border tracking, so the answer to "who else touches this data, and where" is one click rather than one week.
- Handle people and requests properly. Consent, notice and data principal rights workflows for your own employees and candidates, with dated responses.
- Rehearse and run breaches. Breach workflow and detection and response tooling with the clocks built in, so the 3 a.m. question has an owner.
- Answer every client from one file. A tamper-evident evidence trail built for the day someone says "prove it."
VaultDef is built by practitioners who have worked across offensive security, defensive security and compliance, including RBI and CERT-In regimes. That background matters in this industry, because your clients are usually regulated entities themselves. If you want the full ten-step approach behind this programme, start with our DPDP audit readiness checklist.