DPDP Act 2023 & Indian Privacy Law

What the DPDP Act is and why it arrived

The Digital Personal Data Protection Act 2023 is India's dedicated personal-data law, enacted after the Supreme Court recognised informational privacy as a fundamental right. It replaces the patchwork earlier governed by Section 43A of the Information Technology Act 2000 and the IT (Reasonable Security Practices… Sensitive Personal Data) Rules 2011 (SPDI Rules), which only covered "sensitive personal data" of a body corporate's customers. The DPDP Act is far broader and applies to all digital personal data.

The three roles you must learn

• Data Principal: the individual the data is about (for a child, this includes the parent/guardian).
• Data Fiduciary: any person who, alone or with others, determines the purpose and means of processing — usually your company. This is the role that carries almost every obligation.
• Data Processor: a person who processes data on behalf of a Fiduciary, such as a cloud host or payroll vendor.

What "personal data" covers

Personal data is any data about an identifiable individual. Unlike the old SPDI Rules, the Act does not carve out a separate "sensitive" category with special rules — a name, email, phone number, IP-linked identifier or photo all qualify. The Act applies to digital personal data, and to non-digital data that is later digitised.

Applicability (s.3)

• Processing of digital personal data within India.
• Processing outside India if it is connected to offering goods or services to Data Principals in India — so an overseas SaaS serving Indian users is caught.
• It does not apply to purely personal/domestic use, or to data made publicly available by the Principal or under a legal duty.

Common mistakes

• Assuming "we only hold names and emails, so we're exempt" — those are personal data.
• Relying on the old SPDI consent letters; they do not meet the DPDP standard.
• Thinking a foreign-hosted product escapes the Act when it targets Indian users.

Takeaway: If your business decides why and how personal data is handled, you are a Data Fiduciary under the DPDP Act 2023 — and the IT Act SPDI regime no longer defines your duties.

Consent is the default ground (s.6)

Under Section 6, where you rely on consent, it must be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the data necessary for the stated purpose. Bundled, pre-ticked or "accept everything to proceed" designs do not meet this standard. Consent may be withdrawn at any time, and withdrawal must be as easy as giving it.

The itemised notice (s.5)

Before or at the time of seeking consent, you must give a notice in clear, plain language describing the personal data to be collected, the purpose of processing, how the Principal can exercise their rights, and how to complain to the Data Protection Board. The notice must also be available in English or any of the languages in the Eighth Schedule to the Constitution. Build this with a DPDP privacy notice tailored to your actual data flows.

Consent managers and legitimate uses

• The Act introduces Consent Managers — registered intermediaries through which a Principal can give, manage, review and withdraw consent.
• Certain legitimate uses (s.7) allow processing without fresh consent, e.g. where the Principal voluntarily provided data for a specified purpose, for employment, or to comply with law — but these are narrow and must not be over-read.

Practical India guidance

• Use a separate, granular checkbox per purpose; never bundle marketing with service delivery.
• Log consent: what was shown, when, and the version of the notice.
• Provide a one-click "withdraw consent" path and honour it promptly.

Common mistakes

• Pre-ticked boxes or "by using this site you agree" banners.
• A notice that lists purposes vaguely ("for business purposes").
• Making withdrawal harder than consent (e.g. requiring an email to support).

Takeaway: A compliant flow pairs an itemised Section 5 notice with a Section 6 consent that is granular, logged and as easy to withdraw as to give.

The rights you must honour (ss.11–14)

• Right to access (s.11): a summary of the personal data being processed and the identities of other Fiduciaries/Processors with whom it has been shared.
• Right to correction and erasure (s.12): correction of inaccurate or incomplete data, and erasure of data no longer necessary for the purpose (unless retention is required by law).
• Right of grievance redressal (s.13): the Principal must first use the Fiduciary's grievance mechanism before approaching the Board.
• Right to nominate (s.14): the Principal can nominate another individual to exercise rights in case of death or incapacity.

Your matching duties

You must publish the contact details of a Data Protection Officer (DPO) or a person who can answer questions about processing, and you must respond to rights requests within the period the Rules prescribe. The Principal also has duties (s.15) — for example not to file false complaints — but this does not dilute your obligation to respond in good faith.

Significant Data Fiduciaries (s.10)

The Government may notify some Fiduciaries as Significant Data Fiduciaries (SDFs) based on volume and sensitivity of data, risk to Principals, and impact on sovereignty or public order. An SDF carries extra duties: appointing a DPO based in India who reports to the board, appointing an independent data auditor, and conducting periodic Data Protection Impact Assessments.

Common mistakes

• No published grievance channel, so Principals escalate straight to the Board.
• Treating an erasure request as optional when no legal retention duty applies.
• Assuming SDF duties apply to everyone — they apply only on notification, but plan for them if you handle large or sensitive datasets.

Takeaway: Stand up a documented rights-and-grievance workflow with a named contact now, and be ready for the heavier SDF duties if your data footprint grows.

You stay responsible — even through vendors (s.8)

Under Section 8, the Data Fiduciary is responsible for compliance even where processing is done by a Processor on its behalf. A Processor may be engaged only under a valid contract. So before you share personal data with a cloud host, analytics tool or payroll service, put a vendor data processing agreement in place that binds the vendor to your purposes, security and deletion requirements.

What the DPA must cover

• Processing strictly on documented instructions and only for the stated purpose.
• Security safeguards, confidentiality, and restrictions on sub-processing.
• Assistance with rights requests and breach reporting, and deletion or return of data on termination.

Breach notification (s.8(6))

On a personal data breach, you must notify both the Data Protection Board and each affected Data Principal in the form and manner prescribed by the Rules. There is no "harm threshold" filter in the Act — the default is to inform. Practically this means you need an incident-response runbook, contact templates and a log, ready before an incident happens.

Cross-border transfer

The Act takes a "blacklist" approach (s.16): personal data may be transferred outside India except to countries the Central Government restricts by notification. This is more permissive than a localisation mandate, but sector regulators (e.g. RBI for payment data) may impose stricter localisation that continues to apply. Map where each vendor stores and processes data so you can react if a country is restricted.

Common mistakes

• Relying on a vendor's standard terms with no DPDP-specific clauses.
• No breach runbook, so notification is late and disorganised.
• Forgetting that RBI/sectoral localisation sits on top of s.16.

Takeaway: Contract every Processor with a DPA, keep a tested breach-notification runbook, and maintain a data-location map so cross-border rules and sectoral localisation don't catch you out.

Start with a data inventory

You cannot protect or delete what you have not mapped. Build a record of processing: what personal data you hold, why, where it lives, who can access it, which vendors touch it, and on what legal ground. This inventory underpins your notices, your rights workflow, and your breach response.

Retention and deletion (s.8(7))

The Act requires you to erase personal data once the purpose is served and retention is no longer necessary or legally required. Set a documented retention schedule per data category and an automated or checklist-driven deletion workflow, including instructing Processors to delete on your behalf. Keep evidence that deletion happened.

Security safeguards and the InfoSec policy

Section 8 requires reasonable security safeguards to prevent a breach. Translate that into a written information security policy covering access control, encryption, logging, patching, backups and incident response — and review it periodically. This is also where the legacy IT Act 2000 / IT (Amendment) Act 2008 security and intermediary obligations continue to sit alongside the DPDP Act.

People controls

• Bind staff and contractors with an employee NDA and confidentiality terms covering personal data.
• Restrict access on a need-to-know basis and train staff on consent, rights and breach reporting.
• Keep adjacent compliance tidy — for example a workplace POSH complaint procedure involves sensitive personal data and should follow the same confidentiality discipline.

Common mistakes

• A policy folder with no data inventory behind it.
• Indefinite retention "just in case", which now breaches s.8(7).
• Security promises in the privacy notice that the InfoSec policy does not actually deliver.

Takeaway: A working programme is a data inventory plus a retention/deletion schedule, a real InfoSec policy and trained, NDA-bound staff — documented well enough to show the Board if asked.