How to Write a Cyber Security Policy That People Actually Follow

Most security policy libraries are written to satisfy an auditor. They reference the right frameworks, they include all the required policy elements, and they are approved by the board at the appropriate interval. They are also written in language that most staff find impenetrable, structured in a way that makes it difficult to find the specific guidance relevant to a given situation, and long enough that reading the full document is not a realistic expectation for anyone with a day job.

A policy that nobody reads is not a control. If the behaviour the policy is intended to produce does not actually change because of the policy, the policy is a documentation exercise, not a security measure. Writing a policy that functions as an actual control means starting with the people who are supposed to follow it, not with the framework requirement that justifies having a policy in the first place.

Start With the Behaviour, Not the Control Requirement

The right question to ask when writing a security policy is: what do we need people to do differently, and what information do they need to do it? That question leads to a very different document than the question: what does the framework require us to document? A policy designed to change behaviour tells people what they need to know, in the language they use, at the level of specificity that lets them make the right decision when the situation arises.

Take an acceptable use policy. A compliance-driven acceptable use policy is typically several pages of prohibitions written in legal language. A behaviour-driven acceptable use policy answers the questions that staff actually ask: Can I use my work laptop for personal use? Can I access work systems from a public network? What do I do if I receive a suspicious email? Those are the questions that come up in practice. Answering them directly, in plain language, is what makes the policy functional rather than decorative.

Separate Policy From Procedure

One of the most common structural problems in security policy libraries is mixing policy, procedure, and technical standards in the same document. A policy states what the organisation has decided. A procedure describes how to implement that decision. A technical standard specifies the technical parameters that must be met. Mixing all three into a single document produces a document that is too detailed for executives, too vague for practitioners, and too mixed in scope to update efficiently.

The separation matters operationally. When a process changes, you should be able to update the procedure without touching the policy. When a technical standard is revised, you should be able to update the standard without reviewing the entire policy document. Keeping these layers separate makes the policy library more maintainable, and it makes each document more readable because it is focused on a single level of guidance. Policy documents should be short enough to read in ten minutes. Procedures can be longer, but they should be specific enough to be actionable.

Write for the Reader, Not the Framework

Security policy language has a style that is immediately recognisable. It uses the passive voice extensively. It defines terms before using them. It refers to "the organisation" instead of "us" or "you". It uses "shall" and "must" in ways that sound like legal drafting but are often unclear in practice. None of those choices make the policy easier to understand or more likely to be followed.

Plain language does not mean informal language. It means language that the intended reader can understand without a legal or technical background. "You must use a different password for each of your work accounts" is plainer and more actionable than "Users shall maintain unique credentials for each system accessed in the performance of their duties." Both say the same thing. One of them is more likely to be understood and followed by the person reading it at their desk after a security awareness session. Write the version that works for that person, and the auditor will still recognise it as a policy.

Build In Enforcement and Accountability

A policy without consequences is an aspiration. For a policy to function as a control, it needs to be enforceable, and the enforcement mechanism needs to be understood by the people the policy applies to. That does not mean every policy breach needs to result in disciplinary action. It means that the policy is connected to the organisation's accountability structure in a way that makes compliance a real expectation rather than an optional preference.

Enforcement starts with awareness. Staff cannot follow a policy they do not know about. At a minimum, policies should be communicated at onboarding, reviewed annually, and accessible in a place where staff can find them when they need to check something. Beyond awareness, the policies that matter most should be supported by technical controls where possible. A policy that says "you must use multi-factor authentication" is much more enforceable if the system requires multi-factor authentication than if it is left to individual compliance. Where technical enforcement is not possible, manager accountability and clear breach reporting processes are the next best option.

• Identify the specific behaviour each policy is intended to produce before writing it
• Keep policy documents separate from procedures and technical standards
• Write in plain language directed at the person who needs to follow the policy
• State consequences clearly and ensure they are connected to the organisation's accountability structure
• Support policies with technical controls where possible, and clear reporting processes where not
• Communicate policies at onboarding, review annually, and keep them accessible

To discuss security policy development for your organisation, contact Cyberlinx at info@cyberlinx.com.au.