DORA-TLPT-Nachweise mit ISO 27001-Kontrollen

Es ist 07:40 Uhr an einem Montagmorgen, und der CISO eines mittelgroßen Zahlungsinstituts blickt auf drei Varianten derselben unbequemen Frage.

Das Leitungsorgan will wissen, ob die Organisation einen durch Ransomware verursachten Ausfall ihres Kunden-Zahlungsportals überstehen kann. Die Aufsicht verlangt Nachweise, dass Tests der digitalen operationalen Resilienz keine PowerPoint-Übung sind. Die Interne Revision erwartet einen sauberen Prüfpfad von DORA-Verpflichtungen zu IKT-Risiken, ISO 27001-Kontrollen, Testergebnissen, Abhilfeplänen, Lieferantennachweisen und Managementfreigaben.

Der CISO hat einen Red-Team-Bericht. Das SOC hat Screenshots von Alarmmeldungen. Die Infrastruktur hat ein Protokoll zur Backup-Wiederherstellung. Die Rechtsabteilung hat einen DORA-Readiness-Tracker. Der Einkauf hat Bescheinigungen von Cloud-Anbietern.

Nichts davon ist miteinander verbunden.

Genau hier scheitern viele DORA-TLPT- und Resilienztestprogramme. Nicht, weil die Tests schwach wären, sondern weil die Nachweise fragmentiert sind. Wenn ein Auditor fragt: „Zeigen Sie mir, wie dieser Test die Resilienz einer kritischen oder wichtigen Funktion belegt“, kann die Antwort kein Ordner voller Screenshots sein. Sie muss eine belastbare Nachweiskette sein.

An dieser Stelle wird ein an ISO/IEC 27001:2022 ausgerichtetes ISMS wirksam. ISO 27001 strukturiert Geltungsbereich, Risikobeurteilung, Kontrollauswahl, Anwendbarkeitserklärung (SoA), operative Steuerung, internes Audit, Managementbewertung und kontinuierliche Verbesserung. DORA liefert den sektorspezifischen regulatorischen Druck. Die Methodik und die Cross-Compliance-Werkzeuge von Clarysec verbinden beides zu einem einheitlichen, auditbereiten Nachweismodell.

DORA TLPT ist ein Governance-Test, nicht nur eine Angriffssimulation

Threat-led Penetration Testing, kurz TLPT, wird leicht missverstanden. Technisch kann es wie eine anspruchsvolle Red-Team-Übung aussehen: Bedrohungsinformationen, realistische Angriffspfade, verdecktes Vorgehen, Ausnutzungsversuche, Szenarien zur lateralen Bewegung und Validierung der Blue-Team-Reaktion.

Für DORA liegt der Kern jedoch in der digitalen operationalen Resilienz. Kann das Finanzunternehmen schwerwiegende IKT-Störungen überstehen, darauf reagieren und sich davon erholen, wenn Geschäftsprozesse betroffen sind? Kann es nachweisen, dass kritische oder wichtige Funktionen innerhalb der Auswirkungstoleranzen bleiben? Kann das Management darlegen, dass IKT-Risiken gesteuert, finanziert, getestet, behoben und verbessert werden?

DORA Artikel 1 schafft einen einheitlichen EU-Rahmen für die Sicherheit von Netzwerk- und Informationssystemen, die Geschäftsprozesse von Finanzunternehmen unterstützen. Er umfasst IKT-Risikomanagement, Meldung schwerwiegender IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz, IKT-Drittparteienrisikomanagement, verpflichtende Vertragsanforderungen an IKT-Lieferanten, Aufsicht über kritische IKT-Drittdienstleister und aufsichtliche Zusammenarbeit. DORA gilt ab dem 17. Januar 2025.

Für Organisationen, die auch unter NIS2 fallen, wirkt DORA als sektorspezifischer Rechtsakt der Union für überschneidende Cybersicherheitsanforderungen. Praktisch sollten Finanzunternehmen DORA bei IKT-Risikomanagement, Vorfallsmeldung, Tests und IKT-Drittparteienrisiken priorisieren, soweit sich die Regelwerke überschneiden, und zugleich die NIS2-Erwartungen an Gruppenstrukturen, Lieferanten und nichtfinanzielle digitale Dienste verstehen.

DORA verankert zudem Rechenschaftspflicht auf oberster Ebene. Artikel 5 verpflichtet das Leitungsorgan, IKT-Risikoregelungen zu definieren, zu genehmigen, zu überwachen und umzusetzen. Dazu gehören die Strategie für digitale operationale Resilienz, die IKT-Business-Continuity-Leitlinie, Reaktions- und Wiederherstellungspläne, Auditpläne, Budgets, IKT-Drittparteienrichtlinien, Meldekanäle und ausreichendes IKT-Risikowissen durch regelmäßige Schulungen.

Die Auditfrage lautet daher nicht einfach: „Haben Sie ein TLPT durchgeführt?“

