The DPDP Act and your India GCC: roles, deadlines and BOT contracts
DPDP GCC compliance guide: the Rules timeline to May 2027, fiduciary vs processor roles for an India GCC, BOT contract clauses and a breach-readiness checklist.
By Onfocus editorial team. Published . 9 min read.
India's Digital Personal Data Protection (DPDP) Act 2023 is coming into force in stages. The DPDP Rules were notified on 13 or 14 November 2025 (sources differ by a day), the Consent Manager registration rule applies from about 13 to 14 November 2026, and the core obligations on notice, consent, security safeguards, breach notification and retention apply from about 13 to 14 May 2027. Until then, the SPDI Rules 2011 remain in force (PIB, Nov 2025; Storyboard18, Nov 2025).
For a GCC, DPDP compliance turns on which role the India entity plays for which data. In our analysis, a GCC is usually a data processor for its parent's customer data and a data fiduciary for its own employee and vendor data. In a Build-Operate-Transfer (BOT) arrangement those roles can sit with different entities before and after transfer, so the contract should allocate them explicitly, and breach notification and cross-border data mapping should be ready before May 2027.
The DPDP timeline, as of November 2026
The Rules were published with a staggered start. The dates below are counted from publication, which is why sources give a two-day window.
| When | What applies | Rules |
|---|---|---|
| 13 or 14 Nov 2025 | Publication; the opening rules and the Data Protection Board provisions apply immediately | Rules 1, 2 and 17 to 21 |
| About 13 to 14 Nov 2026 | Consent Manager registration | Rule 4 |
| About 13 to 14 May 2027 | Core obligations: notice, consent, security safeguards, breach notification, retention | Rules 3, 5 to 16, 22 and 23 |
| Until the core obligations apply | The SPDI Rules 2011 stay in force | Not applicable |
Sources: Storyboard18, Nov 2025; The Week/PTI, Nov 2025.
The Consent Manager rule starts to apply this week. Most GCCs will never register as a consent manager, so for them the date that matters is May 2027, about six months away. That is a short runway if the centre's contracts, notices and incident processes were written for the SPDI Rules.
There is also an overlap to manage. Until May 2027 the SPDI Rules are still the operative standard, so a centre should keep meeting them while it builds toward DPDP, rather than switching early and leaving a gap.
Fiduciary or processor: how a GCC's roles usually split
The DPDP framework distinguishes the data fiduciary, which decides why and how personal data is processed, from the data processor, which processes data on a fiduciary's behalf. Most of the obligations listed above attach to the fiduciary. So the first job for any GCC is to work out which hat it wears for each kind of data.
The table below is our analysis of a typical captive or BOT centre. It is not a regulatory position, and the facts of your centre can change the answer.
| Data | Typical role of the India entity | Reasoning |
|---|---|---|
| The parent's customer data, handled for support, engineering or analytics work | Processor | The parent decides the purpose; the GCC works on its instructions |
| India employees' data, including payroll and performance records | Fiduciary | The India entity is the employer and decides how it uses this data |
| Candidates' data collected during hiring | Fiduciary (of whichever entity is recruiting) | The recruiting entity decides what it collects and keeps |
| Vendor and contractor contact data | Fiduciary | These are the entity's own business relationships |
| Group HR or finance data processed as a shared service for other group companies | Usually processor, case by case | The group company that owns the relationship normally decides the purpose |
Roles can shift with the work. A centre that starts deciding how customer data is used, for example by choosing which records to train a model on for its own initiative, may be doing more than processing. If your GCC runs AI and machine learning work on production data, have counsel look at that specific flow.
How far DPDP reaches the parent's own processing outside India is a separate question for counsel. The point for the India entity is narrower: know its role for each data set, and be able to show it.
Allocating roles across a BOT contract
A Build-Operate-Transfer (BOT) GCC moves through three phases. In build, the provider sets up a legal entity (or a ring-fenced unit inside its own entity), secures premises and staffs the centre. In operate, the centre delivers contracted services with SLAs and governance. At transfer, the entity or its assets pass to the customer, followed by a transitional services agreement (TSA) (Morgan Lewis, Jun 2024). The same source describes three structures: asset-based, a provider-owned entity with a call option over all its shares, and a joint venture the customer later buys out.
Each structure puts the employer, and therefore the fiduciary for employee data, in a different place at different times. A sketch for the common provider-owned entity, again as our analysis:
| Phase | Employer of India staff | Employee and candidate data | Parent's customer data |
|---|---|---|---|
| Build | The provider's entity | The provider's entity is fiduciary, including for candidates it recruits | Usually limited; any access is as processor for the parent |
| Operate | The provider's entity | The provider's entity is fiduciary | The parent is fiduciary; the India entity acts as processor |
| Transfer by share purchase | The same entity, now owned by the client | The entity stays fiduciary; employment continues because the employer doesn't change | Roles stay the same; the contract terms are re-papered as intra-group |
| Transfer by business transfer (slump sale) | The client's own entity | Records move to the new employer, which becomes fiduciary | The client's entity takes over the processor role |
| TSA period | The client's entity | Unchanged | The provider may still touch some data, for example payroll or IT support, as a processor |
The choice between share purchase and slump sale is covered in the BOT transfer: share purchase vs slump sale, and the employment side in moving employees at transfer under India's new labour codes.
Why timing makes this urgent
Providers commonly describe an operate phase of 18 to 36 months, or two to three years (eCorpIT, Aug 2026; Wisemonk, Oct 2026). These are vendor figures and indicative only. On any of them, a BOT signed today will still be in operate when the core DPDP obligations apply in May 2027. The contract should be drafted to the DPDP standard from day one, while the centre keeps meeting the SPDI Rules until May 2027.
What the contract should say
One vendor practitioner guide calls a vague transfer clause, one that doesn't specify what moves, the single biggest BOT risk. Data is one of the things that has to be specified. Law-firm guidance also flags compliance divergence, where payroll, contract or FEMA records end up split between operator and parent (IMC via Legal 500, May 2026). Privacy records split the same way if nobody owns them.
Clauses we would expect to see:
- A role schedule that names the fiduciary and processor for each data category in each phase, including the TSA.
- Processor terms for the operate phase: acting on documented instructions, security safeguards, approval of any sub-processors, and return or deletion of data at the end.
- A breach notification chain covering who detects, who decides, who notifies, and the internal deadlines between provider and parent.
- A list of privacy records that transfer with the centre: notices issued, consent records where consent is the basis, processing inventories and retention schedules.
- A data migration step in the transfer plan. The usual sequence is share transfer or equity issuance, then contract assignment, then IP migration, then employee onboarding under parent governance (IMC, as above), and data handling belongs inside each step.
- Retention and deletion terms for whatever the provider keeps after transfer, with a certificate of deletion.
Breach notification readiness
Breach notification is one of the obligations that applies from May 2027. For a GCC the harder part is usually the internal chain: an incident in the India centre may involve the parent's customer data (where the parent is fiduciary) and employee data (where the India entity is fiduciary) at the same time.
A workable setup has a few parts:
- One incident owner across provider and parent during operate, named in the contract.
- A decision tree that starts from the question "whose data is this?" and routes to the right fiduciary.
- Pre-agreed internal deadlines for the processor to tell the fiduciary, short enough to leave the fiduciary room to meet its own duties in India and in its home jurisdiction.
- Logs and evidence kept long enough to reconstruct what happened.
- A tabletop exercise before May 2027, run jointly if the centre is still in operate.
None of this depends on the exact regulatory timelines, so it can start now.
Cross-border data mapping
Data in a GCC moves in both directions. The parent's data comes into India for engineering, support or analytics work, and the India entity's own data, such as employee records, often flows out to group HR, payroll and identity systems.
Map these flows now: what data, which systems, which countries, which entity is fiduciary, and on what basis it moves. Check the DPDP position on transfers outside India with counsel as the Rules take effect. A clean map also makes the transfer simpler, because it shows exactly which systems and records have to change hands.
A practical checklist before May 2027
- Confirm the current dates with counsel and keep meeting the SPDI Rules until the core obligations apply.
- Build a data inventory for the India entity, split by category: customer, employee, candidate, vendor and group shared-service data.
- Record the fiduciary or processor role for each category, with the reasoning.
- For a BOT, add a role schedule to the contract covering build, operate, transfer and the TSA.
- Update processor terms between the India entity and the parent, and between the provider and the client during operate.
- Rewrite employee and candidate notices to the DPDP standard.
- Set retention periods and deletion routines for each category.
- Map cross-border flows in both directions.
- Agree the breach notification chain and run a tabletop exercise.
- List the privacy records that must move at transfer, alongside the employee, lease and contract lists.
If you are at an earlier stage, the BOT phases are explained in Build-Operate-Transfer for GCCs in India.
How Onfocus can help
Onfocus builds GCCs in India under a Build-Operate-Transfer model and already recruits and runs engineering teams for clients in fintech, banking and Web3, where customer data handling is part of daily work. We plan the operate and transfer phases with data roles, records and incident routing written in from the start, working alongside your counsel. To discuss your plans, contact us about a GCC.
This article is general information, not legal or tax advice. Confirm the details for your situation with Indian counsel and a chartered accountant.
Frequently asked questions
- When do the DPDP Rules apply to a GCC in India?
- The Rules were notified on 13 or 14 November 2025. Consent Manager registration applies from about November 2026, and the core obligations, including notice, consent, security safeguards, breach notification and retention, apply from about May 2027.
- Is a GCC a data fiduciary or a data processor under DPDP?
- In our analysis, a GCC is usually a processor for its parent's customer data and a fiduciary for its own employee, candidate and vendor data. The facts of each centre can change this, so confirm with counsel.
- Do the SPDI Rules still apply before May 2027?
- Yes. The SPDI Rules 2011 stay in force until the core DPDP obligations apply, so a GCC should keep meeting them while it prepares for DPDP.
- How should a BOT contract handle DPDP?
- It should name the fiduciary and processor for each data category in each phase, including the transitional services period. It should also set processor terms, a breach notification chain and the list of privacy records that move at transfer.
- Why does DPDP matter for a BOT signed now?
- Providers commonly describe an operate phase of 18 to 36 months, so a BOT signed now will still be in operate when the core obligations apply in May 2027. The contract should be drafted to the DPDP standard from the start.