What Is a Risk Treatment Plan? The ISO 27001 Document Between the Risk Assessment and the SoA

A risk treatment plan is the document ISO/IEC 27001:2022 clause 6.1.3 e requires the organization to "formulate," and clause 6.1.3 f requires it to "obtain risk owners' approval of the information security risk treatment plan and acceptance of the residual information security risks." Our glossary gives the working definition: "A risk treatment plan is the ISO/IEC 27001 document that records, for each risk the organization has decided to treat, the option chosen, the controls to be applied, the owner, the resources and the timescale." Here is the contrarian part. The standard's text does not prescribe a single one of those columns. What it does prescribe is who signs: the risk owners identified under 6.1.2 approve the plan and accept what is left over. Most treatment plans we review are elaborate spreadsheets with no approval on them, and an auditor reading 6.1.3 f will find the missing signature before they find a missing column.

This article covers where the plan sits in the clause 6.1 process, the treatment options ISO actually defines (there are more than four), residual risk and who accepts it, how the plan differs from the risk register and the Statement of Applicability, and what keeps it alive after certification.

A note on sources. iso.org blocked every fetch during the writing of this piece, so ISO/IEC 27001:2022 is quoted from its own front pages as republished in a distributor's preview PDF, which covers clauses 1 to 6.3 in full. The risk treatment definition is quoted from ISO/IEC 27006-1:2024, which restates it with attribution to ISO/IEC 27000:2018. NIST's glossary is used for the two residual-risk definitions.

Key takeaways

• Clause 6.1.3 requires two things of the plan by name: that it be formulated (6.1.3 e) and that risk owners approve it and accept the residual risks (6.1.3 f). Everything else about its format is yours to decide.
• Risk treatment is "process to modify risk," and ISO lists seven ways to do it, including "retaining the risk by informed choice." Accepting a risk is a treatment, not a failure to treat.
• The plan is the operational half of a pair: the Statement of Applicability records the control-by-control position, the plan records what will be done, by whom and by when for each treated risk.
• Risk owners are identified in the risk assessment under 6.1.2 c 2 and approve the plan under 6.1.3 f. A plan approved by the security lead on the owners' behalf has skipped the requirement.
• Treatment "can create new risks or modify existing risks," in ISO's words, so a plan is an input to the next assessment, not the end of the process.

Where the plan sits in clause 6.1

ISO/IEC 27001:2022 clause 6.1.2 requires a risk assessment process that "establishes and maintains information security risk criteria" including "the risk acceptance criteria," that identifies risks and "the risk owners," that "determine[s] the levels of risk," and that finally "prioritize[s] the analysed risks for risk treatment." Clause 6.1.3 then requires a risk treatment process with six lettered parts:

• a) "select appropriate information security risk treatment options, taking account of the risk assessment results"
• b) "determine all controls that are necessary to implement the information security risk treatment option(s) chosen"
• c) "compare the controls determined in 6.1.3 b) above with those in Annex A and verify that no necessary controls have been omitted"
• d) "produce a Statement of Applicability"
• e) "formulate an information security risk treatment plan"
• f) "obtain risk owners' approval of the information security risk treatment plan and acceptance of the residual information security risks"

The plan is item e, and the standard adds that the organization "shall retain documented information about the information security risk treatment process." One caution before anyone reads a sequence into those letters: the standard's introduction says "the order in which requirements are presented in this document does not reflect their importance or imply the order in which they are to be implemented," and that "the list items are enumerated for reference purpose only." So the fact that the Statement of Applicability is d and the plan is e does not mean the SoA comes first. In practice the two are produced together from the same treatment decisions, and the failure mode is producing either one before the risk assessment exists.

ISO/IEC 27006-1:2024 describes the link from assessment to treatment in its definition of risk analysis: it "provides the basis for risk evaluation and decisions about risk treatment." The plan is where those decisions land.

The treatment options, and why four words are not enough

ISO/IEC 27006-1:2024 clause 3.14, quoting ISO/IEC 27000:2018, defines risk treatment as "process to modify risk," the same three words the NIST glossary carries from ISO Guide 73. Its note lists what treatment "can involve":

• "avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk"
• "taking or increasing risk in order to pursue an opportunity"
• "removing the risk source"
• "changing the likelihood"
• "changing the consequences"
• "sharing the risk with another party or parties (including contracts and risk financing)"
• "retaining the risk by informed choice"

