DPDP Act 2023

Definition: what the Act actually governs

The Digital Personal Data Protection Act, 2023 regulates the processing of digital personal data in India. Personal data is data about an individual who can be identified by or in relation to that data, and digital covers what you collect through apps, websites, call recordings, chat logs, forms and imported spreadsheets. Processing is intentionally broad: collecting, storing, using, sharing, correcting, deleting and analysing all count.

The Act reaches organisations inside India and, in defined situations, organisations outside India that offer goods or services to people in India. That second limb matters for a SaaS business with an Indian customer base but servers elsewhere, and for a brand that runs campaigns into India from a regional hub. If you are profiling people in India or selling to them, you should assume the Act is relevant and take advice on the specifics.

Two ideas run through the whole statute. The first is that an organisation must have a lawful basis for processing, usually consent or one of the recognised legitimate uses. The second is that the person must be able to see what is happening, correct it, and have it removed when it is no longer needed. Everything else, including the paperwork, is machinery for those two ideas.

What it is not, and why the distinction saves money

It is not a clone of European data protection law. The vocabulary is different, the obligations are arranged differently, and several concepts that European practitioners expect are handled through rules, notifications and sector regulators rather than in the statute itself. Copying a GDPR programme across and renaming the documents produces a lot of paperwork that does not answer an Indian question, such as who is accountable when a marketing list is purchased from a data broker.

It is not a security standard. The Act requires reasonable safeguards, but it does not certify your encryption, your access control or your incident response. Those come from your own risk assessment and from sector regulators such as the financial or health authorities, whose instructions continue to apply alongside this Act. A team that treats compliance as a privacy policy rewrite will pass an internal review and fail the first serious incident.

It is also not a consent-banner law. Consent is one basis among several, and a banner that collects a click for everything is weaker than a purpose-by-purpose record. The distinction between a banner and a consent record is the difference between claiming permission and being able to show it. This page explains the concepts; it deliberately does not give legal advice, because the correct position depends on your facts and your sector.

The four roles, and where your business sits

A data principal is the individual the data describes. A data fiduciary decides why and how data is processed, and carries the accountability that follows. A data processor handles data on the fiduciary’s instructions under a contract. A consent manager is a registered intermediary that lets a person give, review and withdraw consent across organisations, accountable to the person rather than to the businesses it serves.

A single company often occupies two roles at once. A CRM vendor is a processor for its customers’ contact data and a fiduciary for its own website leads, billing records and support tickets. A D2C brand is a fiduciary for its customers and a processor when it runs a marketing programme for another brand. Mapping which role applies to which data set is the first useful artefact in any compliance programme, because the obligations differ and the contracts differ.

The Act also contemplates additional obligations for fiduciaries that process large volumes or sensitive categories, with the designation and the duties set out in the statute and the rules rather than left to interpretation. You do not need to guess whether you qualify today; you need a data map good enough to answer the question when it is asked.

Notice: the document that carries the proof

Notice is served before or at the point of collection, and it is specific to that moment. It says what data is being sought, why, what happens if the person declines, how to exercise rights and how to complain to the Data Protection Board. Plain language is part of the requirement, which rules out a single forty-page policy linked from a footer as the only notice a person ever sees.

The notice and the privacy policy do different jobs. The notice explains this collection: this form, these fields, this purpose, this retention. The policy explains the organisation’s overall practice and the categories of vendors it uses. Collapsing them produces a document too long to read at the point of collection and too vague to prove what a person was told on a Tuesday two years ago.

Versioning is the mechanism that makes notice auditable. Every notice gets an identifier and a date. Every consent records the identifier it was taken against. When the purpose changes or a new field is added, the notice changes and consent is refreshed for the people affected. Without that link, a later edit quietly rewrites history and the organisation can no longer demonstrate what anyone agreed to.

Consent mechanics, and the legitimate-use shortcut

Valid consent is a clear affirmative act, given for a stated purpose, after a notice the person could actually read. Pre-ticked boxes, silence, bundled terms and consent by continued use do not qualify. Consent must also be as easy to withdraw as to give, which has an engineering consequence: the withdrawal path has to exist in every channel where the consent was collected, not only on the website.

The Act recognises certain legitimate uses where consent is not required, such as performing a contract the person asked for, complying with a legal obligation, responding to a medical emergency, or processing for employment purposes. These are read narrowly. A legitimate use still requires notice, and it does not authorise repurposing data for marketing. In practice most outbound marketing sits on consent, while order fulfilment, invoicing and statutory retention sit on other bases.

The operational output is a consent ledger: one row per person, purpose, notice version, timestamp, collection point, channel and status. It has to be queryable in both directions, so you can answer what a person agreed to and which people agreed to a given purpose. That single table is the difference between a defensible campaign and an apology.

Rights requests: access, correction, erasure, grievance

