Open your last board report. Find the page that says Key Risk Indicators. Look at the indicators. How many of them actually warned you about something before it happened?
The honest answer, for almost every mid-market security and risk program in 2026, is none of them.
It is not because the team is bad. It is because the way Key Risk Indicators get built — in every enterprise GRC platform on the market and every spreadsheet that took their place — was designed for a different era and never updated.
How your KRIs actually got there
Three years ago, somebody at the company sat down with the risk appetite framework, looked at the standard list of operational risk categories, and wrote 20 or 30 indicators by hand. They picked thresholds based on benchmark guesses and rough intuition. They drew red/amber/green bands. They built a dashboard.
Then the document was approved. Then it stopped getting touched.
The platforms charge enterprise prices for exactly the work the platform doesn't do for you. You define the indicators. You set the thresholds. You decide which ones still matter when the business changes. The software draws the chart.
Why none of those indicators predict anything
There are four failure modes. They all show up at the same time.
The thresholds were guesses, and nobody ever checked
A warning threshold set in 2023 is a 2023 guess. Nothing has compared the warnings the indicator produced against the events that actually happened. A real example from the methodology spec: a SecurityGroupChanges indicator warning at 20 changes/day produced 45 warnings in 6 months, of which 3 corresponded to real incidents — a 93% false positive rate. Nobody had noticed because nobody was tracking whether the warnings predicted anything.
The indicators are lagging by design
Counting incidents that already happened is easy. Predicting the next one requires structural analysis the manual process can't do at scale. The board report shows last quarter's loss events. By the time they show up there, the loss already happened.
The list is structurally incomplete
Twenty hand-curated indicators cannot cover the actual risk surface of a 200-person company with 80 vendors and a five-region cloud footprint. The blind spots are the parts of the dependency graph nobody thought to write an indicator for — which is most of it.
Nothing knows what depends on what
A traditional KRI program treats indicators as standalone metrics. "Vendor count" is one indicator; "Okta MFA enforcement" is another. Nothing in the program understands that Okta supports three of your critical business functions, that a concentration there matters more than vendor count, or that a configuration drift on Okta should immediately re-derive the conditional exposure on those critical functions.
Hubbard's Failure of Risk Management documented this in 2020: a typical risk program's indicators perform worse than random at predicting which events will actually occur, because the indicators were defined to look complete on paper rather than to be predictive in practice. Five years on, almost no GRC platform has changed the underlying model.
What a real indicator should be
Four properties make the difference between an indicator on a slide and an indicator that actually warns you about something.
Each of these is solvable in software. None of them are being solved in software by the platforms charging enterprise prices. We built the thing that does.
Introducing Continuous Indicators
Continuous Indicators is the new capability inside vCISO Lite that produces the report your existing board pack couldn't. It is the operational alternative to the 20-to-50 manually-defined KRIs you stopped touching three years ago.
Three things define it:
Auto-derived from your dependency graph
When a vendor in your environment supports two or more of your critical business functions, the system surfaces a concentration indicator for that vendor automatically. When a single point of failure appears anywhere in a critical path, an SPOF indicator surfaces. When the scanner detects internet-exposed resources accelerating in your AWS account, an attack-surface-drift indicator surfaces with the per-resource exploit-likelihood scores. Nobody had to write any of these by hand. The graph wrote them.
Derived live, not derived once
Every indicator carries a freshness stamp. "Derived 3 min ago." "Re-derived hourly while incident is active." When a credential-exfiltration campaign hits GitHub-integrated organizations, the conditional exposure indicator computes your probability of being affected — 34%, derived from your live config signals, not a guess — and combines it with your modeled loss magnitude to produce an expected exposure. The number updates as the incident unfolds.
Calibrated against whether the warnings predict anything
Every threshold the system uses is tracked against the events that actually happened in the window after the warning. The system reports its own Brier score per indicator. When the false positive rate on a threshold climbs above the acceptable bound, the system recommends an adjustment with the historical math attached. No more set-and-forget thresholds. The platform argues for its own changes.
"Observed live by the scanner, not self-reported." Every existing GRC platform asks you questions and shows you your own answers. Continuous Indicators reads the environment and derives the indicator. That is the difference between a dashboard and a barometer. "Owner · J. Diaz, Platform Eng." Every indicator names the human responsible for it. Accountability is operationalized, not aspirational.
What this looks like in practice
The headline number is the Risk Posture Index. It is the composite that tells the board where the program is headed, not where it is today. The product shows it alongside the traditional Program Health score — so the difference between "where we are" and "where we're going" is visible in the same view.
Underneath it: indicators, organized by where the signal came from.
- Behavioral indicators from continuous scanner streams and integration data (Okta auth anomalies, AWS configuration drift, GitHub secret-scanning alerts).
- Conditional indicators from active incidents, computed via the Bayesian conditional-exposure framework that updates while the incident is live.
- Structural indicators from the dependency graph, auto-generated as the graph changes (vendor onboarding, system additions, critical-function redefinitions).
- Financial indicators from FAIR-based risk quantification — annualized loss expectancy by category, value at risk at the 95th and 99th percentiles, exposure as a percentage of revenue.
Each indicator carries a freshness stamp, an owner, a confidence interval, and a reasoning trail. The board report is not a static artifact you regenerate quarterly. It is the live state, summarized.
Where this stands today, honestly
Continuous Indicators ships now to vCISO Lite customers on the Business plan and above. The four indicator categories (behavioral, conditional, structural, financial) are all live. The Risk Posture Index aggregates across them.
Two parts of the methodology are still maturing. The calibration layer — the Brier scoring and the automatic threshold-adjustment recommendations — needs enough prediction-outcome data to make recommendations a customer can trust. For rare events, that data accumulates over months, not days. The system reports its own confidence in every recommendation, and the threshold recommendation is a recommendation, not an auto-applied change. You decide.
The other open work is the indicator coverage of action-categories beyond what the existing modules feed. As we expand the integration surface — more cloud providers, more identity providers, more observability tools — the structural and behavioral indicator coverage widens.
What this is not
Continuous Indicators is not a replacement for risk quantification. FAIR-based quantification continues to do what it does: convert scenarios into dollar distributions you can defend to a CFO. The indicators feed off the quantification and contextualize it; they do not replace it.
It is also not a replacement for incident response. When a vendor breach hits, the incident-response discipline takes over — the triage runs, the conditional exposure gets computed, the stay-exit-mitigate decision happens at human speed with human judgment. The indicator surfaces the active incident's exposure; the response handles the actual decision.
And it is not an autonomous agent. The system surfaces what's coming. The team still decides what to do about it. That is the right model for compliance and risk decisions at any stake level that matters, and the methodology underneath both products is the same: measured first, acted on second, every claim traceable to the evidence that produced it.
The next article in this series unpacks the framing the whole approach rests on — forward risk versus backward risk, and why the board report you give today is almost certainly the latter.
Where this matters next
Forward risk vs. backward risk: the board report that shows where you're headed — the leading-vs-lagging framing, why every existing GRC board report is structurally backward-looking, and what a forward-looking report should contain.
"Why this probability": showing your work in conditional exposure — the Bayesian decomposition that produces an exposure number a CFO can defend to the board — base rate, plus your specific signals, minus your specific controls, equals the posterior. Show your work.
The $150K GRC dirty secret: manual KRIs at enterprise prices — the verified competitive landscape — what enterprise GRC platforms actually charge for KRI management, and what they leave you to do yourself.
Conditional exposure analysis: why your risk isn't what the vendor reported — the mathematical core of the conditional-indicator computation — the framework the indicator runs on every time a vendor incident reaches the platform.
Vendor concentration risk: the dimension per-vendor TPRM misses — the structural-indicator companion. When the dependency graph surfaces a vendor that supports two-plus critical functions, this is the standing-program analysis that contextualizes it.
Platform: Executive Reporting — the forward-looking board reports the CFO defends — dollar-denominated exposure, KRIs derived live from your dependency graph, not manually curated.
Use Case: Quantify Risk — how to translate cyber risk into dollars the CFO defends and the board funds — in one hour, not one quarter.