---
name: risk-assessor
description: Produces a formal risk register entry with likelihood, impact, treatment plan, and owner, ready to add to ISO 27001 / ISO 31000 / NIST RMF registers.
version: 1.0.0
author: VantagePoint Networks
audience: IT Managers, Risk Owners, Information Security Leads, Compliance Managers
output_format: Formatted Markdown risk register entry + optional board paper summary paragraph.
license: MIT
---

# Risk Assessor

A conversation that turns "I'm worried about X" into a defensible, standards-aligned risk register entry with a named owner, a chosen treatment strategy, and a review date.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. Run `/risk-assessor` in Claude Code. Describe the thing you're worried about in your own words. The skill will work with you to classify, score, and choose a treatment.

## When to use this

- An audit is coming and you've been told the risk register is thin.
- You've identified a new risk during an incident or change and need to log it properly.
- You're reviewing existing risks at the quarterly RMF meeting and need to re-score some entries.
- You're writing a board paper and need a summary of one specific risk.
- You're building the risk register from scratch and want one entry at a time, done right.

## What you'll get

- **Full risk register entry** with all standards-expected fields.
- **Likelihood x Impact score** on a 5x5 matrix with transparent rationale.
- **Inherent risk** (before controls) and **residual risk** (with existing controls) - both scored.
- **Treatment strategy** recommendation (accept / transfer / mitigate / avoid) with reasoning.
- **Specific treatment actions** with owners, due dates, and expected residual score after treatment.
- **KRI (Key Risk Indicator)** suggestions - measurable signals that this risk is changing.
- **Review cadence** based on severity.
- **Board paper paragraph** - a 3-5 sentence summary you can drop into a governance pack.

## Clarifying questions I will ask you

1. **Describe the risk in one sentence starting with "There is a risk that...".** (Forces cause/event/consequence shape.)
2. **What's the underlying cause or threat?** (Human error, malicious actor, supplier failure, technology obsolescence, natural event)
3. **What business outcome gets damaged if it happens?** (Revenue, reputation, regulatory, safety, data)
4. **What controls are already in place?** (List what mitigates this today.)
5. **How likely is it, honestly, in the next 12 months?** (Rare / Unlikely / Possible / Likely / Almost Certain)
6. **If it happens, how bad?** (Insignificant / Minor / Moderate / Major / Catastrophic across relevant impact categories)
7. **Has something similar happened before** - here or at peers? (Calibrates likelihood honestly.)
8. **Who owns this risk?** (The accountable named individual - not a team.)
9. **What's your organisation's risk appetite for this category?** (Risk-averse / cautious / open / hungry)
10. **What framework do you align to?** (ISO 31000, ISO 27005, NIST RMF, COSO ERM, bespoke)

## Output template

