GDPR uptime monitoring — what an EU DPA actually requires

The compliance gap nobody talks about

If you run an EU SaaS, you have probably spent more weekends than you would like mapping sub-processors. Stripe is on the list. Your email provider is on the list. Your CRM is on the list. And then there is the uptime monitor — the small line item the founder added in year one and nobody has touched since.

That tool is reading your production traffic. A typical HTTP probe sends a request to /api/health every minute and stores the full response body, the status code, and the latency. A synthetic browser check records the rendered DOM. An SMTP probe stores credentials. A database probe holds the connection string. The vendor's database is full of URLs that include customer IDs, of response payloads that include email addresses, and of IPs from the regions your customers happen to be in.

Under GDPR Article 4(2), that is processing of personal data. Under Article 28(1), the vendor doing it on your behalf is a processor, and you are the controller. Whether you have thought about them as a sub-processor or not, your customers' data protection authority will. That is the gap this guide is written to close.

What Article 28 actually demands of a sub-processor

Article 28 is the practical centre of GDPR for anyone managing vendors. It is also short — five pages — and worth reading once in full. The obligations that bite monitoring vendors specifically:

• A binding written contract (Art. 28(3)). The processor must process personal data only on documented instructions from the controller. In practice this means a signed Data Processing Agreement, not a clause buried in the terms of service. If your vendor cannot produce a DPA on request, you do not have one.
• Confidentiality (Art. 28(3)(b)). Everyone the vendor authorises to access the data has to be under an enforceable confidentiality obligation. "Our staff sign NDAs" is the minimum, not the answer.
• Security of processing (Art. 28(3)(c), pointing to Art. 32). Encryption in transit and at rest, ability to restore availability after an incident, and a process for regularly testing the controls. A monitoring vendor that does not encrypt your probe credentials at the application layer is not meeting this bar — TLS in transit is table stakes, not the ceiling.
• No further sub-processors without authorisation (Art. 28(2)). The vendor cannot quietly add a new AI service, a new analytics pipeline, or a new region of cloud compute. General authorisation with prior notice and a right to object is allowed; silent addition is not.
• Assistance with data subject rights (Art. 28(3)(e)). When your customer files a Subject Access Request, your vendor has to help you fulfil it. If the monitoring database holds an email address you cannot find or delete, that is your problem, not theirs — unless the contract says otherwise.
• Audit rights (Art. 28(3)(h)). You have the right to audit the processor, or to accept a recent third-party audit report in lieu. SOC 2 Type II is the usual answer, but the right itself exists with or without one.
• Return or deletion at end of processing (Art. 28(3)(g)). When you terminate, the vendor either returns the data or deletes it. Cached probe results from two years ago do not get to drift forever in a backup.

A monitoring DPA that does not cover all seven items — explicitly — is not a GDPR-compliant DPA. It is a marketing PDF.

Data residency after Schrems II (2020)

The Court of Justice of the European Union's July 2020 judgment in Schrems II (Case C-311/18) is the line most monitoring vendors still pretend does not exist. The judgment did two things. First, it invalidated the EU-US Privacy Shield as a basis for transferring personal data to the United States. Second — and more importantly — it held that Standard Contractual Clauses (SCCs), while still valid in principle, are not on their own sufficient for transfers to countries whose surveillance laws fail to meet EU essential equivalence. The US, the court found, was such a country.

Schrems II did not "ban US data transfers" — that overreading is common and wrong. What it did was require a case-by-case transfer impact assessment, plus supplementary measures (legal, technical, or organisational) for any transfer that relies on SCCs to a third country with disqualifying surveillance regimes. The EDPB recommendations of 18 June 2021 spell out what counts as a supplementary measure: end-to-end encryption where the receiving party does not hold the keys, pseudonymisation, strict access controls, and transparency about government access requests.

For an uptime monitoring vendor, the practical consequence is binary. Either (a) the vendor processes EU customer data inside the EEA — in which case Chapter V is not engaged at all for that data — or (b) the vendor processes it in the US under SCCs plus supplementary measures, and you have to read those measures and decide whether they are sufficient for your risk. The 2023 EU-US Data Privacy Framework provides an additional adequacy basis for certified organisations, but is itself under legal challenge and should not be relied on as the only path.

The safe path, for most EU SaaS teams under most procurement reviews, is option (a): pick a vendor whose processing for your tenant happens entirely in the EEA. Read the vendor's data flow map. If "EU" only appears in the context of "edge PoPs" while the database of record sits in us-east-1, you are still in option (b), and you still owe Schrems II its homework.

The 7-question audit for your current vendor

Send these to your monitoring vendor's account team. The answers should be in writing, sourced from documentation, and consistent with the signed DPA. Vague responses are themselves a finding.

1. Where does my tenant's data physically live? Not where the marketing site says "EU PoPs available" — where is the database of record, the backup region, and any analytics warehouse. Ask for a region name, not a vendor name.
2. Who is on the current sub-processor list? Ask for the URL of the page that lists every sub-processor, the data each touches, and the region. If the page does not exist, the vendor has already failed Article 28(2).
3. What is the data retention period for each data class? Probe configuration, probe results, alert logs, customer support tickets — each has its own retention. "Indefinitely" is not a retention policy under Article 5(1)(e).
4. Do you rely on SCCs, and what supplementary measures apply? For any US-resident processing, this is the Schrems II question. Acceptable answers reference end-to-end or application-layer encryption, pseudonymisation, or technical isolation. "We have SCCs" alone is not an answer.
5. Can I get a signed DPA today, in PDF, with my company on it? Not "available on enterprise plans". The right to a DPA does not depend on a price tier.
6. What is your audit policy? SOC 2 Type II report available under NDA? ISO 27001 certificate? Or a contractual right to audit directly? One of those three should exist.
7. What happens on a personal data breach? Article 33(2) requires the processor to notify the controller without undue delay. Ask for the SLA in hours, not days, and the channel (email to a named address, in-product banner, phone).

