Phishing-Simulation richtig aufsetzen: Metriken, Szenarien, Leitplanken

Viele Unternehmen betreiben Phishing-Simulationen seit Jahren, und viele berichten dasselbe Ergebnis: Die Klickrate sinkt zunächst, pendelt sich dann bei einem Wert zwischen fünf und fünfzehn Prozent ein und bewegt sich nicht mehr. Die Geschäftsleitung fragt, was das Programm eigentlich gebracht hat. Die IT-Sicherheit kann es nicht sauber beantworten, weil die einzige Kennzahl die falsche ist.

Eine Phishing-Simulation ist kein Test, ob Mitarbeitende Fehler machen. Das tun sie, so wie jeder Mensch unter Zeitdruck. Sie ist ein Test, ob die Organisation einen Angriff erkennt, meldet und eindämmt, bevor er Schaden anrichtet. Diese Perspektive ändert alles: die Ziele, die Metriken, die Szenarien und den Umgang mit den Ergebnissen.

Dieser Beitrag beschreibt, wie Sie eine Phishing-Simulation so aufsetzen, dass sie messbare Verbesserung liefert statt eines Dauerzustands mit kosmetischen Zahlen. Er richtet sich an CISO und IT-Leitung, die ein bestehendes Programm überprüfen oder ein neues starten wollen, und behandelt auch die rechtlichen und kulturellen Leitplanken, an denen Programme in Deutschland häufig scheitern.

Welche Ziele eine Simulation verfolgen sollte

Bevor die erste E-Mail verschickt wird, sollte klar sein, welche Frage beantwortet werden soll. Wir unterscheiden drei legitime Ziele, die unterschiedliche Programme erfordern:

• Messung der Meldekultur: Wie viele Mitarbeitende melden eine verdächtige E-Mail, wie schnell, und erreicht die Meldung die richtige Stelle? Dieses Ziel ist für die Verteidigung das wichtigste, weil eine frühe Meldung einen Vorfall auf wenige Postfächer begrenzt.
• Test der technischen Kette: Greifen E-Mail-Filter, Link-Umschreibung, Browser-Isolation und MFA so, dass selbst ein Klick und eine Eingabe keinen Schaden anrichten? Hier steht nicht der Mensch im Fokus, sondern die Kontrollen hinter ihm.
• Vorbereitung auf gezielte Angriffe: Wie reagieren exponierte Gruppen wie Buchhaltung, Assistenz der Geschäftsführung oder IT-Admins auf Spear Phishing, also individuell zugeschnittene Nachrichten? Dieses Ziel verlangt wenige, hochwertige Szenarien statt Massenversand.

Ein Programm, das alle drei Ziele mit derselben Kampagne erreichen will, erreicht keines. Legen Sie pro Welle ein Hauptziel fest und wählen Sie Metriken und Szenarien danach.

Metriken jenseits der Klickrate

Die Klickrate ist leicht zu messen und leicht zu manipulieren. Eine Kampagne mit offensichtlichem Absender erzeugt zwei Prozent, eine mit gefälschter interner Personalabteilung vierzig Prozent. Beide Zahlen sagen nichts über die Widerstandsfähigkeit der Organisation. Die folgenden Kennzahlen sind aussagekräftiger:

Die Zeit bis zur Eindämmung ist die Kennzahl, die den Unterschied zwischen Awareness-Programm und Sicherheitsprogramm ausmacht. Sie misst nicht die Mitarbeitenden, sondern das SOC oder das IT-Team: Wie lange dauert es, bis eine gemeldete E-Mail tatsächlich unschädlich gemacht ist? In vielen Organisationen wird gemeldet, aber niemand reagiert innerhalb der nächsten Stunden. Dann ist die hohe Meldequote wertlos.

Szenarien nach Reifegrad

Ein gutes Programm steigert die Schwierigkeit kontrolliert, sodass die Organisation mitwächst, statt überfordert oder gelangweilt zu werden. Wir arbeiten mit vier Reifegraden:

1. Grundlagen: Generische Szenarien mit erkennbaren Merkmalen: externer Absender, allgemeine Anrede, Paketbenachrichtigung oder Passwortablauf. Ziel ist, den Meldeweg zu etablieren und die technische Kette zu prüfen.
2. Kontextbezug: Szenarien nutzen öffentlich bekannte Informationen über das Unternehmen: aktuelle Projekte, Softwareumstellung, Messebesuch, Namen von Führungskräften. Die Absender wirken intern oder stammen von bekannten Partnern.
3. Gezielte Angriffe: Spear Phishing auf ausgewählte Rollen mit individuellem Vorwand, etwa eine Rechnungsanfrage an die Buchhaltung oder ein Bewerbungsdokument an die Personalabteilung. Hinzu kommen Varianten über andere Kanäle wie Smishing per SMS oder Messenger.
4. Kombinierte Kampagnen: Mehrstufige Angriffe, bei denen eine E-Mail einen Anruf vorbereitet oder umgekehrt, QR-Codes auf gedruckten Aushängen, Consent-Phishing in Microsoft 365 oder Vishing beim Helpdesk. Auf dieser Stufe verschwimmt die Grenze zur Social-Engineering-Komponente eines Red Teamings.

Der häufigste Fehler ist der Sprung von Stufe eins zu Stufe drei, weil die Klickrate auf Stufe eins „zu gut“ aussah. Das Ergebnis ist eine Welle mit hoher Eingabequote, Frustration bei den Mitarbeitenden und ein Programm, das intern als Fallenstellerei wahrgenommen wird. Erhöhen Sie die Schwierigkeit erst, wenn Meldequote und Eindämmungszeit auf der aktuellen Stufe stabil die Zielwerte erreichen.

Rechtliche und kulturelle Leitplanken

In Deutschland entscheidet die Vorbereitung über Erfolg oder Scheitern eines Programms. Drei Themen müssen vor der ersten Welle geklärt sein.

Betriebsrat und Mitbestimmung

Eine Phishing-Simulation ist eine technische Einrichtung, die geeignet ist, Verhalten von Beschäftigten zu überwachen. Damit greift in Unternehmen mit Betriebsrat regelmäßig die Mitbestimmung nach dem Betriebsverfassungsgesetz. Beziehen Sie den Betriebsrat früh ein, am besten mit einer Betriebsvereinbarung, die Zweck, Auswertung, Aufbewahrungsfristen und den ausdrücklichen Verzicht auf individuelle Sanktionen regelt. Ein Betriebsrat, der das Programm mitträgt, ist der beste Verbündete für eine positive Meldekultur. Einer, der übergangen wurde, kann es zu Recht stoppen.

Datenschutz

Ergebnisse einer Simulation sind personenbezogene Daten. Die Rechtsgrundlage ist in der Regel das berechtigte Interesse an der Informationssicherheit, gestützt durch die Pflicht zur regelmäßigen Wirksamkeitsprüfung aus Art. 32 DSGVO. Das bedeutet in der Praxis: Datensparsamkeit (keine Erfassung von eingegebenen Passwörtern, nur ob eingegeben wurde), zweckgebundene Auswertung, kurze Löschfristen für personenbezogene Rohdaten, Einbindung der Datenschutzbeauftragten und bei umfangreichen Programmen eine Datenschutz-Folgenabschätzung. Externe Dienstleister arbeiten auf Basis eines Auftragsverarbeitungsvertrags.

Keine Bloßstellung

Das wichtigste kulturelle Prinzip: Niemand wird für einen Klick bestraft, öffentlich genannt oder in ein „Nachschulungsprogramm“ gesteckt, das als Strafe wahrgenommen wird. Wer Angst vor Konsequenzen hat, meldet nicht, und ohne Meldungen ist die Verteidigung blind. Ergebnisse werden auf Ebene von Abteilungen oder Standorten ausgewertet, nie unterhalb einer Gruppengröße, die Rückschlüsse auf Einzelne erlaubt. Führungskräfte erhalten keine Namenslisten. Die Landing-Page nach einem Klick erklärt sachlich, woran die E-Mail erkennbar war, und dankt für die Aufmerksamkeit, falls die Person anschließend meldet.

Typische Fehler, die wir in Programmen sehen

