DPDP Act 2023 · Sections 5–7

A consent management platform that produces records, not just banners

Purpose-specific consent across your website, forms, apps and APIs — each event written to an append-only record carrying the purpose, the notice version, the timestamp, the channel and the region. Built against the DPDP Act 2023 and the DPDP Rules 2025 as written, not adapted from GDPR.

yoursite.in
We use cookies
Choose what you're comfortable with. Each purpose is a separate decision.
Essential
Analytics
Marketing
What gets written
purpose: analytics
notice_version: 4
channel: web-banner
ts: 2026-09-10T09:14Z
signed ✓

Collecting consent is easy. Proving it is the part that fails.

Almost every organisation can show you a consent screen. Very few can answer the question a regulator actually asks: for this individual, on this date, what exactly was she shown, which purposes did she agree to, and can you produce that in a form we can rely on?

The gap usually opens in one of four places. Consent was collected as a single blanket checkbox, so there is no way to show what she agreed to purpose by purpose. The notice text has been edited since, so nobody can reconstruct what was on screen. Consent lives in a table with no integrity guarantee, so it could have been edited. Or consent was withdrawn and the record shows only the current state, with no history.

DPDP is specific about consent being free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the specified purpose (DPDP Act 2023, s.6(1)). Each of those words is a requirement you may have to evidence individually.

A consent management platform is not a Consent Manager

Worth getting straight before anything else, because the two terms are used interchangeably in the market and they mean different things.

Consent Management Platform (CMP)Consent Manager (DPDP Act)
What it isSoftware a Data Fiduciary deploys to meet its own consent obligationsA distinct registered entity acting as a neutral intermediary between Data Principals and multiple Data Fiduciaries
RegistrationNone requiredRegistered with the Data Protection Board under Rule 4, against the conditions in Part A of the First Schedule
ObligationsThose of the Data Fiduciary that deploys itThe separate obligations in Part B of the First Schedule
TimingAvailable nowRegistration window opens 13 November 2026 (Rule 4 commences one year after publication)
Consiva's roleThis. Consiva is a CMP, acting as your Data Processor.Not this.

Consiva is a consent management platform. It is not, and does not seek to be, a registered Consent Manager. You remain the Data Fiduciary and retain the obligations; Consiva processes on your behalf under contract, as Section 8(2) requires.

We say this plainly because the confusion cuts both ways. Some buyers assume they need a registered Consent Manager when they do not. Others assume a CMP discharges obligations that remain theirs. Neither is true.

What Consiva does

1
Consent captured, per purpose
Web banner, form, mobile SDK or API — each purpose is its own decision, not one blanket accept.
Analytics
Marketing
Functional
2
Notice, versioned
Every published notice gets a version. Edit it tomorrow and yesterday's records still resolve to yesterday's text.
notice_version: 4
live_since: 2026-06-02
superseded_by: —
3
Signed, append-only record
Withdrawal is a new entry, not an overwrite — the full history survives, never edited.
purpose: analytics
ts: 2026-09-10T09:14Z
signed ✓
4
Webhook, the same second
Signed webhooks push consent and withdrawal events to your CRM or CDP in real time, on Pro and Enterprise.

Captures consent per purpose, not per visit. Each purpose is a separate decision with its own record. A visitor who accepts analytics and declines marketing produces a record that shows exactly that.

Versions the notice. Every published notice gets a version. Every consent record points at the version that was live when it was captured. Edit the notice tomorrow and yesterday's records still resolve to yesterday's text.

Writes to an append-only log. Records are added, never modified. A withdrawal is a new entry, not an overwrite, so the full history survives.

Treats withdrawal as equal to acceptance. Rule 3(c)(i) requires ease of withdrawal comparable to ease of giving. Consiva's preference centre is reachable in the same number of steps as the accept button.

Handles consent from more than the website. Web banner, form submissions, mobile SDK and REST API, all writing to the same log with the channel recorded.

Notifies your systems in real time. Signed webhooks (HMAC-SHA256) push consent and withdrawal events to your CRM, CDP or campaign platform as they happen, on Pro and Enterprise.

A webhook delivers the event. Whether your downstream system acts on it is a property of that system, and Consiva records the delivery, not the downstream outcome. Any vendor claiming end-to-end “consent propagation” without confirmation from the receiving system is claiming more than the architecture supports.

See it working

