NIS2 und die Rolle von Datensicherung, Wiederanlauf und Krisenmanagement

4.1.1 Business-Continuity-Plan (BCP) und Disaster-Recovery-Plan (DRP)

Gemäß Artikel 21 Absatz 2 Buchstabe c der Richtlinie (EU) 2022/2555 sind betroffene Unternehmen verpflichtet, einen Business-Continuity-Plan (BCP) sowie einen Disaster-Recovery-Plan (DRP) zu erstellen und kontinuierlich aufrechtzuerhalten. Diese Pläne sind im Falle eines sicherheitsrelevanten Vorfalls anzuwenden.

ORIENTIERUNGSHILFE

Bei der Erstellung von Business-Continuity- und Disaster-Recovery-Plänen sind anerkannte Standards des Business-Continuity- und Notfallmanagements sowie bewährte Verfahren der Informationssicherheit heranzuziehen.

Insbesondere ist eine strukturierte Übersicht potenzieller Ereignisse zu erstellen, die die Erbringung geschäftskritischer Dienste beeinträchtigen können, darunter:

• Naturkatastrophen (z. B. Stürme, Brände, Überschwemmungen),
• sonstige Ereignisse wie menschliche Fehlhandlungen oder technische Störungen.

Ergänzend sind die operativen Wiederanlauffähigkeiten nachvollziehbar zu dokumentieren, unter anderem:

• Datensicherungen mit definierten Aufbewahrungszeiträumen,
• regelmäßig durchgeführte Tests der Wiederherstellbarkeit,
• klar definierte Wiederherstellungsziele (RTO, RPO).

Kommentar Nuabee: In der aktuellen Bedrohungslage greift eine Risikobetrachtung zu kurz, die Cyberangriffe nicht explizit berücksichtigt.

BEISPIELE MÖGLICHER NACHWEISE

• Dokumentierter Business-Continuity-Plan.
• Dokumentierter Disaster-Recovery-Plan.
• Nachweis der Konformität mit anerkannten Normen, Standards oder Best Practices.
• Strukturierte Übersicht relevanter Schadensszenarien sowie verfügbarer interner oder externer Wiederanlauffähigkeiten.

4.1.2 Operativer Business-Continuity- und Wiederanlaufplan

4.1.2 Der Betrieb der betroffenen Unternehmen ist entsprechend dem Business-Continuity-Plan und dem Disaster-Recovery-Plan wiederherzustellen.

Der operative Wiederanlaufplan basiert auf den Ergebnissen der Risikobewertung und umfasst – sofern zutreffend – mindestens folgende Elemente:

1. Zielsetzung, Geltungsbereich und betroffene Organisationseinheiten
2. Rollen und Verantwortlichkeiten
3. Zentrale Kontaktstellen und Kommunikationskanäle (intern und extern)
4. Kriterien zur Aktivierung und Deaktivierung des Notfallplans
5. Priorisierte Reihenfolge des Wiederanlaufs
6. Wiederanlaufpläne für spezifische Geschäftsprozesse einschließlich der Wiederherstellungsziele
7. Erforderliche Ressourcen (u. a. Datensicherungen, Redundanzen)
8. Rückführung vom Notfallbetrieb in den Regelbetrieb

EMPFEHLUNGEN

Die Aktivierung und Durchführung des Wiederanlaufplans ist nachvollziehbar zu dokumentieren, einschließlich:

• getroffener Entscheidungen,
• umgesetzter Maßnahmen,
• erreichter oder verfehlter Wiederanlaufzeiten.

Die Priorisierung des Wiederanlaufs sollte sich an folgenden Kriterien orientieren (nicht abschließend):

• Schutzbedarf und Kritikalität der Assets,
• Bedeutung der Dienste für die Geschäftstätigkeit,
• technische und organisatorische Abhängigkeiten,
• Wiederherstellungsziele (Anhang der Verordnung, Abschnitt 4.1.3)
• Verfügbarkeit der Ressourcen
• regulatorische Anforderungen.

Eine geeignete Kapazitätsplanung stellt sicher, dass nach Aktivierung des Notfallbetriebs ausreichende Ressourcen für:

• Informationsverarbeitung,
• Telekommunikation,
• unterstützende Infrastrukturen

zur Verfügung stehen.

Zur Sicherstellung der Betriebsfähigkeit der Wiederanlauf- und Notfallkonzepte sind primäre sowie redundante Telekommunikationsdienstleister vorzusehen (siehe Abschnitt 13.1).

Für den Notfallbetrieb und das ortsunabhängige Arbeiten müssen Mitarbeitende mit kritischen Betriebsfunktionen:

• über redundante Internetzugänge verfügen (z. B. mobile Breitbandverbindungen oder Tethering),
• regelmäßig an Tests von Failover-Szenarien teilnehmen, einschließlich:
  • der Nutzung von VPN-Zugängen sowie
  • der Sprachkommunikation (z. B. VoIP oder Cloud-Telefonie)
    über Backup- und Ersatznetze.

Die Vorbereitung des Wiederanlaufs umfasst unter anderem:

• Ausweich- und Notfallstandorte,
• räumlich getrennte Datensicherungen,
• getestete und validierte Wiederherstellungsverfahren.

Es ist sicherzustellen, dass erforderliche Drittleistungen (z. B. ein Notfall- oder Ausweichstandort) im Schadensfall verfügbar sind.

Bei entsprechendem Schutzbedarf sind erweiterte Maßnahmen zur Notfall- und Wiederanlauffähigkeit umzusetzen, beispielsweise:

• vollständige Redundanz,
• kontrollierte Failover-Mechanismen,
• ein alternativer Betriebs- bzw. Ausweichstandort.

BEISPIELE MÖGLICHER NACHWEISE

• Umgesetzte und dokumentierte Maßnahmen zur Bewältigung von Schadens- und Notfallszenarien, z. B. Ausweichstandorte und externe Datensicherungen.
• Aktuelle und unternehmensweit kommunizierte Organisationsstrukturen.
• Inventar der für die Netz- und Servicekontinuität wesentlichen Bereiche und Dienste sowie dokumentierte Notfallpläne zur Begrenzung der Auswirkungen auf abhängige und miteinander verknüpfte Geschäftsbereiche und Services.

Kommentar Nuabee: Auch an dieser Stelle bleiben Cyberangriffe und die daraus resultierende Notwendigkeit einer konsequenten Cyberresilienz unzureichend berücksichtigt.

