Phishing Simulation Tool Data Privacy: How to Meet GDPR Duties, Protect Employee Trust and Use Metrics Responsibly

Key takeaways

• Phishing simulation tool data privacy covers identity records, campaign metadata, behavioral events, simulated form inputs, cybersecurity awareness training records, risk scores and audit logs;
• Individual results that connect to an identifiable employee are personal data under the GDPR, and pseudonymized records stay in scope while a re-identification key exists;
• Legitimate interests fit workplace phishing simulation programs better than employee consent, provided the employer documents necessity, proportionality and safeguards;
• A phishing simulation tool data privacy review should set retention by data type, with separate schedules for raw events, campaign evidence, remediation records and risk scores;
• Role-based access keeps individual results with security and cybersecurity awareness training administrators while managers and executives receive aggregate trends;
• Meaningful human review before any consequential action helps keep a susceptibility score from operating as an automated employment decision;
• Disciplined phishing simulation tool data privacy controls produce audit evidence without building a permanent behavioral file on every employee.

Want more from Adaptive in your Google results?

Realistic phishing tests create a detailed record of how named employees behave under pressure, and that record usually outlives the campaign that produced it. According to the FBI IC3 2025 Internet Crime Report, phishing and spoofing generated 191,561 complaints, more than any other crime type. Security teams respond to rising phishing volume with frequent testing, then discover that clicks, reports, simulated submissions and risk scores have become an employee behavioral file.

Phishing simulation tool data privacy decides whether that file strengthens defenses or damages trust inside the workforce. Privacy regulators, works councils and employees ask the same three questions: why the data was collected, who can see it and when it disappears.

Vishing, smishing, deepfake and OSINT-personalized scenarios raise more privacy questions because each channel introduces identifiers that email testing never touched. This guide covers:

• How phishing simulation tool data privacy applies to identity records, behavioral events, simulated form inputs and cybersecurity awareness training records;
• When phishing simulation results become personal data and profiling under the GDPR;
• Which lawful basis, DPIA screening and processor controls support a defensible phishing simulation program;
• Which metrics a privacy-aware phishing simulation tool should collect, and how denominators should be defined;
• Which retention, access and deletion settings a phishing simulation tool data privacy review should test before production data arrives;
• How multi-channel and AI-personalized scenarios change the phishing simulation tool data privacy analysis.

Phishing tests collect employee behavior, and governance has to be set before the first campaign sends. Adaptive Security runs multi-channel phishing simulations with role-based access and configurable retention.

Take a self-guided tour

What Data Does a Phishing Simulation Tool Collect?

A phishing simulation tool sends controlled, realistic phishing messages to authorized employees and records how they respond. It uses those results to deliver targeted cybersecurity awareness training, measure behavioral change and produce reports for security, compliance and leadership teams. Privacy exposure depends on configuration, because a basic email campaign can collect limited event data while multi-channel testing and optional risk enrichment build a much broader employee profile.

That breadth is why phishing simulation tool data privacy starts with an inventory. According to the Verizon 2026 Data Breach Investigations Report, 62% of confirmed breaches involve a human element. Because people are part of so many breaches, organizations test employee behavior as well as technical controls. The testing itself then becomes a processing activity that needs its own justification.

How Do Phishing Simulations Work?

A phishing campaign begins with identity synchronization. Depending on the deployment, the cybersecurity awareness training platform imports a workforce roster through an identity provider, HRIS, SCIM connection or spreadsheet upload. Common fields include names, work email addresses, employee IDs, departments, job titles, managers, locations, language preferences and employment status.

The tool uses those attributes to select recipients, assign role-specific scenarios and exclude people who should not receive a phishing simulation. Campaign configuration then determines what the exercise records, because an administrator selects the cyberattack type, audience, delivery channel, schedule, landing page, training response and reporting rules.

Campaign metadata can include the campaign name, template, sender identity, target group, start and end dates, simulation type, assigned administrator and completion deadline. This information describes how the exercise ran and does not include what an employee privately communicated.

Message delivery creates technical event data. For an email phishing simulation, the tool can record whether a message was sent, delivered, bounced, opened or blocked, along with timestamps and delivery status. When an employee opens a tracking link or landing page, the system can also process an IP address, browser type, operating system, device category or user-agent string.

Those fields support troubleshooting and reporting, and they simultaneously expand the organization's privacy inventory. Each added field needs an owner, an access rule and a deletion date before the first campaign launches.

The interaction stage produces the most visible behavioral records. A phishing simulation platform can record whether an employee clicked a simulated link, opened an attachment, scanned a QR code, replied to a message, entered information into a simulated form or reported the message through a reporting button. It can also record the time between delivery, interaction and reporting.

These events show whether a person recognized the scenario and used the expected reporting process. They do not prove negligence because a click can result from curiosity, misunderstanding or a technical redirect.

The tool then delivers a corrective response. An employee who interacts with a phishing simulation may receive a short training module, an explanation of warning signs or a link to report the message. Cybersecurity awareness training records can include enrollment, assignment, start time, completion time, score, failed or passed knowledge checks, course version, language and overdue status.

Organizations should define in advance whether those records improve security behavior, support formal compliance or enter performance processes. Writing that decision down before launch prevents a training record from drifting into an HR file six months later.

Finally, the tool produces aggregate reports. Security teams can view campaign-level click rates, reporting rates, delivery rates, time-to-report, completion rates and trends by department, role, location or business unit. Individual dashboards can also display a person's phishing simulation history or risk score.

The UK Information Commissioner's Office guidance on automated decision-making and profiling explains that automated processing used to evaluate behavior can constitute profiling. That makes transparency, accuracy, access controls and retention operational requirements under phishing simulation tool data privacy rules. Individual scores deserve treatment as sensitive workforce information even when they sit outside the special-category definition.

Organizations can use a phishing simulation platform with multi-channel testing to rehearse email, voice, SMS and deepfake scenarios. Each added channel changes the data collected and the privacy analysis, so an email test and an AI-generated voice simulation should never share the same default retention or access policy.

What Data Categories Does a Phishing Simulation Tool Collect?

A practical data inventory separates information required to run a campaign from information the organization elects to collect for deeper risk analysis. Exact fields vary by vendor, contract, integration and administrator settings, so a category label alone cannot carry a phishing simulation tool data privacy review.

• Account and workforce identity data: Name, work email address, employee or directory ID, department, job title, manager, location, language, employment status and group membership, which support audience selection, provisioning, training assignment and reporting;
• Campaign metadata: Campaign name, scenario, template, sender profile, target group, channel, schedule, administrator, landing-page configuration, training assignment and campaign status;
• Behavioral events: Delivery, bounce, open, click, attachment interaction, QR scan, reply, form submission, report action, time-to-report, training launch and timestamps, along with technical context such as IP address, browser and device information;
• Simulated form inputs: A landing page can record whether a participant typed a username, password, verification code, payment detail or other value, so the configuration should prevent collection of real secrets and specify whether the tool stores the value, masks it or records only that an entry occurred;
• Cybersecurity awareness training records: Course assignment, enrollment, completion, score, failed knowledge checks, overdue status, module version, language and remediation history;
• Risk scores: A calculated score drawn from simulation outcomes, reporting behavior, training completion and other configured signals, which remains an organizational assessment of one behavior sample;
• Audit logs: Administrator logins, role changes, campaign creation, configuration changes, exports, report views, API activity and deletion events, which support accountability and help investigate unauthorized access;
• Optional enrichment: Open-source intelligence (OSINT), identity, access, credential breach-exposure, executive exposure, device or application-use signals that go beyond what a campaign needs to send a message and record a click.

The distinction between required and optional data should shape deployment. A phishing simulation tool needs enough identity data to know who should receive a campaign, enough campaign data to execute it, enough event data to measure the exercise and enough training data to deliver remediation.

It has no inherent need for an employee's personal phone number, private social media profile, personal email address, real password, precise location or unrelated HR record. Every field past that line requires a documented reason.

Optional enrichment can improve targeting and risk analysis while creating additional questions. What source supplied the data? Was it public, licensed or connected through an enterprise system?

Administrators should also confirm whether the field is accurate, how long it will be retained and who can view it. Data minimization means choosing the narrowest inventory that supports a defined security purpose, so a team that can meet the same training objective without a field should drop it.

Risk scores require particular care because they can influence training priority, manager visibility, access reviews or employment decisions. Security teams should document the score's inputs, establish human review, correct inaccurate records and prohibit automatic punitive action based only on a simulation result.

An isolated click is a training signal with a short shelf life. Treating it as a permanent label attached to an employee turns a coaching tool into a personnel judgment.

How Does Email-Only Testing Differ From Vishing, Smishing and Deepfake Simulations?

Email-only testing generally collects work identity data, message-delivery events, link interactions, reporting actions and cybersecurity awareness training records. The campaign can usually operate without personal telephone numbers, voice recordings, webcam access or video identity data. That narrower design reduces exposure when the organization also controls tracking fields, simulated form inputs and retention.

Multi-channel testing earns its added complexity because cyberattackers already work across channels. According to the IBM Cost of a Data Breach Report 2026, phishing remained the top initial attack vector for the fourth consecutive year, with voice and SMS phishing (vishing and smishing) involved in 17% of breaches and carrying the highest average breach cost.

Vishing simulations require a phone number or enterprise telephony route, along with call attempts, connection status, call duration, keypad actions, transcript data or recording data when the configuration captures the conversation. A voice scenario using an AI-generated executive persona can also involve script metadata, synthetic voice assets and the identity of the impersonated role.

