Schrems II Compliance

Disclaimer: The information below is not legal advice, and we don't accept any legal liability. We have received our own legal advice, and this page is our interpretation of the law. If you have any concerns regarding Schrems II compliance, please forward this page to your legal team.

What is Schrems II?

In July 2020, the Court of Justice of the European Union (CJEU) invalidated the EU-US Privacy Shield framework in a ruling known as Data Protection Commissioner v Facebook Ireland Limited, Maximillian Schrems, commonly called Schrems II. The Privacy Shield had been the primary legal mechanism that thousands of companies relied on to transfer personal data from the EU to the United States. With it gone, those transfers became legally precarious overnight.

The core concern is this: the US government, under laws such as FISA 702 and Executive Order 12333, can compel US-owned companies to hand over data stored on their infrastructure, even if that infrastructure is physically located inside the European Union. A server in Frankfurt owned by Amazon Web Services is still subject to US government orders. The data doesn't leave Germany, but the US government can get to it. Under Schrems II, that is not GDPR-compliant.

The ruling applies to any transfer of personal data about EU data subjects to a third country without adequate protections. Under the GDPR, an IP address is personal data. Any system that processes a raw IP address from an EU visitor on US-owned infrastructure is, unless adequately addressed, non-compliant with Schrems II.

The problem this creates for analytics providers

Most analytics infrastructure runs on US cloud providers. AWS, Google Cloud, DigitalOcean, Cloudflare, Linode: all US-owned. Deploying in an EU region does not solve the legal problem. The physical location of the server is irrelevant if the company that owns and operates it is subject to US surveillance law.

This is the mistake many analytics companies make: they deploy in Frankfurt or Amsterdam, declare themselves "EU-hosted," and consider the matter closed. It isn't. The data may not cross a border, but a US government order can compel access to that EU server, and the data subject (your website visitor) has no recourse.

The correct solution requires processing EU personal data exclusively on infrastructure that is:

  1. Physically located in the EU, and
  2. Owned and operated by a non-US entity not subject to US surveillance law.

How Clerion AI addresses Schrems II

Our infrastructure is EU-native by design

Clerion application server runs on Railway, deployed in the Netherlands, a European Union member state. Railway is not a US-owned cloud provider in the same sense as AWS or Google Cloud. Our deployment region is eu-west (Netherlands), and all application-layer processing of incoming tracking events happens on this infrastructure.

When a visitor to your website triggers a tracking event, that request is received and processed by our Netherlands-based server. The raw IP address never leaves EU infrastructure during its brief moment of existence in our processing pipeline.

IP addresses are hashed before anything else happens

The first operation performed on an incoming tracking event (before any database write, before any geo lookup, before any other processing) is IP pseudonymisation. The raw IP address is transformed using HMAC-SHA256 keyed against a server-side secret (IP_HASH_SECRET) that exists only in our EU server's environment. This happens in memory, on the EU server, before anything is persisted anywhere.

The raw IP address is never written to disk, never inserted into the database, and never forwarded to any external service. What is stored is a one-way cryptographic hash. Without the secret key, the hash cannot be reversed. Without brute-forcing every possible IP address against the key (a computation that would cost orders of magnitude more than the global economy), the hash is practically irreversible.

Geolocation is performed via a EU-only endpoint, before hashing discards the IP

Country-level geolocation is resolved via IPLocate.io using their dedicated EU API endpoint:

https://eu-api.iplocate.io/api/lookup/{ip}

IPLocate routes all requests to this endpoint exclusively to servers within the European Union. The IP address is sent to IPLocate solely to retrieve a country code. IPLocate does not retain IP addresses beyond the duration of the API call. A signed DPA with EU Standard Contractual Clauses (SCCs) is available at iplocate.io/legal/dpa and is pre-incorporated into their Terms of Service.

Once the country code is returned, the raw IP address is discarded. What is stored in our database is the country code only, not the IP, not the hash of the IP at this stage. The geo record is attached to the event at a country-level granularity.

The hash salt never leaves EU infrastructure

The IP_HASH_SECRET (the key used to produce the HMAC-SHA256 hash) exists only in the environment variables of our Netherlands-based Railway server. It is not stored in Supabase, not logged, not transmitted to any third party, and not held in any location outside the EU. If our database were compromised, the attacker would have only one-way hashes with no key to reverse them.

Our database is hosted in the EU

Clerion uses Supabase with our project provisioned in the EU region (Frankfurt, Germany, AWS eu-central-1). While AWS itself is a US company, the data stored in our Supabase instance does not contain any personal data as defined under the GDPR:

  • No raw IP addresses.
  • No reversible identifiers linked to individual visitors.
  • Only HMAC-SHA256 hashes (irreversible without the key, which is held separately on EU server infrastructure).
  • Country-level geo codes.
  • Aggregated behavioural data.

The AI layer and Schrems II

Clerion uses Anthropic Claude (US-based) to generate analytics intelligence. Anthropic is a US company and is, in principle, subject to US surveillance law.

However, the data we send to the Anthropic API is aggregate and statistical: page view counts, country-level traffic breakdowns, device type summaries, bounce rate percentages, ranked page lists. It does not contain personal data as defined under the GDPR. It does not contain IP addresses, hashed or otherwise. It does not contain session identifiers, User-Agent strings, or any data point that could be linked to an identifiable individual.

Because no personal data is forwarded to Anthropic, the Schrems II framework, which governs transfers of personal data to third countries, does not apply to this leg of our processing pipeline. We nonetheless maintain a signed Data Processing Addendum (DPA) with Anthropic as a matter of best practice, and Anthropic's DPA explicitly prohibits the use of submitted data for model training. Anthropic's DPA is available at anthropic.com/legal/data-processing-addendum.

The complete data journey for an EU visitor

Here is exactly what happens, in order, when a visitor in the EU triggers a page view on a website using Clerion:

  1. The Clerion tracking script fires a POST request to our server in Netherlands (Railway, EU).
  2. Our server receives the request. The visitor's IP address is available only in memory, on the EU server.
  3. The raw IP is sent to IPLocate's EU-only API endpoint to resolve a country code. The IP is not stored by IPLocate beyond this call.
  4. The raw IP is immediately hashed in memory using HMAC-SHA256 with a secret key that never leaves the EU server. The raw IP is discarded.
  5. The hash and the country code are written to our Supabase database (Frankfurt, EU).
  6. When an AI feature is used, aggregate statistics (counts, percentages, ranked lists) are sent to the Anthropic Claude API. No personal data, no hashes, no IPs.

At no point does an EU visitor's raw IP address leave EU infrastructure. At no point does any personal data about an EU visitor reach a US-owned system.

Conclusion

Schrems II is a serious ruling that much of the analytics industry has responded to inadequately. Pointing to a Frankfurt data centre and calling it compliant is not enough if that data centre is run by Amazon Web Services.

Clerion's approach to Schrems II is built into the architecture. Our application runs on EU-owned infrastructure in the Netherlands. IP pseudonymisation happens at the EU server boundary, in memory, before any data is persisted anywhere. The hash key never leaves the EU. The only US-owned system in our pipeline, Anthropic, receives aggregate statistical data that contains no personal data by any reasonable interpretation of the GDPR.

We believe this is a genuine and defensible Schrems II compliance posture.

Last updated May 2026For questions about our privacy or data practices, contact our team at hello@getclerion.com