MODULE 4- THE DO PHASE

 This module will give you a short overview of the ISO 27001 clause that covers the Do
phase of the PDCA cycle: 8 Operation.

 The Do phase includes implementing ISMS requirements, various ISMS processes,

plans for achieving information security objectives, and information security controls
according to the risk treatment plan. It also covers managing changes and outsourced
processes. This phase is important because it describes the longest phase of the PDCA
cycle, i.e., the implementation of actual safeguards, and day-to-day operations of the
Information Security Management System.

Seven steps for implementing policies and

procedures.

Have you ever found yourself in a situation where you have been given the task to write a security policy or a
procedure? But you don’t want your document to end up like so many others – gathering dust in some
forgotten drawer? Here are some thoughts that might help you…

The steps I’m about to present to you are designed based on my experience with various kinds of clients, large
and small, government or private, for-profit or non-profit – I find these steps applicable to all of them.
Actually, these steps for implementing policies and procedures are applicable to any kind of policies and
procedures, not only those related to ISO 27001 or ISO 22301.

1. Study the requirements

First you have to study very carefully various requirements – is there a legislation which requires something to
be put in writing? Or maybe a contract with your client? Or some other high level policy that already exists in
your organization (perhaps a corporate standard)? And of course the requirements from ISO 27001 or BS
25999-2 if you want to comply to those standards.

2. Take into account the results of your risk assessment

Your risk assessment will determine which issues you have to address in your document, but also to which
degree – for instance, you may need to decide whether you will classify your information according to its
confidentiality, and if so, whether you need two, three or four levels of confidentiality.

This step may not be relevant in this form if your policy or procedure is not related to information security or
business continuity. However, risk management principles are applicable to other areas as well – quality
management (ISO 9001), environmental management (ISO 14001), etc. For instance, in ISO 9001 you have to
determine to which extent a process is crucial for your quality management and accordingly to decide whether
you will document it or not.
3. Optimize and align your document(s)

An important thing to consider is the total number of documents – are you going to write ten 1-page
documents or one 10-page document? It is much easier to manage one document, especially if the target group
of readers is the same. (Just don’t create a single 100-page document.)

Moreover, you have to be careful to align your document with other documents – the issues you are defining
may be already partially defined in another document. In such case, it may not be necessary to write a new
document, maybe only expand the existing one.

If you are writing a new document about an issue that is already mentioned in another document, be sure to
avoid redundancy – to describe the same issue in both documents. Later it would become a nightmare to
maintain those documents; it’s much better that one document makes a reference to another, without
repeating the same stuff.

4. Structure your document

You also need to take care that you observe your corporate rules for formatting the document – you already
may have a template with pre-defined fonts, headers, footers etc.

If you already implemented ISO 27001 or BS 25999-2 (or any other management standard), you’ll need to
observe a procedure for document control – such a procedure defines not only the format of the document, but
also the rules for its approval, distribution etc.

5. Write your document

The rule of the thumb is – the smaller the organization and the smaller the risks, the less complex your
document will be. There is nothing more useless than deciding to write a lengthy document no one is going to
read – you have to understand that reading the document takes time, and the level of one’s attention is
inversely proportional to the number of lines in your document.

One good technique to overcome the resistance of other employees to this document (no one likes change,
especially if that means something like an obligation to change passwords on a regular basis) is to involve
them in writing or commenting this document – this way they will understand why it is necessary.

6. Get your document approved

This step is rather self-evident, but its underlying importance is this – if you are not a high ranking manager in
your company, you won’t have the power to enforce this document.

This is why someone with such a position has to understand it, approve it, and actively require its
implementation. Sounds easy, but believe me – it is not. This step (and the next one) are the ones where
implementation most often fails.

7. Training and awareness of your employees

This step is probably the most important, but sadly it is one that is very often forgotten. As mentioned before,
employees are tired of constant changes, and they surely won’t welcome another one especially if it means
more work for them.

Therefore, it is very important to explain to your employees why such a policy or procedure is necessary –
why it is good not only for the company, but also for themselves.
Sometimes training will be necessary – it would be wrong to assume that everyone possesses the skills to
implement new activities. For you, who wrote this document, it may seem easy and self-evident, but for them
it may seem like brain surgery.

