DPDP Compliance Software: How to Choose a DPDP Act Platform

Most of the DPDP compliance software demos I sit through solve the wrong problem. They show you a beautiful consent banner and a colour-coded dashboard, then go quiet the moment you ask the only question that matters in an actual notice from the Data Protection Board: show me, for this one data principal, every place their personal data lives, why you hold it, what consent you have on record, and when you will delete it.

That single question is the whole game. The Digital Personal Data Protection Act 2023 (DPDP Act) does not reward pretty screens. It rewards evidence you can produce on demand. So before you sign a contract, stop evaluating the tool as a marketing asset and start evaluating it the way an auditor will: as an evidence machine. This piece walks through what a DPDP platform must actually do, what to ignore, and how to test a vendor before they test your budget.

The DPDP Act 2023 was passed in August 2023, and the draft DPDP Rules were published for consultation in January 2025. As of now the operational timelines flow from those Rules, which stagger obligations rather than switch everything on at once. That staggering lulls teams into treating compliance as a future project. It is not. The obligations that hurt most are the ones that require you to have already built plumbing before an incident or a complaint arrives.

Here is what separates DPDP from a checklist regime like a one-time ISO 27001 certification. DPDP is continuous and principal-centric. Your obligations are triggered by individuals exercising rights, by breaches happening, and by the Board asking questions. You cannot pass by producing a policy PDF. You pass by producing records: consent artefacts, processing purposes, data flows, retention decisions, and grievance logs, all tied to specific people and specific moments in time. Software that cannot reconstruct that timeline is decoration.

Strip away the branding and there are four core jobs. If a tool is weak on any one of them, you will be doing that job in spreadsheets, which means you are not compliant, you are hoping. I grade every platform against these four before I look at anything else.

Consent is the feature every vendor demos and the one most of them get subtly wrong. The DPDP standard under Section 6 is that consent must be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the personal data necessary for the stated purpose. It must be as easy to withdraw as to give. And the notice you present must be itemised by purpose, not a single wall of text.

Watch what happens when you push a demo on this. Ask the sales engineer to withdraw consent for one purpose only, say marketing, while keeping consent for service delivery intact, and then show you the downstream effect: does the marketing system actually stop, and is there a record of exactly when and by whom it stopped. Many tools capture consent beautifully and then do nothing with the withdrawal. The consent record and the operational reality drift apart. That gap is precisely what a complaint to the Board will expose.

Data discovery and mapping is unglamorous, so vendors underinvest and buyers under-scrutinise. Then a data principal exercises their right to erasure under Section 12, and the organisation discovers their personal data lives in the CRM, the email marketing tool, three shared drives, a support ticketing system, a data warehouse, and six months of database backups. The tool that promised compliance mapped exactly one of those.

A real scene from an assessment. A mid-size lender, roughly 40 lakh customer records, bought a well-known consent platform. It worked. Then a principal filed a grievance that his data was still being used after withdrawal. On investigation, consent had been withdrawn in the platform, but a nightly ETL job kept copying fresh records from the core banking system into a marketing data mart that the platform had never been told existed. The consent state was correct in one system and invisible in the one actually sending the messages. The fix took eleven weeks and a lot of uncomfortable meetings. The tool was not lying. It was simply never connected to reality.

So the question for any platform is not can you store consent. It is how do you discover and keep in sync every system that touches personal data. Look for automated discovery, connectors to your real stack, and a way to represent data flows, not just a static register you update by hand and quietly stop maintaining after quarter two.

This is the obligation that turns a bad week into a regulatory event. Under the DPDP framework you must notify the Data Protection Board and each affected data principal of a personal data breach. Critically, DPDP does not carry a materiality or risk-of-harm threshold the way GDPR Article 33 does. The plain reading is broad: personal data breaches are reportable. That is a heavier default than most Indian teams are used to.

Layer on the CERT-In directions of April 2022, which already require reporting specified cyber incidents to CERT-In within 6 hours of detection. So a single incident can trigger two clocks running to two regulators with different forms and timelines. If your DPDP tool and your security incident response live in separate worlds, you will lose time you do not have reconciling them. The platform should let you move from detection to a structured, defensible notification without a committee meeting to decide who owns the template.

Vendor demos are choreographed. Break the choreography. Bring your own scenarios and make them run your data, not their sandbox. Below is the test script I use. If a platform passes these, it is doing real work; if it deflects, you have your answer.

Ballpark figures so you can sanity-check a quote. These move with data volume, number of systems, and whether you are a Significant Data Fiduciary carrying DPO and audit duties. Treat the low end as a small single-entity deployment and the high end as a multi-system enterprise.

Not everyone needs a dedicated platform on day one. The honest answer depends on your data footprint and your risk. A single-product SaaS company with one customer database and clean architecture can get a long way with a well-configured consent module, a maintained processing register, and a disciplined incident runbook. A bank, insurer, hospital chain, or ad-tech firm processing sensitive data across dozens of systems cannot, and should stop pretending a banner will save them.

If you do only the things on this list, and you do them properly, you will be ahead of most enterprises I audit. None of it requires the fanciest tool. All of it requires discipline the tool must support rather than fake.

Go back to that one question: for this person, show me everything. A DPDP platform is worth its licence fee if, and only if, it lets you answer that question completely, quickly, and with records you would be comfortable placing in front of the Board. Every other feature is in service of that, or it is theatre. Buy the evidence machine, not the dashboard.

If you want a second pair of eyes before you sign, our team at CyberSigma are CERT-In empanelled auditors who run these vendor tests hands-on and map DPDP obligations to your actual data estate. We would rather help you buy the right thing once than remediate the wrong one later.