Human Risk Scoring
SkillSecurityExplainable 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.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Human Risk Scoring skill
What this skill tells your AI
The instructions your AI receives, as published by wyre-ai/msp-claude-plugins in msp-claude-plugins/awareness-pack/skills/risk-scoring/SKILL.md and read by ahel’s review.
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-reportingorproofpoint-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-normalizationin 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:
- Training completion (from
training-completion-tracking) — whether the user is current on required training, and how overdue they are if not. - Phishing-simulation performance (from
phishing-simulation-analysis) — click/fail history and repeat-clicker status. - 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:
- Score users purely on training-overdue status and severity (days overdue, number of overdue modules).
- Label the output explicitly as "training-completion-only score — no phishing-simulation data connected" so it is never mistaken for the fuller score.
- 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
- Discover connected inputs via
conduit__search_tools. - Pull training-completion status via
training-completion-tracking. - Pull phishing-simulation history via
phishing-simulation-analysis, if connected. - Pull real-click/attack-targeting signal from a connected email-security tool, if available, as compounding-risk enrichment.
- Apply the factor table to bucket each user into Low / Elevated / High risk, with the specific triggering factors shown per user.
- Rank users within the client by risk tier, highest first.
Portfolio-wide human risk ranking
- Run the per-user workflow above for every client in scope.
- Roll up to a per-org risk distribution and an overall org risk tier.
- Rank orgs by proportion of High-risk users (not raw count, so a large org isn't penalized purely for having more users) and surface the specific highest-risk individuals per org for remediation follow-up.
- Present orgs with zero connected training/awareness tooling as unmeasured, separate from the ranked list — a silent 0-risk score for an unmeasured org is a data gap, not a clean bill of health.
Error Handling
No training or simulation data connected at all
State plainly that no human-risk scoring is possible for this client — do not produce a fabricated Low-risk score by default.
Only training data available
Produce a training-completion-only score, explicitly labeled as such.
Only simulation data available
Produce a simulation-only score, explicitly labeled as such, and note that training-overdue status wasn't available as an input.
Real-click enrichment unavailable
Proceed with training + simulation scoring; note that real-world click-through enrichment wasn't available rather than treating its absence as a scoring failure.
Related Skills
- Training Completion Tracking — the primary input for training-overdue severity.
- Phishing Simulation Analysis — the primary input for click-rate and repeat-clicker severity.
Signals
- GitHub stars
- 45
- Forks
- 24
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
human-risk-scoring- Source
- github.com/wyre-ai/msp-claude-plugins