DPF Collapse Plan B: 12 EU Alternatives to US Tools (2026)

Main article: Schrems II + DPF Update 2026 — covering the status of the Data Privacy Framework, transfer impact assessments and standard contractual clauses in detail.

What a change of provider triggers in documentation terms

For each of the 12 tools, a change of provider usually puts the same four documents up for review: the contract with the new provider, the record of processing activities, the privacy notice and the reference to technical and organisational measures (TOMs) — which of them applies depends on the role; added to this are the clarification of the role itself and, where processing is likely to result in a high risk, the impact assessment. Where the new provider processes the data on your behalf, the change swaps one data processor for another. Where this article deals with self-hosting — Mattermost in item 3, Zammad in item 7, Kanboard and Wekan in item 10, cal.com in item 11 — the role shifts: you are then the one describing the technical and organisational measures, and data processors are at most the hosting and maintenance service providers. Whether an option described as open source is operated by you or as a provider's service therefore has to be clarified option by option.

Why the record comes first: according to the BfDI Annual Report 2024, 85% of all supervisory enquiries begin with the submission of the record of processing activities; the practical order of review is record, data processing agreement, TOM concept, impact assessment. Practical recommendation: for each change, draw up a list of the processing activities affected before you negotiate the contract — otherwise the tool moves and the documentation stays with the old provider.

Experience shows that nine errors recur in records of processing activities (practical observation) — a change of provider touches precisely the fields in which they arise. Several of the following 12 items refer to the numbers in this list.

The product, price and duration figures in the following 12 items come from the original version of 2 May 2026 and have not been updated; the legal information reflects the state of the update.

Not every one of the 12 alternatives is located in the EU

Six options in five of the following 12 items expressly carry a non-EU flag — they replace a US provider, but not necessarily the third country element. This article expressly flags them as non-EU options; the table collects them so that they are not overlooked when completing the record. For recipients outside the EU, record-keeping practice uses a separate column for the safeguard; the types of safeguard it names are standard contractual clauses, the Data Privacy Framework and binding corporate rules. Which safeguard holds in an individual case and how it is to be assessed is covered in the main article.

For the remaining options, this article makes no statement about the provider's place of establishment beyond the flags in the headings of the following 12 items. Practical recommendation: obtain the full list of sub-processors used for each provider before you set the "third country transfer" column in the record to "none".

When to trigger Plan B — and how much time is then left

Plan B is triggered by the annulment of the adequacy decision — historically, transition periods ranged from 0 to 3 months (Privacy Shield 2020). This range is the reason why the order has to be fixed beforehand: changes at the upper end of the range documented in this article — up to 6 months in item 1, up to 9 months in item 2 — cannot be completed in full within 0 to 3 months. Duration figures are available in this article only for items 1, 2, 6 and 8; for the other eight changes you will have to estimate the duration yourself. Practical recommendation: do not sort by duration, therefore, but by type of data — special categories under Art. 9 GDPR and employee data first, then the processing activities with the largest numbers of data subjects.

Practical recommendation: keep two documents ready for each US tool before the trigger event occurs — the standard contractual clauses countersigned by the provider and a transfer impact assessment with date, tool, types of data and outcome — and file both in the same place as the data processing agreement. Whether a safeguard holds in an individual case and how the assessment is to be conducted in substance is covered in the main article.

Practical recommendation — transition strategy for 6 to 12 months, not a statutory order:

1. Sensitive data first: migrate HR, finance and special categories under Art. 9 GDPR to the EU provider immediately.
2. Leave standard data in place for now: marketing and customer data stay with the US provider for as long as the DPF applies.
3. Keep a sub-tenant ready: set up a second tenant with the EU provider in parallel, with users, permissions and folder structure created, but operate it without production data — contractually this already constitutes a processing relationship (Art. 28(3) GDPR), while in the record it is not yet an active processing activity.
4. Switch to production if the worst happens: activate the sub-tenant, migrate standard data within 4 to 12 weeks.

