The data fiduciary vs data processor question decides what a healthtech company owes under India’s Digital Personal Data Protection Act, 2023 (the DPDP Act), the law that governs how businesses use digital personal data, with most of its duties applying from 13 May 2027.

The Act’s chapter of duties is addressed to the data fiduciary, the business that decides the purpose and means of processing (ss.2(i), 8(1)). A company that runs software only on a hospital’s instructions is a processor. Once it uses that patient data for a purpose of its own, it becomes a fiduciary for that use. A|P’s reading, not settled law; confirm with counsel.

Take a seed-stage Pune patient-engagement company that sends appointment reminders for eight private hospitals. Its product team wants to train a no-show prediction model on all eight hospitals’ appointment histories and sell the predictions back as a premium feature. As a product idea, the model is sound. Whether it is a sound business depends on a prior question: whose purpose does the training serve?

This is the first Builder piece in A|P’s DPDP series. The series guide page, The DPDP Act and Rules for Indian healthcare businesses, holds the timeline and the notifications to watch; this piece works one question from it through for founders.

Why is your DPDP role a product decision, not a compliance task?

A|P’s product-market fit framework for healthtech startups in India sets two checks before any building starts: founder-market fit and regulatory-market fit. The second rests on one idea: “Regulation isn’t a pre-launch checklist item — it’s a constraint on which products are even viable in a given market”. So regulation should shape the product hypothesis from the start, not get handled after launch.

The DPDP Act turns that idea into a concrete test for any product that touches hospital data. Your role in each data flow decides which duties you carry. Those duties decide which revenue lines are practical. That puts the role question on the healthtech regulatory pathway in India, next to device classification and clinical approvals, and in the product plan rather than the compliance backlog.

Data fiduciary vs data processor: how does the DPDP Act decide?

The Act defines a data fiduciary as “any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data” (s.2(i)). A data processor is “any person who processes personal data on behalf of a Data Fiduciary” (s.2(k)). The patient is the data principal (s.2(j)).

The test turns on facts, not labels. If you decide why patient data is used, you are a fiduciary for that use, whatever your contract with the hospital calls you. The words “in conjunction with other persons” also mean that two businesses can be fiduciaries for the same flow, for example a vendor and a hospital that design a data product together. A|P’s reading, not settled law; confirm with counsel.

From 13 May 2027, the Act makes the fiduciary responsible for compliance “irrespective of any agreement to the contrary”, including for processing a processor does on its behalf (s.8(1)). The fiduciary may use a processor “only under a valid contract” (s.8(2)), and the DPDP Rules, 2025 require that contract to provide for reasonable security safeguards (Rule 6(1)(f)). The duties in Chapter II and the patients’ rights in Chapter III run against the fiduciary. A processor’s obligations reach it through the contract it signs with its hospital client. A|P’s reading, not settled law; confirm with counsel.

Today, a healthtech vendor’s duties are its own

Until 13 May 2027, health data held by a company is governed by the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 (the SPDI Rules), made under section 43A of the Information Technology Act, 2000. The SPDI Rules treat medical records and health conditions as sensitive personal data (rule 3), and several of their duties apply to a “body corporate or any person on its behalf”.

That wording names the vendor directly. A healthtech company that stores or handles a hospital’s patient records must today publish its own privacy policy (rule 4) and keep the data secure as rule 8 provides (rules 5(8) and 8). A|P’s reading, not settled law; confirm with counsel. The Rules also say that information collected “shall be used for the purpose for which it has been collected” (rule 5(5)), without naming who is bound. Section 43A itself makes a body corporate handling sensitive personal data liable to pay compensation when its negligence in security causes wrongful loss.

On 13 May 2027 that picture flips. Section 44(2) of the DPDP Act removes section 43A and the rule-making power the SPDI Rules were made under (s.44(2)(a), (c)). A vendor acting only on a hospital’s instructions then has no duties of its own under the DPDP Act, and its exposure moves into the hospital’s contract. A|P’s reading, not settled law; confirm with counsel.

Two consequences follow for founders. First, reusing hospital data for your own product is already restricted today, by rule 5(5), not only from 2027. A|P’s reading, not settled law; confirm with counsel. Second, from 13 May 2027 your hospital clients carry the duties, so expect them to push those duties into your contract as security clauses, breach timelines and audit rights, a shift that belongs in your go-to-market strategy for healthtech startups in India.

The DPDP Act for healthtech startups: four business models, mapped

This piece groups healthtech companies that handle hospital data into four models; many companies mix them. The role follows each data flow, so a single company can be a processor in one flow and a fiduciary in another.

Software run for hospitals

A hospital information system, revenue cycle management (billing and insurance-claims) software, or a clinical workflow tool processes patient data on the hospital’s instructions. For that data, the vendor is a processor. A|P’s reading, not settled law; confirm with counsel. It is still a fiduciary for data it uses for its own purposes, such as its own sales leads and its employees’ records. Revenue comes from licence and subscription fees, which need no use of patient data beyond the service itself.

Software plus data reuse

The same software becomes a different business when the vendor also uses hospital data for its own ends: cross-client benchmarking, product analytics, AI model training or selling insights. For each of those uses the vendor decides the purpose, the s.2(i) test for a fiduciary. A|P’s reading, not settled law; confirm with counsel. The Act changes this model most, because its revenue depends on a use the patients were never asked about.

Platform serving hospitals and patients

Some companies sell software to hospitals and also run an app that patients sign up to directly. They are a processor for the hospital’s flows and a fiduciary for the app relationship. A|P’s reading, not settled law; confirm with counsel. The app is an asset: it is the company’s own channel to give patients notice and ask for consent. The cost is discipline, keeping data tagged by the flow it came from so hospital data doesn’t drift into the company’s own uses.

Direct-to-patient app

A telemedicine or chronic-care app that patients use directly is a fiduciary for its users’ data. A|P’s reading, not settled law; confirm with counsel. The Act’s own illustration for consent uses one: a telemedicine app that asks for access to the user’s phone contacts gets valid consent only for the telemedicine service, because the contact list isn’t needed for it (s.6(1)). For this model the role is clear; what is left is consent design.

What does becoming a data fiduciary cost a healthtech company?

From 13 May 2027, a vendor that becomes a fiduciary for a use takes on, for that use, the duties a hospital carries. The first is a legal basis of its own. Every processing purpose needs either the person’s consent or one of the “certain legitimate uses” in section 7 (s.4).

The legitimate use most often cited, data “voluntarily provided” for a specified purpose (s.7(a)), covers data the patient provided “to the Data Fiduciary”. The patient gave the data to the hospital, for care. That leaves consent as the vendor’s route for its own uses. A|P’s reading, not settled law; confirm with counsel.

Consent brings its own machinery. From 13 May 2027, every request must be accompanied or preceded by a notice (s.5(1)) that meets Rule 3: understandable on its own, with an itemised list of the data and the specific purposes. Withdrawing consent must be as easy as giving it (s.6(4)), and in any proceeding the fiduciary must prove both notice and consent (s.6(10)). A vendor with no patient-facing channel has no obvious way to give that notice or keep that proof. A|P’s reading, not settled law; confirm with counsel.

From 13 May 2027, the rest of the fiduciary’s duties follow the use:

• Patients’ rights: access to a summary of their data and of everyone it was shared with (s.11), correction and erasure (s.12), grievance redressal (s.13) and nomination (s.14).
• Security and breaches: Rule 6’s minimum safeguards, and intimation of any breach to each affected patient and to the Data Protection Board of India, the regulator, with a detailed report to the Board within 72 hours (s.8(6), Rule 7).
• Retention: personal data, traffic data and processing logs kept for at least one year from the processing, then erased unless another law requires longer (Rule 8(3)).
• Children: verifiable consent from a parent before processing the data of anyone under 18 (ss.2(f), 9(1); Rule 10), and no tracking, behavioural monitoring or targeted advertising directed at children (s.9(3)).

The children’s rule reaches further into healthtech than the exemption suggests. Part A of the Fourth Schedule, read with Rule 12, lifts the parental-consent and tracking rules for clinical establishments, mental health establishments and healthcare professionals providing health services to the child, and for allied healthcare professionals supporting a treatment and referral plan, in each case “to the extent necessary for the protection of her health”.

A healthtech platform is none of these classes, and none of the purposes in Part B covers training a model for the vendor’s own product. From 13 May 2027, a no-show model trained on a paediatric hospital’s appointment data for the vendor’s own product would need verifiable parental consent. A|P’s reading, not settled law; confirm with counsel.

Scale adds a further exposure. From 13 May 2027, the government may designate a fiduciary as a Significant Data Fiduciary on factors that include the volume and sensitivity of the data it processes (s.10(1)). A vendor pooling patient data from many hospitals raises both. A|P’s reading, not settled law; confirm with counsel.

From 13 May 2027, a designated fiduciary must appoint a Data Protection Officer and an independent data auditor (s.10(2)), and run a Data Protection Impact Assessment and an audit every twelve months (Rule 13(1)). It must also check that its algorithmic software does not put patients’ rights at risk (Rule 13(3)). As of the guide page’s last check on 4 October 2026, no Significant Data Fiduciary had been designated.

Penalties set the stakes. From 13 May 2027, the Schedule to the Act allows the Board to impose up to ₹250 crore for failing to take reasonable security safeguards, and up to ₹200 crore for breaching the obligations on children’s data.

How can a healthtech company build data products without becoming a fiduciary by accident?

There are three routes. None is a loophole: each changes who decides the purpose, or whose relationship carries the consent.

Keep the hospital as the decision-maker

