The DPDP Act applies to your clinic. Here is the checklist.

The Act applies to your clinic, however small it is.

The Digital Personal Data Protection Act, 2023 applies to anyone who decides why and how personal data is processed in digital form. A clinic that keeps patient records in an EMR, in a spreadsheet or in a WhatsApp chat is a Data Fiduciary under the Act. The patient is the Data Principal.

Health records are personal data. There is no small-clinic exemption for a business that processes patient data as part of its work. So the question is not whether the Act applies to you, but how much of it you already cover and what is still open.

This checklist is written for a clinic owner or practice manager. It does not replace legal advice. It is meant to get you from 'we should look at this' to a list of items with an owner and a date.

Part 1. Know what you hold.

You cannot protect data you have not mapped. Start with an inventory, and be honest about the informal places.

• List every place patient data lives: EMR, billing software, lab system, WhatsApp on staff phones, paper registers, backup drives, email.
• For each, note what is stored: name, phone, Aadhaar, ABHA, diagnosis, prescriptions, reports, payment details.
• Note who can open it, and whether access is by a named login or a shared password.
• Note where it is physically hosted. Ask your vendor in writing.
• Note how long you keep it and whether anything is ever deleted.

The two items that surprise most clinics are staff phones and shared logins. A receptionist's personal WhatsApp holding three years of patient reports is a data store, and it walks out of the door when they leave.

Part 2. Notice and consent.

The Act requires that a Data Principal be given a notice, in clear language, describing what personal data is collected, for what purpose, and how they can exercise their rights and complain. Consent has to be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action.

What that means at the front desk.

• A short notice, in English and the local language, at registration and in your WhatsApp onboarding message.
• Consent for treatment records is separate from consent for marketing messages. Do not bundle them.
• Record when consent was given, for what, and through which channel. A tick box in the EMR with a timestamp is enough; a verbal 'yes' with no record is not.
• Make withdrawal as easy as giving consent. If a patient replies STOP on WhatsApp, that must actually stop the messages.

For children, the Act requires verifiable parental consent. Paediatric clinics should design a specific step for this rather than treating the parent's phone number as implied consent.

If you need a starting draft, our patient consent form template sets out the clauses one by one.

Part 3. Purpose limitation and minimisation.

Collect what you need for care and billing, and use it only for that. Aadhaar numbers are the usual offender: many clinics collect them out of habit. If you are creating an ABHA, the Aadhaar OTP step happens on the ABDM side and you do not need to store the number.

• Remove fields from your registration form that no one uses.
• Do not export patient lists to personal devices for 'a quick campaign'.
• If you send health tips or offers, that is a different purpose and needs its own consent.

Part 4. Security safeguards.

The Act requires reasonable security safeguards to prevent a personal data breach. The word 'reasonable' is doing a lot of work. For a clinic, the following list is a sensible floor.

• Named logins for every staff member; no shared passwords.
• Role-based access: the pharmacy counter does not need the psychiatry notes.
• An audit trail that records who opened and changed which record.
• Encrypted backups, with a restore you have actually tested.
• Two-factor login for doctors and administrators.
• Automatic sign-out on shared front-desk machines.
• Data hosted in India, with the region stated in the contract.

Ask your vendor for each of these in writing. On Saaro Health, role-based access, an audit trail and hosting in India (Mumbai region) are standard; the details are on our security and data residency pages.

Part 5. Retention and erasure.

The Act expects personal data to be erased once its purpose is served, unless another law requires you to keep it. Clinical records have their own retention requirements under medical council rules, so you are not expected to delete a case file on request. A marketing list, an old reminder log or a former employee's exports are a different matter.

• Write down a retention period for each category in your inventory.
• Decide what 'erase' means in each system, and test that it works.
• Route erasure requests through one named person, with a log.

Part 6. Rights, grievances and breach response.

Patients have the right to access a summary of their data, to correction and erasure, to a grievance mechanism, and to nominate someone to exercise these rights for them. You need a way to receive and answer such requests.

1. 1Name a contact for data requests and publish it. A clinic email address is fine.
2. 2Set an internal turnaround target and log every request.
3. 3Write a one-page breach plan: who is told, who assesses, how the Data Protection Board and affected patients are notified.
4. 4Rehearse it once. A lost laptop is a good tabletop scenario.

A breach must be reported to the Board and to the affected Data Principals. The Rules under the Act set out the form and timing; your plan should point to whichever version is current rather than copying a deadline that may change.

Part 7. Vendors and processors.

Your EMR vendor, your lab's software, your messaging provider and your accountant are Data Processors when they handle patient data on your behalf. The Act keeps you, the Fiduciary, responsible for what they do with it under contract.

• Have a written agreement with each processor covering security, sub-processors, breach notification and deletion at the end of the contract.
• Know where each of them hosts data.
• Ask how patient messaging is handled. If your EMR sends WhatsApp messages through a third-party BSP, that is another processor in the chain. Saaro sends through SaroConnect, Lumotis's own WhatsApp Business infrastructure, so there is one contract to review rather than two.

What a finished checklist looks like.

When you are done you should have a one-page inventory, a notice patients actually see, consent recorded per purpose in the EMR, named logins with roles, a retention table, a named contact for requests and a breach plan someone has read.

That is the substance of DPDP readiness for a clinic. The rest is keeping it current. Our DPDP compliance page lists which of these items Saaro handles as product controls and which stay with the clinic.