Die Cloud-Frage in der Kirche: Kirchliche Rechenzentren, Microsoft 365 und die Ehrlichkeit über Datenstandorte

Es gibt in kirchlichen Häusern einen Satz, der jede Cloud-Diskussion in dreißig Sekunden beendet, und zwar in beide Richtungen: „Wir haben doch unser Rechenzentrum.“ Gesagt von der einen Seite heißt er: Wir brauchen Microsoft nicht. Gesagt von der anderen Seite heißt er: Warum zahlen wir dann noch für etwas, das im Pfarrbüro niemand bedienen kann? Beide Lesarten sind bequem, und beide sind falsch.

Die ehrliche Antwort ist unbequemer und langweiliger: Ein kirchliches Rechenzentrum und Microsoft 365 lösen zu großen Teilen verschiedene Probleme. Das eine betreibt Fachverfahren, in denen Register geführt, Haushalte gebucht und Bezüge abgerechnet werden. Das andere organisiert, dass ein Presbyterium eine Vorlage gemeinsam liest, bevor es darüber abstimmt. Wer beides gegeneinander stellt, bekommt am Ende zwei halbe Lösungen und eine ganze Rechnung.

Dieser Beitrag ordnet das Feld nüchtern ein: was ein kirchliches Rechenzentrum leistet, was Microsoft 365 leistet, wo Hybridmodelle wirklich tragen — und was die Sätze über Datenstandorte tatsächlich bedeuten, die in Angeboten und Gremienvorlagen stehen. Er gehört zur Serie Microsoft 365 in Kirche, Diakonie und Caritas, in der die übrigen Bausteine — Datenschutzrecht, Mitbestimmung, Lizenzen, Architektur — einzeln behandelt werden.

Eine Vorbemerkung zur Fairness: Es werden hier keine konkreten Rechenzentren bewertet. Weder die evangelischen Verbünde noch die diözesanen IT-Dienstleister noch die Häuser, die Diakonie und Caritas beliefern. Es geht um Kategorien von Betriebsmodellen. Wer einen Anbietervergleich sucht, braucht eine Ausschreibung, keinen Fachartikel.

Was ein kirchliches Rechenzentrum wirklich leistet

Kirchliche Rechenzentren sind in Deutschland historisch gewachsen, und zwar aus einem sehr handfesten Grund: Die Verfahren, die Kirche braucht, gab es auf dem freien Markt nicht. Kein kommerzieller Anbieter baut ein System, das Kirchenaustritte verarbeitet, Kirchensteueranteile verteilt, Patenverhältnisse abbildet und die Kollekte einer Gemeinde in einen landeskirchlichen Haushalt überführt. Diese Fachlichkeit ist der eigentliche Wert, nicht der Serverraum.

Fachverfahren, Meldewesen, Finanzwesen

Der harte Kern ist überall ähnlich, ob im Landeskirchenamt oder im Generalvikariat. Das Meldewesen führt die Gemeindegliederdaten und hängt an den staatlichen Meldedatenströmen. Das Finanzwesen bildet eine Haushaltssystematik ab, die mit kaufmännischer Buchführung nur entfernt verwandt ist. Das Personalwesen rechnet nach kirchlichem Arbeitsrecht ab — Dritter Weg, AVR, eigene Eingruppierungen. Dazu kommen Friedhofsverwaltung, Gebäude- und Bauunterhaltung, Stiftungs- und Kollektenwesen.

In Diakonie und Caritas verlängert sich die Liste um die Fachverfahren der Einrichtungen: Klientenverwaltung in der Beratungsstelle, Belegungs- und Pflegedokumentation, Kita-Verwaltung, Jugendhilfe-Fachverfahren, im Krankenhaus das Krankenhausinformationssystem. Diese Systeme sind keine Bürosoftware. Sie haben eigene Aufsichten, eigene Prüfroutinen, eigene Zertifizierungen, und sie lassen sich nicht in eine Dokumentbibliothek überführen, nur weil dort die Suche schöner ist.

Was das Rechenzentrum außerdem mitbringt — und was oft übersehen wird

Ein gutes kirchliches Rechenzentrum liefert mehr als Rechenleistung: Es kennt die Kassations- und Archivordnung, es kennt die Prüfungswege der Rechnungsprüfungsämter, es weiß, warum ein Kirchenkreis anders bucht als ein Verband. Es hat Personal, das kirchliche Strukturen versteht, ohne dass man sie erklären muss. Das ist ein realer Vorteil, der in keiner Preisliste steht.

Ebenso real sind die Grenzen. Kirchliche Rechenzentren sind selten groß genug, um im Wettbewerb der Kommunikationsplattformen mitzuhalten. Eine Videokonferenzlösung auf dem Stand des Jahres 2026 zu betreiben, mit Telefonanbindung, mobilen Apps, Untertiteln und einem Sicherheitsbetrieb rund um die Uhr, ist eine industrielle Aufgabe. Wer sie trotzdem selbst übernimmt, tut es aus Überzeugung, nicht aus Wirtschaftlichkeit — und sollte das so auch in die Gremienvorlage schreiben.