Recording a participant's voice differs materially from recording whether the person answered or followed a prompt. Those settings therefore require separate approval and separate retention limits.

Smishing simulations require mobile numbers or a managed messaging integration. The phishing simulation platform can record message delivery, link clicks, replies, opt-outs, timestamps and device or carrier metadata. Personal mobile numbers should stay out of a campaign unless a documented business purpose supports their use, with a restricted audience and a clear route for employees to identify an authorized exercise.

Deepfake simulations add video and identity considerations. A scenario can use a synthetic executive video, a live impersonation session or a prerecorded message, so the organization must determine whether it is processing an employee's image, voice or likeness, and whether any of that data qualifies as biometric data under Article 9. The safest design avoids collecting participant webcam footage unless the exercise genuinely requires it.

Before deployment, security teams should confirm the exact data inventory in the vendor's privacy documentation, data processing agreement, current subprocessor list and product configuration. Those documents should identify collection purposes, processing roles, hosting regions, international transfers, retention periods, deletion procedures, security controls, support access, subprocessors and individual-rights workflows.

The UK ICO's worker-monitoring guidance stresses that monitoring should protect workers' data rights and build trust. Advance notice, proportionality and restricted access keep phishing simulation data focused on safer behavior while limiting unnecessary employee surveillance.

Which fields does a campaign actually need before the first message sends? Adaptive Security scopes email, voice, SMS and deepfake simulations to the data each scenario requires.

Explore the platform

Are Phishing Simulation Results Personal Data Under the GDPR?

Phishing simulation results are personal data under the GDPR when they can be connected to an identifiable employee. Identifiable clicks, reports, credential-like submissions, completion records, susceptibility scores and behavioral risk scores generally meet that standard because Article 4 of the GDPR covers information relating to an identified or identifiable person.

Truly aggregated statistics and irreversibly anonymized data sit outside the GDPR, while pseudonymized records usually remain within scope. That classification sets the practical boundary for every later decision about access, retention and reporting.

What Counts as Personal Data and Profiling Under Phishing Simulation Tool Data Privacy Rules?

Identifiability determines the privacy impact of a phishing simulation tool. If a security team can connect a click, report, completion record or score to an employee through a name, email address, employee ID, device record or lookup table, the information relates to a natural person. The simulated nature of the exercise leaves that classification unchanged, because the event still records how a particular employee responded to a controlled security scenario.

Because identifiable results are personal data, the organization must handle them to the same standard as any other employee record.

A phishing simulation tool data privacy review should treat these records as personal data while they remain tied to an individual:

• A click or page visit linked to an employee account;
• A report submitted through a phishing report button or equivalent workflow;
• A credential-like submission captured by a phishing simulation;
• Cybersecurity awareness training enrollment, completion, failure or overdue status;
• A susceptibility score calculated from one or more events;
• A behavioral risk score combining simulation, reporting and training signals.

Personal data status does not prohibit phishing simulations, but it does set conditions. The organization defines a lawful purpose, provides transparent privacy information, limits collection, restricts access, sets retention periods and protects records against misuse.

A documented data protection impact assessment becomes appropriate when monitoring is systematic, extensive or likely to create meaningful employment-related risks. That screening decision belongs in the campaign record, alongside the approver's name.

Pseudonymization and anonymization produce different legal effects. Pseudonymization replaces a name with a token, employee number or random identifier while preserving the possibility of reidentification elsewhere, so an administrator who can turn "user-4821" back into a named employee through a separate table is still handling personal data. The European Data Protection Board's 2025 pseudonymization guidelines explain that pseudonymized data remains within GDPR scope unless the person is no longer identifiable.

Anonymization requires a stronger result. The organization must be unable to reasonably single out, link or infer an individual from the retained dataset, considering the other information it holds.

A report stating that 12% of a 2,000-person workforce clicked a simulated email can be sufficiently aggregated when no manager can isolate a department, role or employee from the figures. A report showing that one finance employee clicked three simulations stays identifiable even after the name is stripped from the dashboard.

Repeated tracking can turn separate events into a profile. One click shows a single training outcome, while a year of clicks, reports, response times, completion records, OSINT exposure and risk scores evaluates an employee's behavior and susceptibility to social engineering. That activity falls within profiling when automated processing uses personal data to assess or predict aspects of an individual, including performance at work.

Organizations should keep security improvement separate from employee surveillance. Individual results can trigger supportive coaching, targeted microlearning or a follow-up conversation, while raw records stay with authorized security or training personnel.

Managers should see only the detail their role requires, and executives should receive team trends when individual identities add nothing. A phishing simulations program makes that boundary visible through role-based access, clear reporting purposes and retention controls.

What Does Article 22 Require for Automated Decisions?

Article 22 becomes relevant when a susceptibility or behavioral risk score drives a decision without meaningful human involvement. The rule addresses solely automated decisions, including profiling, that produce legal effects or similarly significant effects.

A score used to automatically remove system access, reduce compensation, fail a promotion review or trigger disciplinary action presents a materially different risk from a score used to assign optional refresher training. The first path demands human judgment before anything happens to the employee.

The UK Information Commissioner's Office guidance on automated decision-making and profiling explains that organizations must identify when Article 22 applies, provide information about the processing, offer a way to request human intervention and allow the individual to challenge the outcome. Although the guidance addresses the UK GDPR, its explanation of profiling reflects the same core safeguards found in the EU GDPR.

A susceptibility score should never be the sole basis for decisions about employment, compensation or discipline. Any decision about access needs human review of the underlying events and a documented necessity and proportionality analysis. Scores measure performance in selected scenarios under controlled conditions and say nothing about intent, competence, honesty or overall job performance.

An employee might click because the exercise was unusually realistic, an accessibility need affected the interaction or a legitimate work process resembled the simulated request. Another employee might avoid a click through luck while missing the underlying cyberattack pattern entirely.

Any consequential action needs a human review path. The reviewer should examine the underlying events, verify that the data is accurate, consider relevant context, allow the employee to explain or challenge the result and document the decision.

The reviewer also needs authority to change the outcome, because a rubber-stamp approval of an automated recommendation offers no protection. This step improves security judgment by separating a teachable mistake from a recurring control gap.

The same principle applies to access restrictions. A high score can justify temporary coaching or additional verification for a narrowly defined high-risk workflow, while an automatic blanket lockout requires a separate necessity and proportionality analysis. Security leaders should document why the action is needed, which less intrusive measures were considered and how long the action will last.

Privacy notices should explain what the phishing simulation tool records, why it records it, how scores are calculated at a meaningful level, who can view the results, how long records remain available and how employees can exercise their rights. A score deserves an accurate description as a security training signal with defined limitations.

Can Phishing Simulations Create Special-Category Data Risks?

Phishing content can accidentally reveal or infer special-category information even when the program measures only security behavior. Under Article 9, special categories include health, disability-related information, trade union membership, political opinions, religious or philosophical beliefs, racial or ethnic origin, genetic data, biometric data used for identification, sex life and sexual orientation. An inference can create risk even when the employee never deliberately submitted that information.

Examples include a phishing simulation that asks an employee to confirm a medical appointment, a message referring to a workplace accommodation for a disability or a training response that reveals union membership. A free-text field can also invite employees to disclose health conditions, family emergencies or religious observances when explaining missed training.

The organization should leave health, union or similar details uncollected even when the cybersecurity awareness training platform makes collection technically possible. A dropdown with neutral options answers the same operational question.

Sensitive themes belong in a campaign only when the organization has documented necessity, an Article 6 lawful basis and an applicable Article 9 condition. Simulation content should stay focused on the decision employees must practice, such as verifying a payment request or reporting a suspicious message.

Protected characteristics should never rank susceptibility or personalize risk scores. When sensitive information appears accidentally, administrators should restrict access, stop unnecessary reuse, record the incident and delete the data once retention is no longer necessary.

Human review becomes a necessary governance control whenever a score could materially affect an employee or sensitive information enters the workflow. Security, privacy, HR and legal teams should agree in advance on escalation rules, correction procedures, retention limits and prohibited uses.

The safest operating model treats phishing simulation results as confidential security-training records with a defined lifespan. A reviewer who opens the system a year later should find coaching history, and nothing resembling an unrestricted performance database.

Adaptive Security keeps identifiable phishing simulation results inside the security team while managers and executives receive department-level trends, remediation status and reporting speed without employee names.

Take a self-guided tour

Who Controls Phishing Simulation Data and What Legal Basis Applies?

Phishing simulation tool data privacy depends on who decides why employee testing occurs and how the resulting data is used. In the usual arrangement, the employer is the controller because it determines the testing purpose, scope, audience and retention period, while the vendor is the processor because it handles data under the employer's documented instructions.

Legitimate interests often fit routine security testing better than consent, provided the employer can show necessity, proportionality and safeguards. A legal obligation can support cybersecurity awareness training where it applies, but it does not authorize every deceptive scenario, detailed individual score or indefinite record. The correct allocation and legal basis depend on the contract, processing design, employment law and jurisdiction.

Controller Versus Processor Responsibilities

The employer controls the business decision behind a phishing simulation. It decides whether the objective is to measure susceptibility to credential theft, rehearse reporting behavior, test vishing defenses or satisfy a documented security-control requirement.

It also chooses which employees participate, what information is collected, whether managers receive aggregate results and how long records remain available. Those choices determine the purposes and essential means of processing, which generally makes the employer the GDPR controller.

The phishing simulation vendor normally acts as a processor when it delivers the tool according to the employer's instructions. It can host campaign data, send simulated messages, record clicks or reports, calculate scores and provide dashboards without deciding the employer's independent purpose.