consiva.ai/dashboard/banner-builder
Consiva.ai🎨 Banner Builder📊 Dashboard🌐 Domains📜 Consent LogsBanner Builder — acme.inPURPOSES✓ Strictly Necessary — always on☐ Analytics — Google Analytics 4☐ Marketing — Meta Pixel+ Add PurposeNOTICE VERSIONv4 · published 3 Sept 2026LIVE PREVIEW🍪 We use cookiesChoose which purposes to allow.AcceptPreferences

Purposes are configured on the left, one row each, named against the actual processing they govern. Strictly Necessary cannot be switched off — a visitor cannot decline the cookies that make the site work, and offering her the choice would be misleading. Each other purpose is opt-in and independently recordable. Publishing writes a new notice version, which is what makes a consent record from six months ago still meaningful.

consiva.ai/dashboard/consent-logs
Consiva.ai📜 Consent LogsConsent Logs — acme.inVISITOR ID · TIMESTAMP · ACTION · PURPOSE SET · CHANNEL · REGION · NOTICE vv_8f21a3…03 Sep, 14:22:07GRANTEDNecessary, AnalyticsWebINv4v_8f21a3…14 Sep, 09:03:41WITHDRAWNMarketingAPIINv4v_c72e19…14 Sep, 09:04:02GRANTEDAll purposesMobile SDKINv4ExportDated CSV of the rows above, plus a written statement of what could not be observedExport CSV

This is the artefact. One row per decision: an anonymised visitor identifier, timestamp to the second, the action taken, the exact purpose set, the channel it came through, and the region. Records are appended, never edited — a withdrawal appears as a new row referencing the same notice version as the original grant, so the pair reads as one history. The export is a CSV of these rows, which is what you would hand to an auditor or attach to a Board response. Note the channel column: Web, Mobile SDK and API all write to the same log, so a consent given in your app and a consent given on your website are queryable together.

How it works

Input
You define your processing purposes and the notice text for each.
Consiva
Publishes a versioned notice and exposes capture points: banner, form hook, SDK, API.
Action
A Data Principal makes a clear affirmative choice, per purpose.
Output
Non-consented processing is withheld; consented processing proceeds; your downstream systems receive a signed event.
Evidence
An append-only record tying the individual, the purposes, the notice version, the channel and the time — exportable on demand.

Consent across every channel you actually use

ChannelHow consent is capturedAvailable on
Website bannerOne script tag, purpose-level choicesAll plans
Web formsForm hook capturing consent alongside submissionAll plans (50/month on Free)
Mobile appSDK writing to the same consent logPro, Enterprise
Backend and offlineREST API, so a call-centre or in-person consent can be recordedPro, Enterprise
Downstream systemsHMAC-SHA256 signed webhooksPro, Enterprise

Stated honestly: consent taken offline is only in the record if something submits it through the API. If your branch staff take consent on paper and nobody keys it in, the log will not show it, and Consiva's exports say so rather than implying completeness.

Withdrawal is a first-class workflow, not a footer link

Most platforms treat withdrawal as an afterthought. The Rules do not.

Rule 3(c)(i) requires that the means of withdrawing consent be provided with ease comparable to that with which the consent was given. In practice: if a visitor accepted with one click on a banner, withdrawing cannot require her to find a policy page, locate an email address, and write a request.

And withdrawal has consequences beyond the banner. Section 8(7) requires the Data Fiduciary to erase personal data on withdrawal of consent — or when it is reasonable to assume the specified purpose is no longer being served, whichever is earlier — unless retention is necessary for compliance with a law in force. The Data Fiduciary must also cause its Data Processor to erase.

That erasure duty runs into two separate one-year retention duties in the Rules. Rule 6(1)(e) requires retaining logs and personal data for one year to enable detection and investigation of unauthorised access. Rule 8(3) requires retaining personal data, associated traffic data and logs for a minimum of one year for Seventh Schedule purposes — and Illustration Case 2 extends that duty expressly to a cloud service provider acting as a Data Processor.

So a withdrawal can create a genuine collision: the individual has a right to erasure, and you may have a statutory duty to retain. Almost nobody in this market acknowledges it exists. Consiva records the withdrawal, records the erasure action taken, and records where a retention duty was asserted instead — so the decision is documented rather than silent.

Further reading: Erasure Doesn't Mean Delete · DPDP Retention & Erasure

What Consiva leaves behind

Per consent event: anonymised individual identifier · timestamp to the second · action (granted / partially granted / withdrawn) · exact purpose set · notice version · channel · region.

Per notice: a versioned, retrievable copy of the text that was on screen, so any historical record can be resolved to what the individual actually read.