Skizze 1: Aufgabenlandkarte — links das Fachverfahren, rechts die Zusammenarbeit, in der Mitte der eigentliche Projektauftrag.

FAKTEN — Wer beaufsichtigt eigentlich wen? Kirchliche Träger unterliegen nicht der DSGVO-Aufsicht der Länder, sondern eigenem Recht mit eigener Aufsicht: evangelisch dem DSG-EKD mit dem Beauftragten für den Datenschutz der EKD, katholisch dem KDG mit den Diözesandatenschutzbeauftragten beziehungsweise den gemeinsamen Datenschutzzentren. Das novellierte DSG-EKD gilt seit dem 1. Mai 2025. Die Novelle des KDG wurde von der Vollversammlung des Verbandes der Diözesen Deutschlands am 24. November 2025 beschlossen und ist zum 1. März 2026 in Kraft gesetzt worden, nachdem die Diözesanbischöfe sie in ihren Bistümern in Kraft gesetzt haben. Beide Gesetze kennen die Auftragsverarbeitung als eigenen Regelungsbereich. Prüfe die jeweils aktuelle Fassung mit deinem örtlich Beauftragten: Bei beiden Rechtskreisen hat sich bei Auftragsverarbeitung und Aufsichtsanbindung zuletzt etwas bewegt.

 

Was Microsoft 365 leistet — und was es ausdrücklich nicht ist

Microsoft 365 ist eine Plattform für Kommunikation, Zusammenarbeit und Büroarbeit. Postfach, Kalender, Chat, Besprechung, Telefonie, Dokumente, Intranet, dazu die Verwaltungsebene für Identitäten, Geräte, Klassifizierung und Aufbewahrung. Das ist ein großer Bereich, und er deckt den Alltag im Pfarramt, im Dekanat, in der Kreisgeschäftsstelle und in der Trägerverwaltung sehr weitgehend ab.

Die Stärke: Alltag, nicht Fachlichkeit

Der Nutzen entsteht dort, wo Menschen miteinander arbeiten. Ein Kirchenvorstand, der seine Vorlagen nicht mehr per E-Mail-Anhang in sieben Versionen austauscht. Eine Kita-Leitung, die den Dienstplan auf dem Diensthandy sieht, ohne Schreibtisch und ohne Desktop. Eine Beratungsstelle, deren Erreichbarkeit nicht mehr an einer Tischtelefonanlage aus dem vorigen Jahrzehnt hängt. Eine Verwaltung, die Ablagestrukturen hat, die man auch nach einem Personalwechsel noch versteht.

Dazu kommt eine Sicherheits- und Steuerungsschicht, die ein mittelgroßer Träger selbst nie bauen würde: bedingter Zugriff, mehrstufige Anmeldung, Geräteverwaltung, Schutzkennzeichnungen, Aufbewahrungsrichtlinien, Protokollierung. Das ist der Teil, den Aufsichten inzwischen sehen wollen und der in reinen Eigenbetrieben häufig fehlt.

Die Grenze: kein Fachverfahren, kein Register, kein Archiv im Rechtssinn

Microsoft 365 ist kein Meldewesen. Es ist kein Finanzverfahren. Es ist keine Klientenakte und kein Krankenhausinformationssystem. Es ist auch kein digitales Archiv im Sinne der kirchlichen Archivgesetze — Aufbewahrungsrichtlinien können Fristen abbilden, ersetzen aber keine Anbietung an das Archiv und keine Kassationsentscheidung.

Wer versucht, Fachlichkeit in Listen und Dokumentbibliotheken nachzubauen, landet nach etwa achtzehn Monaten bei einer selbstgebauten Anwendung ohne Betriebskonzept, ohne Testumgebung und mit genau einer Person, die sie versteht. Diese Person geht dann in Elternzeit. Das ist kein Witz, das ist ein Muster.

WICHTIG — Die Abgrenzung zur Kommune — und wo sie endet Echt anders als in einer Kommune: eigene Rechtsordnung statt DSGVO-Landesaufsicht, eigene Aufsichtsbehörden, Mitarbeitervertretung nach MVG-EKD oder MAVO statt Personalrat, Dienstgemeinschaft und Dritter Weg als Rahmen des Arbeitsrechts, Seelsorge- und Beichtgeheimnis als eigenständiger Schutzbereich, Klientendaten in Diakonie und Caritas mit besonderem Schutzbedarf, Ehrenamt als eigene Nutzergruppe ohne Arbeitsverhältnis. Nicht anders als überall sonst: Tenant-Grundeinstellungen, Identitätsschutz, Geräteverwaltung, Netzwerkanbindung, Lizenzmodelle, Migration, Schulung, Betrieb. Das ist normales Microsoft 365, und man sollte es auch so behandeln, statt jede Standardaufgabe mit kirchlicher Besonderheit zu begründen.

 