That is exactly where the time gain lies: instead of the up to 6 months of a full M365 change (item 1), 4 to 12 weeks remain if the worst happens; with item 2 at up to 9 months, the gain is correspondingly greater. In documentation terms the trigger event is not a special case — an emergency migration also changes the contract, the record and the privacy notice under the same requirements, and the list of errors above applies all the more under time pressure. Practical recommendation: keep the mapping of "which tool carries which processing activity" continuously up to date — if the trigger event occurs, it is your migration sequence.

1. Microsoft 365 → Stack-IT (DE) / IONOS Cloud (DE)

This change swaps the data processor for almost all office processing operations at the same time — which is why the contract is the first step, not the last. Migration 2-6 months. Costs similar. Stack-IT belongs to the Schwarz Group (Lidl); the classification as privacy-focused is a provider statement and does not replace evidence of sufficient guarantees under Art. 28(1) GDPR. IONOS Cloud (DE) is the second documented option; on feature parity and price see the FAQ "Which EU alternative is best for M365?" — in documentation terms the same steps apply to both options. In documentation terms this means: a contract with the full minimum content under Art. 28(1) and (3) GDPR (catalogue in the table above), and because M365 typically carries several processing activities at once — payroll, applicant management, customer communication — each of them has to be updated individually in the record (Art. 30(1) GDPR).

2. Google Workspace → OpenDesk (PHOENIX, DE)

Here it is above all one line of the record that changes, one that is particularly often out of date in practice: the recipient list. Migration 3-9 months. OpenDesk is a German federal initiative, open source. In record templates, Google Workspace is a standard entry in the "third country transfers and safeguards" column; after the change this entry has to be amended and the old provider removed. That is exactly where errors 1 and 3 of the list of record-keeping errors above occur: outdated recipient lists, because the replaced system was never removed, and a missing third country reference for US services. Practical recommendation: remove the old provider with a date and keep the record under version control — missing version control is error 9 in the same list.

3. Slack → Mattermost (self-hosted) / Element (UK) / Rocket.Chat

These three options lead to three different role profiles, and the role determines which document you need. Mattermost is open source, often cheaper. Element is good for end-to-end encryption — record the level of encryption in the TOM description to which the record and the contract refer (Art. 32(1) GDPR); for entities subject to NIS2, cryptography forms part of the statutory minimum catalogue (§ 30(2) of the German BSI Act (BSIG 2025) in Germany, § 32(4) of the Austrian Network and Information Systems Security Act 2026 (NISG 2026) in Austria, applicable from 1 October 2026). With Mattermost, expressly described as self-hosted, you process the data yourself: the record field on technical and organisational measures then describes your own measures, and data processors are at most the hosting and maintenance service providers — for whom in turn a contract under Art. 28(3) GDPR is required. Where the service is operated for you, the classic processing relationship remains. Clarify the role first, therefore (check point 1). On Rocket.Chat, this article makes no statement about the place of establishment or the operating model — clarify both before the contract, because the role and the third country entry depend on them. On the flagging of Element (UK) see the section above.

4. Salesforce → Pipedrive (EE) / Hubspot with EU DC / Zoho EU region

CRM is regular processing — the change is therefore subject to the record-keeping obligation, irrespective of the size of the company. Pipedrive is an Estonian provider and simpler. HubSpot has had an EU data centre since 2024. The 250-employee exemption in Art. 30(5) GDPR applies only cumulatively: fewer than 250 employees and no risk to the rights and freedoms of data subjects and no regular processing and no special categories under Art. 9 or criminal-offence data. What matters is the official wording "a risk", not "high risk" — the "high risk" threshold applies to the impact assessment under Art. 35(1) GDPR. Because customer master data is processed regularly, the exemption does not apply. In addition, record the legal basis for each processing operation as a practical field, for example contract or legitimate interests (catalogue: Art. 6(1) GDPR; documentation follows from the accountability principle in Art. 5(2) GDPR). Which of the options triggers a third country entry together with a safeguard should be clarified under the rule in the section "Not every one of the 12 alternatives is located in the EU".

5. AWS → OVH (FR) / Hetzner (DE) / Stack-IT

