Most organisations have an awareness programme. Employees complete an e-learning module once a year, receive a few simulated phishing emails and see posters near the coffee machine. Completion rates are reported to management. Click rates go down a little over time.
And yet, when a real incident is analysed afterwards, the people involved usually knew the rule. They knew that payment details should be verified. They knew that passwords should not be shared. They knew that a visitor should be accompanied. They still did something else.
That is not a failure of awareness. It is a sign that awareness was never going to be enough.
A familiar situation
An employee in the finance department receives an email from a known supplier. The supplier has changed banks and asks for the next invoice to be paid into a new account. The email is written in the usual style, refers to an existing contract and arrives at the end of the month, when the team is busy closing the books.
The employee has completed the awareness training and knows that changed payment details are a warning sign. They reply to the email asking for confirmation. The confirmation arrives within the hour, from the same address. The payment is made.
The employee did follow part of the advice. What they did not know was that confirming through the same channel confirms nothing, that the procedure required a call to a number already on file, and that they were allowed to delay a payment without approval from their manager. Nobody had practised this situation with them. The training told them to be alert. It did not tell them what to do.
The difference between knowing and acting
Security competence can be described in five steps. Awareness programmes usually cover the first one and sometimes the second.
- Knowing that a risk exists and what the rule is.
- Understanding why the rule exists, what it protects and what the trade-offs are.
- Practising the response in realistic situations, including situations where the rule is inconvenient.
- Deciding what to do when the situation does not match the rule exactly, under time pressure or social pressure.
- Acting within one's own role and mandate, including stopping a process or escalating to someone senior.
The gap between the first and the last step is where most incidents happen. Closing it requires something different from more information.
Why awareness programmes stall
When awareness does not produce better behaviour, the first response is often to repeat the message more often or make it more engaging. That rarely solves the underlying problem, because the root cause is usually elsewhere:
- The content is the same for everyone. A board member, a procurement officer and a system administrator face completely different security decisions, but receive the same module.
- The procedure is not workable. If verifying a payment change takes two days and requires three signatures, people under pressure will find shortcuts. Training cannot fix a process that does not fit the work.
- People do not feel entitled to act. An employee who suspects something is wrong but has to challenge a senior manager to stop it needs explicit permission, and needs to know that the organisation will back them.
- Success is measured by completion. Completion rates show that people have been exposed to content. They say nothing about what people will do.
What competence-based training looks like
Organise by role, not by topic
Start by asking which security decisions each group actually makes. The board decides on risk appetite and accepts residual risks. Managers decide on access, exceptions and priorities. Procurement decides which suppliers are assessed and what is contractually required. HR decides how joiners, movers and leavers are handled. Specialists decide how controls are configured. Training should follow these decisions.
Use real cases
Abstract examples produce abstract understanding. A case based on the organisation's own processes, suppliers and systems makes people recognise the situation when it happens. It also tends to surface weaknesses in the procedure itself, which is useful information for the people who own it.
Practise the difficult part
The difficult part of security is rarely knowing the rule. It is applying it when it is inconvenient: refusing a request from a senior colleague, delaying an urgent payment, reporting your own mistake. These moments can be rehearsed. Short exercises in which people say the actual words ("I will call you back on the number we have on file") make it far more likely they will do so when it matters.
Fix what the training reveals
Good training produces findings. If participants consistently say that they would not know whom to call, or that the procedure cannot be followed at the end of the month, that is a governance issue. Feeding these findings back to process owners is part of the work, not a side effect.
Measure behaviour
Useful indicators include the number and speed of reports, the proportion of verification steps actually followed in practice, and the results of realistic exercises across several channels. Social engineering tests that look at the full process, rather than only at who clicked, give a far better picture than completion rates.
What competence looks like in different roles
Competence is easier to discuss when it is made concrete. A few examples of what it means in practice:
- A board member can explain which information security risks the organisation has accepted, why, and when that decision will be reviewed. They ask for evidence when told that something is "under control".
- A department manager knows which access rights in their team are sensitive, reviews them when asked, and does not approve an exception simply because someone is in a hurry.
- A procurement officer knows which suppliers need a security assessment before signing, and what to do when the supplier refuses to provide evidence.
- An HR adviser makes sure that access is removed on the last working day, including for contractors and people moving to another role.
- An employee at reception can politely refuse entry to a visitor without an appointment, even when the visitor is confident and mentions the name of a director.
None of these examples requires deep technical knowledge. Each requires that people know what is expected of them in their own role, have practised it, and know that the organisation supports them when they apply it.
The role of the security team
Competence-based training changes the role of the security or awareness team as well. Instead of producing content for everyone, the team works with process owners to identify the decisions that matter, helps design realistic exercises and collects what the exercises reveal. The aim is not to make the organisation dependent on the security team, or on an external trainer. It is to build judgement and reusable methods that stay in the organisation after the training has ended.
Three things to do this quarter
- List the five security decisions that matter most in your organisation and who makes them. Check whether those people have ever been trained on that specific decision.
- Run one tabletop exercise with finance or procurement using a realistic payment change scenario. Note where the procedure is unclear or unworkable.
- Tell employees explicitly that they may delay or stop an unusual request in order to verify it, and that they will not be blamed for doing so.
Conclusion
Awareness is a necessary starting point. People need to know that risks exist. But security improves when people in each role understand the reasoning, have practised the response and feel entitled to act. That is the difference between an organisation that knows about security and one that is capable of it.
The Security Training & Competence page describes how FLODISQ builds role-based training for boards, managers, specialists and employees. Where training reveals that roles and mandates are unclear, Security Governance is usually the next step.