Risk Register Template¶
Use this format for the risk register in remediation plans.
Risk Table Format¶
| Risk | Impact | Likelihood | Mitigation |
|---|---|---|---|
| Short description of what could go wrong | What breaks if the risk materialises | Low / Medium / High | Concrete action to prevent or respond |
Writing Rules¶
- Risk — State the specific failure scenario, not a vague category. "Python 3.14 base image has unpatched CVE blocking deployment" is better than "Version compatibility issues".
- Impact — State what breaks in operational terms. "Docker build fails" or "Auth tokens rejected in production" or "Event replay produces different state on PostgreSQL vs SQLite".
- Likelihood — Base on evidence, not anxiety. If the team has done this before successfully, it's Low. If there's no precedent, it's Medium. If there's a known blocker, it's High.
- Mitigation — Must be actionable. "Monitor" is not a mitigation. "Run parity tests comparing output across both backends before cutover" is a mitigation.
Common Risk Categories¶
Technology Risks¶
- Runtime or framework version incompatibility
- Platform-specific build failures (OS, architecture, Docker)
- Library deprecation or breaking changes during migration
- Performance regression after architecture change
Integration Risks¶
- Auth provider configuration mismatch (token validation, role mapping)
- Database schema or serialisation differences across backends
- Network connectivity issues (VNet, private endpoints, DNS resolution)
- API contract drift between service and consumers
Operational Risks¶
- Team unfamiliarity with new stack (operational handover gap)
- Missing runbooks for failure modes unique to the new architecture
- Monitoring blind spots during migration (old metrics don't apply, new ones not yet wired)
- Rollback complexity (can we actually go back if something fails?)
Process Risks¶
- External approvals blocking progress (security review, change advisory board)
- Decision paralysis on key choices (platform, database, auth model)
- Scope creep during remediation (fixing things that aren't in the gap analysis)
- Vendored code divergence from upstream (if applicable)
Risk Count Guidelines¶
- Small plans (3–5 phases): 4–6 risks
- Medium plans (5–8 phases): 6–10 risks
- Large plans (8+ phases): 8–12 risks
If you have more than 12 risks, consolidate related items. If you have fewer than 4, you're probably missing something — revisit the dependency map and decision list.