NEW YORK, MARCH 13, 2026 - AesirX today announced AesirX ComplianceOne, a self-hosted Governance, Risk and Compliance (GRC) platform designed for organizations operating under Vietnam’s evolving regulations, including the Personal Data Protection Law (PDPL) and its implementing decree, the Data Law, cybersecurity legislation, the AI Law, the Telecommunications Law, and the Law on E-Commerce.
ComplianceOne is built for how Vietnamese banks, telcos, payment institutions, and large enterprises must operate in practice - with standardized dossier expectations, workflow-driven compliance, audit-grade evidence, and cross-border governance that must hold up under scrutiny. It connects web consent to back-end compliance execution so organizations can move from ‘policy compliance’ to ‘operational proof.’’
“Vietnam’s enforcement direction is becoming process-driven and evidence-driven,” said Ronni K. Gothard Christiansen, Technical Privacy Engineer and CEO of AesirX. “ComplianceOne is built for that reality - dossiers, registers, workflows, and audit-grade evidence that can be produced consistently when regulators, procurement, or incidents demand it.”
<h2>Why Now</h2>
Vietnam's regulatory environment has shifted from documentation to demonstrable execution. With the PDPL effective from 2026 and accompanied by implementing rules and standardized administrative procedures, organizations increasingly need to show active compliance programs – structured records, traceable workflows, exportable evidence packs, and rights-request handling that can be measured against timelines.&nbsp;
In parallel, the Data Law expands governance obligations at the system level and increases pressure on cross-border governance discipline.
Spreadsheets and email chains do not scale to this enforcement reality, especially when incidents occur, vendors change, cross-border flows evolve, or authorities request evidence in specific formats.
<h2>What ComplianceOne Is</h2>
ComplianceOne is a self-hosted GRC (governance, risk, and compliance) platform - built for Vietnam and deployed inside the customer’s own infrastructure so data remains within the organization’s control.
Key capabilities include:
<ul>
<li aria-level="1">Rights Requests (DSR/DSAR) case management with structured workflows, SLA tracking, identity checks, evidence collection, and exportable response packs.</li>
<li aria-level="1">Data Mapping and RoPA inventory of systems, data categories, purposes, retention, and data flows with cross-border indicators.</li>
<li aria-level="1">DPIA and Assessments with scoring, mitigation tracking, approvals, and dossier exports.</li>
<li aria-level="1">Vendor Governance with sub-processor tracking, cross-border documentation, drift detection, and deletion playbooks.</li>
<li aria-level="1">Consent Governance with version-controlled policies, CMP integration, and drift detection between approved policy and deployed runtime.</li>
<li aria-level="1">Incident Response intake, triage, severity scoring, timelines, and evidence packs prepared for submission.</li>
<li aria-level="1">Audit Trail with timestamped actor logs for sensitive operations, including view, export, approve, and delete events.</li>
</ul>
Modules operate as one connected system with a unified task engine, shared audit trail, and compliance program dashboard.
<h2>Proof by Design</h2>
ComplianceOne generates audit logs for sensitive actions and supports role-based access controls and separation of duties. Sensitive fields can be masked and revealed only through controlled exception paths. For high-assurance environments, optional cryptographic anchoring is available to strengthen integrity guarantees for exported evidence packs.
The result: when a regulator asks for evidence, or an enterprise RFP requires traceable workflows, organizations can export a structured dossier rather than assembling ad hoc document folders.
<h2>Availability</h2>
ComplianceOne is available now. A live demo environment is accessible for evaluation , and AesirX will release updated landing pages and three ready-to-deploy packages this Friday as part of its official market rollout.
Vietnam contact:
Tu Pham, Country Manager - <a href="mailto:tu@aesirx.io">tu@aesirx.io</a> | +84 918 098 010
To learn more, visit: <a href="https://aesirx.io/compliance-one" target="_blank" rel="noopener">https://aesirx.io/compliance-one</a>&nbsp;
<h2>About AesirX</h2>
AesirX builds privacy-first, self-hosted compliance infrastructure for regulated organizations. Its platforms are designed to help enterprises run governance workflows, produce audit-grade evidence, and maintain data sovereignty across complex vendor and cross-border environments.
<h2>References</h2>
<ul>
<li aria-level="1">PDPL Law No. 91/2025/QH15 effective 01/01/2026</li>
<li aria-level="1">Decree 356/2025/ND-CP effective 01/01/2026</li>
<li aria-level="1">Decision 778/QĐ-BCA-A05 dated 09/02/2026 (admin procedures)</li>
<li aria-level="1">Data Law No. 60/2024/QH15 effective 01/07/2025</li>
<li aria-level="1">AI Law No. 134/2025/QH15 effective 01/03/2026</li>
<li aria-level="1">E-Commerce Law No. 122/2025/QH15 effective 01/07/2026</li>
<li aria-level="1">Cybersecurity Law No. 116/2025/QH15 effective 01/07/2026</li>
</ul>
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/images/Benefits_of_Using_Aesirx_ComplianceOne.png" alt="Benefits of Using Aesirx ComplianceOne" width="942" height="563" />

AesirX Launches ComplianceOne, a Self-Hosted GRC Platform Built for Vietnam’s Regulatory Reality

Blog Press Release Aesirx

AesirX ComplianceOne is Vietnam's first purpose-built compliance platform for banks, telcos, and enterprises. Self-hosted, audit-ready, legally aligned.

AesirX Launches ComplianceOne

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR:&nbsp;Vietnam’s compliance stack is expanding beyond privacy and data governance into two domains that will increasingly define digital operations in 2026:
<ul>
<li aria-level="1">The AI Law (effective 01 March 2026) pushes businesses from "we use AI" to "we can prove it is governed" - classification, transparency, labeling where relevant, and incident readiness.</li>
<li aria-level="1">The E-Commerce Law (Law No. 122/2025/QH15) pushes platforms from "we sell online" to "we can prove the platform is controlled" - seller verification, takedowns, dispute handling, ranking accountability, and evidence-ready order flows.</li>
<li aria-level="1">The Cybersecurity Law overlay (effective 01 July 2026) will increasingly determine architecture constraints - where data sits, how monitoring is implemented, and how fast you can respond to authority requests. Draft guidance is still a watchlist, but the capability-building cannot wait.</li>
</ul>
</div>
This article walks through the next layer of the Vietnamese legal stack and is written for DPOs, legal and compliance teams, CISOs, and digital leaders operating in Vietnam - especially in banking, telecom, payments, e-commerce platforms, AI-driven product teams, and large enterprises with cross-border services. If you are responsible for governing AI systems in production, managing seller and platform enforcement workflows, producing dossier-ready evidence, or keeping vendor and data-flow governance audit-ready under scrutiny, this is written for you.
<h2>AI Law + E-Commerce Law + the Cybersecurity overlay</h2>
The same pattern from Part I now applies across AI and platforms: Most organizations can write a policy. Fewer can run the workflows. Very few can produce the correct dossier formats quickly, consistently, and with audit-grade evidence.
<h2>Callback to Part I - read Chapters 1-5 first</h2>
<a href="https://aesirx.io/blog/aesirx/market-focus-regulatory-compliance-vietnam" target="_blank" rel="noopener">Part I covers the first five chapters of Vietnam’s regulatory stack</a> and why enforcement is becoming procedure-driven and evidence-driven:
<ol>
<li aria-level="1">Personal Data Protection (PDPL 2025 and implementation)</li>
<li aria-level="1">Standardized administrative procedures and dossier lifecycle</li>
<li aria-level="1">The Data Law and system-level governance</li>
<li aria-level="1">Telecom overlays shaping real-world obligations</li>
<li aria-level="1">The Cybersecurity trajectory and why drafts must be treated as a watchlist</li>
</ol>
If those five chapters describe the compliance foundation, Part II is where the stack starts to shape product design, platform operations, and system architecture in practice.
Part II continues from Chapter 6.
“Vietnam compliance is no longer document compliance - it is execution compliance.”
<h2>The Vietnamese regulatory stack (continued)</h2>
<h3>6. The Vietnam AI Law (effective 01 March 2026)</h3>
<h4>AI compliance is not an AI policy - it is a risk governance system</h4>
Most companies still think AI compliance means adding a disclaimer, a policy paragraph, or a checkbox in procurement. That logic does not survive once AI is treated as a regulated risk domain.
AI creates a new type of compliance exposure: systems that influence outcomes at scale. Ranking, recommendations, fraud scoring, eligibility signals, customer service decisions, dynamic pricing, identity signals, content generation - these are not "features" anymore. They are operational risk surfaces.
“If AI influences outcomes, it is already a regulated capability - whether you call it AI or not.”
What matters in Vietnam is not abstract AI ethics. It is what the implementing framework is signaling: classification, transparency, controllable safeguards, and the ability to produce evidence when asked. In practice, enforcement will not debate your model architecture - it will test whether you can demonstrate governance in the format and workflow reality Vietnam is standardizing.
<h4>The pivot: classification comes before everything</h4>
In a risk-based AI regime, classification becomes the first mandatory discipline. Not the model name. Not the vendor. The deployment context.
The same model can be low risk in one use case and high risk in another. That means classification must be repeatable and auditable. It cannot live in product team memory. It must live in a system.
In practice, that means you need an AI register that answers, consistently and defensibly:
What AI systems exist in production? Who owns them? Where are they used in the product? Which users or groups are affected? What data feeds them? What harms are plausible? What oversight exists? What evidence exists?
<h4>What AI compliance looks like in production</h4>
AI compliance only becomes real when it is operationalized into a governance spine.
Start with a living AI System Register. This is the AI equivalent of a processing register - not a document, but a continuously updated inventory of deployed AI capabilities, their purposes, their data dependencies, their ownership, and their change history.
Then define pre-deployment gates for systems that can create meaningful harm. The moment AI impacts eligibility, access, safety, financial outcomes, or rights, the deployment process needs controls: internal review, documented safeguards, monitoring readiness, and rollback capability.
“The compliance question is not 'do you use AI?' - it is 'can you prove you control it?”
Transparency becomes a deliverable, not a slogan. You do not need to publish your model. You need to be able to produce the right level of explanation for the system’s purpose, limitations, expected oversight, and what users are told.
If your product generates or modifies content, labeling and provenance controls become part of compliance. Not because regulators care about aesthetics, but because integrity, traceability, and evidence are now central to trust.
Finally, you need AI incident handling as a first-class workflow. Not only breaches. AI incidents include harmful outputs at scale, systemic decision errors, unsafe behavior, and failures that require rapid containment and evidence preservation.
<h3>7. The E-Commerce Law (Law No. 122/2025/QH15)</h3>
<h4>E-commerce is regulated as platform operations, not just online sales</h4>
The common failure mode in e-commerce compliance is treating it as legal packaging. Add some terms, update the footer, and assume the risk is covered.
Vietnam’s direction increasingly regulates platforms as governed systems: onboarding, seller identity, visibility, enforcement, complaints, and proof.
“A marketplace without evidence is not a platform - it is a liability engine.”
<h4>The operational reality: your platform must be proof-capable</h4>
Compliance pressure does not arrive as a philosophical question. It arrives as a request:
Show what was displayed. Show what was agreed. Show what rule was in force at the time. Show why visibility changed. Show why a listing was removed. Show how a complaint was handled.
In Vietnam, the platform fails the moment it cannot produce a clean, time-stamped evidence pack in the required dossier format - not when it lacks a policy page.
If you cannot produce that evidence quickly, the platform fails under scrutiny, even if your policies are beautifully written.
Mandatory disclosures are not a single page. They are a versioned publishing workflow. You need to prove what was published, when it changed, and what users and sellers were shown.
Order and contract flows are not only UX. They become compliance evidence systems. You need to prove what information was presented and confirmed.
Seller onboarding becomes a governed workflow. Identity verification cannot be a casual form field. It requires logs, review steps, and escalation paths.
Takedown and enforcement must become formalized. If the platform can remove listings or suspend sellers, every enforcement event becomes a record that can be challenged. Intake, assessment, action, notification, appeal, finalization.
Ranking and visibility become accountability surfaces. If you rank, recommend, boost, suppress, or filter content, you are running algorithmic governance. Even if you never call it AI, the effect is the same: outcomes are influenced at scale.
The practical requirement is simple: you need a ranking accountability pack that can be produced quickly when disputes occur. If you cannot explain why visibility changed, you cannot defend your platform.
<h3>8. The Cybersecurity Law overlay (effective 01 July 2026)</h3>
<h4>Cybersecurity does not replace other laws - it constrains the architecture</h4>
Part I already covered the cybersecurity trajectory. Part II clarifies the business impact: AI and e-commerce platforms are typically the most exposed categories because they operate high-volume services with user accounts, cross-border infrastructure, and algorithmic decision systems.
Cybersecurity overlays shift compliance in three concrete ways.
First, where data sits and how quickly you can respond becomes an operational requirement, not an abstract legal analysis. Architecture decisions become compliance decisions.
Second, monitoring becomes part of regulatory posture. Detection, incident coordination, and evidence preservation shift from best practice to auditable capability.
Third, account telemetry and IP-related attributes become compliance-sensitive. Not because logs are bad, but because logs become governed evidence.
The correct posture remains the same as Part I: draft guidance is signal, not final law. Treat it as a watchlist. But do not delay capability-building. When implementing rules land, the companies that already have workflow and evidence architecture will move fastest.
<h2>The new enforcement surface - AI systems, platforms, and cybersecurity readiness</h2>
Part I’s execution layer focused on registers, assessments, dossiers, workflows, and evidence discipline. Part II extends that into two operational domains:
AI governance as a controlled system. A living AI register, classification workflow, pre-deployment gates for high-impact systems, transparency deliverables, provenance controls where relevant, and AI incident workflows.
Platform governance as a controlled system. Versioned disclosures, evidence-ready order flows, seller verification, enforcement workflows, ranking accountability, and dispute handling with evidence preservation.
This is the shared pattern across the stack:
Compliance becomes manageable the moment it becomes a system.
<h2>Why I'm writing this now</h2>
Over the past months, I have been deep inside Vietnam’s compliance reality while building a Vietnam-native governance platform that has to survive in the real world - not in slide decks.
Part I focused on the core compliance stack most teams are already feeling: personal data protection, data governance, cross-border handling, and procedure-driven dossier requirements.
Part II expands the same operational proof into two domains that will define 2026 for digital business in Vietnam: AI systems and e-commerce platforms - with the cybersecurity overlay increasingly shaping what is possible at an architecture level.
The pattern I keep seeing is still simple, but the blast radius is larger:
Most organizations can write a policy. Fewer can run the workflows. Very few can prove control when the system is live - across privacy, AI, platform operations, cross-border flows, vendors, and incidents.
That gap is where compliance becomes expensive, slow, and risky - especially when an AI feature ships without governance, a ranking system causes disputes, a seller incident escalates, a cross-border dependency changes, or authorities request evidence in a specific format.
<h2>Vietnam enterprises, banks, telcos, platforms - what we are building and what we need from you</h2>
We have been building AesirX ComplianceOne as a Vietnam-native compliance execution layer that covers the full stack across Part I and Part II: dossiers, registers, workflows, evidence, and submission readiness - not as documents, but as a system that runs continuously.
This coming Friday, we are officially releasing AesirX ComplianceOne into the market, including new landing pages, three ready-to-deploy packages and an enterprise rollout plan.
If you are operating in Vietnam and you are:
<ul>
<li aria-level="1">A bank or financial institution running regulated or cross-border data flows.</li>
<li aria-level="1">A telco, ISP, data center operator, or large digital infrastructure provider.</li>
<li aria-level="1">An e-commerce platform or marketplace managing sellers, ranking, enforcement, and disputes.</li>
<li aria-level="1">A large enterprise deploying AI systems, copilots, recommendation engines, fraud scoring, dynamic pricing, or automated decisioning.</li>
<li aria-level="1">A group company managing multiple subsidiaries, vendors, and shared platforms.</li>
</ul>
We are open to early enterprise input and pilot participation.
“Compliance becomes manageable the moment it becomes a system”
<h2>What we need is not feature requests - it is operational reality</h2>
If you want to shape a Vietnam-native compliance platform that is built for the way enforcement works in practice, we are looking for specifics:
What I’m looking for is a clear picture of where compliance breaks inside live operations. Which dossiers and registers your teams struggle to produce on demand, and which artifacts consistently fail the “format, timeline, evidence” test when pressure hits.
I also want to understand which workflows collapse first when the environment changes - incidents, authority requests, vendor changes, cross-border dependencies, internal reorganizations, or disputes that require fast decisions with a clean evidence trail.
And for teams shipping AI and running platforms, I want the uncomfortable details: which AI systems are hardest to govern in production (classification, oversight, transparency, logging), and which platform operations create the most exposure (seller verification, takedowns, ranking disputes, complaints, appeals). When you say “audit-ready” internally, what evidence actually gets challenged first - and what does your organization wish it could produce faster, cleaner, and with less manual effort?
If this sounds like your world, send me an email or reach out here. We will start with a short call, give you access to a demo environment, map your compliance pain points, and turn them into concrete roadmap priorities for your Vietnam reality.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>
<h2>References</h2>
Part I frameworks referenced: PDPL 2025 (Law No. 91/2025/QH15), Decree 356/2025/NĐ-CP, Decision 778/QĐ-BCA-A05, Data Law (Law No. 60/2024/QH15), Telecommunications Law (Law No. 24/2023/QH15 and Decree 163/2024/NĐ-CP), Cybersecurity Law 2025 (Law No. 116/2025/QH15) and draft guidance.
Part II frameworks cover: Vietnam AI Law (effective 01 March 2026) and implementing framework and guidance, E-Commerce Law (Law No. 122/2025/QH15), Cybersecurity Law 2025 (effective 01 July 2026) and draft guidance.

