Privacy scanner and drift
What the website scanner observes and cannot judge, how findings map to obligations, how scans are compared over time, and how register drift is detected.
Summary
- The scanner loads each monitored page through three consent phases (no interaction, after reject, after accept) plus an optional Global Privacy Control phase, then maps what it saw onto the regulations you selected. It reports observable browser behaviour only.
- Monitors are re-scanned daily and on demand, one scan at a time, and two scans are compared only when their execution profiles are compatible.
- Drift is a separate, rule-based engine: it compares the access grants your identity provider reports against the vendor register and the records of processing, and puts every mismatch in the privacy inbox.
Concepts
| Term | Meaning |
|---|---|
| Monitor | A public URL you watch; its hostname must resolve to a public address. |
| Phase | One isolated browser session: no interaction, after reject, after accept, or with the GPC signal set. Nothing carries over between phases. |
| Finding | A technical observation with a severity of critical, warning, or info, and the rule behind it. |
| Jurisdiction status | Per selected regulation: non-compliant, at risk, inconclusive, not tested, manual review, no monitored issue, or not applicable after review. None is a legal determination. |
| Execution profile | The browser build, timeouts, GPC selection, locale, viewport, ruleset version, and egress region a scan ran under; see Scan metadata. |
| Grant | An application's access to personal data, observed by an identity-provider sync; listed under Connected apps. |
How it works
What the scanner observes
| Signal | How |
|---|---|
| Cookies and storage | Cookies are captured per phase and classified against a cookie catalog (category, retention, controller); unclassified cookies become manual-review evidence. Storage keys are recorded, values discarded. |
| Trackers | Hosts classified as analytics, advertising, social, fingerprinting, pixel, or CDN, plus pixel and beacon heuristics. Cookieless analytics count as consent-exempt. |
| Consent banner | Looked for in the page, its frames, and open shadow roots, with the consent platform and IAB TCF state recorded where present. A reject or accept phase requires one unambiguous control, a verified click, and an observed outcome; an ambiguous banner fails closed without clicking. |
| Policy links | Privacy, cookie, terms, and "do not sell" links on the tested route, checked for reachability and read by static extraction only. |
| Transport | HTTPS, HSTS, and insecure cookie flags. |
The Technical risk score has four dimensions: Consent-control signals, Cookie behaviour, Easy refusal, and Transparency. Grades run A at 90 or above, B at 75, C at 60, D at 45, and E and F below. The score is global and technical; selecting fewer regulations never changes it.
Mapping to obligations
Findings are mapped onto the regulations chosen under Privacy settings; an empty selection produces no jurisdiction assessments. One structural rule is built in: storing or reading from the visitor's device is an ePrivacy and PECR question, not a GDPR one alone. Purpose, operator role, exemptions, and applicability need reviewed evidence, so a regulation stays inconclusive until it exists. The GPC phase runs only when a selected regulation recognises a universal opt-out signal, and its legal conclusion is always "not determined": fewer hosts under GPC is evidence, not proof the signal was honoured.
Explicit limits
The scanner cannot assess lawful basis, retention, or a notice's adequacy. It sees one route, one persona, one region, and only what is public: no authenticated pages, mobile apps, server-side transfers, WebSocket or WebRTC traffic, closed shadow roots, or multi-layer settings flows. "No monitored issue" is not a compliance determination.
Execution
- Before every scan the hostname is resolved and checked against a public-network guard. A private or unresolvable host never scans; the reason is written on the scan.
- One run at a time, in isolation. A second request while a scan runs reports it as in progress, a late result from a superseded run is discarded, and the browser runs in a sandbox with no access to your organization's data.
- Ambiguous policy links may be resolved by an AI step that sees only the link text and its surroundings.
Disposition and comparison
A completed scan is assessed only if the page loaded, the result is complete, the score and legal context are valid, and the execution profile is one Noru manages. Anything else is unassessed: never graded, never compared.
Assessed scans are grouped into compatibility segments. When any tracked dimension of the profile changes, the next scan starts a new segment instead of being compared with the previous one; the sparkline on the monitor page covers one segment. Within a segment a finding moves from new to open to resolved, each step confirmed by a repeat scan, and each scan labels it new, unchanged, changed, reappeared, or missing. One absence is never a fix.
Vendor reconciliation
Observed tracker hosts are matched to the vendor register by the registrable domain of the vendor's website, then by normalised name, and the scan raises Not in the vendor register, No DPA recorded, Recipient outside the EEA, Stores data outside the EEA, No transfer recorded, or Loaded before consent.
Data map enrichment
After a data map is pushed, an AI pass drafts, for each activity missing them, a lawful basis with reasoning, a purpose narrative, retention rules, transfers, and an assessment recommendation; below a confidence floor the draft is empty. Drafts arrive as AI drafts in the inbox and never touch the record until someone accepts them field by field.
Drift findings
Grants come from identity-provider syncs with a severity derived from the personal data their scopes reach; a grant is dormant after 90 days without use. Four rules run over grants, the register, and the records of processing:
| Rule | Condition | Severity |
|---|---|---|
| Not in the vendor register | A high or critical grant with no vendor record | The grant's severity |
| On no record | A high or critical grant with a vendor but on no record of processing | High if the grant is critical, else medium |
| Access withdrawn | A record lists a recipient whose grant is revoked | Medium |
| Registered but unused | A registered vendor whose grant is dormant | Low |
A finding stays open until it closes on its own, is marked known, or is marked not an issue with a reason; a decided finding cannot be decided again. Findings appear in the inbox as Register drift.
Edge cases and failure modes
- Incomplete loads produce no score. A blank page, bot challenge, or consent wall is a failed scan, not a clean result.
- A changed profile is not a regression. After a browser or ruleset upgrade the next scan is a new baseline, and its "new" findings are first observations.
- Regional variance is real. Geo-targeted banners can show the scanner a different page from the one your customers see.
- Drift only knows what connectors report. A processor no identity provider sees cannot drift.
What you can influence
- The selected regulations, which decide jurisdiction output and whether GPC runs.
- Which URLs are monitored and when you request a re-scan.
- Vendor website, DPA, and data-location fields, which drive reconciliation.
- Deciding drift findings, marking applications out of scope, and accepting enrichment drafts.
Related guides
- Privacy monitoring
- Records of processing
- Privacy inbox
- Connected apps
- MCP server for pushing a data map
Last updated on
Vendor risk and questionnaire AI
What triggers a vendor risk assessment, how public security documents are gathered, how the risk level is derived, and how questionnaire answers and reviews are drafted by AI.
AI and Cortex
Where AI is used in Noru, how customer data is handled, how Cortex tools are gated by role, and how AI output is marked so it is never mistaken for a decision.