Browse documentation
Risk score and readiness
Every change carries a risk score from 0 to 10, shown with the factors that produced it. It exists because a self-selected "risk: medium" says what someone chose, not what the change costs if it goes wrong.
How the score is built
The score starts from the risk rating you selected, then adjusts for things that are actually true about the change:
Pushes the score up
| Factor | Why |
|---|---|
| Causes an outage | The largest single addition. |
| High or critical impact | |
| Touches a network device | Weighted above a server — losing a switch takes everything behind it. |
| Touches a server | |
| Affects three or more items | Breadth of blast radius. |
| Window collision | Another change overlaps the same items in the same window. |
| No assignee | Nobody is accountable for it. |
Pulls the score down
| Factor | Why |
|---|---|
| Rollback plan present | There's a way back. |
| Implementation plan present | The work is thought through. |
| Ran successfully before | A comparable change has worked. |
The result lands in a band: low, moderate, high, or critical.
Two things worth knowing
The score is calculated fresh every time it's shown, never stored. Adding a rollback plan lowers the risk the moment you save it, not at some later recalculation.
The factors are always shown. A score you can't interrogate would be no better than the rating it replaced, so the contributing factors are listed alongside it — you can see exactly why a change scored what it did, and what would lower it.
The weights are a deliberate policy choice, not a measurement. If your organisation disagrees with how heavily something is weighted, that's a conversation to have — the numbers are stated so they can be argued with.
Readiness checks — "before you save"
Alongside the score, a change shows readiness checks. Most are advisory: a draft is allowed to be incomplete, and the checks are there to tell you what you'll want before this goes anywhere.
| Check | Blocking? |
|---|---|
| Assignee set | Yes — approval cannot start without one |
| Rollback plan | Yes, on high-risk changes — rated High or Critical, or causing an outage |
| Affected items listed | No — but without them there is no blast radius and no collision detection |
| Implementation plan | No |
| Window scheduled | No — but unscheduled changes don't appear on the calendar |
| No window collision | No — a warning that another change overlaps |
Notes & tips
- If a change won't go for approval, check the two blocking items first: assignee, and rollback plan on anything high-risk.
- A high score is not a veto. It's an argument for more preparation — a rollback plan and a booked window will bring it down.