• Nur die Klickrate wird berichtet. Die Geschäftsleitung sieht eine Zahl, die stagniert, und stellt das Programm infrage. Berichten Sie Meldequote und Eindämmungszeit, dann wird der Fortschritt sichtbar.
• Szenarien mit Gehaltserhöhung, Kündigung oder Boni. Solche Köder erzeugen hohe Klickraten und hohe Verbitterung. Sie beschädigen das Vertrauen in die Personalabteilung und das Programm dauerhaft. Ein echter Angreifer nutzt sie, ein internes Programm sollte es nicht.
• Allowlisting des Simulations-Dienstleisters. Damit die E-Mails sicher ankommen, werden Filter umgangen. Das misst dann den Menschen, aber nicht die Kette. Testen Sie zumindest in jeder zweiten Welle ohne Allowlisting, um zu sehen, was die Technik tatsächlich stoppt.
• Keine Reaktion auf Meldungen. Wer meldet und nichts hört, meldet beim nächsten Mal nicht mehr. Jede Meldung braucht eine kurze Rückmeldung, automatisiert ist besser als keine.
• Kein Test der Eindämmung. Die E-Mail wird gemeldet, aber niemand prüft, ob sie innerhalb einer Stunde aus allen Postfächern entfernt wurde. Genau das ist der Teil, der im Ernstfall zählt.
• Vorwarnung über Intranet oder Betriebsversammlung. Angekündigte Wellen messen Aufmerksamkeit für die Ankündigung, nicht für Phishing. Die Betriebsvereinbarung regelt den Rahmen, nicht den Zeitpunkt.
• Programm ohne Anbindung an die Verteidigung. Die Simulation läuft bei HR oder Compliance, das Sicherheitsteam erfährt von den Ergebnissen aus dem Quartalsbericht. Die Erkenntnisse gehören ins Detection Engineering: Welche Merkmale hätten die Filter erkennen müssen?

Von der Simulation zum Red Team

Eine Phishing-Simulation prüft einen Angriffsvektor isoliert. Sie beantwortet nicht, was nach einem erfolgreichen Klick geschieht: Kann der Angreifer von einem Arbeitsplatz aus ins interne Netz, erreicht er Domänenrechte, bemerkt das SOC seine Bewegungen? Diese Fragen beantwortet ein Assumed Breach, bei dem wir genau dort starten, wo die Simulation endet: mit einem kompromittierten Client oder Benutzerkonto. Reife Programme verbinden deshalb beide Formate. Die Simulation liefert die Eintrittswahrscheinlichkeit, der Assumed Breach den Schaden, der daraus folgen kann. Zusammen ergeben sie das Risiko, das die Geschäftsleitung bewerten muss.

Für Organisationen, die bereits auf Reifegrad drei oder vier arbeiten, ist der nächste Schritt eine vollständige Social-Engineering-Kampagne mit E-Mail, Telefon und gegebenenfalls physischer Komponente, wie wir sie in unserer Leistung Social Engineering & Phishing durchführen. Dort gelten dieselben Leitplanken wie bei der Simulation, mit schriftlichen Rules of Engagement und einem eingeweihten Control Team.

Fazit

Eine Phishing-Simulation ist dann richtig aufgesetzt, wenn sie die Verteidigungsfähigkeit misst und nicht die Fehlerquote der Belegschaft. Meldequote, Zeit bis zur Meldung und Zeit bis zur Eindämmung zeigen Fortschritt, wo die Klickrate stagniert. Betriebsrat, Datenschutz und der Verzicht auf Bloßstellung sind keine Hindernisse, sondern die Voraussetzung für eine Meldekultur, die im Ernstfall trägt. Steigern Sie die Schwierigkeit erst, wenn die Organisation die aktuelle Stufe beherrscht. Wenn Sie Ihr Programm auf den Prüfstand stellen oder um gezielte Szenarien erweitern möchten, finden Sie unter Social Engineering & Phishing unser Vorgehen und unter Ablauf, wie ein Projekt mit uns beginnt.

Quellen

• Mandiant, M-Trends 2026: E-Mail-Phishing 6 % und Vishing 11 % der Erstzugriffe; 52 % der Vorfälle intern erkannt.
• IBM, Cost of a Data Breach Report 2025: Phishing als Erstzugriff bei 14 % der untersuchten Vorfälle in Deutschland.
• Verordnung (EU) 2016/679 (DSGVO), Art. 32: Verfahren zur regelmäßigen Überprüfung der Wirksamkeit technischer und organisatorischer Maßnahmen, eur-lex.europa.eu.

Häufige Fragen zum Thema