Why Phishing Risk Thresholds Matter in 2026

Ten employees have repeatedly failed phishing simulations. Security wants mandatory follow-up training; HR worries that a rigid response will feel punitive and damage trust. The disagreement is understandable—but without clear phishing risk thresholds, the organization has no consistent, defensible way to decide when a pattern of behavior requires additional intervention.

A single click does not necessarily indicate carelessness. Employees face increasingly convincing social engineering, including impersonation, credential-harvesting pages, QR-code lures, and urgent business-email requests that closely resemble legitimate work. Yet repeat failures, especially on higher-risk simulations or after prior coaching, can expose a meaningful gap that attackers may exploit.

At the same time, regulatory, audit, customer, and cyber-insurance expectations increasingly require organizations to show that security awareness is not merely an annual checkbox. Teams need evidence that they identify employee phishing risk, apply proportionate remediation, and follow through when the same risks persist. Leaving repeat failures unmanaged can create operational risk as well as a weak audit trail.

Well-designed thresholds turn an emotional, case-by-case debate into a repeatable decision process. They can account for failure frequency, simulation difficulty, job role, access level, prior training completion, and signs of improvement—rather than treating every click as equally serious. This makes it possible to trigger targeted, timely support before a risky pattern becomes an incident.

This guide will help security awareness managers, IT managers, HR, and compliance teams establish defensible phishing risk thresholds, automate follow-up security training, protect employee morale, and document escalated interventions. The goal is phishing simulation remediation that reduces real-world risk while remaining fair, explainable, and aligned with workplace policy.

Most importantly, phishing simulation results should support learning and risk reduction—not automatically become a disciplinary scorecard. Escalation should be proportionate, transparent, and paired with practical help so employees can recognize and report the next threat with confidence.

What a Phishing Risk Score Should Measure

A phishing risk score should identify a meaningful, actionable pattern—not label an employee as “the person who clicked once.” A single simulation failure can result from an unusually convincing lure, a rushed workday, an ambiguous scenario, or a test that differs substantially from prior campaigns. It is a useful coaching signal, but it is rarely enough on its own to justify mandatory follow-up security training.

Employee phishing risk becomes more meaningful when results show repetition, severity, and limited improvement over time. For example, repeated credential entry during comparable simulations after targeted coaching presents a different level of concern than one link click in a difficult campaign followed by prompt reporting and strong performance thereafter. A practical score should help teams see that difference clearly before applying phishing risk thresholds.

Useful scoring inputs may include:

Failure frequency: the number and rate of failures across an appropriate review period, rather than the raw total from one campaign.
Recent versus historical results: recent events should generally carry more weight, while longer-term history shows whether risk is improving, stable, or recurring.
Reporting behavior: reporting a suspicious message, especially before interacting with it, is a protective behavior that should reduce—not increase—the employee’s risk score.
Credential-entry or sensitive-action behavior: entering credentials, approving a simulated multifactor prompt, downloading a file, or submitting sensitive information usually reflects greater potential exposure than opening an email or clicking a link.
Simulation difficulty: scores should account for whether the message was a basic awareness test or a sophisticated, role-relevant impersonation attempt.
Role and privilege level: employees with administrative access, payment authority, access to sensitive records, or the ability to change vendors may warrant more protective support because the impact of compromise is higher.
Exposure to targeted attacks: finance, HR, executives, IT administrators, and customer-facing teams may receive more realistic or frequent attacks in real life; their score should reflect exposure without automatically penalizing the role.
Completion of prior remediation: whether the employee completed assigned coaching, demonstrated comprehension, and improved in later simulations helps distinguish an unresolved gap from a corrected one.

These inputs should not simply be added together as if every simulation were identical. Scores must be normalized across campaigns. Comparing an employee who received a highly targeted credential-harvesting simulation with another who received a simple generic lure is not fair or analytically sound. Use campaign-level baselines, difficulty ratings, and comparable cohorts where possible. A failure rate, severity-weighted result, or percentile within a similar campaign is more defensible than a raw count of clicks.

It also helps to separate the components of a score so that decision-makers understand why someone reached a follow-up threshold:

Leading indicators: missed training, delayed reporting, repeated low-severity interactions, and lack of improvement after coaching.
Outcome indicators: credential entry, sensitive-data submission, simulated payment approval, malware-download behavior, or repeated failures in comparable campaigns.
Contextual modifiers: simulation difficulty, role-based exposure, privileged access, campaign assignment frequency, leave status, and completed remediation.

Finally, phishing simulation remediation data should be handled as sensitive workforce information. Collect only the data needed to reduce security risk, limit access to authorized security, HR, and compliance stakeholders, and retain results according to a documented schedule. Employees should be told what is measured, how scores are used, who can view them, and what support or appeal path is available. Policy transparency and data minimization make follow-up security training more credible—and help ensure that phishing risk thresholds remain a fair tool for risk reduction rather than a hidden disciplinary mechanism.

Defining Actionable Phishing Risk Thresholds

Phishing risk thresholds should translate simulation results into timely, proportionate support. They are not universal disciplinary cutoffs, and they should never be based on a single raw percentage without context. Start with the organization’s own campaign baselines, role-based exposure, simulation difficulty, and historical outcomes; then calibrate the thresholds as data shows which interventions actually improve safer behavior.

The four-tier model below creates a clear path from routine awareness to formal review. It also separates follow-up security training from employment action: most employees should move through coaching and role-relevant remediation before any cross-functional escalation is considered.

