Data Fiduciary vs Data Processor under DPDP: Roles and Responsibilities
Answer-first guide to who decides purpose and means, who acts on instructions, and how contracts should allocate DPDP work without shifting fiduciary accountability.
“Data Fiduciary” means the person who determines the purpose and means of processing; “Data Processor” means a person who processes personal data on the fiduciary’s behalf.
Section 8 places responsibility for compliance on the Data Fiduciary even when processing is outsourced; using a processor does not transfer that accountability.
A valid contract is the Act’s express basis for engaging a processor. Detailed clauses on instructions, security, sub-processors, rights support, breach escalation and deletion are recommended controls, not one universal statutory checklist.
The role depends on the activity. A SaaS provider, BPO or marketplace may be a processor for one use and a fiduciary for another if it decides an independent purpose.
Timing matters: the definitions are in force, while key substantive fiduciary duties and most related Rules are scheduled to commence around May 2027. Recheck official notifications before relying on a deadline.
Data Fiduciary vs Data Processor: the short answer
A Data Fiduciary is the person who determines the purpose and means of processing digital personal data. A Data Processor processes that data on behalf of the fiduciary. The fastest test is: who decides why the data is used and the essential way it is used? That party is the fiduciary for that activity.
Outsourcing does not outsource DPDP accountability. Section 8(1) provides that a Data Fiduciary remains responsible for compliance for processing undertaken by it or on its behalf. Section 8(2) permits engagement of a processor for offering goods or services only under a valid contract. The contract can assign operational tasks, evidence and remedies, but it cannot erase the fiduciary’s statutory accountability.
Current-status note (29 August 2026): the Act’s definitions are in force. Under the Central Government’s commencement notification and the Digital Personal Data Protection Rules, 2025, key substantive obligations in sections 3–17 and most operational Rules are scheduled for the 18-month tranche, around May 2027. Organisations can prepare now, but should recheck official notifications before treating any duty or date as operative.
Definitions and role test under the DPDP Act
Data Fiduciary: the person who alone or with others determines the purpose and means of processing personal data. Data Processor: a person who processes personal data on behalf of a Data Fiduciary. These are the Act’s own labels; GDPR controller/processor concepts can help by analogy, but they are not a substitute for the Indian text.
Use a three-question role test for each processing activity: (1) Who chose the purpose? (2) Who controls essential means such as data categories, individuals, retention and disclosures? (3) Is the vendor limited to documented instructions? If your organisation controls the first two and the vendor stays within instructions, the usual position is fiduciary–processor. If the vendor chooses a separate purpose, it may be a fiduciary for that activity.
Examples are context-specific. An employer will generally be the fiduciary for employee records and an HRMS may process them on instructions. A SaaS platform may be a processor for hosting but a fiduciary for independently chosen cross-client analytics. A marketplace may be a fiduciary for account and order purposes, while a logistics or support vendor may act as processor for the scoped service.
Do not label an entire vendor once and stop. Build an activity-level matrix covering purpose, data categories, instructions, retention, sub-processors, disclosures and independent reuse. Where responsibilities are shared or purposes diverge, obtain legal advice; the DPDP Act does not simply copy the GDPR’s joint-controller framework.
High-level comparison of data fiduciary and data processor roles under the DPDP Act.
Decision area |
Data fiduciary |
Data processor |
Procurement focus |
|---|---|---|---|
Who decides why and how personal data is processed |
Determines purposes (the “why”) and essential means (the “how”), including what data to collect, which individuals it relates to, retention, and sharing. |
Implements processing strictly according to the fiduciary’s documented instructions and does not set independent purposes. |
Clarify in RFQs and contracts who owns purpose decisions for each use case and document that role in the data processing agreement. |
Regulatory accountability under DPDP |
Remains responsible under section 8(1) for compliance in respect of processing undertaken by it or on its behalf. |
Carries out agreed processing on the fiduciary’s behalf. The Act does not create a general standalone processor-duty checklist equivalent to the fiduciary’s section 8 obligations; commitments commonly arise through contract and other applicable law. |
Keep statutory accountability with the fiduciary; use risk-based contract terms to assign processor tasks, evidence, escalation and remedies. |
Typical examples in B2B outsourcing |
Employers for employee data; banks and fintechs for borrower data; ecommerce platforms for customer orders. |
Payroll providers, HRMS or CRM platforms, cloud hosting providers, KYC vendors, and call centre BPOs. |
Use examples to sanity-check claimed roles and identify outliers that may need deeper legal review. |
Data use beyond the engagement |
May reuse data for its own compatible purposes consistent with notices and lawful grounds. |
Should not reuse or combine client data for its own independent purposes without becoming a fiduciary for that activity. |
Ask vendors about any data reuse, aggregation, or analytics across clients and ensure roles and consents align with those uses. |
Implications for contracts and governance |
Specifies instructions, security baselines, rights-handling model, and audit approach; maintains the vendor register and governance framework. |
Documents how it will implement instructions, security controls, sub-processor management, and cooperation on rights and breaches. |
Make roles explicit in data processing agreements and align them with internal RACI, approval workflows, and monitoring plans. |
Statutory accountability of the Data Fiduciary
Statutory position. Section 8(1) makes the Data Fiduciary responsible for compliance in respect of processing undertaken by it or on its behalf, and section 8(2) permits it to engage a Data Processor for offering goods or services only under a valid contract. Those substantive section 8 duties are scheduled to commence in the 18-month tranche, around May 2027.
Once operative, the fiduciary-duty framework covers the validity and accuracy of data used for decisions or disclosure, reasonable security safeguards, breach intimation, erasure when consent is withdrawn or the purpose is no longer served unless retention is legally necessary, contact and grievance mechanisms, and enabling applicable Data Principal rights. Check each obligation against the commenced Act and Rules.
Processor use does not change the accountable party. The fiduciary should therefore be able to show instructions, security expectations, rights-handling workflows, incident escalation, retention and deletion logic, and oversight evidence across its vendor chain. These records are practical evidence of governance; not every artefact is separately mandated by the Act.
Additional duties can apply to children’s data and to entities notified as Significant Data Fiduciaries. Cross-border processing is subject to any country or territory restrictions notified by the Central Government, as well as sector-specific rules. A generic DPDP vendor checklist does not override RBI, CERT-In or other applicable regimes.
Data Processor role: statutory limit and contract controls
Statutory boundary. A Data Processor is defined by acting on behalf of a Data Fiduciary. Section 8(2) speaks to the fiduciary engaging the processor under a valid contract; the Act does not set out a universal processor-only obligations schedule comparable to section 8 for fiduciaries. Avoid presenting every negotiated control as a direct statutory duty of the processor.
Recommended contract controls. Depending on risk, a data processing agreement can require processing only on documented instructions, confidentiality, agreed security measures, prompt incident escalation, assistance with Data Principal requests, retention and deletion, audit evidence, sub-processor governance, location transparency, data return at exit, and change-notification duties. These provisions allocate operations and remedies between the parties; they do not transfer the fiduciary’s statutory accountability.
Activity-by-activity limit. If a vendor chooses an independent purpose—such as cross-client profiling, its own marketing or retention for its own analytics—it may become a Data Fiduciary for that processing. Record each role separately for core service delivery, product telemetry, fraud controls, support, analytics and any independent reuse.
Responsibility matrix and processor-contract checklist
Use a two-layer matrix. Layer one records the statutory accountable party: for fiduciary obligations under the DPDP Act, the Data Fiduciary remains accountable even when a processor performs the task. Layer two records operational ownership: which vendor or internal team is responsible, consulted and informed for notices, rights requests, security, breaches, retention and deletion.
Recommended processor-contract checklist (risk-based, not a universal statutory list): scope and documented instructions; personal-data categories and purposes; confidentiality; security controls and evidence; incident escalation; rights-request support; retention, return and deletion; sub-processor approval or notice; data locations and transfer changes; audit and cooperation; exit assistance; liability, indemnity and insurance; and a process for legal or service changes. Tailor the list to the service and any sectoral rules.
Example—HR SaaS. The employer generally decides the employment purpose and essential means, so it is the fiduciary; the SaaS provider usually acts as processor for hosting and workflows. If the provider independently chooses to use identifiable employee data for cross-customer benchmarking or marketing, analyse that separate use as a possible fiduciary activity and contract for it separately.
Example—marketplace. The platform may be a fiduciary for user accounts, order orchestration and fraud decisions; sellers or service providers may be separate fiduciaries for their own legal and business purposes; support, hosting or logistics vendors may process scoped data on instructions. Map purpose and control for each data flow instead of forcing one label across the ecosystem.
Procurement toolkit: RFQ questions, vendor scorecard, and hidden-cost checklist
These procurement tools are recommended governance controls; the Act does not prescribe a single RFQ, scorecard or certification. Tailor them to the service, risk profile and applicable sectoral rules.
On role clarity, ask vendors to state, for each major processing activity, whether they act as a data processor, a data fiduciary, or both, and to explain the basis for that classification.
On security, request a description of their security governance, including how they manage access control, encryption, logging, backup and recovery, and vulnerability management, along with any independent assessments or certifications they hold.
On data principal rights, ask how they would support your organisation in fulfilling access, correction, and erasure requests, what standard response timelines they can support operationally, and what tooling exists for bulk or automated requests.
On sub-processing and cross-border transfers, require a current list of sub-processors and data locations, along with their approach to onboarding new sub-processors and reacting to changes in applicable transfer restrictions.
A structured vendor scorecard helps turn qualitative answers into comparable scores. One practical approach is to group criteria into a small number of weighted bands and assess each vendor against those bands using consistent evidence.
Example DPDP-aligned vendor scorecard bands for assessing processors.
Band |
What to evaluate |
Evidence to request |
Weighting considerations |
|---|---|---|---|
Compliance and DPDP alignment |
Clarity of fiduciary/processor role definitions, quality of contractual commitments, and evidence that the vendor understands DPDP obligations. |
Sample data protection addendum or privacy schedule, mappings of services to DPDP roles, relevant internal policies, and training materials. |
Give extra weight where the vendor handles large volumes, children’s data, high-impact uses or data regulated under sectoral rules. |
Security and resilience |
Technical safeguards, incident response maturity, business continuity arrangements, and any history of material security incidents. |
Security policies, architecture diagrams, incident response playbooks, summaries of recent independent assessments or tests, and high-level breach history disclosures. |
Prioritise for internet-facing platforms and services that would materially disrupt operations or reputation if compromised. |
Operational capability for data principal rights |
How easily access, correction, erasure, consent withdrawal, and data export orders can be implemented, and what level of support is offered to your teams. |
Product demonstrations, workflow or API documentation, sample reports, and descriptions of standard support processes for rights requests. |
Increase weight where you expect high request volumes, strict response timelines, or complex multi-system data flows. |
Data architecture and localisation |
Data residency options, segregation between clients, logging depth, and ease of data portability at exit. |
Data flow diagrams, list of data centres and sub-processors, export formats, log retention descriptions, and standard exit support scope. |
Weight heavily if your organisation is subject to localisation rules or has strict cross-border and concentration risk appetites. |
Commercial risk and total cost |
Liability caps, indemnity structure, insurance coverage, and the cost and effort of onboarding, integration, and potential exit. |
Draft contract terms, certificates of insurance, implementation plans, and rate cards for professional services or change requests. |
Align to your organisation’s risk appetite and the business criticality of the processing, not just to standard procurement thresholds. |
Using RFQ questions, a scorecard, and a hidden-cost checklist together allows procurement to compare vendors not only on headline pricing and functional fit but also on the depth of their DPDP readiness and the likely effort your organisation will bear. Vendors that appear cheaper on licence fees but require significant internal work to support consent, rights fulfilment, or audits may, in practice, be more expensive and riskier. Making these trade-offs explicit in evaluation documents helps leadership take informed decisions and allocate budgets for privacy-by-design rather than treating it as an afterthought.
Common questions for procurement teams about DPDP roles
Once the basic fiduciary–processor split is understood, many procurement questions focus on complex or hybrid scenarios. Multi-tenant SaaS platforms may act as processors for core functions but as independent fiduciaries for cross-client analytics. Joint offerings, such as co-branded credit cards or marketplace platforms, can involve two or more data fiduciaries sharing data and jointly shaping the customer journey. Global vendors may process personal data of Indian residents across multiple jurisdictions, raising questions about DPDP’s extraterritorial application, sectoral localisation rules, and contractual commitments to Indian standards. Frequently asked questions tend to centre on these edge cases, and clear answers help evaluation teams engage more confidently with vendors and internal stakeholders.
Putting a DPDP operating model in place for vendors
Embedding DPDP roles into vendor management is easier if you treat it as a structured rollout rather than a one-off compliance project.
-
Map personal data, systems, and vendors
A practical first action is to build or update a register of systems and vendors that process personal data. For each relationship, record what categories of individuals are involved, what data is processed, for what purposes, and where it is stored or accessed. Identify whether your organisation is acting as a data fiduciary, a data processor, or both, and whether the external party is a processor, a co-fiduciary, or an independent fiduciary for some purposes. Align this register with existing supplier segmentation so that high-risk and high-impact vendors receive more attention than low-risk utilities.
-
Align governance, templates, and procurement workflows
Standardise DPDP-aligned data processing clauses in your master service agreements and purchase order terms, and define clear thresholds where legal, information security, and privacy teams must review or approve vendor engagements before contracts are signed. Integrate DPDP-focused questions into your standard due diligence questionnaires and RFP templates so that every new processing relationship is assessed on roles, security, rights support, and cross-border factors from the outset. For organisations that are, or may become, Significant Data Fiduciaries, build more structured oversight into the operating model, such as periodic third-party assessments of key processors or deeper review of vendors handling children’s data or large-scale profiling.
-
Refresh existing contracts in risk-based waves
For existing suppliers, prioritise vendors that handle the largest volumes of personal data, children’s data, high-impact uses or critical business processes, and consider applicable sectoral rules. As contracts renew, refresh role definitions, security and incident terms, rights support, sub-processor transparency and data-location commitments. This is a risk-based governance approach—not a statement that the Act requires every contract to be renegotiated immediately.
-
Build ongoing visibility and board-ready reporting
Over time, a DPDP-aware operating model should give leadership a consistent line of sight across the personal data ecosystem: which vendors are critical from a fiduciary perspective, what controls are in place at each, how quickly incidents can be detected and contained, and where concentration or geographic risks are building up. That visibility, supported by clear contracts and procurement tools, makes regulatory compliance more defensible and helps your organisation treat privacy as part of business resilience rather than a purely legal concern.
Yes. Roles are determined for each processing activity. A SaaS provider may be a Data Processor for client-directed hosting and a Data Fiduciary for independently chosen cross-client analytics. Map the purposes, essential decisions and instructions separately instead of assigning one label to the whole vendor.
The DPDP Act does not create a blanket data-localisation rule. It permits the Central Government to restrict transfers to notified countries or territories, while RBI or other sectoral rules may impose separate requirements. Map storage, remote access, sub-processors and applicable sector rules, and contract for transparency, change notice and cooperation.
The definition allows a person to determine purpose and means alone or in conjunction with other persons. If two parties genuinely make those essential decisions together, each may be a Data Fiduciary for that activity. The Act does not use the GDPR term “joint controller” or establish an identical allocation regime, so document the decision-making and obtain advice for complex arrangements.
The Data Fiduciary remains responsible for compliance in respect of processing undertaken on its behalf, including use of processors. A processor incident can therefore expose the fiduciary to regulatory scrutiny once the applicable duties are operative. The processor may separately face contractual remedies or consequences under other applicable law, depending on the facts. Do not assume the processor automatically has the same standalone DPDP statutory liability as the fiduciary; draft incident, evidence and liability terms expressly.
The DPDP Act does not prescribe one certification or audit standard for every Data Processor. A Data Fiduciary can nevertheless require audits, assurance reports or certifications as risk-based contract controls, and other laws or sector regulators may impose separate expectations. Significant Data Fiduciary audit requirements attach to that notified fiduciary role, not automatically to every processor.
- The Digital Personal Data Protection Act, 2023 (No. 22 of 2023) - Ministry of Law and Justice, Government of India
- Digital Personal Data Protection Rules, 2025 - Ministry of Electronics and Information Technology, Government of India
- DPDP Act commencement notification (13 November 2025) - Ministry of Electronics and Information Technology, Government of India
- 2025 Update : Deep Dive – Digital Personal Data Protection Act (DPDPA), 2023 - Spice Route Legal
- India’s Digital Personal Data Protection Act 2023 vs. the GDPR: A Comparison - Latham & Watkins LLP
- Data Fiduciary and Data Processor Obligations Under DPDPA, 2023 - AMLEGALS
