management-risk-managementUse this skill when the user says 'risk management', 'risk register', 'risk assessment', 'risk mitigation', 'project risk', 'technical risk', 'risk matrix', 'risk analysis', 'probability impact', 'risk log'. Identify, assess, and plan responses for project and technical risks. Do NOT use for: security vulnerability scanning or compliance audits.
Independent GitHub snapshot · Automated classification · Original documentation governs
Identify, assess, and mitigate project and technical risks through a structured risk register. Calculates risk scores as probability times impact, assigns named owners, and tracks mitigation through regular review during sprint retrospectives.
Risk management is not about eliminating risk entirely — that is neither possible nor desirable. It is about making informed decisions under uncertainty by surfacing risks before they become emergencies. This skill provides a systematic five-step process: identify risks across all categories, categorize them for trend analysis, assess each with a probability and impact score, plan a specific response strategy for each, and review regularly. Every risk in the register has a score, a responsible owner, and a clear response plan. An empty risk register is not a sign of a low-risk project — it is a sign that risks have not been surfaced yet.
The maturity model for risk management is visible in the register itself. A startup may have three items tracked in someone's head. A mature team maintains 10-20 documented risks with scores, owners, and response plans reviewed every sprint. The goal is not to reach zero risks — that is impossible. The goal is to have every significant risk visible, quantified, and managed so the team makes conscious tradeoffs rather than being surprised by avoidable problems.
"risk management", "risk register", "risk assessment", "risk mitigation", "project risk", "technical risk", "risk matrix", "risk analysis", "probability impact", "risk log"
Risk register populated with at least 5-10 identified risks across multiple categories. Every risk has a calculated PxI score, a response strategy, and an assigned owner. The review cadence is defined. At least one contingency plan is pre-defined for a high-score risk.
2500 tokens
| Framework | Focus | Structure | Best For | Maturity |
|---|---|---|---|---|
| PMBOK Risk Management | Project risks | 6 processes (plan, identify, analyze, respond, monitor) | Traditional project management | High |
| ISO 31000 | Enterprise risk | Principles, framework, process | Organization-wide risk management | Very high |
| FAIR | Cyber risk quantification | Monte Carlo simulation, loss magnitude | Security risk quantification | Quantitative |
| OCTAVE | Information security | Asset-driven, organizational | Security risk assessment | Medium |
| NIST RMF | Risk management framework | 7 steps (prepare, categorize, select, implement, assess, authorize, monitor) | US government, compliance | Very high |
| Simple PxI (this skill) | Project + technical risks | Probability x Impact matrix | Agile teams, startups | Low - Medium |
What is the risk score (P x I)?
├── 15-25 (High)
│ ├── Can the risk be eliminated by changing the plan?
│ │ ├── Yes → Avoid (change approach, remove risky feature)
│ │ └── No → Can we reduce probability or impact?
│ │ ├── Yes → Mitigate (add redundancy, increase testing)
│ │ └── No → Can someone else handle it?
│ │ ├── Yes → Transfer (insurance, SLA-backed vendor)
│ │ └── No → Contingency (pre-define Plan B, monitor trigger)
├── 6-14 (Medium)
│ ├── Does mitigation cost less than expected impact?
│ │ ├── Yes → Mitigate
│ │ └── No → Accept + monitor at sprint retro
└── 1-5 (Low)
└── Accept (log and review quarterly)
| Category | Description | Examples |
|---|---|---|
| Technical | Technology, architecture, implementation | Tech debt slowing velocity, performance degradation, security vulns |
| Schedule | Timeline, milestones, delivery | Aggressive estimates, dependency delays, scope creep |
| Resource | People, budget, tools | Team member unavailability, skill gaps, key person dependency |
| External | Vendors, market, regulations | API deprecation, framework abandonment, new regulations |
| Operational | Process, deployment, incidents | Deployment failures, missing monitoring, backup gaps |
| Strategic | Direction, alignment, competition | Wrong prioritization, competitor moves, market shifts |
| Level | Stage | Characteristics | Register Size |
|---|---|---|---|
| 1 | Ad-hoc | Risks in someone's head, reactive | 0-3 undocumented |
| 2 | Aware | Basic register exists, not regularly reviewed | 3-7 documented |
| 3 | Managed | Register reviewed at sprint retro, owners assigned | 8-15 tracked |
| 4 | Measured | Risk burndown tracked, trends analyzed, quantified | 10-20 active |
| 5 | Optimizing | Predictive risk modeling, automated triggers, continuous monitoring | 15-25 active |
Conduct structured brainstorming across all risk categories. Technical: tech debt accumulation slowing feature velocity, performance degradation under load, security vulnerabilities in dependencies, architectural decisions that limit future options, data loss scenarios, single points of failure in the system. Schedule: aggressive timeline estimates, external dependency delays, resource availability gaps at critical milestones, scope creep from unclear requirements, cascading delays on the critical path. Resource: team member unavailability (vacation, sick leave, turnover), key person dependency (only one person knows X), skill gaps for new technology adoption, burnout risk from sustained high velocity. External: vendor API deprecation or breaking changes, ecosystem shifts (framework deprecation, library abandonment), market changes that reduce demand, partner delays or failures. Compliance: new regulations affecting data handling, audit findings with remediation deadlines, privacy requirements changes, accessibility mandates. Operational: deployment failures, missing monitoring, insufficient incident response runbooks, backup and restore gaps.
Tag each risk with exactly one primary category for consistent filtering and trend analysis. Standard categories: technical-debt, third-party-dependency, team-capacity, timeline-pressure, scope-creep, security-vulnerability, compliance, operational, market-risk. Consistent categorization enables the team to run reports like "show all third-party risks" or "what is the total risk score for security items."
For each risk, assign two numerical values. Probability (P): 1 = rare (<10% chance), 2 = unlikely (10-25%), 3 = possible (25-50%), 4 = likely (50-90%), 5 = almost certain (>90%). Impact (I): 1 = negligible (minor inconvenience, no schedule effect), 2 = minor (small delay <1 week, easily recoverable), 3 = moderate (1-2 week delay, budget impact), 4 = major (2-4 week delay, feature may be cut), 5 = critical (project-threatening, >1 month delay, significant cost overrun). Calculate risk score = P x I (range 1-25). Map to priority: High = 15-25 (immediate response plan and active monitoring), Medium = 6-14 (assign owner, monitor at sprint retro), Low = 1-5 (log and accept, review quarterly).
For every risk, select and document one of five response strategies. Avoid: change the project plan to eliminate the risk entirely — remove the risky feature, use a different technology, reschedule to avoid the conflict. Mitigate: take action to reduce the probability or impact — add redundancy, increase test coverage, implement feature flags for quick rollback, cross-train team members to reduce key person risk. Transfer: shift the risk to a third party who is better equipped to handle it — purchase insurance, use an SLA-backed vendor, outsource a high-risk component, use a managed service instead of self-hosting. Accept: document the risk and its score, monitor it regularly, but take no active mitigation — appropriate for low-score risks or risks where mitigation costs more than the expected impact. Contingency: pre-define a Plan B that triggers automatically if the risk materializes — rollback plan, fallback vendor, manual override process, incident response runbook.
Review the entire risk register at every sprint retrospective. Each risk owner reports the current status: increased (probability or impact has gone up), stable (no change), decreased (probability or impact has gone down), materialized (the risk has happened — execute contingency), or closed (risk is no longer relevant). Add new risks as they are discovered during the sprint. Move materialized risks into contingency execution mode with tracking. Archive closed risks with a closure note explaining why they are no longer relevant. Track the risk burndown: the sum of all risk scores over time should trend downward as mitigation actions take effect.
For high-score risks, perform quantitative analysis: estimate the expected monetary value (probability x estimated cost impact), run Monte Carlo simulation for schedule impact (use 3-point estimates for task durations), calculate contingency reserves (budget buffer based on risk exposure), determine the critical path risk (which risks affect the critical path most). Document confidence levels for completion dates. Update quantitative analysis after each risk review.
Not all risks are threats. An opportunity is a risk with positive impact. Identify opportunities alongside threats: early vendor delivery, faster-than-expected adoption, technology breakthrough, team productivity gains. For each opportunity: assign probability and positive impact score, plan response — exploit (make it happen), enhance (increase probability or impact), share (partner to capture upside), or accept (benefit if it occurs). Track opportunities in the same register as threats but with positive impact scores.
Tailor risk communication to audience: executives need top 5 risks with business impact and mitigation status (one-page summary), project team needs full register with action items and owners, stakeholders need risk profile changes since last update. Use RAG status for quick visualization. Highlight new risks, closed risks, and score changes. Escalate critical risks (score 15+) immediately, not at next review.
At sprint planning: review top 5 risks and adjust sprint scope if needed, allocate capacity for risk mitigation tasks, ensure risk owners are assigned to sprint. At quarterly planning: reassess all risks against new scope, adjust risk scores based on progress, add new risks identified in the quarter, update contingency plans. At project milestones: conduct formal risk reassessment with stakeholders, validate risk response effectiveness, close risks that are no longer relevant.
After project completion or major milestone: review the entire risk management process, evaluate accuracy of probability and impact estimates, identify risks that were missed (should have been identified), assess effectiveness of response strategies, document lessons learned for future projects. Update risk identification checklist based on lessons learned.
| Probability Down Arrow | Impact 1 | Impact 2 | Impact 3 | Impact 4 | Impact 5 |
|---|---|---|---|---|---|
| 5 (Almost Certain) | 5 Low | 10 Medium | 15 High | 20 High | 25 High |
| 4 (Likely) | 4 Low | 8 Medium | 12 Medium | 16 High | 20 High |
| 3 (Possible) | 3 Low | 6 Medium | 9 Medium | 12 Medium | 15 High |
| 2 (Unlikely) | 2 Low | 4 Low | 6 Medium | 8 Medium | 10 Medium |
| 1 (Rare) | 1 Low | 2 Low | 3 Low | 4 Low | 5 Low |
| Condition | Recommended Strategy |
|---|---|
| Risk can be eliminated by changing the plan | Avoid |
| Probability or impact can be reduced | Mitigate |
| A third party can handle it better | Transfer |
| Low score, mitigation costs more than impact | Accept |
| Can't reduce but can prepare | Contingency |
| Metric | Formula | Target |
|---|---|---|
| Total Risk Exposure | Sum of (P x I) for all risks | Decreasing trend |
| Risk Density | Active risks / total risks tracked | < 30% high risks |
| Mitigation Velocity | Closed risks per sprint | > 2 per sprint |
| Time to Escalation | Days from risk identified to score > 10 | < 7 days |
| Risk Identification Lag | Days from risk emerging to register entry | < 3 days |
| Concept | Definition | Example |
|---|---|---|
| Risk Appetite | Amount of risk the organization is willing to accept | "We accept moderate schedule risk for innovation features" |
| Risk Tolerance | Specific acceptable variation from targets | "Schedule delay up to 2 weeks is acceptable; more requires escalation" |
| Risk Threshold | Point at which risk requires action | "Any risk scoring > 15 triggers immediate mitigation plan" |
A completely clean risk register is not a sign of low risk — it is a sign that risks have not been surfaced. Every project has risks. An empty register means no one is looking.
Creating a risk register at project start and never updating it. Fix: review at every sprint retro. Risk status must be updated at least monthly.
Assigning high scores but no response plan. Fix: every risk with a score > 6 must have a named response strategy and owner.
Using the same probability/impact criteria for different risk types. Fix: tailor impact criteria to each category (schedule impact = delay, technical impact = performance degradation, financial impact = cost overrun).
Risks with P=1, I=5 (score 5, low) can still destroy a project. Fix: classify risks by both score and impact level. High-impact risks need contingency plans regardless of score.
Only tracking threats and missing positive risks. Fix: explicitly ask "what could go better than expected?" during identification.
Assigning ownership without the authority to implement mitigation. Fix: risk owners must have the resources and decision rights to act.
"Monitor the situation" is not a mitigation plan. Fix: every mitigation must have specific, actionable steps with deadlines.
Treating P and I estimates as precise when they are guesses. Fix: use ranges instead of single values. Document confidence level for each estimate.
Risks that are no longer relevant remain in the register as noise. Fix: review and close risks that have passed their window of relevance.
| Approach | Strengths | Weaknesses |
|---|---|---|
| Simple P x I Matrix (this skill) | Fast, intuitive, low overhead | Subjective, no quantification |
| Expected Monetary Value | Financial quantification, supports ROI | Requires cost estimates for all impacts |
| Monte Carlo Simulation | Handles uncertainty, provides confidence intervals | Complex, requires tools |
| Decision Tree Analysis | Explicit choices, visual | Limited to sequential decisions |
| Scenario Analysis | Captures extreme outcomes | Few discrete scenarios |
| Bow Tie Analysis | Visual cause-consequence | Complex for multiple risks |
| ID | Category | Description | P | I | Score | Priority | Response | Owner | Status |
|---|---|---|---|---|---|---|---|---|---|
| R-001 | Technical | Database migration may cause data loss | 2 | 5 | 10 | Medium | Mitigate: test migration on full copy | DB lead | Active |
| R-002 | Schedule | Vendor API delivery may slip 2 weeks | 4 | 3 | 12 | Medium | Contingency: mock API ready by week 4 | PM | Active |
## Top 5 Risks — {project} — {date}
Risk Score Trend: {up/stable/down} — Total Exposure: {n}
1. {risk} — Score {n} — {P}x{I} — {status} — {mitigation status}
2. {risk} — Score {n} — {P}x{I} — {status} — {mitigation status}
3. {risk} — Score {n} — {P}x{I} — {status} — {mitigation status}
4. {risk} — Score {n} — {P}x{I} — {status} — {mitigation status}
5. {risk} — Score {n} — {P}x{I} — {status} — {mitigation status}
New this period: {n} | Closed: {n} | Escalated: {n}
Risk: {name}
Trigger Condition: {specific, measurable event that triggers Plan B}
Trigger Threshold: {warning level before trigger activates}
Plan B Steps:
1. {action} — Owner: {name} — Timeline: {deadline}
2. {action} — Owner: {name} — Timeline: {deadline}
Activation Authority: {who decides to execute contingency}
Success Criteria: {how to confirm Plan B worked}
Fallback from Fallback: {what if Plan B also fails}
A SaaS team building on a third-party API identified the risk "Vendor API deprecation with 30-day notice" scoring P=3, I=4 (score 12). They mitigated by building an abstraction layer that could swap to a second provider. When the vendor announced deprecation with only 14 days notice, the team switched providers in 10 days with no customer impact. Cost of mitigation: 2 weeks engineering. Cost avoided: 3 months of rework + customer churn.
A fintech startup ignored regulatory risk until mid-project, when new KYC requirements added 6 weeks of work and delayed launch. Post-mortem: the risk was identifiable from the start (P=4, I=5, score 20) but was not tracked because no formal risk register existed. Fix: implemented risk register with mandatory regulatory review at project initiation.
| Category | Example | Typical P | Typical I | Response |
|---|---|---|---|---|
| Technical | Core library deprecation EOL next quarter | High | High | Mitigate: upgrade before EOL |
| Technical | CI pipeline outage during release | Medium | High | Mitigate: redundant CI runners |
| Schedule | Key dependency delayed by 2 sprints | Medium | High | Mitigate: buffer allocation |
| Resource | Team member departure mid-project | Low | Critical | Accept: document knowledge |
| Budget | Cloud cost overrun from unexpected usage | Medium | Medium | Mitigate: cost alerts + budget |
| Requirements | Scope creep from ambiguous requirements | High | Medium | Avoid: strict definition of ready |
| External | Regulatory change affecting data handling | Low | Critical | Transfer: legal review + insurance |
| External | Vendor goes out of business | Low | High | Mitigate: vendor diversification |
| Organizational | Reorg changes team composition | Medium | Medium | Accept: knowledge transfer plan |
| Security | Data breach from unpatched vulnerability | Medium | Critical | Mitigate: patch SLA + WAF |
| Impact ↓ \ Probability → | 1 Rare | 2 Unlikely | 3 Possible | 4 Likely | 5 Almost Certain |
|---|---|---|---|---|---|
| 5 Critical | Medium | High | High | Critical | Critical |
| 4 Major | Medium | Medium | High | High | Critical |
| 3 Moderate | Low | Medium | Medium | High | High |
| 2 Minor | Low | Low | Medium | Medium | High |
| 1 Negligible | Low | Low | Low | Medium | Medium |
| Score | Label | Required Action | Review Cadence | Authority |
|---|---|---|---|---|
| 1-4 | Low | Accept, monitor | Quarterly | Team lead |
| 5-9 | Medium | Active mitigation plan | Monthly | Team lead |
| 10-14 | High | Detailed response plan | Bi-weekly | Program manager |
| 15-19 | Critical | Escalated to steering | Weekly | Steering committee |
| 20-25 | Unacceptable | Immediate escalation | Daily | Executive sponsor |
Risk ID: R-{nnn}
Date Identified: {date}
Identified By: {name}
Description:
{Clear, specific statement of the risk}
Category:
{Technical | Schedule | Resource | Budget | Requirements | External | Organizational | Security}
Causes:
- {Root cause or trigger condition 1}
- {Root cause or trigger condition 2}
Consequences:
- {Negative outcome if risk occurs}
- {Secondary effects}
Probability: {1-5 | Low to Almost Certain}
Impact: {1-5 | Negligible to Critical}
Risk Score: P × I = {score}
Response Strategy: {Avoid | Mitigate | Transfer | Accept}
Response Plan:
- {Action 1 with owner}
- {Action 2 with owner}
- {Action 3 with owner}
Contingency Plan (if risk materializes):
- {Step 1 with owner}
- {Step 2 with owner}
Trigger Condition:
{What event indicates the risk has occurred and contingency should activate}
Residual Risk Score (after mitigation): P × I = {score}
Owner: {name}
Status: {Open | Mitigating | Monitoring | Closed | Realized}
Review Date: {date}
Eliminate the risk by changing the plan.
Example: If a third-party API is unstable, avoid by building an in-house alternative.
Trade-off: May cost more time/money upfront.
When to use: When probability or impact is too high to accept.
Reduce probability or impact.
Example: If data loss risk during migration, mitigate by running parallel systems.
Probability reduction: Add validation, testing, redundancy.
Impact reduction: Limit blast radius, prepare rollback.
When to use: When probability and/or impact can be meaningfully reduced.
Shift risk to another party.
Example: Cyber insurance for security incidents. Fixed-price contract for vendor delivery.
Does NOT eliminate the risk — transfers financial/consequence impact.
When to use: When another party can better manage the risk.
Acknowledge the risk and proceed without mitigation.
Passive acceptance: Monitor without action.
Active acceptance: Set aside contingency budget/time.
When to use: When cost of mitigation exceeds expected impact, or when risk is low.
| Strategy | Description | Example |
|---|---|---|
| Exploit | Make it happen | Accelerate delivery if early customer interest is high |
| Enhance | Increase probability/impact | Add more resources to capture unexpected market demand |
| Share | Partner to capture opportunity | Co-invest with another team for shared benefit |
| Accept | Take advantage if it occurs | If regulatory changes favor us, fast-track expansion |
EMV = P(risk) × Impact($) + P(opportunity) × Impact($)
Example:
Risk: API vendor price increase of $50k with 40% probability
EMV (risk) = 0.4 × (-$50k) = -$20k
Opportunity: Early vendor discount of $20k with 30% probability
EMV (opportunity) = 0.3 × $20k = $6k
Net EMV = -$20k + $6k = -$14k
Application:
- Use EMV for budget contingency calculation
- Sum EMV across all identified risks for total contingency
- Confidence level: P50, P80, P90 for different risk tolerances
Sprint | Risk Count | Total Score | Critical Count | Mitigated This Sprint | New This Sprint
Sprint 1 | 15 | 62 | 3 | — | —
Sprint 2 | 14 | 54 | 2 | 2 | 1
Sprint 3 | 12 | 41 | 1 | 3 | 1
Sprint 4 | 10 | 35 | 1 | 2 | 0
Sprint 5 | 9 | 28 | 0 | 1 | 0
Goal: Trend toward 0 on total score and critical count by delivery date.
Meeting: Risk Review #{n}
Date: {date} | Duration: 30 min
Agenda:
1. New risks since last review (5 min)
- Present new risks, assign preliminary score and owner
2. Existing risks status update (10 min)
- Walk through open risks; review mitigation progress
3. Risk score changes (5 min)
- Update P and I as conditions change
4. Risk burndown review (5 min)
- Dashboard: trend lines for total score, critical count
5. Top 3 risks deep dive (5 min)
- Focused discussion on highest-scored active risks
6. Action items and owners (5 min)
Decision log:
- {n} risks accepted
- {n} risks closed
- {n} new actions assigned
sprint-retro (the risk register is reviewed at every sprint retro), create-roadmap (risk scores inform timeline adjustments and buffer allocation on the roadmap).
| Decision Point | Option A | Option B | Decision Criteria |
|---|---|---|---|
| Risk severity | Accept (cost to fix > impact) | Mitigate (cost to fix < impact) | Budget, risk appetite, compliance |
| Risk ownership | Assign to risk owner (accountable) | Transfer (insurance/outsource) | Expertise, financial capacity |
| Monitoring frequency | Continuous (automated dashboards) | Periodic (quarterly review) | Risk volatility, regulatory requirements |
`markdown
| ID | Risk Description | Category | Probability | Impact | RPN | Owner | Response | Status |
|---|---|---|---|---|---|---|---|---|
| R-001 | Key developer leaving | Resource | 4/5 | 5/5 | 20 | @tech-lead | Mitigate - cross-train | Active |
| R-002 | Vendor bankruptcy | External | 2/5 | 4/5 | 8 | @procurement | Transfer - escrow contract | Monitoring |
| R-003 | Data breach | Security | 3/5 | 5/5 | 15 | @cso | Mitigate - security audit | Active |
| R-004 | Schedule delay | Project | 4/5 | 3/5 | 12 | @pm | Accept - buffer in timeline | Active |
| ` |
`markdown
| Anti-Pattern | Symptom | Solution |
|---|---|---|
| Risk register as shelfware | Register created, never consulted | Review risks in every sprint planning/retro |
| Everything is high priority | No useful prioritization | Force ranking with relative scoring, not absolute |
| Ignoring positive risks | Missed opportunities | Include opportunity register alongside threat register |
| Risk owner doesn't know | Assigned without consent | Obtain explicit acceptance from risk owners |
| Probability blindness | 50/50 bias in scoring | Use reference classes, historical data for calibration |