1. Crawling
Vi starter en headless Chromium-nettleser (via Playwright) med desktop User-Agent og viewport på 1366×800. Deretter laster vi URL-en du oppga og venter til siden når 'networkidle' i opptil seks sekunder.
Betalte skanninger øker dekningen ved å følge lenker på samme domene opp til valgt plangrense: fem sider på Pro og Agency Starter, eller tjue på Agency og Agency Pro. Auto-oppdagelse prioriterer nyttige interne ruter, og betalte brukere kan i tillegg feste spesifikke stier som checkout-, konto- eller kontaktsider. Hver sti holdes innenfor totalt sidebudsjett.
Gratis skanning laster forsiden én gang og registrerer hva nettleseren gjør uten interaksjon, ingen innlogging, ingen skjemainnsending, ingen klikk på samtykkebanner. Betalte planer kjører automatisk samtykkebevisst skanning: vi åpner nettstedet på nytt i en ren nettleserkontekst, klikker en Godta alle-knapp i samtykkebanneret, og besøker deretter inngangssiden pluss opptil fire baseline-undersider i samme kontekst (slik at samtykkecookies og localStorage-flagg bevares). Rapporten viser en side-ved-side-delta av tjenester, cookies og tredjepartsdomener som kun lastes etter samtykke.
Samtykkeklikkeren søker både i hovedsiden og sannsynlige CMP-iframes (Sourcepoint, OneTrust, Cookiebot, Didomi, TrustArc, Quantcast, Usercentrics, Iubenda, Klaro, Osano, Borlabs, Complianz) med en kuratert liste av leverandørselektorer og godta-alle-knappetekster på omtrent 15 språk. Når deterministiske selektorer ikke treffer, kan en valgfri LLM-fallback (gpt-4o-mini, cachet per vert) identifisere godta-knappen fra en avgrenset liste av synlige elementer. Kun avgrenset kontrollmetadata fra skannet side (etiketttekst, tag, CSS-klasser, ID-er og ARIA-etiketter) sendes. Frame-identifikatorer er ugjennomsiktige, og vanlige mønstre for e-post, telefon, URL og lange identifikatorer maskeres først. Vi sender ikke med hensikt personopplysninger, skanne-URL, cookies eller sideinnhold (se vår personvernerklæring). Mot en smoke-test på 18 større europeiske nettsteder er nåværende treffrate rundt 89%.
2. Registrering av forespørsler
For hver nettverksforespørsel nettleseren gjør registrerer vi URL, vert og ressurstype. En forespørsel klassifiseres som tredjepart når registrerbart domene er forskjellig fra registrerbart domene for det skannede nettstedet.
For å fastslå registrerbart domene bruker vi Public Suffix List, den samme listen nettlesere bruker for å avgjøre hvor en organisasjons domene slutter og et delt register starter. Dette håndterer korrekt flerdelte suffikser som .co.uk, .com.au og .co.jp, slik at shop.example.co.uk reduseres til example.co.uk og ikke registeret co.uk.
On paid plans we also tag each retained request with the page it fired on and whether it ran before a choice, after Accept all or after Reject all. Where Chromium exposes it, the evidence can also include request method, resource type, redirect hops and the initiating URL. This provenance lets the report show where and when a service was observed instead of only saying that it exists somewhere on the site.
Consent-control evidence is deliberately privacy-reduced. We retain bounded metadata about the activated control and may capture a small image of that control, never a full-page screenshot. Storage entries and TCF strings are represented by key names, byte sizes and SHA-256 hashes; raw storage values, raw cookie values and raw TC strings are never retained. Paid users can export a sanitized evidence manifest with stable evidence IDs and an integrity hash. Request evidence is bounded per service, so it is a reproducible sample rather than a claim that every request made by the site was retained.
3. Leverandørmatching
Vi vedlikeholder en kuratert database med 910 tredjepartsleverandører: utforsk katalogen. Hver leverandøroppføring inneholder ett eller flere domenemønstre.
En forespørsel matcher en leverandør når:
- vertsnavnet er lik mønsteret, eller
- vertsnavnet slutter med
.+ mønsteret (suffiksmatch), eller - for de få ikke-domenemønstrene vi bruker, inneholder full URL mønsteret.
Når en forespørsel matcher flere mønstre velger vi det mest spesifikke (lengste). Domener som ikke matcher noen leverandør listes som umatchede.
4. Regionklassifisering
Hver leverandør klassifiseres etter eierregion. Klassifiseringen baseres på hvor morselskapet er registrert, ikke hvor data fysisk ligger. En USA-eid leverandør med datasentre i EU klassifiseres fortsatt som USA fordi innsynsforespørsler (FISA 702, Cloud Act) styres av eierskap.
5. Lastet før samtykke og overføringsvurdering
Utover skåren svarer to deler av rapporten på spørsmålene en DPO faktisk stiller: hva som lastes før besøkende samtykker, og hvor dataene går. Begge utledes direkte fra registrerte forespørsler. De beskriver hva vi observerte, ikke om det er lovlig.
Lastet før samtykke
No-interaction load er vår baseline. For flersideskanning består den av én ren no-interaction load per skannet URL, før noe samtykkebanner klikkes. Vi dedupliserer observerte tjenester i baseline-inventaret, beholder kun reelle sporingsrelevante kategorier (annonsering, analyse, tag management, feilsporing og lignende), og skiller førsteparts-tjenester fra tredjeparts-tjenester. Hovedtallet teller kun tredjepartstrackere, fordi et nettsted som laster eget subdomene ikke er hovedproblemet her.
Dette er en teknisk observasjon fra skannedatoen. Det er ikke en juridisk konklusjon om gyldigheten av samtykke.
Observed external services and transfer review worksheet
Vi grupperer hver observert ekstern tjeneste etter eierskap og DPF-signaler, ikke etter en konkludert behandlingslokasjon eller juridisk mekanisme: Technical observations that can support updates to processing records and vendor registers. Legal and organisational fields require customer verification.
Hver tjeneste merkes også med om den fyrte før eller etter samtykke. Eksponeringsmatrisen teller observerte tjenester per signalgruppe og fase. Den hjelper med prioritering, men er ikke en GDPR-risikoscore. Betalte planer viser mulig mekanisme eller kontrollpunkt og eksporterer et CSV-ark med kunde-eide felt tomme.
Hvordan vi verifiserer DPF-status: vi gjetter ikke. En USA-eid tjeneste får kun DPF-treffsignal når juridisk enhet matches mot den offisielle deltakerlisten publisert av U.S. Department of Commerce på dataprivacyframework.gov og at den enheten har en aktiv EU–US-sertifisering. Ved treff viser rapporten nøyaktig sertifisert enhet og dato for siste kontroll (for eksempel “Verifisert 8. juli 2026 · Stripe, LLC”), slik at du ser hvor ferskt funnet er. En automatisk jobb kontrollerer hele listen ukentlig. Nye sertifiseringer fanges opp, og hvis en leverandørs sertifisering utløper får vi varsel og nedgraderer status. Leverandører vi ikke kan matche mot aktiv sertifisering står som “status ukjent” i stedet for at vi impliserer noe negativt.
6. EU Independence Score
Skåren er et eksperimentelt signal, ikke en etterlevelsesvurdering. Den starter på 100 og fire straffekomponenter trekkes fra:
Score = 100 − P_vendor − P_mix − P_unknown − P_infra
Formelen over gjelder for nettsteder eid av et EU/EØS-selskap. Hvis selve det skannede nettstedet eies av et amerikansk, kinesisk eller russisk selskap, overstyrer dette leverandørmatematikken: skåren begrenses og relabeles (for eksempel USA-eid nettsted), fordi tredjepartsstacken da i stor grad er eierens egne førstepartsressurser. I slike tilfeller reflekterer skåren nettstedets eierskap, ikke hvor EU-vennlige innebygde leverandører er. Derfor kan en EU-uavhengighetsskår og et eierskapsforbehold vises sammen i samme rapport.
When significantly non-EU services (US, China, Global) make up a large share of the classified service inventory, an additional penalty applies, up to −20. The penalty is scaled by sample size so a single finding on a short scan does not over-fire.
Example: 3 US-owned services, 1 EU-owned service = 75% non-EU ratio → P_mix ≈ 15
A site can run its trackers from the EU yet still host itself, its email or its DNS on a non-EU-owned provider. That is a first-order sovereignty concern (CLOUD Act / FISA 702) independent of the third-party stack, so we resolve the origin hosting, email (MX) and authoritative DNS (NS) providers and classify each by ownership region.
Kun tydelig ikke-EU leverandører (USA, Kina, Global, Ukjent) teller. Når infrastruktur ikke kan løses, er P_infra 0. Skanningen straffes aldri for manglende data.
Etikett-vaktregler
Labels are not derived purely from the numeric score. Hard rules prevent misleading labels even when the score is numerically high. For example, Mostly EU independent is blocked if non-EU services outnumber EU/EEA services, regardless of the score.
The score card in your report shows a full breakdown so you can see exactly how each component contributed, along with a confidence indicator.
7. Overvåking, historikk og policysporing
Betalte planer skanner hvert overvåket nettsted ukentlig og gjør resultatene om til en varig historikk i stedet for et enkelt øyeblikksbilde. Hver skanning sammenlignes med forrige, og tre ting registreres.
Tjenestetidslinje
For each service we keep a first-seen and last-seen date, whether it is currently active, and whether it loaded before or after consent. A change timeline logs every service added, service removed and score change between scans, so you can point to the exact date a tracker appeared, useful evidence at an audit. The full history is browsable per site and exportable to CSV or JSON.
Historikk for post-reject-signal
Every weekly scan repeats the Reject-all network test. When a service first appears in the post-reject observation, we log a timestamped post-reject signal on the timeline and email you. When that signal later disappears, we record the change. This gives you dated before-and-after technical evidence from StackPatrol’s scheduled tests; it does not prove the exact moment a wider consent issue started or was fully resolved.
Sporing av juridiske dokumenter
On the same run we discover the site’s privacy policy, cookie policy, DPA, terms and GDPR pages. Links are classified from both the URL and the anchor text across multiple languages, and we deliberately follow the very common case where a site hosts these documents on a parent-company or group domain (for example a newspaper whose privacy policy lives on the publisher’s domain), while excluding social-network and search-engine platform policies. This crawl runs with a lightweight, size- and time-bounded fetch outside the page budget, so it never reduces the service-inventory page allowance.
For each document we normalise the text, take a SHA-256 content fingerprint, and extract the date the page states it was last updated (cue-based, multilingual, rejecting impossible or future dates). The report retains the document title, sanitized source URL, stated update date, fetch timestamp and fingerprint so the comparison can be verified. On the next monitoring scan we compare fingerprints to detect when the content actually changed, independently of whatever date the page claims.
Flagg for dokumentasjonsgap
The signal we find most useful: when your service inventory changes but the privacy (or cookie/DPA) document stays frozen, the alert flags a possible documentation gap. It is a prompt to review, not a legal finding. A policy can be correct without changing, and a change does not prove anything. You decide what needs updating.
Disclosure gap (Consent Assurance)
We go one step further than tracking when a document changed: we compare the disclosure sources we can inspect against the services the scan actually observed. These sources include readable policies and, in paid reports when available, the configured vendor list exposed by the site’s consent manager. Each observed service receives one of three evidence states. Exact service match means its own domain or distinctive service name appears in a checked source. Provider or parent match means an explicitly curated provider alias appears, but the specific service name does not. No match found means no service, domain or approved provider alias was found in a checked source.
Consent-manager inspection runs in a separate clean browser context and only navigates to the vendor view. It never saves or changes consent. StackPatrol has dedicated extraction adapters for Sourcepoint and Cookiebot vendor views, plus structured vendor/provider views exposed by OneTrust and Cookie Information installations. When an installation exposes categories but no configured vendor names, the inspection remains incomplete and contributes no matches. Vendor names are extracted deterministically; AI may only choose a numbered visible navigation control when deterministic labels fail. The report retains the sanitized source URL, inspection time, configured names and a SHA-256 fingerprint. A CMP entry is technical disclosure evidence, not proof that the legal disclosure is sufficient.
Provider or parent matches are qualified evidence and never count as exact disclosure. They come from explicit catalogue aliases rather than automatic inheritance from a corporate parent. Short or ambiguous names (“Segment”, “Forms”) and shared infrastructure domains (amazonaws.com, googleapis.com) are ignored to reduce false matches. Linked sub-processor registers and inaccessible consent-manager views can still be missed, so “no match found” means “worth checking”, never proof of non-disclosure. Free scans show the policy-based count; paid reports show the combined named evidence when CMP inspection succeeds.
If auto-discovery misses a document, you can pin exact policy URLs per monitored site and we track those instead.
Varighetssjekk av cookiedeklarasjon
When a readable cookie policy contains a structured table, we can compare an exact cookie name with a persistent cookie observed by the browser. We report a possible mismatch only when the observed lifetime clearly exceeds one unambiguous numeric declaration: more than 25% beyond the declared duration, plus one day. Session cookies, missing expiry evidence, ambiguous declarations and free-form policy prose are skipped.
The comparison covers names and durations only. It does not infer whether a stated purpose, provider or legal basis is correct. A name such as consentUUID is safe to show because it is the cookie’s label; the UUID value itself is never retained or displayed. A duration mismatch is a technical prompt to compare the cookie configuration and policy, not a legal finding.
Reject-all verdict (Consent Assurance)
Disclosure asks what a policy names; the Reject-all test observes what happens after a restrictive control is activated. On paid plans we open the site in a fresh browser context, activate a “Reject all” or “Only necessary” control, then revisit the entry page plus up to four baseline subpages and record third-party requests seen after control activation. The clicker mirrors the Accept-all automation but is biased toward the most restrictive explicit choice and never selects Accept or a generic Save control.
We only count genuinely non-essential trackers against the banner: advertising, analytics, product analytics, session replay, A/B testing, customer-data platforms, marketing automation, email marketing, affiliate and social embeds. Functional, infrastructure and tag-management services are deliberately excluded so a green or red verdict stays defensible. A tracker that fired on the very first load, before the visitor could reject, is not counted here. That belongs to the “loaded before consent” finding. Only requests observed after the reject click count as a violation.
The report separates four things that should not be conflated: whether a control was found, whether the UI interaction completed, whether stored CMP or TCF state changed, and what network traffic followed. A completed interaction does not by itself prove a valid rejection state. The test may report no banner, an unconfirmed control, a technical scan error, or a completed interaction with either quiet or continued non-essential traffic. Incomplete states are never presented as a pass or fail.
Only requests observed after the evidence boundary count in this test. Continued traffic is a network observation to review, not proof that a service ignored a legally valid rejection. Likewise, quiet traffic shows what this automated run observed; it does not certify the banner or the site as compliant.
8. Hva vi ikke gjør
- Vi avgjør ikke GDPR- eller DSA-etterlevelse.
- Vi klikker ikke samtykkebannere i gratis skann (betalte planer kjører automatisk post-consent-pass).
- Vi crawler ikke hele nettstedet som standard (kun forside på Free, opptil 5 sider på Pro og Agency Starter, opptil 20 på Agency og Agency Pro).
- Vi logger ikke inn i autentiserte områder og fyller ikke ut skjema.
- Vi lagrer ikke IP-adresser i klartekst. De salt-hashes daglig.
- Vi beholder ikke rå cookiewerdier, rå localStorage- eller sessionStorage-verdier, eller rå TC-strenger i rapportbevis.
9. Begrensninger
Geografisk skjevhet spiller også inn: enkelte leverandører serverer ulike skript avhengig av besøkerens land. Vi skanner for tiden fra europeisk IP, så resultatene er en tilnærming av hva europeiske besøkende ser.
Metodikken utvikles etter hvert som vi forbedrer dekningen. Hvis du finner en feil klassifisering, gi oss gjerne beskjed.