The DPDP Act for Health-Tech Builders: What We Built, What's Next

India’s Digital Personal Data Protection Act, 2023 has no special category for health data, but for anyone building clinic or hospital software it still reads as a product spec. The DPDP Rules, 2025 fill in the detail: itemised notices, consent as easy to withdraw as to give, minimum security safeguards with logs kept for a year, a detailed breach report to the Data Protection Board within 72 hours, and a working way for people to access, correct and erase their data. The core obligations commence in May 2027. Below, we map each obligation to an engineering control, and give an honest account of what we have built into Clinizy Care, our own hospital management software, and what comes next.

This is an engineering guide, not legal advice. We quote the official texts; how they apply to you is a question for your lawyer.

Key takeaways

• The clock is running. The DPDP Rules were published in the Gazette on 13 November 2025; the core duties of Data Fiduciaries commence eighteen months later, in May 2027.
• Health data is not a separate legal category. One standard covers all digital personal data. The legal floor is uniform; the harm from a breach is not.
• A vendor cannot carry the clinic’s liability. The clinic is usually the Data Fiduciary and stays responsible for processing done on its behalf.
• Rule 6 reads like an engineering checklist: encryption or masking, access control, logs, continuity, one-year retention and processor contracts. Failing to take reasonable security safeguards can attract a penalty of up to ₹250 crore.
• In Clinizy Care, India hosting, tenant isolation, role-based access, two-factor sign-in, an append-only audit trail and clinic-level export and deletion are built. Patient-level consent, individual rights requests, field-level encryption and read auditing are next.

When do the DPDP Act and Rules apply to health-tech?

The Act is Act No. 22 of 2023, enacted on 11 August 2023. Most of it sat dormant until MeitY published the Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E)) and a commencement notification for the Act (G.S.R. 843(E)), both in the Gazette of India dated 13 November 2025. They switch provisions on in three phases, counted from that date:

Phase	What comes into force	What it means for builders
On publication (13 November 2025)	Definitions, the Data Protection Board and the penalty framework (Act sections 2, 18–26, 35, 38–43; Rules 1, 2, 17–21)	The Board exists; product duties do not bite yet
After one year (November 2026)	Registration of Consent Managers (Act section 6(9); Rule 4)	Consent platforms can register with the Board
After eighteen months (May 2027)	Notice, consent, security safeguards, breach intimation, erasure, children’s data, rights and grievances (Act sections 3–17 except 6(9); Rules 3, 5–16, 22, 23)	Everything in this post

That leaves a little over seven months from the date of this post; check MeitY for any amendment before you plan around these dates. Note for clinics moving off paper: under section 3, data collected on paper and digitised later is also in scope.

Who is the Data Fiduciary when a clinic uses your software?

The Act defines six roles. The Data Principal is the person the data is about (for a child, including the parent or lawful guardian). The Data Fiduciary decides the purpose and means of processing; a Data Processor processes on its behalf. A Significant Data Fiduciary is notified by the Central Government and must appoint a Data Protection Officer and an independent auditor. A Consent Manager is a Board-registered consent platform, which the Rules require to be a company incorporated in India. The Data Protection Board of India inquires into breaches and imposes penalties.

In most clinic software, the clinic is the Data Fiduciary for patient data and the vendor is its Data Processor. Under section 8(1), the fiduciary is responsible for compliance “irrespective of any agreement to the contrary”, including for processing its processor does. It may use a processor only under a valid contract (section 8(2)), and Rule 6 requires that contract to cover reasonable security safeguards.

So we choose our words carefully: Clinizy Care is built to be DPDP Act 2023 aligned, but no vendor can hand a clinic compliance, because the clinic remains the fiduciary. Clinizy Care’s privacy policy sets out the split: Brynex Labs is a Data Processor for patient data, where the clinic is the Data Fiduciary, and a Data Fiduciary for its own account data. A vendor’s job is to ship the controls, document them, and make evidence easy to produce. Our clinic-facing explainer on what DPDP alignment means for clinic data security covers the same ground from the owner’s side.

