Im Beitrag "Cloud-Software für Kanzleien: Der technische Aufbau im Überblick" wurde der technische Aufbau von Cloud-Software detailliert beleuchtet. Die komplexe, mehrstufige Architektur ist die Grundlage für die praktischen Vorteile von Cloud-Diensten, bringt aber gleichzeitig spezifische Gefahren für Rechtsanwaltskanzleien.

Die drei fundamentalen Risikobereiche

Im Folgenden werden drei fundamentale Risikobereiche, die sich unmittelbar aus dem technischen Aufbau ergeben, analysiert. 

1. Supply-Chain-Risiken: Die unsichtbare Abhängigkeitskette

Moderne Legal-Cloud-Software ist keine monolithische Anwendung mehr, sondern ein komplexes Geflecht aus hunderten bis tausenden Komponenten unterschiedlicher Herkunft. Diese sogenannte Software Supply Chain – die Lieferkette aller technischen und infrastrukturellen Bestandteile einer Anwendung – ist für Kanzleien in der Regel weder leicht einsehbar noch kontrollierbar und bringt technische und rechtliche Risiken, die sich auf zwei Ebenen manifestieren: in der Software-Architektur selbst und in der Cloud-Infrastruktur, auf der sie betrieben wird.

Die Abhängigkeitskaskade moderner Software

Legal-Cloud-Software lässt sich grundsätzlich in sechs Ebenen aufteilen: Frontend, API-Schicht, Business-Logic, Datenschicht, Infrastruktur und Integration. Typische Web-Anwendungen greifen dabei auf eine Vielzahl von Software-Bibliotheken zurück. Ein Node.js-Projekt enthält nicht selten über 1.000 npm-Pakete in seiner Dependency-Chain, wobei jede Bibliothek wiederum eigene – sogenannte transitive – Abhängigkeiten mitbringt. Diese Komponenten stammen von unterschiedlichen Entwicklern weltweit und werden über öffentliche Repositories verteilt.

Jede einzelne Bibliothek kann Schwachstellen enthalten, etwa durch unbeabsichtigte Programmierfehler, unzureichende Wartung oder – in seltenen Fällen – durch vorsätzliche Manipulationen. Für den Betreiber der Anwendung sind diese Risiken oft kaum zu überblicken, da viele Abhängigkeiten tief in der technischen Struktur verborgen sind und ohne konkrete Kenntnis der nutzenden Kanzlei als potenzielle Risikofaktoren existieren.

Subunternehmer-Ketten im Cloud-Betrieb

Ähnliche Intransparenzen bestehen auf der Infrastrukturebene. Selbst wenn ein Legal-Tech-Anbieter seine Anwendung bei einem Cloud-Provider mit Rechenzentren in Deutschland hostet, ist damit nicht gewährleistet, dass sämtliche Datenverarbeitung ausschließlich dort erfolgt. In der Praxis werden regelmäßig weitere spezialisierte Dienste eingebunden, etwa:

• Volltextsuche über externe Suchdienste wie Elastic Cloud,

• E-Mail-Versand über Drittanbieter wie SendGrid,

• Backups über separate Backup-Dienstleister,

• Content Delivery Networks (CDN) wie Cloudflare mit weltweit verteilten Knoten,

• Monitoring- und Fehleranalyse über Dienste wie Sentry oder Datadog.

Für Kanzleien entsteht hierdurch ein strukturelles Transparenz- und Kontrollproblem, da sie die vollständige Verarbeitungskette regelmäßig nur eingeschränkt überblicken können.

Das Transparenzdefizit der Supply Chain

Diese Intransparenz führt zu mehreren praktischen und rechtlichen Herausforderungen:

• Dynamische Änderungen: Cloud-Anwendungen werden kontinuierlich aktualisiert. Updates können neue Abhängigkeiten einführen oder bestehende verändern, ohne dass der Kunde hierauf unmittelbar Einfluss hat.

  
  

