DPDP Act Compliance Checklist for Indian Companies (2026)

Most boards I sit in front of think DPDP is a policy problem. Draft a privacy notice, publish it, tick a box. Then I ask one question that ends the meeting: show me, right now, every system that holds a customer's phone number and who inside your company can read it. Silence. Nobody knows. That single unanswered question is the whole compliance gap in one sentence.

The Digital Personal Data Protection Act, 2023 (DPDP Act) is not the GDPR with an Indian accent. It is shorter, sharper and in some ways less forgiving. The Data Protection Board can impose penalties up to 250 crore rupees per instance for failing to prevent a breach, and the draft DPDP Rules, 2025 put hard clocks on things Indian companies have never had to time before. If you are treating this as a documentation exercise, you have already lost. This is an engineering and operations problem wearing a legal costume.

India has had privacy language before. The IT Act Section 43A and the SPDI Rules of 2011 asked for reasonable security practices and consent for sensitive data. Almost nobody enforced them. The result was a compliance culture that learned it could write a policy, never operationalise it, and never get caught. DPDP breaks that habit for three reasons.

You, as the Data Fiduciary, are the entity that decides why and how personal data is processed. Your cloud vendor, your payment gateway, your call-centre BPO, your email tool: those are Data Processors acting on your instructions. The Act holds you accountable for what they do. You cannot outsource the liability. That single clause redraws every vendor contract you have signed.

After running DPDP gap assessments across banks, health-tech firms and D2C brands, I have stopped presenting findings as a flat list. Nobody fixes a flat list. I present it as seven layers, deliberately ordered so that each layer depends on the one above it. You cannot build consent without a data map. You cannot honour erasure without retention rules. Work top to bottom.

Everything starts here, and this is where 90 percent of programmes stall. You cannot protect, delete or account for data you have not located. A DPDP data map is not a diagram drawn by a consultant in a workshop. It is a living record of every data element, its source, its purpose, its storage location, its lawful basis, its retention period and its downstream recipients.

Here is what actually happens. A mid-size lending firm told me they had two systems holding customer PII. We ran a discovery scan. We found forty-one. The marketing team had exported the full customer base to a spreadsheet on a shared drive in 2022 for a campaign, and it was still there, unencrypted, readable by nineteen people. There was a WhatsApp Business export sitting in an S3 bucket with no lifecycle policy. Their support team was pasting Aadhaar numbers into a helpdesk ticketing tool that stored them in plain text forever. None of this was in their policy. All of it was in their environment.

Your data map must capture, per data element:

DPDP recognises two broad grounds for processing: consent, and certain legitimate uses defined in the Act, such as an individual voluntarily providing data for a stated purpose, employment, medical emergencies and legal obligations. For most commercial processing you will rely on consent, and the bar is specific. Consent must be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action.

Read that again. Unconditional means you cannot bundle consent to marketing with the delivery of the core service. Pre-ticked boxes are dead. A single blanket consent covering eleven unrelated purposes is dead. Every request must be accompanied by, or preceded by, a notice in plain language, and the draft Rules require you to offer that notice in English and the languages of the Eighth Schedule to the Constitution. The individual must be able to withdraw consent as easily as they gave it, and withdrawal must be as frictionless as the sign-up.

The artefact that fails audits here is the consent record itself. When the Board asks you to prove that a specific person consented to a specific purpose on a specific date under a specific notice version, can you produce it? Most consent management is a checkbox that writes true to a database column with no timestamp, no notice version and no audit trail. That is not a consent record. That is a rumour.

Every record you keep past its purpose is a liability with no upside. DPDP requires you to erase personal data once the purpose is served and retention is no longer necessary for a legal obligation, unless another law compels you to keep it. The draft Rules go further for large platforms, proposing a default erasure of certain data after the Data Principal has been inactive for a defined period, with prior notice before deletion.

This collides head-on with sector rules you already follow. The RBI KYC Master Direction requires you to retain KYC records for five years after the business relationship ends. The Prevention of Money Laundering Act mandates similar retention. SEBI, IRDAI and tax law each impose their own clocks. DPDP does not override these; it sits alongside them. So your retention schedule must map, per data category, the maximum permitted retention under DPDP against the minimum required retention under sector law, and resolve the conflict explicitly.

Individuals can ask you what data you hold about them, request correction and completion, request erasure, and raise grievances. They can also nominate someone to exercise these rights on their behalf in the event of death or incapacity. The draft Rules attach timelines, and grievance redressal in particular has a defined response window that you must publish and meet.

The operational trap is that a rights request is not a legal task, it is a data task. To answer an access request honestly, you must pull every fragment of that person's data from all forty-one systems your map revealed. If you have not built the map, you cannot answer the request, and a missed request is itself a compliance event. Build a rights-fulfilment runbook now, with named owners, a ticketing workflow, an identity-verification step, and a hard SLA measured in days.

This is the layer companies discover last and regret most. You remain the Data Fiduciary even when a vendor does the processing. That means every processor must be bound by a valid contract that restricts them to your documented instructions, and you are responsible for their security failures. When was the last time you read the data-processing terms of your CRM, your analytics platform, your SMS gateway or your offshore support desk?

A retail client of mine had a clean internal environment and still failed the assessment, because their loyalty programme was run by a third party that was quietly reselling aggregated purchase data to advertisers. Under the old regime, arguable. Under DPDP, that is the client's liability, because the client is the Fiduciary and never authorised or even knew about the onward sharing. Sub-processors are the blind spot. Your vendor's vendor is still your problem.

This is where DPDP is stricter than most people realise, and where it stacks on top of an obligation you may already have missed. Under the draft DPDP Rules, on becoming aware of a personal data breach you must notify affected Data Principals without delay, and notify the Data Protection Board within seventy-two hours, with an initial description followed by fuller details. Separately, the CERT-In Directions of April 2022 already require reporting of cyber incidents to CERT-In within six hours. These are two different regulators, two different clocks, one incident.

Six hours is brutal if you are not ready. What actually sinks companies is not the reporting itself; it is detection. You cannot report a breach you have not noticed. I have investigated incidents where attackers exfiltrated data for weeks and the first the company heard of it was a customer complaint or a dark-web listing. If your logging, alerting and monitoring cannot tell you a breach is happening in near real time, your seventy-two-hour and six-hour clocks are meaningless because they never start on time.

The Central Government can classify certain organisations as Significant Data Fiduciaries based on volume and sensitivity of data, risk to Data Principals and other factors. If you are notified as one, additional duties apply: you must appoint a Data Protection Officer based in India who reports to the board, appoint an independent data auditor, and conduct periodic Data Protection Impact Assessments. Even if you are not an SDF, appointing a clear owner and running impact assessments on high-risk processing is the difference between a programme and a paper.

Governance is what makes the other six layers defensible. When the Board comes calling, they will not just ask whether you had controls. They will ask who owned them, how you tested them, and how you proved they worked. Accountability under DPDP is demonstrable accountability, not asserted accountability.

If you do nothing else this quarter, do this, in this order. Each item unblocks the next.

The board that could not tell me who could read a customer's phone number was not negligent. They were normal. Almost every Indian company is in exactly that position, because for fifteen years the rules rewarded policy over practice. DPDP inverts that. It rewards companies that know their data cold and punishes those who only know their policy. Start with the map, and the rest of the Act stops being abstract.

At CyberSigma, we run DPDP gap assessments and readiness programmes hands-on as senior CERT-In empanelled auditors and PCI QSAs, sitting in your environment and building the artefacts with your team rather than handing you a template. If you want a second set of eyes on where your seven layers actually stand, that is the work we do.