Public edition. This is the public, citable edition of the Dxtra Privacy Scanner methodology (Methodology v1.8). It documents what the scanner checks and why; it omits internal detector implementation. The companion Regulator Reference is the authoritative source for every citation used below.

How the Dxtra Privacy Scanner works¶

Methodology, sources, and limitations.

Version 1.8 — last updated 22 June 2026. Status: Canonical methodology, ratified 2026-06-16. Supersedes v1.6 base prose + the v1.7 Geo-Vantage Addendum (both preserved as historical). Changelog at end of document.

The Dxtra Privacy Scanner reads a website the way a regulator reads it. It looks for the things the regulator's own enforcement decisions tell us they look for — the missing privacy notice, the cookie banner that pretends to ask for consent, the tracking pixel that fires before a user has agreed to anything, the site that ignores the Global Privacy Control signal even though its home state requires it, the AI feature with no transparency notice, the cross-border transfer with no documented lawful basis — and it tells you what it found, paired with what would fix it.

Terminology — notice vs policy. This methodology and all Dxtra-facing output call the public-facing transparency document a privacy notice (the disclosure made to data subjects under, e.g., GDPR Arts 13–14). It is commonly labelled “Privacy Policy” in the wild, and Dxtra surfaces acknowledge that label once on first mention. “Policy” is reserved for an organisation’s internal governing document. Statutory terms of art keep their legal naming — e.g. Washington MHMDA’s “consumer health data privacy policy” and the “cookie policy” document type.

This page explains exactly how the scanner does that. We have written it because anyone publishing an assessment against your domain owes you that explanation. We have also written it because the scanner is going to be wrong sometimes — every diagnostic tool is — and you deserve to know what it can and cannot do before you act on the result.

Companion document. The full list of regulator sources, statutory instruments, enforcement decisions, and jurisdictional architecture is maintained as a separate living document: the Dxtra Privacy Scanner Regulator Reference (v1.7). That companion document is updated more frequently than this methodology and is the authoritative source for every citation used in the finding catalogue below.

What the scanner is, and what it isn't¶

The scanner is a diagnostic indicator, not a legal opinion. It surfaces patterns that regulators have publicly identified as compliance concerns through their guidance and their enforcement decisions. It does not — and cannot — make a determination of whether a particular site or business is in breach of any specific regulation. That determination requires legal analysis of facts the scanner cannot see: your processing purposes, your contracts, your internal records, your jurisdictional reach, your legitimate interests assessments, your records of automated decision-making. We strongly recommend that any material decision you take about your privacy program is reviewed by a qualified privacy professional or counsel admitted in the relevant jurisdiction.

We chose the indicator framing deliberately. The alternative — collapsing dozens of distinct regulatory concepts into a single headline number — is satisfying for marketing copy but cannot survive scrutiny. So the headline is always a risk band, never a single score, and the scanner returns:

• A risk band (low / medium / high) calibrated to the site's regulatory exposure
• An indicator count by severity (high / medium / low)
• A list of specific findings, each tied to a named regulator source and a control framework reference
• A capability mapping showing how each finding could be remediated
• A list of commendable practices where observed implementation exceeds baseline regulator expectation — informational only, not inputs to the risk band
• A secondary capability-maturity indicator (0–100) that tracks how completely an observable privacy programme is implemented (described in "The capability-maturity indicator" section below) — a progress measure, explicitly not the headline and not a regulatory determination

This is the framing used by ENISA, NIST, and the major privacy professional bodies for the same reason: it is honest about the limits of automated assessment.

Scan-agent naming¶

The three scan components are referred to throughout this methodology as scan agents. Dxtra is upfront about AI: the names describe what each agent does and reserve "AI" for the parts that genuinely are.

Collective term: Dxtra's scan agents.

The attribution rule is unchanged in principle — every piece of evidence is tied to a named component: tracker, cookie and consent evidence is attributed to the Browser Agent; deep policy substance is attributed to the Policy AI; public-surface and link-discovery findings are attributed to the Surface Agent. Earlier prototype documents used "Worker 1 / Worker 2 / Worker 3" — those names are retained as historical only. The mapping is:

This section is the authoritative mapping; any later document that still says "Worker N" should be read against this table.

The framework backbone¶

The scanner's findings are organised against a controls catalogue derived from three established frameworks. Where the catalogue, the regulator guidance, and an enforcement precedent all converge on the same point, the scanner has a finding type. Where they diverge or where the underlying point is ambiguous, the scanner does not produce a finding.

NIST Privacy Framework v1.1 (2025) is the closest thing to a US-recognised privacy controls catalogue. NIST released the Initial Public Draft on 14 April 2025 with a final version published later in 2025. It realigns the Core with the NIST Cybersecurity Framework v2.0 and introduces Section 1.2.2 on AI and privacy risk management.

ISO/IEC 27701:2025 was published on 14 October 2025, replacing the 2019 edition as a standalone Privacy Information Management System standard. Controls are organised into Annex A (31 for PII controllers), Annex B (18 for PII processors), and Annex C (29 information security).

ENISA's risk-based methodology for personal data security (2018, with Online Platform 2020) provides the peer-reviewed European basis for privacy risk scoring. We use ENISA's likelihood × impact × data sensitivity model.

Jurisdictional architecture¶

The scanner detects the apparent jurisdictional reach of a site (UK, EU, Switzerland, Singapore, Malaysia, Thailand, India, China, South Korea, Brazil, Australia, Canada, UAE, Nigeria, Saudi Arabia, Hong Kong, South Africa, US-CA, US-WA, US-other-state, multi-jurisdiction) and adjusts its regulatory framework accordingly. (Nexus detection for Singapore, Japan, India, China, Canada, Malaysia, Thailand, Hong Kong and South Africa was implemented in code on 2026-06-20 — each fires on a ccTLD or an explicit law/regulator reference, never a bare country name. Dedicated jurisdiction-specific findings currently exist for Switzerland, South Korea, UAE, Nigeria and Saudi Arabia (M24–M29); the newer regimes are named on the report and scored under the general findings and the most-stringent-regime rule, with dedicated findings on the roadmap. Target-market caution (informational, never scored): a site may market its services to another country's residents without being established there — which can still bring that regime into play for the data subjects it serves (e.g. a Singapore firm helping a UK citizen buy UK property may process UK residents' data). Where a country appears near service/market language (property, invest, mortgage, clients, serve…) but is not a detected nexus, the report surfaces a worded caution to verify — it does not move the band or fire a finding. Detection of nexus itself remains establishment / operating-base / named-law based, never service geography.) Thirteen architectural points matter:

1. The ePrivacy Directive operates outside the GDPR one-stop-shop. Established by the CNIL's September 2025 decisions against SHEIN and Google. Cookie enforcement is not subject to the lead-supervisory-authority mechanism.

2. UK and EU regimes have diverged materially. Since DUAA commenced 5 February 2026, UK PECR has expanded exemptions for low-risk analytics/functional cookies while increasing maximum fines 35-fold to £17.5 million or 4% of global turnover.

3. Tracking is no longer a cookies question. EDPB Guidelines 02/2023 (finalised October 2024) confirm Article 5(3) ePrivacy extends to tracking pixels, tracking links, device fingerprinting, local processing, and certain IP tracking. Meta Pixel, LinkedIn Insight Tag, Microsoft UET, TikTok Pixel, and fingerprinting scripts are subject to the same consent regime as cookies.

4. US state privacy is not California-only. At least twelve US states have enforceable privacy statutes with universal opt-out signal mandates. The CA/CO/CT joint GPC enforcement sweep (September 2025) and Washington's separate My Health My Data Act (with a private right of action) confirm enforcement is now geographically distributed.

5. AI-specific statutory regimes are live and enforcing. The EU AI Act's Article 5 prohibitions and Article 4 AI literacy have been in force since 2 February 2025, with sanctions applicable since 2 August 2025 (€35M or 7% global turnover). Article 50 transparency is enforceable from 2 August 2026. California's CPPA ADMT regulations are in force from 1 January 2026 (ADMT obligations from 1 January 2027). Colorado's AI Act (SB 24-205) takes effect 30 June 2026. Australia's Privacy Act requires ADM disclosure from 11 December 2026.

6. Asia-Pacific regimes have matured rapidly. China's three-pathway CBDT framework is complete from 1 January 2026. Thailand imposed cumulative THB 21.5M in fines by August 2025. Malaysia PDPA Amendment commenced through 2025. India's DPBI was established 13 November 2025.

7. Brazil's ANPD is now an independent regulatory agency. Elevated by Provisional Measure 1,317/2025 (September 2025); cumulative BRL 98M (USD 20M) in fines 2023–2025; ECA Digital (Law 15,211/2025) adds minors' obligations.

8. Canada operates a fragmented landscape with Quebec as the most stringent. Quebec Law 25 fully in force since 22 September 2024 with extraterritorial reach, penalties up to CAD 25M or 4% global turnover, and a private right of action with CAD 1,000 minimum statutory damages. The privacy officer contact must be published on the company website.