4.1.3 Business-Impact-Analyse (BIA)

4.1.3 Die betroffenen Unternehmen führen eine Business-Impact-Analyse (BIA) durch, um die möglichen Auswirkungen schwerwiegender Störungen auf ihre Geschäftstätigkeit zu bewerten. Auf Grundlage der Ergebnisse leiten sie die Anforderungen an die Kontinuität der Netz- und Informationssysteme ab.

LEITFADEN
Auf Grundlage der Ergebnisse der Business-Impact-Analyse (36) sowie der Risikobewertung hat die Organisation geeignete Wiederherstellungsziele festzulegen, wie sie in Abschnitt 4.1.2 Buchstabe f des Anhangs der Verordnung beschrieben sind (indikative, nicht abschließende Liste):

•  Recovery Time Objective (RTO)
  Zur Bestimmung der maximal zulässigen Zeitspanne für die Wiederherstellung von Ressourcen und operativen Funktionen nach einem Schadensereignis, beispielsweise von Informations- und Kommunikationstechnologiesystemen (IKT) und zugehörigen Geschäftsprozessen.
  Typische Anwendungsfälle sind die maximal tolerierbare Nichtverfügbarkeit der Website, des Enterprise-Resource-Planning-Systems (ERP) oder der E-Mail-Infrastruktur der Organisation.
• Recovery Point Objective (RPO)
  Zur Festlegung des maximal akzeptablen Datenverlusts für bestimmte Geschäftsprozesse oder IKT-Anwendungen.
  Der RPO wird in der Regel als maximale Zeitspanne definiert, innerhalb derer Daten wiederhergestellt werden müssen, ohne gemäß der Risikobewertung unzumutbare Auswirkungen auf die Geschäftstätigkeit zu verursachen, beispielsweise bei einem E-Commerce-System, einem ERP-System oder einem Mailserver.
• Service Delivery Objective (SDO)
  Zur Bestimmung des minimalen Leistungsniveaus, das Geschäfts- und Supportfunktionen während eines alternativen Betriebsmodus erreichen müssen. Beispiele (indikativ und nicht abschließend) sind:
  • der prozentuale Anteil eingehender Anrufe, die ein Callcenter innerhalb eines definierten Zeitfensters annehmen muss,
  • der erforderliche Verfügbarkeitsgrad von Bestell- und Zahlungssystemen einer E-Commerce-Plattform innerhalb eines bestimmten Zeitraums,
  • die Wiederherstellungszeit für den Zugriff auf geschäftskritische, gemeinsam genutzte Dateien über cloudbasierte Dateizugriffssysteme,
  • der Zeitraum, innerhalb dessen die vollständige Funktionsfähigkeit der Remote-Arbeitsinfrastruktur wiederherzustellen ist.
• Maximum Acceptable Outage (MAO) und Maximum Tolerable Period of Disruption (MTPD)
  Zur Bestimmung des Zeitraums, nach dessen Überschreitung die potenziellen Auswirkungen der Nichtbereitstellung eines Produkts oder einer Dienstleistung bzw. der Unterbrechung einer Geschäftstätigkeit gemäß der Risikobewertung nicht mehr akzeptabel oder signifikant werden.
  Diese Zeiträume sind in der Regel länger als die definierten RTO-Werte. Während sich MAO/MTPD primär auf die Verfügbarkeit von Diensten beziehen, fokussieren sich RPO-Werte auf den Verlust von Daten. Beispiele (indikativ und nicht abschließend) sind:
  • der Zeitraum, ab dem der Kundenservice erheblich beeinträchtigt wird und das Reputationsrisiko signifikant steigt,
  • die maximale Dauer, während der eine länger andauernde Unterbrechung einer E-Commerce-Website zu signifikanten Umsatzverlusten sowie einem Vertrauensverlust der Kunden führen kann,
  • der Zeitraum, ab dem der eingeschränkte Zugriff auf gemeinsam genutzte Projektdateien die Zusammenarbeit oder Entscheidungsfindung wesentlich behindert, insbesondere bei cloudbasierter Datenspeicherung,
  • die maximal akzeptable Unterbrechung der Remote-Arbeitsinfrastruktur, ab der Geschäftsprozesse erheblich gestört werden und Produktivitätsverluste zunehmen.

Die definierten RTO-, RPO- und SDO-Werte dienen als Grundlage zur Festlegung geeigneter Backup- und Redundanzverfahren.

• Der Disaster-Recovery-Plan ist zu dokumentieren unter Berücksichtigung:
  • der festgelegten RTO-, RPO- und SDO-Werte sowie
  • der Einhaltung der jeweils anwendbaren gesetzlichen und regulatorischen Anforderungen.

Kommentar NuabeeAus fachlicher Sicht sehen wir weiterhin strukturelle Defizite in Bezug auf die Berücksichtigung von Cyberangriffen und die daraus resultierende Notwendigkeit einer ganzheitlichen Cyberresilienz.In Cyberangriffsszenarien ist das Recovery Time Objective (RTO) kein geeigneter primärer Steuerungsindikator. Maßgeblich sind vielmehr die Tiefe und Historie der Datensicherungen, die strikte Isolation der Umgebungen sowie die Fähigkeit zur kontrollierten Wiederherstellung nicht kompromittierter Systemstände.

BEISPIELE MÖGLICHER NACHWEISE

• Dokumentierte Business-Impact-Analyse mit definierten Wiederherstellungszielen.
• Prozesse und Maßnahmen zur Sicherstellung des erforderlichen Kontinuitätsniveaus in Stör- und Krisensituationen.

 

4.1.4 Tests, Überprüfung und kontinuierliche Weiterentwicklung

4.1.4 Der Business-Continuity-Plan und der Disaster-Recovery-Plan sind in regelmäßigen Abständen zu testen und zu überprüfen.
Darüber hinaus erfolgen Tests und Überprüfungen nach schwerwiegenden Vorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risikolage. Sofern erforderlich, werden die Pläne aktualisiert, wobei die betroffenen Unternehmen sicherstellen, dass die aus den Tests gewonnenen Erkenntnisse systematisch in die Pläne einfließen.

LEITLINIEN

Business-Continuity- und Disaster-Recovery-Pläne sind mindestens einmal jährlich zu testen, zu überprüfen und – sofern erforderlich – zu aktualisieren.

