Security Awareness Training: Building a Programme That Survives an Audit

Every security awareness programme is sold on a number, and the number is usually the same one: a third of your staff will click a phishing email, then almost none of them will after a year of training. The 2025 edition of the largest vendor benchmark puts the global baseline at 33.1% phish-prone and the twelve-month figure at 4.1%, and those two numbers have been quoted into thousands of budget papers. What rarely travels with them is the methodology note in the same report: the baseline is measured across everyone, and the twelve-month figure is measured only on users who completed training and at least ten simulations. The curve is real. It is also measured by the party selling the training, on the population that stayed in the programme, using the library the programme was built from.

That is not a reason to skip awareness training. It is a reason to build a programme that does not depend on the curve being true. Verizon's 2025 Data Breach Investigations Report, covering 22,052 incidents and a record 12,195 confirmed breaches across 139 countries, still finds the human element in around 60% of breaches, and it also finds third-party involvement doubling from 15% to 30% - which means a growing share of the risk your staff face arrives through suppliers' staff rather than through their own judgement. The programme that survives contact with an audit and with a real incident is not the one with the best click-rate graph. It is the one that makes the safe action the fastest action, shortens the time between a mistake and a response, and can produce evidence a regulator, auditor or insurer accepts.

This guide is for the person who has to build or repair that programme in 2026: the IT manager handed the awareness budget, the compliance lead answering a NIS2 or ISO questionnaire, the HR partner who has been asked to approve phishing simulations, and the buyer comparing three platforms that all claim the same outcome. It covers what the evidence actually supports, which decisions are worth training, how to measure without lying to yourself, how to run simulations lawfully in the UK and the EU, what the standards require by clause rather than by marketing, and what to put in front of a board that has one slide of attention.

What the published numbers do and do not tell you

The Verizon figure and the vendor benchmark are measuring different things and are routinely added together. The DBIR's 60% is a classification of breach causes: incidents where an action by a person - a click, a misconfiguration, a mistaken transfer, a social-engineering conversation - contributed to the outcome. It is a statement about where losses come from, and its stability across years tells you the human element is structural rather than a training backlog. It does not tell you which training would have prevented which breach, because the report cannot observe the counterfactual.

The benchmark figure is a susceptibility metric under controlled conditions: a known-good template, sent by a vendor, to a population that has opted into measurement. Read that way, 33.1% falling to 4.1% is a claim about recognition of well-worn lures after repeated exposure, and the sharpest critique of it comes from the programme it describes. A user who has seen thirty-nine simulated invoices and correctly ignores the fortieth has demonstrated template familiarity as much as judgement, and the 2026 version of the same lure - delivered by a real supplier, in a real thread, with a real invoice attached - is a different test.

The third number a board will ask for is cost, and the honest answer is that awareness training does not have a clean return. What it has is a clean failure mode: an untrained organisation cannot recognise a campaign in progress, so it learns about the compromise from a customer, a bank, or a journalist. That is the value to argue - detection and speed - not a promised percentage reduction in clicks.

Why the field evidence is weaker than the vendor decks

The academic record on whether awareness training changes behaviour is more equivocal than either side admits, and a programme designed on the assumption of a large durable effect will be designed wrongly. The best-known longitudinal study - Caputo, Pfleeger, Freeman and Johnson's two-year examination of repeated spear-phishing at a US national laboratory, published in IEEE Security & Privacy in 2014 - followed the same population through repeated campaigns and embedded training, and did not find click rates falling in the way the training model predicts; experience in the organisation was not a reliable predictor of who clicked.

Two robust findings do survive the noise, and both are design instructions rather than discouragement. First, measured effects are largest immediately after a lesson and decay over the following months, which is an argument for spacing and for re-testing rather than for a longer annual course. Second, susceptibility is strongly situational: the National Cyber Security Centre's own guidance notes that people click for reasons including being busy and stressed, and that threatening punishment does not change those conditions. A person who clicks at 4:55pm on a Friday before a holiday is not demonstrating a training deficit; they are demonstrating workload.

The practical conclusion is the one the NCSC states in a sentence that should be printed on every awareness budget: no training package, including phishing simulations, can teach users to spot every phishing attempt, and asking them to examine every email in depth would leave no hours in the day for work. Training is a control with a real but bounded effect. Everything else in the programme exists to make sure the bound does not matter.