End of story?

If you thought you’ve reached the end of your document-implementation story, you’re wrong – the journey
has just begun. It is not enough to have a perfect policy or procedure that everyone just loves, you also need to
maintain it.

Someone has to take care this document is up-to-date and improved, or else no one is going to observe it
anymore – and that someone is usually the same person who has written it. Not only that, someone has to
measure if such a document has fulfilled its purpose – again, it may be you.

As you may have noticed reading this article, it is not enough to have a nice template for a successful policy
or procedure – what is needed is a systematic approach to its implementation. And in doing so do not forget
the most important fact: the document is not an end in itself – it is only a tool to enable your activities and
processes to run smoothly. Don’t let the opposite happen – that such a document makes these activities and
processes run with more difficulty.

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. For that
purpose, see this article: List of mandatory documents required by ISO 27001 (2013 revision). If the
document is mandatory, you have nothing to think about – you must write it if you want to be compliant with
this standard. (See also: Seven steps for implementing policies and procedures.)

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 (see also: The
basic logic of ISO 27001: How does information security work?). 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.

How detailed should the ISO 27001 documents be?

When starting to write a policy or a procedure, you’re probably puzzled as to how lengthy it should be. And
the truth is, ISO 27001 (as well as other ISO standards like ISO 20000, ISO 9001, ISO 14001 and others) are
very flexible in this respect. They basically allow you the freedom to decide for yourself what level of detail
you are going to write in your documents.

Criteria for deciding on the level of detail

So, before you start writing your documentation, you should go through these criteria to decide how detailed
your policies and procedures should be:

Level of complexity. The more complex the process or activity is, the more details you will have to write. Of
course, if your process has 5 very simple steps you will write your whole procedure in a single page, but if the
process has 100 steps – some of which are really difficult – you may come up with a document that is a few
dozen pages long.
Maturity. If a process or activity is complex, but practice has proved there are few problems with it because
employees have been performing it the same way for years and know exactly how it is done, you don’t have to
write a very lengthy document.

How often they are performed. If the process or activity is performed rarely, then you will probably have to
explain it in more detail – this is because your employees will tend to forget how the process or activity is
done; if it is performed very regularly, the document will be much shorter.

Importance/risks. The more important the activity or process is, the more detailed the documents tend to be,
because you’ll want to make sure everyone understands exactly how to perform it. For example, if you have
many risks that are related to information systems access control, you should describe those rules in more
detail; on the other hand, if your physical security is not really an issue, you will describe it only generally (or
avoid writing a document at all).

Compliance. In some cases, you will have auditors coming to your company from regulatory bodies and/or
from your important clients – if they expect to see a very detailed, e.g., BYOD policy, then make your life
easier and give them that nice-looking, detailed policy.

The decision on how many documents you want to have and how detailed they should be is a strategic one –
you should make such a decision even before starting your ISO 27001 project. See also: 8 criteria to decide
which ISO 27001 policies and procedures to write.

Once you start writing the documents, use this article: Seven steps for implementing policies and procedures.

Problems with complex documentation

Many information security professionals fall into the trap of thinking “we’ll describe all the security rules in
detail → everyone will know exactly what to do → we will have higher level of security,” but it doesn’t work
this way. Complex documents require a lot of effort to maintain, and even worse: employees dislike reading
lengthy policies and procedures.

So remember, the fewer documents you have and the less complex they are, the greater the chances your
employees will comply with them. Therefore, don’t get too ambitious when writing your documents; but do
get ambitious in asking the security rules to be implemented.

How to structure the documents for ISO 27001

Annex A controls
Once you’ve finished your risk assessment and treatment, it is time for you to start writing documents that
describe your security controls according to ISO 27001 Annex A. But, which documents should you write?
How do you structure them? Which one do you begin with?

Here’s what I found to be the best way to do it.

How to choose which documents to write

ISO 27001 says that you cannot simply start to select the controls and/or write the documents that you like the
most – the point is that selection of controls must be a direct consequence of the risk assessment and risk
treatment process. See also: ISO 27001 risk assessment & treatment – 6 basic steps.

