GDPR and CDNs: keeping European data in Europe
A CDN sits between your visitors and your site, which means it handles their data. What GDPR actually asks of you, why the transfer question is the awkward one, and the short way to avoid it.
"Do I need to mention my CDN in my privacy policy?" is one of those questions where the honest answer is yes, it takes one sentence, and the reason it takes one sentence is worth understanding — because the same reasoning decides several other things you probably have not thought about.
Here is the reasoning. Every request to your site passes through your CDN. A request carries an IP address. Under GDPR, an IP address is personal data — this was settled by the Court of Justice in Breyer back in 2016, on the grounds that it can be combined with other information to identify someone. Therefore your CDN processes personal data on your behalf, which makes it a processor and you a controller, and controllers have specific obligations toward their processors.
None of which is dramatic. But it does mean a few concrete things.
This is a practical overview written by engineers, not legal advice. If you handle health data, financial data or anything else in a special category, talk to someone qualified — the general shape below still applies, but the details will not be enough.
What you actually need in place
A data processing agreement
Article 28 requires a written contract between controller and processor. Every serious CDN publishes a standard DPA; you usually accept it in your account settings or it forms part of the terms you already agreed to. The thing to check is that it exists, that you know where it is, and that it lists sub-processors — the parties your CDN in turn relies on, which are also processing your visitors' data.
That sub-processor list is the part people skip and the part that matters. A provider whose stack quietly depends on infrastructure in three other jurisdictions has given you three more transfer questions to answer.
A lawful basis, and a sentence in your privacy policy
Using a CDN to deliver and secure your site is a textbook legitimate interest, and that is normally the basis relied on — no consent banner required, because this is not tracking. What is required is transparency: say in your privacy policy that a CDN processes requests to deliver content and protect the service, and name it. One sentence.
Note the distinction, because it gets muddled constantly. Delivering your site through a CDN is not a cookie-consent matter. If you also inject analytics or marketing scripts through that CDN, those need consent — not because of the CDN, but because of what the scripts do.
An answer to the transfer question
And this is the one that is genuinely awkward.
Why transfers are the difficult bit
Chapter V of GDPR restricts sending personal data outside the EEA unless the destination provides equivalent protection. For the United States that has been an unusually eventful area of law: Safe Harbor was struck down in 2015, Privacy Shield was struck down in 2020 (Schrems II), and the current framework — the EU-US Data Privacy Framework, adopted in July 2023 — has itself faced legal challenge.
The practical consequence for you is not that transfers are forbidden. It is that any arrangement depending on a particular adequacy decision is depending on something that has been overturned twice in a decade. Building your compliance story on it means revisiting that story whenever the legal ground shifts, which it does.
A global CDN routes requests to whichever edge is nearest. Without configuration, a European visitor's request can be handled anywhere in that network, which means the transfer question applies to your ordinary day-to-day traffic rather than to some backup process you can reason about separately.
The short way out
You can avoid the entire discussion by not transferring. If European visitors are served by European edge servers and your origin is in Europe, the data never leaves the EEA, Chapter V never engages, and you do not need to track the current status of any adequacy decision.
It is worth being precise about what "European" has to cover, because there is more than one leg:
- The edges serving your traffic. The obvious one.
- Where logs are stored and processed. Frequently a different system in a different place from the edges themselves.
- Where the control plane and support tooling run. If support staff outside the EEA can view request logs, that is a transfer.
- Every sub-processor. Back to that list — the chain is only as European as its weakest link.
Collect less and the problem shrinks
Data residency answers "where", but GDPR also asks "how much", and Article 5's minimisation principle is the cheapest compliance win available to you.
Truncating or hashing IP addresses in logs, keeping request logs for days rather than years, and not retaining fields you never query all reduce your exposure without costing you anything you were using. It also makes a breach notification a much shorter conversation, since you cannot leak what you did not keep.
The checklist
| Item | Status |
|---|---|
| DPA in place with your CDN provider | Required |
| Sub-processor list read and understood | Required |
| Privacy policy names the CDN and why | Required |
| EU visitors served from EEA edges | Strongly recommended |
| Log storage and support access also in the EEA | Strongly recommended |
| IP anonymisation in logs | Recommended |
| Log retention set to something short and deliberate | Recommended |
| Transfer mechanism documented, if any data leaves | Required if applicable |
Frequently asked questions
Is a CDN GDPR compliant?
A CDN can be, but compliance is a property of how you use it rather than of the product itself. You need a data processing agreement with the provider, a lawful basis — normally legitimate interest — a mention in your privacy policy, and either a valid transfer mechanism or an arrangement where European traffic stays within the EEA. The same CDN can be compliant for one customer and not for another.
Is an IP address personal data under GDPR?
Yes. The Court of Justice of the European Union confirmed in Breyer in 2016 that a dynamic IP address constitutes personal data when the holder has means reasonably likely to be used to identify the individual, for instance by combining it with information held by an internet provider. Because every HTTP request carries an IP address, any CDN handling your traffic is processing personal data.
Do I need cookie consent to use a CDN?
No. Delivering and securing your website through a CDN relies on legitimate interest, not consent, and does not require a cookie banner. Consent obligations arise from what you place on the page — analytics, advertising or marketing scripts — regardless of whether those are delivered through a CDN. Serving your own site's files faster is not tracking.
Does using a US-based CDN break GDPR?
Not automatically, but it means your compliance depends on a transfer mechanism such as the EU-US Data Privacy Framework or standard contractual clauses. The difficulty is durability rather than legality: the two previous frameworks, Safe Harbor and Privacy Shield, were both invalidated by the courts, and the current one has been challenged. Keeping European traffic on European edges removes that dependency entirely.
What is a DPA and do I need one with my CDN?
A data processing agreement is the written contract Article 28 of GDPR requires between a controller and any processor acting on its behalf, setting out what the processor may do with the data and what safeguards apply. You need one with your CDN. Most providers publish a standard DPA that is either accepted in account settings or incorporated into their terms of service, and it should list their sub-processors.
What is data residency and why does it matter for a CDN?
Data residency means controlling the geographic location where data is stored and processed. For a CDN it matters because requests are routed to the nearest available edge by default, so a European visitor's data may be handled outside the EEA unless the network is configured otherwise. Constraining traffic to European edges keeps the data within EU jurisdiction and removes the need for a transfer mechanism.
The summary is less alarming than the topic sounds. Sign the DPA, read the sub-processor list, add a sentence to your privacy policy, keep European traffic on European infrastructure, and log less than you think you need. That covers the great majority of it, and — unlike a transfer mechanism — none of it stops being true when a court rules again.
See how NordicCDN does this for your site:
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
