Governance von Entscheidungen über Ransomware-Zahlungen für NIS2 und DORA

Es ist 3:17 Uhr an einem Werktag im Jahr 2026. Maria, CISO einer schnell wachsenden Fintech-Plattform, wird durch eine Nachricht ihres leitenden SOC-Analysten in eine Krisenkonferenz gerufen: großflächige Verschlüsselung bestätigt, zentrale Dienste ausgefallen, und eine Ransomware-Gruppe behauptet, 2 TB Kundendaten entwendet zu haben.

Der CEO schaltet sich als Erster in die Telefonkonferenz ein. Danach folgen Rechtsabteilung, Datenschutz, Finanzen, Kommunikation, der Cyberversicherer, ein forensischer Dienstleister und das Cloud-Betriebsteam. Ein Darknet-Portal zeigt eine Frist von 48 Stunden und eine siebenstellige Forderung in Kryptowährung.

Der CEO stellt die Frage, vor der sich jeder CISO fürchtet.

„Können wir zahlen, und wer darf das entscheiden?“

Die falsche Antwort ist, dies als Verhandlungsproblem zu behandeln. Die richtige Antwort ist, es als Governance-Problem zu behandeln.

Im Jahr 2026 ist die Governance von Entscheidungen über Ransomware-Zahlungen keine interne technische Krisenentscheidung mehr. Sie kann von Aufsichtsbehörden, Auditoren, Versicherern, Kunden, Strafverfolgungsbehörden, Anteilseignern und dem Leitungsorgan geprüft werden. Eine Zahlungsentscheidung berührt Sanktionsrisiken, die Bewertung einer Verletzung des Schutzes personenbezogener Daten, Bedingungen der Cyberversicherung, vertragliche Pflichten, Krisenkommunikation, Beweissicherung, gestufte Meldungen nach NIS2, Vorfallklassifizierung nach DORA, Meldungen nach GDPR und Verbesserungsmaßnahmen nach dem Vorfall.

Deshalb empfiehlt Clarysec seinen Kunden, die Governance von Entscheidungen über Ransomware-Zahlungen bereits vor dem Vorfall im ISMS zu verankern. ISO/IEC 27001:2022 liefert die Struktur des Managementsystems. Die Kontrollen aus ISO/IEC 27002:2022 liefern das operative Modell. Zenith Blueprint: 30-Schritte-Roadmap für Auditoren und Zenith Controls: Der Cross-Compliance-Leitfaden helfen dabei, diese Struktur in praktische, auditfähige Nachweise zu überführen.

Ein Ransomware-Playbook, das lediglich „Rechtsabteilung benachrichtigen“ vorsieht, reicht nicht aus. Die Organisation muss wissen, wer Verhandlungen autorisieren darf, wie die Sanktionsprüfung durchgeführt wird, wann der Versicherer zustimmen muss, wie die Klassifizierung nach GDPR, NIS2 und DORA dokumentiert wird und wie Beweismittel geschützt werden, während Wiederherstellungsteams unter Druck arbeiten.

Warum Ad-hoc-Entscheidungen über Ransomware-Zahlungen scheitern

Eine Entscheidung über eine Ransomware-Zahlung wird häufig als binär beschrieben: zahlen oder nicht zahlen. Tatsächlich umfasst die Entscheidung mindestens sechs Ebenen:

1. Ist das Ereignis bestätigt, eingedämmt und korrekt klassifiziert?
2. Sind personenbezogene Daten, regulierte Daten oder die Erbringung kritischer Dienste betroffen?
3. Darf die Organisation rechtlich mit dem Bedrohungsakteur kommunizieren oder Transaktionen durchführen?
4. Verlangt die Cyberversicherung eine vorherige Mitteilung, zugelassene Anbieter, Zustimmung oder bestimmte Nachweise?
5. Würde eine Zahlung die geschäftlichen Auswirkungen verringern, oder würde sie rechtliche, finanzielle und Reputationsrisiken erhöhen?
6. Wer ist entscheidungsbefugt, und wie wird diese Entscheidung aufgezeichnet?

Während eines laufenden Vorfalls verfolgen voneinander entkoppelte Teams häufig unterschiedliche Ziele. Der CFO kann das Lösegeld angesichts zunehmender Ausfallzeiten als geschäftliche Kosten betrachten. Die Rechtsabteilung sieht Sanktionen, Finanzkriminalität und regulatorische Exponierung. Der Datenschutzbeauftragte bewertet, ob verschlüsselte oder exfiltrierte Daten eine meldepflichtige Verletzung des Schutzes personenbezogener Daten darstellen. Die Compliance-Funktion überwacht die Meldefristen nach NIS2 und DORA. Der CISO versucht, Beweismittel zu sichern und gleichzeitig Dienste wiederherzustellen. Der CEO möchte eine Empfehlung, bevor die Frist des Angreifers abläuft.

