Wie bekomme ich den Betriebsrat zur Zustimmung für eine Phishing-Simulation?

Das wichtigste zuerst: So kommen Sie zur Zustimmung

Die Zustimmung des Betriebsrats wird nicht durch Überredung wahrscheinlicher, sondern durch ein sauberes Programmdesign. Legen Sie vor dem Start offen, welches Sicherheitsziel die Phishing-Simulation verfolgt, welche Daten wirklich verarbeitet werden, wer Ergebnisse sehen darf, wie lange Informationen gespeichert werden und dass die Maßnahme nicht für Leistungs- oder Verhaltenskontrolle genutzt wird. Wenn Betriebsrat, Datenschutz, HR, Legal und Security diese Grenzen früh gemeinsam festlegen, wird aus einer potenziell heiklen Kampagne ein zustimmungsfähiges Lernprogramm.

Dieser Artikel ist keine Rechtsberatung. In Deutschland und anderen DACH-Umgebungen können Mitbestimmung, Datenschutz, Arbeitsrecht und interne Betriebsvereinbarungen relevant sein. Security, Datenschutz, HR, Legal und Betriebsrat sollten deshalb gemeinsam prüfen, wie die konkrete Simulation ausgestaltet wird. Genau darum geht es: nicht darum, den Betriebsrat zu überreden, sondern eine Maßnahme so sauber vorzubereiten, dass sie zustimmungsfähig wird.

Warum die Frage falsch gestellt wird, wenn sie nur nach Zustimmung sucht

Diese Betriebsratsfrage klingt zunächst nach einer Hürde im Projektplan. In der Praxis ist der Betriebsrat aber kein nachträglicher Freigabestempel. Er vertritt berechtigte Interessen: Schutz vor Leistungs- und Verhaltenskontrolle, faire Behandlung von Mitarbeitenden, transparente Datenverarbeitung und klare Grenzen für technische Systeme.

Ein gutes Security-Team nimmt diese Punkte nicht als Störung wahr. Es nutzt sie als Qualitätskriterien. Denn eine Phishing-Simulation, die intern als Überwachung erlebt wird, verliert genau das, was sie verbessern soll: Aufmerksamkeit, Meldebereitschaft und Vertrauen. Mitarbeitende melden verdächtige E-Mails eher, wenn sie wissen, dass das Programm ihnen hilft und sie nicht öffentlich vorführt.

Die beste Vorbereitung ist deshalb kein juristischer Umweg, sondern ein glaubwürdiges Programm-Design:

• klare Lernziele statt Schuldzuweisung
• minimale personenbezogene Daten statt maximaler Detailauswertung
• aggregierte Reports statt Ranglisten
• begrenzte Aufbewahrung statt dauerhafter Personenhistorie
• transparente Kommunikation statt Überraschungsangriff
• Review mit Betriebsrat und Datenschutz statt einseitigem Rollout

Wenn diese Punkte belastbar dokumentiert sind, wird die Abstimmung deutlich einfacher.

Die Kurzantwort für IT- und Security-Teams

Sie bekommen den Betriebsrat eher zur Zustimmung, wenn Sie vor der ersten Kampagne zeigen können:

1. Die Simulation dient einem legitimen Sicherheits- und Lernziel.
2. Sie ist verhältnismäßig und auf einen klaren Umfang begrenzt.
3. Es werden nur Daten verarbeitet, die für dieses Ziel wirklich nötig sind.
4. Personenbezogene Auswertungen werden vermieden oder eng begrenzt.
5. Ergebnisse werden nicht für Abmahnungen, Disziplinarmaßnahmen oder individuelle Leistungsbewertung genutzt.
6. Mitarbeitende erhalten transparente Informationen und sinnvolle Lernunterstützung.
7. Aufbewahrung, Löschung und Zugriffsrechte sind vorab geregelt.
8. Nach dem Pilot gibt es eine gemeinsame Auswertung und Anpassung.

Das klingt weniger spektakulär als „Awareness-Kampagne starten“, ist aber der Unterschied zwischen einem politischen Konflikt und einem tragfähigen Sicherheitsprogramm.

Früh einbinden, bevor das Tool schon ausgewählt ist

