Definitions
Terms used in this paper
These definitions establish how the paper uses its core terms before the argument begins.
- Operational state
- A current description of observed cybersecurity conditions, controls, evidence, exposure, or trajectory.
- Actuarial loss probability
- A probability or distribution tied to a defined insured outcome and calibrated against appropriate exposure and loss data.
- Frequency
- The occurrence rate of a defined event or loss outcome.
- Severity
- The magnitude of loss conditional on an event occurring.
1. Two different questions are often collapsed into one score
A security leader may ask whether control state is improving. An underwriter may ask how that state changes expected frequency or severity of insured loss. Those questions are connected, but the second does not follow automatically from the first.
An operational cyber metric can summarize observed controls, evidence quality, exposure, or trajectory. An actuarial model needs an empirically defensible relationship between explanatory variables and defined loss outcomes. The output may be a frequency distribution, severity distribution, expected loss, or another pricing input. Calling an operational score a probability does not create that relationship.
NIST's enterprise risk guidance reinforces the importance of documenting assumptions, scenarios, likelihood, impact, and uncertainty. The discipline applies equally here: a measurement should state what it represents before someone uses it in a downstream financial decision.
- Operational question
- What condition is observed now, what changed after intervention, and is improvement supported over time?
- Actuarial question
- How likely is a defined event over a defined period, and what loss could follow under the relevant terms?
Operational measurements may inform actuarial work. The conversion requires defined outcomes, exposure populations, loss data, and validation.
Operational state supplies an actuarial input. Validation establishes its relationship to loss outcomes.
2. Why the distinction matters for cyber insurance pricing
Pricing combines more than cybersecurity posture. Policy language, limits, attachment, retention, revenue, industry, geography, data exposure, historical loss, legal environment, aggregation, and market conditions can all matter. A strong security signal may improve the quality of one part of the underwriting view without replacing the rest of the model.
The distinction also protects model development. If an operational index is first treated honestly as a state variable, its history can be tested prospectively against outcomes. Researchers can examine discrimination, calibration, stability, lag effects, and interaction with other underwriting variables. The evidence can then support or reject actuarial interpretations rather than assuming them in advance.
For insureds, this avoids the equally problematic promise that a favorable score should mechanically produce a particular premium. Insurers retain underwriting and pricing authority. The value of better operational evidence is that it gives those decisions a stronger factual basis.
3. Frequency and severity should remain separate
Cyber losses are heterogeneous. A control failure may affect incident frequency, severity, recovery cost, business interruption duration, liability exposure, or several dimensions at once. A single scalar that does not state which outcome it is calibrated to can hide more than it explains.
The NAIC cybersecurity insurance market report illustrates why insurance analysis separates premiums, claims, losses, expenses, policy counts, and coverage structures. Operational cybersecurity data should enter that discipline with equally explicit definitions.
For example, stronger privileged-access enforcement might plausibly reduce the probability or blast radius of some attack paths. Faster verified recovery might affect interruption severity more directly than initial compromise frequency. Those are hypotheses to test, not meanings that should be silently embedded in one cyber score.
4. A useful interface between security telemetry and actuarial work
The interface begins with stable definitions. Security data should preserve source, observation time, control meaning, missingness, and changes in measurement methodology. Outcome data should define event, loss, development period, and exposure base. Cohorts and observation windows should be fixed before results are interpreted.
The next step is prospective testing. Historical backtests are useful for exploration, but repeated forward checkpoints are harder to overfit. If an operational signal consistently separates higher- and lower-loss cohorts under defined conditions, the actuarial case strengthens. If it does not, the model should change.
This is a slower path than marketing a security score as a loss probability on day one. It is also the path more likely to produce a signal that security teams, actuaries, brokers, and regulators can argue with constructively.
5. The boundary makes both products more credible
VitalSec's Risk Compression Index is an operational control-state index, not an actuarially calibrated probability of breach or insured loss. The Ford Model describes modeled risk direction from Enforcement, Proof Continuity, Decay, and Adversarial Pressure. Those outputs can be studied alongside loss experience, but their operational meaning should remain intact until evidence supports a broader interpretation.
The benefit of that restraint is practical. Security operators can use the measures for intervention without waiting for an insurance model. Insurers can test the measures without surrendering pricing judgment. Researchers can preserve falsifiability because the variable does not change meaning every time a new business use is proposed.
Good measurement architecture therefore has an explicit seam between observed cyber state and actuarial inference. That connection is where validation happens.
Evidence base
Sources and notes
External foundations are kept distinct from VitalSec implementation notes so readers can see what supports the argument independently and what documents the platform implementation.
External foundations and sources
VitalSec implementation notes
These links document how the argument is implemented or described inside VitalSec. They are not offered as independent validation of the paper's thesis.
