Smishing-Simulation auf BYOD-Geräten: Was rechtlich zulässig ist

Warum lösen BYOD-Smishing-Simulationen Datenschutzbedenken aus?

Bring Your Own Device (BYOD)-Richtlinien haben die Angriffsfläche europäischer Unternehmen vergrößert. Mobile Messaging-Apps und SMS umgehen klassische Netzwerk-Perimeter und Secure Email Gateways und landen direkt im ungeschützten Posteingang privater Smartphones. Threat Actors nutzen Open-Source-Intelligence (OSINT), um hochgradig zielgerichtete SMS-Phishing-Nachrichten (Smishing) zu verfassen, die interne IT-Benachrichtigungen, Authentifizierungsanfragen oder Cloud-Service-Warnungen imitieren.

Laut den Leitlinien von NIST SP 1800-22 zur Sicherheit mobiler Geräte erfordert das Management von Security-Risiken auf privaten Geräten den Ausgleich zwischen dem Zugriff auf Unternehmensressourcen und dem Schutz der Privatsphäre einzelner Nutzer.^[1] Auf privaten Smartphones fehlen den Security-Controls der IT vollständige Einblicke ins Gerät. Wenn Security-Teams die Widerstandsfähigkeit gegenüber mobilen Bedrohungen durch simulierte Smishing-Kampagnen bewerten wollen, stoßen sie sofort auf rechtliche Reibungspunkte bei der Verarbeitung personenbezogener Daten von Mitarbeitenden auf nicht unternehmenseigener Hardware.

Diese operative Reibung stellt Security-Verantwortliche vor ein Dilemma. Bevor Angriffssimulationen auf mobile Kanäle ausgeweitet werden, müssen klare rechtliche und datenschutzbezogene Grenzen zwischen privater Handynutzung und unternehmerischem Bedrohungstest gezogen sein.

DSGVO-Konformität: Brauchen Sie die Einwilligung von Mitarbeitenden oder ein berechtigtes Interesse?

Bei der Ausgestaltung mobiler Security-Simulationen nach der Datenschutz-Grundverordnung (DSGVO) ist die Wahl der richtigen Rechtsgrundlage entscheidend. Unternehmen ziehen häufig die Einwilligung von Mitarbeitenden nach Art. 6 Abs. 1 lit. a in Betracht.^[4] Europäische Datenschutzbehörden halten jedoch durchgängig fest, dass eine freiwillig erteilte Einwilligung im Beschäftigungsverhältnis wegen des strukturellen Machtgefälles zwischen Arbeitgeber und Beschäftigten praktisch unmöglich ist.^[2] Die EDPB-Leitlinien zur Einwilligung behandeln eine wirksame Einwilligung von Mitarbeitenden als Ausnahmefall, nur möglich, wenn eine Verweigerung keine nachteiligen Folgen hätte.^[3] Die deutsche Praxis ist ebenso deutlich: Das Mitbestimmungsrecht des Betriebsrats ist zwingend und lässt sich weder durch eine interne Richtlinie noch durch die Einwilligung der Mitarbeitenden umgehen – die Einwilligung erzeugt also Papierkram, ohne rechtliche Sicherheit zu schaffen. Eine vorherige Ankündigung der Kampagne beseitigt zudem die unangekündigten Bedingungen, die den Test diagnostisch wertvoll machen.

Stattdessen müssen Security-Verantwortliche mobile Attack-Simulationen auf das berechtigte Interesse nach Art. 6 Abs. 1 lit. f DSGVO stützen – die Rechtsgrundlage, die die Verarbeitung erlaubt, soweit sie zur Wahrung der berechtigten Interessen des Verantwortlichen erforderlich ist und die Rechte der Mitarbeitenden nicht überwiegen.^[5] Wer sich auf das berechtigte Interesse beruft, muss eine formale Interessenabwägung (Legitimate Interest Assessment, LIA) dokumentieren.^[3] Dieser dreistufige Test weist den Verarbeitungszweck nach, belegt die Notwendigkeit für die organisatorische Verteidigung und führt eine strenge Abwägung gegen die grundrechtlichen Datenschutzbelange der Mitarbeitenden durch.

Um einen tragfähigen Anspruch auf berechtigtes Interesse zu wahren, müssen Organisationen die Datenminimierung konsequent durchsetzen. Das Speicherbegrenzungsprinzip der DSGVO verlangt, dass personenbezogene Daten nicht länger in identifizierbarer Form gespeichert werden, als der genannte Zweck erfordert.^[3] In der Praxis heißt das: Nur Interaktionsereignisse erheben (Öffnen, Klick, Dateneingabe, Meldung) und diese nur für ein kurzes operatives Zeitfenster identifizierbar halten (üblich sind 30 bis 90 Tage), bevor sie für langfristige Trendberichte aggregiert oder anonymisiert werden. Die Ausrichtung des Simulationsprogramms an verpflichtenden Vorgaben wie NIS2-Awareness-Trainings stützt das Notwendigkeitsargument zusätzlich.

