Security awareness training in 2026: what research shows, what works, and how to measure impact

What the research shows

The most important change in the approach to awareness is the move away from measuring attendance toward measuring behaviour and organisational capability. NIST SP 800-50 Rev. 1, published in 2024, describes a learning programme as a cycle linked to risk, culture, roles, and evaluation of outcomes, rather than a catalogue of courses to tick off.^[3]

One of the most useful field studies on how long training effects persist is the work by Reinheimer and co-authors presented at SOUPS 2020. The study involved 409 employees of a German public administration organisation. Immediately after the programme and again after four months, participants were significantly better at distinguishing phishing messages from legitimate ones. After six months, the improvement over baseline was no longer significant. The authors therefore identified about six months as a reasonable point for a reminder in the organisation studied.^[4]

This is not evidence of a universal legal requirement to train employees every six months. It is, however, a strong argument against assuming that a single exposure to training material will remain effective for years.

The same study compared four reminder formats. Video material and interactive examples performed best, and the effect persisted for at least another six months.^[4] The result supports programmes based on short, repeated interventions rather than one long annual training session.

Bullée and co-authors analysed 74 documented scenarios of successful social engineering attacks. They divided them into 142 attack steps and identified 180 occurrences of persuasion principles. Authority was the most frequently used principle: as a single principle it appeared in 76 of 142 steps, or 53.5%, and when all combinations were included it accounted for approximately 63% of persuasion-principle occurrences.^[5]

That distinction matters. The study does not support the statement that "63% of attacks use authority". It examined scenarios described in four books and individual interaction steps, not a representative population of all incidents. The practical conclusion remains useful: training should teach people to recognise manipulation mechanisms, such as authority pressure, rather than merely the visual appearance of a particular email.

The work by Lallie and co-authors on attacks during the COVID-19 period shows how quickly criminals adapt to changes in social and organisational context.^[6] Training material should therefore respond to actual campaigns, changes in working practices, and new technologies instead of remaining the same collection of examples for several years.

What to teach

Content should be selected on the basis of organisational risk, incidents, user reports, technological changes, and sector-specific threats. The ENISA Threat Landscape can provide European context, but data from the organisation's own SOC, help desk, email environment, and incident response team are even more important because they show what actually reaches that organisation.^[7]

A typical core programme covers:

• social engineering, including phishing, BEC, phone calls, messaging platforms, and impersonation of managers or suppliers;
• authentication, password managers, MFA, and rules for handling requests for codes or login approvals;
• secure handling of information and personal data;
• reporting incidents, mistakes, lost devices, and suspicious messages;
• remote and mobile work;
• use of cloud services, file-sharing tools, and SaaS applications;
• safe use of generative AI and rules governing data entered into models;
• role-specific content, for example for finance, HR, administrators, the help desk, and management.

Not every employee needs to understand the details of CVSS, Kerberos configuration, or CSIRT obligations. A programme becomes more effective when the knowledge corresponds to decisions that the person actually has to make. An accounts payable clerk needs to recognise a changed bank account number in supplier correspondence; an administrator needs to recognise an attempt to hijack a privileged session.

Awareness, training, and exercises are different things

Different learning formats serve different purposes, and treating them as interchangeable is a common reason for disappointment with a programme.

• A short communication raises awareness of a new campaign. It does not teach a skill, but it shortens reaction time while the campaign is running.
• Training teaches a specific skill and should end with an action the participant is able to perform.
• A phishing simulation tests behaviour in a defined scenario. It is a measurement, not a course.
• A tabletop exercise tests how roles cooperate during an incident: who decides, who informs, who activates the procedure.
• A cyber range assesses the technical skills of a team in an environment close to production.

NIST SP 800-50 Rev. 1 treats these elements as parts of a broader learning programme and recommends a cycle covering planning, delivery, evaluation, and improvement.^[3] There is no need to reduce the entire programme to a single e-learning platform.

Phishing simulations and how to use them fairly

A phishing simulation is a diagnostic tool, not an employee ranking system. Its result depends on scenario difficulty, the target group, the time of delivery, previous campaigns, the communication channel, the reporting method, and whether users recognise the test pattern.

For that reason, click rate alone is a weak metric for comparisons between organisations. There is no single scientifically justified threshold below which an organisation can declare maturity. A 0% click rate may reflect very good resilience, but it may also mean that the scenario was trivial, the simulation sender was recognisable, or participants had been warned in advance. The result must be interpreted in context.