Ohne formalen Entscheidungsprozess kann die lauteste Stimme im Raum zum Governance-Modell werden. Genau diese Situation soll moderne Cybersicherheitsregulierung verhindern.

NIS2 macht Cybersicherheit zur Verantwortung der Unternehmensleitung. Article 20 behandelt Governance und Rechenschaftspflicht der Leitungsorgane, während Article 21 Risikomanagementmaßnahmen verlangt, die Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Backup-Management, Krisenmanagement, Sicherheit der Lieferkette, Zugriffskontrolle, Asset-Management, Multi-Faktor-Authentifizierung und Wirksamkeitsbewertung abdecken. Article 23 schafft eine gestufte Meldung erheblicher Sicherheitsvorfälle, einschließlich Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden und, soweit anwendbar, Abschlussbericht innerhalb eines Monats.

Für Finanzunternehmen ist DORA das sektorspezifische Regelwerk zur digitalen operationalen Resilienz. Article 5 weist dem Leitungsorgan die Verantwortung für das Management von IKT-Risiken zu. Articles 17, 18 und 19 behandeln das Management IKT-bezogener Vorfälle, die Klassifizierung und Meldung schwerwiegender IKT-bezogener Vorfälle. DORA verlangt außerdem Reaktions- und Wiederherstellungsfähigkeiten, Backup und Wiederherstellung, Lernen aus Vorfällen, Tests sowie IKT-Drittparteienrisikomanagement.

GDPR ergänzt dies um eine eigenständige, aber überlappende Bewertung. Wenn Ransomware zur unbeabsichtigten oder unrechtmäßigen Vernichtung, zum Verlust, zur Veränderung, zur unbefugten Offenlegung von oder zum Zugriff auf personenbezogene Daten führt, muss der Verantwortliche bewerten, ob eine Verletzung des Schutzes personenbezogener Daten vorliegt. Ist eine Meldung erforderlich, läuft die Frist gegenüber der Aufsichtsbehörde in der Regel 72 Stunden ab Bekanntwerden. Besteht ein hohes Risiko für betroffene Personen, kann auch eine Benachrichtigung der betroffenen Personen erforderlich sein.

Die Schlussfolgerung ist einfach: Die Lösegeldfrage darf nicht erstmals im Krisenraum gestellt werden.

ISO 27001:2022-Kontrollen, die die Zahlungs-Governance verankern

Ein ISO/IEC 27001:2022-ISMS ist keine Checkliste für Auditoren. Es ist ein Managementsystem für risikobasierte Entscheidungen. Die Governance von Ransomware-Zahlungen gehört in dieses System, weil sie Risikobeurteilung, Risikobehandlung, Rollen, rechtliche Verpflichtungen, Management von Informationssicherheitsvorfällen, Kontinuität, Lieferantenmanagement und kontinuierliche Verbesserung miteinander verbindet.

Die relevantesten Kontrollen aus ISO 27001:2022 Anhang A bilden eine zusammenhängende Kontrollkette.

In Zenith Controls klassifiziert der Abschnitt zu A.5.24, Planung und Vorbereitung des Managements von Informationssicherheitsvorfällen, die Kontrolle als korrektiv, verknüpft mit Vertraulichkeit, Integrität und Verfügbarkeit sowie ausgerichtet an den Konzepten Respond und Recover. Er verknüpft A.5.24 außerdem mit der Ereignisbewertung nach A.5.25, dem Lernen aus Vorfällen nach A.5.27, der Protokollierung nach A.8.15, der Überwachung nach A.8.16, der Sicherheit bei Störungen nach A.5.29, Kontinuität und Kontakt mit Behörden.

Das ist wichtig, weil die Governance von Ransomware-Zahlungen eine Kette ist. Wenn Sie das Ereignis nicht erkennen und klassifizieren können, können Sie nicht entscheiden. Wenn Sie Beweismittel nicht sichern können, können Sie die Entscheidung nicht verteidigen. Wenn rechtliche Verpflichtungen nicht abgebildet sind, können Verhandlungen oder Zahlungen rechtswidrig sein. Wenn Wiederherstellungsoptionen nicht getestet sind, können Führungskräfte zu einer Entscheidung gedrängt werden, die auf Angst statt auf Fakten beruht.

Zenith Controls beschreibt die Beziehung zwischen Vorbereitung und Entscheidungsfindung klar:

„5.25 ist der Entscheidungspunkt, der bestimmt, wann ein Ereignis den Schwellenwert zu einem Sicherheitsvorfall überschreitet und dadurch die in 5.26 beschriebenen Maßnahmen auslöst. Eine zeitnahe und genaue Ereignisbewertung stellt sicher, dass die Reaktion auf den Sicherheitsvorfall weder verzögert noch fehlgeleitet wird.“

