GDPR-compliant edge logging — keeping the audit trail without leaking the personal data

A security edge is a data-protection problem too

Any WAF worth running keeps logs — you cannot investigate an incident, tune a rule, or prove what was blocked without them. But those logs are a record of real people’s requests: IP addresses, URLs, user-agents, sometimes headers that carry identifiers. Under GDPR that is personal data, and where it lives, how long it lives, and who can reach it are not implementation details. They are legal obligations. A security product that ignores them is trading one risk for another.

Smart WAF is built EU-first, and the logging is designed around the regulation rather than retrofitted to it. That is a deliberate positioning against the incumbents whose “global” platforms route your traffic — and your logs — through jurisdictions you did not choose.

Data residency is the default, not an add-on

Our edge nodes run in the EU (Hetzner, OVH, Scaleway), and request logs stay in the region. There is no US control plane quietly receiving a copy, no “global” analytics backend outside EU jurisdiction. For a European business, or anyone serving European users, that removes the hardest part of a security-vendor data-protection assessment: the transfer question. Data generated in the EU is processed and stored in the EU.

This matters beyond GDPR the checkbox. Data-sovereignty concerns — which government can compel access to your logs — turn on jurisdiction, and jurisdiction turns on where the data physically sits and who operates it. EU residency is a concrete answer, not a policy promise.

The audit trail is immutable — and that is the point

Every configuration change and every security decision is written to an immutable, append-only audit log. Append-only is a specific technical guarantee: records can be added but not edited or silently deleted, so the trail cannot be rewritten after the fact — not by an attacker who gets in, and not by us. When you need to show what a rule blocked, when a policy changed, or who changed it — for an incident review, a customer, or a regulator — the record is defensible precisely because it could not have been tampered with.

That immutability is what makes the log useful for tuning false positives and for documenting a virtual patch: the evidence is trustworthy.

Retention and deletion you actually control

GDPR data-minimization means you should not keep personal data longer than you need it, and individuals have a right to have their data erased. So:

• Retention is configurable. You set how long request logs live rather than accepting a fixed vendor default, so you can align retention with your own data-protection policy.
• The right to deletion is supported. When you need to remove a data subject’s records, that is a supported operation, not a support-ticket negotiation.
• Multi-tenant isolation is structural. Every log record is scoped to a tenant, so one customer’s data is never visible to another — isolation is enforced in the data model, not by a filter someone might forget to apply.

What we don’t claim

We are not going to wave a certification badge at you — GDPR alignment is about how the system actually handles data, and a logo does not prove that. We describe the mechanisms: EU residency, append-only logging, configurable retention, supported deletion, tenant isolation. We also do not claim logging is free of trade-offs; more retention means more forensic depth and more data to protect, and that balance is yours to set, deliberately. None of this compromises the request path — logging happens out of the hot path, so it never touches our ≤5 ms design budget.

Keeping the trail and the compliance

If EU data residency and a defensible, honest audit trail are requirements and not nice-to-haves, that is exactly what this edge is built for. Tell us your domain or read about our approach to trust.