Market Focus - Regulatory Compliance Vietnam (Part II)

Blog Aesirx

Vietnam’s AI, E-Commerce, and Cybersecurity laws reshape compliance in 2026. Learn how enterprises operationalize governance with AesirX ComplianceOne.

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR:&nbsp;Vietnam is moving fast from “privacy as paperwork” to privacy as an operational system: impact dossiers, cross-border assessments, administrative procedures, data governance, telecom confidentiality, and cybersecurity-driven localization rules.
If you operate in banking, telecom, payments, e-commerce, or any large digital service, compliance now means maintaining ongoing registers, structured workflows, and verifiable evidence, not just publishing a policy page.
The real risk isn’t that you don’t have documents; it’s that you can’t produce the right dossier in the right format, on the right timeline, with the right audit trail.
</div>
This article is a practical walkthrough of the Vietnamese legal stack and is written for DPOs, legal/compliance teams, CISOs, and digital leaders operating in Vietnam - especially in banking, telecom, payments, e-commerce, and large enterprises with cross-border services. If you’re responsible for producing dossiers, running incident and authority-request workflows, or keeping vendor and data-flow governance audit-ready, this is written for you.
<h2>Why a Vietnam-first regulatory map matters</h2>
If you’ve run compliance programs in the EU, US or Singapore, it’s tempting to assume Vietnam is the same story with different wording. It isn’t.
Vietnam’s direction is clear: governance + state-grade procedures + operational accountability. That means:
<ul>
<li aria-level="1">Formalized procedures and standardized templates where authorities expect structured submissions.</li>
<li aria-level="1">Clearer requirements around cross-border transfer, localization, and data governance controls.</li>
<li aria-level="1">Sector overlays (especially telecom and cybersecurity) that change what “normal privacy compliance” looks like in practice.</li>
</ul>
“Vietnam compliance is no longer ‘do you have a policy?’ - it’s ‘can you produce the dossier, prove the controls, and show the audit trail on demand?”
A modern Vietnam GRC (Governance, Risk, and Compliance) program therefore needs two layers:
<ol>
<li aria-level="1">The legal frameworks layer: laws, decrees, decisions, guidance.</li>
<li aria-level="1">The execution layer: registers, assessments, submission dossiers, incident workflows, vendor controls, evidence management.</li>
</ol>
This article walks through both.
<h2>The Vietnamese Regulatory stack&nbsp;</h2>
<h3>1. Personal data protection: PDPL 2025 and Decree 356</h3>
Vietnam’s Personal Data Protection Law (PDPL 2025) is the anchor for personal data governance: principles, roles, rights, breach handling expectations, and the system of impact assessments and cross-border assessments. Decree 356 is the implementation layer that turns “what the law says” into “how you do it.”
What a Vietnam-ready GRC program needs here is not only a DPIA-style report, but a structured program covering:
<ul>
<li aria-level="1">Role mapping (controller / processor / joint roles) per processing activity.</li>
<li aria-level="1">Personal data inventory (including sensitive categories).</li>
<li aria-level="1">Consent and notice management (what was shown, when, to whom, and proof).</li>
<li aria-level="1">Data subject rights workflows and evidence logs.</li>
<li aria-level="1">Breach workflow, triage, and reporting package generation.</li>
<li aria-level="1">Vendor/processor governance: due diligence, contracts, sub-processors, change controls.</li>
<li aria-level="1">Cross-border transfer register + transfer impact assessment structure.</li>
</ul>
“The fastest way to fail PDPL is to treat it like a ‘privacy policy project’ instead of a ‘governance and evidence system.”
<h3>2. Administrative procedures: Decision 778 and the formal dossier process (A05 / MPS)</h3>
Decision 778 is where Vietnam’s PDPL enforcement becomes operational. It doesn’t just say “prepare a dossier.” It standardizes the lifecycle of a dossier: how it is received, validated, supplemented, refused, extended, and finalized. That matters because it moves compliance from static documentation to controlled execution.
In practice, this means enterprises need a dossier capability that can:
<ul>
<li aria-level="1">produce submission-ready outputs consistently, with the correct attachment structure.</li>
<li aria-level="1">track status changes and version history when dossiers are updated or supplemented.</li>
<li aria-level="1">maintain an audit trail that shows what changed, who approved it, and when.</li>
</ul>
That’s a positive shift for serious compliance teams: more predictability, clearer expectations, and less ambiguity under pressure.
“When the state standardizes the process, your compliance system must become process-native-not document-native.”
<h3>3. Data governance: Vietnam Data Law</h3>
Vietnam’s Data Law pushes beyond personal data and into broader data governance: data classification, risk management in processing, governance responsibilities, and the concept that “data compliance” is not only a privacy topic.
For organizations, this means you need governance artifacts that look familiar to GRC teams:
<ul>
<li aria-level="1">Enterprise data inventory (datasets, owners, systems, locations, retention).</li>
<li aria-level="1">Data classification and handling rules.</li>
<li aria-level="1">Retention and deletion schedules (with exceptions documented).</li>
<li aria-level="1">Data sharing and disclosure logs.</li>
<li aria-level="1">A governance audit plan and evidence collection workflow.</li>
<li aria-level="1">Risk assessments that cover privacy risk, cybersecurity risk, access risk, and operational risk.</li>
</ul>
In mature organizations, PDPL and Data Law must be mapped together: the same dataset often triggers both.
<h3>4. Telecom overlay: Telecommunications Law and implementing rules</h3>
If you’re a telco, ISP, data center operator, or a regulated digital infrastructure provider, telecom rules add a second “compliance gravity field” around confidentiality, disclosure, logging expectations, and operational controls.
Even for non-telcos, telecom infrastructure is often upstream of your services. That matters because compliance risk can travel through vendors and critical suppliers.
A Vietnam-ready GRC approach here requires:
<ul>
<li aria-level="1">Confidentiality and access control rules for telecom-related data.</li>
<li aria-level="1">Disclosure governance: approvals, scope minimization, and disclosure logs.</li>
<li aria-level="1">Authority request intake/verification/response package records.</li>
<li aria-level="1">Retention schedules aligned to sector obligations.</li>
<li aria-level="1">Incident reporting and post-incident corrective action records.</li>
</ul>
“Sector law is where generic privacy programs go to die-because sector obligations are operational, not theoretical.”
<h3>5. Cybersecurity and localization: the LOSC 2025 direction and what it changes</h3>
Cybersecurity regulation is where Vietnam’s approach becomes most “infrastructure-driven.” The compliance question becomes: where is the data stored, what is the service, who are the users, and how quickly can you respond to lawful requests?
What matters for most large digital services:
<ul>
<li aria-level="1">Localization triggers (when they apply, what data categories are in scope).</li>
<li aria-level="1">Architecture decisions (onshore storage, segmentation, access control, monitoring).</li>
<li aria-level="1">Authority request handling readiness (intake, verification, response, chain-of-custody).</li>
<li aria-level="1">Incident readiness and evidence preservation.</li>
</ul>
A draft implementing decree/guidance under the Law on Cybersecurity 2025 signals tighter rules on data localization and IP address identification. This is exactly where teams should be careful: drafts can reshape definitions, thresholds, timelines, and even who is in scope.
The right stance is:
<ul>
<li aria-level="1">Track drafts as a watchlist framework.</li>
<li aria-level="1">Build readiness templates as “preparation controls”.</li>
<li aria-level="1">Promote to “active compliance requirements” only when finalized.</li>
</ul>
<h2>Drafts and consultations: how to stay compliant without chasing noise</h2>
Draft guidance is signal, not law. It’s useful because it shows where enforcement is heading - but it can also change materially before it becomes final. The mistake is to rewrite your compliance program every time a consultation paper drops.
A more resilient approach is to run a two-speed compliance posture:
<ul>
<li aria-level="1">Enforceable instruments (laws, decrees, decisions): these drive your mandatory registers, dossiers, workflows, and audit evidence.</li>
<li aria-level="1">Draft instruments (consultations): these go into a monitored “watchlist” so your DPO and security/compliance teams can assess likely impact without treating it as a binding obligation yet.</li>
<li aria-level="1">Readiness documentation: lightweight preparation notes - data flow mapping, architecture options, gap lists - so you can move quickly if the draft becomes final.</li>
</ul>
When the instrument is finalized, you don’t start from scratch. You convert your readiness work into updated dossiers, templates, and controls with clear versioning and an audit trail.
“Treat drafts like weather forecasts: you prepare for them, but you don’t rebuild your house every time the wind changes.”
<h2>What “Regulatory Compliance Vietnam” should look like in practice</h2>
For Vietnamese enterprises, banks, and telcos, compliance can’t live in scattered Word files and ad-hoc spreadsheets. The real requirement is operational: when something changes - an incident, a vendor update, a cross-border flow, or an authority request - you need to produce the right dossier, with the right attachments, on the right timeline.
That’s why a Vietnam-focused compliance program typically needs four building blocks working together:
<h3>A. Core registers that stay current</h3>
<ul>
<li aria-level="1">A Vietnam-adapted processing inventory (ROPA-style).</li>
<li aria-level="1">Personal data inventory including sensitive data classification.</li>
<li aria-level="1">Vendor/processor register including sub-processors and change history.</li>
<li aria-level="1">Cross-border transfer register (flows, recipients, safeguards, locations).</li>
<li aria-level="1">Disclosure and authority request logs.</li>
<li aria-level="1">Retention and deletion schedule (with documented exceptions).</li>
</ul>
“If your registers aren’t alive, your compliance is a snapshot - not a system.”
<h3>B. Assessments and dossier outputs you can generate consistently</h3>
<ul>
<li aria-level="1">Processing impact assessment dossier (PDPL).</li>
<li aria-level="1">Cross-border transfer impact assessment dossier (PDPL).</li>
<li aria-level="1">Data governance risk assessments where Data Law applies.</li>
<li aria-level="1">Localization and architecture readiness assessments where cybersecurity/localization rules apply.</li>
</ul>
<h3>C. Workflows for the moments when risk becomes real</h3>
<ul>
<li aria-level="1">Data subject rights intake → verification → response → closure evidence.</li>
<li aria-level="1">Incident response: triage → record → decision → reporting package → corrective actions.</li>
<li aria-level="1">Authority request handling: intake → verification → response package → chain-of-custody.</li>
<li aria-level="1">Vendor change impact assessment when onboarding or altering third parties.</li>
</ul>
<h3>D. Evidence and audit trail that survives scrutiny</h3>
<ul>
<li aria-level="1">Policy approvals and attestation records.</li>
<li aria-level="1">Evidence pack generation (what exists, where it is, who approved it, when it changed).</li>
<li aria-level="1">Submission tracking and status history for procedures that are standardized, including supplement cycles and versioning.</li>
</ul>
The common failure mode isn’t “we didn’t try.” It’s that compliance is distributed across teams, formats, and folders - so when time pressure hits, nobody can assemble a complete, defensible dossier fast enough.
<h2>Why I’m writing this now</h2>
Over the past months, I’ve been deep inside Vietnam’s compliance reality while building a Vietnam-native GRC platform for enterprise teams who need their documentation, workflows, and evidence to hold up under scrutiny.
The pattern I keep seeing is simple:
<ul>
<li aria-level="1">Most organizations can write a policy.</li>
<li aria-level="1">Fewer can run the workflows.</li>
<li aria-level="1">Very few can produce the correct dossier formats quickly, consistently, and with audit-grade evidence.</li>
</ul>
That gap is where compliance becomes expensive, slow, and risky - especially when an incident happens, a vendor changes, cross-border flows evolve, or authorities request documentation.
<h2>Vietnam enterprises, banks, telcos - what we’re building and what we need from you</h2>
We’re currently building a dedicated Vietnam GRC Suite tailored to Vietnam’s legal frameworks and the way compliance is enforced in practice: dossiers, registers, workflows, evidence, and submission readiness.
If you’re operating in Vietnam and you are:
<ul>
<li aria-level="1">A bank or financial institution.</li>
<li aria-level="1">A telco, ISP, or data center operator.</li>
<li aria-level="1">A large enterprise running cross-border services or regulated data flows.</li>
<li aria-level="1">A group company managing multiple subsidiaries and vendors.</li>
</ul>
…we’re open to early enterprise input and pilot participation.
“Compliance becomes manageable the moment it becomes a system”
What we’re looking for isn’t abstract “feature requests,” but real operational reality:
<ul>
<li aria-level="1">Which dossiers and registers your teams struggle to produce.</li>
<li aria-level="1">Which workflows break under time pressure (incidents, authority requests, vendor changes).</li>
<li aria-level="1">Which data flows are hardest to govern (cross-border, shared platforms, third parties).</li>
<li aria-level="1">What “audit-ready” means inside your organization (and what evidence actually gets challenged).</li>
</ul>
If you want to shape a Vietnam-native GRC Suite built for your environment, send me an email or reach out here. We’ll start with a short call, give you access to a demo environment, map your compliance pain points, and translate them into concrete roadmap priorities.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>
Laws referenced in this article: Decision 778/QĐ-BCA-A05 (administrative procedures PD protection), PDPL 2025 (Law No. 91/2025/QH15), Decree 356/2025/NĐ-CP, Vietnam Data Law (Law No. 60/2024/QH15), Telecommunications Law (Law No. 24/2023/QH15) and Decree 163/2024/NĐ-CP.
Disclaimer: This article highlights only a subset of Vietnam’s regulatory frameworks relevant to the specific topic and space constraints of the LinkedIn format. Other frameworks also require serious attention in practice, including the Vietnam AI Law (effective 1 March 2026), the E-Commerce Law (Law No. 122/2025/QH15), and the Cybersecurity Law (Law on Cybersecurity 2025, effective 1 July 2026).

