Praktischer Leitfaden zur Datenresidenz-Architektur

Für die Erstellung eines Finanzberichts lädt ein Kollege eine Tabelle aus der Cloud herunter, ein anderer fragt Daten aus dem ERP an, und ein dritter kopiert Daten von einem externen Partnerportal. Der Prozess funktioniert – bis die Frage aufkommt: Wo genau befinden sich diese Daten, wer hat Zugriff darauf, und was passiert, wenn ein System oder Dienst ausfällt?

Der praktische Leitfaden zur Datenresidenz-Architektur bezieht sich nicht in erster Linie auf die geografische Platzierung von Servern. Es geht darum, dass die Speicherung, Verarbeitung, Übertragung und Wiederherstellung von geschäftskritischen Informationen kontrollierbar ist. Bei einem Unternehmen mit 20 bis 500 Mitarbeitern beeinflusst dies direkt die Betriebskontinuität, die Zuverlässigkeit von Berichten, das Vertrauen von Partnern und die Compliance-Risiken.

Was ist Datenresidenz wirklich?

Datenresidenz bezeichnet die physische und logische Umgebung, in der sich Daten geografisch, rechtlich und betrieblich befinden. Es reicht nicht zu wissen, dass eine Anwendung „in der Cloud läuft“. Es ist wichtig zu klären, in welcher Region die primären Daten gespeichert sind, wo Backups erstellt werden, wohin Integrationsnachrichten geleitet werden und in welchem Land das Supportpersonal arbeitet, das im Bedarfsfall auf das System zugreifen kann.

Die Frage wird besonders greifbar, wenn ein Webshop Bestelldaten an das ERP sendet, das ERP die Informationen an die Rechnungsstellung weitergibt und dann der Logistikpartner die für die Lieferung erforderlichen Daten erhält. Die Daten einer einzigen Bestellung können in mehreren Systemen, in mehreren Kopien und sogar in mehreren Ländern erscheinen. Wenn dies nicht bewusst geplant wurde, weiß das Unternehmen tatsächlich nicht mit absoluter Sicherheit, wo es seine Daten verwaltet.

Datenresidenz ist daher nicht nur eine rechtliche oder IT-Frage. Es ist auch eine betriebliche Frage. Wenn der Standort, der Eigentümer oder die Wiederherstellungsmethode einer kritischen Information nicht klar ist, basiert der tägliche Betrieb auf einer versteckten Abhängigkeit.

Datenresidenz-Architektur: Kartieren Sie zuerst den Datenfluss

Ein häufiger Fehler ist, dass die Organisation einen Dienstleister oder eine Cloud-Plattform auswählt, bevor sie den Datenfluss aufdeckt. Das ist, als würde man ein neues Lager bauen, ohne zu wissen, welche Waren, wie oft und von wo sie dorthin gelangen.

Ein guter Ausgangspunkt sind einige wichtige Geschäftsprozesse. Dazu gehören die Auftragsabwicklung, die Bearbeitung von Fertigungsaufträgen, die Rechnungsstellung, die Datenübertragung für die Gehaltsabrechnung oder die Erstellung von Managementberichten. Bei jedem Prozess muss verstanden werden, wo die Daten beginnen, wer sie ändert, welche Systeme Kopien davon erhalten und wo sie langfristig verbleiben.

Nicht alle Daten erfordern den gleichen Schutz oder die gleiche geografische Behandlung. Ein öffentlicher Produktkatalog, ein interner Bestandsbericht, ein Vertrag und HR-Dokumente mit persönlichen Daten stellen unterschiedliche Risiken dar. Eine einheitlich zu strenge Regulierung kann den Betrieb unnötig verteuern und verlangsamen. Ein zu lockerer Ansatz kann jedoch zu unkontrolliertem Zugriff und schwer zu handhabenden Compliance-Situationen führen.

Erstellen Sie ein Dateninventar mit einem Geschäftsverantwortlichen