The vendor cannot repurpose employee-level results for advertising, unrelated profiling or its own product research unless a separate lawful arrangement supports that use. Regulators examine what each party actually decides and does, so a contract label alone settles nothing.

The employer carries the primary accountability burden. It must document the processing, provide appropriate privacy information, select proportionate scenarios, restrict access and respond to employee rights requests.

It must also stop managers from turning a limited training signal into an unsupported disciplinary profile. A click on a simulated link can reflect a momentary response under realistic pressure, which says little about whether an employee is careless or permanently high risk.

The processor holds a narrower but substantial role. It must follow documented instructions, keep personnel confidential, apply appropriate security controls, assist with rights requests and notify the employer promptly after discovering a personal-data breach.

The GDPR's Article 28 requirements for processors also require contractual controls for subprocessors, audits and the return or deletion of data. Security leaders should test those obligations against the tool's actual architecture before accepting a generic data-processing label.

Which Legal Basis Fits a Phishing Simulation?

The legal basis explains why the employer can process simulation data at all. Legitimate interests under Article 6(1)(f) frequently provide the most workable route for private-sector security testing, because protecting systems, accounts and confidential information is a recognizable organizational interest.

The employer must still show that processing is necessary, that the security objective cannot be achieved through a less intrusive design and that the organization's interest does not override employees' rights and reasonable expectations. The employer's necessity argument rests on its own risk assessment, such as incident history, audit findings and the credential theft scenarios it needs staff to recognize.

A legitimate-interest assessment should cover the entire testing lifecycle. The employer should define the cyber threat being rehearsed, explain why a phishing simulation is needed, identify the data fields collected, assess likely employee impact and document safeguards.

It should compare alternatives such as aggregate reporting, pseudonymous identifiers, short retention and role-based access. The assessment should also address whether a deceptive exercise involving a finance employee, executive impersonation or a voice channel creates greater risk than an ordinary email exercise.

The European Data Protection Board's 2024 legitimate-interest guidelines frame the analysis around purpose, necessity and the balancing of interests, rights and freedoms. That structure prevents an employer from treating "security" as a universal permission slip.

A phishing simulation can be necessary while a specific design remains excessive. Recording an employee's voice during a vishing exercise, exposing a failed result to a broad management group or retaining raw interaction logs for years each require separate justification.

Proportionality should shape the campaign before launch. Collect only the data needed to determine whether employees recognized and reported the scenario, and leave out message content, device details or behavioral telemetry that cannot change the training outcome.

Retention should follow remediation, trend analysis or audit needs. Employees should receive clear privacy information covering purpose, data categories, access rules, retention period and rights, written in language they can understand.

Legal obligation works differently. An employer can rely on Article 6(1)(c) only where a specific law or binding regulatory requirement genuinely requires the relevant processing.

A general expectation that organizations maintain cybersecurity does not make every phishing test legally required. Even where cybersecurity awareness training is mandatory, that obligation may support completion records or evidence of a program while leaving deceptive content and granular individual scoring unjustified.

Consent deserves caution despite its familiarity. Employees often face a power imbalance with their employer, making it difficult to demonstrate that refusal would carry no disadvantage.

Consent also becomes unstable when participation is necessary for a job, when an employee cannot realistically decline a test or when withdrawal would affect treatment at work. Contract necessity rarely helps either, because an employment contract does not automatically require behavioral monitoring.

Other bases apply in limited circumstances. A public-sector employer may rely on a task carried out in the public interest or official authority where national law supports it.

Special-category data, such as health information accidentally revealed through a training record, triggers additional requirements and should be excluded wherever possible. The employer should document the selected basis for each processing purpose, since one basis rarely covers an entire cybersecurity awareness training platform.

What Should a Legitimate-Interest Assessment Cover?

A defensible assessment starts with a precise objective. "Improve security" is too broad, while "teach employees to verify urgent payment requests through an independent channel" identifies a concrete risk and a measurable training outcome.

The employer should then identify the specific data needed, such as delivery status, interaction type, report timing and follow-up training completion. Each field on that list should trace back to the stated objective.

The necessity test asks whether the same objective can be achieved with less personal data or less intrusive testing. Aggregate department trends might support program decisions without exposing individual names, and pseudonymized records might support longitudinal measurement while limiting routine manager access.

A high-risk finance exercise may justify individual follow-up for a small, defined group. Organization-wide publication of scores fails the necessity test, because the security benefit disappears while the employee impact grows.

The balancing test must account for surprise, embarrassment, workplace consequences and the possibility that employees read a phishing simulation as disciplinary surveillance. Safeguards should include advance transparency about the program, confidential remediation, restricted dashboards, defined retention, appeal channels and a prohibition on using isolated results for unrelated employment decisions.

A phishing simulation program designed around these controls can test realistic behavior while keeping data use tied to human-risk reduction.

What Must a Data Processing Agreement Include?

A data processing agreement should convert the employer's privacy decisions into enforceable operating instructions. It should identify the subject matter, duration, nature and purpose of processing, along with the categories of employees and personal data.

It should also state whether the vendor handles names, work email addresses, department or role information, simulation events, training status, reports, scores, IP addresses, voice recordings or video assets. Where a field is unnecessary, the agreement should prohibit its collection outright.

A practical DPA should cover these controls:

• Documented instructions: The vendor processes data only for specified phishing simulation, training, reporting and support purposes, with a controlled process for changing instructions;
• Confidentiality: Personnel with access to employee data are bound by confidentiality duties and receive appropriate privacy and security training;
• Security measures: The agreement describes access controls, encryption, authentication, logging, resilience, recovery, vulnerability management and testing at a level that matches the risk;
• Subprocessors: The vendor identifies approved subprocessors, provides advance notice of changes and gives the employer a meaningful opportunity to object where required;
• Data-subject rights: The vendor assists with access, correction, deletion, restriction, objection and other requests within the employer's response timetable;
• Breach notification: The vendor reports personal-data breaches to the employer without undue delay and supplies the facts needed for regulatory and employee communications;
• Deletion and return: At the end of the service, the vendor returns or deletes data, including backups and subprocessor copies, subject only to a documented legal-retention exception;
• Audit rights: The employer can obtain compliance information, review relevant certifications or reports and conduct proportionate audits without weakening other customers' security;
• International transfers: The parties document transfer locations, the transfer mechanism, supplementary safeguards, government-access risk assessment and instructions for changes in adequacy or transfer law.

The DPA should also distinguish customer data from vendor telemetry, support records and aggregated statistics. "Aggregated" stops being anonymous the moment employees can be singled out through small teams, rare roles or repeated campaign patterns.

The employer should require the vendor to explain whether scores can be linked back to named people, whether data is used to train models and whether support staff outside the employer's region can access it.

A clear controller-processor allocation leaves the employer's accountability intact while making responsibility visible. The employer justifies the test and limits its use, and the vendor executes documented instructions and protects the data.

Contracts describe processor duties while product configuration decides what a vendor actually stores. Adaptive Security exposes those retention and access settings to administrators before production data arrives.

Book a demo

How Should Organizations Assess Phishing Simulation Tool Data Privacy Before a Campaign?

A phishing simulation tool data privacy review should begin before anyone receives a test message. The sequence runs from campaign purpose to field inventory, DPIA screening, access and retention controls, then approval from privacy, security, HR, legal and employee representatives where required.

A privacy review should begin before anyone receives a test message. Smaller organizations need a screening process they can run without a dedicated privacy department.

1. Screen the Campaign for DPIA and Risk-Assessment Requirements

Document what the phishing simulation is intended to achieve. A legitimate purpose is to improve employees' ability to identify and report phishing, measure behavioral change and direct follow-up training.

Employee discipline, productivity ranking, termination decisions and general performance surveillance are separate purposes that require separate analysis. Mixing them into one campaign record makes the whole program harder to defend.

Describe the processing in operational terms. Record which employees are included, which channels are tested, how messages are personalized, what events are logged, where data is stored, which vendors process it and whether results are combined with training completion, identity, HR or risk data.

Include open-source intelligence (OSINT) when it informs scenario design, and explain why each data source is necessary. A source without a justification is a source to remove.

A DPIA is required when processing is likely to create a high risk to people's rights and freedoms. The UK Information Commissioner's Office DPIA guidance directs organizations to consider the likelihood and severity of harm and to identify warning signs such as evaluation or scoring, systematic monitoring, innovative technology, data matching, large-scale profiling and vulnerable data subjects.

A phishing campaign can trigger several of those indicators at once. Individual risk scores, behavior tracked over time, AI-generated content and simulation results combined with other employee records each move the campaign toward the high-risk threshold.

Ask whether an employee could be embarrassed, unfairly labeled, denied an opportunity or subjected to disciplinary action because of an inaccurate or misinterpreted result. Consider contractors, interns, temporary workers, employees on leave and people working under a collective agreement.

The employer-employee power imbalance makes proportionality and transparency essential in each of those cases.

Complete the DPIA before launch when screening identifies high-risk processing. Where the organization concludes that a DPIA is unnecessary, record the reasoning, safeguards and approving person.

A documented "no DPIA required" conclusion carries more weight when it explains why the campaign avoids significant effects, sensitive data, extensive profiling and incompatible purposes.

2. Minimize Fields and Test Controls Before Approval

The safest phishing simulation tool design collects only what the campaign needs. For most programs, that means a work identifier, business unit or role, delivery status, interaction event, report event, training assignment and timestamps.

Message content from personal accounts, private browsing activity, health information, protected characteristics and unrelated productivity data all sit outside that list. Adding them expands the privacy inventory without changing the training outcome.