Viele Abstimmungen scheitern, weil der Betriebsrat erst dann eingebunden wird, wenn Tool, Anbieter, Kampagnenplan und Reportingmodell faktisch schon feststehen. Dann wirkt die Beteiligung wie Formalität. Schlechter Start.

Besser ist ein zweistufiger Ansatz. Zuerst wird das Programmdesign abgestimmt: Zweck, Grenzen, Daten, Auswertungen, Kommunikation und Pilot. Erst danach wird die konkrete Plattform final bewertet. So kann der Betriebsrat nachvollziehen, welche Anforderungen das Tool erfüllen muss. Datenschutz und Legal können dieselben Kriterien nutzen.

Besonders früh sollte der Betriebsrat eingebunden werden, wenn eine oder mehrere dieser Fragen mit „ja“ beantwortet werden:

• Werden einzelne Beschäftigte in der Simulation erfasst?
• Gibt es Reports zu Klicks, Meldungen, Formularinteraktionen oder Trainingsstatus?
• Werden Ergebnisse an Führungskräfte, HR oder andere Stellen weitergegeben?
• Wird die Simulation regelmäßig wiederholt?
• Wird ein externer Cloud-Dienstleister eingesetzt?
• Gibt es Folgeprozesse wie Nachschulung, Reminder oder Eskalationen?
• Können technische Daten indirekt Rückschlüsse auf einzelne Personen erlauben?

Wenn Sie diese Punkte offen auf den Tisch legen, nimmt das Spannung aus der Diskussion. Verstecken erzeugt Misstrauen. Präzision erzeugt Verhandlungsfähigkeit.

Das Zustimmungspaket: Was vorbereitet sein sollte

Ein gutes Zustimmungspaket muss nicht hundert Seiten lang sein. Es muss die richtigen Fragen konkret beantworten. Die folgenden Bausteine reichen oft als belastbare Arbeitsgrundlage für Security, Datenschutz, HR, Legal und Betriebsrat.

1. Zweck und Nutzen

Beschreiben Sie den Zweck der Maßnahme in einem Satz:

Die Phishing-Simulation soll Mitarbeitende für reale Angriffsversuche sensibilisieren, sichere Meldewege trainieren und die Sicherheitskultur verbessern.

Diese Formulierung ist wichtig. Sie macht klar, dass es nicht darum geht, Fehlverhalten zu sammeln. Gute Programme messen nicht, wer „versagt“, sondern ob die Organisation Phishing schneller erkennt, meldet und verarbeitet.

Vermeiden Sie Formulierungen wie „Risikopersonen identifizieren“ oder „Fehlverhalten sichtbar machen“. Solche Ziele klingen nach Kontrolle. Besser sind Ziele wie „Meldequote erhöhen“, „Reaktionsfähigkeit verbessern“, „Training gezielter aussteuern“ oder „Sicherheitsprozesse testen“.

2. Umfang der Simulation

Der Betriebsrat sollte wissen, was genau passieren soll. Dokumentieren Sie:

• welche Standorte, Länder, Gesellschaften oder Abteilungen teilnehmen
• ob alle Mitarbeitenden oder nur Pilotgruppen einbezogen werden
• in welchem Zeitraum die Kampagne läuft
• wie oft Simulationen geplant sind
• welche Kanäle genutzt werden, zum Beispiel E-Mail, SMS oder QR-Code
• welche Szenarien ausgeschlossen sind
• ob besonders sensible Rollen oder Ausnahmesituationen berücksichtigt werden

Ein Pilot ist oft leichter zustimmungsfähig als ein sofortiger Vollrollout. Er begrenzt Risiko, Aufwand und Unsicherheit. Nach dem Pilot können Betriebsrat und Datenschutz prüfen, ob die vereinbarten Regeln funktionieren.

3. Datenkategorien

Datenminimierung ist der Kern. Listen Sie sauber auf, welche Daten verarbeitet werden und wofür sie benötigt werden. Typische Kategorien können sein:

• geschäftliche E-Mail-Adresse oder Nutzerkennung
• Organisationseinheit oder Kampagnengruppe
• Versand- und Zustellstatus
• Öffnung, Klick oder Formularinteraktion
• Meldung über den vorgesehenen Meldekanal
• Abschluss einer Lernsequenz
• technische Protokolldaten zur Fehleranalyse