Derselbe Leitfaden verknüpft A.5.31, Rechtliche, gesetzliche, regulatorische und vertragliche Anforderungen, mit Datenschutz, Aufbewahrung von Aufzeichnungen, unabhängiger Überprüfung und Einhaltung interner Richtlinien. Bei Ransomware ist A.5.31 der Ort, an dem Sanktionsprüfung, Versicherungsverpflichtungen, Einbindung der Strafverfolgungsbehörden, Kundenverträge, Datenschutzpflichten und sektorspezifische regulatorische Meldungen in einem Compliance-Register erfasst werden.

Das Fünf-Gate-Modell von Clarysec für die Governance von Ransomware-Zahlungen

Das Modell von Clarysec unterteilt die Governance von Entscheidungen über Ransomware-Zahlungen in fünf Gates. Ziel ist nicht, Zahlungen zu erleichtern. Ziel ist, jede Entscheidung, einschließlich der Weigerung zu zahlen, evidenzbasiert, rechtlich geprüft, autorisiert und auditierbar zu machen.

Dieses Modell nutzt die Logik der Risikobehandlung nach ISO 27001. Eine Ransomware-Zahlung ist keine Sicherheitskontrolle. Sie ist allenfalls eine Krisenoption, die im Kontext von Risikobehandlung und Wiederherstellung betrachtet wird. Vor einem Vorfall sollte die Organisation bereits entschieden haben, wie Ransomware-Risiken behandelt werden: durch Kontrollen mindern, einen Teil der finanziellen Exponierung über Versicherung übertragen, inakzeptable Abhängigkeiten von Altsystemen vermeiden oder Restrisiko, wo begründet, ausdrücklich akzeptieren.

In der Phase Risikomanagement, Schritt 13, Risikobehandlungsplanung und Anwendbarkeitserklärung, weist Zenith Blueprint Organisationen an, Behandlungsoptionen für jedes Risiko festzulegen und im Risikoregister zu dokumentieren. Es warnt, dass Übertragung, etwa durch Cyberversicherung, die Notwendigkeit von Kontrollen nicht beseitigt, weil Übertragung häufig die finanziellen Auswirkungen und nicht die Eintrittswahrscheinlichkeit adressiert. Es heißt außerdem:

„Akzeptanz muss ausdrücklich erfolgen und vom Management genehmigt werden, insbesondere bei Risiken mittlerer Einstufung. Hohe Risiken werden nur selten akzeptiert, es sei denn, sie sind wirklich unvermeidbar und auf oberster Ebene abgestimmt.“

Diese Aussage ist unmittelbar relevant für die Governance von Ransomware-Zahlungen. Wenn das Leitungsorgan gebeten wird, das Restrisiko einer Zahlungsverweigerung oder das rechtliche und Reputationsrisiko einer Verhandlungsfreigabe zu akzeptieren, muss diese Akzeptanz ausdrücklich, aufgezeichnet und durch die zuständige Befugnis genehmigt sein.

Clarysecs Risikomanagement-Richtlinie bekräftigt denselben Punkt:

„Entscheidungen zur Risikobehandlung müssen an den vordefinierten Optionen ausgerichtet sein.“
Aus Klausel 5.5.

Eine Lösegeldentscheidung ist daher keine Abkürzung am Risikomanagement vorbei. Sie muss als formale, dokumentierte Entscheidung zur Risikobehandlung unter definierter Befugnis gehandhabt werden.

Richtlinienbefugnis: Wer darf unter Druck entscheiden?

Viele Ransomware-Fehler sind Governance-Fehler, die als technische Fehler erscheinen. Jemand kontaktiert den Angreifer außerhalb des genehmigten Kanals. Jemand sagt eine Zahlung zu, bevor der Versicherer zugestimmt hat. Jemand stellt Systeme wieder her und überschreibt forensische Beweismittel. Jemand informiert Kunden zu früh, zu spät oder mit ungenauen Fakten.

Clarysec-Richtlinien sind darauf ausgelegt, diese Unklarheit zu beseitigen.

Für KMU gibt die Richtlinie zu Governance-Rollen und Verantwortlichkeiten – KMU eine einfache Regel vor:

„Alle wesentlichen Sicherheitsentscheidungen, Ausnahmen und Eskalationen müssen aufgezeichnet und nachvollziehbar sein.“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.5.

Die KMU-Richtlinie zum Management von Informationssicherheitsvorfällen – KMU weist die Eskalationsbefugnis zu:

„Der General Manager (GM) ist für die Autorisierung aller Entscheidungen zur Vorfalleskalation, regulatorischen Meldungen und externen Kommunikation rechenschaftspflichtig.“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.1.1.

Sie verknüpft außerdem Vorfälle mit Kundendaten mit regulatorischen Verpflichtungen:

„Wenn Kundendaten betroffen sind, muss der General Manager die rechtlichen Benachrichtigungspflichten auf Grundlage der Anwendbarkeit von GDPR, NIS2 oder DORA bewerten.“
Aus dem Abschnitt „Risikobehandlung und Ausnahmen“, Richtlinienklausel 7.4.1.

