Data Fiduciary and Data Processor: who is responsible for what?

When a business buys software, it often asks whether the supplier is “the processor”. The answer cannot safely come from the invoice label alone. It depends on what the supplier does with the particular data and who decides the purpose and means of that processing.

Under section 2 of the DPDP Act, a Data Fiduciary determines purpose and means, alone or with others. A Data Processor processes on behalf of a fiduciary. As of 22 October 2026, these definitions have commenced while the main accountability and contract duties discussed here are scheduled for May 2027 under the commencement notification.

Follow one activity rather than one organisation

Suppose a hypothetical online grocer appoints a cloud provider to host its customer database. The grocer decides why customer details are collected and how they support orders. The provider hosts the database under agreed instructions. That activity is a plausible fiduciary-processor relationship, subject to the actual arrangement.

The same provider may maintain its own business contacts for billing and account administration. It makes separate decisions about those records. Its role for that activity can differ. Writing “processor for everything” in a contract will not remove independently determined purposes.

A courier presents another useful question. It may use delivery details to fulfil the retailer’s instructions while also processing information for its own legal or operational purposes. The business should map those activities rather than assume that every recipient fits one simple label. A clear description of facts is more valuable than a hurried classification.

Responsibility does not leave with the data

Section 8(1) places responsibility on the fiduciary for processing it undertakes or has undertaken on its behalf, despite contrary agreements. Section 8(2) provides for a valid contract when involving a processor for the specified goods-or-services activity. The final security rule also requires appropriate contractual provision for safeguards where applicable.

These provisions make vendor diligence practical. If a processor has weak access controls, a contract saying “all liability belongs to the vendor” does not establish that the fiduciary has met its own obligations. The business needs evidence about the service, meaningful instructions and a way to respond when something goes wrong.

Conversely, a vendor should not be treated as powerless. It needs a defined service scope, a route for questionable instructions, clear security responsibilities and timely notice of changes that affect its work. The operational arrangement should make the required conduct possible.

Ask five questions before signing

1. Who decides the business purpose for each dataset?
2. Which processing is performed on the customer’s behalf, and which is independently determined?
3. Can the supplier use customer data for its own advertising, product development or other secondary purposes?
4. Which other providers receive access, and how are instructions and safeguards passed on?
5. Who will locate, correct, restrict use, retain or erase records when a customer request or incident occurs?

The third question deserves a direct answer. A broad clause allowing any use to “improve services” can conceal several different activities. Ask for a concrete example of the information used, the intended outcome and whether identifiable records are needed. Assess each activity on its own facts.

Design the handoff before an incident

Imagine the grocer discovers that a support account at the cloud provider accessed unexpected customer records. The grocer needs facts quickly: what was accessible, what actually happened, which logs exist and what containment is safe. The provider needs a named contact and an agreed escalation route.

A useful contract and operating guide specify notification speed, investigation assistance, preservation of evidence and responsibility for external communications. Those are recommended implementation details; they should not be misrepresented as a universal statutory contract template. The legal notification clocks and the organisation’s internal escalation target are different things.

Apply the same thinking to an erasure request. A vendor cannot fulfil an instruction it never receives. A business cannot truthfully confirm completion if it has no visibility of exports, subprocessors or backup treatment. Agree what the vendor will do and what evidence it will return.

Keep a role map that can change

Record the activity, data, purpose, decision-maker, service provider and relevant contract. Review the map when the supplier adds analytics, introduces a new subprocessor or changes its terms. Procurement approval should not freeze an outdated assumption for years.

The aim is a workable chain of responsibility. Staff should know who makes the decision, who performs the action and who checks the result. A role label helps only when those handoffs are clear enough to use during an ordinary customer request or a difficult incident.