Market Focus - Regulatory Compliance Vietnam

Understand Vietnam’s compliance stack, from PDPL and Data Law to telecom and cybersecurity rules, and what a modern GRC program must include.

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR:&nbsp; Cookie scanners often measure cookie inventories, not the real compliance question: what loads before consent (including beacons, tag bootstraps, and other tracking tech beyond cookies). I tested 10 EU-focused scanner ecosystems on the same site, measuring only the pre-consent window (no clicks, no reject/accept flow). The outputs disagreed wildly - from “44 trackers” to “0 findings,” and one scanner didn’t even finish within an hour.
</div>
Two weeks ago I published a <a href="https://www.linkedin.com/pulse/danish-e-commerce-awards-2026-ronni-k-gothard-christiansen-p5bte/" target="_blank" rel="noopener">study of Danish E-Commerce Awards nominees</a>. Most sites still triggered pre-consent tracking evidence.
After it went live, one of the nominated companies reached out. They were appreciative - and then added a line I hear constantly:
Their cookie scanner didn’t reveal any problems. Their supplier had told them it was compliant. They thought they were compliant.
That’s the moment this Weekly is built around.
Because if your scanner says “all good” while your site still makes tracking calls before anyone has chosen anything, you don’t have compliance - you have false confidence. And false confidence is what keeps leakage “normal” for years.
“A clean scanner report can be the most dangerous outcome - it convinces the business to stop looking.”
<h2>What scanners usually measure vs what compliance actually is</h2>
Most scanners are designed to answer the question teams want answered:
“What cookies exist, and can we classify them into a declaration?”
That’s useful documentation. It is not the compliance boundary.
The compliance boundary is timing at the device access layer: whether tracking identifiers or tracking calls happen before a visitor has had a real choice.
And the modern problem is that tracking isn’t “just cookies” anymore. A site can initialize the marketing stack, send event data, and only set identifiers later - producing a scanner report that looks calm while the browser has already “phoned home.”
“Banners don’t create compliance - architecture does.”
<h2>What the data showed</h2>
In the nominee dataset, pre-consent leakage wasn’t exotic - it was standard.
The most common pre-consent beacon host was Google Tag Manager, and the surrounding ecosystem followed the same gravity: email tooling, platform telemetry, ad pixels, analytics stacks.
Here’s the part that matters for teams reading this: if your scanner is not explicitly measuring pre-consent network activity, it can miss exactly the most common failure mode.
<h4>Most common pre-consent beacon hosts (unique domains share)</h4>
<ul>
<li aria-level="1">Google Tag Manager (GTM) - 92/137 (67.15%)</li>
<li aria-level="1">Klaviyo - 40/137 (29.20%)</li>
<li aria-level="1">Shopify telemetry - 38/137 (27.74%)</li>
<li aria-level="1">Meta - 37/137 (27.01%)</li>
<li aria-level="1">Google Analytics - 36/137 (26.28%)</li>
</ul>
<h4>Most common tracking cookies observed pre-consent</h4>
<ul>
<li aria-level="1">DoubleClick test_cookie - 13.14%</li>
<li aria-level="1">Meta _fbp - 12.41%</li>
<li aria-level="1">DoubleClick IDE - 8.03%</li>
<li aria-level="1">LinkedIn bcookie - 8.03%</li>
<li aria-level="1">LinkedIn li_gc - 8.03%</li>
<li aria-level="1">LinkedIn lidc - 8.03%</li>
</ul>
These are not “edge trackers.” This is mainstream MarTech, firing before the visitor has done anything.
“If GTM loads before choice exists, the rest of the stack is already out of your control.”
<h2>Why scanners miss pre-consent beacons</h2>
This isn’t about accusing vendors of intent. It’s about acknowledging methodology limits in a modern web.
If you remember only one thing from the dataset, remember this: the pre-consent stack isn’t ‘mystery trackers’ - it’s the most standard tools in e-commerce.
Most scanners struggle with one or more of these realities:
<ul>
<li aria-level="1">They’re cookie-inventory heavy, but tracking can be “cookieless until later.”</li>
<li aria-level="1">They don’t consistently isolate/report the pre-consent window.</li>
<li aria-level="1">They under-execute dynamic behaviors: async injections, timers, soft navigations, embedded widgets.</li>
<li aria-level="1">They don’t model how marketing teams actually ship: new scripts added outside the gate, app updates, tag changes.</li>
</ul>
And there’s a point that feels taboo but is necessary to say:
Sometimes the consent layer itself becomes part of the leak.
In the Awards write-up I called out the pattern of pre-consent third-party calls to CMP-provider infrastructure - the “gate” talking externally before the visitor has chosen.
“Nothing found” doesn’t mean “nothing happened.” It can mean “we didn’t measure the pre-consent window.”
<h2>The test that settles the argument</h2>
You don’t need a debate about definitions. You need evidence.
Open a clean session and test three states:
<ol>
<li aria-level="1">Pre-consent (do nothing)</li>
<li aria-level="1">Reject all</li>
<li aria-level="1">Accept all</li>
</ol>
Then compare:
<ul>
<li aria-level="1">network requests (beacons / endpoints)</li>
<li aria-level="1">tag bootstrap scripts (especially tag managers)</li>
<li aria-level="1">identifiers (cookies + localStorage)</li>
</ul>
If you want a quick first step before doing deeper forensics, run the domain through our <a href="https://aesirx.io/services/privacy-scanner" target="_blank" rel="noopener">free Privacy Scanner</a> first. It’s built around the same baseline principle: what evidence appears before a valid consent signal (client-side beacons + cookies), not just what can be documented later.
If it flags pre-consent evidence, the work is rarely “rewrite the banner.” The work is “move execution order so the marketing stack can’t initialize early.”
That’s the manual ground-truth method. For the scanner benchmark below, I only compared what each tool reports in the pre-consent window.
<h2>The 10 scanner ecosystems I tested</h2>
I tested ten of the most commonly used EU / EU-focused scanning ecosystems against “beacon reality” - using the same baseline every time:
What happens on the site before consent (the pre-consent window).
So I stopped arguing in theory and ran the scanners against a site that contains both cookies and beacons - because that’s where scanners either tell the truth or expose their limits.
Here are the results as each tool presented them (note: the labels and methodology vary a lot, so this is best read as “what problems the scanner surfaced,” not as a standardized measurement):
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/images/in-blog.png" alt="in blog" width="942" height="695" />
<h4>The test site and the baseline reality</h4>
All tests were run against the same site: Dansk Erhverv (the organization behind the Danish E-Commerce Awards), using&nbsp;<a href="https://www.danskerhverv.dk/" target="_blank" rel="noopener">https://www.danskerhverv.dk/</a>.
In our <a href="https://aesirx.io/services/privacy-scanner/result/www.danskerhverv.dk" target="_blank" rel="noopener">reference privacy scan</a>, we observe 1 third-party cookie and 9 beacons on the site. That makes it a useful “reality check” target: it contains both cookie activity and beacon activity, so you quickly see whether a scanner actually detects tracking technologies beyond cookies.
On this site:
<ul>
<li aria-level="1">Before consent, the website makes requests to 18 distinct third-party hosts.</li>
<li aria-level="1">Potential third-party web beacons are sent to 5 distinct hosts.</li>
<li aria-level="1">We observe 7 first-party cookies and 1 third-party cookie.</li>
<li aria-level="1">The site has 92 distinct third-party hosts whitelisted (allowlisted).</li>
<li aria-level="1">Server-side Google Tag Manager is loaded prior to consent via load.sgtm.danskerhverv.dk - which can circumvent detection for scanners that rely on cookie-only logic or third-party heuristics&nbsp;because the third-party destination is hidden behind a first-party endpoint.</li>
</ul>
<h4>Why the results don’t line up (and why that’s the point)</h4>
Each scanner uses a different methodology and vocabulary, and they don’t agree on what counts as a “tracker,” what is “necessary,” what is “marketing,” or what should be classified at all. That makes it extremely difficult for a company to compare results or to understand whether the scanner is validating consent-before-tracking - or merely generating a cookie inventory.
The goal of this chapter was not to crown a “winner.” It was to identify whether these tools surface the kinds of real-world issues that actually matter in the pre-consent window.
<h4>Friction and dark patterns in the scanning experience</h4>
A surprising number of these ecosystems make it hard to get a clear answer:
<ul>
<li aria-level="1">Several tools require account creation with name, company, and email before showing anything useful.</li>
<li aria-level="1">Only Cookie-Script and Piwik PRO (and our reference privacy scanner) offered a free scan without registration.</li>
<li aria-level="1">Some scanners even require consent to marketing or similar conditions to download a report (for example CookieHub), which is problematic in itself - especially for tools positioned as privacy compliance infrastructure.</li>
</ul>
<h4>The hard conclusion</h4>
Let’s be honest: for most companies, it’s extremely difficult to get a clear, actionable overview from many of these scanners.
Some don’t measure beyond cookies. Some hide key details behind signup or paid plans. Some classify questionable findings as “OK” without explaining what actually happened pre-consent. And when server-side tag management enters the picture, several scanners simply lose the trail entirely.
Which brings us back to the core point of this Weekly:
If a scanner isn’t explicitly measuring the pre-consent window - what requests and identifiers happen before the visitor chooses - then “we’re compliant” is not a conclusion. It’s a guess.
<h2>The moment teams need to recognize</h2>
Most companies aren’t trying to cheat. They’re trying to be safe.
They buy a CMP. They run a scanner. The report looks calm. They take a screenshot. They move on - because they have revenue targets, campaigns, and a backlog.
And that is exactly how pre-consent tracking becomes normal: not through intent, but through misplaced trust in the wrong measurement.
So here’s the value-based takeaway that actually matters:
If you operate in Denmark/EU, don’t outsource truth to a PDF report.
The standard isn’t “we documented cookies.” The standard is “we didn’t start tracking before the visitor chose.”
If you want, run your domain through the free Privacy Scanner and message me the pre-consent result. I’ll tell you plainly whether you’re looking at a small configuration gap - or a structural gate failure that needs engineering ownership.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

