Data fiduciary

Defined by the decision, not the database

A data fiduciary is the organisation that determines the purpose and the means of processing personal data. Purpose is the why: marketing a new collection, running credit checks, delivering a course, processing a claim. Means is the how at a level of significance: which systems, which vendors, which retention period, which channel. The entity that answers those questions is the fiduciary, and with that authority comes the obligation to answer for the result.

The definition is functional rather than contractual. Calling yourself a platform, an aggregator or a technology enabler does not change the analysis if you decided what the data would be used for. Conversely, a company that handles enormous volumes on somebody else’s documented instructions is a processor, not a fiduciary, even though it looks like the bigger party in the room. Labels in a terms of service are evidence of intent; the actual decision-making is what a regulator examines.

For an Indian team the practical test is simple. Ask who would have to approve a new use of the data, such as selling a product category to the same list or sharing it with a partner. If the answer is your company, you are the fiduciary for that processing. If the answer is a client and you would need their written instruction, you are the processor. Most companies are both, in different parts of the same product, which is why one privacy policy is rarely enough.

Joint arrangements are the grey area. Two companies can jointly determine purpose, for example a co-branded credit card or a hospital referral partnership, and each may be a fiduciary for the shared processing. The Act does not provide a detailed joint-controller regime, so the workable approach is a written allocation of duties: who serves the notice, who answers rights requests, who reports a breach, and who owns the grievance. Without that allocation, both parties assume the other is doing it, and the principal discovers the gap at the worst moment.

Fiduciary and principal: authority against rights

The pair to keep straight is fiduciary and principal, because the words sound symmetrical and the relationship is not. A data fiduciary holds the authority to decide processing and carries the duties that go with it. A data principal is the individual the data is about, and holds rights rather than duties: to access a summary of what is held, to correction and completion, to erasure, to grievance redressal and to nominate someone to exercise rights if they die or become incapacitated.

What each can demand follows from that. A principal can demand that you explain the processing, fix an error, delete data whose purpose is served, and answer a complaint within the prescribed process. A fiduciary can demand that a processor follow instructions, keep the data secure, notify a breach quickly and delete on termination. A principal cannot demand that a processor answer them directly, because there is no relationship between them; the request travels to the fiduciary, who then instructs the processor.

This is why the phrase whose data is it gets confusing. The data is about the principal, and the principal has rights over it, but the fiduciary holds the lawful basis and the operational control. Neither owns the data in a property sense. Treating personal data as an asset owned by the company, to be sold, enriched or transferred freely, is the mental model that produces most DPDP failures, because it collapses a duty of care into a line item.

The obligations that come with the role

The core duties are short to list and long to operate. Give a notice that is itemised and plain before or with the consent request. Obtain consent that is free, specific, informed, unconditional and unambiguous, or identify another lawful basis the Act permits. Answer rights requests. Protect the data with reasonable security safeguards. Report a personal data breach to the Board and to affected principals in the form and timeframe the Rules set. Publish a way to reach a grievance officer and actually resolve grievances.

Two duties are frequently underestimated. The first is accuracy, because correction requests expose how many systems hold a stale copy of a phone number or an address. The second is erasure by default: once the purpose is served, the data should go unless a law requires retention. That inverts the usual corporate instinct to keep everything in case it becomes useful, and it means retention has to be designed at the point of collection rather than discovered during an audit.

Consent quality sits underneath all of it. A fiduciary that relies on consent must be able to show, for a specific person and a specific purpose, what notice was served and what act was taken. That is the consent artefact and the ledger described elsewhere in this glossary, and it is the operational form of the fiduciary duty. Without it, the obligation exists on paper and fails on inspection.

Significant Data Fiduciary: the higher tier

The Act allows the Government to notify certain fiduciaries as Significant Data Fiduciaries, based on the volume and sensitivity of data handled, the risk to principals and other factors including national security. The designation is not a compliment; it attaches additional obligations that require standing capacity rather than a project team.

A Significant Data Fiduciary must carry out a data protection impact assessment, conduct periodic audits, appoint a data protection officer based in India who reports to the board, and put in place a grievance redressal mechanism with a named officer. It must also undertake algorithmic due diligence where processing involves automated decision-making, and observe any restrictions the Government imposes on transferring specified categories of data outside India.