Secondly, you must know which documents are mandatory and which are not – see this list here: List of
mandatory documents required by ISO 27001 (2013 revision).
Finally, once you know which controls must be applied and which documents are mandatory, you must decide
how extensive your documentation will be:

 Smaller companies will tend to have a smaller number of documents: (1) they won’t document each
control, and (2) they will include several controls in a single document.
 Larger companies will tend to have more documents, and the documents will be more detailed.

However, these are not the only criteria to decide which documents to write – see also 8 criteria to decide
which ISO 27001 policies and procedures to write.

Which documents should cover which controls?

Since Annex A has 114 controls, the truth is that it is not very easy to decide how to group policies and
procedures to cover them (see also: Overview of ISO 27001:2013 Annex A). And the fact that ISO 27001
does not prescribe which controls must be allocated to which policies and/or procedures might initially seem
like a problem, but once you realize that such an approach gives you big freedom to adapt the documentation
to your real company needs, you will actually become grateful that ISO 27001 is so flexible.

Again, there are two approaches to group the documents:

Smaller companies will normally have policies and/or procedures that cover several controls with one
document only – for instance, you might use:

 Access Control Policy to cover all the 14 controls from section A.9 (without writing detailed procedures),
 BYOD (Bring Your Own Device) Policy to cover not only A.6.2.1 (Mobile device policy) and A.6.2.2
(Teleworking), but also A.13.2.1 (Information transfer policies and procedures),
 with Acceptable Use Policy, you might get even more ambitious and cover controls from various sections of
Annex A, since this document could serve as a security baseline for all employees: A.6.2.1, A.6.2.2, A.8.1.2,
A.8.1.3, A.8.1.4, A.9.3.1, A.11.2.5, A.11.2.6, A.11.2.8, A.11.2.9, A.12.2.1, A.12.3.1, A.12.5.1, A.12.6.2, A.13.2.3,
and A.18.1.2.

Bigger companies usually structure the documentation in a different way:

 each section from Annex A will be covered with a policy – e.g., Organization of Information Security Policy
(A.6), Human Resources Security Policy (A.7), Asset Management Policy (A.8), etc.
 each policy will have detailed procedures and/or working instructions that cover single controls – for example,
Information classification procedure (for control A.8.2.1), Information labeling procedure (control A.8.2.2),
Information handling procedure (control A.8.2.3), etc.

The sequence of writing the documents

Once you have an idea of how to structure the documents, how do you decide where to start, and where to
end?

For smaller companies, you can use a couple of criteria to decide which documents to start with:

 Areas where you can get quick wins – this means you can select an area where you know you will finish your
document quickly, and this way you show your management, your peers (and yourself) that you are capable of
doing this job effectively.
 Areas where you have largest risks – this way you start resolving the biggest problems first –you may not finish
this quickly, but sometimes this approach is necessary if your risk assessment has shown you have some very
big gaps to fill in.
  Areas that are compatible with other running projects in your company – for example, if your company is
currently implementing help desk software, you might want to start writing incident management procedure,
because this will regulate how that software will be used in the context of ISO 27001.

For documents that are to be written at the end, my personal preference is documents that cover larger number
of controls (for example, the Acceptable Use Policy). This way you will know which controls you covered
with other documents, and those that haven’t been described in other policies and procedures can be described
in an all-inclusive document at the very end.

Again, bigger companies will have a different approach – they will write the policies first, and related
procedures/working instructions second, while for the decision on which policies to start first they can use the
same criteria as described above.

So, to conclude, make sure you use this flexibility that ISO 27001 offers you to adapt the documentation to
your specific needs – because the idea is that the documentation serves you, not the other way around.

For the cells that are empty in this Risk Treatment Plan, match the correct answers below.

Match the empty cells with the following answers:

1. Cell 1 - Risk no. 25 – Unavailability of electronic information because of accidental loss of the
information

2. Cell 2 - System administrator

3. Cell 3 - June 2016

4. Cell 4 - Risk no. 32 – Laptops could be stolen by external people

5. Cell 5 - Risk no. 68 – Paper-based personnel files including personal data can be accessed by
unauthorized employees

Choose which of the following statements can be documented as results for the follow up from the
implementation of a control: card-controlled access to the server room:

1. The internal audit is conducted – Incorrect! This information is not relevant for this control.

2. The card reader for access to the server room is implemented – Correct!

