Does GDPR require monitoring data to stay in the EU?

GDPR does not require data to physically stay inside the EU, but Chapter V of Regulation (EU) 2016/679 requires that any transfer to a third country provide a level of protection 'essentially equivalent' to EU law. After the Schrems II judgment (C-311/18), the Court of Justice held that transfers to the United States cannot meet that standard on Standard Contractual Clauses alone, because US surveillance law — Section 702 FISA and Executive Order 12333 — overrides contractual safeguards. In practice, the cleanest way to stay compliant for monitoring data is to use an EU-incorporated controller with EU-only sub-processors. That removes the transfer question entirely.

What is the difference between EU hosting and EU jurisdiction?

EU hosting means the servers physically sit in the EU. EU jurisdiction means the legal entity that controls those servers is incorporated under EU law and answers only to EU courts. The US CLOUD Act compels any US-incorporated provider — including their EU subsidiaries — to hand data to US authorities regardless of where the servers are located. AWS Frankfurt, Microsoft Azure West Europe, and Google Cloud europe-west are EU-hosted but not EU-jurisdiction. A monitoring vendor incorporated in Germany, France, or the Netherlands, using infrastructure from a European provider like Hetzner, Scaleway, OVH, or Netcup, gives you both.

Is AWS Frankfurt enough for GDPR-compliant monitoring?

Not on its own. AWS Frankfurt keeps the data physically in Germany, which addresses data residency, but Amazon Web Services Inc. is incorporated in the United States. Under the CLOUD Act, US authorities can serve a warrant on Amazon's US parent and compel disclosure of data held in any region. The EDPB Recommendations 01/2020 list this kind of access risk as the exact scenario where supplementary measures — typically strong customer-managed encryption with keys held outside the US — are required. For most monitoring workloads, those measures are impractical, since the vendor needs to read response bodies and incident metadata to operate. EU-jurisdiction vendors avoid the problem instead of mitigating it.

What is in scope of GDPR when I monitor my own infrastructure?

More than most teams assume. Alert targets — the email addresses, phone numbers, Slack user IDs, and webhook URLs your monitoring tool calls — are personal data when they belong to identifiable team members. Incident notes that name responders are personal data. Response bodies captured during a failing check often contain user identifiers, support ticket IDs, or session tokens. Audit logs of who acknowledged an alert are personal data. The monitor URLs themselves are not personal data, but the combination — who reacts to which alerts, on which schedule, for which services — is a behavioural profile that falls squarely within Article 4(1) GDPR. Treat your monitoring tool as a processor under Article 28.

Are SCCs enough after Schrems II?

Standard Contractual Clauses remain valid as a transfer mechanism, but the Court was explicit in C-311/18: SCCs are a contract, and a contract cannot bind a non-party government. If the data importer is subject to US surveillance law, the SCCs do not provide essentially-equivalent protection on their own. The EDPB Recommendations 01/2020 require a Transfer Impact Assessment (TIA) and supplementary measures — typically technical, such as end-to-end encryption where the importer never sees plaintext. For monitoring data, end-to-end encryption is usually incompatible with the service (the vendor must read responses to detect failures). SCCs plus a TIA plus impractical supplementary measures is a worse position than picking an EU-jurisdiction vendor in the first place.

Which monitoring vendors are EU-incorporated?

As of May 2026, the EU-incorporated uptime monitoring vendors include FoundersDeck (Germany, Netcup Nuremberg), Hyperping (France), Oh Dear (Belgium), Uptime.com (formerly US-based; verify current entity), and self-hosted options like Uptime Kuma and Statping which run on whatever infrastructure you provide. US-incorporated tools — Datadog, Pingdom (SolarWinds), UptimeRobot, BetterStack, Checkly, Better Uptime, StatusCake — fall under the CLOUD Act regardless of which region you select in their console. Always verify the legal entity in the vendor's imprint or Data Processing Agreement; marketing copy about 'EU data centres' is not a substitute for an EU controller.

Why Your Monitoring Data Shouldn't Leave the EU