Datenstandort, EU-Datengrenze und die Ehrlichkeit über das Kleingedruckte

Jetzt zum Teil, der in Gremienvorlagen am häufigsten schiefgeht. Die EU-Datengrenze ist eine vertragliche Zusage von Microsoft, Kundendaten und personenbezogene Daten für die Unternehmens-Onlinedienste innerhalb eines geografisch definierten Raums zu speichern und zu verarbeiten. Dieser Raum umfasst die Staaten der Europäischen Union und der Europäischen Freihandelsassoziation; Microsoft betreibt dafür Rechenzentren in mehreren dieser Länder, darunter Deutschland.

Was die Zusage abdeckt

Kundendaten sind das, was ihr in den Dienst hineingebt: Postfachinhalte, Dateien, Teams-Chats, Kalendereinträge, Anhänge. Für Microsoft 365 gilt die EU-Datengrenze für Kunden mit einem Registrierungsstandort in der EU oder EFTA. Wer zusätzlich die Datenhaltung im eigenen Land vertraglich absichern will, kann ein Zusatzangebot für erweiterte Datenresidenz buchen, das unter anderem für Deutschland verfügbar ist.

Ebenfalls erfasst: pseudonymisierte personenbezogene Daten in den Systemprotokollen, die im Regelbetrieb entstehen. Microsoft verlangt intern, dass personenbezogene Angaben in diesen Protokollen pseudonymisiert werden, und beschränkt den Zugriff auf gehärtete Administrationsarbeitsplätze und virtualisierte Desktops.

Was die Zusage nicht abdeckt — und das ist der interessante Teil

Microsoft dokumentiert die Ausnahmen selbst, ziemlich ausführlich und ohne Schönfärberei. Man muss sie nur lesen, bevor man sie zitiert.

Sicherheitsbetrieb: Zur Abwehr weltweiter Angriffe werden pseudonymisierte personenbezogene Daten und Support-Daten außerhalb der Grenze verarbeitet, überwiegend in den USA, und in seltenen Fällen auch eng begrenzte Kundendaten.

Support und Beratung: Titel von Supportfällen, an Produktteams eskalierte Fälle und Sprachnachrichten an den Support können außerhalb liegen. Daten aus Beratungsleistungen fallen gar nicht erst in den Geltungsbereich und liegen derzeit in US-Rechenzentren.

Verzeichnisdaten: Eingeschränkte Verzeichnisangaben aus Microsoft Entra — darunter Benutzername und E-Mail-Adresse — können außerhalb der Grenze repliziert werden, um den Dienst überhaupt bereitzustellen.

Netzwerkwege: Um Latenz und Ausfallsicherheit zu steuern, kann Verkehr zeitweise außerhalb geroutet werden.

Vorschau- und Testdienste sind nicht einbezogen, ebenso wenig eingestellte Dienste und Daten in lokaler Software auf euren eigenen Geräten.

Vom Anwender ausgelöste Übertragungen: Wer eine Mail nach Übersee schickt, einen Gast aus einem Drittland in eine Besprechung holt oder einen Connector zu einem Fremdsystem einrichtet, übermittelt selbst. Microsoft bremst das bewusst nicht aus.

Wenn ein Kunde die Nutzung von Anthropic-Modellen in den generativen KI-Diensten von Microsoft zulässt, werden Kundendaten durch Anthropic in den USA verarbeitet; die Speicherung bleibt an der EU-Datengrenze.

Wer Multi-Geo-Funktionen erworben hat, fällt nicht in den Geltungsbereich der EU-Datengrenze — auch dann nicht, wenn der Mandant auf ein EU-Land eingetragen ist.

Skizze 2: Die Datenkategorien und ihre Wege. Die blaue Seite ist die Zusage, die rote Seite ist das, was trotzdem weiterläuft.

WARNUNG — „Die Daten liegen in Frankfurt, also ist alles gut“ — diese Verkürzung kostet dich die Prüfung Der Satz ist nicht falsch, er ist unvollständig. Er beantwortet genau eine Frage — wo liegen ruhende Kundendaten — und lässt drei andere offen: Wer kann darauf zugreifen? Was passiert mit den Protokoll-, Support- und Verzeichnisdaten? Und unter welcher Rechtsordnung steht das Unternehmen, das den Schlüssel zum Serverraum hat? Ein Standort ist eine geografische Tatsache, keine Zugriffsbeschränkung. Zugriffsbeschränkung entsteht durch Rollen, Genehmigungsprozesse, Freigabeverfahren wie die Kundensicherheitsbox, Protokollierung und Verschlüsselung — nicht durch die Postleitzahl des Rechenzentrums. Der gleiche Fehler in die andere Richtung ist genauso verbreitet: „Es ist ein US-Konzern, also geht es gar nicht.“ Auch das beantwortet keine einzige Frage aus einer Datenschutz-Folgenabschätzung. Beide Sätze sind Ausreden, sich nicht mit den Datenkategorien zu befassen. Formuliere in der Gremienvorlage stattdessen: Für die Datenart X gilt Betriebsmodell Y, weil Schutzbedarf Z. Das hält einer Nachfrage der Aufsicht stand. Der Frankfurt-Satz nicht.

 

