DPDP Compliance for Patient Support Programs in India

What sponsors have to decide before May 2027

A patient on your oncology support program tells a coordinator, mid-call, that she wants out. Not out of therapy — out of the reminder calls, the adherence surveys, the home-visit scheduling.

Count the systems that need to know: the third party service provider’s CRM, the SMS gateway, the nursing agency's roster, the diagnostics partner's pending-order queue, the analytics warehouse your global team reads from. Then ask the harder question: does her withdrawal also switch off your adverse event reporting? Because if your enrolment form bundled pharmacovigilance consent with program consent — and most do — you have just created a conflict between the DPDP Act and your obligations to CDSCO.

That second question is the one almost nobody is asking. The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025 as G.S.R. 846(E), and Rules 3 and 5 to 16 come into force eighteen months later — around 13 May 2027. This article covers what a sponsor running a patient program in India is now accountable for, based on the notified text rather than the draft. For how patient programs are structured and operated, see our guide to patient support programs in India.

Zelthy is an AI-native platform for life sciences operations, built on the open-source Zango framework, running patient programs for top-10 global pharma companies across 12+ countries.

a. Where sponsors sit, and what does not transfer

Patient programs run on a chain. A single specialty program typically involves a third party vendor providing processing support, a call centre, a nursing or home-care agency, a diagnostics partner, a logistics provider, a specialty pharmacy, and field coordinators working from their own phones.

The sponsor is the Data Fiduciary across all of it. The vendors are Data Processors. Primary compliance responsibility rests with the data fiduciary even where processing is outsourced, and contractual delegation does not absolve sponsors of liability. The Rules reinforce this structurally rather than just in principle — Rule 6(1) requires the Data Fiduciary to protect personal data "including in respect of any processing undertaken by it or on its behalf by a Data Processor," and Rule 8(3) makes the fiduciary responsible for ensuring processors retain logs too. The Rules' own illustration for that sub-rule is a company engaging a cloud provider to host customer records.

Two structural points to internalise before anything else.

There is no sensitive data tier. Unlike GDPR or India's earlier SPDI framework, the DPDP Act creates no special category for health data. Diagnosis, prescription history, and genetic information carry the same obligations as a mailing address. No special regime to build — but equally, no assumption that health data is covered by a separate carve-out.

DPDP stacks; it does not replace. New Drugs and Clinical Trials Rules, ICMR guidance, Telemedicine Guidelines 2020, and ABDM consent artefacts all continue to apply. Ethics-committee compliance and DPDP compliance were never the same thing.

The phased timeline

Penalty exposure, from the Act's Schedule: up to ₹250 crore for failing to take reasonable security safeguards, ₹200 crore for failing to notify a breach, ₹200 crore for breaching children's data obligations, ₹150 crore for Significant Data Fiduciary obligations, and ₹50 crore as a catch-all for any other breach of the Act or Rules. A single incident can engage more than one row.

b. The structural problem: your GDPR legal-basis map does not port

This is the finding that should reshape most sponsors' India programs.

Section 7 of the DPDP Act lists the legitimate uses permitting processing without consent. It is a closed list of exactly nine categories — a numerus clausus — with no balancing test. And critically, it contains no general legitimate-interests basis and no contractual-necessity basis.

Under GDPR, a sponsor can run most of a patient program on Article 6(1)(b) (necessary for contract performance) or 6(1)(f) (legitimate interests). Neither exists in India. What remains, for a patient program, is narrow:

Three consequences follow, and each one breaks something most programs currently do.

First, "we need this to run the program" is not a legal basis in India. There is no contractual necessity clause to fall back on. If a processing activity isn't in Section 7's list, it needs consent — full stop.

Second, Section 7(a) is narrower than it reads. It covers the specified purpose for which the Data Principal voluntarily provided her data, where she hasn't objected. The Act's own illustrations make the limits explicit: a pharmacy given a phone number to send a payment receipt may process it for that receipt — not for marketing, not for profile-building. And in the second illustration, once the person says she no longer needs the service, the fiduciary must cease processing. Applied to a PSP: a patient who hands over a number to enrol has enabled enrolment, not a three-year adherence campaign.

Third, and most importantly — pharmacovigilance sits on a different basis than everything else, and almost no consent form reflects that. AE reporting is a statutory disclosure obligation to the State. It should be resting on Section 7(d), not consent. Which means it survives withdrawal. But only if you unbundled it in the first place. If your enrolment form bundles PV into a single "I consent to the program" checkbox, you have converted a non-withdrawable statutory duty into a withdrawable permission — and when a patient withdraws, you are left choosing which law to breach.

Unbundling the consent form by legal basis is the single highest-value piece of remediation available to an Indian PSP sponsor right now. It costs a form redesign and a data model change. It resolves a conflict that otherwise surfaces at the worst possible moment.

