DSGVO-konformes Phishing-Training: Regeln und Dokumentation

Warum Einwilligung scheitert: die Rechtsgrundlage für Angriffssimulationen

Die Einwilligung der Beschäftigten wird häufig als Standardrechtsgrundlage für unternehmerische Security-Initiativen genannt – doch im Kontext von Angriffssimulationen schafft der Rückgriff auf die Einwilligung eine unmittelbare regulatorische Schwachstelle. Europäische Datenschutzbehörden bewerten Einwilligungen konsequent durch die Brille des Machtgefälles zwischen Arbeitgeber und Arbeitnehmer. Wenn ein Unternehmen eine Einwilligung für Security-Tests einholt, verhindert die inhärente Abhängigkeit im Arbeitsverhältnis, dass Beschäftigte tatsächlich frei entscheiden können, ohne implizite Karrierenachteile befürchten zu müssen.

Der Europäische Datenschutzausschuss (EDPB) hat diese strukturelle Einschränkung in den Leitlinien 05/2020 zur Einwilligung nach der Verordnung 2016/679 adressiert: Das Machtgefälle bewirke, dass ein Beschäftigter die Bitte des Arbeitgebers um Einwilligung kaum frei ablehnen könne; die Einwilligung sei im Beschäftigungskontext daher als Rechtsgrundlage problematisch.^[1] Zudem müsste das Unternehmen, sobald ein Beschäftigter von seinem gesetzlichen Recht Gebrauch macht, die Einwilligung jederzeit zu widerrufen, ihn von Security-Bewertungen ausschließen – und schafft damit unbeobachtete blinde Flecken in kritischer Infrastruktur.

Um eine belastbare rechtliche Grundlage zu schaffen, sollten Security-Verantwortliche auf Art. 6 Abs. 1 lit. f DSGVO setzen.^[2] Diese Vorschrift erlaubt die Verarbeitung, die zur Wahrung der berechtigten Interessen des Verantwortlichen erforderlich ist, sofern nicht die Interessen oder Grundrechte der betroffenen Person überwiegen. Der Schutz unternehmerischer IT-Systeme gegen Social Engineering stellt ein solches berechtigtes Geschäftsinteresse dar. Die Berufung auf Art. 6 Abs. 1 lit. f erfordert jedoch die Durchführung und Dokumentation einer formalen Interessenabwägung (Legitimate Interest Assessment, LIA), bevor Multi-Channel-Kampagnen starten.

• Zwecktest: Dokumentation der rechtlichen und operativen Notwendigkeit, Unternehmenswerte, geistiges Eigentum und die Netzwerksicherheit gegen KI-gestützte Social-Engineering-Bedrohungen zu schützen.
• Erforderlichkeitstest: Nachweis, dass Multi-Channel-Angriffssimulationen notwendig sind, um Erkennungsgewohnheiten aufzubauen – passive Belehrung oder jährliche Security-Lektüre können keine Abwehrbereitschaft schaffen.
• Abwägungstest: Darlegung, dass das Sicherheitsinteresse des Unternehmens individuelle Datenschutzbelange überwiegt, durch standardmäßige Datenminimierung, Gruppenanonymisierung und nicht-disziplinarische Rahmenbedingungen.

Wer diesen dreistufigen Test vor dem Rollout abschließt, stellt sicher, dass Security-Teams kontinuierliche Multi-Channel-Simulationen durchführen können und dabei strikt den europäischen Regulatorik-Standards entsprechen.

Datenminimierung: welche personenbezogenen Daten dürfen Sie tatsächlich verarbeiten?

Artikel 5 Abs. 1 lit. c DSGVO verankert den Grundsatz der Datenminimierung: Erhobene personenbezogene Daten müssen strikt auf das jeweilige Ziel der Verarbeitung abgestimmt sein.^[3] In Angriffssimulationen ist die Erfassung von Mitarbeiterreaktionen unverzichtbar, um die Abwehrbereitschaft der Organisation zu bewerten – die Protokollierung sensibler Betriebsdaten oder Nutzerzugangsdaten verletzt jedoch diese grundlegenden Datenschutzgrenzen.

