Viele Organisationen investieren in Sicherheit – und merken im Ernstfall trotzdem, dass Abläufe, Zuständigkeiten und Wiederanlauf nicht belastbar sind. Der Unterschied liegt selten in einzelnen Tools, sondern darin, ob Cyber-Resilienz als steuerbarer Betriebsprozess geführt wird. Genau hier hilft ein Cyber-Resilienz KPI-Set: Es macht Prävention, Erkennung und Wiederherstellung messbar, priorisierbar und auditfähig.
Dieser Beitrag liefert ein praxistaugliches Kennzahlenset für IT-Leitung, Compliance und Sicherheitsverantwortliche. Im Fokus stehen nicht „schöne Dashboards“, sondern: Welche Kennzahlen zeigen echten Risikorückgang? Welche Datenquellen sind realistisch? Wie werden Zielwerte und Toleranzen definiert? Und wie verhindert man, dass KPIs zu einer Reporting-Übung werden, während Angriffsflächen, Log-Lücken oder Restore-Unsicherheit weiterwachsen?
Was Cyber-Resilienz im Unternehmen konkret bedeutet
Cyber-Resilienz wird häufig mit „Sicherheit“ gleichgesetzt. Praktisch ist es breiter: Cyber-Resilienz ist die Fähigkeit, cyberbedingte Störungen zu verhindern, früh zu erkennen, wirksam zu begrenzen und den Geschäftsbetrieb kontrolliert wiederherzustellen. Das umfasst Technik, Prozesse und Entscheidungen.
Wichtig ist die Trennung in drei Steuerungsdimensionen:
- Prävention: Reduziert Eintrittswahrscheinlichkeit und Angriffsfläche (z. B. Patch- und Identity-Härtung).
- Erkennung & Reaktion: Verkürzt Zeit bis zur Entdeckung und stabilisiert die Incident-Bearbeitung (z. B. Logging-Abdeckung, Alarmqualität, Runbooks).
- Wiederherstellung: Stellt Systeme und Daten innerhalb definierter Zielwerte wieder bereit (z. B. RTO/RPO, Restore-Tests, Wiederanlaufketten).
Ein Cyber-Resilienz KPI-Set muss diese drei Dimensionen abdecken – und dabei sowohl technische Signale als auch Governance- und Evidenzanforderungen erfüllen (z. B. Nachweisbarkeit in Audits, Management-Entscheidbarkeit, klare Verantwortlichkeiten).
Warum ein KPI-Set besser ist als eine einzelne „Resilienz-Kennzahl“
Eine einzige Kennzahl („Resilience Score“) klingt attraktiv, ist aber in der Steuerung oft unbrauchbar. Sie glättet Unterschiede zwischen kritischen und unkritischen Assets, vermischt Ursachen und Wirkungen und ist schwer zu auditieren. Ein KPI-Set funktioniert besser, wenn es drei Eigenschaften erfüllt:
- Asset- und Risiko-Bezug: Kritische Geschäftsservices (z. B. ERP, Produktionssteuerung, Identitätsplattform) werden separat betrachtet.
- Leading und Lagging Indicators: Frühindikatoren (z. B. Patch-Backlog, Log-Quellen-Abdeckung) plus Ergebniskennzahlen (z. B. MTTD, RTO-Einhaltung).
- Operative Anschlussfähigkeit: Jede Kennzahl hat eine konkrete Maßnahme, einen Owner, eine Messmethode und eine Schwelle für Eskalation.
Für Compliance ist zusätzlich relevant: KPIs müssen als kontinuierliche Kontrolle funktionieren. Ein Audit fragt nicht nur „gibt es ein Konzept?“, sondern „wird es gelebt, gemessen, nachgesteuert – und lässt sich das belegen?“
Governance: So verankern Sie Cyber-Resilienz-KPIs in Verantwortung und Entscheidungswegen
Ohne Governance werden Kennzahlen schnell zu „Security-Theater“. Damit das KPI-Set steuert, braucht es eine klare Zuordnung:
- Owner: Verantwortlich für Zielerreichung (typisch: CISO/IT-Security für Prävention/Erkennung, IT-Betrieb für Wiederherstellung, Service Owner für Business-Prioritäten).
- Data Steward: Verantwortlich für Datenqualität und Definition (z. B. SIEM-Use-Cases, CMDB-Objekte, Backup-Katalog).
- Entscheidungsgremium: Nimmt Abweichungen an, priorisiert Maßnahmen, gibt Budget/Änderungen frei (z. B. IT-Steuerkreis, Risk Committee).
In der Praxis bewährt sich ein zweistufiges Reporting:
- Monatlich operativ: Trend, Top-Abweichungen, Maßnahmenstatus pro Domäne (Patch, Identity, Detection, Backup/Recovery).
- Quartalsweise Management: Risiko-Statement in Geschäftssprache, Ampellogik pro kritischem Service, Investitions- und Entscheidungsbedarf.
Wichtig für die Wirksamkeit: Definieren Sie Entscheidungsregeln, nicht nur Zielwerte. Beispiel: „Wenn RTO-Tests für einen kritischen Service zwei Zyklen in Folge nicht bestanden werden, wird ein Change-Freeze für nichtkritische Features geprüft und Ressourcen für Recovery-Härtung priorisiert.“
Das Cyber-Resilienz KPI-Set: Kernkennzahlen für Prävention, Erkennung und Wiederherstellung
Die folgenden Kennzahlen sind bewusst so gewählt, dass sie in vielen Unternehmens-ITs realistisch messbar sind. Nicht jede Organisation muss alle KPIs starten. Entscheidend ist, dass Sie pro Dimension mindestens 3–5 belastbare Kennzahlen nutzen, die sich auf kritische Services herunterbrechen lassen.
1) Prävention: Angriffsfläche, Identitäten, Schwachstellen, Konfiguration
KPI P1: Patch-Compliance für kritische Assets
Definition: Anteil kritischer Systeme (Server, Clients, Netzwerkkomponenten, zentrale Plattformen), die innerhalb definierter Fristen mit sicherheitsrelevanten Updates versorgt sind.
Warum es zählt: Patch-Backlog ist einer der häufigsten Verstärker für erfolgreiche Angriffe. Fristen müssen risikobasiert sein (z. B. Internet-exponiert vs. intern, Geschäftsservice-Kritikalität).
Evidence: Patch-Reports, Change-Tickets, Ausnahmegenehmigungen (Risk Acceptance) mit Ablaufdatum.
KPI P2: Vulnerability Remediation SLA (nach Kritikalität)
Definition: Zeit von „Vulnerability identifiziert“ bis „wirksam behoben oder kompensiert“; segmentiert nach Schweregrad (z. B. kritisch/hoch) und Asset-Klasse.
Hinweis: „Kompensiert“ muss technisch nachweisbar sein (z. B. WAF-Regel, Netzwerksegmentierung, Deaktivierung Feature) – nicht nur „akzeptiert“.
Evidence: Scanner-Export, Ticketing, Nachtest-Resultate.
KPI P3: MFA- und Conditional-Access-Abdeckung
Definition: Anteil privilegierter und regulärer Zugriffe, die durch Multi-Faktor-Authentifizierung (MFA) und Kontextregeln (Conditional Access: Gerät, Standort, Risiko) geschützt sind.
Warum es zählt: Identity ist oft der schnellste Pfad in die Umgebung. Privilegierte Konten (Admin, Service Accounts) sind gesondert zu betrachten.
Evidence: Identity-Provider-Policies, Ausnahmen, Break-Glass-Konten mit Kontrolle (z. B. getrennte Aufbewahrung, regelmäßiger Test).
KPI P4: Hardening- und Konfigurations-Compliance (Baseline)
Definition: Anteil Systeme, die einer definierten Sicherheitsbaseline entsprechen (z. B. deaktivierte Legacy-Protokolle, sichere Cipher, lokale Admin-Rechte begrenzt).
Warum es zählt: Viele Incidents entstehen aus Konfigurationsdrift. Baselines reduzieren Varianz und erhöhen Wiederherstellbarkeit.
Evidence: Policy-Exports, Konfigurationsscans, Drift-Reports.
KPI P5: Exposure-Inventory-Genauigkeit (Asset- und Service-Transparenz)
Definition: Anteil Assets/Services mit verlässlicher Zuordnung (Owner, Kritikalität, Datenklasse, Abhängigkeiten) in CMDB/Servicekatalog.
Warum es zählt: Ohne Inventar werden Prioritäten blind gesetzt. Diese Kennzahl ist ein „Enabler-KPI“ – schwach am Anfang, aber entscheidend für die Steuerbarkeit.
Evidence: CMDB-Qualitätsreports, Stichprobenprüfung, Abgleich mit Discovery/Cloud-Accounts.
2) Erkennung & Reaktion: Sichtbarkeit, Signalqualität, Reaktionsfähigkeit
KPI D1: Log-Quellen-Abdeckung für kritische Services
Definition: Anteil definierter Pflicht-Logquellen (z. B. Identity-Provider, EDR, Firewall, VPN, wichtige Server, SaaS-Audit-Logs), die tatsächlich zentral ankommen und auswertbar sind (SIEM oder Log-Plattform).
Warum es zählt: Ein SIEM ohne vollständige Quellen liefert Scheinsicherheit. „Ankommen“ heißt: korrekt geparst, Zeit synchron, mit ausreichender Retention.
Evidence: Datenquellenliste, Ingestion-Status, Retention-Konfiguration, Test-Events.
KPI D2: MTTD (Mean Time to Detect) für relevante Incident-Klassen
Definition: Durchschnittliche Zeit von Eintritt eines sicherheitsrelevanten Ereignisses bis zur Detektion; segmentiert nach Incident-Typ (z. B. Malware, Credential Misuse, Datenabfluss) und Quelle (EDR, SIEM, User-Meldung).
Warum es zählt: Verkürzte MTTD reduziert Schaden und senkt Wiederherstellungskosten. Segmentierung verhindert, dass ein einzelner Incident die Kennzahl verzerrt.
Evidence: Incident-Timeline, Alarm-Historie, Case-Management.
KPI D3: True-Positive-Rate / Alarm-Qualität
Definition: Anteil Alerts, die nach Triage als tatsächlich relevant bestätigt werden (oder als „benigne“/„false positive“ geschlossen werden).
Warum es zählt: Zu viele Fehlalarme erzeugen Blindheit, zu wenige Alarme bedeuten häufig Lücken. Ziel ist eine stabile Qualität, nicht „möglichst viele Alerts“.
Evidence: SOC-Tickets, Klassifizierungsregeln, regelmäßige Use-Case-Reviews.
KPI D4: Incident-Response-Readiness (Runbook-Abdeckung und Übungsgrad)
Definition: Anteil kritischer Incident-Szenarien (z. B. Ransomware, kompromittierter Admin, Cloud-Token-Leak), für die es geprüfte Runbooks gibt, inklusive Eskalationspfad, Kommunikationsplan und technischer Checklisten.
Ergänzung: Übungsquote (Tabletop oder technische Übung) pro Quartal/Halbjahr.
Evidence: Versionierte Runbooks, Übungsprotokolle, Lessons Learned, Maßnahmen-Backlog.
KPI D5: EDR-Abdeckung und Sensor-Gesundheit
Definition: Anteil Endpoints/Server mit aktivem EDR-Sensor (Endpoint Detection & Response: Verhaltensbasierte Erkennung und Reaktion) und Anteil „healthy“ (aktuell, nicht deaktiviert, nicht offline).
Warum es zählt: EDR-Lücken sind typische Angriffsfenster. „Installiert“ reicht nicht; Gesundheitszustand ist entscheidend.
Evidence: EDR-Konsole, Ausnahme-Listen, Deployment-Status.
3) Wiederherstellung: RTO/RPO, Restore-Nachweis, Wiederanlaufketten
KPI R1: RTO-Erfüllung pro kritischem Service
Definition: Anteil Services, die ihre Recovery Time Objective (RTO: maximale tolerierbare Wiederanlaufzeit) in Tests oder realen Vorfällen einhalten.
Warum es zählt: RTO ist die Management-Sprache für Ausfallkosten. Es zwingt zu Abhängigkeiten (DNS, IAM, Datenbanken, Schnittstellen) und zu „was zuerst“.
Evidence: Restore-/Failover-Protokolle, Zeitstempel, Abnahme durch Service Owner.
KPI R2: RPO-Erfüllung und Backup-Freshness
Definition: Anteil Services, die ihr Recovery Point Objective (RPO: maximal tolerierbarer Datenverlust) erreichen; gemessen als „Alter des letzten konsistenten Backups“ plus Validierungsstatus.
Wichtig: Für Datenbanken zählen applikationskonsistente Backups (z. B. mit Logs/Snapshots) – nicht nur Dateikopien.
Evidence: Backup-Katalog, DB-Log-Status, Restore-Validierung.
KPI R3: Erfolgsquote Restore-Tests (inkl. Zugriff & Integrität)
Definition: Anteil geplanter Restore-Tests, die erfolgreich sind, wobei „erfolgreich“ nicht nur „Daten zurückkopiert“ bedeutet, sondern: System startet, Zugang funktioniert, Datenintegrität geprüft, relevante Schnittstellen erreichbar.
Warum es zählt: Viele Backups sind im Ernstfall nicht nutzbar (fehlende Keys, falsche Rechte, inkonsistente Daten, nicht dokumentierte Abhängigkeiten).
Evidence: Testprotokoll, Prüfschritte, Screens/Logs als Nachweis, Abweichungs-Tracking.
KPI R4: Immutability/Schutz der Backups gegen Manipulation
Definition: Anteil kritischer Backup-Sätze, die gegen Löschung/Manipulation geschützt sind (z. B. WORM/Immutable Storage, getrennte Admin-Pfade, getrennte Credentials), inklusive Nachweis, dass Löschoperationen nicht trivialisierbar sind.
Warum es zählt: Ransomware zielt oft zuerst auf Backups und Admin-Tools. Backup-Schutz ist ein Resilienz-Kern, nicht nur „Storage-Feature“.
Evidence: Storage-Policies, IAM-Rollen, Audit-Logs, Penetration/Red-Team-ähnliche Kontrollen (ohne überzogene Versprechen).
KPI R5: Wiederanlaufkette getestet (Dependency-Chain Coverage)
Definition: Anteil kritischer Services, bei denen die Abhängigkeitskette (Identität, Netzwerk, Daten, Messaging, Schnittstellen) in einem integrierten Test wiederhergestellt wurde.
Warum es zählt: Einzelkomponenten können „grün“ sein, während der End-to-End-Service nicht läuft. Diese Kennzahl zwingt zu Service-Denken statt Server-Denken.
Evidence: Architektur-/Abhängigkeitsdokumentation, Testplan, Ergebnisprotokoll.
Zielwerte, Schwellen und Toleranzen: So wird aus Kennzahlen Steuerung
KPIs ohne Zielwerte sind Beobachtung, nicht Steuerung. Zielwerte müssen zur Risikotoleranz des Unternehmens passen und pro Service differenziert werden. In der Praxis funktionieren drei Ebenen:
- Minimum (Pflicht): Untergrenze, ab der ein Risiko formal akzeptiert oder sofort adressiert werden muss.
- Ziel (Plan): Erwarteter Zustand bei normaler Ressourcenlage.
- Ambition (Strategisch): Zielbild, das Investitionen begründet (z. B. Automatisierung, Plattformwechsel).
Für Compliance und Audit ist entscheidend, dass Abweichungen mit Maßnahmen oder Risikoakzeptanz verknüpft sind. „Rot“ ohne Konsequenz ist ein Audit-Risiko: Es zeigt fehlende Wirksamkeit der Governance.
Datenquellen und Messdesign: Woher kommen die Zahlen wirklich?
Ein häufiger Fehler: KPIs werden definiert, bevor klar ist, ob sie zuverlässig messbar sind. Besser ist ein Messdesign mit Datenquellen, Zuständigkeiten und Qualitätsregeln. Typische Quellen:
- Identity Provider (MFA-Status, Conditional Access, Admin-Rollen, Login-Risiken)
- EDR/XDR (Sensor-Gesundheit, Detection-Timelines, Response-Aktionen)
- SIEM/Log-Plattform (Ingestion, Retention, Use-Case-Abdeckung)
- Vulnerability Scanner (Findings, Remediation-Zeiten, Asset-Abdeckung)
- Patch-/Endpoint-Management (Compliance, Ausnahmen)
- Backup/Recovery-Lösung (Job-Erfolg, Restore-Tests, Immutable-Policies)
- ITSM/Ticketing (Incident-Daten, Changes, SLA, Lessons Learned)
- CMDB/Servicekatalog (Owner, Kritikalität, Abhängigkeiten)
Für die Auditfähigkeit sollten Sie pro KPI eine kurze „Definition of Done“ pflegen: Welche Datenfelder müssen vorhanden sein? Welche Aktualität ist erforderlich? Wie werden Ausnahmen dokumentiert?
Vorlage: KPI-Steckbrief (damit jede Kennzahl prüfbar und betreibbar wird)
Wenn Sie Ihr Cyber-Resilienz KPI-Set einführen, vermeiden Sie lange Konzeptpapiere ohne Betriebseffekt. Bewährt hat sich ein kompakter Steckbrief pro KPI:
- Name & Zweck (welches Risiko wird beeinflusst?)
- Scope (welche Services/Assets, welche Ausschlüsse?)
- Formel (klar, ohne Interpretationsspielraum)
- Datenquellen (Systeme, Reports, Owner)
- Messfrequenz (täglich, wöchentlich, monatlich)
- Zielwerte (Minimum/Ziel/Ambition) und Eskalationsregel
- Maßnahmenkatalog (typische Remediation-Schritte)
- Evidence (welche Artefakte werden für Audit gespeichert?)
Checkliste: In 6 Schritten zum belastbaren Cyber-Resilienz KPI-Set
- Kritische Geschäftsservices definieren: Was muss in welcher Zeit wieder laufen? Wer ist Service Owner? Ohne diese Liste bleiben KPIs generisch.
- Risiko-Hypothesen formulieren: Beispielsweise „Credential Misuse ist unser Top-Risiko“, „Backup ist manipulationsgefährdet“, „Cloud-Logs fehlen“.
- KPIs je Dimension auswählen: Pro Dimension 3–5 KPIs starten, nicht 20 auf einmal.
- Datenpipeline & Qualität sichern: Datenquellen, Definitionen, Ausnahmen, Zeitstempel, Retention.
- Zielwerte und Eskalationen festlegen: Mit Management und Service Ownern, inkl. Risikoakzeptanzprozess.
- Regelbetrieb etablieren: Monatliches Review, Maßnahmen-Backlog, Lessons Learned aus Incidents und Tests.
Audit- und Regulatorik-Perspektive: Welche Nachweise typischerweise zählen
Unabhängig davon, ob Ihr Rahmenwerk ISO 27001, NIS2, DORA oder interne Konzernvorgaben sind: Audits prüfen wiederkehrend drei Dinge – Design, Wirksamkeit und Nachweis.
- Design: Sind Controls und KPIs logisch aus Risiken und Kritikalität abgeleitet?
- Wirksamkeit: Werden KPIs regelmäßig gemessen und führen Abweichungen zu Entscheidungen?
- Nachweis: Können Sie für Stichproben belegen, dass Messung, Review und Maßnahmen stattgefunden haben?
Praktische Evidence-Artefakte, die in Prüfungen oft helfen: versionierte Runbooks, Übungsprotokolle, Restore-Testberichte, Change- und Ausnahmegenehmigungen, KPI-Trend-Reports mit Management-Review (z. B. Protokollauszug), sowie Nachweise zur Datenintegrität (Retention, Zeit-Synchronisation, Zugriffskontrollen).
Kosten- und Priorisierungslogik: KPIs als Investitionskompass statt „Reportpflicht“
Ein KPI-Set ist auch ein Budget- und Priorisierungswerkzeug. Typische Kostenblöcke in Resilienzprogrammen sind: Lizenzen/Plattform, Personalzeit (Betrieb, Triage, Übungen), Modernisierung (z. B. Identity, Logging), sowie Infrastruktur (Immutable Storage, getrennte Admin-Zonen).
KPIs sollten daher so gewählt sein, dass sie Investitionsentscheidungen begründen. Beispiele:
- Wenn D1 Log-Quellen-Abdeckung dauerhaft unter Ziel bleibt, ist oft nicht „mehr SOC“ die Lösung, sondern Standardisierung von Log-Onboarding, zentrale Zeitquelle (NTP), saubere Retention und klare Pflichtquellen pro Service.
- Wenn R3 Restore-Tests scheitern, ist ein Upgrade der Backup-Software nicht zwingend der erste Schritt; häufig fehlen Rechte-/Key-Management, dokumentierte Abhängigkeiten oder testbare Wiederanlaufumgebungen.
- Wenn P3 MFA-Abdeckung für privilegierte Konten nicht erreicht wird, ist das meist ein Governance- und Legacy-Thema: Service Accounts, Ausnahmen, Break-Glass-Prozesse, Automatisierung.
Typische Fallstricke aus dem Betrieb – und wie Sie sie vermeiden
1) KPIs ohne Servicekontext
Eine globale Patch-Quote kann gut aussehen, während ein einzelner kritischer Service monatelang hinterherläuft. Gegenmaßnahme: KPIs immer für „kritische Services“ und „Tier-0-Systeme“ separat reporten.
2) Datenqualität wird nicht gemessen
Wenn CMDB, Scanner oder Log-Plattform unvollständig sind, sind KPIs nur Annäherungen. Gegenmaßnahme: Enabler-KPIs (Inventar-Genauigkeit, Log-Ingestion-Health) explizit aufnehmen.
3) Restore wird als „Backup erfolgreich“ missverstanden
Ein grüner Backup-Job sagt wenig über Wiederanlauf aus. Gegenmaßnahme: Restore-Tests mit Integritäts- und Zugriffsnachweis, plus End-to-End-Kettentests (R5).
4) KPI-Reporting ohne Konsequenz
Wenn rote Kennzahlen keine Entscheidung auslösen, sinkt die Disziplin. Gegenmaßnahme: Eskalationsregeln, Risikoakzeptanz mit Ablaufdatum, verbindlicher Maßnahmen-Backlog.
5) Alarmflut statt Erkennung
Viele Alerts werden als Aktivität verkauft. Gegenmaßnahme: Alarm-Qualität (D3), Use-Case-Review, Messung von MTTD nach Incident-Klassen.
Praktische Source-Blöcke: Vorlagen für Policies und KPI-Definitionen
Die folgenden Vorlagen sind bewusst generisch gehalten, damit sie in Richtlinien, Kontrollkataloge oder Audit-Ordner übernommen werden können.
KPI-Steckbrief (Template)
KPI-ID:
Name:
Zweck / Risikobezug:
Scope (Services/Assets):
Ausschlüsse:
Formel / Messmethode:
Datenquellen (Systeme/Reports):
Messfrequenz:
Zielwerte (Minimum/Ziel/Ambition):
Schwellwerte (Gelb/Rot):
Owner (Zielerreichung):
Data Steward (Definition/Datenqualität):
Eskalationsweg (Gremium, Fristen):
Standardmaßnahmen bei Abweichung:
Evidence (Artefakte, Aufbewahrung):
Letzte Review / nächste Review:Policy-Baustein: Restore-Testpflicht für kritische Services
1. Für alle als "kritisch" klassifizierten Geschäftsservices sind Restore-Tests in festgelegter Frequenz durchzuführen.
2. Ein Restore-Test gilt nur als bestanden, wenn:
a) das System/der Service startet,
b) Authentisierung und autorisierte Zugriffe geprüft sind,
c) Datenintegrität anhand definierter Prüfpunkte validiert ist,
d) relevante Abhängigkeiten (z. B. DNS/IAM/DB/Schnittstellen) im Test berücksichtigt sind.
3. Abweichungen sind als Maßnahmen zu dokumentieren; bei wiederholtem Nichtbestehen ist eine Eskalation in das zuständige IT-/Risk-Gremium verpflichtend.
4. Evidence (Testprotokolle, Zeitstempel, Logs) ist revisionssicher aufzubewahren.Policy-Baustein: Risikoakzeptanz (Exception Handling) für KPI-Abweichungen
1. KPI-Abweichungen unterhalb des Minimum-Niveaus dürfen nur über eine formale Risikoakzeptanz genehmigt werden.
2. Jede Risikoakzeptanz enthält:
- betroffenen Service/Asset-Umfang,
- Risiko-Begründung und Kompensationsmaßnahmen,
- Ablaufdatum (max. definierter Zeitraum) und Review-Termin,
- genehmigende Rolle (Service Owner + IT-Security + ggf. Compliance).
3. Risikoakzeptanzen ohne Ablaufdatum sind unzulässig.Schlussfazit: Resilienz wird nicht behauptet – sie wird gemessen und geübt
Cyber-Resilienz ist eine Management- und Betriebsdisziplin. Ein Cyber-Resilienz KPI-Set hilft, Sicherheit aus dem Reaktiven zu holen: Es zwingt zu Klarheit über kritische Services, zu belastbarer Messung, zu Übungen und zu Entscheidungen, wenn Zielwerte verfehlt werden. Wenn Sie klein starten, Datenqualität ernst nehmen und Wiederherstellung nicht nur als „Backup vorhanden“ definieren, entsteht ein Steuerungsinstrument, das sowohl im Alltag als auch im Audit trägt.
Für dieses Thema sind auch Cyber Resilience und Security Kpis wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.