c. What Rule 3 does to the enrolment form

Rule 3 sets out what a notice must be, and it is stricter than most enrolment paperwork currently is.

The notice must be presented and understandable independently of any other information the fiduciary makes available. A consent clause on page 11 of a 14-page enrolment pack does not meet this. It must give, in clear and plain language, at minimum an itemised description of the personal data and the specified purpose or purposes, with a specific description of the goods or services enabled by the processing. "We collect your health information to provide program services" fails on both counts.

Then Rule 3(c) — the provision with the sharpest operational teeth. The notice must give the communication link and other means by which the patient may withdraw consent, with the ease of doing so being comparable to that with which such consent was given, exercise her rights, and complain to the Board.

Read that against how PSP consent is actually captured. A coordinator sits with the patient, explains the program, and takes a signature in under a minute. Withdrawal, in most programs, means finding a helpline number, calling during business hours, and being routed through a vendor's IVR. That asymmetry does not satisfy Rule 3(c)(i) on its face.

If consent is captured in the field by a person, withdrawal must be available in the field too. That is a workflow requirement, not a policy one.

d. The paediatric trap

This is the finding most likely to catch sponsors off guard, and it carries ₹200 crore exposure.

Section 9 imposes verifiable parental consent for children's data and prohibits tracking, behavioural monitoring, and targeted advertising directed at children. Rule 12 disapplies sub-sections 9(1) and 9(3) for classes of fiduciaries listed in Part A of the Fourth Schedule.

Here is Part A, in full, for healthcare: a Data Fiduciary who is a clinical establishment, mental health establishment or healthcare professional, where processing is restricted to the provision of health services to the child, to the extent necessary for the protection of her health. And a Data Fiduciary who is an allied healthcare professional, restricted to supporting a treatment and referral plan.

A pharmaceutical company is none of these. Neither is a hub vendor, a call centre, or a logistics partner. Those terms carry defined meanings drawn from the Clinical Establishments (Registration and Regulation) Act, 2010, the Mental Healthcare Act, 2017, and the National Commission for Allied and Healthcare Professions Act, 2021.

So: a paediatric patient support program run by a sponsor gets no entity-based exemption. Verifiable parental consent applies in full. The prohibition on tracking and behavioural monitoring applies in full — and "adherence monitoring" in a paediatric program deserves a careful look against that language. A clinician treating the same child is exempt; the sponsor's program wrapped around that treatment is not.

Any sponsor running rare-disease, paediatric oncology, or growth-hormone programs in India should be treating this as a live gap, not a 2027 problem.

e. Retention: the three-year rule that does not apply to you

Most DPDP advisory currently states that data must be erased after three years of user inactivity. For patient programs, this is not valid.

Rule 8(1) applies that erasure obligation only to the classes of fiduciaries in the Third Schedule. The Third Schedule contains exactly three: e-commerce entities with at least two crore registered users, online gaming intermediaries with at least fifty lakh, and social media intermediaries with at least two crore. A pharma sponsor running a patient program is in none of them.

What does apply universally is Rule 8(3): a Data Fiduciary must retain personal data, associated traffic data, and processing logs for a minimum of one year from the date of processing, after which they must be erased — unless longer retention is required by another law. And the fiduciary must ensure its processors do the same.

So the actual retention picture for an Indian PSP is a floor and a ceiling from two different directions. The patient record is governed by purpose limitation — hold it while the purpose is served, and for as long as NDCT Rules, PV record-keeping, or tax law independently require. The logs are governed by a one-year statutory minimum. Neither is a three-year inactivity timer.

One exception worth flagging: if your program includes a direct-to-patient fulfilment or ordering platform, check whether it meets the e-commerce entity definition. If it does, Third Schedule obligations may bite on that component — including the requirement to warn the patient at least 48 hours before erasure.

f. Breach: two clocks, and a notification problem specific to PSPs

Rule 7 creates a two-track obligation, and the tracks run on different clocks.

To each affected patient, without delay: a description of the breach including nature, extent and timing; the consequences relevant to her; mitigation measures taken; safety measures she can take; and business contact information for a person who can answer her questions.

To the Board, in two stages: without delay, a description including nature, extent, timing, location and likely impact. Then within seventy-two hours — extendable only on a written request the Board allows — updated detail, the broad facts and circumstances leading to the breach, mitigation measures, any findings on who caused it, remedial measures to prevent recurrence, and a report on the intimations given to patients.

Two things follow. The 72-hour submission is a forensic report, not a heads-up, and it includes a report on patient notifications — meaning patient intimation has to be substantially done inside the same window. And the clock starts on awareness, not on completing the investigation.

