How to create a sample information security policy template

It took us several months of hard work to complete our own information security policy template – and this post will guide you through the process if you are after building your own, rather than getting ours.

The first step in the way is identifying what standards and guidelines should such a policy follow – as there are multiple infosec policies available for copying directly – virtually all of them are entirely different and it is really difficult choosing which one should you use – specifically, because not a single one would match everything your organization may need.

Then, if you have copied a random security policy off the Internet, you will have a whole range of challenges:

  • how do you keep your policy current?
  • how do you enforce a policy which does not directly apply to your organization?
  • how do you add or remove irrelevant items as not to overburden your personnel with useless information?
  • How do you identify which is relevant and which is not relevant to your organization?
  • and many others…

So went and looked at the available information security policies out there, hoping we would find one at least worth taking as an example – and there were a few good ones, but not a single one was capable of encompassing absolutely everything a company might need to take care of in a policy. And if a policy misses important areas, is it really worth using it?

Our next step was to check if any of the organizations tasked with information security had developed any standards in the area – and luckily there were lots to choose from.

NIST, to start with – has developed a set of information assurance controls and a set of predefined, best values for them – so you could benchmark your environment against their best practices – in the 800-53 v3 and v4 documents. Then, in the 800-100 document, they have identified to some degree would should an information security policy contain – but then, to our opinion, the chapter in that document related to policies was too short and not enough.

The DOI however has published a wonderful Information Security Handbook – available at – if you read that 460 page document (at least twice) – you will see why a good policy should really contain *everything* – or at least, enough to cover most areas of any business, which makes it easy to add to it the bits you personally need.

You should start by taking this last document, remove any information that is not a policy statement (do not touch any of the controls) – because, really, this document is full of “filler” text, especially at the start of it. Many of the standards should be separate documents and distributed to the relevant teams who should follow them – along with the policy – and they should definitely not be  a part of it.

Then you should change all the government-centric titles and names in the document to ones which would match a private company. Done? Good! Now, take a few of the freely available information security policies out there and compare them to the document you got. You probably need to adjust a few things, but definitely do not remove any of the controls – unless it is never going to be relevant to your organization.

By now, you should probably have ended up with a document which is roughly 200 pages long (compared to the 460 initially) – separating the standards from the policy, removing all unnecessary information, changing all titles to reflect a company-centric naming convention. That would have required somewhere between 20 to 40 hours of work – depending on the complexity of your organization – you can safely take that document and use it as your information security policy – but you could take it firther.

Read the resulting document once again – and try removing all remaining filler information, the removal of which would not impact your ability to educate and enforce – some sentences can be shortened, many government-centric processes and procedures – removed altogether.