Start here
Before you fix it: what this check means
Scavo looks for tools such as session recording, fingerprinting, and some chat services, and checks available browser evidence for activity before a choice. Finding a tool in the page source alone does not prove it ran or collected sensitive information. Scavo evaluates one control.
Why this matters in practice: visitors need understandable privacy information and choices that work as described.
Use this as evidence, not a final verdict. A scan cannot determine which privacy laws apply or certify compliance. Missing browser evidence means behaviour is unconfirmed, not that tracking is absent. Check the live site first. Open the same page with fresh cookie settings, try its privacy choices, and compare what happens with the report Make one controlled change. Classify replay/chat/behavioral tools into high-risk consent categories. Re-scan the same URL and compare the finding; check the feature yourself as well.
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 (quick version)
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.
