Data Fiduciary vs Data Processor vs Data Principal: Complete DPDPA Glossary

If your organisation is preparing for India’s Digital Personal Data Protection Act, three terms must be understood before anything else:

• Data Principal
• Data Fiduciary
• Data Processor

These are not just legal labels.

They decide who owns the privacy obligation, who gives instructions, who processes personal data on behalf of someone else, and whose rights must be honoured.

In simple terms:

The Data Principal is the individual whose personal data is being processed.

The Data Fiduciary is the organisation that decides why and how that personal data will be processed.

The Data Processor is the organisation or vendor that processes personal data on behalf of the Data Fiduciary.

You can review the official DPDP Rules and government explanation here: Digital Personal Data Protection Rules 2025.

This glossary is designed for founders, DPOs, CISOs, legal teams, compliance teams, product leaders, HR teams, BFSI teams, fintechs, SaaS companies, healthcare platforms, e-commerce businesses and vendors who need a practical understanding of DPDPA roles before building their compliance programme.

If you already know these definitions but are unsure how they apply across your systems, vendors and workflows, start with a DPDPA readiness assessment.

The easiest way to understand the difference is to ask three questions:

• Whose personal data is it? That person is the Data Principal.
• Who decides why and how the data is processed? That organisation is the Data Fiduciary.
• Who processes the data on the Fiduciary’s behalf? That entity is the Data Processor.

For example, when a customer applies for a loan through a bank’s digital onboarding journey, the customer is the Data Principal.

The bank or NBFC deciding the purpose of KYC, credit assessment, account servicing and regulatory retention is usually the Data Fiduciary.

A KYC vendor, cloud provider, CRM platform, analytics service or background verification partner processing the data on the bank’s instructions may act as a Data Processor for that activity.

The key phrase is for that activity.

The same company can be a Data Processor in one workflow and a Data Fiduciary in another.

For instance, a SaaS vendor may process employee data only on behalf of an enterprise customer in one context. But if the same vendor uses customer data for its own product analytics, benchmarking, advertising or independent business purpose, it may become a Data Fiduciary for that separate processing activity.

This is why role mapping should be done activity by activity, not only company by company.

A contract may call a vendor a processor, but the operational test is practical: who determines the purpose and means of processing?

For organisations building a privacy programme, this distinction affects notices, consent, Data Principal rights, retention, vendor contracts, breach response, audit evidence and accountability.

Use this glossary as a practical starting point for DPDPA implementation.

Data Principal

The individual to whom the personal data relates. In the case of a child, this includes the parent or lawful guardian. In certain disability-related cases, it may include the lawful guardian acting on the person’s behalf.

Data Fiduciary

The person or organisation that determines the purpose and means of processing personal data, either alone or with others. In most business contexts, this is the company collecting or using personal data for onboarding, service delivery, marketing, employment, payments, fraud prevention, support or compliance.

Data Processor

An entity that processes personal data on behalf of a Data Fiduciary. Examples include payroll vendors, cloud providers, CRM systems, KYC vendors, payment processors, call centres, analytics tools, background verification agencies and support platforms.

Personal Data

Data about an individual who is identifiable by or in relation to that data. This can include names, phone numbers, email addresses, identity documents, account identifiers, employee records, location data, health information, transaction data and other identifiers.

Digital Personal Data

Personal data in digital form. This includes data collected digitally as well as personal data that is digitised from offline records.

Processing

Any operation performed on digital personal data, such as collection, recording, storage, use, sharing, disclosure, adaptation, retrieval, transmission, erasure or deletion.

Consent

A clear, informed and specific indication by the Data Principal allowing processing of personal data for a specified purpose. Consent should be linked to purpose, notice, timestamp, channel and withdrawal status. For enterprise consent workflows, explore Consentica for purpose-based consent management.

Notice

The information given to the Data Principal explaining what personal data is being processed, for what purpose and how rights can be exercised. A notice should not be hidden inside vague terms and conditions.

Specified Purpose

The specific purpose mentioned in the notice for which the Data Principal has given consent. Purpose clarity matters because one broad consent label such as “customer management” may hide several different uses.

Certain Legitimate Uses

Specific situations where personal data may be processed without consent under the Act. Organisations should avoid treating this as a blanket exemption and should document why a particular use applies.

Consent Manager

A registered entity that enables a Data Principal to give, manage, review and withdraw consent through an accessible, transparent and interoperable platform.

Significant Data Fiduciary

