DPDP and Hospital Voice AI: What Clinics Must Ask

How India got a data protection law

I'd start with the Supreme Court judgment. On 24 August 2017, a nine-judge Bench held that privacy is a fundamental right, part of life and personal liberty under Article 21 and part of the freedoms in Part III of the Constitution (Justice K.S. Puttaswamy (Retd.) v Union of India; DigiSCR summary).

The timing has a small twist people often get backwards. MeitY hadn't waited for the judgment at all. It had already set up a Committee of Experts under Justice B.N. Srikrishna on 31 July 2017, a few weeks before the Bench ruled, and that committee came back in July 2018 with a draft Personal Data Protection Bill (PRS chronology; MeitY press brief, 1 Aug 2017).

After that, the Bill went through several more years of work. The Personal Data Protection Bill, 2019 went to a Joint Parliamentary Committee, which reported in December 2021, and the Bill was withdrawn in August 2022. A fresh consultation draft came out that November. And after five years of drafts, the end was oddly quick: the Digital Personal Data Protection Bill, 2023 was introduced on 3 August 2023, the Lok Sabha passed it on 7 August, the Rajya Sabha on 9 August, and it received assent on 11 August 2023 as Act No. 22 of 2023 (PRS; MeitY Act PDF).

Even after the Act passed, we were still waiting for the Rules that would spell out how it would work.

Those came two years later. The Digital Personal Data Protection Rules, 2025 were notified in the Gazette on 13 November 2025 (Rules PDF; MeitY listing; Digital India press note). So, roughly eight years from a court judgment to working rules. Where does that leave a clinic right now?

When does the Act actually apply?

Not on one day, and that trips a lot of people up. The Central Government staggered commencement through Gazette notification G.S.R. 843(E), dated 13 November 2025 (the same Gazette day as the Rules), and counted forward from that publication date:

Sources: G.S.R. 843(E) Act commencement (Gazette English text); Rule 1 in the notified Rules PDF.

For planning a clinic deployment, I'd work back from 13 May 2027.

The way I'd read that table from your side of it: Gazette day switched on the definitions and the Board's establishment provisions. The Consent Manager piece lands on 13 November 2026. The consent, notice, retention and most day-to-day processing rules you design a voice agent around (including most operational Rules) apply from 13 May 2027. The Board's power to impose Schedule penalties under section 33 sits in the same May 2027 tranche — so "there is a Board" and "these penalty provisions are in force for your processing" are not the same checkpoint. Eighteen months sounds generous until you count a procurement cycle, a privacy review, and getting notice and consent wording approved and reviewed in every language your patients use. I'd start that work now; leaving it until April 2027 would give you very little room.

What it means for a patient, a clinic and a vendor