The three jobs a programme actually does

Strip away the content library and a security awareness programme has three functions, and only the first is what people mean when they say "training". The first job is to make the safe action the fastest action: a report button in the mail client, a one-click route to the security team, a callback number printed on the intranet that is faster to use than the payment request is to approve. If reporting takes four minutes and approving takes ten seconds, the programme is fighting the interface and will lose.

The second job is to shorten the interval between a mistake and a response. Almost every expensive incident has a window - hours, sometimes days - in which the organisation could have contained it if anyone had said something. A programme that produces one report per hundred staff per month and nobody triages it is worse than no programme, because it creates the appearance of detection. The measurable objective is not fewer clicks; it is a shorter time from a suspicious message arriving to a human on the security team looking at it.

The third job is evidence. NIS2, ISO 27001, PCI DSS, HIPAA, DORA and most cyber insurance questionnaires all ask a version of the same question: prove your people were trained, appropriately to their role, recently, and that you evaluated whether it worked. That is a documentation problem with a documentation solution, and it is the one part of the programme that can be fully completed in a quarter - which is why it is also the part most programmes complete and then mistake for the whole.

Start from decisions, not from topics

Topic-led programmes are built from a catalogue - phishing, passwords, malware, social media, GDPR - and they teach recognition. Decision-led programmes are built from the moments where a person's choice determines the outcome, and they teach a specific response. The second kind is shorter, easier to remember and far easier to test, because a decision has a right answer and a wrong answer and both can be observed.

Write the list before choosing any content. For most organisations it is twelve decisions, and every one of them has a wrong answer that has cost somebody money:

• A payment detail change arrives by email. Wrong answer: update the record. Right answer: call the number on file, never the number in the message, and hold the change for a second approver.
• Someone on the phone asks for a password reset or an MFA code. Wrong answer: verify with the caller's answers to questions the caller supplied. Right answer: end the call and call back on the number in the directory.
• An unexpected MFA prompt appears. Wrong answer: approve it to make it stop. Right answer: deny it and report it, because someone has your password.
• A file arrives that needs macros enabled to view. Wrong answer: enable. Right answer: report and wait.
• A USB stick is found in the car park or posted to reception. Wrong answer: plug it in to identify the owner. Right answer: hand it to IT unplugged.
• A customer data extract is needed for analysis. Wrong answer: personal email or a personal cloud drive. Right answer: the approved store, with the classification rule applied.
• A colleague asks you to share your login "just for the audit". Wrong answer: share the password. Right answer: delegated access, named, time-bound.
• A document needs summarising and a free AI tool will do it. Wrong answer: paste the client contract in. Right answer: the approved tool, or ask - and know which one you are allowed to use.
• An invoice arrives from a supplier you have used for years, urgently, from a director you have never met. Wrong answer: approve. Right answer: the same callback rule, with no exception for seniority.
• A suspicious message arrives and you are not sure. Wrong answer: delete it quietly. Right answer: report it, even if it turns out to be nothing.
• You realise you clicked something you should not have. Wrong answer: say nothing and hope. Right answer: report within minutes, and be thanked.
• You are leaving, or a colleague is leaving. Wrong answer: hand over the laptop with the session still open. Right answer: the offboarding checklist, signed.

Twelve decisions map onto about four hours of content per person per year if taught properly, and onto a programme that can be evaluated by asking whether each decision was made correctly the last time it came up in real life. That is a far better unit of measurement than a quiz score, and it is the unit an incident review already uses.

A topic map that fits the org chart

Role-based training is the most over-promised and least-delivered idea in the category. The promise is thirteen separate curricula; the delivery is one course with a dropdown. The workable version is three tiers plus four named roles, each with a different failure mode and therefore a different scenario set.

Tier one, everyone, including contractors and the management body: the twelve decisions above, the reporting route, the acceptable-use rules that actually bind them, and a one-page answer to "what happens if I make a mistake". Delivered at induction, then in short reinforcing pieces across the year - and re-sent when a policy changes, because a rule change nobody was told about is not a rule.

