How to build a security awareness programme: a 12-month plan, step by step

Last week's article set out the evidence auditors accept for security awareness. This one is about the step before that: building the programme that produces the evidence. It does not need a platform, a budget line or a full-time owner to start. It needs six decisions, written down, and twelve months of following them.

The steps below fit an organisation of fifty people or five thousand. The difference is the number of audiences, not the method.

Step 1: Write a short policy and name an owner

A security awareness policy is one or two pages. It says why the programme exists, who it covers, how often people are trained, what happens when someone misses a session, and who is accountable. The owner is a named role, not a team.

Two points are worth settling in the policy and nowhere else. First, scope: do contractors and temporary staff with access to your systems take part? They should, and the policy is where that is decided. Second, consequences: what follows repeated non-completion. A policy that is silent on this leaves every manager to invent an answer.

Step 2: Define audiences and match them to risk

One session for everyone is the most common design and the weakest. List the groups that face different risks and need different content. A workable first list has six: all staff, new joiners, administrators and other privileged users, developers, executives, and contractors.

Then look at your risk register and your incident history. If phishing and payment fraud lead the list, they lead the plan. If a new system goes live in March, the people who will use it are an audience in February. The plan should be traceable to risk in one glance.

Step 3: Put twelve months on one page

The plan is a table: months down the side, audiences across the top, one topic and one channel in each cell that needs one. Most cells stay empty, and that is the point. A small programme that runs every month is stronger than a large one that runs once.

A sensible first year has four core modules for all staff, spread across the year, a joiner module delivered in the first weeks of employment, one deeper session each for privileged users and executives, and short reminders between modules. Add two review points, at six and twelve months. Get the plan approved and dated. From that moment it is the baseline every later record is checked against.

Step 4: Agree the phishing simulation rules before the first test

Phishing simulations are the part of a programme most likely to go wrong, and they rarely go wrong technically. They go wrong because nobody agreed the rules.

Write a short simulation policy before the first email is sent. It should say who approves each exercise, which themes are off limits (pay, redundancy and health are the usual exclusions), how results are reported, and what happens to someone who clicks. The answer to the last question should be more training, never public naming. Results reported by team or by role protect the reporting culture the programme depends on. A reported test email is a success and should be counted as one.

Agree this with HR and, where relevant, staff representatives. A simulation that surprises HR will be the last one you run.

Step 5: Keep one register

Every session, every audience, every date, in one place: how many people were expected, how many completed, who did not, and the follow-up date. Simulations and their results belong in the same register, with a link to where the detail is held.

One register sounds obvious and is rarely done. Attendance usually sits in a learning platform, a spreadsheet and three inboxes. Moving it to one place takes an afternoon and removes the most common audit problem, which is not missing training but evidence nobody can assemble.

Step 6: Choose a few measures and review them twice a year

Pick three or four measures you can collect without new tooling: completion by audience, quiz scores, simulation click rate and simulation report rate. Record the baseline in month one, even if it is poor. Set a target for each.

At six months and twelve months, hold a short review. Look at the numbers, decide one or two changes, and record them: a topic added, a module shortened, an audience split in two. That record closes the loop. It is also the piece of evidence most programmes cannot show.

What a small team can leave for year two

Not everything belongs in the first year. Gamification, monthly simulations, role-specific tracks for every department and a dedicated platform can all wait. In year one the aim is a programme that is planned, delivered, recorded and reviewed. Depth comes after the cycle has run once.

How the six steps map to the frameworks

ISO/IEC 27001:2022 addresses awareness in clause 7.2 (competence), clause 7.3 (awareness) and Annex A control 6.3 (awareness, education and training). NIST CSF 2.0 addresses it in the Awareness and Training category: PR.AT-01 for all personnel and PR.AT-02 for people in specialised roles, with improvement drawn from evaluations under ID.IM-01. The policy and plan answer the "is there a programme" question in both. The audiences answer the role-based expectation. The register and measures answer "did it reach people" and "did it work". The review answers improvement.

A note on using AI

AI tools are good at adapting one message for six audiences and at drafting quiz questions. Use them for that, label the output as a draft, and have a named person approve it. Do not paste staff names or simulation results into a public tool, and never use AI to produce attendance records, results or sign-offs. A record that was generated and not observed is not evidence.

The free kit

Each step above has a matching file in the Cybersecurity Awareness Programme Kit: a policy, a 12-month plan, four module outlines, a phishing simulation policy, an attendance and evidence register, a metrics dashboard and a crosswalk between ISO/IEC 27001:2022 and NIST CSF 2.0, with a worked example in every template. It is free, with no sign-up: Cybersecurity Awareness Programme Kit.