When “we’re compliant” is the problem

Compliance isn't about documenting cookies. It’s about preventing tracking before consent. Most EU sites still fail

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR:&nbsp; I scanned 173 nominees across 10 categories and, after deduplication, analyzed 137 unique domains using client-side evidence captured before consent. Only 22 nominees land in a low-risk range of 0-4 pre-consent findings, which means 151 out of 173 are still non-compliant by a conservative measure - 87.28%. The headline is not which vendor is popular; it’s that “consent before tracking” is still not the default operating mode in Danish e-commerce. The good news is that a meaningful group now shows zero or near-zero pre-consent evidence, proving correct gating is possible in real commerce stacks.
</div>
<h2>Progress, but still systematic data abuse before consent</h2>
This is the 4th year I’m auditing the top nominees in the Danish E-Commerce Awards. The reason I keep doing it is simple: e-commerce is where “growth” and “compliance” collide in real life - and it’s also where the gap between what companies claim and what their sites actually do becomes measurable.
This is not a niche compliance debate. This award is a benchmark for what Denmark calls “best practice” in e-commerce. That’s why it matters whether the winners are building trust - or quietly bypassing it.
This is also why the organizer matters. When Dansk Erhverv - Digital Handel positions these nominees as “the best of Danish e-commerce”, it becomes a benchmark for what the industry normalizes - including in a time where Denmark is debating digital independence and trust.
This year I want to highlight two things at the same time. First, we are finally seeing a meaningful group of nominees with zero or near-zero pre-consent evidence. Second, the broader dataset still shows that the default operating mode across the industry is to load tracking before consent.
“Only 22 out of 173 nominees land in a low-risk range. The remaining 87.28% still leak before consent.”
<h2>What the study measures</h2>
The award list contains 173 nominees across 10 categories. Because some nominees appear in multiple categories, the list contains duplicates. After deduplication, the dataset covers 137 unique website domains.
Unless otherwise stated, scans were performed using the AesirX Privacy Scanner (hosted in Germany), based on the EDPS Inspection Tool / Website Evidence Collector engine. For automated processing, 172 scan result URLs were generated and deduplicated to 136 unique domains, and one domain (henosia.com) is included through manual HAR-based handling due to an application error. On Henosia, the HAR shows one first-party analytics beacon (PostHog-ingest style) and zero cookies.
The analysis is limited to client-side evidence captured by scanner/HAR: network requests classified as beacons and cookies set or observed before a valid consent signal. Sites are not assessed for server-side tracking, proxying, masking, or other circumvention techniques. Actual data collection may therefore exceed what is reflected in these results.
<img src="https/api.aesirx.io/images/images/what-this-analytics-covers-and-why-it-matters.png" alt="what this analytics covers and why it matters" width="942" height="610" />
<h2>The legal foundation in Denmark</h2>
The compliance baseline in Denmark is not a grey-zone “risk assessment” exercise. It is governed by two different legal pillars and two different authorities.
GDPR is implemented via Databeskyttelsesloven and enforced by Datatilsynet. If you process personal data for marketing measurement and tracking, you need a lawful basis that matches reality, and if you rely on consent, that consent must be freely given, specific, informed, unambiguous, and withdrawable.
The terminal equipment rule is ePrivacy Directive Article 5(3), implemented in Denmark via cookiebekendtgørelsen and governed by Digitaliseringsstyrelsen. This rule is binary: storing or accessing information on the user’s device requires prior consent unless it is strictly necessary for the service the user explicitly requested.
That “strictly necessary” exception is narrow. It is not a blanket justification for attribution, marketing optimization, telemetry, profiling, enrichment, or vendor-side measurement. If tracking beacons and/or non-essential cookies are observed before a valid consent signal, the implementation fails the “consent before access/storage” requirement under cookiebekendtgørelsen, and it will often also fail GDPR requirements for valid consent.
In practice, GDPR asks whether your processing is lawful; ePrivacy Directive 5(3) asks the simpler question first: did you access the device for non-essential purposes before consent - yes or no.
Read the full <a href="https://digst.dk/media/oy1btb02/faellesvejledning-med-datatilsynet.pdf" target="_blank" rel="noopener">joint guidelines on cookies and tracking technologies</a> from Datatilsynet and Digitaliseringsstyrelsen.
<h2>The headline finding: 87.28% still non-compliant</h2>
Here is the conservative classification that matters for any serious discussion.
Only 22 out of 173 nominees score in a low-risk range. Conservatively, 0-4 findings is a low-risk range and a reasonable proxy for likely compliance in this dataset.
The remaining 151 nominations are classified as non-compliant under cookiebekendtgørelsen (ePrivacy Directive Article 5(3)) in Denmark and/or Databeskyttelsesloven (GDPR), because they trigger tracking evidence prior to a valid consent signal.
This is the core narrative point. Not “which vendor is most common”. Not “which CMP is trending”. The baseline question is: does tracking start before consent - yes or no.
<img src="https/api.aesirx.io/images/images/domain-compliance-findings.png" alt="domain compliance findings" width="942" height="1101" />
<h2>Why this keeps happening in e-commerce</h2>
The recurring cause is not ignorance of the law - it is the way e-commerce stacks are assembled. Templates ship with tag managers and marketing widgets enabled by default, teams inherit “measurement-first” setups from agencies, and vendor stacks are increasingly bundled so telemetry, attribution, personalization, reviews, and email marketing are fused together. The result is predictable: tracking initializes first, and consent logic is asked to retroactively justify what already happened.
The law does not allow retroactive gating. If the first network requests and device identifiers appear before consent, the implementation is structurally non-compliant - even if the banner looks polished.
<h2>What still loads before consent</h2>
This is where the technical reality becomes uncomfortable, because it shows how the modern marketing stack behaves by default.
<h3>1) Tag infrastructure and tracking endpoints still fire pre-consent</h3>
In the deduplicated dataset of 137 unique domains, the Top Beacon Hosts table counts how many unique domains triggered at least one pre-consent request to each host and how frequently those hosts appear across the dataset.
A major signal remains that Google Tag Manager loads pre-consent on 92 out of 137 domains, which is 67.15%. That is not a “minor configuration edge case”. It is the default operating mode.
“If your first request is a tag manager, your consent logic is already chasing a train that left the station.”
<img src="https/api.aesirx.io/images/images/top-10-beacons-loading-before-consent.png" alt="top 10 beacons loading before consent" width="960" height="540" />
In other words, the industry’s default architecture is still “tag manager first, consent later” - which is backwards under ePrivacy Directive 5(3).
<h3>2) Tracking cookies are still being set pre-consent</h3>
The Top Cookies table counts cookie families observed across unique domains, filters out obvious platform/essential cookies and common consent cookies, and focuses on tracking identifiers that appear prior to consent.
That matters because ePrivacy Directive 5(3) is not “cookie theatre”. It’s device access. If tracking cookies are set before consent, the implementation fails the baseline.
“If tracking cookies are set pre-consent, the compliance discussion is already over.”
&nbsp;<img src="https/api.aesirx.io/images/images/top-10-tracking-cookies-set-before-consent.png" alt="top 10 tracking cookies set before consent" width="960" height="540" />
These identifiers are not “technical necessity”. They are marketing infrastructure, and when they appear pre-consent the implementation fails the baseline regardless of what the banner claims.
<h3>3) The consent layer is often part of the leak</h3>
This point is easy to misunderstand, so I’ll state it precisely.
The Top CMP table does not measure “CMP presence”. It measures pre-consent third-party calls to CMP-provider infrastructure that were classified as beacons in the export. In the deduplicated dataset (N=137 domains, including Henosia via HAR), at least one of the Top CMP providers was observed loading pre-consent on 97 out of 137 domains, which is 70.80%.
If a consent vendor processes data or accesses terminal equipment prior to consent for vendor purposes, such as telemetry, geo-IP lookups, or pixel trackers, that is not “technical necessity” on behalf of the visitor under GDPR and ePrivacy Directive 5(3). The consent mechanism becomes part of the non-compliant data flow.
“A consent layer that phones home before consent is not a gate. It’s part of the tracking.”
<img src="https/api.aesirx.io/images/images/top-5-cmp-consent-providers-observed-loading-pre-consent.png" alt="top 5 cmp consent providers observed loading pre consent" width="960" height="540" />
A consent layer that triggers vendor-side processing pre-consent turns compliance into theatre, because the “gate” is already exchanging data before the visitor decides.
A growing part of this problem is bundling. Vendors increasingly ship CMP, analytics, marketing automation, widgets, and CDNs as one stack. That makes implementation easier, but it also blurs purposes and recipients, and it creates pressure to treat vendor telemetry as “necessary”. The strict necessity test is about what the visitor requested - not what the vendor needs for attribution, invoicing, enrichment, or product analytics.
<h2>Worst and best: the spread tells the truth</h2>
I rank domains by total observed pre-consent activity (beacons + cookies). The purpose is not drama. The purpose is to show the distance between “we can’t” and “we did”.
<h3>Top 10 Non-Compliant</h3>
This list ranks the highest observed pre-consent totals. The unit is unique nominee domains in the final deduped dataset (n=137), and totals are calculated from client-side evidence observed before consent.
&nbsp;<img src="https/api.aesirx.io/images/images/top-10-worst-offenders.png" alt="top 10 worst offenders" width="960" height="540" />
These are not outliers. They are what happens when the stack is allowed to initialize marketing infrastructure before consent.
<h3>Top 10 Best (lowest observed)</h3>
This list ranks the lowest observed totals. “0” does not prove compliance. It means no tracking-classified beacons or tracking cookie identifiers were observed pre-consent in the captured client-side evidence, and server-side/proxy/masking was not assessed.
This matters because it proves the industry excuse is wrong. It is possible to build an e-commerce stack that does not leak by default.
<img src="https/api.aesirx.io/images/images/top-10-best-lowest-total-pre-consent.png" alt="top 10 best lowest total pre consent" width="960" height="540" />
These are the proof cases. They show that you can run serious commerce without pre-consent leakage, if you gate properly and keep telemetry in check.
<h2>A note on the “Best e-commerce case” nominees</h2>
For the Best e-commerce case nominees, the scanned domain reflects the customer/case implementation presented. The scan is used as an indicator of the solution’s ability to support compliance with Danish and European requirements, including Databeskyttelsesloven (GDPR) and cookiebekendtgørelsen (ePrivacy Directive Article 5(3)).
That means the scan is not just a comment on a brand. It is also a signal about the implementation model being showcased as “best practice”.
<h2>Banners don’t create compliance - architecture does</h2>
The e-commerce industry needs to stop treating this as a copywriting problem and start treating it as an engineering property.
The simplest compliance test in Denmark is still the most powerful: does your site store or access tracking identifiers on the device or call tracking endpoints before consent - yes or no. That is cookiebekendtgørelsen implementing ePrivacy Directive 5(3), and it is governed by Digitaliseringsstyrelsen. If you process personal data for tracking and rely on consent that is not freely given, informed, and specific, that is GDPR via Databeskyttelsesloven, governed by Datatilsynet.
This year’s dataset shows two truths at once. A small group proves compliant gating is feasible. The majority proves that the default is still systematic pre-consent tracking.
And if we don’t call that what it is, the industry will keep polishing banners while the data flows remain unchanged.
And that is exactly why the award benchmark itself has to be part of the discussion.
<h2>Digital independence vs data doping: the contradiction in plain numbers</h2>
Denmark is having a serious debate about digital independence from US BigTech. That is exactly why it’s hard to read this dataset without calling out the hypocrisy: Google Tag Manager loads pre-consent on 67.15% of top nominees. That is not “digital leadership”. That is a structural dependency - and it’s incompatible with the story Denmark tells itself about taking control of its digital future.
I’m not asking an award show to act as a regulator. I’m asking an industry organisation to stop treating “growth at any cost” as excellence when it conflicts with Danish law and public trust. If an awards benchmark ignores GDPR and ePrivacy Directive 5(3) year after year, it doesn’t just reflect the market - it trains the market.
This is a question for Dansk Erhverv - Digital Handel and for Brian Mikkelsen: do we want Danish digital leadership to mean sovereignty and trust - or just better optimization on top of illegal tracking?
“If 67.15% of ‘top’ nominees load GTM before consent, the award isn’t measuring excellence - it’s measuring how well data doping performs..”
If Denmark wants digital leadership, we must stop awarding stacks that treat consent as a decorative layer on top of default surveillance.
<h2>Full findings and category tables</h2>
I’m publishing the full results as a PDF carousel so you can verify everything without taking my word for it.
The carousel includes the complete Top 20 nominee tables for all 10 categories, plus the cross-category summary tables: Top 10 Beacons, Top 10 Cookies, Top 5 CMPs, Top 10 Non-Compliant, and Top 10 Compliant / Lowest observed.
Use it like a reference deck: open your category, find the nominee, and you’ll see immediately whether tracking starts before consent.
<div>pdflink:https://api.aesirx.io/images/Blog/Danish_E-Commerce_Awards_2026.pdf</div>
<h2>What you can do next</h2>
If you want to check your own site, start with the same method this study uses: measure what loads before consent. Run your domain through the <a href="https://aesirx.io/services/privacy-scanner" target="_blank" rel="noopener">AesirX Privacy Scanner</a> and review the client-side evidence (beacons and cookies) that appears before a valid consent signal.
If the scanner shows pre-consent tracking evidence, you already have the diagnosis: consent gating and configuration are broken under ePrivacy Directive 5(3), and the GDPR consent story will often also fail because the processing begins before any valid choice exists.
Start there. If your pre-consent findings are 0-4 you’re likely in a good place. If not, you have a concrete engineering problem to fix.
If you want a prioritized remediation plan you can hand to developers or an agency, the <a href="https://aesirx.io/services/privacy-review" target="_blank" rel="noopener">Technical Privacy Review</a> converts evidence into fixes - what leaks, why it leaks, and what to change first.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Danish E-Commerce Awards 2026