Tier two, anyone who touches money, data or access: finance and accounts payable, HR and payroll, anyone with administrative rights, executive assistants, and sales operations with CRM export rights. These groups get the same twelve decisions plus their own three, taught as scenarios in the actual screens they use.

Tier three, the people who design the traps: engineering, platform and product teams, whose risks are secrets in repositories, over-broad service accounts, dependency confusion and - increasingly - the way they use code assistants. Their training is not awareness content; it is secure development practice, and it belongs to a different owner with a different budget.

The four named roles that deserve their own hour and never get it: the service desk, which is the single most attacked function in most organisations; the executive team, which faces authority-based fraud and deepfakes rather than phishing; legal and procurement, who sign the supplier contracts that decide whether the third-party risk described in the DBIR is mitigated; and the developer with production access, whose mistakes are not clicks.

The leading metric: report rate, with a clock on it

If a programme can only report one number to management, it should be the share of simulated campaigns that a member of staff reported, and the median time from delivery to first report. Both are leading indicators in the literal sense: they move before incidents do, and they measure the behaviour that actually contains an attack. The NCSC makes the same point from the opposite direction - a programme that measures only the absence of clicks rewards silence, and silencing your early warning system is the one outcome worse than a click.

The measurement is straightforward and does not need a vendor: a reporting button that creates a ticket, a ticket system that timestamps arrival, and a monthly export. What matters is the denominator. Report rate should be computed over campaigns, not over people, because one vigilant employee reporting a campaign to eighty recipients produces a 100% campaign-level report rate and tells you nothing about the other seventy-nine. Report both: campaign report rate and unique reporter rate - the share of staff who reported at least one campaign in the period - and treat the second as the culture indicator.

Set targets that are honest about the population. A first campaign in an organisation that has never asked for reports will see report rates in the low single digits, and a mature programme should be well past half of campaigns reported within an hour of delivery. Time to report is the number that predicts cost: in a business email compromise the difference between a ten-minute report and a next-morning report is usually the difference between a recalled payment and a lost one.

The lagging metric: click rate, and why it must not be a target

Click rate is required by every platform, quoted in every board pack and is the metric most likely to be gamed, because it is the one people are judged on. Three properties make it dangerous as a target. It is noisy: at 200 staff and a 15% click rate, the 95% sampling interval alone is about plus or minus 5 percentage points, so a "three-point improvement" between two campaigns is indistinguishable from who was on holiday. It is comparable only within a template library, so a fall may mean the lures got easier rather than that the staff got better. And it responds to notice - an organisation told that click rate drives a bonus will produce a falling click rate.

Use it as a monitor with three guards. Fix the difficulty of the campaign set in advance and record it: the Phish Scale, published as NIST Technical Note 2276, rates a lure's difficulty from eight observable cues, which turns "we sent a hard one" into a number. Report a rolling four-campaign average rather than single campaigns, and never compare across a change of template library. Exclude the populations that would corrupt it - anyone in their first week, anyone on leave, anyone currently inside an incident - and state the exclusions in the same breath as the number.

The more useful variant is leakage rate: the share of a campaign where someone did not merely click but entered credentials, approved an MFA prompt, or opened an attachment. Click is curiosity plus a slow mail gateway; leakage is the behaviour that precedes a breach, and it is usually a small fraction of clicks, which means it needs more campaigns before it moves. Report it anyway, because it is the number that maps to the DBIR's credential-abuse category.

Five numbers, one page, and a rule about dashboards

A working measurement set fits on one page and survives a change of platform: campaign report rate, unique reporter rate, median time to report, leakage rate, and one outcome number drawn from operations rather than from the programme - reports of suspicious messages that turned out to be genuine phishing, or payment-change requests blocked by the callback rule. The last one is the only number that connects training to money, and it comes from the fraud controls rather than from the learning platform.

Everything else is a means. Completion percentage belongs in the audit file, not on the dashboard, because completion measures attendance and attendance is a scheduling problem, not a security outcome. Quiz scores are worse: a pass mark high enough to matter becomes a blocker that generates helpdesk tickets, and a pass mark low enough not to be a blocker measures nothing.

One rule makes the entire set trustworthy: the dashboard is produced from the same export the auditor would receive, by the same script, on the same day each month. Programmes fail audits not because the numbers were bad but because the numbers in the board pack could not be reproduced from the system of record. Where the two disagree, the auditor believes the system of record - and by then the board has been told something that was not true.

