Wardn HubTrusted MCP server directory.

Registry

  • MCP Servers
  • Skills
  • Categories

Resources

  • API docs
  • Score method

Contribute

  • Submit server
  • Advertise
© 2026 Wardn Hub
Wardn Hub
MCP ServersSkillsCategoriesAPI docsSubmit server
Submit server
skills/mohitagw15856/pm-claude-skills/risk-register

risk-register

1
mohitagw15856/pm-claude-skills·Audit passed·Snapshot ee4a737a7bae

Summary

This source did not publish a separate summary. Review SKILL.md before using the skill.

SKILL.md

Risk Register Skill

This skill produces a complete risk register for a project, programme, or product. Output follows standard risk management practice with likelihood × impact scoring, RAG status, a risk heat map, and specific mitigation and contingency plans. Ready to share with a project board, steering committee, or programme office.

Required Inputs

Ask the user for these if not provided:

  • Project or product name
  • Project stage (discovery / delivery / launch / live / programme-level)
  • Key objectives — what is the project trying to achieve?
  • Known risks — anything already on the team's radar (even informal concerns count)
  • Key dependencies — external vendors, teams, systems, or regulatory approvals
  • Deadline or milestone sensitivity — are there hard dates that cannot move?
  • Audience — who will read this? (internal team / executive steering / external board / regulator)

Output Structure

Risk Register: [Project / Product Name]

Project stage: [Discovery / Delivery / Launch / Live / Programme] Version: [1.0] Owner: [PM / Programme Manager / Risk Lead] Last reviewed: [Date] Next review: [Date — recommend weekly during delivery, monthly during discovery] Status: [Active / Archived]

1. Risk Scoring Framework

Likelihood (L)

ScoreLabelDefinition
5Almost certain>80% probability of occurring
4Likely60–80% probability
3Possible40–60% probability
2Unlikely20–40% probability
1Rare
<20% probability

Impact (I)

ScoreLabelDefinition
5CriticalProgramme failure, regulatory breach, major financial loss, safety event
4HighSignificant schedule delay (>4 weeks), scope reduction, reputational damage
3MediumModerate delay (1–4 weeks), cost overrun, reduced quality
2LowMinor delay (<1 week), manageable cost increase
1NegligibleMinimal impact, easily absorbed

Risk Score = L × I

ScoreRAGAction
20–25🔴 CriticalImmediate escalation; active management required
12–19🔴 HighOwner-assigned mitigation; weekly review
8–11🟡 MediumMitigation planned; fortnightly review
4–7🟡 LowMonitor; monthly review
1–3🟢 NegligibleAccept; review if context changes

2. Risk Register

IDRiskCategoryLIScoreRAGOwnerStatusMitigationContingencyReview date
R01[Risk description — be specific: "Third-party API may not support required volume, causing X to fail"][Schedule / Technical / Resource / Commercial / Compliance / External][1–5][1–5][L×I]🔴/🟡/🟢[Name][Open / Mitigating / Closed][What are we doing to reduce likelihood or impact?][What do we do if it happens?][Date]
R02[...][...][...][...][...][...][...][...][...][...][...]

3. Risk Categories — Common Risks by Type

Use these to prompt risk identification. Add, remove, or customise for your project.

Schedule & Delivery

  • Key milestone depends on a dependency that has not confirmed availability
  • Team capacity reduced by planned or unplanned absence during critical period
  • Technical complexity is underestimated — story points consistently overrun
  • External approval (regulator, legal, procurement) takes longer than planned

Technical

  • Integration with a third-party system not yet prototyped or agreed
  • Existing technical debt makes the change harder or riskier than estimated
  • Security or compliance review required before launch has not been scoped
  • Performance under production load untested
  • Key technical knowledge held by one person (single point of failure)

Resource & People

  • Key SME or engineer leaving or unavailable during critical phase
  • Budget not confirmed for Phase 2 of the project
  • Stakeholder sponsor changes role or leaves the organisation
  • Team not yet at full capacity (hiring lag, access issues, onboarding time)

Commercial & Financial

  • Vendor or partner contract not yet signed
  • Cost estimate based on assumptions that have not been validated
  • Revenue or savings case depends on assumptions outside the team's control
  • Currency exposure or exchange rate risk for international projects