Separate operational data from reporting data. Security administrators may need an individual result to assign remedial cybersecurity awareness training, while executives usually need aggregated trends by department, role or region.

Dashboards should prevent senior leaders from browsing individual outcomes by default, and HR access should open only when a defined employment process requires it. A blanket prohibition on treating simulation results as a general performance score belongs in the written policy.

Retention should follow the purpose. Set a documented period for raw event data, individual remediation records and aggregated trend data, then delete or anonymize individual results once training, audit, incident review or a documented legal obligation no longer requires them.

Recheck retention after each campaign cycle. Years of accumulated individual results quietly convert a security database into a behavioral surveillance system that nobody decided to build.

Test controls with sample accounts before the first live campaign. Confirm that role-based permissions work, exports omit unnecessary fields, deleted users disappear from future campaigns and support personnel cannot view results without authorization.

Verify encryption, processor agreements, cross-border transfer mechanisms, breach notification procedures and audit logging with privacy and security teams. Organizations evaluating a phishing simulation program built around multi-channel testing should ask vendors how individual results, scenario content, message metadata and remediation records are separated and protected.

The decisive question is whether every analytic field has a defined purpose, owner, access rule and deletion date. Fields that fail that test should be switched off before the roster is uploaded.

3. Publish an Employee Transparency Notice

Employees should receive a privacy notice before the program begins, even while campaign timing remains confidential. Surprise testing requires secrecy about when a phishing simulation will occur and which scenario will be used.

That secrecy stops at the program's existence, security purpose, categories of data processed and the rights available to employees. Publishing those four elements costs the exercise nothing in realism.

The notice should explain in plain language that the organization conducts controlled phishing simulations to improve detection, reporting and response. It should identify the categories of data involved, such as work contact details, delivery and interaction events, reporting behavior, assigned training, department, role and campaign timestamps.

Where OSINT, AI-generated content, voice, SMS or video is used, the notice should state that clearly and describe its boundaries. Vagueness in this section produces the suspicion the notice is meant to prevent.

Identify who can access individual results and under what conditions. Explain whether access is limited to security or cybersecurity awareness training administrators, whether managers receive only aggregated reports and when HR, legal or employee relations may receive information.

Name the privacy contact, data protection officer, works council contact or employee representative responsible for questions and complaints. A named human makes the complaint route real.

Include retention periods or the criteria used to set them. Explain applicable rights, including access, correction, restriction, objection where available and deletion where applicable.

The European Data Protection Board's explanation of data subject rights identifies rights to be informed, access, rectification, erasure, restriction, objection, portability and safeguards around solely automated decisions. Employees also need to know exactly where to submit a request and how the organization will verify and respond to it.

A clear correction route lets employees challenge inaccurate records before a mistaken result affects training assignments, reporting or employment decisions.

4. Establish Governance and Approve Each Scenario

Create a written campaign policy that separates security improvement from employee performance management. A simulation result should trigger coaching, targeted training or a review of confusing controls before anyone considers employment action.

Repeated deliberate misuse, refusal to follow an established security process or a separate policy violation can require HR review. That path must be defined in advance and applied consistently, so nobody invents an escalation rule mid-campaign.

Give employees a correction route. An employee who believes a result is inaccurate should be able to request the underlying event record, explain the circumstances and ask for correction.

The review should distinguish a genuine interaction from a false positive, delegated mailbox activity, accessibility issue, technical delivery problem or a scenario mismatched to the employee's role. An incorrect risk label deserves removal even after it appears in a dashboard.

Before approval, security, privacy, HR, legal, communications and the relevant works council or employee representatives should review the purpose, audience, data fields, scenario language, access model, retention period and escalation rules. In high-impact sectors or jurisdictions, local legal advice should replace the assumption that one global policy fits every workforce.

Use an approval record for every campaign. It should confirm the defined purpose, minimum data fields, DPIA decision, lawful basis, processor review, access controls, employee notice, scenario approval, exception handling and deletion date.

After the campaign, review aggregate outcomes, complaints, correction requests, false positives and access logs. Scenarios that create unnecessary distress or fail to measure a relevant security behavior should be retired from the library.

When a campaign launches before privacy, HR and legal approve the data fields, the record outlives the exercise. Adaptive Security ties each campaign to documented scope.

Take a self-guided tour

Which Phishing Simulation Metrics Should a Privacy-Aware Tool Collect and Report?

Phishing simulation metrics should show whether employees recognize and report simulated cyber threats without turning training data into unnecessary surveillance. The main distinction runs between event-level telemetry, which records a specific interaction, and aggregate risk reporting, which shows whether a team or organization is becoming more resilient.

Individual metrics such as a click or credential-like submission support targeted coaching, while department-level trends support program decisions and executive reporting. Aggregate metrics protect context and dignity better than named scorecards, and individual visibility stays appropriate where access is restricted and a clear remediation purpose exists. The framework should match the metric's security value, the audience receiving it and the minimum data needed to act.

What Phishing Simulation Metrics Should Be Collected, and How Should Denominators Be Defined?

Metric definitions determine whether a phishing simulation produces useful evidence or misleading conclusions. Every campaign should record the eligible recipient population, delivery status, meaningful interaction events, reporting behavior, training response and remediation outcome.

Data that cannot change a security decision should stay out of the calculation. As NIST computer scientist Julie Haney and University of Maryland Associate Professor Wayne Lutters concluded in their peer-reviewed analysis published in Computer (October 2020), compliance metrics do not tell the whole story and fail to measure the effectiveness of the program in a sustained change in employee attitudes and behaviors.

A practical framework includes:

• Delivery rate: Delivered messages divided by eligible recipients, with failed deliveries separated from suppressed, quarantined or excluded addresses;
• Open rate: Opened messages divided by delivered messages, used only where the mail environment provides technically reliable event data, since privacy tools, image blocking, caching and automated security systems make opens unreliable as a primary risk metric;
• Click rate: Unique human clickers divided by delivered messages, or by confirmed human recipients when delivery data is incomplete, with the denominator reported alongside every result;
• Report rate: Unique employees who use the approved reporting channel divided by delivered messages, counting the first report per campaign rather than repeated button presses;
• Time to report: The elapsed time between delivery and the first valid report, expressed in bands such as under 15 minutes, 15 to 60 minutes and over 60 minutes where exact timestamps create unnecessary precision;
• Credential-like submission rate: Employees who submit text into a simulated username or password field divided by delivered messages or confirmed human visitors, on a page that never receives, stores or transmits real passwords;
• False-positive rate: Reports classified as benign divided by total reports, used to guide coaching on verification rather than to punish employees for escalating uncertainty;
• Cybersecurity awareness training completion: Assigned learners who complete the required module divided by those assigned, which shows exposure to instruction;
• Repeat susceptibility: Employees who repeat the same risky action across comparable campaigns over a defined period, compared like with like rather than mixing email clicks with vishing or smishing events;
• Resilience over time: Change in click, submission and report behavior across successive campaigns, where a falling click rate paired with a rising report rate shows stronger defensive action;
• Remediation completion: Employees who finish assigned coaching divided by those assigned, paired with a later retest to determine whether the intervention changed behavior.

Denominators must remain visible. A 4% click rate among 10,000 delivered messages and a 4% click rate among 25 delivered messages are mathematically identical and operationally different.

Campaign reports should also identify exclusions, duplicate events, test accounts, bounced messages and recipients who never received the phishing simulation. Those footnotes prevent a reviewer from reading improvement into a smaller sample.

The European Data Protection Board's 2025 pseudonymization guidelines emphasize that pseudonymization separates identifying information from other records while preserving controlled usefulness. Applied to phishing simulations, that means storing campaign outcomes under a stable pseudonymous identifier for each retention period, restricting the re-identification key and documenting when named access is necessary. Identifiers reset at the end of each retention period.

How Should Individual and Aggregate Phishing Simulation Results Be Reported?

Individual reporting is justified when a security team must assign targeted training, investigate a repeated high-risk pattern or confirm remediation. Access should remain limited to authorized administrators, use role-based controls and display only the events needed for that action.

A manager usually needs a team trend and remediation status. A complete history of every email interaction by every employee exceeds what any manager decision requires.

Team and department reporting should be the default for operational reviews. Security leaders can compare click rate, report rate, time to report, submission rate, false-positive rate and repeat susceptibility by department, role or risk category.

Small groups require extra care because a percentage can identify one person indirectly. Suppress results for very small cohorts, combine teams where appropriate and avoid rankings that turn training into public punishment.

Executive and board reporting should use organization-level signals. A useful board view shows the percentage of eligible employees who reported simulations, the trend in human actions over time, the share completing remediation, the number of departments with improving resilience and the number requiring additional investment.

Employee names have no place in that view, and a single composite score without its component metrics hides more than it explains. Completion rate shows program reach, while repeat susceptibility and reporting speed show whether exposure is falling.

Compliance reporting should generally use aggregate counts, campaign dates, assigned populations, completion evidence, policy mappings and remediation records. Individual-level evidence deserves retention only when a documented purpose, defined retention period and access control support it.

Security awareness training and reporting workflows should preserve audit evidence while keeping personal behavior histories out of every administrator's default view. An auditor reviewing that setup sees completion and remediation proof without opening a single employee profile.

How Can Administrators Distinguish Genuine Employee Actions From Automated Email Events?

Automated systems can distort phishing simulation metrics before an employee sees a message. Link scanners may open every URL, safe-link services may rewrite destinations, email security tools may follow links in sandboxes and automated previews may generate page views that resemble human activity.

An open or click event alone cannot establish that an employee read the message or chose to interact with it. Treating scanner traffic as human behavior inflates risk scores for people who did nothing.

