Phishing Awareness Training That Actually Works in 2026

Most phishing awareness training is a slide deck about spelling mistakes, delivered once a year, in a year when the mail is written by a language model and the login page is an exact copy of the real one. The people who fail the test are then treated as the problem. That model does not survive contact with the attacks actually arriving in inboxes: an adversary-in-the-middle proxy does not break your one-time code, it relays it; a consent grant steals a mailbox without a password at all. What does work is narrower and less comfortable. Accept that training cannot stop every click. Decide which four kinds of request must be verified out of band no matter who appears to be asking. Count reports rather than clicks. And write the first hour after a click as a runbook, so nobody has to invent it at 9pm. This is that programme, in full.

Start with what training cannot fix

Training competes against a technical gate, and the gate is usually weaker than the lesson. If a static password plus a six-digit code is all that stands between an attacker and the mailbox, an adversary-in-the-middle proxy will walk through it without cracking anything: the victim types the real password into a page that happens to sit behind the attacker, the real code arrives at the victim's phone, the victim types that too, and the proxy forwards both to the genuine service and keeps the session cookie that comes back. The code was correct. The password was correct. The account is gone anyway.

Three controls make everything downstream easier, and they belong in the programme's first slide because they explain why the lesson is not "be more careful":

• Phishing-resistant authentication. FIDO2 security keys or passkeys bound to the real origin. A proxy cannot relay a signature that is cryptographically tied to a domain it does not own, which is precisely the property a one-time code lacks. Put it on the identity provider and the mailbox before anything else; on finance and IT admin accounts first if you must stage the rollout.
• Sender authentication with an enforced policy. DMARC at p=reject on your own domains, SPF and DKIM aligned, plus an external-sender banner so staff can see that a message claiming to be the CEO did not come from your tenant. None of this stops a lookalike domain, and all of it removes the easiest impersonation.
• The ability to revoke. Session and refresh-token revocation, mailbox rule inspection and OAuth grant review, available to whoever answers the phone at 9pm. A containment step that requires a vendor ticket does not exist.

The honest framing for a board is this: training moves two numbers, the share of staff who click and the time it takes someone to report. Neither goes to zero. The second number is worth more than the first, and almost no programme measures it.

The lure families that make visual inspection useless

"Check the sender, hover the link, look for urgency" was good advice against 2016 phishing. It is close to useless against the current set, because each of the families below has been engineered to pass exactly those checks. A programme that teaches only the checklist produces people who feel trained and still hand over a mailbox.

Two consequences follow. First, the lesson cannot be "spot the fake" - several of these are indistinguishable from the real thing by design. Second, the only reliable defence is procedural: a small number of request types that always trigger a second channel, every time, even when the request looks perfect and even when the person asking is senior and in a hurry. That is a policy with a script, not a habit of suspicion, and it is what the next section turns into.

Four questions, and four requests that always need a second channel

The lesson that survives contact with all eight families above fits on one page. Four questions, asked in order, take about fifteen seconds:

1. Who is asking, and is this the channel they normally use for this? A bank does not ask for a password by email; a supplier does not change bank details by email alone; IT does not hand out remote access through a link.
2. What does the action hand over? Money, a credential, an approval, remote access, or a file. Naming the asset is what turns a vague feeling into a decision.
3. Is it reversible in ten seconds? Opening a document and reading it is reversible. Approving an MFA prompt, granting an app permission, paying an invoice and pasting a command into a run dialog are not.
4. Can I verify through a channel I already had before this message arrived? A number from your own records, a message in the team chat, a walk to the next desk. Never a number, link or address supplied by the message itself.

Then the rule that makes it enforceable. These four request types are verified out of band every single time, with no discretion and no exceptions for seniority:

Give people the script for the awkward moment, because verification fails in practice for social reasons, not technical ones: "I am not doubting you - this is the process for anything that moves money. I will call you on the number I have and we can do it in two minutes." A programme that does not supply that sentence leaves every employee improvising a refusal to their own manager, and most will not.

The fifth habit is reporting, and it needs to be reframed explicitly: the target is not "never click". It is "tell us within the hour, especially if you clicked". Every hour of silence is an hour of the attacker's access, and the difference between a contained incident and a breach is almost always how fast somebody said something.

Measuring the programme: report rate leads, click rate lags

The published benchmarks look contradictory until you read their denominators. KnowBe4's 2025 phishing benchmarking report, built on 67.7 million simulations across 14.5 million users and 62,460 organisations, puts the baseline phish-prone percentage at 33.1% globally before any training, falling to 4.1% after twelve months of continuous training and simulation. Verizon's 2025 Data Breach Investigations Report, working from more than 100,000 campaigns, reports a median click rate of 1.5% per campaign and - the number that matters more - roughly 21% of recipients reporting a simulated phish where recent training had happened, against a base rate near 5%. Fortra's 2025 benchmark of 14 million recipients lands at 5.42% clicking, 1.99% submitting credentials, and only 10.5% reporting.