Simulations: what they can prove, and what they cannot

A simulation answers one question honestly: would this population, on this day, with this lure, take this action. It does not answer "are we secure", and it cannot answer "would training help", because the people who clicked were not randomly assigned. Treat campaigns as sampling rather than as an examination, and the reporting becomes useful instead of theatrical.

Difficulty calibration is the discipline that separates a programme from a game. A first campaign should be recognisably suspicious - a mismatched sender, an offer nobody asked for - so that it establishes a baseline rather than an ambush. Difficulty should then rise along cues the organisation has actually taught: an internal-looking sender that is not internal, a thread that appears to be a reply, a supplier domain one character off. Campaigns should stay comparable year on year, which means keeping a set of standard templates and a set of rotating ones and reporting them separately, so novelty never masquerades as progress.

Two operational details decide whether the results mean anything. Delivery timing must vary, because a campaign sent at 10am on a Tuesday measures a different population from one sent at 5pm on a Friday - and the Friday campaign is the one that predicts real behaviour. And the follow-up must be immediate: a thirty-second "here is what you missed" screen at the moment of the click teaches more than a module three weeks later, and it costs nothing. What should never happen is a public league table of who clicked. It converts a measurement into a punishment and guarantees that the next campaign's real clicks go unreported.

Running simulations lawfully in the UK and the EU

Phishing simulations process personal data - who was targeted, who clicked, when, from which device - and in most European jurisdictions they are also a monitoring activity affecting workers. That does not make them unlawful; it makes them a processing operation that needs a lawful basis, a stated purpose, a retention rule and, in some member states, a works council conversation before the first email goes out.

In the UK the practical route is legitimate interests with a documented assessment: the purpose (measuring and improving resilience), the necessity (no less intrusive way to test reporting), the balancing (the intrusion is a click and a timestamp, nobody is disciplined on the basis of a simulation), and the safeguards (aggregate reporting, short retention, no naming). The ICO's employment practices guidance and its guidance on monitoring workers are the references an auditor will expect you to have read, and where monitoring is systematic, a data protection impact assessment is the artefact that shows you did the thinking. Where the workforce is unionised or a works council exists - Germany, Italy, France, the Netherlands and many sectors elsewhere - consultation is a precondition rather than a courtesy, and a campaign run without it will be stopped after the first send.

Three rules keep the programme on the right side of the line. Simulations test the organisation's defences, not the individual's diligence, so no disciplinary outcome should ever flow from a click. Nobody should be targeted in a way that follows them into leave, or at hours they are not working. And the data collected should be the minimum that answers the question - a click and a timestamp, not a keystroke log from the landing page, and never a password field that accepts input. The NCSC's warning is worth quoting to whoever signs off: since nobody can be expected to spot every phishing email, punishing people for clicking on emails you sent starts to resemble entrapment, and the trust cost is paid by the reporting channel you were trying to build.

The service desk is the highest-leverage hour in the programme

If a programme can only train one team properly, it should be the people who reset credentials, because they hold the keys to every account and are asked for them by strangers all day. The attack is not sophisticated: a caller claims to be a remote worker locked out before a meeting, has a name, a manager's name and a plausible reason, and asks for a reset and an MFA re-enrolment. When it works, the attacker does not need a phish at all - they inherit a working account, and the first thing an experienced operator does is add their own second factor and a mailbox rule.

What works here is not awareness content but a procedure with no discretion: identity verification against a record the caller cannot influence, a callback to the number in the directory rather than the number offered, a rule that MFA re-enrolment is never done on an inbound call, and a queue where a reset request that cannot be verified is logged and escalated rather than refused and forgotten. Pair it with a monthly fifteen-minute review of the resets that were refused and the ones that were granted under pressure, because the desk's judgement is the control and the review is what keeps it sharp.

The same logic applies to IT administrators themselves. Their scenario is not a phish; it is a request from a senior person to bypass a control, a contractor asking for a shared credential, or a "temporary" firewall rule that outlives the project. Training for this audience is a decision rehearsal inside the actual approval workflow, and it is the only training in the programme where saying no has to be visibly supported by management.

Executives, and the obligation nobody reads out loud

Executive training is usually a forty-minute video about phishing, assigned to the people least likely to be phished and most likely to be impersonated. Their actual exposure is authority: a payment approved because the request appeared to come from the chief executive, a supplier onboarded on a personal recommendation, a legal hold ignored because it was inconvenient, a breach disclosed late because disclosure was embarrassing.

There is now a legal reason to take this seriously rather than a cultural one. NIS2 Article 20(2) requires members of management bodies of essential and important entities to follow cybersecurity training, and it does not delegate that to the security team; Article 21(2)(g) makes basic cyber hygiene practices and cybersecurity training a mandatory risk-management measure across the entity. Comparable expectations appear in DORA for financial entities and in the UK's Cyber Assessment Framework for regulated sectors. An attendance sheet for a video does not satisfy a regulator who asks what the board discussed.

What does satisfy it is a ninety-minute tabletop twice a year with the executive team in the room, built from a scenario they will recognise: a supplier invoice fraud caught on a Friday afternoon, a ransomware demand during a product launch, a journalist calling about customer data. The artefacts - the scenario, the attendees, the decisions taken, the two actions with owners and dates - are the evidence, and they double as the most useful management review the security function will get all year.

Finance: the callback rule, and why it needs to be boring

Business email compromise remains the most reliably profitable crime against businesses because it targets a process rather than a person: a change of bank details, a remittance that must go today, an invoice that looks exactly like the last eleven. The DBIR's 2025 figures put credential abuse at 22% and vulnerability exploitation at 20% of initial access, and the payment-fraud variant needs neither - a lookalike domain and a plausible thread will do.

The control that works is procedural and must be dull: any change to payment details is verified by a callback to a number held on file, never to a number supplied in the request, and the change waits for a second approver who is not the person who received it. Add a cooling period for first payments to new suppliers, and a rule that urgency is itself a warning sign rather than a reason to skip the rule. Training for finance is then a rehearsal of that procedure in the real payment system, with one specific lesson attached: the fraudster will know the names, the amounts and the invoice format, because they have been reading the mailbox for a week.

Measure it where it happens. The number to report is not "finance staff trained" but "payment-detail changes verified out of band, and attempts blocked", taken from the finance system rather than the training platform. That number is small, real, and it is the one a finance director will defend in a budget meeting.

What 2026 added: deepfakes, voice clones and shadow AI

Two changes have made the older content look dated. The first is that impersonation now has a video channel. In February 2024 a multinational engineering firm's Hong Kong office was reported to have transferred about 25 million US dollars after a video conference in which several participants, including a finance director the employee recognised, were synthetic. The lesson the industry took was "detect deepfakes"; the lesson that survives is that the callback rule would have stopped it, and that a video call is no longer proof of identity for a payment instruction.

The second is that the riskiest data movement in a modern office is no longer a USB stick but a prompt. Staff paste contracts, customer records and source code into consumer AI tools because it makes them faster, and the organisation discovers the exposure at the next audit or the next supplier questionnaire. Training cannot solve this by prohibition alone - the same guidance that says blaming users does not work applies to tool use - so the programme needs a decision instead of a warning: here is the approved tool, here is what may go into it, here is the classification rule, and here is who to ask when the answer is not obvious. Shadow AI is the 2026 restatement of shadow IT, and the control is the same: an approved path that is genuinely easier than the workaround.

Two older themes have also returned with better evidence. MFA fatigue - a stream of push prompts until someone approves one - is a decision that belongs in the twelve: deny and report, never approve to stop the noise. And the "reply to this thread" lure now arrives through chat platforms as often as email, which means the reporting button has to exist in the chat client too, or the programme has taught people to report in the one channel attackers have moved away from.

Coverage: induction, role change, contractors and the joins

Most audit findings in this area are not about content quality. They are about coverage: a population that was never enrolled, an enrolment that happened ninety days after the account was created, a contractor who has had production access for a year and no training record, a role change that moved someone into finance without moving them into the finance curriculum.

The fix is architectural rather than editorial. Drive enrolment from the HR system or the identity provider rather than from a spreadsheet, and make training completion a gate on privileged access rather than a parallel process. New starters should complete the core module before or during their first week - not because a week is magic, but because the first month is when the reporting habit forms and the first phishing email usually arrives. Role changes should trigger the delta automatically, as should a move into a privileged group. Contractors and suppliers with access belong in the same population with the same evidence, and that expectation belongs in the contract rather than in a reminder email.

