Wenn etwas schiefläuft — wen rufen Sie an, und ist der Plan real?
TL;DR. Incident-Response, Disaster-Recovery und dokumentierte Runbooks, die getestet sind, nicht abgeheftet. KI-gestützte Vorbereitung und Triage, menschlich geführte Eindämmung und Wiederherstellung. Ein Retainer, damit die Antwort auf ‚wen rufen wir an' bereits bekannt ist.
Worum es geht
Die meisten Kontinuitätspläne sind PDFs, die seit dem Audit niemand geöffnet hat. Das ist keine Kontinuität — das ist Papierkram. Wir bauen Runbooks, die getestet sind, halten eine Incident-Response-Fähigkeit in Bereitschaft und machen Wiederherstellung zu einer eingeübten Abfolge anstatt einer Improvisation im schlimmsten Moment. NIS2 will schnelle, strukturierte Incident-Berichte; das ist nur möglich, wenn Prozess, Logging und Playbooks vor dem Vorfall existieren.
Wie wir es betreiben
Wir bereiten vor: DR-Runbooks, Recovery-Ziele (RTO/RPO), vorautorisierter Zugriff, ein IR-Playbook auf Datei. Agenten auf Nova9 halten Nachweise und Telemetrie kontinuierlich, damit sich beim Eintreten eines Vorfalls die Zeitleiste selbst rekonstruiert. Der Bereitschafts-Retainer garantiert ein Response-Fenster; Aktivierung bringt aktive Incident-Behandlung, Forensik, Eindämmung und Wiederherstellungskoordination — menschlich geführt, agenten-gestützt. Danach produzieren wir den strukturierten Post-Incident-Bericht, den Regulatoren erwarten.
Für wen es passt
KRITIS- und NIS2-pflichtige Organisationen mit verpflichtender Incident-Meldung. Unternehmen, deren DR-Plan unter Last nie getestet wurde. Bestehende SOC-Kunden, die das vollständige Sicherheitsnetz wollen — Erkennung plus die Antwort auf „und jetzt?".
Was wir nicht tun
Wir übergeben Ihnen keine Vorlage und nennen es einen Plan. Wir improvisieren keine Wiederherstellung. Wir lassen die Post-Incident-Berichterstattung nicht bei Ihnen, wenn der Regulator wartet.
Was Sie übernehmen lassen
-
Getestete DR-Runbooks
Wiederherstellungsverfahren mit definierten RTO/RPO, eingeübt — nicht abgeheftet.
-
IR-Retainer (Bereitschaft)
Garantiertes Response-Fenster, vorautorisierter Zugriff, IR-Playbook auf Datei.
-
Incident-Aktivierung
Aktive Behandlung, Forensik, Eindämmung, Wiederherstellungskoordination — menschlich geführt, agenten-gestützt.
-
Kontinuierliche Nachweise
Telemetrie und Logging aktuell gehalten, damit sich die Incident-Zeitleiste selbst rekonstruiert.
-
Regulator-tauglicher Post-Incident-Bericht
Ursache, Maßnahmen, strukturierte Berichterstattung im Rhythmus, den NIS2/DORA erwarten.
Fakten zum Mandat
| Bereitschaft | Garantierter Response-SLA, vorautorisierter Zugriff, Playbook auf Datei |
|---|---|
| Aktivierung | Aktive Incident-Behandlung, Forensik, Eindämmung, Wiederherstellung |
| DR-Tests | Runbooks eingeübt, RTO/RPO pro System definiert |
| Berichterstattung | Strukturierter Post-Incident-Bericht für NIS2/DORA-Rhythmus |
| Bündelung | Vergünstigter Retainer für bestehende Security-Operations-Kunden |
Was vor dem Briefing oft gefragt wird
-
Lohnt sich der Retainer, wenn nichts passiert?
Der Retainer garantiert ein Response-Fenster und hält Ihre Runbooks getestet und den Zugriff vorautorisiert. Der Wert ist, dass der schlimmste Tag eingeübt ist, nicht improvisiert. -
Übernehmen Sie die regulatorische Berichterstattung?
Ja. Wir produzieren den strukturierten Post-Incident-Bericht im Rhythmus, den NIS2 und DORA erwarten, mit Ursache und Maßnahmen. -
Wie verbindet sich das mit Ihrem SOC?
Erkennung und Kontinuität sind ein Sicherheitsnetz. Bestehende Security-Operations-Kunden erhalten einen vergünstigten, vorintegrierten Retainer. -
Was sind RTO und RPO in der Praxis?
Wir definieren Recovery-Time- und Recovery-Point-Ziele pro System und üben gegen sie, anstatt eine Zahl in ein Dokument zu schreiben.
Den schlimmsten Tag zu einem eingeübten machen.
Wir prüfen Ihren Kontinuitätsplan gegen ein echtes Szenario und zeigen, was getestete Runbooks plus ein Bereitschafts-Retainer tatsächlich ändern.