DPDP Act Readiness for Clinics in India: A Practical 2027 Compliance Workflow

The DPDP Act received presidential assent in August 2023, but its provisions did not all commence immediately.

The official notification published on 13 November 2025 brought provisions concerning the Data Protection Board and supporting administration into force. It schedules section 6(9) and part of section 27 for one year after publication. Most operational duties and data-principal rights, including sections 3 to 17, are scheduled for eighteen months after publication.

Unless the schedule is amended, that places the main operational commencement date on 13 May 2027. The final DPDP Rules use a corresponding phased schedule. DPDP Act commencement notification and Digital Personal Data Protection Rules, 2025.

As of 9 September 2026, a clinic should not describe all DPDP operational provisions as already in force. It should also not wait until May 2027 to begin.

Use the preparation period to build processes that staff can actually follow:

• Data and purpose mapping
• Clear privacy notices
• Consent and withdrawal handling
• Patient access and correction requests
• Record-retention decisions
• Vendor and processor oversight
• Security safeguards
• Breach response
• Staff training
• Evidence of completed actions

The timeline does not suspend existing duties concerning medical confidentiality, professional records, cybersecurity, contracts, or applicable State requirements.

The DPDP Act uses specific roles.

A Data Principal is the individual to whom the personal data relates. In a clinic, this will commonly be the patient. The Act also addresses parents, lawful guardians, and individuals nominated to exercise rights in specified circumstances.

A Data Fiduciary determines the purpose and means of processing personal data. A clinic may perform this role for patient registration, care delivery, billing, communication, and clinic administration.

A Data Processor processes personal data on behalf of a Data Fiduciary.

Do not assign these labels only by looking at the software invoice. The actual role depends on what each organisation decides and does.

For example:

• The clinic decides which patient information is required for care.
• A clinic-software provider may host or support the system.
• A messaging provider may transmit appointment or prescription messages.
• A laboratory may process an investigation and also have its own professional responsibilities.
• An AI or speech provider may receive selected information for an optional feature.
• A backup or infrastructure provider may store encrypted data.

Record the proposed role of every party, then confirm it through the contract and qualified legal advice.

The clinic remains responsible for understanding processing performed on its behalf. The Act states that a Data Fiduciary is responsible for processing undertaken by it or on its behalf and may engage a processor for relevant activities under a valid contract. Digital Personal Data Protection Act, 2023.

Begin with workflows rather than database tables.

Map personal data across:

• Enquiries and appointment requests
• Patient registration
• Identity and contact verification
• Consultation notes
• Vitals, allergies, diagnoses, and clinical observations
• Prescriptions
• Laboratory orders, reports, and attachments
• Pharmacy dispensing and billing
• Clinic invoices and payments
• Referral records
• WhatsApp, SMS, email, and telephone communication
• Audio recording and AI-assisted workflows
• Staff and practitioner records
• Audit logs
• Support access
• Backups
• Data exports
• Archived or deleted accounts

One broad consent statement should not be used to justify every activity.

The DPDP Act provides for processing for a lawful purpose based on consent or certain legitimate uses. Its consent provisions describe consent as specific, informed, unambiguous, based on clear affirmative action, and limited to the personal data necessary for the specified purpose.

The Act also includes certain legitimate uses, including processing voluntarily provided data for the specified purpose and responding to medical emergencies. These provisions should not be stretched into a permanent emergency exception for routine analytics, marketing, or unrelated product development.

Build a purpose table such as:

The Act’s notice provisions require information about the personal data and proposed purpose, rights, and complaint route. The final Rules provide more detail for a clear, standalone notice with an itemised description of the data, the purpose, and a route for withdrawal, rights, and complaints.

A clinic notice should be understandable without forcing the patient to interpret a long vendor contract.

Include:

• Clinic identity and contact information
• Categories of personal data
• Purposes of processing
• Optional processing choices
• Important recipients and processors
• How to withdraw consent where consent is the basis
• How to request access, correction, completion, updating, or erasure
• Grievance contact
• Important retention qualifications
• Date and version of the notice

The Act provides for access to notices and consent requests in English or a language listed in the Eighth Schedule to the Constitution.

The DPDP Act sets out rights concerning access to information, correction, completion, updating, erasure, grievance redressal, and nomination.

Create one request desk rather than directing each issue to a different employee.

The request record should contain:

• Unique request number
• Patient identity
• Requester and relationship
• Identity-verification method
• Right being exercised
• Data or workflow concerned
• Date received
• Assigned owner
• Clinical or legal review required
• External processor involved
• Decision
• Action completed
• Information sent to the requester
• Closure date
• Escalation or grievance status

Patient identity must be verified without collecting excessive additional information.

Access requests may require a summary of processed personal data and information concerning sharing with other fiduciaries or processors. Corrections should preserve the history necessary to understand clinical and operational records.

An erasure request should not trigger indiscriminate deletion. The Act itself recognises that retention may remain necessary for the specified purpose or compliance with another law. The clinic must reconcile privacy requests with applicable professional, medical-record, billing, pharmacy, dispute, and statutory obligations.

See CliniKite’s guides to medical-record corrections and medical-record retention for the underlying operational workflows.

The Act contains specific provisions for children and people with lawful guardians. The final Rules prescribe verification approaches and limited exemptions.

The Fourth Schedule includes a conditional exemption for a clinical establishment, mental-health establishment, or healthcare professional when processing is restricted to providing health services to a child to the extent necessary to protect the child’s health.

That is not a general exemption for every use of children’s data.

A clinic should still distinguish:

• The child
• Parent or lawful guardian
• Person bringing the child for care
• Person authorised to receive information
• Person paying the bill
• Mobile number used for communication
• Consent for an optional communication or recording
• Clinically necessary processing
• Marketing or secondary use

Do not assume that the adult holding the phone has authority for every decision or disclosure.

Maintain relationships and communication permissions explicitly. The patient registration and family relationships guide provides a practical starting point.

Because the Act, Rules, guardianship law, professional duties, and the circumstances of care may interact, clinics should obtain qualified advice for their paediatric and guardian workflows.

“Secure” is not an operational specification.

The final Rules describe safeguards including encryption, obfuscation, masking or tokenisation where appropriate, access control, logging and review, backups, continuity measures, processor contracts, and technical and organisational controls.

Although the relevant operational Rules are scheduled for May 2027, these measures require preparation.

Evaluate:

• Individual staff accounts
• Role-based access
• Multi-factor authentication for administrative access
• Encryption in transit and at rest
• Secure backups
• Restore testing
• Audit logs
• Access review
• Session and device controls
• Support-access approval
• Security-update responsibility
• Export controls
• Secure deletion
• Incident detection
• Vendor notification obligations

The Rules also describe one-year retention of specified security logs and related information for security purposes once the relevant provisions commence, unless another law requires different retention.

Do not confuse this with the retention period for the medical record itself.

The role-based access guide and backup and recovery guide can help convert these safeguards into demonstration tests.

The Act requires notification to the Board and affected Data Principals in the prescribed manner after a personal-data breach.

The final Rules describe affected-person communication without delay and an initial Board notification without delay, followed by detailed information within seventy-two hours unless the Board allows longer.

Build the process before an incident:

• 1. Confirm the report and preserve evidence.
• 2. Contain the affected account, device, integration, or service.
• 3. Identify the data, people, period, and systems involved.
• 4. Record what is confirmed and what remains uncertain.
• 5. Escalate to the clinic’s named incident owner and advisers.
• 6. Coordinate with affected processors.
• 7. Determine applicable notifications and timelines.
• 8. Prepare clear patient communication.
• 9. Record mitigation and recovery.
• 10. Review the cause and prevent recurrence.