Um konform zu bleiben, sollten Security-Systeme nur essenzielle binäre Interaktionsmetadaten verarbeiten – etwa E-Mail-Adressen, Rollen und Zeitstempel von Aktionen wie Melden oder Klicken. Unter keinen Umständen dürfen Simulationsplattformen die tatsächlichen Zugangsdaten erfassen oder speichern, die auf simulierten Landing Pages eingegeben werden. Die Auswertung von Daten aus über 100.000 Security-Simulationen zeigt: Abwehrbereitschaft hängt davon ab, Meldeverhalten zu messen – nicht die Inhalte individueller Eingaben zu protokollieren.

Auch beim Einsatz künstlicher Intelligenz gelten strenge technische Grenzen. Interaktive Security-Trainings über die revel8 Plattform stellen sicher, dass Kundendaten oder Simulationsaufzeichnungen niemals zum Training der zugrunde liegenden KI-Modelle verwendet werden. Sämtliche Datenverarbeitung findet ausschließlich im dedizierten Tenant des Kunden statt – die Telemetrie der Organisation bleibt damit isoliert und geschützt.

Wer sich strikt auf Interaktionsmetadaten beschränkt, erfüllt die Anforderungen der Datenminimierung und verlagert den Fokus der Organisation weg von individueller Überwachung hin zum Aufbau einer belastbaren Human Firewall.

Das Mitbestimmungsrecht des Betriebsrats: Security und Datenschutz in Einklang bringen

Wer im DACH-Raum Technologie einführt, die das Verhalten von Mitarbeitenden bewerten kann, stößt auf strenge arbeitsrechtliche Anforderungen. Nach § 87 Abs. 1 Nr. 6 des Betriebsverfassungsgesetzes (BetrVG) hat der Betriebsrat ein Mitbestimmungsrecht bei der Einführung und Verwendung technischer Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmenden zu überwachen.^[4]

§ 87 Abs. 1 Nr. 6 wird in der Regel weit ausgelegt und erfasst jede Software, die individuelle Interaktionsmetriken erhebt. Phishing-Simulationen ohne vorherige Zustimmung des Betriebsrats einzusetzen, riskiert rechtliche Unterlassungsansprüche, gestoppte Kampagnen und erhebliche Reibung im Unternehmen. Wer die Arbeitnehmervertretung früh in die Architekturplanung einbindet, macht aus einer Compliance-Hürde ein gemeinsames Security-Ziel.

In der Praxis wird der Rahmen für Simulationstools über eine verbindliche Betriebsvereinbarung formalisiert. Die deutsche arbeitsrechtliche Praxis behandelt eine solche Vereinbarung als Standardinstrument, um die Mitbestimmung bei überwachungsfähiger Software zu regeln: Sie legt die genauen Parameter der Tests, die Grenzen der Datenverarbeitung und die Schutzmechanismen für die Belegschaft fest.^[5]

• Verpflichtende Nicht-Sanktionsklausel: Ein ausdrückliches Verbot, Simulationsaufzeichnungen für Leistungsbeurteilungen, Disziplinarmaßnahmen oder Kündigungen zu verwenden.
• Standards für anonymisierte Berichte: Strukturelle Anforderungen, die eine Aggregation auf Gruppenebene vorschreiben, sodass individuelle Fehlerraten weder dem Management noch IT-Administratoren einsehbar sind.
• Transparenzprotokolle: Klare Vorabinformationen an die Belegschaft, dass Multi-Channel-Simulationen regelmäßig durchgeführt werden, um die Abwehrkräfte der Organisation zu stärken.

Eine ausdrückliche Nicht-Sanktionsklausel gibt den Mitarbeitenden die Sicherheit, dass Simulationen Lerninstrumente sind und keine Überwachungswerkzeuge – sie schützt das Vertrauen der Belegschaft und wahrt zugleich die rechtliche Wirksamkeit nach dem Arbeitsrecht.