Two further notes matter for the plan. Treatments "that deal with negative consequences are sometimes referred to as 'risk mitigation', 'risk elimination', 'risk prevention' and 'risk reduction'," which is where the familiar four-word menu of accept, avoid, transfer and mitigate comes from; NIST's version of that menu, and its warning that transfer has a limit, is in our piece on the risk register. And: "Risk treatment can create new risks or modify existing risks." A plan that introduces multi-factor authentication has also introduced a lockout and recovery risk, and a plan that never records a risk created by its own treatments is not being maintained honestly.

The option most teams handle badly is the last one. "Retaining the risk by informed choice" is a treatment. Recording that a risk is accepted, by its owner, against the acceptance criteria the organization set under 6.1.2 a, is a complete and legitimate line in the plan. What is not legitimate is the version that hides acceptance elsewhere: a control marked not applicable in the SoA because it was expensive, with no accepted risk behind it. Our Statement of Applicability guide calls that out as the exclusion auditors never take, and the plan is where the honest version of that decision belongs.

Residual risk, and who is allowed to accept it

Clause 6.1.3 f ties two things together: approval of the plan and "acceptance of the residual information security risks." Residual risk is what is left after treatment. NIST's glossary carries two definitions that say the same thing from different angles: "portion of risk remaining after security measures have been applied," and, from NISTIR 8286, "risk that remains after risk responses have been documented and performed."

The people who accept it are the risk owners, and the standard is precise about where they come from: 6.1.2 c 2 requires the risk assessment process to "identify the risk owners." Their approval is a requirement on the treatment process, not a courtesy. Three consequences follow for the plan.

Every treated risk needs a named owner on the plan, and the owner has to be someone who can accept a residual risk. An engineer who can implement the control is often not the person who can accept the risk that remains after it. If the plan's owner column is a list of implementers, the approval under 6.1.3 f has not happened.

The acceptance has to be against the criteria. Clause 6.1.2 a requires "the risk acceptance criteria" to be established and maintained. A residual risk above the criteria that an owner accepts anyway is a documented deviation from your own ISMS, and it can be raised as a nonconformity against your own requirement. If that happens repeatedly, the criteria are wrong, and the fix is to change them through the management review rather than to keep signing exceptions. What a nonconformity against your own document looks like, and how the grade is decided, is in our piece on ISO 27001 nonconformities.

The approval has to be evidenced. The note to ISO/IEC 27000:2018's definition of documented information says the term can refer to "evidence of results achieved (records)." A plan with an approval column that reads "approved" and no record of who, when or of what version is not evidence of 6.1.3 f. Dated sign-off by owner, on the version they saw, is the artifact an auditor will ask for.

The plan, the register and the SoA

Three documents, one process, and they get confused because each carries some of the same fields. The distinction is what question each answers and which clause it satisfies.

The register and the plan are often one spreadsheet with more columns, and the standard does not object; "documented information" in ISO/IEC 27000:2018 is "information required to be controlled and maintained by an organization and the medium on which it is contained," so the medium is free. What has to be separable is the approval: an auditor needs to see which rows the owners approved as treatments and which residual risks they accepted, and a single sheet where everything is marked "reviewed" cannot show that.

The SoA is different in kind. It is a control-by-control statement of position and it is derived from the treatment decisions, which is why an SoA written before the plan exists has nothing for its justifications to trace to. The SoA article owns the drafting of that document and the FAQ on how the two differ; this page owns the plan.

Keeping the plan alive after certification

The plan is a clause 6 planning document with a clause 8 execution requirement: the contents page of ISO/IEC 27001:2022 lists "Information security risk treatment" under Operation as clause 8.3, alongside the risk assessment at 8.2. Planning the treatment is not implementing it, and a surveillance auditor sampling clause 8 will pick a treatment from the plan and ask for the evidence that it happened.

Three things move the plan after the initial certification. A treatment completes, and its residual risk needs re-evaluation against the criteria. A new risk enters the register from an incident, a new supplier or a change, and needs a treatment decision and an owner. And a treatment creates a new risk, which the note quoted above says to expect. Clause 6.2 c also requires the information security objectives to "take into account applicable information security requirements, and results from risk assessment and risk treatment," so the plan feeds the objectives that top management reviews. A plan that has not changed in a year while the business has is the same tell auditors look for in an unchanged SoA.

The honest caveat: the plan is a decision record, not a project plan