A change of infrastructure affects all processing operations running on it at the same time — the bottleneck is therefore the selection documentation, not the move itself. Hetzner is inexpensive — the price does not replace evidence of sufficient guarantees under Art. 28(1) GDPR. OVH offers a Kubernetes service. Stack-IT is M365-compatible. In legal terms, Art. 28(1) GDPR requires you to use only data processors providing sufficient guarantees to implement appropriate technical and organisational measures; which evidence you rely on for this is for you to decide and document. After that, every processing activity affected has to be updated in the record (Art. 30(1) GDPR). For entities subject to NIS2, the supply chain dimension is added — see the separate section below.

6. Mailchimp → Brevo (FR) / CleverReach (DE) / GetResponse (PL)

With a newsletter change it is not only addresses that move, but consents — and these must remain demonstrable. Brevo (formerly Sendinblue) offers a 4-week migration. CleverReach is a German provider. Where processing is based on consent, the controller must be able to demonstrate that the data subject has consented (Art. 7(1) GDPR); withdrawal must be possible at any time and as easy as giving consent (Art. 7(3) GDPR). In practice this means: migrate the record of consent including the time and source, and have the unsubscribe route working from the first mailing out of the new system. In Austria, § 174 TKG 2021 applies in addition for unsolicited messages (consent, double opt-in). Mailchimp is at the same time the standard example of error 3 of the list of record-keeping errors above, the missing third country reference for US tools — this entry too has to be amended when making the change. Third country entry: under the rule in the section "Not every one of the 12 alternatives is located in the EU".

7. Zendesk → Freshdesk (IN) / OTRS (DE) / Zammad (DE)

Experience shows that special categories arise unnoticed in support systems: customers write health information into tickets. Zammad is open source. Freshdesk addresses the mid-market segment, OTRS the enterprise segment. The processing of health data and other special categories is prohibited in principle and permissible only under the exceptions in Art. 9(2) GDPR, for example with explicit consent (Art. 9(1) GDPR). Where such data is processed on a large scale, it belongs to the standard cases for an impact assessment (Art. 35(3) GDPR). Also plan for access to the ticket history: access requests must be answered without undue delay and in any event within one month (Art. 12(3) GDPR) — including during the changeover. The choice determines the role: in so far as you operate OTRS or Zammad yourself, you describe the TOMs yourself and need a contract only for hosting and maintenance; where the option is operated as a service, the processing relationship remains. Third country entry: under the rule in the section "Not every one of the 12 alternatives is located in the EU".

8. HubSpot → Pipedrive / Zoho EU

Functionally this is a comparatively small change; in documentation terms it is the one where the role is most often determined incorrectly. Item 4 names HubSpot with an EU data centre as a possible Salesforce destination — that is not a contradiction, but a question of the region booked and the data flow: anyone already running HubSpot without an EU data centre changes either the region or the tool; anyone coming from Salesforce examines the same question before booking. Migration 2-4 months. Functionally comparable. "Processing on behalf confused with what is actually joint controllership" is error 4 of the list of record-keeping errors above — and marketing suites are a frequent occasion for it in practice, because forms, campaigns and sales data converge in one system. Determine the role per data flow, therefore, not per tool. Only then is it clear whether a contract under Art. 28(3) GDPR is the right document or whether the role has to be documented under Art. 26 GDPR. The role assessment in this item applies equally to Pipedrive and Zoho EU; the details on place of establishment and region are set out in item 4.

9. Asana → Notion (EU hosting) / ClickUp (US, with EU data boundary)

A reference to EU hosting is information about the storage location — alongside it, the record requires the categories of recipients and, where applicable, the third country transfer together with its safeguard. Notion has offered EU hosting since 2024. Both mandatory entries stand independently of each other in Art. 30(1) GDPR; the selection of the provider additionally remains bound by Art. 28(1) GDPR. Project tools frequently carry personnel data, for example task assignments and time entries for named employees — they therefore belong in the record as a separate processing activity, not in a collective line; "collective processing: communication" is error 6 of the list above. Third country entry: under the rule in the section "Not every one of the 12 alternatives is located in the EU".

10. Trello → Kanboard (self-hosted) / Wekan (open source)