Für die Tests der Business-Continuity- und Disaster-Recovery-Pläne sind eine oder mehrere geeignete Methoden auszuwählen und miteinander zu kombinieren, unter anderem:

• • alternative Arbeitsstandorte für Mitarbeitende,
  • Disaster-Recovery-Standorte bzw. Notfallstandorte,
  • digitale Zwillinge,
  • Simulationen,
  • Tabletop-Übungen.

Die Pläne sind regelmäßig zu testen, wobei insbesondere zu berücksichtigen sind:

• • Änderungs- und Versionsprotokolle,
  • frühere Sicherheits- und Störfälle,
  • dokumentierte Ergebnisse vorheriger Tests.

Sofern zutreffend, ist der Disaster-Recovery-Plan an einem alternativen Notfallstandort zu testen, um:

• • das betroffene Personal mit den verfügbaren Einrichtungen und Ressourcen vertraut zu machen, und
  • die Fähigkeit des alternativen Standorts zur Übernahme des operativen Betriebs zu bewerten.

Die Rechenzentrumsinfrastruktur ist im Rahmen der Tests zu überprüfen, insbesondere in Bezug auf:

• • Verfügbarkeit,
  • automatisches Failover,
  • Umschaltung zwischen Energieversorgern sowie zwischen primären Energiequellen und Notstromsystemen (z. B. Generatoren oder Batteriesystemen),
  • die erforderliche Resilienz zur Aufrechterhaltung der Servicebereitstellung für Kunden.

Im Rahmen der Tests des Disaster-Recovery-Plans ist zudem der vollständige Wiederanlauf sowie die Wiederherstellung des Informationssystems in einen definierten, bekannten und validierten Zustand festzulegen und zu verifizieren.

Business-Continuity- und Disaster-Recovery-Pläne sowie die zugehörigen Maßnahmen sind auf Basis folgender Erkenntnisse fortzuschreiben:

• • Änderungsprotokolle,
  • Erfahrungen aus vergangenen Vorfällen,
  • Dokumentation individueller Schulungs- und Trainingsmaßnahmen.

Änderungsprotokolle sowie die dokumentierten Ergebnisse früherer Tests sind regelmäßig zu überprüfen, um sicherzustellen, dass die gewonnenen Lessons Learned in den Plänen angemessen berücksichtigt sind.

Rollen und Verantwortlichkeiten sind regelmäßig zu überprüfen und bei Bedarf anzupassen.

 

TECHNISCHE UMSETZUNGSHINWEISE

• Die Disaster-Recovery-Konzepte abhängiger Drittanbieter sind zu prüfen, um sicherzustellen, dass diese die Business-Continuity-Anforderungen der Organisation erfüllen.
• Änderungen an Business-Continuity- und Disaster-Recovery-Plänen sind zielgerichtet an die jeweils relevanten Schlüsselpersonen zu kommunizieren.
• Relevante Anpassungen sind dem betroffenen Schlüsselpersonal transparent und nachvollziehbar zu vermitteln.

 

BEISPIELE MÖGLICHER NACHWEISE

• Dokumentierte Test- oder Zeitpläne für zukünftige Übungen.
• Protokolle über durchgeführte Tests, Überprüfungen und gegebenenfalls vorgenommene Aktualisierungen.
• Protokolle über Aktivierung und Durchführung von Business-Continuity- und Disaster-Recovery-Plänen, einschließlich getroffener Entscheidungen, umgesetzter Maßnahmen sowie der tatsächlich erreichten Wiederanlaufzeiten.
• Nachweisliche Kommunikation, z. B. E-Mails, Dokumente oder Intranet-Mitteilungen, zu Änderungen an Business-Continuity- und Disaster-Recovery-Plänen.
• Nachweise darüber, dass Erkenntnisse aus früheren Tests systematisch in die Pläne integriert wurden, beispielsweise durch Anpassungen von Arbeitsabläufen oder aktualisierte Planversionen.

 

EMPFEHLUNGEN

Über die in Abschnitt 4.1.2 des Anhangs der Verordnung genannten Anforderungen hinaus kann der Business-Continuity-Plan insbesondere folgende Aspekte berücksichtigen:

• das Engagement der Unternehmensleitung;
• die Koordination zwischen den organisatorischen Einheiten;
• den strukturierten Kommunikationsplan;
• die Einhaltung gesetzlicher und regulatorischer Vorgaben;
• Kennzahlen zur Bewertung der wirksamen Umsetzung des Plans.

Business-Continuity- und Disaster-Recovery-Pläne sind vor unbefugter Offenlegung sowie vor nicht autorisierten Änderungen zu schützen.

Es ist sicherzustellen, dass Business-Continuity- und Disaster-Recovery-Pläne im Falle eines Systemausfalls jederzeit verfügbar und zugänglich sind. Geeignete Maßnahmen hierzu können unter anderem sein (indikative, nicht abschließende Aufzählung):

• physische Kopien der Pläne;
• Speicherung in Cloud-Umgebungen;
• Nutzung externer Datenträger;
• mobiler Zugriff für berechtigte Personen

Der Business-Continuity-Plan sollte relevanten Schlüsselpersonen in geeigneter Form zur Verfügung gestellt werden.

Die Aktivierung und Umsetzung des Business-Continuity-Plans ist zu überwachen. Dabei sind sowohl erfolgreiche als auch nicht erfolgreiche Wiederanläufe sowie die jeweils erreichten Wiederanlaufzeiten zu dokumentieren.

Der Business-Continuity-Plan sollte einen eindeutigen Verweis auf die geltenden Richtlinien, Pläne und Verfahren des Incident-Managements enthalten oder diese in geeigneter Form beschreiben.

Der Business-Continuity-Plan ist mit den jeweiligen Plänen externer Dienstleister abzustimmen, um die Einhaltung der Kontinuitätsanforderungen sicherzustellen.

Das in Business-Continuity- und Wiederanlaufprozesse eingebundene Schlüsselpersonal ist entsprechend zu schulen.

Es sind Verfahren zur Nutzung geeigneter Kommunikationskanäle mit den zuständigen (inter)nationalen Behörden festzulegen, einschließlich Katastrophenschutzorganisationen und Rettungsdiensten.

Das für Disaster-Recovery-Maßnahmen verantwortliche Personal ist regelmäßig fortzubilden.

