Many organizations reach a point where they decide that information security needs to be taken more seriously. They invest in endpoint protection, tighten password requirements, deliver awareness training, and sometimes bring in an external consultant to review the environment. From a distance, this can look like genuine progress. Management sees visible activity, the IT team sees concrete improvements, and the organization begins to feel more secure. Yet that sense of readiness can prove misleading when a real disruption occurs. If a key supplier suddenly fails, if an important service becomes unavailable, or if an incident forces difficult business decisions, the underlying weakness is often exposed very quickly. Questions arise that should already have been answered like, who was responsible for preventing the disruption? How will it affect our business priorities and obligations? How much will it cost in terms of man-power and money to resolve? In many case the problem was not a lack of effort, but rather that effort was mistaken for planning. What appeared to be preparedness was in fact a collection of disconnected measures made without a clearly structured direction.
Clause 6.1, Actions to Address Risks and Opportunities
This is where clause 6 of ISO/IEC 27001 enters in. Up to this point the standard has laid the foundation for organisations to understand its own context, identify relevant interested parties, define the scope of the Information Security Management System (ISMS), and establish leadership, policy, and responsibilities. Clause 6 now asks a more difficult question: once the organization knows its context and has leadership commitment, what will it actually do with that knowledge? The answer to that is planning. Clause 6 is where the ISMS begins to move from intention to direction and from direction to deliberate action.
This matters because an ISMS is not meant to be a collection of good intentions, disconnected controls, or general awareness that “security is important.” ISO 27001 presents the ISMS as a risk-based management system that preserves the confidentiality, integrity, and availability of information through a risk management process, and that gives confidence to interested parties that risks are being adequately managed. ISO 27000 defines information security as the preservation of confidentiality, integrity, and availability of information, and defines risk as the effect of uncertainty on objectives. Taken together, these ideas explain why planning sits at the centre of the standard. Information security is not managed by reacting emotionally to whatever incident happened last week. It is managed by thinking ahead, deciding what matters, and preparing the organization to address uncertainty in a structured way.
Clause 6 contains three subclauses. The first, 6.1, addresses risks and opportunities. The second, 6.2, deals with information security objectives and planning to achieve them. The third, 6.3, requires changes to the ISMS to be carried out in a planned manner. This first part focuses on Clause 6.1, and this is the heart of the chapter. If Clause 5 establishes leadership, Clause 6.1 establishes direction. It asks the organization to think carefully about what could affect the ISMS, what could prevent it from achieving its intended outcomes, and what actions should be taken in response.
One reason Clause 6.1 can be difficult for some readers is that it operates on more than one level at once. One might assume that this section is simply about creating a risk register, but it far more than that. ISO 27003 explains that planning under 6.1 includes two related but distinct categories. The first concerns risks and opportunities relevant to the intended outcomes of the ISMS as a whole. These are covered in 6.1.1. The second concerns information security risks themselves, specifically risks related to loss of confidentiality, integrity, and availability of information within the scope of the ISMS. These are handled in 6.1.2 and 6.1.3 through risk assessment and risk treatment. That distinction is important. Some risks affect the management system’s ability to function properly, while others affect the organization’s information directly. A mature approach to planning recognizes both.
6.1.1 General
ISO 27001 states that when planning for the ISMS, the organization shall consider the issues referred to in Clause 4.1 and the requirements referred to in Clause 4.2, and determine the risks and opportunities that need to be addressed in order to ensure that the ISMS can achieve its intended outcomes, prevent or reduce undesired effects, and achieve continual improvement. The organization must then plan actions to address these risks and opportunities, and determine how to integrate and implement those actions into its ISMS processes and evaluate their effectiveness.
That wording may sound abstract at first, but its logic is straightforward. The organization already identified its internal and external issues in Clause 4.1 and the requirements of relevant interested parties in Clause 4.2. Now it must ask: given this context, what might help or hinder the ISMS? What must be addressed if the system is to work as intended? This means Clause 6.1.1 is not limited to technical threats. It includes organizational weaknesses, governance gaps, conflicting priorities, lack of resources, poor awareness, unclear responsibilities, and other factors that can undermine the system before a specific incident ever occurs. ISO 27003 makes this especially clear, noting that risks at this level can include unclear processes and responsibilities, poor awareness among employees, weak engagement from management, or insufficient resources for operating the ISMS.
Consider a simple example. An organization may have correctly identified that customer expectations, contractual commitments, and regulatory requirements place strong pressure on confidentiality and availability. It may also have decided that certification to ISO 27001 is strategically important. Yet if responsibility for risk decisions is unclear, if meetings are irregular, if management review is treated as a formality, and if security actions are not integrated into project planning, then the ISMS itself is at risk of underperforming. The weakness here is not primarily a missing firewall or an unpatched laptop. The weakness is that the management system lacks structure, support, or coherence.
Clause 6.1.1 also refers to opportunities, and this is sometimes overlooked. In standards language, opportunity does not mean vague optimism. It means a condition or possibility that could improve the ability of the ISMS to achieve its intended outcomes. An organization may, for example, discover that it can improve risk visibility by integrating information security into procurement, or reduce confusion by aligning security documentation with existing business processes, or strengthen consistency by tying security planning more closely to project governance. ISO 27003 notes that opportunities can arise from refining processes, reducing administrative overhead, clarifying interfaces, improving documentation, or introducing better technology. In other words, planning is not only defensive. It is also constructive.
This is one reason Clause 6.1 should not be read in a narrow or purely negative way. It is not simply asking, “What could go wrong?” It is also asking, “What needs to be improved so that the system becomes more reliable, more effective, and more aligned with organizational needs?” An ISMS that never thinks in terms of opportunity will often remain technically busy but strategically stagnant.
The final part of 6.1.1 is equally important. The organization must not only identify actions, but also plan how those actions will be integrated into ISMS processes and how their effectiveness will be evaluated. This is where planning begins to connect visibly with later clauses such as operation, monitoring, internal audit, and management review. A security action that is never assigned, never implemented in practice, and never evaluated may exist as an idea, but it does not yet exist as a management system reality.
6.1.2 Information security risk assessment
Clause 6.1.2 moves from general planning considerations into the formal risk assessment process for information security. ISO 27001 requires the organization to define and apply an information security risk assessment process. That process must establish and maintain information security risk criteria, including risk acceptance criteria and criteria for performing information security risk assessments. It must ensure that repeated assessments produce consistent, valid, and comparable results. It must identify information security risks, identify risk owners, analyse risks in terms of consequences and likelihood, determine risk levels, evaluate the risks against the criteria, and prioritize them for treatment. The organization must also retain documented information about the information security risk assessment process.
This is one of the most important parts of the standard because it prevents risk assessment from becoming arbitrary. Many organizations say they are “doing risk management,” but what they actually have is a list of concerns with no clear method behind it. One person rates almost everything high. Another person uses low unless disaster is almost certain. A third focuses only on cyberattacks and ignores process failures, supplier weaknesses, or human error. Clause 6.1.2 pushes the organization away from improvisation and toward a repeatable process.
ISO 27003 explains this well. The organization must establish criteria for assessing consequences and likelihood, and a method for combining them into a level of risk. The goal is not mathematical elegance for its own sake. The goal is consistency, validity, and comparability. If two similar risks are assessed by two different people, the results should not be wildly different without good reason. If the organization repeats the assessment later, it should be able to understand whether risk has increased, decreased, or remained stable. A method that produces unpredictable outcomes may look formal, but it does not support sound management.
At this point it is worth slowing down and clarifying several key terms. ISO/IEC 27000 defines risk assessment as the overall process of risk identification, risk analysis, and risk evaluation. Risk treatment is a separate process that modifies risk. Risk acceptance is the informed decision to take a particular risk. Residual risk is the risk remaining after treatment. These distinctions matter because they help prevent common misunderstandings. Assessing a risk is not the same as treating it. Treating a risk is not the same as eliminating it. Accepting a residual risk is not the same as ignoring it.
Risk identification comes first. The organization must identify risks associated with the loss of confidentiality, integrity, and availability of information within the scope of the ISMS. It must also identify risk owners, meaning persons or entities with the accountability and authority to manage a risk. This is a crucial discipline. Risks that belong to everyone often belong to no one. A risk register may look impressive, but if no one has authority to make decisions about a risk, allocate resources, or approve treatment, then the process is already weakened.
The familiar triad of confidentiality, integrity, and availability gives this section its structure. Confidentiality concerns preventing unauthorized disclosure. Integrity concerns accuracy and completeness. Availability concerns accessibility and usability on demand by an authorized entity. These are not theoretical abstractions. They provide a practical lens through which risks can be identified. A misdirected E-Mail containing personal data is primarily a confidentiality risk. An unauthorized modification to supplier bank details is primarily an integrity risk. A ransomware infection that blocks access to critical systems is primarily an availability risk, though it may also have confidentiality and integrity dimensions.
The organization must then analyse the risks by assessing potential consequences and realistic likelihood. Consequences ask what harm would result if the risk materialized. Would there be financial loss, legal exposure, operational disruption, reputational harm, safety implications, or damage to customer trust? Likelihood asks how realistic the occurrence is, taking into account the environment, existing conditions, and circumstances. ISO 27003 emphasizes that the organization may use qualitative, quantitative, or semi quantitative methods, but whatever technique is chosen, the process should remain sufficiently objective and useful.
Take a practical example. Imagine an organization that relies heavily on a cloud-based document system for customer records, internal procedures, and contract management. If that system becomes unavailable during a critical business period, the consequences could include delayed service delivery, missed contractual deadlines, and inability to access key records. If the organization has weak offline fallback arrangements and no tested business continuity procedures for that service, the likelihood of serious impact rises. Once those factors are analysed, the organization can determine the level of risk and compare it against its risk acceptance criteria.
This comparison leads to risk evaluation. Here the organization decides whether the risk is acceptable or whether it requires treatment. This is another point where many organizations struggle. The temptation is to label almost every meaningful risk as “accepted” because treatment may be inconvenient, expensive, or politically difficult. Yet the standard does not treat risk acceptance as a shortcut to avoid action. It expects an informed decision. Risk acceptance criteria should be real criteria, not a convenient excuse. If the organization claims that a severe availability risk is acceptable, that claim should be defensible in relation to its business objectives, interested party requirements, and leadership commitments.
Prioritization follows. Not all risks can be treated at once. Clause 6.1.2 therefore requires the organization to prioritize analysed risks for treatment. This reflects reality. Resources are limited. Time is limited. Management attention is limited. A mature ISMS does not merely compile a catalogue of problems. It helps the organization decide what needs attention first, what can be scheduled, and what must not be postponed.
6.1.3 Information security risk treatment
Once risks have been assessed, the organization must decide what to do about them. Clause 6.1.3 requires the organization to define and apply an information security risk treatment process. This includes selecting appropriate treatment options, determining the controls necessary to implement the chosen option or options, comparing those controls with Annex A to verify that no necessary controls have been omitted, producing a Statement of Applicability, formulating an information security risk treatment plan, and obtaining risk owners’ approval of the treatment plan and acceptance of the residual information security risks. The organization must retain documented information about the risk treatment process.
This is where planning becomes concrete. A risk assessment may tell the organization what matters, but risk treatment determines what the organization will actually do in response. ISO/IEC 27000 defines risk treatment as the process to modify risk, and notes that treatment can involve avoiding the risk, changing likelihood, changing consequences, sharing the risk, removing the risk source, or retaining the risk by informed choice. This is helpful because it reminds us that treatment is broader than simply adding controls. Sometimes the right response is to redesign a process, discontinue an activity, shift contractual arrangements, or reduce exposure rather than merely layering on more technical measures.
For example, suppose an organization identifies a risk that confidential files are being shared through an uncontrolled consumer file sharing service. One treatment option might be to block that service and enforce an approved alternative with access controls and logging. Another might be to redesign the collaboration process so that external sharing occurs only through managed business platforms. Another might be to reduce the underlying need for such sharing by changing workflow design. In each case, the response is not just “buy a tool.” It is a treatment choice based on the assessed risk and the organization’s context.
Clause 6.1.3 also requires the organization to determine all controls necessary to implement the chosen treatment options, and then compare those controls with Annex A. This comparison does not mean Annex A automatically dictates every control the organization must implement. Rather, the organization must verify that no necessary controls have been overlooked. ISO 27001 explicitly allows organizations to design controls as required or identify them from any source, but it still expects a disciplined check against Annex A. This helps prevent narrow or incomplete treatment planning.
This is also where ISO 27002 becomes especially useful. ISO 27002 describes itself as a reference for determining and implementing controls for information security risk treatment in an ISMS based on ISO 27001. In other words, ISO 27001 sets the requirement to treat risk and verify necessary controls, while ISO 27002 provides implementation guidance and a structured catalogue of controls to support that process. It is therefore a mistake to treat ISO 27002 as the requirement standard itself, but it is equally mistaken to ignore its practical value during treatment planning.
The Statement of Applicability, often called the SoA, emerges directly from this discipline. Clause 6.1.3 requires it to include the necessary controls, the justification for their inclusion, whether they are implemented, and the justification for excluding any of the Annex A controls. This document is often misunderstood. It is not merely a certification formality. It is a visible expression of treatment logic. It shows how the organization moved from assessed risk to control decisions, and how it justified what was included or excluded. When well maintained, it becomes one of the clearest windows into the thinking of the ISMS.
The risk treatment plan complements the Statement of Applicability. If the SoA explains the control decision landscape, the treatment plan explains execution. What will be done? By whom? In what order? With what resources? Over what timeframe? This is where planning stops being theoretical. A risk that has been assessed and assigned a proposed control is not yet treated. Treatment only becomes real when implementation is planned, carried out, and followed through.
Clause 6.1.3 ends by requiring risk owners to approve the treatment plan and accept the residual risks. That final element is critically important. Residual risk is normal. No organization eliminates all uncertainty. No set of controls creates perfect security. The standard is realistic about this. What it rejects is the idea that residual risk should be accidental, invisible, or ownerless. The remaining risk after treatment should be known and consciously accepted by those with authority to do so. This reinforces accountability and keeps risk management tied to decision making rather than administrative routine.
Common misunderstandings
Clause 6.1 often reveals several persistent misunderstandings in practice. The first is the idea that risk assessment is mainly a spreadsheet exercise. In truth, the spreadsheet is only a record. The real work is in the judgement, structure, and reasoning behind it. A perfectly formatted register with weak thinking behind it is still weak risk assessment.
The second is the assumption that risk treatment means buying technology. Technology may be part of treatment, but treatment can also involve governance changes, procedural changes, contractual changes, redesign of workflows, training, segregation of duties, or decisions to stop doing something in a risky way.
The third is the belief that every risk must be reduced to zero. That is neither realistic nor required. The standard assumes that residual risk will remain. The point is not perfection, but informed and defensible management of uncertainty.
The fourth is the habit of treating Clause 6.1 as though it were only about negative events. As already noted, the clause explicitly includes opportunities. A strong Information Security Management System does not merely suppress problems. It also identifies ways to improve processes, clarify ownership, strengthen integration, and increase effectiveness over time.
Conclusion
Clause 6.1 is where planning in ISO/IEC 27001 becomes real. It requires the organization to do more than acknowledge that risk exists. It requires the organization to think systematically about what could affect the ISMS, what could threaten confidentiality, integrity, and availability, how those risks should be assessed, who owns them, what treatment is necessary, which controls are required, and what residual risk remains after treatment. It is one of the clearest examples in the standard of the difference between activity and management. Activity is doing things that appear security related. Management is deciding, deliberately and repeatedly, what should be done, why it should be done, and how the organization will know whether it is working.
That is also why Clause 6.1 deserves such careful attention. It gives the organization its first real planning discipline within Chapter 6 by requiring it to move beyond general concern about security and toward a structured understanding of risks, opportunities, ownership, treatment, and residual exposure. Without that foundation, the ISMS can easily become reactive, fragmented, or overly focused on isolated activities rather than managed priorities. With it, the organization begins to establish direction, deciding what must be addressed, why it matters, and how those decisions are to be carried through in a deliberate and defensible way.
At the same time, Clause 6.1 is only the opening part of Chapter 6, not the whole of it. Risk based planning gives the organization direction, but that direction still needs to be translated into defined objectives and then sustained through controlled change. In Part 2 we will move to Clause 6.2 and examine how the standard requires organisations to establish information security objectives, as well as create plans on how to achieve those objectives.