KRIs for the human layer

Human security is the most cited risk factor in most programs and the worst measured. “Human error is behind the majority of breaches” shows up on slide after slide, but the same programs rarely have anything past phishing simulation click rates to back it. A click rate tells you who failed last quarter. It tells you almost nothing about whether your people would catch the real thing, report it, or quietly forward it to finance.

The KRIs here read the full range of human-generated signal: who reports, which high-consequence cohorts are actually covered, where behavioral indicators are drifting, how resilient your help desk is to a phone call, and whether access actually gets cut the day someone leaves. The point is to move human security from a training-completion metric to a leading indicator you can act on before an incident, not document after one. If you are standing up this domain from scratch, start with the sequencing in our guide to building a KRI program, then map these signals against the green/amber/red bands in the KRI reference library.

This guide is part of a series that runs the same treatment across domains, including identity and access management, GRC, and enterprise security. The human layer touches all three, so expect overlap at the edges, especially around joiner-mover-leaver and privileged accounts.

Why human security KRIs need a different approach

Technical KRIs measure systems. Human security KRIs measure behavior, and behavior is harder to quantify, more context-dependent, and more sensitive to collect. That sensitivity cuts two ways, and both are real failure modes.

The first is under-measurement. A program that leans only on phishing simulation results and training completion is tracking activity, not risk. Those numbers move when you run more campaigns, not when your people actually get better at spotting an attack.

The second is over-surveillance. Measuring individual employee behavior in the wrong way creates legal exposure, erodes trust, and produces the exact opposite of the culture you are trying to build. People who feel watched stop reporting, and reporting is the signal you most need.

The KRIs in this domain are built to measure aggregate patterns and program effectiveness, not to surveil individuals. Where individual behavior genuinely matters (insider threat), it carries a hard prerequisite: documented governance, legal review, and HR partnership before anything is deployed. Treat that as a gate, not a footnote.

KRI inventory

1. Phishing simulation resilience rate

What to measure. The percentage of employees who correctly identify and actively report simulated phishing (not just avoid clicking, and not ignore), tracked as a trend across simulation campaigns over the trailing 12 months.

Why it matters. Click rate is a negative metric: it counts failure. Reporting rate is the positive one: it counts active participation in defense. An organization that trains people to report suspicious email gets earlier warning on the real campaigns. Trend beats any single snapshot. A reporting rate climbing from 12% to 28% across four campaigns is a genuine culture signal, where a flat 20% is not.

Derivation sources.

• Security awareness training platform (KnowBe4, Proofpoint Security Awareness Training, Cofense, Mimecast Awareness Training): per-campaign click_rate, report_rate, and open-without-click rates. See the KnowBe4 integration guide for pulling campaign results into Draxis.
• Email security gateway: “Report Phishing” button activation rate (Cofense Reporter, Proofpoint PhishAlarm, Microsoft Report Message).
• Incident management system: trend in user-reported suspicious email volume.

How to calculate. Click rate = (users clicking the simulated link) ÷ (users who received the simulation) × 100. Report rate = (users who reported the simulation) ÷ (users who received it) × 100. Track the report-rate change across the trailing four campaigns as the headline trend.

Status	Criteria
Green	Click rate <5%; report rate >25%; report rate trending upward; repeat-clicker rate <1%
Amber	Click rate 5–15%; or report rate flat; or repeat-clicker rate 1–5%
Red	Click rate >15%; or report rate declining; or repeat-clicker rate >5%; or no reporting mechanism at all

2. High-risk cohort training completion and behavioral profile

What to measure. Completion rate for targeted security training within the highest-consequence population: executives, finance, HR, IT administrators, engineers with production access, and repeat phishing-simulation clickers.

Why it matters. Aggregate completion rates hide the population that matters most. A company at 95% overall but 40% in the finance team that approves wire transfers has a serious gap the headline number buries. High-risk cohorts need their own tracking, their own content, and their own escalation path when they miss.

Derivation sources.

• LMS or security awareness platform: completion records segmented by department, role, and phishing-simulation history.
• HR system: employee role classifications used to define cohorts.
• Phishing simulation platform: the repeat-clicker list, used to assign targeted training.
• IT systems: administrator and production-access accounts cross-referenced against training records.

How to calculate. Define each high-risk cohort explicitly, then per cohort: (cohort members with current training complete) ÷ (total cohort members) × 100. Report per cohort, never as a single blended figure.

Status	Criteria
Green	>95% completion in every high-risk cohort; cohort definitions reviewed annually; targeted content differentiated from the general population
Amber	80–94% in one or more high-risk cohorts; or one-size-fits-all training regardless of cohort
Red	<80% in any high-risk cohort; or no high-risk cohort definition; or the executive population exempt from training

3. Insider threat behavioral indicator rate

