How to Build a Risk Treatment Plan That Actually Works

Share with

Contents

A risk treatment plan is the document that turns your risk assessment into action. The assessment tells you which risks matter. The risk treatment plan says what you will do about each one, who is responsible, by when, and what the risk looks like once the work is finished.

It is a mandatory output under ISO 27001, but the reason to build one properly has little to do with the certificate. Without it, risk assessments become an annual exercise that changes nothing. Teams identify twenty serious risks, agree they are serious, and find the same twenty listed again a year later.

A good risk treatment plan closes that loop. It names an owner for every decision, records why the decision was made, and tracks whether the control actually reduced the risk. This page covers the four treatment options, what belongs in the plan, how to handle residual risk, and the mistakes that make plans stall. If you are building out the wider information security management system, this sits between assessment and implementation.

What a Risk Treatment Plan Is

It is a structured record of decisions, not a list of problems.

For each risk that exceeds your acceptance threshold, the plan captures the chosen treatment option, the controls that deliver it, the owner, the deadline, the resources needed, and the expected residual risk once the treatment is in place.

The difference between this and a risk register matters. The register holds all identified risks with their scores. The plan holds only those needing action, plus the decision trail behind each one. Keeping them separate stops the register turning into a project tracker that nobody maintains.

The Four Risk Treatment Options

Every risk gets one of four decisions. Naming the option explicitly is what keeps the plan honest.

The Four Risk Treatment Options

Modify the Risk

Apply controls to reduce likelihood, impact, or both. This is the most common route and covers the majority of entries in a typical plan. Encryption, access restrictions, monitoring, and patching all sit here.

Avoid the Risk

Stop the activity causing the risk. Retiring an unsupported application or ending a data-sharing arrangement removes the exposure entirely. It is underused because it feels drastic, but it is often cheaper than years of compensating controls.

Share the Risk

Transfer part of the exposure through insurance, outsourcing, or contractual terms. Note the limit: you can share financial consequences, but accountability for the data usually stays with you. Regulators rarely accept a supplier contract as a defence.

Accept the Risk

Take no further action because the risk sits within your tolerance or treatment costs more than the exposure. Acceptance is a legitimate choice, provided it is documented, justified, and approved by someone with authority to carry it.

What to Include in the Plan

Keep each entry short enough that owners will actually update it. A workable entry holds the risk reference and description, the current risk score, the treatment option chosen, the specific controls being applied, the control owner, the target completion date, the resources or budget approved, the expected residual risk, and the approval record.

The two fields most often missing are expected residual risk and the approval record. Without the first, you cannot tell whether treatment worked. Without the second, nobody can say who agreed to carry the leftover exposure.

Link each entry to the relevant Annex A controls so the plan and your Statement of Applicability stay consistent. Auditors compare the two, and mismatches are a common finding.

Try Effivity for Free and see how treatment actions stay linked to the risks that triggered them.

Free Trial →

How to Build a Risk Treatment Plan

Work from the assessment output, not from a control list. Starting with controls produces plans that implement whatever is easy rather than whatever is needed.

Sort by Risk, Not by Convenience

Order risks by score and deal with the top band first. Where several risks share a root cause, group them: one control often treats five entries. That grouping is where most of the practical savings appear.

Choose the Option Before the Control

Decide whether you are modifying, avoiding, sharing, or accepting before selecting any control. Teams that skip this step default to modification every time and end up building controls for risks they should simply have accepted or removed.

Assign One Named Owner

An owner is a person, not a department. Shared ownership is the single biggest cause of overdue treatment actions, because everyone assumes the other party has it. The owner needs budget authority or a clear route to someone who has it.

Set Realistic Dates

A plan where every action is due in three months is a plan nobody believes. Stagger deadlines by risk score and available resources. Slipping dates repeatedly damages credibility with auditors more than a longer honest timeline.

Residual Risk and Approval

Residual risk is what remains after treatment. Every entry should state the expected residual level before work starts and the actual level once controls are live.

The gap between the two is useful information. If treatment consistently fails to reach the expected level, your control selection or effectiveness testing needs review, not just more controls.

Residual risk that stays above your acceptance threshold needs formal sign-off from management, recorded with a date and a name. This is where risk mitigation work becomes a governance question rather than a technical one. Leadership must consciously accept what is left over, because that acceptance is what auditors test during certification.

Common Mistakes That Stall a Plan

Treating it as a document rather than a schedule. A plan written once and filed is not a plan. It needs review dates and status updates like any project.

Listing controls without owners or deadlines. These entries never move. If a line has no name and no date, it is a wish, not a treatment.

Skipping the acceptance decision. Risks left unaddressed without a recorded acceptance look like oversights, and auditors treat them as such.

Copying treatments from a template. Controls must match your context. A borrowed plan produces actions nobody understands and nobody completes.

No link back to the assessment. When the risk score changes, the treatment should be reviewed. Plans disconnected from the information security risk management process drift out of date quietly.

Reviewing and Updating the Plan

Review at a set interval, quarterly for most organisations, and whenever something changes materially: a new system, a new supplier, a significant incident, or a change in the risk score.

Each review should confirm progress against dates, whether completed controls achieved the expected residual risk, whether new risks need entries, and whether any accepted risks have grown beyond tolerance.

Bring the summary into your management review. Leadership seeing overdue treatments alongside other performance data is what unblocks stalled actions. Findings from your ISO 27001 audit should feed the same cycle rather than sitting in a separate list.

How Software Keeps the Plan Live

Spreadsheets work until several owners and dozens of actions are involved. After that, status becomes unreliable and nobody trusts the version they are looking at.

A structured platform links each treatment action to its source risk, sends reminders to owners as dates approach, records approvals with timestamps, and shows current status without anyone chasing updates. Effivity's information security management software handles this through its ISMS Risk Management module, connecting risks, treatments, Annex A controls, and the Statement of Applicability so one update flows through all of them.

The gain is visibility. When leadership can see which treatments are late and which risks remain above tolerance, decisions happen in the meeting rather than three weeks later. Reporting through a risk matrix view makes that conversation faster.

Get a Free Personalized Demo to see how your existing risks would map into a working treatment plan.

Free Demo →

Frequently Asked Questions

It is a document that records how each significant risk will be handled, including the treatment option, controls, owner, deadline, and expected residual risk. It turns assessment findings into tracked actions.

Modify, avoid, share, and accept. Every risk above your acceptance threshold must be assigned one of these, with the reasoning recorded alongside it.

Yes. Clause 6.1.3 requires a documented risk treatment process and plan, along with owner approval of residual risks before certification.

The register lists all identified risks and their scores. The treatment plan covers only risks needing action, with owners, dates, and decisions attached.

Quarterly suits most organisations, plus reviews triggered by new systems, new suppliers, incidents, or changes in risk scores. Record every review date.

Share with