Wem gehört diese selbstgehostete Anwendung? Ein Register für Anwendungsverantwortlichkeiten aufbauen

Warum eine Anwendung technisch laufen und dennoch operativ ohne Verantwortliche sein kann

Eine funktionierende Anmeldeseite ist kein Nachweis für klare Verantwortlichkeit. Eine Anwendung kann über eine funktionierende Domain, ein gültiges TLS-Zertifikat, Serverressourcen und geplante Backups verfügen und dennoch in den entscheidenden Punkten ohne Verantwortliche sein, wenn eine Geschäftsentscheidung erforderlich ist. Wer entscheidet, ob das Tool noch benötigt wird? Wer genehmigt einen neuen Administrator? Wer bestimmt, ob ein Export weitergegeben werden darf? Wer kann entscheiden, dass die Wiederherstellung der Daten von gestern die richtige Reaktion auf einen Fehler ist?

Diese Lücke ist in kleinen und mittleren Portfolios häufig. Eine Abteilung fordert ein Tool an, jemand stellt es bereit und die Infrastrukturarbeiten werden abgeschlossen. Mit der Zeit wechselt die ursprünglich anfragende Person die Rolle, die Menschen mit Prozesswissen gehen, während Zugangsdaten, Integrationen und Daten bestehen bleiben. Die Anwendung läuft weiter, doch die Rechenschaftspflicht ist nur informell verteilt – oder überhaupt nicht vorhanden.

Das NIST Cybersecurity Framework 2.0 fordert, dass Cybersicherheitsrollen, Verantwortlichkeiten und Befugnisse festgelegt und kommuniziert werden. Dieses Prinzip lässt sich gut auf selbstgehostete Software übertragen: Klare Verantwortung ist keine Bürokratie um ihrer selbst willen. Sie beschleunigt alltägliche Entscheidungen und sorgt dafür, dass Entscheidungen unter hohem Druck weniger improvisiert getroffen werden.

Die Lösung ist ein Register für Verantwortlichkeiten selbstgehosteter Anwendungen: eine gepflegte Übersicht über jede Anwendung, ihren Zweck, die Personen mit Entscheidungsbefugnis, wichtige Abhängigkeiten und die erforderlichen Schritte, wenn sich der Dienst verändert oder ausfällt. Es kann als Tabellenkalkulation beginnen. NIST weist ausdrücklich darauf hin, dass ein Inventar so einfach wie eine Tabellenkalkulation sein kann; der Nutzen entsteht dadurch, dass es nutzbar, aktuell und mit tatsächlichen Betriebsentscheidungen verknüpft bleibt.

• Betrachten Sie „die Person, die es bereitgestellt hat“ als vorübergehende Tatsache, nicht automatisch als dauerhaft verantwortliche Person.
• Erfassen Sie Anwendungen, Daten, Software, Dienste und Lieferantenabhängigkeiten – nicht nur Server und Container.
• Weisen Sie jeder Produktionsanwendung eine namentlich benannte primäre verantwortliche Person und eine namentlich benannte Vertretung oder einen Eskalationsweg zu.
• Prüfen Sie Verantwortlichkeiten nach einem Rollenwechsel, einer wesentlichen Änderung von Integrationen, einem Sicherheitsvorfall oder einer Änderung des Geschäftsprozesses.

Trennen Sie die vier Verantwortungsrollen, bevor Sie Namen zuweisen

In einem sehr kleinen Team kann eine Person mehrere Rollen innehaben, doch die Rollen selbst sollten getrennt bleiben. So wird verhindert, dass von einem Infrastrukturbetreiber erwartet wird, über die Aufbewahrungsrichtlinie einer Abteilung zu entscheiden, oder dass eine geschäftlich verantwortliche Person ein Routing-Problem diagnostizieren soll. Das Register sollte für jede Rolle die verantwortliche Person oder das verantwortliche Team sowie die damit verbundene Befugnis benennen.

