The consent management platform,
on its own.
Everything TryTrustable does for consent, as a separate application with its own dashboard and its own login. Buy it because consent is the problem you have this quarter, not because you wanted a compliance platform. The control graph is still underneath, so nothing has to be rebuilt when you do.
Fifteen screens, three jobs.
Declaring what you process, running the consent that follows from it, and answering for both when somebody asks. The dashboard is organised around those three, because that is the order the obligations arrive in.
Declare it once, in the words the notice will use
Everything a notice has to state, held as one versioned object rather than scattered across a config file and a copy deck. Change a purpose and the version moves with it.
- Consent profiles: The whole notice as one versioned object: purposes, the data each one touches, and the language it is shown in.
- Purposes: What you process for, declared once, in the words the notice will use.
- Data categories: The other half of a Section 5 notice, not just why, but what.
- Banner & inventory: The banner itself, and the cookie table behind it.
Run it against what the site is actually doing
The day-to-day: what your site actually sets, who has chosen what, and pushing a new notice to people who consented against an older one.
- Tracker scan: Two passes over your site, before consent and after, so the inventory is observed rather than remembered.
- Bulk notices: Re-consent campaigns when a purpose changes, with delivery tracked per recipient.
- Data principals: Everyone who has made a choice, and the dossier of every choice they made.
- Withdrawals: Withdrawal relayed to each processor that received the data, not just stopped at your edge.
Answer for it on the clock
The obligations that arrive on someone else's schedule, each with a statutory clock and a named owner rather than an inbox.
- Requests: Access, correction, erasure, grievance and nomination, each on its statutory clock.
- Nominations: The Section 14 right most implementations forget exists.
- Processors: Who receives what, under which agreement, linked to the purpose that justifies it.
- Breaches: Notification to the Board and to affected people, with the 72-hour clock running from awareness.
- Assessments: DPIAs, and a risk register that scores the processing rather than the paperwork.
Standalone, not stripped down
This is the same consent engine the platform runs, not a reduced edition of it. The append-only ledger, the versioned notices, the withdrawal relays and the tracker scanner are identical: what differs is the shell around them and what you are asked to pay for.
| Consent by TryTrustable | The full platform | |
|---|---|---|
| Consent ledger, hash-chained | Yes | Yes |
| Versioned notices, 22 languages | Yes | Yes |
| Tracker scan, before and after consent | Yes | Yes |
| Withdrawal relayed to processors | Yes | Yes |
| Rights, nominations, breaches, DPIA | Yes | Yes |
| Risk register | Scoped to privacy risk | Whole-organisation |
| SOC 2, ISO 27001, ISO 42001 readiness | No | Yes |
| Security intelligence, AI governance, device posture | No | Yes |
| Cross-framework mapping | No | Yes, one control answers many |
| SDK, CI gate, IDE plugin | Consent endpoints only | Full |
Moving up is a setting, not a migration: the consent data you have already collected is the same data the platform reads.
Who should buy this rather than the platform
Three situations, and they are all about timing rather than size.
- A deadline on one obligation. DPDP notice and consent duties commence eighteen months after the Rules were published in the Gazette on 13 November 2025. If that is the thing on your plan this quarter, buying a whole compliance platform to solve it is the wrong shape of purchase
- You already have a GRC tool you are not replacing. Vanta or Drata for SOC 2 and nothing for consent is the commonest stack we see: those tools are bought for framework readiness, not to run the banner and keep the consent ledger on your website
- A cookie audit found something. A scan that shows trackers firing before consent is a specific problem with a specific fix, and it does not need a platform decision attached to it
If you are carrying two or more frameworks, buy the platform instead: the whole advantage there is that one control answers several requirements at once, and that advantage does not exist inside a single pillar.
Choosing a consent management platform in India
A consent management platform for India has to do more than show a banner. It should show the DPDP notice in the languages your users read, keep proof of consent per purpose, make withdrawal as easy as consent, and block trackers until the visitor chooses, with each of those things something you can verify rather than take on trust.
The checklist below is the one we would use buying from anyone, ourselves included. Ask for a demonstration of each item on your own site, not a slide.
| What to check | Why it matters | What to ask the vendor |
|---|---|---|
| DPDP notice languages | Section 5(3) of the DPDP Act requires the notice to be available in English or any of the 22 languages in the Eighth Schedule to the Constitution. | Which Eighth Schedule languages can the notice be shown in today? Does each consent record store the language the person actually saw? |
| Proof of consent per purpose | Section 6(10) puts the burden of proving notice and consent on the Data Fiduciary. A single yes/no flag cannot show which purposes were agreed. | Show me one person's record: which purposes, which notice version, when, and by what action. Can a stored record be edited without trace? |
| Withdrawal as easy as giving | Section 6(4) requires withdrawal to be comparable in ease to giving consent, and section 6(6) requires processing, including by your processors, to stop. | How many steps does withdrawal take compared with consent? What happens downstream when someone withdraws: does anything reach the processors that received the data? |
| Pre-consent tracker blocking, verified by scan | A banner that records a choice after the tags have already fired documents processing before consent. | Which scripts, iframes and pixels are held before a choice? Can you scan my site before and after consent and show me what fired? |
| Notice versioning | Purposes change. Consents have to point at the text the person actually saw, not at today's notice. | Is every notice change a new version? Can I read an old version and see who consented against it? How is re-consent handled when a purpose is added? |
| Audit export | When the Board, an auditor or a customer asks, the evidence has to leave the tool in a form they can check without you in the room. | What does an export contain, in what format, and how would a third party verify it has not been altered? |
| Data residency | Consent records are personal data. Where they are stored matters to your own transfer analysis and to your customers' security reviews. | Where are consent records for Indian users stored and processed? Which sub-processors touch them, and in which countries? |
A buyer's checklist, not legal advice. The statutory references are to the DPDP Act 2023.
This page answers most of these for Consent by TryTrustable: the 22 languages and versioned notices are in consent profiles, the ledger and withdrawal relays in why it is worth the ledger, and the two-pass scan in run it. Residency is covered on the trust and security page. To check the tracker item on your own site before any call, run the free two-pass cookie scan. For what the law requires underneath the checklist, read the DPDP Act and Rules 2025 guide.
One term to keep straight while comparing: a consent management platform is not a Consent Manager in the DPDP sense, which is a Board-registered intermediary acting for individuals across many businesses. How a DPDP Consent Manager differs from a CMP is set out in its own guide.
What installing it actually involves
One script tag, first in <head>, not async. That ordering is not fussiness: the blocker installs synchronously so that nothing runs before it exists, and a tag loaded asynchronously lets the parser move on and fire your analytics first.
<!-- first in <head>, and not async --> <script src="https://api.trytrustable.com/api/consent/embed.js" data-org="<your org id>"></script>
Your org id is issued when your organisation is created. The banner reads its configuration at runtime, so changing purposes, languages or styling in the dashboard takes effect everywhere without anyone touching the site again.
From there it holds non-essential scripts, iframes and pixels until the visitor chooses: an embedded video sets advertising cookies on load, which is the most common finding on a site that otherwise blocks correctly. Every choice is written to the ledger with the notice version and language it was given against.
Recording a decision is not enforcing it
Most banners store a choice while the tags they are asking about have already loaded and set their cookies. That is not a partial implementation, it is a documented breach: you now hold a record proving you processed before consent. Blocking first and recording second is the whole difference.
- Non-essential scripts, iframes and pixels held before consent
- Each record carries who, what purposes, when, and against which notice version
- Append-only and hash-chained, so an edited record breaks the chain detectably
- Withdrawal fans out to every processor that received the data
The things people ask us
How is this different from the consent platform inside the suite?
It is the same engine, not a reduced edition. The ledger, versioned notices, tracker scan and withdrawal relays are identical. What you do not get is the rest of the platform: framework readiness, security intelligence, AI governance and cross-framework mapping.
Can we move to the full platform later?
Yes, and it is a setting rather than a migration. The consent data already collected is the same data the platform reads, because both run on one control graph. Nothing is exported, re-imported or re-consented.
Does it work alongside Vanta, Drata or Sprinto?
Yes, and that is the commonest reason people buy it. Those tools are bought for SOC 2 and ISO 27001 readiness. Consent by TryTrustable runs the banner on your own site, blocks trackers until consent and keeps the proof in a ledger, which is a different job, so the two sit side by side.
Do we need the SDK to use it?
No. The banner is one script tag and the dashboard does the rest. The SDK is there if you want consent checks inside your own services, but nothing about the product depends on it.
Which regimes does one banner cover?
It resolves the applicable regime per visitor: opt-in for the EU, UK and India, opt-out with Global Privacy Control support for California and comparable US states, and local variations across Brazil, Canada, Singapore and Australia. Serving the strictest rule everywhere is lawful and costs conversions where opt-out is permitted.
Is Consent by TryTrustable a Consent Manager registered with the Data Protection Board?
No. 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, and it must be a company incorporated in India with a net worth of at least two crore rupees. Consent by TryTrustable is a consent management platform: software a Data Fiduciary runs on its own site, which needs no registration. The difference is explained in our guide to DPDP Consent Managers.
Is the free cookie scanner the same thing?
The scanner is the read-only half: it shows what fires before consent on any site, with no account. The product is what fixes it: blocking those tags until the visitor agrees and keeping the record proving they did.
See it against your own site.
We run the scan live on the call, then show you the same trackers held behind a banner and the consent landing in the ledger. Thirty minutes.