KRIs for the enterprise risk portfolio

Most KRI work happens inside a single domain. You measure whether identity hygiene is holding, whether endpoint coverage is complete, whether the SIEM is catching what it should. Each of those answers part of the question. None of them answers the one a CISO actually has to defend: across everything we run, how exposed are we right now, and is that exposure getting better or worse?

That is what enterprise KRIs do. They sit on top of the domain signals and synthesize them. This guide covers the nine that belong in the enterprise risk register, the ones that represent material risk to the organization’s financial health, operational continuity, regulatory standing, or reputation, and it shows exactly how to derive each from data you already collect. If you are still standing up the underlying program, start with how to build a KRI program and the consolidated KRI reference library, then come back here for the synthesis layer.

The domain detail lives in the sibling guides: security operations KRIs, identity and access management KRIs, and GRC KRIs. The enterprise KRIs here pull from all of them.

Why enterprise-level KRIs are different

Domain KRIs tell you whether a specific control area is functioning. Enterprise KRIs tell you whether the sum of those control areas adds up to acceptable risk posture. That is a different question, and the difference matters in practice.

A team can have excellent endpoint coverage and poor identity hygiene and still be badly exposed, because the weakest domain sets the floor. An organization can pass every individual control benchmark while carrying a critical gap that only appears at the seam between two domains, where neither owner is watching. And the people who answer to auditors, regulators, and insurers (and yes, the board too) need a composite signal they can stand behind, not eleven separate domain reports that they have to reconcile in their heads.

Enterprise KRIs are the synthesis layer. They draw on multiple sources by design, and their value comes from the cross-domain perspective, the view that no single tool produces on its own. When one of them moves, the useful next question is which domain is driving it. For reading that movement before it becomes an incident, see reading the signal in drifting KRIs.

KRI inventory

1. Overall risk posture score

What to measure. A weighted composite score (0–100) aggregating KRI status across all active security domains, using domain weights calibrated to the organization’s industry, regulatory regime, and threat model.

Why it matters. It gives you a single defensible number you can track over time and decompose on demand. When it moves, the score itself tells you which domains are driving posture up or down, so you are arguing from data rather than impression.

Derivation sources:

• Aggregate from domain-level KRI scores (see the domain-specific guides in this series).
• CSPM tools (Wiz, Prisma Cloud, AWS Security Hub) for the cloud posture contribution.
• Security ratings platforms (BitSight, SecurityScorecard) as an external validation check.
• GRC platforms (ServiceNow GRC, Archer) where risk register scores are maintained.

How to calculate. Sum of (domain KRI score × domain weight) ÷ sum of domain weights. Domain weights are set during program initialization and reviewed annually.

Status	Criteria
Green	75–100. Strong posture, no critical gaps.
Amber	50–74. Material gaps in one or more domains, active remediation in progress.
Red	Below 50. Critical exposure in one or more domains, or multiple concurrent amber-level gaps.

2. Mean time to detect (MTTD), enterprise-wide

What to measure. Average hours from confirmed security event to security team detection, measured across all incident types over the trailing 90 days.

Why it matters. MTTD is the single most predictive metric for breach cost. Organizations detecting in under 4 hours run breach costs roughly half those of organizations that take 24 hours or more. This number tells you whether your detection investment is actually paying off.

Derivation sources:

• SIEM (Splunk Enterprise Security, Microsoft Sentinel, Elastic SIEM): time delta between first log evidence of attack behavior and first alert or ticket creation.
• EDR (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint): alert timestamp versus event timestamp in telemetry.
• Incident management platform (PagerDuty, ServiceNow, Jira Service Management): incident creation time versus event time recorded during post-incident review.
• SOAR (Palo Alto XSOAR, Splunk SOAR): automated playbook trigger time versus first indicator timestamp.

How to calculate. For each closed incident in the trailing 90 days: (alert/detection timestamp) − (earliest confirmed event timestamp from forensic log review). Average across all incidents, weighting by severity if desired.

Status	Criteria
Green	Under 4 hours average.
Amber	4–24 hours.
Red	Over 24 hours, or no MTTD tracking capability.

3. Mean time to contain (MTTC), enterprise-wide

What to measure. Average hours from confirmed detection to confirmed containment of the threat: attacker access removed, malware isolated, exfiltration stopped.

Why it matters. Containment speed is the primary driver of breach scope. Fast detection without fast containment still produces large losses. MTTD and MTTC together define the damage window, and the window is where the money goes.

Derivation sources:

• Incident management platform: containment action timestamp versus detection timestamp, logged per incident.
• EDR: isolation action timestamp for endpoints.
• Firewall and NAC: block rule creation timestamp for lateral movement containment.
• SOAR: automated containment action timestamp.

