Cyberangriff – und jetzt? Was in den ersten 72 Stunden wirklich zählt

Du kommst ins Büro. Der Rechner startet nicht. Die Tür zum Serverraum lässt sich nicht öffnen, weil die Zugangskontrolle über den Server läuft. Auf einem der noch erreichbaren Bildschirme erscheint eine Meldung: deine Daten wurden verschlüsselt, gegen Zahlung gibt es einen Entschlüsselungskey. Das ist kein Gedankenexperiment. Das ist der Alltag, den Unternehmen in Deutschland jede Woche erleben – kleine Architekturbüros mit acht Mitarbeitenden genauso wie mittelständische Industrieunternehmen mit 1.200 Beschäftigten.

Der wirtschaftliche Schaden durch Cybervorfälle lag in Deutschland zuletzt bei rund 200 Milliarden Euro pro Jahr. Zum Vergleich: alle DSGVO-Bußgelder zusammen machen davon rund 0,015 Prozent aus. Die Relation zeigt, wo das eigentliche Risiko liegt – und warum es sich lohnt, genau dieses Szenario ernstzunehmen, bevor es eintritt.

Bevor wir in die Krisenreaktion einsteigen, lohnt ein kurzer Blick auf die Einfallstore. Denn wer versteht, wie Angriffe beginnen, begreift auch, warum bestimmte Sofortmaßnahmen so wichtig sind.

Der häufigste Ausgangspunkt ist heute eine sogenannte initiale Kompromittierung über identitätsbasierte Angriffe. Das bedeutet: Angreifer kaufen im Darknet Zugangsdaten zu Unternehmenskonten, oder sie nutzen Helpdesk-Prozesse aus, um sich Zugänge zu erschleichen, die ihnen nicht zustehen. Daneben sind öffentlich erreichbare Systeme mit bekannten Schwachstellen nach wie vor ein klassisches Einfallstor. Angreifern gelingt der Einstieg häufig deshalb, weil grundlegende Sicherheitsmaßnahmen schlicht nicht umgesetzt wurden.

Was dann folgt, ist eine Kette. Der Einstieg allein reicht den Angreifern nicht. Sie brauchen Bewegungsfreiheit innerhalb des Netzwerks. Und die bekommen sie in vielen Unternehmen deshalb, weil Berechtigungen nicht restriktiv genug vergeben sind. Service Accounts – also privilegierte Konten, die für automatisierte Prozesse oder Software-Updates angelegt wurden – sind dabei ein häufig unterschätztes Risiko. Ich hatte selbst einen Vorfall, bei dem nicht ein Mitarbeiteraccount, sondern der Account des Netzwerkscanners angegriffen wurde. Über diesen Service Account konnten sich die Angreifer dann lateral durch das System bewegen. Microsoft bietet für solche Accounts bereits im Active Directory Bordmittel zur Absicherung an – Group Managed Service Accounts mit automatischer Passwortrotation etwa. Genutzt werden sie selten.

Die gleiche Logik gilt für Software-Verteilung in Praxen oder Kanzleien: Damit Anwendungen sich automatisch auf allen Clients aktualisieren, bekommen bestimmte Accounts weitreichende Rechte. Praktisch, aus Bequemlichkeit eingerichtet – und gleichzeitig ein offenes Tor. Aus Bequemlichkeit, weil kein Mensch einmal die Woche durch alle Rechner laufen will und manuell auf „Bestätigen" klicken möchte. Das ist menschlich nachvollziehbar. Sicherheitstechnisch ist es ein Problem.

Der Angriffsvektor über Social Engineering – also gefälschte E-Mails, Anrufe oder Nachrichten – ist durch den Einsatz von KI-Werkzeugen erheblich professioneller geworden. Sprachliche Qualität, Personalisierung und Glaubwürdigkeit haben sich durch große Sprachmodelle deutlich verbessert. Was früher am schlechten Deutsch einer Phishing-Mail erkennbar war, ist heute kaum noch zu unterscheiden.

