8 criteria to decide which ISO 27001 policies and procedures to write

If you’re just starting to implement ISO 27001 in your company, you’re probably in a dilemma as to how many documents you need to have, and whether to write certain policies and procedures or not.

Criteria for deciding what to document

Well, the first step is easy – you need to check whether a document is required by ISO 27001. If the document is mandatory, you have nothing to think about – you must write it if you want to be compliant with this standard.

However, if the document is not mandatory, you may find yourself puzzled over whether you need to write it or not – for example, would you need a Backup Policy? Or perhaps a Classification Policy? Or a BYOD Policy?

Here are a couple of criteria that will help you:

Risks. You have to start by assessing the risks to see if there is a need for such a control at all. If there is no risk, then certainly you won’t need a document for it; if there is a risk, this still doesn’t mean you have to write a document, but at least you have resolved the dilemma of whether the control is needed or not.

Compliance. Sometimes you may have a regulation or a contractual requirement to write a certain document – e.g., a regulation may require you to write the Classification Policy, or your client may require you to sign NDAs with your employees.

Size of your company. Smaller companies will tend to have fewer documents, so in such a case you should try to avoid writing a procedure for every small process – for example, if you have 20 employees you don’t need 50 documents for your ISMS. Of course, if you are a multinational organization with 10,000 employees, writing policies where each would have a couple of related procedures, and then for every procedure a couple of working instructions – this approach does make sense.

Importance. The more important a process or activity is, the more likely you will want to write a policy or a procedure to describe it – this is because you’ll want to make sure everyone understands how to perform such a process or activity in order to avoid breakdowns in your operations.

Number of people involved. The more people perform a process or an activity, the more likely you will want to document it; for example, if you have 100 people involved, it will be very difficult to explain verbally to all these people how to perform certain process – it is much easier to write a procedure that would explain everything in detail. On the other hand, if you have five people involved, you can probably explain how the whole process works in a single meeting, so there is no need for a written procedure. There is one exception, though: if you have only one person working on a process, you might want to document it because no one else knows how to do it – so if this person becomes unavailable, you’ll be able to continue your operations.

Complexity. The more complex the process, the more likely it is that you’ll need a written document for it (at least in the form of a checklist) – it is simply impossible to remember by heart, e.g., 100 steps that need to be performed in the exact sequence.

Maturity. If a process or an activity is clearly established, if it has been running for years and everyone knows exactly how to perform it, if it is finely tuned, then there is probably no need to document it.

Frequency. If you perform some activities rather rarely, you might want to write them down because you might forget how they are done.

Find the right balance

The more documents you have and the more detailed they are, the more difficult it will be to maintain them and to make your employees observe them. On the other hand, a smaller number of documents that are also quite short might not describe exactly what you need to do.

In most cases, I recommend my clients not to become too ambitious – if there is no absolute need to create some new document, don’t do it; if there is no need to describe some process in great detail, make it shorter.

And remember – unnecessary documents will bring you nothing but trouble.

See here an example of Procedure for document control.