Administrators should separate raw telemetry from confirmed human action. Record the event type, timestamp, user agent, IP or network context where necessary, redirect sequence and whether the event produced a browser session consistent with the employee's normal environment.

Known scanner signatures and security-review traffic deserve an automated label. A single user-agent string remains weak evidence, because cyberattackers and privacy tools can alter it.

Human confirmation should require stronger evidence than a page request. A click followed by a short-lived session with no page interaction may indicate scanner activity, while a click followed by form focus, deliberate navigation or a report through the approved channel provides stronger evidence of employee action.

Even then, administrators should preserve confidence categories such as confirmed, probable, automated or unresolved. Forcing every event into a binary judgment manufactures certainty the data cannot support.

Accurate event classification also matters for response speed, because analysts who chase scanner-generated clicks have less time for genuine reports.

The same accuracy rule applies to report rate. A report sent by an automated mailbox rule should stay out of the employee report count, while duplicate reports from the same person should count once. Calibrating these rules before a campaign keeps security infrastructure from inflating employee risk scores.

Why Must Simulated Landing Pages Reject Real Passwords and Sensitive Information?

A simulated landing page should demonstrate the decision point while collecting nothing secret. It must reject real passwords, payment details, personal identifiers, customer records and free-text submissions that could contain confidential information.

The page can record that a credential-like field was used, the campaign identifier, the time window and the minimum technical context required to validate the event. Those four items support coaching without creating a credential store.

Administrators can retain useful evidence while storing no sensitive content. Configure the form to accept a fixed test token, discard field values immediately, disable server-side logging for submitted text, prevent third-party analytics from capturing the page and display an immediate teaching message after the event.

Where a browser autofill tool inserts a real value, the system should block transmission at the source. Relying on later deletion leaves the value in transit logs that nobody reviews.

Campaign evidence should answer four questions: who was eligible, what simulated action occurred, when it occurred and what remediation followed. The exact text entered into a field and a permanent record of every page request both fall outside that requirement.

Set retention periods by purpose, reset pseudonymous identifiers at the end of each retention period and delete raw event data once aggregated trends carry the analysis. A privacy-aware program also separates learning from discipline, so employees understand that reporting a suspicious simulation is the desired outcome even when the report turns out to be a false positive.

Turn click and report events into role-based coaching with Adaptive Security's AI-powered microlearning, then publish department trends while raw event telemetry stays inside the security team.

Explore the platform

What Privacy and Security Controls Should a Phishing Simulation Tool Provide?

A phishing simulation tool should give buyers control over who can access employee data, how long each data type is retained, where it is hosted and what happens when the contract ends. Encryption, tenant isolation, role-based access, auditability, deletion, backup handling, subprocessors, export controls and breach response all deserve verification before names, email addresses, simulation results or risk scores reach the vendor.

Privacy settings function as deployment requirements, because realistic phishing simulations create detailed records of employee behavior. A phishing simulation tool should give buyers verifiable controls over access, retention and deletion before any employee data is uploaded.

1. Establish Access Governance and Auditability

Map every person, service account and integration that can access phishing simulation data. The vendor should provide role-based access control with separate permissions for campaign designers, trainers, analysts, administrators, human resources personnel and executives.

A user who needs aggregate department reporting has no operational reason to receive raw click records, message content or individual risk histories. Default permissions rarely reflect that distinction, so administrators should set them deliberately.

Least privilege should operate at both the tenant and object levels. Confirm whether administrators can restrict access by business unit, geography, campaign, data type or employee group.

Check whether the cybersecurity awareness training platform supports single sign-on, multifactor authentication, automated provisioning and deprovisioning and session controls. Departed administrators and over-permissioned service accounts otherwise keep their access to employee records long after their role ends.

Audit logs must record more than login events. Verify that the tool captures who viewed, changed, exported, shared or deleted data, which object they accessed, when the action occurred and whether it succeeded.

Logs should be tamper-resistant, searchable, exportable to the organization's monitoring system and retained long enough to support investigations. A dashboard that shows campaign performance while recording no administrative activity leaves a material accountability gap.

Bulk downloads deserve an alert, an approval step or a reason code. Confirm that exports are limited to authorized roles and that the system records the file type, scope, destination and administrator who initiated the action.

These controls matter because a legitimate report containing employee names and risk scores creates a second privacy exposure outside the tool. Review the vendor's phishing simulation platform controls alongside its administrative permissions, identity integrations and reporting workflows before approving production data.

2. Set Retention and Deletion Configuration by Data Type

One global retention period fails every data category at once. A practical policy separates raw events, campaign evidence, aggregated reports and risk scores, because each category carries a different operational purpose and privacy impact.

Raw events include message delivery, opens, clicks, credential-entry attempts, reports, timestamps, device details, IP addresses and similar telemetry. These records support immediate troubleshooting and behavior analysis while carrying the greatest employee-level detail, so the shortest workable period applies.

Campaign evidence includes the simulation template, landing-page copy, approval record, recipient group, screenshots and proof that a particular scenario ran. Organizations often need this material longer than raw telemetry to demonstrate that training occurred, investigate a dispute or satisfy an internal audit.

Evidence of that kind should still exclude unnecessary personal data. A redacted scenario record proves the same control operated.

Aggregated reports combine results by department, role, region or time period. They can remain available after identifiable events are deleted when the aggregation prevents reasonable reidentification.

Confirm how small groups are handled, because a report showing one employee in a department stays identifiable under a department label. Suppression thresholds belong in the configuration rather than in a reviewer's judgment.

Risk scores require a defined review period and documented purpose. Where a score influences training assignment, access decisions, performance discussions or executive reporting, retention should end when that purpose ends.

The vendor should let customers configure separate retention periods for each category. The UK Information Commissioner's Office guidance on storage limitation advises organizations to erase or anonymize personal data once it is no longer needed, and buyers should test whether the tool enforces scheduled deletion rather than merely documenting it.

3. Test the Complete Data Lifecycle

A vendor's lifecycle controls should cover collection, use, export, correction, portability, deletion, backup recovery and contract termination. Request a data-flow diagram identifying the primary application, databases, analytics systems, support tools, object storage, disaster-recovery environments and subprocessors.

The diagram should show which systems receive raw employee data and which retain only pseudonymized or aggregated records. That distinction drives the transfer analysis later.

Verify how the tool handles correction requests. An employee or customer administrator should be able to correct inaccurate identity information, campaign assignments or reporting attributes without creating a duplicate profile.

Ask whether corrections propagate to analytics stores, exports, dashboards and backups. An incorrect record surviving inside a downloadable report keeps producing inaccurate risk decisions long after the fix.

Data portability should be practical. Confirm that customers can export users, campaign configurations, simulation evidence, cybersecurity awareness training history, risk scores, audit logs and retention metadata in documented formats.

The export should include field definitions, timestamps, identifiers and relationships between records. Without those, a migration or regulatory review turns into a reconstruction project.

Deletion workflows must distinguish logical deletion from permanent deletion. When a user is removed, determine whether the tool blocks access while retaining the record, anonymizes it or permanently erases it.

Confirm how deletion affects linked campaign evidence, reports, risk scores, search indexes, caches and support tickets. The vendor should provide completion evidence, including the deletion date, data categories covered and any records excluded under a documented legal or security exception.

The contract should specify when production data is deleted after cancellation, how the customer receives a final export, how access is revoked and when vendor employees and subprocessors lose access. "Deleted from the active environment" means something narrower than permanent deletion while replicas, archives or backups remain searchable.

Ask how often backups run, where they are stored, how they are encrypted, who can restore them and when expired records disappear from backup cycles. The vendor should explain whether a deleted record can reappear after a full-system restore and what prevents that outcome.

Where immediate backup erasure is technically infeasible, the contract should define isolation, restricted access and a fixed overwrite schedule. Regional hosting must match the organization's risk and legal requirements, covering production databases, backups, support access and subprocessors.

EU data residency should cover the full processing chain. A U.S.-hosted support system or analytics service creates an international transfer even when the main database sits in Europe.

Customer-managed encryption keys, where available, provide additional control over access and key revocation. Verify whether those keys protect backups, logs, analytics stores and subprocessors alongside the primary database.

Require subprocessor transparency and breach response commitments. The vendor should publish current subprocessor names, processing locations, functions and notification procedures, with advance notice of material changes.

The contract should define how quickly the vendor will notify the customer, preserve evidence, support investigation, contain access and provide updates after a suspected breach. Ask whether customer simulation data is used to train AI models, improve products, create benchmarks or develop new content, and set the default to no secondary use without explicit customer authorization.

Before approval, run a deletion test, export test, access-review test, backup-restoration exercise and breach-notification tabletop using nonproduction records. Document the approved retention schedule and assign an owner to review it as the phishing simulation program changes, so old click events stop identifying employees who changed their behavior two years ago.

A vendor promise about deletion means little without a scheduled deletion test. Adaptive Security documents retention, access and export controls across the full cybersecurity awareness training record set.

Book a demo

What Audit Evidence Should a Phishing Simulation Tool Provide for Data Privacy and Compliance?

A phishing simulation tool should produce evidence that connects testing activity to the organization's governance, training and risk-management controls. Auditors distinguish between design evidence, which shows that controls were defined and approved, and operating-effectiveness evidence, which shows that those controls worked consistently during a review period.

Design evidence includes policies, scope, roles, retention settings and data-processing decisions established before a campaign begins. Operating evidence includes delivery records, completion data, remediation activity, exceptions and management review captured as the program runs. GDPR, ISO 27001, SOC 2, HIPAA, PCI DSS, NIS2 and DORA each evaluate broader control environments, and none universally requires deceptive testing or individual failure records.

