DPDP compliance checklist for enterprises (2026)

India's Digital Personal Data Protection Act (DPDP Act, 2023) and its Rules (notified on 13 November 2025) apply to every company that handles digital personal data of people in India. Most duties apply in full from 13 May 2027. That sounds far away. For a large company with dozens of systems, it is not.

This checklist turns the law into seven steps. Tick each one off to see where you stand.

The 7 steps at a glance

Check where you stand

The step most companies get stuck on

Step 1. You cannot protect, report on or delete data you cannot find. In most large companies the same customer sits in the CRM, the ERP, billing, support tools and a few spreadsheets, often spelled differently in each.

So start there. Pick your three biggest systems, list the personal data in each, and note who owns it. Then add the rest.

Three simple rules that make the rest easier

1. Collect less. Data you never collect is data you never have to protect.
2. Write down the reason. Every piece of personal data should have a purpose next to it.
3. Log by default. If every access and change is logged, step 7 takes care of itself.

Each step in more detail

Step 1. Map the data

Start with a simple table. One row per system. For each one, write down:

• what personal data it holds (names, phone numbers, PAN, bank details, health data),
• whose data it is (customers, employees, vendors, website visitors),
• why you hold it (the purpose),
• who owns the system, and who can see the data,
• where it is stored, and whether it leaves India.

Do not forget the places nobody thinks of: shared drives, email inboxes, exported spreadsheets, call recordings and backups.

Step 2. Notice and consent

Before you collect personal data on the basis of consent, give the person a short notice. It should say what you collect, why, and how they can withdraw consent or complain. It must be in plain language, and people can ask for it in English or any language in the Eighth Schedule of the Constitution.

Consent must be free, specific, informed and clear. A pre-ticked box is not consent. Withdrawing must be as easy as giving it.

Some uses do not need consent. The Act calls these "legitimate uses". Examples include data a person gives you voluntarily for a specific purpose, and some employment purposes. Check these with your legal team before relying on them.

Step 3. Security safeguards

The Rules ask for "reasonable security safeguards". In practice, that means:

• encryption, masking or similar protection of personal data,
• access only for people whose role needs it,
• logs of who accessed what, so misuse can be spotted and investigated,
• backups, so data can be restored after an incident,
• the same standard written into contracts with your vendors.

Step 4. Breach reporting

Write a short breach plan before you need it. It should name who decides an incident is a breach, who tells affected people, and who files with the Data Protection Board. Run a practice drill once a year. The 72-hour clock for the detailed report is short when nobody knows who does what.

Step 5. Rights requests

People can ask to see a summary of their data, correct it, complete it, or have it erased. They can also name someone to act for them if they die or cannot act. You need one place to receive these requests, a way to confirm who is asking, and a way to find their data across every system. Step 1 makes this possible.

Step 6. Vendors

If a vendor processes personal data for you (payroll, cloud hosting, a call centre, a marketing agency), you are still responsible. List every such vendor. Make sure each contract covers security, breach reporting to you, and deleting data when the work ends.

Step 7. Proof

Keep records you can produce quickly: the data map, notices, consent records, access logs, breach reports and responses to requests. If the Board ever asks, these records are your answer.

Who does what

A simple 90-day starter plan

1. Weeks 1 to 4. Name an owner. Map your five biggest systems. List your vendors.
2. Weeks 5 to 8. Rewrite notices and consent flows. Turn on access logs. Review who can see what.
3. Weeks 9 to 12. Write and test the breach plan. Set up the rights-request process. Update vendor contracts.

Then extend the data map to the rest of your systems, and repeat the review every year.

Common mistakes

• Treating it as a website cookie banner. DPDP covers employee, vendor and offline data that is later digitised, not only web visitors.
• Collecting "just in case". Every extra field is extra risk.
• Keeping data forever. Once the purpose is served, the data should be erased unless a law requires you to keep it.
• Logs that nobody can search. A log you cannot query during an incident is not much help.

Key terms

• Data Principal: the person the data is about. For a child, this includes the parent.
• Data Fiduciary: your company, when it decides why and how data is used.
• Data Processor: a vendor that processes data for you.
• Consent Manager: a registered platform that helps people give, manage and withdraw consent.
• Data Protection Board: the body that handles complaints and breaches, and sets penalties.

Where Samvrik fits

Samvrik runs inside your own environment. Smelter keeps one record of each customer across your systems, with access by role and every action logged. Assembler adds the approvals: who signed off, when, and under which rule. That covers much of steps 1, 3 and 7. The legal side, notices and contracts, stays with your legal team.

Sources: Digital Personal Data Protection Act, 2023; Digital Personal Data Protection Rules, 2025 (Gazette notification, 13 Nov 2025). This is a plain summary, not legal advice.

Common questions