CYBOK 04.2 and 04.4: Usable Security, Awareness and Education
Relevant learning outcomes
| CYBOK topic | Learning outcomes |
|---|---|
| 04.2 Human factors - Usable security | Analysis |
| 04.4 Cybersecurity awareness and education | Analysis, Advice, Design, Realisation, Manage & Control |
Examples of possible products
The products below are examples rather than a complete list. A product can support more than one learning outcome when you make the evidence for each outcome explicit.
| Learning outcome | Possible products |
|---|---|
| Analysis | Human-centred security analysis; security task and workload analysis; contextual inquiry report; usability evaluation of an authentication process, warning or policy; analysis of security fatigue or workarounds |
| Advice | Evidence-based awareness and education advice; advice on selecting a behavioural or technical intervention; improvement advice for an existing learning programme |
| Design | Design for a role-based awareness, education or training intervention; learning journey; campaign and evaluation design |
| Realisation | Tested microlearning module, exercise, simulation or campaign asset, including evidence from a pilot |
| Manage & Control | Cybersecurity learning programme plan; measurement dashboard; evaluation report and continuous-improvement cycle |
Why this matters
Security only works when people can use it while doing their actual work. A technically strong control can still fail when it demands too much attention, conflicts with the primary task or does not work in the user's physical and social environment. People may then delay the security task, make errors or create a workaround. This is often a rational response to a system that does not fit the work, rather than evidence that people are careless.
Usable security therefore asks whether specified users can achieve their goals securely and with acceptable effectiveness, efficiency and satisfaction. Accessibility and the ability to recover from mistakes are also essential. This changes the starting question from "Why did the user fail?" to "What made secure behaviour difficult in this situation?"
Awareness, education and training can support secure behaviour, but they cannot repair an impossible process or an unusable control. First remove unnecessary friction and contradictory rules. Then use a learning intervention when the remaining problem genuinely concerns attention, understanding or skill.
Key concepts for your work
Primary tasks and security tasks
A primary task is the work a person is trying to complete, such as helping a customer, administering a patient or publishing a software release. Security is usually an enabling task: it protects the work but is not the person's immediate goal.
Every additional login, warning, approval or training activity consumes time and attention. When the total demand becomes too high, people experience security fatigue and spend their limited compliance budget on the controls that seem most important. Unofficial workarounds can then emerge. These practices are sometimes called shadow security because people are still trying to manage risk, but outside the approved process.
Human error is not a complete explanation
A click on a phishing link is an observable action, not yet a root cause. Your analysis should distinguish:
- slips and lapses, where the intention was correct but attention or memory failed;
- mistakes, where a person used an incorrect rule or did not possess the necessary knowledge;
- latent conditions, such as high workload, weak defaults, unclear responsibilities, conflicting targets or excessive false alarms.
This distinction matters because the interventions differ. More information will not prevent a slip caused by a crowded interface, and a redesigned interface will not by itself correct a missing mental model.
Automatic and deliberate thinking
People perform much routine work automatically. This is efficient, but attention or memory can fail when a security step interrupts a familiar sequence. Deliberate thinking is useful for unfamiliar or high-impact decisions, but it is slower and can also lead people to rationalise a suspicious situation. Do not assume that every warning will make a person stop and reason correctly. Decide which decisions genuinely require attention and make those signals infrequent, clear and trustworthy.
Security hygiene before learning interventions
Policies and controls must be credible, consistent and possible to follow. One impossible rule can reduce trust in other rules. Investigate non-compliance and repair contradictory processes before asking people to try harder. This organisational security hygiene creates the conditions in which awareness, education and training can work.
Authentication illustrates why context matters. Long password rules can overload memory, copying a one-time password can interrupt the primary task, and a CAPTCHA can create accessibility barriers. The question is not whether these mechanisms are secure in isolation, but whether the complete task is secure and workable for the intended people, devices and environment.
Awareness, education and training have different purposes
| Intervention | Main purpose | Appropriate when |
|---|---|---|
| Awareness | Gain attention and show why a risk and a response are relevant | People do not recognise the relevance of a risk or available action |
| Education | Develop a more accurate mental model | People need to understand how or why a threat, control or consequence works |
| Training | Develop and practise a skill | People need to perform a specific response reliably in a realistic setting |
Knowing what to do does not guarantee that behaviour will change. The desired action must also be possible, supported by the environment and practised often enough to become part of normal work. A positive security culture reinforces this by making it safe to report mistakes, near misses and workarounds.
A practical starting point
Use the following sequence when you analyse or improve a human-facing security problem.
1. Define the security outcome
Describe the risk, the people involved and the observable secure behaviour. Avoid vague objectives such as "users must be more aware". A stronger objective is: "Service-desk employees verify a caller through the approved process before resetting an account."
2. Understand the primary task
Observe how the work is performed and ask people what they are trying to achieve. Record time pressure, interruptions, handovers, social norms, performance targets and dependencies on other systems. Contextual inquiry combines observation with short questions during the work.
3. Analyse the complete security task
Map every step, decision, warning, device and recovery path. Include the cumulative workload created by other security controls. Useful evidence can include:
- task-completion time and error rate;
- interviews and observations;
- support tickets, incident reports and near misses;
- examples of workarounds;
- a workload instrument such as NASA-TLX;
- a usability test with representative participants.
4. Diagnose the barrier before selecting an intervention
Determine whether the main barrier concerns the design of the control, the process, access to support, knowledge, skill, motivation or a conflict with organisational norms. Several barriers may interact. Do not select training simply because it is easy to procure.
5. Choose the least burdensome effective response
Where possible, remove unnecessary decisions, use secure defaults, reduce false alarms and offer a secure recovery route. If learning is still needed, make it relevant to the role and the real task. Focus on one or two priority behaviours instead of sending many generic messages.
For warnings, use the NEAT test: is the warning Necessary, Explained, Actionable and Tested? An actionable warning tells the person what to do next and provides a secure way to complete the primary task.
6. Pilot with representative people
Test the control or intervention under realistic conditions. Include different roles, levels of experience, accessibility needs, devices and work locations. Ask participants to perform a task rather than only asking whether they like the solution.
7. Evaluate and improve
Compare the result with the baseline. Measure secure task success, errors, completion time, recovery, reporting behaviour and unintended workarounds. Completion rates and quiz scores may be useful process measures, but they are not proof of safer behaviour or reduced risk.
Short example: multifactor authentication for field staff
An organisation introduces one-time passwords for field engineers. Login failures increase and engineers begin sharing active sessions. Sending another awareness email would treat the visible behaviour but not its cause.
A human-centred analysis shows that engineers often work outdoors, wear gloves, use small screens and must respond quickly to faults. The organisation can first reduce task friction, improve the recovery route and test an authentication method that fits the environment. Short, role-specific practice can then explain the remaining decisions. Suitable measures include secure login success, recovery time, support requests and the number of shared-session workarounds. This combination addresses the system and the behaviour.
Quality checklist
Use these questions to review your work:
- Is the desired security outcome linked to a relevant organisational risk?
- Have you described the primary task as well as the security task?
- Did you involve representative people in their actual or a realistic context of use?
- Did you consider workload, accessibility, devices, interruptions, norms and time pressure?
- Are slips, mistakes and latent conditions distinguished instead of grouped as "human error"?
- Did you investigate why workarounds exist before judging or removing them?
- Does every warning or prohibition offer a secure and workable alternative?
- Is awareness, education or training used for a clearly diagnosed need?
- Does the intervention avoid fear, blame and unnecessary repetition?
- Are success measures behavioural and risk-related rather than limited to attendance or completion?
- Did you check for unintended effects, such as alarm fatigue, reduced trust or a new workaround?
- Are privacy, informed participation and responsible handling of research data addressed?
Further learning
- Core literature: CyBOK Human Factors Knowledge Area - the underlying discussion of usable security, human error, awareness, education and stakeholder engagement.
- Practical guidance: NCSC - Engagement and training - guidance on relevant, positive and role-sensitive learning activities.
- Practical guidance: NCSC - Putting people at the heart of an organisation's approach to cyber security - people-centred design, user research and learning culture.
- Programme guidance: NIST SP 800-50 Rev. 1 - Building a Cybersecurity and Privacy Learning Program - a lifecycle approach to planning and evaluating learning programmes.
- Method and tool: NASA Task Load Index - a method for assessing perceived workload.
For advanced students
At a more advanced level, examine how individual behaviour interacts with organisational culture, leadership, incentives and technical architecture. You can compare interventions through a controlled or quasi-experimental study, but first define what meaningful change looks like and consider whether the study setting represents real work.
Possible advanced products include:
- a longitudinal evaluation of a cybersecurity learning programme;
- a mixed-method study combining observations, interviews, workload scores and behavioural data;
- an analysis of security culture, psychological safety and incident-reporting behaviour;
- a controlled usability study comparing two authentication or warning designs;
- a socio-technical improvement programme that links design changes, learning activities and governance measures.
Be cautious with metrics. A lower phishing click rate may reflect learning, but it can also be affected by exercise difficulty, reporting rules or selection effects. Explain alternative interpretations and use several forms of evidence before claiming that risk has decreased.