Risk Register
Risk Register: {{PROJECT_NAME}}
Project: {{PROJECT_NAME}}
Version: {{VERSION}}
Date: {{DATE}}
Author: {{AUTHOR}}
Status: Draft | In Review | Approved
Reviewers: {{REVIEWERS}}
Document History
| Version |
Date |
Author |
Changes |
| 0.1 |
{{DATE}} |
{{AUTHOR}} |
Initial draft |
1. Risk Identification Methodology
Identification Methods Used:
Initial Risk Assessment Date: {{DATE}}
Next Scheduled Review: {{DATE}}
Risk Owner: {{RISK_OWNER}} (typically the Project Manager)
2. Risk Categories
| Category |
Description |
Common Examples |
| Technical |
Technology failures, integration issues, performance, security |
API changes, infrastructure limits, unknown complexity |
| Resource |
Team availability, skill gaps, capacity constraints |
Key person sick leave, agent performance degradation |
| Client |
Client-side decisions, availability, requirement volatility |
Delayed approvals, changing priorities, unclear requirements |
| External |
Third-party dependencies, regulatory changes, market shifts |
API deprecation, GDPR change, competitor launch |
| Financial |
Budget overruns, payment delays, cost estimates |
Underestimated effort, currency exposure, vendor price change |
| Timeline |
Schedule risks, deadline pressure, estimation errors |
Milestone slip, hard deadline, dependency delays |
| Quality |
Defect rate, technical debt, process failures |
Insufficient testing, rushed delivery, poor documentation |
| Organizational |
Internal politics, process changes, leadership decisions |
Reprioritization, team restructure, tool changes |
3. Risk Probability & Impact Scale
3.1 Probability Scale
| Level |
Score |
Definition |
Example |
| Very Low |
1 |
< 10% chance — rare, theoretical |
Unknown-unknown |
| Low |
2 |
10–30% chance — unlikely but possible |
Historical precedent rare |
| Medium |
3 |
30–50% chance — may occur |
Has happened on similar projects |
| High |
4 |
50–70% chance — likely to occur |
Happens regularly |
| Very High |
5 |
> 70% chance — almost certain |
Happened before on this type |
3.2 Impact Scale
| Level |
Score |
Schedule Impact |
Budget Impact |
Quality Impact |
| Negligible |
1 |
< 1 day |
< 1% |
Minor fix needed |
| Minor |
2 |
1–3 days |
1–5% |
Some rework needed |
| Moderate |
3 |
3–7 days |
5–10% |
Significant rework |
| Major |
4 |
1–2 weeks |
10–20% |
Deliverable at risk |
| Critical |
5 |
> 2 weeks |
> 20% |
Project failure risk |
3.3 Risk Matrix (Probability × Impact)
IMPACT →
1(Neg) 2(Min) 3(Mod) 4(Maj) 5(Crit)
P 5(VH) | 5 | 10 | 15 | 20 | 25 | ← CRITICAL ZONE (≥15)
R 4(H) | 4 | 8 | 12 | 16 | 20 |
O 3(M) | 3 | 6 | 9 | 12 | 15 |
B 2(L) | 2 | 4 | 6 | 8 | 10 | ← MEDIUM ZONE (5-14)
↑ 1(VL) | 1 | 2 | 3 | 4 | 5 | ← LOW ZONE (≤4)
| Score |
Risk Level |
Response Required |
Escalation |
| 1–4 |
LOW |
Monitor; review monthly |
PM awareness |
| 5–9 |
MEDIUM |
Active mitigation plan required |
PM + Tech Lead |
| 10–14 |
HIGH |
Immediate action + weekly review |
PM + John |
| 15–25 |
CRITICAL |
Emergency response; may stop project |
John + Alem |
4. Risk Appetite Statement
Overall Risk Appetite: {{LOW | MEDIUM | HIGH}}
| Risk Category |
Appetite |
Rationale |
| Technical |
Medium |
Innovation requires technical experimentation |
| Financial |
Low |
Budget is fixed; overruns require CEO approval |
| Quality |
Low |
Client satisfaction is core to ALAI brand |
| Timeline |
Medium |
Some schedule flexibility acceptable if quality maintained |
| Security |
Very Low |
Zero tolerance for data breaches or compliance violations |
| Regulatory |
Very Low |
Legal exposure is unacceptable |
Maximum Acceptable Risk Exposure: Score ≤ 9 without escalation to John.
Escalation Threshold: Any risk scoring ≥ 10 must be reported to John within 24 hours.
5. Active Risk Register
| ID |
Risk Description |
Category |
Prob (1-5) |
Impact (1-5) |
Score |
Response Strategy |
Owner |
Trigger Indicators |
Status |
Date Identified |
Review Date |
| R-001 |
{{RISK_DESCRIPTION}} |
Technical |
{{1-5}} |
{{1-5}} |
{{SCORE}} |
Mitigate |
{{OWNER}} |
{{TRIGGER}} |
Open |
{{DATE}} |
{{DATE}} |
| R-002 |
Key client contact unavailable for approvals |
Client |
3 |
4 |
12 |
Mitigate |
PM |
Slow email responses; missed meetings |
Open |
{{DATE}} |
{{DATE}} |
| R-003 |
Third-party API deprecates required endpoint |
External |
2 |
5 |
10 |
Mitigate |
Tech Lead |
Vendor changelog; API versioning notice |
Open |
{{DATE}} |
{{DATE}} |
| R-004 |
Scope creep from undiscovered requirements |
Client |
4 |
3 |
12 |
Mitigate |
BA/PM |
Frequent "small" change requests |
Open |
{{DATE}} |
{{DATE}} |
| R-005 |
Performance targets not met under load |
Technical |
3 |
4 |
12 |
Mitigate |
Tech Lead |
Slow response in dev testing |
Open |
{{DATE}} |
{{DATE}} |
| R-006 |
{{RISK_DESCRIPTION}} |
|
|
|
|
|
|
|
Open |
{{DATE}} |
{{DATE}} |
| R-007 |
|
|
|
|
|
|
|
|
Open |
|
|
| R-008 |
|
|
|
|
|
|
|
|
Open |
|
|
6. Risk Response Strategies
| Risk ID |
Strategy |
Response Actions |
Contingency Plan |
Resources Required |
| R-001 |
{{STRATEGY}} |
1. {{ACTION_1}}; 2. {{ACTION_2}} |
{{CONTINGENCY_IF_RISK_OCCURS}} |
{{RESOURCES}} |
| R-002 |
Mitigate |
1. Identify backup decision-maker; 2. Set approval deadlines in contract; 3. Async approval process |
Escalate to John → client sponsor |
PM time: 2h/week |
| R-003 |
Mitigate + Accept |
1. Abstract API calls behind service layer; 2. Monitor vendor changelog; 3. Build integration tests |
Switch to alternative vendor; allocate 3-day buffer |
Tech Lead: 1 day setup |
| R-004 |
Avoid + Mitigate |
1. Detailed BRD sign-off before development; 2. Formal change request process enforced; 3. Weekly scope review |
Raise change request; negotiate timeline/budget |
BA: 2h/week scope monitoring |
Response Strategy Definitions
| Strategy |
When to Use |
Action |
| Avoid |
High score + feasible to eliminate |
Change plan to remove the risk source |
| Mitigate |
Cannot avoid; must reduce probability or impact |
Implement controls, monitoring, early warning systems |
| Transfer |
Risk can be shared with third party |
Insurance, contractual liability transfer, outsourcing |
| Accept (Active) |
Low score; mitigation cost > risk cost |
Monitor and create contingency plan |
| Accept (Passive) |
Negligible score |
Acknowledge, no action required |
| Escalate |
Exceeds project authority or appetite |
Raise to John / Alem / client sponsor |
7. Risk Heat Map
quadrantChart
title Risk Heat Map — {{PROJECT_NAME}}
x-axis Low Impact --> High Impact
y-axis Low Probability --> High Probability
quadrant-1 "CRITICAL — Immediate Action"
quadrant-2 "HIGH — Active Management"
quadrant-3 "LOW — Monitor"
quadrant-4 "MEDIUM — Watch"
R-001: [0.7, 0.5]
R-002: [0.6, 0.5]
R-003: [0.8, 0.3]
R-004: [0.5, 0.7]
R-005: [0.7, 0.5]
Update coordinates as Probability/Impact scores change. X = Impact/5, Y = Probability/5.
8. Escalation Thresholds
| Threshold |
Action |
Responsible |
Timeframe |
| Any new risk Score ≥ 15 |
Immediate escalation to John + Alem |
PM |
Within 4 hours of identification |
| Any existing risk score increases by ≥ 5 |
Escalate to John |
PM |
Within 24 hours |
| > 3 risks at Score ≥ 10 simultaneously |
Emergency risk review meeting |
PM + John |
Within 48 hours |
| Any risk triggers its contingency plan |
Notify all stakeholders |
PM |
Immediately |
| Risk causes milestone slip > 3 days |
Formal change request + escalation |
PM |
Within 24 hours |
9. Risk Review Schedule
| Frequency |
Activity |
Participants |
Output |
| Weekly (Sprint Planning) |
Review all active risks, update scores/status |
PM, Tech Lead |
Updated register |
| Sprint Retrospective |
Identify new risks; close resolved risks |
Full team |
New risks added |
| Monthly |
Full risk register review + heat map update |
PM, John |
Risk report to stakeholders |
| Ad-hoc |
New risk identified (any time) |
Risk identifier + PM |
New risk logged within 24h |
| Milestone |
Risk review before each major milestone |
PM, Tech Lead, John |
Go/no-go input |
Review Log
| Date |
Reviewer |
Risks Reviewed |
New Risks Added |
Risks Closed |
Key Changes |
| {{DATE}} |
{{NAME}} |
{{COUNT}} |
{{COUNT}} |
{{COUNT}} |
{{SUMMARY}} |
10. Closed / Accepted Risks Archive
| ID |
Risk Description |
Resolution Type |
Resolution Notes |
Date Closed |
| R-999 |
Example: Third-party payment provider delays |
Mitigated |
Switched to backup provider; no impact |
{{DATE}} |
Approval
| Role |
Name |
Date |
Signature |
| Author |
|
|
|
| Reviewer |
|
|
|
| Project Manager |
|
|
|
| AI Director (John) |
|
|
|
| Project Sponsor |
|
|
|