A data principal can ask what you hold, ask for correction, ask for erasure, nominate someone to act on their behalf, and raise a grievance. The Act expects these requests to be answered within a defined process, and the practical burden falls on whoever can actually find the data. If a support agent cannot locate a person across the CRM, the helpdesk, the warehouse and the backup, the rights process fails at the first step.

Design the path before the first request arrives. An intake form that captures identity, the right being exercised and the channel. A verification step proportionate to the sensitivity of the data. A search that covers every system in the data map, including call recordings and chat transcripts. A response template that explains what was done, what was withheld and why. And a log that records the request, the evidence and the outcome.

Erasure is the hardest right to honour because data is copied by default. A deletion in the CRM does not remove the contact from the warehouse, the analytics tool, the email suppression list, the call recording archive or last quarter’s backup. Erasure has to be a workflow across the estate with a completion check, not a button in one application. Suppression entries are the exception worth keeping: you need to remember that someone asked not to be contacted.

Retention and erasure across the real estate

The Act does not prescribe one retention period for everything. It requires that data is kept only as long as the purpose needs it, unless another law requires longer. That means each purpose needs a stated period, an owner and a deletion mechanism. Invoices are kept for tax reasons, support tickets for a service window, marketing contacts while consent is live, and call recordings for a shorter quality window unless a dispute requires otherwise.

The hard part is the estate. Primary databases are the easy case. Logs, analytics events, exported spreadsheets, marketing automation copies, vendor-side archives and backups all hold the same person in different forms. A retention sweep that only touches the CRM gives a false sense of compliance, because the copy that matters in an incident is often the one nobody owns.

Make deletion observable. Every sweep should produce a record: which rule ran, which systems it touched, how many records it removed and what it could not remove. When a system cannot delete, it needs a documented compensating control such as tokenisation or a short retention window. The audit question is never whether you have a policy; it is whether you can show the policy ran.

• One retention period per purpose, written down with an owner.
• Sweep logs, analytics and exports, not only the CRM.
• Keep suppression records so erasure does not cause re-contact.
• Document systems that cannot delete and why that is acceptable.
• Review vendor retention at renewal, not only at onboarding.

Processors, sub-processors and the contract layer

Most Indian marketing stacks involve at least five processors: an email platform, a WhatsApp business solution provider, a voice or telephony provider, a CRM, and a cloud host. Each receives personal data and each needs a contract that limits it to your instructions, requires security, governs sub-processors and sets deletion terms. The Act puts the accountability on the fiduciary, so a weak vendor contract is your exposure, not the vendor’s.

Keep a sub-processor register and make it real. A vendor that adds an AI inference provider or a new analytics sub-processor changes where data goes, and a customer’s security questionnaire will ask exactly that. Review the register at renewal, confirm the notice period for changes, and check whether the vendor’s deletion actually covers backups and derived data.

Cross-border movement is permitted but conditioned. The practical discipline is to know which data leaves India, to which entities, for which purpose, and under what contractual terms. Marketing teams often discover that a campaign tool stores contact data in a region nobody documented, and that discovery usually happens during a customer audit rather than during onboarding.

Breach intimation and the evidence trail

A personal data breach triggers duties to intimate the Data Protection Board and to inform affected individuals, in the form and manner set out in the rules. The statute is deliberate about the sequence and the content, and it does not reward a public statement issued before the facts are known. The operational requirement is an incident process that can establish scope quickly: whose data, which systems, what categories, how many people, and whether the data left your control.

That scope question is answered by the same inventory that supports rights requests. If you cannot say which vendor held the affected data, you cannot say who was affected. If your access logs are incomplete, you cannot say what was accessed. Privacy engineering and security engineering converge here, and teams that built the data map early spend an incident answering questions instead of reconstructing them.

Keep the evidence. Incident timelines, decisions, notifications and remediations belong in a record that survives staff changes. The Board and affected individuals are entitled to a coherent account, and your own legal team will need one. A run trace for agent-driven actions is part of that record when the action was taken by software rather than a person.

Making it operational, and knowing it works

A working programme has six artefacts: a data map, a purpose register, a consent ledger, a rights workflow, a retention schedule and a processor register. None of them require a large team. They require one owner with authority across marketing, engineering and support, and a review cadence that survives quarter-end. The documents are worthless if they are written once for a customer questionnaire and never updated.

Measure the things that fail in practice. Percentage of contacts with a live consent record that names a notice version. Median time to close a rights request. Percentage of systems covered by an automated retention sweep. Number of vendors without a current contract. Age of the oldest unresolved data map gap. These are unglamorous metrics, and they predict incidents far better than a policy review.

A worked example: a D2C brand with 4,00,000 contacts discovers that 60,000 came from a purchased list in 2019, with no notice version and no source. The lawful answer is not to re-permission the whole file with one email, because a non-response is not consent. The workable path is to suppress the unexplained segment, rebuild consent through a specific offer with a clear notice, and keep the old records as evidence of what was held and why it was retired. That is slower than a campaign and considerably cheaper than a complaint.