Those are not competing claims. One measures people who have never been trained, one measures the median campaign of organisations that already run simulations, one measures a vendor's customer base. What they agree on is the shape of the problem: the click rate in a mature programme plateaus, the report rate is the number that keeps moving, and the report rate is what actually catches real attacks. A staff member who clicks and reports in four minutes has cost you a password reset. A staff member who clicks and says nothing has cost you the quarter.

One discipline makes these numbers trustworthy: keep the difficulty comparable. If this month's campaign was an obvious fake and last month's was a two-line thread hijack, the improvement is an artefact. Record the lure family and its difficulty with every campaign, and compare like with like.

Running simulations lawfully, and without poisoning the well

This is the section that stops European programmes dead, and the one almost no vendor page mentions. Simulating a phishing attack on your own employees is generally lawful, but it is not automatically lawful, and the conditions are not technical.

• Consult before you send. In Germany a works council has codetermination rights over monitoring technology and over conduct rules, and simulation results are employee monitoring. Similar consultation or information duties exist in other EU states and under many collective agreements. Do this first: a campaign launched without it can be stopped mid-flight, and the record of who clicked may have to be deleted.
• Treat the results as personal data. Which named employee clicked is personal data under the GDPR, and arguably behavioural data at that. That needs a lawful basis, a documented purpose, proportionality, a retention period and an access rule. Aggregate by team by default; individual records stay with security and HR under a written policy, not in a shared dashboard.
• Never capture what people type. A simulation whose landing page stores the submitted password is a credential-harvesting system you built and now have to secure. Use a benign landing page, disable form capture, and make the debrief the payload.
• Do not spoof domains you do not own. Several template libraries ship lures that impersonate real brands on lookalike domains. That creates a real DMARC and trademark problem, and it teaches staff that an authentic-looking external domain is normal.
• Coach, never punish. The moment a click carries a consequence - a note in a file, a mandatory remedial course, a mention in a review - reporting stops, and the silent clicker is the exact person an attacker needs. This is not sentiment; it is the measured reason report rates collapse in punitive programmes.
• Name the exclusion windows. No campaign against someone returning from leave, in their first week, under a performance process, or during an active incident. Write the stop rule down: if a real phishing wave is in progress, simulations pause.
• Keep the record. What was sent, to whom, when, which lure family, what the landing page did, and what the debrief said. That record is your defence if a simulation is ever challenged, and it is what an auditor asks for.

Transparency and realism are not in conflict here if you separate the two: announce the programme and its purpose, never the individual campaign. Staff who know that simulations happen monthly, and that a click produces a two-minute lesson rather than a black mark, report more, not less.

Programme architecture: roles, cadence, records

A programme that survives its first year has an owner, a scope and a calendar, and none of those is the training content. The owner is accountable for the numbers, usually the security lead, with HR owning the records and the consultation. The scope is everyone with a mailbox: employees, contractors, the executive team and the board, who are the most impersonated people in the organisation and the least likely to be tested. The calendar looks like this.

Two smaller design choices carry disproportionate weight. Every module ends with what to do, not what to fear: a report button, a phone number, a named person. And every module is written in the languages your staff actually read - a translated slide that reads like machine output is a signal that the programme is a formality, and staff treat it accordingly.

The reporting loop is the programme

Here is the failure mode that makes the whole exercise theatre: staff report, nothing visible happens, and within two months nobody reports. The lesson was fine; the response was absent. The loop below is what turns a report rate from 10% into something worth having.

1. One click to report, and it keeps the original. A report button in the mail client that forwards the message with full headers, not a screenshot and not a forward that loses them.
2. A triage owner and a time target. Someone is on rotation; first triage within fifteen minutes during business hours, an hour otherwise. "We will look at it tomorrow" is how a real attack gets a full working day of access.
3. An automatic acknowledgement. The reporter gets an instant reply saying the message was received and what happens next. Silence reads as "nobody cares", and the next report never comes.
4. A fleet-wide hunt, not a single-mailbox fix. The same message went to forty people. Search by sender, subject and URL across every mailbox, purge the unopened copies, and check who opened or clicked.
5. Feedback within one business day. What it was, whether it was malicious, what was done, and a thank you. This one message is what converts a reporter into a repeat reporter.
6. Containment for the people who clicked, without blame. The runbook below, run by security, with the clicker treated as the person who told you.
7. A monthly digest. "You reported 63 suspicious messages this month; 11 were real attacks; the fastest report took two minutes." Recognition at the level of the group, never a ranking of individuals.