Tier	Suggested indicators	Intervention	Owner	Time frame	Exit criteria
Tier 1: Normal variation	One low- or moderate-severity failure in a defined period; performance within the normal range for a comparable campaign or cohort; no credential submission; or a strong reporting history that offsets an isolated interaction.	Send routine awareness messaging, a short learning reinforcement, and a clear reporting reminder. Do not label the employee high risk or require formal training solely because of this event.	Security awareness team or automated learning platform.	Immediately or within 5 business days of the simulation.	Message or microlearning completed, if assigned; no recurring pattern in subsequent comparable simulations; or employee demonstrates positive reporting behavior.
Tier 2: Targeted follow-up	A first meaningful failure, such as credential entry, a simulated sensitive-data submission, or a click on a role-relevant high-quality lure; one failure after a prior routine reminder; or results materially worse than the employee’s comparable cohort.	Assign just-in-time coaching that explains the specific cue missed, provides a short scenario-based exercise, and asks the employee to practice reporting. Keep the response supportive and narrowly tailored to the behavior.	Security awareness manager, with the employee’s manager copied only when policy requires it.	Assign within 1–3 business days; complete within 7–14 days.	Targeted module completed; employee acknowledges the reporting process; and no equivalent high-severity action in the next defined review period or comparable simulation.
Tier 3: Mandatory role-based training	Two failures in a defined rolling period, such as 90 or 180 days; failure after assigned remediation; repeated credential submission; repeated risky actions across comparable simulations; or a severity-weighted score above the organization’s high-risk threshold. Elevated privileged access, payment authority, or sensitive-data access may justify faster protective intervention when paired with meaningful risk behavior.	Require role-based phishing simulation remediation, such as finance payment-fraud scenarios, administrator credential-harvesting drills, or HR data-request exercises. Include a documented coaching conversation and a follow-up assessment. Consider temporary, proportionate technical safeguards where appropriate.	Security awareness lead with the employee’s manager; IT/security operations for access-related safeguards.	Assign within 2–5 business days; complete training within 14–30 days; reassess in the next relevant simulation cycle.	Mandatory training and assessment completed; no repeat of the triggering behavior during the defined monitoring period; improvement relative to comparable cohort performance; and any temporary safeguards reviewed for removal or continuation.
Tier 4: Coordinated formal review	Only policy-defined, substantiated criteria: repeated Tier 3 outcomes despite completed support; repeated credential submission after remediation; intentional bypass of security controls; refusal to complete required training; or a pattern that creates material risk because of highly privileged access. A simulation result alone should not establish misconduct.	Conduct a coordinated review of risk, support provided, technical controls, policy requirements, and relevant employee context. Determine whether additional training, access changes, manager support, HR processes, compliance review, or another documented response is appropriate. Preserve due process and an appeal or correction path.	Security, manager, HR, compliance, and legal or privacy stakeholders as required by policy.	Initiate promptly after criteria are validated; set a documented review timeline, typically within 10 business days.	Case closed through a documented, proportionate decision; required support and safeguards completed; access and workforce actions reviewed under applicable policy; and a defined reassessment date established.

Use the indicators as decision guides, not automatic triggers. For example, “two failures in 90 days” may be a reasonable Tier 3 starting point only if employees had comparable opportunities to receive simulations and the campaigns were similarly difficult. An employee assigned one sophisticated simulation who fails it has a very different evidence base from an employee who repeatedly enters credentials across several comparable tests.

Likewise, do not escalate an employee solely because they have a low raw percentage in a small sample. A 0% reporting or 100% failure rate based on one message is statistically thin and can be misleading. Review the number of simulations received, lure severity, relevant role exposure, prior coaching, improvement trend, and positive actions such as reporting suspicious messages. This prevents employee phishing risk from being overstated by sparse or uneven data.

Before putting the model into production, document each threshold, the evidence required to move between tiers, who may approve an exception, and how long records remain active. Review outcomes quarterly: if Tier 2 coaching reliably reduces repeat failures, preserve it; if a threshold captures too many employees who quickly improve, adjust it. This calibration process makes phishing risk thresholds defensible, improves phishing simulation remediation, and gives security, HR, and compliance teams a shared basis for action.

How to Set Thresholds Without Overreacting

Calibrating phishing risk thresholds is an evidence-and-governance exercise, not a search for the lowest possible tolerance for clicks. The goal is to identify employees who need effective follow-up security training while avoiding automatic escalation for normal variation, uneven testing exposure, or circumstances that make a result unreliable. Start conservatively, measure whether interventions work, and change the policy only when the organization’s own results support the adjustment.

Use a repeatable calibration process

Establish a baseline from several campaigns. Use results from multiple campaigns—ideally including different lures, difficulty levels, and delivery periods—before finalizing a high-risk cutoff. Calculate comparable rates for reporting, clicks, credential entry, and completion of remediation. One campaign can reveal a problem; it cannot reliably define normal behavior.
Segment results by role and exposure. Compare employees with peers who face similar message volume, business processes, access, and simulation scenarios. A finance team receiving payment-change lures should not be measured against a low-exposure team that receives generic awareness tests.
Choose a rolling observation window. A 90-, 180-, or 365-day window can show whether risk is recent and recurring rather than permanent. Weight recent behavior more heavily, but retain enough history to see whether targeted coaching produced improvement. Resetting every month may hide a pattern; retaining old events indefinitely may unfairly preserve a resolved issue.
Set minimum sample sizes. Do not classify someone as high risk from one message. Define a minimum number of comparable simulation opportunities before using a rate-based threshold, such as three relevant simulations in a rolling period. If the sample is smaller, use education and manual review rather than an automated escalation.
Test false positives and false negatives. Review employees who would have been escalated: did they actually repeat risky actions after coaching, or did they improve immediately? Also review employees who were not escalated but later demonstrated repeated high-severity behavior. Too many false positives wastes manager and HR capacity; too many false negatives leaves meaningful risk unsupported.
Pilot the policy before broad enforcement. Run proposed phishing risk thresholds in “shadow mode” for one or two campaign cycles. Record who would have received each tier, have security and HR review edge cases, and compare outcomes against the current process before sending mandatory assignments.
Review outcomes quarterly. Assess completion rates, repeat failure rates, reporting behavior, employee feedback, exception requests, and whether role-based training changes later performance. Adjust the threshold, observation window, or training path when the evidence shows that the current rule is too sensitive, too lenient, or inequitable.

Role risk should influence the type and speed of support, not create a presumption that people in certain jobs are careless. A finance administrator may need a faster response to simulated payment-diversion or vendor-bank-change behavior because a real compromise could move funds quickly. A help-desk agent may need practice verifying identity and resisting password-reset or MFA-bypass requests. An executive assistant may need training on impersonation, calendar requests, and urgent wire or document workflows. A developer may benefit from scenarios involving source-code access, OAuth consent, cloud consoles, or dependency notices. A privileged administrator may require credential-harvesting drills, out-of-band verification procedures, and temporary protective controls after a severe event because administrative credentials can have broad impact.