Die geschäftlich verantwortliche Person trägt die Verantwortung für das Ergebnis, das die Anwendung unterstützt. Sie definiert, warum die Anwendung existiert, wer sie nutzen soll, welches Ausmaß an Unterbrechung das Unternehmen tolerieren kann und ob die Anwendung weitergeführt, geändert oder eingestellt werden soll. Sie entscheidet über den Geschäftsprozess, ist aber nicht unbedingt die Person, die die Software konfiguriert.

Der Anwendungsadministrator übernimmt den Betrieb auf Anwendungsebene: Konten, Rollen, Konfiguration, Routineverwaltung und die erste Koordination mit Nutzern. Je nach Anwendung kann dies ein versierter Nutzer aus einer Fachabteilung, ein IT-Generalist oder eine externe Supportfunktion sein. Der Administrator sollte nicht stillschweigend zur endgültigen Entscheidungsinstanz für geschäftliche oder personenbezogene Datenentscheidungen werden, nur weil er die Bedienelemente nutzen kann.

Der Datenverantwortliche trifft oder eskaliert Entscheidungen über die Informationen im System: Datenklassifizierung, zulässige Nutzung, Weitergabe, Exporte, Aufbewahrung und Löschung. Bei Verarbeitungen im Geltungsbereich der DSGVO ist der Verantwortliche die Stelle, die Zwecke und Mittel der Verarbeitung personenbezogener Daten bestimmt; ein Auftragsverarbeiter verarbeitet personenbezogene Daten im Auftrag des Verantwortlichen. Rechtliche Rollen hängen von den Tatsachen und Vereinbarungen ab. Verwenden Sie ein operatives Register daher nicht als Ersatz für eine rechtliche Analyse. Die Unterscheidung ist dennoch operativ nützlich, weil sie Entscheidungen über den Datenzweck von den technischen Aufgaben des Hostings oder der Verarbeitung trennt.

Der Infrastrukturbetreiber trägt die Verantwortung für die Cloud- und Plattformebene rund um die Anwendung. Sein Aufgabenbereich kann je nach Servicevereinbarung den Serverbetrieb, den Lebenszyklus von Workloads, Routing, Zertifikate, DNS-Prüfungen und Backups umfassen. Diese Rolle besitzt nicht automatisch die Verantwortung für die Nutzer der Anwendung, den Geschäftsprozess, Entscheidungen zur Datenaufbewahrung oder die Genehmigung jeder Änderung. Bei Airbip laufen Anwendungsinstanzen als Docker-Workloads auf Airbip-Cloud-Servern, während Airbip die zugehörigen Infrastrukturdienste übernimmt, darunter Routing und TLS-Automatisierung, DNS-Prüfungen, Lifecycle-Management und konfigurierbare Backup-Zeitpläne. Kunden benötigen dennoch namentlich benannte Personen für Anwendungs-, Zugriffs- und Datenentscheidungen, die sich nicht aus der Infrastruktur ableiten lassen.

• Geschäftlich verantwortliche Person: verantwortlich für Zweck, Nutzer, Kritikalität sowie Entscheidungen über Fortführung oder Einstellung.
• Anwendungsadministrator: zuständig für die tägliche Anwendungskonfiguration und Kontoverwaltung.
• Datenverantwortlicher: verantwortlich für Klassifizierung, zulässige Nutzung, Aufbewahrung, Löschung und Entscheidungen über Exporte.
• Infrastrukturbetreiber: zuständig für den vereinbarten Umfang von Hosting- und Plattformbetrieb.
• Sicherheits- oder Datenschutzkontakt: Ergänzen Sie diese Rolle, wenn Risiko, Richtlinien oder Regulierung eine fachliche Prüfung erfordern.

Die Mindestfelder eines Registers für Anwendungsverantwortlichkeiten

Beginnen Sie mit einer Zeile pro Produktionsanwendung oder eigenständiger Produktionsinstanz. Ein Register, das sich leicht ausfüllen und prüfen lässt, ist besser als ein ausgefeiltes System, das niemand aktualisiert. Verweisen Sie auf unterstützende Dokumente, statt das Register zum Ablageort für jedes Konfigurationsdetail zu machen.

