CHAPTER 23: SECURITY POLICIES

Policies provide organisation-wide directions to do – or not do – certain things. They are a statement of intent, and set out the rules and boundaries your organisation operates within (based on various influences, like legal, contractual and business requirements) that can influence and even direct staff behaviour. A good and properly enforced policy can prove a more effective way of changing staff behaviour than sophisticated technological measures – though remember that your security must cover all three pillars from Chapter 5: people, processes and technology.

It is best practice for your policies to be written and to be supported by documented procedures, which set out in more practical terms how the policies are applied. Documenting policies and procedures ensures consistency, clarifies responsibilities and accountability, makes them easy to communicate and improves staff awareness. In addition, writing them down can help you meet your compliance obligations, as well as prove that you are meeting them.

It is important, however, to view developing policies and procedures as an ongoing process, not a one-off effort. Your organisation’s approach to doing things will almost certainly evolve as you gain experience or new insights, so your documented instructions should be reviewed and updated in line with those changes.

The overarching security policy

You are likely to end up with a set of policies that form part of your security project, with one overarching security policy and subsidiary policies that fall out of that policy, such as a password policy and a patch management policy. These can then be further supported by other documentation, including procedures and records. This type of hierarchical approach offers a good balance of coherence and usability.

The overarching policy is necessarily a high-level and relatively abstract document, but should still be specific about some information key to your implementation project, such as:

• The scope of your project;

• Your organisation’s context;

• Stakeholder needs, including relevant legal and contractual requirements; and

• The strategic aims and objectives of your security programme.

The policy should be published internally and communicated to all staff and contractors under management’s authority (in fact, the CEO should be signing the policy off). The policy should also be made available to any third parties upon request.

Creating effective policies and procedures

For all their benefits, policies and procedures can have serious limitations if they have not been designed well. They can be too complex or vague, making them difficult to understand, which commonly leads to them being ignored. Staff might also not follow them if a policy or procedure has not been communicated properly, meaning that they forget about it or do not even realise it exists.

With that in mind, how do you develop effective policies and procedures? First, keep them realistic. Even though policies are aspirational – they state where you want to be, and not necessarily where you are – and procedures are instructive – so, again, do not necessarily completely reflect what staff are currently doing – both must remain practicable. If they look too idealised, staff will feel they are not realistic or reasonable, and will almost certainly end up ignoring them.

Specifically for procedures, it is also important to keep them clear and straightforward. Staff will not find hard-to-follow instructions helpful, and likely end up ignoring them again. It is also important to incorporate the input from the people who will actually be following your procedures. Managers can certainly provide insight into how they want things to be done and set targets, but if they do not also oversee day-to-day tasks, they may not be fully aware of typical approaches or challenges. By talking to operational staff and noting their comments, you can keep your procedures realistic and easy to enforce.

Your documents must also avoid duplication. Different areas of security naturally overlap, so you will end up with different documents that need to touch on the same points. However, that does not mean they need to cover the same point the same way. Where different documents interact with each other, have only one of them cover that point in detail, and include just a reference to that document in the others. This approach also mitigates the risk of, when making changes to a document as you review it (another important way of keeping it effective), forgetting to make the same changes in other documents that also cover that point.