Loading...
DPDP readiness becomes real when a GCC can produce evidence for every live data path.
Section
Table of Contents
- Introduction
- The First Failure Is Usually a Stale Map
- A GCC Is Not One Processing Activity
- AI Extends the Data Path Beyond the System of Record
- Ownership Fails When Evidence Has No Home
- One Record Can Expose the Gaps a Program Hides
- The Control Register Has to Change With the Work
- The Question Will Surface Again
- FAQs (Frequently Asked Question)
Key Takeaways
- How to distinguish a compliant-looking data inventory from a control register that can produce evidence during a rights request, breach investigation, or audit.
- How to assess each GCC processing activity without assuming that one corporate label, one platform, or one parent-company contract determines the answer.
- How to bring AI prompts, retrieval sources, model providers, tool calls, and operational logs into the same governance record as conventional enterprise systems.
- How to run a one-record readiness drill that identifies missing ownership, broken retention paths, and vendor blind spots before they become an operational problem.
Introduction
“Which version of the data map is the audit team meant to rely on?” The privacy lead has already asked the question twice. One file lists the HR platform and the service-management tenant. A separate architecture record shows a new retrieval source for an internal AI assistant. Procurement has the model provider contract, while the platform team owns the logs. No one can say whether those four records describe the same processing activity.
This is the point at which DPDP readiness stops looking like a legal workstream and starts looking like an operating problem. The Digital Personal Data Protection Act, 2023 defines a Data Fiduciary by the party that determines the purpose and means of processing. That legal test matters, yet a GCC also needs to know who can answer a request, halt a faulty workflow, trace a vendor path, or produce the evidence when a control is questioned.
The law and the notified Rules do not create one uniform answer for every GCC activity. They make the opposite discipline necessary. India workforce records, global shared-service operations, group analytics, customer support, vendor administration, and AI-assisted workflows have to be examined as discrete activities. The registry must remain current after a system release, a new interface, or a changed model configuration. A spreadsheet prepared for an assessment will not survive that pace.
The First Failure Is Usually a Stale Map
A data map can be complete on the day it is signed off and misleading a month later. That is not an argument against data mapping. It is an argument against treating mapping as a document rather than an operating record.
The notified DPDP Rules set a concrete technical baseline: safeguards include access control, visibility through logs, monitoring and review, backups, and appropriate provisions in Data Processor contracts. The Rules also require retention of relevant data and logs for at least one year for the specified purposes, unless another law requires otherwise. Those requirements make a list of applications insufficient. The GCC has to connect a processing purpose to the systems, identities, vendors, access events, retention trigger, and evidence that support it.
A fair objection is that large enterprises already keep asset registers, CMDBs, vendor inventories, and privacy records. They do. The friction appears because those records answer different questions and change on different clocks. The CMDB may know a service exists. Procurement may know a contract was signed. Privacy may know a purpose was approved. None of those records, by itself, shows whether a new connector sends employee records into an AI service or whether a deletion request reaches the downstream index.
The recurring pattern in enterprise assessments is a control register that stops at a named system. The useful unit is smaller: one processing activity, one purpose, a defined data population, a legal role to be verified by counsel, accountable owners, systems and vendors, transfer points, retention logic, and the evidence location. A GCC does not need another survey. It needs a record that can be tested.
A GCC Is Not One Processing Activity
The label “GCC” tells a board where work is performed. It does not settle why a particular data set is processed or who determines its essential means. The distinction becomes awkward in global operating models, which is why it tends to be flattened too early.
Section 17 of the Act contains a narrow, activity-specific exemption for processing personal data of Data Principals outside India under a contract with a person outside India. It does not remove the Data Fiduciary’s accountability under Section 8(1) or its duty to take reasonable security safeguards under Section 8(5). The statutory wording is precise: the analysis turns on the processing and contractual facts, rather than the enterprise calling the whole center “outsourced.”
That is where a global HR tenant becomes difficult. The Indian entity may be the Data Fiduciary for local recruitment, payroll, workplace access, benefits, and employee relations. It may process a foreign parent’s customer records on instructions for another activity. One shared platform may hold both data streams. A record that assigns a blanket role to a tenant hides the very distinction an audit or rights request will require.
Some leaders will argue that this is a legal classification exercise and belongs with privacy counsel. The legal conclusion does. The implementation work cannot wait for a legal memo to travel through five operating teams. The architecture owner needs to know which data set is in the tenant, the identity owner needs to know who can access it, the vendor manager needs the applicable contract terms, and the local process owner needs a route for a grievance or withdrawal request. GCC advisory and execution becomes useful when those roles are designed as an operating rhythm rather than a committee chart.
AI Extends the Data Path Beyond the System of Record
An AI use case can look harmless in an application catalogue because the visible interface is only the last step. The personal data may have entered through a prompt, a retrieved document, an embedding store, a plug-in call, an identity token, or an operational log. The location where the answer appears is rarely the full processing path.
The obvious pushback is that an internal assistant does not create a new privacy program each time a team changes a prompt. It should not. A material change in data source, model provider, tool access, retention behavior, or decision use does create a new control question. A retrieval source added to an employee-support assistant can change who accesses the data, which vendor handles it, how long it is retained, and whether the original purpose remains defensible.
The Rules are more specific than generic AI governance advice. For a Significant Data Fiduciary, Rule 13 requires due diligence that technical measures, including algorithmic software used for processing, are unlikely to pose a risk to Data Principals’ rights. The Rule 13 requirement does not create a universal AI-control checklist for every enterprise. It does make it difficult to defend an AI deployment that cannot identify its data sources, technical path, and responsible owners.
What this looks like in practice is a shared control record for each AI-enabled processing activity. It should identify the user group, input data, retrieval sources, model or service provider, tools with write or read access, output use, human review point, logging location, retention path, and owner of a model or configuration change. Microsoft Copilot services and Microsoft Azure cloud solutions create different implementation paths, yet the governance record should ask the same questions of both.
Ownership Fails When Evidence Has No Home
The Data Fiduciary remains accountable for processing undertaken on its behalf by a Data Processor. That does not mean the privacy office should operate every control. It means the enterprise needs a visible chain between legal accountability and the people who manage identity, system configuration, vendor obligations, data quality, operations, and incident response.
The counterargument writes itself: a RACI chart can solve this. It helps, until the chart gives responsibility to a function and no one owns the evidence. “Security” is not an evidence location. “IT” is not an escalation path. “The vendor” is not a remediation plan. A working register needs named roles for the purpose owner, system owner, data owner, technical control owner, vendor owner, and incident lead. One person can hold more than one role in a smaller GCC. The role itself cannot remain unnamed.
This separation answers a question that often surfaces too late. A parent entity may determine the purpose and means, while the India GCC operates the environment and can see the logs. The legal outcome requires activity-specific advice. The operating model still needs both sides stated before an incident: who authorizes the use, who detects a failure, who can pause processing, who communicates with the affected population, and who produces the record of what happened.
The Data Protection Board of India was established in 2026, so the governance question has moved beyond a future-policy discussion. A business that cannot locate evidence across the parent, GCC, and supplier boundary will struggle even when its written policy is sound. The issue is practical: the people who need the evidence must be able to retrieve it without assembling it from scratch.
One Record Can Expose the Gaps a Program Hides
An enterprise does not need to wait for a breach to learn whether its DPDP controls are connected. It can select one real record, one active workflow, and one owner, then follow the record through the route it actually takes.
Choose an India employee record that appears in the HR system, identity platform, service-management tool, and an AI-enabled support or analytics process. Ask whether the team can identify the purpose of processing, the parties who determine the purpose and means, every vendor and internal system involved, access history, retention and erasure behavior, and the person who can answer a rights request. If the same record appears in a retrieval store or model log, the trace must include those locations too.
This does not replace legal analysis. It turns legal analysis into an operational test. A policy can state that data is deleted when a purpose ends. The test asks which job disables the account, deletes the source, removes downstream copies, handles backups or logs within the applicable retention requirements, and records that the sequence completed. The failure is usually visible before the answer reaches the end of the trace.
The Control Register Has to Change With the Work
The privacy lead’s question will return, perhaps in a rights request, perhaps during a supplier review, perhaps after an AI workflow produces an answer from a source no one remembers enabling. The useful answer will not be a policy statement. It will be the current record for the processing activity, with the owners and evidence attached.
For GCCs that need to turn that test into a working program, VBeyond Digital can conduct a DPDP readiness assessment across live data flows, systems, vendors, AI use cases, ownership, and control evidence. The work starts by tracing a small number of real processing activities, then building the operating record that the wider program needs.
The map will need to be current when the question is asked.
The Question Will Surface Again
Annual remediation has a place, especially where the organization is working through a large inventory. It cannot be the only mechanism. The control record starts losing value the moment a team changes a data source, enables a plug-in, adds a model provider, alters an integration, or opens an AI workflow to another user group.
The pattern across enterprise delivery is that release management and privacy management meet only when a production issue forces the conversation. That leaves a GCC with controls that describe last quarter’s architecture. A more useful approach makes a small set of privacy and evidence questions part of the material-change gate: does the purpose change, does a new personal-data path appear, does a vendor or subprocessor change, can access expand, does the retention path alter, and has the accountable owner accepted the new control record?
This matters as much for conventional enterprise systems as for AI. A payroll interface, a CRM export, an identity sync, or an analytics feed can create the same ownership break as a new model connector. The distinction is not between old systems and AI. It is between a change that leaves an evidence trail and one that is discovered after the fact.
Turn Azure Chargeback Disputes Into Clear Cost Decisions
FAQs (Frequently Asked Question)
No single answer can be assigned to the entire GCC. The Act applies to processing of digital personal data within India, subject to its scope and exemptions. Section 17 includes an exemption for certain processing of personal data of Data Principals outside India under a contract with a person outside India, while retaining specified accountability and security duties. Each activity needs legal review against its data population, purpose, contractual chain, and operating facts.
It should go beyond applications and data categories. For each processing activity, record the data population, purpose, legal role to be confirmed, accountable roles, systems, integrations, vendors, transfer points, AI components where relevant, access and logging evidence, retention trigger, erasure path, incident route, and the date of the last material change.
Treat the AI workflow as a data path, not as a feature label. Map the user group, input data, retrieval sources, model or service provider, tool access, output use, human review, logs, retention, and change owner. The right level of control depends on the use case and risk, but the path has to be visible before the system scales.
Legal accountability depends on the processing activity and who determines its purpose and means. Operationally, evidence should have named owners even where systems are shared: a business owner for the purpose, a system owner for configuration, a data owner for the record, a technical control owner for access and logs, a vendor owner for supplier commitments, and an incident lead for escalation.
Trace one live record through one active process. Use a record that crosses several systems and, where applicable, an AI workflow. The test should reveal whether the enterprise can show purpose, role, access, vendors, processing history, retention, deletion, and the named route for an incident or rights request.
