We are adding analytics next sprint.
The consent you hold may not cover the new purpose. The engine cites the purpose-limitation obligation, gives you the framework's test method, and tells you what evidence would show it.
For developers
Get your codebase and deployments DPDP ready.
For engineering teams. Point your agent at the product and its deployment, scope the technical obligations, and work them with the engine behind it.
The deadline is real
DPDP is an engineering problem, and it has a date.
Consent failures are architectural. They live in your notice, your capture flow, your retention jobs and your logs, not in a policy document. MeitY has said there will be no extensions.
199
obligations the engine can scope against your product
72 h
to report a breach to the Data Protection Board
6 h
to report a cyber incident to CERT-In, separately and already in force
13 May 2027
when the substantive obligations bite, with no grace period
13 Nov 2026
Consent Managers
Registration opens, and the ecosystem you may have to integrate with goes live.
13 May 2027
Notice, consent, security, breach
The substantive obligations commence together, including SDF duties.
Where the obligations land
Every obligation has a home in your stack.
This is the same obligation set the engine holds, sorted by where the work actually happens.
Frontend
- Notice at every collection point
- Consent that is specific and informed
- Rights: access, correction, erasure
- Children's consent verification
Backend and API
- Consent enforced at the point of use
- Purpose limitation per data field
- Retention and erasure jobs
- Rights endpoints
Data
- Encryption at rest and in transit
- Retention windows per purpose
- Cross-border transfer rules
- Erasure you can prove
Infra and ops
- Access control and logging
- Breach detection
- CERT-In 6 hours
- Board notice 72 hours
What your agent sees
It knows what to look for. It does not decide for you.
● scan · https://staging.astra.example16 checks · 2 fail
✓ notice published and reachable
✓ transport security (TLS 1.2+)
✗ 2 trackers fire before consent
✓ contact for data queries published
✓ withdrawal route present
Finding raised · DP-F-5.3 · consent before processing · tier P2. Re-scan after the fix.
The test method, cited
Your agent queries the obligations and the framework's own test methods, with the page they came from. You get what to look for, not a conclusion handed to you.
A scanner on your machine
It tests the live deployment from outside, and runs locally, so it reaches staging and pages behind a login. A scan can show a control is present; it can never show it operates.
Evidence from config and logs
Attach the artefact. It is hashed on receipt, and the assessment must quote the passage it relied on.
Findings coded to the provision
Each finding carries its DP-F code, provision and penalty tier, and feeds a 30/60/90 plan. Precise enough to hand to an engineer.
What it looks like
Three Slack messages.
01
02
Is our consent flow actually compliant?
Your agent scopes the obligations that touch the flow, and the scanner checks the live deployment from outside: the notice, trackers before consent, transport security, the published contact.
03
Staging fires trackers before consent.
The scanner runs on your machine, so it reaches staging and pages behind a login. You get a finding coded to the provision, a fix, and a re-scan.
Get started
One line, one sign-in.
The endpoint
https://www.dpdpdone.com/mcp
Sign-in is OAuth 2.1, handled once by your assistant in a browser tab. There is no API key to paste.
Claude Code, one line
claude mcp add --transport http dpdpdone https://www.dpdpdone.com/mcp
Any MCP-capable agent works the same way.
Ship DPDP-ready, with the framework behind you.
Free to start. Pro is ₹500 a month, introductory.
First finding in about ten minutes.