Datenkategorie	Wo im Regelfall	Wann verlässt sie den Raum	Was du selbst steuern kannst
Kundendaten (Postfach, Dateien, Chats)	EU/EFTA, Standortwahl u. a. Deutschland	Eng begrenzt bei Sicherheitsuntersuchungen; sonst durch eigenes Handeln der Anwender	Datenresidenz-Zusatz, Kundensicherheitsbox, Gastzugangs- und Freigaberegeln
Systemprotokolle	EU/EFTA, pseudonymisiert	Für Bedrohungsanalyse und globale Qualitätsmessung	Wenig — dafür Protokollierung im eigenen Tenant sauber regeln
Support- und Beratungsdaten	Teils EU, Beratungsdaten in den USA	Bei Eskalation, Falltiteln, Sprachnachrichten	Was ihr in Tickets schreibt: keine Klartextdaten, keine Klientennamen
Verzeichnisdaten	EU/EFTA mit Replikation	Eingeschränkte Angaben wie Name und Adresse dauerhaft	Namenskonventionen, keine sprechenden Bezeichner mit Fallbezug
Fachverfahrensdaten	Kirchliches Rechenzentrum	Gar nicht — wenn ihr die Grenze haltet	Alles: Schnittstellen, Exporte, Zugriffsrechte

 

Verschlüsselung mit eigenem Schlüssel: was sie kann, was sie kostet

Sobald das Gespräch bei Datenstandorten unbequem wird, kommt der Vorschlag: „Dann verschlüsseln wir eben selbst.“ Guter Reflex, aber er zerfällt in zwei sehr verschiedene Verfahren mit sehr verschiedenen Folgen.

Kundenschlüssel — mehr Kontrolle, voller Funktionsumfang

Microsoft 365 verschlüsselt ruhende Daten ohnehin auf Datenträgerebene. Der Kundenschlüssel legt eine zusätzliche Ebene darüber, deren Wurzelschlüssel ihr bereitstellt und steuert. Abgedeckt sind Daten aus Exchange, SharePoint, OneDrive und Teams sowie — je nach Richtlinientyp — auch Copilot-Interaktionen. Nicht abgedeckt sind unter anderem Viva Engage, Planner und Teams-Liveereignisse.

Zwei Punkte, die man in einer Vorlage nicht verschweigen darf. Erstens: Der Kundenschlüssel schützt ausschließlich ruhende Daten in der Cloud, nicht Postfächer oder Dateien auf euren eigenen Systemen. Zweitens: Neben eurem Schlüssel existiert ein Verfügbarkeitsschlüssel, den Microsoft schützt — ohne ihn wäre der Dienst nicht betreibbar. Wer den Zugriff auf seine Schlüssel widerruft, löst dessen Löschung und damit die kryptografische Vernichtung der Daten aus. Das ist ein Notausgang, keine Alltagsfunktion.

Doppelschlüsselverschlüsselung — maximaler Schutz, maximaler Funktionsverlust

Bei der Doppelschlüsselverschlüsselung liegt ein Schlüssel bei Microsoft und der zweite ausschließlich bei euch, in einem Dienst, den ihr selbst betreibt — zum Beispiel im kirchlichen Rechenzentrum. Ohne beide Schlüssel bleibt der Inhalt für Microsoft undurchsichtig. Genau deshalb funktionieren für diese Inhalte auch die meisten Dienste nicht mehr.

Konkret: keine Inhaltssuche und keine Indizierung, keine eDiscovery, keine Datenverlustprävention, keine gemeinsame Dokumentbearbeitung, kein automatisches Speichern, kein Öffnen in Office für das Web, keine Nutzung durch Copilot, keine Nachrichtenflussregeln, die in den Anhang schauen müssen. SharePoint und OneDrive können solche Dateien nicht verarbeiten. Kalendereinträge, Teams-Besprechungen und Chats lassen sich damit gar nicht schützen. Lesen und schreiben lässt sich der Inhalt in den Windows-Office-Anwendungen; lizenzseitig setzt Microsoft dafür die höchste Ausbaustufe voraus.

Microsoft selbst empfiehlt dieses Verfahren für einen sehr kleinen Anteil der Daten — die Größenordnung, die in der Dokumentation als „Kronjuwelen“ beschrieben wird. Für kirchliche Träger ist das eine brauchbare Denkfigur: Es ist das Werkzeug für einige wenige Dokumente, nicht für die Beratungsstelle, und erst recht nicht für den Gemeindebrief.