Sie lautet:

• War das TLPT mit kritischen oder wichtigen Funktionen verknüpft?
• War es autorisiert, abgegrenzt, sicher und risikobeurteilt?
• Wurden Lieferanten, Cloud-Abhängigkeiten und ausgelagerte IKT-Dienstleistungen einbezogen, soweit relevant?
• Hat der Test Nachweise zu Erkennung, Reaktion, Wiederherstellung und Lessons Learned erzeugt?
• Wurden Feststellungen in Risikobehandlung, nachverfolgte Abhilfemaßnahmen, erneute Tests und Managementberichterstattung überführt?
• Erläutert die Anwendbarkeitserklärung (SoA), welche ISO 27001-Kontrollen aus Anhang A zur Steuerung des Risikos ausgewählt wurden?

Deshalb behandelt Clarysec DORA-TLPT-Nachweise als ISMS-Nachweisproblem und nicht nur als Liefergegenstand eines Penetrationstests.

Das ISO 27001-Nachweisrückgrat vor Testbeginn aufbauen

ISO 27001 verlangt von einer Organisation, ein ISMS einzurichten, umzusetzen, aufrechtzuerhalten und kontinuierlich zu verbessern, das Vertraulichkeit, Integrität und Verfügbarkeit durch einen Risikomanagementprozess schützt. Die Abschnitte 4.1 bis 4.4 verlangen, dass die Organisation interne und externe Themen, interessierte Parteien, gesetzliche und regulatorische Verpflichtungen, Schnittstellen und Abhängigkeiten versteht und anschließend den ISMS-Geltungsbereich dokumentiert.

Für ein DORA-reguliertes Unternehmen sollte dieser Geltungsbereich kritische oder wichtige Funktionen, IKT-Assets, Cloud-Plattformen, ausgelagerte Betriebsleistungen, Zahlungssysteme, Kundenportale, Identitätsdienste, Protokollierungsplattformen, Wiederherstellungsumgebungen und IKT-Drittdienstleister ausdrücklich erfassen. Wenn der TLPT-Geltungsbereich nicht auf den ISMS-Geltungsbereich zurückgeführt werden kann, ist der Prüfpfad bereits geschwächt.

ISO 27001 Abschnitte 6.1.1, 6.1.2 und 6.1.3 verlangen zusammen mit den Abschnitten 8.2 und 8.3 einen Prozess für Risikobeurteilung und Risikobehandlung. Risiken müssen im Hinblick auf Vertraulichkeit, Integrität und Verfügbarkeit identifiziert werden. Risikoverantwortliche müssen zugewiesen werden. Eintrittswahrscheinlichkeit und Auswirkungen müssen bewertet werden. Kontrollen müssen ausgewählt und mit Anhang A abgeglichen werden. Restrisiken müssen durch die jeweiligen Risikoverantwortlichen akzeptiert werden.

Das ist die Brücke zwischen DORA und auditbereiten Tests.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint beschreibt in der Phase Risikomanagement, Step 13, diese Rolle der Nachvollziehbarkeit klar:

Die SoA ist faktisch ein Brückendokument: Sie verbindet Ihre Risikobeurteilung/Risikobehandlung mit den tatsächlich vorhandenen Kontrollen. Durch das Ausfüllen prüfen Sie zugleich, ob Sie Kontrollen übersehen haben.

Für DORA TLPT darf die Anwendbarkeitserklärung (SoA) kein statisches Zertifizierungsartefakt sein. Sie muss erläutern, warum Kontrollen wie Lieferantensicherheit, Incident Management, IKT-Bereitschaft für Business Continuity, Protokollierung, Überwachung, technisches Schwachstellenmanagement, Backups, sichere Entwicklung und Sicherheitsprüfung für das Resilienzszenario anwendbar sind.

Ein praxisnahes Risikoszenario könnte lauten:

„Die Kompromittierung privilegierter Zugangsdaten eines Identitätsanbieters ermöglicht einem Angreifer den Zugriff auf Administrationssysteme der Zahlungsabwicklung, die Änderung von Routing-Konfigurationen und die Störung einer kritischen Zahlungsfunktion. Dies führt zu Serviceausfall, regulatorischen Berichtspflichten, Kundenschäden und Reputationsschaden.“

Dieses eine Szenario kann TLPT-Geltungsbereich, Erkennungs-Use-Cases, Lieferanteneinbindung, Wiederherstellungsübung, Berichterstattung an das Leitungsorgan und Nachweissatz steuern.

Der Zenith Blueprint empfiehlt außerdem, regulatorische Nachvollziehbarkeit ausdrücklich herzustellen:

Verweisen Sie auf Vorschriften: Wenn bestimmte Kontrollen speziell zur Einhaltung von GDPR, NIS2 oder DORA umgesetzt werden, können Sie dies entweder im Risikoregister (als Teil der Begründung der Risikoauswirkungen) oder in den SoA-Anmerkungen festhalten.

