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.