Für größere Organisationen verlangt die Enterprise-Richtlinie zu Governance-Rollen und Verantwortlichkeiten eine sofortige Eskalation, wenn rechtliche Exponierung oder meldepflichtige Datenschutzverletzungen bestehen können:

„Rechtliche und regulatorische Eskalation: Vorfälle mit potenzieller rechtlicher Exponierung oder meldepflichtigen Datenschutzverletzungen sind unverzüglich an den Rechts- und Compliance-Beauftragten und die Geschäftsleitung zu eskalieren.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.4.3.

Die Enterprise-Richtlinie zum Management von Informationssicherheitsvorfällen definiert die Befugnis der Geschäftsleitung bei schweren Vorfällen. Klausel 4.6.1 legt fest, dass die Rolle des Executive Management Team darin besteht:

„Strategische Entscheidungen bei Vorfällen mit hohem Schweregrad zu treffen, einschließlich der Freigabe von Meldungen und öffentlicher Kommunikation.“

Im Ransomware-Kontext behandelt Clarysec Zahlungsdiskussionen, Verhandlungsautorisierung, Kundenbenachrichtigung, regulatorische Stellungnahmen und öffentliche Kommunikation als strategische Entscheidungen, nicht als technische Maßnahmen.

Daraus folgt eine praktische Governance-Regel: Der CISO kann empfehlen, das Vorfallteam kann bewerten, die Rechtsabteilung kann beraten, Finanzen kann Zahlungsmechanismen validieren, der Versicherer kann Deckung zustimmen oder ablehnen, aber die Geschäftsleitung oder das Leitungsorgan muss die Entscheidung gemäß vordefinierter Befugnis verantworten.

Sanktionskonforme Eskalation vor jeder Verhandlung

Ein sanktionskonformer Ransomware-Prozess beginnt mit einem Verbot: Kein Mitarbeiter, Auftragnehmer, Lieferant, Broker, Verhandlungsführer oder Vorfallreaktionsteam darf ohne genehmigte rechtliche Prüfung mit einem Bedrohungsakteur verhandeln, etwas zusagen, eine Transaktion ermöglichen oder Werte übertragen.

Der rechtliche Kontrollpunkt muss vor jeder aktiven Interaktion mit dem Angreifer erfolgen, nicht erst nachdem eine Wallet-Adresse erscheint. Der Prozess sollte Folgendes umfassen:

• Einbindung der Rechtsabteilung vor jeder Kommunikation, die über passive Beweiserfassung hinausgeht.
• Identifizierung des Bedrohungsakteurs anhand forensischer, nachrichtendienstlicher und, soweit verfügbar, strafverfolgungsbehördlicher Informationen.
• Prüfung gegen Sanktions- und Sperrlisten für Gruppennamen, Aliasse, Wallet-Adressen, Infrastruktur, zwischengeschaltete Parteien und Zahlungskanäle.
• Prüfung und Aufzeichnung einer Konsultation mit Strafverfolgungsbehörden.
• Benachrichtigung des Cyberversicherers gemäß Versicherungsbedingungen vor Beauftragung von Anbietern oder Aufnahme von Verhandlungen.
• Einbindung des Datenschutzbeauftragten oder Datenschutzverantwortlichen, wenn personenbezogene Daten betroffen sein können.
• Bestätigung durch CFO oder Finanzleitung zu Zahlungskontrollen, Funktionstrennung, Betrugspräventionsprüfungen und Anforderungen an die Freigabe durch das Leitungsorgan.
• Aufzeichnung der Entscheidung der Geschäftsleitung unter Berücksichtigung von Alternativen, einschließlich Wiederherstellung, Eindämmung, Aussetzung der Leistungserbringung, Kundenkommunikation und Zahlungsverweigerung.
• Sicherung von Beweismitteln zu Kommunikation mit Angreifern, Indikatoren, Wallet-Details, Entscheidungssitzungen, Freigaben und externer Beratung.

Für Ransomware sollte das Rechtsregister mindestens die folgenden Quellen von Verpflichtungen enthalten.

Organisationen sollten außerdem festlegen, wer die Zahlungsentscheidung stoppen kann. Rechtsabteilung, Compliance, Datenschutzbeauftragter, Sanktionsberater oder Leitungsorgan sollten ausdrücklich befugt sein, Verhandlungen oder Zahlungen zu pausieren, wenn die Prüfung unvollständig ist, Beweismittel unzuverlässig sind, Bedingungen des Versicherers nicht erfüllt sind oder die Handlung gegen Gesetz oder Vertrag verstoßen könnte.

Beweissicherung: Bei der Wiederherstellung keine Nachweise vernichten

