A banner is not consent. The record is.

Anyone can put a dialog on a page. The question a regulator asks afterwards is what your site actually did, and whether the record you kept can be trusted.

SHA-256Every record hash-chained
Reject-AllReplayed and recorded
16Notice languages, auto-translated
01 · The joinONLY WE CAN ASK THIS

Do your purposes actually cover what you collect?

A consent platform knows what you declared. A code scanner knows what you collect. Scrutora holds both, so it can tell you the thing neither can on its own: you are collecting a category of personal data that no purpose on your banner covers.

scrutora
Consent coverage: enter data categories or a Scrutora scan ID to check whether configured purposes cover the personal data the application collects. Below it, the runtime tag monitor.
Paste the categories, or hand it a scan ID and let it pull the personal data the scanner already detected in your code.
02 · What actually firedBEFORE CONSENT · REJECT-ALL

Tags that ignore the banner are the fines.

The monitor loads your live page three times and records which advertising and analytics tags fire before any choice is made, on Reject-All, and on Accept-All. A tag that fires before consent, or survives a rejection, is the exact pattern behind the cookie enforcement actions on record.

Link a code scan and it separates the two cases that matter: tags in your repository, and tags that fire at runtime but are nowhere in your code. Those are living in your tag manager, added by someone who never opened a pull request.

runtime tag monitor3 loads
Before any choice
tags fired before the banner was answered
On Reject-All
tags that survived a rejection
On Accept-All
the baseline you intended
03 · The recordTAMPER-EVIDENT

Hash-chained, so nobody can tidy it up later.

Each consent artifact is hashed together with the hash of the one before it. Altering any record after capture breaks every hash downstream of it, and the chain check finds exactly which. That is the difference between a log you keep and evidence you can stand behind.

scrutora
Webhooks and evidence: signed consent and DSR events, chain verification, and a downloadable DPDP evidence pack.
Verify the chain on demand, export a DPDP evidence pack for an auditor, and push signed consent and request events to your own endpoint.
04 · Requests

Erasure and access, with the clock running.

Data principal requests arrive with a type, a verification state and an SLA date, next to the consent history for the same subject. Fulfilling an erasure scrubs the raw identifier while the chain stays verifiable.

scrutora
Records and requests: an open erasure request with an SLA date, above the consent record history showing purposes granted over time.
Consent history per subject, with the purposes granted at each point in time. Exportable as CSV.
05 · The noticeDPDP SCHEDULE LANGUAGES

In the language they actually read.

DPDP expects notice to be available in the languages of the Eighth Schedule. The banner auto-translates to the visitor’s browser language with no setup, and you can offer an in-banner switcher. Purpose names and buttons ship pre-translated; override any wording per language when your lawyers want their own phrasing.

Hindi, Marathi, Gujarati, Tamil, Kannada, Telugu, Bengali, Malayalam and Punjabi, alongside Spanish, French, German, Portuguese, Arabic, Japanese and Chinese.

scrutora
Purposes and notice configuration: allowed origins, banner languages, per-language banner text, and the purpose list with required and functional flags.