Dieser Hinweis ist einfach, verändert aber das Auditgespräch. Anstatt einem Auditor mitzuteilen, dass DORA berücksichtigt wurde, kann die Organisation zeigen, wo DORA im Risikoregister, in der SoA, im Testprogramm, im Richtliniensatz und in der Managementbewertung erscheint.

DORA-Tests auf ISO 27001-Kontrollen abbilden, die Auditoren kennen

DORA Artikel 6 erwartet ein dokumentiertes IKT-Risikomanagementrahmenwerk, das in das übergreifende Risikomanagement integriert ist. ISO 27001 Anhang A liefert den Kontrollkatalog, der dies operativ macht.

Für DORA TLPT und Resilienztests sind diese ISO/IEC 27001:2022-Kontrollen aus Anhang A besonders wichtig:

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls hilft Organisationen, diese Kontrollen nicht als isolierte Checklistenpunkte zu behandeln. Der Leitfaden ordnet ISO/IEC 27002:2022-Kontrollen Attributen, Domänen, operativen Fähigkeiten, Auditerwartungen und Cross-Framework-Mustern zu.

Beispielsweise klassifiziert Zenith Controls die ISO/IEC 27002:2022-Kontrolle 5.30, IKT-Bereitschaft für Business Continuity, als „Korrektiv“, ausgerichtet auf „Verfügbarkeit“, verbunden mit dem Cybersicherheitskonzept „Respond“ und eingeordnet in die Domäne „Resilienz“. Diese Klassifizierung ist nützlich, um Auditoren zu erläutern, warum eine Wiederherstellungsübung nicht nur ein IT-Vorgang ist, sondern eine Resilienzkontrolle mit definierter Rolle im Kontrollumfeld.

Zenith Controls klassifiziert außerdem die Kontrolle 8.29, Security Testing in Development and Acceptance, als präventive Kontrolle zur Unterstützung von Vertraulichkeit, Integrität und Verfügbarkeit, mit operativen Fähigkeiten in Anwendungssicherheit, Informationssicherheits-Assurance sowie System- und Netzwerksicherheit. Bei TLPT-Feststellungen, die auf Schwächen im Anwendungsdesign, unsicheres API-Verhalten, mangelhafte Authentifizierungsabläufe oder unzureichende Validierung zurückzuführen sind, ist dies der Kontrollpfad in die Governance der sicheren Entwicklung.

Auch Kontrolle 5.35, Independent Review of Information Security, ist wichtig. Sie unterstützt unabhängige kritische Prüfung, Governance-Sicherung und korrektive Verbesserung. Interne Teams können Tests koordinieren, aber auditbereite Nachweise erfordern Überprüfung, Eskalation und Aufsicht über die Personen hinaus, die die getesteten Systeme gebaut oder betrieben haben.

Das System schützen, während es getestet wird

Eine gefährliche Annahme bei Resilienztests ist, dass Testen automatisch gut ist. Tatsächlich können intrusive Tests Ausfälle verursachen, sensitive Daten offenlegen, Protokolle verunreinigen, automatisierte Abwehrmaßnahmen auslösen, Kundensitzungen unterbrechen oder Lieferanten dazu bringen, Notfallverfahren einzuleiten.

Clarysecs Security Testing and Red-Teaming Policy Security Testing and Red-Teaming Policy bietet Organisationen ein Governance-Muster für sichere Durchführung. Abschnitt 6.1 lautet:

Testarten: Das Sicherheitsprüfungsprogramm muss mindestens Folgendes umfassen: (a) Schwachstellenscans, bestehend aus automatisierten wöchentlichen oder monatlichen Scans von Netzwerken und Anwendungen zur Identifizierung bekannter Schwachstellen; (b) Penetrationstests, bestehend aus manuellen, vertieften Tests bestimmter Systeme oder Anwendungen durch qualifizierte Tester zur Identifizierung komplexer Schwächen; und (c) Red-Team-Übungen, bestehend aus szenariobasierten Simulationen realer Angriffe, einschließlich Social Engineering und anderer Taktiken, um die Erkennungs- und Reaktionsfähigkeiten der Organisation als Ganzes zu testen.

Für TLPT ist das Red-Teaming-Element offensichtlich, aber der Auditwert entsteht durch das Programmdesign. Schwachstellenscans, Penetrationstests, Red-Team-Übungen, Resilienzübungen und erneute Tests müssen einen Zyklus bilden, keine Sammlung unverbundener Tests.

Abschnitt 6.2 derselben Richtlinie behandelt die sichere Durchführung:

Geltungsbereich und Einsatzregeln: Für jeden Test oder jede Übung muss der STC den Geltungsbereich definieren, einschließlich Systeme und IP-Bereiche im Geltungsbereich, zulässige Testmethoden, Ziele, Zeitpunkt und Dauer. Einsatzregeln müssen dokumentiert werden. Beispielsweise können betrieblich sensitive Systeme als „nur beobachten“ gekennzeichnet werden, um Störungen zu vermeiden, und alle Tests in der Produktion müssen Rollback- und Stoppverfahren enthalten. Sicherheitsmaßnahmen wie definierte Zeitfenster und Kommunikationskanäle müssen eingerichtet werden, um unbeabsichtigte Serviceausfälle zu verhindern.

Dies lässt sich direkt auf Zenith Blueprint, Phase Controls in Action, Step 21, abbilden, der sich auf ISO 27001-Kontrolle 8.34 aus Anhang A, Protection of Information Systems during Audit Testing, konzentriert. Der Zenith Blueprint weist darauf hin, dass Audits, Penetrationstests, forensische Prüfungen und operative Bewertungen erhöhte Zugriffsrechte, intrusive Werkzeuge oder temporäre Änderungen des Systemverhaltens beinhalten können. Er betont Autorisierung, Geltungsbereich, Zeitfenster, Genehmigung durch Systemverantwortliche, Rollback, Überwachung und sichere Handhabung von Testdaten.

Das auditbereite Nachweispaket muss enthalten:

• TLPT-Charta und Ziele
• Zusammenfassung der Bedrohungsinformationen und Begründung des Szenarios
• Kritische oder wichtige Funktionen im Geltungsbereich
• Systeme, IP-Bereiche, Identitäten, Lieferanten und Umgebungen im Geltungsbereich
• Ausschlüsse und Systeme im „Nur beobachten“-Modus
• Einsatzregeln
• Risikobeurteilung für Tests in der Produktion
• Rollback- und Stoppverfahren
• SOC-Benachrichtigungsmodell, einschließlich offengelegter und zurückgehaltener Informationen
• Freigaben durch Recht, Datenschutz und Lieferanten
• Nachweise zur Erstellung und zum Entzug von Testkonten
• Sicherer Speicherort für Testartefakte und Protokolle

Ein DORA TLPT, das keine sichere Autorisierung und Steuerung der Testaktivität belegen kann, kann zwar Resilienzlücken aufdecken, erzeugt aber zugleich Governance-Lücken.

TLPT-Ergebnisse in Risikobehandlung überführen

Der häufigste Fehler nach dem Test ist das Red-Team-Bericht-im-Regal-Problem. Ein qualitativ hochwertiger Bericht wird geliefert, verteilt, besprochen und verliert dann langsam an Schwung. Feststellungen bleiben offen. Kompensierende Kontrollen werden nicht dokumentiert. Akzeptierte Risiken bleiben informell. Erneute Tests finden nie statt.

Die Security Testing and Red-Teaming Policy macht dies unzulässig. Abschnitt 6.6 lautet:

Behebung von Feststellungen: Alle identifizierten Schwachstellen oder Schwächen müssen in einem Feststellungsbericht mit Schweregradbewertung dokumentiert werden. Nach Erhalt des Berichts sind Systemverantwortliche für die Erstellung eines Abhilfeplans mit Fälligkeitsterminen verantwortlich; beispielsweise müssen kritische Feststellungen innerhalb von 30 Tagen und Feststellungen mit hohem Schweregrad innerhalb von 60 Tagen gemäß der Vulnerability and Patch Management Policy der Organisation behoben werden. Der STC muss den Fortschritt der Abhilfemaßnahmen nachverfolgen. Erneute Tests müssen durchgeführt werden, um zu bestätigen, dass kritische Probleme behoben oder angemessen gemindert wurden.

Abschnitt 6.7 ergänzt die Governance-Ebene:

Berichterstattung: Zum Abschluss jedes Tests muss ein formaler Bericht erstellt werden. Für Penetrationstests muss der Bericht eine Management-Zusammenfassung, Methodik und detaillierte Feststellungen mit unterstützenden Nachweisen und Empfehlungen enthalten. Für Red-Team-Übungen muss der Bericht die Szenarien, die erfolgreichen Angriffspfade, die Erkennung durch das Blue Team und die Lessons Learned zu Erkennungs- und Reaktionslücken darstellen. Der CISO muss zusammengefasste Ergebnisse und den Status der Abhilfemaßnahmen der oberen Führungsebene vorlegen und sie, sofern relevant, in den jährlichen Sicherheitsbericht an das Leitungsorgan aufnehmen.

Dies entspricht der Risikobehandlungsleitlinie aus ISO/IEC 27005:2022: Behandlungsoptionen auswählen, Kontrollen aus ISO 27001 Anhang A und sektorspezifischen Anforderungen bestimmen, einen Risikobehandlungsplan erstellen, verantwortliche Personen benennen, Fristen definieren, Status verfolgen, Genehmigung des Risikoverantwortlichen einholen und Restrisikoakzeptanz dokumentieren.