Ransomware-Teams drängen naturgemäß darauf, den Betrieb wiederherzustellen. Wenn die Wiederherstellung jedoch Logs, Snapshots, Lösegeldforderungen, Schadsoftware-Proben, Speicherabbilder oder Angreifernachrichten vernichtet, kann die Organisation die Fähigkeit verlieren, nachzuweisen, was geschehen ist.

In der Phase „Kontrollen in der Praxis“, Schritt 23, Organisatorische Maßnahmen, weist Zenith Blueprint Organisationen an, Fähigkeiten des Vorfallmanagements zu validieren und zu testen, indem meldepflichtige Sicherheitsereignisse definiert, Entscheidungsfindung dokumentiert und forensische Beweismittel gesichert werden. Es weist Teams an:

„Alle Entscheidungen, Rollen und Kommunikationen zu erfassen und zu protokollieren (5.26) und den Plan um gewonnene Erkenntnisse zu aktualisieren (5.27). Zu bestätigen, dass Verfahren zur Sicherung forensischer Beweismittel vorhanden sind (5.28), einschließlich Log-Snapshots, Backups und sicherer Isolation betroffener Systeme.“

Derselbe Schritt erläutert A.5.28 in einer Sprache, die jedes Leitungsorgan verstehen sollte:

„Was Sie nachweisen können, ist genauso wichtig wie das, was tatsächlich geschehen ist.“

Clarysecs Enterprise-Richtlinie zur Beweissicherung und Forensik bekräftigt, dass Beweismittel nachvollziehbar bleiben müssen:

„Ein Protokoll zur Übertragungskette muss alle physischen oder digitalen Beweismittel vom Zeitpunkt der Erfassung bis zur Archivierung oder Übertragung begleiten und Folgendes dokumentieren:“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.6.

Für KMU ist die Richtlinie zur Beweissicherung und Forensik – KMU bewusst praxisnah:

„Es muss immer eine forensische Kopie oder ein Export erstellt werden; das Originalbeweismittel darf niemals direkt bearbeitet werden.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.1.

Sie verlangt außerdem rechtliche Konsultation, wenn HR-, rechtliche oder kundenseitige Auswirkungen bestehen können:

„Wenn der Vorfall potenzielle Auswirkungen auf Human Resources (HR), rechtliche Belange oder Kunden hat, muss der GM vor der Fortsetzung von Durchsetzungs- oder Eskalationsmaßnahmen die Rechtsabteilung konsultieren.“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.4.2.

Ein praktisches Beweismittelpaket sollte während Gate 2 eröffnet werden. Erstellen Sie einen eingeschränkten Ordner für Vorfallsbeweismittel. Exportieren Sie SIEM-Zeitachsen, EDR-Erkennungen, Cloud-Audit-Logs, Anmeldeprotokolle des Identitätsanbieters, Status von Backup-Jobs, Lösegeldforderungen, Screenshots, Angreifernachrichten, Wallet-Adressen, Dateiproben, Verweise auf Rechtsberatung, Korrespondenz mit dem Versicherer und Sitzungsentscheidungen. Weisen Sie einen Verwahrer zu. Zeichnen Sie Hashwerte auf, sofern angemessen. Lassen Sie Administratoren betroffene Systeme nicht bereinigen, bevor eine forensische Erfassung erfolgt ist, es sei denn, der Schutz von Leib und Leben, der Schutz kritischer Dienste oder eine von der Geschäftsleitung genehmigte Eindämmung erfordern dies.

Ein Klassifizierungsarbeitsblatt für NIS2, DORA und GDPR

Ein Ransomware-Vorfall kann mehrere Fristen auslösen. Die Herausforderung besteht nicht nur darin, die Fristen zu kennen. Sie besteht darin zu wissen, wann die Organisation Kenntnis erlangte, was sie zu diesem Zeitpunkt wusste und wie Klassifizierungsentscheidungen getroffen wurden.

NIS2 Article 23 verlangt von wesentlichen und wichtigen Einrichtungen, dem CSIRT oder der zuständigen Behörde erhebliche Sicherheitsvorfälle unverzüglich zu melden. Erheblichkeit ist mit schwerwiegender Betriebsstörung, finanziellen Verlusten oder erheblichem materiellem oder immateriellem Schaden für andere verbunden. Das gestufte Modell umfasst eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden, Zwischenaktualisierungen auf Anforderung sowie, soweit anwendbar, einen Abschlussbericht innerhalb eines Monats nach der Vorfallmeldung.

DORA verlangt von Finanzunternehmen, ein Management IKT-bezogener Vorfälle zu definieren und umzusetzen, Vorfälle und erhebliche Cyberbedrohungen aufzuzeichnen, Vorfälle anhand von Kriterien wie betroffenen Kunden, Dauer, geografischer Ausbreitung, Datenverlust, Kritikalität und wirtschaftlichen Auswirkungen zu klassifizieren und schwerwiegende IKT-bezogene Vorfälle über Erst-, Zwischen- und Abschlussberichte an zuständige Behörden zu melden.

