Security Awareness Plan Template: Audiences, Topics, Phishing Simulation and Metrics

Most security awareness programmes are an annual e-learning module and a monthly phishing test, which produce completion certificates and click rates but very little change in how people actually work. This template sets out a one-year awareness plan that an organisation can adopt as written: who the audiences are, what each one learns and when, how phishing simulations are run without blaming staff, and which metrics go to leadership. It follows the life cycle in NIST SP 800-50 Rev. 1 and the UK NCSC position that reporting, not clicking, is the behaviour to build. It also covers two audiences most plans leave out: developers who handle secrets and API keys, and staff using AI tools. It is written for security awareness leads, CISOs and HR partners. To judge how mature your current programme is, use the Security Awareness Maturity Model.

How to use this template

• Replace text in square brackets, such as [Organisation], [Awareness Lead] and [quarterly], with your own names and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a documented exception may be justified.
• Complete the audience table in section 4.1 first: every other section depends on it. NIST SP 800-50 Rev. 1 treats audience segmentation as part of planning, before any content is designed.
• Agree the phishing simulation rules in section 4.4 with [HR] and [Legal] before the first campaign. The NCSC warns that punishing people for falling for simulations can resemble entrapment and erodes the trust that reporting depends on.
• Use it with the Phishing Simulation Programme Guide, the AI Acceptable Use Policy Template and the Phishing Incident Response Playbook.

1. Purpose

This plan sets out how [Organisation] will build the security knowledge and habits its workforce needs over the period [1 January to 31 December YYYY]. Its aim is measurable behaviour change: more and faster reporting of suspicious messages and mistakes, safer handling of credentials and data, and correct use of approved AI tools. Course completion is recorded for compliance but is not treated as evidence that the plan is working.

2. Scope

This plan applies to all employees, contractors, temporary staff and third parties who hold an [Organisation] account, from their first day of access. It covers baseline awareness for everyone, role-based training for higher-risk roles, phishing and social engineering exercises, and ongoing communications. Technical training for the security team itself is covered by the [Security Team Development Plan].

3. Roles and responsibilities

4. Policy statements

4.1 Audiences

1. [Organisation] must segment its workforce into the audiences below and assign each a learning path. Membership must be derived from [HR system / identity platform groups] so it updates when people join or change role.
2. Each audience must have a named content owner and at least one behaviour it is expected to show.

4.2 Onboarding and annual cycle

1. New workforce members must complete the baseline module within [5 working days] of account creation. NIST SP 800-50 Rev. 1 gives an example policy requiring initial training within 24 hours of account grant; choose a value you can enforce.
2. Role-based training must be completed before access to higher-risk systems or privileges is granted, and refreshed at least [annually].
3. Awareness activity must run throughout the year as short campaigns, not as a single annual module.
4. Content must be updated within [30 days] of a significant incident, a new attack technique seen by [Security Operations], or a major system change.

4.3 Topics and annual calendar

1. Baseline topics must include the four behaviours promoted by CISA's Secure Our World campaign: recognise and report phishing, use strong passwords with a password manager, turn on MFA, and update software.
2. The developer module must cover: never committing secrets, using [secrets manager] and short-lived credentials, what to do when [GitHub push protection / pre-commit scanning] blocks a push (remove the secret and rotate it; the "used in tests", "false positive" and "fix it later" bypass reasons are audited and must be used honestly), vetting packages, IDE extensions and AI coding assistants, and reporting an exposed key to [Security Operations] within [1 hour]. See the Secrets Rotation Runbook Template.
3. The AI tools module must cover: which tools are approved, which data classes must never be entered, connecting AI tools or agents to company data only with approval, treating AI output as unverified, and recognising prompt injection in documents and web pages. See the Shadow AI Policy Template.
4. Finance and executive content must cover voice and video impersonation. See the Deepfake and AI Impersonation Guide.

4.4 Phishing simulation rules

1. Simulations are a learning exercise, not a test of individuals. Results must not be used in performance reviews, disciplinary action, league tables of named staff, or public call-outs. NIST SP 800-50 Rev. 1 states that such exercises should not be punitive.
2. Staff must be told in advance, in the baseline module, that simulations happen at random through the year.
3. Themes must be approved by [Awareness Lead] and [HR]. Themes that exploit pay, bonuses, redundancies, health or personal hardship must not be used.
4. A person who clicks must see a short, supportive explanation of the cues, never a warning of consequences.
5. Each campaign must record its difficulty, for example using the NIST Phish Scale referenced in SP 800-50 Rev. 1, so that results are compared like for like.
6. Simulations should include [quarterly] reporting-focused exercises and, at least once a year, a non-email exercise such as SMS, voice or a payment verification tabletop.
7. Individual simulation data must be retained for no longer than [12 months] and reported only in aggregate by [department / audience].

