How Long to Keep Simulation Data: A Retention Schedule

Why is a retention schedule for simulation data necessary?

A phishing or vishing simulation produces two kinds of records at once, and they pull in opposite directions. The click event, the credential entry on a simulated landing page, the transcript of a voice drill: each of these is personal data about a named employee, and each is exactly the kind of record a data protection officer wants gone as soon as its learning purpose is served. At the same time, the aggregated numbers behind those events are the only proof that your awareness program exists at all, and auditors under NIS-2 and ISO 27001 want that proof to reach back years, not weeks.

Most organizations resolve this tension ad hoc, which is the worst of both options. Raw event data lingers in the simulation platform long after the micro-training moment has passed, while the aggregated trend lines an auditor would actually accept are never exported anywhere durable. When the works council asks what is stored and for how long, or when the auditor asks for three years of training evidence, nobody can point to a document that answers both.

An itemized retention schedule resolves the conflict by splitting the data into classes with different clocks. Individual-level event data lives only as long as it serves the employee in front of it. Aggregated, anonymized evidence lives as long as the audit cycle demands. Written down class by class, the same schedule satisfies the DPO, the works council, and the auditor, and it becomes a paste-ready annex to your DPIA and your data processing agreement.

• Data protection officers need documented, justified retention periods for every category of personal data, not open-ended storage.
• Auditors and regulators need multi-year proof that training happened and that it worked.
• An itemized schedule by data class satisfies both at once, because the short clock applies to personal data and the long clock applies to anonymized aggregates.

What does simulation data retention GDPR require?

Article 5(1)(e) GDPR, the storage limitation principle, states that personal data must be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which it is processed. The regulation deliberately sets no fixed numbers. It requires you to define the purpose, justify a period for each data category, document it, and stick to it.

The UK ICO's guidance on the storage limitation principle makes the practical requirements concrete: you need a policy setting standard retention periods wherever possible, you must be able to justify each period against your stated purposes, and you should periodically review what you hold and erase or anonymize it when the need ends. The ICO also draws the key distinction for simulation data: if you no longer need to identify individuals, you should anonymize rather than keep identifiable records, and pseudonymized data, such as key-coded click events, still permits identification and therefore remains personal data.

Applied to awareness programs, this means every simulation artifact tied to a named person is personal data: the fact that Max in accounting clicked a specific lure, the voice recording of a vishing drill, the timestamp of a reported email. Recital 26 defines the exit: once data has been rendered anonymous such that the data subject is no longer identifiable, taking into account all means reasonably likely to be used, the GDPR no longer applies to it at all.^[1] Anonymization is therefore not just one disposal option among several. It is the mechanism that lets useful trend data outlive the personal data it was computed from.

• Simulation events tied to an individual are personal data under GDPR Art. 4(1).
• Art. 5(1)(e) requires a documented, justified retention period per data category, not indefinite storage 'just in case'.
• Pseudonymized records still count as personal data; only true anonymization removes data from GDPR scope (Recital 26).
• The ICO expects a written retention policy with standard periods and regular reviews.

When is phishing simulation data deletion mandatory?

Deletion or anonymization becomes mandatory when the individual-level record no longer serves the purpose it was collected for. For a click event, that purpose is the micro-training moment: the employee clicks, sees the teachable landing page, completes a short in-the-moment lesson. Once that moment has passed and the result has flowed into an aggregate, keeping the named record has no remaining purpose, and storage limitation says it must go. For a voice simulation recording, the purpose is even shorter-lived: the recording exists so the drill can run and be scored, and it should not survive the campaign.

The cleanest way to make this operational is default group-level anonymization with a minimum group size, so that no report can ever single out an individual. revel8 applies this by default: reporting is anonymized at group level with a minimum group size of 5, using hash functions that prevent identification of individuals even by the IT department, and personalized reporting with clear names is only possible with explicit customer permission.

This design is also what makes the works council conversation workable. Under Section 87(1) No. 6 BetrVG, co-determination is triggered by technical equipment capable of monitoring employee behavior or performance, and German legal practice treats a simulation platform that logs per-user clicks and credential entries as exactly that.^[2] A Betriebsvereinbarung that specifies purpose limits, a ban on using results in personnel decisions, defined retention periods for raw data, and aggregation thresholds is therefore the foundation, not an afterthought. Address it early in onboarding, and the retention schedule below gives you the concrete clauses to negotiate.

• Individual click, credential-entry, and vishing events: anonymize or delete once the micro-training moment has passed and the result is aggregated.
• Voice recordings from vishing drills: delete immediately after the simulation is scored; never retain by default.
• Reporting metadata: keep in anonymized, group-level form (minimum group size of 5) for trend analysis.
• Works council alignment: a Betriebsvereinbarung covering purpose, retention periods, and aggregation thresholds should be in place before the first campaign.

How to build a retention schedule for security awareness?

A schedule earns its place in the DPIA and the AVV only if it names the data class, the action, the period, and the justification. The periods below are recommendations you must justify against your own purposes, not statutory numbers; GDPR sets no fixed limits, and neither does NIS-2. What the law requires is that the period is defined in advance and documented. The table is structured so a DPO can lift it directly into the DPIA annex and the works council can read it without translation.