Verfahren	Was es schützt	Was es kostet	Sinnvoll für
Standardverschlüsselung der Plattform	Ruhende Daten auf Datenträgerebene, Transportwege	Nichts, ist enthalten	Alles — die Grundlinie
Kundenschlüssel	Zusätzliche Ebene mit eurem Wurzelschlüssel über Exchange, SharePoint, OneDrive, Teams	Betriebsaufwand für Schlüsselverwaltung, Lizenzstufe, echte Löschgefahr bei Fehlbedienung	Träger mit Nachweispflichten gegenüber der Aufsicht
Doppelschlüsselverschlüsselung	Inhalt bleibt für Microsoft undurchsichtig, zweiter Schlüssel bleibt bei euch	Suche, eDiscovery, Datenverlustprävention, gemeinsame Bearbeitung, Web-Clients und Copilot entfallen	Einzelne Dokumente mit höchstem Schutzbedarf
Ablage außerhalb von Microsoft 365	Vollständige Trennung	Zwei Welten, zwei Betriebsmodelle, zwei Schulungen	Fachverfahren, Meldewesen, Klientenakte, Seelsorgedokumentation

 

TIPP — Die Frage, die du vor der Schlüsseldiskussion stellen solltest Verschlüsselung mit eigenem Schlüssel beantwortet die Frage „Wer kann im Ernstfall auf den Inhalt sehen?“. Sie beantwortet nicht die Frage „Gehört dieser Inhalt überhaupt in diese Plattform?“. Die zweite Frage ist billiger, schneller und meistens ergiebiger. In neun von zehn Fällen ist die richtige Antwort nicht ein zweiter Schlüssel, sondern eine klare Zuordnung: Seelsorge bleibt draußen, Meldewesen bleibt im Rechenzentrum, Klientendokumentation bleibt im Fachverfahren, und der Rest ist normale Büroarbeit mit sauberer Klassifizierung.

 

Die Betriebsmodelle im Vergleich

Jetzt die Tabelle, die in jede Vorlage gehört. Wichtig ist die letzte Spalte: Es gibt kein Modell, das für alles passt. Ein Träger kann für seine Bürowelt Modell drei fahren und für die Klientendokumentation Modell eins, ohne sich zu widersprechen.

Betriebsmodell	Vorteil	Nachteil	Passt für
Alles im kirchlichen Rechenzentrum	Eine Rechtsordnung, eine Aufsicht, bekannte Ansprechpartner, kirchliche Fachlichkeit im Haus	Kommunikations- und Zusammenarbeitsfunktionen hinken dem Markt hinterher; Sicherheitsbetrieb rund um die Uhr ist teuer	Meldewesen, Finanz- und Personalwesen, Fachverfahren der Einrichtungen
Microsoft 365 ohne eigenes Rechenzentrum	Schnell verfügbar, moderne Zusammenarbeit, starke Sicherheits- und Steuerungsebene	Kein Ort für Fachverfahren; Abhängigkeit von einem Anbieter; Datenkategorien müssen sauber geregelt sein	Kleine Träger ohne eigene Fachverfahren, einzelne Einrichtungen, Verbände
Hybrid: Rechenzentrum plus Microsoft 365	Jede Datenart dort, wo sie hingehört; Fachlichkeit bleibt, Zusammenarbeit wird modern	Zwei Betriebswelten, Identitäts- und Schnittstellenpflege, höherer Steuerungsaufwand	Landeskirchen, Bistümer, Kirchenkreise, Dekanate, größere Träger der Diakonie und Caritas
Souveräne öffentliche Cloud mit Datenresidenz-Zusatz	Vertraglich abgesicherte Datenhaltung im eigenen Land, zusätzliche Zugriffskontrollen	Zusatzkosten, nicht alle Dienste abgedeckt, ändert nichts an Protokoll- und Supportwegen	Träger mit expliziter Auflage der Aufsicht oder besonders exponierten Bereichen
Souveräne private Cloud (Microsoft 365 Local)	Exchange Server, SharePoint Server und Skype for Business Server auf eigener Infrastruktur, auch getrennt vom Netz betreibbar	Hardware, Betrieb und Personal beim Träger; nur über zertifizierte Partner; keine Cloud-Funktionen der Plattform	Sehr hohe Souveränitätsanforderungen, Rückfallebene für den Krisenfall
Fremde Groupware im kirchlichen Rechenzentrum	Kein US-Anbieter in der Kette, oft quelloffen	Funktionsumfang, Telefonie, mobile Nutzung und Integration mit Fachverfahren müssen einzeln geprüft werden	Träger mit klarer strategischer Festlegung und eigenem Betriebspersonal

 