9. Switzerland operates a GDPR-adjacent regime with criminal — not administrative — enforcement. The new Federal Act on Data Protection (nFADP / revFADP) has been in force since 1 September 2023 and is extraterritorial. The FDPIC cannot levy turnover-based fines; instead, cantonal prosecutors impose fines of up to CHF 250,000 on responsible individuals (nFADP Art. 60). The Swiss cookie/tracking regime is transparency-based, not ePrivacy opt-in (FADP transparency + Telecommunications Act; FDPIC cookie guidance v1.1, 6 October 2025) — so the prior-consent cookie findings (F3–F7) must NOT be applied to a Switzerland-only site absent an EU/UK nexus.

10. South Korea's PIPA is among the strictest regimes, with turnover-based fines and CEO-level accountability. PIPA as amended (effective 15 September 2023; automated-decision provisions 15 March 2024), enforced by the PIPC. Administrative penalties up to 3% of total revenue (a 10%-of-turnover ceiling is scheduled for 11 September 2026 — verify before relying on it). 72-hour breach notification; mandatory Chief Privacy Officer (Art. 31); right to refuse/explain fully-automated decisions (Art. 37-2); cross-border transfer requires separate consent (Art. 28-8).

11. The UAE runs a federal regime plus two independent free-zone regimes. Federal Decree-Law No. 45 of 2021 (UAE PDPL) took effect 2 January 2022 and is extraterritorial, overseen by the UAE Data Office; DPO contact must be notified to the Bureau (Art. 10); immediate breach notification (Art. 9); cross-border transfer to adequate/approved destinations or via safeguards (Art. 22–23). Its Executive Regulations remain pending, so breach timing, the approved-country list and penalty amounts are not yet fixed (UAE findings are treated as interim). The DIFC (DPL 2020) and ADGM (DPR 2021) free zones have their own laws and are excluded from the Federal PDPL — jurisdiction detection must distinguish a mainland-UAE nexus from a DIFC/ADGM one.

12. Nigeria's NDPA is enforced by a dedicated commission with a "major importance" tier. The Nigeria Data Protection Act 2023 (NDPC; General Application and Implementation Directive 2025) imposes registration and DPO duties on "data controllers/processors of major importance"; 72-hour breach notification to the NDPC; penalty for such entities is the higher of ₦10,000,000 or 2% of preceding-year annual gross revenue.

13. Saudi Arabia's PDPL is in full enforcement, with criminal exposure for sensitive-data disclosure. The PDPL (Royal Decree M/19) and Implementing Regulations came into force 14 September 2023, with SDAIA in full enforcement since the grace period ended 14 September 2024. 72-hour breach notification to SDAIA (Implementing Regulations Art. 24); cross-border transfer via consent/adequacy/approved safeguards + risk assessment. Penalties up to SAR 5M (doubled on repeat); disclosing sensitive personal data carries up to 2 years' imprisonment and/or SAR 3M.

Cross-jurisdictional sites are scored against the most stringent applicable regime. A site serving UK, EU, US-CA, US-WA, Singapore, Malaysia, Thailand, Brazil, and Quebec users is held to the strictest standard for each finding — a deliberately conservative choice. Where the scanner runs from multiple geographic vantages (see "Geographic vantage" below), this rule is applied to the observed worst case across vantages rather than the inferred worst case.

Full regulator detail for each of these architectural points is in the Regulator Reference.

How findings are detected¶

The scanner runs three concurrent scan agents against your URL. None require credentials or cooperation beyond serving public pages. All three agents run live in production — there are no stubbed components in the canonical pipeline.

Surface Agent — static HTML scan (3–8 seconds). Reads the homepage and follows footer links to identify privacy notice, cookie policy, separate consumer health data privacy policy (Washington), DNSMPI link, DSAR page, Transparency Center, AI transparency notice, published privacy officer contact, complaints procedure, and GPC support posture at .well-known/gpc.json. Hub / privacy-centre discovery uses tightened matching — see M5 / C8 below.

Browser Agent — headless browser pass (8–20 seconds). Runs as a real, self-hosted headless Chromium browser (no paid third-party API in the scan path). Captures every cookie, tracking pixel, fingerprinting script, or other Article 5(3) tracker set in the first 3 seconds before any consent action. Captures third-party network requests and identifies processors. Detects cookie banner presence (including iframe-served CMP banners), Reject All prominence, implied-consent language, TCF/Consent Mode v2 signals, and whether a browser-sent GPC signal is honoured. Simulates Reject All (including two-step Manage → Reject) and re-checks tracker state. Detects SDK signatures of ADMT systems, AI recommendation engines, facial/biometric processing, chatbots, and patterns suggestive of EU AI Act Article 5 prohibited practices.

Policy AI — privacy notice semantic analysis (8–12 seconds). Extracts controller, legal bases, named processors, DSAR mechanism, cited regulations, last-updated date, AI/ADMT disclosure, pre-use notices, GPC response, and cross-border transfer legal basis. Cross-references named processors against Browser Agent detections. Jurisdiction-specific extractions: UK complaints procedure; Malaysia DPO contact; India DPDPA Rule 3 notice elements; Thailand DPO appointment; China PIPL separate-consent language; Brazil Encarregado contact; Australia ADM transparency; Quebec privacy officer contact; Washington MHMDA separate health data policy; Colorado AI Act consumer-facing AI disclosure; EU AI Act Article 50 statements.

How severity is assigned¶

Each finding type carries a fixed severity tier determined by the scanner's published rules. The tier comes from a versioned configuration we maintain.

The severity rules follow ENISA's three-axis model:

• Likelihood — how commonly does this finding correlate with regulator action? Repeated CNIL cookie decisions, the California / Colorado / Connecticut GPC enforcement sweep, Thailand's August 2025 enforcement wave, China CAC's March 2025 campaign, Brazil ANPD's DPO non-compliance campaign, and the active Washington MHMDA private right of action all make the relevant findings high-likelihood rather than theoretical.
• Impact — PECR £17.5M/4%, Malaysia RM1M, Thailand THB 5M administrative, DPDPA INR 250 crore, LGPD 2% Brazilian revenue, PIPL up to RMB 50M or 5%, EU AI Act €35M/7%, Australia civil penalties up to AUD 50M, and Quebec CAD 25M/4% materially raise impact ratings. Washington MHMDA's private right of action adds litigation exposure beyond regulator action.
• Data sensitivity — findings on health, biometric, financial, child-directed, or AI-driven profiling sites carry higher weight.

Severity overlays (report presentation)¶

Severity-coloured finding cards in the rendered report carry overlay classes that signal the underlying sensitivity profile at a glance. The overlays do not change the underlying finding's severity tier — they signal the contextual sensitivity to the reader and the reviewer:

• severity-child (magenta) — child-directed services (Brazil ECA Digital, Quebec under-14 parental consent, ICO Age-Appropriate Design Code, COPPA scope).
• severity-health (teal) — sensitive-data processors (health, biometric, mental health, Washington MHMDA scope).
• severity-platform (purple-bright) — platform-delegated governance findings (storefronts the client does not own; shared-responsibility framing).
• severity-financial (indigo #3730a3) — regulated financial-services processors (payments, identity verification, automated fraud / credit decisioning). Added 2026-06-16 to keep the financial overlay visually distinct from severity-health so the overlay reads unambiguously at a glance in the report.

The overlay set is part of the canonical design system (see the Wireframe Spec); any future overlay class must (a) anchor to a named regulator-defined sensitivity context, (b) be visually distinct from existing overlays, and © be documented here before use in a report.

The risk band¶

The risk band — low / medium / high — is the headline and the authoritative statement. It is set by the count of confirmed high- and medium-severity findings, never by a single composite number. Generic SME calibration:

• Low risk — 0 high-severity findings, 0–2 medium-severity findings
• Medium risk — 0–1 high-severity findings, 3+ medium-severity findings
• High risk — 2+ high-severity findings, regardless of medium count

For high-sensitivity sites (health, financial, child-directed, AI-driven significant decisioning, Washington MHMDA-covered processing) the bands tighten. See Appendix B.

The capability-maturity indicator (0–100)¶

Alongside the band, the scanner shows a secondary capability-maturity indicator on a 0–100 scale. It is a progress measure — a summary of how completely an observable privacy programme is implemented, expressed as distance to the level a fully built, independently verifiable programme would reach. It is not the headline, and it is not a regulatory determination. The band above is always the authoritative statement; the indicator exists so a site can see and track remediation progress over time.

The indicator is not floored. A site with no observable privacy programme — no published notice, no consent gating, trackers firing before consent, third-party sharing with no disclosure — can legitimately read 0 / 100. A low indicator, including 0/100, is a genuine reading, not an error: it means the scan found few or no privacy controls on the public surface to credit. As with the band, the indicator reflects implemented controls only — commendable practices are recognised in the report but never move it.

Commendable practices¶

Findings detect gaps between observed state and regulator-stated expectation. Commendable practices detect the inverse — observed state that materially exceeds the baseline regulator expectation. Same evidence model, same framework anchoring, opposite direction.

Commendable practices are informational only. They do not affect the risk band. The risk band is anchored solely to findings, because any score that moves based on observed praise becomes gameable — a site could add a Sub-Processors List and drop a band. That would undermine the scanner's diagnostic value. Commendable practices help the reader interpret the report; they do not compensate for findings.

We cap commendable practices at six per scan. If more than six are detected, the scanner surfaces the six strongest and reports the count of additional.

Each commendable practice is anchored to a specific regulator expectation that it exceeds. The C-catalogue is in Appendix A alongside the F / M / L findings. Ten commendable practice types are defined in v1.5; the list will grow as we identify additional patterns that regulators commend in guidance or publicly praise in enforcement decisions.

A note on tone. Commendable practices should not read as marketing. A report with six C-findings and two M-findings is still a report with two M-findings; the M-findings are the thing that matters. The commendable section helps the reader understand whether the site is making a good-faith effort overall, but it does not soften the findings themselves.

Geographic vantage¶

Consent banners and tracker behaviour are gated by the visitor's location (by IP, and sometimes by locale). A scan from a single country cannot observe how a site behaves for users elsewhere — a US-vantage scan will not see the EU/TCF banner a French user gets, or the PDPA notice a Singapore user gets. v1.7 lets the scanner run from multiple vantages and makes the vantage a first-class, disclosed part of every result. This chapter is the methodology rule set for vantages.

Definitions¶

• Vantage — the geographic point a scan is performed from. Each vantage maps to a cloud function region whose egress IP geolocates to that country, plus an Accept-Language for the locale. The catalogue of currently available vantages is given below.
• Egress region — the region the scan function actually ran in.
• Egress matched — true when the egress region equals the requested vantage's region (a genuine in-country scan). When false, the vantage is approximated: locale matches but the egress IP is elsewhere, so IP-gated banners may not reproduce.
• Datacenter-IP vantage — egress is a cloud/datacenter IP that geolocates to the country, not a residential IP. This is the default and must be disclosed (see "Datacenter-IP honesty & cloaking" below).

Rule — vantage disclosure (mandatory)¶

Every scan and every rendered report MUST state the vantage it was performed from: the vantage label, the egress region, and whether egress matched. A finding such as "trackers fire before consent" is only valid relative to its vantage and must be read that way. The scanner records this on every result and shows it on the report.

Rule — absence ≠ compliance¶

Absence of a finding from one vantage is never evidence of compliance in another jurisdiction. If example.com shows no cookie banner from a US vantage, the report must not imply GDPR is satisfied — only that the EU experience was not observed. This preserves the "indicator, not legal opinion" framing. Reports phrase clean per-vantage results as "not observed from this vantage", never "compliant".

Rule — multi-vantage scoring¶

When a site is scanned from several vantages:

• Score each vantage independently against the Appendix B bands, recording the vantage on each.
• The headline band is the worst (most severe) observed across vantages, consistent with the existing "most stringent applicable regime" rule — but now observed rather than inferred.
• Findings are attributed per vantage; the report shows which vantage each came from.
• Commendable practices remain informational and never move the band, per vantage or in aggregate.

Rule — datacenter-IP honesty & cloaking¶

Datacenter egress is disclosed as such. Some sites cloak or block datacenter IPs and serve a challenge page or an empty shell. When the scanner cannot establish that it actually read the site (bot-challenge markers, or both static markup and rendered DOM empty), it returns a preliminary, access-limited scan and withholds absence-based findings — only directly observed tracker/banner behaviour is reported. (Same spirit as the HTTP 429 access-limited rule.)

An access-limited result assigns no risk band. It is explicitly preliminary — neither a pass nor a fail; a clean Low band is never returned when the absence-class checks could not be run, because "we could not read it" must never read as "nothing is wrong." Conversely, a site is access-limited only when neither read succeeds: the read threshold is static OR rendered, so if the headless (Browser Agent) render is readable, the scan proceeds and absence findings may be asserted even when the static fetch alone was WAF/bot-blocked. A static block on its own is a discovery gap for one channel, not grounds to suppress a finding the rendered surface confirms.

Rule — GPC / UOOM framing is vantage-dependent¶

GPC's legal weight depends on the user's state (e.g., California UOOM). GPC findings (F10) are framed against the vantage's jurisdiction. The California vantage is the correct place to assess CCPA/CPRA + GPC; Washington MHMDA can only be approximated by a US-West vantage (no in-state datacenter in Washington) and must be labelled approximate.

Vantage catalogue (all currently available)¶

Real in-country datacenter egress is available for: US East, US California, US West/Oregon, US Cleveland, EU Germany, EU France, EU Ireland, EU Sweden, UK, Japan Tokyo, Japan Osaka, Singapore, Australia, Brazil, India, South Korea, Hong Kong, South Africa. Regimes observable per vantage include GDPR, ePrivacy, UK GDPR/PECR, CCPA/CPRA, GPC/UOOM, APPI, PDPA, Privacy Act/APPs, LGPD, DPDPA, PIPA, PDPO, and POPIA. US granularity is city-level: California is coverable; individual US states beyond a city region are not.

As of 16 June 2026 the priority-region rollout is complete: seven vantages are live and verified in production — US East, US California, EU France, UK, Singapore, Australia, Japan.

Honesty stance on de-cloaking¶

To see the real page (not a bot shell), the Browser Agent presents a normal desktop User-Agent, the vantage's Accept-Language, and light de-cloaking (does not advertise navigator.webdriver). This is limited to being served the same page a normal browser would get. The scanner does not defeat CAPTCHAs or bot-detection challenges; challenged scans are reported as access-limited (see the datacenter-IP rule above).

Residential-proxy egress — future escalation (requires a policy change)¶

Datacenter IPs are sufficient for most IP-based geo-gating, but some sites treat datacenter IPs differently. True residential egress would give the most faithful "real user" view. It is a paid third-party in the scan path, which conflicts with our self-hosted, no-paid-third-party scan-path policy as written, and carries ethical due-diligence obligations for residential-proxy networks. v1.7 records this as a documented future escalation: it would require an explicit policy change and a vetted vendor, and would be offered as a targeted/opt-in option rather than the default free scan.

Report & output additions¶

Every result carries its vantage (label, region, the regimes observable from it, and whether egress matched). Rendered reports add a vantage line near the headline band and, for multi-vantage scans, a per-vantage breakdown. The standard disclaimer is unchanged.

Limitations¶

The scanner cannot see what is inside your business. Documented processing purposes, Article 28 contracts, internal records, staff training, incident response plans, DPIAs, cybersecurity audit reports, AI training data lineage, transfer impact assessments — none are visible externally.

The scanner cannot detect issues that only manifest after authentication. It does not log into account areas.

The scanner cannot determine the appropriate legal basis for your processing.

The scanner cannot read your contracts.

The scanner cannot fully assess EU AI Act compliance. Article 5 prohibitions require factual and contextual analysis beyond external observation. Article 4 AI literacy is internal. The scanner flags patterns suggestive of prohibited practices but cannot confirm violations.

The scanner cannot definitively assess compliance with emerging regimes. DPDPA phased commencement, Australia ADM transparency window, Colorado AI Act (30 June 2026), and EU AI Act's staged applicability all mean some detection logic is interim.

Switzerland nFADP, South Korea PIPA, UAE PDPL, Nigeria NDPA, and Saudi Arabia PDPL are now covered (since v1.6). The UAE findings are interim: the UAE PDPL's Executive Regulations remain pending, so breach-notification timing, the approved-transfer-country list, and penalty amounts are not yet fixed — treat UAE output as preliminary. DIFC and ADGM free-zone entities are governed by their own laws (DIFC DPL 2020 / ADGM DPR 2021), not the Federal PDPL, and are out of scope of the UAE findings. Further regimes (additional GCC, African, and Latin American frameworks) are assessed on a rolling basis.

The scanner cannot guarantee complete coverage of your site. It scans the homepage and follows footer links to a defined depth.

The scanner cannot anticipate emerging regulator guidance. Our finding catalogue is updated roughly monthly.

The scanner cannot replace a qualified privacy professional.

A scan represents one vantage at a time. Absence of a finding from a given vantage is not evidence of compliance from any other jurisdiction — see the "Geographic vantage" chapter for the full discipline.

How we update the methodology¶

The catalogue of findings, severity tiers, risk band thresholds, and the companion Regulator Reference are all versioned. The version used in your scan is recorded in your report PDF. The displayed version across the scanner is sourced from a single version constant, so future updates stay consistent everywhere.

We commit to publishing a methodology paper through a recognised privacy venue (IAPP Privacy Symposium, Computer Law & Security Review, or equivalent) within 12 months of public launch, co-authored with an independent privacy academic.

Disclaimer¶

The Dxtra Privacy Scanner provides an automated diagnostic indicator based on publicly available information. It does not constitute legal advice. Findings are not determinations of regulatory breach. Privacy law is jurisdiction-specific and fact-specific. For material privacy decisions, consult a qualified privacy professional or counsel admitted in your jurisdiction.

Dxtra Inc. provides this scanner as a free tool. Use does not create any contractual or advisory relationship between you and Dxtra.

Appendix A — Finding catalogue and commendable practice catalogue¶

Forty-eight finding types (F1–F15, M1–M29, L1–L4) and ten commendable practice types (C1–C10). Each entry has severity tier or strength, anchor framework mapping, and anchor regulator sources. Full source detail for each citation is in the companion Regulator Reference.

Where a finding lists a sector-specific statute among its anchor sources — for example Washington MHMDA (a consumer-health law) on the missing-notice finding — that statute is shown only when the matching elevated-sensitivity context was actually detected (health or biometric processing, for MHMDA). The entries below list the full anchor set for each finding; this sensitivity-gating governs only which sector anchors are displayed on a given scan, so an ordinary site's finding is not annotated with a consumer-health statute that does not apply to it.

High-severity findings (15)¶

F1 — Missing privacy notice - Detection: no privacy notice linked from any inspected page - Frameworks: NIST PF v1.1 CT.PO-P1, CM.PO-P1; ISO/IEC 27701:2025 A.7.3.2 - Anchor sources: GDPR Art. 13–14; CCPA s.1798.130; LGPD Art. 9; PIPL Art. 17; Australia APP 5; PDPA Notification Obligation (SG/MY/TH); DPDPA s.5; Quebec Law 25; Washington MHMDA - Assertion condition: asserted only when the public surface was actually read — via the static fetch OR the rendered headless DOM — and no privacy notice is referenced anywhere in either read. A WAF/bot-blocked static fetch alone does not suppress F1 if the rendered surface was readable. Withheld (not-evaluated) when neither read succeeds, or when a privacy notice is referenced but its page could not be resolved (discovery gap, not a true absence).

F2 — Stale privacy notice (24+ months or references repealed legislation) - Detection: policy older than 24 months, or references DPA 1998, pre-DUAA PECR fines, pre-Schrems-II SCCs, Privacy Shield, pre-Amendment Act Malaysia PDPA - Frameworks: NIST PF v1.1 GV.PO-P1; ISO/IEC 27701:2025 A.7.3.2 - Anchor sources: ICO accountability principle; EDPB transparency guidelines

F3 — Cookies or equivalent trackers set before consent - Detection: tracking cookies, tracking pixels (Meta Pixel, LinkedIn Insight Tag, Microsoft UET, TikTok Pixel), device fingerprinting, or other Article 5(3) trackers fire in first 3 seconds before any user interaction - Frameworks: NIST PF v1.1 CT.PO-P3; ISO/IEC 27701:2025 A.7.2.4 - Anchor sources: CNIL Deliberation SAN-2025-005 (SHEIN); EDPB Guidelines 02/2023 on technical scope of Article 5(3); ePrivacy Directive Art. 5(3)

F4 — Implied consent banner - Detection: banner uses "by continuing you accept" or equivalent - Frameworks: NIST PF v1.1 CT.PO-P3; ISO/IEC 27701:2025 A.7.2.3 - Anchor sources: EDPB Guidelines 05/2020; DSA Art. 25(1)

F5 — Unequal prominence Accept / Reject - Detection: Accept All visually dominant or Reject All hidden behind intermediate menu - Frameworks: NIST PF v1.1 CT.PO-P3; ISO/IEC 27701:2025 A.7.2.3 - Anchor sources: CNIL SAN-2025-005 (intermediate "Cookie settings" interface); EDPB Guidelines 03/2022

F6 — Cookies or equivalent trackers persist after Reject All / consent withdrawal - Detection: simulated Reject All; cookies, pixels, or other Article 5(3) trackers continue after refusal - Frameworks: NIST PF v1.1 CT.PO-P3, CT.DM-P1; ISO/IEC 27701:2025 A.7.2.3 - Anchor sources: CNIL SAN-2025-005 (third specific basis); EDPB Guidelines 02/2023

F7 — Marketing tags or advertising pixels fire without consent - Detection: Meta Pixel, Google Ads, Bing Ads, TikTok Pixel, LinkedIn Insight Tag, or similar load before consent - Frameworks: NIST PF v1.1 CT.DM-P1; ISO/IEC 27701:2025 A.7.4.4 - Anchor sources: PECR Reg. 6 (UK; £17.5M/4% under DUAA); EDPB Guidelines 05/2020 and 02/2023

F8 — No DSAR mechanism - Detection: no published rights-request page, portal, or designated contact for data access requests - Frameworks: NIST PF v1.1 IP.MP-P1, IP.MP-P2; ISO/IEC 27701:2025 A.7.3.5 - Anchor sources: GDPR Art. 12–22; CCPA s.1798.100; LGPD Art. 18; DPDPA s.11–14; PIPL Chapter IV; Australia APP 12–13; Thailand PDPA Sections 30–42 - Assertion condition: asserted only when the public surface was actually read — via the static fetch OR the rendered headless DOM — and no rights-request page, designated privacy contact, or policy-stated rights mechanism was found. A WAF/bot-blocked static fetch alone does not suppress F8 if the rendered surface was readable. Withheld when neither read succeeds, or when a policy exists but its rights/contact content could not be extracted (content-extraction gap, not a confirmed absence).

F9 — No appointed privacy officer (mandatory jurisdictions or high-sensitivity) - Detection: no DPO (GDPR), UK SRI (DUAA), Malaysia DPO (1 June 2025), Thailand DPO (Section 41), Brazil Encarregado, or Quebec privacy officer publicly contactable; for Quebec, CEO is the default privacy officer unless delegated - Frameworks: NIST PF v1.1 GV.PO-P3; ISO/IEC 27701:2025 A.6.3.1.1 - Anchor sources: GDPR Art. 37–39; Malaysia PDPA s.12A; Thailand PDPA Section 41; LGPD Art. 41; Quebec Law 25 s.8–8.1; HIPAA §164.530(a)

F10 — GPC / universal opt-out signal ignored in mandating US state - Detection: site serves users in UOOM-mandating state (CA, CO, CT, TX, MT, DE, NJ, NH, MD, MN, NE, OR); browser sends GPC; site does not honour - Frameworks: NIST PF v1.1 CT.DM-P1, CT.PO-P3; ISO/IEC 27701:2025 A.7.4.5 - Anchor sources: CCPA regulations §7025; Healthline Media $1.55M settlement (July 2025); CA/CO/CT joint GPC enforcement sweep (September 2025); California Opt Me Out Act (AB 566) - Vantage note: F10 must be assessed from the California vantage for CCPA/CPRA scope (see "Geographic vantage").

F11 — ADMT for significant decisions without pre-use notice (California) - Detection: site uses ADMT for significant decisions (financial/lending, housing, education, employment, healthcare) affecting California residents; no pre-use notice at point of collection - Frameworks: NIST PF v1.1 CT.DM-P1, CM.PO-P1, Section 1.2.2; ISO/IEC 27701:2025 A.7.3.2 - Anchor sources: CCPA regulations §7200-7221 (adopted 23 September 2025; ADMT obligations 1 January 2027)

F12 — Cross-border PI transfer without documented lawful basis - Detection: site processes PI of mainland Chinese, Malaysian, or Brazilian users and transfers abroad; privacy notice lacks reference to mandatory transfer pathway (PIPL Security Assessment / SCCs / PIP Certification), Malaysia TIA, or current Brazil ANPD SCCs (grace period ended 23 August 2025), or lacks separate consent for cross-border transfer (PIPL) - Frameworks: NIST PF v1.1 CT.DM-P5; ISO/IEC 27701:2025 A.7.5 - Anchor sources: China PIPL Art. 38–39; Measures for Certification of Cross-Border Transfer (effective 1 January 2026); Malaysia CBPDT Guidelines (29 April 2025); Brazil ANPD Resolution CD/ANPD No. 19/2024

F13 — EU AI Act Article 5 prohibited practice pattern detected - Detection: public surface describes or technically deploys patterns suggestive of Article 5 prohibitions (emotion recognition in workplace/education, biometric categorisation by sensitive attributes, subliminal manipulation, real-time remote biometric ID in public spaces, social scoring, individual criminal risk prediction) - Frameworks: NIST PF v1.1 Section 1.2.2 - Anchor sources: EU AI Act Art. 5; European Commission Guidelines on Prohibited AI Practices (4 February 2025); Article 99 sanctions (enforceable 2 August 2025; €35M or 7% global turnover) - Note: scanner flags patterns for legal review; Article 5 determinations require contextual analysis beyond external observation

F14 — Mandatory breach notification process visibly absent - Detection: site subject to mandatory breach notification jurisdiction (GDPR, UK PECR/DUAA, Singapore, Malaysia, Thailand, Australia NDB, Brazil, China, DPDPA from May 2027, Quebec); privacy/trust surface lacks any published notification commitment or breach contact - Frameworks: NIST PF v1.1 PR.PO-P1, RS.RP-P1; ISO/IEC 27701:2025 A.6.13.1 - Anchor sources: GDPR Art. 33; Malaysia PDPA s.12B (72h); Thailand PDPA Section 37; Brazil LGPD Art. 48 and ANPD Resolution CD/ANPD No. 15/2024; PIPL Art. 57; Quebec Law 25

F15 — Washington MHMDA: separate consumer health data privacy policy missing — NEW IN v1.4 - Detection: site processes consumer health data affecting Washington users (fitness, wellness, nutrition, biometric, bodily functions, reproductive, mental health, location reasonably indicating health); no separate consumer health data privacy policy prominently linked from the homepage, distinct from the general privacy notice - Frameworks: NIST PF v1.1 CM.PO-P1; ISO/IEC 27701:2025 A.7.3.2 - Anchor sources: Washington MHMDA RCW 19.373.020 (in force 31 March 2024; 30 June 2024 small businesses); private right of action under Washington Consumer Protection Act; parallel Nevada Consumer Health Data Privacy Law (no PRA) - Severity rationale: high because of the private right of action — litigation exposure is not contingent on AG enforcement

Medium-severity findings (13)¶

M1 — Stale privacy notice (12–24 months) — same mappings as F2

M2 — No cookie banner where non-exempt tracking detected — NIST PF v1.1 CT.PO-P3; ePrivacy Directive Art. 5(3); EDPB Guidelines 02/2023; PECR as amended by DUAA

M3 — Processors not named or disclosed — NIST PF v1.1 CM.PO-P1; ISO/IEC 27701:2025 A.7.3.4; GDPR Art. 13(1)(e)

M4 — No privacy officer contact (general, non-mandatory jurisdictions) — NIST PF v1.1 GV.PO-P3; same sources as F9 (mandatory jurisdictions promote to F9)

M5 — No public Transparency Center / privacy hub - Detection: no dedicated transparency centre / privacy hub linked from the public surface - Detection scope (corrected 2026-06-16): M5 fires only on elevated-sensitivity processing — health, biometric, financial, child-directed, or AI significant-decisioning. Ordinary SMBs without a hub do not fire M5; a transparency centre is an above-baseline practice (rewarded as C8) and its absence is the norm for an ordinary site whose privacy notice already meets the baseline. This mirrors the existing M6 (DPIA) gating rationale and prevents M5 from firing as noise on every ordinary SMB. - Frameworks: NIST PF v1.1 CM.PO-P1; ISO/IEC 27701:2025 A.7.3.2

M6 — No DPIA / PIA / processing risk assessment referenced — NIST PF v1.1 ID.RA-P3; ISO/IEC 27701:2025 A.7.2.5; GDPR Art. 35; CCPA §7150; PIPL Art. 55–56; LGPD Art. 38; Malaysia CBPDT Guidelines TIA

M7 — Data breach response timeline or contact missing (process exists) — same sources as F14; becomes F14 where no process at all

M8 — No CCPA Do Not Sell or Share link — NIST PF v1.1 CT.DM-P1; CCPA s.1798.135; CPRA

M9 — Cross-border transfer disclosures absent or stale (non-mandatory-pathway jurisdictions) — EDPB Article 3/Chapter V guidelines; ICO international transfer guidance (DUAA); EDPB Recommendations 01/2020. Mandatory-pathway cases promote to F12.

M10 — No record of processing activities (ROPA) referenced — NIST PF v1.1 ID.IM-P1; GDPR Art. 30; LGPD Art. 37

M11 — No data protection complaints procedure (UK; in force 19 June 2026) — DUAA 2025; becomes high severity after 19 June 2026

M12 — AI processing without disclosure — NIST PF v1.1 Section 1.2.2; PDPC AI Advisory Guidelines (1 March 2024); EU AI Act Art. 50 (enforceable 2 August 2026); CCPA ADMT regulations; Australia Privacy Act ADM transparency (11 December 2026)

M13 — No GPC response disclosure — CCPA regulations §7025; state UOOM mandates; asserted only when a California / US (CA-US) nexus is detected — GPC / universal opt-out is a US-state construct, so M13 is not raised on sites with no US footprint (e.g. EU- or Singapore-only sites); can become F10 if GPC is not honoured

Medium-severity findings (jurisdiction-specific) (7)¶

M14 — Malaysia PDPA: DPO contact not published — Malaysia PDPA s.12A; Circular No. 2/2025

M15 — DPDPA notice format missing for Indian-targeted sites — DPDPA 2023; DPDP Rules 2025 Rule 3; becomes high severity after 13 May 2027

M16 — Australia ADM transparency not addressed — Privacy and Other Legislation Amendment Act 2024; ADM transparency effective 11 December 2026

M17 — Brazil LGPD: Encarregado contact or substitute not published — LGPD Art. 41; ANPD Resolution CD/ANPD No. 18/2024; DPO non-compliance campaign 2024–2025

M18 — Thailand PDPA: DPO not appointed or published (mandatory cases) — Thailand PDPA Section 41; Royal Gazette 9 October 2025 (state agencies mandatory)

M19 — Brazil ECA Digital: minors' services without required safeguards — Law 15,211/2025; ANPD Resolution CD/ANPD No. 30/2025

M20 — EU AI Act Article 4 AI literacy indicators absent — EU AI Act Art. 4 (in force 2 February 2025)

New medium-severity findings in v1.4 (3)¶

M21 — Quebec Law 25: privacy officer contact not published on website — NEW IN v1.4 - Detection: site serves Quebec residents; privacy officer (or delegated equivalent) contact not published on the organisation's public website; where undelegated, no CEO contact identified as privacy officer - Frameworks: NIST PF v1.1 GV.PO-P3, CM.PO-P1; ISO/IEC 27701:2025 A.6.3.1.1 - Anchor sources: Quebec Law 25 s.8–8.1 — privacy officer appointment and public contact publication mandatory; CAI has imposed administrative penalties for non-publication

M22 — Colorado AI Act: consumer-facing AI disclosure absent — NEW IN v1.4 - Detection: Colorado-jurisdiction site deploys a consumer-facing AI system (chatbot, conversational agent, AI-driven intake); no disclosure that the consumer is interacting with an AI system - Frameworks: NIST PF v1.1 Section 1.2.2, CM.PO-P1; ISO/IEC 27701:2025 A.7.3.2 - Anchor sources: Colorado AI Act (SB 24-205) — effective 30 June 2026 (delayed by SB 25B-004 signed 28 August 2025); consumer-facing AI systems must disclose the consumer is interacting with an AI unless it would be obvious to a reasonable person - Note: severity becomes high for high-risk AI systems making consequential decisions (employment, education, housing, healthcare, financial/lending, legal services) from 30 June 2026

M23 — Non-cookie tracker fires before consent (pixels, fingerprinting, tracking links) — NEW IN v1.4 - Detection: non-cookie Article 5(3) trackers detected by the Browser Agent — browser fingerprinting scripts (e.g., FingerprintJS, device.js), email tracking links resolving to third-party beacons, local processing that transmits data off device — firing before consent - Frameworks: NIST PF v1.1 CT.PO-P3; ISO/IEC 27701:2025 A.7.2.4 - Anchor sources: EDPB Guidelines 02/2023 on technical scope of Article 5(3) — extends scope beyond cookies; ePrivacy Directive Art. 5(3); WP29 Opinion 9/2014 on device fingerprinting - Note: treated as medium rather than high because enforcement precedent is still primarily cookie-focused; will likely promote to high severity within the next year as CNIL/ICO enforcement catches up with EDPB 02/2023 scope

Jurisdiction-specific medium-severity findings — NEW IN v1.6 (6)¶

M24 — Switzerland nFADP: Swiss representative contact not published - Detection: site offers goods/services to, or monitors the behaviour of, people in Switzerland and appears to be controlled from outside Switzerland; no Swiss representative contact published on the site or in the policy - Frameworks: NIST PF v1.1 GV.PO-P3, CM.PO-P1; ISO/IEC 27701:2025 A.6.3.1.1 - Anchor sources: nFADP Art. 14 — certain foreign controllers must designate a representative in Switzerland; the representative maintains a copy of the ROPA and is the contact point for data subjects and the FDPIC

M25 — South Korea PIPA: Chief Privacy Officer (CPO) contact not published - Detection: site targets or processes personal information of users in South Korea; no CPO (or equivalent privacy contact) identifiable on the site or in the policy - Frameworks: NIST PF v1.1 GV.PO-P3; ISO/IEC 27701:2025 A.6.3.1.1 - Anchor sources: PIPA Art. 31 — mandatory CPO designation for every controller; statutory qualifications and direct board-reporting line - Note: where no privacy officer of any kind is contactable for a Korea-facing site, the finding promotes to F9

M26 — South Korea PIPA: automated-decision rights not addressed - Detection: site deploys automated/AI decisioning affecting Korean users (Browser Agent SDK signatures and/or Policy AI reading); policy does not address the right to refuse, or to obtain an explanation of, significant fully-automated decisions - Frameworks: NIST PF v1.1 Section 1.2.2, CM.PO-P1; ISO/IEC 27701:2025 A.7.3.2 - Anchor sources: PIPA Art. 37-2 and the enforcement-decree provisions effective 15 March 2024 — right to refuse / right to explanation of fully-automated decisions

M27 — UAE PDPL: Data Protection Officer contact not published (where required) — INTERIM - Detection: site has a mainland-UAE nexus (not DIFC/ADGM) and conditions suggest a DPO is required (large-scale or sensitive processing); no DPO/privacy contact identifiable on the site or in the policy - Frameworks: NIST PF v1.1 GV.PO-P3; ISO/IEC 27701:2025 A.6.3.1.1 - Anchor sources: UAE Federal Decree-Law No. 45 of 2021 Art. 10 — DPO appointment in defined circumstances; the controller/processor specifies the DPO contact and notifies the UAE Data Office (Bureau) - Notes: interim pending the PDPL Executive Regulations; suppress for DIFC/ADGM-nexus sites (governed by DIFC DPL 2020 / ADGM DPR 2021)

M28 — Nigeria NDPA: DPO contact not published for a controller of major importance - Detection: site appears to be a Nigerian "data controller/processor of major importance" (Nigeria nexus + scale/sector signals); no DPO contact identifiable on the site or in the policy - Frameworks: NIST PF v1.1 GV.PO-P3, ID.IM-P1; ISO/IEC 27701:2025 A.6.3.1.1 - Anchor sources: Nigeria Data Protection Act 2023 — DPO and NDPC-registration duties for controllers/processors of major importance; NDPC General Application and Implementation Directive (GAID) 2025

M29 — Saudi PDPL: Data Protection Officer contact not published (where required) - Detection: site has a Saudi nexus and conditions suggest a DPO is required (large-scale sensitive processing or systematic monitoring); no DPO/privacy contact identifiable on the site or in the policy - Frameworks: NIST PF v1.1 GV.PO-P3; ISO/IEC 27701:2025 A.6.3.1.1 - Anchor sources: Saudi PDPL and Implementing Regulations (SDAIA) — DPO appointment criteria; in full enforcement since 14 September 2024

M30 — Personal-data form without a point-of-collection notice or consent — NEW (staged for v1.8) - Detection: a contact/enquiry form collects personal data (an email or phone field plus a name or free-text field) with no consent option and no privacy notice in the form (the site-wide cookie banner does not satisfy this — it is about cookies, sits outside the form, and appears on every page). The Surface Agent fetches contact / support / partner / demo / apply pages (/contact, /support, /partners, /demo, /apply, … or a discovered link) in addition to the homepage, and the Browser Agent renders the best candidate. - Severity: medium. Capability: Notices, Policies & Agreements. - Frameworks: NIST PF v1.1 CM.PO-P1; ISO/IEC 27701:2025 A.7.3.2 - Anchor sources: GDPR Art. 13 (information at the point of collection); Singapore PDPA Notification Obligation; CCPA notice-at-collection (s. 1798.100(b)) - Coverage: the Surface Agent fetches the contact page statically AND the Browser Agent renders it (and the homepage), so JS-rendered/SPA forms (Wix, React) are seen. A form on a page neither fetched nor rendered may still be missed — absence of M30 is not evidence the form is compliant.

M31 — Live-chat / PII-collection widget with no privacy notice — NEW (staged for v1.8) - Detection: the Browser Agent detects a known live-chat / conversational widget (Intercom, Drift, Crisp, Tawk.to, Zendesk, HubSpot, Freshchat, etc.) loading. Such widgets routinely collect personal data in-conversation, which a contact-form check (M30) cannot see because they are not <form> elements. M31 (medium) fires when a widget is present AND the site has no privacy notice (no disclosure anywhere). Where a notice exists, the in-chat notice cannot be verified from the public surface, so the report shows an informational caution (verify the pre-engagement notice and that the provider is named as a processor) rather than a scored finding. - Severity: medium. Capability: Notices, Policies & Agreements. - Frameworks: NIST PF v1.1 CT.PO-P3; ISO/IEC 27701:2025 A.7.3.2 - Anchor sources: GDPR Art. 13 (information at the point of collection); Singapore PDPA Notification Obligation

Anchor-source extensions in v1.6¶

The following existing findings gain anchor sources for the new regimes (no new detection types): F1 (nFADP Art. 19; PIPA Art. 30; UAE/NG/SA notice duties); F9 (PIPA Art. 31 CPO; Nigeria DPO for controllers of major importance; Saudi DPO; UAE DPO Art. 10 — Switzerland does not mandate a DPO, only the M24 representative); F12 (PIPA Art. 28-8 separate consent; Saudi cross-border Regulation; UAE Art. 22–23; Nigeria adequacy); F14 (nFADP Art. 24; PIPA 72h; Nigeria 72h; Saudi Implementing Regs Art. 24; UAE Art. 9); M6 (nFADP Art. 22 DPIA; Saudi risk assessment); M9 (Switzerland Federal Council adequacy list / SCCs; UAE/NG/SA transfer disclosure); M10 (nFADP Art. 12 ROPA); M12 (PIPA Art. 37-2; nFADP Art. 21 automated individual decisions).

Low-severity findings (4)¶

L1 — No standalone Cookie Policy where promised - Detection: the privacy notice (or another public page) explicitly references a separate cookie document by name — "Cookie Policy", "Cookie Notice", "Cookie Statement", or a "Cookie & Tracking Technologies Notice" / "Cookie and Similar Technologies Policy" variant — but no such page resolves. Tightened 2026-06-20: a bare "we use cookies", or an incidental "cookie" token in markup or third-party tag scripts (GA/Meta), does not trigger this (that over-match produced a false positive on sites with no cookie document referenced at all). A published standalone cookie page clears it.

L2 — Children's section without age-gating (non-child-directed) — ICO Age-Appropriate Design Code; FTC COPPA; PDPC Children's Guidelines (28 March 2024); DPDPA Rule 10; Brazil ECA Digital; Thailand PDPA Section 20; Quebec Law 25 parental consent under-14s

L3 — Do Not Track signal explicitly ignored (GPC not separately implicated)

L4 — Behavioural advertising without explicit consent disclosure — EDPB Guidelines 05/2020; PECR Reg. 6; EDPB Guidelines 1/2024 on Art. 6(1)(f); becomes high where consent claimed but not collected (F7)

Commendable practices (10)¶

Observed implementation that exceeds baseline regulator expectation. Informational only; does not affect risk band. Scanner surfaces the six strongest per scan.

C1 — Dedicated privacy portal on a separate domain or subdomain - Detection: DSAR and rights-management interface available at a distinct URL (e.g., privacy.example.com) rather than as a form embedded in the main privacy notice - Frameworks: NIST PF v1.1 CM.PO-P1, IP.MP-P1; ISO/IEC 27701:2025 A.7.3.5 - Baseline exceeded: GDPR Art. 12 "easily accessible" — baseline is any functioning rights mechanism; C1 recognises dedicated infrastructure - Anchor source: EDPB Guidelines on transparency; PDPC accountability guidance

C2 — Maintained, publicly-linked sub-processors list - Detection: a dedicated page or document listing named processors, linked from the privacy notice or footer, with evidence of maintenance (version number, last-updated date, or change log) - Frameworks: NIST PF v1.1 ID.IM-P1; ISO/IEC 27701:2025 A.7.3.4 - Baseline exceeded: GDPR Art. 28 processor transparency — baseline is naming categories of processors; C2 recognises naming specific processors with ongoing maintenance - Anchor source: EDPB Guidelines on Article 28; ICO processor guidance

C3 — Privacy policy structured by data subject category - Detection: privacy notice explicitly distinguishes rights and processing for different categories (e.g., end users vs. end customers vs. representatives vs. visitors; controllers vs. processors; adults vs. minors) rather than applying a single uniform narrative - Frameworks: NIST PF v1.1 CM.PO-P1; ISO/IEC 27701:2025 A.7.3.2 - Baseline exceeded: GDPR Art. 13–14 — baseline is clear disclosure; C3 recognises the correct response to multi-role platform obligations - Anchor source: EDPB transparency guidelines; ICO right to be informed

C4 — Explicit AI training disclosure with data category naming - Detection: privacy notice explicitly discloses that personal data is (or may be) used to train AI models, and names the categories of data used - Frameworks: NIST PF v1.1 Section 1.2.2, CM.PO-P1; ISO/IEC 27701:2025 A.7.3.2 - Baseline exceeded: EU AI Act Art. 50 transparency (enforceable 2 August 2026) — baseline is AI interaction disclosure; C4 recognises training-data transparency beyond the statutory minimum - Anchor source: PDPC AI Advisory Guidelines (1 March 2024); EU AI Act Art. 50; California CPPA ADMT regulations

C5 — Jurisdiction-specific localised privacy materials - Detection: privacy and cookies policies available in multiple jurisdictions with jurisdiction-specific routing and content (not merely translation) — e.g., stripe.com/en-ca/legal vs. stripe.com/fr-ca/legal vs. stripe.com/de/legal with distinct legal content - Frameworks: NIST PF v1.1 CM.PO-P1; ISO/IEC 27701:2025 A.7.3.2 - Baseline exceeded: GDPR Art. 12 "clear and plain language" — baseline is readable language; C5 recognises jurisdiction-aware content delivery - Anchor source: CNIL localisation guidance; PDPC Advisory Guidelines on Key Concepts

C6 — Publicly available Data Processing Agreement and transfer addenda - Detection: DPA, Data Transfer Addendum, and/or Supplier DPA available as public, linked documents without sales or support contact required - Frameworks: NIST PF v1.1 ID.SC-P1; ISO/IEC 27701:2025 A.7.2.6 - Baseline exceeded: GDPR Art. 28 — baseline is entering into a DPA on request; C6 recognises public pre-signed availability - Anchor source: EDPB Guidelines on Art. 28; ICO controller-processor guidance

C7 — Privacy policy updated within 6 months - Detection: privacy notice "last updated" date within 180 days of scan date - Frameworks: NIST PF v1.1 GV.PO-P1; ISO/IEC 27701:2025 A.7.3.2 - Baseline exceeded: accountability principle — baseline is keeping policies accurate; C7 recognises active maintenance - Anchor source: ICO accountability principle; EDPB transparency guidelines - Note: at 12 months, C7 no longer triggers; at 24 months, F2 triggers. C7 exists specifically to reward currency, not to penalise its absence.

C8 — Transparency Center or privacy hub beyond a single policy page - Detection: a dedicated, linked privacy hub consolidating policies, rights tools, sub-processors, transfer documentation, DPF self-certification, and incident disclosures into a navigable surface - Detection criteria (corrected 2026-06-16): C8 requires a genuine, dedicated privacy/trust hub — a privacy-centre, transparency, or trust-centre surface, or a true privacy/trust subdomain — not merely an ordinary privacy notice. Detection was tightened on 2026-06-16 so that an ordinary privacy notice, a plain legal/terms page, or incidental "trusted by…" text no longer counts as a hub. - Frameworks: NIST PF v1.1 CM.PO-P1; ISO/IEC 27701:2025 A.7.3.2 - Baseline exceeded: ISO/IEC 27701:2025 A.7.3.2 transparency — baseline is publishing a privacy notice; C8 recognises hub-level organisation - Anchor source: PDPC accountability guidance; EDPB transparency guidelines

C9 — Sub-processor change notification mechanism - Detection: a subscribable notification channel (RSS, email list, versioned changelog, or webhook) that notifies customers of sub-processor additions or changes before they take effect - Frameworks: NIST PF v1.1 ID.SC-P1; ISO/IEC 27701:2025 A.7.2.6 - Baseline exceeded: GDPR Art. 28(2) prior notice of processor changes — baseline is the contractual obligation; C9 recognises operational infrastructure to deliver on it - Anchor source: EDPB Guidelines on Art. 28; Microsoft, AWS, and Google Cloud models widely cited as reference implementations

C10 — Published DPIA / PIA methodology or summary - Detection: public documentation of the DPIA/PIA methodology used, or a published summary of DPIAs for high-risk processing (e.g., AI/ADMT, biometric, large-scale profiling) - Frameworks: NIST PF v1.1 ID.RA-P3; ISO/IEC 27701:2025 A.7.2.5 - Baseline exceeded: GDPR Art. 35 — baseline is conducting DPIAs and making them available to the supervisory authority on request; C10 recognises voluntary publication - Anchor source: ICO DPIA guidance; EDPB Guidelines 4/2017 on DPIA (WP248)

Appendix B — Risk band thresholds¶

Generic SME (low sensitivity)¶

Elevated sensitivity¶

Sites handling health, biometric, financial, child-directed data, AI-driven significant decisioning, Washington MHMDA consumer health data, or EU AI Act Article 5 prohibited practice scope.

Trigger conditions for elevated sensitivity¶

• Self-identification as healthcare, medical, biometric, financial, banking, insurance, child-directed service
• Domain or content patterns indicating regulated industry
• Privacy policy explicitly mentions special-category, biometric, health, financial, or children's data
• Detected technologies suggest sensitive data collection (face scan SDKs, biometric authentication, payment processing beyond standard checkout, AI recommendation / decisioning)
• ADMT for significant decisions in CCPA-covered contexts
• AI systems potentially within EU AI Act Article 5 or Colorado AI Act high-risk scope
• Washington MHMDA consumer health data indicators (fitness, wellness, nutrition, biometric, bodily functions, reproductive, mental health, location reasonably indicating health)
• Sites likely to be accessed by children under ICO Age-Appropriate Design Code, PDPC Children's Guidelines, Brazil ECA Digital, Thailand PDPA Section 20, Quebec Law 25, or COPPA
• Cross-border PI transfers requiring documented pathways (China PIPL, Malaysia CBPDT, Brazil post-SCC)

Appendix C — Version and changelog¶

Current version: v1.8, effective 21 June 2026 (refinements 22 June 2026).

Changelog¶

v1.8 — 22 June 2026 (refinements) - M13 gated to a US nexus: "No GPC response disclosure" is now asserted only when a California / US (CA-US) nexus is detected. GPC / universal opt-out is a US-state construct (CCPA §7025 + other UOOM states), so it is no longer raised on EU- or Singapore-only sites with no US footprint. The underlying citations are unchanged. - Finding regulator-anchors are sensitivity-gated for display: a sector-specific statute attached to a finding's anchor sources (e.g. Washington MHMDA, a consumer-health law) is shown only when the matching elevated-sensitivity context — health / biometric for MHMDA — was actually detected. The full anchor catalogue is unchanged; this scopes only what is displayed on a given scan, so a missing-notice finding on a non-health site no longer cites a consumer-health statute. - Capability-maturity indicator (0–100) documented; not floored: the secondary 0–100 indicator now has its own section, "The capability-maturity indicator". A site with no observable privacy programme can legitimately read 0/100 — a genuine reading, not an error. The band remains the headline and the indicator never moves on commendable practices. - Plain-language summary always renders: the report's plain-language summary is produced for every scan — AI-authored when it passes the methodology's claim checks, otherwise a deterministic summary built only from the scored findings — so it never silently disappears.

v1.8 — 21 June 2026 - Terminology: standardised on "privacy notice" (not "privacy policy") for the public transparency document across methodology, findings catalogue, UI, report and AI prompts; statutory terms of art retained (Washington MHMDA "consumer health data privacy policy", "cookie policy"). Agent name Policy AI unchanged. - F7 / L4 citation fix: corrected the PECR anchor from Reg. 22 (electronic-mail marketing) to Reg. 6 (storage of / access to information — the cookie/pixel consent rule); Regulator Reference now distinguishes the two. - M3 / M13 wording: no longer presume a privacy notice exists — when F1 also fires they report the gap as a consequence of the missing notice. M13 title shortened to "No GPC response disclosure". - L1 false-positive fix + variants: requires an explicit reference to a separate cookie document by name, and recognises the Cookie Notice / Statement / "& Tracking Technologies" variants; a bare "cookie" mention no longer fires. - Jurisdiction nexus expansion: added Singapore (PDPA), Japan (APPI), India (DPDPA), China (PIPL), Canada (PIPEDA), Malaysia/Thailand (PDPA), Hong Kong (PDPO), South Africa (POPIA) to the nexus detector (ccTLD or explicit law/regulator reference), plus readable regime labels on report chips. - Operating-base nexus (new): a corroboration-gated inference (legal-entity suffix, country in the site title, calling code, address/postcode) that names a regime for sites clearly operating in a country without citing its law — restricted to the non-finding-gating regimes (SG/MY/JP/IN/HK/TH/CN/ZA) so it never moves a band. - M30 (new) + contact-page crawl + render: the Surface Agent fetches a contact/enquiry page and the Browser Agent renders it (and the homepage); M30 fires when a personal-data form has no point-of-collection notice or consent. The cookie banner doesn't satisfy it. A proper disclosure (processing statement / Transparency Center / data-subject-rights — Dxtra's own form pattern) correctly clears it. - Crawl expansion + M31 (new): the Surface Agent now also reaches support / partner / demo / apply pages (not just /contact); M31 flags a live-chat / PII-collection widget (Intercom, Drift, Crisp, Zendesk…) — a scored finding when the site has no notice, an informational caution otherwise. Chat widgets aren't forms, so M30 alone can't catch them. Target-market caution (informational) added to the jurisdiction section for regimes a site serves but isn't established in. - Privacy-notice content verification: a referenced/linked "privacy policy" is now accepted as a notice only if its page contains substantive privacy content (≥2 markers such as personal data, your rights, processors, lawful basis), not merely the word "privacy" (which the cookie banner puts on every page). A link that resolves to a non-notice page (e.g. a duplicate homepage) now correctly fires F1 and no longer credits a false "policy present" strength. M3 retitled "Processors not named or disclosed" to read correctly whether a notice is incomplete or absent. (Found via the tailormyproperty.com /home-1 case.)