A Data Fiduciary notified by the Central Government based on factors such as volume and sensitivity of personal data, risk to Data Principals, impact on sovereignty and integrity of India, security of the State and public order. Significant Data Fiduciaries have additional obligations.

Data Protection Officer

An individual appointed by a Significant Data Fiduciary to represent it under the Act and act as a point of contact for grievance redressal and compliance matters.

Personal Data Breach

Any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access that compromises confidentiality, integrity or availability of personal data.

Data Protection Board of India

The authority established to determine non-compliance, inquire into breaches and impose penalties under the DPDP framework.

Data Principal Rights

The rights available to individuals, including access, correction, updating, erasure, grievance redressal and nomination. Operationally, these rights require systems, vendors and workflows to respond within defined timelines.

Data Minimisation

The principle that organisations should collect and process only the personal data necessary for the specified purpose.

Storage Limitation

The principle that personal data should not be retained beyond the period necessary for the purpose, unless retention is required under law.

Security Safeguards

Reasonable technical and organisational measures used to protect personal data from breach, misuse, unauthorised access or loss. Where raw PII is spread across logs, test environments or support tools, organisations may also evaluate Privault for tokenised PII protection.

Most organisations make a mistake when they ask, are we a Data Fiduciary or a Data Processor?

The better question is:

What role do we play for this specific processing activity?

A company can play different roles across different workflows.

Example 1: HR and payroll

An employer collecting employee personal data for hiring, salary processing, benefits, performance and retention is usually the Data Fiduciary for that employee data.

A payroll vendor processing salary, tax and bank information on the employer’s instructions may act as a Data Processor.

If the payroll vendor uses employee data for its own analytics, benchmarking or independent product development, role analysis may change for that separate activity.

Example 2: Banking and fintech

A bank deciding why borrower data is collected for KYC, underwriting, fraud checks, servicing and regulatory retention is usually the Data Fiduciary.

A fintech platform, KYC API provider, bureau integration partner, collection agency or cloud vendor may act as a Data Processor when it processes personal data only on the bank’s instructions.

But where a fintech independently decides how to use customer data for its own cross-sell, analytics, scoring, retention or marketing purposes, it may become a Data Fiduciary for those purposes.

Example 3: E-commerce and marketplaces

A marketplace collecting buyer and seller data for account creation, order fulfilment, payments, returns, loyalty and fraud prevention will often act as a Data Fiduciary.

Delivery partners, payment gateways, customer-support tools and marketing platforms may act as processors for specific activities, depending on their role and instructions.

Example 4: Healthcare and healthtech

A hospital or healthtech platform deciding how patient data is collected and used for appointments, diagnostics, billing, insurance and communication will often act as a Data Fiduciary.

A lab, teleconsultation tool, billing vendor, cloud provider or appointment platform may act as a Data Processor where it processes data on documented instructions.

Example 5: SaaS platforms

A SaaS company may be a processor when it stores or processes its customer’s user data only to provide the contracted service.

But it may become a fiduciary for its own website leads, employee data, product analytics, marketing database or independent AI training purposes.

This is why every organisation needs an activity-level role map.

Without role mapping, vendor contracts, consent notices, Data Principal rights, retention rules and audit evidence become inconsistent.

Understanding the difference between Data Principal, Data Fiduciary and Data Processor is only the first step.

The real compliance work starts when you map these roles across actual systems, vendors, purposes and data flows.

For every processing activity, your organisation should be able to answer:

• Who is the Data Principal?
• Which organisation determines the purpose and means of processing?
• Which vendors or platforms process data on behalf of the Data Fiduciary?
• What personal data categories are involved?
• What notice or consent applies?
• Which systems store or transmit the data?
• Which vendors receive the data downstream?
• How long is the data retained?
• Who handles Data Principal rights?
• What evidence proves the role allocation?

A static glossary can help teams understand the words.

But a DPDP readiness programme needs an operational map.

OpenBlockAI Discovery Studio helps organisations map personal data, systems, vendors, processing activities, role ownership, RoPA inputs, retention gaps, DPIA triggers and audit evidence before implementation.

It can help convert scattered team knowledge into a structured DPDP readiness baseline.

Use Discovery Studio to map your Data Fiduciary, Data Processor and Data Principal responsibilities.

Book a DPDP readiness discussion with OpenBlockAI.

The organisations that get DPDP right will not only know the definitions.

They will know exactly where each role applies across every customer, employee, vendor and product workflow.