Both options are candidates for self-hosting; where you operate the system yourself, the record field on technical and organisational measures describes your own measures from that point on. Kanboard and Wekan are open source alternatives with a lite feature set. Art. 30(1) GDPR requires a general description of the TOMs; it belongs in the record as a reference to a central TOM concept under Art. 32(1) GDPR, not as content copied into each processing activity — the duplication is error 7 of the list above. Anyone who outsources operation to a hosting or service provider still needs a contract with that provider under Art. 28(3) GDPR. Practical recommendation: where you self-host, record who is responsible internally for updates and access rights — that role was previously part of the provider contract.

11. Calendly → cal.com (open source) / Doodle (CH)

Appointment booking widgets sit on your own website — which is why the law on access to terminal equipment applies in addition to data protection law. cal.com is open source. Doodle is a Swiss provider; third country entry: under the rule in the section "Not every one of the 12 alternatives is located in the EU". In Germany, the storage of information in terminal equipment and access to information already stored are permissible only with prior consent on the basis of clear and comprehensive information; no consent is required where the sole purpose is the transmission of a message or where access is strictly necessary in order to provide a digital service expressly requested by the user (§ 25(1) and (2) of the German Telecommunications-Digital-Services Data Protection Act (TDDDG)). In Austria this is governed by § 165 of the Austrian Telecommunications Act 2021 (TKG 2021), with opt-in for tracking cookies. For each widget, therefore, examine what it stores on the terminal device, and add the new recipient to the privacy notice (Art. 13 GDPR). The choice determines which second document is added: with cal.com self-hosted you describe the technical and organisational measures yourself; with Doodle (CH) it is the third country entry just mentioned. The consent assessment for the widget arises in both cases.

12. DocuSign → SignNow (USA) / Skribble (CH) / Yousign (FR)

Signature platforms process contract documents containing personal data — here it is the erasure period that matters, not the migration time. Skribble offers the qualified electronic signature (QES) under the eIDAS Regulation; that changes nothing about the contract or the record, but it does change what you record on the retention of signature documents — the envisaged erasure period belongs in the record for each category of data. Yousign is a French provider. The record requires envisaged erasure periods for each category of data (Art. 30(1) GDPR); with contract documents these regularly collide with retention obligations of 10 years under the German Commercial Code (HGB) and the German Fiscal Code (AO) (Germany). Document this conflict with the right to erasure under Art. 17 GDPR in the record instead of leaving it open — "no specific figure" for erasure periods is error 2 of the list above. Legacy data moves with you: determine in advance which documents are taken over and which are deleted in the legacy system. The choice determines the erasure-period documentation together with the third country entry; for SignNow (USA), Skribble (CH) and Yousign (FR) the third country entry follows the rule in the section "Not every one of the 12 alternatives is located in the EU".

Germany and Austria: what differs when changing provider

Six points differ: the supervisory authority, the Austrian data secrecy obligation, the national law on access to terminal equipment, the additional provision for newsletters, the threshold for the data protection officer and the national sanctions alongside Art. 83 GDPR. The core obligations, by contrast, are identical — Art. 28 and Art. 30 GDPR apply in both countries in identical wording, with the same mandatory entries and without differing thresholds or deadlines.

Entities subject to NIS2: the change is supply chain security

Anyone falling under NIS2 additionally treats a change of provider as a supply chain matter: supply chain security forms part of the statutory minimum catalogue of risk management measures (§ 30(2) BSIG 2025 in Germany, § 32(4) NISG 2026 in Austria (applicable from 1 October 2026), Art. 21(2) of the NIS2 Directive). The same catalogue also covers cryptography and encryption, access control and multi-factor authentication — all points that are reconfigured when a tool is changed.

