Praktischer Leitfaden zur Datenresidenz-Architektur

Für die Erstellung eines Finanzberichts lädt ein Kollege eine Tabelle aus der Cloud herunter, ein anderer fordert 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 Dienstanbieter 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 der Berichte, das Vertrauen der Partner 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 aus zu wissen, dass eine Anwendung „in der Cloud läuft“. Es ist ratsam zu klären, in welcher Region die Primärdaten gespeichert werden, wo Backups erstellt werden, wohin Integrationsnachrichten gehen und in welchem Land das Support-Personal arbeitet, das bei Bedarf 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 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 niemand bewusst geplant hat, 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: Zuerst den Datenfluss kartieren

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 Verwaltung von Produktionsaufträ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 ein HR-Dokument 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 hingegen kann zu unkontrollierten Zugriffen 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 muss es einen Geschäftsverantwortlichen geben, der sagen kann, warum die Daten benötigt werden, wie lange sie aufbewahrt werden müssen, welcher Fehler ein Geschäftsproblem 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, muss dies ebenfalls vermerkt werden. Duplikation ist nicht immer ein Fehler: Sie kann für Verfügbarkeit, Leistung oder gesetzliche Aufbewahrung erforderlich sein. Aber jede Kopie sollte einen Grund und einen Verantwortlichen haben.

Die Entscheidungen sollten von Risiko und Betriebsbedarf gemeinsam geleitet werden

Bei Entscheidungen zur Datenresidenz gibt es selten eine einzige, für alles passende Antwort. Für ein Unternehmen, das ausschließlich mit inländischen Systemen arbeitet, kann es sinnvoll 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 Verarbeitung in mehreren Regionen.

Wichtig ist, dass die Entscheidung dokumentiert ist. Das Management muss verstehen, bei welchen 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, strenger rollenbasierter Zugriff, Protokollierung, regelmäßige Berechtigungsü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 Zugriffprotokolle unverständlich sind. Ebenso kann eine gut geplante, regulierte Cloud-Umgebung eine kontrollierte Lösung sein, wenn die Organisation die Verantwortungsgrenzen kennt.

Trennen Sie Primärdaten, Kopien und Backups

Viele Betriebsprobleme resultieren daraus, dass das Unternehmen nicht zwischen diesen drei Konzepten unterscheiden kann. Die Primärdaten sind die authentische Quelle, von der der tägliche Betrieb ausgeht. Eine Kopie kann eine aufgrund einer Integration erstellte Instanz in einem anderen System sein. Das Backup dient nicht dem täglichen Betrieb, sondern der Wiederherstellung.

Wenn das ERP die Finanzdaten als authentisch betrachtet, 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 manuelles Kopieren 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 Datenwege

Auf der Systemliste eines Unternehmens stehen in der Regel ERP, CRM, Webshop, Rechnungs- 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 können die Daten einer Bestellung aus einem Webshop über eine Integrationsplattform laufen, in ein Fehlerprotokoll gelangen und dann in einer E-Mail-Benachrichtigung erscheinen. Wenn die Bestellung persönliche oder geschäftlich sensible Daten enthält, sind diese Wege alle Teil der Architektur. Es reicht nicht aus zu überprüfen, wo der Webshop und das ERP laufen.

Daher ist es bei jeder wichtigen Schnittstelle ratsam zu prüfen, welche Daten darüber laufen, ob sie vorübergehend gespeichert werden, wie lange sie verbleiben, welche Fehlerbehandlung erfolgt und wer die Protokolle sieht. Ein schlecht eingestelltes Fehlerprotokoll kann jahrelang Daten aufbewahren, 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 der 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ögerungen, Überstunden oder Kundenbeschwerden verursacht das? Wenn die Produktion einen Tag lang nicht auf die technischen Dokumentationen zugreifen kann, kann sie sicher arbeiten? Die Wiederherstellungsziele müssen aus solchen geschäftlichen Konsequenzen abgeleitet werden.

Das 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 vorhanden 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 alle den Datenfluss verändern. Die einmal erstellte Architektur veraltet daher schnell, wenn keine Änderungsverwaltung dahintersteht.

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

Eine gute Datenresidenz-Architektur ist nicht daran erkennbar, dass viele Dokumente darüber erstellt werden. Sondern daran, 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 langen E-Mail-Wechseln kommen, sollte man mit der Kartierung des Datenflusses beginnen.