Szenariobasierte Notfallpläne für Systeme sind zu implementieren.

Die Aktivierung und Umsetzung von Notfallplänen ist zu überwachen, wobei erfolgreiche und nicht erfolgreiche Zielerreichungen in Bezug auf RTO, RPO und SDO zu erfassen und auszuwerten sind.

Für besonders kritische sowie stark voneinander abhängige Bereiche und Dienste sind spezifische Notfallpläne vorzusehen.

 

BEISPIELE MÖGLICHER NACHWEISE

• Nachweis geeigneter technischer und organisatorischer Maßnahmen (z. B. Verschlüsselung, Zugriffskontrollen) zum Schutz von Business-Continuity- und Disaster-Recovery-Plänen vor unbefugter Offenlegung oder Veränderung.
• Aktuelle, unternehmensweit kommunizierte Organisationsstrukturen.
• Dokumentierter Entscheidungsprozess zur Aktivierung von Notfallplänen.
• Systembezogene Notfallpläne mit klar definierten Maßnahmen  für typische Bedrohungsszenarien, einschließlich Auslösebedingungen, strukturierter Prozessschritte sowie festgelegter RTO-, RPO- und SDO-Werte.
• Protokolle über die Aktivierung und Durchführung von Notfallplänen, einschließlich getroffener Entscheidungen, umgesetzter Maßnahmen und der tatsächlich erreichten Wiederanlaufzeiten.

4.2.1 Datensicherungsrichtlinie

4.2.1 Um ein angemessenes Maß an Redundanz sicherzustellen, haben die betroffenen Unternehmen Sicherungskopien ihrer Daten vorzuhalten und ausreichende verfügbare Ressourcen bereitzustellen – einschließlich technischer Einrichtungen, Netzwerken, Informationssystemen und qualifiziertem Personal.

 

ORIENTIERUNGSHILFE

Auf Basis der Business-Impact-Analyse (Anhang der Verordnung, Abschnitt 4.1.3) ist zu entscheiden, ob die erforderliche Redundanz:

• durch eigene Infrastrukturen oder
• unter Einbindung geeigneter Drittanbieter, beispielsweise Cloud-Service-Provider,
  realisiert wird.

 

BEISPIELE MÖGLICHER NACHWEISE

• Datensicherungen sind physisch und logisch von den produktiven Systemen getrennt, die sie erzeugen.
• Sofern Drittanbieter eingebunden sind: dokumentierte Service-Level-Agreements (SLA).

 

4.2.2 Anforderungen an Datensicherungen

4.2.2 Auf Grundlage der Ergebnisse der Risikobewertung (Abschnitt 2.1) sowie des Business-Continuity-Plans haben die betroffenen Unternehmen Notfallpläne zu etablieren, die mindestens folgende Elemente umfassen:

a) definierte Wiederherstellungszeiten

b) Sicherstellung der Vollständigkeit und Integrität der Sicherungskopien, einschließlich Konfigurationsdaten sowie in Cloud-Service-Umgebungen gespeicherter Daten. 

c) Speicherung der Sicherungskopien (online oder offline) an einem oder mehreren sicheren Standorten, die sich nicht im selben Netzwerk wie das produktive System befinden und räumlich ausreichend getrennt sind, um Schäden infolge eines Ereignisses am Primärstandort zu vermeiden,

d) angemessene physische und logische Zugriffskontrollen für die Sicherungskopien entsprechend der Klassifizierung der Assets

e) definierte Verfahren zur Wiederherstellung von Daten aus den Sicherungskopien

f) Aufbewahrungsfristen auf Basis geschäftlicher und regulatorischer Anforderungen

 

LEITLINIEN

• Die Wiederherstellungszeiten dürfen die in Abschnitt 4.1.2 Buchstabe f des Anhangs der Verordnung definierten Wiederherstellungsziele nicht überschreiten.
• Bei der Festlegung der Aufbewahrungsfristen sind die Vorgaben aus Abschnitt 3.2.5 des Anhangs der Verordnung zu berücksichtigen.
• Sofern Drittanbieter in die Bereitstellung von Redundanz eingebunden sind, ist klar festzulegen, ob:
  • die Verantwortung für die Sicherungskonzepte vollständig beim Unternehmen verbleibt oder
  • Drittanbieter in die Konzeption und Umsetzung eingebunden sind.

 

BEISPIELE MÖGLICHER NACHWEISE

• Dokumentierte Datensicherungs- und Notfallpläne.
• Protokolle der Datensicherungssoftware, die regelmäßige Sicherungen nachweisen.
• Physisch getrennte und angemessen geschützte Datensicherungen, einschließlich Verschlüsselung.
• Protokolle oder Berichte, die belegen, dass Sicherungskopien extern gespeichert werden (z. B. Cloud-Speicher oder entferntes Rechenzentrum).
• Konfigurationseinstellungen der Datensicherungssoftware, aus denen hervorgeht, dass:
  • mehrere Kopien erstellt werden und
  • diese auf unterschiedlichen Speichermedien abgelegt sind.
• Klar dokumentierte Wiederherstellungsverfahren für alle relevanten Systeme und Dienste.
• Sofern zutreffend: Konfigurationen von Cloud-Speicherdiensten, die den Empfang und die Speicherung von Sicherungskopien gewährleisten.

 

4.2.3 Integritätsprüfungen von Datensicherungen

4.2.3 Die betroffenen Unternehmen haben regelmäßige Integritätsprüfungen der Datensicherungskopien durchzuführen.

 

LEITLINIEN

Die Integrität von Datensicherungen ist regelmäßig zu überprüfen. Bewährte Verfahren sind unter anderem (indikativ, nicht abschließend):

• Einsatz von Checksummen oder kryptografischen Hash-Verfahren, um sicherzustellen, dass die gesicherten Daten mit den Originaldaten übereinstimmen (vgl. Abschnitt 9.2).
• Automatisierte Prüfmechanismen zur regelmäßigen Durchführung dieser Kontrollen, um das Risiko menschlicher Fehler zu minimieren.
• Regelmäßige Wiederherstellungstests, um sicherzustellen, dass Sicherungen vollständig und funktionsfähig sind sowie durch fachlich verantwortliche Anwender validiert sind.
• Tests unterschiedlicher Wiederherstellungsszenarien, einschließlich vollständiger Systemwiederherstellungen sowie gezielter Wiederherstellung einzelner Dateien, um sicherzustellen, dass alle Komponenten des Datensicherungssystems zuverlässig funktionieren.
• Nutzung externer Cloud-Speicherlösungen für Offsite-Backups, die integrierte Integritätsprüfungen und Redundanzmechanismen bereitstellen.

 

