How AnzenOT Quantifies Industrial Cyber Risk

A risk leader asked to brief the board on the company's cyber exposure has two unsatisfying options most days. The first is a colour-coded heatmap that says "high" or "medium" without saying why. The second is a number generated by an AI that came back with $4.3 million of potential loss without showing its work.

Neither is enough to make a capital allocation decision.

The board wants to know three things. What is the most likely scenario that could hurt us? How much would it cost if it happens What does it cost to reduce the probability or the consequence? And they want answers that hold up the next time they're asked, which means the methodology behind the numbers has to be visible, defensible, and consistent.

This is what AnzenOT does. The platform takes a facility description, a threat scenario, and the operator's security posture, and returns a likelihood score, a financial loss distribution, and a costed set of mitigations. Every number has a published lineage. Every adjustment leaves an audit trail. No step is an opaque AI guess.

The rest of this article explains how each of those numbers is produced.

Scenarios are the unit of analysis

A blanket "cyber risk" number for a facility is not a useful object. A 50 MW solar plant has a different exposure to a ransomware operator than to a state-sponsored APT, and a different exposure to a remote vendor compromise than to a malicious insider. Treating these as one number averages signal with noise.

AnzenOT does what insurers and FAIR-trained risk teams have done for years. It models the specific scenarios that matter. An operator describes a concrete event in their own words ("a ransomware affiliate exploits a known VPN vulnerability to reach the engineering workstations and encrypts the historian") and the platform analyses that scenario against the facility's actual
posture.

This is the right unit because it is the unit decisions are made on. A board that approves a budget approves it for specific projects against specific threats. A scenario maps directly to that conversation.

Likelihood comes from a published table, not an opinion

Most risk platforms produce a likelihood score by asking an AI to estimate one. That works until the AI is wrong, at which point there is nothing to defend.

AnzenOT scores likelihood by classifying every scenario along four axes that a trained analyst can defend independently. How capable is the threat actor? How difficult is the attack vector? How mature is the defender's posture? How active are these incidents in the sector?

Each axis has four tiers. The four classifications produce a base likelihood by lookup into a published table. The table is anchored to industry sources (Dragos and Verizon for actor and vector data, NIST and CIS for posture, CISA and sector reports for base rates), and it is the same table for every customer and every scenario.

The AI step that follows is bounded. It may adjust the score by at most two points from the table base, and only with a reason from a published list. If it tries to push further, the platform caps it back to the band and records the attempt. A reviewer who disagrees with the score can re-classify the four inputs and read the matrix directly.

The point is independence. The likelihood number is not what the AI thinks. It is what a published, defensible table returns, with a bounded sanity layer on top.

Loss is a distribution, not a number

A single point estimate of loss is misleading. The most probable outcome of a ransomware event at a manufacturing plant might be $1.8 million, but the worst tenth-percentile outcome could be ten times that. A board allocating capital against the wrong figure will under-insure or over-spend.

AnzenOT models loss as a distribution. Cyber losses are skewed and heavy-tailed (every published dataset of size confirms this), so the platform uses the distribution shape that the actuarial profession, the FAIR Institute, and the Society of Actuaries all converge on for individual-event severity.

What the operator sees on the report is the median, the actuarial mean, the tenth percentile, the ninetieth, the ninety-ninth, and the tail value at risk. Both parameters that drive these numbers are surfaced. The uncertainty coefficient has a published range and floor logic. A scenario that risks a regulatory tail outcome cannot have an artificially narrow distribution. A scenario with multi-day downtime cannot have an artificially confident recovery estimate. The platform forces the distribution wide where the situation justifies it, then records what it did and why.

There is no Monte Carlo. There is no sampling. There is no random seed that produces a different number on a different day. Given the same scenario, the same facility, and the same posture, the platform returns the same distribution. Reproducibility is a methodology requirement.

Recommendations are anchored to a published catalogue

