SYSTEMIC CYBER RISK / INSURANCE LENS
One event.
Several different consequences.
The Lloyd’s and ABI framework gives businesses a useful vocabulary for describing a major cyber event. Use it to improve scenarios and evidence, while keeping insurance coverage a separate question.
A cyber incident rarely arrives with a neat boundary. Several companies may be affected by one supplier failure, while one company may experience disruption, data exposure and recovery costs on different timescales.
Lloyd’s and the Association of British Insurers brought seven components together in their 2024 paper, Components of a major cyber event: a (re)insurance approach. The framework was developed for insurance and reinsurance, but its questions can improve a smaller business’s preparation without turning that business into a catastrophe modeller.
THE EXECUTIVE BRIEF
Use a shared description before arguing about the total.
- Separate what happened, where it reached and the consequences being measured.
- Retain uncertainty about attribution and event boundaries.
- Use the framework for preparation; the actual policy determines coverage.
01
Seven lenses for the same event.
THE INCIDENT NOTEBOOK
Ask a different question with each lens.
WHO
Attribution
What evidence supports an actor or a non-malicious origin, and what remains uncertain?
WHAT
Cause of loss
Which failure, malicious action or system problem produced the relevant consequence?
WHERE
Footprint
Which organisations, services, locations and digital dependencies are affected?
WHEN
Start and duration
Which clock is being measured: intrusion, discovery, service interruption or recovery?
HOW
Spreading mechanism
Did the impact propagate through systems, manual actions or a common supplier?
WHY
Motive
Is a purpose supported by evidence, or merely inferred from the outcome?
IMPACT
Monetary loss
Whose loss, which categories and which period are included?
Framework headings adapted from Lloyd’s/ABI; the questions are CyberSolace business-review prompts. Not every component applies in the same way to every event.
Attribution can remain uncertain while an organisation still needs to contain harm and restore service. Do not make a confident actor name the prerequisite for action. Preserve the evidence and state the confidence of any assessment.
The cause of an event and its motive are different questions. A software deployment can create a serious non-malicious outage; a criminal campaign can cause both theft and interruption. A scenario that assumes every major event is ransomware will miss other important dependencies.
02
A shared dependency can make separate incidents related.
Imagine several businesses relying on the same important technology service. Each has its own contract, recovery team and customers, but the initiating disruption may be common. Counting supplier names in isolation can miss the concentration behind those relationships.
The framework’s footprint and spreading questions help make that distinction. Does the harm spread because malicious software moves between systems, because the same vulnerable product is used widely, or because one service is unavailable to many customers? The answer changes the preparation.
ILLUSTRATIVE SCENARIO
An update fails. The consequences diverge.
Customer operations
Transactions cannot be completed while an important service is unavailable.
Recovery work
Teams need people, access and supported restoration procedures across affected systems.
Commercial consequences
Lost sales, contractual issues and delayed work may continue after the systems restart.
Fictional scenario, not an estimate of a named incident or a modelled probability.
For an SME, the practical work is to identify the handful of dependencies that can prevent an important service from operating. Ask how the supplier will communicate, which workaround is realistic and whether recovery depends on the same failed system.
03
Define the clock before comparing duration.
The time an attacker first gained access is different from the time a service became unusable. Detection, containment, restoration and normal customer operation can each have a different start and end. A single “incident lasted two days” figure can conceal those distinctions.
| Clock | Business question |
|---|---|
| Discovery and assessment | When did the organisation know enough to make a response decision? |
| Service interruption | When did customers lose an important capability, and when was it acceptably restored? |
| Technical recovery | Which systems were restored, validated and returned to managed operation? |
| Continuing consequences | What work, communication or loss remained after the service returned? |
A recovery test should therefore finish with a business acceptance decision. A server running again may not mean that transactions reconcile, staff can work or customers can trust the result. Keep the technical and business outcomes connected.
04
Three loss ledgers that should not be confused.
THE IMPACT RECORD
The policy is not the whole economic event.
BUSINESS LOSS
What did the organisation experience?
Identify interruption, recovery, investigation and other relevant consequences, with assumptions and a defined period.
INSURED LOSS
What does the policy respond to?
Apply the actual wording, limits, exclusions, conditions and adjustment process to the relevant claim.
WIDER IMPACT
What happened beyond the organisation?
Customers, suppliers and the wider economy may face consequences outside that policy and business ledger.
Conceptual distinctions. No amounts, probabilities or coverage conclusions are implied.
The paper is not a universal policy definition or a guarantee that an event will be covered. A useful risk discussion separates the business’s gross exposure from the part it expects to transfer, and identifies the basis for that expectation.
Keep insurer and broker contacts in the incident plan and understand any notification or prior-approval conditions. Specialist advice can help interpret the actual contract; a general framework cannot settle a coverage dispute.
05
Put the lenses to work in one practical exercise.
- Choose an important service and a plausible disruption, including a non-malicious or supplier-led event.
- Describe the event using the seven lenses and mark unknowns explicitly.
- Map the people, evidence, authority and supplier contacts needed to respond.
- Test a minimum useful service and the acceptance criteria for recovery.
- Estimate relevant consequences transparently, then review the insurance assumptions separately.
Do not over-engineer a scenario until it becomes a highly specific story that feels reassuringly unlikely. Vary an assumption: the principal contact is absent, the supplier’s recovery is delayed or the backup is available but an essential identity service is not.
NIST’s 2025 incident-response guidance reinforces the connection between response and wider risk management. The value of an exercise is the gap it helps close and retest, not simply a completed meeting or a neatly filled notebook.
REVIEWED / 20 OCTOBER 2026
The Lloyd’s and ABI framework is an insurance and reinsurance analysis tool. The business scenarios here are illustrative; the framework does not replace the actual policy wording or establish whether a particular loss is insured.
THE CYBERSOLACE PERSPECTIVE
Describe the event well enough to make a decision.
Start with one important service and a credible disruption. The seven lenses can help management see the assumptions that need evidence, ownership or a better recovery plan.
THE ORIGINAL FRAMEWORK
SOURCES & EDITORIAL REVIEW
Research and presentation reviewed 20 October 2026. The SME adaptation is CyberSolace analysis; no insurance coverage or universal event boundary is asserted.