Whether you fall within scope is determined in Germany by § 28 BSIG 2025 and depends, for companies, on a type listed in the annexes: particularly important entities include other entities of a type specified in Annex 1 that employ at least 250 employees or have an annual turnover of more than EUR 50 million and also an annual balance sheet total of more than EUR 43 million; in addition, § 28(1) BSIG 2025 covers operators of critical installations as well as — irrespective of size — qualified trust service providers, top-level domain name registries and DNS service providers. Important entities are entities of a type specified in Annex 1 or Annex 2 that employ at least 50 employees or have an annual turnover and an annual balance sheet total of more than EUR 10 million each, in so far as they are not already particularly important entities (§ 28(2) BSIG 2025). In Austria, § 25(2) and (3) NISG 2026 distinguishes between large and medium-sized companies using the same figures; classification as an essential or important entity follows from § 24 NISG 2026 and likewise requires a type listed in Annex 1 or Annex 2.

The decision is a matter for the top: the management bodies of particularly important and important entities must implement the risk management measures and monitor their implementation, and are liable for culpably caused damage where their entity breaches its obligations (§ 38(1) to (3) BSIG 2025); in Austria the management bodies must ensure and supervise compliance (§ 31(1) and (2) NISG 2026). For infringements of the risk management and reporting obligations, the fine range in Germany is up to EUR 10 million for particularly important entities and up to EUR 7 million for important entities; where total turnover exceeds EUR 500 million, up to 2% or 1.4% respectively of worldwide total turnover is possible by way of derogation (§ 65(5) no. 1, (6) and (7) BSIG 2025). For administrative offences under § 45(1) NISG 2026, the fine in Austria is up to EUR 10 million or up to 2% of the total worldwide annual turnover for essential entities and up to EUR 7 million or up to 1.4% for important entities, whichever is higher (§ 45(2) and (3) NISG 2026). The Austrian obligations under the NISG 2026 are applicable from 1 October 2026.

6 check points before every change

Before each of the 12 changes you answer the same 6 questions — they determine which documents you have to touch. The order is the practical structure of this article, not a statutory order; when the individual obligation applies is set out in the respective source.

1. Role: are you a controller (Art. 4 no. 7), a data processor (Art. 4 no. 8) or joint controllers (Art. 26 GDPR)? Everything else depends on this.
2. Contract: does the provider offer sufficient guarantees to implement appropriate technical and organisational measures, and does the contract cover the minimum content (Art. 28(1) and (3) GDPR)? For providers with a third country element, the Plan B discipline from the section "When to trigger Plan B" (practical recommendation) applies in addition: check whether standard contractual clauses and a transfer impact assessment are on file.
3. Record: which processing activities are affected, and have the recipients, transfers including safeguards, erasure periods and TOM reference been updated (Art. 30(1) GDPR; as a data processor, Art. 30(2) GDPR)?
4. Types of data: do special categories arise (Art. 9(1) GDPR)? For the threshold and the standard cases for an impact assessment see the document table above (Art. 35(1) and (3) GDPR). In Germany, processing subject to a DPIA entails the designation of a data protection officer with no headcount threshold (§ 38(1) sentence 2 BDSG); in Austria the designation obligation follows solely from Art. 37 GDPR.
5. Data subject rights during the changeover: can access, rectification and erasure still be handled within one month (Art. 12(3) GDPR)? On the extension and the parallel phase see the FAQ "What happens to access requests during the migration?".
6. AI features in the replacement tool: the AI Act has applied in principle since 2 August 2026 (Art. 113 AI Act). If the new tool contains AI features, it must be assessed whether it falls under Art. 50 AI Act; the transparency obligations apply only to the systems named there: providers must ensure that AI systems intended to interact directly with natural persons inform them that they are interacting with an AI system, and must mark synthetic audio, image, video or text content in a machine-readable format as artificially generated ((1) and (2)); deployers must inform the persons concerned in the case of emotion recognition and biometric categorisation and, in the case of deepfakes, disclose that the content has been artificially generated or manipulated ((3) and (4)).

If something goes wrong during the migration: notification deadlines

A personal data breach during the changeover follows the normal notification route — 72 hours from becoming aware, to the competent supervisory authority (Art. 33(1) GDPR), and communication to the data subjects where there is likely to be a high risk (Art. 34(1) GDPR). Notification to the supervisory authority must be made without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to rights and freedoms. Practical recommendation: keep a handover record for each data set during the migration phase — if the worst happens, it supplies the notification details on categories of data and the approximate number of data subjects.