v1.7 — 16 June 2026

Consolidation + corrections + geo-vantage integration. Material changes:

Scan-agent naming - "Worker 1 / Worker 2 / Worker 3" are renamed to Surface Agent / Browser Agent / Policy AI throughout the methodology. The mapping table is the new "Scan-agent naming" subsection at the top of the methodology. Earlier docs retain "Worker N" as historical only. - Collective term: Dxtra's scan agents. Tracker/consent evidence is attributed to the Browser Agent; deep policy substance to the Policy AI; public-surface/link discovery to the Surface Agent.

Transparency-hub correction - M5 is now gated to elevated-sensitivity processing (health, biometric, financial, child-directed, AI significant-decisioning). Ordinary SMBs without a transparency centre no longer fire M5 — its presence remains rewarded as C8. Mirrors the M6 (DPIA) gating rationale. - C8 detection is tightened to require a genuine, dedicated privacy/trust hub (a privacy-centre, transparency, or trust-centre surface, or a true privacy/trust subdomain) rather than an ordinary privacy notice. The previous looser matching over-counted an ordinary privacy notice, plain legal pages, and incidental "trusted by…" text as a hub.

Geographic vantage - The geo-vantage addendum is folded into the methodology as the new "Geographic vantage" chapter. All rules carry across: vantage disclosure (mandatory), absence ≠ compliance, multi-vantage scoring (worst observed = headline), datacenter-IP honesty & cloaking, GPC/UOOM vantage dependency, the vantage catalogue, the de-cloaking honesty stance, residential-proxy egress as a future escalation requiring a policy change, and the vantage output fields. The cross-jurisdictional rule is reframed against observed vantages rather than only inferred exposure.