Status	Criteria
Green	Under 2 hours for critical incidents; under 8 hours for high.
Amber	2–8 hours for critical.
Red	Over 8 hours for critical, or containment not tracked per incident.

4. Critical asset inventory completeness

What to measure. The percentage of assets classified as critical (those whose compromise would cause material harm) that are tracked in the enterprise asset inventory with a documented owner, classification, and control assignment.

Why it matters. Critical assets without documented owners have no accountability for their protection. This KRI measures whether the organization knows what it is protecting and who is responsible for it.

Derivation sources:

• CMDB (ServiceNow, Ivanti): critical asset classification fields and owner assignments.
• Cloud inventory (AWS Config, Azure Resource Graph, GCP Asset Inventory): tagging completeness for criticality and owner tags.
• Network discovery tools (Qualys CSAM, Axonius, Armis): discovered assets cross-referenced against the CMDB.
• AD and Entra ID: server and workstation inventory cross-referenced against asset records.

How to calculate. (Critical assets with documented owner, classification, and control assignment) ÷ (total discovered assets classified as critical) × 100.

Status	Criteria
Green	Over 98% of critical assets fully documented.
Amber	90–97%.
Red	Under 90%, or no formal critical asset classification scheme.

5. Security debt index

What to measure. A composite measure of deferred security remediation: open critical and high vulnerabilities, unresolved critical pen test findings, overdue risk register items, and end-of-life assets, expressed as a trended score.

Why it matters. Security debt accumulates silently and compounds. Teams that track it explicitly make conscious decisions about acceptance and prioritization. Teams that don’t track it discover it at claim time, which is the worst possible moment to learn the number.

Derivation sources:

• Vulnerability scanner (Qualys VMDR, Tenable, Rapid7): open critical and high findings by age.
• Pen test management (PlexTrac, Dradis, or tracking in Jira): open findings by severity and age.
• GRC platform or risk register: overdue risk treatment actions.
• Asset management: end-of-life hardware and software counts.

How to calculate. Assign points: critical vuln over 30 days = 10 points each; high vuln over 60 days = 5 points each; critical pen test finding over 30 days = 15 points each; end-of-life asset in production = 8 points each; overdue risk register item = 6 points each. Index = total points normalized to a 0–100 scale against a defined maximum.

Status	Criteria
Green	Index under 20.
Amber	20–50.
Red	Over 50, or index increasing for three consecutive periods.

6. Regulatory breach notification exposure

What to measure. The number of active regulatory notification obligations a breach would trigger, combined with the fastest applicable notification deadline, expressed as a composite regulatory exposure rating.

Why it matters. Organizations under overlapping regimes (GDPR plus HIPAA plus SEC plus state privacy laws) face simultaneous, differently-clocked notification obligations. Missing a notification deadline is often the most expensive part of a breach, and it is the part you can prepare for in advance.

Derivation sources:

• Legal or compliance system, or a manually maintained regulatory calendar: applicable regulations and their notification timelines.
• Data inventory: types of data held and which regulations they trigger.
• Incident response plan: documented notification workflow and contact list.
• Outside counsel or DPO input for multi-jurisdiction organizations.

How to calculate. Maintain a table of applicable regulations, their notification windows, and whether a documented workflow exists for each. The KRI value is (number of applicable regulations with a documented, tested notification workflow) ÷ (total applicable regulations).

Status	Criteria
Green	100% of applicable regulations have documented, tested notification workflows.
Amber	80–99%, or the fastest notification deadline is under 72 hours with no tested workflow.
Red	Under 80%, or any applicable regulation with a mandatory notification window and no documented workflow.

7. Third-party risk concentration score

What to measure. The degree to which critical business functions are concentrated in a small number of vendors, specifically vendors whose failure or compromise would cause material enterprise-wide impact.

Why it matters. The CrowdStrike event made vendor concentration risk impossible to ignore. High concentration in a security, cloud, or operational vendor produces correlated losses that no internal control can prevent. For the supporting vendor signals, see the third-party risk intelligence guide.

Derivation sources:

• Vendor management system or third-party risk platform (ProcessUnity, Prevalent, Draxis TPRM module): vendor criticality tiers and dependency mapping.
• Business impact analysis: critical business functions and their vendor dependencies.
• Procurement or finance system: vendor spend concentration as a proxy for operational dependency.
• Network and identity systems: vendor access patterns that surface undocumented critical dependencies.

How to calculate. Identify vendors whose loss would cause a Tier 1 business impact (over 4-hour outage of critical systems, or over $500K immediate financial impact). Count them. Score = (number of Tier 1 vendors with no documented fallback) weighted by criticality tier.

Status	Criteria
Green	Zero undocumented Tier 1 single-vendor dependencies.
Amber	1–2, with documented mitigation plans.
Red	More than 2, or any critical operational function with an undocumented vendor dependency.