Two rules keep the schedule honest. First, anonymization must be real: hashed identifiers that can be re-linked with a key are pseudonymization, and storage limitation still applies to them. Second, every period needs an owner and a review date, because a schedule nobody enforces is a document, not a control.

What is the required NIS-2 audit evidence retention period?

Here the clocks diverge on purpose. Since 6 December 2025, the German NIS-2 implementation act (NIS2UmsuCG) has been in force, extending BSIG obligations to roughly 29,500 supervised entities in Germany, up from about 4,500 under the previous law. For the Mittelstand, the relevant scope threshold is 50 employees or more than EUR 10 million in annual turnover and balance-sheet total in a regulated sector. Section 30(1) sentence 3 BSIG requires these entities to document compliance with their risk management measures, and Section 30(2) No. 7 BSIG explicitly names basic training and awareness measures among the mandatory categories.^[3] At the directive level, Article 21(2)(g) NIS-2 requires basic cyber hygiene practices and cybersecurity training, and Article 21(2)(f) requires procedures to assess the effectiveness of those measures.^[4]

Neither the directive nor the BSIG fixes a retention period in months. The implementing regulation for certain digital providers requires logs to be kept for a 'predefined period', and German commentary is explicit that the circulating figures of six, twelve, or twenty-four months are consulting practice, not statutory text; what the framework demands is a justified, documented period defined in advance.^[5] ISO 27001:2022 behaves the same way: Annex A 5.33 (Protection of records) requires a retention schedule specifying how long each record type is kept, and secure destruction once the period ends, without prescribing the number.^[6]

The practical anchor is the audit cycle. Certification bodies for ISO 27001 operate on a three-year surveillance and recertification cycle, and a NIS-2 supervisory review will reasonably ask what your awareness metrics showed over recent years, not just last quarter. Keeping aggregated, anonymized evidence for three years covers that cycle without holding any personal data for it. This is the resolution of the tension from the start of this article: the GDPR does not apply to anonymous information, including for statistical purposes, so aggregated trend data can sit in cold storage for the full audit cycle while every named record behind it was anonymized months earlier.^[1]

• Section 30 BSIG and Article 21(2)(g) NIS-2 require documented training measures and their effectiveness assessment.
• No statute fixes a retention figure; you must define, justify, and document the period in advance.
• A three-year retention line for aggregated evidence matches the ISO 27001 audit cycle and typical supervisory review horizons.
• Aggregated, anonymized data satisfies the auditor without violating GDPR storage limitation.

How does the revel8 Platform enforce data retention policies?

A schedule on paper is only as good as its enforcement, and manual deletion jobs are where retention policies quietly die. The revel8 Platform addresses this at the infrastructure and reporting layers, which is why it fits the schedule above without custom engineering.

• Sovereign hosting: all data is hosted in Germany on STACKIT (Schwarz Gruppe infrastructure), and revel8 is ISO 27001:2022 certified and fully GDPR-compliant, a deciding factor for regulated industries.
• Default anonymization: reporting is anonymized by default at group level with a minimum group size of 5, using hash functions that prevent identification of individuals even by the IT department; personalized reporting requires explicit customer permission.
• Data minimization by design: required personal data is limited to first name, last name, email address, job title, and user group, with optional fields such as phone number and location.
• Audit-ready evidence: the platform provides audit-ready logs of every simulation, lesson, and user action, configurable data aggregation for privacy, and SIEM-ready exports for real-time compliance monitoring.
• No AI training on customer data: customer data is never used to train AI models, and all data processing happens within the customer's tenant.

For the DPO, default group-level anonymization with a minimum group size of 5 removes the most common sticking point in DPIA reviews, because individual performance monitoring is structurally impossible rather than merely promised. For the auditor, SIEM-ready exports and audit-ready logs mean the three-year evidence line in the schedule above is a configuration task, not a data project. And for the works council, the combination of German hosting, tenant-level processing, and hash-based anonymization gives the Betriebsvereinbarung concrete, verifiable clauses to reference. If you want to see the data flow your DPO would approve, the deepfake demo runs without IT setup and shows the anonymization behavior live.

Retention is where privacy and security stop being rivals and start being the same discipline: keep what proves your program works, in a form that no longer describes a person, and delete the rest on a clock everyone has seen and signed. Put the schedule from this article in front of your DPO, and make it the annex to your DPIA and AVV before the next campaign launches.

Sources

1. Recital 26 - Not Applicable to Anonymous Data - General Data Protection Regulation (GDPR), gdpr-info.eu
2. Phishing-Simulation rechtssicher: BetrVG, DSGVO, Betriebsrat, entropy-cybersecurity.com
3. § 30 BSIG, gesetze-im-internet.de
4. NIS 2 Directive, Article 21: Cybersecurity risk-management measures, nis-2-directive.com
5. NIS2-Protokollierung: Aufbewahrung, Frist und Nachweis im Detail, hostspezial.de
6. ISO 27001:2022 Annex A Control 5.33 Explained, isms.online