DPDP Act 2023: What Your Business Must Do

Most DPDP coverage explains the law. This explains the work. If you hold personal data about people in India — and if you have customers, you do — here is what has to change, in the order it is worth doing.

None of this is legal advice. It is the engineering and process work that compliance obligations translate into, written by the people who have to build it. Where the law is genuinely ambiguous, we say so rather than inventing certainty.

First, the two words the Act runs on

Two definitions carry most of the obligations, and getting them straight makes the rest legible:

• Data fiduciary — whoever decides why and how personal data is processed. If you run the business collecting the data, that is you, and the obligations are yours even when someone else does the processing.
• Data processor — whoever processes it on your behalf. Your CRM vendor, your payroll provider, your cloud host. You remain accountable for what they do with it, which is why the contract matters.

There is no turnover or headcount threshold below which the Act stops applying. A ten-person firm with customer phone numbers in a spreadsheet — or in a CRM — is a data fiduciary.

Step 1 — Map what you actually hold

Every other obligation depends on this, and almost nobody has it written down. You cannot honour a deletion request for data you have forgotten you keep.

Build one table. For every system holding personal data, record:

• What personal data it holds, field by field — name, phone, email, address, ID numbers, anything identifying
• Why you hold it, stated as a purpose a customer would recognise
• Where it physically lives, including backups and any third-party service
• Who can read it, and who can export it
• How long you keep it, and what triggers deletion

Do not forget the unglamorous places: WhatsApp groups, the shared inbox, exported spreadsheets on someone's laptop, the old CRM nobody logged into since the migration, CCTV, visitor books, and form submissions emailed to a distribution list. These are where most real exposure sits.

Step 2 — Fix consent at the point of collection

Consent under the Act must be free, specific, informed, unconditional and unambiguous, and given by a clear affirmative action. In practice that rules out several patterns that are still everywhere on Indian websites:

• Pre-ticked boxes. Not an affirmative action.
• Bundled consent. One tick covering the service, marketing emails and sharing with partners is not specific.
• Consent as a condition of service for data the service does not need. You cannot require marketing consent to deliver an order.
• Notices written for lawyers. The Act requires plain language and an option to receive it in the languages listed in the Eighth Schedule.

What has to exist alongside it: a withdrawal mechanism as easy to use as the original consent, and a record of what each person consented to and when. That record is the only thing that proves consent existed if it is ever questioned — which means consent has to be stored as data, not as a design decision on a form.

Step 3 — Build the rights machinery

Data principals — the people whose data you hold — can ask you for things, and you need a route that answers rather than a promise that you would:

Right	What you must be able to do
Access	Tell them what you hold and who you shared it with
Correction	Amend inaccurate or incomplete data across every system holding it
Erasure	Delete it, unless you are legally required to keep it
Grievance	Provide a working complaint route and respond within your stated period
Nomination	Let a person nominate someone to exercise their rights if they die or are incapacitated

The engineering implication is the one teams underestimate: erasure has to reach backups, analytics, exports and any processor you sent the data to. A delete button that clears one row in the production database and leaves six copies elsewhere is not erasure.

Step 4 — Security safeguards you can evidence

The Act requires reasonable security safeguards without prescribing a specific standard, which makes "reasonable" the operative word. What a regulator can see afterwards is what you can evidence:

• Encryption in transit and at rest — HTTPS everywhere, encrypted database storage, encrypted backups
• Access control scoped to role, reviewed on a schedule, and removed the day someone leaves
• Logging of who accessed and changed personal data, retained long enough to investigate
• Patching with a defined cadence, and a record that it happens
• Processor contracts that bind your vendors to the same standards

The largest penalty head under the Act attaches to failing to take reasonable safeguards where a breach follows. That is worth knowing when the security budget is being argued about.

Step 5 — Be able to report a breach

Breach notification to the Data Protection Board and to affected individuals is an obligation, and it is the one that most often finds organisations unprepared — because it is not a control you build, it is a rehearsal you have never run.

Write the plan while nothing is on fire. It needs: who decides that an incident is a breach, who notifies, what the notification says, how you reach affected people, and where the evidence is kept. Then rehearse it once. An hour of tabletop exercise is worth more than a fifty-page policy nobody has opened.

If you operate infrastructure in India you are likely also subject to the CERT-In directions, which carry their own — and tighter — reporting timelines. Treat them together rather than discovering the overlap during an incident.

Step 6 — Retention, which is where the risk quietly accumulates

The Act expects personal data to be erased once the purpose is served and retention is no longer required. Most Indian businesses keep everything forever by default, which converts every old record into standing liability for a purpose that expired years ago.

Set a retention period per data type, implement it as a scheduled job rather than an intention, and log the deletions. The uncomfortable conversation is with whoever wants to keep all historical data "just in case" — the answer is that undeleted data you have no purpose for is pure downside.

What this costs

For a small business already running reasonable systems, most of the work is process rather than software: writing the map, rewriting notices, defining retention. Budget engineering time for consent storage, the erasure path across systems, and access logging — typically a few weeks rather than a project.

The costs escalate when personal data is spread across systems that were never designed to delete anything, which is the usual finding and the usual argument for consolidating onto one system you control rather than six you partially do.