What Evidence Supports Governance and Cybersecurity Awareness Training Controls?

Governance evidence shows that phishing simulation is an authorized control activity. A reviewer should be able to see the approved human-risk policy, business owner, permitted simulation methods, escalation process and the roles authorized to access results.

The policy should explain why simulations occur, which channels are in scope, how employees are notified or excluded where appropriate and how the organization limits unnecessary personal-data collection. Board engagement strengthens that record. In the World Economic Forum Global Cybersecurity Outlook 2026, 52% of highly resilient organizations said board members receive regular cybersecurity updates.

Scope documentation must identify the employee and contractor population included in the program, the provisioning source, the date the population was reviewed and the process used to identify gaps. A campaign that covers full-time employees while omitting contractors, privileged administrators or recently acquired teams creates an incomplete control picture.

Records should show how leavers, long-term absences, service accounts and approved exceptions were handled.

Campaign evidence should connect each exercise to a defined risk or control objective. Retain the campaign date, scenario type, target group, channel, approval record and simulation status.

Useful scenario descriptions state whether the exercise tested credential entry, attachment handling, invoice fraud, business email compromise (BEC), vishing, smishing or another behavior. A redacted event record demonstrates the same control outcome as full message content, with far less personal data attached.

Training evidence shows what happened after the signal appeared. Preserve assignment records, completion dates, learning objectives, remediation ownership, due dates, reassignment history and evidence that overdue work was escalated.

This closed loop from exposure to corrective action creates a stronger audit trail than an isolated click rate. Adaptive Security's Security Awareness Training can map to governance and training controls, while the organization's own policy approvals, risk assessments and audit judgment remain in place.

How Should SOC 2 Type I and Type II Evidence Differ?

SOC 2 Type I and Type II evidence answer different audit questions. Type I evidence addresses whether relevant controls were suitably designed and implemented at a specified date, and Type II evidence addresses whether those controls operated effectively throughout a defined review period.

A Type I package should emphasize the approved policy, system configuration, population scope, access model, retention settings, data-processing documentation and a representative campaign record established by the assessment date. Type II evidence must demonstrate continuity through campaigns conducted across the audit period, consistent delivery records, metric calculations, training assignments, completion activity, remediation follow-up and exception handling.

The package should also show that the control owner reviewed results and acted when performance fell outside the stated threshold. One successful campaign cannot establish operating effectiveness across several months.

Metric definitions prevent reviewers from misreading the evidence. Document the denominator for delivery rate, report rate, click rate, credential-submission rate, completion rate and time to report.

Explain whether duplicate events count once, how bounced messages are treated, how mid-period hires are included and whether simulations blocked by a mail filter are recorded as delivered, undelivered or excluded. Keep these definitions stable unless a documented methodology change explains the adjustment.

The same controls protect employees. Individual results can support targeted remediation while access stays limited to authorized administrators and reviewers with a legitimate need.

Management reports can aggregate results by department, role or risk tier while detailed records remain in a controlled system. Auditors receive useful evidence, and the training data stays out of unrestricted personnel files.

What Makes Phishing Simulation Reporting Audit-Ready?

Audit-ready reporting is a chain of evidence rather than a dashboard screenshot. Each report should identify the control objective, reporting period, population, campaign parameters, source data, metric definitions, exceptions, remediation status and reviewer.

A reviewer should be able to move from an approved policy to a campaign, from that campaign to delivery and interaction records, and from an interaction to the assigned corrective action. Any break in that chain becomes an audit finding.

Access logs strengthen the chain by showing who viewed, exported or changed sensitive results. Retention settings should identify how long campaign records, training records, audit logs and exports are kept, where they are stored and when they are deleted.

Data-processing documentation should identify the categories of personal data collected, processing purposes, service-provider roles, transfer arrangements, security measures and deletion procedures. These records matter because phishing simulation results can relate to identifiable employees.

The European Data Protection Board's guidance on data protection principles reinforces the need to protect personal data while documenting responsible processing. Applying that discipline to simulation data means limiting collection to the stated purpose, restricting access and deleting records when the retention period ends.

Management review closes the evidence loop. Preserve meeting records, approval notes, risk-acceptance decisions, trend summaries and actions assigned to accountable leaders.

A review that records rising reporting rates, unresolved exceptions or changes to high-risk populations demonstrates that leaders used the evidence. ENISA's 2025 NIS2 technical implementation guidance reflects the wider expectation that cybersecurity measures be documented, governed and evidenced.

How Should Evidence Map Across Major Frameworks?

A single evidence set can support several frameworks when the mapping is explicit and the scope remains accurate.

• ISO 27001 and SOC 2: Map policy approval, risk ownership, access control, cybersecurity awareness training records and operating-period results to the organization's defined controls;
• HIPAA: Connect workforce training, sanction procedures, access safeguards and security incident processes to the covered entity's documented control environment;
• PCI DSS: Use role-based awareness records, phishing-related training and management review where those activities support defined cardholder-data protection controls;
• GDPR: Document purpose limitation, data minimization, access restrictions, retention decisions, processor roles and international transfer arrangements when simulation results identify employees;
• NIS2 and DORA: Demonstrate governed cybersecurity practices, accountable ownership, documented risk treatment and evidence that controls operated as intended.

No framework requires phishing simulations as a specific test format. The defensible approach maps each record to a control objective, documents why the exercise is proportionate and preserves only the information needed to show that the control operated.

A phishing simulation tool should make exportable evidence available, while the organization approves scope, defines lawful and fair processing, reviews exceptions and retains records according to its obligations. Clear ownership means an auditor can follow the trail without the compliance file turning into a second privacy exposure.

How long does an auditor spend assembling campaign evidence from five systems? Adaptive Security exports completion, scenario and remediation records formatted by framework and date range.

Take a self-guided tour

How Can Organizations Use a Phishing Simulation Tool Without Damaging Employee Trust?

A phishing simulation tool strengthens employee trust when its data drives coaching and better cybersecurity awareness training. Punitive use encourages employees to hide mistakes, while a learning-centered program converts failed simulations, delayed reports and recurring patterns into targeted support.

Finance teams carry the sharpest version of the balance between realistic testing and employee rights. According to the FBI IC3 2025 Internet Crime Report, business email compromise (BEC) caused $3.05 billion in losses across 24,768 complaints, about $123,000 per case.

How Does Point-of-Error Coaching Turn a Failed Phishing Simulation Into Improvement?

Point-of-error coaching gives employees useful guidance at the moment a risky decision occurs. If someone clicks a simulated link, submits credentials or misses a suspicious voice request, the program should explain the overlooked signal, show the safer action and provide a short module matched to the mistake.

The goal is recognition while the scenario is fresh. A permanent record of failure does not change behavior, while a short lesson at the moment of error can.

Coaching messages should remain factual and respectful. "This request used an urgent payment deadline and an external sender address. Verify requests like this through a known channel before acting." This style teaches a repeatable behavior.

"You failed a test" produces embarrassment while leaving judgment unchanged. Employees also need a clear way to report confusing, inaccessible or role-inappropriate simulations.

Training must reflect language, job duties and communication channels. A finance employee handling wire transfers needs practice with vendor impersonation and business email compromise (BEC), while a field employee may face smishing or vishing on a mobile device.

An executive may receive a deepfake video or an urgent request from an apparent board member. Translated modules, captions, screen-reader compatibility and realistic role context keep training barriers from distorting the result.

A modern phishing simulation program should connect each event to an appropriate remediation path. An email mistake can trigger a short email analysis lesson, while a missed voice simulation can lead to verification practice and a second-channel confirmation exercise.

The measure that matters is whether the next decision improves. If employees describe the program as punishment, the coaching design needs work.

How Should Organizations Interpret Phishing Simulation Results Fairly?

Fair interpretation treats one event as a signal rather than a verdict. A single click can reflect an unusually realistic scenario, a rushed workday, unclear instructions, a language barrier or a technical problem.

Security leaders should examine repeated patterns across time, role and channel before assigning additional support. Patterns carry information that isolated events cannot.

Useful analysis covers several dimensions. Review whether the employee repeatedly interacts with credential requests, misses simulations across email and SMS, reports suspicious messages promptly, completes assigned coaching and improves after remediation.

Compare time to report, reporting accuracy and trend direction with the initial result. Someone who clicks once and then reports the next three simulations quickly is showing behavioral improvement, while someone who avoids clicks and never reports suspicious messages still needs practice.

Role and channel risk also affect interpretation. A finance employee receives more high-consequence payment requests than many other teams, so exposure should be evaluated alongside job responsibilities and approval controls.

Contractors may have less access to internal training or use personal devices, requiring a separate onboarding path. Executives and assistants often face concentrated impersonation risk and need private verification drills without public rankings.

Risk scores should remain directional indicators for training allocation. Labels such as "careless," "unsafe" or "high risk" strip away the context that makes a score meaningful.

Leaders should document the factors behind a score, separate observed behavior from inferred intent and review whether the data is complete. Employees need a correction process for inaccurate role assignments, duplicated identities, mistaken results and accessibility issues.

What Governance Prevents HR or Disciplinary Misuse of Phishing Simulation Data?

Individual results should be visible only to authorized security or program administrators who need them for coaching. Managers should receive aggregated team trends unless a specific intervention requires individual context.

HR should receive no raw click histories by default, and an individual risk score must never serve as the sole basis for hiring, promotion, compensation, termination or disciplinary action. That prohibition belongs in writing before the first campaign, where it can survive a change of security leadership.

