«Wir dürfen Microsoft 365 nicht einsetzen – wir sind DSGVO-pflichtig und unterliegen der berufsrechtlichen Verschwiegenheit.» Dieser Satz fällt in Compliance-Meetings, Mandantengesprächen und kanzleiinternen Datenschutzrunden mit einer Regelmäßigkeit, die ihn fast zum Mantra gemacht hat. Er klingt vorsichtig, verantwortungsbewusst, geradezu standesrechtlich geboten. Und in dieser Pauschalität ist er schlicht nicht richtig.
Das Problem ist nicht Microsoft. Das Problem ist eine Denkfigur, die komplexe regulatorische Abwägungen durch eine simple Binärregel ersetzt: US-Anbieter gleich datenschutzwidrig, gleich Verstoß gegen § 203 StGB. Wer so urteilt, schützt weder personenbezogene Daten noch das Mandatsgeheimnis – sondern umgeht die eigentlichen Fragestellungen. Dieser Beitrag stellt genau diese Fragen. Und er beantwortet sie – speziell aus Sicht von Steuerberatern und Wirtschaftsprüfern, die mit einer doppelten Schutzschicht arbeiten: dem allgemeinen Datenschutzrecht und der berufsrechtlichen Verschwiegenheitspflicht nach § 203 StGB, § 62 StBerG bzw. § 43 WPO.
Die DSGVO kennt kein kategorisches Verbot des Einsatzes amerikanischer Cloud-Dienste. Sie kennt ein Regelwerk für den Umgang mit personenbezogenen Daten und ein differenziertes Anforderungsprofil für Drittlandtransfers. Ob Microsoft 365 (M365) in einer konkreten Kanzleiumgebung datenschutzkonform und berufsrechtlich zulässig betrieben werden kann, hängt nicht von der Nationalität des Anbieters ab, sondern von drei Fragen:
Und wie werden Restrisiken bewertet und dokumentiert?
Die pauschale Ablehnung ist keine datenschutzrechtliche Position – sie weicht der eigentlichen Aufgabe aus.
Die Skepsis gegenüber Microsoft 365 hat eine nachvollziehbare Entstehungsgeschichte. Mit dem Urteil des Europäischen Gerichtshofs (EuGH) vom 16. Juli 2020 in der Rechtssache «Schrems II» (C-311/18) wurde das EU-US Privacy Shield für ungültig erklärt. Der Grund: Das US-amerikanische Recht – insbesondere «Section 702» des «Foreign Intelligence Surveillance Act» (FISA) und «Executive Order 12333» – erlaubt weitreichende Überwachungsbefugnisse amerikanischer Nachrichtendienste, ohne dass europäische Betroffene wirksamen Rechtsschutz gegen solche Zugriffe hätten. Der EuGH stellte fest, dass dies mit dem in Art. 45 DSGVO vorausgesetzten «wesentlich gleichwertigen» Schutzniveau nicht vereinbar sei.
Das Urteil entfaltete erhebliche Wirkung. Nicht nur, weil es den damals meistgenutzten Transfermechanismus für personenbezogene Daten in die USA außer Kraft setzte, sondern weil es eine grundsätzliche Frage aufwarf: Können Daten überhaupt rechtssicher in die USA übermittelt werden, solange amerikanische Nachrichtendienste unter geltendem US-Recht auf Cloud-gespeicherte Informationen zugreifen können? Diese Frage war berechtigt. Dass daraus jedoch ein pauschales «Nein» für Microsoft 365 wurde, ist ein Kategorienfehler. Erstens hat sich die Rechtslage seither erheblich verändert. Zweitens ist Microsoft kein passiver Beobachter der regulatorischen Entwicklung, sondern hat technisch und vertraglich nachgesteuert.
Für Steuerberater- und Wirtschaftsprüferkanzleien kommt eine zweite Sorgenebene hinzu: § 203 StGB sanktioniert die Offenbarung fremder Geheimnisse. Seit der Gesetzesänderung von 2017 (sog. «Mitwirkende-Erweiterung» in § 203 Abs. 3, 4 StGB) ist die Einschaltung externer Dienstleister zwar grundsätzlich möglich, setzt aber eine angemessene vertragliche und organisatorische Absicherung voraus. Diese berufsrechtliche Komponente macht die Frage «M365 ja oder nein?» in Kanzleien anspruchsvoller als in einem typischen Industrieunternehmen – aber sie liefert keinen pauschalen Verbotsgrund.
Am 10. Juli 2023 verabschiedete die Europäische Kommission den Angemessenheitsbeschluss für das «EU-US Data Privacy Framework» (DPF) – Durchführungsbeschluss (EU) 2023/1795. Seit diesem Datum existiert wieder ein formelles Transferinstrument im Sinne von Art. 45 DSGVO, das Datenübermittlungen an nach dem DPF zertifizierte US-Unternehmen ohne zusätzliche Garantien wie Standardvertragsklauseln (SCCs) oder Binding Corporate Rules (BCRs) zulässt.
Microsoft ist seit Inkrafttreten des DPF zertifiziert und gelistet. Das lässt sich direkt im öffentlichen Zertifizierungsregister des U.S. Department of Commerce (privacyshield.gov) überprüfen – ein Schritt, den jede Kanzlei im Rahmen ihrer Dokumentationspflichten ohne nennenswerten Aufwand selbst nachvollziehen kann. Die DPF-Zertifizierung ist kein Marketinglabel: Sie verpflichtet das Unternehmen zur Einhaltung der DPF-Grundsätze, unterstellt es der Aufsicht der U.S. Federal Trade Commission (FTC) und sieht verbindliche Streitbeilegungsmechanismen vor. Entscheidend ist ein Kernelement, das nach dem Schrems-II-Urteil ausdrücklich neu gestaltet wurde: die Einrichtung des «Data Protection Review Court» (DPRC), eines unabhängigen Gremiums, das europäischen Betroffenen erstmals einen effektiven Rechtsbehelf gegen Zugriffe amerikanischer Nachrichtendienste eröffnet.
Ob das DPF einer erneuten gerichtlichen Prüfung standhält, ist eine legitime Frage – Max Schrems und die Organisation NOYB haben bereits angekündigt, die Rechtmäßigkeit des Beschlusses anzufechten. Zum gegenwärtigen Zeitpunkt ist das DPF jedoch gültig. Wer sich auf einen wirksamen Angemessenheitsbeschluss stützt, bewegt sich im Rahmen von Art. 45 Abs. 1 DSGVO auf einer rechtlich tragfähigen Grundlage. Eine vorsorgliche Ablehnung aus Sorge vor einer künftigen Nichtigerklärung ist keine Datenschutzmaßnahme – sie ist Kaffeesatzlesen mit Compliance-Anstrich. Für eine Kanzlei bedeutet das: Solange das DPF gilt, ist es ein tauglicher Transferanker; gleichzeitig empfiehlt es sich, technische und vertragliche Komplementärmaßnahmen vorzuhalten, die auch im Falle eines «Schrems III» tragen.
Parallel zum DPF hat Microsoft auf technischer und infrastruktureller Ebene reagiert. Mit der «EU Data Boundary for the Microsoft Cloud» – einer Initiative, die seit 2022 schrittweise umgesetzt und für Microsoft 365 Commercial im Wesentlichen bis Ende 2023 abgeschlossen wurde – bietet das Unternehmen die Möglichkeit, ruhende Daten (Data at Rest) sowie wesentliche Verarbeitungsvorgänge auf den Europäischen Wirtschaftsraum (EWR) zu beschränken. Konkret: Kundendaten, pseudonymisierte personenbezogene Daten und service-generierte Daten werden bei entsprechender Konfiguration in Microsoft-Rechenzentren innerhalb der EU bzw. des EWR gespeichert und verarbeitet – nicht in den USA.
Für die datenschutzrechtliche Bewertung ist dieser Punkt zentral, weil er die Frage des Drittlandtransfers in weiten Teilen gar nicht erst entstehen lässt bzw. deutlich reduziert. Art. 44 DSGVO statuiert das Übermittlungsverbot in Drittländer ohne geeignete Garantien. Werden Daten jedoch nicht übermittelt, weil sie physisch und verarbeitungstechnisch im EWR verbleiben, greift das Transferregime des Kapitels V der DSGVO grundsätzlich von vornherein nicht. Es wäre unredlich zu behaupten, die EU Data Boundary eliminiere alle Transferprobleme vollständig – es verbleiben Support-Szenarien, in denen Microsoft-Mitarbeitende außerhalb des EWR temporär auf Daten zugreifen können müssen. Die pauschale Gleichsetzung von «Microsoft Cloud» und «Datentransfer in die USA» ist seit der EU Data Boundary jedoch nicht mehr haltbar.
Für Kanzleien ist dieser Aspekt besonders relevant: Mandantenakten, Buchhaltungsdaten, Prüfungsdokumentation und Korrespondenz lassen sich bei korrekter Tenant-Konfiguration im EWR halten – ein Argument, das gegenüber Mandanten und gegenüber der eigenen Berufskammer nachweisbar dokumentiert werden kann.
Ein weiteres technisches Instrument, das in der pauschalen Ablehnung von Microsoft 365 regelmäßig unerwähnt bleibt, ist die «Customer Lockbox». Die Funktion ist in Microsoft 365 ab bestimmten Enterprise-Lizenzplänen verfügbar und stellt sicher, dass Microsoft-Mitarbeitende ohne explizite Genehmigung des Unternehmenskunden keinen Zugriff auf Kundendaten erhalten – auch nicht zu Supportzwecken.
Der Mechanismus funktioniert wie ein Vier-Augen-Prinzip auf Systemebene: Benötigt ein Microsoft-Supportmitarbeitender zur Lösung eines technischen Problems Zugriff auf Kundendaten, löst das System automatisch eine Genehmigungsanfrage an den autorisierten Administrator des Kundenmandanten aus. Der Zugriff wird erst nach expliziter Freigabe durch den Kunden gewährt, ist zeitlich befristet und wird vollständig protokolliert. Anfragen können abgelehnt werden – und Microsoft muss diese Entscheidung akzeptieren. Für die Bewertung der Auftragsverarbeitung nach Art. 28 DSGVO, der klare Anforderungen an Auftragsverarbeiter stellt, ist Customer Lockbox damit ein zentrales Instrument zur Nachweisbarkeit und Kontrolle von Verarbeitungsvorgängen.
Bildlich gesprochen: Der Schlüssel zum Tresor liegt beim Kunden. Die Bank – also Microsoft – kann den Tresor nicht ohne Zustimmung des Schlüsselinhabers öffnen, auch nicht zu Wartungszwecken. Das ist nicht nur eine technische Schutzmaßnahme; es ist eine strukturelle Machtverschiebung in der Auftragsverarbeitungsbeziehung zugunsten des Verantwortlichen. Für Kanzleien ist das ein direkt verwertbares Argument im Rahmen der Sorgfaltspflichten, die § 203 Abs. 3 und 4 StGB an die Einbindung mitwirkender Personen stellt – einschließlich der nachweisbaren Auswahl- und Sicherungsmaßnahmen.
Wer Microsoft 365 nüchtern bewertet, kommt an einem Thema nicht vorbei, das tatsächlich regulatorischen Handlungsbedarf erzeugt: die Verarbeitung von Diagnose- und Telemetriedaten. Microsoft erhebt im Betrieb von Microsoft 365 systemseitig Daten zu Nutzungsverhalten, Fehlerereignissen, Leistungsmetriken und Konfigurationsparametern – teilweise zu eigenen Zwecken. Diese Verarbeitung steht nicht vollständig unter der Kontrolle des Kunden.
Die Datenschutzkonferenz (DSK) – das Gremium der deutschen Datenschutzaufsichtsbehörden – hat in ihrer Orientierungshilfe zu Microsoft 365 vom November 2022 genau diesen Punkt kritisch bewertet. Die DSK kam zu dem Schluss, dass Microsoft in bestimmten Telemetrie-Szenarien als eigenständiger Verantwortlicher im Sinne von Art. 4 Nr. 7 DSGVO agiert und nicht (nur) als Auftragsverarbeiter nach Art. 28 DSGVO. Das ist rechtlich erheblich, weil eine eigenverantwortliche Verarbeitung eines US-Unternehmens einem anderen Regime unterliegt als eine reine Auftragsverarbeitung: Der Kunde kann hier nicht allein durch vertragliche Gestaltung (AVV) für Rechtmäßigkeit sorgen; er muss prüfen, ob Microsofts eigene Verarbeitungszwecke eine taugliche Rechtsgrundlage aufweisen.
Microsoft hat auf diese Kritik reagiert. In den aktuellen Produktdatenschutzbestimmungen («Product Privacy Notice») und im «Microsoft Products and Services Data Protection Addendum» (DPA) hat das Unternehmen Anpassungen vorgenommen, um die Transparenz über Telemetrieverarbeitungen zu erhöhen und die Konfigurierbarkeit von Diagnosedaten zu verbessern. Enterprise-Kunden können über die Diagnoseeinstellungen in der Microsoft 365-Administratorkonsole zwischen «Erforderlichen Diagnosedaten» und «Optionalen Diagnosedaten» unterscheiden und den Umfang der an Microsoft übermittelten Daten reduzieren. Wer auf «Erforderliche Diagnosedaten» beschränkt, minimiert die telemetrische Datenübertragung auf das technisch Notwendige.
Damit ist das Telemetrieproblem nicht vollständig gelöst – es bleibt ein Residualrisiko, das im Verzeichnis der Verarbeitungstätigkeiten nach Art. 30 DSGVO und – sofern einschlägig – in einer Datenschutz-Folgenabschätzung nach Art. 35 DSGVO dokumentiert und bewertet werden muss. Aber es ist handhabbar. Wer Telemetrie als K.-o.-Kriterium behandelt, übersieht, dass nahezu jede Cloud-Plattform – ob aus den USA, der EU oder der Schweiz – Diagnosedaten erhebt. Die entscheidende Frage lautet stets: Wie transparent ist der Anbieter, und wie konfigurierbar ist der Datenfluss? Auch der vermeintlich «sichere» deutsche Anbieter ist hier zu prüfen.
Unabhängig vom DPF setzt der konforme Einsatz von Microsoft 365 eine korrekte vertragliche Grundlage voraus. Nach Art. 28 DSGVO ist jede Auftragsverarbeitung schriftlich zu regeln, mit den in Art. 28 Abs. 3 DSGVO normierten Mindestinhalten. Microsoft stellt das bereits erwähnte Data Protection Addendum (DPA) bereit, das als Auftragsverarbeitungsvertrag fungiert und für alle Microsoft-365-Kunden standardmäßig gilt; es enthält zudem die EU-Standardvertragsklauseln (SCCs) gemäß Durchführungsbeschluss (EU) 2021/914.
Für Unternehmen, die SCCs neben dem DPF als komplementären Transfermechanismus oder ausschließlich nutzen, gilt nach dem Schrems-II-Urteil und der EDPB-Empfehlung 01/2020 die Pflicht zur Durchführung eines «Transfer Impact Assessment» (TIA). Dabei handelt es sich um eine strukturierte Risikoanalyse, die prüft, ob das Recht und die Praxis des Empfängerlandes (hier: USA) den Schutz der SCCs in der Realität untergraben. Der EDPB (Europäischer Datenschutzausschuss) empfiehlt eine Prüfung anhand von sechs Fallkategorien. Angesichts des DPF-Angemessenheitsbeschlusses ist ein TIA für nach DPF zertifizierte Empfänger formell nicht mehr zwingend – der Beschluss entfaltet Bindungswirkung. Dennoch empfiehlt sich eine dokumentierte Risikobewertung als Element der Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO und – für Kanzleien – als Nachweis berufsrechtlicher Sorgfalt.
Für Steuerberater und Wirtschaftsprüfer endet die Prüfung nicht bei der DSGVO. § 203 StGB sanktioniert die Offenbarung anvertrauter Geheimnisse durch Berufsgeheimnisträger; § 62 StBerG und § 43 WPO konkretisieren die berufsrechtliche Verschwiegenheitspflicht. Seit der Neufassung von § 203 StGB im Jahr 2017 ist die Einschaltung «mitwirkender Personen» – also auch Cloud-Dienstleister – grundsätzlich zulässig, wenn die Mitwirkung zur Inanspruchnahme der Tätigkeit erforderlich ist und die mitwirkende Person zur Verschwiegenheit verpflichtet wird (§ 203 Abs. 3, 4 StGB).
Daraus folgen konkrete Anforderungen, die im Microsoft-365-Setup einer Kanzlei abgebildet werden müssen:
Die Bundessteuerberaterkammer (BStBK) und die Wirtschaftsprüferkammer (WPK) haben in ihren Hinweisen zur Cloud-Nutzung wiederholt klargestellt, dass Cloud-Dienste – auch US-amerikanischer Anbieter – nicht per se ausgeschlossen sind, sofern die berufsrechtlichen Anforderungen erfüllt werden. Die berufsrechtliche Schwelle ist also nicht «kein US-Anbieter», sondern «nachweisbar angemessene Vorkehrungen».
Praktisch heißt das: Eine Kanzlei, die EU Data Boundary aktiviert, Customer Lockbox nutzt, Telemetrie reduziert, einen wirksamen AVV mit SCCs vorhält, ein dokumentiertes TOM-Konzept fährt und das Ganze in ihrem Datenschutz- und Berufspflichtenmanagement nachweist, erfüllt bei entsprechender Konfiguration sowohl die DSGVO- als auch die berufsrechtlichen Anforderungen. Die Frage «§ 203 StGB-Verstoß durch M365?» beantwortet sich dann nicht über die Nationalität des Anbieters, sondern über die Qualität der Implementierung.
Eine sachliche Bewertung verlangt, zwei Risikokategorien sauber zu trennen: das regulatorische Restrisiko – also das Risiko, dass eine Behörde oder ein Gericht die bestehenden Transfermechanismen für unzureichend hält – und das Datenschutzrisiko im engeren Sinne, also das Risiko eines tatsächlichen Zugriffs Unbefugter auf personenbezogene Daten oder Mandatsgeheimnisse.
Das regulatorische Restrisiko ist real. Das DPF ist angreifbar, und es wäre naiv zu glauben, Max Schrems würde das Feld räumen. Ein «Schrems III“-Szenario» ist nicht ausgeschlossen. Wer ausschließlich auf das DPF setzt und keine komplementären technischen Maßnahmen ergriffen hat, stünde in einem solchen Fall vor einem erheblichen Erklärungsproblem. Wer hingegen EU Data Boundary aktiviert hat, Customer Lockbox einsetzt, Telemetrie auf das Minimum reduziert und ein DPA inklusive SCCs abgeschlossen hat, steht auch nach einem hypothetischen Schrems-III-Urteil deutlich stabiler – weil der Transfer in weiten Teilen schlicht nicht stattfindet.
Das Datenschutzrisiko im engeren Sinne wird hingegen häufig überschätzt. Die Wahrscheinlichkeit, dass ein US-Nachrichtendienst gezielt auf die Kalender-, E-Mail- oder Mandantendaten einer mittelständischen Steuerkanzlei zugreift, ist – Sondersektoren wie verteidigungsnahe Mandate ausgenommen – ausgesprochen gering. Der Fokus der Compliance-Arbeit sollte sich auf reale, wahrscheinliche Risiken richten: ungesicherte Endgeräte, schwache MFA-Konfigurationen, fehlerhafte Berechtigungsstrukturen, unverschlüsselte Postfächer, unklare Rollenkonzepte, Phishing. Diese Risiken bestehen mit oder ohne Microsoft 365 – und bestehen ebenso bei rein europäischen Cloud-Anbietern, einschließlich der in der Branche verbreiteten Spezialanwendungen.
Die Frage «Dürfen wir als Kanzlei Microsoft 365 einsetzen, wenn wir DSGVO-konform und berufsrechtlich sauber arbeiten wollen?» hat keine pauschale Antwort. Sie hat eine bedingte: Es kommt darauf an. Auf die Konfiguration. Auf das DPA. Auf die EU Data Boundary. Auf die Telemetrieeinstellungen. Auf das TOM-Konzept. Auf die Dokumentation. Auf die Mandanteninformation. Auf die Risikoabwägung. Und auf die Bereitschaft, regulatorische Verantwortung nicht zu delegieren, sondern wahrzunehmen.
Klar ist: Der pauschale Satz «M365 kann nicht datenschutzkonform genutzt werden, weil Microsoft ein US-Unternehmen ist» ist rechtlich unzutreffend. Er ignoriert das EU-US Data Privacy Framework als gültigen Angemessenheitsbeschluss nach Art. 45 DSGVO. Er ignoriert EU Data Boundary, Customer Lockbox und die Konfigurierbarkeit von Telemetriedaten. Er ignoriert, dass die DSGVO kein Herkunfts-, sondern ein Schutzprinzip kennt. Und er ignoriert, dass auch europäische Cloud-Anbieter datenschutzrechtliche und berufsrechtliche Hausaufgaben zu machen haben – inklusive der bei Steuer- und Prüfungssoftware verbreiteten Spezialanbieter.
Microsoft 365 ist kein Freifahrtschein. Es ist ein Werkzeug – mit bekannten Stärken, bekannten Schwächen und einem bekannten regulatorischen Rahmen. Wer diese Faktoren bewertet, dokumentiert und steuert, handelt datenschutz- und berufsrechtskonform. Wer sie ignoriert und stattdessen auf pauschale Ablehnung setzt läuft Gefahr, der eigentlichen Verantwortung nicht gerecht zu werden.
Die Datenschutz-Grundverordnung ist kein Verbotsregister. Sie ist ein Abwägungsrahmen. Wer das verstanden hat, stellt andere Fragen – präzisere, unbequemere, aber richtigere.
Die folgenden Fragen begegnen uns in Mandatsgesprächen, kanzleiinternen Datenschutzrunden und in der Beratung am häufigsten.
Nein, nicht per se. Seit der Neufassung von § 203 Abs. 3, 4 StGB im Jahr 2017 ist die Einschaltung externer Dienstleister – einschließlich Cloud-Anbietern – grundsätzlich zulässig, sofern die Mitwirkung zur Berufsausübung erforderlich ist und der Dienstleister zur Verschwiegenheit verpflichtet wird. Diese vertragliche Verpflichtung ist im Microsoft Data Protection Addendum (DPA) enthalten. Entscheidend ist nicht die Nationalität des Anbieters, sondern die Qualität der getroffenen Vorkehrungen: ein wirksamer AVV mit SCCs, EU Data Boundary, Customer Lockbox, reduzierte Telemetrie und ein dokumentiertes TOM-Konzept. Wer diese Bausteine nachweisbar implementiert, erfüllt die Anforderungen an «angemessene technische und organisatorische Vorkehrungen» im Sinne von § 203 Abs. 4 StGB.
Eine DSFA ist nach Art. 35 DSGVO erforderlich, wenn eine Verarbeitung «voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen» zur Folge hat. Die Liste der DSK zu Art. 35 Abs. 4 DSGVO enthält Fallgruppen, in denen eine DSFA verpflichtend ist. Für Steuerberater- und WP-Kanzleien ergibt sich aufgrund der Verarbeitung umfangreicher und sensibler Mandantendaten regelmäßig zumindest die Pflicht zur dokumentierten Schwellenwertprüfung. Eine vollständige DSFA wird in der Praxis dort empfehlenswert, wo neben dem klassischen Mandantenkern auch besondere Kategorien personenbezogener Daten (Art. 9 DSGVO – z. B. Gesundheitsdaten in Lohnabrechnungen, Sozialdaten) oder umfangreiche Verhaltensanalysen über Mitarbeitende (z. B. via Microsoft Purview, Insights) relevant werden. In jedem Fall sollte die Bewertung dokumentiert werden – sie ist Teil der Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO und Element berufsrechtlicher Sorgfalt.
In aller Regel: nein. Die Verarbeitung von Mandantendaten zur Erbringung steuerberatender oder prüfender Leistungen stützt sich datenschutzrechtlich auf Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung) oder Art. 6 Abs. 1 lit. c DSGVO (rechtliche Verpflichtung), nicht auf Einwilligung. Auch berufsrechtlich folgt aus § 203 StGB nach geltender Auffassung kein generelles Einwilligungserfordernis für die Einschaltung von Cloud-Dienstleistern, sofern die Voraussetzungen des § 203 Abs. 3, 4 StGB erfüllt sind. Empfehlenswert – und in vielen Mandatsverträgen Standard – ist eine transparente Information der Mandanten in den Mandatsbedingungen oder Datenschutzhinweisen über die eingesetzten IT-Dienstleister einschließlich Cloud-Anbieter. Eine ausdrückliche Einwilligung kann im Einzelfall bei besonders sensiblen Mandaten (z. B. Strafverteidigungsnähe, hoheitsnahe Sektoren) sinnvoll sein, ist aber kein Regelfall.
Mit Argumenten, nicht mit Defensive. Eine sachgerechte Antwort gegenüber Mandanten umfasst drei Elemente: Erstens den Hinweis auf den geltenden Angemessenheitsbeschluss nach dem EU-US Data Privacy Framework. Zweitens die konkrete Darstellung der getroffenen Maßnahmen – EU Data Boundary, Customer Lockbox, reduzierte Telemetrie, AVV mit SCCs, TOM-Konzept. Drittens den Hinweis darauf, dass auch deutsche und europäische Cloud-Anbieter denselben datenschutz- und berufsrechtlichen Sorgfaltsmaßstäben unterliegen und ihre Eignung ebenfalls nachweisen müssen. Wo Mandanten besondere Anforderungen haben (etwa als Auftraggeber gegenüber öffentlichen Stellen mit eigenen Cloud-Vorgaben), kann zusätzlich ein dediziertes Setup oder ein alternatives Tooling für genau dieses Mandat sinnvoll sein. Eine pauschale Migration der gesamten Kanzlei ist regelmäßig weder erforderlich noch verhältnismäßig.
Eine Nichtigerklärung (Kassation) des DPF würde die Rechtsgrundlage des Drittlandtransfers nach Art. 45 DSGVO entfallen lassen, hätte aber – anders als 2020 – keinen sofortigen Stillstand zur Folge. Microsoft hält mit dem DPA die EU-Standardvertragsklauseln als komplementären Transfermechanismus vor. Hinzu kommen die strukturellen Maßnahmen: Soweit Daten dank EU Data Boundary den EWR gar nicht verlassen, ist der Transfer-Tatbestand des Art. 44 DSGVO nicht eröffnet – das Schutzregime des Kapitels V der DSGVO greift nur, wo es etwas zu transferieren gibt. Kanzleien, die heute schon ein robustes Setup mit EU Data Boundary, Customer Lockbox, minimaler Telemetrie und einem dokumentierten TIA betreiben, sind auf ein «Schrems III»-Szenario erheblich besser vorbereitet als Kanzleien, die ausschließlich auf das DPF vertrauen. Die richtige Reaktion ist daher nicht ein vorsorglicher Anbieterwechsel, sondern eine vorsorgliche Vertiefung der ergriffenen Maßnahmen – und deren Dokumentation.
DSGVO (EU) 2016/679, insbesondere Art. 4, 5, 6, 9, 28, 30, 35, 44–49 | EuGH, Urteil v. 16.07.2020, C-311/18 (Schrems II) | Europäische Kommission, Durchführungsbeschluss (EU) 2023/1795 (EU-US Data Privacy Framework) | Europäische Kommission, Durchführungsbeschluss (EU) 2021/914 (Standardvertragsklauseln) | EDPB, Recommendations 01/2020 on measures that supplement transfer tools | Datenschutzkonferenz (DSK), Orientierungshilfe zu Microsoft 365, November 2022 | Schweizerisches Datenschutzgesetz (revDSG), in Kraft seit 01.09.2023, Art. 16 ff. | § 203 StGB; § 62 StBerG; § 43 WPO | Hinweise der Bundessteuerberaterkammer (BStBK) und Wirtschaftsprüferkammer (WPK) zur Nutzung von Cloud-Diensten | Microsoft, EU Data Boundary for the Microsoft Cloud – Dokumentation | Microsoft, Products and Services Data Protection Addendum (DPA) | U.S. Department of Commerce, Data Privacy Framework Program – Zertifizierungsregister