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.