Die NIST-Leitlinien zum Asset-Management unterstützen ein Inventar, das umfassend genug ist, um Software, Systeme, Dienste, Daten und von Lieferanten bereitgestellte Dienste einzuschließen. Außerdem wird empfohlen, Assets anhand von Klassifizierung, Kritikalität, Ressourcen und Auswirkung auf die Mission zu priorisieren. Ihr Register sollte daher Betriebsfakten mit Informationen zu Verantwortung und Entscheidungsbefugnis verbinden.

Verwenden Sie stabile Kennungen. Produktnamen allein sind oft mehrdeutig, wenn ein Team eine Test- und eine Produktionsinstanz, mehrere Bereitstellungen für verschiedene Abteilungen oder eine außer Betrieb genommene Instanz mit weiterhin vorhandenen Daten hat. Erfassen Sie eine eindeutige interne ID, die Umgebung und die kanonische Service-URL.

• Anwendungsidentität: interne ID, Anwendungsname, Produktions- oder Nichtproduktionsumgebung, Service-URL und Bereitstellungsdatum, falls bekannt.
• Geschäftskontext: Zweck, geschäftlich verantwortliche Person, nutzende Abteilungen, Nutzerkreis und namentlich benannte Vertretung.
• Operative Kontakte: Anwendungsadministrator, Infrastrukturbetreiber, Eskalationskontakt für Sicherheit oder Datenschutz sowie gegebenenfalls Lieferanten- oder Anbieteransprechpartner.
• Kritikalität: eine einfache Stufe und eine Beschreibung in klarer Sprache, was ausfällt, wenn die Anwendung nicht verfügbar ist.
• Zugriff: verantwortliche Person für Kontofreigaben, privilegierte Zugriffe, Offboarding und Prüfungsrhythmus.
• Daten: Datenverantwortlicher, Klassifizierung, zentrale Datenkategorien, Speicherorte, Exporte, Aufbewahrungsregel, verantwortliche Person für Löschungsentscheidungen sowie anwendbare rechtliche oder interne Richtlinienverweise.
• Abhängigkeiten: Domain, DNS-Konto oder verantwortliche Person, E-Mail-Versanddienst, Identitätsanbieter, Integrationen, verantwortliche Person für API-Zugangsdaten, persistenter Speicher und Backup-Umfang.
• Änderung und Wiederherstellung: Änderungsgenehmiger, verantwortliche Person für Updateentscheidungen, verantwortliche Person für Wiederherstellungsentscheidungen, Wiederherstellungskontakte, Datum des letzten Wiederherstellungstests und Links zu Runbooks oder Testnachweisen.

Erfassen Sie Zweck, Nutzer und geschäftliche Kritikalität in Geschäftssprache

Beschreiben Sie den Zweck einer Anwendung nicht nur als „CRM“, „Wiki“ oder „Automatisierungstool“. Beschreiben Sie die Geschäftstätigkeit, die sie ermöglicht, zum Beispiel: „Pflegt die Interessenten- und Kunden-Nachverfolgungsdaten des Vertriebsteams“ oder „Veröffentlicht die öffentliche Dokumentation, die von Kunden und Support genutzt wird“. So können Personen außerhalb des technischen Teams Auswirkungen beurteilen und Prioritäten genehmigen.

Listen Sie sowohl vorgesehene als auch betroffene Nutzer auf. Ein internes Dashboard kann zehn direkte Nutzer haben, aber einen Dienst unterstützen, den alle Kunden verwenden. Ein Workflow-System kann nur zwei Administratoren haben, aber für einen monatlichen Finanzprozess unverzichtbar sein. Berücksichtigen Sie Spitzenzeiten, Fristen oder manuelle Alternativen, wenn sie wesentlich dafür sind, wie mit einer Unterbrechung umgegangen werden sollte.