8. Insurance coverage adequacy

What to measure. The ratio of estimated maximum probable loss (MPL) from a major cyber event to the cyber insurance policy limit, adjusted for known exclusions and sublimits.

Why it matters. Organizations routinely underinsure their cyber exposure. Finding the gap during a claim, when ransomware recovery exceeds the policy limit or a BEC sublimit covers a fraction of the loss, is an unrecoverable financial surprise. For the broader prep, see the cyber insurance readiness checklist.

Derivation sources:

• Cyber insurance policy: policy limit, sublimits (BEC, ransomware, systemic event), exclusions.
• Broker or actuary: MPL estimate for the organization’s size, industry, and data profile.
• Incident cost modeling: internal estimate of breach cost at different severity levels.
• IBM Cost of a Data Breach and the Verizon DBIR: industry benchmarks for breach cost.

How to calculate. (Policy limit accounting for sublimits and exclusions) ÷ (estimated MPL). A ratio below 1.0 indicates underinsurance.

Status	Criteria
Green	Coverage ratio over 1.2 (policy limit exceeds MPL by a 20% margin).
Amber	0.8–1.2.
Red	Under 0.8, or no MPL estimate performed.

9. Security program maturity trend

What to measure. Year-over-year change in security program maturity, assessed against a consistent maturity model (CIS Controls Implementation Groups, NIST CSF Tiers, or CMMC levels).

Why it matters. Point-in-time maturity matters less than trajectory. A program at IG2 and improving is in a better spot than one at IG2 and flat. Trend data is what auditors, insurers, and the board want to see, and it is what justifies sustained security investment.

Derivation sources:

• Annual assessment against CIS Controls IG1/IG2/IG3 or NIST CSF, scored by a qualified assessor or self-assessed with evidence.
• Security ratings platform: year-over-year score change as an external proxy.
• KRI trend data from this system: aggregate improvement across domains over 12 months.
• Pen test findings year-over-year: reduction in critical and high findings as a maturity signal.

How to calculate. Report the year-over-year delta on the chosen maturity scale. Present it as a trend line with the specific capability improvements driving the change.

Status	Criteria
Green	Measurable improvement year-over-year, with specific capability gains documented.
Amber	Flat. No material change in maturity.
Red	Declining maturity, or no assessment conducted in the last 12 months.

Deriving enterprise KRIs by source type

From SIEM (Splunk, Microsoft Sentinel, Elastic, IBM QRadar)

Compute MTTD by querying earliest_event_time by incident_id against alert_creation_time; the delta is MTTD per incident. Track detection coverage as a count of log sources actively ingesting versus the expected source inventory, run weekly. Watch the alert fatigue ratio, (total alerts) ÷ (alerts resulting in human investigation), since a high ratio signals tuning debt. Useful dashboards: mean-time metrics by incident type, source coverage gaps, and weekly alert volume trend. The security operations KRI guide goes deeper on detection signals.

From vulnerability management (Qualys, Tenable, Rapid7, Wiz)

For the security debt index, export open findings with age, severity, and asset criticality, then apply the scoring formula above. Track critical asset patch compliance by filtering on the asset criticality tag and comparing to the patch SLA. Measure external exposure delta by comparing internet-facing scan results to the approved asset baseline.

From CMDB and asset management (ServiceNow, Ivanti, Axonius)

Measure critical asset inventory completeness by querying for assets where criticality = "critical" and any of owner, classification, or control_assignment is null. Track the end-of-life asset rate by querying for assets whose OS or hardware end-of-life date is in the past. Surface shadow IT by comparing CMDB records to network discovery scan output; the delta is unmanaged assets.

From GRC and risk register (ServiceNow GRC, Archer, OneTrust, Draxis)

Pull regulatory exposure by querying applicable regulations, notification timelines, and workflow documentation status. Track risk treatment currency as the count of risk register items past their review_date or treatment deadline. Feed the risk component of security debt from open risk items with a treatment = "mitigate" status and overdue action dates. The GRC KRI guide covers these in full.

From third-party risk platforms (ProcessUnity, Prevalent, Draxis TPRM)

Build the vendor concentration score by exporting the Tier 1 vendor list, mapping it to business functions, and flagging single-vendor dependencies. Track assessment currency as the date of last assessment per vendor against a 12-month threshold. Trend vendor security ratings quarterly using BitSight or SecurityScorecard scores for critical vendors.

From security ratings (BitSight, SecurityScorecard, RiskRecon)

Use external ratings as a sanity check on your internal KRI scores. Material divergence, where internal scores look strong but the external rating is low, points to a measurement gap worth chasing down. Pull industry peer group data for context in reporting, and run your own organization through the rating tool before an insurance renewal so the number you carry into negotiation is your own, not a surprise.