Classify India and global data flows, determine the GCC's role for each processing activity, reuse the privacy and security controls you already run, and identify what actually needs to change across people, systems and vendors.
Practical implementation framework • Source-linked • Provider-neutral
Every connector is a processing activity to classify, not a single "GCC compliance" question to answer.
A Global Capability Centre is not a single privacy problem. Inside one legal entity, personal data moves through populations, systems and contracts that each sit differently under the DPDP Act. Treating them as one programme is where most GCC efforts lose accuracy.
Employees, candidates, payroll, benefits, access provisioning, workplace monitoring and internal investigations. High volume, high sensitivity, and the population most clearly within India.
Indian personal data commonly sits in platforms owned, configured or operated across several countries: global HRIS, identity, collaboration, service management and analytics.
The India centre may process personal data belonging to people outside India, for a foreign entity, under contract. Whether a specific carve-out is relevant depends on the facts, not the label.
For its own India operations the entity may decide purposes itself. For group work it may act on a parent's instructions. The same GCC can hold different roles for different activities.
The corporate label "GCC" does not answer the DPDP question. The processing activity does.
The question is rarely "are we DPDP compliant?" It is a sequence of narrower questions, answered per data stream, that tell you which obligations attach and what has to change.
Do not classify an entire global platform as "in scope" or "exempt" simply because one population or one processing activity appears to meet a particular condition. A single system often carries several streams that must be assessed separately.
Section 17(1) is a partial, purpose-specific exemption, not a blanket corporate carve-out. One of its listed purposes concerns processing personal data of Data Principals not within India under a contract with a person outside India. Whether it applies is a question of fact for each activity, and even where it does, the accountability duty under Section 8(1) and the security duty under Section 8(5) continue to apply.
Core workforce processing of people in India. Analyse under the normal applicable framework: notice, a lawful basis (consent or a Section 7 legitimate use), security, rights and retention.
Processing personal data of people outside India for a foreign entity under contract may bring Section 17(1)(d) into consideration. This requires activity-specific assessment against the statutory conditions, not an assumption.
The same platform carries both India and non-India populations. Do not treat the entire system identically. The India-resident records need their own analysis even if the tenant is shared.
Where the entity decides some purposes itself and acts on a parent's instructions for others, it may hold different roles for different activities. Role should be resolved per activity.
Section 17 is written by processing purpose and, in parts, depends on government notification. Applicability in mixed or layered arrangements should be verified by qualified counsel against the current statutory text and any rules in force. Nothing here is legal advice, and no exemption should be assumed for an activity that has not been assessed.
Role is not a property of the entity. It follows from who decides the purpose and the essential means of a given processing activity. The examples below are illustrative prompts for analysis, not universal legal answers.
| Activity | Who decides purpose? | Who controls essential means? | Who selects vendors? | Who faces the Data Principal? | Possible role |
|---|---|---|---|---|---|
| Local recruitment | India entity | India entity | India entity | India entity | Data Fiduciary |
| India payroll | India entity | India + vendor | India entity | India entity | Fiduciary; vendor a processor |
| Physical access & security | India entity | India entity | India entity | India entity | Data Fiduciary |
| Employee benefits | Shared | Provider | Group or India | India entity | Review required |
| Global customer support | Foreign client | Foreign client | Client | Client | Likely Data Processor |
| Global HR shared services | Parent | Parent | Parent | Parent / local | Review required |
| Group analytics | Group | Group | Group | Rarely direct | Review required |
| Foreign-client processing | Client | Client | Client | Client | Likely Data Processor |
Role mapping should be performed by processing activity, not by corporate entity label. A single GCC can be a Data Fiduciary for its own India workforce and a Data Processor for a foreign client in the same week.
Indian workforce data is usually the clearest population within India, and it moves through a long chain of systems and vendors. Implementation means the whole chain works, not that a policy exists.
Section 7 sets out certain legitimate uses that let a Data Fiduciary process personal data without fresh consent. It is a closed, listed set of situations, and one item concerns specified employment purposes. It is an alternative basis for particular purposes, not a general rule that workforce data never requires consent.
Map each workforce processing purpose to its basis. Some may rely on the employment legitimate use; others may still need consent or a different basis, and all of them still require notice, security, rights handling and defensible retention. Where the basis is unclear for a purpose, that is a review item, not an assumption.
A single employee record propagates across a stack that was designed globally. Each hop is a place where access, purpose, retention and a rights request have to be answerable.
Many GCCs already operate inside mature global privacy, security and assurance environments. The implementation question is not "start again". It is: what can be reused, and what is the DPDP and India-specific delta?
Inventories, vendor governance, access management, incident processes and assessment discipline often map across with adjustment.
DPDP roles, lawful basis, notice content, rights routing across global systems and defensible retention usually need targeted work.
Data inventory, rights machinery, vendor governance, assessment practice.
DPDP's own legal structure and roles, and India-resident processing specifics. GDPR transfer mechanisms do not carry over.
Security governance, access control, supplier controls, incident response.
Privacy purpose, notices, Data Principal rights, retention and role determination.
A privacy information management structure and control set.
India-specific legal mapping and the actual DPDP data flows through your systems.
Evidence discipline and a mature security control environment.
It does not by itself answer DPDP role, purpose, notice or rights questions.
No framework automatically equals DPDP compliance. Certification proves a control environment exists. It does not resolve who the Data Fiduciary is for a given activity, or whether an India-resident rights request can actually be fulfilled end to end.
A single access, correction or erasure request rarely lives in one system. Fulfilling it means routing across owners and processors, acting, responding within time, and keeping proof.
A web form is not a rights programme if the organisation cannot locate and action the underlying records across its global systems and processors. The intake is the easy part; the routing and the evidence are the implementation.
One departure fans out into many systems. Each holds a copy, each has an owner, and each needs a decision that is actually executed, not just written down.
A retention schedule is a policy artefact. Implementation means making retention and erasure executable in each system and traceable to a record. Retention periods are not prescribed here; they should be set against your purposes and any sectoral or legal obligations, then written into the systems that hold the data.
Under Section 8, a Data Fiduciary remains responsible for processing carried out on its behalf and may engage a Data Processor only under a valid contract. The boundary of the programme is the boundary of the ecosystem, not the office.
Contract clauses matter, but they do not prove that access is scoped, that a rights request reaches the processor, or that offboarding actually removed the data. Vendor governance is an operating loop, not a signature.
A mature GCC already detects and responds to incidents. DPDP adds a personal-data lens on top of that capability, and the two need to run as one workflow.
Reasonable security safeguards are a standing duty under Section 8(5), and breach handling is a Data Fiduciary obligation under Section 8. The precise content and timing of any notification obligation should be set against the current Act and the rules in force, and confirmed with counsel, rather than assumed from another regime.
Assistants, copilots and analytics pipelines now sit on top of the same enterprise systems that hold workforce and customer data. They are processing activities like any other, and they need the same classification.
The DPDP Act does not prohibit AI. It means AI features that touch personal data are inventoried, given a purpose and a role, and brought inside the same rights, retention and evidence discipline as every other system.
Eleven workstreams that move a GCC from policy to operation. Each starts from a real problem, inspects specific things, and leaves an operating outcome behind.
Populations and flows are treated as one.
Data Principal location, purpose, contract, role per stream.
A stream-level classification, not an entity-level guess.
Fiduciary vs processor is assumed, not decided.
Who decides purpose and essential means per activity.
A role register that stands up per activity.
Employee data spans a long lifecycle.
Basis, notice, systems and vendors at each stage.
An operating workforce data-flow, not just an HR notice.
Indian data moves through global platforms.
Ownership, access, purpose and retention per system.
A system inventory that answers rights and retention.
Notice content and delivery are inconsistent.
What is told, to whom, at which touchpoint.
A notice matrix mapped to actual flows.
A request cannot be routed and actioned.
Intake, routing, owners, processors, timelines.
A working rights workflow with evidence.
Schedules exist but are not executed.
Rules, exceptions, owners and downstream copies.
Executable retention and erasure, verified.
The boundary extends into vendors.
Inventory, role, contract, access, offboarding.
A processor register and an operating loop.
Privacy sits outside the SOC workflow.
Where the privacy overlay meets detection and IR.
One coordinated incident workflow.
Personal data enters the model layer unseen.
Which tools, which data, which purpose, which contracts.
An AI processing register inside the same discipline.
Controls exist but are not proven.
Ownership, tests, and the evidence each produces.
A RACI and a readiness evidence base.
The output of implementation is a set of artefacts a reviewer, an auditor or the next DPO can actually inspect. The previews below are illustrative field structures, not templates.
| Population | India employees |
| System | Global HRIS |
| Purpose | Workforce administration |
| Role | Review required |
| Vendor | Yes |
| Section 17 | Not assumed |
| Owner | HR + Privacy |
| Stream | Global support |
| Principal location | Outside India |
| Contract | Foreign client |
| Assessment | Activity-specific |
| Verified by | Legal |
| Activity | India payroll |
| Decides purpose | India entity |
| Role | Data Fiduciary |
| Processor | Payroll vendor |
| Stage | Onboarding |
| Systems | HRIS, IAM, email |
| Basis | Per purpose |
| Retention | Linked to owner |
| System | Identity provider |
| Owner | Global IT |
| Access | Scoped, logged |
| Rights-ready | In progress |
| Vendor | Background check |
| Role | Processor |
| Contract | DPDP terms present |
| Offboarding | Defined + tested |
| Touchpoint | Candidate apply |
| Audience | Applicants |
| Content | Purpose, rights |
| Status | Live |
| Request | Erasure |
| Systems hit | 7 |
| Owners | HR, IT, Vendor |
| Evidence | Retained |
| Record | Payroll |
| Rule | Per obligation |
| Owner | Finance |
| Executable | Wiring |
| Trigger | Exit |
| Targets | All copies |
| Processor step | Included |
| Verification | Required |
| Existing | ISO 27001 |
| Maps to | Security duty |
| Gap | Notice, rights |
| Action | Targeted |
| Event | Suspected breach |
| PD impact | Assessed |
| Processor coord | Triggered |
| Evidence | Preserved |
| Tool | Copilot |
| Data | Employee content |
| Purpose | Defined |
| Contract | Reviewed |
| Control | Rights handling |
| Accountable | DPO |
| Responsible | HR, IT |
| Consulted | Legal |
| Streams classified | Tracked |
| Roles resolved | Tracked |
| Rights tested | Tracked |
| Evidence | Retained |
A quick read of where the work actually stands. This is a prompt for your own team, not a score.
DPDPActIndia helps organisations understand and scope implementation requirements. Where specialist execution is required, relevant implementation capability may be considered based on factors such as your processing environment, systems, data flows, existing privacy and security maturity, technical remediation and sector context.
The intake is shared across the DPDP implementation framework. Tell us it is a Global Capability Centre and describe the environment; scoping is provider-neutral.
Generally yes, where the GCC processes digital personal data in connection with activity in India. How it applies depends on the processing activity, the population involved and the role the GCC plays, which is why classification comes before compliance. Applicability in specific arrangements should be confirmed against the current Act.
No. A GCC is not automatically a Data Processor. For its own India operations it may decide purposes and act as a Data Fiduciary; for group or client work it may act on instructions and look more like a processor. The same entity can hold different roles for different activities, so role should be mapped per activity.
Section 17(1) is a partial, purpose-specific exemption. One listed purpose concerns processing personal data of Data Principals not within India under a contract with a person outside India. Whether it applies is fact-specific and should be legally verified, and even where it applies, the Section 8(1) accountability and Section 8(5) security duties continue. It is not a blanket exemption for all offshore work.
Not by itself. GDPR maturity gives you reusable inventories, rights machinery, vendor governance and assessment discipline. DPDP has its own legal structure, roles and requirements, and GDPR transfer mechanisms do not carry over. Treat GDPR as a strong starting point and map the India-specific delta.
They cover a security control environment and evidence discipline, which are genuinely reusable. They do not by themselves answer DPDP questions of role, purpose, notice, rights and retention. Those need a specific mapping exercise on top of the certification you already hold.
Map the workforce lifecycle across every system the data touches, identify the basis and notice for each purpose, and make rights and retention actually executable in those systems, including downstream processors. The presence of a global platform does not remove the India-resident analysis.
Most substantive operational provisions are scheduled to commence on 13 May 2027. The reason to start earlier is not a deadline countdown; it is lead time. System discovery, role analysis, vendor remediation, workflow design and testing across global systems take time that a policy refresh does not.
Legal statements on this page are grounded in the primary text of the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025. Practical points are implementation interpretation, not legal advice.
What the law says is drawn from the enacted statute. What this means operationally and implementation consideration are our own framework and should be validated for your specific arrangements with qualified counsel. This page is not legal advice and DPDPActIndia is not a law firm, regulator or certification body.