Security awareness in 2026: what the research shows, what works and what to avoid

What the research says about training effectiveness

The best documented finding in security awareness research is that the effect of training is real but does not last. Reinheimer and colleagues ^[4] ran a field study in a German public authority covering 409 employees and measured their ability to distinguish phishing messages from genuine ones immediately after training and in the months that followed. The improvement was statistically significant straight after training and held after four months, but after six months it no longer did. That is the strongest available argument that once-a-year training does not work: at least six months pass between one session and the next, during which the organisation is back where it started.

The same work answers the question of how to refresh. The authors tested four forms of reminder and found that video material and interactive message examples performed best - their effect held for a further six months, keeping phishing recognition elevated twelve months after the first training. The organisation studied consequently adopted a six-month reminder cycle. Purely textual forms performed worse in that comparison.

Bullée and colleagues ^[3] approached the problem from another direction: they decomposed 74 documented social engineering scenarios and examined which persuasion mechanisms they relied on. The result bears directly on training content. The dominant mechanism turned out to be authority, present in about 63 per cent of attacks and clearly more frequent than the others. The attacks were short - fewer than two interaction steps on average - and telephone contact predominated in the set studied. A programme focused solely on email therefore omits the channel this analysis found most frequent, and teaching people to recognise one persuasion mechanism covers more real attempts than drilling them on specific message patterns.

The third finding concerns context. Lallie and colleagues ^[5], analysing cyberattacks during the pandemic, showed how strongly attackers adapt their content to current events and how much a sudden change in working conditions helps them. The practical conclusion is that training material two years old describes scenarios that no longer exist, and that vulnerability peaks precisely when an organisation is going through change - a reorganisation, a new system, a move to remote work.

The way such programmes are conceived has changed too. NIST SP 800-50 Rev. 1, published in September 2024 ^[6], abandoned the awareness, training and education split familiar from the 2003 version, judging it hard to apply in practice, and shifted the emphasis to building a learning programme aimed at behaviour change and tied to the organisation's real risk.

One clarification is worth making about what those 68 per cent from DBIR 2024 actually measure. The figure covers two different things: falling for social engineering, and plain error - a misconfiguration, data sent to the wrong address, a lost device. Splitting it matters, because only the first is amenable to training in the classical sense; the second responds far more to process change and technical controls. The conclusion for the programme is stable, though: phishing deserves first place, but a programme built solely around phishing misses half the problem.

What specifically to train on

Topic selection should not rest on intuition. The starting point is the current threat picture - the annual threat landscape published by ENISA ^[2], for instance - set against what actually reaches the reporting channel in that organisation. The second part matters more and is skipped more often, because it is what distinguishes a tailored programme from one bought off the shelf.

The core of a programme is usually eight areas. The first and largest is social engineering: recognising manipulation attempts, verifying the sender's identity independently and - in light of the findings of Bullée and colleagues - treating an appeal to authority as a warning signal, on the telephone as much as in email. The second is authentication: a password manager, multi-factor authentication as standard, no credential sharing, and awareness that a password once used on another service is a public password. The third is information handling: what is confidential, how to label it and what must never leave by an external channel. The fourth is data protection to the extent an employee needs it: what personal data is, what to do about a breach and what rights data subjects have (see the article on GDPR audits).

The remaining four areas are more practical. The fifth covers workplace hygiene - locking the screen, a clear desk, documents left in the printer. The sixth concerns mobile and remote work: public networks, personal devices used for work and keeping the two roles apart. The seventh, in practice the most important, is what to do during an incident: how to recognise one, whom to tell, what not to delete and within what time. The eighth is role specifics - finance faces different scenarios from HR, and system administrators different ones again.

Standing apart is the module for the management body, required outright by article 20(2) of the NIS2 directive ^[7]. Its content differs from general training: it is not about recognising messages but about the ability to assess risk and risk management practices, knowledge of sector-typical threats and awareness of the personal liability the rules create.

Format: what works and what does not

Retention research yields a simple conclusion about form: what counts is the frequency of contact, not the length of a single session. Short modules repeated every few weeks hold recognition better than one long meeting, and reminders based on video and interactive examples performed clearly better in the study by Reinheimer and colleagues ^[4] than purely textual forms. Scenarios requiring a decision with immediate feedback work well, as does discussing real incidents once anonymised - the latter because they move the problem out of the abstract and into a familiar context.

What does not work is equally well documented. An annual presentation stops having a measurable effect long before the next one. Generic content that does not relate to the realities of the sector requires the audience to translate it into their own work, which they usually do not. Purely technical material explaining what phishing is, without explaining why this particular employee is a target, does not change behaviour.

The most serious design mistake is punishing a click. The result is not greater caution but fewer reports - an employee who fears the consequences stays silent during a real incident, and it is time to report that determines the size of the damage. An approach built on a reporting culture rather than sanction is also the one NIST SP 800-50 Rev. 1 adopts ^[6].

Phishing simulations

Simulations are the most used tool in these programmes and simultaneously the easiest to get wrong. A sensible frequency is at least quarterly, and every four to six weeks in more mature organisations, with short modules in between. Difficulty should rise: the first campaigns can use patterns that are easy to spot, later ones can reference the organisation's real processes, and the most advanced can model situations where a specific person or role is the target.

After a campaign, what matters is what happens in the following hour. Somebody who clicked should land on a short page explaining how the message could have been recognised - not on a notice about their lapse. Individual results should not be published; team-level aggregates are enough to manage the programme and do not destroy the trust that reporting depends on. Scenarios that play on strong emotions, such as fictitious redundancies or messages about personal misfortune, should also be avoided - they generate resistance to the whole programme and their instructional value is negligible.