Noch gravierender: Es ist heute technisch möglich, einen Videocall überzeugend zu fälschen. Das Bild der Vorgesetzten, ihre Stimme, ein vertrauter Kontext – und dann kommt die Anweisung, eine Überweisung durchzuführen oder einen Zugang freizuschalten. Technisch ist dagegen kaum etwas auszurichten, wenn Bild und Stimme in Echtzeit manipuliert werden. Was bleibt, sind organisatorische Maßnahmen: ein Vier-Augen-Prinzip bei bestimmten Aktionen, Rückrufpflichten über separat verifizierte Kanäle, interne Prozesse, die genau das abfangen. Denn wenn du deine Vorgesetzte in einem Teams-Meeting siehst, ihr Bild erkennst und ihre Stimme hörst – dann wird es schlicht schwierig zu beurteilen, ob das real ist oder nicht. KI macht genau das heute möglich.

An dieser Stelle ist ein Gedanke wichtig, der in vielen Unternehmen noch nicht angekommen ist: Was wir bisher beschrieben haben – Krisenteam, Notfallhandbuch, Backup-Strategie, Kommunikationspläne, Wiederherstellungsprozesse – ist für eine wachsende Zahl von Unternehmen keine freiwillige Vorbereitung mehr. Es ist gesetzliche Anforderung.

NIS-2, das in Deutschland seit Dezember 2025 gilt und auf die betroffenen Unternehmen unmittelbar Auswirkungen hat, listet Business Continuity explizit als eine der zentralen Sicherheitsanforderungen. Konkret umfasst das: Backup-Management, Disaster Recovery und Krisenmanagement. Diese drei Begriffe klingen technisch, beschreiben aber im Kern genau das, was wir hier durchgehen: Kannst du nach einem Vorfall weitermachen? Wie schnell? Mit welchen Daten? Und wer entscheidet was in der Krise?

NIS-2 unterscheidet dabei zwischen wesentlichen und wichtigen Einrichtungen. Wesentliche Einrichtungen – dazu gehören etwa Unternehmen aus den Bereichen Energie, Transport, Wasser, Gesundheit, digitale Infrastruktur – unterliegen strengeren Anforderungen und aktiverer Aufsicht. Wichtige Einrichtungen, also z.B. größere Unternehmen aus der verarbeitenden Industrie, dem Lebensmittelsektor oder dem Post- und Kurierwesen, haben etwas mehr Spielraum, aber grundsätzlich dieselben inhaltlichen Pflichten. Und auch wenn dein Unternehmen nicht direkt unter NIS-2 fällt: Die Anforderungen beschreiben einen Mindeststandard, der in der Praxis für jedes Unternehmen sinnvoll ist – unabhängig von der rechtlichen Betroffenheit.

Was NIS-2 im Kern von Unternehmen verlangt, ist ein nachweisbarer, dokumentierter Ansatz zur Aufrechterhaltung des Betriebs im Krisenfall. Das bedeutet nicht, dass alles sofort funktionieren muss. Es bedeutet, dass du weißt, was du tust, wenn es nicht mehr funktioniert. Genau das ist der Unterschied zwischen einem Unternehmen, das nach einem Cyberangriff handlungsfähig bleibt, und einem, das wochenlang im Chaos versinkt.

Business Continuity Management – kurz BCM – ist ein Begriff, der in vielen Unternehmen entweder gar nicht bekannt ist oder als Thema für große Konzerne abgetan wird. Beides ist ein Fehler. BCM bedeutet im Kern nichts anderes als: Wir haben uns überlegt, was passiert, wenn unsere wichtigsten Systeme, Prozesse oder Ressourcen ausfallen – und wir haben festgelegt, wie wir damit umgehen.

Der erste Schritt ist die Identifikation der sogenannten kritischen Geschäftsprozesse. Also: Was muss laufen, damit das Unternehmen überlebt? Nicht was schön wäre, sondern was wirklich unverzichtbar ist. Für ein produzierendes Unternehmen kann das die Fertigungssteuerung sein. Für eine Arztpraxis die Patientenverwaltung und die Terminvergabe. Für einen Dienstleister der Zugriff auf Kundendaten und Kommunikationssysteme. Diese Prozesse müssen priorisiert werden – und für jeden davon muss klar sein, in welcher Reihenfolge er nach einem Vorfall wiederhergestellt wird.

Der zweite Schritt ist die Festlegung von Wiederherstellungszielen. Zwei Kennzahlen sind dabei zentral: Wie viel Datenverlust ist maximal tolerierbar – also wie alt darf das letzte Backup maximal sein, das eingespielt wird? Und wie lange darf ein Prozess maximal ausfallen, bevor der Schaden existenzbedrohend wird? Diese Fragen klingen abstrakt, bis man sie konkret beantwortet. Für manche Prozesse liegt die Toleranz bei Stunden, für andere bei Tagen. Die Antwort bestimmt, wie häufig Backups gemacht werden müssen, wie schnell die Wiederherstellung funktionieren muss – und was das technisch und finanziell bedeutet.

