<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
<!-- NERF is a trademark of defconxt. -->
---
name: implementing-key-risk-indicators
description: >-
  Design, implement, and operationalize key risk indicators (KRIs) that provide early warning of increasing risk exposure with automated collection, threshold monitoring, and trend analysis.
domain: cybersecurity
subdomain: governance-risk-compliance
tags:
  - kri
  - risk-indicators
  - risk-monitoring
  - threshold-management
  - trend-analysis
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: []
---

# Implementing Key Risk Indicators

## Overview

KRIs are forward-looking metrics that signal changes in risk exposure before incidents occur. This technique covers designing KRIs aligned to risk appetite, automating data collection from security tools, setting threshold triggers, and building trend dashboards for risk committees.

Mode: `[MODE: BLUE]` — KRI implementation, monitoring, and threshold management.

## Prerequisites

| Requirement | Details |
|---|---|
| Security tooling APIs | SIEM, vuln scanner, EDR, IAM |
| Risk appetite statements | Defined thresholds |
| Python 3.10+ | For agent tooling |

## Workflow

### 1. KRI Design Framework

```
Effective KRI characteristics (SMART):
├── Specific: clearly defined metric
├── Measurable: quantifiable from data sources
├── Actionable: triggers defined response
├── Relevant: aligned to risk appetite
└── Timely: collected at useful frequency

KRI categories:
├── Leading indicators (predictive):
│   ├── Failed login attempts trend
│   ├── Phishing click rate
│   ├── Unpatched critical vulns count
│   └── Third-party risk score changes
├── Lagging indicators (outcome-based):
│   ├── Number of security incidents
│   ├── Data breach count
│   ├── Audit findings count
│   └── Compliance violation count
└── Current indicators (state-based):
    ├── Patch compliance percentage
    ├── MFA adoption rate
    ├── Encryption coverage
    └── Backup success rate
```

### 2. KRI Threshold Configuration

```
Traffic light thresholds:
├── GREEN: Within normal operating range
│   └── No action required
├── AMBER: Approaching risk tolerance limit
│   ├── Increase monitoring frequency
│   ├── Notify risk owner
│   └── Prepare mitigation plan
└── RED: Exceeding risk tolerance
    ├── Escalate to risk committee
    ├── Activate response plan
    └── Report to board if at limit

Example thresholds:
├── Patch compliance: GREEN >95%, AMBER 80-95%, RED <80%
├── MTTD: GREEN <4hr, AMBER 4-24hr, RED >24hr
├── Open critical vulns: GREEN 0, AMBER 1-5, RED >5
└── Phishing click rate: GREEN <3%, AMBER 3-8%, RED >8%
```

### 3. Automated Collection

```bash
# KRI data sources:
├── SIEM API → incident counts, MTTD, MTTR
├── Vulnerability scanner → vuln counts, patch rates
├── IAM system → MFA adoption, access reviews
├── EDR platform → detection rates, endpoint health
├── GRC platform → audit findings, compliance scores
└── Phishing simulator → click rates, report rates

# Collection frequency:
├── Real-time: incident counts, failed logins
├── Daily: vulnerability counts, patch status
├── Weekly: phishing metrics, training completion
├── Monthly: compliance scores, third-party risks
└── Quarterly: maturity assessments, trend reports
```

## Verification

- [ ] Process documented and approved
- [ ] Stakeholders identified and engaged
- [ ] Tooling configured and automated where possible
- [ ] Outputs reviewed and validated
- [ ] Reporting integrated into GRC program
- [ ] Periodic review schedule established