Much of the data on simulation effectiveness comes from vendors of training platforms, which calls for caution in reading it. The industry review published by KnowBe4 ^[8] reports that the proportion of people clicking simulated messages falls over a year or so of a programme from around a third to a few per cent. That is, however, material from a company selling such programmes, based on its own customers' data rather than a controlled study - the figures are worth treating as an indication of direction, not as a measured causal effect. The peer-reviewed retention research described above is a much stronger basis in that role.

Programme metrics

Without measurement there is no way to tell a programme that works from one that is merely ticked off. Methodological guidance for building such measures comes from ISO/IEC 27004:2016 ^[9]; the set below is a practical minimum.

The basic measure is coverage - the proportion of staff who completed the planned modules on time. It is easy to collect and useless in isolation, because it measures participation rather than effect. Two measures that describe effect are the click rate on simulated messages and the report rate for flagging them as suspicious. Of the two the second matters more, because clicking tells you about a single mistake while reporting tells you whether the organisation learns about attack attempts at all. The ratio between them is a better maturity indicator than either alone.

The third measure is time to report, counted from delivery of the message to it being reported. It translates directly into the consequences of a real incident and into regulatory deadlines, including the 24-hour early warning under NIS2 ^[7]. The fourth is the number of real events reported by staff, and a rise in the first months of a programme is a good sign rather than a bad one: what grows is not the number of attacks but the number noticed. That is exactly why reports, clicks on real messages and actual compromises have to be counted separately - the first of those numbers should rise, the other two fall.

All these measures should be reported regularly and in one place, because individually each can be improved without security improving. A click rate near zero is not a success but a signal to review the programme: most often it means simulations that are too easy, recognisable by sender or campaign pattern, or a culture in which nobody risks interacting with a suspicious message or reporting it.

Legislation that requires training

The training obligation today follows from several independent bases, each covering a slightly different group. The NIS2 directive ^[7] names, in article 21(2)(g), "basic cyber hygiene practices and cybersecurity training" among the risk management measures, and separately, in article 20(2), obliges members of the management body to undergo regular training enabling them to identify risks and assess risk management practices. Those two provisions are distinct, and satisfying one does not discharge the other. In Poland they apply through the national cybersecurity system act ^[10].

In the public sector an independent basis is the KRI regulation ^[11]. Its § 19(2)(6) requires training for people involved in processing information and, alone among the whole list, states the subject matter directly: information security threats, the consequences of breaching the rules including legal liability, and the use of measures minimising human error. The provision sets no frequency, which is sometimes mistaken for the absence of an obligation.

The GDPR ^[12] approaches this differently: article 39(1)(b) assigns awareness-raising and staff training to the data protection officer as one of their tasks, which makes it a duty of the role rather than of the organisation as such. ISO/IEC 27001:2022 ^[13] in turn provides control A.6.3, covering awareness, education and training for everyone within the scope of the information security management system.

Two bases are newer and cover narrower groups. DORA ^[14] requires financial entities to include security and operational resilience training in their mandatory training programmes, covering senior management as well. Following the 2026 amendment, article 4 of the AI Act ^[15] requires providers and deployers to take measures that support the development of AI literacy among staff and other people operating or using AI systems on their behalf. It expressly does not require them to guarantee a specified level of literacy for each individual. This duty is distinct from information security, although in practice it is often addressed in a shared module.

Where this is heading

The clearest change is on the attacker's side. Language models have lowered the barrier to attacks tailored to a specific person: content free of language errors and referencing publicly available information about the recipient has stopped being a sign of effort invested. Add to that voice synthesis techniques, which move the problem onto the telephone channel - the same one that turned out to be most frequent in the analysis by Bullée and colleagues ^[3]. The practical answer is not to teach recognition of ever subtler signals, because that road has run out, but to build independent verification into the process for every action with significant financial or access consequences.

The second change concerns the scope of programmes, which today have to cover the use of tools built on artificial intelligence: the limitations of such models, the risk of feeding them data that should not be disclosed, and their susceptibility to manipulation through input content. Article 4 of the AI Act ^[15] gives this a legal basis, but the need predates the rule.

The third change follows directly from the work of Lallie and colleagues ^[5]: since time pressure and unusual situations clearly increase susceptibility, it makes sense to teach people to recognise their own state and to introduce a simple rule of pausing before acting in urgent situations. It is the one element of a programme that works regardless of what the specific attack scenario looks like.

How to recognise a mature programme

A well-built programme can be described by a few easily checked characteristics. It has a regular rhythm - at least quarterly points of contact, not one meeting a year - and differentiated tracks for the management body, administrators, HR, finance and everyone else. It includes phishing simulations with immediate feedback and no sanction for clicking, and a reporting mechanism available to everyone that flags a suspicious message in one action, with reports reaching a team able to handle them (see the article on SOC).

Organisationally, a mature programme includes induction training that a new employee completes before gaining access to systems rather than several weeks later, and documented training for the management body, as article 20(2) of NIS2 requires. Materials - policies, instructions, contact details - are available on the intranet rather than circulated once and forgotten.

Finally, a mature programme is measured and reviewed. A monthly summary of coverage, click rate, report rate and time to report makes regression visible before an incident reveals it, and an annual review allows scenarios to be replaced with ones matching the current threat picture ^[2]. Holding it all together is a culture in which reporting is valued - including reporting one's own mistake. Without it, the other elements measure something other than what they claim.