Das Dateninventar ist keine technische Tabelle, die von der IT-Abteilung ausgefüllt wird. Für jede wichtige Datengruppe sollte es einen Geschäftsverantwortlichen geben, der sagen kann, warum die Daten benötigt werden, wie lange sie aufbewahrt werden müssen, welches Problem ein Fehler verursachen würde und wer sie verwenden darf.

Es ist ratsam, den Datentyp, das primäre System, die Zielsysteme der Integrationen, die Speicherregion, den Ort der Backups, die Aufbewahrungszeit und die Zugriffsrollen zu dokumentieren. Wenn eine Information in derselben Form in drei bis vier Systemen existiert, sollte dies ebenfalls festgehalten werden. Duplikation ist nicht immer ein Fehler: Sie kann aus Verfügbarkeits-, Leistungs- oder gesetzlichen Aufbewahrungsgründen erforderlich sein. Aber jede Kopie sollte einen Grund und einen Verantwortlichen haben.

Entscheidungen sollten von Risiko und betrieblichen Anforderungen geleitet werden

Bei Entscheidungen über Datenresidenz gibt es selten eine einzige, universell gültige Antwort. Für ein Unternehmen, das ausschließlich mit nationalen Systemen arbeitet, kann es gerechtfertigt sein, dass bestimmte Daten auf ungarischer Infrastruktur verbleiben. Ein E-Commerce-Unternehmen, das in mehreren Ländern verkauft, benötigt jedoch möglicherweise aus Leistungs-, Kundenservice- oder Partnergründen eine Verarbeitung in mehreren Regionen.

Wichtig ist, dass die Entscheidung dokumentiert ist. Das Management muss verstehen, für welche Daten eine bestimmte geografische Region erforderlich ist, bei welchen eine andere Platzierung akzeptabel ist und welche Kontrollen das Risiko mindern. Solche Kontrollen können Verschlüsselung, strikter rollenbasierter Zugriff, Protokollierung, regelmäßige Zugriffsüberprüfungen und ein getesteter Wiederherstellungsplan sein.

Der geografische Standort allein bietet keine Sicherheit. Ein lokal gespeichertes System kann riskant sein, wenn mehrere Personen ein gemeinsames Administratorkonto verwenden, keine Backup-Tests durchgeführt werden oder die Zugriffsprotokolle unverständlich sind. Ebenso kann eine gut geplante, regulierte Cloud-Umgebung eine kontrollierte Lösung sein, wenn die Organisation die Verantwortungsgrenzen kennt.

Unterscheiden Sie zwischen primären Daten, Kopien und Backups

Viele Betriebsprobleme resultieren daraus, dass das Unternehmen nicht zwischen diesen drei Begriffen unterscheiden kann. Primäre Daten sind die authentische Quelle, von der aus der tägliche Betrieb startet. Eine Kopie kann eine durch eine Integration erstellte Instanz in einem anderen System sein. Ein Backup dient nicht dem täglichen Betrieb, sondern der Wiederherstellung.

Wenn die Finanzdaten im ERP als authentisch gelten, der Managementbericht jedoch aus einer manuell aktualisierten Tabelle erstellt wird, darf die Tabelle nicht stillschweigend zur zweiten Wahrheitsquelle werden. In diesem Fall muss zuerst der Berichtsprozess in Ordnung gebracht werden: Warum ist eine manuelle Übertragung erforderlich, welche Daten fehlen im ERP und aus welchem System sollte der Bericht automatisch erstellt werden?

Dies ist ein weniger sichtbarer, aber wichtiger Teil der Datenresidenz-Architektur. Es regelt nicht nur, wo sich die Daten befinden, sondern auch, welchen Daten man vertrauen kann.

Integrationen sind oft versteckte Datenpfade

