DPDP
Consent (DPDP)
How Erasure supports purpose-bound consent collection with durable proof.
Consent
Under DPDP-shaped work, organizations often process personal data on the basis of consent (among other possible grounds under the Act). Where consent applies, teams need free, specific, informed choices, and the ability to demonstrate what was agreed.
Erasure’s Accord product turns a banner into:
- Configured purposes and notice copy
- A published immutable version
- Append-only receipts when subjects choose
- Optional webhooks so backends can enforce choices
How Erasure supports this
| Need | Product behaviour |
|---|---|
| Purpose structure | Required and optional purposes in configuration |
| Consistent notice | Draft → Publish freezes a version |
| Proof of choice | Receipt stores choices + version / consent hash |
| Live integration | Browser SDK loads published config only |
| Backend reaction | consent.updated webhook (HMAC) |
| Origin control | Allowed origins (default on for new projects) |
What you do in Erasure
- Create a project.
- Configure purposes and notice.
- Publish.
- Create a publishable key; set allowed origins.
- Install the SDK; confirm receipts.
See Publish your first consent form and Consent (concept).
Limits (honest)
- Erasure does not write your legal notice for you.
- Draft config is never what the SDK serves.
- Receipts are operational proof, not a sealed legal archive.
- v1 identity is device/browser-scoped, not multi-device subject accounts.
- Whether consent is the correct lawful ground for a purpose is a legal question.
What to do next
Read Notice for versioning, or Withdrawal for preference changes.