Then close the joins, because that is where the evidence breaks. Reconcile the trained population against the directory quarterly and investigate the difference instead of reporting a percentage of those who were enrolled. A completion rate of 97% against an enrolable population that is missing forty contractors is a worse answer than 89% against everyone, and only the second one survives an ISO auditor reading the population definition.

The reporting loop is the programme

The anatomy of a working loop is unglamorous: one intake route that works from email, chat and mobile; an owner with a service level - triage within an hour in business hours, an automated acknowledgement immediately; a verdict communicated back to the reporter, including when the answer is "that was marketing, well spotted"; and a monthly pattern review that feeds the next quarter's content. The feedback step is the one that gets dropped, and it is the one that determines whether the next report happens.

Two details separate a loop from a form. First, the acknowledgement must be instant and the verdict must be human - an automated "thank you for your report" with nothing after it trains people to stop reporting. Second, the near-miss channel must be separate from the incident process: someone who typed a password into a landing page needs a route that does not begin with an incident number, or they will not use it, and the first hour is the one that matters. Make the near-miss route publicly blameless, say so during induction, and prove it the first time someone senior uses it and is thanked in public.

Instrument the loop the way the simulations are instrumented: volume of reports, share that were genuine, median time to verdict, and the number of incidents first detected by a staff report rather than by a customer or a bank. That last number is the programme's real output, and it is the one to put beside the click rate when someone asks whether the budget is working.

Training formats that earn their slot

Four formats carry most of the value and all of them are cheap. Spaced reinforcement - short pieces every few weeks rather than an annual block, because the retention curve for a single session is steep and unforgiving. Retrieval practice - asking people to recall the callback rule rather than to recognise it in a list, because recall is what happens under pressure. Scenario rehearsal - the twelve decisions practised in the interface people actually use, with the real payment system and the real report button. The teachable moment - thirty seconds at the moment of a click or a report, which is the highest-retention intervention available and costs nothing to deliver.

The formats that consume budget and produce nothing: the annual forty-five-minute video with a completion certificate, unskippable slide decks with a pass mark, cartoon characters in a workplace that has none, generic content in a language half the workforce does not read comfortably, and the security newsletter nobody opens. Each of these is defensible as evidence of activity and indefensible as behaviour change - and the annual video in particular has a perverse property, because it makes the organisation believe the obligation is discharged.

Multilingual delivery is not a nicety in a business with a distributed workforce: a training module in a second language halves its effect and doubles the time cost, and a report button labelled in a language the reporter does not read is a dead end. If the workforce is multilingual, the content and the reporting route have to be too - which is a procurement criterion, not a content preference.

Procurement: twelve questions that separate programmes from products

Platforms are broadly comparable on content and wildly different on the four things that decide whether the programme is auditable. Ask these before signing, and get the answers in writing, because the account manager who promised them will not be the person you call in year two.

• What does the audit export contain, and can I produce it myself without a support ticket? Per user, per module, per date, with role and population, in a format a spreadsheet can open.
• How is report rate measured, and does the reporting data live in the same system? If reporting lives in another product, the leading metric is not measurable.
• Can I set campaign difficulty deliberately? Fixed standard templates, rotating templates, and a record of which was which.
• What happens to my data at exit? Full export, format, timescale, deletion confirmation.
• How many languages, and are they human-reviewed rather than machine-translated? Ask to see one module in the language your workforce actually reads.
• Does the simulation landing page ever accept a password? It should not, and the answer tells you how the vendor thinks about data minimisation.
• What is the false-positive rate of the report button, and who triages it? The honest answer is often "your service desk", which is fine if it was priced.
• Can simulations be excluded by population, and is the exclusion recorded? Leave, new starters, and anyone inside an incident.
• Where is the training content hosted, and does it load third-party trackers on my staff? A module that phones home to six ad networks is a privacy finding in your own estate.
• How does the platform handle role changes and leavers? Automated from the identity provider, or a CSV somebody uploads.
• What does renewal cost at three times the seats? Per-seat simulation pricing scales badly when a merger doubles headcount.
• What evidence do you give me that the programme changed behaviour rather than attendance? The good answer describes report rate and time to report; the bad answer describes the completion rate.

