DORA-Testing: Wie Sie TLPT-Logik pragmatisch vorbereiten, ohne sich zu verbrennen

DORA-Testing: Wie Sie TLPT-Logik pragmatisch vorbereiten, ohne sich zu verbrennen

DORA-Testing: Wie Sie TLPT-Logik pragmatisch vorbereiten, ohne sich zu verbrennen

Vorschlag Veröffentlichungsdatum: 15/09/2025 09:21

Tags: DORA, Resilienztests, TLPT, Krisenfähigkeit, Nachweise

DORA hat eine Eigenschaft, die in vielen Organisationen erst spät wirklich ankommt: Es geht nicht nur darum, dass Sie Prozesse und Kontrollen haben. Es geht darum, dass Sie unter realistischen Bedingungen zeigen können, dass Ihr Betrieb Störungen aushält – und dass Sie daraus sichtbar besser werden. Genau deshalb rückt Testing unter DORA so stark in den Vordergrund. Und genau deshalb entsteht rund um „Threat-led Penetration Testing“ (kurz TLPT) ein besonderer Druck: Viele Teams hören „Penetrationstest“ und denken sofort an Technik. In der Praxis ist TLPT aber vor allem eine Disziplin der Steuerung: realistische Szenarien, klare Ziele, eng abgestimmte Grenzen, Einbindung von Dienstleistern, belastbare Nachweise und vor allem ein sauberer Umgang mit Ergebnissen.

Wenn Unternehmen sich an TLPT „verbrennen“, liegt das selten daran, dass sie grundsätzlich zu wenig können. Meist liegt es an zwei Dingen: Entweder man startet zu groß (zu viel Scope, zu viele Systeme, zu viele Stakeholder, zu wenig Routine). Oder man startet zu technisch (Tool-Fokus), während die entscheidenden Fragen ungelöst bleiben: Welche kritischen Services testen wir wirklich? Welche Abhängigkeiten sind in der Kette? Welche Entscheidungspunkte müssen im Ernstfall funktionieren? Und wie machen wir den Test so, dass er nicht nur „spannend“ ist, sondern für Betrieb und Nachweis wirklich verwertbar?

Dieser Beitrag zeigt eine pragmatische Vorbereitung auf TLPT-Logik, die den Druck rausnimmt und trotzdem ernsthaft ist. Sie bekommen kein theoretisches Idealbild, sondern einen Weg, der in Organisationen funktioniert, die gleichzeitig Betrieb, Projekte, Auditdruck und Lieferantenrealität managen müssen.

Warum TLPT-Logik anders ist als „ein guter Penetrationstest“

Ein klassischer Penetrationstest prüft typischerweise Systeme, Anwendungen oder Netzsegmente auf Schwachstellen – oft in einem klaren technischen Rahmen. TLPT setzt anders an. „Threat-led“ bedeutet: Die Ausgangsbasis sind plausible Angreifer- und Störungsszenarien, die sich an Ihrer realen Bedrohungslage orientieren und an Ihren kritischen Geschäftsleistungen. Das Testziel ist nicht „möglichst viele Findings“, sondern: Was passiert, wenn ein realistischer Angriffsweg auf einen kritischen Service trifft? Wie schnell erkennen Sie das? Wie gut funktionieren Entscheidungen, Eskalation, Kommunikation, technische Gegenmaßnahmen und Wiederanlauf? Und können Sie das als prüfbare Spur nachweisen?

Damit wird TLPT automatisch zu einem End-to-end-Test. Technische Schritte sind wichtig, aber sie sind nur ein Teil. Das Testdesign muss auch die Organisation testen – nicht als Theater, sondern als Betrieb: Schnittstellen zwischen IT, Security, Fachbereich, Dienstleistern, Bereitschaft, Krisenkommunikation, Incident-Führung. Wenn diese Schnittstellen unklar sind, wird der Test entweder gefährlich oder nutzlos. Beides wollen Sie vermeiden.

Die häufigsten Gründe, warum TLPT-Vorbereitung eskaliert

In der Praxis wiederholen sich ein paar Muster sehr zuverlässig. Wenn Sie die früh erkennen, sparen Sie sich Monate an Reibung.

• Scope wird über Compliance definiert („wir müssen viel testen“), statt über kritische Services und echte Abhängigkeiten. Das endet oft in einem riesigen Test, der organisatorisch nicht handhabbar ist.
• Rollen sind formal geklärt, aber nicht stressfest. Im Test stellt sich dann heraus, dass niemand die Incident-Führung wirklich übernimmt oder Kommunikationsfreigaben zu lange dauern.
• Dienstleister sind spät eingebunden. Gerade bei kritischen Abhängigkeiten ist das fatal: Im Ernstfall hängt Geschwindigkeit an Eskalationswegen, Ansprechpartnern und Informationsqualität.
• Testgrenzen sind unklar. Dann entstehen Sicherheitsrisiken, Betriebsrisiken oder rechtliche Risiken, weil nicht sauber geregelt ist, was „erlaubt“ ist und was nicht.
• Evidenz entsteht nachträglich. Das führt zu Nachweisstress, weil man zwar vieles getan hat, aber die Spur nicht sauber ist.

