If you have spent any time around healthcare data protection outside India, you have probably internalized a simple mental shortcut: health data is "special category" data. GDPR calls it out explicitly in Article 9. HIPAA builds an entire regulatory architecture around "protected health information." The assumption baked into most privacy programmes is that the law itself will tell you which fields deserve the highest tier of protection, and your job is to build controls around that tier.
The Digital Personal Data Protection Act, 2023 does not give you that shortcut.
DPDP does not create a special category for health data. A patient's name sits, legally, in the same bucket as their diagnosis, their HIV status, their psychiatric history, or their insurance claim number. The Act's obligations around notice, consent, security safeguards and breach reporting apply uniformly to all personal data, full stop. For most sectors this is a simplification. For healthcare, it is a trap — because it means the law will not do your risk triage for you. You have to build that risk tiering yourself, on top of a compliance floor that treats a patient's mobile number and their oncology report as legally identical.
I have spent the better part of two decades sitting in hospital IT steering committees and, more recently, in DPDP readiness reviews for hospital chains, diagnostic networks and health insurers. The pattern is consistent: organizations that treat DPDP as "GDPR with an Indian accent" build the wrong programme. The obligations look similar on paper. The operating reality of a 400-bed hospital, a 900-centre diagnostic chain, or a TPA processing lakhs of claims a month, is a different animal entirely. This article is about that reality — what the Act actually requires, where healthcare organisations genuinely struggle to meet it, and what a defensible programme looks like.
Where health data actually lives
Ask a hospital CIO where patient data resides and you will usually get an answer describing the Hospital Information System. That answer is wrong the moment you look past the front door.
A single patient encounter typically touches: the HIS for registration, billing and discharge summaries; a separate Laboratory Information System for pathology; a Radiology Information System and PACS for imaging; a pharmacy management system for dispensing; an empanelled diagnostic partner for tests the hospital doesn't run in-house; a TPA or insurer's portal for cashless claim processing; a referring doctor's own clinic software; and, increasingly, a patient-facing app or WhatsApp thread where reports get shared because it's faster than the official portal. Add a diagnostic chain's own topology — hundreds of collection centres feeding a handful of central labs, each hop a potential point of loss — and you get a data landscape that no single system inventory will ever capture.
This matters under DPDP for a specific reason: Section 8 places the obligation for accuracy, security and breach response on the Data Fiduciary regardless of where the data physically sits or who technically caused the failure. If your empanelled lab's vendor loses a laptop with unencrypted reports, the reputational and regulatory exposure is still substantially yours. Most healthcare organizations I have reviewed do not have an accurate, current map of where personal data lives across this network — they have an org chart of systems someone built for a NABH audit three years ago. A data map that is accurate today and stale in six months is not a compliance artefact. It's a liability with a delay timer on it.
Consent is not one thing in a hospital
The instinct in a lot of hospital compliance teams is to solve consent once: put up a consent form at registration, get a signature, move on. DPDP does not let you get away with that, because a single patient journey can trigger several different legal bases in sequence, each with different rules.
Routine, non-emergency treatment runs on Section 6 consent — free, specific, informed, unconditional and revocable, with a notice under Section 5 that actually explains what will be collected and why, in a language the patient understands, not a boilerplate paragraph buried in the admission form.
An unconscious patient wheeled into the ER runs on Section 7(f) — the medical emergency exception, which permits processing without consent where there is a threat to life or immediate threat to health. But this exception has a clock on it that most hospitals never operationalize. The legal basis for accessing that patient's history evaporates the moment the emergency resolves and the patient is conscious and stable. From that point, continuing to process their data — for billing, for follow-up care, for anything beyond the emergency itself — needs a proper consent event, ideally including a retroactive explanation of what was accessed during the emergency. In practice, almost no hospital I have reviewed has a defined trigger for "the emergency has ended, switch legal basis now."
Epidemic and public health response — contact tracing, outbreak surveillance, vaccination drives — runs on Section 7(g), and again it is purpose-bound and time-bound. It is not a general licence to keep using outbreak-era data once the outbreak has passed.
Then there is everything that isn't treatment at all: clinical research, secondary analytics on de-identified cohorts, patient engagement apps, marketing for a wellness package. None of this can piggyback on the consent a patient gave to be treated. Conflating "consent to treat" with "consent to use my data for your research paper or your app's engagement metrics" is one of the most common — and most exposed — practices I encounter in hospital groups building digital products alongside their clinical operations.
Children in the system
Paediatric wards, vaccination camps, school health check-ups, and children's hospitals sit inside one of the more nuanced parts of DPDP. Section 9 requires verifiable parental or guardian consent before processing a child's personal data, and prohibits tracking, behavioural monitoring or targeted advertising directed at children — full stop, no exceptions for "it's for their own good."
The Rules issued in 2025 do carve out relief here, and it is worth getting precise about its scope. Clinical establishments, mental health establishments and healthcare professionals are exempted from the verifiable-consent requirement specifically where the processing is necessary to deliver health services or a treatment plan in the child's interest. This is a narrow, purpose-bound exemption — regulators and legal commentators have been consistent that it does not extend to analytics, profiling, engagement tracking in a companion app, or any use of the child's data beyond the immediate clinical purpose. A paediatric hospital treating a child under this exemption is on solid ground. The same hospital using that child's data to power a parent-facing engagement app with usage analytics is not, and needs to go back to Section 9's default rule: verifiable parental consent, full stop.
The rights problem at hospital scale
Sections 11 through 14 give every patient the right to access what data you hold on them, correct or erase it, raise a grievance, and nominate someone to exercise these rights on their behalf after death or incapacity. These read as reasonable, almost obvious, individual rights. They become genuinely hard to operationalize the moment you have more than one facility.
Most hospital chains I have worked with do not have a single, de-duplicated patient identity. A patient who visited three branches over five years frequently exists as three or four separate MRD numbers, none of them cleanly linked, each holding a slightly different slice of the record. When that patient exercises a right to access or correction, "find everything we hold on this person" is not a database query — it's a project. Layer onto this the fact that clinical establishment regulations and medical council guidance require hospitals to retain certain categories of medical records for defined periods (often measured in years, longer for medico-legal cases), and you have a genuine tension with the Section 8(7) principle that data should be erased once its purpose is served. The resolution is not to ignore either obligation — it's to document, per category of record, exactly which retention period applies and under which law, so that an erasure request can be answered correctly rather than reflexively refused or reflexively honoured.
Two clocks, one breach
Healthcare has become one of the more frequently targeted sectors for ransomware in India, for an unglamorous reason: hospitals cannot afford operational downtime the way a retailer can, which makes them more likely to pay, which makes them a more attractive target. The sector-wide memory of a major government hospital's systems being knocked offline for weeks by a ransomware attack, with patient data potentially exposed, is not abstract risk modelling — it happened, it was widely reported, and it changed how seriously hospital boards take this conversation.
Under the DPDP Rules notified in 2025, a personal data breach triggers a two-stage notification process once the breach provisions come into force: an initial intimation to the Data Protection Board "without delay" — alongside notification to affected individuals, with no materiality threshold that would let you skip notifying a "low-risk" breach the way GDPR permits — followed by a detailed report to the Board within 72 hours of becoming aware of the breach. The clock starts at awareness, not at the conclusion of your forensic investigation, and it runs through weekends and 2 a.m. alike.
For most hospitals, this DPDP clock is not the only one running. Where a breach involves a cybersecurity incident — which most ransomware and hacking-driven breaches do — CERT-In's 2022 directions impose a separate, much tighter six-hour reporting window to CERT-In itself. These obligations stack. A single incident can require action on two independent regulatory timelines simultaneously, and I have yet to see a hospital incident response runbook that names an owner for both clocks rather than treating "regulatory reporting" as one generic task.
Vendors, insurers, and where the data actually flows next
A hospital's own systems are rarely the riskiest part of its data footprint. The riskier part is everything downstream: the TPA processing a cashless claim, the insurer receiving diagnosis codes to adjudicate that claim, the diagnostic partner running a specialised test you don't do in-house, the reinsurer sitting behind the insurer — sometimes outside India entirely, which brings Section 16's cross-border transfer provisions into play. DPDP takes a blacklist approach here rather than GDPR's adequacy model: transfers are permitted by default except to jurisdictions the Central Government specifically restricts. That is more permissive than many hospital compliance teams assume, but it does not remove the obligation to know where the data is actually going, under what contract, and with what security commitments from the receiving party. Section 8 requires a Data Fiduciary to ensure its processors are bound to the same standard of protection — a requirement that a decade-old vendor empanelment contract, written before DPDP existed, almost certainly does not satisfy.
What this actually costs to get wrong
It is worth putting real numbers next to this, because "compliance risk" tends to feel abstract until it isn't. The Schedule to the DPDP Act sets out penalties of up to ₹250 crore for failing to implement reasonable security safeguards, up to ₹200 crore for failing to notify a breach, up to ₹200 crore for non-compliance with the special provisions on children's data, and up to ₹150 crore for a Significant Data Fiduciary that fails its additional obligations — DPO appointment, independent audit, and periodic data protection impact assessments. Large hospital networks, diagnostic chains and insurers are exactly the kind of high-volume, high-sensitivity data handlers the Significant Data Fiduciary designation was built for. These are not the kind of numbers a hospital board can treat as a rounding error, and they are not the only cost — a breach involving patient diagnoses or psychiatric history carries a reputational and patient-trust cost that no penalty schedule captures.
Where Vaultdef fits into this
None of the challenges above are solved by a policy document. They are solved by knowing, continuously and with evidence, what personal data you actually hold, where it moves, who has legitimate access to it, and what happens when something goes wrong — and by being able to prove it, not just assert it, when a regulator or an accreditation auditor asks.
Vaultdef's data discovery engine is built for exactly the fragmented environment described above — HIS, LIS, RIS/PACS, pharmacy systems, insurance interfaces and legacy on-prem databases alike — scanning for personal and health-related fields and returning a verdict with a confidence score and the specific reasons behind it, rather than a black-box flag you have to trust blindly. On consent, the platform is built to hold multiple concurrent legal bases for the same patient record — Section 6 consent for routine care, the time-bound Section 7 exceptions for emergencies and public health measures, and the narrow healthcare exemption for children's data under Rule 12 — as a signed, traceable receipt rather than a single static checkbox, so your legal basis for any given record is always answerable, not assumed. For the rights obligations under Sections 11 to 14, Vaultdef's rights-management module is designed to work across duplicate identities and multiple facilities, so an access or correction request resolves against everything you hold on a patient, not just whatever one branch's system happens to return. On incident response, the platform maps your breach workflow against both the CERT-In six-hour clock and the DPDP Board's notification timeline in parallel, so a single incident triggers one coordinated response rather than two teams working from two different playbooks. And every action — every consent captured, every access granted, every rights request fulfilled, every control applied — writes to a hash-chained, append-only ledger, so that when a hospital board, an NABH assessor, or the Data Protection Board asks what happened and when, the answer is a verifiable record, not a reconstruction.
Healthcare doesn't get the shortcut DPDP gives other sectors. It doesn't have a "special category" to tell it where to focus. That makes the discipline of knowing your data — precisely, continuously, and provably — not a compliance nicety but the actual foundation of running a modern health system in India. If you want to see what that looks like against your own environment, a working session with your own schema is the fastest way to find out where the gaps actually are.