Wählen Sie eine Methode zur Kritikalitätseinstufung, die Ihr Team konsistent anwenden kann. Es muss kein komplexes Bewertungsmodell sein. Eine praktische Stufe kann die Folgen eines Ausfalls, die Sensibilität der Daten, die Konzentration von Abhängigkeiten und die Verfügbarkeit eines praktikablen manuellen Prozesses kombinieren. NIST unterstützt die Priorisierung von Assets nach Klassifizierung, Kritikalität, Ressourcen und Missionsauswirkung.

Kritikalität ist eine Entscheidungsgrundlage, keine Garantie. Sie hilft der geschäftlich verantwortlichen Person und dem Infrastrukturbetreiber dabei, sich darauf zu verständigen, welche Dienste den klarsten Wiederherstellungsplan, häufigere Prüfungen der Verantwortlichkeit und bewusstere Änderungsfreigaben benötigen.

• Nennen Sie den Geschäftsprozess, nicht nur die Produktkategorie.
• Benennen Sie die Abteilung, die das Ergebnis verantwortet, und die Person mit Entscheidungsbefugnis.
• Erfassen Sie direkte Nutzer, betroffene Interessengruppen und zeitkritische Zyklen.
• Beschreiben Sie konkret, welche Folgen ein Tag ohne die Anwendung hat.
• Vermerken Sie, ob eine manuelle Ausweichlösung existiert, wer sie durchführen kann und welche praktischen Grenzen sie hat.
• Legen Sie ein Prüfdatum fest; die Kritikalität kann sich ändern, wenn sich Prozess, Integrationen oder Daten ändern.

Weisen Sie Verantwortlichkeiten für Konten, Rollen und privilegierte Zugriffe zu

Die Zugriffsverwaltung ist einer der deutlichsten Bereiche, in denen das Risiko entsteht, weil „alle dachten, jemand anderes kümmert sich darum“. Das Register sollte beantworten, wer Zugriff beantragen darf, wer ihn genehmigt, wer Konten erstellt oder ändert, wer erhöhte Berechtigungen vergeben kann und wer Zugriffe nach einem Rollenwechsel oder Austritt prüft.

Die NIST-Übersichtsleitlinien empfehlen eindeutige Konten für Beschäftigte und einen auf die für ihre Aufgaben notwendigen Ressourcen beschränkten Zugriff. Übertragen Sie dies in eine praktische Betriebsregel: Vermeiden Sie gemeinsam genutzte namentliche Nutzerkonten, sofern individuelle Konten möglich sind, gewähren Sie nur den für die zugewiesene Arbeit erforderlichen Zugriff und machen Sie den Genehmigungsweg sichtbar.

Privilegierter Zugriff benötigt ein eigenes Feld. Ein normaler Anwendungsnutzer, ein Anwendungsadministrator, ein Domainadministrator und ein Infrastrukturadministrator können den Dienst jeweils auf unterschiedliche Weise beeinflussen. Erfassen Sie, welche Rolle auf die Anwendungsverwaltung, Server- oder Workload-Steuerung, DNS, E-Mail-Versandeinstellungen, Backups und Integrationszugangsdaten zugreifen kann. Tragen Sie keine Geheimnisse in das Register ein; erfassen Sie nur das führende System für das Geheimnis und die verantwortliche Person.

Schließen Sie einen Offboarding-Auslöser ein. Ein Register ersetzt keine Identity- und HR-Prozesse, sollte aber benennen, wer bestätigt, dass Konten und privilegierte Zugriffe geprüft werden, wenn ein Beschäftigter, Auftragnehmer oder Administrator ausscheidet oder Verantwortlichkeiten wechselt.

• Weg zur Kontobeantragung: antragstellende Person, genehmigende Person und Administrator.
• Rollenmodell: Standardrollen, wer sie zuweisen darf und wer benutzerdefinierte Rollen erstellen kann.
• Verantwortliche Person für privilegierte Zugriffe: namentlich benannte Person oder Team für jede administrative Oberfläche.
• Prüfungsrhythmus für Zugriffe: Definieren Sie das Ereignis oder Intervall, das eine Prüfung auslöst.
• Verantwortliche Person für Offboarding: Benennen Sie, wer die Entfernung oder Neuzuweisung von Zugriffsrechten bestätigt.
• Notfallzugriff: Dokumentieren Sie, wer ihn autorisieren darf und wie die Entscheidung anschließend festgehalten wird.

