Data Retention Periods for Healthtech Companies in India Under DPDP
Health data in India sits at the intersection of clinical establishment rules, medical council regulations, and the DPDP Act. Here is how to set retention periods that satisfy all three.
Healthtech data retention in India comes primarily from clinical and medical council regulation, commonly 3 years from last treatment, not from the DPDP Act directly. The DPDP Act adds proportionate security safeguards under Rule 6, itemised consent for any secondary use, and a one-year minimum on security logs.
A common misconception is that the DPDP Act has a special "health data" category with its own rules, the way GDPR treats special category data. It does not. Instead, Rule 6 requires security safeguards proportionate to the sensitivity of the data and the harm exposure could cause, which in practice means health data gets the strictest treatment even without a named category. The specific retention numbers come from clinical and professional regulations layered underneath.
The retention floors from clinical and medical regulation
| Data category | Governing rule | Typical retention |
|---|---|---|
| Clinical establishment medical records | State Clinical Establishment Rules (framework varies by state, following the Clinical Establishments Act 2010) | Commonly 3 years from the date of last treatment, longer for specific record types like surgical and MLC records in many state rules |
| Medical Council / NMC practitioner obligations | Indian Medical Council (Professional Conduct) Regulations | 3 years from the date of commencement of treatment, for records maintained by individual practitioners |
| Diagnostic and lab records | Varies by state and accreditation body (e.g. NABL) | Commonly 3 to 5 years depending on record type and accreditation requirements |
| Insurance-linked health records | IRDAI record-keeping norms where insurance claims are involved | Typically aligned to policy and claims retention norms, often longer than pure clinical retention |
What the DPDP Act adds specifically for healthtech
- •Safeguards proportionate to harm, not a fixed list. Rule 6 does not hand healthtech a checklist the way GDPR's special category rules do. It requires safeguards that reflect the harm a health data breach could cause, which in practice means stronger encryption, tighter access controls, and more granular audit logs than a general consumer app would need for the equivalent infrastructure spend.
- •Itemised consent for every secondary use. Using health data collected for treatment to also power personalisation, research, or a connected insurance product requires its own separate consent under §6. Bundling "treatment" and "product improvement" into one consent is exactly the gap we flagged in a recent teardown of a food delivery platform's prescription-data handling through its pharmacy vertical.
- •Children's health data gets a partial carve-out, not a free pass. Rule 12 and the Fourth Schedule exempt clinical establishments and healthcare professionals from some of §9's general child-consent restrictions, but only when processing is restricted to providing the health service itself, not for any secondary use like analytics or marketing.
- •A minimum one-year log retention, regardless. Rule 6(1)(e)'s one-year security log retention applies on top of whatever your clinical retention schedule says for the underlying health record.
A worked retention schedule for a telehealth platform
| Data category | Retention period | Basis |
|---|---|---|
| Consultation and treatment records | 3 years from last treatment (verify against your state's specific rules) | Clinical Establishment Rules / medical council norms |
| Prescription data | Aligned to consultation record retention | Clinical Establishment Rules |
| Lab and diagnostic results | 3 to 5 years depending on test type | NABL / accreditation and state norms |
| Security and access logs | 1 year minimum | DPDP Rule 6(1)(e) |
| App usage and engagement analytics | Until consent withdrawn, or defined inactivity trigger | DPDP Rule 8 (no clinical floor applies) |
| Data shared with insurance partners | Matches insurer's claims retention requirement, tracked with separate consent | IRDAI norms + DPDP §6 |
Why healthtech cannot treat this as a generic DPDP policy
The single most common gap we see in health-adjacent products is applying one blanket retention rule ("delete after 2 years") across data that actually has three different legal floors underneath it: the clinical record itself, the diagnostic result, and any insurance-linked data. Getting this wrong by deleting too early creates its own liability under medical record-keeping rules, independent of DPDP. Privacy Labs' discovery scan flags health-adjacent data categories specifically so they get mapped to the right floor before a generic retention policy accidentally overrides them. See the full DPDP compliance checklist for what else applies beyond retention, or run a free Compliance Score below to check your own setup.
Frequently asked questions
Does the DPDP Act have special rules for health data like GDPR does?
No separate category. The DPDP Act does not define a "sensitive data" or "special category" classification. Instead, Rule 6 requires security safeguards proportionate to the sensitivity of the data and the potential harm from exposure, which in practice results in stricter treatment for health data without a named category.
How long must a clinic keep patient records in India?
This is generally governed by state Clinical Establishment Rules and medical council regulations rather than the DPDP Act directly, commonly around 3 years from the date of last treatment, though specific record types and state rules can extend this. Always verify against your specific state's rules and any applicable accreditation body norms.
Can a patient ask a healthtech app to delete their medical records under DPDP?
Clinical and professional record-keeping regulations generally take precedence over a general DPDP erasure request for the underlying medical record, similar to how DPDP preserves retention required by other laws. Data collected for secondary purposes beyond direct treatment, such as analytics or marketing, is more directly subject to a standard DPDP erasure request.