Cookie consent management
that keeps the proof.
Under the DPDP Act the Data Fiduciary carries the burden of proving that notice was given and consent was taken, in the language the person actually read. TryTrustable keeps that proof, and the same ledger answers GDPR Article 7, ePrivacy and CCPA opt-out.
Free cookie scan: start with what you are running today
Before configuring anything, see what your site already sets before anyone consents. The free scan loads your page twice, with and without consent, and reports the difference.
Every choice, kept and versioned
Accept, reject, partial and withdraw are all recorded against the notice version that produced them, so a consent taken in 2024 is never mistaken for consent to today's purposes.
- Append-only records, nothing is edited in place
- Notice version stamped on every record
- Language recorded as shown, per the 8th Schedule
- Anonymous subject ids; IPs kept as a salted hash prefix
- Withdrawal is as easy as consent, and just as provable
Granular by default, not by upgrade
Necessary, analytics, marketing and any purpose you define, each one accepted or refused on its own, with the banner rendering in the visitor's language.
- Per-purpose accept, reject and withdraw
- Region-aware defaults: opt-in for the EU and India, opt-out for US states
- Scriptless script blocking until consent is given
- Preference centre reachable from any page
One banner, every jurisdiction
The same deployment serves an Indian visitor under DPDP, a German visitor under GDPR and ePrivacy, and a Californian under CPRA, with the right defaults for each.
- India, DPDP Act 2023 notice and consent
- EU/UK, GDPR Art. 7 and the ePrivacy cookie rules
- US states, CCPA/CPRA opt-out and Global Privacy Control
- Brazil, Canada, Singapore, Thailand, Japan, Korea
You cannot block what you have not found
The consent manager blocks trackers by purpose, which only works if the inventory is right. The scanner runs a real browser against your site, so it sees the tags that load after page load, the identifiers kept outside cookies, and the requests that set nothing at all.
- Two passes: what fires before consent, and what waits for it
- Cookies, localStorage, sessionStorage and IndexedDB
- Third-party beacons that set no cookie but still disclose the visitor
- Canvas, WebGL, audio and font fingerprinting
- Weekly re-scans that alert when a new tracker appears
Prove consent, not intent.
We will set the banner up against your real domains on the call and show you the first records landing in the ledger.
What a consent record has to prove
Under the DPDP Act the Data Fiduciary carries the burden of proving that notice was given and consent was taken. The GDPR puts it almost identically in Article 7(1): the controller must be able to demonstrate that consent was given. Both mean the same practical thing: a boolean column saying consented = true proves nothing at all.
A defensible record answers five questions about a single moment, and you cannot reconstruct any of them afterwards.
| Question | What has to be stored | Why it is asked |
|---|---|---|
| Who | A stable identifier for the person or the device | Without it the record cannot be produced on request |
| What | The exact purposes consented to, not a category label | Consent is specific to purpose; a bundled yes is not consent to each |
| When | A timestamp that cannot be back-dated | Determines whether processing before it was lawful |
| Against what | The version of the notice actually displayed, and its language | DPDP requires notice in English or an Eighth Schedule language, and you must show which was shown |
| How | The mechanism and the surface: banner, form, preference centre, API | A pre-ticked box and an affirmative click are not the same act |
The chain matters as much as the fields: an append-only ledger shows a record was not edited after the fact.
Withdrawal is the obligation most implementations fail
Section 6(4) of the DPDP Act says withdrawal must be as easy as giving consent was. Article 7(3) of the GDPR says the same. It is a short sentence with an expensive implication: if consent took one tap in a banner, withdrawal cannot take an email to support and a three-day wait.
Two further consequences are routinely missed. First, withdrawal has to propagate: to your own processing, and to every processor you already shared the data with. A withdrawal that stops your analytics but leaves the data sitting in three downstream tools is not a withdrawal. Second, withdrawal does not retroactively invalidate processing carried out while consent was live, which is exactly why the timestamp on the original record matters.
Consent is not the only lawful basis, and it is not always the right one
Reaching for consent by default is a common and costly mistake. Under the GDPR there are six bases, and consent is often the weakest available: it can be withdrawn at any moment, and it has to be freely given, which is hard to argue where there is a power imbalance such as employment. Contract or legitimate interests are frequently the better fit for processing you cannot actually stop doing.
The DPDP Act is narrower. It has consent, and it has the legitimate uses listed in Section 7: data voluntarily provided for a specified purpose, employment purposes, medical emergencies, disasters and certain state functions. There is no general legitimate-interests basis, and treating the GDPR's as if it carries over is one of the most common errors in Indian privacy programmes. The DPDP guide walks the distinction in detail.
One banner, several regimes
The regimes disagree about defaults more than they disagree about principles, which is what makes a single global banner difficult and a geography-aware one necessary.
- EU and UK. Opt-in. Nothing non-essential before an affirmative act, and refusing must be as prominent as accepting
- India. Opt-in, with notice itemised per purpose and available in English or an Eighth Schedule language
- California and comparable US states. Opt-out, with a recognised Do Not Sell or Share mechanism and support for Global Privacy Control signals
- Brazil, Canada, Singapore, Australia. Broadly opt-in with local variations in what counts as necessary and how long consent lasts
Serving the strictest rule everywhere is the simplest answer and it costs measurable revenue in opt-out jurisdictions. Serving the loosest is not defensible. Resolving the applicable regime per visitor is the only approach that is both lawful and commercially sane: see coverage for the full list.
Where the record has to live
A consent ledger is only evidence if it is tamper-evident. Ours is append-only and hash-chained: each record carries the hash of the one before it, so an altered or deleted entry breaks the chain and is detectable. That property is what turns a database table into something an auditor or a regulator can rely on, and it is the same mechanism the platform's evidence ledger uses everywhere else.
Before configuring any of this, it is worth knowing what you are actually running today. The free cookie scan shows what fires before anyone consents, which is usually the shortest route to understanding the size of the problem.
The things people ask us
Is this a Consent Manager registered with the Data Protection Board?
No, and the distinction matters. Under section 6(9) of the DPDP Act and Rule 4 of the DPDP Rules 2025, a Consent Manager is a registered intermediary that acts for Data Principals across many organisations : it must be a company incorporated in India, hold a net worth of at least two crore rupees, and be registered with the Board. Rule 4 comes into force on 13 November 2026. TryTrustable is a Consent Management Platform: software a Data Fiduciary runs on its own site to collect, enforce and evidence consent. That needs no registration, and it is what almost every organisation actually needs.
What is the difference between a cookie banner and a consent management platform?
A banner is a user interface. A consent management platform is the banner plus the record behind it: what each person was shown, in which language, which version of the notice, when they chose, and what they chose per purpose. The banner is what a visitor sees; the record is what you produce when a regulator asks you to demonstrate consent.
What does a valid consent record have to contain?
Who consented, to exactly which purposes, when, against which version of the notice and in which language, and by what mechanism. A boolean flag does not satisfy either the DPDP Act or GDPR Article 7(1), because neither the specificity nor the notice version can be reconstructed from it later.
Does the DPDP Act have a legitimate interests basis like the GDPR?
No, and assuming it does is a common and serious error. The Act provides consent and the specific legitimate uses listed in Section 7: voluntarily provided data, employment purposes, medical emergencies, disasters and certain state functions. These are narrower than the GDPR's legitimate interests and should not be treated as equivalent.
How easy does withdrawing consent have to be?
As easy as giving it was. That is explicit in DPDP Section 6(4) and GDPR Article 7(3). If consent was one tap in a banner, withdrawal cannot require an email to support. It also has to propagate to every processor you already shared the data with, not just stop your own processing.
Do I need different banners for different countries?
You need different behaviour, which can come from one banner. The EU, UK and India require opt-in before non-essential cookies; California and comparable US states operate an opt-out model with Global Privacy Control support. Applying the strictest rule everywhere is lawful but costs conversions where opt-out is permitted.
What makes a consent ledger tamper-evident?
Append-only storage plus hash chaining: each record includes the hash of the previous one, so editing or removing an entry breaks the chain detectably. Without that property a consent table is just a database anyone with write access could have changed after the fact.