Wann ist die Zustimmung des Betriebsrats (BetrVG) erforderlich?

In Deutschland und in Regionen mit Mitbestimmungsrahmen unterliegen technische Systeme, die das Verhalten von Mitarbeitenden messen oder bewerten, einer strengen gesetzlichen Aufsicht. Nach § 87 Abs. 1 Nr. 6 Betriebsverfassungsgesetz (BetrVG) hat der Betriebsrat eine zwingende Mitbestimmung bei jeder technischen Einrichtung, die dazu bestimmt ist, das Verhalten oder die Leistung der Mitarbeitenden zu überwachen.^[6]

Da Smishing-Simulationen pro Empfänger protokollieren, wer eine Nachricht öffnet, wer auf den Link klickt, wer Zugangsdaten eingibt und wer sie meldet, gilt die zugrunde liegende Simulationsplattform als technische Überwachungseinrichtung. Die gefestigte Rechtsprechung des Bundesarbeitsgerichts fragt nur, ob ein System objektiv geeignet ist, Leistungen oder Verhalten zu überwachen – die Mitbestimmung greift also selbst dann, wenn Einzelergebnisse nie ausgewertet werden.^[4] Besteht ein Betriebsrat und wird die Simulation ohne dessen Beteiligung eingeführt, ist die Maßnahme rechtswidrig, die bereits erhobenen Daten gelten als unrechtmäßig erlangt, und der Betriebsrat kann den Rollout blockieren, bis eine Einigung erzielt ist.^[4] Der Versuch, den Betriebsrat zu umgehen, erzeugt unmittelbare rechtliche Haftungsrisiken und einen schweren Vertrauensverlust in der gesamten Organisation.

• Formale Betriebsvereinbarung: Eine verbindliche Betriebsvereinbarung, die vor dem Rollout unterzeichnet wird und Plattformumfang sowie Regeln zur Datenverarbeitung festlegt.
• Keine individuelle Überwachung: Strenge vertragliche Verbote, Simulation-Klickraten für individuelle Leistungsbeurteilungen oder Disziplinarmaßnahmen zu verwenden.
• Gruppenbasierte Berichte: Aggregation der Kennzahlen, damit individuelle Reaktionen gegenüber Management und IT-Administratoren vollständig anonym bleiben.
• Technische Transparenz: Vollständige technische Dokumentation für die Arbeitnehmervertretung zu Datenflüssen, Speicherorten und Sub-Dienstleistern.

Wer den Betriebsrat früh in die Planung einbindet, schafft geteilte Verantwortung für die Cyber-Resilienz der Organisation und stellt zugleich die vollständige Einhaltung von § 87 Abs. 1 Nr. 6 BetrVG sicher.

Was macht eine Smishing-Betriebsvereinbarung ethisch?

Eine belastbare Betriebsvereinbarung legt die operativen Rahmenbedingungen für mobile Security-Tests fest und zieht zugleich ethische Grenzen ein, die die teilnehmenden Mitarbeitenden schützen. Grundvoraussetzung ist eine strikte Zweckbindung: Simulationskennzahlen dürfen ausschließlich dem Zweck dienen, das organisatorische Risiko zu bewerten und gezieltes Microtraining im Arbeitsfluss auszulösen – niemals der Disziplinierung von Mitarbeitenden. Die deutsche Praxisorientierung ist eindeutig: Ergebnisse dienen dem Security-Awareness-Ziel, nicht der Leistungs- oder Verhaltenskontrolle, und aus einem einzelnen Klick dürfen keine arbeitsrechtlichen Konsequenzen folgen.^[4]

Ethische Leitplanken sind ebenso entscheidend bei der Auswahl der Köder. Die britische NCSC warnt, dass Phishing-Simulationen das Vertrauen zwischen Mitarbeitenden und Security untergraben – und weil niemand jede Phishing-Nachricht erkennt, beginnt die Bestrafung von Klicks auf selbst versendete E-Mails, einer Locksituation zu ähneln.^[7] Deshalb rät die Behörde Organisationen, vor jeder Simulation stets die Personalabteilung einzubinden. Köder, die auf sensiblen Finanz- oder Personalthemen aufbauen, verschärfen diesen Schaden zusätzlich. Solche täuschenden Köder untergraben die Interessenabwägung des berechtigten Interesses nach Art. 6 Abs. 1 lit. f DSGVO und bergen das Risiko unmittelbarer Arbeitskonflikte.

• Verbotene HR-Köder: Szenarien mit Verweisen auf fingierte Boni, Gehaltsanpassungen, Kündigungen oder Leistungsbeurteilungen.
• Verbotene persönliche Themen: Köder mit Themen wie familiären Notfällen, medizinischen Mitteilungen oder rechtlichen Schritten.
• Genehmigte Szenario-Themen: Simulationen, die auf routinemäßigen IT-Benachrichtigungen, gängigen Software-Updates oder üblichen Vendor-Kommunikationen basieren.
• Sofortige Lernmomente: Unmittelbarer Übergang von einer Simulationsinteraktion zu nicht-sanktionierendem, educativem Feedback.

