How to Stand Up a Security Awareness Training Programme

Direct answer: To stand up a security awareness training programme that holds up to an audit, define who is in scope, pick content that matches the roles you have, set two triggers so training happens on hire and every year after, run phishing simulations and act on the failures, and keep a dated completion record for every person. The programme is not the training. It is the evidence that the training reached everyone and kept running.

Step 1: Define who is in scope

Start with the population, because coverage is the thing an auditor tests and the thing most programmes get wrong. In scope is anyone who can access systems or data that fall inside your compliance boundary: employees, yes, but also contractors with a cloud role, a code repository seat or a support tool login. Pull the list from your identity provider rather than from HR, because the identity provider is where access actually lives and HR will not know about the contractor someone added directly. Reconcile the two lists and you have your denominator.

Step 2: Pick content that matches your roles

A single generic module for everyone is enough to start, and for a small company it may be enough full stop. As you grow, add role-specific training where the risk concentrates: secure coding for developers, wire and invoice fraud for finance, data handling for anyone touching customer records, and privileged-access hygiene for administrators. The point is relevance. ISO 27001 in particular expects awareness to fit the role, and a developer sitting through a module aimed at accounts payable is evidence of effort, not of a working control.

Step 3: Set the two triggers

Every framework reduces to two triggers. On hire, new personnel complete training close to their start date, recorded. Annually, everyone refreshes so no one exceeds twelve months. Wire both into a process that does not depend on someone remembering. The onboarding trigger belongs in the joiner checklist alongside account creation. The annual trigger belongs on the compliance calendar with a named owner and a due date. Treat a missed completion the way you would treat a missed access review, as something to chase and close, not a formality.

Step 4: Run a phishing simulation

Baseline first. Run one simulated phishing campaign across the whole population before you draw any conclusions, because the first result tells you where you actually stand rather than where you hope to. Then run them on a recurring cadence, quarterly for most teams. Record each campaign: date, population, click rate, report rate. The report rate is the number worth improving, because a workforce that reports suspicious mail is a detection control, not just a lower-risk target.

Step 5: Capture completion records as evidence

From day one, store completions in a form you can sample. One record per person: name, module or version, date. Tie it to the roster from step one so coverage is provable in a single view rather than reconstructed from inboxes a year later. If you run a separate policy acknowledgement, and PCI DSS wants one, keep it as its own record rather than folding it into the training completion. The test you are building toward is simple: an auditor names ten people, and you produce ten dated records inside the relevant period without a search party.

Step 6: Handle repeat clickers and non-completers

A programme is judged on what it does with failures. Define up front what happens when someone clicks a simulated phish or misses their training deadline. Remedial training for repeat clickers, recorded. An escalation path for people who ignore the annual refresh, usually through their manager. The pattern that fails an audit is a good headline result with no trail showing the exceptions were handled, because that tells the auditor the control identifies problems and does nothing about them.

Step 7: Keep the programme audit-ready between audits

The work after launch is maintenance, and it is where programmes decay. New starters have to hit the onboarding trigger every time, not just in quiet months. The annual refresh has to land inside the window for everyone, including executives and board members with access, who sit outside the normal flow and are a common gap. Someone has to own the calendar. A quarterly fifteen-minute look at coverage against the current roster catches drift before fieldwork does. If you are not sure which cadence and evidence your framework expects, the security training requirement finder maps it per framework.

What it takes to run, in hours

The setup is a few hours: reconcile the roster, choose the content, wire the two triggers, and schedule the first phishing campaign. After that the standing cost is small and lumpy. New starters are a few minutes each at onboarding. The annual refresh is a push and then chasing the stragglers, which is the part that eats time because a predictable slice of any workforce ignores the first three reminders. Each phishing campaign is an hour to set up and an hour to review, plus the remedial follow-up for the people who failed. Budget a quarterly fifteen-minute reconciliation of completions against the current roster, because that single habit is what keeps the programme from drifting into an exception while nobody is watching. None of this is difficult work. It is work that needs a named owner, and the programmes that fail are the ones where the owner left and the triggers kept running on nobody.

Common mistakes

Training employees but not contractors with access. Running once and never refreshing. Letting the annual refresh slip outside a Type II observation window. Reporting phishing results with no remediation trail. Conflating a policy acknowledgement with training when a framework wants both. And building the whole thing around a platform demo before checking what your actual framework requires, which is how teams buy features they do not need and miss the record-keeping they do.

How long does it take to stand up?

The mechanics of a basic programme can be in place quickly. The part that takes real time is the first full cycle of evidence, because a Type II needs the records to exist across the observation window. The sooner the triggers and records are running, the sooner that clock starts.

Do we need a platform to do this?

No. A platform makes records easier to produce and harder to lose, but the control is coverage and cadence, and a disciplined manual process evidences the same thing. Choose the platform because it saves you work, not because you think the auditor requires one.

Who owns the programme once it is live?

Name one person, usually whoever owns security or people operations, and put the annual refresh and the phishing cadence on their calendar with due dates. The programme does not need much time, but it does need an accountable owner, because the common failure is not bad training. It is triggers that keep firing after the person who set them up has gone, with nobody reconciling coverage until fieldwork exposes the gap.