Anonymisierte Berichte: Risiko messen ohne Überwachung

Das menschliche Risiko einer Organisation zu messen, ohne einzelne Personen zu überwachen, erfordert eine robuste strukturelle Anonymisierung. Um sowohl die Anforderungen des Managements als auch die Vorgaben des Betriebsrats zu erfüllen, müssen Security-Metriken auf kollektive Verhaltenstrends statt auf personenbezogenes Tracking setzen.

Die standardmäßige Gruppenanonymisierung in der Berichterstattung erzwingt eine strikte technische Mindestgruppengröße von fünf Mitarbeitenden. Enthält eine Organisationseinheit weniger als fünf Mitglieder, aggregiert die Reporting-Plattform die Daten automatisch in einer übergeordneten Abteilung. Kryptografische Hash-Funktionen verhindern, dass IT-Administratoren einzelne Nutzeraktionen deanonymisieren können – die Berichterstattung bleibt dadurch rein statistisch.

Enterprise-Deployments wie Alexander Bürkle zeigen beispielsweise, wie aggregierte Kennzahlen es dem Management ermöglichen, die organisatorische Resilienz wirksam zu verfolgen, ohne die Privatsphäre einzelner Personen zu gefährden. Security-Verantwortliche sollten Key Performance Indicators verfolgen, die proaktives defensives Verhalten hervorheben, statt isolierte Fehler zu sanktionieren.

Die Reporting-Quote als zentrale Security-Kennzahl zu betonen, fördert die proaktive Erkennung von Bedrohungen und etabliert eine transparente Security-Kultur, die auf Vertrauen basiert.

Nachweispflicht: Compliance gegenüber dem Auditor belegen

Wenn Aufsichtsbehörden oder externe Auditors das Security-Awareness-Programm einer Organisation prüfen, reichen mündliche Zusicherungen nicht aus. Artikel 5 Absatz 2 DSGVO macht den Verantwortlichen dafür verantwortlich, die Einhaltung der Verarbeitungsgrundsätze „nachweisen zu können“ – dem Grundsatz der Rechenschaftspflicht.^[3] In der Praxis bedeutet das: Chief Information Security Officers benötigen eine umfassende Compliance-Dokumentation, die die rechtmäßige Datenverarbeitung und strenge technische Sicherheitskontrollen belegt.

Nach Artikel 30 DSGVO sind Verantwortliche verpflichtet, ihre Datenabläufe in einem formalen Verzeichnis von Verarbeitungstätigkeiten zu dokumentieren – mit Angaben dazu, warum Daten verwendet werden, wessen Daten betroffen sind, welche Löschfristen gelten und welche übergreifenden Sicherheitsmaßnahmen bestehen.^[6] Darüber hinaus schreibt Artikel 28 vor, dass bei der Beauftragung eines externen Anbieters eine bindende Vereinbarung zur Auftragsverarbeitung abgeschlossen werden muss, die strenge technische Kontrollen durchsetzt, den Einsatz von Sub-Prozessoren steuert und umfassende Prüfungsrechte garantiert.^[7]

Souveräner Datenstandort ist ein zentrales Standbein europäischer Compliance. Die revel8-Plattform wird auf STACKIT-Infrastruktur in Deutschland gehostet, sodass sämtliche Verarbeitung ausschließlich unter europäischer Rechtsprechung stattfindet. Die verpflichtenden Vorgaben der deutschen BSI-Umsetzung von NIS2 zu Awareness-Trainings NIS2 Awareness-Trainings verlangen auditfeste Protokolle jeder Simulation und jeder Trainingsmaßnahme. Organisationen, die sich an europäischer Datensouveränität orientieren, können Infrastruktur über den STACKIT Marketplace beziehen, um Beschaffung und Compliance-Nachweis zu vereinfachen.