Danach kommt die entscheidende Frage: Welche dieser Daten müssen personenbezogen sichtbar sein? Für viele Steuerungszwecke reichen aggregierte Trends, Gruppenmetriken und anonymisierte Auswertungen. Das Security-Team muss wissen, ob Meldungen steigen und riskante Muster zurückgehen. Es muss nicht zwangsläufig jede Person dauerhaft in einer Historie sehen.

4. Reporting und Zugriff

Reporting ist meistens der empfindlichste Punkt. Definieren Sie vorab, wer welche Auswertung sehen darf.

Ein privacy-freundliches Modell kann so aussehen:

• Security-Team: operative Kampagnenmetriken, technische Zustellinformationen und aggregierte Lernsignale
• Management: Trends, Programmentwicklung, Risikobereiche und Verbesserungen
• Führungskräfte: keine personenbezogenen Ranglisten
• HR: keine Nutzung für Disziplinarmaßnahmen
• Betriebsrat und Datenschutz: vereinbarte Kontroll- oder Review-Informationen

Vermeiden Sie Bestenlisten, Negativlisten, Abteilungspranger und dauerhafte personenbezogene Vergleichswerte. Solche Mechaniken beschädigen Vertrauen und liefern selten bessere Sicherheit. Ein Team, das Angst vor Bloßstellung hat, meldet weniger und lernt langsamer.

Wenn personenbezogene Auswertungen in Einzelfällen nötig sind, sollten Zweck, Zugriff, Frist und Löschung eng begrenzt sein. Es sollte klar sein, wer Detaildaten sehen darf und wer nicht.

AutoPhish kann dabei helfen, weil die AutoPhish-Anonymisierung E-Mail-Adressen in Kampagnen und Reports maskieren kann, während aggregierte Kennzahlen erhalten bleiben. Das ist kein Ersatz für eine interne Prüfung, aber ein konkreter technischer Baustein für datensparsame Programme.

5. Kommunikation an Mitarbeitende

Eine Phishing-Simulation muss nicht jedes konkrete Szenario vorher ankündigen. Aber das Programm selbst sollte transparent sein. Mitarbeitende sollten verstehen:

• warum Phishing-Simulationen eingesetzt werden
• welche Meldewege genutzt werden sollen
• was nach einem Klick oder einer Meldung passiert
• ob und welche Daten ausgewertet werden
• dass Ergebnisse nicht zur Bloßstellung genutzt werden
• wo sie Rückfragen stellen können

Die Tonalität entscheidet mit. „Wir testen euch“ erzeugt Abwehr. „Wir trainieren gemeinsam realistische Situationen“ ist näher am Ziel. Gute Kommunikation macht die Simulation nicht schwächer, sondern wirksamer. Reale Angriffe verschwinden nicht, nur weil Mitarbeitende wissen, dass es Awareness-Übungen gibt.

6. Aufbewahrung und Löschung

Legen Sie Fristen fest, bevor die erste Kampagne läuft. Das ist wesentlich glaubwürdiger, als Löschung später „irgendwann“ zu versprechen.

Ein mögliches Modell:

• Rohdaten nur so lange wie für Kampagnenauswertung, Support und Fehleranalyse nötig
• personenbezogene Detaildaten mit kurzer, begründeter Aufbewahrung
• aggregierte Reports länger, wenn sie für Sicherheitssteuerung, Audit oder Programmverbesserung gebraucht werden
• dokumentierter Lösch- oder Anonymisierungszeitpunkt
• klare Verantwortlichkeit für Umsetzung und Kontrolle

Die konkrete Frist hängt von internen Anforderungen ab. Wichtig ist, dass sie nicht aus Bequemlichkeit unendlich wird.

7. Rollen und Verantwortlichkeiten

Benennen Sie die Rollen, damit im Betrieb keine Grauzonen entstehen:

• fachlicher Owner für Security Awareness
• Datenschutzansprechperson
• Betriebsratskontakt
• technischer Administrator
• Ansprechpartner für Rückfragen von Mitarbeitenden
• externer Dienstleister, falls eingesetzt
• Verantwortliche für Review und Löschung

Gerade bei externen Plattformen sollte außerdem klar sein, welche Vertrags- und Datenschutzdokumente benötigt werden: Auftragsverarbeitung, technische und organisatorische Maßnahmen, Speicherorte, Subdienstleister und Supportzugriffe.