Die formale Verankerung dieser ethischen Grenzen in der Betriebsvereinbarung wahrt die Würde der Mitarbeitenden und sichert zugleich die rechtliche Wirksamkeit mobiler Threat-Tests.

Wie sollten BYOD-Richtlinien für mobile Tests aktualisiert werden?

Artikel 13 DSGVO verpflichtet Verantwortliche, bei Erhebung personenbezogener Daten die Betroffenen über die Zwecke der Verarbeitung und deren Rechtsgrundlage zu informieren – und bei einer Grundlage nach Artikel 6 Absatz 1 Buchstabe f über das verfolgte berechtigte Interesse.^[8] Organisationen müssen mobile Security-Tests daher ausdrücklich in offizielle BYOD-Richtlinien integrieren. Mitarbeitende, die private Geräte für Arbeitsaufgaben nutzen, müssen darüber informiert sein, dass Multi-Channel-Threat-Simulationen Teil des Security-Frameworks des Unternehmens sind. Dieser Hinweis muss klarstellen, dass sich die Tests über SMS, Voice Phishing und mobile Messenger-Kanäle erstrecken.

Die deutsche Praxisorientierung versteht Transparenz so, dass die Belegschaft vorab, in verständlicher Sprache, über Zweck, Ablauf und Auswertung der Simulationen informiert wird.^[4] Diese Pflicht ist durch einen vorherigen Hinweis erfüllt – nicht durch die Veröffentlichung von Kampagnenplänen oder Nachrichten-Vorlagen, die die authentischen Testbedingungen untergraben würden. Die BYOD-Richtliniendokumentation muss daher darlegen, welche Interaktionsdaten erhoben werden und wie persönliche Inhalte auf dem Gerät unangetastet bleiben.

1. Vektor-Umfang definieren: Formell dokumentieren, dass Security-Tests die Vektoren E-Mail, SMS, Voice und Messenger umfassen.
2. Datengrenzen festlegen: Detailliert beschreiben, dass ausschließlich Interaktionsereignisse und Zeitstempel verarbeitet werden – niemals private Textnachrichten oder private Apps.
3. Datenschutzrechte darlegen: Mitarbeitende über ihre Rechte nach der DSGVO informieren und die Kontaktstelle für Datenschutzanfragen benennen.
4. Educative Ziele benennen: Betonen, dass mobile Tests darauf abzielen, Gewohnheiten in der Belegschaft zu stärken – nicht Einzelpersonen zu überwachen.

Klare BYOD-Richtlinien beseitigen Mehrdeutigkeiten und geben Mitarbeitenden volle Klarheit darüber, wie private Geräte während unternehmensweiter Threat-Tests geschützt bleiben.

Wie kann souveräne Infrastruktur sichere Smishing-Simulationen gewährleisten?

Rechtlich konforme Smishing-Simulationen auf BYOD-Geräten erfordern Datenschutz-Schutzmechanismen, die direkt in die Plattformarchitektur eingebettet sind. Die Awareness Playlist automatisiert kontinuierliche Multi-Channel-Attack-Simulationen über SMS, E-Mail, Voice und Messenger und verbindet realen Open-Source-Intelligence (OSINT)-Kontext mit strikten technischen Datenschutzmaßnahmen.

Der Datenschutz wird nativ über die gruppenbasierte Anonymisierung der Berichte durchgesetzt: Eine Mindestgruppengröße von fünf Empfängern macht individuelles Verhaltenstracking unmöglich. Die deutsche Betriebsratspraxis erwartet genau dieses Muster: Klickraten ausschließlich aggregiert, je Abteilung, Szenario oder Zeitraum – niemals namentlich.^[4] Diese Aggregation direkt in der Plattform erspart die manuelle Datenbearbeitung nach jeder Kampagne. Alle Kundendaten verbleiben im Kundentenant und werden niemals zum Training der zugrundeliegenden KI-Modelle verwendet.

Um souveräne Datenkonformität zu garantieren, läuft die gesamte Simulationsinfrastruktur auf europäischer Cloud-Infrastruktur über STACKIT in Deutschland STACKIT Marketplace. Diese Infrastruktur stellt die Einhaltung von DSGVO, NIS-2, DORA und ISO 27001 sicher und garantiert lokale Datenresidenz.

Quellen

1. The NIST NCCoE Publishes Guidance to Address Mobile Device Security Concerns with BYOD, nist.gov
2. Consent - General Data Protection Regulation (GDPR), gdpr-info.eu
3. autophish.io
4. fraghugo.de
5. Art. 6 GDPR – Lawfulness of processing - General Data Protection Regulation (GDPR), gdpr-info.eu
6. luther-lawfirm.com
7. Phishing attacks: defending your organisation, ncsc.gov.uk
8. gdpr-info.eu