An independent audit of Danish E-Commerce Awards nominees shows 87.28% still trigger tracking before consent, despite GDPR and ePrivacy rules.

NEW YORK, FEBRUARY 6, 2026 - AesirX release Analytics Pro for WordPress, an advanced first-party analytics platform designed to deliver deeper visibility into campaigns, visitor behavior, and real business outcomes.
Most analytics tools still depend on third-party tracking stacks that are increasingly blocked, distorted, and difficult to govern. This leaves teams working with incomplete data and reports centered on surface-level metrics such as pageviews and clicks rather than meaningful performance results.
AesirX Analytics Pro for WordPress runs entirely in a true first-party setup, keeping analytics data under the site owner’s control by default. Built for compliance-first measurement, privacy and governance are embedded directly into the architecture rather than added as afterthoughts. 
The Pro version builds on <a href="https://aesirx.io/solutions/analytics/freemium/wordpress" target="_blank" rel="noopener">AesirX Analytics Freemium</a>, adding advanced reporting, real-time visibility, and value-focused insights for teams that require deeper measurement and faster decision-making.
<h2>From Volume Reporting to Outcome-Driven Analytics</h2>
Traditional analytics excels at counting visits, clicks, and pageviews but struggles to explain what actually drives business impact. For WordPress site owners looking for better insight without third-party tracking stacks, marketing and growth teams that need real-time campaign clarity, and agencies managing multiple sites at scale, surface-level metrics often fall short.
AesirX Analytics Pro shifts measurement toward outcomes by combining engagement scoring with metric value mapping across campaigns and on-site actions. Instead of treating all visits equally, each session becomes a sequence of value events that reflect intent, interaction depth, and meaningful results.
This allows teams to clearly see which campaigns generate high-quality journeys rather than just high traffic, which user flows consistently move visitors closer to conversion, and where friction causes value to stall or drop off across the site. By connecting acquisition sources with on-site behavior and outcomes, Analytics Pro delivers a unified view of performance that supports faster, more informed decision-making.
<h2>How AesirX Analytics Pro Changes Day-to-Day Measurement</h2>
Reliable data without third-party loss AesirX Analytics Pro improves data reliability by operating in a true first-party environment rather than relying on third-party tracking stacks that are often blocked or restricted by browsers and privacy tools. This results in more complete visibility into real visitor activity, helping teams base decisions on accurate performance data instead of distorted or partial reports.
Deeper visibility into visitor journeys Instead of viewing behavior as disconnected pageviews and isolated events, Analytics Pro reveals complete user paths across pages and flows. Teams can see how visitors progress through the site, where engagement strengthens, and where drop-offs occur, making it easier to identify high-impact journeys and areas that need improvement.
Real-time insight into live activity With built-in real-time reporting, teams can monitor active visitors as they interact with the site. Current pages, traffic sources, and live session value are visible as actions happen, allowing faster responses to campaigns, launches, and content changes without waiting for delayed reports.
Clearer conversion performance Analytics Pro highlights where visitors exit journeys and where meaningful actions take place. By visualizing drop-off points and conversion paths, teams can pinpoint friction within funnels and prioritize improvements that directly influence results.
Outcome-focused, value-based measurement Through UTM Value Mapping and Tag Event Value Mapping, Analytics Pro connects campaigns and on-site actions to business impact rather than just traffic volume. Sessions become sequences of value events, enabling teams to understand which sources and behaviors truly contribute to outcomes.
Smarter UX and content prioritization Engagement scoring shows how deeply visitors interact with different journeys and experiences. This allows teams to focus optimization efforts on flows that demonstrate strong interest and meaningful interaction instead of relying solely on popularity metrics like pageviews.
Privacy-first data ownership and control All analytics data is collected, stored, and processed within a first-party architecture, keeping it under the site owner’s control by default. This supports stronger governance and compliance-first measurement without dependence on third-party analytics services.
Fast deployment for WordPress teams Analytics Pro is delivered through a WordPress plugin, enabling teams to activate advanced analytics without coding. Installation and setup are streamlined so organizations can begin collecting meaningful insights quickly.
Scalable analytics without traffic limits Unlike many analytics platforms that introduce volume-based pricing and hidden thresholds, Analytics Pro supports growth without traffic caps. Teams can scale reporting across larger sites and higher traffic levels without unexpected costs.
<h2>Feature Highlights</h2>
Key capabilities in AesirX Analytics Pro for WordPress include:
<div class="table-responsive">
<table class="table table-bordered">
<tbody>
<tr class="bg-primary-stroke-2">
<td style="text-align: center;">Feature</td>
<td style="text-align: center;">Benefit</td>
</tr>
<tr>
<td>Pro dashboards</td>
<td>A clear snapshot of key performance metrics including real-time active users, visitors, top pages, locations, browsers, events, and tracking.</td>
</tr>
<tr>
<td>Real-time analytics</td>
<td>Live visibility into active visitors, current pages, and session value as meaningful actions happen.</td>
</tr>
<tr>
<td>UTM Value Mapping</td>
<td>Connect campaigns directly to business outcomes instead of relying on traffic volume alone.</td>
</tr>
<tr>
<td>Tag Event Value Mapping</td>
<td>Assign value to on-site actions such as clicks, signups, and conversions to understand which behaviors matter.</td>
</tr>
<tr>
<td>User experience views</td>
<td>Visualize every user journey and see which flows generate real value through scored paths.</td>
</tr>
<tr>
<td>Behavior analytics</td>
<td>Understand which pages hold attention, where users drop off, and how visitors move through the site.</td>
</tr>
<tr>
<td>Visitor analytics</td>
<td>Compare engagement across devices, platforms, and regions to spot performance issues and high-value segments.</td>
</tr>
<tr>
<td>First-party architecture</td>
<td>All data is collected, stored, and processed in a privacy-first structure without reliance on third-party analytics services.</td>
</tr>
<tr>
<td>Acquisition analytics</td>
<td>See how visitors arrive via channels, search engines, and campaigns, and which sources drive meaningful engagement.</td>
</tr>
</tbody>
</table>
</div>
<h2>How to get AesirX Analytics Pro for WordPress</h2>
AesirX Analytics Pro for WordPress is now available, giving teams a first-party, privacy-first analytics platform built around value rather than vanity metrics.
1. Install the plugin: <a href="https://github.com/aesirxio/wordpress-analytics-pro-plugin/releases" target="_blank" rel="noopener">Download and install the AesirX Analytics plugin</a> for WordPress.
2. <a href="https://signup.aesirx.io/" target="_blank" rel="noopener">Register your account</a>: Log in using your AesirX Shield of Privacy ID to activate your trial.
3. Configure analytics settings: Add your license key and start viewing data in the dashboard.
Get AesirX Analytics and turn every campaign into measurable value.
➡ <a href="https://github.com/aesirxio/wordpress-analytics-pro-plugin/releases" target="_blank" rel="noopener">Download Plugin</a>
To learn more, visit: <a href="https://www.aesirx.io" target="_blank" rel="noopener">https://www.aesirx.io</a>