GDPR stellt eine andere, aber überlappende Frage: Hat der Vorfall eine Verletzung des Schutzes personenbezogener Daten verursacht? Wenn ja, führt sie voraussichtlich zu einem Risiko für betroffene Personen? Ist die Meldeschwelle erreicht, muss die Meldung an die Aufsichtsbehörde im Hinblick auf die 72-Stunden-Frist bewertet werden. Besteht ein hohes Risiko, kann auch eine Benachrichtigung betroffener Personen erforderlich sein.

Clarysec empfiehlt, ein einheitliches Ransomware-Klassifizierungsarbeitsblatt mit getrennten Abschnitten für jedes Regelwerk zu führen.

Dieser Ansatz passt zu den ISO 27001-Klauseln zu Risikobeurteilung, Risikobehandlung und dokumentierter Information. Er ist außerdem mit NIST CSF 2.0 abgestimmt. Die Funktion GOVERN des NIST CSF 2.0 erwartet, dass Organisationen Interessenträger, rechtliche und regulatorische Verpflichtungen, Risikobereitschaft, Rollen, Richtlinien, Aufsicht und Drittparteienrisiken verstehen. Die Ergebnisse zu Erkennung, Reaktion und Wiederherstellung unterstützen Vorfalldeklaration, Analyse, Reaktionskoordination, Benachrichtigung von Interessenträgern, Wiederherstellungsdurchführung und Validierung der Wiederherstellung.

Für Finanzunternehmen kann DORA als sektorspezifisches Cybersicherheitsregime für überlappende NIS2-Verpflichtungen wirken. Das beseitigt jedoch nicht die Notwendigkeit, die Anwendbarkeit von NIS2 auf Gruppengesellschaften, IKT-Anbieter, Managed Services oder Cloud-Abhängigkeiten zu verstehen. Die praktische Antwort besteht nicht darin, getrennte Playbooks zu pflegen. Sie besteht darin, ein ISMS-Nachweismodell zu betreiben, das auf alle relevanten Verpflichtungen abgebildet ist.

Cyberversicherung und Lieferantenkoordination sind Governance-Kontrollen

Cyberversicherung kann wertvoll sein, ist aber keine Ransomware-Strategie. Sie ist ein Mechanismus der Risikoübertragung mit Bedingungen. Während eines Ransomware-Ereignisses kann der Versicherer unverzügliche Benachrichtigung, Nutzung freigegebener Dienstleister, vorherige Freigabe für Verhandlungen, Sicherung von Beweismitteln, Nachweis eines Backup-Fehlers, Nachweis angemessener Kontrollen und rechtliche Prüfung vor jeder Zahlungsabwägung verlangen.

DORA macht IKT-Drittparteienrisiko zu einem zentralen Compliance-Bereich. NIS2 Article 21 verlangt außerdem Sicherheit der Lieferkette sowie die Berücksichtigung von Schwachstellen und Cybersicherheitspraktiken von Lieferanten. ISO 27001 unterstützt dieselbe Logik durch Lieferanten- und Cloud-Kontrollen wie A.5.19 bis A.5.23 sowie durch Vorfall-, Kontinuitäts- und rechtliche Kontrollen.

Zenith Controls verknüpft Vorfallvorbereitung mit externen Partnern, einschließlich forensischer Firmen, Rechtsabteilung, PR und Kontakt mit Behörden. Aus Auditsicht kann das Fehlen vorab identifizierter externer Partner als Bereitschaftslücke bewertet werden, weil es die Reaktion während eines realen Vorfalls verzögern kann.

Für die Governance von Ransomware-Zahlungen empfiehlt Clarysec, vorab zu vereinbaren:

• Forensischer Rahmenvertrag oder Bedingungen für schnelle Reaktion.
• Verfügbarkeit externer Rechtsberater für Datenschutzverletzungen, Sanktionen und Privilegierungsstrategie.
• Benachrichtigungsweg zum Cyberversicherer und Liste genehmigter Lieferanten.
• Eskalationsweg zum Cloud-Anbieter für Snapshots, Logs, Isolation und Wiederherstellung.
• Verfahren zur Vorfallzusammenarbeit mit MSSP oder MDR.
• Prüfprozess für PR und Krisenkommunikation.
• Bank- oder Finanzfreigabekontrollen für jede außergewöhnliche Zahlung.
• Kontaktprotokoll für Strafverfolgungsbehörden.

Dies lässt sich gut auf Ergebnisse zur Lieferkette im NIST CSF 2.0 abbilden, einschließlich Lieferantenrollen und -verantwortlichkeiten, gebotene Sorgfalt, vertragliche Cybersicherheitsanforderungen, Lieferantenkoordination bei Vorfällen und Tätigkeiten nach Vertragsbeendigung.

