The Risk-Appetite Test for Technology Supply-Chain Dependencies

Setting Board-Level Risk Appetite for Shared Technology Dependencies

A board that has never set an explicit limit on technology vendor concentration has, by default, an unlimited appetite for it. That is rarely a deliberate decision, and it is exactly the gap a risk-appetite test is meant to close.

How should boards define risk appetite for shared tech dependency?

As a specific, quantified concentration limit, not a general statement of concern about technology risk.

An effective appetite statement names a maximum acceptable share of the portfolio exposed to any single vendor, cloud region, or critical service provider. Without that number, "we are concerned about technology risk" gives underwriting and treaty teams nothing concrete to act against. What the executive committee must ask about technology supply-chain risk makes clear that specificity, not general concern, is what separates a managed program from an unmanaged one. Once a number exists, breaches of it become measurable events the organization can actually respond to.

What stress scenarios reveal true concentration exposure?

A simulated major outage at a specific vendor or cloud region, modeled against the portfolio's real, current dependency map.

CyberCube's analysis of a major AWS outage highlighted "the scale, duration, and geographic concentration of the disruption," centered on a single cloud region, as the exact profile boards should be stress-testing against. Modeling that kind of scenario using generic industry assumptions, rather than the organization's own dependency data, will understate the true exposure. The Exposure Concentration Risk AI Agent can run this kind of scenario directly against the current book, giving the board a realistic number rather than an industry-average estimate. A board that has only seen a generic industry stress scenario has not actually tested its own risk appetite.

How does regulatory designation of critical providers change appetite setting?

It gives boards an external, independently validated signal of which providers already carry systemic status.

The EU's supervisory authorities have formally designated critical ICT third-party providers under DORA, describing them as providers with "a pivotal role within the financial ecosystem." That designation is a useful external input for a board's own appetite-setting process, since it confirms which dependencies already carry regulatory-grade systemic weight. Boards do not need to build this assessment entirely from internal judgment when regulators have already done part of the work. Ignoring an official designation in internal risk appetite setting would be difficult to defend to a regulator later.

What governance triggers should prompt a portfolio review?

Three specific events: a concentration threshold breach, a regulatory designation change, or a major outage at a dependent vendor.

Defining these triggers in advance means the board reacts to a pre-agreed plan, not to whatever is happening in the news that week.

How should this appetite flow into treaty and retro structuring?

By pointing hedging spend directly at whichever vendor concentrations sit closest to, or beyond, the board's approved limit.

Once a concentration threshold is breached or approaching, that is precisely where retro or ILW cover should be targeted first. This turns risk appetite from a passive statement into an active input for purchasing decisions each renewal cycle. It also connects directly to the earnings-stability argument in the earnings-volatility effect of technology supply-chain dependencies, since well-targeted hedging is what narrows that volatility. Appetite statements that never influence actual purchasing decisions are not really governing anything.

What accountability sits with the risk committee versus underwriting?

The risk committee owns the threshold itself, while underwriting owns enforcing it day to day at the point of binding.

This split mirrors how other risk appetite limits already work inside most reinsurers, and there is no reason technology concentration should be treated differently. The risk committee's job is to set and periodically revisit the number, informed by stress testing and regulatory input. Underwriting's job is to check every new binding against that number, using the same Cloud Security Posture Assessment AI Agent data already used for individual account review. Splitting ownership this way means enforcement happens continuously, not just at the annual board review.

How should this be reported to rating agencies?

As a specific, quantified limit with evidence of active monitoring, not a qualitative assurance that the topic is being watched.

Rating agencies respond more favorably to a concrete threshold and a demonstrated monitoring process than to a general statement of awareness. This mirrors the reporting approach recommended for treaty wording risk in what would break first if cyber event definitions worsened, where specificity also outperforms general assurance. Being able to show the actual dashboard used to monitor concentration, rather than describing it in a narrative, tends to shorten these conversations considerably. Preparation here pays off well beyond the immediate rating discussion.

How should risk appetite differ between pure-play cyber and diversified multi-line reinsurers?

A pure-play cyber reinsurer needs a tighter concentration limit than a diversified multi-line reinsurer, since the same vendor failure represents a much larger share of its total book.

For a reinsurer writing mostly cyber business, a major cloud or SaaS outage can affect a large proportion of the entire portfolio at once. A diversified multi-line reinsurer can typically absorb the same event more easily, since technology-dependent exposure is only one part of a broader book. That does not mean diversified reinsurers can ignore the risk; it means their appetite threshold can reasonably sit at a different level, calibrated to what technology exposure represents within their specific mix. Setting one flat concentration limit across very different books is less useful than calibrating the threshold to each reinsurer's actual portfolio composition.

What board education is needed before this appetite conversation can happen well?

Board members need a working, non-technical understanding of cloud concentration and single points of failure before they can meaningfully approve a numeric threshold.

Without that grounding, board approval of a concentration limit risks becoming a formality rather than an informed decision. A short briefing built around real, well-documented examples, such as the CrowdStrike outage or a major cloud provider's regional disruption, tends to build this understanding quickly and concretely. This should not be a one-time briefing, since the technology landscape and the vendors that matter most continue to shift over time. Boards that revisit this education periodically are better positioned to ask sharper questions the next time the appetite threshold comes up for review.

How should smaller reinsurers calibrate this appetite without a large peer-benchmarking dataset?

Smaller reinsurers can calibrate an initial threshold using their own historical largest-loss scenario as a proxy, refining it as better market data becomes available over time.

Peer-benchmarking data for technology concentration risk specifically is still immature across the market, which leaves smaller organizations without an easy external reference point. Rather than waiting for that data to mature, a reinsurer can model its own worst historical loss scenario and use that as a starting reference for an initial concentration limit. That internally-derived threshold will not be perfect, but it gives the board something concrete to govern against now, with room to refine it as industry benchmarks eventually develop.

How should appetite be revisited when a major new technology trend emerges?

Emerging concentration points, such as widespread reliance on a single dominant AI platform provider, should trigger an appetite review outside the normal annual cycle, not wait for the next scheduled one.

Technology adoption trends can shift a market's underlying concentration faster than an annual governance calendar is built to track. A new platform that a large share of an industry rapidly standardizes on can become a material concentration point well before the next scheduled appetite review would have caught it. Boards should authorize an out-of-cycle review trigger specifically for this kind of fast-moving technology shift, separate from the fixed triggers already covering outages and regulatory designations. Waiting for the calendar to catch up to a fast-moving technology trend means governance is always reacting a cycle behind where the real exposure already sits.

What does a well-governed technology dependency program look like a year from now?

A board that can state its concentration limit, name its top monitored vendors, and demonstrate a tested response plan for a breach.

That combination is the practical output of everything covered across this batch: the diagnosis in why reinsurance leaders misdiagnose technology supply-chain dependencies, the monitoring control in how to build an early-warning system for technology dependencies, and the appetite-setting discussed here. None of it requires the board to become technical experts in cloud infrastructure. It requires only a willingness to put a number on a risk that, until now, most boards have only discussed in general terms.

Risk appetite that is never quantified is not really appetite at all, just an assumption waiting to be tested by the next outage. Boards that put a real number on technology supply-chain concentration now will be the ones setting the terms of that test, rather than being surprised by it.

Sources

• Bank of England / PRA, "Operational resilience: Critical third parties to the UK financial sector" (CP26/23)
• EIOPA/ESAs, "European Supervisory Authorities designate critical ICT third-party providers under DORA"
• CyberCube, "AWS Outage Highlights Systemic Risk from Cloud Concentration"