FAKTEN — Souveräne private Cloud: Stand der Dinge Microsoft 365 Local ist allgemein verfügbar. Es bringt Exchange Server, SharePoint Server und Skype for Business Server auf eine vom Kunden besessene und verwaltete Azure-Local-Infrastruktur — wahlweise angebunden oder vollständig vom Netz getrennt. Die Bereitstellung läuft ausschließlich über von Microsoft zertifizierte Lösungspartner auf validierten Hardware-Konfigurationen. Ein Beispiel für eine große Installation umfasst eine dreiknotige Instanz für SharePoint und SQL, vier Einzelknoten für Exchange-Postfachrollen und zwei weitere für den Edge-Transport. Microsoft hat zugesagt, die Abonnement-Editionen von Exchange Server, SharePoint Server und Skype for Business mindestens bis 2035 zu unterstützen. Wichtig für die Erwartungssteuerung: Das ist Serversoftware in einer modernen Verpackung — nicht Teams, nicht Copilot, nicht die Steuerungsebene der Cloud.

 

Die Hybridarchitektur im Bild

Die praktisch häufigste Antwort ist das Hybridmodell. Es steht und fällt mit der mittleren Spalte: der Übergangsschicht. Wer dort keine Regeln hat, hat kein Hybridmodell, sondern zwei Systeme und viele Kopien. Die Identitätsfrage ist dabei die erste, die beantwortet werden muss — und bei Anwendungen, die vor Ort bleiben, hängt sie oft an der Frage, ob die Anmeldung sauber durchgereicht wird; wie das technisch funktioniert, ist im Kompetenzbereich Microsoft Kerberos beschrieben.

Skizze 3: Hybridarchitektur — kirchliches Rechenzentrum links, Microsoft 365 rechts, und die Übergangsschicht, in der die eigentliche Arbeit steckt.

WARNUNG — Der Klassiker: die Schnittstelle, die zur Kopie wird Ein diakonisches Werk in einer Großstadt wollte „nur die Stammdaten“ aus dem Fachverfahren in eine Liste in der Zusammenarbeitsplattform spiegeln, damit die Verwaltung nicht ständig nachfragen muss. Zwei Jahre später enthielt die Liste Betreuungsstatus, Ansprechpartner und Freitextfelder mit Fallnotizen. Niemand hat das entschieden. Es ist gewachsen, Feld für Feld, jeweils mit guter Begründung. Genau so entsteht aus einer Schnittstelle eine zweite Klientenakte — eine, die in keiner Verfahrensverzeichnis-Zeile steht und für die niemand eine Löschfrist definiert hat. Gegenmittel: Jeder Datenübergang bekommt eine Feldliste, einen Zweck, eine Löschfrist und einen Verantwortlichen. Erweiterungen laufen über denselben Weg wie die Ersteinrichtung. Klingt bürokratisch, ist aber billiger als die Nachbesserung nach einer Prüfung.

 

Vom Modell zur Entscheidung: Verträge, Aufsicht, Gremien

Die Auftragsverarbeitung ist eine Kette, kein Vertrag

Sowohl das DSG-EKD als auch das KDG regeln die Verarbeitung im Auftrag in eigenen Vorschriften: sorgfältige Auswahl, Prüfung der technischen und organisatorischen Maßnahmen, Festlegung von Gegenstand, Zweck, Datenarten, Weisungsrechten, Kontrollrechten, Unterauftragsverhältnissen und dem, was am Ende mit den Daten geschieht. Historisch war der große Stolperstein für Cloud-Dienste im evangelischen Bereich die Anforderung, dass sich der Auftragsverarbeiter der kirchlichen Datenschutzaufsicht unterwirft. Die Novellen haben hier Bewegung gebracht; wie die Verträge heute konkret aussehen müssen, ist in DSG-EKD verständlich: Was das evangelische Datenschutzgesetz für Microsoft 365 konkret bedeutet und KDG verständlich: Microsoft 365 unter dem Kirchlichen Datenschutzgesetz der katholischen Kirche ausführlich beschrieben.

Für die Cloud-Frage entscheidend ist: Es gibt nie nur einen Vertrag. In einem Hybridmodell hängen mindestens drei Parteien in der Kette — der Plattformanbieter, das kirchliche Rechenzentrum und meist ein Systemhaus mit administrativem Zugriff. Dazu kommt jeder Fachverfahrenshersteller einzeln. Ein Caritasverband auf Kreisebene, der das ordentlich aufgestellt hat, kommt schnell auf ein zweistelliges Vertragswerk. Das ist kein Zeichen von Überregulierung, sondern die logische Folge davon, dass Daten an mehreren Stellen verarbeitet werden.

Mitarbeitervertretung, Presbyterium, Kirchenvorstand, Synode

Die Wahl des Betriebsmodells ist keine reine IT-Entscheidung. Sie berührt Arbeitsabläufe, Erreichbarkeit, Protokollierung und damit die Mitbestimmung nach MVG-EKD beziehungsweise MAVO. Eine Dienstvereinbarung, die erst nach dem Rollout verhandelt wird, verhandelt über vollendete Tatsachen — und die MAV weiß das. Was in eine solche Vereinbarung gehört und was nicht, steht in Mitarbeitervertretung und Microsoft 365: MVG-EKD, MAVO, Dienstvereinbarung und Mitbestimmung bei Teams, Copilot und Protokollierung.

