Everything needed to reproduce the numbers, and an explicit account of the method's limits. If a limit here makes a figure on the edition page look weaker than you expected, that is the intended effect.
A register entry only becomes a data point if we can find its website AND confirm the site is really theirs. Most do not make it, and the reasons matter more than the count.
name_mismatch | 1400 | 49.4% | the site was reached, but it is not this company's site — not scanned, and deliberately not guessed at |
confirmed | 715 | 25.2% | the company's own name was found on the candidate site, so it was scanned |
unreachable | 598 | 21.1% | the domain did not resolve or refused the connection — usually stale registry data, not a finding about the company |
robots_disallowed | 117 | 4.1% | the site's own robots.txt asked us not to fetch it, and we did not |
blocked_unsafe_host | 3 | 0.1% | the domain resolved to a private or internal address and was refused |
2833 candidate organisations were put through identity confirmation for this edition. Only the confirmed row was scanned at all.
Every figure in this edition comes from one instrument, and you have no reason to take our word for it. So a reviewer is asked to open a randomly drawn set of the same sites and judge the same checks by eye. The draw is reproducible: sites are ordered by md5(edition id + organisation id), so anyone can re-derive exactly which were drawn and confirm we did not pick the flattering ones. 0 of 944 drawn judgements have been reviewed. Where a person genuinely could not tell, that is recorded as its own outcome rather than forced into agreement or disagreement.
Per-check judgements: not yet reviewed. 944 judgements across the sample have been drawn but none has been checked by a person yet, so this edition carries no per-check agreement figure.
A separate review did happen. A person at Consent Tree checked a sample of the measured sites one by one to confirm each belongs to the company named on the register; those results are stated on the research page. That review did not re-score any check. Until per-check agreement is reported here, read the per-check figures as measurements by the instrument, not as figures a person has confirmed.
A scanner verdict of
pass is published as signal present, fail as signal absent, and
unverified as could not assess. Could-not-assess is drawn on the chart itself
and is never counted as a failure. not_applicable is reported separately and
excluded from the denominator entirely.
A sector-and-check cell is published only when at least 30 organisations were actually assessed for it. Below that the cell reads “insufficient panel this quarter” and carries no rate. The floor is applied when the aggregate is computed, not when the page is written, so the page cannot disagree with the data about what was publishable.
Where fewer than three organisations hold an outcome, the exact figure is replaced by a bound. The complementary figure is withheld too — otherwise the exact count could be recovered by subtracting from the published total.
The check set and scoring are fixed for an edition and versioned here. A change creates a new version with its own changelog entry; trend lines only ever compare measurements taken on the same version.
Every edition is supposed to carry a human spot-check of scanner verdicts sampled across sectors, with the agreement rate published here. That has not been done for this edition. Until it is, treat every rate on the edition page as unvalidated against human judgement — the scanner's accuracy on this panel is unmeasured, not assumed good.
Only the privacy-notice-contents check is mapped to a specific Rules citation (Rule 3 / Third Schedule). The other checks carry a plain-language explanation of why the signal matters, not a claim that a specific Rule requires it. Nothing on the edition page should be read as 'the Rules require this'.
This is an outside-in scan of a homepage and standard compliance pages. It cannot see consent records, retention practice, breach process, vendor contracts, or anything behind a login — which is most of what DPDP compliance actually consists of. Prevalence claims here are about publicly posted signals and nothing more.
A candidate domain is only scanned if the company's own distinctive name tokens appear on the site. Companies whose site could not be confirmed are counted as not assessed rather than guessed at, which makes coverage smaller and the numbers that remain more trustworthy. The coverage table below shows exactly how many were lost at each step, and why.
Each is observed on a homepage and a fixed set of standard compliance pages. Each returns exactly one verdict per organisation.
web.ccpa-optout-link
If your site shares or sells visitor data to advertising or analytics partners, this checks whether there's a clear, one-click way for a visitor to say no to that sharing.
DPDP's consent-withdrawal principle points the same direction: whatever consent was given for sharing, it should be just as easy to take back.
web.consent-mechanism
This checks whether a consent banner or similar mechanism appears before analytics, advertising or other tracking tools start collecting data — versus those tools just running silently on page load.
DPDP requires consent to be obtained before personal data is collected for a given purpose, not retroactively.
web.consent-withdrawal
This checks whether there's a lasting way for a visitor to come back later and turn off tracking or update their preferences — not just a one-time banner they can never see again.
DPDP requires withdrawing consent to be as easy as giving it — a banner that only ever appears once fails that on its face.
web.cookie-policy
Cookies and similar trackers quietly collect information about how visitors use your site (often for analytics or advertising). This checks whether you publish a page explaining what's used and why, when trackers are present.
If a tracker collects data that can identify a person (even indirectly), DPDP's notice-and-consent duties apply to it.
web.dpo-contact
Similar to the grievance contact, this checks for a published contact person or role responsible for data protection at your company.
Businesses DPDP classifies as "Significant" must appoint a Data Protection Officer based in India — smaller businesses should still name someone accountable.
web.form-notice-proximity
When a visitor fills out a form on your site (contact, signup, checkout), this checks whether there's a nearby note or link explaining what that data will be used for.
DPDP requires notice to accompany the request for consent — a form with no context nearby doesn't meet that.
web.google-consent-mode
Some tools (like Google's tag manager) support a setting where trackers stay quiet by default and only activate once someone has actually agreed. This checks whether that default-off behaviour is switched on.
Ties directly to DPDP's requirement that processing only begin once valid consent has actually been given.
web.gpc-declaration
Some browsers let a visitor set a single preference that says "don't sell or share my data," which sites can read automatically. This checks whether your site recognises and publishes support for that signal.
web.grievance-contact
This checks whether your site publishes a named contact (a "grievance officer" or equivalent) that a visitor can write to about how their data is handled.
DPDP s.13 requires a named Grievance Officer who must respond to complaints within a defined period.
web.https
When someone visits your site, an encrypted connection (the padlock/HTTPS you see in a browser) scrambles everything sent between their browser and your server, so nobody else on the network can read it.
DPDP requires "reasonable security safeguards" for personal data — encrypting the connection is the baseline, not the ceiling.
web.language-option
This checks whether your privacy notice or consent banner offers at least one Indian language alongside English.
DPDP allows notices in English or any language listed in the Constitution's Eighth Schedule (Hindi, Tamil, Bengali, and others).
web.privacy-policy-content
Having a privacy policy page isn't the same as it covering the right things. This checks the actual text for the core items a real notice should include — who you are, what you collect, why, how long you keep it, who you share it with, and how someone can complain or withdraw consent.
DPDP sets out specific items a notice must cover — purpose, retention, sharing, rights, and how to complain or withdraw consent.
web.privacy-policy-link
A privacy policy is the page that tells visitors what personal data you collect and why. This checks whether a working link to one exists — usually in the footer.
DPDP requires this notice to be given in clear, plain language before or when data is collected.
web.tls-chain
The padlock relies on a security certificate being installed completely. If part of it is missing, some visitors' browsers or apps (often older phones) may show a warning or refuse to connect, even though the site looks fine on a modern browser.
Falls under the same DPDP reasonable-security-safeguards duty as the padlock check.
These are security hygiene rather than data-protection obligations, and are reported as such.
web.header.csp
This is a server setting (CSP) that restricts which scripts and resources a page is allowed to load, so if an attacker manages to inject malicious code, its damage is limited.
web.header.hsts
This is a small instruction (HSTS) your server can send telling browsers "always use the encrypted connection for this site, never fall back to unencrypted." Without it, there's a brief window where a visitor's first connection could be downgraded.
A technical detail under the same DPDP security-safeguards duty as encryption itself.
web.header.referrer-policy
When someone clicks a link from your site to another, browsers can pass along the exact web address they came from — which, if that address contains a search term, an order ID, or a token, hands that information to the destination site.
web.header.xcto
This setting (X-Content-Type-Options) stops a browser from guessing a file's type in a way that could turn an ordinary file (like an uploaded image) into something that runs as code.
web.header.xfo
This setting (X-Frame-Options) stops other sites from loading your pages inside an invisible frame to trick visitors into clicking something they didn't mean to ("clickjacking") — for example, a hidden "submit payment" button under what looks like a game.
FIRST USED IN 2026-Q3
Baseline instrument. 19 scanner checks (14 DPDP-facing verdict checks plus 5 security-response-header checks), Pulse tier only: a homepage and a fixed set of standard compliance pages, no crawl.
· First published version — nothing to compare against yet. Trend lines begin with the next edition on this version.