Weisen Sie Verantwortlichkeiten für Datenklassifizierung, Aufbewahrung, Exporte und Löschung zu

Infrastruktur kann Daten bewahren, aber nicht entscheiden, welche Daten erhoben werden sollen, ob sie exportiert werden dürfen oder wie lange sie identifizierbar bleiben sollen. Dies sind Governance-Entscheidungen, die bei den geschäftlich und für Daten verantwortlichen Personen liegen, gegebenenfalls unter Einbezug von Anforderungen aus Datenschutz, Sicherheit, Verträgen und Aktenführung.

Für Verarbeitungen im Geltungsbereich der DSGVO nennt Artikel 30 nützliche Elemente für Aufzeichnungen, etwa Kontaktdaten des Verantwortlichen, Verarbeitungszwecke, Kategorien betroffener Personen und personenbezogener Daten, Empfänger, Übermittlungen, Fristen für die Löschung sowie eine allgemeine Beschreibung der technischen und organisatorischen Sicherheitsmaßnahmen. Ihr Register für Anwendungsverantwortlichkeiten muss kein formelles Verzeichnis von Verarbeitungstätigkeiten duplizieren, sollte aber darauf verlinken oder genügend Informationen enthalten, um den verantwortlichen Datenverantwortlichen und die maßgebliche Aufzeichnung zu identifizieren.

Die Aufbewahrung sollte als zweckgebundene Entscheidung formuliert sein, nicht lediglich als „für immer aufbewahren“ oder als Anzahl der Tage, für die ein Backup besteht. Der Grundsatz der Speicherbegrenzung in der DSGVO verlangt, dass personenbezogene Daten nicht länger als für den Zweck erforderlich in einer Form gespeichert werden, die die Identifizierung ermöglicht, vorbehaltlich bestimmter Ausnahmen. Ob und wie dies auf Ihre Organisation zutrifft, hängt vom Kontext ab; operativ entscheidend ist, zu benennen, wer die Aufbewahrungsentscheidung verantwortet und wo sie dokumentiert ist.

Unterscheiden Sie gedanklich zwischen Live-Daten, Exporten, Protokollen und Backups. Ein Administrator kann möglicherweise einen Datensatz in der Anwendung löschen, während eine Backup-Kopie einem anderen Lebenszyklus unterliegt. Nach Ende von Auftragsverarbeitungsdiensten gemäß DSGVO entscheidet der Verantwortliche über Löschung oder Rückgabe personenbezogener Daten, vorbehaltlich gesetzlicher Aufbewahrungspflichten. Ihr Register sollte Entscheidungsbefugnis und erwarteten Prozess sichtbar machen, statt anzunehmen, dass eine Infrastrukturmaßnahme die Frage abschließend klärt.

• Benennen Sie den Datenverantwortlichen und verlinken Sie auf das anwendbare Dateninventar, die Richtlinie oder das Verarbeitungsverzeichnis.
• Klassifizieren Sie die wichtigsten Datentypen, einschließlich personenbezogener, vertraulicher, finanzieller oder betrieblicher Informationen gemäß dem Schema Ihrer Organisation.
• Erfassen Sie, wo Daten liegen: Anwendungsdatenbank, Dateispeicher, angebundene Dienste, Exporte sowie Backup-Speicherorte oder -Umfänge.
• Definieren Sie, wer Exporte, Importe, Massendownloads und integrationsbasierte Übermittlungen genehmigen darf.
• Erfassen Sie verantwortliche Personen für Aufbewahrungs- und Löschungsentscheidungen, die maßgebliche Regel und Ausnahmen, die eine Genehmigung erfordern.
• Dokumentieren Sie die Löschung in der Anwendung, die Backup-Aufbewahrung und die Beendigung des Dienstes als getrennte operative Fragen.