The most common failure mode in AI-generated risk reports is the cost line. The platform recommends multifactor authentication for vendor access. The report says it will cost $90,000. Where did that number come from? Nobody is sure.

AnzenOT recommends from a published catalogue of OT controls. Each entry has a documented cost range anchored to public sources: ENISA NIS2 implementation guidance, CIS Critical Security Controls cost data, US federal contract awards in OT cybersecurity, European procurement records, sector-specific cost guides from CISA and the EPA, NERC CIP compliance surveys, and public vendor pricing. The catalogue cites its sources per control.

The catalogue baseline is not the customer's final number. The platform applies facility multipliers that adjust for the
operator's specific context. The regulatory overhead of the industry matters (pharmaceutical and defence carry validation
burden that food and beverage does not). The maturity of the change-management capability matters (mature programmes execute faster). The regional labour rate matters. Each multiplier is published.

When a scenario surfaces an unusual recommendation that does not match a catalogue entry, the platform flags it clearly. The cost is an AI estimate, not a catalogue number, and the report tell the reader to validate against vendor quotes before committing budget. The distinction matters because it lets the operator allocate budget with confidence to the controls that are anchored and bring scrutiny to the ones that are not.

The AI is the analyst, not the methodology

Generative AI is an excellent analyst. It can read a narrative scenario, identify the relevant techniques, recognise the assets at risk, suggest mitigations, and write a coherent executive summary. AnzenOT uses it for exactly those tasks.

What the AI does not do is generate the numbers. The numbers come from the published tables, the published catalogue, a closed-form loss distribution, and a deterministic reconciliation that runs every cost figure through an actuarial sanity check before it appears in a report. The AI is one input among several, bounded by ranges and reasons that are made visible to the reader.

This is the part that distinguishes AnzenOT from products that wrap a language model in a dashboard. A board can read an AnzenOT report and ask "where did this figure come from?" for every line, and get a traceable answer. A board reading the output of an AI-only platform is asked to take the figure on faith.

What changes when methodology is anchored

Three things change when the methodology behind a risk number is visible and defensible.

The conversation with the board changes. Instead of arguing about whether $4.3 million is the right number, the conversation moves to whether the inputs that produced it are right. The four-axis classification, the facility's declared maturity, the sector's base rate, the uncertainty floor on the loss distribution. These are conversations a risk professional can lead and a CFO can engage with. The output is the consequence of a defensible process, not a single number the audience has to trust or reject.

The conversation with the insurance broker changes. Underwriters who insist on closed-form math (who want to know the median, the mean, the tail percentile, and the loading factor implied by the uncertainty) can read these figures off the report directly. Underwriters who use FAIR or any equivalent vocabulary recognise the methodology and the audit fields. The friction in pricing a programme drops because both sides are speaking the same language.

The conversation with the next assessment changes. When the threat landscape shifts, when a vulnerability moves into active ransomware use, when the facility's posture improves after a control investment, the platform flags the scenarios whose inputs have materially changed and offers a re-analysis path. Old reports do not silently age into wrong reports. The audit trail identifies which methodology version produced which scenario, so a report from last year is still defensible on its own terms while the current report reflects the current state.

How to read a number with confidence

A risk leader who wants to defend a number from an AnzenOT report should be able to do four things. Look at the four-axis classification under the likelihood score and check it against the scenario. Look at the published source citations behind any recommendation cost. Look at the credibility summary on the scenario for any flag that the AI's estimate was reconciled against the closed-form figure. Look at the executive summary for the cost and hours fields the operator can override, which the report carries to make clear that the platform's number is a starting point for informed judgement.

If a number is wrong, it is wrong for a reason that can be inspected and corrected. That is the difference between a defensible methodology and an opaque one.

—-

AnzenOT is built for the operators, risk leaders, and insurers who carry the consequences of getting industrial cyber risk
numbers wrong. The methodology described here applies to every assessment the platform produces.