Template and example of ISO27001 Risk and Opportunities to the ISMS (Clause 6.1.1)

This article gives some advice and a suggested template and some possible examples to do the “Risks and Opportunities “ requirement of clause 6.1.1 of ISO27001.

It is actually a bit of an odd topic for an article given that so few people know about this requirement and even fewer ISO27001 certification auditors ever ask about it. But it is a requirement of ISO27001. I can hear you saying “what is he talking about - of course I know about the risk assessment” but this is not the information security risk assessment that everyone talks about. This is something different. If you are not familiar with the requirements for this clause then you should read this article that explains the requirement.

https://www.dhirubhai.net/pulse/why-you-need-2-risk-assessments-iso27001-chris-hall/

The principle is that this will help improve the likelihood of success for your Information Security Management System (ISMS). Not surprisingly, that is why clause 6.1.1 of ISO27001 asks you to do it. Even though most people don’t do it.

You do this by asking the three questions:

? What could go wrong with my initial implementation of the ISMS?

? What could go wrong with or because of the ongoing operation of the ISMS?

? What is the good thing (i.e opportunity) that might (of might not) happen in relation to or because of the ISMS?

This needs to be done by taking into account the context of the ISMS. This is the items in clause 4 of the standard – e.g. the internal and external issues, the interested parties, and the scope. Plus anything else that is relevant.

ISO27001 does not require you to document this but I suggest that you do so to help with the analysis and so you can provide evidence to the auditors in the unlikely event that they ask about it.

Organisations sometimes have formal processes for managing project risks and managing?operational risks. If that is the case then as long as they meet the requirements of clause 6.1.1 of ISO27001 you could follow those for managing the implementation and ongoing risks related to the ISMS.

Organisations don’t usually have formal processes for managing opportunities but if they do then as long as they meet the requirements of clause 6.1.1 of ISO27001 they could follow those processes for the opportunities.

I strongly recommend keeping the risk and opportunities risk assessment/register separate to the information security risk assessment. I also think that it is best to split the risk and opportunities into two separate registers – one for opportunities and one for risks.

I would typically expect to see only a few such opportunities and just a few risks identified in each of these registers.

You will need to keep your risk and opportunities analysis updated and you will need to track whatever actions you have.

Opportunities

Examples of some possible “Opportunities”.

Some possible opportunities are:

? We get significant and unexpectedly high volumes of additional sales because we have ISO27001.

? Clients recognise that ISO27001 gives them confidence in our management of information risks and as such reduce their emphasis on-site audits.

? We find it much easier to respond to due diligence questionnaires than we expected.

? The success and benefits of the ISMS means that other parts of the organisation also decide to implement an ISO27001 compliant ISMS.

? In the event of a data breach the implications and potential fines are reduced because the Information Commissioners Office (ICO) recognises that we have taken information security seriously by implementing ISO27001.

? It helps us ensure that we follow more consistent processes across the organisation and not just from an information security perspective.

? It helps us convince clients that we don’t need to do a SOC 2.

? It makes it a lot easier for us to meet other information security frameworks – for example SOC 2 and Cyber Essentials.

? It enables us to expand into countries/marketplaces that we currently can’t do so because of regulatory requirements that restrict us.

Some of these are probably objectives of why you are doing ISO27001. If they are then you shouldn’t really define them as opportunities but I don’t think that matters too much. The idea is to think formally about what good things might or might not happen with respect to the ISMS.

Template for “Opportunities” for the ISMS.

The following are some suggested attributes for opportunities:

Opportunity. What is the good thing that might (of might not) happen in relation to or because of the ISMS?

Opportunity Owner. Who is the owner of this opportunity?

Decision. Are we going to pursue this opportunity or not? Yes/No.

Actions to pursue the opportunity. What, if anything are we going to do to try to make the opportunity happen? These actions should have owners and target dates.

Status. What is the status of this opportunity? Open/Closed/In Progress, etc.

There are lots of other attributes that could be included if you think they will help you, for example likelihood and impact. You also need to think about how you will implement these actions into the ISMS and how to evaluate the success of these actions.

Risks

Examples of some possible implementation “Risks”.

Some possible implementation risks are:

? We employ external resource to help us implement ISO27001 but the people employed do not have sufficient experience or skills to properly help us.

? We implement an ISMS that is much more complicated and costly to run than is needed to enable the ISMS to meet its objectives.

? There is insufficient management commitment or buy in across the organisation.

? There is insufficient budget.

? We accidentally obtain a certificate that was not properly accredited.

? The certification body are unable to undertake the certification audit in our required timescales.

? We are not clear or specific enough about why we are implementing an ISMS and because of this the design and implementation does not properly meet our objectives.

? We fail to achieve ISO27001 certification in the required timescale.

? Our implementation of ISO27001 meets our requirements but does not satisfy our key stakeholders – for example the scope does not match what they want or they expected us to implement some controls that we did not implement.

There are lots of others!

Examples of some possible ongoing “Risks”.

Some possible ongoing risks are things like:

? Staff do not understand the part they play in managing the organisation’s information security risks and as such do not take it seriously.

? There is insufficient resource or management commitment put into the ISMS on an ongoing basis.

? The ISMS manager leaves.

? The processes supporting the operation of the ISMS (notably the controls) are not properly embedded/socialised into the day to day operations of the business.

? The processes supporting the operation of the ISMS are not clear.

? The people involved with managing the ISMS do not follow the defined processes for the ISMS.

? There is insufficient engagement with the risk assessment process to ensure that good decisions are made with respect to the risks.

? Designated managers do not attend our regular information security committee meetings.

? There are too many staff (notably managers) who do not buy into what we are doing and why.

? It is all just too much for us and gets in the way of us running our business.

? Staff do not have the necessary skills needed to properly operate the processes needed to ensure the ISMS meets its objectives.

? Staff do not follow the defined documented processes for the controls.

? We get a major non conformity at a surveillance audit.

Try to avoid risks that are just restating the objectives associated with the ISMS. Some of the above examples may do this depending on what objectives you have.

Template for “Risks” for the ISMS.

The following are some suggested attributes for these risks:

Risk. What is it that could go wrong (but might not):

? with the implementation of the ISMS? and/or

? with or because of the ongoing operation of the ISMS?

Risk Owner. Who is the owner of this risk?

(Likelihood. How likely is it on a scale of Low/Medium/High that this risk will happen? This is optional but can help in making decisions about the actions needed.)

(Impact. On a scale of Low/Medium/High, what would the impact on the business be if this risk did happen? This is also optional but can help in making decisions about the actions needed.)

Decision. What are we going to do about this risk? Treat it/Avoid it/Accept it.

Actions to help manage the risk. If we are going to treat this risk (i.e. manage it) what is it we are going to do to do. Some of these things will be ongoing and some will be one off improvement actions. If they are one off improvement actions then these actions should have owners and target dates.

Status. What is the status of this risk? Open/Closed/In Progress, etc.

There are lots of other typical risk attributes that could be included if you think they will help you. You also need to think about how you will implement these actions into the ISMS and how to evaluate the success of these actions.

Summary

You should do clause 6.1.1 but bear in mind that very few organisations do so and it is rare for an ISO27001 certification auditor to ask about it.

Chris

www.btrp.co.uk