DPDP readiness checklist for the software your business runs

Open a blank sheet and list every place where a customer or employee name can be typed, imported, scanned or stored, in a cloud tool or a drawer. Include biometric attendance machines and CCTV recorders, which nobody thinks of as databases, though both hold faces, names and timestamps that identify a person. Most firms find more than they expected. Write them all down.

The WordPress contact form plugin, the Zoho or HubSpot CRM, the Razorpay dashboard, the payroll spreadsheet, the WhatsApp Business inbox and the S3 backup bucket usually all qualify. So does the shared drive that still holds last year’s Excel export of every customer, complete with phone numbers and addresses nobody has cleaned up since.

Give each system one named owner. Without that, every later check stalls. Nobody knows who may change a setting. Add the vendor behind each tool too, because a hosted CRM means an outside processor holds your customer records on servers you never see and cannot inspect yourself.

Open each form on a phone, the way a visitor would see it, and read it from top to bottom before you touch a single setting. Is a notice visible before the submit button, and does it say what you collect and why in words a shop customer would follow? A footer link rarely passes.

Then look at the record behind the tick. When someone agrees, does your system store the timestamp, the exact wording they saw, the version of the form and the page address where they ticked? A tick that leaves no trace proves nothing.

Pre-ticked checkboxes and bundled consent hide in old Google Forms, plugin templates and the landing pages a marketing agency built three years ago. Fix those first, because they are quick.

Export the user list from the CRM and the billing tool, and read every name slowly against the current staff list from HR. A leaver from March often still has access. Expect a shared admin login passed around three desks, and a sales rep with permission to export the whole lead table to CSV. Remove, split or restrict each one.

Next comes retention. For each data type, write down how long it is needed, what event ends that need, and who confirms the event has happened. A rejected applicant’s CV, a closed enquiry, a paid invoice and an expired warranty claim each run on a different clock, so one blanket rule fits none of them.

Many tools keep everything forever by default. That is the trap. Look for an auto-delete or archive setting. If none exists, put a monthly clean-up on a shared calendar, assign it to a named person, and tick it off in the incident log described below.

Pick a test customer and ask for their data to be erased, then follow the request through every system on your list. Does it vanish from the CRM yet survive in the invoice PDF folder, the Mailchimp audience, last month’s database dump and an old export on a manager’s laptop? Write down each place it lingers.

Backups need a rule, even a plain one. Older copies expire on a schedule, and a restore never brings deleted people back without a re-check against the erasure list, which you keep beside the backup schedule.

Finally, start an incident log. A shared sheet will do. Keep it simple. Record the date, what happened, which system was involved, who was told, how long the problem lasted and what changed afterwards so it cannot repeat.

Collect every failed check into one spreadsheet. Score each gap by how many people it touches, and by how hard it is to repair given the vendor’s admin panel. A pre-ticked box is an hour of work. A missing audit trail in an old desktop invoicing package may be a whole project with its own developer, test plan and release date.

Take the table to your lawyer. Your lawyer decides what the Act asks of your business, and you bring the facts about what each tool really stores, shows, shares and deletes.

Book the quick fixes this week and schedule the harder ones, such as log retention and schema changes, into the next quarter. Then repeat the walk-through every six months.