BEISPIELE MÖGLICHER NACHWEISE

• Protokolle oder Berichte, aus denen hervorgeht, dass Checksummen oder Hash-Algorithmen eingesetzt werden.
• Konfigurationsparameter der Datensicherungssoftware oder von Backup-Skripten, die den Einsatz von Checksummen oder Hash-Algorithmen festlegen.
• Dokumentierte Nachweise regelmäßiger Wiederherstellungstests.
• Nachweise über Tests unterschiedlicher Wiederherstellungsszenarien, einschließlich vollständiger Systemwiederherstellungen sowie der Wiederherstellung einzelner Dateien.
• Protokolle oder Berichte zu realen Sicherheits- oder Störfällen, in denen Wiederherstellungsverfahren tatsächlich angewendet wurden (Anhang der Verordnung, Abschnitte 3.2 und 3.5).
• Sofern zutreffend: dokumentierte Service-Level-Agreements (SLA) bei Drittanbietern.

 

4.2.4 Mindestressourcen

4.2.4 Auf Basis der Risikobewertung (Abschnitt 2.1) und des Business-Continuity-Plans stellen die betroffenen Unternehmen sicher, dass mindestens eine partielle Redundanz für folgende Ressourcen besteht:

a) Netzwerke und Informationssysteme
b) Sachwerte, einschließlich Standorte, technische Einrichtungen und Betriebsmittel
c) qualifiziertes Personal mit definierten Rollen, Befugnissen und Kompetenzen
d) geeignete Kommunikationskanäle

 

ORIENTIERUNGSHILFE

Die erforderlichen Mindestressourcen sind klar zu definieren. Dies kann unter anderem umfassen (indikativ, nicht abschließend):

• Netzwerke und Informationssysteme
  • mehrere Internet-Zugangsprovider,
  • Load-Balancing,
  • gespiegelte Server,
  • Virtualisierung,
  • redundante Speicherarchitekturen (z. B. RAID).
• Sachwerte
  • gemeinsam genutzte Arbeitsplätze,
  • Backup- bzw. Ausweichstandorte,
  • Ersatz- und Reserveausstattung,
  • mehrere Lieferanten für identische Produktkategorien.
• Personal
  • Vertretungsregelungen,
  • Jobrotation,
  • Notfall- und Krisenübungen.
• Kommunikation und Energieversorgung
  • mehrere Kommunikationsplattformen (z. B. E-Mail, Messaging-Anwendungen, soziale Netzwerke),
  • redundante Energieversorgung durch mehrere Stromlieferanten oder Notstromsysteme (z. B. Generatoren).

 

BEISPIELE MÖGLICHER NACHWEISE

• Nachweis, dass ein oder mehrere der genannten Redundanzmechanismen umgesetzt sind.

 

4.2.5 Änderungs- und Kapazitätsmanagement

4.2.5 Sofern zutreffend, stellen die betroffenen Unternehmen sicher, dass die Überwachung und bedarfsgerechte Anpassung der Ressourcen – einschließlich Standorten, Systemen und Personal – systematisch in die Anforderungen an Datensicherung und Redundanz integriert wird.

 

ORIENTIERUNGSHILFE

Entscheidungen zur Allokation und Anpassung von Ressourcen sind an der Erfordernis auszurichten, ein angemessenes Niveau an Datensicherungs- und Redundanzkapazitäten sicherzustellen. Hierzu kann die Organisation eine oder mehrere der folgenden Maßnahmen vorsehen (indikative, nicht abschließende Liste):

• Priorisierung von Ressourcen auf Basis der Ergebnisse der Risikobewertung,
• Umsetzung partieller Redundanzkonzepte,
• Diversifikation von Backup-Standorten,
• Kontinuierliche Überwachung der Ressourcen mit Redundanzbedarf.

 

BEISPIELE MÖGLICHER NACHWEISE

• Nachweise zu den in Abschnitt 4.2.4 des Anhangs der Verordnung genannten Elementen.
• Nachweise aus regelmäßigen Simulationen und Sensibilisierungsmaßnahmen zur Bewertung:
  • der Einsatzbereitschaft des Personals sowie
  • der Angemessenheit der Verfahren.

 

4.2.6 Tests von Datensicherungen und Redundanzen

4.2.6 Die betroffenen Unternehmen führen regelmäßig Wiederherstellungstests von Datensicherungen und Redundanzen durch, um sicherzustellen, dass diese unter realistischen Bedingungen zuverlässig funktionieren und alle erforderlichen Kopien, Prozesse und Kenntnisse für eine effektive Wiederherstellung abdecken. Die Ergebnisse der Tests sind zu dokumentieren und bei Bedarf sind Korrekturmaßnahmen umzusetzen.

 

ORIENTIERUNGSHILFE

Die Frequenz der Überprüfung der Datensicherungen ist auf Grundlage der Risikobewertung (Abschnitt 2.1) an die Kritikalität der Daten anzupassen. Beispielsweise:

• Hochkritische Daten: wöchentliche Tests,
• Mittel- und geringkritische Daten: monatliche Tests,
• Wesentliche Änderungen: unmittelbare Tests nach Umsetzung.

Festgestellte Schwachstellen und Lessons Learned aus den Übungen sind systematisch zu adressieren und in Prozesse und Systeme zu überführen.

Relevante Drittanbieter, Geschäftspartner oder Kunden sind – sofern sinnvoll – in die Tests einzubeziehen.

 

BEISPIELE MÖGLICHER NACHWEISE

• Testberichte und Protokolle zu Datensicherungen, Prozessen und Verfahren.
• Dokumentierte Planung von Tests der Datensicherungspläne, einschließlich:
  • Notfallszenarien,
  • Testfrequenzen,
  • Rollen und Verantwortlichkeiten,
  • Vorlagen und Verfahren zur Durchführung der Tests sowie
  • Vorlagen für Nachtestberichte.
