GDPR by architecture

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 so that GDPR compliance is structural — there is no personal data to disclose, no cookie to consent to, no cross-border transfer to justify. Compliance is the architecture, not an overlay on top of it.

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 and /dpa; this is the reasoning behind them.

GDPR by architecture, 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: 55% of EU users reject consent (see chapter 03), and the measurable population narrows to roughly 13% of real traffic.

SealMetrics does not rely on consent because there is no personal data to consent to. What we measure is aggregate event data — a request hit /product-X, originated from a referrer, on a device whose fingerprint we do not collect. There is no identifier that resolves to a person. The data is not personal data within the meaning of GDPR Article 4(1). Therefore none of Article 6's lawful bases applies — because Article 6 concerns personal data, and we do not process any.

For the narrow set of fields where pseudonymisation is technically possible (e.g., a visit-scoped ID used for last-click attribution within a single visit, then discarded), 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.

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 does none of these. The pixel sends a single HTTPS POST with the event payload. No terminal storage is set, no terminal storage is read. The user-agent string is parsed server-side and immediately generalised to browser family plus major version. IPs are not stored. Canvas, audio context, font lists, screen resolution, plugin lists — none are collected.

"There is no terminal access. Article 5(3) does not apply. 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 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 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), 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.