• Indirekte Sicherheitsvorfälle: Immer wieder zeigen Vorfälle, dass nicht die Kernsysteme selbst, sondern vorgelagerte oder nachgelagerte Dienste kompromittiert werden. Ob und wie schnell der Anbieter reagiert, liegt dabei allein in dessen Verantwortung – der Kunde hat hierauf keinen Einfluss.

  • MOVEit/Cl0p-Angriff: 2023 nutzten Angreifer in einer weit verbreiteten Drittanbieter-Transferlösung eine Zero-Day-Schwachstelle. Eine Zero-Day-Schwachstelle ist eine Sicherheitslücke, die dem Hersteller zum Zeitpunkt des Angriffs noch unbekannt war und für die folglich kein Sicherheitsupdate existierte. Zahlreiche Kanzleien waren betroffen, obwohl ihre eigene Infrastruktur keine Sicherheitslücke aufwies.

  • Log4Shell (2021): Im Dezember 2021 wurde eine kritische Schwachstelle in der Java-Bibliothek Log4j entdeckt. Diese Logging-Bibliothek wird in Millionen von Anwendungen weltweit eingesetzt – oft mehrere Ebenen tief in der Dependency-Chain. Die Schwachstelle erlaubte Angreifern die vollständige Übernahme betroffener Systeme.

    
    

• Vendor Lock-in: Die enge technische Verzahnung mit spezifischen Cloud-APIs erschwert einen Anbieterwechsel erheblich. Preisänderungen, Übernahmen oder strategische Neuausrichtungen des Anbieters können dadurch erhebliche Auswirkungen auf die Kanzlei haben.

Rechtliche Konsequenzen

Aus datenschutzrechtlicher Sicht sind die an der Erbringung von Legal-Tech- und Cloud-Dienstleistungen beteiligten Akteure – soweit sie personenbezogene Daten im Auftrag verarbeiten – als (Unter-)Auftragsverarbeiter im Sinne der Art. 28 ff. DSGVO einzuordnen. Die Kanzlei ist jedoch nicht verpflichtet, mit jedem einzelnen Subunternehmer selbst einen Auftragsverarbeitungsvertrag abzuschließen. Ausreichend ist ein Vertrag mit dem Legal-Tech-Anbieter als Haupt-Auftragsverarbeiter, der nach Art. 28 Abs. 4 DSGVO verpflichtet ist, sämtliche Subunternehmer vertraglich einzubinden und ihnen gleichwertige Datenschutzpflichten aufzuerlegen.

Nach Art. 28 Abs. 2 und Abs. 3 lit. d DSGVO muss die Kanzlei sicherstellen, dass weitere Auftragsverarbeiter nur mit ihrer vorherigen Genehmigung eingesetzt werden. Diese Genehmigung kann praxisgerecht als allgemeine Genehmigung ausgestaltet werden, verbunden mit einer Informations- und Widerspruchspflicht bei Änderungen der Subunternehmerliste. Eine vollständige technische oder organisatorische Durchdringung der gesamten Subunternehmerkette – etwa im Hinblick auf konkrete Bibliotheksversionen, interne Sicherheitsmaßnahmen oder den Zugriff auf Verschlüsselungsschlüssel – ist datenschutzrechtlich weder geschuldet noch realistisch umsetzbar. Die Kontrollpflicht der Kanzlei beschränkt sich auf eine angemessene, risikobasierte Auswahl-, Dokumentations- und Überwachungspflicht.

Unabhängig davon gelten die berufsrechtlichen Vorgaben zur anwaltlichen Verschwiegenheit. § 43e BRAO verlangt eine vertragliche Verschwiegenheitsvereinbarung mit dem Dienstleister und bei Einbindung Dritter deren Bindung an gleichwertige Geheimhaltungspflichten. Da Einzelfallkontrollen in komplexen Subunternehmer-Ketten praktisch kaum möglich sind, empfehlen BRAK und DAV eine „flow-down"-Gestaltung: Der Dienstleister verpflichtet alle Mitarbeiter und Subunternehmer auf dieselben Geheimhaltungspflichten und gibt diese entlang der gesamten Verarbeitungskette weiter.

Für den Einsatz von KI-Systemen folgt hieraus zusätzlich, dass Mandatsdaten nicht zu Trainings- oder Weiterentwicklungszwecken des Dienstleisters verwendet werden dürfen. Eine solche Nutzung überspannt regelmäßig die Erforderlichkeitsschwelle des § 43e BRAO und ist daher vertraglich ausdrücklich auszuschließen. Gleichwohl verbleibt ein strukturelles Transparenz- und Kontrollrisiko, das Kanzleien nur durch sorgfältige Vertragsgestaltung, dokumentierte Anbieterprüfung und laufende Beobachtung der Dienstleister minimieren können.

2. Shared Responsibility: Das Missverständnis der geteilten Verantwortung

Cloud-Anbieter arbeiten nach dem Prinzip der „Shared Responsibility".

Das Shared-Responsibility-Modell