Ein praktisches Eskalations-Playbook für Ransomware-Zahlungen

Die fünf Gates können in ein operatives Playbook übersetzt werden. Jeder Schritt sollte dokumentiert, verantwortet und geübt werden.

Ziel ist nicht, eine angenehme Entscheidung zu garantieren. Möglicherweise gibt es keine angenehme Entscheidung. Ziel ist sicherzustellen, dass die Entscheidung autorisiert, evidenzbasiert, rechtlich fundiert und belastbar ist.

Die 90-minütige Tabletop-Übung, die Bereitschaft nachweist

Der einfachste Weg, die Governance von Ransomware-Zahlungen zu testen, ist kein technisches Red Team. Es ist eine entscheidungsorientierte Tabletop-Übung.

Nutzen Sie Zenith Blueprint, Phase „Kontrollen in der Praxis“, Schritt 23, um die Fähigkeit zum Vorfallmanagement zu validieren. Wählen Sie ein Ransomware-Szenario und führen Sie eine zeitlich begrenzte Übung durch. Ziel ist nicht, vorab zu entscheiden, dass die Organisation zahlen oder niemals zahlen würde. Ziel ist nachzuweisen, dass die Organisation eine gesteuerte Entscheidung treffen kann.

Szenario: Eine Cloud-basierte Kundendatenbank ist verschlüsselt, der Angreifer behauptet Exfiltration, Backups existieren, wurden aber noch nicht auf Integrität geprüft, der Versicherer wurde nicht benachrichtigt, und der Angreifer stellt eine Wallet-Adresse mit einer Frist von 48 Stunden bereit.

Übungscheckliste:

• Vorfall deklarieren und Vorfallleiter zuweisen.
• Ransomware-Entscheidungsprotokoll eröffnen.
• Ereignis anhand der Kriterien aus A.5.25 klassifizieren.
• Betroffene Assets und Geschäftsservices identifizieren.
• Feststellen, ob personenbezogene Daten betroffen sind.
• Bewertungs-Workflows für GDPR, NIS2, DORA und vertragliche Pflichten auslösen.
• Rechtsabteilung, Datenschutzbeauftragten, Geschäftsleitung, Versicherer und forensischen Dienstleister benachrichtigen.
• Beweismittel vor destruktiven Wiederherstellungsmaßnahmen sichern.
• Backup-Integrität und Wiederherstellungsoptionen prüfen.
• Sanktionsprüfung vor jeder Verhandlung durchführen.
• Aufzeichnen, ob eine Konsultation mit Strafverfolgungsbehörden erforderlich ist.
• Halteerklärungen für Kunden und Aufsichtsbehörden entwerfen.
• Entscheidungsoptionen der zuständigen Geschäftsleitungsinstanz vorlegen.
• Entscheidung, Begründung, abweichende Meinungen, Freigaben und nächste Maßnahmen aufzeichnen.
• Nachprüfung nach dem Vorfall und Maßnahmen zur Kontrollverbesserung einplanen.

Das Ergebnis sollte ein vollständiges Nachweispaket sein: Teilnehmerliste, Zeitachse, Klassifizierungsarbeitsblatt, Entscheidungsprotokoll, Kommunikationsentwürfe, rechtliche Maßnahmenpunkte, Maßnahmenpunkte des Versicherers, Backup-Feststellungen und gewonnene Erkenntnisse. Dieses Paket ist aus Auditsicht besonders wertvoll, weil es zeigt, dass Governance bereits vor einer realen Krise funktioniert.

Wie Auditoren und Aufsichtsbehörden den Prozess prüfen werden

Auditoren mit unterschiedlichem Hintergrund betrachten denselben Ransomware-Prozess aus unterschiedlichen Blickwinkeln.

Zenith Controls bietet detaillierte Auditmethodik für A.5.24, A.5.25 und A.5.31. Für A.5.24 prüfen Auditoren den Incident Response Plan, Schweregradklassifizierungen, Rollen, Kontaktlisten, Anweisungen zur regulatorischen Meldung, Übungen und Regelungen mit externen Partnern. Für A.5.25 prüfen sie, ob Kriterien zur Ereignisklassifizierung bestehen, ob Aufzeichnungen zur Alarmbearbeitung Untersuchungs- und Eskalationsentscheidungen belegen, ob SIEM und Bedrohungsinformationen genutzt werden und ob Datenschutzbeauftragter oder Rechtsabteilung einbezogen werden, wenn personenbezogene Daten betroffen sein können. Für A.5.31 suchen Auditoren nach Rechtsregistern, Zuordnungen zur Compliance, Nachweisen der Überprüfung, Abdeckung durch Interne Revision und Berichterstattung an die oberste Führungsebene.

Das Auditrisiko besteht nicht nur darin, dass eine Organisation gezahlt oder die Zahlung verweigert hat. Das Auditrisiko besteht darin, dass niemand nachweisen kann, wie die Entscheidung getroffen wurde.

