When Does a Data Refresh Become a Model Change?

When a risk model’s exposure data is refreshed, does that count as a model change for governance purposes?

The answer matters. And it shapes how (re)insurers make underwriting decisions, manage capital, and respond to a threat landscape that moves faster than any peril the industry has traditionally dealt with.

Strong model governance is essential — it provides the stability and auditability required for underwriting, portfolio steering, and capital management. However, the rapid evolution of cyber risk is challenging how that governance works. Security controls improve or deteriorate. Vulnerabilities emerge. Technology footprints shift. Data describing a company's cyber risk posture can become stale in weeks or months, not years.

Yet cyber model governance today often treats refreshed vendor exposure data within a model as if it changes the model itself. This creates a tension: governance requires stability and reproducibility, while underwriting and portfolio management need current information. The industry may be forcing a tradeoff between control and relevance that doesn't need to exist.

This piece explores that tension and asks: Should vendor data refreshes in cyber catastrophe models automatically be treated as model changes for governance purposes, or does cyber require a different framework?

The Current Reality: Data Is Part of the Model

Cyber catastrophe models embed vendor-sourced exposure data directly into the modeled view of risk. This data, which includes company-level security scores, firmographics, technographics, and observed vulnerabilities, is integral to the model.

When this exposure data refreshes, typically with a major model update, it triggers model governance actions. But here's the ambiguity that creates friction — from the model’s perspective, neither its methodology nor its parameters have changed solely due to an exposure data refresh.

From an operational perspective, the output changes and the view of risk shifts. The data refresh is embedded into a full model change, triggering model governance and change management actions. But what if we decoupled exposure data changes from a major model update?

This distinction matters because cyber data is improving constantly. Security posture vendors get better at identifying exposed services. Technographics providers refine industry classifications. Underlying telemetry becomes more granular and current. However, if each exposure refresh bumps into governance frameworks as a full model change, organizations face an impossible choice: accept governance overhead that slows decision-making, or keep data locked and older than preferred.

Property Cat vs. Cyber: A Useful Comparison

In traditional catastrophe modeling, this question is usually manageable. A model has defined methodology, a calibrated view of risk, and exposure inputs. When a (re)insurer improves exposure data — better geocoding, updated construction details, more accurate replacement values — outputs may change, but the model itself hasn't changed.

The convention holds because the boundary is clear. Building characteristics are observable, standardized, and relatively stable. They're exposure facts, separable from methodology.

Cyber challenges that convention. The "building characteristics" in cyber, such as security controls, vulnerabilities, software configurations, and threat actor interest, move fast and are harder to observe at scale. The data improving faster creates a second problem where the line between exposure data and the sub-models that process it becomes blurrier.

For example, is a security risk score considered exposure data, or is it a sub-model? If the scoring methodology is unchanged and only the telemetry refreshed, it's closer to exposure data. But if the scoring logic itself evolved, that's methodological. In cyber, these boundaries aren't pre-established, so when data refreshes happen, there's legitimate ambiguity about whether that constitutes a model change.

The Core Tension: Stability vs. Relevance

Two legitimate needs collide here.

Governance requires stability, reproducibility, and auditability. You lock down a model version, validate it, deploy it, and that version remains your source of truth for 12 to 24 months. This is sound governance.

But underwriting and portfolio management operate differently. An underwriter evaluating a renewal needs the current security posture of that account. A portfolio manager steering the book needs visibility into whether risk quality has improved or deteriorated since binding. A capital team needs to know whether the portfolio looks the same as when those policies were written.

This matters in cyber specifically because a company can meaningfully shift its security posture within a single policy year. They can deploy multi-factor authentication, reduce exposed surfaces, and remediate critical vulnerabilities. Or they can deteriorate quickly through acquisitions, unmanaged cloud migrations, or newly exposed infrastructure. The risk at inception may look materially different from the risk at renewal, and not because the model changed, but because the company changed.

If your model view is locked to last year's data vintage, you're managing the portfolio using an increasingly stale snapshot.

Where This Breaks: At the Point of Decision

The problem surfaces throughout the insurance lifecycle.

At the account level: an underwriter knows that an account has improved or deteriorated its security posture. However, the portfolio model reflects older exposure data, which creates a disconnect between modeled view and known current risk. Do you refresh the model itself to get a current view? That triggers governance. Do you work around the model? That undermines the point of having one. Do you establish a separate view of risk for underwriting? That invites inconsistency.

In portfolio steering: a portfolio manager wants to know whether risk quality has shifted since policies were written. A static model view cannot answer that question easily. You'd need to re-run the entire portfolio against refreshed data, which feels like a model change, even though you haven't changed how the model works.

The practical consequences include underwriting friction, misaligned pricing or capacity decisions, and internal challenges between teams. This directly affects underwriting and portfolio quality.

The Key Question: What Counts as a Model Change?

A true model change — a shift in how methodology works, how it calibrates, how it translates exposures to losses — absolutely should be governed carefully. The territory in between is murkier.

One useful question to ask is whether you need to distinguish between three distinct categories:

• Model methodology changes
• Sub-model changes (engineered features that feed into the model)
• Data refreshes (updated inputs to unchanged model logic)

The issue isn't update frequency, but rather classification and governance. Current definitions may be creating unnecessary constraints.

A useful starting point requires defining raw exposure data, sub-models, and the core catastrophe model.

Raw security telemetry (observable signals about technology footprint, exposed services, security configurations, and patching posture) describes the risk being modeled. Like building characteristics in property cat modeling, these are exposure facts.

Risk quality scores or control scores may themselves be sub-models. They transform multiple raw signals into structured assessments and influence frequency, severity, scenario susceptibility, or other outputs.

That distinction is important. A change to the scoring methodology, or a change in how that score feeds into the catastrophe model, likely counts as a model or sub-model change. The same applies if raw telemetry feeds into a model parameter requiring expert judgement. Either should be governed accordingly.

If only the underlying telemetry refreshes while the scoring methodology and catastrophe model methodology remain unchanged, it should be considered an exposure change. This aligns with how the industry treats improved exposure data in property cat modeling — the model simply processes updated exposures through an unchanged methodology.

Cyber should adopt a similar principle while recognizing that the boundary between data, sub-model, and model must be explicitly defined and governed.

An Emerging Direction: Separating Views of Risk

The tension (re)insurers face is that the market needs models stable enough to govern but dynamic enough to remain decision-useful. The industry doesn't need to choose between locked models and current data.

One approach separates model governance from data currency through three complementary views:

The locked model calibration view is your baseline measuring stick. This is the stable view associated with the latest approved release (typically annual or biennial). It supports governance, validation, capital modeling, reserving, regulatory discussions, and reproducibility. It answers the question: what does the approved model say about the portfolio using the embedded data vintage?

The bound or renewed account view uses the latest available security data at bind or renewal and locks that view for the policy term. This aligns with underwriting reality. If current security telemetry exists when a policy is written, it should be usable for decision-making, provided methodology and scoring framework are unchanged and data vintage is recorded. It answers: What did we believe about this risk when we made the underwriting decision? And how do those underwriting decisions aggregate across the portfolio?

The latest point-in-time portfolio view applies current technology and security data across all in-force policies to provide an up-to-date view of risk. It answers: How healthy is my portfolio today?

Together, these three views create a stepwise understanding of risk movement. The locked calibration provides the governed baseline. The bound account view shows how risk looked at entry. The point-in-time view shows whether the account or portfolio has improved or deteriorated since then.

This progression helps (re)insurers separate changes caused by model version, changes caused by risk selection at bind or renewal, and changes caused by movement in security posture. It supports portfolio steering, risk engineering prioritization, accumulation monitoring, and more informed discussions between underwriting, exposure management, and capital teams.

Governance Should Evolve, Not Disappear

This approach doesn't abandon governance. It makes governance more precise.

A catastrophe methodology change is one category. A risk quality scoring algorithm change is another. A refresh of raw telemetry or exposure data is another. Each may require governance, but not necessarily the same governance pathway.

To maintain robust oversight, governance frameworks would need to explicitly formalize these perspectives, ensuring validation and control protocols match how each view is actually used.

Better data only creates value if it can be used. Treating every vendor data refresh as a full model change may preserve procedural consistency, but it slows decision-making and leaves (re)insurers relying on stale views of a fast-moving peril.

(Re)insurers should maintain a stable, validated model view for formal governance while using refreshed exposure data to support underwriting and portfolio decisions. You need to version the model, the sub-models, the data, and be clear about which view is used for which decision.

What This Means for the Industry

The path forward requires evolving governance frameworks to match the velocity of cyber perils. By formally codifying the distinction between methodology changes and exposure data refreshes, (re)insurers can unlock the value of point-in-time insights without sacrificing institutional rigor. By explicitly governing model methodology and data currency as distinct but complementary layers, they can build a more resilient and decision-useful foundation for cyber underwriting and portfolio management.

This is an opportunity to improve both risk insight and decision speed. Early movers can gain operational advantage, but it requires industry collaboration.

A Fundamental Rethink in Cyber

Should vendor exposure data refreshes in cyber catastrophe models automatically be treated as model changes for governance purposes, or does cyber require a different framework?

Addressing this isn't about abandoning governance. It's about evolving how governance is applied — and the answer will shape how (re)insurers make underwriting decisions, manage capital, and respond to a threat landscape that moves faster than any peril the industry has dealt with.

The industry won't settle this in one conversation. It happens between underwriters and modelers, exposure managers and capital teams, data providers and clients — and CyberCube is one of the parties having it. The goal isn't consensus. It's clarity about what stability means and what flexibility looks like when cyber risk can shift materially within a single policy year.

One test cuts through the ambiguity: run the same portfolio through a locked calibration and a refreshed-data view side by side. The gap between them shows how much of your "model risk" is really just data currency. The (re)insurers who work it out first — who can tell a model change from a market that's moved — will be making faster, better-informed decisions while others wait on their next model version. And CyberCube stands ready to support the industry with this next evolution of cyber risk analytics.