Legitimate Interest Assessment (LIA) — Template

This page is the customer-facing template of the Legitimate Interest Assessment (LIA) Statnive recommends operators document when running cookieless first-party analytics in the EU on the basis of GDPR Article 6(1)(f). It is structured per EDPB Guidelines 1/2024 on Legitimate Interest of 8 October 2024.

Use this template as a starting point. Adapt it to the operator's specific processing context with qualified counsel in your jurisdiction before publication. A documented LIA is required whenever processing personal data under Article 6(1)(f); it does not replace consent requirements at the ePrivacy Article 5(3) terminal-equipment layer where those apply.

Step 1 — Identification of the legitimate interest

Controller: [operator name and registered address]

Interests pursued:

• Functional: operating, improving and securing the controller's website — a recognised legitimate interest under CJEU C-582/14 Breyer paras. 60–64 (19 October 2016).
• Commercial: measuring audience and content engagement — recognised under CJEU C-621/22 KNLTB paras. 47–49 (4 October 2024, ECLI:EU:C:2024:857), which confirmed that purely commercial interests can be legitimate under Article 6(1)(f) provided they are lawful.

Lawfulness check:

• No breach of EU or Member-State law.
• No Article 9 special-category data processed.
• No automated profiling within the meaning of Article 22.
• Interests are clearly articulated, real and present.

Step 2 — Necessity

Audience measurement cannot reasonably be achieved by less intrusive means while still producing the metrics needed for product and business decisions. Minimisation measures already applied:

• No persistent device identifier (no cookie, no localStorage, no fingerprinting).
• Daily-rotating, site-scoped BLAKE3-HMAC visitor signature; previous day's salt destroyed at rotation.
• Raw IP address discarded before storage; only the truncated network portion (IPv4 /24, IPv6 /48) is retained briefly for geolocation.
• User-Agent reduced server-side to device + major-browser-version + major-OS-version; raw UA string discarded.
• Referrer reduced to the host portion only; query strings never enter persistent storage.
• Aggregation to nearest 10 in dashboards (per CNIL Sheet n°16 recommendation).
• 25-month maximum data retention; automatic deletion via 750-day TTL on rollup tables.

Alternatives considered:

• Consent-gated analytics — rejected as the primary path because the resulting measurement loss (per Plausible's cookie-banner study, approximately 55.6% of visitors decline or close the banner) defeats the necessity of the measurement.
• Raw access logs — rejected because raw IPs introduce higher re-identification risk than the daily-salted-hash scheme.
• No analytics at all — rejected because audience-measurement data is necessary to operate and improve the service.

Step 3 — Balancing test

Data-subject interests: Charter Article 7 (respect for private life) and Article 8 (protection of personal data).

Nature of the data: Indirect identifiers (hashed signatures, truncated IP-derived geolocation, reduced User-Agent) that become effectively irreversible at end of day due to salt destruction. Per the draft EDPB Guidelines 01/2025 on Pseudonymisation (adopted as draft 16 January 2025), these remain personal data when re-identification is reasonably likely; the daily salt rotation puts them at the low-risk end of the pseudonymisation spectrum.

Reasonable expectations: A visitor expects the operator to know aggregate visit counts and page popularity, not individual cross-day or cross-site surveillance. The architecture matches that expectation by construction.

Impact on the data subject:

• No behavioural advertising.
• No profiling.
• No third-party data sharing.
• No decisions affecting the data subject.
• No cross-site or cross-day visitor tracking (salt rotation prevents both).

Mitigations:

• Salt destruction at end of day.
• IP truncation at ingest before any storage.
• Retention cap (25 months) with automatic deletion.
• Article 21 right-to-object endpoint exposed at POST /api/privacy/opt-out.
• Article 15 right-of-access endpoint at GET /api/privacy/access.
• Article 17 right-to-erasure endpoint at POST /api/privacy/erase.
• Article 28 Data Processing Agreement in place where applicable — see the DPA template.
• EU-only data residency (Nuremberg, Germany).
• GPC and DNT honoured at the ingest layer.
• Open-source code paths for self-hosted deployments.

Conclusion: The legitimate interests pursued are not overridden by the data subject's rights and reasonable expectations. Processing is lawful under GDPR Article 6(1)(f).

Review cadence

This LIA is reviewed at minimum annually, and on any material change to:

• The data Statnive processes (new fields, new event types).
• The applicable case-law (e.g., a CJEU referral that affects the Breyer or IAB Europe analysis).
• National regulator guidance (CNIL, DSK, Garante, AEPD, AP, ICO publications).
• EU legislative developments (notably the Digital Omnibus COM(2025) 837 proposal).

Country-specific layers

This LIA covers the GDPR Article 6 lawful-basis layer. The ePrivacy Article 5(3) terminal-equipment-access layer is governed separately by national transpositions and is addressed by Statnive's consent-free architecture (no terminal-equipment storage or access happens). For jurisdiction-specific notes, see:

• France — CNIL Sheet n°16 audience-measurement exemption
• Germany — § 25 TDDDG server-side-only constraint
• Country-by-country map (IT, ES, NL, BE, IE, UK, AT)

Disclaimer

This template is privacy research, not legal advice. Every Statnive customer remains the data controller and is responsible for its own LIA and DPIA. Cross-reference this template with qualified counsel in your jurisdiction before publication on your site or before relying on it in a regulator inspection.

Questions

For questions on the LIA template or on adapting it to a specific deployment, contact support@statnive.com.