Chapter 20 — Security awareness
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Why awareness"]
N2["20.2 Designing activities"]
N3["20.3 Encouraging reporting"]
N4["20.4 Measuring outcomes"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 Why awareness"]
N2["20.2 Designing activities"]
N3["20.3 Encouraging reporting"]
N4["20.4 Measuring outcomes"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Why awareness]
|
v
[20.2 Designing activities]
|
v
[20.3 Encouraging reporting]
|
v
[20.4 Measuring outcomes]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) design awareness activities for staff; (2) encourage reporting; (3) measure awareness outcomes.
20.1 Why awareness
Many incidents begin with a person: clicking a phishing link, sending data to the wrong recipient or sharing a password. Aisha learns that awareness programmes help staff recognise and respond to threats. ISO/IEC 27002:2022 includes awareness, education and training among its people controls. Dr. Carrow warns that awareness is not about blaming staff, and that systems should be designed so that a single mistake does not cause serious harm. She reads examples of awareness programmes that improved reporting without blaming those who clicked.
20.2 Designing activities
Aisha designs a programme for Ashfield: a short annual course, monthly two-minute tips by email, simulated phishing exercises and branch discussions of real fraud attempts with personal details removed. She tailors content to roles. Tellers learn to spot social engineering by phone; finance staff learn about fake payment requests. She keeps sessions short, because long annual sessions are quickly forgotten. She tests the first monthly tip with five staff members, who say it is clear and takes under two minutes to read. The IT manager approves the programme for the coming year.
20.3 Encouraging reporting
Reporting matters more than never clicking. Aisha recommends a report button in email and a simple phone number for branch staff. Every report receives a thank-you, even if the message was harmless. When one teller reports a suspicious call, the IT manager discovers several branches received the same call. Dr. Carrow explains that staff who fear blame stop reporting, which removes one of the organisation's best detection sources. The IT manager blocks the caller's number and warns all branches within the hour.
20.4 Measuring outcomes
Aisha proposes measures: training completion, the share of simulated phishing emails reported and the time to first report of real suspicious emails. She avoids using click rates alone, because they depend on how hard each simulation is. She plans to track trends over a year. She learns that awareness outcomes are best measured by behaviour, especially reporting, rather than by attendance alone. She sets up a simple spreadsheet to track the three measures monthly, and the IT manager agrees to include the results in the quarterly board report.
Worked example
Aisha designs role-based awareness with short sessions, makes reporting easy and thanked, uses a reported call to detect a wider campaign and measures behaviour.
Synthetic case. The programme is synthetic.
Errors and limits
Blaming staff for clicks discourages the reporting that detects attacks.
Exercises
- EX058 — Teller topic. What do tellers learn to spot? Rubric: 3 = social engineering by phone;; 2 = partly correct;; 1 = other;; 0 = none.
- EX059 — Report value. What did one teller's report reveal? Rubric: 3 = several branches received the same call;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX060 — Click caution. Why avoid click rates alone? Rubric: 3 = they depend on simulation difficulty;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 20 (chapter 20 of 40)
← Chapter 19 · Course chapter index · Chapter 21 →
Continue to the next authored lesson.