Der dritte Schritt ist die Dokumentation. Ein BCM-Konzept, das im Kopf der IT-Leitung lebt, ist kein BCM-Konzept. Es muss schriftlich vorliegen, regelmäßig aktualisiert werden und für die relevanten Personen zugänglich sein – auch dann, wenn die Systeme nicht laufen. NIS-2 verlangt genau das: nachweisbare, dokumentierte Maßnahmen. Im Falle eines Vorfalls und einer anschließenden Prüfung durch die Aufsichtsbehörde ist Dokumentation der Unterschied zwischen einem geordneten Verfahren und einem teuren Problem.

Wenn das Unternehmen betroffen ist, ist die erste und wichtigste Aufgabe, nicht in Aktionismus zu verfallen. Das klingt trivial, ist es aber nicht. In fast jedem Vorfall, den ich begleitet habe, brach zunächst Chaos aus – auch in Unternehmen, die ein Notfallhandbuch hatten. Der Unterschied lag immer darin, ob vorher tatsächlich geübt worden war.

Der erste konkrete Schritt ist die Einberufung des Krisenteams. Dieses Team sollte klein sein, aber vollständig: Geschäftsführung, IT-Leitung, Rechtsabteilung wenn vorhanden, jemand aus der Kommunikation sowie der Datenschutzbeauftragte und der Informationssicherheitsbeauftragte. Letztere sind aus einem ganz konkreten Grund unverzichtbar: Ein IT-Sicherheitsvorfall wird unter DSGVO sehr schnell auch zu einem meldepflichtigen Datenschutzvorfall, sobald Verfügbarkeit, Vertraulichkeit oder Integrität von personenbezogenen Daten betroffen sind.

Das Krisenteam tagt nicht einmal und geht dann auseinander. Es kommt regelmäßig zusammen – in den Fällen, die ich begleitet habe, alle ein bis zwei Stunden. Jedes Treffen beginnt mit einem Lagebildupdate: Was wissen wir sicher? Was sind Hypothesen, auf denen wir weiterarbeiten müssen? Dazwischen hat jeder seine Aufgaben. Und am Ende jedes Treffens wird entschieden, was als nächstes passiert. Dieser Rhythmus klingt aufwendig. Er ist das Einzige, was in einer solchen Situation Struktur hält.

Parallel dazu muss das gesamte Krisenteam sofort auf einen Kommunikationskanal wechseln, der mit der betroffenen Infrastruktur nichts zu tun hat. Private Handys, Laptops aus dem Schrank, die noch nie im Firmennetz waren, externe E-Mail-Adressen. Der Grund ist ernst: In einem realen Vorfall hat ein Unternehmen die Kommunikation über die eigentlich gesperrten Systeme weitergeführt – in der Überzeugung, diese seien nicht kompromittiert. Sie waren es. Die Angreifer haben alles mitgelesen. Das ist fatal und darf nicht passieren.

Sobald das Krisenteam steht und ein sicherer Kommunikationskanal etabliert ist, geht es um Containment – also darum, die weitere Ausbreitung des Angriffs zu stoppen. Das bedeutet: kompromittierte Identitäten sperren, Tokens zurückrufen, betroffene Systeme vom Netzwerk isolieren. Entscheidend dabei ist, wer diese Entscheidungen treffen darf. Das muss vorab geklärt sein – welche Systeme dürfen abgeschaltet werden, wer hat die Befugnis dazu.

Ein weiterer Punkt, der in der Hektik leicht in den Hintergrund gerät: die Cyberversicherung. Falls eine besteht, muss sie unmittelbar kontaktiert werden – und zwar bevor mit der Untersuchung der Systeme begonnen wird. In einer Police kann stehen, dass eigenständige forensische Maßnahmen den Versicherungsschutz gefährden, weil die Versicherung eigene Forensiker einsetzen will. Ich habe Fälle erlebt, in denen das Unternehmen mehrere Stunden warten musste, bis die Versicherung grünes Licht gab – eine frustrierende, aber notwendige Wartezeit. Diese Bedingungen muss man kennen, bevor man sie im Ernstfall versehentlich verletzt.