For a company building agents, the algorithmic due diligence clause deserves attention. It is not satisfied by a model card. It requires a documented understanding of how automated decisions affect principals, what data they use, how errors are detected and what a person can do about an adverse outcome. An agent that scores leads is low stakes; an agent that decides credit eligibility or triages a medical complaint is a different category of risk and needs a different level of documentation, whether or not the company is formally notified.

The practical signal that the higher tier is close is not the notification list but the shape of the processing. If a single automated decision can deny someone a loan, a job or a hospital admission, the company already carries the risk the tier is designed to manage, whether or not the notification has arrived. Building the impact assessment and the audit trail early is cheaper than retrofitting them under a deadline, and it is the same evidence a client will ask for in a vendor review.

Where a platform like LoopNow actually sits

For customer marketing data, LoopNow is a data processor. A client decides which contacts to import, why they are being messaged, how long they are kept and which channels are used. LoopNow stores and processes that data on documented instructions, applies security controls, and does not use it for its own purposes such as training models or building benchmark datasets. Those prohibitions belong in the contract, not only in a marketing page.

For its own website visitors, trial signups, billing records and support conversations, LoopNow is a data fiduciary. It decides why an email address is collected at signup, how long a billing record is retained for tax purposes, and which sub-processors receive support transcripts. That processing needs its own notice, its own retention logic and its own grievance route, and it is governed by LoopNow’s privacy policy rather than a client’s instructions.

The mixed role is normal and it is where most confusion in procurement arises. A client’s security questionnaire will ask whether the vendor is a fiduciary, and the honest answer is that it depends on the data. The useful answer distinguishes the two categories explicitly, names the sub-processors for each, and points to the data processing agreement that governs the client data. An answer that says we are only a processor, full stop, is usually wrong somewhere in the product.

The contract is where the role becomes real

A data processing agreement is the instrument that converts the fiduciary relationship into operational rules. It should state the subject matter, duration, nature and purpose of processing, the categories of data and of principals, and the obligations of the processor. It should also state the specific instructions, the security measures, the breach notification window, the sub-processor authorisation mechanism, the audit rights and the deletion or return obligation at termination.

Three clauses deserve negotiation rather than acceptance. The breach notification window should be short enough that the fiduciary can meet its own reporting duty, which means hours rather than days for a confirmed incident. The sub-processor clause should require prior notice and a right to object, with a current list maintained somewhere the client can read. The deletion clause should specify what happens to backups, because deleting a production row and leaving seven years of immutable snapshots is not deletion.

Audit rights are the clause most often written broadly and exercised rarely. A practical alternative to on-site audits is a standing evidence pack: the latest independent report, the sub-processor list, the retention schedule, the access control summary and a sample of consent artefacts. Reviewing that pack annually, with a right to ask follow-up questions, gives a client more assurance than a two-hour walkthrough arranged for the visit.

Termination deserves a rehearsal rather than a clause. Ask the vendor to demonstrate, on a test tenant, what happens at the end of the contract: how the data is exported, in what format the consent artefacts arrive, how long deletion takes and what the confirmation looks like. A vendor that cannot run the rehearsal has not built the exit, and the clause will be negotiated under duress at renewal. The same rehearsal is a useful check on your own export tooling, which is usually the weaker side of the pair.

What a principal can demand, and what stops at the door

A principal can ask a fiduciary for a summary of the personal data being processed, the identities of the fiduciaries with whom it has been shared, a description of the processing, and the categories of data. They can ask for correction of inaccurate data and completion of incomplete data, for erasure where the purpose is served and no legal obligation requires retention, for a grievance to be heard, and for a nominee to act on their behalf. The fiduciary has to verify identity before acting and has to respond within the process the Rules set out.

A principal cannot demand that a processor answer them, cannot demand the source code of a model, cannot demand deletion of data that a tax or sector law requires to be kept, and cannot demand that a grievance skip the fiduciary’s process and go straight to the Board. Those limits are not loopholes; they are the shape of a system that places one accountable party in front of the individual.

