Coder Legion - Recent posts tagged gdpr

GDPR Compliance for Your Online Store: A Practical Guide for New Business Owners

Sun, 12 Jul 2026 12:15:34 +0000

If you run an online store and even one customer outside your home country can buy from you, someone has probably asked you: "Is your store GDPR compliant?" For most new store owners, the honest answer is "I'm not sure." This guide breaks down what GDPR actually requires for an online store, in plain language, and what it realistically costs to get right.

Yes, if your store sells to, ships to, or even markets toward customers in the European Union or UK — regardless of where your business itself is registered. GDPR applies based on who your customers are, not where your server or company sits. A US-based WooCommerce store with a handful of German or French customers is just as much in scope as a Berlin-based shop.

Quick check: if your store accepts orders from EU/UK addresses, runs Google Analytics or Meta Pixel without a consent banner, or collects email signups from European visitors — GDPR already applies to you today.

Strip away the legal language, and GDPR compliance for a typical store comes down to five practical pieces.

1. A Real, Specific Privacy Policy

Not a generic template copied from another site. It needs to state plainly what data you collect (name, email, address, payment details, browsing behavior), why you collect each type, how long you keep it, and which third-party tools (payment gateway, email marketing, analytics) you share it with.

This is the single most common compliance gap. Under GDPR, non-essential cookies — analytics, advertising, retargeting pixels — cannot fire until the visitor actively consents. Loading Google Analytics or Facebook Pixel on page load, before any consent banner interaction, is a direct violation.

3. A Lawful Basis for Every Type of Data You Collect

Order processing and shipping data are covered under "contractual necessity" — no separate consent needed. Marketing emails and analytics tracking need explicit, opt-in consent — a pre-ticked checkbox does not count.

4. Honoring Customer Data Rights

Customers can ask to see what data you hold on them, correct it, or have it deleted. You need a simple process — even just a dedicated contact email — to handle these requests within 30 days.

5. A Breach Response Plan

If customer data is ever exposed in a hack, GDPR requires notifying the relevant authority within 72 hours of discovering it. Having even a one-page internal plan for this ahead of time makes a real difference if it ever happens.

If your store runs on WooCommerce, most of the technical groundwork is achievable without custom development:

Cookie consent: A properly configured consent management plugin that blocks analytics/ad scripts until consent is given — not just a banner that displays without actually blocking scripts.
Checkout data: Review exactly which fields your checkout collects. Extra fields (like unnecessary birthdate or phone number requirements) should be removed or clearly justified.
Google Analytics 4: Configure Consent Mode so GA4 only processes data after consent, with IP anonymization enabled and a sensible data retention window set.
Payment and hosting providers: Confirm your payment gateway and hosting company have signed Data Processing Agreements available — most major providers (Stripe, WooCommerce Payments, PayPal) publish these already.

This is the part most guides skip. Realistic ranges for a small-to-mid store:

DIY with a plugin (cookie banner plugin + template privacy policy generator): $0–$150
Developer-configured setup (proper consent-mode integration, custom privacy policy, checkout field audit, GA4 configuration): $300–$900
Full compliance audit + implementation (data mapping, DPA review, breach response plan, multi-region cookie rules): $900–$2,500+

Why DIY often falls short: most free cookie-consent plugins display a banner but don't actually block tracking scripts until consent is given — which is the actual legal requirement, not just showing a popup. This gap is one of the most common (and easily fined) mistakes small stores make.

Frequently Asked Questions

Does GDPR apply to my store if I'm not based in Europe?
Yes. GDPR applies based on your customers' location, not your business's location. If EU or UK residents can buy from your store, GDPR applies regardless of where you're registered.

Can I just copy a GDPR privacy policy template?
A template is a starting point, not a finished policy. It must accurately reflect your actual data practices — which third-party tools you use, what you collect, and how long you retain it.