Auf der Leitungsseite sind es je nach Struktur Presbyterium oder Kirchenvorstand, Pfarrgemeinderat, Kirchenverwaltung, Kreissynodalvorstand oder Dekanatsrat, bei größeren Vorhaben die Synode oder das Generalvikariat. Die Erfahrung aus mehreren Verfahren: Gremien entscheiden schnell, wenn die Vorlage die Datenarten benennt und je Datenart ein Modell vorschlägt. Sie entscheiden gar nicht, wenn die Vorlage mit „Cloud ja oder nein“ überschrieben ist. Was die Aufsicht bei alledem sehen will, ist in Kirchliche Datenschutzaufsicht in der Praxis: Was BfD EKD und Diözesandatenschutzbeauftragte von einem Microsoft-365-Tenant erwarten zusammengetragen.

Skizze 4: Der Entscheidungsfahrplan. Sechs Schritte, in dieser Reihenfolge — Abkürzungen rächen sich in Schritt fünf.

TIPP — Formulierungshilfe für die Gremienvorlage Statt: „Wir führen Microsoft 365 ein, die Daten liegen in der EU.“ Besser: „Für Bürokommunikation, Gremienarbeit und Zusammenarbeit nutzen wir Microsoft 365 mit Datenhaltung in der EU und dem Zusatz für Datenresidenz in Deutschland. Meldewesen, Finanz- und Personalwesen sowie die Fachverfahren der Einrichtungen bleiben im kirchlichen Rechenzentrum. Seelsorgedokumentation wird in keinem der beiden Systeme geführt. Die Übergänge zwischen beiden Welten sind auf die Identitätssynchronisierung und zwei definierte Exporte beschränkt.“ Der zweite Text ist länger und wird deutlich schneller beschlossen — weil er beantwortbar ist.

 

Fazit

Die Cloud-Frage in der Kirche ist selten eine Grundsatzfrage und fast immer eine Zuordnungsfrage. Kirchliche Rechenzentren sind gut in dem, was Kirche fachlich einzigartig macht: Register, Haushalte, Bezüge, Fachverfahren, Archivlogik. Microsoft 365 ist gut in dem, was Kirche mit jedem anderen Arbeitgeber teilt: reden, schreiben, abstimmen, gemeinsam an Texten arbeiten, erreichbar sein. Die produktive Architektur nimmt beides und beschreibt den Übergang so genau, dass er nicht heimlich wächst.

Beim Thema Datenstandort lohnt sich Nüchternheit auf beiden Seiten. Die EU-Datengrenze ist eine ernstzunehmende, vertraglich unterlegte Zusage mit klar dokumentierten Ausnahmen — Sicherheitsbetrieb, Support, Verzeichnisdaten, Netzwerkwege. Verschlüsselung mit eigenem Schlüssel verschiebt Kontrolle, kostet aber in der stärksten Ausbaustufe fast alles, was die Plattform ausmacht. Und eine souveräne private Installation ist verfügbar, aber sie liefert Serversoftware im eigenen Haus, nicht die Cloud ohne Cloud.

Wer diese drei Sätze in seiner Vorlage stehen hat, muss die Cloud-Frage nicht mehr diskutieren. Er muss nur noch entscheiden, welche Datenart wohin gehört — und das ist eine Frage, die ein Presbyterium, ein Kirchenvorstand und eine Geschäftsführung tatsächlich beantworten können.

Häufige Fragen

Brauchen wir unser kirchliches Rechenzentrum noch, wenn wir Microsoft 365 einführen?

In aller Regel ja. Microsoft 365 ersetzt keine Fachverfahren. Solange ihr Meldewesen, Finanzwesen, Personalabrechnung nach AVR oder Fachverfahren in Kita, Pflege, Jugendhilfe und Beratung betreibt, braucht ihr den Betreiber dieser Verfahren weiter. Was sich ändert, ist der Umfang: Groupware, Ablage und Kommunikation wandern häufig aus dem Rechenzentrum ab, die Fachlichkeit bleibt.

Heißt „Datenstandort Deutschland“, dass niemand aus den USA auf unsere Daten zugreifen kann?

Nein. Der Standort sagt, wo die Daten liegen und verarbeitet werden. Ob jemand darauf zugreifen kann, hängt an Rollen, Freigabeprozessen und Verschlüsselung. Microsoft dokumentiert selbst, dass es keinen Standardzugriff auf Kundendaten gibt, dass Zugriffe zweckgebunden, befristet, protokolliert und auf gehärtete Arbeitsplätze beschränkt sind — und dass ihr über eine Kundensicherheitsbox zusätzlich selbst zustimmen könnt. Für Sicherheitsuntersuchungen gibt es dokumentierte Ausnahmen.