Is health data a special category under the DPDP Act?

No. The Act does not define a separate class of sensitive or health data. “Personal data” means any data about an individual who is identifiable by or in relation to it (section 2(t)), so a patient’s diagnosis and a patient’s phone number carry the same obligations.

Health appears in two places. Section 7’s “legitimate uses”, which do not rest on consent, include responding to a medical emergency and providing treatment during an epidemic or other public health threat. And the “sensitivity of personal data processed” is one factor the government may weigh when notifying a Significant Data Fiduciary (section 10(1)). The legal floor is uniform, but health records are where a breach does the most harm, so they deserve your strongest controls.

What about children’s data in paediatric clinics?

Section 9 requires verifiable parental consent before processing a child’s data (a child is anyone under eighteen) and bars tracking, behavioural monitoring and targeted advertising directed at children. The Fourth Schedule to the Rules exempts clinical establishments, mental health establishments and healthcare professionals from those two provisions where processing is restricted to providing health services to the child, to the extent necessary to protect her health. Two details matter for design: the ban on processing likely to harm a child’s well-being (section 9(2)) still applies, and the exemption is scoped to care, so promotional messages to parents would not obviously fall within it. Record the purpose alongside the data so the boundary stays visible.

What does “reasonable security safeguards” mean in code?

Rule 6 is the closest the law comes to an engineering spec. Safeguards must include, at the minimum:

• Data security measures such as encryption, obfuscation, masking or virtual tokens.
• Access control over the computer resources used by the fiduciary or its processor.
• Visibility on access through logs, monitoring and review.
• Continuity: reasonable measures to keep processing if data is compromised, such as data backups.
• One-year retention of those logs and personal data, unless another law requires otherwise.
• Processor contracts that require safeguards, plus the technical and organisational measures that make it all work.

The Schedule to the Act sets the stakes: up to ₹250 crore for failing to take reasonable security safeguards; up to ₹200 crore each for failing to notify the Board or affected people of a breach and for breaching the obligations on children’s data; and up to ₹50 crore for any other breach. The PIB backgrounder on the Rules summarises the same ceilings.

One point is easy to miss: Rule 6 wants logs, and Rule 8(3) separately requires personal data, traffic data and processing logs to be kept for at least a year. If your audit log copies whole records, you have built a second, less-guarded copy of every patient chart. In Clinizy Care the audit trail records every successful create, update and delete automatically, but a field allowlist decides what gets written, so patient health data stays out of the log itself.

// Simplified illustration, not our production code
const AUDIT_SAFE_FIELDS = {
  appointment: ['status', 'doctorId', 'slotTime'],
  invoice: ['status', 'total', 'paymentMode'],
};

function auditFields(entity, changes) {
  const allowed = AUDIT_SAFE_FIELDS[entity] || [];
  return Object.fromEntries(
    Object.entries(changes).filter(([key]) => allowed.includes(key))
  );
}

How fast must a personal data breach be reported?

Rule 7 sets two tracks. Each affected Data Principal must be told without delay, in plain language: what happened, the likely consequences, what is being done, how to protect themselves, and who to contact. The Board gets a description without delay, then a detailed report within seventy-two hours of the fiduciary becoming aware, or longer if the Board allows it on written request.

Seventy-two hours is short if answering “whose data was affected?” takes a day. The controls that answer it are the ones Rule 6 already asks for: strict tenant scoping, access tied to named users, and queryable logs.

What must the product do for notice, consent and rights?

Under Rule 3, a notice must stand on its own, in clear and plain language, with an itemised description of the data, the specific purposes, and a way to withdraw consent, exercise rights and complain to the Board. The Act adds that withdrawal must be as easy as giving consent (section 6(4)), that people must be able to read notices in English or any language in the Eighth Schedule to the Constitution, and that if consent is disputed, the fiduciary must prove a valid notice was given and consent obtained (section 6(10)).

