Provable consent, built for the DPDP Act.
A Consent Management Platform engineered for India's Digital Personal Data Protection Act, 2023 — and flexible enough for GDPR, CPRA and every market you expand into.
Consent you cannot prove is consent you do not have.
The DPDP Act shifts the burden of proof onto you. It is not enough to have shown a notice — you must be able to demonstrate, for any individual at any past moment, what they were told, what they agreed to, and that you honoured it everywhere.
maximum penalty per breach type
The Act's schedule of penalties reaches ₹250 crore for failure to prevent a personal data breach, and ₹50 crore for failures around children's data. These are per-instance ceilings, not annual caps.
languages you must offer
Notices must be available in English or any language in the Eighth Schedule to the Constitution, at the data principal's option. A single English banner does not satisfy the requirement.
as it was given
Withdrawal must be no harder than granting. A one-click accept paired with a five-step withdrawal flow is a compliance failure regardless of what your policy document says.
is where compliance actually breaks
Most organisations can capture consent. Very few can prove that a withdrawal propagated to the CRM, the CDP, the email platform and the analytics warehouse before the next campaign ran.
What the DPDP Act requires, and where this product meets it
Most consent platforms describe features. If you are the person accountable for this, you are working from the statute — so this table starts there instead.
| § | Your obligation | How the platform meets it |
|---|---|---|
| S.5 | Give notice before or at the time of seeking consentItemised description of the personal data sought, the specific purpose, how to exercise rights and how to complain to the Board. | Versioned, content-hashed notices rendered at the point of collection |
| S.5(3) | Offer the notice in English or any Eighth Schedule languageThe individual chooses the language. A single English notice does not discharge the duty. | All 22 Eighth Schedule languages, with the language served recorded |
| S.6(1) | Obtain free, specific, informed, unconditional and unambiguous consentConsent must be a clear affirmative action, limited to what is necessary for the stated purpose. | Granular per-purpose capture; no pre-ticked boxes, no bundled consent |
| S.6(3) | Make withdrawal as easy as giving consentAsymmetry between a one-click accept and a multi-step withdrawal is itself a contravention. | Symmetrical flows enforced, with the interaction cost of each path recorded |
| S.6(4) | Cease processing within a reasonable time of withdrawalThe duty extends to your processors. Withdrawal upstream must stop processing downstream. | Real-time check API plus webhook propagation with delivery receipts |
| S.8(5) | Implement appropriate technical and organisational measuresYou must be able to demonstrate compliance, not merely assert it. | Hash-chained ledger with published Merkle roots for independent verification |
| S.9 | Obtain verifiable parental consent for childrenNo tracking, behavioural monitoring or targeted advertising directed at children. | Age assurance, parental consent workflow, platform-level enforcement |
| S.11–S.14 | Honour access, correction, erasure, nomination and grievance rightsEach carries its own statutory response expectation. | Self-service rights portal with clocks, routing, escalation and audit trail |
This is not legal advice. The table summarises our reading of the Act to help you scope a project. Your purpose taxonomy, notice wording and lawful bases must be approved by your own counsel, and the obligations under the Act remain yours as Data Fiduciary.
Turn a legal obligation into an operational asset
A consent platform is bought because of regulation, but the organisations that get it right find it settles arguments that predate the Act — which team may use which data, for what, and on whose authority.
Answer the regulator in minutes
When the Data Protection Board asks about a specific individual on a specific date, you produce the notice version they saw, the purposes they accepted and the propagation record — rather than opening an investigation into your own systems.
Stop unlawful processing before it happens
Consent state is enforced at the point of use through APIs and SDKs, so a withdrawn permission removes the individual from the next campaign automatically instead of relying on a manual suppression list.
Reach the whole Indian market lawfully
Multilingual notices are a statutory requirement, but they are also the difference between meaningful consent and a bounce. Serving a notice in the user's own language raises both compliance and conversion.
Take rights requests off your inbox
Access, correction, erasure, nomination and grievance requests arrive through a self-service portal with statutory clocks, routing and escalation — instead of an unmanaged privacy@ mailbox.
Regain control of your own tags
Continuous scanning finds the trackers marketing added through a tag manager without telling anyone, and prior-blocking stops them firing until a lawful basis exists.
One platform as you expand
The same purpose model and ledger serve GDPR, CPRA and IAB TCF v2.2, so entering a new market is a configuration change rather than a second vendor.
What Zenxecure Consent does
The complete consent and preference management surface — built as one product, not assembled from acquisitions.
DPDP-aligned consent notices
Clear, itemised, purpose-specific notices with the statutory right to withdraw as easily as consent was given.
Multilingual by default
Serve notices in English and the languages of the Eighth Schedule, as the Act requires.
Immutable consent ledger
Every grant, refresh and withdrawal is hash-chained with timestamp, purpose, version and proof-of-notice.
Data principal rights portal
Self-service access, correction, erasure, nomination and grievance requests with statutory clocks and escalation.
Cookie and tracker governance
Automatic scanning, classification and prior-blocking of tags and trackers across web and mobile.
Downstream propagation
Consent state is pushed to your CRM, CDP, marketing and analytics stack through APIs and SDKs so nothing acts on stale permission.
Six situations this actually changes
Not feature descriptions — the specific moments where the difference between having this product and not having it shows up in someone's week.
A grievance escalates to the Board
An individual complains that they withdrew consent and kept receiving messages. Proving what happened means pulling logs from four systems, and the timestamps do not reconcile.
You retrieve their complete consent history in one query: the notice version served, the language, the purposes accepted, the withdrawal timestamp and the propagation receipt from every downstream system.
How it works
The ledger is hash-chained, so the record is tamper-evident. The evidence pack exports as a signed PDF with the verification hash, which is materially stronger than a database extract.
A campaign that cannot send unlawfully
Suppression lists are exported weekly and uploaded manually. Someone who withdrew on Tuesday still receives Thursday's campaign because the list was cut on Monday.
The email platform checks consent state through the API at send time. A withdrawal made sixty seconds earlier removes that individual from the send, with no list to maintain.
How it works
Enforcement runs at the point of use rather than on a batch schedule. Where a platform cannot query in real time, webhook propagation pushes the change and records a receipt with latency.
Consent for a mobile app and a web journey
The app and the website capture consent separately. The same customer appears as two data principals with contradictory permissions and no way to reconcile them.
Native SDKs and the web banner both write to one ledger keyed to a resolved identity, so consent granted in the app is honoured on the website immediately.
How it works
Identity resolution links device identifiers, authenticated accounts and pseudonymous IDs. Pre-authentication consent is bound to a pseudonymous ID and merged on login, without losing the original timestamp.
The tag nobody approved
An agency adds a remarketing pixel through the tag manager for a campaign. It stays live for fourteen months, collecting data under no declared purpose.
Continuous scanning detects the new tracker within a day, classifies it, and blocks it until it is mapped to a declared purpose with a lawful basis.
How it works
Prior-blocking works by intercepting script execution before the tracker initialises, rather than deleting cookies after the fact — which is the distinction regulators have consistently drawn.
Proving notices were actually understood
Your notice exists only in English. You have no record of which version any individual saw, and the notice has been edited several times with no version history.
Every notice is versioned and content-hashed. The ledger records exactly which version, in which language, was rendered to each individual at the moment they consented.
How it works
Because the notice is hashed, you can prove the text has not changed since it was served — you are not asking the regulator to take your word for what the notice said in March.
Expanding into the EU
Entering a new market means procuring a second consent vendor, rebuilding the purpose taxonomy, and running two systems that disagree.
The existing purpose model is extended with GDPR lawful bases and, where needed, IAB TCF v2.2 signalling. One ledger, one integration surface, region-aware notice logic.
How it works
Jurisdiction is resolved per request, so an Indian visitor sees a DPDP notice and an EU visitor sees a GDPR notice with the correct legal basis and vendor disclosures, from the same deployment.
Where the AI actually earns its place in Zenxecure Consent
Four concrete jobs the model does on your data — each logged, each explainable, none of it guesswork.
Purpose discovery
Scans your properties and data flows to infer the processing purposes you actually need to declare.
Notice drafting and translation
Generates plain-language notices and verified translations, versioned for audit.
Consent drift detection
Flags trackers firing without a valid basis and downstream systems acting on withdrawn consent.
DPO copilot
Answers regulator-style questions against your own consent ledger and produces the evidence pack.
What this satisfies, clause by clause
The DPDP Act is the design target, but the same purpose model and ledger serve GDPR, CPRA and IAB TCF v2.2 — so entering a new market is a configuration change rather than a second vendor.
| Framework | Requirement | How Zenxecure Consent addresses it |
|---|---|---|
| DPDP Act, 2023 | S.5 — Notice; S.6 — Consent and withdrawal | Itemised, purpose-specific notices in the individual's chosen language, with withdrawal made no harder than granting and every event recorded. |
| DPDP Act, 2023 | S.6(3) — Withdrawal must be as easy as giving consent | Symmetrical interaction design enforced in the banner and preference centre, with the interaction cost of both paths recorded as evidence. |
| DPDP Act, 2023 | S.9 — Processing of children's personal data | Age-assurance gating, verifiable parental consent workflow, and enforced blocking of tracking and targeted advertising for flagged principals. |
| DPDP Act, 2023 | S.11–S.14 — Rights of access, correction, erasure, nomination and grievance | Self-service rights portal with identity verification, statutory clocks, routing, escalation and a complete audit trail per request. |
| DPDP Act, 2023 | S.8(9) — Grievance redressal mechanism | Published grievance channel with tracked SLAs and escalation path to the Data Protection Board recorded on the case. |
| GDPR | Art. 6, 7, 12–22 · Recital 32 | Lawful-basis modelling, demonstrable consent, granular purposes and data-subject rights workflows for EU-facing properties. |
| IAB TCF v2.2 | Transparency and Consent String generation | Conformant CMP signalling for advertising partners where programmatic inventory is in scope. |
| ISO/IEC 27701 | PIMS controls for consent and data subject rights | Evidence artefacts aligned to privacy information management system audit requirements. |
This mapping is provided to help scope an assessment. It is not legal advice and does not certify compliance — your auditor, assessor or counsel makes that determination.
Everything below this line is for the person who has to make it work.
How trackers are discovered, how the purpose taxonomy is modelled, exactly what a consent record contains, how the ledger resists tampering, and how enforcement reaches your downstream systems.
How the data actually flows
Five stages from discovering what your properties actually collect through to proving, months later, that you honoured what someone agreed to.
Discover
Before you can declare purposes honestly, you need to know what is actually collecting data across your properties.
- Automated crawl of web properties detecting cookies, pixels, beacons and local storage
- Mobile SDK inventory from your app bundles and third-party dependency manifests
- Tag manager container analysis, including tags added outside change control
- Data-flow inference mapping each tracker to the vendor and processing purpose it serves
Model
Purposes, not cookies, are the unit of consent under the DPDP Act. The purpose taxonomy is the core configuration and everything else derives from it.
- Hierarchical purpose taxonomy with retention period and lawful basis per purpose
- Vendor and processor register mapped to the purposes each one serves
- Notice templates versioned and content-hashed, with translations attached per version
- Jurisdiction rules resolving which notice, basis and signalling apply per request
Collect
Consent is captured through a lightweight banner, native SDKs or your own interface calling the API directly.
- Web SDK under 20 KB gzipped, served from CDN, asynchronous and non-blocking
- Native SDKs for iOS, Android and React Native with offline queueing
- Server-side API for call-centre, in-branch, kiosk and IVR capture
- Prior-blocking: non-essential scripts are prevented from executing until a basis exists
- Language selection from the Eighth Schedule, with browser and geo-based defaulting
Record
Every consent event is written to an append-only ledger designed to be evidence rather than a log.
- Append-only records — no update or delete path exists in the data model
- Each record hash-chained to its predecessor, making tampering detectable
- Captured per event: principal ID, purpose set, notice version hash, language, timestamp, interaction method, jurisdiction and IP-derived region
- Periodic Merkle root published so the chain can be independently verified
- Identity resolution merging pseudonymous and authenticated identifiers without losing original timestamps
Enforce and prove
Consent state is pushed and queried at the point of use, and the evidence trail is assembled continuously rather than at audit time.
- Real-time consent check API for systems that can query at the point of processing
- Signed webhooks with delivery receipts and latency for systems that cannot
- Drift detection comparing observed tracker behaviour against recorded consent state
- One-query evidence pack per principal, exportable as a signed PDF with verification hash
What a consent record actually contains
The difference between a consent log and consent evidence is what you can prove months later. Every event in the Zenxecure ledger carries the full context needed to reconstruct the moment, and the chain makes tampering detectable.
Principal identity
Resolved identity plus every linked pseudonymous identifier, so app and web consent reconcile to one person.
Purpose set and version
Exactly which purposes were accepted or refused, against the versioned taxonomy in force at that moment.
Notice version hash
Content hash of the precise notice rendered, which proves the wording has not changed since it was served.
Language served
The Eighth Schedule language actually displayed, and whether it was chosen by the principal or defaulted.
Interaction evidence
Method of capture, the interaction path taken, and the symmetry check confirming withdrawal was no harder than granting.
Jurisdiction and basis
Which regime applied and which lawful basis was relied upon, resolved at request time rather than assumed.
Propagation receipts
Confirmation and latency for every downstream system that acknowledged the state change — the part most platforms omit.
Records are append-only. A withdrawal does not modify the original grant; it writes a new event that supersedes it, so the complete history remains reconstructable.
Every connector, and exactly what it reads
Collection surfaces write to the ledger; enforcement integrations read from it. The second group is the one that matters most — capturing consent is straightforward, honouring it everywhere is where compliance programmes usually fail.
Collection surfaces
| System | Method | What we read |
|---|---|---|
| Web SDK | Async script from CDN | Banner, preference centre, prior-blocking, language selection |
| iOS / Android SDK | Native package | In-app consent, offline queueing, ATT coordination |
| React Native / Flutter | Bridge package | Cross-platform consent capture with native ledger writes |
| Server-side API | REST, server-to-server | Call-centre, branch, kiosk and IVR consent capture |
Downstream enforcement
| System | Method | What we read |
|---|---|---|
| Salesforce | Two-way API sync | Contact-level consent state and suppression flags |
| HubSpot | Two-way API sync | Subscription preferences and lawful-basis fields |
| Segment / CDP | Destination filter | Per-purpose event routing gated on consent state |
| Braze / MoEngage / Netcore | Webhook + API | Real-time suppression before campaign send |
Tag and analytics governance
| System | Method | What we read |
|---|---|---|
| Google Tag Manager | Consent Mode v2 + container API | Consent signals and container tag inventory |
| Google Analytics 4 | Consent Mode v2 | Granular storage and ad-personalisation signals |
| Meta / LinkedIn pixels | Prior-blocking + consent signal | Execution gating until a basis exists |
| IAB TCF v2.2 vendors | TC String | Conformant transparency and consent signalling |
Data platform and workflow
| System | Method | What we read |
|---|---|---|
| Snowflake / BigQuery / Databricks | Scheduled export or view | Consent state as a joinable table for lawful analytics |
| Jira / ServiceNow | OAuth 2.0, two-way | Rights request routing and grievance case management |
| Entra ID / Okta | SCIM + OIDC | Staff directory for DPO, reviewer and approver roles |
| SIEM | Webhook or syslog | Consent drift and unauthorised-processing events |
Not listed? A documented REST API and signed webhooks cover the rest, and we build priority connectors with design partners. Tell us what you run.
The answers your architecture review will ask for
Written down here so you do not have to raise a ticket to get them. Anything not covered, ask us and we will put it in writing.
Deployment
- Models
- Multi-tenant SaaS · single-tenant dedicated · private cloud in your VPC
- Primary region
- India by default; EU and US regions available for multinational rollouts
- Web SDK size
- Under 20 KB gzipped, async, non-blocking
- CDN
- Multi-region edge delivery with India PoPs
Ledger and evidence
- Structure
- Append-only, hash-chained; no update or delete path in the data model
- Verification
- Periodic Merkle root published for independent chain verification
- Retention
- Configurable; default is consent lifetime plus 8 years for limitation periods
- Evidence export
- Signed PDF with verification hash, plus JSON for machine processing
- Throughput
- Designed for 10,000 consent writes per second per tenant
Languages and accessibility
- Indian languages
- All 22 Eighth Schedule languages, plus English
- Other locales
- 40+ additional locales for multinational deployments
- Accessibility
- WCAG 2.2 AA targeted for banner and preference centre
- Translation workflow
- AI-drafted, human-reviewable, versioned and locked per notice version
Interfaces and security
- API
- REST, JSON, OpenAPI 3.1 specification published
- Rate limit
- 2,000 requests/minute per tenant for consent checks
- Webhooks
- Signed, with delivery receipts, retry and recorded latency
- Single sign-on
- SAML 2.0 and OIDC with SCIM 2.0 provisioning
- Encryption
- TLS 1.3 in transit; AES-256 at rest with per-tenant keys
Check consent at the point of processing
The most important integration is the simplest one: before any system acts on personal data, it asks whether it may. The check is designed to sit in a hot path — cached at the edge, single-digit millisecond response.
OpenAPI 3.1 specification published
Signed webhooks with delivery receipts
Scoped API keys and OAuth 2.0 client credentials
A denied decision always returns the reason and the ledger reference, so the refusal itself is auditable — you can prove not only that you stopped, but why.
curl -s https://api.zenxecure.com/v1/consent/check \ -H "Authorization: Bearer $ZX_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "principal_id": "usr_8823401", "purposes": ["marketing_email", "profiling_analytics"], "jurisdiction": "IN" }' # {# "principal_id": "usr_8823401",# "decisions": {# "marketing_email": { "allowed": true, "basis": "consent",# "granted_at": "2026-04-18T09:12:44Z",# "notice_version": "v7", "language": "hi" },# "profiling_analytics": { "allowed": false, "reason": "withdrawn",# "withdrawn_at": "2026-08-30T17:05:02Z" }# },# "ledger_ref": "led_01JQ7Z5T3N",# "evaluated_in_ms": 4# }What the first month actually looks like
Including the parts that need your people, and roughly how much of their time it takes. We would rather set the expectation now than discover it in week three.
Discover
Automated scanning of your web properties, apps and tag containers produces an inventory of every tracker and the purposes they actually serve.
Model purposes
Working session with your DPO and legal counsel to agree the purpose taxonomy, retention periods and lawful bases. This is the step that determines everything downstream.
Notices and translations
Notices are drafted against the agreed taxonomy, translated into your required Eighth Schedule languages and reviewed by your counsel before being version-locked.
Deploy collection
Web SDK and mobile SDKs go live, initially in monitoring mode so you can observe real consent rates before prior-blocking is enforced.
Wire enforcement
Downstream systems are connected — CRM, CDP, marketing platforms and analytics — and propagation receipts are verified end to end.
Operate and prove
Rights requests flow through the portal against statutory clocks, drift detection runs continuously, and evidence packs are produced on demand.
The things buyers actually ask
Including the awkward ones. If your question is not here, ask it — we will answer it directly rather than route you to a brochure.
Is this just a cookie banner?
No. A cookie banner is one collection surface. The product is the ledger underneath it and the enforcement on the other side — proving what was agreed and making sure every downstream system honours it. Most organisations can already show a banner; very few can prove that a withdrawal reached the CRM before the next campaign ran. That gap is what this addresses.
Do we really need all 22 Eighth Schedule languages?
You need to be able to serve notice in English or any Eighth Schedule language at the individual's option, so the practical answer is that you need the capability even if most traffic uses two or three. The platform ships all 22 plus English; you choose which to surface by property and region. Translations are AI-drafted, reviewed by your counsel, then version-locked with the notice.
How is the ledger 'immutable' if it is in a database?
Three mechanisms. The data model has no update or delete path — a withdrawal writes a new superseding event rather than modifying the grant. Each record is hash-chained to its predecessor, so altering a historical record breaks every subsequent hash. A Merkle root is published periodically, letting you verify the chain independently of us. It is tamper-evident rather than physically unalterable, which is the standard that matters evidentially.
What happens to consent captured before we deployed this?
Historical consent can be imported during onboarding, and we strongly recommend it so your ledger does not start empty. Imported records are explicitly marked as migrated with their original source and timestamp, and they are not hash-chained back beyond the import point — we will not claim cryptographic provenance for data we did not observe. Where historical records lack the evidence the Act expects, re-consent campaigns can be targeted at exactly the affected population.
Will prior-blocking break our website or lose us analytics?
Prior-blocking only gates non-essential scripts, and it is deployed in monitoring mode first so you can see the real impact before enforcing. For analytics specifically, Google Consent Mode v2 is supported, which preserves modelled measurement for non-consenting users rather than losing them entirely. Essential functionality never depends on consent and is never blocked.
How do you handle children's data under Section 9?
Age assurance gates the flow, and where a principal is identified as a child the platform enforces a verifiable parental consent workflow and blocks tracking and targeted advertising for that principal regardless of other settings. The enforcement is at the platform level, not a flag your marketing tools can override.
We operate in India and the EU. Do we run two systems?
One. Jurisdiction is resolved per request, so an Indian visitor receives a DPDP notice and an EU visitor receives a GDPR notice with the appropriate lawful basis and, where programmatic advertising is in scope, a conformant TCF v2.2 string. The purpose taxonomy and the ledger are shared; only the notice logic and signalling differ.
Who is the Data Fiduciary — us or Zenxecure?
You are. For personal data processed inside your tenant, Zenxecure acts as a Data Processor on your documented instructions under the terms of our agreement. We provide the mechanism and the evidence; the obligations under the Act, including notice content and purpose declarations, remain yours. Nothing in this product constitutes legal advice, and your counsel should approve the purpose taxonomy and notice wording.
The rest of the platform
Every Zenxecure product writes to the same asset graph, so adding the next one compounds what you already have.
Zenxecure VM
AI Vulnerability Management
Zenxecure VM unifies every scanner, cloud account and asset inventory you already own, then uses AI to decide what actually threatens your business — and drives the fix to closure.
Explore Zenxecure VMZenxecure ASM
External Attack Surface Management
Continuous, outside-in discovery of every domain, IP, certificate, cloud bucket, API and exposed credential connected to your brand — including the assets no one told you about.
Explore Zenxecure ASMFind out where your consent trail actually breaks.
We will scan your public properties, map the trackers against declared purposes, and show you the gap between what you collect and what you can prove. No obligation, and you keep the findings.
No agents to install · Read-only connectors · Data residency in India