4.5 Reporting and feedback

1. [Organisation] must provide a one-click report button in [email client] and a [chat channel / phone number] for other lures.
2. Reporting a message, including one already clicked or acted on, must never lead to sanctions. This commitment must be stated by [CEO / CISO] and repeated in the baseline module.
3. Every report must receive an acknowledgement and, where the message is real, a thank-you. Real phishing reported by staff must trigger the Phishing Incident Response Playbook.

4.6 Metrics

1. Click rate may be recorded as context, but must not be the headline metric, and must always be shown with campaign difficulty and report rate. The NCSC advises that metrics should reward reporting as well as measure clicks.

5. Exceptions

1. Exceptions to training deadlines (for example long-term leave) must be requested by the line manager and approved by [Awareness Lead], with a new completion date.
2. Exceptions that would allow access to higher-risk systems without role-based training must be approved by [CISO], time-limited to [30 days] and recorded in the [Risk Register].
3. Accessibility adjustments, such as alternative formats or extra time, must be provided on request and do not count as exceptions.

6. Compliance and monitoring

1. [Awareness Lead] must keep training records sufficient for audit (who, what, when) and report coverage monthly to line managers.
2. Access to higher-risk roles should be conditional on completion of the role path, enforced through [identity platform / access request workflow].
3. Metrics in section 4.6 must be reported to [CISO] quarterly and to [Executive Committee / Board] at least [twice a year], with a short narrative of what changed.
4. This plan supports NIST SP 800-53 Rev. 5 AT-1, AT-2 (including AT-2.1 Practical Exercises and AT-2.3 Social Engineering and Mining), AT-3 and AT-4, NIST CSF 2.0 PR.AT-01 and PR.AT-02, CIS Controls v8.1 Control 14, and ISO/IEC 27001:2022 Annex A control 6.3. Organisations that provide or deploy AI systems in the EU should also consider the AI literacy duty in Article 4 of the EU AI Act, which has applied since 2 February 2025.

7. Review and approval

Implementation guidance

1. Baseline first (month 1): collect one month of report volume, time to report and real phish data before changing anything, and run one simulation of known difficulty. Without a baseline, next year's figures mean nothing.
2. Fix reporting before testing (months 1 to 2): deploy the report button, agree the no-blame statement with [HR], and make sure [Security Operations] can acknowledge every report. Testing staff before reporting works teaches them that security only notices failure.
3. Pilot with one audience (months 2 to 3): run the developer or finance path with a single team, ask for feedback, and adjust length and tone. Roll back any module that draws complaints of being patronising or irrelevant.
4. Roll out by quarter (months 3 to 12): follow the calendar in section 4.3, and replace generic content with real lures your own staff have reported.
5. Back training with controls: the NCSC is clear that training alone cannot stop phishing. Pair each module with a control: phishing-resistant MFA with the credentials theme, secret scanning with the developer module, an approved AI tool with the AI module. See the Phishing-Resistant MFA Guide.

Small and large organisations

• Small (under [250] staff): keep three audiences (all staff, finance, technical staff), use a quarterly simulation and a shared chat channel for reports, and let the [CISO] or IT lead own the plan directly.
• Large: use the full audience table, assign content owners per audience, localise content, and route reports into a ticketing workflow so feedback is reliable at volume.

Common failure patterns

• Click rate as the goal: a falling click rate often reflects easier lures, not better staff. Report it only next to difficulty and report rate.
• Developers left out: generic modules do not teach what to do with an exposed key. In the xAI API key leak, a scanner alerted the developer on the day of the commit, yet the key stayed valid for about two months.
• AI rules taught after the fact: in the Samsung ChatGPT leak, engineers pasted source code into a public AI tool within weeks of it being allowed, before clear data rules were in place.
• No verification habit in finance: the Arup deepfake fraud succeeded after a video call overcame an employee's initial suspicion; a second-channel check is the behaviour to drill.
• Blame-based follow-up: naming or disciplining clickers stops people reporting the real incident later.

Related NHI Mgmt Group resources: Security Awareness and Human Risk Management Guide · Security Awareness Maturity Model · Phishing Guide · Security Awareness Training Buyer's Guide · Incident Response Plan Template