GDPR Phishing Simulations: What You May and May Not Store

What is the legal basis for phishing simulations under GDPR?

According to the 2026 Verizon Data Breach Investigations Report, the human element remains involved in 62% of corporate data breaches. To mitigate this exposure, security leaders must regularly test employee readiness against social engineering techniques, including real-world OSINT patterns. However, Chief Information Security Officers (CISOs) and Data Protection Officers (DPOs) frequently grapple with a fundamental regulatory question: what is the lawful basis for sending simulated attack scenarios to employees under the General Data Protection Regulation (GDPR)?

Organizations often assume that obtaining explicit employee consent under Article 6(1)(a) GDPR is the safest route. In practice, relying on consent for security simulations is legal framework failure. Under European data protection principles, consent given within an employer-employee relationship is rarely considered freely given due to the inherent hierarchical imbalance. Furthermore, asking employees to opt in to threat testing destroys simulation realism, as prior notice invalidates the exercise.

The European Data Protection Board (EDPB) in Guidelines 1/2024 supports that data controllers may rely on Article 6(1)(f) GDPR: Legitimate Interest. Protecting corporate networks, securing intellectual property, and ensuring operational resilience against cyber threats constitute legitimate business interests that justify processing personal data during simulated exercises.

• Explicit consent fails the freely given threshold in employment contexts due to structural power imbalances.
• Prior opt-in requirements alert employees in advance, invalidating the diagnostic value of threat simulations.
• Legitimate Interest under Article 6(1)(f) GDPR provides the lawful foundation for proactive defensive security testing.

How do you perform a Legitimate Interests Assessment (LIA)?

Relying on Article 6(1)(f) GDPR is not a self-executing exemption. The EDPB states that for processing to be based on Article 6(1)(f) GDPR, three cumulative conditions must be fulfilled, and that identifying a legitimate interest is not in itself sufficient to rely on that legal basis. In practice this means executing and documenting a formal Legitimate Interests Assessment (LIA) before launching any simulation program, so that processing activities remain strictly necessary and balanced against worker privacy rights.

The assessment is structured as a three-part test that must be documented within the LIA: the purpose test, the necessity test, and the balancing test. The EDPB applies the same sequence, treating the pursuit of a legitimate interest, the necessity analysis, and the balancing exercise as three cumulative steps. Security operations must establish that defensive testing serves a genuine security purpose, that simulated exercises are necessary because passive instruction alone cannot build muscle memory, and that the impact on employee rights is minimized through technical safeguards.

Maintaining a written LIA is mandatory under the accountability principle of Article 5(2) GDPR. If a security incident prompts regulatory scrutiny or triggers a 72-hour breach notification window, supervisory authorities will examine the LIA to verify that employee data processing during simulations was proportionate and lawful.

What employee data may you legally store?

The principle of data minimization under Article 5(1)(c) GDPR requires that personal data collected for simulations must be adequate, relevant, and limited to what is strictly necessary. CISOs must ensure that training systems store only core directory attributes essential for campaign routing and organizational risk mapping.

Permissible employee data attributes typically fall into basic corporate identification categories. Storing excessive attributes, such as personal mobile numbers, private email addresses, or non-work locations, violates minimization requirements unless explicitly required for specific multi-channel test scenarios with prior authorization.

• Permitted storage: First name, last name, business email address, corporate job title, and broad department or user group.
• Optional temporary attributes: Work-issued mobile number (for SMS or vishing scenarios) and business unit location, stored strictly during active campaign cycles.
• Prohibited excessive data: Personal phone numbers, private home addresses, financial details, or non-work identity data.

For DACH and European enterprises, sovereign data residency is a core regulatory constraint. Personal data processed during simulations must reside on European cloud infrastructure, such as STACKIT hosted in Germany, ensuring full GDPR compliance and alignment with sovereign European data protection standards STACKIT marketplace.

What data storage practices are strictly prohibited?

While storing basic profile attributes for campaign delivery is permissible under a valid LIA, several data storage practices violate European data protection law. Article 5(1)(b) GDPR states that personal data must be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes, so data gathered for security testing must never be repurposed for secondary tracking or automated employee evaluations.

Organizations are strictly prohibited from utilizing customer or employee interaction data to train public or commercial AI models. AI systems integrated into security platforms must process data exclusively within the enterprise tenant, ensuring zero data retention for external model training. Furthermore, conducting automated behavioral profiling or sentiment analysis on workers via simulation interaction metrics violates GDPR restrictions.

• AI model training prohibition: Enterprise data and simulation results must never be ingested to train external AI models.
• No behavioral profiling: Systems must not generate individual psychological profiles or automated performance scoring used for employment decisions.
• Ethical scenario boundaries: Deceptive lures involving sensitive personal triggers, such as fake salary bonuses or termination notices, are prohibited to maintain trust and legal integrity.

Data warehousing beyond active campaign requirements is similarly forbidden. Logs containing raw interaction details must be automatically pruned or converted into irreversibly aggregated statistics once reporting retention windows close.

How does the works council (Betriebsrat) impact simulations?

Deploying security simulations in Germany requires addressing statutory worker representation early in the process. Alongside Section 26 of the German Federal Data Protection Act (BDSG), Section 87(1) No. 6 of the Works Constitution Act (BetrVG) gives the works council (Betriebsrat) a co-determination right over the introduction and use of technical devices designed to monitor the conduct or performance of employees.

To obtain works council approval without operational delays, platforms must incorporate technical privacy safeguards by default. Reporting dashboards typically anonymize performance data at the group level, where a minimum group size of 5 is a widely adopted practice for satisfying works council anonymization expectations. Cryptographic hashing functions prevent IT administrators, HR managers, or department heads from identifying specific individuals who clicked simulated links.

1. Engage the Betriebsrat during initial scoping to review the technical architecture and data minimization safeguards.
2. Draft a formal works council agreement (Betriebsvereinbarung) defining campaign parameters and prohibiting disciplinary actions based on simulation results.
3. Configure mandatory group-level reporting anonymization with a minimum group size of 5 employees.
4. Establish clear process flows showing that reporting focuses on systemic risk reduction rather than individual performance monitoring Alexander Bürkle.

By implementing group-level anonymization by default, security teams satisfy co-determination requirements while preserving the executive visibility needed to measure organizational threat reporting rates.

What is the GDPR compliance checklist for phishing simulations?

Maintaining a legally clean security awareness program requires continuous coordination between security operations, privacy officers, and employee representatives. Following a systematic checklist ensures that defensive simulations meet European legal standards at every stage.

To maintain compliance while building resilient defenses across email, SMS, and deepfake vishing, organizations utilize platforms engineered specifically for European regulatory standards. The revel8 Platform automates these privacy guardrails, combining OSINT-driven simulations with default group-level anonymization and German cloud infrastructure to meet NIS-2 and ISO 27001 requirements out of the box. Audit your current LIA documentation today and verify that your simulation parameters adhere strictly to European data minimization rules.