This boundary matters because behavioral data becomes more sensitive once it merges with performance records, attendance information or manager opinions.

High-risk groups require stronger safeguards. Executives and finance teams should receive private coaching, tightly controlled simulations and explicit approval workflows for high-impact requests, while contractors should receive equivalent instructions before testing begins.

Voice, SMS and deepfake simulations should include clear escalation routes, because employees may reasonably question whether a familiar voice or face is authentic. Simulation content should never create real financial transactions, request genuine credentials or expose an employee to avoidable reputational harm.

A fair program also needs an appeal and correction process. Employees should be able to challenge a result, report a misleading scenario, request an accommodation and ask for inaccurate records to be corrected.

Security leaders should review aggregate outcomes quarterly, retire scenarios that create confusion and adjust training when a department's reporting time worsens or repeated errors persist. Employees who learn that reporting leads to private coaching rather than discipline are more likely to report real incidents.

Replace punitive scorecards with coaching that reaches employees at the moment a phishing simulation exposes a gap, using Adaptive Security's personalized cybersecurity awareness training.

Explore the platform

How Should Organizations Measure Risk Reduction Within Privacy Limits?

A phishing simulation tool produces credible evidence of risk reduction when repeated employee behavior connects to operational outcomes. Establish a defensible baseline, compare like-for-like cohorts and campaigns, analyze trends over time and validate simulation results against genuine reporting and response data.

Treat the findings as directional evidence rather than proof that phishing simulations alone caused every improvement. Campaign difficulty, staffing changes, scanner interference and parallel security controls all affect results, which is why measurement design deserves the same discipline as phishing simulation tool data privacy configuration.

1. Establish a Baseline and Design Comparable Cohorts

Run a baseline campaign before changing cybersecurity awareness training, simulation frequency or reporting workflows. Record the exposed population, delivery channel, campaign theme, difficulty, send time, click rate, credential-submission rate, report rate, time to report and remediation status.

One campaign creates a fragile baseline, so comparable activity should repeat before anyone draws conclusions. A behavioral pattern and an unusual result look identical after a single exercise.

Segment data by role, department, seniority, location, employment status and channel. Finance employees facing vendor-payment requests should never be measured against engineers receiving fake developer notifications.

Email, vishing and smishing simulations require separate baselines because decision pressure and reporting mechanics differ. Preserve cohort definitions so quarterly results reflect the same type of population.

Control the experiment where practical. Keep campaign difficulty within a defined range, document new hires and departures, exclude security scanners that automatically open links and record technical delivery failures.

Mark seasonal conditions such as year-end finance activity, holidays and major organizational changes. Record simultaneous initiatives, including new multifactor authentication, email controls, policy changes and manager-led training, because each one competes for credit in the results.

NIST's 2025 incident response guidance treats continuous improvement as a core part of cybersecurity risk management, which makes disciplined measurement more useful than a pass-fail score. A privacy-conscious phishing simulation tool should separate identity from reporting wherever possible.

Restrict individual records to authorized administrators, define retention periods before launch and give analysts only the fields required to remediate a specific risk. Measurement quality and phishing simulation tool data privacy improve together under that structure.

2. Analyze Longitudinal Trends Without Overstating Causation

Measure change across repeated, like-for-like campaigns. One lower click rate proves very little on its own, while the relationship between unsafe interaction and reporting behavior shows real movement.

A healthy program produces fewer unsafe actions and more timely reports. Track time to report from delivery or first interaction, then examine median and upper-percentile performance, because delayed reports from a small group can leave an active cyber threat exposed.

Repeat susceptibility is another essential signal. Identify employees who fail more than once within a defined period, track whether targeted remediation is completed and measure subsequent behavior.

Completion alone does not show risk reduction. An employee who finishes a five-minute module and repeats the same action has left the behavioral gap open, so post-remediation performance should be compared with that employee's own baseline and with a matched cohort.

Use rolling averages or control charts to reduce campaign noise. An apparent improvement after a campaign that reaches fewer people, uses an easier lure or excludes mobile users demonstrates nothing about behavior.

Annotate every chart with population changes, delivery anomalies, scanner interference and major security initiatives. Report causation carefully with phrases such as "coincided with" or "is consistent with," unless the program uses a credible controlled design.

A useful dashboard connects four layers:

• Exposure: Who received the phishing simulation and through which channel;
• Behavior: Clicks, submissions, reports and time to report;
• Intervention: Cybersecurity awareness training assignment, completion and repeat susceptibility;
• Risk operations: Whether analysts received cleaner, earlier signals.

That structure keeps completion rates from standing in for behavioral evidence. A reviewer can see in one screen whether exposure fell or only attendance rose.

3. Connect Phishing Simulation Results to Operational and Business Outcomes

Simulation metrics become credible when they change how the security team works. Compare reported-phish volume with the percentage correctly classified, analyst triage time, false-positive rates, escalation rates and time from report to containment.

Where reporting rises while malicious messages are identified sooner and repetitive tickets decline, the program is improving detection workflow. That is a stronger claim than a falling click rate, and it rests on operational data the security team already holds.

Track genuine incidents separately from simulations. Measure how many real suspicious messages employees report, how quickly they report them, how many are confirmed malicious and how many require broad remediation.

Simulated and genuine events belong in separate success rates. Phishing simulations rehearse behaviors that should appear during real cyberattacks, so genuine reporting provides the validation signal.

Translate results into business terms without assigning unsupported savings. Show the number of high-risk employees remediated, the proportion of repeat susceptibility cases closed, hours of manual triage avoided and response-time improvements for confirmed malicious messages.

For each business unit, connect reduced exposure to the processes at stake, such as invoice approval, payroll changes, privileged access or sensitive data handling. These measures give executives a clearer view than a single organization-wide click percentage.

Use human risk reporting to present individual data privately and board-level trends collectively. Boards need aggregate movement by department and channel, material exceptions, unresolved repeat susceptibility, operational improvements and a dated action plan.

A public leaderboard or a list of employees who clicked serves no governance purpose. End every reporting cycle with a decision: increase targeted practice for a cohort whose time to report remains high, adjust campaign difficulty when results are distorted, investigate a rise in genuine incidents or retire a control that produces no measurable improvement.

Completion rates measure attendance while cyberattackers measure response time. Adaptive Security reports time to report, repeat susceptibility and remediation progress by department and channel.

Take a self-guided tour

How Does Data Privacy Change for Multi-Channel and AI-Personalized Phishing Simulations?

Phishing simulation tool data privacy becomes more complex when testing expands beyond email into voice, SMS, deepfake video and AI-personalized scenarios. Email-only testing typically processes work addresses, delivery records, click activity and reporting behavior, while multi-channel programs can also process phone numbers, voice recordings, likenesses, device metadata, message logs and third-party data.

Email simulations create a narrower privacy perimeter and weaker preparation for vishing, smishing, deepfake impersonation and AI-generated spear phishing. According to the Sumsub 2025–2026 Identity Fraud Report, sophisticated multi-step attacks rose from 10% to 28% of identity fraud cases, an increase of 180%. Multi-channel programs answer that shift when they use the minimum data required, define each purpose clearly, limit access and delete records on a fixed schedule.

How Should Voice and SMS Phishing Simulations Protect Employee Data?

Voice and SMS simulations introduce identifiers that employees and existing policies often treat differently from email data. A vishing simulation can involve a personal or corporate phone number, call-routing information, call duration, recording metadata, transcript text, voice characteristics and delivery status.

A smishing simulation can generate message logs, carrier records, device information, link-interaction data and evidence that a message reached a shared or family device. Each of those fields needs its own justification before the campaign runs.

The collection notice should identify the channel being tested, explain whether calls or messages are recorded, describe the behavioral signals being measured, name the people who can review the results and state when records will be deleted. Security leaders should prohibit personal numbers unless the organization documents a specific need and lawful basis.

An alternative route should exist for employees who cannot reasonably separate work and private communications. A managed device or a work-issued number usually solves the problem without a policy exception.

Voice recordings should have short retention periods or be deleted immediately after scoring. Transcripts should be redacted where the full conversation adds nothing to the training decision.

Organizations implementing multi-channel phishing simulations should configure data collection around the training decision rather than around every signal the platform can capture. The UK Information Commissioner's Office guidance on biometric recognition explains that biometric processing requires a lawful basis and a separate condition when special-category biometric data is involved under UK GDPR.

A voice simulation is not biometric processing in most configurations. Using voice characteristics to identify or authenticate a person changes that analysis, so the safer design simulates the request while creating no reusable employee voiceprint.

What Controls Should Govern Deepfake Likeness and AI Content?

Deepfake video raises a distinct governance issue, because a realistic scenario can use an employee's face, voice, name, job title or public appearance. In 2024, an Arup employee transferred approximately $25 million after joining a video call populated by deepfake participants, according to CNN's report on the Hong Kong fraud.

The attempted impersonation of Ukraine's former foreign minister, Dmytro Kuleba, in a call with U.S. Sen. Ben Cardin illustrated the same risk in a government context, according to NBC News. These incidents justify realistic rehearsal while setting limits on likeness collection and storage.

Organizations should establish approval boundaries before using a generative AI simulation engine. Executive likenesses should require written authorization, finance and legal review and a documented list of permitted scenarios.

Simulations should avoid depicting medical conditions, political beliefs, protected characteristics, family members, private locations or other sensitive attributes. Human review must occur before delivery, because generated content can contain an inaccurate title, an inappropriate request or a message that creates reputational harm.