Those distinctions do not require harsher treatment. They require role-relevant phishing simulation remediation, proportionate safeguards, and thresholds that account for both likelihood and impact. For example, a single high-severity credential-submission event by a privileged administrator may justify immediate coaching and an access review, while still not constituting misconduct or an automatic HR case.

Combine signals instead of relying on a single click count

A concise decision rule makes the policy consistent while preserving human review for high-impact decisions:

if employee.reported_before_interaction:
    risk_adjustment = -1
else:
    risk_adjustment = 0

score = (recent_failure_frequency × 2)
      + severity_of_action
      + unresolved_remediation_history
      + role_risk_modifier
      + risk_adjustment

if sample_size < minimum_comparable_campaigns:
    assign supportive coaching; do not auto-escalate
elif severity_of_action is critical:
    assign immediate role-based training and human review
elif score >= mandatory_training_threshold:
    assign mandatory follow-up security training
elif score >= targeted_coaching_threshold:
    assign targeted coaching
else:
    provide routine reinforcement

In this model, severity should distinguish a reported message, a link click, credential entry, simulated sensitive-data submission, and a privileged or payment-related action. Remediation history should reflect whether prior training was completed and whether comparable behavior improved afterward—not merely whether an employee has ever been assigned a module.

Build fair handling into the threshold policy

New hires and contractors often lack enough observations for a meaningful employee phishing risk score. Give them onboarding education and role-specific practice, then delay rate-based classification until the minimum sample is met. Contractors should be covered by the same protective training expectations where their access and work justify it, while escalation ownership and contractual requirements are documented in advance.

Pause or contextualize scoring for employees on extended leave, employees returning from leave, and people who were unavailable during assigned remediation. Do not treat non-completion caused by an approved absence as refusal. Offer a reasonable catch-up period and reassess after current, comparable opportunities are available.

Accessibility and language needs must be addressed before interpreting results. Training, simulations, reporting tools, and deadlines should be accessible and understandable for the employee. Provide approved accommodations, translated or plain-language materials where appropriate, and alternate learning formats. If a simulation or assigned module was not reasonably accessible, the result should not be used as a threshold trigger without review.

Finally, recognize reporting as a positive security behavior. An employee who reports a suspicious message before clicking should receive credit even if the message was a simulation. If someone reports after an interaction, preserve that signal as well: prompt reporting can reduce real-world impact and may indicate that coaching should focus on verification before action rather than punitive escalation.

Pre-publication checklist for security and HR

What behaviors and severity levels count toward each threshold, and which behaviors require human review?
What minimum number of comparable simulations is required before automated escalation?
How are campaign difficulty, role exposure, and unequal assignment frequency normalized?
What rolling window applies, how are recent events weighted, and when do resolved events expire?
How does completed remediation and demonstrated improvement reduce the score?
How are reports, near-misses, and positive security actions credited?
What accommodations, language support, leave exceptions, and contractor processes apply?
Which decisions are educational, which require manager involvement, and which may involve HR or compliance?
What appeal, correction, and data-access path is available to employees?
Which quarterly measures will prove that follow-up security training reduces risk without over-escalating employees?

Publishing answers to these questions alongside the thresholds gives employees and managers a clear expectation: the program is designed to reduce risk through timely support, not to turn a single phishing simulation result into a disciplinary verdict.

Integrating Follow-Up Training Into Security Workflows

A defensible remediation process turns a phishing simulation result into a closed, auditable support workflow—not an automatic disciplinary event. The workflow should apply the phishing risk thresholds already approved by security, HR, compliance, and privacy stakeholders, while leaving high-impact employment or access decisions to people. ATTACK Simulator can automate the timely, repeatable steps: capture the result, update the employee phishing risk score, assign the appropriate learning path, and verify whether the employee met the defined exit criteria.

From simulation event to verified closure

Capture and normalize the event. When a simulation ends, ATTACK Simulator records the employee identifier, campaign and scenario, delivery date, action taken (reported, clicked, opened, entered credentials, or submitted data), severity, and any mitigating behavior such as prompt reporting. Match the record to the active identity rather than relying on an email address alone, so transfers, name changes, and duplicate accounts do not create misleading histories.
Calculate or update the risk score. Apply the organization’s approved scoring rules, including recent comparable failures, severity, prior remediation status, role context, minimum sample requirements, and positive reporting behavior. The system should mark low-confidence results—such as an employee with too few comparable simulations—as “coaching only” rather than automatically classifying the person as high risk.
Select the intervention path. If the updated score crosses a defined phishing risk threshold, ATTACK Simulator can trigger just-in-time training for the exact behavior observed or role-based training for the employee’s work context. For example, a finance employee who acts on a simulated vendor banking-change lure can receive payment-fraud verification training; an administrator who enters credentials can receive credential-harvesting and MFA-resistance training. A lower-risk event may receive a brief reinforcement instead of a mandatory assignment.
Notify the employee privately. Send a neutral, supportive message through the approved email or collaboration channel. The notice should explain the assigned learning, due date, support contact, and how to request an accessibility, language, leave, or technical exception. Avoid broadcasting results to peers, copying broad distribution lists, or using shame-based wording.
Deliver and track the training. Pass the assignment to the learning management system (LMS), or launch approved training directly where supported. Completion, assessment results, and accommodations status should flow back to ATTACK Simulator so the security awareness team has one remediation record rather than manually reconciling spreadsheets.
Schedule a relevant retest. After a reasonable learning interval, enroll the employee in a comparable follow-up simulation or assessment. Do not retest immediately merely to generate a score. The retest should measure the same decision skill—such as verifying payment requests or reporting credential lures—without reusing the identical message.
Evaluate exit criteria and close the case. Close the automated remediation record when the employee completes the assignment, meets any required assessment standard, and satisfies the policy’s monitoring or retest criteria. Record the closure date, evidence, risk-score change, and any temporary safeguards that should be reviewed or removed.

What to automate—and what to review

Automation is appropriate for consistent educational and administrative actions: scoring against approved rules, assigning a standard module, sending private reminders, opening a low-severity remediation ticket, scheduling a retest, and updating a dashboard. It is also appropriate for notifying a security awareness owner when an assignment cannot be delivered or completed.

