TL;DR:
ISO 27001 may be risk-based, but pre-consent tracking is binary - if your site loads non-essential third parties before consent, you’re simply non-compliant, and because that’s externally visible and repeatable it can undermine your ISMS, so real compliance in 2025 means enforcing consent-before-access in code, keeping it first-party, scanning continuously, and fixing findings before an auditor sees them.
Too many organizations still treat ISO/IEC 27001 like a force field: “we have our ISMS, we passed the audit, so we’re covered.” That illusion breaks the moment someone can technically document that your public website is loading third parties, setting non-essential cookies, or transmitting identifiers to vendors before you have a valid legal basis.
That’s the uncomfortable truth: ISO 27001 is risk-based, but ePrivacy/GDPR device access is binary. And when you have a binary failure that is reproducible, visible from the outside, and contradicts your stated controls, it stops being “just marketing tech” and starts being a potential nonconformity.
This is the gap we need to close.
Binary vs. Risk-Based Compliance
ISO 27001 lives in a world of risk appetite, likelihood, impact, and corrective actions. You can accept certain risks, defer others, and show auditors you have a plan.
ePrivacy Directive 5(3) does not live in that world.
If your site accesses or stores information on a user’s device for non-essential purposes before consent, you’re non-compliant. Not “partially,” not “until next sprint,” not “accepted by management.” It’s simply a violation.
So when a website:
- fires a marketing pixel too early,
- lets a CMP vendor phone home for geo/billing before consent,
- loads GTM and lets tags run regardless of the user choice,
…that’s a binary fail. You can’t paperwork your way around it.
Why That Matters for ISO 27001
“Okay, but ISO 27001 is about information security, not cookie banners.”
Yes - but 27001:2022 is also about whether your ISMS actually works.
If your policies say “consent before tracking,” and your implementation says “we block,” but a simple scan shows your production site doing the opposite, what you have is a control that is not operating as designed.
Auditors don’t need to become data protection authorities to see that. They only need to see:
- You defined a control (no non-essential device access pre-consent),
- Evidence shows the control not working (third-party calls before consent),
- It’s repeatable and has not been corrected.
That’s enough to trigger findings. And if the pattern is systemic across multiple sites/brands or ignored over time, it can put pressure on your certification.
“If your policy says ‘consent before tracking’ but the site doesn’t, the control is not operating as designed.”
How This Gets Exposed
The scary part is how easy it is to prove.
Anyone - a regulator, a customer doing due diligence, or even a competitor - can:
- Load your homepage in a clean browser.
- Capture network traffic before any consent choice.
- List all third-party endpoints, pixels, SDKs, beacons, and cookies.
- Compare with what your privacy notice and CMP claim.
If what your site does and what your policies say don’t align, the technical reality wins.
Once it’s documented and reproducible, it’s no longer “a small marketing misconfiguration.” It’s evidence that your ISMS isn’t monitoring an actual entry point where personal data leaves your control.
“When a scan can repeatedly show third-party loads pre-consent, it’s no longer a misconfiguration - it’s a systemic failure.”
The Usual Culprits
Most organizations don’t fail on purpose - they fail because the web stack is messy. The patterns repeat:
- CMPs that do their own non-essential requests (geo-IP, telemetry, billing, “is banner needed?”) before consent.
- GTM containers that allow tags to fire regardless of consent state.
- Chat/UX/CS tools that inject their own trackers.
- A/B testing or personalization tools that need to load early to “work.”
- Multiple business sites where one is configured correctly and the others are forgotten.
Each of these is enough to flip you from “we claim consent-first” to “we actually don’t.”
And yes - if you can scan it once, you can scan it every day. That makes it very hard to argue it’s a one-off.
You can use our free Privacy Scanner to test your website before consent and see if you have a problem.
“We Did a Risk Assessment” Is Not a Shield
A classic pushback is: “we assessed it, and we accepted the risk.”
That works for information security trade-offs. It does not work for legal prerequisites.
You can’t “risk-accept” unlawful device access just because marketing needed a dashboard. You can’t accept the risk of sending personal data to a third country without a legal basis and expect ISO 27001 to cover it. That’s not residual risk - that’s doing something you’re not allowed to do.
“You can’t risk-accept unlawful device access just because marketing needed a pixel.”
So the only real answer is: fix the technical behavior.
What Real Compliance Looks Like in 2025
Let’s make it operational - this is what a grown-up model looks like:
- Consent-before-access, enforced in code
Non-essential scripts, pixels, beacons, storage, and third-party calls are blocked or queued until the user opts in. Not simulated, not “we set denied,” but actually blocked. - First-party by design
The consent UI and enforcement live on your domain or in your own first-party infrastructure, so you don’t introduce a new third party just to manage consent. - Continuous web-facing scanning
Run automated scans (pre-consent and post-consent) to see what is actually loading. This catches when someone in marketing “just tests something” on Friday. - Closed loop into the ISMS
Findings from those scans go straight into your ISMS as incidents / nonconformities → assigned → remediated → verified. That’s what auditors love to see. - Evidence on demand
When a DPO, CISO, or auditor asks “are we blocking pre-consent?”, you can show a last-scan report - not only a policy document.
This way, your public website becomes part of the monitored surface, not a rogue marketing island that quietly undermines the certification the rest of the company worked for.
The Strategic Point
Why push this now? Because the modern stack - AI embeds, server-side GTM, edge/CDN logic, Measurement Protocol, third-party CMPs that “optimize” - all of that can silently re-introduce technical non-compliance even while your policies and DPIAs are still correct.
If you don’t have continuous visibility, your ISO story can be true on paper and false in production.
“In 2025, production wins: what the site actually loads matters more than what the policy says.”
Turn It Into Evidence
If you’re responsible for ISO 27001, DPO work, or web privacy, do one thing this week:
Run an external, pre-consent scan of your main site and compare it with what your CMP and policies claim.
If it’s clean - perfect. Document it.
If it’s not - don’t argue with it. Treat it like any other nonconformity: log → fix → re-scan → prove.
Do the same the next day, and then the day after again and every day because ISO/IEC 27001:2022 expects continuous performance monitoring of controls, treating web-facing scans as part of that monitoring closes the gap between the ISMS on paper and the behavior of the live site.
That is how we do it in AesirX with continuous privacy monitoring of our websites and web-facing solutions.
ISO 27001 still matters. It just can’t protect you from a browser that shows the truth.
Ronni K. Gothard Christiansen
Technical Privacy Engineer & CEO, AesirX.io
