CEM ROI Calculator

This worksheet is for security leaders building a business case for a continuous exposure management (CEM) program or platform, often framed as continuous threat exposure management (CTEM). It helps you replace vendor benchmark claims with your own numbers, so finance can check every input. Use it before a purchase decision, then again six months after rollout with actual data.

The risk calculation uses the standard quantitative formula: annualized loss expectancy (ALE) equals single loss expectancy (SLE) multiplied by the annual rate of occurrence (ARO).

How to use this calculator

1. Collect twelve months of baseline data for every input below.
2. Use low, likely, and high estimates instead of single numbers, and present the range.
3. Have finance validate the cost inputs and security validate the risk inputs.

Step 1: Baseline inputs

• □ A. FTEs working on vulnerability and exposure management (scanning, triage, reporting, chasing remediation).
• □ B. Fully loaded cost per FTE (salary, benefits, overhead).
• □ C. Share of their time spent on manual work such as deduplication, correlation, and reporting. Estimate it with a two-week time sample.
• □ D. Annual cost of tools the program would retire or consolidate.
• □ E. Hours per year spent producing vulnerability evidence for audits.
• □ F. Incidents in the last three years where a known, unremediated exposure was the root cause, and the average cost of each (response, downtime, recovery, legal, notification).
• □ G. Total annual program cost: licenses, implementation amortized over three years, and staff time to operate it.

Step 2: Formulas

Illustrative example only: 4 FTEs × 150,000 fully loaded × 40% manual time × 50% expected reduction gives 120,000 per year in labor savings. Replace every number with your own.

Step 3: Operational metrics to track

Dollar figures need supporting evidence. Track these alongside the model, organized around the CTEM stages of scoping, discovery, prioritization, validation, and mobilization:

• □ Mean time to remediate exploitable, business-critical exposures, not all findings.
• □ Discovery coverage of critical assets, including cloud, SaaS, and internet-facing systems.
• □ Share of findings validated as exploitable through attack path analysis or testing.
• □ Open exposures listed in the CISA Known Exploited Vulnerabilities catalog past your remediation SLA.
• □ Time from discovery to owner assignment, which measures mobilization.

Common pitfalls

• Using vendor benchmark percentages as your inputs. They come from other environments; use them only to sanity-check your estimates.
• Counting vulnerabilities closed instead of risk reduced. Closing thousands of low-impact findings can leave the real attack paths open.
• Ignoring remediation effort. Better prioritization often increases fix work for engineering teams at first.
• Double-counting risk reduction already claimed in the business case for another control.
• False precision. A single ROI figure invites argument; a defensible range earns trust.