Risk management
A risk register is useful when it changes decisions. A register of generic risks that nobody reads is a compliance artefact, not a control.
Process
Identify → Assess (impact × likelihood) → Respond → Assign → Review → Close
Likelihood
| Level | Description | Probability | Score |
|---|---|---|---|
| 5 | Near certainty | 81–99% | 5 |
| 4 | Highly likely | 61–80% | 4 |
| 3 | Likely | 41–60% | 3 |
| 2 | Low likelihood | 21–40% | 2 |
| 1 | Not likely | 0–20% | 1 |
Impact
| Level | Description |
|---|---|
| 5 | Critical — outage, data loss, regulatory breach, project failure |
| 4 | Significant — major delay, material cost, customer-visible degradation |
| 3 | Moderate — delay to a milestone, rework, additional cost |
| 2 | Minor — inconvenience, contained rework |
| 1 | Negligible — no material effect |
Rating matrix
| Likelihood ↓ / Impact → | 1 Negligible | 2 Minor | 3 Moderate | 4 Significant | 5 Critical |
|---|---|---|---|---|---|
| 5 Near certainty | 5 Medium | 10 High | 15 Extreme | 20 Extreme | 25 Extreme |
| 4 Highly likely | 4 Low | 8 Medium | 12 High | 16 Extreme | 20 Extreme |
| 3 Likely | 3 Low | 6 Medium | 9 Medium | 12 High | 15 Extreme |
| 2 Low | 2 Low | 4 Low | 6 Medium | 8 Medium | 10 High |
| 1 Not likely | 1 Low | 2 Low | 3 Low | 4 Low | 5 Medium |
| Band | Score | Action |
|---|---|---|
| Low | 1–4 | Accept; monitor |
| Medium | 5–9 | Mitigate as low as reasonably practicable |
| High | 10–16 | Mitigate; named owner; reviewed weekly |
| Extreme | 17–25 | Escalate to sponsor; consider pausing the affected work |
Categories
| Category | Typical risks |
|---|---|
| Technical | Data loss during migration, incompatible legacy dependencies, performance shortfall |
| Schedule | Access delays, customer availability, procurement lead time |
| Scope | Undiscovered systems, requirements changing mid-delivery |
| Cost | Cloud spend above estimate, migration egress, unplanned licences |
| Security | Credential exposure, misconfiguration, insecure legacy components |
| Compliance | Data residency, audit evidence gaps, regulatory change |
| Organisational | Sponsor departure, resistance from an affected department, key-person dependency |
| Supplier | AWS service limits, third-party integration failure, vendor support |
Register
| ID | Risk | Category | Impact | Likelihood | Score | Response | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| R-01 | Data loss during migration | Technical | 4 | 3 | 12 High | Rehearsed migration, DMS with validation, pre-cutover snapshot | Data lead | Open |
| R-02 | Account access delayed | Schedule | 3 | 4 | 12 High | Access request raised in week 1; sponsor escalation path | PM | Open |
| R-03 | Cost exceeds estimate | Cost | 3 | 3 | 9 Medium | Monthly cost review; budget alarms; right-sizing checkpoint | Cloud lead | Open |
Responses
| Strategy | When |
|---|---|
| Avoid | Change the plan so the risk no longer exists |
| Reduce | Lower likelihood or impact through a control |
| Transfer | Move the consequence — insurance, contractual terms, vendor SLA |
| Accept | Acknowledge and monitor; appropriate for Low risks and where mitigation costs more than the exposure |
Every Medium or higher risk has a response, an owner and a date. "Monitor" is a response only for Low risks.
Review cadence
| Forum | Frequency | Content |
|---|---|---|
| Delivery stand-up | Weekly | New risks, changes to High risks, blockers |
| Risk review | Fortnightly | Full register; score changes; mitigation progress |
| Steering | Monthly | Extreme and High risks; escalations; acceptance decisions |
Risk to delivery, not just risk in delivery
The assessment also covers the risk of the transformation itself:
- Organisational resistance that delays adoption.
- A pilot that succeeds technically but does not generalise.
- A sponsor who leaves mid-programme.
- A security finding that pauses migration.
- A dependency on one engineer's knowledge.
These belong in the register alongside the technical risks. They are the ones most likely to affect the outcome.