Designed for GDPR from the architecture up
How we design for GDPR, ePrivacy, and Schrems II without resorting to creative legal interpretations — a self-assessment, not a certification, and what we explicitly do not claim.
Most analytics vendors meet GDPR by adding things — consent banners, cookie disclaimers, processing agreements, sub-processor lists, transfer impact assessments. The compliance budget grows. The product stays the same.
We took the opposite route. The product was designed for GDPR from the architecture up, so the approach is structural — there is no personal data to disclose, no cookie to consent to, no cross-border transfer of visitor data to justify. The compliance work lives in the architecture, not in an overlay on top of it. That is our own assessment, not a certification.
This chapter is written for DPOs, legal teams, and procurement leads — the people who have to sign that everything checks out. The signable artefacts live at /security; this is the reasoning behind them.
Designed for GDPR from the architecture up, not by permission
GDPR distinguishes six lawful bases for processing personal data: consent (Art. 6(1)(a)), contract, legal obligation, vital interests, public interest, and legitimate interest (Art. 6(1)(f)).
The default route in analytics is consent — the user agrees to be tracked, the cookie fires, the data is processed. This is what GA4 requires. It is also what fails: in our experience with clients, between 40% and 60% of traffic doesn’t accept cookies (see chapter 03). Stack ad blockers and browser restrictions on top, and the measurable population shrinks further, by an amount that depends on the store.
Sealmetrics stores nothing on the device and no data that identifies anyone. What we report is aggregate event data — a request hit /product-X, originated from a referrer, on a device for which we keep no persistent identifier. The session identifier rotates daily and, once rotated, not even we can reconstruct it. During the day it is a pseudonym, and pseudonymised data is still personal data under GDPR, so it needs a lawful basis.
For the session identifier (pseudonymised on the server with a salt that rotates daily, used to group the hits of a visit for last-click attribution), the lawful basis is Article 6(1)(f) — legitimate interest in measuring a customer's own website. The Legitimate Interest Assessment (LIA) is documented in the DPA package.
The Spanish AEPD has published a framework specifically for cookieless analytics under legitimate interest. The French CNIL maintains an equivalent self-assessment for measurement tools that operate without consent (the “exempted measurement” framework). Sealmetrics is built to satisfy both. Where you have a DPO, these are the documents they will ask about.
ePrivacy and the cookie question
GDPR governs personal data. ePrivacy governs access to terminal equipment. They overlap but they are not the same regulation, and a tool can be GDPR-clean while being ePrivacy-dirty.
ePrivacy Article 5(3) is the relevant clause. Storing or accessing information on a user's terminal equipment requires prior consent — unless it is strictly necessary for a service the user requested.
Cookies trigger Article 5(3). So do localStorage, sessionStorage, IndexedDB, the Cache API, and — crucially — fingerprinting techniques that read back terminal information. ePrivacy does not care whether the data is personal; it cares whether the technique accesses the terminal.
Sealmetrics stores nothing on the terminal: no terminal storage is set, no terminal storage is read. The pixel sends a single HTTPS POST with the event payload. To group the hits of a visit, it does read a few browser characteristics — user agent, time zone, languages, screen size, colour depth, colour-scheme and motion preferences, CPU cores, device memory — and hashes them with the site's account ID. Before any use, the server replaces that hash with a keyed hash salted daily, and the previous salt is deleted, so the value cannot be linked across days or across sites. IPs are not stored. Canvas, audio context, font lists and plugin lists are never collected. That reading is limited to the site's own audience statistics, with no cross-site tracking and no reuse: the case the audience-measurement exemption from Article 5(3) covers.
"Nothing is stored on the terminal, and what is read serves only the site's own audience statistics, with an identifier that rotates daily. No consent banner is required for measurement."
The legal-and-product boundary that produces this conclusion is the same one chapter 09 covers from the product-design side. Engineering and legal arrived at the same line independently.
Schrems II and data transfers
Schrems II (Court of Justice EU, July 2020) invalidated the Privacy Shield framework that previously legitimised US-based processing of European personal data. Post-Schrems II, transferring personal data to the United States — including via US cloud sub-processors — requires Standard Contractual Clauses (SCCs) plus a Transfer Impact Assessment (TIA) demonstrating that US surveillance laws do not compromise the data subject's rights.
In practice this is impossible to demonstrate for most setups. The US Cloud Act, FISA Section 702, and Executive Order 12333 give US authorities broad access to data held by US companies regardless of where the servers physically sit. The Data Privacy Framework — Privacy Shield's successor — is currently being challenged on the same grounds.
Sealmetrics avoids this entirely. All visitor-data processing — pixel ingestion, validation, attribution, storage — runs in owned infrastructure in Dublin, Ireland. Zero US sub-processors for the data plane. No AWS, no Google Cloud, no Snowflake. CDN edge sits on EU/UK PoPs operated by EU providers. See chapter 05 for the infrastructure detail.
The corresponding TIA is not a defensive document we write to justify a decision. There is no visitor-data transfer to assess.
DPA and TPSR package
Before the document set, a side-by-side that DPOs tend to ask for early — what GA4 needs to remain compliant for an EU eCommerce deployment, versus what Sealmetrics needs.
Every Scale plan ships with a Data Processing Agreement (DPA), signed before any data flows. We are the data processor; you are the controller. The DPA covers scope of processing, the lawful basis (legitimate interest, where applicable), categories of data, the sub-processor list (zero outside the EEA on visitor data), technical and organisational measures, data-subject rights handling, and breach notification timelines.
Alongside, we ship a Third-Party Security Review (TPSR) package — the document set procurement and security teams typically request. It is bundled, not bespoke per customer:
- Information security policy summary
- Technical and organisational measures (TOMs)
- Sub-processor list, with separate disclosure for EEA-only processors
- Penetration test report (current cadence: annual)
- Incident response plan
- Business continuity and disaster recovery summary
- Records of Processing Activities (ROPA) excerpt
- Legitimate Interest Assessment (LIA) for the relevant processing
Sent under NDA at the start of a procurement evaluation. Most of it is already on /security if you want a head start before the NDA.
Continue with chapter 07 — How we price.
Was this chapter useful? Tell us →