If you can only fix one thing in an existing programme, fix this one. The lesson content is replaceable; the response is what teaches people that reporting is worth the effort.

The first hour after a click

Order matters, and the intuitive order is wrong. Changing the password first feels decisive and leaves the attacker's live session working, because a session token is not invalidated by a password change. Revoke first, then reset.

Two prohibitions belong in the runbook as well. Do not wipe or reinstall the machine before someone captures what is on it: the evidence of what the payload did is worth more than an hour of cleanliness. And do not send credentials, MFA codes or session links through chat or email while helping - that is the same attack arriving a second time, from a colleague's account, which is exactly how it spreads inside an organisation.

What the standards actually require

Most programmes are bought to satisfy a clause, so it is worth knowing what the clauses say. Verify the current edition and your own scope with counsel: numbering moves between revisions, and a sector regime can be stricter than the framework.

• NIST SP 800-53 (AT-2, AT-3). Awareness training for all users, role-based training for privileged and security roles, records of completion and refreshers. The control family expects content tied to the organisation's actual risks, which is why a generic annual module satisfies the paperwork and nothing else.
• ISO/IEC 27001:2022, Annex A 7.3. Awareness, education and training appropriate to the person's role, delivered on a schedule. Auditors ask for the programme document, the records and the management review, not the slide deck.
• PCI DSS v4.0, Requirement 12.6. An ongoing security awareness programme, education at least annually, an annual review, and the v4.0 addition that the programme must address phishing and related attacks, with simulations expected rather than optional.
• HIPAA Security Rule, 45 CFR 164.308(a)(5). A security awareness and training programme for the workforce, covering protection from malicious software and log-in monitoring, with periodic refreshers.
• NIS2 (EU 2022/2555), Article 20. Management bodies must approve and oversee the measures and receive training themselves, which puts the executive session on the compliance path rather than in the nice-to-have column.
• GDPR Articles 32 and 33. Training is part of the technical and organisational measures, and the ability to detect and report a breach quickly is the practical half of the notification duty. The training records are personal data too, which is the caveat most programmes forget.

The distinction that decides audits: a completion certificate proves attendance. What increasingly gets asked for is evidence of behaviour - the report rate trend, the time to first report, the response records for real messages. Build the reporting loop and the compliance file fills itself.

Build or buy: the questions that separate programmes from products

Both routes work at different sizes. Buying gets you a template library, a learning platform and reporting for a per-seat fee; building gets you control and, below roughly fifty people, a lower cost. What matters either way is what you demand of the thing you run.

The mistake on both sides is measuring the supplier instead of the outcome. A vendor review that asks "how many templates" is asking the wrong question; the one that asks "what will our report rate and median time to report look like in six months, and what does your product do to move them" gets a useful answer.

Where this meets the paid-help market, lawfully

Two things happen after a real click, and both attract people selling services. The first is legitimate: an organisation needs an external assessment - a controlled phishing engagement, a red team, or incident response under a proper letter of authorization. The second is fraud: the employee is contacted by someone offering to "clean the trace", "hack the hacker back", or "recover the account" for a fee paid in crypto.

A legitimate engagement is defined by paperwork before it is defined by tooling. Written authorization from the asset owner - not just the IT manager - naming the targets, the time window, the lure families permitted, the handling rules for any data encountered, the rule that harvested credentials are never used beyond demonstrating the finding, and an emergency stop. A tester who retains what they captured, targets employees' personal accounts, or touches a third-party supplier without that supplier's consent has stopped testing and started committing an offence.

The fraud has recognisable markers, and staff should meet them in the same module as the phishing lesson: they contact you first, they guarantee the outcome, they want payment in cryptocurrency, they ask for your password or a link to "verify", or they offer to hack someone else on your behalf. There is no lawful service that recovers an account by breaking into it; recovery runs through the platform, the identity provider, or the courts. If you bring in outside help after an incident, ask for the authorization letter, the scope and the data-handling terms before anything else. The hacker-for-hire engagement guide sets out what a proper letter contains, and the blog carries the platform-specific recovery paths if an account is already lost.

The short version

Training is worth doing, and it is worth doing as a procedure rather than a warning. Put phishing-resistant authentication in front of the mailbox so the lesson is not the only defence. Teach four questions and the four request types that always get a second channel. Run one short module and one simulation a month, record the difficulty, and never punish a click. Build the reporting loop - one click, fifteen minutes to triage, feedback within a day, a fleet-wide purge - because the loop produces the number that matters. Write the containment runbook in the order that ends an attacker's session. Then report the numbers monthly and stop calling completion a result. An organisation that reports a real phishing attempt in four minutes has a programme; one that completes its annual module and hears nothing has a certificate.