Making Risk Visible and Trackable
A risk register is a structured document — often a spreadsheet or table — that catalogs every identified risk, its likelihood, its impact, its current mitigation status, and who owns it. Think of it as an inventory: you cannot manage what you have not written down.
Without a risk register, risk knowledge lives in individual engineers' heads. When those engineers go on vacation, change teams, or leave the company, the knowledge evaporates. A risk register makes institutional knowledge explicit and actionable.
A minimal risk register has these columns:
| ID | Risk Description | Likelihood | Impact | Risk Score | Current Mitigation | Mitigation Gap | Owner | Last Reviewed |
|---|---|---|---|---|---|---|---|---|
| R-001 | Primary DB disk fills up | High (monthly) | Medium ($5K) | High | Disk usage alert at 80% | No auto-scaling, no runbook | @alice | 2024-01-15 |
| R-002 | Payment provider API outage | Medium (quarterly) | High ($50K/hr) | Critical | Circuit breaker in place | No fallback provider, no cached auth | @bob | 2024-02-01 |
| R-003 | Single engineer knows deploy process | High (always true) | High ($20K) | Critical | Partial documentation exists | No cross-training, no automated pipeline | @carol | 2023-11-20 |
| R-004 | Region-wide cloud outage | Low (yearly) | Catastrophic ($500K) | High | Daily backups to second region | No automated failover, RTO untested | @dave | 2024-01-30 |
How to build one:
- Brainstorm risks across categories: infrastructure, dependencies, security, people (bus factor), process, and compliance.
- Score each risk using your likelihood × impact formula. Use consistent scales — for example, 1–5 for each axis, giving scores from 1–25.
- Document current mitigations — what is already in place to reduce this risk?
- Identify mitigation gaps — what is not in place that should be?
- Assign owners — a risk without an owner is a risk nobody will fix.
- Review regularly — a risk register last updated 18 months ago is worse than no register at all, because it creates false confidence.
Review cadence matters. Most teams review their risk register monthly or quarterly. Trigger an ad-hoc review after any significant incident, architecture change, or new dependency introduction.
Key Point: The most valuable column in a risk register is "Last Reviewed." A stale risk register is dangerous — it gives the illusion of preparedness while the actual risk landscape has shifted. Tie risk register reviews to your sprint retrospectives or architecture review meetings so they become habitual rather than aspirational.