Severity overlays — severity-financial added - The severity-overlay set (severity-child, severity-health, severity-platform) gains severity-financial (indigo #3730a3) for regulated financial-services processors (payments, identity verification, automated fraud / credit decisioning), to keep the financial overlay visually distinct from severity-health so the overlay reads unambiguously at a glance.

Scanner-is-real framing - All three scan agents now run live in production (a self-hosted headless browser for the Browser Agent; no paid third-party API in the scan path). The previous "stubbed Worker 2 / thin prototype" framings have been removed where they were factual descriptions of capability; the "indicator, not legal opinion" framing is unchanged because that is a permanent positioning, not a prototype caveat.

Companion document version - Companion Regulator Reference bumped to v1.6 (Munich Google Fonts entry added; version coupled to Methodology v1.7).

Catalogue invariants preserved - 48 findings (F1–F15 high, M1–M29 medium, L1–L4 low) + 10 commendable practices (C1–C10). All finding IDs and commendable IDs are unchanged from v1.6.

v1.6 — 21 May 2026

Jurisdictional coverage expansion. Material changes:

New regimes covered - Switzerland nFADP (in force 1 September 2023), South Korea PIPA (amended 15 September 2023; automated-decision provisions 15 March 2024), UAE PDPL (Federal Decree-Law 45/2021), Nigeria NDPA 2023, and Saudi Arabia PDPL added as covered regimes; all removed from the limitations section. - Jurisdictional architecture expanded from eight to thirteen points (Switzerland criminal/personal enforcement + transparency-based cookies; Korea turnover-based fines + CEO accountability + ADM rights; UAE federal + DIFC/ADGM free-zone split; Nigeria "major importance" tier; Saudi full enforcement + criminal sensitive-data exposure).

New findings (6) — catalogue grows from 42 to 48 - M24 (Switzerland nFADP: Swiss representative not published); M25 (Korea PIPA: CPO contact not published); M26 (Korea PIPA: automated-decision rights not addressed); M27 (UAE PDPL: DPO contact not published — interim); M28 (Nigeria NDPA: DPO contact not published for controllers of major importance); M29 (Saudi PDPL: DPO contact not published). - Anchor-source extensions to F1, F9, F12, F14, M6, M9, M10, M12 for the five regimes.

Guards and caveats - Prior-consent cookie findings (F3–F7) are suppressed for Switzerland-only sites (no ePrivacy nexus), to avoid false positives. - UAE findings flagged interim pending the PDPL Executive Regulations; UAE Federal-PDPL findings suppressed for DIFC/ADGM-nexus sites.

Citation verification - Article-level citations verified against authoritative secondary sources (law-firm guidance, IAPP, official UAE legislation portal). A final confirmation against primary statutory text by a qualified privacy professional is recommended before any enforcement-grade reliance.

Carried-forward deferrals updated - Switzerland/Korea/UAE/Nigeria/Saudi are no longer deferred; future jurisdictions (additional GCC/African/LATAM regimes) are assessed on a rolling basis.

v1.5 — 17 April 2026

Added commendable practices dimension. Material changes:

Output model extension - Scanner output now includes a list of commendable practices alongside findings - Commendable practices are informational only and do not affect the risk band (anchored to findings to preserve diagnostic integrity) - Scanner surfaces up to six commendable practices per scan, ordered by strength; additional practices are counted but not enumerated - New dedicated "Commendable practices" section in front matter explains the design rationale and the non-effect on risk band

New C-catalogue (10 types) - C1: Dedicated privacy portal on a separate domain or subdomain - C2: Maintained, publicly-linked sub-processors list - C3: Privacy policy structured by data subject category - C4: Explicit AI training disclosure with data category naming - C5: Jurisdiction-specific localised privacy materials - C6: Publicly available DPA and transfer addenda - C7: Privacy policy updated within 6 months - C8: Transparency Center or privacy hub beyond a single policy page - C9: Sub-processor change notification mechanism - C10: Published DPIA / PIA methodology or summary

Motivation - Running v1.4 against stripe.com surfaced the issue: a site that has done the work rated Low risk with 2 minor medium findings, but the report read as faint praise. The existing model had no way to recognise genuinely above-baseline implementation. v1.5 addresses this without compromising the scoring's diagnostic integrity.

Scope discipline - Each C-finding must (a) exceed a named regulator's baseline expectation, (b) be externally observable, © anchor to a specific regulator source the same way F-findings do - C-findings are not defensive overclaims ("we have a privacy team") — they require observable public surface - C-findings do not soften F or M findings; a report with six C-findings and two M-findings still has two M-findings to address

Known v1.5 gaps carried over from v1.4 - Switzerland nFADP and South Korea PIPA still flagged in limitations; integration deferred to v1.6 to avoid conflating the commendable-practices work with new jurisdictional coverage. Planned v1.6 target Q3 2026.

v1.4 — 17 April 2026

Fourth expert privacy review with structural refactor. Material changes:

Structural refactor - Regulator encyclopedia extracted to companion Dxtra Privacy Scanner Regulator Reference document - Methodology now focused on the 42 finding types the scanner actually checks, with anchor framework mappings and anchor regulator sources; full citation detail is maintained in the Reference

Canada integration (previously unmentioned) - Commission d'accès à l'information du Québec (CAI) added - Office of the Privacy Commissioner of Canada (OPC) added - Quebec Law 25 (fully in force 22 September 2024) added as statutory instrument - PIPEDA added - New M21 (medium-severity): Quebec Law 25 privacy officer contact not published on website - F1, F9, F14 updated with Quebec Law 25 citations - L2 updated with Quebec Law 25 parental consent threshold

US state privacy expansion (beyond GPC) - Washington State Attorney General added as regulator - Colorado Attorney General added for AI Act enforcement - Washington My Health My Data Act (RCW 19.373) added as statutory instrument - Nevada Consumer Health Data Privacy Law added as parallel regime - Colorado AI Act (SB 24-205) added with delayed effective date (30 June 2026 per SB 25B-004) - New F15 (high-severity): Washington MHMDA separate consumer health data privacy policy missing - New M22 (medium-severity): Colorado AI Act consumer-facing AI disclosure absent

EDPB Guidelines 02/2023 tracking-scope integration - EDPB Guidelines 02/2023 on technical scope of Article 5(3) ePrivacy (finalised October 2024) added - F3, F6, F7 broadened to cover tracking pixels, fingerprinting, tracking links, and other Article 5(3) trackers beyond cookies - New M23 (medium-severity): non-cookie tracker fires before consent (pixels, fingerprinting, tracking links) - Jurisdictional architecture point 3 added: "tracking is no longer a cookies question"

Jurisdictional architecture - Expanded from seven to eight points; Canadian privacy fragmentation added as architectural point 8

Acknowledged gaps for v1.5 - Switzerland nFADP (in force September 2023) flagged in limitations - South Korea PIPA flagged in limitations - Both named as planned v1.5 integrations

Finding catalogue growth - v1.0: 14 findings - v1.1: 17 findings - v1.2: 21 findings - v1.3: 28 findings - v1.4: 42 findings (15 high-severity, 13 core medium + 7 jurisdiction-specific medium + 3 new medium, 4 low)

v1.3 — 17 April 2026

Third expert privacy review. Brazil LGPD integration; China PIPL integration; Australia Privacy Act reforms; Thailand PDPA integration; EU AI Act Article 5 and Article 4; 7 new findings (F12, F13, F14, M16, M17, M18, M19, M20). Jurisdictional architecture expanded to seven points.

v1.2 — 17 April 2026

Second expert privacy review. US state privacy expansion (GPC enforcement); CCPA 2026 ADMT regulations; EU AI Act Article 50; Malaysia PDPA Amendment; India DPDPA Rules; 5 new findings (F10, F11, M13, M14, M15).

v1.1 — 17 April 2026

First expert privacy review. NIST PF v1.1, ISO/IEC 27701:2025, DUAA UK, CNIL SHEIN/Google deliberations, PDPC 2024 guidelines, jurisdictional architecture section, 3 new findings (F6, M11, M12).

v1.0 — Initial publication

Indicator-based methodology, NIST PF v1.0 and ISO/IEC 27701:2019 reference frameworks, 14 finding types.

Questions about the methodology can be sent to methodology@dxtra.ai. We respond to substantive methodology questions from researchers, journalists, and customers within 5 business days.