Human review is required before an action could materially affect employment, access, or reputation. A security awareness manager should review critical simulation actions, repeated outcomes after completed support, disputed records, accessibility or leave exceptions, and any proposed access restriction. HR-related escalation must have a documented approval step from the designated security owner and HR or employee-relations representative. A simulation result alone must never automatically create a disciplinary case, notify HR, or trigger a punitive manager notification.

Recommended integration pattern

Identity and access management: Use an identity provider or HR identity source for authoritative employee IDs, manager relationships, department, role, employment status, and access-risk attributes. Provisioning changes should pause, reassign, or close training appropriately when someone transfers or leaves.
Learning management system: Exchange assignment, due date, completion, assessment, and accommodation data. Keep the learning content in the LMS when it is the system of record, while ATTACK Simulator retains the simulation and remediation decision trail.
Ticketing platform: Create tickets for exceptions, failed delivery, overdue mandatory training, or human review queues. Tickets should contain only the minimum necessary simulation details and should use restricted access groups.
Email and collaboration tools: Deliver private employee notices and limited reminders through approved channels such as email or a direct collaboration message. Notify managers only when policy requires their support, after ensuring the record is accurate and the employee has received the initial private notice.
Reporting dashboards: Send de-identified or aggregated trends to leadership dashboards, including threshold crossings, completion, retest improvement, exception rates, and time to closure. Restrict named employee reporting to staff with a legitimate operational need.

Workflow safeguards that prevent over-escalation

Build deduplication into the workflow so one campaign does not create multiple assignments, tickets, and reminders for the same employee. Use a case key based on employee, triggering behavior, campaign window, and intervention type; merge related events into one open remediation case where policy permits. Set notification limits as well—for example, an initial notice and a small number of spaced reminders—then route unresolved cases to a human queue instead of repeatedly messaging the employee.

Exception handling must be explicit. Pause deadlines for approved leave, accessibility needs, language support, technical delivery failures, or a documented dispute about identity or simulation conditions. Do not count an incomplete assignment as noncompliance until the exception is resolved and a reasonable new due date is provided. Preserve an immutable audit log of the triggering event, score inputs, threshold version, automation actions, notices, approvals, exceptions, human decisions, and closure evidence.

Finally, review the workflow itself each quarter. Measure whether just-in-time and role-based phishing simulation remediation improves retest performance, reduces repeat high-severity actions, and closes cases without unnecessary HR escalation. If a rule creates excessive reminders, duplicate tickets, or mandatory training for employees who quickly improve, adjust the rule before expanding automation. The strongest workflow uses ATTACK Simulator to make follow-up security training prompt and consistent while keeping consequential decisions proportionate, reviewable, and human-led.

Balancing Remediation With Employee Morale

Follow-up security training works best when employees experience it as timely coaching tied to a real decision—not as a penalty for being tricked. Phishing risk thresholds should identify where additional support is needed, but the resulting workflow should preserve dignity, explain the reason for the assignment, and give people a practical way to improve. This approach supports the behavior the organization needs most: pausing, verifying, and reporting suspicious activity early.

Send the initial notification privately to the employee through an approved direct channel. Use plain language that explains what happened at an appropriate level of detail, what learning is required, why it is relevant to the employee’s role, and when it must be completed. Avoid loaded labels such as “failure,” “noncompliant,” or “careless.” A score is a risk-management signal based on defined rules; it is not a judgment about an employee’s character, commitment, or competence.

Make corrective training practical and respectful

Keep lessons short and relevant. Assign a focused module or scenario-based exercise on the observed skill, such as verifying a payment change, spotting a credential-harvesting page, or reporting an impersonation request. Do not respond to one event with a long, generic annual course.
Use role-specific examples. Finance teams need realistic vendor and invoice examples; help-desk staff need identity-verification practice; administrators need credential, MFA, and privileged-access scenarios. Relevance makes remediation useful rather than performative.
Provide accessible options. Offer captioned video, screen-reader-compatible content, keyboard navigation, transcripts, translated or plain-language materials where appropriate, and an alternate format or session when needed.
Set reasonable completion windows. Give employees enough time to complete the assignment around normal workload, approved leave, travel, and shift patterns. Send limited, spaced reminders and provide a clear process to request an extension.
Allow questions and corrections. Every notice should name a support contact and explain how to dispute an inaccurate result, report a technical issue, request an accommodation, or describe an ambiguous simulation condition.

Managers should receive guidance before they are asked to support completion. Their role is to protect time for the employee to complete the learning, reinforce the importance of safe decisions, and direct questions to the security awareness team. They should not demand explanations in a group setting, speculate about intent, or turn a simulation result into an informal performance discussion. Where manager notification is necessary, it should be limited to the minimum information needed to support the assignment.

Sample private notification

Subject: Required phishing-safety learning

Hello [Name],

Your recent phishing-simulation activity exceeded our current phishing risk threshold for follow-up support. To help you recognize and safely handle similar messages, please complete the assigned [training name] by [date]. The lesson takes approximately [time] and focuses on [relevant skill or scenario].

This assignment is designed to strengthen safer decision-making and reporting—not to assign blame. If you believe the result is inaccurate, had a technical issue, need an accessibility or language accommodation, or need more time, contact [support contact] by [date].

Thank you for helping protect the organization and reporting suspicious messages whenever something does not look right.

Avoid practices that suppress reporting

Public leaderboards, surprise shaming, and broad manager or team notifications may create a short-term incentive to avoid visible mistakes, but they can also teach employees to hide them. When people fear embarrassment, they may be less likely to report a suspicious message after clicking, disclose a possible credential submission, or ask for help quickly. Those are precisely the moments when rapid reporting can reduce real-world harm.

Similarly, excessive simulation volume can create fatigue and skepticism, especially when campaigns arrive during high-pressure business periods or repeatedly use unclear, edge-case scenarios. Employees may begin treating every message as a test instead of performing their work, while teams lose confidence that the program measures a realistic decision. Use enough simulations to establish a meaningful employee phishing risk pattern, but space them appropriately and vary them according to role and exposure.

Automatic disciplinary action is particularly damaging. A phishing simulation result can reflect a mistake, a rushed but understandable business context, a technical malfunction, an accessibility barrier, an identity-matching error, or a simulation whose ambiguity exceeded the organization’s stated standard. Making discipline automatic turns phishing simulation remediation into a punitive system and weakens trust in both security and HR.

Separate intent from error before escalating