Die Notfallnummern der Versicherung, der zuständigen Behörden und externer Dienstleister müssen deshalb analog verfügbar sein. Nicht digital, nicht im Passwortmanager, der auf dem verschlüsselten Server liegt. Ein physisches Notfallbuch mit den wichtigsten Kontakten, Passwörtern und Meldewegen ist eine der sinnvollsten Investitionen, die ein Unternehmen in seine Vorbereitung machen kann – und gleichzeitig ein konkretes Element eines NIS-2-konformen BCM-Konzepts.

Neben der technischen Reaktion ist Krisenkommunikation eine eigenständige Aufgabe, die mindestens ebenso viel Vorbereitung erfordert. Wenn die Systeme ausfallen, klingelt das Telefon – bei Kunden, Lieferanten, Partnern. Jeder, der mit dem Unternehmen zusammenarbeitet und plötzlich keine Verbindung mehr bekommt, wird auf jedem verfügbaren Weg versuchen, eine Antwort zu bekommen. Stellt euch das Umgekehrte vor: ihr seid Kunde und ein System läuft nicht mehr. Ihr würdet alle Kontaktwege versuchen, die ihr kennt. Und ihr würdet euch nicht mit einer Bandansage abspeisen lassen.

Die erste Regel ist Proaktivität. Wer wartet, bis der erste Anruf kommt, ist bereits in der Defensive. Kommunikation muss aktiv und zielgruppenspezifisch erfolgen: Kunden bekommen andere Informationen als Lieferanten, interne Mitarbeitende bekommen andere Informationen als Aufsichtsgremien. Eine einheitliche Nachricht an alle funktioniert nicht. Jede Zielgruppe braucht ein vorbereitetes Template. Wer das im Ernstfall erst erstellen muss, wird scheitern.

Die zweite Regel: Es gibt eine Person, die für die Kommunikation verantwortlich ist – und nur diese eine. Unterschiedliche Aussagen von unterschiedlichen Ansprechpartnern erzeugen Misstrauen und Chaos, auch intern. Die dritte Regel: Kündige den nächsten Update-Termin aktiv an. Bereits in der ersten Nachricht kommunizieren, wann der nächste Statusbericht kommt. Das reduziert Rückfragen erheblich und gibt Betroffenen das Gefühl, dass jemand den Überblick behält.

Und noch etwas, das nicht wie im Film ist: Ihr findet nicht heraus, dass ihr gehackt wurdet, und wisst zwei Minuten später die Ursache, den Zeitplan und alle nächsten Schritte. Das ist eine langwierige Geschichte, die sich in Wellen entwickelt. Man ist erst der Meinung, Backups können zurückgespielt werden – dann geht es doch nicht. Man glaubt, nur bestimmte Systeme sind betroffen – dann sind es mehr. Diese Unsicherheit muss kommuniziert werden. Eine Erstmeldung, gefolgt von regelmäßigen Updates, ist ehrlicher und glaubwürdiger als Schweigen bis zur vermeintlich vollständigen Antwort.

Ein Cyberangriff entbindet nicht von gesetzlichen Meldepflichten. Im Gegenteil – er löst in vielen Fällen mehrere parallele Meldepflichten aus, die unterschiedliche Fristen haben und an unterschiedliche Stellen zu richten sind.

Nach der DSGVO gilt die bekannte Frist von 72 Stunden für die Meldung an die Datenschutzaufsichtsbehörde, wenn personenbezogene Daten betroffen sind. Unter NIS-2 kommen für betroffene Unternehmen gestaffelte Fristen hinzu: eine Erstmeldung bereits innerhalb von 24 Stunden nach Entdeckung des Vorfalls, eine Folgemeldung nach 72 Stunden und ein Abschlussbericht nach 30 Tagen. Für KI-Systeme, die unter den AI Act fallen, gelten wiederum eigene Meldefristen. All das muss vorbereitet sein – Templates, Meldewege, Zuständigkeiten, und zwar bevor der Ernstfall eintritt.

Für den Fall, dass der Zugang zum Meldeportal nicht möglich ist, weil die eigenen Systeme kompromittiert sind, hat das BSI die direkte Kontaktaufnahme als zulässige Erstmeldung akzeptiert. Das Ganze wird dann nachgetragen, sobald der Zugang wiederhergestellt ist. Auch hier gilt: diese Nummer muss analog vorrätig sein.

