Risks and Opportunities Under Clause 6.1.1: Where ISMS Planning Begins

Why Clause 6.1.1 Is the Starting Point for Everything That Follows

If you have ever wondered why some information security management systems feel genuinely purposeful while others feel like a collection of documents nobody reads, the answer usually sits in Clause 6.1.1. This is the clause in ISO 27001 where planning begins. Not planning in the calendar sense, but planning in the sense of thinking clearly about what could go wrong, what could go right, and what the organisation needs to do about both.

Clause 6.1.1 sits inside Section 6, which covers Planning. Its full title is General, and that simplicity can mislead people into treating it as a formality. It is not. This clause is where the organisation takes everything it learned about its context in Clause 4 and its leadership commitments in Clause 5, and turns that understanding into a structured approach for managing information security risks and opportunities. Get this wrong, and the rest of the ISMS is built on shaky ground.

This article walks through what Clause 6.1.1 actually requires, how it connects to the rest of the standard, and what auditors look for when they assess whether an organisation has genuinely engaged with this requirement or simply ticked a box.

What the Clause Actually Says

The language of Clause 6.1.1 is deliberately broad. The organisation must determine the risks and opportunities that need to be addressed in order to:

• Give assurance that the ISMS can achieve its intended outcomes
• Prevent, or reduce, undesired effects
• Achieve continual improvement

The clause then requires the organisation to plan actions to address those risks and opportunities, integrate those actions into ISMS processes, and evaluate the effectiveness of those actions.

That is the skeleton. But understanding what it means in practice requires unpacking each element carefully.

The Connection to Context and Interested Parties

Clause 6.1.1 does not exist in isolation. It explicitly requires the organisation to consider the issues identified under Clause 4.1 (the context of the organisation) and the requirements identified under Clause 4.2 (interested parties). This is not optional cross-referencing. The standard is telling you that your risk and opportunity identification must be grounded in what you actually know about your organisation and the people who have a stake in your information security.

In practice, this means that a manufacturing company with a large number of external contractors handling sensitive design data should see that reality reflected in the risks and opportunities it identifies. A healthcare organisation operating under the Privacy Act 1988 and the Notifiable Data Breaches scheme should see those obligations shaping its thinking. If the context analysis says one thing and the risk identification says something entirely different, that is a flag for any competent auditor.

The connection runs in both directions. If the context work is shallow, the risk identification will be shallow too. This is why understanding your organisational context under Clause 4.1 is not a bureaucratic exercise. It is the foundation on which Clause 6.1.1 rests.

Risks and Opportunities: Two Sides of the Same Coin

Many organisations focus almost entirely on risks and treat opportunities as an afterthought. That is understandable, given that information security is fundamentally about protecting the organisation from harm. But the standard includes opportunities for a reason, and auditors will ask about them.

What Counts as a Risk in This Context

In the ISMS context, risks are conditions or events that could compromise the confidentiality, integrity, or availability of information. They might come from:

• External threats such as cyberattacks, phishing, or supply chain compromise
• Internal vulnerabilities such as weak access controls, poor patch management, or inadequate staff awareness
• Organisational changes such as a merger, a shift to cloud infrastructure, or rapid headcount growth
• Regulatory changes that alter what the organisation must do to remain compliant
• Third party dependencies where a supplier or partner controls sensitive data

The key point is that risks at Clause 6.1.1 are broader than the technical risk assessment that follows in Clause 6.1.2. This clause is asking about strategic and systemic risks to the ISMS itself, not just individual information assets. Can the ISMS achieve its intended outcomes? What could prevent that?

What Counts as an Opportunity

Opportunities are conditions that, if acted upon, could improve information security outcomes. They might include:

• Adopting a new technology that strengthens authentication or monitoring
• Consolidating systems to reduce the attack surface
• Improving supplier contracts to include stronger security requirements
• Building staff awareness programmes that shift security culture over time
• Aligning with a recognised framework such as the Essential Eight to lift baseline controls

Opportunities do not need to be grand. A small improvement in how incidents are reported internally can be a genuine opportunity if the current process is a known weak point. The standard is asking organisations to think proactively, not just defensively.

The Intended Outcomes of the ISMS

Clause 6.1.1 refers to giving assurance that the ISMS can achieve its intended outcomes. This phrase matters. The intended outcomes of an ISMS are not just about passing a certification audit. They are about protecting information in a way that supports the organisation's objectives, meets its legal obligations, and satisfies the expectations of its interested parties.

