Purpose
Produce a decision-ready set of Key Risk Indicators for a chosen risk category — each defined precisely enough to measure, with data sources, calibrated green/amber/red thresholds, and reporting cadence — so a risk team can move from "we should monitor this" to a working dashboard without further design work.
When to Use
Invoke this skill when the user asks to:
- Design KRIs for a specific risk category (operational, financial, compliance, cyber, supply chain, strategic)
- Build or populate a risk monitoring dashboard
- Define leading indicators or early-warning metrics for a risk
- Set green/amber/red thresholds for existing risk metrics
- Establish reporting frequency and escalation triggers for risk monitoring
- Convert a risk register entry into measurable, trackable indicators
Inputs Required
Before starting, collect:
- Risk category: The specific risk area to monitor (e.g., liquidity risk, third-party/vendor risk, cybersecurity, regulatory compliance)
- Business context: Industry, business model, and what the organization does
- Company size/stage: Headcount, revenue band, or growth stage — affects which thresholds are realistic
- Existing data systems: What tools/systems already capture relevant data (ERP, CRM, ticketing, GRC platform, spreadsheets)
- Risk appetite: How much of this risk the organization is willing to tolerate (Low / Moderate / High), if known
- Regulatory or contractual obligations: Any mandated metrics, SLAs, or reporting standards that apply
- Reporting audience: Who reviews the dashboard (board, exec committee, operational team)
If risk appetite is unstated, default to Moderate and note the assumption. If thresholds cannot be benchmarked precisely, provide a defensible starting range and flag it for calibration against 3–6 months of actual data.
Instructions
Step 1: Frame the Risk and Its Drivers
Before generating indicators, break the risk category into its underlying drivers:
- Root causes: What conditions cause this risk to materialize?
- Leading vs. lagging split: Identify signals that appear before the risk crystallizes (leading) versus after (lagging). Prioritize leading indicators — a KRI dashboard that only reports lagging metrics is a post-mortem, not an early-warning system.
- Measurability filter: A good KRI must be quantifiable, tied to a data source that actually exists or can be built, and sensitive enough to move before a loss event.
Aim for a mix of roughly 60% leading and 40% lagging indicators in the final set.
Step 2: Generate 5–10 KRIs
Produce between 5 and 10 indicators (default to 7 unless the risk category clearly warrants more or fewer). For each KRI, define all of the following:
- KRI name: Short, specific, dashboard-ready
- What it measures: One sentence tying the metric to the underlying risk driver
- Type: Leading or Lagging
- Measurement methodology: The exact calculation or formula, stated so two people would compute the same number (e.g., "Number of overdue high-severity vulnerabilities ÷ total open high-severity vulnerabilities, measured monthly")
- Unit: Percentage, count, ratio, days, currency, etc.
- Data source: The specific system, report, or owner that provides the input data
- Data owner: The role responsible for supplying the number
- Thresholds — set three bands with concrete values: - Green (acceptable): Within appetite; no action - Amber (watch): Approaching tolerance; requires monitoring and analysis - Red (breach): Outside tolerance; triggers escalation
- Reporting frequency: Daily / Weekly / Monthly / Quarterly — matched to how fast the metric can move and how fast a response is needed
Step 3: Calibrate Thresholds to Context
Set threshold values using this logic, not arbitrary round numbers:
- Anchor to appetite: Low appetite → tighter amber/red bands; High appetite → wider tolerance
- Anchor to benchmarks: Where an industry standard, SLA, or regulatory limit exists, use it as the red line
- Directionality: State whether higher or lower is worse, and set bands accordingly
- Avoid false alarms: If a metric naturally fluctuates, base amber on a rolling trend (e.g., "2 consecutive periods above X") rather than a single reading
- Where a threshold is a best-estimate rather than a benchmarked value, mark it (calibrate after 3–6 months)
Step 4: Define the Escalation Protocol
For amber and red breaches, specify:
- Amber trigger: Who is notified, what analysis is required, and the review timeline
- Red trigger: Who is escalated to (name the role), the required response window, and whether it goes to the board/exec committee
- Include a compound trigger where relevant (e.g., "two amber KRIs in the same period escalates to red-level review")
Step 5: Assemble the Dashboard Layout
Provide a summary table of all KRIs suitable for a monitoring dashboard, ordered by reporting frequency (most frequent first). Recommend the review cadence for the dashboard as a whole and note which indicators warrant real-time or automated alerting.
Output Format
- Structure: Risk framing summary → detailed KRI cards (one per indicator) → threshold rationale → escalation protocol → consolidated dashboard table
- Length: 1,000–1,500 words
- Format: Structured document — KRI details as labeled cards or blocks; final dashboard as a table with columns for KRI, Type, Green, Amber, Red, Frequency, Data Source
- Sections: Risk & Drivers Overview → KRI Definitions (5–10) → Threshold Calibration Notes → Escalation Protocol → Dashboard Summary Table
- Tone: Risk practitioner — precise, defensible, quantitative; every threshold has a reason behind it
Quality Checklist
Before delivering output, verify:
- [ ] Between 5 and 10 KRIs are defined (count them)
- [ ] Each KRI includes all nine required fields (name, measures, type, methodology, unit, data source, owner, thresholds, frequency)
- [ ] At least half the KRIs are leading indicators, not just lagging
- [ ] Every threshold has a concrete numeric value or range — no "TBD" without a starting estimate and a calibrate flag
- [ ] Green/amber/red bands are internally consistent with the stated directionality (higher-is-worse vs. lower-is-worse)
- [ ] The escalation protocol names specific roles, not just "management"
- [ ] The final dashboard table lists every KRI with its thresholds and frequency
Notes
- The most common failure mode is designing KRIs that require data no one collects — always tie each indicator to a data source that exists or is realistically buildable, and flag any that require new instrumentation.
- Leading indicators are the whole point of a KRI program; if the user's risk category resists leading metrics, propose proxy signals (e.g., staff turnover as a leading indicator for operational and knowledge risk).
- Fewer well-instrumented KRIs beat many that are estimated or manually maintained — resist padding the list to reach 10.
- Recommend treating the first quarter of thresholds as provisional and recalibrating once real distribution data is available.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills