The DPDP Act is live. Fines reach ₹250 Cr, and every day matters.Run a free check
DPDPHealthcareHealthtechCompliance

DPDP for Healthcare and Healthtech: Consent, Sensitive Data and Sector Rules

20 June 20268 min readBy Sammati

Hospitals, diagnostic labs, telemedicine platforms, and health-insurance-adjacent products handle some of the most intimate personal data there is. It is tempting to assume India's Digital Personal Data Protection Act, 2023 treats health data as a special, ring-fenced category — the way the older IT Act SPDI Rules and GDPR do. It does not. Understanding that single fact changes how you build for compliance.


DPDP has no "sensitive personal data" tier

The DPDP Act regulates digital personal data as a single class. Unlike the Information Technology (SPDI) Rules, 2011 — which named health, biometric, and financial information as "sensitive personal data or information" — the DPDP Act draws no statutory distinction between ordinary and sensitive categories. A patient's diagnosis and a customer's email address are governed by the same obligations: lawful basis, notice, purpose limitation, security, retention limits, breach reporting, and Data Principal rights.

This is counter-intuitive, so be precise about it in your own documentation. Health data is not legally "more protected" under DPDP — but it is higher-risk in practice, because a breach is more harmful and you are more likely to be designated a Significant Data Fiduciary (SDF).

What to do: Don't build a separate "sensitive data" compliance track expecting the Act to define one. Apply the full DPDP obligation set to all patient data, and treat health data as high-risk in your own risk register and security design rather than as a distinct statutory class.


Consent, and the medical-emergency exception

Most processing of patient data for non-treatment purposes — marketing, analytics, research partnerships, app personalisation — needs consent that is free, specific, informed, unconditional, and unambiguous (§6). The notice that precedes it must itemise the data collected, the purposes, and how to withdraw consent or raise a grievance (§5; DPDP Rules, 2025, Rule 3).

But healthcare has a built-in pressure valve. The Act lists certain legitimate uses that do not require fresh consent (§7), and one of them is processing necessary for responding to a medical emergency involving a threat to the life or immediate health of the Data Principal or another individual. Processing for the purpose of providing medical treatment or health services during an epidemic, outbreak, or threat to public health is also covered.

What to do: Map every processing activity to a basis. Emergency and acute-care processing can rely on the §7 legitimate use; elective, commercial, and secondary uses (research cohorts, marketing, third-party analytics) need consent. Document which is which — a regulator will ask you to show your basis per purpose.


Children's health data is stricter, not looser

Paediatric care, child nutrition apps, and family-health products process the data of minors. The Act requires verifiable parental consent before processing a child's personal data, and a child is anyone under 18 (§9). The Rules set out how to verify the parent is an adult (Rule 10). The Act also bars tracking, behavioural monitoring, and targeted advertising directed at children — a hard limit for any health app monetising on engagement. See our guide to verifiable parental consent for the operational detail.

What to do: If any user can be a minor, build a parental-consent path before processing, and switch off behavioural analytics and ad targeting for those accounts.


How DPDP sits alongside sector frameworks

DPDP does not displace sector regulation — it stacks on top of it. Healthcare entities already operate under a web of frameworks: clinical-establishment registration, telemedicine practice guidelines, IRDAI rules for insurers, and the Ayushman Bharat Digital Mission's health-data ecosystem with its own consent architecture. Where a sector rule is stricter or more specific, you comply with both.

LayerExample obligationRelationship to DPDP
DPDP Act, 2023Consent, notice, rights, breach reportingBaseline for all digital personal data
Sector health-data frameworksFederated consent, ABHA-linked recordsCoexist; often more granular for clinical data
Insurance (IRDAI)Policyholder data handlingSector regulator obligations apply in addition

What to do: Treat DPDP as the floor, not the ceiling. Build your consent and rights stack to DPDP, then layer sector-specific consent semantics on top rather than replacing one with the other.


Data residency and cross-border transfers

There is no blanket data-localisation mandate for health data in the Act. Personal data may be transferred outside India, subject to any requirements the Central Government specifies by general or special order (DPDP Rules, 2025, Rule 15) — a restriction model, not an approved-country whitelist. If you are designated an SDF, the Government may additionally require specific categories of data to be localised (Rule 13(4)). Sector regulators may impose their own residency expectations independently.

What to do: Inventory where patient data physically lives — EHR vendors, cloud regions, analytics processors offshore. Keep the architecture flexible so you can localise a notified category quickly if you are designated an SDF.


Breach reporting is unforgiving for health data

A personal data breach involving health records must be reported. The Act requires intimation to the Data Protection Board and to affected individuals (§8(6)), and the Rules set out the mechanics: notify each affected Data Principal without delay, and give the Board an initial intimation without delay followed by a detailed report within 72 hours (Rule 7). There is no materiality threshold — a breach is reportable regardless of how many records are involved. Our breach-reporting playbook walks through the full workflow.

What to do: Pre-draft your Board intimation and patient-notification templates now. In a real incident you will not have time to compose them inside the 72-hour window.


A practical build order for health products

  • Map data and purposes — every processing activity, its lawful basis (§6 consent or §7 legitimate use), and its retention limit (§8(7)).
  • Build consent and notice — itemised notices (Rule 3), withdrawal as easy as giving (§6(4)).
  • Wire up rights — access (§11), correction and erasure (§12), and grievance (§13). See Data Principal rights under DPDP.
  • Lock down security and breach response — reasonable safeguards (Rule 6) and the 72-hour Board report (Rule 7).
  • Assess SDF exposure — volume and sensitivity make large health platforms credible SDF candidates.

Frequently asked questions

Does DPDP treat health data as "sensitive personal data"?

No. The Act regulates all digital personal data as a single class and creates no statutory "sensitive" tier — a real departure from the older IT Act SPDI Rules and from GDPR. Apply the full obligation set to patient data, and treat it as high-risk in your own design rather than as a special legal category.

Can we process patient data in an emergency without consent?

Yes, where it is necessary for responding to a medical emergency involving a threat to the life or immediate health of an individual — this is a listed legitimate use (§7). Document that basis at the point of care. Elective, research, and marketing uses still need consent.

Do we have to keep health data inside India?

There is no blanket localisation mandate. Personal data may be transferred outside India unless the Central Government restricts it by order (Rule 15), and SDFs may be required to localise specific notified categories (Rule 13(4)). Sector regulators can add their own residency expectations, so check those alongside DPDP.

Are clinics and small practices in scope?

Yes. DPDP applies to any Data Fiduciary processing digital personal data, regardless of size. Smaller practices are unlikely to be designated SDFs, but the baseline duties — notice, consent, rights, breach reporting — apply to everyone.


How Sammati helps healthtech

Sammati is a consent management platform (CMP) and Data Processor — not a registered Consent Manager — built for regulated data:

  • Itemised, versioned consent notices in all 22 Eighth Schedule languages, with per-purpose lawful-basis tracking
  • Immutable, hash-chained consent records that survive audit and litigation
  • Rights-fulfilment workflows for access, correction, erasure, and grievance, with the 90-day grievance ceiling (Rule 14(3)) enforced
  • Deployment patterns (BYOC / in-VPC) that keep patient data inside your own environment and ease localisation

Check your DPDP readiness or talk to our team about healthtech compliance.

Check your DPDP compliance readiness

62 questions · 15 obligation areas · Instant results · No login

Take the Assessment

More from the library

Browse all posts