Das Grundprinzip des Modells beruht auf der geteilten Verantwortung zwischen Anbieter und Kunde: Der Cloud-Anbieter ist verantwortlich für die Sicherheit der Cloud – also für Infrastruktur, Plattform und Cloud-Dienste selbst. Der Kunde trägt die Verantwortung für die Sicherheit in der Cloud – für alles, was er konfiguriert oder verwaltet, insbesondere Daten, Identitäten und Zugriffsrechte.

Bei Software-as-a-Service (SaaS) übernimmt der Anbieter Infrastruktur, Betriebssystem, Middleware und Anwendung. Die Kanzlei bleibt dennoch verantwortlich für:

Identitäts- und Zugriffsmanagement: Administratoren müssen definieren, wer auf welche Daten zugreifen darf. In Microsoft 365 lassen sich Berechtigungen auf Postfächer, SharePoint-Sites, Teams oder einzelne Dokumente vergeben. Komplexe Gruppenstrukturen, Vererbungen und externe Freigaben erhöhen das Risiko versehentlich zu weit geöffneter Zugriffe.

Datenverschlüsselung und Schlüsselverwaltung: Viele Dienste verschlüsseln Daten automatisch im Ruhezustand (Encryption at Rest). Entscheidend ist jedoch, wer die Verschlüsselungsschlüssel kontrolliert. Bei Provider-Managed Keys kann der Anbieter theoretisch auf die Daten zugreifen. Client-Side-Encryption und Customer-Managed Keys erhöhen die Sicherheit, werden in der Praxis jedoch selten angeboten und sind mit deutlich höheren Kosten verbunden. Zudem erfordern beide Ansätze eine erhebliche technische Expertise.

Konfiguration der Cloud-Dienste: Viele Dienste bieten hunderte Optionen für Sicherheit, Compliance und Datenschutz. Standardkonfigurationen sind nicht immer optimal – Fehlkonfigurationen können zu unbeabsichtigten Datenzugriffen führen.

Endgerätesicherheit: Kanzleien müssen die Sicherheit der Geräte gewährleisten, über die auf die Cloud zugegriffen wird. Malware oder kompromittierte Geräte können Datenlecks verursachen, selbst wenn die Cloud-Infrastruktur sicher ist.

Die Kluft zwischen Modell und rechtlicher Realität

Die technische Aufteilung des Shared-Responsibility-Modells korrespondiert nicht automatisch mit der rechtlichen Verantwortung. Nach § 43a BRAO ist der Rechtsanwalt zur Verschwiegenheit verpflichtet, und nach Art. 5 Abs. 2 DSGVO muss die Kanzlei die Einhaltung aller Datenschutzgrundsätze nachweisen können. Diese Verantwortung ist unteilbar:

• Kommt es zu einem Datenleck aufgrund einer Schwachstelle beim Anbieter, bleibt die Kanzlei datenschutzrechtlich verantwortlich.

• Sie muss den Vorfall nach Art. 33 DSGVO melden, haftet gegenüber Betroffenen nach Art. 82 DSGVO und kann mit Bußgeldern belegt werden.

• Die vertragliche Haftung der Anbieter ist typischerweise begrenzt; Reputations- und berufsrechtliche Folgen bleiben bei der Kanzlei.

Die technische Kompetenzlücke

Die sichere Nutzung von Cloud-Diensten erfordert Fachkenntnisse, die viele Kanzleien nicht vollständig abdecken können:

• Verständnis von Role-Based Access Control (RBAC) und Conditional Access

• Kenntnisse über Netzwerksegmentierung, Firewalls und Verschlüsselung

• Fähigkeit zur Konfiguration von Key Management und Monitoring

• Kenntnisse in Compliance-Frameworks wie ISO 27001 oder SOC 2

Da viele Kanzleien keine eigene IT-Abteilung haben, ist eine Verantwortungsdelegation an Managed Security Services, externe IT-Dienstleister oder zertifizierte Cloud-Anbieter empfehlenswert. Formal bleibt die Kanzlei verantwortlich, praktisch lässt sich das Risiko jedoch durch sorgfältige Auswahl, Dokumentation und Verträge erheblich reduzieren.

Praxisbeispiel: Orrick, Herrington & Sutcliffe

2023 wurde die US-Kanzlei Orrick Opfer eines Cyberangriffs, bei dem über nicht hinreichend gesicherte Systeme monatelang Zugriff auf interne Freigaben mit hochsensiblen Mandantendaten bestand. Betroffen waren Daten von über 600.000 Personen. Der Vorfall endete in einem Sammelklage-Vergleich über rund 8 Mio. USD.