Zudem sollte eine Strafanzeige gestellt werden. Nicht weil die Strafverfolgung in den meisten Fällen zu einer Verurteilung führen wird – Angreifer sitzen häufig in Ländern außerhalb der EU – sondern weil es eine Straftat ist, die gemeldet gehört. Die zuständigen Stellen in den meisten Bundesländern sind inzwischen gut aufgestellt, kamen in Fällen, die ich begleitet habe, mit der Forensik vor Ort und haben sich die Systeme tatsächlich angeschaut.

Ein Punkt, der dabei oft vergessen wird: Wenn Daten abgezogen wurden und später veröffentlicht werden, besteht die Meldepflicht gegenüber den Betroffenen unabhängig davon, ob das Lösegeld gezahlt wurde oder nicht. Wer in dieser Situation schweigt und die Veröffentlichung der Daten im Netz später sichtbar wird, steht deutlich schlechter da, als wenn er von Anfang an transparent gehandelt hat.

Die technische Wiederherstellung beginnt nicht mit dem Zurückspielen der Systeme, sondern mit dem Prüfen der Datensicherungen. Die Systeme selbst – also Betriebssysteme, Server-Images, virtuelle Maschinen – sollten grundsätzlich neu aufgesetzt werden, von sauberen Installationsquellen. System-Backups zurückzuspielen birgt das Risiko, eine eingebettete Backdoor mit zurückzuspielen. Angreifer sind heute in der Lage, ihre Werkzeuge so tief im System zu verstecken, dass klassische Scans sie nicht mehr finden. Der klare Rat lautet deshalb: komplett neu aufsetzen, Daten aus isolierten Backups zurückspielen.

Und hier liegt ein zentrales Problem in der Praxis. Backups existieren in vielen Unternehmen – aber sie wurden nie wiederhergestellt. Das klingt nach einem kleinen Unterschied, ist aber ein entscheidender. Ein Backup, das nicht getestet wurde, ist kein Backup. Es ist eine Hoffnung. Unter NIS-2 ist das Testen und Dokumentieren von Wiederherstellungsprozessen explizit Teil der Anforderungen an Business Continuity – und das aus gutem Grund. Genau hier scheitern Unternehmen im Ernstfall.

Isolierte Backups – also Sicherungen, auf die Angreifer keinen Schreibzugriff haben und die für eine festgelegte Aufbewahrungszeit nicht gelöscht werden können – sind die technische Grundvoraussetzung dafür, dass im Ernstfall überhaupt eine Wiederherstellung möglich ist. Write-Once-Systeme, die auch bei kompromittierten Adminrechten nicht überschrieben werden können, sind dabei eine der sinnvollsten Investitionen.

Zur Frage, ob das Lösegeld gezahlt werden sollte: Die Empfehlung lautet nein – es finanziert kriminelle Strukturen, und eine Garantie, dass die Daten danach nicht doch veröffentlicht werden, gibt es nicht. Die Realität in der Praxis ist aber eine andere: In mehr als der Hälfte der Fälle, die ich kenne, haben Unternehmen am Ende doch gezahlt – weil die Backups nicht funktioniert haben, veraltet waren oder nie getestet worden waren. Ergänzend lohnt ein Blick auf das Projekt „No More Ransom", bei dem für viele verbreitete Ransomware-Varianten bereits Entschlüsselungswerkzeuge zur Verfügung stehen.

Wenn die Systeme wieder laufen, kehrt in vielen Unternehmen schnell Business as usual ein – und damit geht der wertvollste Teil verloren: die Aufarbeitung. Eine gründliche Postmortem-Analyse untersucht, wie der Angreifer reingekommen ist, welche Schwachstellen er ausgenutzt hat und welche Lücken beim nächsten Neustart wieder offen wären. Ohne diese Analyse riskiert man, dass in einigen Wochen derselbe Angreifer über dieselbe Schwachstelle wieder einsteigt.