Auf der Systemliste eines Unternehmens stehen in der Regel ERP, CRM, Webshop, Abrechnungs- und Lagersystem. Weniger sichtbar sind die für den Datenverkehr kritischen Zwischenelemente: Integrationsdienste, E-Mail-Exporte, automatisierte Dateiübertragungen, externe Reporting-Tools und Entwickler-Testumgebungen.

Zum Beispiel kann eine aus einem Webshop kommende Bestelldaten über eine Integrationsplattform laufen, in ein Fehlerprotokoll aufgenommen und dann in einer E-Mail-Benachrichtigung angezeigt werden. Wenn die Bestellung persönliche oder geschäftlich sensible Daten enthält, sind all diese Wege Teil der Architektur. Es reicht nicht aus, zu überprüfen, wo der Webshop und das ERP laufen.

Daher sollte bei jeder wichtigen Schnittstelle geprüft werden, welche Daten durch sie hindurchgehen, ob sie vorübergehend gespeichert werden, wie lange sie verbleiben, welche Fehlerbehandlung erfolgt und wer die Protokolle sieht. Ein schlecht eingestellter Fehlerbericht kann jahrelang Daten speichern, die im Betrieb längst nicht mehr benötigt werden.

Planen Sie für Ausfälle, nicht nur für den Normalbetrieb

Der wahre Wert von Entscheidungen zur Datenresidenz zeigt sich in Fehlerfällen. Was passiert, wenn die primäre Region nicht verfügbar ist? Wie viel Datenverlust ist akzeptabel? Wie schnell müssen die Auftragsabwicklung, die Produktionsdaten oder die Rechnungsstellung wiederhergestellt werden?

Dies sind nicht ausschließlich technische Fragen. Wenn das Lager vier Stunden lang die zu erfüllenden Bestellungen nicht sieht, welche Verzögerung, Überstunden oder Kundenbeschwerden verursacht das? Wenn die Produktion einen Tag lang nicht auf die technischen Dokumentationen zugreifen kann, kann sie dann sicher arbeiten? Die Wiederherstellungsziele sollten aus solchen geschäftlichen Konsequenzen abgeleitet werden.

Ein Backup bietet nur dann Schutz, wenn es wiederhergestellt werden kann. Der regelmäßige Wiederherstellungstest ist daher keine administrative Last, sondern eine Validierung. Er zeigt, ob die Dokumentation real ist, die Berechtigungen verfügbar sind und das Unternehmen tatsächlich in der Lage ist, die kritischen Systeme in Betrieb zu nehmen.

Behandeln Sie es nicht als einmaliges Projekt

Ein neuer Partner, ein neues Land, ein neuer Webshop, eine Übernahme oder der Austausch eines alten Systems können den Datenfluss verändern. Eine einmal erstellte Architektur veraltet daher schnell, wenn keine Änderungsverwaltung dahinter steht.

Vor jeder bedeutenden Systemeinführung oder Integration sollte es einen einfachen, aber obligatorischen Kontrollpunkt geben: Welche Daten verarbeitet die neue Lösung, wo werden sie gespeichert, wer hat Zugriff darauf, welche weiteren Dienstleister sind beteiligt und wie passt sie in die Backup-, Protokollierungs- und Wiederherstellungsrichtlinien? Dies verlangsamt die Entwicklung nicht notwendigerweise. Es verhindert spätere Überraschungen, manuelle Umwege und kostspielige Anpassungen.

Eine gute Datenresidenz-Architektur zeichnet sich nicht dadurch aus, dass viele Dokumente darüber erstellt werden. Sondern dadurch, dass ein Manager schnell eine Antwort auf eine kritische Datengruppe erhält: Wo ist sie, wer ist dafür verantwortlich, wer hat Zugriff darauf, was ist damit verbunden und was passiert, wenn das primäre System nicht verfügbar ist? Wenn diese Antworten heute nur nach Rücksprache mit mehreren Personen, mehreren Tabellen und langem E-Mail-Austausch gegeben werden können, sollte man mit der Kartierung des Datenflusses beginnen.