Most threshold crossings should lead to education, coaching, or proportionate protective controls—not an allegation of misconduct. Before considering a policy or HR escalation, require human review of the simulation evidence, the score inputs, prior support provided, the employee’s explanation, and relevant technical records.

Mistakes or knowledge gaps: A person clicked an urgent-looking link, entered simulated credentials, or missed a verification step. Assign relevant training, permit questions, and assess improvement over later comparable opportunities.
Technical or process issues: The message rendered incorrectly, the reporting button failed, the employee was using an approved workflow that made the scenario misleading, or the training was inaccessible. Correct the issue, invalidate or contextualize the result where appropriate, and reset the deadline.
Ambiguous simulations: The lure lacked clear decision points, relied on information employees could not reasonably verify, or conflicted with normal business practice. Review the scenario design before using it as evidence of elevated risk.
Potential intentional violations: Deliberate circumvention of a known security control, sharing credentials despite clear policy and training, or repeated harmful conduct after validated coaching may warrant a separate investigation. Even then, use established HR, legal, compliance, and security procedures rather than treating a score alone as proof of intent.

A trustworthy remediation program makes it safe to learn and safe to report. When employees understand that phishing risk thresholds trigger relevant support, fair review, and a genuine chance to improve, follow-up security training becomes a risk-reduction tool rather than a source of fear.

Aligning Risk Scores With HR and Compliance Policies

Before enforcing phishing risk thresholds, security, HR, legal, privacy, compliance, and business leadership should agree on what the score is for—and what it is not for. Its primary purpose should be to identify where an employee, role, or business unit may benefit from timely follow-up security training, coaching, or proportionate safeguards. A phishing simulation score is a risk-management input with limits; it is not a measure of employee value, loyalty, intelligence, or overall job performance.

Phishing simulation performance must not become a hidden employment metric. Do not quietly feed individual scores into performance rankings, compensation decisions, promotion discussions, workforce reductions, or informal manager assessments. If an organization believes an employment consequence may be appropriate in an exceptional case, that action must follow established policy, documented investigation and review procedures, collective bargaining obligations where applicable, and applicable employment, privacy, and anti-discrimination law. A simulation result alone is not proof of misconduct or intent.

Decisions to make before scores trigger action

Purpose and scope: Define the approved uses of employee phishing risk scores, such as assigning follow-up security training, measuring program effectiveness, and identifying aggregate control gaps. Explicitly prohibit unapproved employment and surveillance uses.
Data ownership and system of record: Identify which team owns simulation events, scoring logic, training completion data, HR identity attributes, and exception records. Define which system is authoritative when data conflicts.
Access to individual results: Limit named results to people with a legitimate operational need: typically designated security awareness staff, limited IT administrators, and HR or compliance reviewers only when a defined escalation requires them. Business leaders should normally receive aggregated trends, not employee-level dashboards.
Retention and deletion: Set separate retention periods for raw simulation telemetry, risk scores, remediation cases, completed training records, and audit logs. Retain records only as long as needed for the approved purpose, legal obligations, and defensible review, then securely delete or de-identify them.
Approved interventions: Specify which actions may follow each threshold: coaching, short role-relevant training, a retest, a temporary protective control, or human review. Require approval before any intervention affects access, employment status, or reputation.
Appeal and correction rights: Give employees a clear route to challenge an inaccurate result, technical fault, misleading scenario, identity error, accessibility issue, or deadline affected by leave. Define who reviews the appeal, expected response times, and how corrected records are handled.
Manager involvement: State when managers are informed, what minimum information they receive, and what they must do—usually protect time for training and support completion. Prohibit public discussion, informal punishment, and requests for personal explanations.
Disciplinary boundaries and exceptions: Distinguish routine mistakes from potential intentional policy violations. Define exceptions for leave, accommodations, language needs, technical failures, role transfers, shared accounts, and disputed results.

Document the policy, not just the score

A defensible program documents four connected controls. First, a threshold policy defines score bands, confidence requirements, triggering events, approved actions, notification rules, and human-review gates. Second, an intervention matrix maps each threshold and behavior to the least intrusive effective response—for example, a brief coaching module after one moderate-risk event and a reviewed role-specific learning plan after repeated, validated high-severity events.

Third, maintain a role-risk taxonomy that explains why certain roles receive different scenarios or follow-up. Finance, payroll, executives, help desk, developers, and privileged administrators may face different phishing exposures, but role context should tailor education and protective controls—not lower the fairness standard or presume greater fault. Finally, establish a review process for score accuracy, disparate outcomes, exception trends, scenario quality, access logs, and policy changes. Review at least quarterly and whenever a material workflow, legal, organizational, or technology change occurs.

Mini RACI-style responsibility model

Security awareness team — Responsible: Designs simulations and learning, administers the scoring model, operates phishing simulation remediation workflows, and monitors whether interventions improve behavior.
IT and identity teams — Responsible/Consulted: Maintain secure integrations, authoritative identity matching, role and manager data feeds, access controls, logging, and technical exception support.
HR — Accountable/Consulted for employment matters: Approves boundaries for manager involvement, accommodations coordination, employee-relations escalation, and any employment-related process.
Compliance, privacy, and legal — Consulted/Approver: Review lawful use, proportionality, record retention, employee notice, cross-border data handling, regulatory obligations, and material policy exceptions.
Business leadership — Accountable for sponsorship: Funds the program, reinforces a learning-first culture, receives aggregate risk reporting, and ensures managers have time to support training.
Managers — Responsible for support: Make time for assigned follow-up security training, avoid blame-based handling, and route disputes or concerns to the designated reviewers.
Employees — Responsible for participation: Complete assigned learning, report suspected phishing promptly, request help or accommodations when needed, and use the appeal process if a result appears inaccurate.

With these guardrails in place, phishing risk thresholds can drive consistent follow-up security training without creating an opaque disciplinary system. The result is a process that is explainable to employees, manageable for leaders, and credible to HR, privacy, legal, and compliance stakeholders.

Documenting and Reporting Escalated Interventions

Once a phishing risk threshold triggers an escalated intervention, create a case record that shows how the decision was made, what support was offered, and how the case was resolved. The record should make the process reproducible and reviewable without turning a phishing simulation remediation workflow into unnecessary employee surveillance. Record validated facts, decision points, and approvals—not subjective comments about attitude, character, or presumed intent.