We write these with clients, so weigh this accordingly. The most common way the document fails is by trying to be two things. A treatment plan that becomes the security team's full project tracker, with sprint tasks and ticket links, buries the decisions the standard cares about under work-in-progress that changes weekly, and the risk owners who are supposed to approve it stop reading it. The plan should carry one line per treatment decision: the risk, the option chosen from the list above, the controls that implement it, the owner who accepted the residual risk, the target for completion, and the status. The engineering detail lives in whatever tool runs the work, and the plan links to it.

And for a small organization with a short register, the plan can be short. Nothing in clause 6.1.3 asks for a document of a particular length; it asks for a formulated plan and an approval. A page that owners have signed beats a workbook they have not.

Where Top Floor fits

The part of this work that benefits from outside help is upstream of the document: risk acceptance criteria that owners can actually apply, a risk assessment whose results are comparable the second time, and treatment decisions that produce traceable SoA justifications. That sits inside our ISO 27001 practice, and for teams with no internal owner it runs as part of compliance as a service. Where the honest gap is that nobody senior enough to accept a residual risk is engaged with security at all, a vCISO engagement addresses the missing approver rather than the missing spreadsheet. An adversarial read of the plan against the register and the SoA before Stage 2 is audit and assurance work, kept separate from the build for the impartiality clause 9.2 requires.

Where we are not needed: if your register has named owners, your criteria are written down, and your owners will sit in a room and sign, you can produce this document yourself in an afternoon. The document is easy. The decisions are the work.

How to decide this week

• Open the plan and look for the approval. If there is no dated sign-off by a named risk owner on the version in front of you, 6.1.3 f has not been met, whatever else the document contains.
• Check that every owner on the plan is someone who can accept a residual risk, not only someone who can build the control.
• Find every risk marked accepted and confirm it sits within the acceptance criteria under 6.1.2 a. Any that do not are either exceptions to record or criteria to change.
• Pick three completed treatments and ask for the evidence under clause 8.3 that they were carried out. If the plan and the evidence disagree, the plan is stale.
• Add a column for risks created by treatments. If it stays empty for a year, nobody is looking.

Frequently asked questions

Who has to approve the ISO 27001 risk treatment plan?

The risk owners. ISO/IEC 27001:2022 clause 6.1.3 f requires the organization to obtain risk owners' approval of the information security risk treatment plan and acceptance of the residual information security risks, and clause 6.1.2 c 2 requires the risk assessment process to identify those owners. Approval by the security lead or the project sponsor on the owners' behalf does not meet the requirement, because the point of the clause is that the person accountable for the risk is the one who accepts what remains after treatment. Record the approval as a dated sign-off on the specific version approved.

Is accepting a risk allowed under ISO 27001?

Yes. ISO's definition of risk treatment, quoted in ISO/IEC 27006-1:2024 from ISO/IEC 27000:2018, lists "retaining the risk by informed choice" as one of the things treatment can involve, and ISO/IEC 27001:2022 clause 6.1.2 a requires the organization to establish risk acceptance criteria as part of its risk criteria. An accepted risk is a legitimate line in the treatment plan when the acceptance is made by the risk owner, recorded, and consistent with those criteria. What is not legitimate is disguising an acceptance as a scope exclusion in the Statement of Applicability.

What are the risk treatment options in ISO 27001?

ISO/IEC 27001:2022 clause 6.1.3 a requires the organization to select appropriate treatment options taking account of the risk assessment results, but it does not enumerate them; the list is in ISO's vocabulary. As restated in ISO/IEC 27006-1:2024 from ISO/IEC 27000:2018, treatment can involve avoiding the activity that gives rise to the risk, taking or increasing risk to pursue an opportunity, removing the risk source, changing the likelihood, changing the consequences, sharing the risk with another party including through contracts and risk financing, and retaining the risk by informed choice. The four-word menu of accept, avoid, transfer and mitigate is a compression of that list, and the same note observes that treatment can itself create new risks.

Does the risk treatment plan have to be a separate document from the risk register?

No. The standard requires the plan to be formulated and approved and requires documented information about the risk treatment process; it does not require a particular document structure, and ISO/IEC 27000:2018 defines documented information without reference to any medium. Many organizations keep the register and the plan as one workbook. What has to be distinguishable is the approval: an auditor needs to see which treatment decisions the risk owners approved and which residual risks they accepted, so if the two live together, the approval record has to identify the rows and the version it covers.