Assumptions note
This register is shared as a sample portfolio artifact. The risk set, scoring, and roles are illustrative and meant to show structure.
Risk assessment approach
Risks are scored using a simple matrix: Impact (1–5) × Likelihood (1–5). The goal isn’t to predict perfectly — it’s to create visibility early enough to act.
Sample risk register
RAG logic used here: Score = Impact × Likelihood. Red ≥ 16, Amber 9–15, Green ≤ 8.
RED
AMBER
GREEN
| ID | Risk | Category | Impact | Likelihood | Score | RAG | Mitigation (prevention) | Contingency (if it happens) | Owner | Status |
|---|---|---|---|---|---|---|---|---|---|---|
| R01 | Security incident exposes citizen personal information | Security | 5 | 2 | 10 | AMBER | Encryption, threat modelling, security testing, training, incident readiness | Lockdown, forensics, notifications, regulatory reporting, remediation sprint | Security Lead | Active |
| R02 | Low adoption post-launch | Adoption | 4 | 3 | 12 | AMBER | User research, guided onboarding, beta cohort, clear value messaging | Targeted campaigns, rapid iteration, extra support, channel partnerships | Change Lead | Active |
| R03 | Integration failures with legacy departmental systems | Technical | 4 | 3 | 12 | AMBER | Early discovery, sandbox testing, clear API contracts, weekly tech sync | Phased integration, temporary manual fallback, escalation path, re-plan | Solutions Architect | Monitor |
| R04 | Privacy/compliance changes require redesign | Compliance | 4 | 2 | 8 | GREEN | DPIA, privacy-by-design, data minimisation, retention policy agreed early | Compliance-first remediation sprint; adjust launch scope if needed | Privacy Lead | Active |
| R05 | Accessibility requirements not met (WCAG 2.1 AA) | Compliance | 3 | 2 | 6 | GREEN | Accessibility built into design; automated checks; external audit planned | Remediation sprint; delay release if mandatory fixes are not complete | UX Lead | Active |
| R06 | Performance degradation during high-load public launch | Technical | 3 | 3 | 9 | AMBER | Load testing, autoscaling, monitoring, phased rollout approach | Emergency scale-up; throttle non-critical features; extended support window | Infrastructure Lead | Active |
| R07 | Budget overrun due to scope creep / underestimated complexity | Financial | 3 | 3 | 9 | AMBER | Change control, strict MVP must-haves, monthly forecast vs actual | Descope lower priority items; move features to Phase 2; request funding | Delivery Lead | Active |
| R08 | Key role attrition during critical phases | Resource | 3 | 2 | 6 | GREEN | Cross-training, documentation, pairing, succession plan for key roles | Rapid backfill; contractor support; re-sequence work to protect milestones | Delivery Lead | Monitor |
| R09 | Vendor delivery delays or quality issues | Vendor | 3 | 2 | 6 | GREEN | Clear milestones, quality gates, frequent check-ins, acceptance criteria | Escalate; add support; swap vendor path; adjust plan and scope | Procurement Lead | Monitor |
| R10 | Policy / priority changes affect scope or funding | External | 4 | 1 | 4 | GREEN | Strong benefits narrative; measurable outcomes; leadership comms rhythm | Protect MVP; phase rollout; rebaseline scope; secure alternate sponsorship | Programme Sponsor | Monitor |
Review cadence
- Weekly RAID review for delivery-level risks and dependencies.
- Escalation to programme board for red risks or material delivery impact.
- Every risk has an owner and a next action — not just a description.