Start here
Before You Fix It: What This Check Means
Sensitive-tracker controls reduce risk from replay/chat-style tooling before explicit consent. In plain terms, higher-risk trackers should not run before explicit consent. Scavo evaluates one control.
Why this matters in practice: this signal influences reliability, trust, and diagnosability of your production setup.
How to use this result: treat this as directional evidence, not final truth. This result reflects what was observable at scan time and should be verified in your own production context. First, confirm the issue in live output: verify directly in live production output with browser/network tools Then ship one controlled change: Classify replay/chat/behavioral tools into high-risk consent categories. Finally, re-scan the same URL to confirm the result improves.
TL;DR: Session replay, fingerprinting, or invasive tracking tools are running without explicit consent — a serious GDPR and CCPA liability.
GDPR classifies browser fingerprinting as personal data processing requiring prior consent, and session replay tools that capture form data or personal information require explicit, informed consent (GDPR Article 4). Non-compliance carries fines up to €20M or 4% of global annual revenue, whichever is higher (GDPR Article 83). These are the highest-risk trackers regulators look for because they're inherently invasive.
What Scavo checks (plain English)
Scavo evaluates one control:
LC-S4: are high-risk tracker-family hosts observed in pre-consent runtime signals?
Current logic behavior:
Fail: matched high-risk hosts are seen pre-consentInfo/Inconclusive: high-risk provider signatures exist but runtime evidence is incompleteWarning: high-risk provider family detected statically, but no pre-consent firing observedPass: no high-risk pre-consent exposure detected
How Scavo scores this check
Scavo assigns one result state for this check on the tested page:
- Pass: baseline signals for this check were found.
- Warning: partial coverage or risk signals were found and should be reviewed.
- Fail: required signals were missing or risky behavior was confirmed.
- Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.
In your scan report, this appears under What failed / What needs attention / What is working for legal_sensitive_tracker_risk, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
legal_sensitive_tracker_risk - Category:
LEGAL_COMPLIANCE
Why fixing this matters
Users are especially sensitive to tools that can capture detailed behavior. If those tools run before consent, trust and legal risk both increase.
For teams, this check helps enforce "least invasive by default" behavior on sensitive journeys.
If you are not technical
- Ask for a list of high-risk tools currently installed and where they run.
- Require explicit consent gating proof for those tools on key routes.
- Review sensitive pages (signup, account, billing, support forms) first.
- Re-run Scavo and confirm this check improves.
Technical handoff message
Copy and share this with your developer.
Scavo flagged Sensitive tracker risk exposure (legal_sensitive_tracker_risk). Please prevent high-risk tracker families from firing pre-consent, especially on sensitive journeys, and provide route-level runtime evidence after remediation.If you are technical
- Classify replay/chat/behavioral tools into high-risk consent categories.
- Default them to blocked until explicit opt-in.
- Disable them entirely on sensitive routes unless clearly justified.
- Apply vendor-side minimization controls (masking, reduced capture scope, retention limits).
- Add canary tests that fail when high-risk hosts appear pre-consent.
How to verify
- In a clean session, load target route without consenting.
- Confirm high-risk hosts do not appear in network requests.
- Confirm they only activate after explicit opt-in (if enabled at all).
- Re-run Scavo and inspect
matched_high_risk_preconsent_hosts.
What this scan cannot confirm
- It is not legal advice or a complete legal risk determination.
- It cannot fully inspect provider-side processing beyond observable runtime evidence.
- Custom/private tracker hostnames may need manual allow/deny mapping outside defaults.
Owner checklist
- [ ] Assign one owner for high-risk tracker governance.
- [ ] Keep route-level tracker policy documented.
- [ ] Re-audit after adding new chat/replay/behavioral vendors.
- [ ] Include sensitive-route checks in every major release QA cycle.
FAQ
Which tools are considered "high risk" here?
Tools with richer behavioral capture patterns (session replay-like tooling and surveillance-heavy chat stacks), especially when they load before consent.
Can we keep these tools and still pass?
Yes, if they do not fire pre-consent and your implementation is tightly controlled.
Why can this return warning instead of fail?
Warning can appear when static provider signatures exist but runtime evidence did not show pre-consent firing in that run.
Should sensitive routes have stricter policy than marketing pages?
Usually yes. Route-level risk controls are often the safest practical approach.
Sources
- EDPB Guidelines 05/2020 on Consent
- ICO: Cookies and similar technologies
- California AG: CCPA overview
- California Penal Code §631 (CIPA)
This guide is operational guidance, not legal advice.