Wenn Sie TLPT pragmatisch vorbereiten wollen, müssen Sie genau diese fünf Punkte entschärfen. Nicht durch mehr Papier, sondern durch klare Vereinbarungen und einfache Standards, die im Test tatsächlich greifen.

Ein praktikabler Startpunkt: Der Test ist immer ein Service-Test

Die wichtigste Entscheidung ist nicht „welche Systeme testen wir“, sondern „welchen kritischen Service testen wir“. DORA denkt in kritischen Leistungen, nicht in Serverlisten. Das klingt trivial, ist aber der Unterschied zwischen „wir haben Technik getestet“ und „wir haben Resilienz getestet“.

Ein guter Service-Scope beschreibt deshalb sehr konkret:

• welcher Service betroffen ist (aus Sicht des Geschäfts, nicht aus Sicht der Infrastruktur),
• welche minimale Betriebsfähigkeit im Notmodus akzeptabel ist,
• welche Abhängigkeiten in der Kette wirklich relevant sind (inklusive Drittparteien),
• welche Auswirkungskriterien den Test „ernst“ machen (Zeit, Daten, Verfügbarkeit, Integrität).

Wenn Sie diese Punkte sauber haben, wird vieles leichter: Testziele werden klar, Grenzen lassen sich definieren, Stakeholder lassen sich sinnvoll auswählen, und die Ergebnisse sind später direkt in Maßnahmen und Prioritäten übersetzbar.

Was Sie vor dem ersten echten TLPT „im Griff“ haben sollten

Hier lohnt sich etwas Struktur, weil genau diese Punkte später über Aufwand und Stress entscheiden. Es geht nicht darum, alles perfekt zu haben. Es geht darum, keine offenen Flanken zu lassen, die den Test unnötig gefährlich oder unnötig chaotisch machen.

1) Eine klare Testabsicht
Was genau wollen Sie zeigen oder lernen? Beispiele: Erkennung und Reaktion auf einen realistischen Angriffsweg auf Service X; Belastbarkeit der Eskalations- und Kommunikationswege; Fähigkeit, den Service kontrolliert zu stabilisieren und wiederherzustellen. Wenn die Absicht klar ist, vermeiden Sie den typischen Fehler „wir testen alles irgendwie“.

2) Eine definierte Testgrenze
TLPT ist kein Freifahrtschein. Sie brauchen Grenzen, die Risiken für den Betrieb minimieren: Was ist tabu (z. B. produktive Datenmanipulation, bestimmte Zeiten, bestimmte Systeme)? Welche Sicherheitsnetze gibt es (z. B. technische Guardrails, Monitoring, Abbruchkriterien)? Wer darf den Test stoppen? Das ist nicht Misstrauen, sondern Professionalität.

3) Eine belastbare Incident-Führung
Wenn im Test etwas „passiert“, braucht es eine Rolle, die den Ablauf führt: Lagebild, Entscheidungspunkte, Kommunikationsrhythmus, Einbindung von Dienstleistern, Dokumentationsspur. Ohne diese Rolle wird jede Organisation langsamer, egal wie gut die Technik ist.

4) Ein definierter Evidenzanker
Der Test muss nicht zu einem Dokumentationsmonster werden. Aber er braucht einen Ort, an dem die wesentlichen Artefakte zusammenlaufen: Zeitlinie, Entscheidungen, Kommunikation, technische Nachweise/Referenzen, Maßnahmen. Wenn Sie das erst nach dem Test „zusammensuchen“, zahlen Sie doppelt.

Die TLPT-Logik pragmatisch aufbauen, ohne gleich „alles“ zu machen

Eine robuste Vorgehensweise ist, die TLPT-Logik in Stufen zu etablieren, ohne daraus ein Großprogramm zu machen. Wichtig ist dabei: Es geht nicht darum, kleine Tests als „Ersatz“ zu verkaufen. Es geht darum, Routine aufzubauen, damit ein späterer, anspruchsvollerer Test nicht zur Überforderung wird.

In vielen Organisationen ist ein sehr sinnvoller Einstieg ein sogenannter „Threat-led Tabletop“: Sie nehmen einen realistischen Angriffs- oder Störungspfad und gehen ihn im Raum durch – nicht als PowerPoint-Übung, sondern als Entscheidungs- und Kommunikationsübung. Was würde in den ersten 30–60 Minuten passieren? Wer entscheidet was? Welche Informationen fehlen typischerweise? Welche Dienstleister müssen wann eingebunden werden? Welche Abbruchkriterien gäbe es? Wo entstehen Nachweise? Das wirkt simpel, hat aber einen enormen Effekt: Sie entlarven offene Fragen, bevor ein technischer Test sie im schlimmsten Moment sichtbar macht.