What to measure. The rate of behavioral indicators tied to insider-threat risk (data exfiltration attempts, unauthorized access to sensitive resources, policy violations, anomalous activity patterns) detected and triaged across the monitored population. This KRI requires an established insider threat program and legal review before implementation.

Why it matters. Insider threats drive a meaningful share of material data loss and stay underdetected because most programs face outward. Behavioral indicator monitoring, when it is governed properly, gives you leading signal before a data-loss event rather than a post-mortem after one.

Legal and governance prerequisite. Before any implementation, this KRI needs a documented insider threat program charter, HR and legal partnership, employee notice consistent with applicable law, and a defined triage and investigation process. Consult legal counsel first.

Derivation sources.

• DLP platform (Microsoft Purview, Forcepoint, Symantec DLP): policy-violation events by category (bulk_download, external_transfer, unauthorized access attempt).
• UEBA platform (Microsoft Sentinel UEBA, Securonix, Exabeam): anomalous behavior scores aggregated across the population.
• Email security or Microsoft Purview Communication Compliance: policy-violation indicators in communication channels.
• Endpoint monitoring: USB device usage, screen-capture attempts, application-usage anomalies, where legally permitted and disclosed.
• Access logs: access to sensitive data outside normal role scope or outside normal working hours.

How to calculate. Track as aggregate rates, never individual surveillance: monthly DLP policy violations per 1,000 employees (trend); UEBA anomaly alert rate above a defined threshold per month; unauthorized sensitive-resource access attempts per month.

Status	Criteria
Green	Baseline established; indicators trending stable or declining; alert-triage SLA defined and met
Amber	Indicators trending upward with no identified explanation; or a growing triage backlog
Red	Confirmed data exfiltration event; or indicators spiking without triage capacity; or no insider threat program in a high-risk environment

4. Security culture health score

What to measure. A composite indicator of security culture drawn from voluntary reporting rates, security-team engagement, policy-exception request rates, and optional periodic survey data on how the program is perceived.

Why it matters. Culture is the long-lead investment that makes every other human-security control work better. A strong culture has people reporting suspicious email, flagging odd requests, asking about security implications early, and holding each other accountable. A weak one treats security as an obstacle and routes around it. This score tells you whether your training is producing actual behavior change or just completion certificates. It is also a good place to watch for early drift; the same trend-reading discipline from reading the signal on drifting KRIs applies here.

Derivation sources.

• Incident reporting system: voluntary security incident and near-miss reports per month. Rising voluntary reporting is a strong culture signal.
• Security team: qualitative read from regular touchpoints with business units.
• Optional annual culture survey: perceived approachability, usefulness, and priority of the security program.
• Policy exception requests: high request-and-grant rates can signal friction between controls and how the business actually works.
• Security champion engagement: participation rates in the champion program.

How to calculate. Score four signals 1–5 and composite them: voluntary reporting trend (rising = 5, declining = 1); policy exception rate (low = 5, high = 1); security champion participation (high = 5, none = 1); survey perception score (if conducted).

Status	Criteria
Green	Composite score >3.5; voluntary reporting trending up; an active security champion program
Amber	Score 2.5–3.5; or flat reporting; or elevated exception rates
Red	Score <2.5; or declining voluntary reporting; or the security team perceived as adversarial to the business

5. Social engineering resilience for voice and messaging channels

What to measure. Employee response to vishing (phone-based social engineering) and SMS/messaging phishing scenarios, segmented by high-risk departments: IT help desk, finance, and executive assistants.

Why it matters. Most simulation programs test email and stop there. Voice-based social engineering is behind some of the most damaging breaches of the last five years, including the MGM Resorts attack, which started with a call to the IT help desk. Finance teams get hit with voice-based BEC. Training email resilience while leaving voice untested is a structural gap, not a rounding error.

Derivation sources.

• Vishing simulation providers (Social-Engineer LLC, KnowBe4 vishing, custom red team exercises): scenario scripts, call results, and employee response records.
• IT help desk ticket records: unusual account-reset requests or identity-verification failures, which lag successful social engineering.
• Finance team: unusual payment-request patterns, a behavioral indicator of phone-based BEC.
• Red team exercise reports: social engineering scenarios aimed at voice channels.

How to calculate. (Employees who correctly challenged and refused the vishing scenario) ÷ (total employees in the simulation) × 100. Track separately for help desk, finance, and executives.

Status	Criteria
Green	>80% resistance in all cohorts; vishing simulation at least annually; help desk runs a formal identity-verification protocol
Amber	60–79% resistance; or simulation only for the general population, not high-risk cohorts
Red	<60% resistance; or no vishing simulation program; or a help desk with no formal verification protocol

6. Onboarding and offboarding security completion rate

What to measure. The percentage of new hires with security training completed inside the first 30 days, and the percentage of departures with all access revocation and equipment return completed within 24 hours of separation.

