How to write a simple IT security policy staff will actually follow

Why bother with a written policy

Without something written down, security depends on what each person happens to believe. One staff member thinks it is fine to forward work email to a personal account; another thinks reporting a suspicious click will get them in trouble. A policy settles those questions in advance. It also gives managers something to point to when behaviour needs correcting, and it is evidence for insurers, clients and auditors that the business has thought about security. It does not need to be long. A short document that staff have read and signed beats a thick template downloaded from the internet that nobody opens.

What to cover

Start with accounts and passwords: unique passwords, a password manager, MFA on everything that supports it and never sharing logins. Then devices: company equipment is for work, screens lock automatically, laptops are encrypted, nothing is installed without approval, and lost devices are reported immediately. Then email and messages: how to handle suspicious messages, the rule for verifying payment changes and the ban on auto-forwarding to personal accounts.

Add data handling: where files are stored, which information is confidential, how to share it with outsiders and what not to put on USB drives or personal cloud storage. Include remote work rules, such as using secure Wi-Fi and not leaving laptops in cars. Finish with incident reporting: what to report, to whom and the assurance that honest mistakes reported quickly will not be punished.

Write it the way people talk

Use short sentences and the second person: you must, you should, you must not. Explain the reason for each rule in a line, because people follow rules they understand. Avoid technical terms where possible, and define the ones you need. A rule like lock your screen when you leave your desk, because anyone walking past can read client files is clearer than a paragraph on access control. Separate the musts from the shoulds. Musts are the non-negotiables that protect the business. Shoulds are good practice. Mixing them creates a document where everything feels equally important and nothing feels essential.

Responsibilities

Name who owns the policy, usually the owner or a manager, and who manages IT, whether that is a staff member or an outside provider. Say who approves new software, who grants and removes access, and who staff contact with security concerns. If you use an IT provider, note which responsibilities sit with them and which stay with the business. Responsibilities also include managers. They should make sure new staff read the policy, raise concerns about behaviour early and lead by example. A policy that the owner ignores will not be taken seriously by anyone else.

Rolling it out

Introduce the policy at a team meeting rather than by email. Walk through the main points, answer questions and explain why it matters to the business and to clients. Ask everyone to read and acknowledge it, and keep a record. Add it to onboarding so new starters see it in their first week. Back the policy with technical settings wherever you can. If the policy says MFA is required, enforce MFA. If it says laptops are encrypted, enforce encryption. Policies work best when they describe how systems already behave, leaving fewer decisions to individual memory.

Keeping it current

Review the policy once a year, and whenever something significant changes: a move to new software, a shift to hybrid work or an incident that exposed a gap. Update the date and version, and tell staff what changed. A policy last updated five years ago, mentioning a server you no longer have, signals that nobody is paying attention. Over time you may add separate short documents for specific topics, such as a BYOD agreement, an acceptable use policy or an incident response plan. Keep the main policy as the entry point that links to them, so staff have one place to start.

A sample structure

If you want a starting shape, try seven short headings: purpose and scope, accounts and passwords, devices, email and payments, handling information, working away from the office, and reporting problems. Under each, write three to six rules, each one sentence with a reason. Add a short responsibilities table at the end listing the owner, the IT contact and the privacy officer, then the version number and review date.

That structure usually fits on three pages. Resist adding detailed technical settings such as firewall rules or backup schedules; those belong in IT documentation that staff never need to read. The policy is for people. Its job is to tell an ordinary employee, in a few minutes, what the business expects of them and where to turn when something looks wrong.