Jede wesentliche TLPT-Feststellung muss zu einem von vier Ergebnissen führen: einer Abhilfemaßnahme, einer Kontrollverbesserung, einer formalen Risikoakzeptanz oder einer Anforderung für einen erneuten Test.

Das Ziel ist nicht, mehr Dokumente zu erzeugen. Das Ziel ist, dass jedes Dokument die nächste Entscheidung erklärt.

Resilienztests müssen Wiederherstellung belegen, nicht nur Erkennung

Ein erfolgreiches TLPT kann zeigen, dass das SOC Command-and-Control-Datenverkehr erkannt, laterale Bewegung blockiert und korrekt eskaliert hat. Das ist wertvoll, aber DORA-Resilienztests gehen weiter. Sie fragen, ob die Organisation Geschäftsservices fortführen oder wiederherstellen kann.

Der Zenith Blueprint, Phase Controls in Action, Step 23, erläutert Kontrolle 5.30, ICT Readiness for Business Continuity, in einer Sprache, die jeder CISO gegenüber dem Leitungsorgan verwenden sollte:

Aus Auditsicht wird diese Kontrolle häufig mit einer einzigen Aufforderung geprüft: Zeigen Sie es mir. Zeigen Sie mir das letzte Testergebnis. Zeigen Sie mir die Wiederherstellungsdokumentation. Zeigen Sie mir, wie lange Failover und Rückschwenk gedauert haben. Zeigen Sie mir den Nachweis, dass das Versprochene geliefert werden kann.

Dieser „Zeigen Sie es mir“-Maßstab ist der Unterschied zwischen Richtlinienreife und operationaler Resilienz.

Clarysecs Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Abschnitt 6.4.1, legt fest:

Die Organisation muss sowohl ihre BCP- als auch ihre DR-Fähigkeiten mindestens jährlich testen. Tests müssen Folgendes umfassen:

Der Abschnitt zur Durchsetzung derselben Richtlinie, Abschnitt 8.5.1, macht die Nachweisverantwortung ausdrücklich:

Der GM muss sicherstellen, dass die folgenden Unterlagen gepflegt und auditbereit sind:

Für ein DORA-reguliertes Finanzunternehmen kann jährliches Testen die Untergrenze sein, nicht das Zielniveau. Kritische oder wichtige Funktionen mit höherem Risiko müssen häufiger getestet werden, insbesondere nach Architekturänderungen, Cloud-Migrationen, wesentlichen Vorfällen, neuen IKT-Lieferanten, wesentlichen Anwendungs-Releases oder Änderungen der Bedrohungsexposition.

Ein belastbares Nachweispaket für Resilienztests muss enthalten:

• Business Impact Analysis mit Zuordnung der kritischen oder wichtigen Funktion
• Durch Geschäftsverantwortliche genehmigte RTO und RPO
• Systemabhängigkeitskarte, einschließlich Identität, DNS, Netzwerk, Cloud, Datenbank, Überwachung, Backup und Drittparteienservices
• Ergebnisse von Backup- und Wiederherstellungstests
• Zeitstempel für Failover und Rückschwenk
• Nachweise, dass Sicherheitskontrollen während der Störung wirksam waren
• Kommunikationsvorlagen für Kunden, Aufsicht und interne Stellen
• Teilnahmeprotokolle des Incident Commanders und des Krisenteams
• Lessons Learned und Verbesserungsmaßnahmen
• Nachweise zu erneuten Tests früherer Wiederherstellungslücken

An dieser Stelle kommt auch GDPR ins Spiel. GDPR Artikel 2 und 3 bringen die meisten SaaS- und Fintech-Verarbeitungsvorgänge personenbezogener Daten aus der EU in den Geltungsbereich. Artikel 4 definiert personenbezogene Daten, Verarbeitung, Verantwortlichen, Auftragsverarbeiter und Verletzung des Schutzes personenbezogener Daten. Artikel 5 verlangt Integrität, Vertraulichkeit und Rechenschaftspflicht, was bedeutet, dass die Organisation die Einhaltung nachweisen können muss. Wenn TLPT oder Wiederherstellungstests Produktivdaten mit personenbezogenen Daten verwenden, Protokolle mit Kennungen kopieren oder die Reaktion auf Datenschutzverletzungen validieren, müssen Datenschutzmaßnahmen dokumentiert werden.

Lieferantennachweise sind der DORA-Blindspot, den Auditoren nicht übersehen werden

Moderne Finanzdienstleistungen werden aus Cloud-Plattformen, SaaS-Anwendungen, Managed-Security-Anbietern, Zahlungsdienstleistern, Datenplattformen, Identitätsanbietern, Observability-Werkzeugen, ausgelagerten Entwicklungsteams und Backup-Anbietern zusammengesetzt.

