/risk-scoring

name: "Human Risk Scoring"
description: >
  Explainable per-user and per-org human risk scoring from training-completion
  status, phishing-simulation failure history, and optional real-world
  click/attack-targeting signal: the weighted factor table, three-tier
  bucketing, per-org rollup as a distribution rather than a blended number,
  and graceful degradation when only some inputs are connected.
when_to_use: >-
  When ranking users or clients by human-layer security risk, or building a
  culture/awareness risk score. Use when: human risk score, riskiest users,
  security culture score, awareness risk ranking, who is our biggest human
  risk, human risk report, security awareness scorecard.

Human Risk Scoring

Overview

A human risk score turns training-completion and phishing-simulation signal into one comparable number per user (and rolled up per org), so an MSP can prioritize remedial attention the same way `tenant-exposure-ranker` in secops-pack prioritizes technical exposure. The design goal here is the same discipline that pack applies: an explainable ranked comparison with visible inputs, never an opaque score a reviewer has to take on faith.

Anti-triggers

• **A vendor's own user risk score** — KnowBe4 and Proofpoint each compute

one from their own data alone; use `knowbe4-reporting` or `proofpoint-people`. This skill blends inputs across tools and keeps the factor table visible.

• **Technical exposure ranking** — ranking tenants or endpoints by threat

and configuration posture is a different axis from human risk; use `alert-severity-normalization` in secops-pack.

Step Zero: Confirm What's Connected

Call `conduit__search_tools` to determine which inputs are actually available before scoring anything. This skill's inputs, from strongest to weakest available data:

1. **Training completion** (from `training-completion-tracking`) — whether the user is current on required training, and how overdue they are if not. 2. **Phishing-simulation performance** (from `phishing-simulation-analysis`) — click/fail history and repeat-clicker status. 3. **Real-world click-through data** (optional) — from a connected email-security tool (Proofpoint, Avanan) exposing actual click or attack-targeting signal, where available.

Not every input will be available for every client. Score with whatever subset is connected, and always state explicitly which inputs were used for a given score — a score computed from training data alone is a different, less complete signal than one that also incorporates simulation and real-click data, and the output must make that difference visible rather than presenting both as equally authoritative.

Key Concepts

A simple, explainable scoring approach

Avoid building an opaque composite score. Instead, use a small number of weighted factors, each independently visible in the output:

| Factor | Signal | Relative weight | |---|---|---| | Training overdue | Overdue assignment(s), and how overdue (days past due) | Highest — an overdue user is a known, current gap | | Repeat phishing-sim failures | 2+ simulated-phishing failures, weighted higher for more recent and more frequent failures | High | | Single/no phishing-sim failure | 0–1 failures in available history | Neutral to low, depending on completeness of history | | Real-world click/attack-targeting signal (optional) | A real click, credential-harvest event, or "attacked person" designation from a connected email-security tool | Compounding — when present alongside repeat sim failures, this pushes the user into the highest risk tier rather than just adding linearly |

Do not fabricate a precise numeric weight scheme (e.g. "37% + 28% + ...") unless the operator has asked for one and supplied real weights — a three-tier bucket (Low / Elevated / High risk) driven by the factor table above is more honest about the precision this data actually supports than a false-precision single percentage. If a numeric score is wanted, keep the formula visible in the output rather than presenting a bare number.

Per-user vs. per-org rollup

Score individual users first — this is where the actionable remediation lives (assign this specific person to retraining, flag this specific account for closer monitoring). Roll up to an org-level score as a distribution summary (e.g. "12% of users High risk, 30% Elevated, 58% Low") rather than a single blended org score that hides which specific users drive it. A per-org score is useful for portfolio-level prioritization, but it should always be paired with the underlying distribution and the list of highest-risk individuals, not presented alone.

Graceful degradation when phishing-simulation data isn't available

If no phishing-simulation platform is connected for a client, do not block scoring — degrade to training-completion-only scoring:

1. Score users purely on training-overdue status and severity (days overdue, number of overdue modules). 2. Label the output explicitly as "training-completion-only score — no phishing-simulation data connected" so it is never mistaken for the fuller score. 3. If a phishing-simulation platform is later connected, re-run to get the fuller score rather than blending partial-era data with full-era data silently.

The same degradation logic applies if training data isn't available but simulation data is — score on simulation performance alone and label accordingly. A score with zero connected inputs cannot be produced; say so explicitly rather than returning an empty or fabricated ranking.

Common Workflows

Per-user risk scoring for a client

1. Discover connected inputs via `conduit__search_tools`. 2. Pull training-completion status via `training-completion-tracking`. 3. Pull phishing-simulation history via `phishing-simulation-analysis`, if connected. 4. Pull real-click/attack-targeting signal from a connected email-security tool, if available, as compounding-risk enrichme