ISO 27001 clause 6.1.1: Risks and opportunities for the ISMS

What clause 6.1.1 requires in practice

Clause 6.1.1 is about planning the management system itself. When planning, the organisation takes the issues from clause 4.1 and the requirements from clause 4.2 and decides which risks and opportunities must be addressed. The standard states three purposes: making sure the ISMS can achieve its intended outcomes, preventing or reducing undesired effects, and achieving continual improvement.

It then asks for two planning steps. The organisation plans actions to deal with those risks and opportunities. It also plans how to integrate and implement the actions within ISMS processes and how to evaluate whether they worked.

This differs from the information security risk assessment in 6.1.2, which concerns risks to information. Here the question is what might stop the system working, or what could make it work better. No particular record is named. The expected output is a reasoned set of actions, with owners and some way of judging their effect.

Recognise the system-level question

Ask what could prevent the management system from working and where a realistic improvement could make it more effective. Examples include unclear decision authority, limited specialist capacity, incompatible processes after an acquisition or recurring delays in obtaining evidence from providers. These matters can affect many security decisions at once.

An opportunity might be integrating security review into an existing procurement process, improving how teams share incident learning or using consistent evidence arrangements across sites. The standard does not require speculative growth opportunities or a separate positive-risk scoring formula. The question is whether an opportunity is relevant to the ISMS and worth addressing.

Plan integration and effectiveness together

Do not stop at “conduct training” or “improve communication”. Explain the change, where it will operate and what result would show it worked. If delayed risk approval is the issue, an action might define decision authority and escalation in the change process. A useful effectiveness check then examines decision timeliness and unresolved exceptions.

Choose an accountable owner and a realistic implementation route. Resources, competence and competing priorities may need management decisions. Embed the action into a process that will continue after the project ends. A one-time campaign can be helpful, but a recurring failure often needs an enduring change in how work is organised.

A simple action record is an optional tool. Clause 6.1.1 does not prescribe a register format or a universal scoring model. Whatever method you choose, retain enough clarity through the wider ISMS arrangements to show what was decided, how it was integrated and how effectiveness was considered.

Why planning for the system itself matters

Many security programmes suffer not from technical weakness but from organisational friction: unclear decision rights, thin specialist capacity, slow evidence from providers or processes that clash after an acquisition. These issues damage every control at once, yet they seldom appear in a technical risk register. Clause 6.1.1 gives them a place. Addressing them early prevents repeated delays, helps leaders see improvement opportunities, such as folding security review into procurement, and gives auditors confidence that the system is managed deliberately. It also encourages checking whether actions worked, which stops the same problems from returning under new names.

How to implement clause 6.1.1

Keep this planning practical and short. One approach Sterling teams use is a periodic discussion at leadership level, informed by the context and requirements already recorded. Expect most of the value to come from accurate discussion, not from the format used to note it.

1. Review the context and interested-party conclusions and ask what could stop the ISMS achieving its outcomes.
2. Add opportunities, such as simplifying evidence collection or improving incident learning.
3. Choose the items that deserve action, with a brief reason for leaving others.
4. Assign an owner to each action and decide which existing process will carry it out.
5. Agree how effectiveness will be judged, for instance by a change in how long decisions take or in recurring findings.
6. Review the results at management review and refresh the list when the business changes.
7. Keep the discussion linked to evidence, such as recurring audit findings, incident reviews or feedback from owners, so that the risks and opportunities identified reflect what is happening and not what is merely assumed.

Illustrative examples

Keep this distinct from other requirements

Information security risk assessment has its own requirements concerning confidentiality, integrity, availability, criteria and owners. A governance opportunity does not replace that assessment. Likewise, an improvement idea is not automatically a corrective action: clause 10.2 addresses actual nonconformity and its causes.

The activities can share information. Repeated assessment delays may expose a system-level resource problem; an incident may reveal an opportunity to improve coordination even where no requirement failure has been established. Connect the records without relabelling all issues as the same type of risk.

Evidence and common weaknesses