AesirX Launches Analytics Pro for WordPress, Bringing First-Party, Value-Based Measurement to Growing Teams

AesirX Analytics Pro for WordPress delivers first-party, privacy-first analytics with real-time insights, user journeys, and value-based measurement.

AesirX Launches Analytics Pro for WordPress

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR:&nbsp; Functional AI is the antidote to both hype and harm: narrow scope, bounded permissions, verifiable outcomes, and lower waste. That same model can help a child communicate - translating weak signals into understood intent - and it can make complex platforms like WordPress safer to deploy and configure with AI. That’s sustainable AI: bounded by purpose.
</div>
My favorite use of AI isn’t “write me anything.” It’s: help me understand what a human is trying to express when the human can’t get it across in the usual way.
My daughter, Ida Marie, cannot speak, and she can’t use sign language in a conventional way. She has a small set of signals. One of them is raising her finger - sometimes it feels like 200 times a day - for her it means: “I want to say something.” But most of the time, we still can’t decode what the “something” is.
That experience forces a very different view of AI: not as a replacement for humans, but as a bridge for human limitations - a tool that turns weak signals into understood intent.
“When a person can’t communicate, AI should translate the signal - not harvest the person.”
And that’s the bridge to the rest of this story: the best AI systems will not be the broadest ones. They’ll be the ones with tight scope, careful permissions, and measurable impact - because that’s how you create trust.
Which brings us to WordPress.
<h2>WordPress “Agent Skills” is a signal of platform maturity</h2>
<a href="https://wordpress.org/news/2026/01/new-ai-agent-skill/" target="_blank" rel="noopener">WordPress introducing “Agent Skills”</a> is meaningful because it’s not just “AI inside WordPress.” It’s WordPress starting to define a contract for AI execution: what actions are permitted, where they can run, and how outcomes can be validated.
That matters because most AI-in-the-dashboard features fail in the same way: they stay in the “advisor” role. They can suggest, but they can’t safely do - and they can’t prove the result. WordPress is now moving toward the pattern that mature systems eventually converge on:
<ul>
<li aria-level="1">Abilities describe what can be done in a structured way.</li>
<li aria-level="1">Skills describe where and how it can be executed safely.</li>
<li aria-level="1">A sandbox (like Playground) creates a disposable environment to test changes without risking production sites.</li>
</ul>
This is subtle, but foundational: it’s the difference between AI that drafts opinions and AI that operates inside guardrails. In practice, it means an agent can (eventually) do things like: create a clean test instance, install a plugin set, change configuration, run checks, roll back, and document what happened - all without turning your live site into a lab.
“Bounded AI is a sustainability strategy: fewer watts, fewer mistakes, more trust.”
And that’s why this is bigger than “WordPress gets AI.” It’s WordPress positioning itself as an environment AI can reliably operate within - because reliability requires three things: permissions, isolation, and verification.
Once a platform has a safe execution surface, you can build bounded, functional agents that do one job end-to-end: observe → propose → apply → verify. Not “general AI,” but AI with a job description.
In WordPress, that’s especially workable because so much of the site’s behavior flows through a small set of control points (plugins, hooks, and script loading), which makes ‘bounded change + measurable result’ realistic.
One of the most obvious jobs inside WordPress is also one of the most neglected: making third-party behavior visible and controllable. Because the modern WP site isn’t a single system - it’s a constellation of plugins, tags, embeds, CDNs, and “just one more script” decisions. That sprawl is why configuration drifts, and why humans lose track of what actually runs on the page.
That’s the use case we focused on in our AI Privacy Advisor inside <a href="https://aesirx.io/solutions/consent-management-platform/wordpress">AesirX CMP Pro for WordPress</a> - as a functional workflow, not a chatbot: it scans what loads before consent, scans again after consent, proposes WordPress-native blocking rules, and generates draft privacy/cookie/consent text based on observed reality - then you can verify the change by re-running the scan.
<h2>The real problem: websites don’t know what they run</h2>
If you want a practical definition of “functional AI,” it’s this:
Turn a messy system into an observable system.
Most websites (especially WordPress sites) can’t answer a simple operational question with confidence: “What exactly executes on first page load - and what changes after a user makes a consent choice?”
That’s not because teams don’t care. It’s because modern sites are assembled from moving parts: plugins, tag managers, embedded widgets, A/B tools, CDN scripts, marketing pixels, chat tools - and they change constantly. Over time, the site becomes a system that behaves, but is no longer understood.
And this is where compliance breaks down, not at the banner layer, but at the runtime layer: pre-consent execution happens by default, and nobody can reliably prove what fired, when, and why.
“The web’s privacy failure is operational drift at scale.”
When we ran our July 2025 <a href="https://aesirx.io/blog/aesirx/36000-danish-business-websites-just-violated-gdpr" target="_blank" rel="noopener">privacy scan of 36.496 Danish business websites</a>, the most important takeaway wasn’t “people wrote bad policies.” It was that at scale, the web behaves like an un-audited runtime - and the measurements showed a high rate of risk and pre-consent third-party loading patterns at ~73% of the scanned sites. That’s not a Denmark or EU-only phenomenon; in our VN work, we repeatedly see the same failure modes, often at higher baseline rates (~90%).
So the question isn’t “how do we write better privacy policies?” It’s: how do we continuously align what the site does with what the site claims - without turning every change into a manual forensic exercise?
That’s the kind of job functional AI is good at: narrow scope, repeatable checks, measurable before/after outcomes - and no need for surveillance.
<img src="https/api.aesirx.io/images/images/functional-ai-is-the-opposite-of-surveillance-ai.png" alt="functional ai is the opposite of surveillance ai" width="942" height="619" />
<h2>Functional AI is the opposite of surveillance AI</h2>
If AI is broad, hungry, and “always learning,” it tends to push toward extraction. That’s the business model of surveillance: more inputs, more profiling, more inference, more risk.
Functional AI is narrow by design: fixed job, bounded permissions, explainable changes, verifiable outcomes.
The point isn’t to be impressive. The point is to be reliable
“Functional AI isn’t smaller ambition - it’s bigger responsibility.”
And there’s a sustainability angle too: broad models running everywhere invite wasted compute. Functional AI is inherently more “energy honest” - because it doesn’t need infinite context to do a single job well.
Now combine those ideas with the consent compliance problem: you don’t need an AI that can philosophize about privacy. You need one that can do a boring, critical workflow consistently.
Which leads to a practical definition of “useful AI” for websites:
Show me what loads before consent. Show me what loads after consent. Help me align configuration and documentation with what actually happens.
That’s the concept behind our AI Privacy Advisor.
<h2>The AI Privacy Advisor: making compliance observable</h2>
Consent compliance fails when it becomes a document-only exercise. “Functional AI” changes the approach: it treats compliance as system state. It’s essentially a before/after experiment harness for consent.
The <a href="https://aesirx.io/features/ai-privacy-advisor">AI Privacy Advisor</a> workflow is straightforward and intentionally limited:
<ul>
<li aria-level="1">Scan the site before consent to detect third-party requests, scripts, beacons, and high-risk technologies.</li>
<li aria-level="1">Scan again after consent to see what changes when the user opts in.</li>
<li aria-level="1">propose platform-native controls (in WordPress terms) that can block what must not load pre-consent.</li>
<li aria-level="1">Generate drafts for the required texts (privacy policy sections, cookie/technology declaration, and consent language) based on the observed behavior, not generic templates.</li>
<li aria-level="1">Keep the scope bounded: it’s not “AI that does everything,” it’s “AI that does this job and proves it”.</li>
</ul>
This is also where the WordPress “Agent Skills” direction becomes relevant: the future of trustworthy AI on platforms is “reason → permission → execute → verify.” Privacy is exactly the kind of domain that demands that structure.
And that circles back to why I started this newsletter with my daughter.
<img src="https/api.aesirx.io/images/images/the-ai-privacy-advisor-making-compliance-observable.png" alt="the ai privacy advisor making compliance observable" width="942" height="443" />
<h2>From consent to communication: AI that earns trust</h2>
I’m building privacy tools because the internet has normalized “extract first, explain later.”
But I’m also thinking about AI for the same reason I think about privacy: human dignity.
When <a href="https://ida-marie.io/" target="_blank" rel="noopener">Ida Marie</a> raises her finger, the world treats it like noise because it can’t decode the signal. Functional AI could be the bridge - not by “knowing everything,” but by being trained for a narrow purpose: interpret her signals, help translate intent, and let her be understood.
“Assistive AI and privacy AI share the same moral constraint: the goal is empowerment, not extraction.”
That’s the same ethical structure I want in privacy compliance AI:
<ul>
<li aria-level="1">Do something specific</li>
<li aria-level="1">Do it verifiably</li>
<li aria-level="1">Do it without turning people into telemetry</li>
</ul>
So yes - the AI Privacy Advisor is a product feature. But the deeper idea is broader and, I think, more important:
The future of sustainable AI isn’t bigger. It’s bounded. Bounded in scope, bounded in permissions, bounded in power consumption - and bounded by purpose.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Explore functional AI with bounded scope and verifiable outcomes, and how WordPress and AesirX use it to make privacy compliance observable.

When AI is useful, it’s usually narrow

Discover how narrowly scoped AI delivers measurable value in privacy compliance, and how AesirX and WordPress make consent, data use, and compliance outcomes transparent and auditable.