Ist ein kirchliches Rechenzentrum rechtlich automatisch die sichere Wahl?

Rechtlich einfacher, ja. Automatisch sicherer, nein. Auch ein kirchliches Rechenzentrum ist Auftragsverarbeiter und braucht einen Vertrag, technische und organisatorische Maßnahmen und eine Prüfung. Ein Haus mit zwölf Beschäftigten kann keinen Sicherheitsbetrieb rund um die Uhr leisten. Die richtige Frage lautet nicht „kirchlich oder nicht“, sondern „welche Schutzmaßnahmen weist der Betreiber nach“.

Sollen wir für sensible Bereiche Doppelschlüsselverschlüsselung einsetzen?

Nur für sehr wenige, einzeln benannte Dokumente — und auch dann erst, nachdem ihr geprüft habt, ob der Inhalt überhaupt in die Plattform gehört. Mit Doppelschlüsselverschlüsselung entfallen Suche, eDiscovery, Datenverlustprävention, gemeinsame Bearbeitung, die Web-Clients und Copilot; Teams-Besprechungen und Chats lassen sich damit gar nicht schützen. Für eine Beratungsstelle ist das kein tragfähiges Arbeitsmodell.

Wie behandeln wir Gemeindegliederdaten aus dem Meldewesen?

Getrennt. Das Meldewesen hat eigene Rechtsgrundlagen, eigene Datenflüsse und eine eigene Zweckbindung. Der Export einer Gemeindegliederliste in eine Dokumentbibliothek, damit „das Team schneller arbeiten kann“, ist der häufigste vermeidbare Befund in Prüfungen. Wenn eine Auswertung gebraucht wird, gehört sie in das Fachverfahren, nicht in die Zusammenarbeitsplattform.

Gilt das alles für Landeskirche und Bistum gleichermaßen?

In der Sache ja, in der Zuständigkeit nein. Evangelisch gilt das DSG-EKD mit dem Beauftragten für den Datenschutz der EKD, katholisch das KDG mit dem jeweiligen Diözesandatenschutzbeauftragten beziehungsweise dem zuständigen Datenschutzzentrum. Die Mitbestimmung läuft evangelisch über das MVG-EKD, katholisch über die MAVO. Die technische Architektur unterscheidet sich dadurch kaum, die Beteiligungs- und Genehmigungswege deutlich.

Wir sind eine kleine Kirchengemeinde. Ist das nicht alles zwei Nummern zu groß?

Die Fragen sind dieselben, die Antworten sind kürzer. Eine Gemeinde ohne eigene Fachverfahren hat in der Regel genau zwei Entscheidungen zu treffen: Wohin gehen Postfach und Ablage, und was passiert mit Seelsorgeinhalten. Für beides gibt es tragfähige Standardantworten. Der Aufwand steigt mit der Anzahl der Einrichtungen und Fachverfahren, nicht mit der Anzahl der Gemeindeglieder.

Was ist der häufigste Fehler bei der Einführung?

Die Reihenfolge. Erst wird das Produkt gekauft, dann der Schutzbedarf geklärt, dann die MAV informiert, dann die Aufsicht. Jede dieser Vertauschungen erzeugt Nacharbeit, und die Nacharbeit ist teurer als die ursprüngliche Konzeption. Der zweithäufigste Fehler: für das ganze Haus ein einziges Modell zu wählen, statt je Datenart zu entscheiden.

Weiter im Thema

Passende Beiträge und Seiten › Microsoft 365 in Kirche, Diakonie und Caritas › Microsoft 365 in Kirche, Diakonie und Caritas: Was wirklich anders ist als in Kommune und Mittelstand › DSG-EKD verständlich: Was das evangelische Datenschutzgesetz für Microsoft 365 konkret bedeutet › KDG verständlich: Microsoft 365 unter dem Kirchlichen Datenschutzgesetz der katholischen Kirche › Kirchliche Datenschutzaufsicht in der Praxis: Was BfD EKD und Diözesandatenschutzbeauftragte von einem Microsoft-365-Tenant erwarten › Microsoft 365 Einführungskonzept für kirchliche Träger: Die Kirchenedition zum Festpreis › Mitarbeitervertretung und Microsoft 365: MVG-EKD, MAVO, Dienstvereinbarung und Mitbestimmung bei Teams, Copilot und Protokollierung › Microsoft 365 für kirchliche Träger: DSG-EKD und KDG › Microsoft 365 in der öffentlichen Verwaltung › Microsoft-365-Schulung für kirchliche Träger

 

Wenn ihr die Zuordnung von Datenarten zu Betriebsmodellen für euer Haus konkret durchspielen wollt — mit Blick auf Rechenzentrum, Fachverfahren, Aufsicht und Mitbestimmung — führt der kürzeste Weg über die Microsoft-365-Beratung für kirchliche Träger.