If an organisation has not clearly defined what it is trying to achieve with its ISMS, it cannot meaningfully assess whether risks and opportunities are relevant to those outcomes. Auditors will probe this. They will ask what the ISMS is supposed to deliver and then test whether the identified risks and opportunities are actually connected to that purpose.

This is where organisations sometimes get caught. They produce a risk register that looks thorough but has no visible connection to what the business actually does or what it has committed to in its information security policy. The risk register becomes a standalone document rather than a living part of the management system.

Preventing Undesired Effects and Achieving Continual Improvement

The clause has two additional purposes beyond protecting intended outcomes. The first is preventing or reducing undesired effects. This is the protective function that most people associate with risk management. Identify what could go wrong, assess how likely and how serious it is, and do something about it.

The second purpose is achieving continual improvement. This is where opportunities come back into focus. The ISMS should not be static. As the threat landscape changes, as the organisation evolves, and as the organisation learns from incidents and audits, the system should improve. Clause 6.1.1 is asking the organisation to build that improvement orientation into its planning from the start.

In practice, this means the risks and opportunities identified here should feed into objectives (Clause 6.2), operational controls (Clause 8), performance evaluation (Clause 9), and improvement activities (Clause 10). When an auditor traces a risk from Clause 6.1.1 through to a control in Annex A and then to a monitoring activity, they are testing whether the system actually works as a system.

Actions to Address Risks and Opportunities

Identifying risks and opportunities is only the first step. Clause 6.1.1 requires the organisation to plan actions to address them. These actions must be:

• Integrated into ISMS processes, not treated as separate tasks
• Evaluated for effectiveness, meaning the organisation must check whether the actions actually worked

This is where many organisations fall short. They identify risks, they document them, and then they stop. The actions either do not exist or are not connected to anything measurable. An auditor reviewing the ISMS will look for evidence that identified risks and opportunities have led to concrete actions, that those actions are owned by someone, and that there is a mechanism for checking whether they made a difference.

Integration into ISMS processes is particularly important. If the action to address a risk is simply “review the risk register annually,” that is not an action. That is a scheduling note. Genuine integration means the risk drives a control, a procedure, a training requirement, an objective, or some other tangible element of the management system.

How Clause 6.1.1 Relates to Clause 6.1.2 and 6.1.3

It is worth being clear about how Clause 6.1.1 sits alongside the subclauses that follow it. Clause 6.1.2 covers the information security risk assessment process, which is the detailed, asset-level or scenario-based process for identifying, analysing, and evaluating specific risks. Clause 6.1.3 covers risk treatment, including the selection of controls and the Statement of Applicability.

Clause 6.1.1 operates at a higher level. It is about the overall planning approach, the strategic risks to the ISMS as a whole, and the identification of opportunities. The detailed risk assessment in Clause 6.1.2 is one of the outputs of the planning process initiated by Clause 6.1.1, not a replacement for it.

Think of it this way. Clause 6.1.1 asks: what do we need to address for our ISMS to work? Clause 6.1.2 asks: what are the specific risks to our information assets? Both questions matter, but they are different questions, and conflating them leads to gaps in the management system.

What Auditors Look for When Assessing Clause 6.1.1

When an auditor sits down to assess Clause 6.1.1, they are not just looking for a document titled “Risks and Opportunities Register.” They are looking for evidence that the organisation has genuinely thought through what could affect its ability to manage information security effectively.

Specific things an auditor will examine include:

• Traceability to context: Do the identified risks and opportunities reflect the issues and interested party requirements documented under Clause 4? If the context analysis identified a heavy reliance on third-party cloud providers as a significant issue, does that appear in the risks and opportunities?
• Coverage of both risks and opportunities: Has the organisation genuinely considered what could go right, or has it only listed threats?
• Connection to intended outcomes: Are the risks and opportunities linked to what the ISMS is supposed to achieve?
• Planned actions: For each identified risk or opportunity, is there a corresponding action? Is that action specific and owned?
• Integration into processes: Do the actions show up elsewhere in the ISMS, for example in objectives, operational controls, or training plans?
• Effectiveness evaluation: Is there a mechanism for checking whether the actions worked?

An auditor will also look at whether the risks and opportunities have been reviewed and updated over time. A register that has not changed in three years, despite significant changes in the organisation or the threat environment, is a red flag. The ISMS should be a living system, and Clause 6.1.1 is where that living quality begins.

For anyone preparing for an ISMS audit, the article on auditing the risk assessment provides a useful companion perspective on what auditors examine in practice.

Common Weaknesses Auditors Find

Based on real audit experience, the most common weaknesses against Clause 6.1.1 are:

1. Generic risk lists: Risks that could apply to any organisation in any industry, with no connection to the specific context of the organisation being audited. Phrases like “data breach” or “unauthorised access” without any specificity about what data, what systems, or what the realistic threat sources are.
2. No opportunities identified: The register covers risks only. When asked about opportunities, the responsible person cannot articulate any.
3. Disconnected actions: Actions listed against risks that have no visible connection to anything in the ISMS. They exist on paper but do not drive any control, objective, or process.
4. No effectiveness evaluation: The organisation has planned actions but has no way of knowing whether those actions have made any difference.
5. Stale documentation: The risks and opportunities have not been reviewed since initial certification, despite significant changes in the organisation's operations, technology, or regulatory environment.
6. Confusion with Clause 6.1.2: The organisation presents its detailed risk assessment as the entirety of its response to Clause 6.1.1, missing the broader strategic planning intent of the clause.

Practical Steps for Getting Clause 6.1.1 Right

If you are responsible for an ISMS and want to make sure Clause 6.1.1 is genuinely effective rather than just compliant on paper, here are some practical steps.

Start with your context outputs. Go back to your Clause 4.1 and 4.2 work. Every significant issue and every significant interested party requirement should prompt a question: does this create a risk or an opportunity for our ISMS? If the answer is yes, it belongs in your planning.

Be specific about intended outcomes. Write down, in plain language, what your ISMS is supposed to achieve. Not just “protect information” but specifically what information, for whom, and against what kinds of threats. Use this as a filter for your risk and opportunity identification.

Require actions, not intentions. For every identified risk or opportunity, insist on a specific action with an owner and a timeframe. Vague statements like “improve security awareness” are not actions. “Deliver quarterly phishing simulation exercises to all staff by the end of Q2, with results reviewed by the ISMS manager” is an action.

Build in effectiveness checks. For each action, define how you will know it worked. This might be a metric, a review outcome, an audit finding, or a change in incident frequency. Without this, you cannot demonstrate effectiveness to an auditor or to yourself.

Review regularly and document the reviews. Set a schedule for reviewing your risks and opportunities, and stick to it. Trigger reviews whenever significant changes occur, whether that is a new system, a new supplier, a regulatory change, or a security incident. Document what changed and why.

The Relationship Between Clause 6.1.1 and Information Security Objectives

One connection that is often underappreciated is the relationship between Clause 6.1.1 and the information security objectives required by Clause 6.2. The objectives an organisation sets for its ISMS should flow from the risks and opportunities identified in Clause 6.1.1. If you have identified that staff awareness is a significant risk factor, one of your objectives should address that. If you have identified an opportunity to improve incident response capability, that should show up as an objective too.

When objectives are disconnected from the risks and opportunities in Clause 6.1.1, it suggests the planning process has not been integrated. Auditors will trace this connection. If the risks say one thing and the objectives say something entirely different, that is worth investigating.

Understanding how to set measurable information security objectives under Clause 6.2 is a natural next step once you have a solid grasp of Clause 6.1.1.

Documented Information Requirements

ISO 27001 does not explicitly require a specific document format for Clause 6.1.1. However, the organisation must retain documented information to demonstrate that the process has been carried out. In practice, this typically means a risks and opportunities register or a planning document that records:

• The risks and opportunities identified
• The actions planned to address them
• Who is responsible for each action
• How effectiveness will be evaluated

The format is less important than the content. A well-maintained spreadsheet that is actively used and regularly reviewed is more valuable than an elaborate document that nobody looks at between audits.

For a broader perspective on what documented information the ISMS requires across all clauses, the article on documented information in an ISMS under Clause 7.5 covers the full picture.

Building Auditor Competence Around ISO 27001 Planning Requirements

For auditors assessing ISMS against ISO 27001, Clause 6.1.1 is one of the most intellectually demanding parts of the audit. It requires the auditor to understand the organisation's context, grasp its intended outcomes, and then evaluate whether the identified risks and opportunities are genuinely connected to both. This is not a checklist exercise. It requires professional judgement.

If you are developing your competence as an ISO 27001 auditor, or if you are a quality or information security professional looking to move into auditing, building a solid understanding of the planning clauses is essential. The ability to trace a risk from Clause 6.1.1 through to a control, an objective, a monitoring activity, and an improvement action is a core auditor skill.

At Audit Workshop, our ISO 27001 internal auditor and lead auditor training covers exactly this kind of practical, clause-level analysis. Trainer Dilawar Laghari brings over 14 years of compliance experience and hundreds of external certification audits to the training room, which means the examples are real and the advice is grounded in what actually happens on audit days. If you are serious about auditing information security management systems effectively, our courses give you the practical foundation to do it well.