8. Technische und organisatorische Schutzmaßnahmen

Der Betriebsrat muss nicht jedes technische Detail prüfen. Aber das Zustimmungspaket sollte zeigen, dass Schutzmaßnahmen ernst genommen werden:

• rollenbasierte Zugriffsrechte
• begrenzte Admin-Zugänge
• Protokollierung administrativer Zugriffe
• sichere Übertragung und Verarbeitung
• Mandanten- und Kundentrennung beim Dienstleister
• definierte Löschprozesse
• datensparsame Standardkonfiguration
• Review der Vorlagen und Szenarien vor dem Start

Diese Punkte helfen auch dem Datenschutz und der Informationssicherheit. Ein sauberer Rollout ist nicht nur politisch besser, sondern operativ stabiler.

Was faire Szenarien ausmacht

Ein häufiger Konfliktpunkt ist die Frage, wie realistisch eine Simulation sein darf. Die Antwort ist: realistisch genug, um nützlich zu sein, aber fair genug, um nicht als Falle wahrgenommen zu werden.

Problematisch sind Szenarien, die private Ängste, Gesundheitsinformationen, persönliche Krisen, Kündigungsdrohungen oder unangemessenen Druck ausnutzen. Sie können zwar Klicks erzeugen, beschädigen aber Vertrauen. Für ein Betriebsratsgespräch sind solche Vorlagen schwer zu verteidigen.

Besser sind geschäftsnahe Szenarien:

• Paket- oder Lieferhinweise im Unternehmenskontext
• Rechnung, Freigabe oder Dokumentenlink
• Passwort- oder MFA-Hinweis ohne echte Zugangsdatenabfrage
• interne Termin- oder Richtlinienkommunikation
• QR-Code- oder Datei-Themen, wenn diese im Unternehmen realistisch vorkommen

Wichtig ist auch die Nachreaktion. Nach einem Klick sollte kein hämischer „Erwischt“-Moment kommen, sondern eine kurze, klare Lernsequenz: Was war auffällig? Wie wäre die richtige Meldung gelaufen? Welche Signale lassen sich beim nächsten Mal prüfen?

Eine gute Agenda für die Freigaberunde

Für die Abstimmung mit dem Betriebsrat hilft eine konkrete Agenda. Sie zeigt, dass die wichtigsten Fragen nicht improvisiert werden.

Nutzen Sie zum Beispiel diese Reihenfolge:

1. Sicherheitsziel und Anlass der Simulation
2. geplanter Pilotumfang
3. Datenkategorien und Datenminimierung
4. Reportingmodell und Zugriffskreise
5. Ausschluss von Leistungs- und Disziplinarnutzung
6. Kommunikation an Mitarbeitende
7. Aufbewahrung, Löschung und Review
8. technische und organisatorische Schutzmaßnahmen
9. Kriterien für Fortsetzung oder Anpassung nach dem Pilot

Bringen Sie nicht nur Folien mit, sondern konkrete Entscheidungen. Der Betriebsrat sollte nicht raten müssen, was später im Tool passiert.

Formulierungsvorschlag für die Betriebsratsabstimmung

Eine knappe Arbeitsformulierung kann so aussehen:

Die Phishing-Simulation wird als präventive Lern- und Schutzmaßnahme durchgeführt. Ziel ist die Verbesserung von Erkennung, Meldung und sicherem Verhalten bei realistischen Phishing-Versuchen. Die Maßnahme dient nicht der individuellen Leistungs- oder Verhaltenskontrolle. Personenbezogene Detaildaten werden vermieden oder eng begrenzt, nicht für Disziplinarmaßnahmen genutzt und nach definierter Frist gelöscht oder anonymisiert. Auswertungen für Management und Programmsteuerung erfolgen grundsätzlich aggregiert.

Das ersetzt keine Betriebsvereinbarung. Aber es hilft, den richtigen Rahmen zu setzen.

Wann ein Pilot sinnvoll ist

Ein Pilot ist besonders sinnvoll, wenn das Unternehmen zum ersten Mal Phishing-Simulationen einführt oder wenn Datenschutz und Betriebsrat noch keine Erfahrung mit dem Programm haben.