Dokumentieren Sie Domains, DNS-, E-Mail- und Integrationsabhängigkeiten

Viele Anwendungsausfälle sind Abhängigkeitsausfälle. Ein Dienst kann funktionsfähig sein, während Nutzer ihn nicht erreichen können, weil sich Domain, DNS-Eintrag, Zertifikatspfad, Identitätsanbieter, Mailkonfiguration oder externe Integration geändert haben. Diese Abhängigkeiten sollten mit derselben Sorgfalt dokumentiert werden wie die Anwendung selbst.

Für öffentliches Routing unterscheidet die Traefik-Dokumentation zwischen EntryPoints, die Traffic entgegennehmen, Routern, die Anfragen mit Diensten verbinden, und optionaler Middleware. In der TLS-Dokumentation wird darauf hingewiesen, dass die automatische Zertifikatsverwaltung für konfigurierte Domains davon abhängt, dass die relevanten DNS-Einträge auf Traefik verweisen. Die operative Lehre ist einfach: Erfassen Sie die kanonische Domain, die für DNS verantwortliche Person, den Ort der DNS-Verwaltung sowie die Person, die Änderungen genehmigen oder durchführen kann. Verlassen Sie sich nicht auf das Registrar-Konto eines früheren Mitarbeiters oder undokumentierte Zugangsdaten.

Wenn die Anwendung E-Mails versendet, erfassen Sie die Versanddomain oder den Versanddienst, die verantwortliche Person für die relevanten DNS-Einträge und die Person, die Konfigurationsentscheidungen verantwortet. Bei Integrationen erfassen Sie, was die Verbindung tut, welche Daten sie austauscht, wer die Zugangsdaten verantwortet, wer auf beiden Seiten geschäftlich verantwortlich ist und welche Folgen ein Ausfall hat. Ein Link zur Integrationsdokumentation ist hilfreicher als eine vage Notiz wie „mit Automatisierung verbunden“.

Bei containerisierten Bereitstellungen erfassen Sie persistenten Speicher getrennt vom laufenden Workload. Docker unterstützt externe Volumes, deren Lebenszyklus außerhalb der Anwendung verwaltet wird. Ein Container kann neu erstellt werden, während der Datenspeicher einen separaten Lebenszyklus, eine andere verantwortliche Person und eigene Wiederherstellungsaspekte hat. Docker-Labels können Container, Volumes, Netzwerke, Images und Dienste außerdem mit Schlüssel-Wert-Metadaten versehen; wenn Ihre Bereitstellungspraxis dies unterstützt, nutzen Sie nicht sensible Labels wie eine interne Anwendungs-ID oder Verantwortungsgruppe, um die Nachverfolgbarkeit zu verbessern. Das Register sollte die maßgebliche geschäftliche Aufzeichnung bleiben, statt sich allein auf technische Labels zu verlassen.

• Kanonische URL, alternative Domains und umgebungsspezifische URLs.
• Verantwortliche Person für Domain-Registrar und DNS-Verwaltung mit Eskalationsweg.
• Verantwortung für Routing und TLS einschließlich der vereinbarten Grenze des Infrastrukturservices.
• E-Mail-Versandabhängigkeit, verantwortliche Person für die Absenderdomain und Konfigurationskontakt.
• Abhängigkeiten von Identität, Zahlungen, Analyse, Speicher, APIs und Automatisierung.
• Zweck der Integration, ausgetauschte Daten, verantwortliches System für Zugangsdaten und Auswirkungsgrad bei Ausfall.
• Persistente Volumes oder andere dauerhafte Speicher, Backup-Umfang und Speicherverantwortliche.

Legen Sie Entscheidungen zu Änderungen, Updates und Wiederherstellung vor einem Vorfall fest