Compliance & Regulatory

  • Data privacy impact assessment (DPIA) not yet complete
  • Regulatory approval required and timeline is uncertain
  • GDPR, HIPAA, SOC 2, or sector-specific compliance requirement not yet mapped
  • Legal review of terms of service or contracts pending

Stakeholder & Adoption

  • Key user group has low awareness or motivation to adopt the change
  • Internal resistance from a team that will be affected by the change
  • Executive sponsor not consistently engaged — decisions are slow
  • Communications plan not yet agreed with change management team

External

  • Market or competitive change could undermine the business case
  • Macroeconomic conditions affect budget or priority
  • Supplier or infrastructure provider risk (e.g. cloud provider, hardware)
  • Geopolitical or regulatory environment change

4. Risk Heat Map

Plot risks by likelihood (Y axis) and impact (X axis):

         │  Low     Medium    High    Critical
         │  (1)      (2-3)    (4)      (5)
─────────┼────────────────────────────────────
Almost   │  🟡        🟡       🔴       🔴
certain  │
(5)      │
─────────┼────────────────────────────────────
Likely   │  🟡        🟡       🔴       🔴
(4)      │
─────────┼────────────────────────────────────
Possible │  🟢        🟡       🟡       🔴
(3)      │
─────────┼────────────────────────────────────
Unlikely │  🟢        🟢       🟡       🟡
(2)      │
─────────┼────────────────────────────────────
Rare     │  🟢        🟢       🟢       🟡
(1)      │

[Plot each risk ID on this grid — e.g. R01 lands at L4/I5 = 🔴 Critical]

5. Top Risks — Executive Summary

For steering committee or board-level reporting:

RankRiskScoreRAGOwnerMitigation status
1[Most critical risk — plain English description][X]🔴[Owner][Active / Planned / Not started]
2[...][...]🔴[...][...]
3[...][...]🟡[...][...]
4[...][...]🟡[...][...]
5[...][...]🟡[...][...]

Decisions required from steering:

  • [Any risk that requires budget, scope, or timeline decision to mitigate]

6. Risk Changes Since Last Review

Risk IDChangeDetail
[R03]Score increased[L moved from 2 → 4 — vendor confirmed delay in API availability]
[R07]Risk closed[Legal sign-off received on 12 May]
[NEW]New risk identified[R09 — budget freeze announcement affects Phase 2 funding]

7. Risk Closure Criteria

A risk is closed when:

  • The risk event can no longer occur (e.g. milestone passed, contract signed), OR
  • The residual risk score drops to Negligible (1–3) AND the team formally accepts it, OR
  • The risk has materialised and transitioned to an issue (tracked separately)

Issues log: [Link to issues log — risks that have materialised and are now active problems being managed]

Quality Checks

  • Every risk has a specific owner — not "the team" or "TBD"
  • Mitigations describe what is actively being done — not "monitor and review"
  • Contingency plans exist for all Critical and High risks
  • Risk descriptions are specific — "vendor may be late" is not specific enough; name the vendor and the dependency
  • Register has been reviewed in the last [X] days
  • Closed risks are archived, not deleted — they provide audit trail
  • Risks are distinguished from issues — a risk is something that might happen; an issue is something that has happened

Example Trigger Phrases

  • "Build a risk register for our product launch"
  • "Create a risk matrix for [project name]"
  • "What risks should I document for a data migration project?"
  • "Generate a risk register for our steering committee"
  • "Help me identify and score risks for our Q3 delivery plan"

Anti-Patterns

  • Do not assign risks to "the team" or "TBD" — every risk must have a named individual owner
  • Do not write mitigations as "monitor and review" — mitigations must describe what is actively being done to reduce likelihood or impact
  • Do not delete closed risks — they provide an audit trail; archive them instead
  • Do not confuse risks with issues — a risk is something that might happen; an issue is something that has already happened
  • Do not leave Critical or High risks without a contingency plan — what happens if the mitigation fails must be documented

Related skills

capacity-planningcompetitor-teardowncontext-engineering-reviewrunbook-writerreceipts-audit