Narrow AI, Real Results: Making Privacy Compliance Verifiable on WordPress

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR:&nbsp; If your Cookie/Consent vendor is a hosted SaaS that prices by traffic, the vendor must measure traffic. Not after consent. Before. That billing requirement forces vendor-side telemetry at the exact moment the user is supposed to have a choice - which collides with consent-before-collection in the EU/UK, and becomes even sharper in Vietnam under Decree 356 where web behavioral tracking is treated as sensitive data. If your stack needs to “phone home” to bill you, you’re not buying compliance. You’re buying a liability design.
</div>
Most CMP compliance claims collapse the moment you open the Network waterfall.
The real compliance test is not what the banner says. It’s what your site transmits before the user has a choice.
“If your CMP vendor sells ‘compliance’ by the visitor, your compliance starts by violating consent.”
And here is the part agencies, DPOs, and site owners keep missing:
If your consent vendor sells CMP as a hosted SaaS and prices by traffic (visitors/sessions), the vendor must measure traffic.
Not “after consent”. Before. Because you can’t invoice what you can’t count.
That single billing requirement creates a structural conflict with consent-before-collection across the EU/UK - and now even more sharply in Vietnam under Decree 356.
Who this is for: anyone shipping or deploying web-facing code into other people’s sites - CMP vendors, “cookie compliance” SaaS providers, analytics and tag-manager stacks (GA4/GTM, TikTok, Meta, CDPs), and the agencies, DPOs, and site owners who keep inheriting the risk when that code executes before a provable affirmative choice.
<img src="https/api.aesirx.io/images/images/the-billing-telemetry-paradox.png" alt="the billing telemetry paradox" width="942" height="619" />
<h2>Why this is happening: the “billing telemetry” paradox</h2>
A website’s tracking stack is usually optional. A SaaS consent stack is not.
In a typical SaaS CMP deployment:
<ul>
<li aria-level="1">The CMP script is loaded from the vendor’s infrastructure (their CDN / domains).</li>
<li aria-level="1">The vendor needs to enforce plan limits (sessions, visitors, properties, geos, features).</li>
<li aria-level="1">The vendor provides “traffic / consent reporting” dashboards.</li>
<li aria-level="1">The vendor operates the infrastructure that serves the CMP and sees the traffic by design.</li>
</ul>
So even if the banner claims “we only deploy strictly necessary trackers before consent”, the architecture often still involves vendor-side telemetry to:
<ul>
<li aria-level="1">count unique visitors / sessions,</li>
<li aria-level="1">record impressions,</li>
<li aria-level="1">enforce consumption tiers,</li>
<li aria-level="1">power reporting and optimization,</li>
<li aria-level="1">troubleshoot and support the account.</li>
</ul>
That telemetry is data processing.
In practice, vendor telemetry rides on standard HTTP request data (IP, user-agent, device/browser metadata, timestamps, request identifiers) - which is exactly what unique counting and account enforcement rely on.
<img src="https/api.aesirx.io/images/images/that-telemetry-is-data-processing.png" alt="that telemetry is data processing" width="942" height="574" />
<h2>The hard line: “Consent UI” is not “consent-before-collection”</h2>
A compliant flow is brutally simple:
Load nothing that phones home → get a real choice → load only what was chosen → log it first-party.
Most cookie/consent stacks fail because they confuse interface with sequence.
A banner can be beautifully designed and still be non-compliant if the page already:
<ul>
<li aria-level="1">calls third-party domains,</li>
<li aria-level="1">fires pixels,</li>
<li aria-level="1">runs tag managers,</li>
<li aria-level="1">loads analytics libraries,</li>
<li aria-level="1">or transmits telemetry to the CMP vendor itself</li>
</ul>
before the user takes an affirmative action.
<h2>EU reality: ePrivacy Directive 5(3) is technology-neutral&nbsp;</h2>
In the EU, the “cookie rule” is not a cookie rule.
ePrivacy Directive Article 5(3) governs storing or accessing information on a user’s terminal equipment and is interpreted as technology-neutral. Guidance keeps reinforcing that it covers more than classic cookies.
Security logging may be necessary, but it does not turn vendor-side traffic metering/product analytics into ‘necessary’ pre-consent tracking.
So if your “consent” solution itself triggers any non-essential storage/access or similar tracking techniques - directly or indirectly - you are relying on a story regulators have been dismantling for years:
“We displayed a banner, therefore pre-consent data flow is acceptable.”
It isn’t.
<h2>UK reality: PECR still requires consent for non-essential tracking</h2>
The UK structure is similar: PECR requires consent for non-essential cookies and similar technologies (with narrow exemptions). UK GDPR then applies when personal data is processed.
So the same paradox shows up:
If the CMP vendor is collecting telemetry to operate a consumption-priced SaaS, that processing must be justified. And “we’re doing it to bill the customer” is not a magic exemption - especially if it happens before a user can choose.
<img src="https/api.aesirx.io/images/images/decree-356-impact.png" alt="decree 356 impact" width="942" height="494" />
<h2>Vietnam just raised the stakes: Decree 356 turns “web behavioral data” into sensitive data</h2>
This is the part most international vendors are not ready for.
Decree 356 (effective 1 January 2026) explicitly lists data tracking behavior and activities in cyberspace services as sensitive personal data.
Read that again.
If your website uses:
<ul>
<li aria-level="1">Google Analytics / GA4</li>
<li aria-level="1">TikTok Analytics / Pixel</li>
<li aria-level="1">Meta Pixel</li>
<li aria-level="1">Google Tag Manager (as the orchestrator)</li>
<li aria-level="1">CDPs and customer event pipelines</li>
<li aria-level="1">session replay / heatmaps</li>
<li aria-level="1">attribution and ad measurement</li>
<li aria-level="1">many fraud / risk tools that profile behavior</li>
</ul>
…you are processing behavioral tracking data in the category the decree calls out.
“At minimum, the collection occurs at the moment the requests/events are generated - not when reports are viewed.”
Which means the usual “this is just analytics” line stops working in Vietnam.
And it gets worse for SaaS stacks: cross-border exposure becomes a first-order risk when the tooling is hosted outside Vietnam and receives Vietnamese visitor data by default through network calls.
<img src="https/api.aesirx.io/images/images/different-purpose-role-mapping-changes.png" alt="different purpose role mapping changes" width="942" height="703" />
<h2>When the vendor’s purpose is not your purpose</h2>
Most teams label the CMP vendor as a “processor” and move on. That shortcut is exactly how non-compliant SaaS consent stacks survive procurement.
Because in a typical hosted CMP model, the vendor isn’t only processing data to deliver your instructions. The vendor also processes visitor data to serve its own independent purposes - and that changes the role analysis.
If the vendor determines purposes such as:
<ul>
<li aria-level="1">traffic-based billing and usage enforcement (counting visitors/sessions/pageviews to invoice and police plan limits)</li>
<li aria-level="1">vendor-side telemetry and product analytics tied to your visitors (service performance, feature usage, “banner impressions”, debugging)</li>
<li aria-level="1">vendor reporting/optimization driven by visitor events (dashboards, benchmarking, experimentation)</li>
</ul>
…then the vendor is not just “your processor” in the narrow sense. The vendor is making decisions about why certain data is collected and how it is used for the vendor’s business operations.
That is the hallmark of (at minimum) joint controllership for those specific processing purposes.
“When the vendor’s purpose is not your purpose, ‘processor’ becomes a shortcut”
And this is where the liability sits:
<ul>
<li aria-level="1">A SaaS CMP vendor that collects or receives personal data for its own purposes cannot hide behind “we’re just a tool.”</li>
<li aria-level="1">Contract language that tries to push everything onto the website owner does not change the factual question regulators ask: who decided the purposes and essential means of processing?</li>
<li aria-level="1">If the vendor’s infrastructure receives data pre-consent to support the vendor’s own metering/telemetry/reporting, then the vendor carries direct accountability for that processing.</li>
</ul>
Joint controllership applies at least to the vendor’s independent purposes (metering/telemetry/optimization), regardless of how the rest of the stack is contracted.
“If the vendor’s infrastructure receives data pre-consent for metering/telemetry, the vendor carries direct accountability.”
<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
Last week’s article“<a href="https://www.linkedin.com/pulse/100-per-cookie-new-unit-economics-non-compliance-christiansen-2kzgc/" target="_blank" rel="noopener">€100 Per Cookie: The New Unit Economics of Non-Compliance</a>”, explains why this matters now: courts are starting to price unlawful device-boundary events as compensable harm - and the spotlight lands on the vendor whose code executed before proven consent, not on the banner screenshot.
</div>
The practical takeaway is simple:
If the vendor’s purpose is not your purpose, it is not purely processing “on your behalf.” So the compliance assessment must include: vendor purposes, vendor endpoints called pre-consent, what data is transmitted by default (IP/UA/metadata), and whether those flows can be eliminated by switching to a first-party / self-hosted deployment.
If your CMP cannot operate without “phoning home” first - especially for traffic metering - then you don’t have a consent layer. You have a vendor-operated data collection layer with a banner attached.
<img src="https/api.aesirx.io/images/images/saas-cmps-price-by-consumption-so-the-vendor-must-measure-your-users.png" alt="saas cmps price by consumption so the vendor must measure your users" width="942" height="614" />
<h2>SaaS CMPs price by “consumption” - so the vendor must measure your users</h2>
Here’s the non-negotiable logic: if a consent vendor charges based on traffic, the vendor must be able to count traffic.
“You can’t invoice what you can’t measure.”
That means measurement is not a side feature. It’s a structural requirement of the SaaS business model.
And the market is explicit about this. The biggest CMP vendors publicly price by usage meters like:
<ul>
<li aria-level="1">Average daily visitors (OneTrust)</li>
<li aria-level="1">Sessions (Usercentrics Advanced CMP)</li>
<li aria-level="1">Monthly Unique Visitors (MUV) (Didomi)</li>
<li aria-level="1">Page views per month (consentmanager.net)</li>
<li aria-level="1">Pageviews/month (CookieYes)</li>
</ul>
So when a website loads a hosted CMP script from the vendor, the vendor’s platform is inherently designed to see and meter the full denominator of visitors/sessions/pageviews - not only those who later click “Accept.”
“A usage meter is not a claim - it’s an operational requirement. If the vendor charges on it, the vendor must compute it.”
The only way a traffic-priced CMP avoids pre-consent vendor processing is if metering happens entirely first-party (customer-side) and the vendor never receives visitor-level telemetry before consent - which is not how hosted CMP SaaS is typically delivered.
That’s why “our banner says we don’t do anything before consent” is not the test. The test is whether any data is processed/disclosed before the user has a choice - and consumption pricing makes that risk predictable.
<img src="https/api.aesirx.io/images/images/traffic-metered-cookie-consent-vendors.png" alt="traffic metered cookie consent vendors" width="942" height="614" />
<h2>The only pattern that scales across EU/UK/VN</h2>
If you want a setup you can defend in audits, procurement, and disputes:
<ul>
<li aria-level="1">CMP must run first-party (your domain / your storage / your infrastructure)</li>
<li aria-level="1">no third-party calls before consent (not just “no cookies”)</li>
<li aria-level="1">consent logs stored first-party (not in the vendor’s cloud as the default)</li>
<li aria-level="1">optional: on-prem / local hosting where cross-border exposure matters (like the VN Data Law)</li>
</ul>
This is not ideology.
It’s risk control.
“Consent is not UI. Consent is runtime. If you can’t prove the boundary, you don’t have compliance.”
<h2>Check what your site does before the user chooses</h2>
If you’re an agency: stop inheriting your clients’ liability. Make “no third-party calls before consent” a non-negotiable delivery standard.
If you’re a DPO/lawyer: audit the network waterfall, not the banner text.
If you own the site: scan your site and look at what loads before any click.
If you want to check if your (or your clients’) website is collecting data prior to consent, use our <a href="https://aesirx.io/services/privacy-scanner" target="_blank" rel="noopener">free privacy scanner</a> to test it.
Thanks to everyone pushing this debate forward. We need far more awareness of technical compliance - not just legal theory or banner screenshots. The fastest way to raise the bar is simple: measure what actually loads before consent, then fix the architecture - not the wording.
Have you ever audited your CMP in DevTools before clicking anything?
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Why traffic-based cookie and consent tools require pre-consent measurement, creating structural conflicts with consent-before-collection rules.

Your Cookie Solution Is Not Compliant

Your Cookie Solution Is Not Compliant - Because the SaaS Business Model Can’t Be

Why traffic-based cookie and consent tools inherently rely on pre-consent measurement, creating unavoidable conflicts with consent-before-data-collection requirements.