• Interessenabwägung (Legitimate Interest Assessment, LIA): Dokumentierter Abwägungstest, der die Rechtsgrundlage nach Artikel 6 Absatz 1 Buchstabe f DSGVO begründet.
• Verzeichnis von Verarbeitungstätigkeiten (ROPA): Formales Register nach Artikel 30 mit Verarbeitungszwecken, Datenkategorien und Löschfristen.
• Vereinbarung zur Auftragsverarbeitung nach Artikel 28: Anbietervertrag mit TOMs, Sub-Prozessor-Listen und Zusagen zu europäischem Cloud-Hosting.
• Auditfeste Simulationsprotokolle: Kryptografisch gesicherte Logs, die die Einhaltung von NIS-2, DORA und ISO 27001 nachweisen.

Wer diese Dokumentation lückenlos vorhält, kann regulatorische Audits erfolgreich bestehen und zugleich proaktives Risikomanagement belegen.

Ethische Grenzen: Welche Social-Engineering-Köder gehen zu weit?

Simulationen müssen realistische Angriffsvektoren abbilden – doch ethische Grenzen bestimmen das Szenario-Design. Manipulative oder emotional belastende Köder zerstören das Vertrauen der Belegschaft, lösen harte Reaktionen des Betriebsrats aus und gefährden die Rechtsgrundlage der Interessenabwägung (Legitimate Interest Assessment, LIA) nach der DSGVO.

Bedrohungsszenarien, die persönliche finanzielle Ängste, Kündigungen, Gehaltsänderungen oder gesundheitliche Notfälle ins Visier nehmen, überschreiten ethische Grenzen. Täuschende Köder, die auf persönliche Notlagen abzielen, verursachen bei den Mitarbeitenden psychischen Schaden und Ressentiments. Wenn Mitarbeitende das Gefühl haben, von den internen Security-Teams manipuliert worden zu sein, bricht die Reporting-Quote ein und rechtliche Auseinandersetzungen nehmen zu.

Statt emotionaler Manipulation sollten Security-Teams realistische Geschäftsszenarien einsetzen, die mit Open-Source-Intelligence-Daten (OSINT) angereichert sind – etwa Zahlungsaktualisierungen von Lieferanten, Verifizierungen von IT-Systemen oder mehrkanalige Meeting-Einladungen. Szenarien, die im beruflichen Alltag verankert sind, schaffen authentische Lernmomente, ohne ethische Standards zu verletzen.

Wer diese ethischen Grenzen respektiert, stellt sicher, dass Social-Engineering-Assessments organisatorische Gewohnheiten stärken, ohne die interne Unternehmenskultur zu beschädigen.

Ein konformes Security-Awareness-Programm im Jahr 2026 aufzubauen erfordert die Balance zwischen konsequenter Bedrohungsabwehr und strikter Einhaltung europäischer Datenschutzgesetze und betrieblicher Mitbestimmung. Wer Kampagnen auf die Interessenabwägung (Legitimate Interest Assessment, LIA) stützt, Gruppenanonymisierung standardmäßig durchsetzt und auditfeste Dokumentation pflegt, kann Human-Risk-Management in einen belastbaren strategischen Vermögenswert verwandeln. Um zu prüfen, wie Ihre Organisation auditfeste, mehrkanalige Simulationen einsetzen kann, die die strengen Anforderungen des Betriebsrats im DACH-Raum erfüllen, kontaktieren Sie unser Security-Team für einen Blick auf unsere DPA-Vorlagen und unsere Compliance-Dokumentation.

Quellen

1. edpb.europa.eu
2. Art. 6 GDPR – Lawfulness of processing - General Data Protection Regulation (GDPR), gdpr-info.eu
3. Art. 5 GDPR – Principles relating to processing of personal data - General Data Protection Regulation (GDPR), gdpr-info.eu
4. Works Constitution Act (Betriebsverfassungsgesetz, gesetze-im-internet.de
5. Digital compliance: labour law guidelines for the use of digital compliance tools, oppenhoff.eu
6. Art. 30 GDPR – Records of processing activities - General Data Protection Regulation (GDPR), gdpr-info.eu
7. Art. 28 GDPR – Processor - General Data Protection Regulation (GDPR), gdpr-info.eu