How to write a policy
08:00 Monday, 13 September 2021
UK Cyber Security Council
Hands up if you relish reading cyber security policies, procedures and standards. Although I can’t see you, I imagine that even if I could, very few hands would be extending upwards.
On one hand, policies are considered by many as an annoyance that gets in the way of them doing their job. This is understandable to an extent, but one can mitigate this feeling in part through training, education and engagement (and, hopefully in the minority of cases, by the disciplinary action against serious transgressions).
There is another, more practical reason that people don’t enjoy reading policies: they’re dull, often full of technical jargon or pointless content, poorly laid out, and overbearing. While you are unlikely ever to make a security policy as compelling as a best-selling crime novel, you can at least change the things that actively put people off reading them.
First, only write what needs to be written. I just downloaded the information security policy of a UK university and it’s a 64-page PDF. To be fair, it’s actually a concatenation of a collection of somewhat smaller policies, but do we really need 64 pages? (Note at this point that this example is typical - I’m not singling out any particular organisation, because most of us are as bad as each other).
Next, put the important stuff at the beginning of the document: don’t put pages and pages of boiler-plate background information at the beginning. By all means set the scene of what the policy is for and who it’s aimed at - but do it in a paragraph. The policy I just mentioned is a useful example; it doesn’t say anything instructional until page eight; and the first two pages are the revision history of the document, represented in a 20-row table describing the changes to the document in the 15+ years since December 2005.
I mentioned that our 64-page policy incorporates several smaller ones (over 20, in fact). Why? Each of the subsumed documents has a document control table and a revision history followed by the main content - and the layout of the main content leaves vast tracts of white space. So that’s over 20 document reviews to do every couple of years, 20 sets of version control, 20 documents for the users to re-read each time around the review cycle. This one in particular could be transformed into a single PDF of 20 pages (if that) which is easy to consume in a single hit and requires just one set of periodic reviews. Fewer is more in this case.
When you write the content, consider: (a) who the reader is; (b) whether you need to write each part at all; and (c) how you should word it. Too many times we see policy statements, in documents aimed at all users of the organisation’s systems, saying things like “The company will ensure the secure, correct operation of information processing systems” or “The organisation takes great care to ensure that personal data is gathered, used, stored and disposed of securely and confidentially”. Good to know, but why are we telling users this in a policy document? We should be using our words to tell the users not to write their passwords down and what to do if they see something bad happening, not wasting words telling them that the company is doing what any sensible user would expect it to.
To this last point, don’t just say things like: “Any user witnessing misuse of IT systems must report the occurrence to the IT security team” - it makes a statement but leaves a question hanging (namely: “Fine, but how do I do that?”). It costs only a few words and a few seconds to expand this to: “Any user witnessing misuse of IT systems must report the occurrence to the IT security team via the intranet reporting portal at http://securityincidents.intranet.local/”. In short: don’t just write the policy to be read (though that’s a start) - write it to be used.
Next, jargon. Using jargon is not a sin, but using it poorly or unnecessarily is. Expand acronyms and abbreviations (VPN, MFA, and so on) the first time you use them. If you feel you can’t do without a term but that you need to describe what it means, explain it in a glossary entry in an appendix - and by all means hyperlink to the entry from the instance when you use it in the body text (your word processor app will inevitably have a feature that lets you do this).
Moving along, explain the reason for policy entries whose motivation might not be obvious. “Users must not connect non-company devices to the company network, except for the BYOD Wi-Fi network”, says the policy, but why? Maybe have an explanatory document that the text hyperlinks to, or if you can fit the explanation in a sentence why not put it in a footnote. If people understand why they need to behave in a particular way, they will be more inclined to do so.
Finally, do something that is seldom done for policies yet which is a perfectly normal - nay, obligatory - part of IT system construction and development: testing. How many organisations gather a bunch of friendly users and say: please critique this policy I’m about to send to the Board for approval? Yet what better way is there to get your policies accepted by the masses than to ask a representative group from the masses to help you get them right and make them usable?