DPDP readiness: a practical starting point

The instinct on privacy compliance is to publish a policy. It is the wrong place to start. A policy that does not describe what your systems actually do is not compliance; it is a written record of commitments you are not keeping, published on your own website, in your own name.

Privacy compliance is an operational question before it is a drafting question. Here is the order we work in.

Start with a data map

Work through, system by system, what personal data you collect, where it is stored, who has access, which vendors receive it, and how long it is kept. Include the systems nobody thinks of as systems: the shared drive, the support inbox, the analytics tool, the spreadsheet the sales team maintains, the WhatsApp group where customer details get pasted.

This is unglamorous work and it is the foundation for everything else. Most organisations find at least one surprise: a spreadsheet of customer records on a former employee's laptop, an analytics tool nobody remembers enabling, an integration that has been forwarding data to a vendor whose contract lapsed two years ago. You cannot protect data you do not know you hold, and you cannot answer a regulator's question about it either.

Then decide what you actually need

Data you do not hold cannot be breached, misused, or demanded of you. Minimisation is the cheapest control available and it reduces the scope of every other obligation you have. Go through the map and ask, for each field, what decision it supports. Fields collected because they might be useful later are the ones to cut.

Set retention periods while you are there, and make them real — a policy that says you delete records after three years, applied to a database that has never deleted anything, is worse than no policy at all.

Fix the vendor chain

Every processor handling personal data on your behalf needs an agreement that says what they may do with it, what security they will maintain, whether they may engage sub-processors, and what happens on termination. Cloud hosting, email delivery, analytics, payroll, CRM, support tooling: each one is a processor.

This is also where enterprise customers will press hardest during a security review, so the work has commercial value well beyond compliance. A company that can answer a vendor questionnaire in a day closes deals faster than one that takes three weeks and improvises.

Get consent mechanics right

Consent has to be a real choice, recorded, and withdrawable as easily as it was given. In practice that means the notice sits where the collection happens rather than only in a policy page, that pre-ticked boxes go, and that there is a working mechanism for withdrawal that reaches the systems actually holding the data.

Keep a record of what each person was told and when, because the notice will change over time and you will need to know which version applied.

Plan for the bad day

Notification obligations run on short clocks. Decide now who is called, who assesses severity, who drafts the notification and who signs it. Decide who talks to customers and who talks to the regulator. Write down the contact details, including out of hours.

A plan written during an incident is written badly, by people who have not slept, under time pressure, while also trying to stop the bleeding. Rehearse it once against a hypothetical and you will find the gaps cheaply.

Write the policy last. By then you will know what it should say.

The policy is the output of this work, not the start of it. Written at the end, it takes an afternoon and it is accurate. Written at the beginning, it takes an afternoon and it is fiction.