Maintain a minimum intervention audit record

Use a unique case identifier and retain the minimum information necessary to explain each escalation. Link supporting simulation and training evidence rather than copying sensitive data into email threads or manager notes. At a minimum, each record should contain:

Event date and case creation date: When the simulation event occurred and when the intervention workflow began.
Campaign and difficulty: The campaign identifier, scenario type, delivery channel, targeted role context, and documented difficulty level.
Observed behavior: The validated action, such as opening, clicking, credential submission, attachment interaction, reporting, or a technical error affecting the result.
Score inputs: The events, time window, weighting, prior validated outcomes, and role-risk factors used to calculate the employee phishing risk score.
Applicable threshold: The approved phishing risk threshold or rule that triggered review, including the policy version in force at the time.
Assigned action: The least intrusive approved response, such as targeted coaching, follow-up security training, retest, protective control, or human review.
Notification date: When the employee was notified, the approved delivery method, due date, and whether a manager received limited support-only notification.
Training completion: Completion date, assigned learning version, accessibility alternative if used, and any approved extension.
Retest result: The comparable follow-up scenario, result, date, and whether the result indicates improvement, continued support needs, or an invalid test condition.
Exceptions and disputes: Leave, accommodation, language, technical, identity-matching, role-change, scenario-quality, or appeal information, along with the outcome.
Approvals: Named approver roles, dates, and rationale for any exception, enhanced control, HR referral, or other non-routine action.
Final disposition: Closed after improvement, closed with an approved exception, training reassigned, retest pending, control adjustment made, or referred to a separate established process.

Do not use the case file as a shadow performance record. Where a case requires employee-relations review, keep that investigation in the appropriate HR system and link only the minimum reference needed to show that the phishing program handed off the matter through approved channels.

Report patterns, not names

Routine reporting should emphasize program trends and control effectiveness rather than identifying individuals. Aggregate results by business unit, role family, location, campaign type, or risk band only when the group is large enough to avoid easy re-identification. Suppress small groups, combine categories where needed, and avoid filters that allow a viewer to infer a named employee from a single result. Operational staff with a documented need may access individual cases, but executives and most managers should see aggregate data.

Use rates and distributions alongside counts. For example, a rise in escalations may reflect a larger campaign population, a harder scenario, or better data validation rather than worsening employee behavior. Add campaign volume, difficulty, target population, and policy-version context to every trend report so leaders do not draw conclusions from a single percentage.

Build dashboards for three different audiences

Operational dashboard: Restricted to the security awareness, IT, and designated HR or compliance operators who administer cases. Show open interventions, notification status, overdue follow-up security training, time to remediation, retest queues, exception aging, and escalation outcomes. Permit individual case drill-down only for authorized users and log that access.
Executive dashboard: Show aggregate risk direction and business impact: repeat-failure rate, phishing reporting rate, median time to remediation, training completion rate, retest improvement, high-risk role coverage, and overall escalation outcomes. Highlight material trends, control gaps, and resource decisions; exclude employee names, case narratives, and small-population breakdowns.
Compliance dashboard: Focus on process integrity: percentage of escalations with complete audit fields, threshold-policy version coverage, approval timeliness, exception volume and categories, retention status, access-log exceptions, appeal outcomes, and evidence of periodic review. This view should demonstrate that interventions followed approved rules consistently and proportionately.

Define metrics precisely. Calculate repeat-failure rate as the percentage of participants with a validated repeat threshold event in a stated period; calculate reporting rate as reports divided by delivered simulations or other clearly stated denominator. Measure time to remediation from validated trigger to completed assigned action, and retest improvement as movement from a comparable baseline behavior to a safer outcome. For high-risk role coverage, report the percentage of identified high-exposure roles that received appropriate simulations, training, or protective controls—not the percentage of people labeled high risk.

Review exception volume carefully. A cluster of accessibility requests, identity errors, or scenario disputes may identify a process defect, not an employee problem. Likewise, escalation outcomes should distinguish completed improvement, approved exceptions, invalidated events, pending cases, and referrals. This makes it possible to improve phishing risk thresholds and scenario design without overstating failure.

Preserve evidence with strict access and retention limits

Preserve evidence needed to validate an escalation: the campaign configuration, simulation event log, scoring-rule version, notification record, training assignment and completion data, retest evidence, exception decision, approvals, and immutable access logs. Store those materials in approved systems with role-based access, encryption, audit logging, and separation between routine awareness records and sensitive HR or legal records. Do not export case data into spreadsheets, shared drives, chat channels, or unrestricted ticket queues.

Apply a written retention schedule to each record type. Keep raw telemetry, case records, training completion evidence, and access logs only for the period justified by the remediation purpose, internal policy, contractual obligations, legal holds, and applicable law. At the end of that period, securely delete the data or de-identify it for aggregate program analysis. Pause deletion only when a documented legal hold or active review requires preservation, then resume the approved schedule once that requirement ends.

A complete but proportionate record gives security, HR, and compliance a shared factual basis for action. More importantly, privacy-conscious reporting keeps the program focused on reducing employee phishing risk, improving reporting behavior, and proving that mandatory follow-up training is fair, effective, and accountable.

Worked Example: Ten Repeat Failures

Assume a quarterly dashboard identifies ten employees with repeated phishing simulation failures. Security sees the group as evidence that mandatory follow-up security training is overdue; HR is concerned that a raw “repeat failure” count could overlook leave, role changes, unequal campaign difficulty, accessibility needs, or unreliable data. The four-tier model resolves this by treating the dashboard as a review queue—not an automatic disciplinary list.

Start with validation, not escalation

For each of the ten employees, the security awareness team should first verify the facts behind the employee phishing risk score. Count the validated failures and their timing. Two credential-submission events in two comparable campaigns within 90 days may indicate a different level of concern than two clicks separated by 18 months. Confirm the severity of each action as well: opening an email, clicking a link, entering credentials, approving a multifactor prompt, or opening a simulated attachment should not receive identical weight.