Ein Vorfall ist der schlechteste Zeitpunkt, um festzustellen, dass der Infrastrukturbetreiber zwar ein Backup wiederherstellen kann, aber nicht befugt ist, einen Wiederherstellungspunkt auszuwählen, oder dass die geschäftlich verantwortliche Person ein Update verschieben möchte, aber niemand weiß, wer das Risiko bewertet. Schreiben Sie den Entscheidungsweg auf, bevor er dringend wird.

Verwenden Sie eine schlanke Änderungsmatrix. Routinemäßige, rückgängig machbare Anwendungsverwaltung kann an den Anwendungsadministrator delegiert werden. Änderungen, die Nutzer, Datenverarbeitung, Integrationen, öffentliche Domains oder Geschäftsabläufe betreffen, sollten einen benannten Genehmiger haben. Änderungen an Infrastruktur, Routing, Backup-Konfiguration oder Plattformlebenszyklus sollten entsprechend dem vereinbarten Serviceumfang mit dem Infrastrukturbetreiber koordiniert werden. Das Ziel besteht nicht darin, alle Änderungen zu verlangsamen, sondern Routinearbeit von Entscheidungen mit wesentlichen Auswirkungen zu unterscheiden.

Für die Wiederherstellung dokumentieren Sie, wer erklärt, dass der Geschäftsprozess betroffen ist, wer nach Abstimmung mit der geschäftlich verantwortlichen Person das Wiederherstellungsziel oder den Wiederherstellungspunkt auswählt, wer die technische Maßnahme durchführt und wer den wiederhergestellten Dienst und die Daten überprüft. NIST CSF 2.0 besagt, dass Wiederherstellungsmaßnahmen ausgewählt, abgegrenzt, priorisiert und durchgeführt werden sollen und dass Backups sowie Wiederherstellungsressourcen vor ihrer Verwendung überprüft werden sollen. Außerdem fordert es die Bestätigung von Integrität und normalem Betriebsstatus nach der Wiederherstellung.

Ein Backup-Zeitplan allein reicht nicht aus. NIST empfiehlt zu testen, dass gesicherte Daten erfolgreich wiederhergestellt werden können. Nehmen Sie im Register das Datum des letzten Wiederherstellungstests, die Person oder das Team, die bzw. das ihn bestätigt hat, den getesteten Umfang und einen Link zu den Nachweisen oder dem Runbook auf. Airbip bietet konfigurierbare tägliche, wöchentliche und monatliche Backups, doch Kunden sollten weiterhin die geschäftlich und anwendungsseitig verantwortlichen Personen bestimmen, die entscheiden, welche Wiederherstellung akzeptabel ist und wer überprüft, ob die wiederhergestellte Anwendung nutzbar ist.

Prüfen Sie das Register in einem vorhersehbaren Rhythmus und nach wesentlichen Änderungen. Die Prüfung sollte kurz sein: Bestätigen Sie, dass die benannten verantwortlichen Personen noch vorhanden sind, Kontakte weiterhin funktionieren, Domains und Abhängigkeiten aktuell sind, privilegierte Zugriffe verstanden werden, Aufbewahrungsentscheidungen weiterhin gültig sind und Wiederherstellungsnachweise aktuell genug für die Kritikalität der Anwendung sind.

• Definieren Sie, welche Änderungen Routine sind, welche eine geschäftliche Genehmigung benötigen und welche eine Daten- oder Sicherheitsprüfung erfordern.
• Benennen Sie eine verantwortliche Person für Updateentscheidungen und einen technischen Koordinator.
• Dokumentieren Sie einen Vorfall-Kontaktweg, der außerhalb der regulären Arbeitszeiten funktioniert, wenn die Kritikalität der Anwendung dies erfordert.
• Benennen Sie die Instanz, die den Wiederherstellungsansatz und Wiederherstellungspunkt auswählt.
• Fordern Sie geschäftliche und technische Überprüfung, bevor die Wiederherstellung als abgeschlossen erklärt wird.
• Erfassen Sie Wiederherstellungstests, gewonnene Erkenntnisse und Maßnahmen, die erforderlich sind, um das Register korrekt zu halten.