# GDPR Scanners & Audit Tools, What They Measure and What They Miss > What GDPR scanners and cookie tools measure technically, where their limits are and why they cannot replace a legal review. - Source: https://www.sidd.swiss/en/insights/gdpr-scanners-audit-tools/ - Language: en - Published: 2026-05-24 - Last updated: 2026-05-24 - Author: Oliver Stutz - Publisher: SIDD Institute for Data Protection and Data Security, a brand of Priverion GmbH, Zugerstrasse 32, 6340 Baar (ZG), Switzerland ## Introduction Automated GDPR and DSG scanners promise a lot: they analyse your website, identify cookies and trackers, build cookie banners, generate privacy policies and check third-party calls against a database of known vendors. CookieBot, Usercentrics, OneTrust, iubenda, Termly, Complianz, CCM19 and dozens of others compete in a fast-growing market. For IT leaders and marketers, these tools look like a convenient compliance shortcut, "scan once, activate the banner, done." The legal reality is more nuanced. These scanners deliver valuable **technical inventories**, but they are not a substitute for legal assessment. This article shows: - what scanners measure technically and what they systematically miss; - how reliable the generated cookie classifications are; - which legal questions a scanner simply cannot answer; - where Consent Management Platforms (CMPs) end and where consulting begins; - how to embed scanners sensibly in an audit process; - and which typical misreadings Swiss organisations commit. Legal anchors: Federal Act on Data Protection (DSG, Art. 6, 8, 9, 19, 22), GDPR (Art. 6, 13, 30, 32), ePrivacy Directive (Art. 5(3)), FDPIC cookie guidance (2023), EDPB Guidelines 03/2022 on dark patterns, CJEU C-673/17 (Planet49). ## What scanners measure technically A modern cookie/tracker scanner consists of three modules: 1. **Crawler:** calls a list of your URLs, often with a headless browser (Chromium), and records all HTTP requests, DNS lookups, loaded scripts, set cookies and local-storage entries. 2. **Classifier:** matches the found domains, cookie names and script URLs against a curated database (e.g. Google Analytics → statistics, Meta Pixel → marketing, Stripe cookie → necessary). 3. **Reporter:** generates a dashboard, a cookie table and, with integrated CMPs, an automatically configured cookie banner. What the tools **do well**: - comprehensive audit of third-party scripts; - detection of new or unauthorised trackers that a marketing team embedded without approval; - detection of pre-consent tracking (scripts firing before banner click); - observation of domain hopping (e.g. when a pixel addresses new domains via CDN redirects). This technical inventory is a prerequisite for any legal assessment, without a scan, you operate in the dark. ## Where scanners reach their limits A scanner can technically see what loads, but it **cannot legally assess whether it is permissible**. Specifically, scanners fail to distinguish: - **Legal basis:** is a cookie "strictly necessary" within the meaning of Art. 5(3) ePrivacy or merely "functional"? This classification is legally valuable but in scanner reporting often flagged "based on vendor declaration", not authoritative. - **Context:** a session cookie may be necessary on a login page and functional/optional on a landing page. The contextual knowledge eludes the scanner. - **Cross-border assessment:** the scanner sees "hostname X = US provider". It does not assess whether a DPA, DPF certification, SCCs or a TIA are in place. - **Content categories:** a scanner sees "form submission to /api/contact" but not whether the form gathers health data, financial details or mandate information. - **Contractual landscape:** data processing agreements, sub-processor lists, joint-controller arrangements, none of this is visible. - **Data flows beyond the website:** back-office processing, ERP integrations, email marketing stacks, employee monitoring, all outside the scanner's radar. Reading a scanner report as "GDPR compliance confirmed" misses the 70% the scanner cannot measure. ## Cookie classification, how reliable is it Classifying cookies into categories such as "necessary", "statistics", "marketing" is the core value of commercial scanners. The classification rests on: - vendor-maintained databases (Cookiebot etc.) of thousands of known cookies; - crowd-sourcing from other customer scans; - partly manual classification by vendor analysts. In practice, this is usually accurate for common cookies (Google Analytics, Meta Pixel, Cloudflare). For niche cookies, custom cookies from your CMS or project-specific trackers, the accuracy drops considerably. In audit projects we regularly see: - cookies classified as "necessary" although they only support an optional newsletter widget; - tracking pixels that are missing from the vendor database and not recognised at all or kept as "unknown"; - subdomain cookies wrongly classified as first-party although CDN tricks effectively forward them to third parties. Practical tip: every scanner output needs a four-eyes review by someone who knows your web architecture. "Automatic cookie classification" is an aid, not a legal opinion. ## What the tools cannot answer legally Even the best scanner cannot answer fundamental questions. Here is a selection of typical audit topics that pure tool outputs miss: 1. **Legal basis of processing:** is storing newsletter subscriptions "legitimate interest" or does it require consent? This is a legal judgment. 2. **Proportionality (Art. 6(2) DSG):** is the collected data necessary or excessive? 3. **Purpose limitation:** are CRM data being used surreptitiously for ML training? 4. **Access and erasure duties:** are the data-subject request processes actually functional? 5. **Breach readiness:** can you notify a breach to the FDPIC within 72 hours? 6. **Cross-border compliance:** is a TIA in place for every US or third-country transfer? 7. **Joint-controller topics:** are the arrangements with Meta, Google, LinkedIn as joint controllers documented? 8. **Employee privacy:** what are the rules for employee monitoring, browser history, email archives? All of these topics require substantive engagement with the processing landscape, the task of a data-protection advisor or in-house DPO, not of a tool. ## Consent Management Platforms, where tool value ends Cookiebot, Usercentrics, OneTrust and CCM19 also provide a **Consent Management Platform**: the cookie banner, storage of the consent decision, coupling third-party scripts to consent (consent-loading via tag manager) and the audit log. These CMPs are technically mature, but they do not automatically make a cookie banner GDPR-compliant. Common misconfigurations: - **Pre-selected boxes:** if the banner displays categories with pre-ticked checkboxes, this is no valid consent after CJEU Planet49. - **Unclear "accept" buttons:** "accept" must not be visually privileged over "reject", otherwise it is a dark pattern (EDPB 03/2022). - **Pre-consent scripts:** if scripts fire before the banner click, the entire architecture is invalid. - **CMP cookie itself:** the consent cookie itself must qualify as "necessary", only possible with minimal content and short lifetime. - **Missing audit trails:** you must prove when a specific person consented. Without storing the consent timestamp and the banner version, you cannot meet this burden of proof. A CMP rollout belongs in a consulting engagement, with a clear configuration spec, quarterly review and escalation logic when new scripts appear without configuration. ## Integrating scanners into the audit process We regularly use scanners in our audits, but as the **first stage** of a multi-stage process: 1. **Scan:** full crawls of all property URLs (public + logged-in areas where technically possible). 2. **Triage:** classification of the found cookies and scripts, manually verified, not blindly trusted. 3. **Contract reconciliation:** every detected third-party vendor is matched against the DPA collection. Missing DPAs are requested. 4. **Banner configuration:** the CMP banner is configured, tag-manager scripts are coupled to consent categories, audit-mode testing. 5. **Legal assessment:** the privacy policy is compared against the real scanner output and complemented. 6. **Training:** marketing and web teams are trained on the new process. 7. **Periodic re-scan:** at least quarterly, ad hoc on campaign rollouts. This sequence maximises tool value and compensates its weaknesses with human judgment. ## How SIDD supports you SIDD runs automated scans with established tools and combines them with legal assessment, delivering a full data-protection diagnostic rather than a tool output. Our services: - cookie/tracker audit with a professional scanner; - configuration and audit of CMPs (Cookiebot, Usercentrics, OneTrust, CCM19); - DPIA for high-risk tracking setups; - mandates as external [data-protection advisor](https://www.sidd.swiss/en/services/data-protection-advisor-switzerland) or external [CISO/ISB](https://www.sidd.swiss/en/services/vciso); - GDPR DPO and EU representation ([GDPR DPO](https://www.sidd.swiss/en/services/data-protection-officer-eu), [EU representative](https://www.sidd.swiss/en/services/eu-representative)); - penetration tests and vulnerability scans as complement to the privacy inventory ([penetration testing](https://www.sidd.swiss/en/services/penetration-test), [vulnerability scanning](https://www.sidd.swiss/en/services/vulnerability-scan)); - ISO/IEC 27001 support as framework for ongoing compliance ([ISO 27001 / ISMS](https://www.sidd.swiss/en/services/iso-27001-isms)). Write to us via the [contact form](https://www.sidd.swiss/en/contact) or request a quote via the [quote form](https://www.sidd.swiss/en/quote). We deliver a free cookie scan of your primary domain within two working days. --- This document is the Markdown rendition of the page linked above. Please cite the HTML URL.