Prior learning: Was the assigned baseline or prior targeted training completed before the later simulation? Was it role-relevant, available in the employee’s required language, and accessible?
Role exposure: Does the employee work in finance, payroll, recruiting, executive support, IT administration, or another role that receives more frequent or more realistic lures? Higher exposure can justify more support, but does not establish greater blame.
Campaign comparability: Were the events from campaigns with comparable difficulty, delivery channel, timing, and scenario type? A sophisticated credential-harvesting simulation and a basic awareness test should not be treated as interchangeable.
Reporting behavior: Did the employee report suspicious messages in other campaigns, report the simulation after clicking, or otherwise demonstrate safer behavior? Reporting is useful context and should be credited rather than ignored.
Data quality: Check identity matching, duplicate records, shared mailbox or device issues, email-delivery logs, role-transfer dates, test exclusions, technical faults, and whether the employee was on leave when training or testing occurred.

Suppose this review reduces the initial list. One record is a duplicate identity match, one occurred during approved leave, and one involves a new employee who had not yet received baseline training. Those cases should be corrected, deferred, or routed to ordinary onboarding rather than escalated. The remaining seven cases now have validated evidence, but they still do not all require the same intervention.

Apply the four tiers proportionately

Use the preapproved phishing risk thresholds and intervention matrix to classify the validated cases. Tier 1 represents routine or isolated low-severity behavior and usually calls for standard awareness reinforcement. Tier 2 captures emerging risk, such as a repeat low-severity event or a single more consequential action, and may trigger coaching, a short learning module, or practical reporting guidance.

Tier 3 is the appropriate threshold for mandatory targeted training when the documented criteria are met: repeated, validated, comparable failures within the policy window; a severity level defined by the program; prior opportunity to complete relevant learning; and no unresolved exception that invalidates the result. For example, four of the seven validated employees may have clicked or submitted credentials in multiple comparable simulations after completing earlier training. Assign those employees mandatory role-relevant follow-up security training and a comparable retest after a reasonable completion period. The objective is to confirm improvement, not to create a punitive record.

The other three validated employees may warrant a different response. An employee who promptly reported the simulation after an initial click may benefit from brief coaching on stopping and reporting sooner. A payroll specialist facing unusually realistic payment-diversion scenarios may need a role-specific verification workflow, manager-supported practice, or an additional protective control alongside training. An employee with a documented accessibility, language, or workload issue may need an alternative learning format or an approved extension. These are still meaningful phishing simulation remediation actions, but they are tailored to the observed risk and context.

Tier 4 should remain narrow. Route only unresolved cases that meet policy-defined conditions for HR or compliance review—for example, a failure to complete mandatory Tier 3 training after documented notice and reasonable support, a repeated Tier 3 outcome after retesting, an allegation of intentional policy circumvention, or a case requiring an employment-policy decision. A simulation result by itself should never trigger disciplinary action.

Resolve security and HR disagreement through the matrix

If security argues that all ten employees should receive the same mandatory intervention while HR argues for no escalation, neither team should negotiate each person’s outcome from scratch. They should review the preapproved intervention matrix, the threshold-policy version in effect, and the validated case evidence. The matrix answers the operational question: given this combination of failure count, timing, severity, prior training, role exposure, reporting behavior, and exceptions, what is the least intrusive approved response?

Security owns the accuracy of simulation evidence and the effectiveness of the follow-up security training. HR confirms that the proposed action fits employment policy, accommodations, notice, and employee-relations boundaries. Compliance or privacy reviewers join only when the matrix requires their approval or a policy exception is involved. Document the final tier, the evidence reviewed, the assigned intervention, and any exception rationale. This shared, rule-based approach makes phishing risk thresholds consistent while preserving the human judgment needed to treat employees fairly.

Implementation Checklist for Security Teams

Use this checklist to turn phishing risk thresholds into a consistent, support-focused workflow. The goal is not to automate punishment. It is to identify validated repeat-risk patterns, deliver proportionate follow-up security training, and confirm that safer behavior improves over time.

Before launch

Define the rolling window: Document how long prior simulation events remain relevant—for example, 90, 180, or 365 days—and specify how role changes, leave, and new-hire onboarding affect the calculation.
Approve the threshold matrix: Set clear criteria for routine reinforcement, targeted coaching, mandatory follow-up training, and the narrow circumstances that require human review. Include failure severity, repeat events, campaign comparability, prior learning opportunity, and reporting behavior.
Check role-risk data: Validate role family, business unit, exposure level, manager, location, and start-date data. Use role risk to tailor support and controls, not to assume employee intent or assign blame.
Assign accountable owners: Name the security awareness owner, system administrator, HR policy contact, compliance or privacy reviewer, manager-support contact, and escalation approver. Define who can approve exceptions and who closes cases.
Configure automated training: Build the trigger, assignment, due-date, reminder, completion capture, and comparable retest workflow. Provide accessible, language-appropriate alternatives and a documented extension path.
Set access and retention controls: Restrict individual case data to authorized operators, separate HR records from awareness records, and apply approved retention periods to event evidence and case files.

During each campaign

Validate campaign tags: Confirm the campaign identifier, scenario type, delivery channel, difficulty rating, target population, and policy version are recorded before launch. These fields make later comparisons defensible.
Test notifications end to end: Send test messages to confirm that trigger notices, training assignments, reminders, manager support notices, and completion confirmations reach the correct audience without exposing unnecessary personal data.
Confirm exclusions and identity matching: Review leave, approved accommodations, new-hire status, shared-mailbox issues, duplicate identities, technical delivery failures, and campaign exclusions before scoring outcomes.
Monitor for scenario defects: Track delivery anomalies, broken landing pages, misleading simulation configuration, and unusually high dispute volume. Pause automated escalation when a material campaign-quality problem is under review.
Apply thresholds only to validated results: Allow the workflow to create a review queue, but do not assign mandatory follow-up security training until the required data-quality checks and exceptions review are complete.

After a threshold breach

Recalculate the employee phishing risk score: Verify the rolling-window events, severity weights, comparable campaign criteria, prior training status, and any positive reporting behavior.
Review exceptions before action: Check for approved leave, accessibility or language needs, role transfers, incomplete onboarding, technical errors, disputed results, and other conditions that require deferral, correction, or an alternative intervention.
Assign the least intrusive approved response: Use coaching or targeted guidance for emerging risk; assign mandatory training only when the documented phishing risk thresholds are met. Add role-specific verification procedures or protective controls where they address the actual exposure.
Notify clearly and respectfully: Explain the required action, due date, available support, privacy boundaries, and appeal or exception route. Keep manager notifications limited to the support they must provide.
Track remediation and retest: Record assignment, completion, extensions, and a comparable follow-up simulation or behavioral check. Escalate overdue items through the approved workflow rather than informal manager pressure.
Close with a documented outcome: Mark the case as improved, retest pending, exception approved, invalidated, reassigned, or referred to a separate HR process. Do not treat completion alone as proof of reduced risk.