Q: How does this affect NIS2 and DORA compliance?

For regulated entities — essential and important entities under NIS2, and financial entities under DORA — monitoring vendors are third-party ICT service providers. NIS2 Directive (EU) 2022/2555 Article 21(2) requires policies on supply-chain security and the assessment of vulnerabilities of direct suppliers. DORA Regulation (EU) 2022/2554 goes further: Chapter V requires a register of ICT third-party service providers, contractual ICT risk management, and concentration-risk analysis. Using an EU-incorporated monitoring vendor materially simplifies both: the supplier is reachable under EU law, sub-processor changes are notified under GDPR Article 28, and the cross-border transfer risk register has fewer entries. US-incorporated vendors are not blocked, but you carry the documentation and TIA burden yourself.

When people think about sensitive data, they think about customer databases, payment information, health records. Monitoring data rarely makes the list.

That’s a mistake.

Your uptime monitoring data contains a surprisingly detailed picture of your infrastructure — and if it leaves the EU, you might be exposing more than you think. This piece walks through the legal framework (Schrems II, the CLOUD Act, NIS2, DORA), then turns it into a concrete checklist you can run against any monitoring vendor.

What Monitoring Data Actually Contains

Let’s look at what a typical monitoring tool collects about your business:

Infrastructure map: Every URL you monitor reveals your service architecture. API endpoints, admin panels, staging environments, internal tools. Anyone with access to your monitoring config knows exactly what your stack looks like.

Uptime patterns: When does your service go down? How long does it take to recover? What’s your real uptime? This is competitive intelligence. For a SaaS business, uptime data is a direct indicator of operational maturity.

Response times: Performance trends reveal capacity issues before they become outages. If someone knows your P95 response time is creeping up on Thursdays, they know when you’re most vulnerable.

Incident history: Every incident tells a story: what broke, when, how long it took to fix, and how many times it’s happened before. This is operational intelligence.

Alert configurations: Who gets alerted, through which channels, and for what? This reveals your team structure, your on-call setup, and your communication channels.

SSL and certificate data: Certificate expiry dates, issuer information, chain of trust — details about your security infrastructure.

This isn’t abstract. This is a detailed profile of your business’s technical operations.

What Is Actually in a Monitor Record?

To make the GDPR analysis concrete, here is the typical contents of a single monitor and its associated records on any mainstream uptime platform:

Monitor URL and method — full URL, including any query parameters or path tokens. Often reveals internal service names.
Response body samples — most tools truncate at 1–10 KB, but the truncated slice still routinely contains usernames, account IDs, support ticket numbers, and partial session data when a failing endpoint leaks them.
HTTP metadata — status codes, headers (including Set-Cookie, X-Request-ID, Server), TLS version, certificate chain, and response timings.
Timestamps and check cadence — minute-precision history of when your service was up and down, broken out by probe region.
Alert targets — email addresses, phone numbers, Slack user/channel IDs, Microsoft Teams webhook URLs, Discord webhook URLs, PagerDuty routing keys. These are tied to identifiable natural persons.
Incident notes — free-text annotations written by responders, often naming colleagues, customers, or affected accounts.
Audit logs — who logged in, who acknowledged an alert, who edited a monitor. Tied to user accounts.

Even if you argue that monitor URLs and HTTP metadata are not personal data on their own, the alert-target list, incident notes, and audit logs unambiguously are. Article 4(1) of the GDPR (Regulation (EU) 2016/679) defines personal data as any information relating to an identified or identifiable natural person. A list of on-call engineers and their alert preferences meets that test. Your monitoring vendor is, therefore, a processor under Article 28 — and the transfer rules in Chapter V apply.

What Happens When This Data Leaves the EU

When you use a US-based monitoring tool (UptimeRobot, Pingdom, BetterStack, Datadog), all of this data is stored on US infrastructure, controlled by a US company. Here’s what that means legally.

The CLOUD Act