The PSP-specific problem is in the delivery channel. Rule 7(1) requires intimation "through her user account or any mode of communication registered by her with the Data Fiduciary." Many patient program enrollees have no user account. If the only contact you hold is a phone number a coordinator wrote on a form, is that a mode of communication registered by her? Sponsors should be capturing a registered communication channel at enrolment, explicitly, as a breach-notification prerequisite. Discovering you cannot lawfully reach 40,000 patients is not a discovery to make during an incident.

g. Cross-border, and the SDF question

Rule 15 is one sentence, and its posture is the opposite of GDPR's. Personal data may be transferred outside India, subject to meeting whatever requirements the Central Government specifies by general or special order regarding availability to a foreign State or an entity under its control.

Transfers are permitted by default until restricted. There is no adequacy list, no SCC regime, no standing mechanism to put in place. What there is instead is executive discretion exercisable at any time — a general order covering a country or category, or a special order targeting a sector, entity, or data type. Health data is a plausible candidate for a special order.

The practical implication is architectural rather than contractual. You cannot build a static transfer mechanism and consider it settled. You need a data architecture that can be re-regioned on short notice, and a live inventory of which flows would be affected by which order.

Separately, if a sponsor is designated a Significant Data Fiduciary under Section 10, Rule 13 adds real weight: an annual Data Protection Impact Assessment and audit, with significant observations reported to the Board; due diligence that algorithmic and technical measures do not pose a risk to Data Principal rights; and a localisation obligation for government-specified personal data — covering not just the data but the traffic data pertaining to its flow.

Designation is not automatic for healthcare. The Central Government decides based on volume, sensitivity, and risk. But a sponsor running programs covering hundreds of thousands of Indian patients should plan for designation rather than hope against it. The algorithmic due diligence clause in particular is worth reading closely by anyone deploying AI-driven adherence scoring or patient risk stratification.

h. What to own, what to contract, what to configure

Policy, legal-basis mapping, DPIAs, and vendor contracts stay with the sponsor. Program operations are contracted. The technical controls underneath should be configured rather than rebuilt — and this is where the platform decision carries weight, because most of what the Rules require is a system property, not a policy statement.

What a platform has to make possible:

• Consent modelled per legal basis, not per patient. If PV, adherence, analytics, and research can't be separated in the data model, they can't be unbundled in the consent form. On Zelthy, consent objects are configured per program and per geography, so a new market is a configuration rather than a rebuild.
• Audit trail on every record touch. Rule 6(1)(c) requires visibility on access through logs, monitoring and review, sufficient to detect unauthorised access and investigate it. This is the difference between telling the Board you have a policy and showing them who accessed which patient record, when, and why.
• Role-based access separating coordinator, medical affairs, and vendor operator views.
• Retention and erasure at module level, so the one-year log floor and purpose-limited patient record can run on different schedules without manual intervention.
• Encryption, masking or tokenisation — Rule 6(1)(a) names these specifically.
• Code ownership through Zango, the open-source framework Zelthy is built on. When an auditor asks how consent propagates through the system, there is no black box in the answer.
• HIPAA and GDPR controls already in place as the starting point rather than a fresh build.
• India data residency deployment option and now also an SDF localisation question
• Consent notices in scheduled Indian languages
• Registered-communication-channel capture at enrolment, and breach notification workflow

What this looks like at scale

Zelthy runs patient programs for top-10 global pharma companies across 12+ countries, covering more than a million patient journeys — including India's largest oncology patient assistance program, from onboarding through product tracking, and a government program monitoring over a million HIV-positive patients.

Programs built on the platform have improved therapy adherence by 45%, cut onboarding time by 60%, and reduced operating costs by 30%. Those outcomes come from the same properties DPDP now requires: structured consent, complete audit trails, and workflows the sponsor can see into directly rather than through a vendor's monthly report.

Where to start

Four things worth doing in the next ninety days, in this order:

1. Reclassify every processing activity by legal basis. Not GDPR bases — Section 7's nine. Anything that lands on "contractual necessity" or "legitimate interests" has no home in India and needs consent or a redesign.
2. Unbundle pharmacovigilance from program consent. This is the conflict most likely to surface first and the one with no good answer once it does.
3. Test one withdrawal end to end. Trigger it, and time how long every downstream system takes to stop. That number is your compliance posture.
4. Check whether any paediatric program is relying on an exemption it does not have. The Fourth Schedule exempts clinicians, not sponsors.

If you are rebuilding program infrastructure ahead of 2027, talk to us about what carries over and what has to change.

This post describes platform capabilities and summarises publicly notified regulatory text. It is not legal advice. Consult qualified counsel on your obligations under the DPDP Act, 2023 and the DPDP Rules, 2025.