At minimum, it is useful to measure:

• the percentage of people who performed the undesirable action;
• the percentage of people who correctly reported the suspicious message;
• time to the first and subsequent reports;
• the number of false-positive reports, to assess the load placed on the process;
• changes over time for the same class of scenario;
• behaviour in real incidents, where this can be measured without undermining privacy or trust.

Report rate and click rate describe different things. Reporting is particularly valuable operationally because it can trigger analysis and protection for other users before the campaign spreads inside the organisation. That does not mean report rate should always be treated as the single most important metric. An organisation should measure a set of indicators linked to its own objectives.

Do not punish the act of reporting a mistake

A programme in which employees are afraid to report their own mistakes makes incident response harder. If someone clicked a link, disclosed a password, or approved an MFA prompt, the most important action is rapid reporting so that credentials can be changed, sessions revoked, and the impact contained. An hour of delay can be the difference between recovering an account and an incident that has to be notified to a supervisory authority.

This does not mean there is no accountability. Repeated disregard of clear rules may require management action. The first step, however, should be to determine the cause: an unclear procedure, a badly designed process, time pressure, an incorrect learned behaviour, or lack of knowledge. The purpose of awareness is to reduce risk, not to improve statistics by encouraging people to hide mistakes.

Training after an incident

An incident can be valuable training material if the organisation can anonymise it and extract lessons without publicly blaming an individual. Employees understand a scenario that occurred in their own environment more readily than an abstract example from another sector.

Lessons learned from an incident should affect more than training. If a user could perform a dangerous action because the process allowed it without additional verification, the technology or procedure should also be improved. Education must not be used as a substitute for a control that can reasonably be automated: no amount of training replaces second-channel confirmation of a change to bank account details.

KSC and NIS2 requirements

NIS2 distinguishes two levels. Article 20(2) requires members of the management bodies of essential and important entities to follow training and encourages entities to offer similar training to employees on a regular basis. Article 21(2)(g) includes basic cyber hygiene practices and cybersecurity training among cybersecurity risk-management measures.^[8]

In Poland, the primary criterion is the Act on the National Cybersecurity System as currently in force. Following the amendment effective from 3 April 2026, the Act provides, among other things, for annual, documented training of the head of an essential or important entity and of the person entrusted with directing cybersecurity tasks, within the statutory scope.^[9] This should not be turned into an invented mandatory duration or a single prescribed training format: the provision sets a cycle and a substantive scope, not a number of hours.

For certain digital entities, the directly applicable Implementing Regulation (EU) 2024/2690 goes further. It requires an awareness-raising programme that is scheduled over time, repeated, covers new employees, and is updated in response to changes in threats. Where appropriate, the effectiveness of the programme must be tested.^[10] That is a process requirement rather than a declaration, and it should be examined as such in a KSC/NIS2 audit.

KRI: training as part of the management system

Section 19 of the regulation on the National Interoperability Framework requires appropriate training for people involved in information processing, covering threats, the consequences of security breaches, legal responsibility, and the application of measures that ensure information security.^[11] The KRI does not prescribe a single universal format, duration, or platform.

In a KRI audit, what matters is evidence that the programme reflects roles and risk, that people subject to the requirement actually participate, and that the material is current. An attendance sheet from three years ago satisfies a formal condition and says nothing about effectiveness.

DORA: compulsory modules in the financial sector

DORA requires financial entities to include ICT security awareness programmes and digital operational resilience training as compulsory modules in staff training schemes. They cover all employees and senior management, and the level of complexity must be commensurate with their functions. Where appropriate, ICT third-party service providers may also be included.^[12]

This is more specific than a general recommendation to "train people". An audit should examine population coverage, role-based adaptation, currency of content, and its relationship to the ICT risk management framework. Buying a training platform answers none of those questions.

GDPR and privacy

GDPR does not establish a universal annual privacy-awareness course for every employee. Training may nevertheless be an important organisational measure under Articles 24 and 32. In addition, the tasks of the data protection officer include awareness-raising and training of staff involved in processing operations, together with the related audits.^[13]

Content should reflect the role. HR needs knowledge about candidate and employee data, marketing about the legal bases for communication and profiling, and a system administrator about access, logging, backups, and incidents. A single shared "GDPR for everyone" course usually answers none of those questions in a way that supports a decision.

AI literacy and security awareness