CERT-In directions may create separate cybersecurity-reporting and log requirements for applicable organisations and incidents. A DPDP notification does not automatically satisfy every other reporting duty. CERT-In directions under section 70B.

Avoid promising that an incident “caused no harm” before the facts support that statement.

Deletion should not be an improvised support request.

Create a retention schedule for:

• Registration records
• Consultation records
• Prescriptions
• Laboratory records
• Pharmacy records
• Bills and payments
• Consent records
• Messages
• Audio files
• AI drafts
• Audit logs
• Security logs
• Backups
• Support records
• Marketing contacts

For each category, document the purpose, applicable requirement, start event, minimum period, extension reason, archive method, deletion method, and approving role.

The National Medical Commission’s published ethics regulations include specific medical-record maintenance and patient-request provisions. They do not establish one universal period for every outpatient, financial, pharmacy, security, and operational record. NMC Code of Medical Ethics Regulations, 2002.

Keep consent withdrawal, account closure, record correction, archive, and deletion as separate actions.

A clinic cannot evaluate privacy only inside the EMR.

Ask every relevant provider:

• What data do you receive?
• For which purpose?
• Are you acting on behalf of the clinic?
• Which subcontractors are involved?
• Where is the information processed and stored?
• Can staff access it?
• How is support access approved?
• What security safeguards apply?
• What is logged?
• How quickly are incidents reported to the clinic?
• How is data returned or exported?
• What happens after termination?
• How is deletion verified?
• Can the contract change without notice?

The Act allows the Central Government to restrict transfers to specified countries or territories and preserves other laws that provide stronger protection or restrictions. Do not claim that the DPDP Act creates a blanket India-only hosting rule for all clinic data.

Data location still matters operationally. It affects contracts, support, incident coordination, latency, exit planning, and the clinic’s own risk decision.

Receptionists, doctors, nurses, pharmacists, and owners do not need to memorise section numbers. They need to recognise the actions that create risk.

Training should cover:

• Confirming the correct patient
• Using individual accounts
• Avoiding shared passwords
• Checking communication recipients
• Recording optional consent
• Handling withdrawal
• Recognising a rights request
• Avoiding unrestricted spreadsheet exports
• Using approved support channels
• Reporting a suspected breach
• Preserving a correction history
• Escalating unusual requests
• Avoiding clinical details in general tickets

Run short scenarios using fictional data.

For example: a parent asks for a child’s report through a different mobile number; a former staff member still has access; a patient withdraws WhatsApp consent; a support engineer requests an export; or a prescription PDF is sent to the wrong recipient.

The exercise should show who acts, who approves, and where the outcome is recorded.

CliniKite’s current public pages describe managed deployment in India and an On-Premise option, role-based access, attributable activity, backups, exports, and explicit optional data paths for WhatsApp, voice, and AI. CliniKite features and CliniKite security and data.

These statements provide useful evaluation context. They do not replace the clinic’s legal assessment or prove that every readiness control in this article is implemented in every release or plan.

During a demonstration, ask CliniKite to show:

• Where the primary clinic database runs
• Which optional features send data elsewhere
• Which processors receive that data
• How staff permissions are configured
• How support access is approved and recorded
• How consent and communication preferences are stored
• How a patient record is corrected
• How data is exported
• Which attachments and audit records are included
• How backup restoration works
• How access is removed when staff leave
• How incidents are communicated
• What happens when the clinic terminates service
• Which DPDP-readiness responsibilities remain with the clinic

Use synthetic data and request written confirmation for requirements essential to the clinic.

DPDP readiness is a clinic workflow, not a privacy-policy page.

Start with the commencement timeline, map each data flow, identify the clinic and vendor roles, separate care from optional processing, and create workable notice, consent, patient-rights, security, retention, and breach processes.

Then test the controls with fictional clinic scenarios.

By May 2027, the clinic should be able to explain what personal data it processes, why it needs it, where it travels, who can access it, how a patient exercises rights, how vendors are controlled, and what the team does when something goes wrong.