On that scan-booking call, the person the data is about is the Data Principal — often the patient, and sometimes more than one person on the same call (for example if the caller gives their own number and another person's clinical detail). Personal data, under the Act, is simply data about an identifiable individual (s.2), and on a hospital call that usually means names, phone numbers, why someone's coming in, sometimes a cycle day or a home address. Booking on someone else's behalf does not, by itself, resolve whose consent or lawful basis you need for their health-related personal data; that is a fact-specific design and governance question. Once the main obligations kick in, Data Principals are owed a notice of what's being collected and why (s.5), consent that's free and specific and that they can take back (s.6), rights of access, correction and erasure (ss.11–12), and some way to complain (s.13).

The clinic is usually the Data Fiduciary, the one that decides the purpose and means of processing (s.2). So if you run the clinic, this responsibility sits with you. When s.8 applies, it stays responsible even for processing someone else does on its behalf, it has to keep security safeguards in place, and if there's a personal data breach it has to tell the Board and the people affected. So recording and retention can't be "whatever the vendor's default happens to be". And once the Rules tranche with the statutory minima applies, clinic policy has to meet those as well — including Rule 6(1)(e), which (for detection and remediation of unauthorised access) requires retaining such logs and personal data for a period of one year, unless compliance with any law for the time being in force requires otherwise, and Rule 8(3), which requires retaining personal data, associated traffic data and other logs of the processing for a minimum period of one year from the date of such processing, for the purposes as specified in the Seventh Schedule (then erasure unless other law requires longer) (Rules PDF). Rule 8(1) separately ties erasure timelines for certain classes of Data Fiduciaries to the Third Schedule (class and purpose matrix), not the Seventh. Map each record class to the sub-rule that actually applies — avoid treating "one year" as a universal rule for every raw recording.

A voice vendor is often a Data Processor, working for the clinic under a valid contract (s.8(2)). That's where I'd begin reading the terms, but I'd keep reading: the same vendor may train its own products on clinic calls, set a retention period the clinic can't change, or add a secondary purpose nobody asked for [all of which deserve an answer before we settle on a role]. At that point, "we're only the processor" needs examining against what the vendor does and what the contract permits. The invoice tells us very little.

You'll also hear the term Significant Data Fiduciary. A clinic or vendor can't decide for itself whether it has that designation. Under Section 10 the Central Government notifies a fiduciary, or a whole class of them, as SDFs, and the extra duties and penalties follow from that notification. I'm making no claim here about whether hospitals, clinics or Iksha are SDFs; I'd need the government notification to say that.

What happens if you get it wrong

The Data Protection Board of India is established under s.18 of the Act (and defined in s.2(c)). Establishment on Gazette day is not the same as every investigation and penalty power applying to your processing from day one: the Schedule penalty route in s.33 sits in the 13 May 2027 commencement batch together with the main processing chapters. Here are the maximum amounts in the Schedule (MeitY Act PDF):

These amounts are the most the Board can impose, rather than an automatic bill for every breach. The Board weighs how grave the breach was, the type of data, whether it was repeated, any gain realised or loss avoided, what was done to mitigate it, and the other factors listed in s.33(2). For the vendor conversation, the first two rows need particular attention: reasonable safeguards against a breach, and telling the Board and affected people if one happens. If a voice vendor has months of your call audio sitting there, I'd want to know how it is protected and who will report a breach. Those are the risks in the first two rows, and the clinic, as fiduciary, is the one that would face the order.

If you're aggrieved by a Board order, you have sixty days from receiving it to appeal to the Telecom Disputes Settlement and Appellate Tribunal (TDSAT) (the telecom tribunal; I found that odd on first reading too). That's the appeal route in the Act (MeitY Act PDF).

Then there's s.37, which most summaries skip and I don't think they should. This needs two things: the Board must have imposed monetary penalties on the Data Fiduciary in two or more instances, and it must advise blocking in the public interest. The Central Government can then, after hearing the fiduciary, direct that public access be blocked to information on a computer resource through which that fiduciary offers goods or services to Data Principals in India (s.37). If your hospital group takes bookings online, that possibility would worry me more than the fine.

How India compares (high level)

People ask me whether DPDP is "India's GDPR" or "India's HIPAA". Neither, really, and health data is where the difference shows. A very rough map:

India's Act doesn't give health data a special category of its own in the way GDPR does. I can see why someone might read that as "lighter for hospitals", but I wouldn't take much comfort from it: even the plain booking call produces personal data under s.2, so the duties above still apply without an extra category. And after looking across these five regimes, I still want the vendor to explain any use of patient calls for training. That's a question for the ops head's meeting too.

What does "DPDP compliant" even mean for a hospital voice agent?

When a vendor says "DPDP compliant", I need them to go through the deployment with me. Under the Digital Personal Data Protection Act, 2023, that starts with what the data is being processed for and who the Data Fiduciary is, then gets into the notice the patient hears, how consent is taken, retention, security and the subprocessors involved. We also have to look at what the clinic and vendor do week to week [the slide doesn't show us any of this].

We design Krisper around the DPDP Act at Iksha, both in the product and in how we operate. That sentence needs the same examination. It doesn't certify your deployment.

Here's the sort of call an Indian clinic's front desk will recognise [made up for this illustration, not taken from a real call or log]:

Illustration only (not a real transcript). "Hello — I'm calling to book a day-3 scan for my wife. Is Thursday possible? Please note the number: nine-eight-one-one, double-five…" [The same scenario may be spoken in English only, or in a mix of English with regional languages; boundary and consent design still need to work for whatever languages you support.]

Under two minutes, and the agent has already heard two names (his and hers), a mobile number read out digit by digit, a reason for the visit and a cycle day. The next caller might mention a medication schedule, or give an address.

Those details count as personal data because they're about identifiable people. Under the Act, collecting them is already "processing", as are recording, storage, use, disclosure and erasure (DPDP Act, 2023, s.2). So the agent is processing personal data throughout that call and afterwards too.

For your deployment, start with the lawful purpose and whether processing rests on consent or a permitted legitimate use under s.4, with the main obligations from 13 May 2027. The notice and consent themselves must meet ss.5–6. Then s.8 keeps the fiduciary responsible for processing on its behalf, including security safeguards and breach intimation; ss.11–13 need a way for the patient to exercise her rights in practice.

If the answer comes back as "we are DPDP ready", I still need to see how consent works on the call and trace how long the data stays, which subprocessors handle it and who is doing what for which purpose. We could spend the rest of the meeting on that, looking at evidence we can review. Until those answers are clear, I'm not ready to sign.

Who is the Data Fiduciary when a clinic uses a voice agent?

For that scan-booking call, the Data Principal could be the caller, the patient or both: it means the person the data is about. The Data Fiduciary is whoever decides the purpose and means of processing, while a Data Processor handles data on that fiduciary's behalf. Those are the three roles in s.2(i)–(k).

Usually it's the clinic that decides why these calls are being handled and what the agent may collect. It also decides which systems the agent can write into and when a human must take over, and somewhere in that discussion it has to decide how long recordings stay (an easy detail to leave until later). Those decisions about purpose and means usually make the clinic or hospital group the fiduciary.

A vendor that processes audio, transcripts or CRM fields on the clinic's behalf is commonly a processor, but only under a valid contract (s.8(2)), and the fiduciary stays responsible for processing done by it or on its behalf (s.8(1)). So having the vendor do the processing doesn't mean it has taken that responsibility off your hands.

In that first meeting, I'd ask the vendor to explain any use it makes of the calls for itself, even if asking feels awkward. Training its own products, choosing secondary uses, keeping retention settings beyond the clinic's control: once those appear in the terms, we have to check whether the processor label still fits what is happening.

What the caller hears before any health detail

Under Section 4, you need a lawful purpose and either consent or one of the permitted legitimate uses to process personal data (s.4).

Legitimate use is not a free pass. Section 7 lists several grounds. Clause (a) allows processing for the specified purpose for which the Data Principal voluntarily provided personal data and has not indicated that she does not consent — the Act illustrates that with receipts and brokerage enquiries, not with call recording or unrelated reuse (s.7(a)). Whether a bare appointment request without objection covers recording, secondary analytics or marketing is fact-specific; it is not a substitute for a clear purpose-limited design. Clauses on medical emergency and public health are narrow; I wouldn't map an ordinary Tuesday booking to those.

For most clinic voice lines I'd still plan around notice and consent once the May 2027 tranche is in force for your processing, because that is what the Rules expect you to operationalise on the ground.

The Act's notice (s.5) must be clear and easy to understand; the 2025 Rules add hard content tests. Rule 3 says the notice must be understandable on its own, give (at minimum) an itemised description of the personal data and the specified purpose, and give the link(s) or other means to withdraw consent, exercise rights and complain to the Board (Rules PDF, Rule 3). A spoken line that does not identify each category of data, each purpose and a durable way to exercise rights is unlikely to satisfy that — you'll usually pair the call with something the person can read or receive (SMS, app, web).

Consent under s.6 has to be free, specific, informed, unconditional and unambiguous, through a clear affirmative action, and limited to what is necessary (s.6). Withdrawal has to be as easy as giving consent. In product work, treating explicit, verifiable consent as the default for recording and health-adjacent fields is often sensible — that is a design choice to reduce ambiguity, not a shorthand for "whatever s.7(a) might allow on the facts".

My favourite part of the Act, oddly, is an illustration tucked under s.6 about telemedicine. A telemedicine app asks for consent to process personal data for its telemedicine service and to access the phone's contact list. Consent for the contact list fails, because the contact list isn't necessary for the service (s.6 illustration). I read that illustration with voice agents in mind. For a scan booking, I wouldn't collect cycle history or diagnosis labels just because somebody might want them later.

AI disclosure. Good practice is to tell people they are speaking with an automated system early; DPDP ties identity of processing to notice and consent rather than inventing a standalone "say you are an AI" sentence in isolation. Build it into the notice and testing plan for each language you ship.

On our side we publish interaction rules (for example pausing or handing over when identity, consent, scope or confidence is insufficient) on the safety page — treat that as material to verify in your deployment review alongside your own notice and records, not as a statute-by-statute guarantee for every clinic build.

Recordings, transcripts, retention and subprocessors

I'd spend much of the review meeting on a page showing where the call data goes. One page from the vendor should be enough: audio and transcripts, the identity and appointment fields going into the HIS, EMR or CRM, and the tool logs and overrides [those last two are easy to leave off when everybody is looking at the recording]. Alongside each data class we need its retention period, the subprocessors involved and where the processing physically happens.

If we can't fill that page in together, I want to know why before signing.

That map matters because s.8 makes the fiduciary, usually the clinic, responsible for appropriate technical and organisational measures and reasonable security safeguards to prevent a personal data breach. Processing done by its processors is included too. If a breach does happen, the fiduciary has to notify the Board and each affected Data Principal, in the prescribed way. Erasure when consent is withdrawn or the purpose ends has to be read together with Rule 8 and any other retention law that applies to your sector — it is not "delete everything instantly in every case" on one hand or "keep all audio forever" on the other (s.8; Rules PDF).

Once the eighteen-month Rules tranche applies from 13 May 2027, at least two different limbs show up in the notified text. Rule 6(1)(e) (reasonable security safeguards) requires retaining such logs and personal data for a period of one year, unless compliance with any law for the time being in force requires otherwise. Rule 8(3) (without prejudice to sub-rules (1) and (2)) requires retaining personal data, associated traffic data and other logs of the processing for a minimum period of one year from the date of such processing, for the purposes as specified in the Seventh Schedule — then the fiduciary shall cause such personal data and logs to be erased unless further retention is required under other law (Rules PDF). Rule 8(1) addresses a different scenario: Data Fiduciaries of classes (and purposes) listed in the Third Schedule. Map each record class to the sub-rule that actually applies before you promise patients a deletion timeline.

Suppose a caller asks for erasure on a Monday morning. I'd follow that request into the transcripts and through to the subprocessors, with the vendor showing how it traces what it processed about this particular caller [the subprocessor list and retention controls should be in front of us]. If we can't follow it, I don't think we're ready for a hospital review, however good the demo looked.

Erasure is only one part of that exercise. The patient also needs access under s.11, correction, completion and updating as well as erasure under s.12, and a readily available way to raise a grievance under s.13. We need to walk through those too.

For diligence, the trust centre points to data-processing materials you can read alongside your privacy reviewer, and the homepage describes how we talk about security and deployment boundaries in marketing copy. Those pages are not proof of how your clinic's production stack behaves — verify encryption scope, isolation, retention and subprocessors against your contract and configuration.

What should clinics ask a vendor before go-live?

I'd take these ten questions to the vendor before signing, while there's time to deal with gaps without a patient complaint forcing the issue.

1. Who is the Data Fiduciary here and who's the processor? Can you show us where those roles are written in the contract, beyond what the deck says?
2. What is the agent allowed to collect on a call, and what's out of scope?
3. What does the caller hear before any health detail comes up, and in which languages? How do you capture affirmative consent, and how have you made withdrawing as easy as giving it?
4. Does the agent identify itself as an automated system early in the call, in every supported language, and how do you test that? (If the vendor points to marketing pages, ask for test calls and logs from your deployment.)
5. Does it keep away from diagnosis, prescribing, plan changes and interpreting results? Our buyer's guide goes into how to test that.
6. Is recording optional and configurable? When are audio, transcripts and logs erased, who can get at them meanwhile, and do those windows meet the Rules floors once they apply?
7. Who are your subprocessors, where are they, and how do the security and erasure obligations flow down to them?
8. Can you show us how encryption, access control and isolation work here? If there's a breach, how will you notify people in line with our incident plan and s.8(6)?
9. When a patient asks for access, correction or erasure, or raises a grievance, what happens, step by step?
10. What can our privacy and security team review before go-live, and does the agent pause or hand over with context when identity, consent, scope or confidence fails? (safety; platform; trust)

Have your privacy person in the room for these answers. If the vendor can't give them plainly, they haven't yet shown how your deployment will meet DPDP requirements [they may come back with answers later, fair enough]. You still need to know where things stand before signing.

How Iksha designs Krisper around DPDP

At Iksha we build the safety and policy layer that healthcare agents run on; Krisper is our flagship. The homepage, Krisper, safety and trust pages describe how we talk about consent, retention, data boundaries and escalation — that is positioning copy, not a certification of your hospital's live configuration.

In diligence, I'd map each marketing bullet to evidence: sample call flows and transcripts from a staging build, subprocessor list and data-flow diagram, retention and encryption settings available to your admin, and how handover works when the model is unsure. If something cannot be shown, treat it as unresolved.

If you run a fertility clinic, there's a Krisper for IVF clinics page as well. Nothing here claims SDF designation, Board approval or automatic compliance for any deployment.

If you're considering Krisper, I'd expect us to work through those ten questions with you in the review meeting.

FAQ