Security Awareness Policy Template

A security awareness policy is a short document setting the ground rules: what the organisation expects from employees, and what employees can expect in return. One or two pages is plenty. A policy nobody reads protects nobody.

Here is the structure to work from.

---

The sections to include

1. Purpose. Two sentences on why the policy exists — reducing risk from phishing and social engineering, and meeting the obligations you are subject to. Auditors read this first.

2. Scope. Who it covers: normally every employee, contractor, and temporary worker with access to company systems. State explicitly whether contractors are included, because this is the gap most policies leave open.

3. Roles and responsibilities. Who owns the programme, who delivers training, who employees report to, and what managers are expected to do. Without a named owner, the policy quietly becomes nobody's job.

4. Training requirements. What training is mandatory, for whom, and how often. Be specific: "within 14 days of joining, then annually, with short monthly modules" is enforceable. "Regular training" is not. Note any role-specific requirements for finance, IT, or executives.

5. Phishing simulations. State plainly that the organisation runs safe, authorised simulated phishing, why, and how results are used. This is the clause that protects the programme later — running simulations without a written mandate is what turns a drill into a grievance.

6. Reporting obligations. How to report a suspicious message, and the expectation that employees report rather than delete. One sentence, one clear route.

7. The no-blame commitment. Explicit language that employees who report their own mistakes will not face disciplinary action for the error itself. This clause does more for your reporting rate than any training module, and its absence is felt immediately.

8. Consequences. What happens with repeated non-completion or wilful policy breach. Keep it proportionate and separate it clearly from the no-blame clause above, so the two do not read as contradictory.

9. Review cycle. When the policy is reviewed and by whom. Annually is standard, and auditors check the date.

---

Why bother writing it down

Without a policy, training feels arbitrary and simulations feel like a trap. A written document turns both into something the organisation committed to, rather than something IT decided to do.

It also does real work in three places: onboarding, where new hires learn expectations once rather than by rumour; audits, where assessors ask for the policy before they ask for evidence; and awkward moments, where an employee who verified an executive's payment request can point to the policy instead of defending a personal judgement call.

Making it stick

Do not file it and forget it. Share it when someone joins, explain the reasoning rather than just circulating the document, and keep it somewhere findable at the moment a question arises.

Then keep it honest. If the policy promises quarterly simulations and you run one a year, the gap is the first thing an auditor finds — and the first thing employees notice.

---

Related Learning

• Security awareness compliance 101
• How to build a security awareness program
• Managed security awareness training