Data Fiduciary or Data Processor? The distinction GCCs keep getting wrong

Ask a global capability centre's privacy team what role they play under the DPDP Act and the answer is usually confident and usually incomplete: "we are a processor, our clients are the fiduciaries." That is true for the client engagement itself. It is not true for the fourteen thousand employee and candidate records the GCC holds in its own HRMS, applicant tracking system and access control logs.

The dual role, stated plainly

A GCC serving a global bank's operations typically holds two entirely separate bodies of personal data under two entirely different roles:

As Data Processor, it holds and processes personal data belonging to its client's customers, employees or counterparties, on the client's documented instructions, under a services agreement. The obligation set here is largely defined by the contract and by the DPDP Act's processor provisions, which are comparatively light — process only on instruction, assist the fiduciary, maintain confidentiality, delete or return on termination.

As Data Fiduciary, it independently determines the purpose and means of processing personal data belonging to its own employees, contractors and job applicants — payroll, performance data, biometric attendance, background verification records, exit interview notes. Here the GCC carries the full fiduciary obligation set: notice, consent where applicable, data principal rights, breach intimation to the Data Protection Board with no materiality threshold, and potential Significant Data Fiduciary duties if the scale crosses the notified thresholds.

Why the confusion happens

Three reasons, consistently.

The privacy programme was built for the client relationship first. Most GCC privacy functions grew out of information security requirements in client contracts — SOC 2, ISO 27001, client-specific data protection addenda — which are processor-shaped concerns. The employee-data fiduciary obligation was never the starting point and often still is not a dedicated workstream.

HR data feels internal, and internal has historically meant lower scrutiny. There is a common and incorrect assumption that data about your own employees carries a lighter compliance burden than data about a client's customers. The DPDP Act draws no such distinction. An employee is a data principal like any other.

The DPDP Act's breach intimation duty has no materiality threshold, which most privacy programmes ported from a GDPR-influenced background do not expect. A breach in the applicant tracking system — commonly a lower-security, higher-turnover-of-access system than production client environments — is exactly the kind of incident that gets triaged as low priority under GDPR-shaped thinking and is not exempt from intimation duty here.

What a correctly separated programme looks like

Two registers, not one. The processor obligations (contractual, largely defined by client agreements) and the fiduciary obligations (defined by the DPDP Act directly, for employee and candidate data) should be tracked as separate obligation sets with separate owners, even though one team may execute both.

Notice to the workforce, not just the client. Employees and candidates are entitled to itemised notice about what personal data is collected and why. Most GCCs have an HR privacy policy; fewer have confirmed it meets the itemised-notice standard the Act actually requires, and fewer still have addressed notice for data collected before the Act's obligations became enforceable.

A breach response path that does not default to the client escalation process. An incident affecting only internal HR data should trigger the fiduciary breach process — intimation to affected employees and the Board — independently of whatever client notification obligations may or may not apply. Running one unified escalation path risks routing an internal-data incident through a process built for client-data incidents, where the triage criteria are different.

Access control logs treated as personal data, not just security telemetry. Badge swipe records, VPN access logs and endpoint monitoring data are personal data about employees under the Act, not merely security artefacts, and a data inventory that omits them is incomplete for fiduciary purposes even if it is adequate for security purposes.

The one-sentence test

If your DPDP programme can answer "what is our position as a Data Processor for client X" fluently but stumbles on "what is our position as a Data Fiduciary for our own workforce," you have built half a programme. Both halves are required, and the fiduciary half — the one built second, if at all — carries the obligation set with the least forgiving trigger: intimation, on every breach, with no materiality test to hide behind.