Building Cyber Risk Quantification In-House vs. Buying a Platform

A team that can write a Monte Carlo simulation over a loss distribution can build a cyber risk quantification model in a few weeks. The mathematics is undergraduate statistics and the code is not the obstacle.

‍

Three other things are, and each one outlasts the build. Loss data good enough to calibrate against, the work of keeping the model current once the person who wrote it moves on, and documentation that holds up when somebody who did not build it starts asking questions.

‍

Why Is Loss Data the Binding Constraint?

‍

Because the organization cannot generate it, and the sources that can are not free.

‍

Internal History Is Too Thin

‍

Cyber loss events are rare for any single organization, so an internal incident record carries almost no signal about annual likelihood and even less about severity at the extreme end. A model calibrated on that history describes a sample too small to support the curve it draws.

‍

External Data Has to Be Licensed

‍

Industry loss databases exist and are bought rather than assembled, which converts a build into a build plus a subscription. The data then has to be mapped onto the organization's own asset and control structure before it can calibrate anything.

‍

What That Does to the Cost Comparison

‍

The question stops being whether to buy and becomes which part to buy. An organization licensing loss data and building a model around it has bought the expensive component and kept the maintenance, which is the least favorable arrangement of the three available.

‍

What Does Maintenance Involve?

‍

More than updating figures, because the threat landscape moves independently of the model.

‍

The Recurring Work

‍

Frequency assumptions need revisiting as attack patterns change, severity distributions need revisiting as costs move, and the control mapping needs revisiting whenever the estate does. None of that is difficult and all of it is somebody's standing responsibility.

‍

The Dependency Nobody Plans For

‍

Models built internally tend to have one author. When that person changes role, the organization holds a model it depends on and cannot confidently modify, which is the point at which most internal builds quietly stop being updated.

‍

What the Symptom Looks Like

‍

A figure that has not moved in three quarters while the estate has changed considerably. A figure that stops tracking reality does not announce itself, which is what makes the decay hard to catch.

‍

What Happens When It Faces an Audit?

‍

The part most build decisions underestimate, particularly in regulated sectors.

‍

A Built Model Becomes a Model

‍

In a bank, a quantification model developed internally falls under model risk management. The revised interagency guidance issued in April 2026 expects independent validation, documentation of assumptions and limitations, and ongoing monitoring, applied on a risk-based basis proportionate to the organization.

‍

What That Requires in Practice

‍

Somebody who did not build the model has to be able to evaluate it, so the documentation has to be written for a reviewer rather than for the author. A second line that cannot evaluate the work produces a signature rather than a validation, and an examiner knows the difference.

‍

Why a Purchased Model Differs

‍

Vendor documentation becomes an input to validation rather than a substitute for it, so the institution still owns the risk. The difference is that the methodology documentation already exists and was written to be read by somebody external.

‍

Who Should Build?

‍

A narrow set of organizations, identifiable in advance by what they already run.

‍

• An existing quantitative function: People who build and validate models as their ordinary work rather than as a project.
• Established model governance: Documentation standards, independent review and a validation cycle already operating.
• A reason the market cannot serve: An unusual exposure structure or a methodological requirement no vendor meets.

‍

Why All Three Matter

‍

The first two make maintenance and defensibility survivable. Without the third there is no reason to spend them on this rather than on something only the organization can do.

‍

What the Function Needs to Look Like

‍

At least two people who understand the model, a documented validation performed by somebody outside the build, a stated review cadence and an owner who is not the author. A single capable person is a dependency rather than a function.

‍

Is There a Middle Option?

‍

Two, and both are commonly overlooked in a binary framing.

‍

Buy the Data, Build the Application

‍

Licensing loss data and event catalogs while building the organization's own scenario logic and reporting on top. It suits organizations with a quantitative function and an unusual structure, and it carries the full maintenance burden.

‍

Buy the Model, Run It Internally

‍

A managed arrangement where the vendor supplies and maintains the model while the organization keeps the analysis and the decisions. A managed program removes the maintenance without removing the internal capability, and what a managed platform adds covers how that arrangement runs.

‍

What Should the Comparison Count?

‍

Four costs, and only the first appears in a build proposal.

‍

The build itself, which is the smallest of the four. The loss data license, which is recurring and unavoidable. The maintenance commitment, expressed as a named person's standing time rather than as a project. Then the validation and documentation burden, which is proportionate to the regulatory environment and is zero only outside it. Total cost of ownership works through the purchased side of the same arithmetic.

‍

What Should Be Established First?

‍

Three things, and the first usually settles it.

‍

Whether an organization already runs a quantitative function with model governance, since building without one means building that too. Which loss data the model would calibrate against and what it costs, because internal history will not serve. Then who validates the model and who maintains it after the author moves on, named rather than assumed. Cyber risk quantification as a purchased capability and the method underneath it are documented for organizations comparing against their own build.

‍

The Model Is the Cheap Part

‍

A capable team can build a working quantification model quickly, which is why the build is a poor basis for the decision. Loss data is the binding constraint, since internal incident history is too thin to calibrate against and external databases are licensed rather than assembled, so an organization that builds has usually bought the expensive component anyway. Maintenance is a standing commitment that tends to rest on one author and stops quietly when that person moves on. In regulated sectors a built model becomes a model under model risk management, requiring independent validation and documentation written for a reviewer. Building suits organizations that already run a quantitative function, already have model governance, and have a reason no vendor can serve.

‍

To compare a purchased quantification against what building one would commit you to, book a demo with our cyber risk experts.