DORA Artikel 28 verlangt von Finanzunternehmen, IKT-Drittparteienrisiken als Teil des IKT-Risikomanagementrahmenwerks zu steuern und auch dann vollständig verantwortlich zu bleiben, wenn IKT-Dienstleistungen ausgelagert werden. Artikel 30 verlangt schriftliche IKT-Serviceverträge mit Servicebeschreibungen, Bedingungen zur Untervergabe, Verarbeitungsstandorten, Datenschutz, Zugriff und Wiederherstellung, Service Levels, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden, Kündigungsrechten, strengeren Bedingungen für kritische oder wichtige Funktionen, Auditrechten, Sicherheitsmaßnahmen, TLPT-Teilnahme soweit relevant und Exit-Regelungen.

Das bedeutet: Ein TLPT-Szenario darf nicht an der Firewall der Organisation enden, wenn die kritische Funktion von einem Lieferanten abhängt.

Clarysecs Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Abschnitt 6.3.1, legt fest:

Kritische oder risikobehaftete Lieferanten müssen mindestens jährlich überprüft werden. Die Überprüfung muss verifizieren:

Die Security Testing and Red-Teaming Policy ergänzt in Abschnitt 6.9 eine testspezifische Lieferantenanforderung:

Koordination von Tests mit Drittparteien: Wenn ein kritischer Lieferant oder Dienstleister in den Geltungsbereich der Gesamtsicherheit der Organisation fällt, muss die Organisation gemäß der Third-Party and Supplier Security Policy, soweit möglich, eine Zusicherung zu dessen Sicherheitsprüfungspraktiken einholen oder gemeinsame Tests koordinieren. Wird beispielsweise ein Cloud Service Provider (CSP) genutzt, kann die Organisation sich auf dessen Penetrationstestberichte stützen oder ihn vorbehaltlich vertraglicher Bestimmungen in kollaborative Red-Team-Szenarien einbeziehen.

Für auditbereite DORA-Nachweise muss die Lieferantensicherheit mit demselben Risikoszenario wie das TLPT verknüpft werden. Wenn der Identitätsanbieter wesentlich für die Wiederherstellung des Zahlungsverkehrs ist, muss das Nachweispaket Lieferanten-Due-Diligence, vertragliche Sicherheitsanforderungen, Bedingungen zur Vorfallsunterstützung, Testkoordination, Assurance-Berichte, Service-Level-Nachweise, Exit-Strategie und Einschränkungen für Tests enthalten.

NIS2 Artikel 21 ist auch für SaaS-, Cloud-, Managed-Service-, Managed-Security-, Rechenzentrums-, CDN-, Vertrauensdienst-, DNS-, TLD-, Online-Marktplatz-, Suchmaschinen- und Social-Networking-Anbieter relevant. Er verlangt einen All-Gefahren-Ansatz, der Risikoanalyse, Incident Handling, Business Continuity, Sicherheit der Lieferkette, sichere Entwicklung, Wirksamkeitsbewertung, Schulung, Kryptografie, Zugriffskontrolle, Asset-Management, MFA und sichere Kommunikation abdeckt.

Das praktische Ergebnis ist einfach: Finanzunternehmen sollten ein einziges Nachweismodell erstellen, das zuerst DORA erfüllt und anschließend NIS2-Erwartungen querverweist, soweit Lieferanten, Gruppengesellschaften oder nichtfinanzielle digitale Dienste beteiligt sind.

Ein praktisches Clarysec-TLPT-Nachweisregister

Angenommen, das Szenario lautet:

„Ein Bedrohungsakteur kompromittiert ein Administratorkonto bei einer SaaS-Supportplattform, bewegt sich in die Zahlungsbetriebsumgebung, ändert Konfigurationen und stört die Transaktionsverarbeitung.“

Erstellen Sie ein Nachweisregister mit einer Zeile je Nachweisobjekt. Warten Sie nicht bis zum Testende. Befüllen Sie es während Planung, Durchführung, Abhilfemaßnahmen und Abschluss.

Nutzen Sie anschließend Zenith Blueprint Step 13, um Nachvollziehbarkeit in Risikoregister und Anwendbarkeitserklärung (SoA) aufzunehmen. Jedes Nachweiselement muss mit einem Risikoszenario, Risikoverantwortlichen, ausgewählten Kontrollen, Behandlungsplan und Restrisikoentscheidung verbunden sein.

Wenn eine Feststellung eine Softwareschwäche betrifft, verweisen Sie auf Kontrollen zu sicherer Entwicklung und Sicherheitsprüfung. Clarysecs Secure Development Policy-sme Secure Development Policy - SME, aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Abschnitt 6.5.2, verlangt:

Tests müssen dokumentiert werden mit:

Wenn eine Feststellung forensisches Material erzeugt, ist die Beweismittelkette zu wahren. Clarysecs Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME, aus dem Abschnitt „Governance-Anforderungen“, Abschnitt 5.2.1, legt fest:

Jedes digitale Beweismittel muss protokolliert werden mit:

Das ist der Punkt, den viele Teams übersehen. Nachweise sind nicht nur Abschlussberichte. Sie sind die kontrollierte Aufzeichnung darüber, wer genehmigt hat, wer durchgeführt hat, was passiert ist, was erkannt wurde, was wiederhergestellt wurde, was geändert wurde, welche Exponierung verbleibt und wer diese Exponierung akzeptiert hat.

Wie Auditoren dieselben TLPT-Nachweise prüfen

DORA-TLPT-Nachweise werden je nach Hintergrund des Auditors unterschiedlich gelesen. Clarysec gestaltet Nachweispakete so, dass jede Prüfperspektive findet, was sie benötigt, ohne Teams zu doppelter Arbeit zu zwingen.

COBIT 2019 erscheint in der Cross-Compliance-Referenz des Zenith Blueprint für sichere Audit- und Testdurchführung, einschließlich DSS05.03 und MEA03.04. Die Relevanz liegt nicht darin, dass COBIT DORA oder ISO 27001 ersetzt, sondern darin, dass Assurance-Fachleute im ISACA-Stil kontrollierte Durchführung, Überwachung, Bewertung und Nachweise der Einhaltung erwarten.

Die Darstellung für das Leitungsorgan: Was das Management genehmigen muss

Berichterstattung an das Leitungsorgan sollte technisches Theater vermeiden. Das Leitungsorgan benötigt keine Exploit-Payloads. Es benötigt entscheidungsfähige Nachweise:

• Welche kritische oder wichtige Funktion wurde getestet?
• Welches Bedrohungsszenario wurde simuliert und warum?
• Hat die Erkennung funktioniert?
• Hat die Eskalation der Reaktion funktioniert?
• Hat die Wiederherstellung RTO und RPO eingehalten?
• Welche Lieferanten waren beteiligt oder eingeschränkt?
• Welche wesentlichen Schwächen verbleiben?
• Wie hoch sind Kosten, Verantwortlicher und Zeitplan der Abhilfemaßnahmen?
• Welche Restrisiken erfordern formale Akzeptanz?
• Was wird erneut getestet?

Hier wird ISO 27001 Abschnitt 5 wichtig. Die oberste Leitung muss sicherstellen, dass Informationssicherheitsleitlinie und Ziele festgelegt, an der strategischen Ausrichtung ausgerichtet, in Geschäftsprozesse integriert, mit Ressourcen ausgestattet, kommuniziert und kontinuierlich verbessert werden. Rollen und Verantwortlichkeiten müssen zugewiesen sein. Ziele müssen, soweit praktikabel, messbar sein und anwendbare Anforderungen sowie Ergebnisse der Risikobehandlung berücksichtigen.

Wenn TLPT feststellt, dass die Wiederherstellungszeit sechs Stunden gegenüber einer geschäftlichen Toleranz von vier Stunden beträgt, ist dies nicht nur ein Infrastruktur-Backlog-Eintrag. Es ist eine Managemententscheidung zu Risikobereitschaft, Budget, Kundenzusagen, regulatorischer Exponierung, Verträgen, Architektur und operativer Kapazität.

Häufige Nachweisfehler bei DORA-Resilienztests

Clarysec-Überprüfungen finden bei Finanzunternehmen und IKT-Dienstleistern, die sich auf DORA vorbereiten, häufig dieselben Nachweislücken.

Erstens ist der TLPT-Geltungsbereich nicht auf kritische oder wichtige Funktionen abgebildet. Der Test kann technisch beeindruckend sein, belegt aber nicht die Resilienz des Geschäftsprozesses, der für Aufsichtsbehörden relevant ist.

Zweitens werden Lieferantenabhängigkeiten anerkannt, aber nicht nachgewiesen. Teams sagen, der Cloud-Anbieter, das ausgelagerte SOC oder die SaaS-Plattform seien im Geltungsbereich, doch Verträge, Auditrechte, Testfreigaben, Bedingungen zur Vorfallsunterstützung und Exit-Pläne fehlen.

Drittens erzeugt Testen Nachweise, aber keine Behandlung. Feststellungen verbleiben in einem Red-Team-Bericht, anstatt in Aktualisierungen des Risikoregisters, Kontrolländerungen, Verantwortliche, Termine, erneute Tests und Restrisikoentscheidungen überführt zu werden.

Viertens wird Wiederherstellung angenommen, statt nachgewiesen. Backup-Richtlinien existieren, aber niemand kann Failover-Zeitstempel, Integritätsprüfungen der Wiederherstellung, Zugriffsprüfung oder Bestätigung durch Geschäftsverantwortliche zeigen.

Fünftens sind Datenschutz- und forensische Nachweise unkontrolliert. Protokolle und Screenshots enthalten personenbezogene Daten, Testartefakte werden auf gemeinsamen Laufwerken gespeichert, temporäre Konten bleiben aktiv und die Beweismittelkette ist unvollständig.