Der Fall zeigt nicht das Versagen der Cloud-Infrastruktur, sondern die Folgen unzureichender Kundenkonfiguration, Zugriffskontrolle und Monitoring. Solche Vorfälle verdeutlichen die praktische Bedeutung des Shared-Responsibility-Modells: Selbst technisch sichere Plattformen erfordern vom Kunden aktive, sachgerechte Verantwortung.

3. Jurisdiktionsprobleme: Wenn Recht auf Technik trifft

Cloud-Daten bewegen sich häufig in einem Spannungsfeld mehrerer Jurisdiktionen. Maßgeblich ist dabei nicht allein der physische Speicherort, sondern auch die rechtliche Zugriffsmacht auf die Daten. Dies stellt Kanzleien vor besondere rechtliche Herausforderungen.

Die Geografie der Cloud – mehr als nur der Serverstandort

Die Zusicherung eines Cloud-Anbieters, Rechenzentren „in Deutschland“ oder „in der EU“ zu betreiben, bedeutet nicht zwingend, dass sämtliche Daten ausschließlich dort verarbeitet werden. Aus Gründen der Betriebssicherheit und Leistungsfähigkeit kommen regelmäßig technische Mechanismen zum Einsatz, etwa:

• Georedundanz zur Ausfallsicherung (z. B. Replikation innerhalb mehrerer EU-Regionen),

• Content Delivery Networks (CDN), die bestimmte Inhalte zwischenspeichern,

• Backups in räumlich getrennten Rechenzentren,

• sowie die zentrale Verarbeitung von Metadaten, Logs und Telemetriedaten zu Sicherheits- und Wartungszwecken.

Diese Datenverarbeitungen betreffen nicht in jedem Fall Mandatsinhalte im engeren Sinne. Gleichwohl erschweren sie die Transparenz über Datenflüsse, insbesondere wenn technische Begleitdaten nicht klar von inhaltlichen Mandatsdaten abgegrenzt werden.

CLOUD Act: rechtliches Risiko, kein Automatismus

Besondere Aufmerksamkeit erfährt in diesem Zusammenhang der US-amerikanische CLOUD Act. Er verpflichtet US-Unternehmen grundsätzlich, auf rechtmäßige Anordnung von US-Behörden Daten herauszugeben – auch dann, wenn diese außerhalb der USA gespeichert sind. Davon betroffen sind insbesondere große Cloud-Anbieter wie Microsoft, Amazon oder Google.

Dies bedeutet jedoch keinen schrankenlosen oder automatischen Zugriff auf in Europa gespeicherte Daten. CLOUD-Act-Anordnungen unterliegen rechtlichen Prüfungen und Konfliktmechanismen, insbesondere bei Kollisionen mit zwingendem ausländischem Recht. Gleichwohl verbleibt aus europäischer Perspektive ein strukturelles Restrisiko, da US-Unternehmen grundsätzlich der US-Rechtsordnung unterfallen.

Schrems II und die Grenzen vertraglicher Absicherung

Der EuGH hat mit dem Urteil Schrems II (C-311/18) klargestellt, dass internationale Datentransfers nicht allein durch Standardvertragsklauseln legitimiert werden können, wenn im Empfängerland staatliche Zugriffsbefugnisse bestehen, die mit europäischen Grundrechten unvereinbar sind. Die Entscheidung richtet sich dabei nicht gegen einzelne Anbieter, sondern gegen das System staatlicher Zugriffsmöglichkeiten insgesamt.

Für Kanzleien folgt daraus, dass vertragliche Zusicherungen eines Cloud-Anbieters notwendig, aber nicht hinreichend sind, wenn sie nicht durch zusätzliche technische oder organisatorische Schutzmaßnahmen ergänzt werden.

Mit dem EU-US Data Privacy Framework (DPF), das seit Juli 2023 auf Grundlage eines Angemessenheitsbeschlusses der Europäischen Kommission gilt, wurde ein neuer Rechtsrahmen für Datentransfers an zertifizierte US-Unternehmen geschaffen. Das DPF soll durch verbesserte Garantien auf US-Seite – insbesondere durch die Executive Order 14086 und einen neuen Rechtsschutzmechanismus (Data Protection Review Court) – die vom EuGH in Schrems II beanstandeten Defizite adressieren. Ob das DPF einer erneuten gerichtlichen Überprüfung standhalten wird, ist jedoch offen. Angesichts der strukturellen Kontinuität der US-Überwachungsgesetzgebung und der bereits gegen die beiden Vorgängerabkommen (Safe Harbor, Privacy Shield) ergangenen EuGH-Urteile sollten Kanzleien das DPF nicht als abschließende Lösung betrachten, sondern weiterhin ergänzende technische und organisatorische Schutzmaßnahmen implementieren.