Article 4 of the AI Act requires providers and deployers of AI systems to take measures to ensure, to their best extent, a sufficient level of AI literacy among staff and other persons dealing with the operation and use of AI systems on their behalf. The provision has applied since 2 February 2025.^[14]

In 2026, the application dates of some provisions concerning high-risk systems were changed, but that amendment did not postpone Article 4, which is located in Chapter I.^[15] AI literacy is therefore already required, regardless of the postponements in Chapter III.

AI literacy and security awareness overlap, but they are not the same thing. A security module should address:

• what information may be entered into approved AI tools;
• the risk of disclosing data, secrets, and source code;
• prompt injection and manipulation through content from external sources;
• the need to verify model outputs;
• permissions granted to agents and integrations that can perform actions in systems;
• the process for reporting unsafe behaviour by an AI tool.

These topics should not, however, be presented as complete fulfilment of all AI Act obligations. Article 4 covers AI literacy more broadly than information security alone.

How to train management

Management does not need a shortened version of employee training. It needs the knowledge required to make decisions: the risk profile, accountability, business impact, supplier dependencies, continuity, reporting deadlines, and ways of evaluating whether security measures are effective.

A scenario-based format works well. Instead of discussing definitions, consider a situation: Saturday, 03:20, suspected server encryption, uncertainty about whether data has been exfiltrated, and the SOC provider requests authorisation to isolate a critical system. Management must decide who has the mandate, who activates the procedure, what information is needed, and which statutory reporting clocks may just have started running.

There is no basis for claiming that management training must by law last two, four, or eight hours. Duration should follow from scope, role, and purpose, and the evidence is not an invoice but documentation identifying participants, date, and substantive scope.

How to measure the whole programme

The most useful set of metrics combines coverage, behaviour, and outcomes:

• coverage of the population and roles that require training;
• timely completion of required modules;
• knowledge-assessment results, but not as the only indicator;
• behaviour in controlled simulations;
• reporting rate and reporting time;
• quality of reports and the resulting triage workload;
• the number of incidents in which the human factor played a role, broken down by type of error;
• completion of corrective actions after incidents;
• results of repeated knowledge or behaviour measurements over time.

A metric should lead to a decision. If an organisation has reported for years that "100% of employees completed training" but never changes content after new incidents and does not measure behaviour, the metric confirms only administrative completion of a task. Such a programme passes a document review and changes no risk.

Frequency: there is no single number for everyone

The Reinheimer study supports a reminder at about six months after the specific programme used in the public administration organisation studied.^[4] NIST recommends a cyclical, risk-based approach.^[3] DORA and part of the implementing rules related to NIS2 require repeated or regular programmes.^[10][12] The KSC establishes an annual cycle for management training within the statutory scope.^[9]

None of these sources creates one universal schedule for the entire programme. A reasonable model may combine onboarding, short communications responding to current campaigns, periodic modules, exercises, and role-based training. Frequency should increase after significant organisational or technological changes and when measurement shows that the effect is fading.

Language and accessibility

There is no general cybersecurity rule stating that every training session for an employee working in Poland must be delivered exclusively in Polish. The material must be understandable to its audience and allow people to perform their duties correctly. In a multilingual organisation, the natural solution is to provide versions matching the actual working languages.

An audit should therefore ask not whether a Polish version formally exists, but whether people covered by the programme actually understand the requirements, reporting channels, and expected behaviour. The same applies to accessibility: material that cannot be viewed on a work phone on a production floor will not reach part of the workforce regardless of language.

Common mistakes

1. One long presentation once a year without measuring whether the effect persists. Research shows the effect decays over months rather than expiring neatly after twelve.
2. A programme built exclusively around phishing. Phishing remains important, but the human factor also includes configuration mistakes, improper sharing, data handling, device use, incident reporting, and administrator behaviour.
3. Identical training for every role. A manager, an accountant, an administrator, and a receptionist make different decisions and need different skills.
4. Basing the assessment of the whole programme on a single click rate. That indicator depends on scenario difficulty and does not by itself describe organisational resilience.
5. Punishment that discourages rapid reporting of mistakes. A silent mistake is far more expensive than a reported one.
6. Buying a platform and assuming the platform itself constitutes a programme. A tool can automate distribution, campaigns, and reporting, but it cannot decide for the organisation which behaviours, roles, and responses matter.
7. Treating vendor benchmarks as scientific maturity thresholds. Vendor data may be operationally useful, but it describes a particular customer population and methodology. The organisation's own trend and peer-reviewed research provide a more defensible basis for conclusions.