
Build useful training around real roles, simple reporting processes and measures that reveal whether safer behaviour is becoming easier.
Start with the decision people need to make
Completing a training module is an activity; recognising and reporting a suspicious request is an outcome. A useful awareness programme identifies the decisions that create risk in everyday work. Those decisions differ across finance, sales, customer support, IT and management. Begin with a few realistic situations instead of trying to teach everyone the whole security vocabulary at once.
Ask each team which unusual requests it receives and where the normal process becomes unclear. Finance may need to verify beneficiary changes, while support staff may need to check identity before changing account details. Use these conversations to choose learning objectives that can be observed. An employee should know what to do, where to find help and which actions require approval.
Connect training to working processes
Teaching staff to report concerns has little value if the reporting address is hard to find or nobody responds. Check the process before running the lesson. Make guidance available where people work, keep it concise and provide an alternative route if the normal system is unavailable. Include the same instructions in onboarding and when responsibilities change.
NIST's learning-programme guidance encourages an ongoing approach that supports behaviour change and reflects the needs of different roles. Apply that principle by connecting short lessons with actual controls. For example, a session on information sharing should show the approved sharing method and the review process, rather than ending with a general instruction to be careful.
Use respectful practice
Scenario discussions allow a team to practise without creating a real incident. Present a fictional request and ask what should happen next. Invite participants to identify uncertainty and missing information. Keep examples relevant to their work and avoid public embarrassment. People are more likely to report promptly when they expect useful support rather than blame for an honest mistake.
If simulated phishing is used, define the purpose, scope and handling of results before the exercise. Avoid misleading participants with emotionally harmful scenarios. Do not collect real passwords or unnecessary personal data. Evaluate the reporting process as well as individual actions. A simulation that catches people but leaves a slow or confusing response process unchanged has limited practical value.
Measure evidence of improvement
Use several measures rather than relying on a single click rate or completion percentage. Look at whether employees know the reporting route, whether reports arrive with useful context and whether staff can demonstrate the correct verification step. NIST's publication includes evaluation and improvement as part of a learning programme. Treat the measures as feedback for programme design, not a league table of people to blame.
Discuss unexpected results with the teams involved. An increase in reports may mean people are more confident about raising concerns, rather than that security has worsened. Repeated errors may reveal an application or approval process that encourages shortcuts. Review the controls and the lesson together, then make a specific change and observe whether it helps.
Keep the programme connected to business changes
Refresh examples when the organisation adopts a new collaboration tool, payment process or remote-working arrangement. Give managers a practical role in reinforcing the agreed steps. Keep a record of lessons, feedback and improvements so the programme survives staff changes. The aim is a workplace where the secure action is understandable, supported and realistic during a normal working day.