Do I need a cookie banner if I only use essential cookies?
No. Strictly necessary cookies (like the ones that keep a shopping cart working) don't require consent. Analytics, advertising, and personalization cookies do.

What happens if my store isn't compliant?
Enforcement for small stores rarely starts with maximum fines. It typically begins with a customer complaint or regulator inquiry, so fixing gaps proactively is far cheaper than fixing them under investigation.

Need help auditing or fixing your store's GDPR setup? I build and harden WooCommerce and WordPress stores for US, UK, and EU businesses. Get in touch here.

Originally published at amanurrahman.com

Why Cookie Consent is Broken on Most UK Business Websites (And How to Fix It)

Tue, 16 Jun 2026 07:41:09 +0000

If you build websites for clients, or you run your own business website,
cookie consent is probably something you have thought about at some point.
You added a banner, moved on, and assumed you were covered.

There is a good chance you are not. And it is not your fault - the way most
cookie banners are implemented makes them look compliant while not actually
being compliant.

I have been building ClearlyCompliant, a free GDPR compliance checker for UK
businesses, and cookie consent is the issue I see failing most consistently
across the sites I scan.

Here is what is actually going wrong and how to fix it.

Quick background on the rules

In the UK, cookie consent is governed by two pieces of legislation: UK GDPR
and PECR (Privacy and Electronic Communications Regulations). The key rule is
simple in theory.

If your site uses cookies that are not strictly necessary for it to function,
you need to get consent before you set them.

Strictly necessary means things like session cookies, shopping basket cookies,
login cookies. It does not mean Google Analytics. It does not mean Facebook
Pixel. It does not mean any third party tracking or marketing script.

For those, you need consent first.

Why most banners do not actually work

The most common failure is a timing issue.

A typical WordPress site might have Google Analytics loaded in the header via
a plugin or hardcoded script tag. The page loads, GA fires, cookies are set.
Then, a fraction of a second later, the cookie consent banner appears.

The banner is asking for consent for something that has already happened.
That is not how consent works.

For a banner to be compliant it needs to load before any non-essential scripts
and it needs to actively block those scripts from firing until the user has
made a choice.

What a compliant setup looks like in practice

A properly implemented consent setup works like this:

Page loads
Consent management script initialises and checks for existing consent
If no consent exists, the banner is shown and all non-essential scripts
are blocked
User makes a choice
If accepted, the relevant scripts are loaded and cookies are set
Choice is stored so the banner does not reappear on every page

Most consent management platforms can do this. The problem is they need to
be set up correctly, which means your analytics and tracking scripts cannot
just be hardcoded into the page head. They need to be loaded conditionally
based on what the user has consented to.

The other common mistakes

Beyond the timing issue, here are the other things I see failing regularly:

No decline option. A banner with only an "Accept" button is not compliant.
Users must be able to decline non-essential cookies just as easily as they
can accept them.

Pre-ticked options. Defaulting analytics to "on" and requiring users to
untick it is not valid consent under UK law.

No way to update preferences. Users need to be able to change their mind
after the initial choice. Most sites have no mechanism for this at all.

Cookie policy missing or vague. You need a cookie policy that lists what
cookies you use, why, and who sets them. "We use cookies to improve your
experience" is not sufficient.

A quick checklist for your own sites

Before shipping any site, it is worth running through these:

Is the consent banner loading before any non-essential scripts?
Is there a genuine accept and decline option?
Are analytics and tracking scripts blocked until consent is given?
Is there a link to a proper cookie policy?
Can users update their preferences after the initial choice?
Is consent being recorded somewhere?

If the answer to any of those is no, the site has a compliance gap.

How to check quickly

If you want to run a quick check on a site you have built or your own business
website, I built ClearlyCompliant to do exactly this. It is free, it scans the
live site rather than asking you to fill in a questionnaire, and it gives you
a breakdown across 23 GDPR compliance checks including cookie consent.

You can run it at clearlycompliant.co.uk - takes a couple of minutes and the
results are instant.