The rights are access to a summary of the data and who it was shared with (section 11), correction and erasure (section 12), grievance redressal (section 13), and nominating someone to exercise them in case of death or incapacity (section 14). Under Rule 14, grievances must be answered within a published period of no more than ninety days. Section 8(7) requires erasure once consent is withdrawn or the purpose is no longer served, unless another law requires retention.

Translated into engineering:

• Consent is a record, not a checkbox. The burden of proof sits with the fiduciary, so store which notice version was shown, which purposes were accepted, when, and when consent was withdrawn.
• Notices are versioned, multilingual content, not hard-coded strings.
• Rights requests are a workflow with a clock: an owner, a status and a deadline for each.
• Retention is a policy per data category. The “unless another law requires retention” carve-out matters in healthcare, so deletion logic must know what it may not delete.

How does Clinizy Care map to the DPDP obligations?

“Built” means in the product today; “In progress” means what we are building next.

Obligation (source)	Engineering control	Status in Clinizy Care
Encryption (Rule 6)	All traffic over TLS with HSTS; uploaded files in S3 encrypted at rest, public access blocked, TLS-only bucket policy; servers and file storage on AWS Mumbai (ap-south-1)	Built
Encryption of secrets (Rule 6)	A clinic’s own credentials, such as its WhatsApp access token, encrypted at the application layer with AES-256-GCM	Built
Encryption of the most sensitive identifiers (Rule 6)	Field-level encryption for key patient identifiers; design done	In progress
Masking and minimisation (Rule 6)	Waiting-room OPD token display shows patient initials only	Built
Access control (Rule 6)	Fail-closed tenant guard on every database query, tested against a real database; seven staff roles, one permission matrix shared by API and interface, per-clinic overrides	Built
Authentication (Rule 6)	TOTP two-factor sign-in; short-lived in-memory access tokens; httpOnly rotating refresh cookie with reuse detection	Built
Logs and retention (Rules 6 and 8(3))	Append-only audit trail of every create, update and delete, with a field allowlist; retained for two years	Built
Visibility on access (Rule 6)	Audit trail extended to reads of patient records	In progress
Notice and consent (sections 5–6; Rule 3)	Patient-level consent at registration, with purpose-specific notices and easy withdrawal	In progress
Website consent (section 6)	Cookie and analytics consent through Google Consent Mode v2	Built
Access and erasure (sections 8(7), 11–12)	Owner exports all clinic data to spreadsheets; account deletion is an immediate soft delete, purged after 30 days, keeping records that must be retained (such as GST invoices and the audit log)	Built (clinic level)
Individual rights requests (sections 11–13; Rule 14)	Workflow for one patient’s access, correction and erasure requests	In progress

On clinizy.in, role-based access is part of the Care Plus plan and above. The tenant guard has its own write-up in how we built a multi-tenant HMS for Indian clinics, and messaging in running the WhatsApp Business API at clinic scale.

What we’re building next

Each “In progress” row maps to an obligation that commences in May 2027:

1. Patient-level consent at registration, with purpose-specific notices and easy withdrawal. It happens at the front desk, so it has to be quick enough for a busy OPD counter.
2. Individual rights requests. Export and deletion work at the clinic level today; next is a workflow for one patient’s request to access, correct or erase their data.
3. Field-level encryption for the most sensitive identifiers. The design is done; implementation is next.
4. Auditing reads, not just changes. Rule 6 asks for visibility on the accessing of personal data; logging who viewed a record, not only who edited it, answers that directly.

The honest takeaway

The DPDP Act does not ask health-tech builders to become lawyers. It asks for software where consent is a record, access is a deliberate decision, every change leaves a trace, and one person’s data can be found, handed over, corrected and removed. We would rather publish an honest map, with the gaps labelled as the roadmap they are, than claim a compliance no vendor can give.

If you are building software that handles patient data, our healthcare software engineering practice builds these controls in from the first sprint, and how we built Clinizy Care shows them in a live product. For the wider build, see our AI-native software engineering service.