Sechstens ist die Managementberichterstattung zu technisch. Führungskräfte können nicht erkennen, ob sich die Resilienz verbessert hat, ob das Risiko innerhalb der Risikobereitschaft liegt oder welche Investitionsentscheidungen erforderlich sind.

Jede dieser Lücken lässt sich schließen, wenn DORA TLPT als strukturierter ISO 27001-Nachweisworkflow behandelt wird.

Clarysecs integrierter Ansatz für auditbereite Resilienz

Der Ansatz von Clarysec kombiniert drei Ebenen.

Die erste Ebene ist die 30-Schritte-Implementierungs-Roadmap Zenith Blueprint. Für dieses Thema baut Step 13 Nachvollziehbarkeit für Risikobehandlung und SoA auf, Step 21 schützt Systeme während Audit-Tests, und Step 23 validiert die IKT-Bereitschaft für Business Continuity. Diese Schritte machen TLPT aus einem technischen Ereignis zu einem dokumentierten Governance-Zyklus.

Die zweite Ebene ist Clarysecs Richtlinienbibliothek. Die Security Testing and Red-Teaming Policy definiert Testarten, Geltungsbereich, Einsatzregeln, Abhilfemaßnahmen, Berichterstattung und Lieferantenkoordination. Die Business Continuity Policy and Disaster Recovery Policy-sme legt Erwartungen an jährliche BCP- und DR-Tests sowie auditbereite Kontinuitätsnachweise fest. Die Third-Party and Supplier Security Policy-sme unterstützt Nachweise zur Lieferantensicherheit. Die Secure Development Policy-sme stellt sicher, dass Sicherheitsprüfung dokumentiert wird. Die Evidence Collection and Forensics Policy-sme unterstützt Beweisprotokollierung und Disziplin in der Beweismittelkette.

Die dritte Ebene ist Zenith Controls, Clarysecs Cross-Compliance-Leitfaden. Er hilft, ISO/IEC 27002:2022-Kontrollen Attributen, Domänen, operativen Fähigkeiten und Cross-Framework-Erwartungen zuzuordnen. Für DORA TLPT ist das wichtigste Muster nicht eine einzelne Kontrolle. Es ist die Beziehung zwischen Testen, Kontinuität, Incident Management, Lieferantenmanagement, Protokollierung, Überwachung, sicherer Entwicklung, unabhängiger Überprüfung und Governance.

Wenn diese Ebenen zusammenwirken, verändert sich das Montagmorgen-Problem des CISO. Statt drei unverbundener Fragen von Leitungsorgan, Aufsicht und Interner Revision hat die Organisation eine einzige Nachweisgeschichte:

„Wir haben die kritische Funktion identifiziert. Wir haben das IKT-Risiko bewertet. Wir haben Kontrollen ausgewählt und begründet. Wir haben TLPT autorisiert und sicher durchgeführt. Wir haben erkannt, reagiert und wiederhergestellt. Wir haben Lieferanten einbezogen, soweit erforderlich. Wir haben Nachweise dokumentiert. Wir haben Feststellungen behoben. Wir haben erneut getestet. Das Management hat das verbleibende Risiko überprüft und akzeptiert.“

Das ist auditbereite Resilienz.

Nächste Schritte

Wenn Ihr DORA-TLPT-Programm noch um Berichte statt um Nachweisketten organisiert ist, beginnen Sie mit einem Clarysec-Nachweis-Walkthrough.

Nutzen Sie Zenith Blueprint Zenith Blueprint Step 13, um TLPT-Szenarien mit Risiken, Kontrollen und der Anwendbarkeitserklärung (SoA) zu verbinden. Nutzen Sie Step 21, um sichere Autorisierung, Einsatzregeln, Rollback, Überwachung und Bereinigung zu verifizieren. Nutzen Sie Step 23, um die IKT-Bereitschaft für Business Continuity mit Wiederherstellungsnachweisen zu belegen.

Richten Sie anschließend Ihre Betriebsdokumente an Clarysecs Security Testing and Red-Teaming Policy Security Testing and Red-Teaming Policy, Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, Secure Development Policy-sme Secure Development Policy - SME und Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME aus.

Nutzen Sie schließlich Zenith Controls Zenith Controls, um Ihre DORA-TLPT-Nachweise auf ISO 27001-Kontrollen, NIS2, GDPR, COBIT 2019 und Auditerwartungen abzubilden.

Wenn Ihr nächster Resilienztest mehr als Feststellungen liefern soll, nutzen Sie Clarysec, um daraus eine belastbare Nachweiskette zu machen. Laden Sie die Toolkits herunter, planen Sie eine Bewertung der Nachweisbereitschaft oder fordern Sie einen Walkthrough an, wie Clarysec DORA TLPT von der Planung bis zur Genehmigung durch das Leitungsorgan auf ISO 27001:2022-Kontrollen abbildet.