How One Digital Dependency Becomes Many Claims
Commercial cyber insurance is usually purchased by one organisation, but the accumulation risk in a cyber portfolio often begins somewhere else: in a shared cloud service, software component, managed provider, or critical infrastructure node. This chapter explains how that common dependency turns one vulnerability, attack, or outage into simultaneous losses for many policyholders. The goal is to distinguish an unusually expensive claim from a correlated event that can challenge the diversification on which insurance depends.
The distinction is not about the amount of one invoice. A ransomware incident at one firm may be severe but remain largely idiosyncratic, meaning its cause and loss are specific to that firm. A common software vulnerability can produce smaller losses at hundreds of firms and still be more dangerous to an insurer because the claims arrive together. Accumulation is the portfolio effect of a shared cause.
The shared node in the middle
Insurance portfolios are often described as collections of separate policyholders. Digital systems are not organised that way. A manufacturer, a hospital and a bank may be separate customers with separate policies, but they can depend on the same identity service, cloud provider, software library, network security tool or managed-service firm. The dependency is an upstream node shared by otherwise unrelated organisations.
A useful causal chain has four stages. First, the common node develops a vulnerability or experiences a failure. The cause may be malicious, such as an attacker exploiting a software flaw, or non-malicious, such as a faulty update or an internal technical error. Second, the event reaches dependent firms through the service or component they share. Third, each firm experiences its own operational consequences: unavailable systems, lost data, halted production, delayed payments, or an inability to serve customers. Fourth, those consequences become claims under one or more insurance policies.
The chain does not mean that every dependent firm will fail or that every loss will be insured. It identifies where correlation can enter. The common node makes the initial event shared; the architecture and preparedness of each firm determine how much loss follows. One organisation may switch to a backup provider within minutes. Another may have no practical substitute and remain offline for days. One policy may cover the resulting interruption. Another may exclude a supplier outage or impose a narrow limit. Accumulation is therefore shaped by both the digital network and the insurance contract.
This is why geography can mislead. In property insurance, distance often helps separate exposures. A storm in one region does not usually damage buildings on another continent at the same time. A software service, by contrast, can be delivered across borders instantly. Firms in different countries may run the same version of a product and connect to the same cloud region. A portfolio that looks diversified by country can be concentrated by technology.
Technology interconnectedness also crosses industry boundaries. A vulnerability in software used by financial institutions may also affect manufacturers, retailers or public agencies. The effect can travel from an information system into a business process, then into a market or supply chain. The November 2023 attack on ICBC, described in EIOPA’s report, disrupted the firm’s ability to clear trades and was associated with higher volatility and reduced liquidity in Treasury markets. The lesson is not that every software dependency has the same market consequence. It is that a digital component can sit inside a function that other organisations cannot easily replace.
The word “common” is more important than the word “large.” An upstream provider need not be the largest technology firm in the world to create accumulation. It needs to be common enough, important enough, or difficult enough to replace that a failure reaches many insureds before alternatives become available. A smaller specialist provider serving one critical process may be more relevant to a portfolio than a large provider used in non-essential ways.
The reverse is also true. A widely used service does not automatically create a systemic event. Redundant architecture, multiple providers, tested recovery, segmentation and rapid patching can break the chain. The relevant questions are how many insureds depend on the node, how essential the service is, whether the same weakness affects them, how quickly the weakness can be exploited, and whether they can operate while the service is restored.
Five routes from correlation to loss
A software supply chain can distribute one compromise
A supply chain is not only a sequence of physical suppliers. It includes the code, updates and services that organisations receive from other firms. If an attacker compromises a software vendor or its update mechanism, customers may install the malicious or defective component as part of an ordinary maintenance process. The customer’s internal controls may be functioning as designed and still admit the problem through a trusted channel.
The SolarWinds case in the BIS report illustrates this route. The vendor’s Orion update mechanism was compromised, allowing attackers to infiltrate many organisations, including government agencies. The important insurance mechanism is not the name of the software. It is the combination of a trusted supplier, a common update path and many customers that may need to investigate, remediate, replace systems and defend claims at the same time.
Supply-chain accumulation can extend beyond the insured’s direct vendor. A service provider may depend on a software component supplied by another firm, or a managed-service provider may use a common platform across many customers. These “vendors of vendors” are difficult to map. The insured may know that it outsources a function without knowing which underlying component creates the shared exposure. An insurer may therefore receive incomplete information about the number of policies connected to the same upstream risk.
The loss does not have to be identical at every customer. One firm may incur investigation costs; another may suffer business interruption; a third may face privacy claims. The common cause can produce a varied set of covered and disputed losses. That variation makes the event harder to recognise as accumulation while claims are being reported under different policy sections.
A cloud or managed-service outage can interrupt thousands of businesses
Cloud computing and managed services centralise functions that firms once operated themselves. This can improve efficiency and provide access to specialised capability, but it also creates dependence on the provider’s availability, security and recovery processes. When a provider fails, customer systems can remain intact and still be unable to operate.
The BIS report includes a major AWS outage as a non-malicious example that disrupted websites, financial platforms and applications worldwide. The event demonstrates why accumulation is not synonymous with criminal intent. A technical failure at a common provider can generate business-interruption claims across many policyholders even when no attacker stole data or demanded a ransom. The precise insured loss will depend on the policy’s definition of interruption and whether contingent business interruption includes that provider.
A provider outage also creates timing correlation. Claims may begin simultaneously, but their severity depends on duration. A short interruption may be absorbed by a firm’s resilience arrangements. A prolonged outage can exhaust waiting periods, consume extra-expense budgets, disrupt suppliers and create liability to customers. If the provider’s recovery estimate changes, many policyholders may revise their claims together. The insurer must estimate not only how often an outage occurs, but how long a common service might remain unavailable and how many contracts respond to it.
A zero-day vulnerability can compress the time available for defence
A zero-day vulnerability is a software flaw that is unknown, or not yet fixed, when attackers begin exploiting it. It matters to accumulation because the same weakness may exist across a large installed base. Once the flaw is discovered and exploit instructions circulate, many firms may face a race between patching and compromise.
The risk is not determined solely by the existence of the flaw. It depends on whether the affected component is exposed, whether it is essential, whether patches are available, whether firms can test and deploy them, and whether compensating controls work. But common adoption can compress these decisions into a short period. A patching backlog at one firm may be an isolated weakness; a widely deployed, remotely reachable component can create a portfolio-wide exposure.
This route also shows why historical claims data can be a weak guide. The next common vulnerability may affect different software, industries and controls than the last one. The set of firms using the component may not match the set of firms previously observed in claims data. A model trained on past incidents can still be useful, but it cannot assume that the next shared flaw will follow the previous pattern.
Critical-infrastructure failure can turn cyber loss into a public function failure
Critical infrastructure includes systems and assets needed for the security of a nation, its economy, or public health and safety. An attack or failure affecting power, communications, payments or other essential services can create losses beyond the direct operator. A company may be unable to produce goods because electricity is unavailable, or unable to settle transactions because a financial function is disrupted.
This route creates difficult questions for cyber insurance. The policyholder’s own system may not have been breached. The event may be treated as a general infrastructure failure, a cyber incident affecting a supplier, a property loss, or an excluded state-backed or terrorism-related event. Even where a policy responds, the amount of loss may be connected to the duration and reach of the public disruption rather than to the insured’s internal security posture.
The German Federal Office for Information Security example cited by BIS shows the cyber-physical link at a steel mill. Spear-phishing compromised the IT network, attackers reached the plant’s operating system, and the blast furnace shut down in an uncontrolled way, causing major damage. The specific case does not establish a universal pattern for industrial facilities. It shows how a digital intrusion can cross into physical operations, expanding the number of insurance lines and the types of loss involved.
The Internet of Things makes this boundary more common. Connected sensors and industrial devices can improve monitoring and production while creating additional software and communication dependencies. If a cyber event changes the behaviour of physical equipment, the resulting claim may include restoration, business interruption, property damage and liability. An insurer that looks only at data breach frequency can miss the severity created by the physical system.
Mass liability can follow even when operational losses differ
A cyber incident can affect customers, suppliers, employees and other stakeholders at once. A data breach may lead to notification and restoration costs for the affected firm, followed by privacy or regulatory claims. A service failure may interrupt customers’ operations and generate contractual disputes. The direct costs can be distributed across policyholders while third-party claims multiply the number of affected parties.
Mass liability is an accumulation route because many claimants can respond to one underlying event. It can also make the eventual loss harder to measure: an operational interruption may end before all customer and stakeholder consequences are known. The insurer may need to reserve for a set of claims whose number and character evolve over time.
These routes can combine. A compromised software supplier can cause a cloud service interruption, which affects a critical process, creates physical damage at one customer and exposes data at another. A single event can then trigger multiple first-party and third-party coverages, as well as property or crime policies. The aggregation is not simply the sum of identical ransomware claims. It is a network of different consequences linked by one cause.
That is the core difference between an idiosyncratic claim and accumulation risk. In an idiosyncratic claim, the insurer mainly asks how this policyholder was affected. In an accumulating event, it must also ask which other policyholders share the cause, which policy lines may respond, how quickly claims will arrive, and where the exposure has moved through reinsurance. The question changes from “How large is this loss?” to “How many losses can this dependency generate at once?”
Controls can reduce the answer, but they cannot make the question disappear. Segmentation may prevent an upstream problem from reaching critical systems. Backups may shorten restoration. Multi-cloud or failover arrangements may provide a substitute. Vendor governance may reveal concentration before a crisis. Limits, exclusions, coinsurance and tight wording may cap the insurer’s financial exposure. Stress tests may show whether capital and reinsurance remain adequate under a severe scenario.
None of these measures proves that the event is independent. A common provider can still fail; a patch can still be delayed; a backup can still be unusable; several insurers can still share the same dependency; and an exclusion can still create a coverage dispute or move the loss into another policy line. Reinsurance can spread the primary insurer’s burden while concentrating the correlated exposure among a smaller set of counterparties.
The useful conclusion is conditional. Shared digital dependencies do not make cyber insurance pointless. They change what prudent insurance requires. An insurer must map technology concentration as well as industry and geography. A policyholder must understand its dependence on suppliers and the limits of contingent cover. A supervisor must look for accumulation across affirmative and non-affirmative policies. And a stress test must ask what happens when many firms experience the same event, not only what happens to one representative firm.
Once this network mechanism is combined with coverage boundaries, a reader can diagnose a cyber scenario before discussing its price. The next step is to put the two ideas together: identify the upstream dependency, trace the affected firms and loss types, locate the possible policy paths, and decide whether the event is ordinary, correlated, or capable of becoming systemic.