• Berichte über frühere Tests der Datensicherungs- und Notfallpläne.
• Berichte über Tests und Übungen, die die Umsetzung der Pläne belegen, einschließlich des Nachweises, dass die definierten Wiederherstellungszeiten eingehalten wurden, sowie der aus den Tests gewonnenen Erkenntnisse.
• Dokumentation von identifizierten Problemen und Lessons Learned aus früheren Tests sowie deren Bearbeitung durch die jeweils verantwortlichen Stellen.
• Aktualisierte Testpläne, Änderungsprotokolle und Review-Kommentare.
• Beiträge von Drittanbietern zur Optimierung der Testszenarien.

 

EMPFEHLUNGEN

• Die Hard- und Software für Datensicherung und Wiederherstellung ist konsequent zu schützen.
• Es ist sicherzustellen, dass verschlüsselte Datensicherungen dauerhaft zugänglich bleiben. Hierzu sind die zugehörigen Verschlüsselungsschlüssel sicher zu verwahren.
• Verschlüsselungsschlüssel sind strikt getrennt von den Sicherungsdaten aufzubewahren, um unbefugten Zugriff zu verhindern und die Wiederherstellbarkeit jederzeit sicherzustellen.
• Vor der Wiederherstellung von Systemen oder Konfigurationen kann es erforderlich sein, einen sogenannten „Patient Zero (37)“ zu identifizieren, um zu vermeiden, dass im Rahmen der Wiederherstellung bereits bereinigte Schwachstellen oder Infektionen erneut aktiviert werden.
  • (37) Der Begriff bezeichnet in der Regel das erste von einem Angriff betroffene System.
• Die 3-2-1-Regel der Datensicherung ist konsequent zu berücksichtigen:
  • Vorhaltung von drei Datenkopien (Originaldaten plus zwei Sicherungskopien),
  • Speicherung auf zwei unterschiedlichen Speichermedien (z. B. Festplatten, Cloud-Speicher),
  • Ablage mindestens einer Kopie an einem externen Standort (offsite).
• Die Integrität der Datensicherungen ist über den definierten Aufbewahrungszeitraum hinweg sicherzustellen. Jegliche unbefugte Veränderung oder Löschung – etwa durch Ransomware-Verschlüsselung oder Manipulation – ist zu verhindern.
  Geeignete Maßnahmen sind unter anderem (indikativ, nicht abschließend):
  • Analyse der Sicherungskopien auf Schadsoftware und Ransomware vor der Ablage,
  • Einsatz unveränderlicher (immutable) Datensicherungen,
  • Offline-Speicherung von Datensicherungen.
• Business-Continuity- und Disaster-Recovery-Pläne sind eng mit den Prozessen der Incident-Response (Anhang der Verordnung, Abschnitt 3.5) sowie dem Krisenmanagement (Anhang der Verordnung, Abschnitt 4.3) zu verzahnen.
• Sofern Cloud-Services eingesetzt werden, ist sicherzustellen, dass:
  • Datensicherungen über mehrere Availability Zones (AZ) repliziert oder alternativ in einer separaten Region gespeichert werden, um die Resilienz bei zonenbezogenen Ausfällen zu gewährleisten;
  • eine zonenübergreifende Replikation konfiguriert ist, um Ausfallzeiten zu minimieren;
  • sämtliche Sicherungsdaten im Ruhezustand mittels cloudnativer Schlüsselmanagementsysteme verschlüsselt und während der Übertragung durchgehend mit TLS 1.2+ geschützt sind;
  • regelmäßige Tests der Datensicherungen durchgeführt werden, um die Wiederherstellungsfähigkeit über mehrere Zonen hinweg zu validieren.

 

BEISPIELE MÖGLICHER NACHWEISE

• Maßnahmen zum Schutz der Backup- und Wiederherstellungsinfrastruktur, beispielsweise physische Zugriffskontrollen, Überwachungssysteme, Verschlüsselung, Integritätsprüfungen sowie Failover-Mechanismen.
• Überprüfung des Datensicherungskonzepts unter Berücksichtigung der 3-2-1-Regel.
• Protokolle der Datensicherungssoftware, aus denen hervorgeht, dass Datensicherungen regelmäßig durchgeführt werden.
• Konfigurationseinstellungen der Datensicherungssoftware, die belegen, dass diese so eingerichtet ist, dass drei Kopien der Daten erstellt und auf unterschiedlichen Speichermedien abgelegt werden.
• Sofern zutreffend: Konfigurationseinstellungen des Cloud-Speicherdienstes, die sicherstellen, dass dieser für den Empfang und die Speicherung von Datensicherungskopien eingerichtet ist.

4.3.1 Krisenmanagementprozess

4.3.1 Die betroffenen Unternehmen haben einen Krisenmanagementprozess zu implementieren.

 

RICHTLINIEN

• Bei der Ausgestaltung des Krisenmanagementprozesses sind anerkannte branchenübliche Normen und Standards zugrunde zu legen (38). Dabei ist zu beachten, dass Krisen unterschiedlich verlaufen können und daher eine einzelfallbezogene, vertiefte Analyse erforderlich sein kann.
• Im Rahmen des Krisenmanagements sind sämtliche relevanten Dimensionen abzudecken (z. B. technische, operative, kommunikative und Remediation-Aspekte), einschließlich klar definierter Prozesse, Rollen und Verantwortlichkeiten.
• (38) Ergänzend sind insbesondere folgende Referenzwerke heranzuziehen:

• • ISO 22361:2022, Security and resilience – Crisis management – Guidelines;
  • ENISA, Best Practices for Cyber Crisis Management;
  • NIST Special Publication 800-61 Revision 2.
• Da die Eskalation eines sicherheitsrelevanten Vorfalls zum Krisenstatus maßgeblich vom Risikoappetit sowie den Fähigkeiten der Organisation im Incident Management abhängt, hat die Organisation objektivierbare Kriterien festzulegen, anhand derer bestimmt wird, wann eine Krise formell auszurufen ist (39).

Diese Kriterien beziehen sich auf Vorfälle mit schwerwiegenden Auswirkungen oberhalb einer definierten Toleranzschwelle und können unter anderem folgende Aspekte umfassen (indikative, nicht abschließende Liste):