Three things to refuse to pay for: punitive league tables of individual scores, risk scores per employee that feed HR decisions, and any campaign designed to catch one named person. Each purchases a measurement at the cost of the reporting channel, and the reporting channel is worth more than the measurement.

The evidence pack an auditor will actually accept

Standards converge on the same eight artefacts, and an organisation that builds them once can answer ISO, NIS2, PCI and insurance questionnaires from a single folder. The mapping matters because each standard asks a slightly different question and each auditor has usually seen only their own.

• The policy and programme document: scope, populations, cadence, owners and the risk assessment that justified the topics. This is the evidence for ISO/IEC 27001:2022 Clause 7.3 and Annex A 6.3, and the "development plan" expectation under NIS2.
• The role-based training matrix: which population gets which content, and why. Clause 7.2 (competence) and Annex A 6.3 (role-appropriate training) test exactly this.
• Completion records by person and date, contractors included, exported from the system of record - the artefact PCI DSS v4.0.1 requirement 12.6.3 expects (at hire and at least annually) and HIPAA 164.308(a)(5) implies.
• Management-body training evidence: NIS2 Article 20(2) - agenda, attendees, trainer, date.
• Effectiveness evidence: campaign results, report-rate trend, time to report, and incidents first detected by a staff report. Clause 9.1 makes this a monitoring obligation rather than a nice-to-have.
• Corrective actions: what changed after a real incident or a poor campaign, with an owner and a date. This is the continual-improvement evidence that separates a live programme from a document set.
• The legal file: the legitimate-interests assessment or DPIA, works council correspondence, the retention rule, and the statement that no disciplinary action follows from a simulation.
• Management review minutes where the awareness numbers were discussed, because a metric that never reaches the review meeting is a metric that is not being used.

One warning about the whole pack: a folder of completion certificates answers "were they trained", not "does it work". Auditors have moved, unevenly but visibly, toward asking for the second, and an organisation holding the eight artefacts above can answer both without inventing anything.

Staffing, budget and a calendar that is not fantasy

The sector's own survey data is the antidote to the vendor timeline. SANS's Security Awareness Report has consistently found that most programmes are run by fewer than three full-time people regardless of the size of the workforce, and that the maturity distribution is weighted heavily towards the early levels - nascent and compliance-driven - rather than the culture-building end. A programme designed for a team of eight will be abandoned in month four by a team of one.

Plan for the team you have. One owner at around 0.4 of a full-time post can run twelve decisions, four campaigns, a monthly report and an audit pack for an organisation of a few hundred people, provided the content is bought rather than built and the reporting loop is owned by the service desk. Add communications support if the workforce passes a thousand, and budget the platform at roughly GBP 8 to 25 per user per year at the mid-market, plus GBP 3,000 to 12,000 for an annual external element - a social-engineering assessment, a tabletop, or an independent review of the programme - which is the part that buys credibility with a board.

A realistic calendar has three phases and no heroics. Days 1 to 90: the twelve decisions written, the reporting button live and triaged, one baseline campaign on an easy template set, the legal file drafted, the role matrix agreed, and the first audit export produced and read by the person who will have to defend it. Months 4 to 12: four campaigns at rising difficulty, role content for finance and the service desk, the executive tabletop, the first content change driven by a real incident, and a quarterly dashboard that reproduces from the system of record. Year two: the join-closing work - identity-provider enrolment, contractor coverage, role-change triggers - and the first honest attempt to measure whether anything changed, using a comparison against a population or a period rather than a before-and-after graph that flatters the programme.

What training cannot fix, and what to pair with it

Every one of the twelve decisions has a technical or procedural control that removes the choice, and the programme is stronger when it says so out loud. Payment-change fraud is mostly solved by a callback workflow and dual authorisation, not by a video. Credential phishing is largely defanged by phishing-resistant authentication - passkeys or FIDO2 keys bound to the origin - because adversary-in-the-middle kits relay a password and a one-time code but cannot relay a hardware-bound credential. Ransomware's blast radius is decided by backup immutability and restore testing. Shadow AI is decided by an approved tool and a data classification rule.

