If your risk register says mitigate but nothing has changed, turn that intention into a specific treatment, owner, deadline and check of effectiveness. A risk treatment schedule makes the implementation decisions and follow-up visible.
Why a register alone doesn't get risks treated
A risk register's job is to identify and rate risks. It is not built to answer the questions that actually drive treatment: which of several possible responses did you choose and why, what will it cost against what it saves, who owns getting it done, by when, and — critically — what happens if the answer is "we're not going to fix this one." Cramming those answers into extra columns on a register usually produces a spreadsheet nobody can read, which is its own failure mode (see Why Your Risk Spreadsheet Confuses Everyone Who Opens It). A treatment schedule is a separate, purpose-built document that picks up where the register leaves off.
The two documents serve different audiences, too. A register is often reviewed at a summary level — a heat map, a top-ten list, a trend over time. A treatment schedule is reviewed at the level of "did this actually happen," which is a different kind of scrutiny and needs a different kind of document to support it.
The treatment options, and why the choice needs to be explicit
ISO 31000:2018 describes risk treatment as a cyclical process of selecting and implementing options to address risk, and it frames the available options broadly as: avoiding the risk, taking or increasing it to pursue an opportunity, removing the source, changing the likelihood, changing the consequences, sharing the risk with another party, or retaining the risk based on an informed decision.
The mistake most treatment schedules make is skipping the explicit choice. "Reduce" is not a treatment option in itself — it's a category that covers several different actions with very different costs and timelines. A schedule that forces you to name which option you actually chose, and why, produces a much more honest document than one that just states an intended outcome.
This matters because the options are not interchangeable in what they cost to implement or how quickly they take effect. Removing a risk source is often the most expensive and slowest option, but it is also the most durable. Sharing a risk — through insurance or a contractual transfer to a supplier — can be fast to put in place but leaves you exposed to whatever the sharing arrangement doesn't actually cover, which is a detail worth checking rather than assuming. Retaining a risk is sometimes the correct answer, particularly for low-consequence risks where the cost of treatment would exceed the cost of the risk materialising, but it only counts as a treatment decision if someone with the authority to accept it actually makes that call.
What a risk treatment schedule template needs to record
A treatment schedule that will still be useful in twelve months' time, not just at sign-off, needs to capture:
- Treatment options considered — not just the one chosen, so a reviewer can see what else was on the table.
- Preferred approach — the option actually selected, with the reasoning.
- Post-treatment rating — what the risk is expected to look like once the treatment is implemented, distinct from where it sits today.
- Cost-benefit result — even a rough comparison of the cost of the treatment against the reduction in risk it buys, so decision-makers can see the trade-off, not just the recommendation.
- Responsibility — a named individual, not a team or department.
- Timeline — a real date, not "ongoing" or "Q_ TBC".
- Monitoring and review — how and when someone checks the treatment actually happened and is still working.
- Accept/reject decision documentation — an explicit record of who decided to accept a risk instead of treating it further, and on what basis, since an undocumented acceptance decision is indistinguishable from an oversight after the fact.
Worked example: a fictional logistics firm's treatment schedule
A fictional three-site logistics firm, Corrangamite Transport, identified that its dispatch system had no tested failover if the primary site lost power. Here is how that risk moved from register entry to treatment schedule:
| Field | Entry |
|---|---|
| Risk | Loss of dispatch capability from a primary-site power outage |
| Treatment options considered | Generator backup at primary site; failover to secondary site; manual dispatch procedure as interim measure |
| Preferred approach | Failover to secondary site (existing infrastructure, lower marginal cost than a new generator) |
| Post-treatment rating | Reduced from high to moderate — failover addresses extended outages, not sub-hour disruptions |
| Cost-benefit result | Estimated setup and testing cost against an estimated cost of one day's lost dispatch capacity; treatment judged cost-justified by the operations manager and finance |
| Responsibility | IT operations manager (named individual) |
| Timeline | Failover configured and tested within one quarter |
| Monitoring and review | Failover test scheduled every six months, logged in the maintenance calendar |
| Accept/reject decision | Residual moderate risk formally accepted by the operations director, recorded with date and reasoning |
Notice that the schedule still leaves a residual risk — sub-hour disruptions aren't addressed — and that residual risk is explicitly accepted rather than left implied. That's the difference between a treatment schedule and a to-do list.
Notice too that the schedule records what was rejected. The generator option wasn't obviously wrong — it would have addressed the sub-hour gap the chosen option leaves open — but recording why it wasn't selected means the decision can be revisited later with the same reasoning in front of whoever reopens it, rather than starting the argument from scratch.
Common mistakes in risk treatment schedules
- No explicit accept/reject decision. A risk that isn't fully treated needs someone to actually decide, on the record, that the remaining exposure is tolerable. Silence is not acceptance.
- Cost-benefit skipped entirely. Without it, treatment priorities tend to reflect whoever argued loudest in the meeting rather than where the money should actually go.
- "Ongoing" as a timeline. A date with no end is a treatment that will never be checked as complete or incomplete.
- Treatment and register drifting apart. When the schedule lives in a different document from the register and nobody keeps them synchronised, the register shows a risk as "being treated" long after the treatment either succeeded or was quietly dropped.
- Reassessing rating without evidence. A post-treatment rating should reflect what the treatment is actually expected to achieve, not be nudged down simply because a treatment now exists on paper — the same documented-versus-working distinction that shows up across Essential Eight Maturity Level 1 vs 2 vs 3: What Each Really Requires.
A treatment schedule built this way also gives you somewhere concrete to record decisions arising from other assessments — for example, treatments that come out of the questions in Ten Questions That Reveal Whether You Have an Insider Threat Problem need the same ownership, timeline and accept/reject discipline as any other risk.
Get the free template
SRMBOK's Template 13.3 Risk Treatment Schedule gives you this structure ready to use: treatment options, preferred approach, post-treatment rating, cost-benefit result, responsibility, timeline, monitoring and review, and accept/reject decision documentation, all in one document.