Design the feature so that each hospital decides to use its own data for its own patients, under its own notice, and you act on its instructions. A no-show model trained separately for each hospital, on that hospital’s data, for that hospital’s use, keeps you a processor. Pooling eight hospitals’ data into a model you own and sell is a purpose you decide. A|P’s reading, not settled law; confirm with counsel.

Build your own patient relationship

A patient app with its own sign-up gives you the channel for notice and consent (ss.5, 6; Rule 3). From 13 May 2027, consent has to be specific to each purpose and limited to the data that purpose needs (s.6(1)). A hospital’s notice can also name your purpose, but you then depend on every client hospital collecting that consent properly. A|P’s reading, not settled law; confirm with counsel.

Read the research exemption narrowly

Section 17(2)(b), which takes effect on 13 May 2027, takes processing out of the Act when it is “necessary for research, archiving or statistical purposes if the personal data is not to be used to take any decision specific to a Data Principal”, and meets prescribed standards. Rule 16 and the Second Schedule set those standards: lawful processing, only the data necessary, reasonable accuracy, retention only as long as needed, security safeguards and clear accountability.

A model whose output is a prediction about a named patient, such as “this patient is likely to miss tomorrow’s appointment”, is built to inform decisions about specific people. Whether training it can count as research is unsettled. A|P’s reading, not settled law; confirm with counsel.

Two things that look like routes are not. First, the Act covers data about an individual “who is identifiable by or in relation to such data” (s.2(t)), but neither the Act nor the Rules set a test for when de-identified data stops being identifiable. A|P’s reading, not settled law; confirm with counsel.

Second, from 13 May 2027, s.17(3) lets the government exempt notified fiduciaries or classes of fiduciaries, including startups, from notice, accuracy, erasure, Significant Data Fiduciary and access duties. It does not remove the need for a legal basis under s.4, and as of 4 October 2026 the government had notified no such exemption.

A five-step test for your product

Run this on your current product and on the next feature on your roadmap. It needs a whiteboard and an hour; a lawyer should see the result.

1. List every flow of patient data your product touches. Collection, storage, analytics, model training, sharing with partners, support access.
2. Write down who decided the purpose of each flow. The hospital, you, or both together.
3. Mark each flow processor or fiduciary. Any flow where you wrote “us” or “both” is a fiduciary flow. A|P’s reading, not settled law; confirm with counsel.
4. For each fiduciary flow, name the legal basis and the channel for notice. If there is no channel to reach the patient, the flow needs redesigning or dropping. A|P’s reading, not settled law; confirm with counsel.
5. Check your hospital contracts and your data for two things. Does any contract limit your use of data to providing the service? Does any flow include patients under 18? Either one changes what a reuse feature costs.

The no-show model, revisited

Trained separately for each hospital, on that hospital’s instructions, the no-show model is a processor feature that the hospital’s own notice covers. Trained on the pooled data of eight hospitals and sold as the vendor’s product, it makes the vendor a fiduciary towards patients it has never spoken to. A|P’s reading, not settled law; confirm with counsel. The code can be identical; the business models are not. That is where the data fiduciary vs data processor line really runs: through the business model, not the software.

So the decision for the founder is not a compliance question. It is a product question: is the pooled model valuable enough to justify building a patient relationship of your own, or is the per-hospital version the product?

Next in the series: Selling to Indian hospitals after the DPDP Act, on what hospital procurement will ask a processor to sign.

Frequently asked questions about data fiduciaries and data processors in healthtech

What is the difference between a data fiduciary and a data processor under the DPDP Act?

A data fiduciary decides the purpose and means of processing personal data (s.2(i)); a data processor processes it on a fiduciary’s behalf (s.2(k)). From 13 May 2027, the fiduciary is responsible for complying with the Act, including for its processors’ work (s.8(1)), and may use a processor only under a valid contract (s.8(2)).

Can a healthtech company use hospital patient data to train an AI model under the DPDP Act?

From 13 May 2027, only with a legal basis of its own when the training serves the company’s own purpose. In practice that means patient consent, or the research exemption in s.17(2)(b) if its conditions are met. Whether model training counts as research is unsettled. A|P’s reading, not settled law; confirm with counsel.

Are healthtech startups exempt from the DPDP Act?

No. From 13 May 2027, section 17(3) lets the government exempt notified fiduciaries or classes of them, including startups, from some duties: notice, accuracy, erasure, Significant Data Fiduciary duties and access. As of 4 October 2026 no such notification had been issued, and the power does not cover the need for consent or another legal basis.

Does the DPDP Act apply when an Indian healthtech team processes US patients’ data?

Mostly not. From 13 May 2027, when a company in India processes the data of people outside India under a contract with a person outside India, most fiduciary duties and patients’ rights do not apply (s.17(1)(d)). The fiduciary’s overall responsibility and its duty to take reasonable security safeguards still do (s.8(1), (5)).