Common failure modes

The same handful of patterns show up in vendor risk questionnaires across the EU SaaS market. They are easy to mistake for compliance.

• "EU PoPs" with centralised US data. The probes run from European edge nodes; the database that stores the results is in Virginia. The marketing is technically true; the Chapter V analysis is the same as a fully US-hosted vendor.
• US-based AI features bolted onto an EU product. A vendor with EU hosting adds an AI incident summariser running on a US foundation model API. Unless that feature is opt-in and clearly disclosed, every customer who triggers it has just exported personal data to the US.
• Undisclosed sub-processors. The DPA references a sub-processor list URL; the URL has not been updated since 2023; the vendor quietly added a CDN, an analytics vendor, and a support-ticketing service in the interim. Article 28(2) is not discretionary.
• DPAs that reference the 2010 SCCs. The European Commission replaced the SCCs in June 2021. A DPA still pointing at the old clauses has not been refreshed in five years and is not a current document.
• Probe credentials in plaintext. Your SMTP password, database connection string, or gRPC client certificate lives in the vendor's database. If it is not encrypted at the application layer with keys the vendor's operators cannot read, the vendor's worst-day blast radius includes your production systems.

EU-friendly options — a short, honest shortlist

The market for uptime monitoring with credible EU processing is smaller than the market overall. The honest picks:

• StatusPulse — each tenant is provisioned in either an EU Azure region (North Europe / West Europe) or a US region (East US / West US), chosen at signup. Azure SQL, Functions, Storage, Key Vault, and Application Insights all follow the tenant region; Azure SQL backups are geo-redundant within that region only, with no cross-region replication. Probe credentials (SMTP, database, WebSocket, gRPC mTLS) are encrypted at the application layer with AES-GCM using a key resolved from Azure Key Vault. The optional AI incident drafter uses Anthropic's Claude API in the US under SCCs and is opt-in per feature — not enabled by default, and clearly disclosed. SOC 2 Type II is in progress, not done; that is in the DPA in writing. Read the full mapping on the StatusPulse GDPR page.
• Better Stack — Czech-based, with EU infrastructure and a stronger EU heritage than most US-founded competitors. A reasonable pick if you need monitoring without the bundled status-page workflow that StatusPulse provides. See the side-by-side comparison for where they overlap and where they do not.
• Statuspage.io (Atlassian) — well-engineered, deeply integrated with Jira and Opsgenie, but hosted in the United States with no per-tenant EU residency option. For EU-led procurement reviews this is a Schrems II conversation every time. The StatusPulse vs Statuspage.io comparison covers the trade.
• Self-hosted (Uptime Kuma, Cabin, Plane status pages). Open-source uptime tools you run on your own EU infrastructure. Compliance burden is yours end-to-end — which is the point. A fine fit if you have a platform team and a strong reason to keep one more service inside your perimeter; not a fit if you want monitoring to be a line item, not a project.

Migration checklist for a SOC 2 / GDPR review

If your last compliance review surfaced your monitoring vendor as a finding, the path through is mechanical rather than dramatic.

1. Export the current vendor's audit log and DPA. Before you cancel, pull the last 90 days of admin actions, the signed DPA, and the current sub-processor snapshot. These are the evidence trail for the review.
2. Pick a replacement with a documented EU region. "Documented" means a public page that names the region (North Europe, West Europe, eu-west-1) and confirms the database of record lives there. Marketing language about "global infrastructure" is not documentation.
3. Run parallel for 30 days. Stand up the new vendor alongside the old one. Wire the same alert channels. Compare incident detection — if the new vendor catches at least the same incidents at the same time, the signal is good.
4. Swap the public incident URLs. If your status page is hosted by the old vendor, update the DNS CNAME to the new one. Most public subscribers carry forward via export / import; allow a week of dual-running before turning the old page off.
5. Update your own sub-processor list publicly. Your GDPR page lists your sub-processors. Remove the old vendor, add the new one, and — under Article 28(2) — give your customers prior notice with a right to object. Thirty days is the typical window.
6. File the evidence for the next review. Save the new DPA, the sub-processor change notification, and the first month of dual-run logs. Whoever does next year's audit will thank you.

Wrap-up

Uptime monitoring sits inside the GDPR perimeter whether the vendor advertises that fact or not. Once you accept that, the analysis is ordinary processor-management work — Article 28's seven obligations, Chapter V for transfers, Article 32 for security. The hard part is usually finding a vendor whose data flow map survives the questions in section four without footnotes.

StatusPulse exists partly because that vendor list was shorter than it should have been. Each tenant pins to a US or EU region at signup, the data of record stays in that region, the only path off the EU is the opt-in AI features under SCCs, and the DPA covers Article 28(3) line by line. If that maps to your next compliance review, the next two steps are below.