The boundary that causes most operational friction is erasure versus retention. A customer asks to be deleted; the finance team needs the invoice for eight years; the support team has a recording that may be evidence in a dispute. The correct handling is to delete or de-identify everything that is not under a legal obligation, keep the minimum that is, restrict access to it, and tell the principal what was kept and why. Refusing the whole request because part of it is subject to retention is a failure of the duty.

Sector regulators sit alongside the Act

India does not have a single privacy regulator that displaces everything else. A lender answers to the Reserve Bank on outsourcing and data localisation, an insurer to the Insurance Regulatory and Development Authority, a broker to the Securities and Exchange Board, a telecom operator to the Telecom Regulatory Authority. The Data Protection Board sits on top of that landscape, and a compliance programme that satisfies the Act while ignoring the sector regulator is incomplete.

The practical implication is that retention periods and transfer rules often come from the sector, not from the Act. Financial records have their own retention expectations. Know-your-customer data has its own handling rules. Health data carries confidentiality obligations from medical regulation in addition to the Act. When a client asks how long a recording is kept, the answer frequently has two parents: the purpose limitation in the Act and a sector instruction that fixes a minimum.

Build the register so that each processing activity names both. A row that says call recordings are kept for ninety days because the purpose is served is incomplete if a sector rule requires six months for dispute evidence. Recording both sources in one place makes the retention decision explainable, which is what an auditor actually wants to see.

The register should also record which regulator owns each obligation, because escalation paths differ. A data question for a lender may need the privacy team, the compliance team and the outsourcing committee, and a single owner who can speak to all three is worth appointing. In practice that person is usually the one who answers client security questionnaires, which makes them the natural owner of the processing register as well.

Building the register that makes the role work

A record of processing activities is the working document of a fiduciary. Each row names a processing activity, its purpose, the lawful basis, the categories of data and principals, the systems involved, the recipients and sub-processors, the retention period with its source, and the security measures applied. It should be short enough to read in a sitting and specific enough that an engineer can find the system it refers to.

Two columns do most of the work. The purpose column forces the conversation that prevents scope creep, because a use that cannot be written down as a purpose is usually a use nobody approved. The retention column forces the deletion design, because a period with no mechanism behind it is an intention. If the register says ninety days and no job deletes at ninety days, the register is fiction and the first audit will show it.

The register should also carry a data protection impact assessment flag for high-risk activities. Not every row needs a full assessment, but the ones involving sensitive categories, systematic monitoring, automated decisions with significant effect, or large-scale profiling do. The assessment does not have to be a fifty-page document; a structured record of the risk, the mitigation and the residual position is enough to demonstrate that the question was asked before the feature shipped rather than after.

Review the register on a schedule and after every launch, not once a year. The trigger for an update is a change in purpose, a new vendor, a new data category or a new market, and those happen between audits. A register that is six months stale is worse than an incomplete one, because it looks authoritative while describing a product that no longer exists. Put the review in the release checklist for anything that touches personal data.

Common mistakes and a worked example

The most common mistake is believing that a processor relationship discharges the duty. It does not. A fiduciary that appoints a messaging vendor remains answerable for what the vendor does with the data, which is why sub-processor governance is a fiduciary activity rather than a procurement chore. The second mistake is treating the privacy policy as the notice, which produces a document too long to read at the point of collection and too vague to prove what a person saw.

The third is a consent model that cannot be withdrawn in the same channel it was given. The fourth is retention by inertia: data kept because deleting it requires a decision, and no one is empowered to make one. The fifth is a grievance channel that exists on a page but has no owner, no ticket queue and no response time, which turns a manageable complaint into a Board complaint.

A mid-sized Indian fintech illustrates the pattern. It collects leads on a partner website, enriches them with a credit bureau pull and calls them within four minutes. The partner is a fiduciary for the website collection and the fintech is a fiduciary for the enrichment and the call, which means two notices and two consent artefacts rather than one. When the fintech rewrote its privacy policy, it assumed the partner’s consent covered the new purpose. It did not. The fix was a shared purpose code, a joint notice version and an artefact that both parties can verify, which cost three weeks of engineering and removed a category of grievance that had been running at a dozen a month.