3. Relevant people are trained in the use of the card readers for access to the server room – Correct!

4. Analysis of the log and the video surveillance show that the card-controlled access to the server room
is very effective – Correct!

5. Cheaper equipment for card-controlled access than the one implemented is available on the market –
Incorrect! This information is not relevant and doesn’t represent a result of the risk treatment.

ISO 27001 requires that every aspect of the ISMS should be documented.

1. True – Incorrect! ISO 27001 doesn’t specify that a document is needed for every single detail, but points
out that the organization should keep documented information in the amount necessary for that organization to
make sure that the activities and controls are carried out as planned.

2. False – Correct!

The ISMS documentation should change (modify, update, delete, add new documents, etc.) in the following
cases:

1. Once a year it is mandatory to make changes in the ISMS documentation – Incorrect! The
documentation should be reviewed periodically to determine if a change is required; there is no schedule for
making the changes.

2. When circumstances in your company change – Correct!

3. When the existing documentation is no longer applicable in your organization – Correct!

4. When the requirements of ISO 27001 change – Correct!

5. When a client asks for the ISMS documentation to change – Incorrect! Clients cannot request a change
in a company’s ISMS documentation; however, certain requests from clients can initiate changes in the ISMS
documentation.

6. If you come to the conclusion that some of the documents don’t fulfill their purpose – Correct!

Companies that have implemented ISO 27001 are not allowed to outsource critical operations, because that
can have a negative impact on the information security.

1. True – Incorrect! Outsourcing activities, especially of critical operations, can have a negative impact on
the ISMS; however, the standard doesn’t forbid outsourcing of such activities. It simply requires that all
outsourced operations are identified and appropriately controlled in regard to information security.

2. False – Correct!
Changes in an organization can be planned and unplanned. Both types of changes should be controlled and
their consequences reviewed.

1. True – Correct!

2. False – Incorrect! ISO 27001 requires that the companies should control planned changes and review
consequences of unintended change, while at the same time taking actions to mitigate unwanted effects.

According to you, which of the listed changes that can happen in a company may require conducting a re-
assessment of risks?

1. Hiring a new employee – Incorrect! This is a very small and common change, and doesn’t impact the
information security significantly, so there isn’t a need for conducting a re-assessment of risks.

2. Outsourcing the IT maintenance process to an IT company – Correct!

3. Switching to a new operating system for all 1000 employees – Correct!

4. Moving the operations to new offices – Correct!

5. Buying new furniture – Incorrect! This is a very small and common change, and doesn’t impact the
information security significantly, so there isn’t a need for conducting a re-assessment of risks.

6. Buying a new laptop for the office manager – Incorrect! This is a very small and common change, and
doesn’t impact the information security significantly, so there isn’t a need for conducting a re-assessment of
risks.

When implementing the information security risk treatment plan, one must:

1. Take into consideration available resources – Correct!

2. Document the information security risk treatment plan – Incorrect! After documenting the risk
treatment plan, it should be executed by implementing the selected controls.

3. Re-assess the risks – Incorrect! This activity is prescribed by ISO 27001; however, it is not part of the risk
treatment plan implementation.

4. Take into consideration the deadlines for implementing the selected controls – Correct!

5. Implement the selected control in practice – Correct!

ISO 27001 requires that companies document the results of the risk treatment.

1. True – Correct!

2. False – Incorrect! The standard requires companies to keep documented information of the results of the
information security risk treatment plan. These results are usually analyzed during every management review.

The Do phase moves companies from a stage where they plan information security to a stage where they
implement information security and protect the information.

1. True – Correct!
2. False – Incorrect! In the Do phase, companies implement numerous information security controls,
processes, and documents, and they put the ISMS into practice on a daily basis.

ISO 27001 requires for the change management procedure to be documented.

1. True – Incorrect! ISO 27001 doesn’t specify requirements for writing such procedure.

2. False – Correct!

Operating an Information Security Management System (ISMS) means:

1. Performing all the activities described in the ISMS policies and procedures – Correct!

2. Producing ISMS records – Correct!

3. Certifying the ISMS – Incorrect! The ISMS should be operated on a daily basis, no matter whether the
system is certified or not.

4. Updating the ISMS documentation when needed – Correct!