The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) requires US companies to hand over data to US law enforcement on request — regardless of where the data is stored. An EU data center doesn’t protect you if the company is American. The reach is corporate, not geographic: it follows the legal entity, not the bytes on disk.

Schrems II: the legal anchor everyone references and few read

The 2020 Schrems II ruling — formally Case C-311/18, Data Protection Commissioner v Facebook Ireland Ltd and Maximillian Schrems — is the legal anchor behind the “EU monitoring” argument. The Court of Justice of the European Union (CJEU) did three things at once.

It invalidated the EU-US Privacy Shield outright. It ruled that Standard Contractual Clauses (SCCs) remain valid only where the importer’s country offers protection essentially equivalent to EU law — and held that US surveillance law (Section 702 FISA, Executive Order 12333) does not meet that standard. And it placed the burden of proof on the data exporter: you, the EU controller, must show the transfer is lawful on a case-by-case basis.

The European Data Protection Board followed up with Recommendations 01/2020 on measures that supplement transfer tools, which formalised the Transfer Impact Assessment (TIA) and listed the technical, contractual, and organisational measures an exporter must layer on top of SCCs when transferring to a third country with surveillance risk.

For monitoring data, the awkward truth is that the most effective supplementary measure — end-to-end encryption where the importer cannot read plaintext — is structurally incompatible with the service. The vendor must read response bodies to detect failures, send alerts to identifiable persons, and render incident notes in a UI. No useful TIA lands on “we’ve encrypted everything the vendor needs to operate.” Years after Schrems II, the simplest path remains: don’t transfer.

FISA Section 702

The Foreign Intelligence Surveillance Act allows US intelligence agencies to conduct programmatic surveillance on non-US persons’ data held by US companies. Your monitoring data could be swept up in bulk collection programmes — PRISM and Upstream are the two best-documented — without any specific warrant or probable cause directed at you. Section 702 was reauthorised in April 2024 for another two years, so the legal exposure here is not a historical artefact.

AWS Frankfurt vs Hetzner Nuremberg: an honest comparison

The most common counter-argument is: “We use AWS Frankfurt, the data stays in Germany.” That is true for residency. It is not true for jurisdiction. Below is what each option actually buys you for monitoring-data hosting.

Provider	Operating entity	CLOUD Act reach	EU SCCs required	Recommended for monitoring data
AWS Frankfurt (eu-central-1)	Amazon Web Services, Inc. (US) and Amazon Web Services EMEA SARL (LU)	Yes — US parent is compellable under 18 U.S.C. § 2713	Yes, for any sub-processor outside the EU/EEA	Only with strong supplementary measures and a documented TIA
Hetzner Nuremberg (or Netcup, OVH, Scaleway)	EU-incorporated GmbH / SAS / BV, controlled and audited under EU law	No — outside the personal jurisdiction of US courts	No — transfer rules do not apply	Yes — preferred default for EU controllers

This is not a sales argument against AWS. AWS Frankfurt is a legitimate choice for plenty of workloads. It is a poor choice when the workload is itself a record of who reacts to your incidents, when, and how often — because the legal cost of defending that transfer is disproportionate to the technical benefit of being on AWS.

The Practical Risks

Beyond legal compliance, there are practical risks:

Competitive intelligence: A government agency or bad actor with access to your monitoring data knows your infrastructure, your weak points, your recovery times, and your technical capabilities.

Supply chain mapping: Your monitoring URLs reveal your vendors, your dependencies, and your integration points. This is valuable for supply chain attacks.

Incident exploitation: Knowing when a company is experiencing issues — in real time — is valuable information for competitors, short sellers, or threat actors.

NIS2 and DORA: when EU jurisdiction stops being optional

For most SaaS founders, the GDPR analysis above is the binding constraint. For anyone selling into regulated sectors — energy, transport, banking, healthcare, digital infrastructure, ICT service management — two further regimes apply, and they push the answer harder toward EU-incorporated vendors.