Vendor contracts should disclose whether prompts, recordings, images, transcripts and simulation results are processed by third-party models. Contracts should also prohibit customer data from training general AI models unless the customer provides explicit, informed authorization for that separate purpose.

The European Data Protection Board's Opinion 28/2024 on AI models states that whether an AI model is anonymous requires a case-by-case assessment and that legitimate interests must be evaluated in context. That analysis belongs in procurement and deployment records, where a reviewer can find it alongside the DPIA.

How Should OSINT-Personalized Phishing Simulations Minimize Data?

Open-source intelligence (OSINT) refers to information collected from publicly available sources. Public availability leaves the appropriateness question open, because a profile detail can be findable and still irrelevant to a training decision.

An AI-personalized spear-phishing scenario might use a job title, professional biography, conference appearance, office location, reporting line or publicly listed vendor relationship. Family information, home addresses, political activity, health details, unrelated photos and data purchased from opaque third parties all stay out of the scenario.

Minimization starts with an approved attribute list. For each scenario, the security team should record why an attribute is needed, whether a less sensitive substitute would produce the same training effect, where the information came from and how long it will remain in the system.

Personalization should sharpen the decision point. A finance exercise needs an invoice workflow or supplier relationship, and nothing resembling a worker's private social history.

The same rule applies to third-party data. Customer records, supplier contact lists, applicant information and personal data imported from HR or CRM systems should remain excluded unless the scenario has a documented purpose and separate approval.

Access should be restricted by role, and exports should omit raw OSINT fields wherever a risk score or scenario outcome supports the action. An analyst assigning remediation rarely needs the source material behind the lure.

What Privacy Governance Should a Modern Cybersecurity Awareness Training Program Require?

Modern AI-powered cybersecurity awareness training should pair broader cyberattack realism with narrower, documented data collection. Before enabling vishing, smishing, deepfake video or OSINT personalization, the organization should complete a purpose and lawful-basis review, update its collection notice, define retention by data type, establish role-based access and document deletion checks.

The review should specify whether employees can opt out of likeness use, whether a scenario crosses jurisdictions and how incidents involving real customer or third-party data will be contained. A documented alternative channel should exist where a phishing simulation would otherwise reach a personal device or expose private communications.

Human review remains the final control. Administrators should approve each scenario, verify that generated details are relevant and accurate, suppress sensitive attributes, confirm that the delivery channel is authorized and ensure that results reach only the people who need them.

Realistic simulations expose how trust operates across email, voice, SMS, video and public information. Disciplined governance keeps the exercise from collecting more personal data than the training decision requires, so a works council reviewing the program finds scenario approvals and deletion dates rather than an undocumented likeness library.

When a deepfake or vishing scenario reaches an employee, the likeness data behind it needs a named owner. Adaptive Security governs multi-channel scenario approval and retention.

Book a demo

How Does Privacy by Design Apply to Phishing Simulation Tools?

A phishing simulation tool can build employee capability without creating an unnecessary surveillance record. Programs that collect only signals tied to a defined security purpose, restrict access, shorten identifiable retention and apply human review give employees relevant practice without eroding trust.

The European Data Protection Board's privacy-by-design guidance defines the approach as building data protection into systems from the start and maintaining those protections throughout processing. Applied to phishing simulation tool data privacy, that principle converts each configuration decision into a durable control rather than a one-time setup task.

How Should Human Risk Signals Be Limited to a Clear Purpose?

Purpose-limited signals keep human risk management inside a controlled feedback loop. A program might record whether someone opened a simulated email, reported it, completed assigned microlearning or resisted a follow-up vishing simulation.

Those events directly support safer training, measurement of resistance to AI-generated social engineering and identification of channel-specific exposure. Every additional field needs to earn the same justification.

Security leaders should define which signals are necessary for a stated outcome, such as improving phishing recognition among finance staff or measuring whether executives verify an urgent payment request. Browsing history, private communications, unrelated performance data and sensitive personal attributes stay outside the program unless a documented legal and security purpose requires them.

Every phishing simulation signal should be tied to a stated cybersecurity awareness training outcome, because available data usually exceeds necessary data.

Data minimization also changes how results are presented. Security teams may need identifiable records to assign remediation, investigate a reported simulation or provide human review after an unusual result.

A board normally needs aggregate trends by department, role, channel and time period. Separating those two views shows whether resistance is improving while keeping training data out of hidden employment scores.

How Does Privacy-Aware Adaptive Cybersecurity Awareness Training Work?

Privacy-aware adaptive training connects a narrow behavioral signal to the smallest effective intervention. An employee who reports a simulated spear phishing email correctly can skip unnecessary retraining, while someone who repeatedly misses smishing scenarios receives a short mobile-focused lesson.

A finance employee who complies with a synthetic voice request should rehearse independent verification in the following exercise. Generic annual content answers none of those three situations well.

This approach treats employees as active participants in defense. Realistic simulations expose the decisions people face, and proportional remediation gives them a practical skill to use during a real incident.

A security awareness training program built around personalized microlearning should make clear what was measured, why the lesson was assigned and how improvement will be assessed. Transparency matters most where simulations use OSINT, AI-generated phishing emails, voice cloning or deepfake video.

Privacy controls must match the sensitivity of each signal. Role-based access can give a training manager remediation data while limiting executives to department-level trends, and encryption, audit logs and separation between training records and unrelated HR files reduce secondary-use risk.

Human review should remain available when an automated score triggers an escalation. A missed simulation can reflect accessibility needs, language barriers, a technical error or a scenario mismatched to the employee's role, and only a person reviewing the underlying events will catch those causes.

Signals collected without a defined purpose become a permanent behavioral file. Adaptive Security ties every phishing simulation signal to a named remediation action and a deletion date.

Explore the platform

How Adaptive Security Supports Phishing Simulation Tool Data Privacy

Adaptive Security runs realistic multi-channel testing and governed record-keeping inside one system, so phishing simulation tool data privacy decisions stay visible to the people accountable for them. Phishing Simulations cover email, voice, SMS and deepfake scenarios with OSINT and AI-generated spear phishing, and each scenario carries its own approval, audience scope and reporting configuration.

Results feed Security Awareness Training as role-based microlearning rather than a public scorecard. Automated assignment, manager escalation and per-framework tracking produce the completion, scenario and remediation evidence auditors request, exportable by framework, employee or date range.

Two adjacent controls close the remaining gaps that phishing simulations alone cannot reach. Cloud Email Security applies AI-driven phishing and BEC detection with automated remediation to genuine inbound messages, and AI Governance surfaces shadow AI use and personal-account data risk, which helps control sensitive data exposure from employees using generative AI tools.

Adaptive Security converts phishing simulation results into role-based cybersecurity awareness training assignments, compliance evidence and department-level reporting inside one governed record set.

Book a demo

Frequently Asked Questions About Phishing Simulation Tool Data Privacy

Are Individual Phishing Simulation Results and Risk Scores Personal Data Under GDPR?

Yes. Individual phishing simulation results and risk scores are generally personal data under GDPR when they relate to an identifiable employee, including through an account, email address or learner ID. Article 4 of the General Data Protection Regulation defines personal data broadly enough to cover information connected to an identified or identifiable person. A click, report, simulated submission, training record or repeated susceptibility pattern can also contribute to behavioral profiling. Truly aggregated statistics and data irreversibly stripped of identifiability fall outside GDPR, while pseudonymized records stay in scope.

What Legal Basis Can an Employer Use for Phishing Simulations, and Is Employee Consent Valid?

An employer will often assess legitimate interests under GDPR Article 6(1)(f) for proportionate phishing simulations, while employee consent is generally unreliable as the default because the employment relationship creates a power imbalance. The EDPB guidance on lawful processing requires an identified interest, a necessity assessment and a balancing of employee rights. A security obligation under law or contract can support specific processing while leaving deceptive tests and indefinite individual scoring unjustified. Consent is valid only when it is genuinely voluntary, specific, informed and withdrawable without disadvantage under GDPR Article 7.

Do Phishing Simulations Require a Data Protection Impact Assessment?

A data protection impact assessment (DPIA) is required when planned processing is likely to create a high risk to employees' rights and freedoms. GDPR does not make every phishing simulation subject to a DPIA. GDPR Article 35 identifies high-risk processing as the trigger. Repeated individual scoring, large-scale workforce monitoring, cross-system enrichment, sensitive data exposure or automated employment decisions can each increase that risk. The EDPB DPIA guidance supports documenting the screening decision even when a full DPIA proves unnecessary.

How Long Should a Phishing Simulation Tool Retain Individual Results and Behavioral Risk Scores?

A phishing simulation tool should retain individual results and behavioral risk scores only for the shortest period necessary to deliver remediation, measure defined trends and satisfy documented audit obligations. GDPR sets no universal number of days. Its storage-limitation principle requires personal data to remain identifiable only as long as the stated purpose requires. Delete or irreversibly aggregate data once the purpose ends, and apply the same rule to exports, backups and vendor copies.

Can a Phishing Simulation Platform Use Anonymous or Pseudonymous Learner IDs for Compliance Evidence?

Yes. A phishing simulation platform can use pseudonymous learner IDs for compliance evidence, and that evidence remains personal data while an organization can reconnect an ID to an employee. GDPR Article 4(5) defines pseudonymization as separating identifying information from the data and protecting the linkage. Store the re-identification key separately, restrict it to authorized personnel and report aggregate completion and trend evidence wherever individual identity adds nothing. Anonymous evidence qualifies only when re-identification is not reasonably possible.

Review how governed phishing simulations, compliance training and reporting work together across one record set with a self-guided tour of Adaptive Security.

Take a self-guided tour