Der nächste Schritt ist häufig eine „kontrollierte technische Probe“ in einem eng begrenzten Umfeld: nicht um „Hacker-Show“ zu machen, sondern um zu prüfen, ob Monitoring, Detektion, Eskalation und Dokumentation wirklich greifen. Wenn Sie diese Proben sauber machen, sind Sie später deutlich schneller, wenn ein umfassenderer Test ansteht.

Drittparteien: Dort entscheidet sich oft die echte Resilienz

Gerade unter DORA ist es selten realistisch, kritische Services zu testen, ohne Dienstleister mitzudenken. Viele kritische Leistungen hängen an Cloud-Komponenten, Plattformen, Managed Services oder spezialisierten Providern. Im Test (und erst recht im Ernstfall) zählen dann vier Dinge: Erreichen Sie im richtigen Moment die richtige Person? Bekommen Sie belastbare Statusinformationen? Haben Sie einen abgestimmten Kommunikationsmodus? Und können Sie Eskalation auch dann auslösen, wenn Standard-Supportkanäle zu langsam sind?

Praktisch bedeutet das: Wenn Sie TLPT vorbereiten, sollten Sie bei kritischen Dienstleistern vorab klären, wie eine Krise gemeinsam gehandhabt wird. Nicht abstrakt, sondern als minimaler Mechanismus: Ansprechpartner, Eskalationsweg, Reaktionszeiten, Informationsformate, und eine klare Regel, wie „gemeinsame Zeitlinie“ und „gemeinsame Maßnahmen“ dokumentiert werden. Das reduziert im Test nicht nur Reibung, sondern verbessert Ihre reale Krisenfähigkeit.

Ergebnisse, die wirklich zählen: Weniger Findings, mehr Entscheidungsklarheit

Ein TLPT-orientierter Test ist dann wertvoll, wenn Ergebnisse nicht in einer Liste versanden, sondern sich in Steuerung übersetzen lassen. In der Praxis sind die stärksten Ergebnisse oft nicht die spektakulärsten technischen Schwachstellen, sondern die Stellen, an denen Entscheidungen und Betrieb „haken“. Typische Beispiele:

• Detektion war technisch möglich, aber niemand hatte die Verantwortung, daraus schnell eine Einstufung zu machen.
• Die Eskalation zu einem Dienstleister funktionierte, aber zu langsam – weil der richtige Kanal nicht bekannt war oder nicht geübt wurde.
• Kommunikation wurde verzögert, weil Freigaben unklar waren oder Faktenlage nicht in einem einfachen Format verfügbar war.
• Wiederherstellung war technisch machbar, aber der kontrollierte Wiederanlauf war nicht sauber abgesichert.

Solche Erkenntnisse sind für DORA oft wertvoller als „noch ein CVE“. Nicht, weil Technik unwichtig wäre. Sondern weil Operational Resilience im Zusammenspiel entsteht – und Prüfer genau dieses Zusammenspiel sehen wollen.

Evidenz ohne Overkill: Was ein Prüfer schnell verstehen muss

Wenn Sie die Nachweisspur von Anfang an sauber denken, wird Testing unter DORA nicht zur Dokumentationslast. Ein Prüfer muss im Kern sehr schnell nachvollziehen können: Was war das Ziel, was war das Szenario, was ist passiert, welche Entscheidungen wurden getroffen, wie wurde reagiert, was wurde gelernt, was wird verbessert und wann wird das überprüft. Das kann in einer kompakten Testakte abgebildet werden, die auf operative Artefakte verweist (Tickets, Logs, Provider-Kommunikation), statt alles doppelt zu dokumentieren.

Ein sehr praktikabler Qualitätscheck ist: Könnte ein fachfremder, aber prüferfahrener Mensch in 10 Minuten verstehen, was getestet wurde und warum das Ergebnis belastbar ist? Wenn ja, sind Sie evidenzseitig meist sehr gut aufgestellt. Wenn nein, fehlt häufig nicht die Arbeit, sondern die Struktur: zu viele verstreute Artefakte, zu wenig Entscheidungsspur, zu wenig klare Ergebnislogik.

Ein typischer Fehler: TLPT als einmaliges „Event“ behandeln

Wenn TLPT als großes Ereignis geplant wird, steigt der Druck so stark, dass das Team häufig nur noch „durchkommen“ will. Das kann kurzfristig funktionieren, ist aber teuer, weil Lernen und Routine zu kurz kommen. Die TLPT-Logik wird tragfähig, wenn sie in den normalen Verbesserungsmodus eingebettet ist: Erkenntnisse werden in Maßnahmen übersetzt, Maßnahmen werden umgesetzt, und es wird später geprüft, ob die Maßnahmen wirklich wirken. Genau hier liegt der Unterschied zwischen „Test bestanden“ und „Resilienz verbessert“.

Wenn Sie Testing so aufbauen, dass es dem Betrieb nützt, reduzieren Sie automatisch das Risiko, sich zu verbrennen. Denn dann ist Testing nicht zusätzliche Arbeit, sondern eine konzentrierte Form von Betriebsverbesserung – mit sauberer Nachweisspur als Nebenprodukt.