Quarterly review

Review threshold performance: Compare escalation volume, false-positive or invalidated cases, exception patterns, and outcomes by campaign difficulty and role context. Adjust rules only through documented governance.
Measure improvement after remediation: Compare post-training retest behavior with a comparable baseline, not merely with overall campaign averages or a different simulation type.
Review owners and service levels: Check whether validations, notifications, training assignments, approvals, and case closures occurred within expected timeframes. Reassign ownership when bottlenecks appear.
Audit workflow integrity: Sample cases for complete evidence, correct policy-version use, appropriate access, timely exception decisions, and consistent intervention selection.
Refresh training and scenarios: Retire modules that do not change behavior, update role-specific content, and address recurring failure modes such as credential entry, attachment handling, or delayed reporting.
Report aggregate findings: Share trends, control gaps, and resource needs with leadership while suppressing small groups and avoiding named-employee reporting outside authorized operational use.

Success metrics that demonstrate remediation works

Comparable retest improvement: The percentage of remediated employees who move from a validated unsafe action to a safer outcome in a comparable follow-up scenario.
Repeat-failure reduction: The change in validated repeat threshold events within the defined rolling window among employees who received intervention.
High-severity action reduction: The decline in credential submissions, risky attachment interactions, or other policy-defined high-impact behaviors after targeted remediation.
Reporting behavior improvement: The increase in timely reporting of suspicious messages, including reporting after recognizing an error.
Median time to remediation: Time from validated threshold breach to completed training, coaching, control change, or approved exception decision.
Durability of improvement: The percentage of employees who maintain safer behavior across later comparable campaigns, rather than improving on only one retest.
Exception and invalidation rate: The proportion of escalations corrected because of data, accessibility, leave, or scenario-quality issues. A rising rate may signal a workflow defect rather than better employee performance.

Next step: Assess your current phishing risk thresholds and implement an automated follow-up training workflow for repeat failures. Start with validated events, a clearly defined rolling window, named owners, and a comparable retest so the program can demonstrate genuine risk reduction—not simply training completion.

Frequently Asked Questions

How many phishing failures should trigger mandatory training?

There is no universal number. Mandatory follow-up security training should be triggered by a calibrated pattern: validated repeat failures within a defined rolling window, comparable campaign difficulty, meaningful action severity, and evidence that the employee previously had a reasonable opportunity to complete relevant learning. For example, two credential-submission events within 90 days may justify a different response than two low-severity clicks over 18 months. Measure whether the intervention improves later behavior, then adjust phishing risk thresholds through documented governance.

Should every employee have the same threshold?

Use consistent core rules, but do not assume identical context. Employee phishing risk should be assessed using the same validated evidence standards while accounting for role exposure, campaign type, onboarding status, prior training access, language, accessibility, and positive reporting behavior. Finance, payroll, executive support, and IT administrators may face higher-risk lures and need more specialized practice or protective controls. Role risk should tailor remediation and support; it should not lower due-process standards or become a shortcut for assigning blame.

When should HR be involved?

HR should help establish the intervention matrix before launch and become involved when a case raises employment-policy, accommodation, leave, fairness, or repeated non-completion concerns. Security should normally own simulation validation and phishing simulation remediation; HR should confirm that notices, extensions, documentation, and any further escalation follow policy. A simulation result alone is not a disciplinary finding. Involve HR before an action could affect employment status, and keep case access limited to people with a legitimate operational need.

How can teams avoid training fatigue?

Make follow-up security training short, targeted, and tied to the observed behavior. An employee who entered credentials needs a different intervention from someone who clicked but reported immediately. Avoid repeatedly assigning the same generic module, especially after low-severity events. Combine concise learning with role-specific examples, a practical verification step, and a comparable retest after enough time to apply the lesson. Track completion, retest improvement, repeat-failure reduction, and reporting behavior. If those measures do not improve, redesign the remediation rather than increasing volume.

What should happen if an employee disputes a simulation result?

Pause automatic escalation and provide a clear, confidential review route. Verify identity matching, delivery and landing-page logs, campaign configuration, shared-mailbox or device issues, leave status, accessibility needs, and whether the event was correctly scored. The reviewer should document the evidence, decision, policy version, and any correction or exception. If the result is validated, explain the proportionate next step and available support; if it is invalidated, remove it from the employee’s phishing risk calculation. Aggregate dispute trends can also reveal simulation-quality or workflow defects that require correction.

Conclusion: Escalate Consistently, Remediate Constructively

Effective phishing risk thresholds are not a shortcut to punishment. They are a documented decision point for proportionate support when validated evidence shows repeated risky behavior in context. A single click, an unclear simulation, or an event during onboarding should not carry the same weight as repeated high-severity actions after an employee has had access to relevant learning and a fair opportunity to improve.

The operating sequence should be clear and repeatable: establish a baseline, apply defined phishing risk thresholds to validated results, assign targeted automated training when the threshold is exceeded, conduct a comparable retest, review outcomes through governance, and report aggregate trends to leadership. This process makes follow-up security training defensible while helping teams distinguish genuine employee phishing risk from data-quality issues, accessibility needs, or campaign defects.

ATTACK Simulator can help operationalize this workflow by connecting threshold breaches to just-in-time and role-based phishing simulation remediation. Use it to support timely learning assignments, reminders, completion tracking, and follow-up testing that reflects the behavior and exposure involved. Keep human review, approved exceptions, and HR or compliance decisions where they belong: in the governance process, not in an automated disciplinary response.

Take action now: Security, IT, HR, and compliance leaders should assess their current phishing risk thresholds, confirm that they account for repeated behavior and context, and implement an automated follow-up training workflow for repeat failures. Measure improvement with comparable retests and documented outcomes so remediation reduces risk constructively—not merely training completion.

The new `25 release for phishing simulations

There’s no reason to postpone training your employees

Get a quote based on your organization’s needs and start building a strong cyber security infrastructure today.

Get a quote