Cookie consent is genuinely one of those things that is easy to get right once
you understand what the standard actually is. The frustrating part is that most
implementations make it look right while getting it wrong under the hood.

GDPR Compliance Checklist for Web Developers in 2026

Sat, 06 Jun 2026 13:15:03 +0000

You've built the app. You've written the privacy policy. You've added a cookie banner. Job done, right?
Not quite. GDPR compliance isn't a single checkbox — it's a spread of technical, legal, and operational requirements that touch almost every layer of a web project. Fines for non-compliance can reach €20 million or 4% of global annual turnover, whichever is higher. And yes, small sites get caught too.
This checklist covers the areas developers are most commonly responsible for — or at least need to flag to their clients before handoff.

Lawful Basis for Processing Data
Before you collect a single byte of personal data, you need a lawful basis under Article 6 of GDPR. The six lawful bases are:

Consent — the user has actively agreed
Contract — processing is necessary to fulfil a contract with the user
Legal obligation — you're required to process the data by law
Vital interests — processing is necessary to protect someone's life
Public task — you're carrying out a task in the public interest
Legitimate interests — you have a genuine, proportionate reason to process

Most web apps rely on consent or contract. The mistake developers make is assuming consent is implied. It isn't. Consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes don't count.
Check: Have you identified and documented the lawful basis for every type of personal data your site processes?

Cookie Consent
Cookies that are not strictly necessary require explicit, opt-in consent before they fire. This includes:

Analytics cookies (Google Analytics, Plausible, Fathom)
Marketing/retargeting pixels (Meta Pixel, Google Ads)
Session recording tools (Hotjar, FullStory)
A/B testing tools (Optimizely, VWO)

A compliant cookie banner must:

Present options clearly, without dark patterns
Make declining as easy as accepting (no grey-out on the reject button)
Not pre-select any non-essential categories
Allow users to withdraw consent at any time
Not block access to the site if the user declines

Check: Are all non-essential scripts blocked until consent is given? Inspect your network tab on first load with a clean session — anything firing before consent is a violation.

Who you are and how to contact you (and your DPO if applicable)
What personal data you collect and why
The lawful basis for each type of processing
How long you retain data
Who you share data with (third-party processors, sub-processors)
Users' rights under GDPR (access, rectification, erasure, portability, objection)
Whether you transfer data outside the UK/EEA, and the safeguards in place
How users can make a complaint to the ICO (or relevant supervisory authority)

Check: Is the privacy policy linked from every page that collects data (forms, checkout, sign-up)? Is it accessible before the user submits any personal information?

Data Minimisation
GDPR's data minimisation principle (Article 5) requires that you only collect what you actually need. This is somewhere developers can make a real difference at the design stage.
Common violations:

Contact forms asking for phone numbers that are never used
Sign-up forms requiring date of birth for no functional reason
Server logs retaining full IP addresses indefinitely
Analytics collecting more granular data than necessary

Check: Go through every form and data collection point on the site. For each field, ask: do we actually need this to deliver the service? If not, remove it.

Data Retention
Storing data indefinitely is a GDPR violation. You need a retention policy that defines how long each category of data is kept, and a mechanism to delete or anonymise it after that period.
Common areas to address:

User account data — what happens when an account is deleted or inactive?
Order/transaction records — often kept for tax/legal reasons, but there's still a limit
Contact form submissions — usually no reason to keep these beyond a few months
Server and application logs — consider truncating or anonymising IP addresses
Email marketing lists — unsubscribers should be purged or suppressed

Check: Do you have automated deletion or anonymisation in place, or are you relying on manual processes? Manual processes tend not to happen.