Ein Praxisbeispiel: Microsoft und die Grenzen europäischer Datensouveränität

Besonders deutlich wurde dies im Juni 2025: In einer Anhörung vor dem französischen Senat räumte Microsoft unter Eid ein, nicht garantieren zu können, dass Daten europäischer Kunden aus EU-Rechenzentren nicht auf Grundlage des CLOUD Act herausverlangt werden könnten. Microsoft hatte bereits im Vorfeld und im Umfeld der Anhörung Souveränitätsinitiativen angekündigt – die „European Digital Commitments" (April 2025) und die Microsoft Sovereign Cloud (Juni 2025) – die Zugriffsrisiken zwar reduzieren, die extraterritoriale Reichweite des US-Rechts aber nicht beseitigen.

Der Vorgang verdeutlicht eine grundsätzliche Grenze solcher Maßnahmen: EU-Hosting und europäische Kontrollstrukturen können Risiken mindern, sie aber nicht vollständig eliminieren. Jurisdiktionskonflikte lassen sich durch Technik und Vertrag nur begrenzt auflösen.

Berufsrechtliche Dimension: besondere Sensibilität, kein Totalverbot

Für Rechtsanwältinnen und Rechtsanwälte verschärft sich diese Problematik durch die anwaltliche Verschwiegenheitspflicht sowie durch Zeugnisverweigerungs- und Beschlagnahmeprivilegien nach deutschem Recht. Diese Schutzmechanismen entfalten ihre Wirkung jedoch primär im deutschen bzw. europäischen Rechtsraum und lassen sich nicht ohne Weiteres auf ausländische Behörden übertragen.

Dies bedeutet jedoch nicht, dass die Nutzung internationaler Cloud-Dienste per se berufsrechtswidrig wäre. Vielmehr handelt es sich um ein erhöhtes Risiko, das bei der Auswahl, vertraglichen Ausgestaltung und technischen Absicherung von IT-Dienstleistungen besonders sorgfältig zu berücksichtigen ist.

Handlungsempfehlungen für deutsche Kanzleien

Die dargestellten Risiken sind keine theoretischen Extremszenarien, sondern folgen unmittelbar aus der technischen und rechtlichen Architektur moderner Cloud-Dienste. Für deutsche Anwaltskanzleien ergibt sich daraus kein generelles Verbot der Cloud-Nutzung, wohl aber ein erhöhter Prüf-, Dokumentations- und Steuerungsbedarf, der sich an Art, Sensibilität und Risikoprofil der jeweiligen Mandate orientieren muss.

1. Vertiefte Due Diligence vor Vertragsabschluss

Kanzleien sollten Cloud- und Legal-Tech-Anbieter vor Beauftragung systematisch prüfen. Dazu gehören insbesondere:

• Transparenz über eingesetzte Subunternehmer und Cloud-Infrastrukturen,

• Angaben zu Datenverarbeitungsorten und Drittstaatenbezügen,

• Klarheit darüber, wer technisch auf Daten und Verschlüsselungsschlüssel zugreifen kann.

• Etablierte Zertifizierungen wie BSI C5, ISO/IEC 27001 oder SOC 2 Typ II können die eigene technische Prüfung nicht ersetzen, belegen aber überprüfbare Grundkontrollen und dienen im Haftungsfall als Dokumentationsbaustein. Diese Prüfung ist zu dokumentieren und regelmäßig zu aktualisieren.

2. Risikobewertung nach Mandatstyp und Datenkategorie

Nicht jede Datenverarbeitung erfordert denselben Schutz. Für besonders sensible Mandate – etwa Strafverteidigung, Whistleblower-Beratung oder M&A-Transaktionen mit Insiderinformationen – sind Cloud-Dienste mit Drittstaatenbezug regelmäßig nur unter erheblichen zusätzlichen technischen und organisatorischen Schutzmaßnahmen vertretbar. In solchen Fällen kann auch ein bewusster Verzicht auf bestimmte Cloud-Lösungen sachgerecht sein.

3. Technische Härtungsmaßnahmen konsequent umsetzen

Wo Cloud-Dienste eingesetzt werden, sollten zusätzliche Sicherheitsmaßnahmen geprüft und – soweit praktikabel – implementiert werden. Dazu zählen insbesondere:

• Multi-Faktor-Authentifizierung und restriktives Identitäts- und Berechtigungsmanagement,

• konsequente Protokollierung und Monitoring sicherheitsrelevanter Zugriffe,

• der Einsatz von Client-Side-Encryption oder Customer-Managed Keys, soweit dies mit dem jeweiligen Dienst vereinbar ist und der damit verbundene Kosten- und Administrationsaufwand im Verhältnis zum Schutzbedarf steht.

4. Vertragliche Absicherung ernst nehmen

Auftragsverarbeitungsverträge sollten nicht als bloße Formalie verstanden werden. Sie müssen folgendes regeln:

• die Einbindung und den Wechsel von Subunternehmern,

• Informations- und Mitwirkungspflichten bei Behördenanfragen,

• Meldewege und Verantwortlichkeiten bei Sicherheitsvorfällen.
  Bei KI-basierten Diensten ist zudem ausdrücklich auszuschließen, dass Mandatsdaten zu Trainings- oder Entwicklungszwecken verwendet werden.

5. Incident-Response-Plan vorbereiten

Kanzleien sollten vorab definieren, wie bei einem Sicherheitsvorfall vorzugehen ist. Der Fall Orrick zeigt, dass nicht nur die Prävention, sondern auch die Reaktionsfähigkeit entscheidend ist. Ein Incident-Response-Plan sollte mindestens umfassen:

• Einhaltung der Meldepflichten nach Art. 33 und 34 DSGVO (72-Stunden-Frist gegenüber der Aufsichtsbehörde, unverzügliche Benachrichtigung betroffener Personen bei hohem Risiko),

• klare interne Zuständigkeiten und Eskalationswege,

• Kommunikationsstrategie gegenüber Mandanten, Versicherern und gegebenenfalls der Öffentlichkeit,

• forensische Sicherung betroffener Systeme zur Beweissicherung,

• regelmäßige Übungen und Aktualisierungen des Plans.

6. Hybride und differenzierte IT-Architekturen erwägen

Für viele Kanzleien kann ein hybrider Ansatz sinnvoll sein, bei dem besonders schützenswerte Daten On-Premise, also auf kanzleieigenen Servern oder On-Device auf Endgeräten verbleiben, während weniger kritische Prozesse in die Cloud ausgelagert werden. Voraussetzung hierfür sind klare Datenklassifizierungen und technisch saubere Trennungskonzepte. Eine ausführliche Darstellung lokaler KI-Architekturen bietet der folgende Beitrag „Lokale KI für Kanzleien: Der technische Aufbau im Überblick".

Fazit

Die Nutzung von Cloud- und Legal-Tech-Software stellt deutsche Anwaltskanzleien nicht vor ein punktuelles Compliance-Problem, sondern vor ein strukturelles Spannungsfeld zwischen Effizienzgewinnen und nicht vollständig auflösbaren rechtlichen und technischen Risiken. Supply-Chain-Komplexität, die praktische Bedeutung des Shared-Responsibility-Modells und jurisdiktionale Zugriffsmöglichkeiten sind keine vorübergehenden Begleiterscheinungen, sondern inhärente Eigenschaften des Cloud-Paradigmas.

Cloud-Nutzung ist dabei weder per se berufsrechtswidrig noch grundsätzlich unvereinbar mit Datenschutz- und Verschwiegenheitspflichten. Zugleich zeigt sich jedoch, dass zentrale Risiken – insbesondere im Zusammenhang mit Drittstaatenzugriffen und komplexen Subunternehmerstrukturen – durch Verträge und Technik lediglich begrenzt kontrollierbar sind. Die Verantwortung für diese Risiken bleibt letztlich bei der Kanzlei und lässt sich nicht vollständig auf Anbieter auslagern.

Die Entscheidung für oder gegen bestimmte Cloud-Dienste ist daher keine rein technische Frage, sondern eine strategische Grundsatzentscheidung, die das Selbstverständnis anwaltlicher Berufsausübung berührt. Kanzleien sind gefordert, ihre IT-Strategie bewusst, dokumentiert und risikoadäquat auszurichten, technische Kompetenz aufzubauen oder einzukaufen und im Zweifel konservative Lösungen zu wählen. Denn die anwaltliche Verschwiegenheitspflicht bildet das Fundament des Vertrauensverhältnisses zum Mandanten – und dieses Fundament darf auch im digitalen Zeitalter nicht relativiert werden.