The honest allocation for a mid-size organisation is that training is a minority of the human-risk budget and a majority of the visible activity. That is not an argument for cutting it: the controls only work if people use them, report when they fail, and know who to call at 6pm. It is an argument for describing the programme accurately in the board paper - training as the layer that makes the other layers usable, rather than the layer that replaces them.

There is one place where training is irreplaceable: the first ten minutes after someone realises they have made a mistake. No control substitutes for a person who knows the route, expects to be thanked, and takes it. That behaviour is the most valuable thing the programme produces, and it is the one thing no product can hand you.

The four slides for the board

Boards do not need a curriculum. They need to know whether the organisation can detect a campaign in progress and whether the obligation is discharged. Four slides do it. One: the obligation and the evidence - which regime applies, which clause, and the artefact that proves it, with the date it was last produced. Two: detection - report rate, unique reporters, time to first report, trend across four campaigns, with the exclusions stated. Three: outcomes - incidents first detected by a staff report, payment-change attempts blocked, and one real example with the identities removed. Four: the ask - the two decisions the board actually owns: approve the pairings that remove choices (phishing-resistant authentication, a callback workflow, immutable backups) and endorse the no-blame rule that makes reporting work.

What not to put in front of them: a click-rate graph with an arrow, a completion percentage presented as a control, and any claim that the programme reduced breach risk by a specific amount. The first two invite questions the programme cannot answer, and the third is the kind of claim a serious board member will ask you to justify in the one meeting where you needed them to approve a budget.

If you are rebuilding the programme from the control side first, three of our guides go deeper than this one can: the phishing awareness and simulation programme guide covers campaign design and the legal limits of simulation in detail, the email security guide sets out the authentication and filtering controls that make a large share of inbound lures fail before a person sees them, and the password and credential guide covers the rollout that turns "use a strong password" into a rule people can actually follow. Each is written for the same reader - the person who has to implement, not the person who has to approve.

Where an external assessment fits, lawfully

An internal programme can measure recognition and reporting. It cannot measure whether the organisation would survive a determined, tailored attempt, because the person running the programme knows too much about the lures and the population. That is the gap an external social-engineering assessment fills: an authorised, scoped exercise with written permission, an agreed target population, an exclusions list, a stop condition, a named contact on both sides, and a report that goes to the programme owner rather than to HR.

Useful scopes for 2026 look less like a mass phish and more like the twelve decisions: a vishing campaign against the service desk with a callback verification test, a supplier-impersonation thread against finance carrying a payment-change request, a pretext call to procurement testing the supplier-onboarding route, and a physical attempt at reception to test tailgating. Each should run only after the legal file exists, and each should end with a debrief for the people who were targeted, because the value is in the correction and not the score.

If the programme is being rebuilt rather than tested, that same engagement can start with a review of the twelve decisions, the measurement set and the evidence pack before anything is sent. That is usually the cheaper half, and it is the half that survives the next audit. You can describe the scope you need through our authorised security assessment service, or contact the team with the regime you are answering to and the population you are responsible for.

The short version

• The 60% human-element figure describes where losses come from, not what training fixes; the 33.1% to 4.1% curve is a vendor-measured recognition metric on a self-selected population.
• The field evidence supports a real but bounded and decaying effect. Design for that: space the content, rehearse decisions, and put controls behind the choices people cannot reliably make.
• Train twelve decisions rather than twenty topics, and give finance, the service desk, executives and privileged engineers their own scenarios.
• Lead with report rate and time to report; monitor click rate with fixed difficulty, rolling averages and stated exclusions; never make it a target.
• Simulations process personal data and monitor workers: lawful basis, DPIA, works council, minimum data, no discipline, no naming.
• Coverage fails at the joins - enrol from the identity provider, gate privileged access on completion, include contractors, reconcile against the directory quarterly.
• Build the eight audit artefacts once and reuse them across ISO/IEC 27001:2022 Clause 7.2, 7.3, Annex A 6.3 and 9.1, NIS2 Articles 20(2) and 21(2)(g), PCI DSS 12.6.3 and HIPAA 164.308(a)(5).
• Pair every decision with the control that removes it, and keep the one thing training alone can deliver: a person who reports their own mistake within ten minutes and is thanked for it.