Risk Register Example: Sixteen Scored Risks on a Cloud Migration
A risk register records each risk as a cause and an effect, scored for probability and impact, with an owner, a response type, the mitigating action and the residual score once that action is done. The example below shows sixteen risks from a fictional cloud migration, including two that have been closed.
The example
The register below belongs to a fictional cloud migration: around 200 applications leaving a leased datacentre in four waves, against a contractual exit date. Sixteen risks, scored on a five-point scale for probability and impact, with the residual score shown after the planned response. Two are closed and left in place. A register at this stage of a programme normally runs to twenty or thirty entries; this is the set that would be reviewed at the monthly board.
| ID | Risk | Category | Owner | P | I | Score | Rating | Response | Mitigating action | Target date | Residual | Status |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| R-01 | The application inventory was built from configuration data last audited two years ago. Undiscovered applications may surface mid-programme, growing wave scope and cost. | Scope | Programme manager | 4 | 4 | 16 | Red | Reduce | Discovery scan across all subnets before wave 2 planning; monthly reconciliation of scan output against the inventory. | 16 May | 8 | Open |
| R-02 | The payroll application is supported by one vendor engineer and has no documented runbook. An incident during the payroll cut could take days rather than hours to resolve. | Operational | HR service owner | 3 | 5 | 15 | Red | Reduce | Runbook written and reviewed with the vendor; parallel payroll run retained for two cycles after the cut. | 09 May | 5 | Open |
| R-03 | Latency between the cloud region and the branch sites may exceed the tolerance of the point-of-sale application, causing transaction timeouts at branch go-live. | Technical | Network architect | 3 | 4 | 12 | Amber | Reduce | Latency measured from six representative branches before wave 2 is committed; caching option costed as a fallback. | 30 May | 4 | Open |
| R-04 | The migration factory is staffed by contractors on three-month rolling contracts. Attrition mid-programme would slow wave delivery. | Resource | Delivery manager | 3 | 3 | 9 | Amber | Reduce | Retention arrangement to programme end agreed for six key roles; a named shadow on each role. | 23 May | 6 | Open |
| R-05 | Regulated finance records could be stored in a region that does not meet the retention policy, creating a compliance breach. | Compliance | Records manager | 2 | 5 | 10 | Amber | Avoid | Finance workloads restricted to the primary region by policy; region confirmed in writing before any finance migration. | 13 May | 5 | Open |
| R-06 | If right-sizing is deferred until after migration, run-rate spend may exceed the business case. | Financial | Finance business partner | 4 | 3 | 12 | Amber | Reduce | Right-sizing review 30 days after each wave; budget alert at 80% of the monthly forecast. | Each wave | 6 | Open |
| R-07 | A longer migration than planned would extend dual running of the old and new estates and exhaust contingency. | Financial | Programme manager | 3 | 3 | 9 | Amber | Reduce | Dual-running cost tracked monthly against contingency; wave scope reduced rather than extended if the trend holds. | Monthly | 6 | Open |
| R-08 | The datacentre exit date is contractual. If wave 4 slips, an extension must be bought at short notice and at whatever price is offered. | Commercial | Vendor manager | 3 | 4 | 12 | Amber | Reduce | Eight-week buffer held before the exit date; extension terms negotiated in advance so the fallback price is known. | 30 Jun | 8 | Open |
| R-09 | The security architecture board meets monthly. Late submissions could delay each wave by up to four weeks. | Governance | Security lead | 3 | 3 | 9 | Amber | Reduce | Standing agenda slot secured; submission checklist agreed with the board secretary. | 08 May | 3 | Closed |
| R-10 | Backup tooling in the target platform differs from the source. Restore procedures could be untested at go-live, making a data loss unrecoverable. | Technical | Infrastructure lead | 2 | 5 | 10 | Amber | Reduce | Restore test per wave, with the evidence recorded as a go-live criterion rather than an assurance. | Each wave | 5 | Open |
| R-11 | Business users may be unavailable for wave 2 verification during the annual stocktake. | Business | Operations lead | 4 | 2 | 8 | Amber | Avoid | Wave 2 verification moved outside the stocktake window; dates confirmed with site managers. | 02 May | 2 | Closed |
| R-12 | The logistics provider may not commit to a change window for the warehouse interface, leaving the feed to be rebuilt after go-live. | Third party | Integration lead | 3 | 4 | 12 | Amber | Transfer | Change window written into the amended service schedule; file-based fallback feed designed and tested. | 23 May | 6 | Open |
| R-13 | Undocumented interfaces between tier-2 applications may only appear when a source system is switched off, causing an outage in a system not in that wave. | Technical | Integration lead | 3 | 4 | 12 | Amber | Reduce | Fourteen days of traffic capture on the source estate before each wave cut; results reviewed with application owners. | Each wave | 6 | Open |
| R-14 | Knowledge transfer to the run team may not complete before contractors roll off, leaving a support gap after the final wave. | Operational | Service transition lead | 3 | 4 | 12 | Amber | Reduce | Knowledge transfer plan per application with a named receiver; 10% of the contractor fee held until sign-off. | 27 Jun | 4 | Open |
| R-15 | Software licensed against physical cores may be re-priced when it moves to cloud instances. | Commercial | Vendor manager | 3 | 3 | 9 | Amber | Reduce | Licence position reviewed with each vendor before its wave; re-pricing exposure quantified per application. | 16 May | 6 | Open |
| R-16 | A late change to the finance year-end calendar would compress wave 3 into a shorter window. | Schedule | Programme manager | 2 | 3 | 6 | Green | Accept | Monitored monthly at the programme board; no action while the published calendar holds. | Monitor | 6 | Open |
Reading the example
- ID - a fixed reference that outlives any re-sorting of the register, and that a status report or minute can cite.
- Risk - written as a cause and an effect, in two sentences at most. R-01 names why the inventory is unreliable and what happens if it is. A register full of entries like "scope creep" is a list of worries; the cause is what tells you where the mitigation goes.
- Category - technical, commercial, operational, compliance and so on. It is worth the column because categories reveal clusters: five commercial and financial risks on this programme says something about the shape of the exposure that no individual row does.
- Owner - the person who can actually do something about it, which is often not the person who raised it. R-05 sits with records management rather than with the programme, because the decision it turns on is theirs.
- Probability and impact - a five-point scale with written definitions, so that a 4 means the same thing in April as in September. Impact is scored against the worst credible outcome, not the average one, which is why R-02 carries a 5 despite a moderate probability.
- Score and rating - the product and the derived colour. Both are calculated, never typed, so a risk cannot quietly go amber without one of the inputs changing. The threshold between amber and red is written down rather than negotiated per risk.
- Response - reduce, avoid, transfer or accept. Naming the type before the action stops everything defaulting to reduce. R-16 is accepted with monitoring, and saying so explicitly is more honest than inventing a mitigation nobody will do.
- Mitigating action - what is actually being done, specific enough that someone could tell you next month whether it happened. "Fourteen days of traffic capture before each wave cut" passes that test; "improve documentation" does not.
- Target date - when the action completes. Some are recurring, which is worth showing honestly as "each wave" rather than pretending a controls-based response has a single end date.
- Residual - the expected score once the action is done. This is the column most registers omit, and it is the one that shows whether the response is worth its cost. R-08 barely moves, which is the register admitting that the programme cannot do much about a contractual date.
- Status - open or closed. Closed risks stay visible; R-09 and R-11 are the record of two problems the programme dealt with rather than absorbed.
What the residual column reveals
Read the score and residual columns together and the register starts saying something a heatmap cannot. R-02 drops from 15 to 5, because a runbook and a parallel run genuinely remove most of the exposure. R-08 goes from 12 to 8, because a buffer and pre-negotiated terms soften a risk the programme fundamentally does not control. R-16 does not move at all, which is what accepting a risk looks like when it is stated honestly.
That comparison is also the argument for spending money. A response that costs three weeks of effort and moves the residual by one point is worth challenging. Without the residual column, every mitigation looks equally useful and the register becomes a list of good intentions.
How this differs from a RAID log
This register carries risks only, and carries them in more depth than a RAID log would: a five-point scale, a category, an explicit response type, a residual score. A RAID log on the same programme would hold a one-line version of each of these alongside its assumptions, issues and dependencies, at a level of detail suited to a weekly working session rather than a monthly board.
Programmes that run both usually treat the register as the authoritative source for risk and the RAID log as the weekly working view, with the register's red and amber entries reflected in it. Two separately maintained descriptions of the same risk is how a board ends up with a different impression of a programme than the delivery team has. The distinction is set out in RAID log versus risk register, and the fields themselves in the RAID log guide.
What this example leaves out
- Scoring definitions. The numbers here mean nothing without the scale behind them - what a 4 for impact is in money, time or reputation. That sits on a separate sheet and is agreed once, at the start.
- History. No row shows what it scored last month. Movement is often more informative than level, and a register that cannot show it relies on people remembering.
- Cost of response. Every mitigation here consumes effort or money that is not recorded, which makes it hard to argue that a response is disproportionate.
- Proximity. A risk that could materialise next week and one that could materialise in October score the same. Larger programmes add a proximity column and sort by it before a board.
- Opportunities. Formal risk management covers upside as well as downside. Most delivery registers, including this one, quietly ignore it.
- Escalation and appetite. Nothing here records which risks exceed the appetite the board has set, or which have been escalated and accepted at a higher level.
The register in presentable form, with the heatmap and escalation log that a committee expects, is the risk register template. If the weekly working view matters more than the board view, the RAID log template covers all four item types on one sheet, and the wave and application planning behind this example is in the cloud migration wave planner.
Questions
How should a risk be worded?
As a cause and an effect in one or two sentences: why the situation exists and what happens if it plays out. Single-word entries such as scope creep or resourcing are categories, and nothing can be mitigated against them.
What is the residual score for?
It shows the expected score once the planned response is complete, which is the only way to tell whether a mitigation is worth its cost. A response that moves the score by one point deserves challenging.
Should closed risks stay in the register?
Yes. Closed entries record what the programme dealt with and how, and they are the part of the register a lessons learned review actually reads.
Do I need both a risk register and a RAID log?
Many programmes run both: the register as the authoritative, deeper record of risk for a board, and the RAID log as the weekly working view covering risks, assumptions, issues and dependencies together. They should read from the same source.