Genauso wichtig ist die Analyse des eigenen Verhaltens während des Vorfalls: Hat das Krisenteam funktioniert? War die Kommunikation konsistent? Haben die Meldeprozesse gegriffen? Was fehlte? Unternehmen, die das ernstnehmen, üben solche Szenarien. Die Feuerwehr macht das. Das Krankenhaus macht das. Wer es kennt, erinnert sich vielleicht an Feuerübungen in der Schule – der Gong geht, alle versammeln sich draußen, niemand muss überlegen. Genau das brauchen Unternehmen auch für den Cybervorfall. NIS-2 beschreibt das als Teil des geforderten Krisenmanagements: nicht nur Prozesse haben, sondern sie auch tatsächlich testen.

Ein abschließender Appell, der mir wichtig ist: Das angegriffene Unternehmen ist das Opfer. In der öffentlichen Wahrnehmung schwingt oft eine implizite Mitschuld mit – die Daten wären schlecht geschützt gewesen, das Unternehmen hätte mehr investieren müssen. Das mag in Einzelfällen stimmen, ändert aber nichts daran, dass der Angriff eine Straftat ist. Und intern gilt das genauso: Schuldzuweisungen im Krisenteam – an den Mitarbeitenden, der auf den Phishing-Link geklickt hat, an die IT, die ein System nicht gepatcht hat – blockieren die Problemlösung. Wer verantwortlich ist für den Schaden, ist immer der Angreifer. Fokussiert euch auf die Lösung, nicht auf die Suche nach dem Verursacher.

Ein Cyberangriff trifft Unternehmen jeder Größe und jeder Branche. Die ersten 72 Stunden entscheiden nicht darüber, ob der Schaden entsteht – sondern wie groß er wird. Wer in diesem Moment Struktur hat, kann handeln. Wer erst anfängt, Prozesse zu definieren, verliert die wichtigste Ressource: Zeit.

NIS-2 hat Business Continuity vom frommen Wunsch zur rechtlichen Anforderung gemacht. Das ist keine Bedrohung, sondern eine Chance: Unternehmen, die sich jetzt ernsthaft mit ihren kritischen Prozessen, ihren Wiederherstellungszielen, ihren Krisenteams und ihren Meldeprozessen beschäftigen, sind nicht nur gesetzeskonform. Sie sind widerstandsfähig. Und Widerstandsfähigkeit ist in einer Bedrohungslage, die durch KI, automatisierte Angriffe und professionelle kriminelle Strukturen weiter zunimmt, kein nettes Zusatzfeature – sondern Überlebensstrategie.

Die wesentlichen Lehren lassen sich klar zusammenfassen. Ein Krisenteam mit definierten Rollen muss im Vorfeld feststehen. Kommunikationskanäle außerhalb der eigenen Infrastruktur müssen vorbereitet sein. Kontakte zu Versicherung, Behörden und externen Spezialisten müssen analog verfügbar sein. Backups müssen isoliert, regelmäßig getestet und dokumentiert sein. Kritische Prozesse müssen priorisiert und mit Wiederherstellungszielen versehen sein. Und die Meldepflichten – gegenüber Datenschutzaufsichtsbehörden, unter NIS-2, unter dem AI Act – laufen auch im Ausnahmezustand weiter.

Wenn du prüfen möchtest, wie gut dein Unternehmen auf einen solchen Vorfall vorbereitet ist, sind das die ersten Fragen: Gibt es ein dokumentiertes BCM-Konzept? Sind kritische Prozesse identifiziert und priorisiert? Wurde das letzte Backup tatsächlich wiederhergestellt – also nicht nur erstellt? Ist das Krisenteam benannt und kennen alle ihre Rolle? Sind die Meldewege unter DSGVO und NIS-2 bekannt, dokumentiert und analog verfügbar?

Falls diese Fragen keine klaren Antworten haben, ist das keine Ausnahmesituation – das ist der Normalfall in den meisten Unternehmen. Mit strukturierter Vorbereitung lässt sich das ändern, und zwar ohne großen Aufwand, wenn man weiß, wo man anfängt.

Auf der NOVICADEMY, unserer Lernplattform für Datenschutz, IT-Sicherheit und KI-Compliance, findest du praxisnahe Schulungen zu genau diesen Themen – für Geschäftsführung, IT-Leitung und Beauftragte. Wir begleiten Unternehmen außerdem bei der Entwicklung von Notfallplänen, BCM-Konzepten, Krisenübungen und der Vorbereitung auf NIS-2-konforme Melde- und Dokumentationsprozesse. Melde dich gern direkt bei uns, wenn du wissen möchtest, wo bei dir der größte Handlungsbedarf liegt.