User Rights
GDPR grants users several rights that your application needs to support. Depending on your scale and tooling, some of these can be handled manually, but the process needs to exist and you need to be able to respond within 30 days.
Right of access (SAR) — Users can request a copy of all data you hold about them. You need to be able to export this.
Right to erasure — The "right to be forgotten." You must be able to delete a user's data from your systems, including backups (within reason) and any third-party processors you've passed data to.
Right to rectification — Users can ask you to correct inaccurate data.
Right to portability — Users can request their data in a machine-readable format (e.g. JSON or CSV).
Right to object — Users can object to certain types of processing, particularly direct marketing.
Check: How would you currently handle a subject access request? Do you know every place a user's data lives (database, email platform, analytics, CRM, support tool)?
Third-Party Processors
Every third-party tool you integrate with that handles personal data on your behalf is a data processor. Under GDPR, you must have a Data Processing Agreement (DPA) in place with each of them.
Most reputable SaaS providers have a DPA you can sign or accept online (Stripe, Mailchimp, AWS, Google, etc.). You also need to list them in your privacy policy.
If any of these processors are based outside the UK or EEA, you need appropriate safeguards for the transfer — usually Standard Contractual Clauses (SCCs).
Check: Make a list of every third-party tool that touches personal data. Have you signed their DPA? Are they in your privacy policy?
Forms and Data Collection Points
Every form that collects personal data needs:

A clear explanation of what the data will be used for (at the point of collection, not buried in a privacy policy)
A link to your privacy policy
Explicit consent where required (e.g. for marketing emails — a pre-ticked opt-in doesn't count)
HTTPS (non-negotiable)

Check: Audit every form on the site. Is there any form collecting data without a clear purpose statement and privacy policy link?

Security Measures
GDPR requires "appropriate technical and organisational measures" to protect personal data (Article 32). For most web applications, this means:

HTTPS everywhere (HSTS is a good addition)
Passwords hashed with a modern algorithm (bcrypt, Argon2) — never stored in plain text
Access controls — does only the right people/systems have access to personal data?
Dependency management — are you keeping libraries up to date? Outdated dependencies are a common breach vector
Database security — is your database exposed to the internet? Are credentials stored securely?
Regular backups, stored securely

Check: When did you last review who has access to your production database and admin panels? Principle of least privilege applies.

Data Breach Response Plan
Under GDPR, if you suffer a personal data breach, you have 72 hours to notify your supervisory authority (the ICO in the UK) if the breach is likely to result in risk to individuals. High-risk breaches also require direct notification to affected users.
This means you need:

A way to detect breaches (monitoring, alerts)
A documented process for assessing severity
Clear ownership of who notifies the ICO
A record of breaches (even those you don't report)

Check: If you discovered a breach today, do you know exactly what to do and who is responsible?

Records of Processing Activities (ROPA)
If your organisation has 250 or more employees, you're required to maintain a formal Record of Processing Activities under Article 30. Below that threshold it's best practice, and the ICO strongly recommends it.
A ROPA documents:

What personal data you process
Why you process it
Who has access to it
Where it's stored (including third-country transfers)
How long you keep it

Check: Even if you're not required to maintain a formal ROPA, do you have enough documentation to answer an ICO enquiry confidently?

Age Verification (if applicable)
If your service is directed at or likely to be used by children, you have additional obligations. In the UK, the Children's Code (Age Appropriate Design Code) sets high standards for services likely to be accessed by under-18s, including defaulting to high privacy settings and not profiling children.
If there's any chance your service reaches minors, this needs specific legal advice — it's one of the more complex areas of UK data law right now.
Check: Is your service likely to be used by under-18s? If so, have you addressed the Children's Code?

Wrapping Up
GDPR compliance isn't something you bolt on at the end of a project — it needs to be considered from the start. The good news is that most of it is straightforward once you know what to look for.
If you're handing off a project to a client or want a quick sense of where a site stands, ClearlyCompliant analyses your site's GDPR compliance and delivers a detailed PDF report covering the key risk areas — useful as a starting point or a sanity check before launch.

Disclaimer: This article is for informational purposes and does not constitute legal advice. For specific legal questions around GDPR compliance, consult a qualified data protection professional.

I built an LLM-powered compliance scanner that points at the actual line of code

Wed, 20 May 2026 13:14:57 +0000

A few weeks ago I went down a rabbit hole. I'd been reading about how every SaaS company eventually has to deal with GDPR / SOC 2 / HIPAA, and how the existing tooling space basically goes like this:

"Do you have a password policy document?"
"Yes."
"Great, you're compliant."

That checks the policy. It doesn't check whether your login route actually stores passwords with MD5. Which felt like… kind of the wrong layer to look at?

So I built Themida — an open-source compliance scanner that reads the actual code.

What it does

Point it at a GitHub repo (or a local directory). It returns findings like this:

src/auth/login.ts:41
CRITICAL  GDPR Art. 5(1)(f), 32(1)(a)
Password hashed with broken MD5
Maximum fine: €20M or 4% of revenue
Fix → bcrypt at cost 12+, or Argon2id

Every finding has:

The exact file and line number
The legal article that the code violates
The maximum fine for context
A code fix you can paste straight into a PR
A severity rating (CRITICAL / HIGH / MEDIUM / LOW)

You can export the whole report as a PDF if you need to share it with someone non-technical.

Why an LLM and not regex?

Honest answer: I tried regex first. It was awful.

Pattern-matching catches the easy cases (crypto.createHash('md5')) but produces a tidal wave of false positives on real codebases. MD5 used to hash a password is a crime. MD5 used as a cache key is fine. A regex can't tell the difference. An LLM can! If you give it enough context and the right prompt.

The scanner runs three passes:

Recon : small/cheap LLM scans the file tree and picks ~15 suspect paths
Deep scan : bigger LLM reads those files line by line and produces findings
Verify : a final pass that drops hallucinated paths and findings already mitigated nearby

Splitting it this way keeps the cost under control. A scan of a medium-sized repo costs around 5–20 cents depending on which models you pick.

Provider-agnostic

You bring your own LLM key. The scanner ships adapters for:

Anthropic (Claude)
OpenAI
Anything that speaks OpenAI's Chat Completions API, OpenRouter, Groq, Together, vLLM, llama.cpp server, Ollama, LiteLLM

Pick one with one env var:

LLM_PROVIDER=openai
OPENAI_API_KEY=sk-...
OPENAI_BASE_URL=https://openrouter.ai/api/v1  # optional, defaults to OpenAI

Self-hosters running a local model are first-class citizens, the cost tracker just records 0 cents and moves on.

What's done, what's not

Done: GDPR (5 rules), EU AI Act (5 rules), full scan pipeline, dashboard, real-time progress, PDF export, GitHub App integration, local CLI path (pnpm dev:scan).

Open issues, PRs welcome: HIPAA, SOC 2, ISO 27001, OWASP Top 10, PCI DSS. Each rule pack is a single TypeScript file with a fairly readable schema, adding rules is the easiest way to contribute.

On the roadmap: Better local-LLM ergonomics, VS Code extension, eval suite for measuring rule accuracy as packs grow.

Try it

git clone https://github.com/Nikolaospet/themida
cd themida
pnpm install
cp .env.example .env.local
# edit .env.local — pick a provider
pnpm dev:scan

There's also a sample report on OWASP NodeGoat you can poke around without setting anything up.

This is a personal project

I want to be upfront about this: Themida isn't a company, it doesn't have funding, there's no "managed version" hiding behind the OSS face. It's a side project I'm building in the open because I find the problem interesting and I think devs are tired of compliance tools that don't read code.

It's released under AGPL-3.0 , use it, modify it, run it for your team, fork it. The license just stops someone wrapping it in a SaaS and closing it back up.

If you try it and something breaks, open an issue. If you want to add a rule pack, an LLM adapter, or improve the eval suite, PRs are warmly welcomed, there's a CONTRIBUTING.md and a PR template ready to go.

The repo is here: github.com/Nikolaospet/themida

If you build software in regulated industries, fintech, health, EU-anything, anywhere with AI Act exposure, I'd love to hear which rule packs would be most useful to ship next. Drop a comment.

Thanks for reading

We Built Automatic GDPR GPS Consent Into Our Field Service App — Here's Why No One Else Does It

Sat, 02 May 2026 12:10:09 +0000

If you build software that tracks employee GPS — even just at clock-in and clock-out — you have a legal problem most companies ignore.

The Problem

Under GDPR Article 13, every employee must sign a privacy notice before you collect their location data. In Germany, the Works Council (Betriebsrat) has co-determination rights under BetrVG §87. In France, the CNIL requires proportionality documentation. In Italy, you need a union agreement or Labour Inspectorate authorization under Article 4 of the Workers' Statute.

Most GPS time-tracking apps handle none of this. They give you the app, you install it on your team's phones, and the legal risk stays with you — the employer.

What We Built

We're GeoTapp, a field service management platform. When we added GPS clock-in to our TimeTracker app, we realized we couldn't just ship the feature and leave compliance to the customer. So we built it into the product:

When an admin invites an employee, the system automatically generates a personalized GPS privacy notice — with the company's name, address, and DPO contact.
The employee receives a link, opens it on any device, reads the full GDPR-compliant notice, and signs with one click. Digital signature with timestamp and IP.
GPS access is blocked until the notice is signed. The employee can install the app and set up their account, but they literally cannot clock in until the privacy consent is on file.
The signed PDF is archived automatically. The admin sees a green badge (signed) or amber badge (pending) next to each employee in the dashboard.
The notice adapts to the employee's language and local regulation. Italian workers see references to the Statuto dei Lavoratori. German workers see BDSG and BetrVG. French workers see CNIL guidelines. English workers see ICO guidance.

Why No One Else Does This

We looked at every major competitor — Connecteam, Clockify, Hubstaff, Jibble, Deputy, BuddyPunch. None of them generate the privacy notice. None of them block GPS access until it's signed. None of them archive the signed document.

They all have some variation of "it is the employer's responsibility to obtain consent" buried in their documentation.

The reason is simple: it's hard to implement correctly across multiple jurisdictions, and most product teams don't have someone who understands both employment law and software architecture. It's easier to punt it to the customer.

The Technical Implementation

For anyone building something similar, here's the high-level architecture:

Public consent page at /privacy-consent?token=ABC123 — no auth required, accessible from any device
Firestore document in companies/{id}/privacy_consents/{id} stores the signed consent with timestamp, IP, user agent, document version and language
PDF generation server-side using the pdf package, uploaded to Firebase Storage
Invite document updated with privacyConsentSigned: true — this is what the app checks before enabling GPS
Feature gate in the employee edit screen prevents admins from manually enabling tracker access if consent is missing

The consent texts are stored as structured data (not free-form strings) so they can be versioned and audited. If the privacy notice text changes, a new version is created and employees can be asked to re-sign.

The Business Case

This isn't just a compliance checkbox. It's a sales argument.

When a potential customer asks "what about GDPR?" — and in Europe, they always ask — most competitors say "that's your responsibility." We say "it's already handled. Your employees can't use GPS until they've signed. Here's the PDF."

That conversation closes deals.

Try It

If you're running a field service business and want to see how this works in practice:

GeoTapp Flow — the management platform
GeoTapp TimeTracker — the mobile app for field workers
Free 14-day trial — no credit card required

We also published a ready-made GPS privacy notice template you can download as PDF — even if you don't use GeoTapp.

Built by a team that got tired of seeing field service companies get fined for a problem their software should have solved.

99.62% of “Bannered” Sites Still Trigger Tracker Signals Pre‑Consent (Runtime Data)

Thu, 30 Apr 2026 08:31:06 +0000

TL;DR: Audited 276 websites and found that 95.65% of them had Cookie Banner (proxy checks) installed and 99.62% of bannered sites have pre-consent third‑party tracker signals still flagged by runtime audit engine.

In other words: banner presence was common, pre‑consent drift was almost universal in this sample.

The takeaway isn’t “banners are useless” It’s: a banner is UI but compliance is behaviour.
If you don’t verify what actually runs and what actually hits the network on a cold visit, you’re trusting configuration screens over browser reality.

Scope: EU/EEA GDPR + ePrivacy (cookies and similar identifiers). Educational, not legal advice.

Most teams treat “banner installed” as the finish line. Engineers and reviewers care about something stricter:

On a cold visit (no prior consent stored), do non‑essential scripts stay inert?
Do non‑essential third‑party requests stay off the network until consent is captured?
A CMP dashboard toggle can say “blocked” while load order, tag manager triggers, or embeds still fire early.

WHAT WE MEASURED (RUNTIME SNAPSHOT)

Dataset and scans were run with SecureSpells - GDPR & ePrivacy–focused runtime browser audit.

Dataset (aggregated only):

Sites scanned: 276
Consent banner detected: 95.65%
Pre-consent third‑party tracker signals flagged: 99.62% (of bannered sites; simplified proxy check)
Critical risk issues flagged: 68.06% (sites with ≥1 critical issue in issue counts)
30‑day regression rate: 3.57% (monitored domains with ≥1 regression event)
Interpretation: banners are common. Observed behaviour still drifts unless you verify it in a browser on a cadence.

Important: “flagged” here means the scan observed behaviour consistent with third‑party tracking/embeds happening pre‑consent under the scan profile. It does not decide lawful basis, jurisdiction, or final legal classification for a specific tag.

Drift usually comes from small changes that bypass the banner’s assumptions:

Tag manager edits (new triggers, containers, templates)
Third‑party embeds added by marketing (video, chat, booking widgets)
CMS/plugin updates introducing new scripts/endpoints
Consent mode configuration drift (signals update, but load order still leaks)
If your process ends at “banner installed,” drift accumulates until a client notices—often via a complaint or a screenshot.

THE WORKFLOW THAT HOLDS UP (AGENCY VERSION)

Treat privacy behaviour like performance regressions: a workflow, not a checkbox.

Baseline on staging (before launch) Run a runtime scan on the entry page under a “no consent yet” profile. Save the output as
evidence.
Gate the usual sources of drift Route marketing tags through a single policy/owner. Keep a written rule like:
No non‑essential third‑party requests before consent (adapt to your legal interpretation).
Re‑scan on change + on cadence After any GTM change, plugin update, or marketing release: re‑scan. Then re‑scan production
weekly/monthly depending on risk.

WHAT TO TELL CLIENTS (LANGUAGE THAT AVOIDS OVERCLAIMS)

“We installed a banner” → “We control and verify tracking behaviour under defined consent states.”
“We’re GDPR compliant” → “Here is runtime evidence for pre‑consent behaviour on the pages we tested; broader compliance still requires legal and operational work.”
“We blocked everything” → “We validated non‑essential third‑party requests don’t occur before consent in the tested profile; we monitor for regressions.”

CONCLUSION

The average state of public websites is, frankly, worryingly sloppy. A cookie banner creates a convincing UI, but it often creates a false sense of compliance when the underlying behavior still leaks: tags fire early, embeds bypass assumptions, and GTM/container edits drift after launch. The big gap isn’t “lack of CMPs” — it’s lack of runtime proof that a cold visit actually stays quiet until consent.

For agencies, this is an opportunity: “compliant websites” can be a real differentiator if you can back it with evidence, not promises. Make runtime scans part of delivery (staging baseline → launch evidence), then sell monitoring as a retainer (re-scan on change + cadence). If you want to reproduce this workflow, SecureSpells is a GDPR & ePrivacy runtime compliance browser audit: https://securespells.com/

READ THE FULL METHODOLOGY + LIMITATIONS

Full post (with methodology, limitations, and the agency workflow):
https://securespells.com/blog/banner-installed-tracking-stopped-runtime-data/

Own Your Consent Layer: Vibe Code, AI, and Runtime Proof With SecureSpells

Wed, 29 Apr 2026 11:45:14 +0000

TL;DR

You can ship a small first-party consent module fast (AI helps). The
part that actually holds up under scrutiny is whether non-essential
requests and scripts stay dead until valid consent in a real
browser. Treat a runtime audit like CI for privacy: red → fix load
order / injectors → re-scan. Skipping a heavy CMP does not mean
skipping proof after every deploy.

Scope: EU/EEA GDPR and ePrivacy (cookies and similar tech on websites). Educational, not legal advice — get counsel for your setup.

Who this is for: you ship or review what loads before consent: index.html and bootstrap order, GTM / container changes, SPA navigations where tags re-run, consent PRs, or infra + security pushes that assume “marketing fixed it in Cookiebot.” The goal below is reproducible proof—cold visit, real browser, same question after every merge—not a greener admin panel.

Commercial CMPs are the right choice for lots of teams. The failure mode for builders is different: the CMP becomes a black box. Marketing edits tags, A/B tests swap snippets, preview ≠ production. Without a runtime check you find out from a complaint, not from your pipeline.

What you want instead is evidence-first consent: “done” means you can point to reproducible proof that non-essential tags did not initialise or send data before consent — not only that a banner rendered.

THE LOOP: CODE → SCAN STAGING → READ FINDINGS → REFACTOR → RE-SCAN

Same rhythm as TDD, except the “test” is a browser execution trace:

In security or platform review, someone will eventually ask “show me Network for a cold visit” — not “screenshot Cookiebot green.” The loop exists so that artifact is repeatable after every deploy:

Freeze the surface — same staging URL, clean profile, same consent variant you ship.
Run a runtime audit — isolated browser; see what fires before accept/reject.
Pick one hypothesis — e.g. “Meta endpoints should not appear before accept.”
Change one thing — usually load order and when GTM / marketing bootstraps run, not cosmetic banner CSS.
Re-scan — until the checks you care about pass; repeat when marketing ships again.

Technically: Default deny (do not load the tag hub until your gate runs) is often easier to reason about than “load GTM and hope it waits internally.”

Lightweight patterns (details and caveats on the blog): keep third-party scripts inert (type="text/plain" until flip), one owner module for consent branches, optional MutationObserver as defence in depth — but the audit is still the referee; observers miss plenty.

WHAT AI IS GOOD FOR (AND WHAT IT IS NOT)

LLMs are great for boilerplate structure, naming, and refactoring if you paste ground truth into the thread: failing network evidence, the exact injector, your consent state machine. If the model is arguing from vibes instead of a trace, you are one deploy away from theatre.

Teams: Consider pasting the anonymised SecureSpells “Technical Details” JSON into the PR when you touch loaders or CMP config—same idea as a failing test log attached to CI. That gives reviewers the same artifact ChatGPT sees and stops “looks fine locally” merges.

THE BORING PARTS YOU STILL OWN

A custom gate can be more inspectable than a hosted script — if you close gaps: consent logging (Art. 7 is not satisfied by localStorage alone), withdrawal UX, granularity that maps to real load branches, geo / TCF if you play in ads, vendor registry if you dropped the CMP crawler, transfers (Chapter V) even when execution looks clean.

Full honest checklist + comparison dimensions + LLM paste bundles:
Own your consent layer — test-driven privacy (full article)

LIMITED LAUNCH (SECURESPELLS)

We’re running a small launch window: first 30 Stripe checkout redemptions get Pro with full audits at €29 for the first month (then renews at list price — always confirm in Stripe, incl. VAT). That tier includes ongoing monitoring plus the runtime evidence story above — i.e. not “a cheaper banner,” but verification + regression signal after you ship.

Start here: https://securespells.com/

If the offer is exhausted or past the campaign end date, the page should reflect that — don’t rely on this article alone.