Per withdrawal: a new appended entry referencing the original grant's notice version, plus the erasure action taken or the retention basis asserted.

Per export: a dated CSV, plus a written statement of what the platform could not observe — offline channels, systems without an integration, and any purpose where capture is manual.

Retention of the records themselves: consent records are held in Indian infrastructure. Note that Consiva, as your Data Processor, is itself subject to the Rule 8(3) retention duty — which is why consent records are not deleted on request the moment you ask. That is a statutory constraint, not a commercial one, and it is documented in the DPA.

Who uses it

DPO / Privacy Officer
Owns purposes and notice text; runs exports for audits and Board responses
Legal
Reviews notice language against Rule 3; sets the retention basis where erasure is refused
Marketing
Sees acceptance rates by purpose and variant; works within the consented audience
Product / Engineering
Implements the SDK and API capture points; consumes webhooks
Customer support
Looks up an individual's consent history when she asks

A realistic scenario

A SaaS company collects consent at signup for three purposes: service delivery, product analytics and marketing email. The signup checkbox is a single blanket agreement, so when a customer emails asking to stop marketing but keep using the product, nobody can show what she originally agreed to and the request is handled by manually unsubscribing her from one tool.

After moving to purpose-level capture, the same request becomes a preference-centre action she performs herself in one click. The withdrawal writes a record, a signed webhook fires to the campaign platform, and the marketing purpose closes while service delivery continues untouched. Three months later, during a customer's vendor-risk review, the company produces her full consent history — the original three grants against notice version 4, the marketing withdrawal against the same version — as a single dated export.

Illustrative. Not based on a named Consiva customer.

Where operations can help

Consent configuration is a decision-making exercise more than a technical one: what your purposes actually are, how they map to your processing, and what the notice should say. Teams without a dedicated privacy function often want that done with them once and then maintained.

Privacy Point-of-Contact — Rule 9 requires you to publish the business contact information of a person able to answer a Data Principal's questions about processing, and to include it in every response to a rights communication. Consiva can staff that role.

Managed Privacy Officer — ongoing operation: purpose reviews, notice updates, consent hygiene and evidence upkeep.

Decision authority stays with you. Consiva does not make legal determinations on your behalf.

Related capabilities

Frequently asked questions

Software that captures, stores, enforces and evidences an individual's consent decisions. Under DPDP the emphasis falls on the last two: enforcement, so non-consented processing does not happen, and evidence, so you can demonstrate what was consented to and on the basis of what notice. A platform that captures consent but cannot produce a defensible record of it has solved the easy half.

You define your processing purposes and the notice text for each. The platform publishes a versioned notice and exposes capture points — a website banner, a form hook, a mobile SDK, an API. When someone makes a choice, it is written to an append-only log with the purpose set, the notice version, the timestamp and the channel, and signed events are pushed to your downstream systems. Withdrawal runs the same way in reverse and is recorded as new history rather than an overwrite.

A consent management platform is software you deploy to meet your own obligations as a Data Fiduciary. A Consent Manager is a distinct entity, registered with the Data Protection Board under Rule 4, that acts as a neutral intermediary between Data Principals and multiple Data Fiduciaries and carries its own obligations under Part B of the First Schedule. Registration for that role opens on 13 November 2026. Consiva is a consent management platform and does not seek registration as a Consent Manager.

Building consent capture is straightforward. What is not straightforward is notice versioning so historical records stay meaningful, append-only storage with integrity guarantees, continuous tracker discovery, 22-language delivery, withdrawal parity, and an export an auditor will accept. Teams that build it in-house usually get capture right and discover the evidence problem eighteen months later, when the records they need have already been overwritten.

Purpose-level capture rather than blanket agreement; notice versioning tied to every record; append-only storage; withdrawal at parity with acceptance, which Rule 3(c)(i) requires; multi-channel capture including forms, mobile and API; real-time signed events to downstream systems; delivery in the Eighth Schedule languages your users actually read; and an export that includes both the records and an honest statement of what the platform could not observe.

It makes obligations operational and evidenced. Notice content maps to Rule 3. Purpose-specific capture maps to Section 6(1). Withdrawal parity maps to Rule 3(c)(i). The erasure trigger on withdrawal maps to Section 8(7). It does not, and cannot, make you compliant on its own — compliance is a programme covering governance, contracts, security and training, of which software is one part. Any vendor telling you their product delivers compliance is overselling it.

Ready to see it on your own domain?

Purpose-level consent, versioned notices and exportable records — live in minutes, free to start.