NIS2 Directive (EU) 2022/2555, in force since January 2023 and transposed across member states through 2024–2025, requires essential and important entities to implement cybersecurity risk-management measures under Article 21. Paragraph 2(d) specifically calls out “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” A monitoring vendor is a direct supplier. Auditing one based in the EU, governed by EU contract law, with a named DPO and an EU establishment, is materially cheaper to evidence than auditing one based in San Francisco that points you at a generic Trust Centre PDF.

DORA Regulation (EU) 2022/2554, applicable to financial entities from 17 January 2025, is stricter still. Chapter V requires a register of all ICT third-party service providers, contractual minimums for ICT risk management, and concentration-risk analysis when too much of your stack lives with one provider or one jurisdiction. The lead supervisory authority for ICT third-party risk sits with the European Supervisory Authorities. Using a US-incorporated monitoring vendor is not prohibited, but it is the kind of cross-border, third-country dependency that DORA assessors will ask you to justify. Picking an EU-incorporated vendor removes the question.

“But We’re Just a Small Startup”

Fair point — nobody is targeting your 5-monitor setup specifically. But the laws don’t distinguish between small and large. The CLOUD Act applies to all US companies equally. GDPR applies whether you have 5 or 500,000 users. And the monitoring tool you choose today may still be processing your data when you’re handling thousands of customers, or when you sign your first regulated enterprise customer who runs a DORA-flavoured vendor questionnaire at you.

Building on EU infrastructure from day one means you never have to migrate later.

A Vendor-Selection Checklist for EU Buyers

Run these questions before signing anything. The first six are non-negotiable.

Legal entity and jurisdiction. Full legal name, country of incorporation, registered address. Look for an EU/EEA GmbH, SAS, BV, OY — not a US LLC with a European sales office.
Named sub-processor list. Current, public, with entity names, countries, and purpose. Gated behind a sales call is a red flag.
EU-only vs SCC posture. Does the vendor commit contractually to EU-only sub-processors, or fall back to SCCs and a TIA? “EU region available” is marketing, not contract.
CLOUD Act exposure statement. Ask in writing whether the operating entity, parent, or any controlling entity is subject to the CLOUD Act, FISA 702, or EO 12333.
DPA available without a sales call. A real Article 28 DPA, downloadable as PDF. Bonus points if pre-signed.
Data export and portability. Monitor configs, check history, incident logs exportable in JSON or CSV at any time, without contacting support.
Retention controls. Configurable retention for check data, response bodies, and incident records. Default-forever is a compliance smell.
Audit logs. Admin actions logged with actor, timestamp, IP — and exportable.
Sub-processor change notifications. Article 28(2) requires prior notice with a right to object. Is that operationalised, or buried in ToS?
Breach notification SLA. The GDPR 72-hour clock starts when you become aware; a 72-hour vendor SLA leaves you with zero time.
Encryption posture. At-rest encryption and key management, clearly documented.
EU choice-of-law clause. Disputes governed by an EU member state’s law, venue in an EU court. Delaware or California clauses contradict the rest of the pitch.

If a vendor cannot answer eight or more without scheduling a call, replace them.

What You Can Do

The checklist above is the long version. The short version is five moves:

Choose monitoring tools from EU companies — not US companies with EU data centers. Our guide to GDPR-compliant monitoring tools lists current options.
Verify actual data residency — “EU region available” is not “EU only.” Ask where the company is incorporated, not just where the servers are.
Check the sub-processor list — does it route through US-based analytics, logging, or infrastructure?
Download the DPA before you sign — if you have to schedule a sales call to get one, that is a red flag.
Consider self-hosted — tools like Uptime Kuma let you run monitoring on your own EU infrastructure.

The Bigger Picture

Data sovereignty isn’t just about compliance. It’s about control. When your monitoring data lives on US infrastructure, you’ve handed over a detailed map of your business to a jurisdiction that can legally access it without telling you. Schrems II made the legal answer plain. The CLOUD Act made the technical answer plain. NIS2 and DORA make the procurement answer plain.

For EU founders building products that handle customer data, this matters. Your monitoring tool is part of your trust story. And increasingly, European alternatives exist that let you tell that story with confidence.