```markdown
# Risk Register Entry: R-YYYY-NNN

## 1. Identification
| Field | Value |
|---|---|
| Risk ID | R-YYYY-NNN |
| Title | <short title> |
| Statement | "There is a risk that [cause] could result in [event], leading to [consequence]." |
| Category | Cyber / Operational / Financial / Strategic / Compliance / Reputational / Third-party / People |
| Sub-category | <as applicable to framework> |
| Owner | <Named individual, role> |
| Raised by | <Name> |
| Raised on | YYYY-MM-DD |
| Linked to | <project / service / asset / process> |

## 2. Threat & Cause Analysis
**Root cause / threat source:** <human error / malicious insider / external attacker / supplier failure / technology failure / natural event / regulatory change>

**Triggering conditions:** <what makes this materialise - e.g. "no patching for >30 days", "quarterly audit finding", "key staff departure without handover">

**Assets at risk:** <systems, data, services, physical assets, people>

**Threat actors (if cyber):** <internal / criminal / state / opportunist / script-kiddie> - motivation: <financial / political / disruption>

## 3. Impact Assessment (if the risk materialises)

| Impact axis | Rating (1-5) | Description |
|---|---|---|
| Financial | N | <revenue loss, fines, remediation cost - include a figure or band> |
| Operational | N | <service interruption, productivity loss, duration> |
| Regulatory | N | <specific regulation, fine band, reporting obligations> |
| Reputational | N | <who finds out, how bad, how long> |
| Safety | N | <if applicable - physical harm potential> |
| Data | N | <confidentiality / integrity / availability impact, volume/sensitivity> |
| **Overall Impact** | **N** | <highest of above, or calibrated composite> |

## 4. Likelihood Assessment
**Rating: 1-5** - <Rare (1) / Unlikely (2) / Possible (3) / Likely (4) / Almost Certain (5)>

**Rationale:**
- Historical occurrence (here / industry): <evidence>
- Current controls effectiveness: <honest view>
- Threat landscape: <increasing / stable / decreasing>
- Peers reporting this: <yes/no/partial>

## 5. Inherent Risk Score (before current controls)
> L x I = N (Band: Low / Medium / High / Critical)
>
> <One paragraph explaining what this would look like in a no-controls world. Forces honest appraisal.>

## 6. Existing Controls

### Preventive controls
| Control | Description | Effectiveness (1-5) | Evidence / tested? |
|---|---|---|---|
| <name> | <what it does> | N | <source/date> |

### Detective controls
| Control | Description | Effectiveness (1-5) | Evidence / tested? |
|---|---|---|---|
| <name> | <what it does> | N | <source/date> |

### Corrective controls
| Control | Description | Effectiveness (1-5) | Evidence / tested? |
|---|---|---|---|
| <name> | <what it does> | N | <source/date> |

## 7. Residual Risk Score (with current controls)
> L x I = N (Band: Low / Medium / High / Critical)
>
> <Explain WHY this is lower than inherent - which controls reduced which axis by how much.>

## 8. Risk Appetite & Tolerance
| Field | Value |
|---|---|
| Appetite band for this category | Averse / Cautious / Open / Hungry |
| Tolerance threshold | <e.g. "Residual > Medium triggers escalation"> |
| Current residual vs tolerance | Within / At threshold / Exceeded |

## 9. Treatment Strategy
**Chosen strategy:** Accept / Transfer / Mitigate / Avoid

**Rationale:**
<One paragraph explaining why this strategy is appropriate given appetite, cost, and feasibility.>

### If MITIGATE - Treatment Plan
| Action | Owner | Due | Effect | Cost | Target residual |
|---|---|---|---|---|---|
| <specific action> | <name> | YYYY-MM-DD | <which axis does it reduce> | <currency> | L=N, I=N |
| <specific action> | <name> | YYYY-MM-DD | <which axis does it reduce> | <currency> | L=N, I=N |

### If TRANSFER - Transfer mechanism
- <insurance policy, contractual clause, outsourcing arrangement>
- Residual risk owner remains: <name> (transfer rarely moves accountability, only liability)

### If ACCEPT - Acceptance record
- Accepted at residual score: <score>
- Accepted by: <name + role + date>
- Acceptance review date: <YYYY-MM-DD>
- Compensating measures (if any): <list>

### If AVOID - Avoidance plan
- Activity being stopped: <what>
- Effective date: YYYY-MM-DD
- Replacement activity (if any): <what>

## 10. Target Residual Risk (after treatment)
> L x I = N (Band)
>
> Achievable by: YYYY-MM-DD

## 11. Key Risk Indicators (KRIs)
Measurable signals that the risk is rising or falling.

| KRI | Source | Threshold - green | Threshold - amber | Threshold - red | Review |
|---|---|---|---|---|---|
| <metric> | <where it comes from> | <value> | <value> | <value> | Monthly / Quarterly |

## 12. Review Cadence
- Critical: monthly
- High: quarterly
- Medium: half-yearly
- Low: annually

**Next review:** YYYY-MM-DD
**Reviewer:** <name>

## 13. Change History
| Date | Change | By |
|---|---|---|
| YYYY-MM-DD | Created | <name> |

## 14. Board Paper Summary (3-5 sentences, drop-in ready)
> <Plain-English explanation suitable for a non-technical board paper. Includes: what the risk is, current residual rating, why the rating is what it is, what we're doing about it, and what would make this paper escalate to "red" next quarter.>
```

## Example invocation

**User:** "/risk-assessor - I'm worried about our reliance on a single network engineer who knows all the firewall configs. If he leaves we're exposed."

**What the skill will do:**
1. Reshape into a formal risk statement: "There is a risk that loss of the single firewall SME through departure/illness could result in inability to respond to incidents or apply configuration changes, leading to extended outages, audit findings, and regulatory exposure."
2. Ask about existing controls (documentation? cross-training? MSP backup? change management rigour?) and get honest ratings.
3. Score inherent risk high (usually L=3, I=4 = 12 in a small team with no documentation).
4. Recommend mitigate with a treatment plan: documented runbooks for top-20 procedures, cross-training a second engineer, signed-up support contract with the vendor for emergency config access.
5. Propose KRIs: "days of single-person dependency per change ticket", "runbook coverage %".
6. Produce a board paper paragraph that names the risk, quantifies it, and shows that it's being treated - without throwing the named engineer under the bus.

## Notes for the requester

- **Phrase the risk as cause->event->consequence.** "Server might break" is not a risk. "Obsolescence of core switch could lead to unrecoverable failure, causing 8+ hour HQ outage" is a risk.
- **Be honest about control effectiveness.** Auditors smell optimism instantly. If a control is in place but has never been tested, rate it lower.
- **The owner is a named person, always.** "The IT team" is not an owner. Someone's name goes in the field or the risk can't be treated.
- **Don't confuse residual risk with target residual.** Residual = where we are now. Target = where treatment will get us. Both are needed.
- **Review dates must be honoured.** A risk register that's never refreshed is negative value. Put the review in your calendar the day the entry is created.
- **"Good" looks like:** an auditor reads the entry, agrees with the inherent score, agrees the listed controls justify the residual score, and sees a concrete treatment plan with owners and dates. They stop asking questions.