security_awareness_training v1.0.0

name: "security_awareness_training" description: "Teaches a whole team safer habits with short lessons on phishing, passwords, and data handling built around real tasks, fair simulated phishing run with consent and no shaming, and measurement of behaviour change over time instead of click counts alone. Triggers when someone needs to build, run, or fix staff security awareness training, plan phishing simulations, write a password or reporting lesson, or measure whether training changed behaviour." metadata: { "includeInPrompt": true }

Security Awareness Training

Purpose

Most staff training fails in a predictable way. It teaches people to spot suspicious emails in a quiz, then measures success by how few people clicked a test message. Real work is messier. People click because they are busy, stressed, or doing exactly what their job asks them to do, which is open messages and follow links. This skill builds training around the habits that hold up under that pressure: verify a request through a second channel, use a password manager and a strong second factor, handle data by its sensitivity, and report fast when something looks wrong. Reporting is treated as the win, not as an admission of failure.

The method follows NIST SP 800-50. For every piece of material, answer two questions first. What behaviour do we want to reinforce. What skill do we want people to learn and apply. If a lesson cannot answer both, cut it.

Workflow

1. Map the real tasks before writing any lesson. List what each group actually does with messages, money, and data. Finance verifies payment changes. Support opens links and attachments from strangers. Managers approve access and expenses. Developers handle secrets and production data. Write lessons for those tasks, in the words those teams use, with screenshots or examples from their own tools where policy allows it.
2. Fix the reporting path first. Before any lesson or simulation, confirm there is one clear way to report a suspicious message, ideally a report button in the mail client, and that the security team replies fast with thanks and a clear outcome. Teach the NCSC line that staff already remember: if in doubt, call it out. A lesson that tells people to report into a slow or silent inbox trains them to stop reporting.
3. Run the core lessons in short sessions. Six lessons cover the baseline. Each one runs 10 to 15 minutes, teaches one procedure, and ends with practice on a realistic example. Full plans are in references/lesson-plans.md.

• Lesson 1, Verify before you act: pause on any request to pay, change bank details, share data, or reset access. Verify through a known number or a separate channel, never through contact details in the message itself.
• Lesson 2, Report fast: how to use the report button, what happens next, and why a report after a click still helps.
• Lesson 3, Passwords that work: length over complexity, three random words for a memorable passphrase, a password manager for everything else, and no reuse across accounts.
• Lesson 4, Second factors that resist phishing: passkeys and hardware keys first, app codes next, and why a code or a push approval can still be handed to a fake site.
• Lesson 5, Handle data by sensitivity: classify before you share, use approved storage and sharing links, check recipients before sending, and clean up copies you no longer need.
• Lesson 6, Devices and remote work: updates, screen lock, approved apps only, and extra care on personal devices and public networks.

1. Teach current password rules, not the old ones. NIST SP 800-63B Revision 4 sets a minimum of 15 characters for a password used on its own and 8 characters for a password used with multi-factor authentication. Systems should allow at least 64 characters. There are no mandatory composition rules, no scheduled expiry, and change happens on evidence of compromise. New passwords get screened against lists of breached and common passwords. If local policy still forces 90 day changes or symbol mixes, flag the gap to the policy owner with the standard cited. Do not train staff to work around a bad policy in secret.
2. Add role lessons where the risk sits. Finance gets payment verification drills and invoice fraud cases. People with privileged access get session and approval safety. Anyone who handles personal or customer data gets sharing, retention, and incident steps for their data type. New starters get lessons 1 to 3 in week one, then the rest in their first month. Everyone gets a short refresher when a real incident or a new attack pattern shows a gap, not only on an annual cycle.
3. Run simulated phishing only under the fair rules. Simulations are practice, not a trap. Follow references/simulation-rules.md in full. The short version: tell staff the programme exists, get HR and legal review first, ban lures about pay, bonuses, health, family, or job security, get consent before any test touches a personal device or phone number, give instant teaching at the moment of a click, and never name, rank, or discipline people from simulation results.
4. Measure behaviour, not theatre. Track the sheet in references/measurement.md with bin/measure.py. The headline numbers are report rate and time to report. Click rate is kept, but only alongside reporting, repeat interaction, verification behaviour, and real incident reports. Compare the same team against itself over at least three rounds of similar difficulty. A falling click rate on easier lures proves nothing.
5. Close the loop every round. After each lesson cycle or simulation, publish a short note to staff: what was tested, what people did well, what will change, and one habit to practise next. Thank reporters by group, never by naming people who clicked. Feed every gap back into a lesson, a procedure fix, or a technical control. Training is one layer. NCSC guidance is clear that defences also need filtering that keeps attacks from reaching people, controls that limit damage after a click, and a fast incident response.

Output Contract

A finished programme contains:

• A task map by team, with the risky tasks each lesson covers
• Lesson plans for the six core lessons, each with the behaviour, the skill, the procedure, and a practice example
• A written reporting procedure, with the report method, the expected response time, and the thank you message staff receive
• A simulation plan that passes every rule in references/simulation-rules.md, signed off by HR or an equivalent owner
• A behaviour measurement sheet covering at least three rounds, produced or checked with bin/measure.py, with report rate and median time to report shown before click rate
• A short staff summary for each round, with wins first and no individual names attached to clicks

Operating Rules

1. Accuracy rule: every factual claim in training material must trace to a verified source. See references/research-brief.md. Never invent statistics, dates, or quotes. Unverifiable means cut it or frame it as opinion.
2. No shaming, ever. No leaderboards of people who clicked, no names in reports to managers, no discipline based on a single simulation click. NCSC warns that punishing people for clicking on messages you sent starts to resemble entrapment, and that blame makes people hide mistakes and report less.
3. No cruel lures. Never build a simulation on pay, bonuses, redundancy, a health scare, a family emergency, or a personal benefit the person has reason to want. Those lures buy a click with trust, and the trust does not come back.
4. Consent and scope come first. Announce that simulations will happen, without giving dates. Get HR and legal review before the first round. Any test on a personal device, personal email, SMS, or voice call needs explicit consent from the people in scope and a check against local telecom and employment rules.
5. Teach procedures over spot-the-phish tricks. Attackers change wording, logos, and sender tricks faster than lessons can track. A verification callback, a report button, and a password manager keep working when the lure gets better.
6. Never promise that training stops phishing. No training teaches people to spot every attempt, and some attacks will get through. Say so plainly, and show the other layers that carry the load when a person has a bad day.
7. Keep data from the programme minimal. Store results by team for trends. Keep individual records only as long as coaching needs them, restrict who can see them, and state the retention period in the programme notice.