Ein guter Pilot ist begrenzt:

• kleine oder mittlere Teilnehmergruppe
• einfache, faire Szenarien
• klarer Zeitraum
• vorab abgestimmte Reports
• kurze Aufbewahrungsfrist
• gemeinsame Auswertung nach Abschluss

Nach dem Pilot können Sie zeigen, was wirklich passiert ist: Welche Daten wurden sichtbar? Welche Reports wurden erzeugt? Wie reagierten Mitarbeitende? Gab es Beschwerden? Wurden Meldewege besser genutzt? Diese Evidenz ist stärker als abstrakte Versprechen.

Was AutoPhish konkret unterstützen kann

AutoPhish ist für defensive Phishing-Simulationen, Follow-up-Training und verwertbares Reporting gebaut. Für Betriebsrats- und Datenschutzfragen sind vor allem diese Punkte relevant:

• Kampagnenplanung mit kontrollierbarem Umfang
• Auswertung von Meldungen, Klicks und Lernfortschritt
• anonymisierte Reports, wenn der anonyme Modus aktiviert ist
• klare Management- und Security-Kennzahlen ohne Prangerlogik
• Unterstützung für wiederkehrende Awareness-Programme
• praktikable Dokumentation für Security-, Compliance- und Audit-Kontexte

Wenn Sie bereits den Datenschutz- und Betriebsratsrahmen vorbereiten, ist auch der ergänzende Artikel zu datenschutzfreundlichem Phishing-Training, Betriebsrat und DSGVO sinnvoll. Er geht stärker auf das Grundmodell von Vertrauen, Mitbestimmung und datensparsamem Training ein.

Häufige Fragen

Braucht jede Phishing-Simulation eine Zustimmung des Betriebsrats?

Das hängt von der konkreten Ausgestaltung, den eingesetzten Systemen und den internen Vereinbarungen ab. Sobald Verhalten oder Leistung von Beschäftigten technisch erfasst oder auswertbar wird, sollte der Betriebsrat früh eingebunden werden. Die konkrete rechtliche Bewertung sollte intern oder extern juristisch geprüft werden.

Sollte die Simulation vorher angekündigt werden?

Viele Organisationen informieren allgemein über das Awareness-Programm, ohne jeden einzelnen Testtermin oder jedes Szenario vorher offenzulegen. Wichtig ist, dass Zweck, Meldewege, Datenverarbeitung und Umgang mit Ergebnissen transparent geregelt sind.

Sind personenbezogene Reports notwendig?

Nicht immer. Für Programmsteuerung, Managementberichte und Sicherheitsverbesserung reichen oft aggregierte Kennzahlen, Trends und anonymisierte Auswertungen. Wenn personenbezogene Details genutzt werden, sollten Zweck, Zugriff, Frist und Löschung klar begrenzt sein.

Darf ein Klick zu einer Pflichtschulung führen?

Das kann sinnvoll sein, muss aber sauber geregelt werden. Eine kurze Lernsequenz direkt nach einer Interaktion ist etwas anderes als eine sanktionierende Nachverfolgung. Entscheidend sind Ton, Zweck, Datenverarbeitung und die Frage, ob daraus individuelle Nachteile entstehen können.

Was ist das beste Ergebnis der Abstimmung?

Das beste Ergebnis ist nicht nur ein „Ja“. Es ist eine klare, dokumentierte Vereinbarung: Lernziel, Umfang, Datenschutz, Reporting, Kommunikation, Aufbewahrung und Review sind geregelt, bevor die erste Kampagne startet.

Fazit

Die Antwort lautet: durch ein Programm, das Zustimmung verdient. Nicht durch Druck, nicht durch vage Sicherheitsargumente und nicht durch nachträgliche Transparenz.

Wenn Sie Zweck, Daten, Reporting, Kommunikation und Löschung sauber vorbereiten, wird aus einer potenziellen Konfliktfläche ein gemeinsames Sicherheitsprojekt. Genau so sollten Phishing-Simulationen funktionieren: realistisch genug, um Verhalten zu trainieren, und fair genug, um Vertrauen zu stärken.

Wenn Sie ein datensparsames Phishing-Simulationsprogramm mit kontrollierbarem Reporting aufbauen möchten, können Sie AutoPhish testen.