Why it matters. The first 30 days is when an employee builds their mental model of what security expects. Training in week one shapes behavior differently than training six months in. Offboarding completeness is the operational control that prevents former-employee access, the most common source of dormant and orphaned accounts. This KRI sits right on the boundary with identity and access management, since the joiner-mover-leaver flow is where HR and IAM either connect or fail.

Derivation sources.

• HR system (Workday, ADP, BambooHR): hire_date and termination_date feeds.
• LMS: security training completion dates cross-referenced with HR hire dates.
• Identity provider: account-creation dates vs. hire dates (late provisioning is a gap signal); account-disable dates vs. termination dates.
• Equipment management (Jamf, Intune, asset tracking): device-return records for departing employees.
• Access certification or IGA: offboarding workflow completion status.

How to calculate. Onboarding = (new hires with security training complete in ≤30 days) ÷ (total new hires in period) × 100. Offboarding = (terminations with all access disabled within 24 hours) ÷ (total terminations in period) × 100.

Status	Criteria
Green	>95% onboarding completion in 30 days; >98% offboarding access disabled in 24 hours; automated triggers from the HR system
Amber	80–94% onboarding; or offboarding in 24–72 hours; or a manual process with no HR-system integration
Red	<80% onboarding in 30 days; or any involuntary termination with access not disabled same-day; or no HR-to-IAM automation

7. Policy exception and violation rate

What to measure. The monthly rate of security policy exceptions granted and policy violations detected, as a ratio to employee population, trended over time.

Why it matters. Exception rates show you where policy creates friction with how the business actually works, which is useful feedback as much as a risk signal. A high exception rate in one area often means the policy needs updating, not that the people need more training. Violation rates measure something different: behavior that bypasses policy instead of requesting an exception.

Derivation sources.

• Ticketing or exception-management system: exception requests per policy area, approval rate, and exception duration.
• DLP alerts: policy violations by category and business unit.
• Email gateway: blocked outbound transmission attempts, a measure of users trying to bypass controls.
• IT help desk: requests to disable security controls, a violation signal even when denied.

How to calculate. Exception rate = (exceptions granted per month) ÷ (total employees) × 1,000. Violation rate = (violations detected per month) ÷ (total employees) × 1,000. Exception quality = (exceptions with a defined expiry date) ÷ (total exceptions) × 100.

Status	Criteria
Green	Exception rate <5 per 1,000 employees/month; violation rate <2 per 1,000; all exceptions carry a defined expiry
Amber	5–15 exceptions per 1,000; or violations trending upward; or exceptions without expiry accumulating
Red	>15 exceptions per 1,000 (the policy may need updating, not just enforcement); or violations spiking; or no exception tracking

Deriving these KRIs by source type

From security awareness platforms (KnowBe4, Proofpoint, Cofense)

The KnowBe4 reporting API returns click_rate, report_rate, and open_rate per campaign and per cohort, which you can filter to high-risk role groups. The KnowBe4 connector handles the campaign and per-user pull. Identify repeat clickers as users with two or more clicks across the last four campaigns, and route them to targeted training and an elevated monitoring flag. Cross-reference completion records against HR department codes to get completion by department, and aggregate the KnowBe4 Risk Score to the department or team level so reporting stays privacy-appropriate.

From email and communication security (Microsoft 365 Defender, Proofpoint, Mimecast)

Report-phishing button usage comes from Exchange message trace plus junk-email reporting events, or Proofpoint PhishAlarm submission events. Track user-reported email volume as a monthly trend of suspicious-email reports sent to the security team. Watch the count of social-engineering attempts that bypassed gateway controls and landed in the inbox; that is a leading indicator of the human-risk pressure your people are actually under.

From DLP and UEBA platforms (Microsoft Purview, Securonix, Exabeam)

Export DLP policy-violation events by category (external_transfer, bulk_download, USB transfer), aggregate per department, and track the monthly trend. From UEBA, aggregate anomaly scores across the population and track the percentage of users above a risk threshold per month rather than reporting individual scores. Treat unusual access patterns (sensitive resources outside normal hours or normal role scope) as an aggregate rate for KRI purposes, not individual tracking.

From HR systems (Workday, ADP, BambooHR, Greenhouse)

Integrate hire and termination event feeds with IAM to drive joiner-mover-leaver automation, which also feeds the onboarding and offboarding timeliness KRI. Role-change history (employees who changed roles in the last 90 days) is an access-review trigger and a quality signal for access certification, not a risk by itself. Current department and role mapping gives you the structure you need for cohort segmentation in training and simulation.

From the identity provider (Entra ID, Okta, Google Workspace)

Compare account_created timestamp to the HR hire date; a lag is an onboarding-process gap. Compare account_disabled timestamp to the HR termination date; a lag is an offboarding security gap. High-privilege account activity outside business hours or from unusual locations is an identity-layer human-risk signal worth surfacing alongside the behavioral indicators above.