DPDP compliance software,
in the order it has to be built.
The Act is explained in our guide. This is the programme: what to build first, which artefact each step produces, where the work usually stalls, and why a retention policy written before a data inventory is a documented breach rather than progress.
Build order, and why it is not negotiable
Every DPDP programme we have seen fail did the same thing: it started with policies, because policies are writable in a week and feel like progress. The obligations do not arrive in that order. Notice and consent generate evidence that cannot be backfilled, and data mapping gates everything downstream of it.
| Order | What you build | The artefact it produces |
|---|---|---|
| 1 | Data inventory: what you hold, where, why, for how long | A register naming systems, categories, purposes and retention. Every later step reads from this. |
| 2 | Notice, itemised per purpose, versioned, in the languages your users read | A versioned notice object, so "which notice did this person see?" has one answer. |
| 3 | Consent capture and the ledger behind it | An append-only record per person: purposes, timestamp, notice version, language, mechanism. |
| 4 | Withdrawal, as easy as consent, propagated to processors | A relay record per processor, showing the withdrawal actually reached them. |
| 5 | Rights handling on statutory clocks | Access, correction, erasure, grievance and nomination, each with a due date and an owner. |
| 6 | Breach detection and the notification path | An incident plan with a rehearsal date, and the ability to scope who was affected. |
Steps 2 and 3 are the ones that cannot be retrofitted: consent taken without a versioned notice cannot later be shown to have been informed.
Where programmes actually stall
- The inventory is never finished. It is treated as a project with an end date rather than a register that changes when systems change, so it is stale within a quarter
- Notice versioning is skipped. The banner is built, the notice text lives in a config file, and nobody can say what a given user was shown in March
- Withdrawal stops at the edge. Processing halts internally and the data sits in three downstream tools that were never told
- Language is treated as translation. Showing a Hindi notice is straightforward; proving which language a specific person was shown is the part that gets asked about
- Retention is documented and not enforced. A stated period with no deletion job is a standard you have written down and are failing
Who owns what
DPDP work is unusually cross-functional, and the failure mode is handing all of it to legal, who cannot build steps 1, 3, 4 or 6.
- Engineering. The inventory, consent capture, withdrawal propagation, deletion jobs, breach scoping
- Legal. Notice wording, lawful basis per purpose, SDF determination, grievance process, Board correspondence
- Product. Where the notice appears, how granular the choice is, how withdrawal is surfaced, "as easy to withdraw as to give" is a design requirement before it is a legal one
- Support. Usually the first to receive a rights request, and usually the last to be told what to do with one
Where this runs in the platform
Steps 2 through 5 are the consent manager, and it can be bought on its own as Consent by TryTrustable if DPDP is the only obligation on your plan this quarter. Step 1 is data discovery, step 6 is the breach workflow, and all of them write into the same evidence ledger, which is what makes "show me the consent for this person" a query rather than an investigation.
Before any of it, the free cookie scan tells you what your site does to visitors today, which is usually the fastest way to discover the size of step 3.
The things people ask us
What is the first thing to build for DPDP?
Notice and consent capture, because that is the obligation where the burden of proof sits on you and where the evidence cannot be reconstructed after the fact. A retention schedule written in month one and a consent ledger started in month six means six months of processing you cannot evidence.
How do we know if we are a Significant Data Fiduciary?
The government designates SDFs by notification, based on volume and sensitivity of data, risk to data principals, electoral democracy, security of the state and public order. You cannot self-certify out of it. Plan on the assumption that a consumer business at scale in India is a candidate, because SDF status pulls in a DPO based in India, an independent data auditor and periodic DPIAs.
Which of the 22 languages do we actually need?
The Act requires the notice to be available in English or any Eighth Schedule language. The practical test is your own user base: if a meaningful share of your users read Hindi, Tamil or Bengali, offering the notice only in English is hard to defend. Start with English plus the two or three languages your support tickets already arrive in, and record which language each person was shown.
What does a rights request actually require operationally?
Finding every system holding that person's data within the statutory window. Most companies fail this not on willingness but on inventory: the data lives in the product database, the warehouse, the CRM, the support tool and a spreadsheet. The rights SLA is a data-mapping problem wearing a legal costume.
How does this differ from our GDPR work?
The controls overlap heavily and the mechanics do not. DPDP has no general legitimate-interests basis, requires notice in Eighth Schedule languages, introduces the registered Consent Manager as an intermediary, and puts the burden of proving notice and consent squarely on you. Treat GDPR work as a strong starting position, not a completed one.
Is this page the law?
No. The obligations, the penalty schedule and the commencement dates set by the DPDP Rules 2025 are in the DPDP Act guide. This page is the implementation order and the artefacts each step produces.
Start with what you are running today.
We scan your site live, then show the same trackers held behind a versioned notice with the consent landing in the ledger.