• erhebliches Risiko für kritische Assets oder kritische Geschäftsprozesse, z. B. Vorfälle hoher Schwere wie Datenschutzverletzungen mit sensiblen Informationen;
• erhebliche Beeinträchtigung des Geschäftsbetriebs, etwa durch langanhaltende Unterbrechungen, großflächige Serviceausfälle oder signifikante Auswirkungen auf den Kundenservice;
• Ausmaß des Vorfalls, insbesondere die gleichzeitige Betroffenheit mehrerer Systeme, Organisationseinheiten oder geografischer Standorte, was auf eine umfassendere Bedrohungslage hindeutet;
• potenzielle Reputationsschäden der Organisation, insbesondere bei Vorfällen, die öffentliche Aufmerksamkeit oder einen Vertrauensverlust bei Kunden nach sich ziehen können;

• potenzielle Auswirkungen eines Cybersicherheitsvorfalls auf Vertraulichkeit, Integrität, Authentizität und Verfügbarkeit von Informationen;
• Sophistizierung und Motivation der Bedrohungsakteure. Vorfälle im Zusammenhang mit Advanced Persistent Threats (APT) oder organisierter Cyberkriminalität können Maßnahmen auf einer Eskalationsebene erfordern, die die regulären organisatorischen Fähigkeiten überschreiten;
• Eskalationspotenzial, beispielsweise durch erneute Ausnutzbarkeit identifizierter Schwachstellen oder durch die weitere Ausbreitung von Schadsoftware.

 

BEISPIELE MÖGLICHER NACHWEISE

• Nachweis, dass der Krisenmanagementprozess mit dokumentierten Normen, Standards und/oder anerkannten Best Practices konform ist.

4.3.2 Abdeckung des Krisenmanagements

4.3.2 Die betroffenen Unternehmen stellen sicher, dass der Krisenmanagementprozess mindestens folgende Elemente abdeckt:

– Rollen und Verantwortlichkeiten des Personals sowie – sofern zutreffend – von Lieferanten und Dienstleistern; dabei ist die Rollenverteilung in Krisensituationen festzulegen, einschließlich spezifischer, einzuhaltender Maßnahmen;

– geeignete Kommunikationsmittel zwischen den betroffenen Einheiten und den zuständigen Behörden;

– Anwendung geeigneter Maßnahmen, um die fortlaufende Sicherheit von Netz- und Informationssystemen in Krisensituationen zu gewährleisten.

Im Sinne von Buchstabe b umfasst der Informationsfluss zwischen den betroffenen Einheiten und zuständigen Behörden sowohl verpflichtende Kommunikation (z. B. Incident-Reports einschließlich der entsprechenden Fristen) als auch nicht verpflichtende Kommunikation.

 

ORIENTIERUNGSHILFE

Im Rahmen der Krisenkommunikation sind insbesondere folgende Aspekte zu berücksichtigen (indikative, nicht abschließende Liste):

• Gesetzliche Kommunikationspflichten, einschließlich festgelegter Kommunikationsfristen, insbesondere im Hinblick auf Melde- und Benachrichtigungspflichten;
• die strukturierte Verteilung von Informationen an interne und externe Stakeholder im Krisenfall, insbesondere an Mitarbeitende, Kunden, direkte Lieferanten und Dienstleister sowie Notfall- und Rettungsdienste;
• vordefinierte Kommunikationsvorlagen;
• die Festlegung geeigneter Kommunikationskanäle je Stakeholder-Gruppe, unter Berücksichtigung, dass:
  • (39) Nach ISO 22361 ist eine Krise ein „abnormales oder außergewöhnliches Ereignis oder eine Situation, die eine Organisation oder Gemeinschaft bedroht und eine strategische, adaptive und schnelle Reaktion erfordert, um ihre Lebensfähigkeit und Integrität zu bewahren“.
• interne und externe Stakeholder unterschiedliche Kommunikationskanäle nutzen können;
• etablierte Kommunikationskanäle in einer Krisensituation möglicherweise nicht sicher oder nicht verfügbar sind;
• die für die Information und Kommunikation mit den zuständigen Behörden vorgesehenen Kanäle explizit zu benennen sind;
• aktuelle und gepflegte Kontaktdaten interner und externer Stakeholder.

 

BEISPIELE MÖGLICHER NACHWEISE

• Dokumentierter Krisenmanagementprozess.
• Liste der Mitglieder des Krisenmanagementteams, einschließlich ihrer Rollen, Kontaktdaten und Stellvertretungen.

 

4.3.3 Beziehung zu CSIRT

4.3.3 Die betroffenen Unternehmen haben einen Prozess zu implementieren, der sicherstellt, dass eingehende Informationen von CSIRTs oder – sofern zutreffend – von zuständigen Behörden ordnungsgemäß verarbeitet werden. Dies gilt insbesondere für Informationen zu Vorfällen, Schwachstellen, Bedrohungen oder möglichen Abhilfemaßnahmen sowie für deren ordnungsgemäße Nutzung.

 

ORIENTIERUNGSHILFE

Zur Verarbeitung und Nutzung der von CSIRTs übermittelten Informationen ist ein strukturierter und nachvollziehbarer Prozess zu implementieren. Dabei sind insbesondere folgende Schritte zu erwägen (indikative, nicht abschließende Liste):

• Benennung eines festen Ansprechpartners (Point of Contact) für die Kommunikation mit dem CSIRT.
• Sicherstellung, dass der Ansprechpartner über ausreichende fachliche Kenntnisse im Umgang mit Sicherheitsvorfällen sowie im Bereich Threat Intelligence verfügt.
• Systematische Klassifizierung eingehender Informationen in Kategorien wie Sicherheitsvorfälle, Schwachstellen, Bedrohungen und Abhilfemaßnahmen;
  –  Priorisierung der Informationen nach Schweregrad und potenzieller Auswirkung auf die Organisation sowie Bewertung, ob die Informationen für die Organisation relevant bzw. anwendbar sind;
  –  Bewertung der Informationen durch den CSIRT-Ansprechpartner im Hinblick auf Relevanz und Handlungsbedarf.
• Validierung der Informationen durch Abgleich mit internen Protokollen und Logdaten, bestehenden Threat-Intelligence-Quellen und geltenden Sicherheitsrichtlinien und -vorgaben.
• Bei identifizierten Schwachstellen oder Bedrohungen: enge Abstimmung mit den zuständigen Fachbereichen (IT, Informationssicherheit, Betrieb) zur Ableitung geeigneter Gegenmaßnahmen.
• Aktualisierung oder Erstellung von Incident-Response-Plänen entsprechend der Art der gemeldeten Bedrohungen oder Vorfälle gemäß Abschnitt 3.5 des Anhangs der Verordnung.
• Sofern zutreffend: Umsetzung der Abhilfemaßnahmen sowie strukturierte Kommunikation mit den relevanten Stakeholdern gemäß Abschnitt 3.5 des Anhangs der Verordnung.
• Freiwilliger Informationsaustausch mit dem CSIRT, insbesondere durch Rückmeldungen zu Vorfällen, zur Wirksamkeit der Maßnahmen und zu gewonnenen Erkenntnissen (Lessons Learned).

 

