Information Security Policies

If your organization is very small, security hygiene measures – which I've written about in detail -- may be all you need for information security.  But as your organization gets larger, the scope of your information security needs necessarily widens and there are more and more controls to put in place (and monitor).

One of the best ways to start down the path to an information security program is to create a suite of information security policies.  Policies, in any domain, essentially state "this is the way we do things here".  If you create an information security policies suite that covers the breadth of controls you need in information security (and privacy) – and if you then implement those policies, as you obviously should – they will drive your entire security (and privacy) program.

It sounds simple but it's best handled with an explicit understanding of your organization's needs in priority order:

1. generate a list of all the policies required by the organization
2. prioritize the list
3. starting from the highest-priority policy and moving down the list, for each policy:
1. write the policy, review it, and iterate it until it's just good enough quality
2. prioritize the list of controls described in the policy
3. implement the high-priority controls in the policy that are not yet already in place (this requires a mini gap analysis)
4. get the entire suite of policies approved
5. set up a system to track compliance with the policies
6. go through all the policies to implement the medium-priority controls in each policy
7. go through all the policies to implement the remaining (lower-priority) controls in each policy
8. revisit the suite of policies annually or when business conditions change

I've tried to show above that the steps are not linear, rather the are circular.  So you can start implementing the important policies before you've written all the policies, and you can start implementing a lower priority policy before you've fully implemented a higher-priority policy.  Your goal is to implement the controls in the order that achieves the best risk reduction for the organization.

There are several frameworks you could start from in creating your suite of policies, but the most commonly used is the specification ISO/IEC 27002:2013, "Information technology — Security techniques — Code of practice for information security controls", or simply ISO 27002.  This is a spec that you'll have to pay for in order to access in full text.

At a basic level you would create one policy artifact for each of the 14 "meat" (non-introductory) chapters -- effectively policy areas -- of the specification:

5. Information security policies

6. Organization of information security

7. Human resource security

8. Asset management

9. Access control

10. Cryptography

11. Physical and environmental security

12. Operations security

13. Communications security

14. System acquisition, development and maintenance

15. Supplier relationships

16. Information security incident management

17. Information security aspects of business continuity management

18. Compliance

Most chapters cover more than one policy area and the areas in scope for each chapter are not always obvious from the chapter titles; so it's very useful to look at the subheadings and sub-subheadings under each chapter, which you can find here. 

I recommend you read though this list carefully in order to understand, at a high level, the wide breath of information security policy areas, and to start your thinking on which areas you need to cover. 

There are a few policy areas that need to be added on top of what ISO 27002 provides, the most important being:

1. Risk Management Policy
2. Acceptable Use Policy (AUP)
3. Disaster Recovery Policy  (this is strongly connected with #17 above)
4. Privacy Policy for external consumption

Each policy area will become one artifact in your suite of policies.  There are different ways to map policy areas to policy documents, such as one-to-one or many-to-one.  It's often best if each artifact is a separate document because this allows you to reissue each one separately, with change control, but some smaller organizations may prefer to have the entire suite in one document for simplicity.

All -- except for two -- of the policy artifacts are written for the purpose of guiding the teams in the organization that are responsible for aspects of security, so their audience is those teams.  These target teams are mainly:

1. information security
2. privacy (if present, for the internal privacy policy) 
3. human resources (for human resources polices, and the AUP)
4. legal (for privacy policies, human resources policies, and the AUP)
5. corporate security (if present, for many aspects of physical security)

The two exceptions are:

1. Acceptable Use Policy (AUP) – the target is employees
2. Privacy Policy for external consumption – the target is customers

Creating policies can be a fair amount of work and is often therefore put off longer than it should be.  The best way to reduce the effort is to start from a template that covers all policies areas in depth and to then customize it to suit the organization.  Templates can be found on the web or from an information security consultant.

Having information security policies is very important for any organization, but you don't need to try to create them all right way.  Proper prioritization, based on a rough gap and risk assessment, is key to knowing which ones are needed ASAP and which can wait.  It's so much better to have in place the handful -- or even a couple - of policies that will make a real different to your organization's security than to postpone indefinitely the creation of any policies because the project seems overwhelming.

This has been only the briefest of overviews of the important area of information security policies.  There is so much more that could be written but this blog post has to stop somewhere.  If you do a web search you'll find no shortage of information.