Why Most Cookie & Consent Tools Are Not Compliant

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR: A German court just put a unit price on unlawful device access: €100 per cookie. That turns “compliance” into unit economics and makes vendor liability scalable. If your SaaS model depends on pre-consent telemetry, billing pings, or “cookie-less” measurement that still runs client-side, you’re not selling compliance - you’re selling liability.
</div>
A German court just did something that will quietly reshape the web-facing technology market.
It didn’t “warn publishers to fix their banners.” It didn’t “remind websites to update their policies.” It didn’t reward the industry’s favorite scapegoat: the messy implementation by someone else.
It put the spotlight where it belongs: on the vendor whose code touched the user’s device without proven consent.
One unlawfully set cookie triggered €100 in non-material damages (<a href="https://www.rv.hessenrecht.hessen.de/bshe/document/LARE260000013" target="_blank" rel="noopener">Higher Regional Court of Frankfurt's December 11 ruling, court ref. 6 U 81/23</a>). The number is small enough to look harmless - until you understand what it does to incentives once it becomes repeatable.
A systemic defect is never “one cookie.” A systemic defect is a pattern. And patterns scale.
So the question I want every agency, MarTech lead, DPO, and SaaS vendor to sit with is not “is €100 a lot?”
It’s this:
If a defect is provable on a site with a million visitors, what does the liability ceiling look like the moment claims become industrialized?
“€100 isn’t the story. The story is that vendor liability is now economically legible.”
Who this is for: anyone distributing client-side code into other people’s websites - CMP vendors, analytics vendors (including “cookie-less”), attribution and personalization tools - and the web agencies/implementers and DPOs who inherit the risk when that code fires pre-consent.
<h2>Germany didn’t produce one signal. It produced a cluster.</h2>
If this were only one Frankfurt ruling, the industry would do what it always does: call it an outlier, wait for appeal, and keep shipping.
But late 2025, Germany didn’t produce a single datapoint. It produced a pattern of court artifacts that all point in the same direction: courts are increasingly willing to price “loss of control” and “feeling of surveillance” as compensable harm - and they’re increasingly willing to treat web-facing vendors as responsible actors when their technology crosses the device boundary - any execution/caching/network instruction that happens - without proven consent.
Frankfurt is the cleanest hook because it’s so legible: €100 for one unlawfully set cookie. Not a regulator fine. A civil damages award that makes unit-economics risk obvious. When a court is comfortable attaching money to a single terminal-equipment event, the entire game changes - because now systematic defects can be turned into systematic claims.
Then you have Munich. Two decisions in December 2025 - both awarding non-material damages (one at €750&nbsp;<a href="https://openjur.de/u/2540283.html" target="_blank" rel="noopener">OLG München, Urteil vom 18.12.2025 – 14 U 2300/25 e</a>, one at €500 <a href="https://openjur.de/u/2540287.html" target="_blank" rel="noopener">OLG München, Endurteil vom 18.12.2025 – 14 U 1314/25 e</a>) in a major “tools” context - reinforcing that courts are not treating this as harmless technical trivia. They’re treating it as a fundamental rights issue with real compensable impact, and they’re comfortable doing it at amounts that immediately change risk calculations for vendors and platforms.
Read that again: within weeks, multiple higher regional courts are handing out damages for covert or uncontrolled tracking-style mechanisms. Different fact patterns, same message.
So if you are a CMP vendor, an analytics vendor, or any “X-as-a-Service” vendor shipping client-side logic into other people’s pages: stop waiting for the perfect legal safe harbor. The courts are already telling you what they will reward and what they will punish.
They will reward systems that can prove a valid boundary existed before the device was touched.
They will punish systems that rely on “we told customers to do the right thing” after the boundary was crossed.
“Germany didn’t just warn the market. It started pricing the intrusion - and the bill lands on vendors.”
<img src="https/api.aesirx.io/images/images/the-old-shield-is-falling.png" alt="the old shield is falling" width="942" height="619" />
<h2>The industry’s old shield is failing: “the customer is responsible”</h2>
For years, vendors protected themselves with a sentence that sounds reasonable until you look at the runtime:
“Publishers are responsible for obtaining consent.”
But a browser doesn’t read your contract.
Your script doesn’t pause because a PDF says “customer must comply.”
A tag fires when it can. An SDK sends events when it’s instructed to. A pixel calls home when it’s loaded. And if the design allows that to happen before a valid user choice exists, the legal risk is not “downstream.” It’s upstream - baked into the product.
This is the key shift: courts are beginning to treat consent not as UI, but as a technical boundary. If the boundary is crossed, “we told customers to do the right thing” stops being persuasive.
Because what the user experiences is not your contractual allocation of responsibility. What the user experiences is your code executing on their device.
“Your JavaScript doesn’t read your contract. Courts are starting to notice.”
<h2>Should every web-facing vendor be nervous?</h2>
It’s tempting to file this under “AdTech problems.”
That’s a mistake.
The same liability logic is relevant anywhere a vendor supplies client-side logic that interacts with a device, measures behavior, or transmits data off-site.
Consent vendors. Analytics vendors. Heatmaps. A/B testing. Personalization. Fraud tooling. “Performance monitoring.” Even “privacy-friendly” measurement stacks.
Because the risk is not “whether you call yourself privacy-first.” The risk is whether your system can be made to cross the device boundary without valid consent and without provable accountability.
And that brings me to the most persistent myth in web privacy.
<h2>The most dangerous sentence in analytics marketing: “we don’t use cookies, so consent isn’t required”</h2>
This week, Plausible Analytics chimed in on <a href="https://x.com/PlausibleHQ/status/2009535726107677010?s=20" target="_blank" rel="noopener">a thread on X</a> with what is probably the most common positioning in the “privacy-friendly analytics” category:
<ul>
<li aria-level="1">We don’t store or access information on the user’s device</li>
<li aria-level="1">We don’t use cookies or persistent identifiers</li>
<li aria-level="1">We only produce aggregated statistics after the request reaches our servers</li>
<li aria-level="1">Therefore, Article 5(3) isn’t triggered and explicit consent isn’t required</li>
</ul>
This is exactly the type of claim that sounds clean, simple, and “engineer-friendly.”
It’s also exactly the type of claim that breaks when you apply modern technical reality and current regulatory thinking.
Because privacy compliance is not a vibe. It’s not a blog post conclusion. It’s not a legal memo that relies on a simplified technical premise.
Privacy compliance is a property of what actually happens in the browser - including execution, caching, network calls, and the fact that modern tracking is not limited to “cookies.”
“Cookie-less is not consent-less - and it’s definitely not liability-less.”
<h2>The technical reality many analytics platforms try to skip</h2>
When you ship a JavaScript analytics tag, you are distributing executable logic to the user’s device. That logic is cached, executed, and used to instruct the device to make measurement calls. Even if you avoid “persistent identifiers,” you still have a system that:
<ol>
<li aria-level="1">runs on the terminal equipment, and</li>
<li aria-level="1">instructs the terminal equipment to transmit tracking-relevant information back to a server.</li>
</ol>
And this is exactly where a lot of “cookie-less” narratives become fragile.
Because the core legal question is not: “Did you set a cookie?” The core legal question is: “Did your mechanism involve storage/access on the device or instruct the device to send back identifiers or tracking information - even temporarily - as part of measurement?”
That’s why “we only aggregate after the request reaches our servers” is not the escape hatch it sounds like.
Aggregation is what you do after the fact. The trigger is what happens at the device boundary.
And if you want a practical demonstration that this is not just theoretical, look at Plausible’s own documentation push: “Run Plausible as a first-party connection … to bypass adblockers.”
Read that again slowly.
They’re explicitly advising customers to proxy the analytics endpoint through the customer’s domain name to evade user controls - not to change the underlying technical action, but to make it harder for users to block.
Now, I’m not making a moral argument here. I’m making a liability argument:
If your compliance narrative relies on “we don’t do device operations that trigger the rule,” while your own docs promote techniques to bypass blockers that target exactly those device-level operations, you are walking customers into a risk posture while advertising it as safety.
<img src="https/api.aesirx.io/images/images/if-a-privacy-feature-bypasses-user-controls-compliance-is-already-compromised.png" alt="if a privacy feature bypasses user controls compliance is already compromised" width="942" height="262" />
<h2>Even if you debate 5(3), GDPR still applies when the script loads</h2>
Let’s say someone wants to argue endlessly about whether a specific implementation triggers the terminal equipment rule. Fine. You can debate that.
But the moment a browser loads a SaaS analytics script and sends requests, the vendor receives what it receives:
IP address. User agent. Request metadata. Timestamp. URL paths. Referrers. Network identifiers. And in many real deployments, even more.
That is processing. That requires a lawful basis. That requires transparency that matches reality. And it requires you to stop hiding behind language like “anonymous” when what you really mean is “we don’t call it an identifier.”
This matters because vendor liability is not going to be limited to “cookie placement.” It is going to expand through the broader accountability doctrine that courts are increasingly comfortable applying: the party with the clearest visibility and control cannot hide behind the party with the least.
Which brings us to the second German signal that should terrify SaaS vendors.
<h2>The burden-of-proof trap: vendors built systems only they can explain</h2>
The web stack has a structural asymmetry: users cannot see what vendors do behind the curtain.
They don’t know where events go. They don’t know who receives them. They don’t know how they’re joined, retained, enriched, or shared. They don’t know whether “aggregated” means “immediately aggregated” or “event-level stored and aggregated later.”
But vendors know.
And courts are increasingly unwilling to accept “blanket denials” when the defendant is the only party who can provide the specifics.
This is where centralized SaaS becomes a litigation liability: your strongest product advantage - your control and visibility - becomes the reason you can’t shrug and say “not our problem.”
“Your data platform is a product advantage - until it becomes a litigation disadvantage.”
<h2>When the data model is the business model</h2>
Now let’s talk about the thing most people avoid because it cuts too close to how the market makes money.
Consent-as-a-Service. Analytics-as-a-Service. Compliance tooling-as-a-Service. Attribution-as-a-Service. Personalization-as-a-Service.
These models share a structural temptation: to be commercially viable, they want data early, and they want it reliably, even when the user says “no.”
And when vendors feel the law tightening, they reach for the same escape hatch: necessity.
Here’s the problem: under both GDPR and the terminal-equipment rule in ePrivacy Directive (Article 5(3)), necessity is assessed from the user’s (data subject’s) perspective - not the vendor’s business model. “Necessary” does not mean “necessary for product metrics, billing, diagnostics, attribution, or growth.” It means necessary to deliver the service the user actually requested - and only what is strictly required to do that.
So the category invents excuses:
<ul>
<li aria-level="1">“Telemetry for service quality”</li>
<li aria-level="1">“Pings for diagnostics”</li>
<li aria-level="1">“We need it for billing”</li>
<li aria-level="1">“We must measure consent to enforce consent”</li>
<li aria-level="1">“We don’t store identifiers; we only measure”</li>
</ul>
…what they are really saying is: our business model needs pre-consent device operations. And that is not a legal basis. That’s a commercial preference.
This is the core contradiction that vendor liability will expose: you can’t justify pre-consent device operations as “technically necessary” when the only thing that makes them “necessary” is the vendor’s revenue model. If the user said “no,” and your stack still needs to run to make your SaaS work, your product isn’t compliant-by-design - it’s consent-hostile-by-design.
If your revenue depends on data you can’t lawfully guarantee, then compliance cannot be a “feature.” It becomes a direct constraint on the business model. And many vendors respond by quietly making compliance optional in practice while advertising it as default.
That is not a “banner problem.” That is a product-market-fit problem under law.
<img src="https/api.aesirx.io/images/images/when-the-data-model-is-the-business-model-non-compliance-isnt-a-bug-its-revenue.png" alt="when the data model is the business model non compliance isnt a bug its revenue" width="942" height="735" />
<h2>It’s not only the EU. The UK, Norway, and Vietnam are moving the same way</h2>
Germany is simply where the court artifacts are currently the loudest.
But the logic is increasingly consistent across jurisdictions:
<ul>
<li aria-level="1">In the EU, the line between “cookie compliance” and “tracking compliance” keeps collapsing into the broader question: what do you do at the device boundary, and can you prove your basis?</li>
<li aria-level="1">In the UK, the same consent-before-tracking dynamics keep reappearing under PECR and UK GDPR accountability.</li>
<li aria-level="1">Norway’s direction under Ekom reforms moves along the same axis: device-level tracking is a legal boundary, not a marketing choice.</li>
<li aria-level="1">Vietnam is now tightening accountability under PDPL and the implementing environment, and any vendor shipping web-facing tracking or measurement into Vietnamese-facing stacks should assume scrutiny will follow the same path: prove what you do, why you do it, and why it’s lawful.</li>
</ul>
Different statutes. Same future: vendors can’t outsource accountability forever.
<h2>The practical conclusion: treat consent as a runtime boundary, or accept that you’re selling liability</h2>
The industry spent a decade turning consent into a UI problem because UI problems can be “fixed” without changing business models.
But courts are increasingly treating consent as what it always was: a boundary around device access, behavioral observation, and invisible power.
So here is the standard that matters now - the only one that will survive hostile examination:
Can you truthfully say your product is designed so non-compliance is hard, not merely discouraged?
Not in your marketing. Not in your contracts. In the runtime.
Because in the vendor-liability era, the only durable compliance posture is the one you can prove when someone is actively trying to break it.
“Consent is not UI. Consent is runtime. If you can’t prove the boundary, you don’t have compliance.”
Agencies: either you standardize this across every client deployment, or you’ll keep being the last person who “installed liability” and then got paid to clean it up later.
If you want to check if your (or your clients) website is collecting data prior to consent use our <a href="https://aesirx.io/services/privacy-scanner" target="_blank" rel="noopener">free privacy scanner</a> to test it.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Recent German court rulings put a monetary value on unlawful device access, reframing consent as a runtime boundary with direct vendor liability

100 Eur Per Cookie: The Unit Economics of Non-Compliance

€100 Per Cookie: The New Unit Economics of Non-Compliance

Recent German court rulings assign a monetary value to unlawful device access, redefining consent as a runtime boundary and exposing vendors to direct financial liability.

Press and Blogs

POPULAR TOPICS

AesirX Launches ComplianceOne, a Self-Hosted GRC Platform Built for Vietnam’s Regulatory Reality

Market Focus - Regulatory Compliance Vietnam (Part II)

Market Focus - Regulatory Compliance Vietnam

When “we’re compliant” is the problem

Danish E-Commerce Awards 2026

AesirX Launches Analytics Pro for WordPress, Bringing First-Party, Value-Based Measurement to Growing Teams

When AI is useful, it’s usually narrow

Your Cookie Solution Is Not Compliant - Because the SaaS Business Model Can’t Be

€100 Per Cookie: The New Unit Economics of Non-Compliance

Join the AesirX Partner Program

Solutions

Resources

Support

Partnership Opportunities