Von Erpressung zu Kontrollverbesserung

Ransomware-Governance endet nicht, wenn Systeme wiederhergestellt sind. ISO 27001 erwartet kontinuierliche Verbesserung. A.5.27 Lernen aus Informationssicherheitsvorfällen ist zentral für diese Erwartung. DORA verlangt Ursachenanalyse und zusätzliche Kontrollen. Die Abschlussberichterstattung nach NIS2 erwartet, soweit anwendbar, Risikominderungsmaßnahmen und die wahrscheinliche Ursache. Die Rechenschaftspflicht nach GDPR erwartet die Dokumentation von Entscheidungen und Schutzmaßnahmen.

Jede Nachprüfung nach einem Ransomware-Vorfall sollte beantworten:

• Wurden Meldefristen korrekt identifiziert?
• Hat die Entscheidungsbefugnis wie vorgesehen funktioniert?
• Erfolgten rechtliche und sanktionsbezogene Prüfungen früh genug?
• Hat die Koordination mit dem Versicherer die Reaktion unterstützt oder verzögert?
• Waren Backups vollständig, segregiert, wiederherstellbar und getestet?
• Reichten Logs aus, um Zugriff und Exfiltration zu bewerten?
• Reagierten Lieferanten vertragsgemäß?
• War die Kundenkommunikation korrekt und zeitgerecht?
• Erhielten Führungskräfte die richtigen Informationen zum richtigen Zeitpunkt?
• Welche Kontrollen, Richtlinien, Verträge oder Schulungen müssen geändert werden?

Diese Antworten sollten das Risikoregister, die Anwendbarkeitserklärung, den Incident Response Plan, die Backup-Strategie, Lieferantenverträge, den Kommunikationsplan und das Schulungsprogramm aktualisieren.

In der Phase „ISMS-Grundlagen und Führung“, Schritt 5, betont Zenith Blueprint die Planung externer Kommunikation, einschließlich der Identifizierung von Kunden, Aufsichtsbehörden, Partnern und Öffentlichkeit, der Festlegung, was wann kommuniziert wird, und der Definition, wer kommuniziert. Bei Ransomware wird dieser Schritt zur Brücke zwischen technischer Reaktion und Erhalt von Vertrauen.

Den Entscheidungsnachweis vor der Lösegeldforderung erstellen

Der beste Zeitpunkt, eine Lösegeldentscheidung zu steuern, ist, bevor der Angreifer die Frist setzt.

Wenn Ihr Ransomware-Playbook Entscheidungsbefugnis, rechtliche Prüfung, Sanktionsprüfung, Freigabe durch den Versicherer, Beweissicherung, Klassifizierung nach NIS2 und DORA, GDPR-Bewertung einer Verletzung des Schutzes personenbezogener Daten und Dokumentation auf Ebene des Leitungsorgans nicht definiert, hat die Organisation eine Governance-Lücke, die auf eine Krise wartet.

Clarysec unterstützt Organisationen dabei, diese Fähigkeit im ISMS aufzubauen durch:

• Zenith Blueprint: 30-Schritte-Roadmap für Auditoren für phasenweise ISO 27001-Umsetzung, Risikobehandlung, Kommunikationsplanung und Validierung der Vorfallfähigkeit.
• Zenith Controls: Der Cross-Compliance-Leitfaden zur Abbildung von ISO 27001-Kontrollen auf NIS2, DORA, GDPR, NIST CSF, COBIT 2019, ISO/IEC 27035, ISO/IEC 27701, ISO/IEC 27005 und Auditnachweise.
• Clarysec-Richtlinien für Enterprise und KMU, einschließlich Richtlinie zum Management von Informationssicherheitsvorfällen, Richtlinie zum Management von Informationssicherheitsvorfällen – KMU, Richtlinie zur Beweissicherung und Forensik, Richtlinie zur Beweissicherung und Forensik – KMU, Richtlinie zu Governance-Rollen und Verantwortlichkeiten, Richtlinie zu Governance-Rollen und Verantwortlichkeiten – KMU und Risikomanagement-Richtlinie.
• Praktische Ransomware-Tabletop-Vorlagen, Entscheidungsprotokolle, rechtliche Eskalationsmatrizen, Beweismittelpakete und Arbeitsblätter für die Cross-Compliance-Berichterstattung.

Warten Sie nicht auf den Anruf um 3 Uhr morgens, um herauszufinden, wer entscheiden darf. Prüfen Sie Ihren Incident Response Plan anhand der fünf Gates von Clarysec, führen Sie eine 90-minütige Tabletop-Übung zu Ransomware-Zahlungen durch und erstellen Sie einen sanktionskonformen, auditbereiten Entscheidungsnachweis, der gegenüber Aufsichtsbehörden, Versicherern und dem eigenen Leitungsorgan Bestand hat.