BEISPIELE MÖGLICHER NACHWEISE

• Nachweise früherer Kommunikation mit CSIRTs oder – sofern zutreffend – mit zuständigen Behörden, z. B. E-Mails, Schriftverkehr und Sitzungsprotokolle.
• Nachweise, dass der benannte Ansprechpartner über ausreichende Kenntnisse im Umgang mit Sicherheitsvorfällen sowie im Bereich Threat Intelligence verfügt.

• 3.4 Die betroffenen Unternehmen testen, überprüfen und – sofern erforderlich – aktualisieren den Krisenmanagementplan in regelmäßigen Abständen oder infolge schwerwiegender Vorfälle bzw. wesentlicher Änderungen der Betriebsabläufe oder der Risikolage.

 

 LEITLINIEN

• Der Krisenmanagementprozess ist mindestens einmal jährlich zu testen.
• Die Tests des Krisenmanagementprozesses sind beispielsweise in Form von Übungen oder Simulationen durchzuführen. Dabei sind insbesondere folgende Aspekte zu erwägen (indikative, nicht abschließende Liste):
  • Einbeziehung von Erkenntnissen aus vergangenen Krisensituationen;
  • Abgleich der Testergebnisse mit den definierten Zielwerten, insbesondere den Wiederherstellungszielen gemäß Abschnitt 4.1.2 Buchstabe f des Anhangs der Verordnung (z. B. RTO, RPO und SDO); sowie
  • Nutzung der Ergebnisse dieses Abgleichs zur gezielten Aktualisierung und Weiterentwicklung des Krisenmanagementprozesses.
• Der Krisenmanagementprozess ist nach durchgeführten Tests oder infolge schwerwiegender Vorfälle bzw. wesentlicher Änderungen der Betriebsabläufe oder der Risikolage zu überprüfen und – sofern erforderlich – anzupassen.
• Die Richtlinie zur Sicherheit von Netz- und Informationssystemen sowie die organisatorischen Maßnahmen des Krisenmanagements sind nach Tests oder infolge schwerwiegender Vorfälle bzw. wesentlicher Änderungen der Betriebsabläufe oder der Risikolage zu überprüfen und – sofern erforderlich – zu aktualisieren.

 

BEISPIELE MÖGLICHER NACHWEISE

• Dokumentation, aus der hervorgeht, wie das Krisenmanagement in die Incident-Response- und Störfallprozesse der Organisation integriert ist (Anhang der Verordnung, Abschnitt 3.5), insbesondere im Hinblick auf IKT-bezogene Sicherheitsvorfälle.
• Dokumente zur systematischen Erfassung früherer Krisen sowie zur Bewertung ihrer Wiederauftretenswahrscheinlichkeit und ihrer potenziellen Auswirkungen auf die Geschäftstätigkeit.
• Dokumentation zu durchgeführten Krisenmanagementtests, einschließlich der getesteten Szenarien, der beteiligten Rollen und Funktionen sowie der erzielten Ergebnisse.
• Ergebnisberichte oder Bewertungen im Anschluss an Krisenmanagementtests, in denen identifizierte Stärken, Schwächen und konkrete Verbesserungsbedarfe dokumentiert sind.

Protokolle interner oder externer Überprüfungen und Audits des Krisenmanagementkonzepts, einschließlich der festgestellten Abweichungen, der abgeleiteten Maßnahmen sowie umgesetzter Korrekturmaßnahmen.

 

ORIENTIERUNGSHILFE

Die Leitungsorgane sollten den Krisenmanagementprozess formell genehmigen und – sofern zutreffend – ihre Rollen und Verantwortlichkeiten für den Krisenfall festlegen.

Über die in Abschnitt 4.3.2 des Anhangs der Verordnung genannten Elemente hinaus kann der Krisenmanagementprozess insbesondere folgende Punkte festlegen (indikative, nicht abschließende Liste):

• Verfahren zur Feststellung und formalen Erklärung einer Krise;
• Verfahren zur Aktivierung des Krisenmanagementteams;
• Eskalationsverfahren;
• Notfallverfahren, die die im Krisenfall zu ergreifenden Maßnahmen beschreiben; sowie
• Ausweich- und Sicherungsverfahren, die Maßnahmen zum Schutz wesentlicher Geschäftsaktivitäten oder unterstützender Dienste definieren (z. B. temporäre Ersatzstandorte zur Aufrechterhaltung, zum Wiederanlauf oder zur Wiederherstellung des Betriebs).

 

BEISPIELE MÖGLICHER NACHWEISE

• Inventar der für das Krisenmanagement erforderlichen Ressourcen, einschließlich Notfall- und Ersatzsystemen, alternativer Kommunikationsmittel sowie erforderlicher Notfallausstattung.
• Genehmigter Krisenmanagementprozess.
• Dokumentierter, durch die zuständigen Leitungsorgane genehmigter und unternehmensweit kommunizierter Krisenkommunikationsplan.
• Zusätzlich zu den in Abschnitt 4.3.2 des Anhangs der Verordnung genannten Anforderungen sowie den vorstehenden Leitlinien umfasst der Plan mindestens folgende Elemente (indikative, nicht abschließende Liste):
  • Regelungen zur Informationsverteilung an relevante Stakeholder im Krisenfall;
  • standardisierte Kommunikationsvorlagen;
  • aktuelle Kontaktdaten interner und externer Stakeholder, einschließlich Mitarbeitenden, Kunden, Lieferanten und Rettungsdiensten.
• Nachweis, dass das betroffene Personal mit den definierten Prozessen vertraut ist und die zuständigen Ansprechpartner im Krisenfall kennt.
• Dokumentierte Ergebnisse regelmäßiger Simulationen und Sensibilisierungsmaßnahmen zur Bewertung der Einsatzbereitschaft des Personals sowie der Angemessenheit und Wirksamkeit der Krisenmanagementverfahren.