The cost of a faster recovery

After the cyberattack, who pays? · Part 8/8

Testing recovery can itself affect a service, while higher budgets leave the hours saved to be measured. TSB’s records, European bank tests and a British policy appraisal expose the decisions made before a crisis, the evidence behind them and the questions still open.

Before TSB’s IT migration, a few hours of cash-machine availability became part of a decision about testing. To put the application under load in its intended configuration, the bank would have had to use both of its production data centres and interrupt some services already running. Its cash machines, for example, would have been unavailable for about three to four hours. TSB ultimately agreed to test just one centre, while the other continued serving customers. Reconstructed by the British regulator in its December 2022 decision, that choice offers a concrete way into the economics of preparedness. 1

After the migration on 22 April 2018, the two-centre configuration contributed to the difficulties customers encountered. A login could reach one centre and the next transaction the other, where the corresponding session was missing. Part of the service therefore relied on an interaction between systems that the restricted test had left without a representative trial. The Prudential Regulation Authority, or PRA, concluded that the bank had lost an opportunity to identify some of the faults. It remained appropriately cautious about what the test would actually have revealed. 1

TSB is a comparison case here: the actual disruption followed a failed IT migration. Its relevance to a series about the consequences of cyberattacks lies in a shared question: what service will an organisation be able to provide when its usual systems fail it? Having followed losses, suppliers, insurers and a public guarantee, this final part moves back to the period before a crisis, when a business decides what resources to commit to shortening its consequences.

Testing already puts part of the business at stake

TSB’s decision had an immediate rationale: keep existing services running while preparing for the full migration. According to the PRA, the bank took confidence in the ability of one centre to handle the load as evidence that the whole arrangement would work. Yet the architecture used both centres simultaneously and required each session to remain in the right place. Traffic-routing rules and an incorrect configuration of the OpenAM authentication component undermined that mechanism. 1

The case helps explain why counting standby equipment gives an incomplete picture of its usefulness. In a system built from many components, the difficulty may lie in an interaction: a user authenticated here, a transaction routed elsewhere, an application waiting for a response it can no longer obtain. A representative test has to expose those relationships. Its cost may include engineering time, an environment capable of reproducing production conditions and, when the live service has to be involved, a planned interruption. The intended benefit is actionable information obtained early enough to correct the faults.

Another passage in the decision describes a different kind of preparation. The executive exercise held in March 2018, known as a Gold exercise, included a simulated ransomware attack and assumed that the service provider, SABIS, was working on repairs. The exercises envisaged resolution within days; the provider was not required to participate. This crisis-management exercise needs to be considered separately from the technical load test. It gave executives practice in making decisions, while the speed of repair depended on work assigned to others. 1

Method and scope

The TSB record separates two forms of preparation. Load testing was confined to one data centre to preserve existing services; after migration, routing faults between the two centres affected sessions and failover. The Gold crisis-management exercise separately assumed prompt repairs by SABIS, whose participation was not required. Ransomware was part of that simulation. The actual April 2018 incident followed an IT migration. The PRA describes a missed opportunity for detection; neither the cost of an adequate test nor the losses it might have prevented is established.

Figure fonts and licences

Figure fonts: Inter Variable and JetBrains Mono Variable, under the SIL Open Font License 1.1. Inter · JetBrains Mono.

The 2018 accounts indicate the scale of the post-migration damage: £330.2 million in additional expenses and waived income, before the estimated contractual recovery from Sabis. That total includes £122.4 million for additional resources and advice. It describes the accounting consequences of a crisis, encompassing several kinds of expenditure and loss; the price of the omitted test, and the share of the damage it might have prevented, remain unknown. 2

A useful comparison would therefore be between preparedness options whose full costs and demonstrated capabilities were understood. Converting these charges into a daily cost would produce an appealing quotient while leaving the question of avoidable damage unanswered. In its response to the regulators on 20 December 2022, TSB apologised again, and its chief executive said that the bank had been transformed over the preceding four years. That corporate position forms part of the historical record; our documentary research examines the mechanisms established for 2018. 3

From restored systems to a usable service

To determine what preparedness buys, the first task is to decide when recovery will count as complete. NIST’s contingency-planning guide distinguishes the target recovery time for an IT resource, the Recovery Time Objective, or RTO, from the total disruption the business can tolerate, the Maximum Tolerable Downtime, or MTD. Within that total period, the RTO should normally leave time for work such as reprocessing data. The Recovery Point Objective, or RPO, instead identifies the point in the past to which data recovery is intended to reach. These concepts allow different questions to be asked of the same backup. 4

An application restored with older data may open successfully while leaving recent transactions to be reconstructed. Teams may also have continued some of their work through manual procedures during the interruption. Guidance published by the National Cyber Security Centre on 1 October 2026 describes precisely this problem: restored data has to be reconciled with records created while operations were running in a reduced mode. It also calls for the sequence in which services restart to be planned, since those services depend on shared resources such as identity systems, networks and storage. 5

Consider, as an illustration, a service that temporarily records its transactions in a separate register. Restoring the main database makes automated processing possible again, after which reconciliation begins: locating missing transactions, identifying duplicate entries and checking the relevant totals. This teaching example describes a dependency in the recovery process; it assigns neither a particular duration nor a JLR-specific procedure to it.

Method and scope

RPO sets the intended data recovery point before an outage. RTO concerns an IT resource; business operations also need time for data reprocessing. The mechanism brings together backups and records created during manual workarounds, with dependency checks and validation. Positions are qualitative: no JLR-specific target or achieved duration is assumed. A dated test with defined scope and validation criteria can compare targets with demonstrated capabilities.

Measurement then becomes much more informative. A test report can specify the volume actually restored, the access available to the operators, the dependencies included and the checks used to accept the result. A written target becomes meaningful when a team tests it against that work. NIST calls for data and functionality to be validated before recovery is declared complete. 4

The requirement remains current. In observations published on 27 March 2026, the Financial Conduct Authority notes progress and investment in resilience, while finding that some firms claim they can recover across all scenarios without presenting tests severe enough to support that assurance. The document provides a supervisory observation but no sample count from which its prevalence could be calculated. It underlines the value of assessing the ambition of a target separately from the strength of the evidence behind it. 14

Supervision changes spending decisions

The European Central Bank subjected this capability to a collective assessment in 2024. Its scenario assumed a successful attack that severely damaged core databases. Preventive defences were treated as having been bypassed so that the assessment could focus on response and recovery. Of the 109 participating banks, 28 had to conduct a dedicated IT recovery test based on the scenario, as part of an enhanced assessment that included an on-site visit. The other 81 submitted questionnaires and evidence, including results from earlier, similar tests. 6 7

The two groups describe the depth of the assessment. The ECB explains that the selection of 28 banks sought a range of countries and business models, rather than ranking institutions by cyber risk. In its findings, published on 26 July 2024, it observed that response and recovery frameworks were in place, then called for improvements in banks’ ability to meet their own objectives and assess losses. The public results explain those requirements; they provide no average recovery time that could be converted into a cost per hour saved. 6 7

A working paper published by the Bank for International Settlements on 26 May 2026 examines another consequence of the intervention: the response in spending. Using supervisory data, the researchers work with a panel of 96 participating banks. They compare 2019–2021 with 2023–2024, around the announcement of the test in March 2023. They exclude 2022 because the corresponding returns were submitted around the time of that announcement. Their financial variable captures annual operating expenditure on IT security. 8

Method and scope

The ECB exercise splits its 109 banks into 28 enhanced and 81 standard assessments: these are protocols, not pass rates. A separate study uses 96 participants. The authors estimate a roughly 81% relative increase in IT security operating expenditure for banks classified as lagging, compared with peers’ change after the announcement. The classification uses a predicted-spending model, and the interpretation depends on the method’s assumptions. No recovery hours saved are inferred. Calculation: 100 × (exp(0.596) − 1) = 81.4845%, rounded to about 81%. Table 6, column 5: PPML estimate using 465 observations; the lagging group has mean residuals at or below the pre-announcement median. These are the authors’ results, subject to the model’s identification assumptions.

The main result concerns banks the model classifies as lagging before the announcement, based on the gap between their spending and the level predicted from their characteristics. For this group, the authors estimate a relative increase in expenditure of about 81% after the announcement, compared with the change at the other banks. The method seeks to distinguish a particular catch-up in spending from a general increase in budgets. Its interpretation depends, among other things, on the assumption that the groups would have followed comparable trends without the intervention being studied. 8

That is a substantial finding about the influence of supervision: announcing a test can change budget decisions before the exercise itself takes place. Its financial meaning nevertheless depends on retaining the definition of the variable. Security operating expenditure covers a range of activities; the share devoted exclusively to restoring a service faster remains unknown in this estimate. In their descriptive before-and-after comparison, several operational indicators produce less precise results. Recovery times come from the annual IT risk questionnaire, concern reported incidents and are published as indices. These data cannot yield recovery days saved or a price for those days. 8

For an executive, the distinction points towards a programme of follow-up measurement. When more money goes into security, it becomes useful to state the outcome expected from each effort: making intrusions harder, containing their spread or restoring operations more quickly. These outcomes can reinforce one another, but each requires an appropriate form of observation. An increase in the budget marks the beginning of that assessment.

An insurance claim tells a different story

Cyber Essentials, the British certification scheme, illustrates the difficulty of turning a favourable indicator into a promise of results. In its 2025 annual review, the NCSC reports a 92% lower likelihood of making an insurance claim among certified organisations, based on insurer data. The documents consulted do not establish the precise comparison period, the sample sizes or the adjustments between groups. They report an insurance-claims statistic, which should retain that scope. 13

The programme evaluation published in October 2024 discusses the wider attribution problem. Its evidence includes 606 current or former users and 516 organisations that had never been certified, surveyed in autumn 2023. The authors examine practices, perceptions and contractual uses, while considering participant selection and the difficulty of measuring rare or underreported incidents. They conclude that the programme has value, although translating it into monetary terms remains difficult. 12

These observations can inform a prevention decision. Answering the question of faster recovery would require another measure alongside them: among organisations whose operations were actually interrupted, what activity resumed, under what conditions and after how long? The frequency of an insurance claim also depends on coverage and on whether the loss is reported. A buyer who distinguishes these stages can welcome a favourable finding without making it carry every promise attached to a security programme.

A threshold that exposes the assumption

The British government faces a similar difficulty when estimating the effects of proposed legislation. The impact assessment for the Cyber Security and Resilience Bill, updated in May 2026, sets out compliance costs and expected benefits while leaving those benefits outside the main monetised assessment. For a group that includes managed IT service providers and data centres newly brought into scope, it reverses the question: how many attacks would have to be prevented each year to offset the expense? 9

The central calculation compares roughly £120 million in annualised direct costs with a benchmark incident cost of £1,101,588. Dividing one by the other gives about 109 additional attacks prevented per year, the threshold published in Table 8.4. The figure makes the assumption open to scrutiny: under the conventions used, the policy would need to produce a benefit of that size to absorb the cost being considered. It remains an illustrative threshold, whose future achievement would have to be measured. 9

Method and scope

The impact assessment updated on 13 May 2026 uses £120 million in annual costs for newly covered MSPs and data centres, then divides it by a £1,101,588 incident-cost proxy. It publishes a central threshold of about 109 additional attacks avoided each year. The curves show this arithmetic and the published ±20% incident-cost sensitivities, with no assigned probabilities. The KPMG proxy comes predominantly from US data, converted to sterling at PPP and modelled for large information-sector firms with turnover above £65 million. Regulatory costs use 2025 prices, while the proxy uses 2024 prices; the threshold is reproduced with this difference and no added adjustment. It describes a condition for breaking even, while the measures’ causal effect and recovery time remain to be measured. Central calculation: 120,000,000 ÷ 1,101,588 = 108.9336, rounded to about 109; published sensitivities: 120,000,000 ÷ 881,270 = 136.1671 and 120,000,000 ÷ 1,321,906 = 90.7780. The counts 136, 109 and 91 reproduce the table’s rounded values, rather than exact integer minima.

The origin of the incident-cost figure deserves closer examination. The KPMG report used by the government relies mainly on US data, converted into pounds at purchasing-power parity and expressed in 2024 prices. The selected amount corresponds to a large company in the information sector, with size defined by turnover. It provides an economic proxy for a regulated population with different characteristics. Its construction uses geometric means, which give extreme losses less weight than an arithmetic mean would. 11

Another convention remains visible in our illustration: compliance costs are expressed in 2025 prices, while the incident cost taken from the model remains in 2024 prices. We reproduce the published ratio with that difference intact, rather than inventing a reconciliation that the document does not make explicit. The precision displayed in the denominator allows the arithmetic to be checked; it does not turn the threshold into an exact forecast. 9 11

The Regulatory Policy Committee’s opinion helps establish the status of this exercise. Dated 18 July 2025 and published in November, it concerns an earlier version of the assessment. The committee accepts an analysis based on qualitative benefits and thresholds, while noting that the number of attacks prevented cannot be estimated and asking for some assumptions to be made clearer. Its judgement concerns the quality of the proposed evaluation, with its limitations, rather than a return already observed from the provisions assessed in May 2026. 10

Businesses can draw on that reasoning if they retain their own question. For a measure intended to accelerate recovery, the benefit sought is the difference in damage between two paths back to normal activity, weighted by the incident scenarios under consideration. Preventing an attack altogether and shortening an interruption after a successful attack are different economic effects. The public threshold of 109 offers a way to discuss assumptions; it leaves the losses that faster recovery could actually prevent to be estimated.

Buying a capability that can be demonstrated

The first task is to define the service the organisation wants to preserve or restore. An activity may become usable at a reduced level before every function returns. To make that level observable, the organisation needs to specify the operations it will accept, the volumes it can handle and the checks that are essential. Work can then proceed backwards from that outcome to the resources it requires, following the impact and dependency analysis described in continuity-planning guidance. 4 5

This approach changes the conversation with a provider. A promise of restoration becomes more useful when accompanied by a test protocol: what data will be reinstated, which components will be available, which teams will take part and who will accept the restored service? TSB shows the importance of this chain of responsibility. Executives can rehearse their decisions while technical resolution remains an assumption in the scenario. Bringing the relevant operators into the exercise allows that assumption to be tested against the constraints they face. 1

Activity that continues during the outage also deserves attention. The findings from the sector-wide CST24 exercise, published by the Bank of England in July 2025, describe the dilemma some participants faced over temporary workarounds: these could keep operations moving, but make later reconciliation more difficult. The discussions also identified the time needed to obtain sufficient assurances from a third party before reconnecting. This was an exploratory exercise using data and workshops; its conclusions illuminate dependencies rather than a recovery time observed during a shared outage. 15

An option that appears faster on the first day may therefore shift work into the next phase. To compare two approaches to preparedness, the assessment has to follow the chain through to the outcome that matters for the business. The economic calculation should distinguish transactions eventually caught up with from those lost permanently, then examine the margin preserved, the additional costs and the contractual consequences of the particular scenario. That approach avoids treating every hour of unavailability as an identical slice of revenue lost.

The costs set against those benefits should cover a comparable period. A test environment, repeated exercises and the availability of specialist teams commit resources on different schedules. A purchasing proposal can set out those expenses alongside the planned tests and the findings that would trigger corrective work. When a test exposes a fault, the information obtained must be able to change the system before an incident occurs. That is how testing becomes a means of reducing future damage.

The benefits extend beyond the organisation paying

The end of this series returns to those who bear the consequences of an outage while having no say over the preparedness budget. The British impact assessment explicitly invokes harm to third parties, imperfect information and coordination failures as reasons for public intervention. A business may capture only part of the benefit its continuity brings to customers and their own users. The amount it is willing to spend of its own accord may therefore differ from the amount justified by the full range of avoidable losses. 9

That gives an economic reason to prepare for recovery even when the precise return is difficult to isolate. It also requires a decision about the boundary of the assessment. The purchaser’s accounts, continuity for its customer and the functioning of a network of businesses may show different outcomes. An investment that benefits the wider system deserves to have its effects measured beyond the organisation paying the bill.

The documents assembled for this final part trace a concrete decision at TSB, an estimated change in bank spending and an explicit threshold in public policy. The decisive work still lies in connecting those observations to the hours of recovery actually saved. It begins with a defined business activity, proceeds through a representative test and is checked with the people who will be able to restore the service. For an organisation paying before a crisis, the most productive question becomes: what new capability will it be able to demonstrate, and what share of the damage will that capability allow it to avoid?

The eight-part investigation

1. JLR’s factories and cash flow
2. Credit for suppliers
3. Cyber insurance and customer disruption
4. JLR’s footprint in GDP
5. The economics of restarting operations
6. Shared providers
7. Public crisis financing
8. The cost of a faster recovery. You are reading the final part.

For the distinct planning targets, see RTO, data recovery RPO and MTD.

Research method and limitations

This article draws on documentary research closed on 19 October 2026: regulatory decisions, published accounts, technical guidance, research papers and public evaluations. The source notes distinguish the dates of incidents, fieldwork and publication. TSB’s statements and the insurance statistic reported by the NCSC remain attributed to their originators. No interview or restoration test was conducted for this article.

The notes below provide the relevant passages, dates and limitations of the documents used. Figure notes explain scopes and reproducible calculations. The BIS paper’s spending estimate, the assessment counts and the British economic threshold measure different things. The UK model’s differing price bases and populations remain explicit; differently scoped internal aggregates are excluded from the numerical narrative. This investigation establishes neither the costs nor the durations of a JLR-specific preparedness programme.

Documentary sources

1. [1] Prudential Regulation Authority / Bank of England · Final Notice to TSB Bank plc · Document: 2022-12-20 ; Published: 2022-12-20. Annex A, §§ 4.25–4.43, pp. 53–58 (architecture and testing); §§ 7.18–7.23, pp. 75–76 (Gold exercises); Annex C § 1.9(2), p. 89 (return to business as usual). Printed pages match the PDF counter. The regulator describes the decision to confine load testing to one data centre, session-persistence faults in the active-active configuration, and the limits of crisis-management exercises. The actual event was an IT migration in April 2018; ransomware was part of a March 2018 exercise. The PRA describes a missed opportunity for detection, without guaranteeing that the omitted test would have revealed the fault. Its findings on preparedness combine several failings. They quantify neither the cost of a suitable test environment nor avoidable losses.
2. [2] TSB Banking Group plc · TSB Banking Group plc : Annual Report and Accounts 2018 · Document: 2019-01-31 ; Published: 2019-02-01. P. 2, reconciliation and footnotes 2–3; p. 10, Charges arising from post migration service disruption; p. 17, Operating expenses; p. 65, approval. PDF counter is one page ahead. The accounts distinguish £296.7m of additional operating expenses and £33.5m of waived income, totalling £330.2m of recognised post-migration effects. An estimated £153.0m recovery from Sabis offsets part of those effects. The £417.3m migration-preparation charge is a separate item. Nominal 2018 income-statement amounts, including provisions: they are neither contemporaneous cash payments nor a comprehensive economic loss. Waived income covers interest and fees forgone by TSB. Recovery is estimated and offset against amounts payable to Sabis. This reconciliation identifies no stand-alone resilience budget. Accounts approved on 31 January 2019 (p. 65); results announced on 1 February 2019. The first upload timestamp for this PDF has not been established.
3. [3] TSB Bank plc · TSB responds to the FCA and PRA findings in relation to the 2018 Migration Programme · Document: 2022-12-20 ; Published: 2022-12-20. Statement body, dated 20 December 2022. TSB confirms an agreement with the regulators. Its chief executive renews the apology to affected customers and says the bank has transformed its business since the events. The bank’s position, included as a response to the findings. The statement does not independently demonstrate the effectiveness of later recovery measures.
4. [4] National Institute of Standards and Technology (NIST) · NIST SP 800-34 Revision 1 : Contingency Planning Guide for Federal Information Systems · Published: May 2010; updated: 11 November 2010. Section 3.2.1, printed pp. 17–18 (PDF pp. 31–32); section 3.5.1, pp. 27–28 (PDF 41–42); section 4.4, p. 41 (PDF 55). Defines recovery time objective (RTO), recovery point objective (RPO) and maximum tolerable downtime (MTD). Data reprocessing must fit within the business limit. Tests should approximate the operating environment; recovered data and functionality must be validated before normal operation. US federal information-system guidance, published in May 2010 and updated on 11 November 2010. Used for terminology and planning mechanics, without presenting it as a duty binding JLR. Figure 3-3 is conceptual and provides no measured economic optimum. NIST catalogue for the updated final edition.
5. [5] UK National Cyber Security Centre (NCSC) · Preparing for highly disruptive cyber incidents : 3. Prepare your technical recovery capability · Document: 2026-10-01 ; Published: 2026-10-01. Sections 3.2–3.4 and 3.6; Published / Reviewed box: 1 October 2026. Restoration must reconcile backup data with data generated during manual workarounds. The guidance calls for dependency and restart-sequence planning, together with the assurance required before reconnection. General guidance published after JLR’s 2025 incident; it explains a mechanism without diagnosing JLR’s systems. It supplies neither a universal recovery time nor a causal estimate of hours saved.
6. [6] European Central Bank : Banking Supervision · FAQ on 2024 cyber resilience stress test · FAQ accompanying the results of 26 July 2024. Questions “What scenario did the stress test use?”, “What kind of information did banks report to the ECB?”, “How did you select banks for the enhanced assessment?” and “How will the ECB use the insights gained from the exercise?”. 81 banks supplied questionnaires, documentation and evidence from earlier IT recovery tests with a similar scenario; 28 additionally had to perform a dedicated recovery test and receive an on-site visit. The enhanced sample covered countries and business models, rather than being selected by cyber risk. The 81/28 split describes assessment requirements, not pass rates. The exercise was predominantly qualitative; individual feedback and follow-up do not form a public dataset of comparable recovery times.
7. [7] European Central Bank : Banking Supervision · ECB concludes cyber resilience stress test · Document: 2024-07-26 ; Published: 2024-07-26. 26 July 2024 release: scenario, 109-bank sample, assessed capabilities and supervisory follow-up. The scenario assumed failed preventive defences and severe damage to core-system databases. The ECB found response and recovery frameworks in place while identifying improvements, including meeting banks’ own recovery objectives and estimating losses. The public summary gives no mean recovery time, time distribution or bank ranking. Results fed into the 2024 SREP without affecting Pillar 2 Guidance. Missing public numbers tell us nothing about confidential bank-level results. Annual Report 2025, section 1.2.2.1. The 2025 follow-up describes generally sound preparedness and areas needing further effort, without supplying an average recovery duration.
8. [8] Nordine Abidi, Leonardo Gambacorta, Christoffer Kok, Leonardo Madio, Ixart Miquel-Flores and Alberto Partida / Bank for International Settlements · Disciplining digital risk: evidence from cyber stress tests : BIS Working Paper No 1351 · Document: 2026-05 ; Published: 2026-05-26. Pp. 12–15: sample and operating-expense definition; pp. 18–20: identification; table 3 p. 22; table 5 p. 24; table 6 p. 25; conclusion p. 33. Printed pages match PDF pages. Uses confidential ECB data; the stated final panel covers 96 banks. The main result estimates an approximately 81% relative rise in annual IT security spending among banks classified as laggards after the announcement, compared with peers. The 45% before/after result and the conditional differential estimate answer different questions. Working paper reflecting authors’ views, not an official BIS position. Underlying data are not public; identification depends on model assumptions, rather than random assignment. “Investment” means euro-denominated operating expenses. Recovery times are disclosed as indices without absolute days; table 5’s differential change is imprecise (p = 0.619) and supplies no cost per hour saved. The paper reports 96 banks and 475 observations before regression attrition: these counts cannot reconstruct a complete panel.
9. [9] Department for Science, Innovation and Technology / UK Parliament · Cyber Security and Resilience (Network and Information Systems) Bill: Final stage impact assessment, updated 13 May 2026 · Document: 2026-05-13 ; Published: 2026-05-14. Printed pp.79–80: horizon and benefits; pp.90–93, tables 8.3–8.5: illustrative thresholds; pp.95–96: costs in 2025 prices; pp.122–124 and 134: inconsistent scorecard and annex; p.133: signature dated 13 May 2026. The assessment calculates how many additional attacks would have to be avoided to offset compliance costs. For MSPs and data centres: £120m a year, a £1,101,588 incident-cost proxy and a published central threshold of about 109 attacks a year. Benefits remain unmonetised because the causal effect cannot be quantified. Ex ante illustration, without a prediction of avoided attacks or a recovery-time measure. Compliance costs use 2025 prices; the incident proxy uses 2024 prices, with no explicit reconciliation found. ±20% is a chosen sensitivity, without probabilities. Page 122 reports -£1,203m in “2025 present value”; the p.134 annex reports -£1,201m with a 2026 PV base. These amounts are kept separate. Some designated critical-supplier costs and later measures remain outside the headline totals. The cover retains the original 12 November 2025 date below a 13 May 2026 update notice; signed on 13 May; Parliament’s catalogue lists 14 May publication. The GOV.UK link consulted still serves an earlier version. Parliamentary timetable checked on 19 October 2026. The Bill remains before the Lords; report stage is scheduled for 26 October, still in the future at this research cutoff.
10. [10] Regulatory Policy Committee · RPC opinion: Cyber Security and Resilience (Network and Information Systems) Bill impact assessment · Document: 2025-07-18 ; Published: 2025-11-17. Pages 1–2: green rating; p.3: reservations on the initial submission; p.7: unmonetised benefits and assumptions; p.8: EANDCB and distribution of effects; pp.9–10: future evaluation. The RPC considers the assessment fit for purpose. It acknowledges that avoided attacks cannot be estimated, accepts a qualitative case and illustrative break-even thresholds, and asks for more detail on several assumptions and calculations. This 18 July 2025 opinion reviews a preparatory version; it certifies neither realised returns nor all May 2026 amendments. The publication page says the rating concerns evidence and analysis rather than the policy itself. Opinion dated 18 July 2025, published 17 November 2025.
11. [11] KPMG LLP for DSIT / DCMS · Economic modelling of sector specific costings of cyber attacks · Document: 2025-04 ; Published: 2025-11-12. Printed pp.1–4: method and units; pp.9–10: limitations; pp.15–17: Cyentia data; pp.25–30: geometric mean and allocation; table 4.11 p.30 (PDF p.36): £1,101,588 for large information-sector firms. The IA’s incident-cost proxy comes from a model relying predominantly on US Cyentia data, converted to sterling at purchasing-power parity and uprated to 2024 prices. Size is defined by turnover, with the large category exceeding £65m. Sector and size inputs rely on geometric means followed by modelled allocation. This is neither an observed arithmetic mean of 2026 UK incidents nor a carmaker’s recovery cost. It assumes comparable UK and US costs and conditions on a significant attack. The underlying sample emphasises publicly visible incidents. A geometric mean cannot automatically replace an arithmetic expected loss. Report dated April 2025, fieldwork completed 31 March 2025 according to the notice, published by DSIT on 12 November 2025. Underlying Cyentia window: 2012–2021; data release: 2022; reference prices: 2024.
12. [12] Pye Tait Consulting for the Department for Science, Innovation and Technology · Cyber Essentials impact evaluation · Document: 2024-10-23 ; Published: 2024-10-23. Sections 2.1–2.4: comparison, attribution, fieldwork, weighting and bias; section 7.5: perceived supply-chain reduction; section 10: value and costs; appendix 2: respondent profiles. A survey of 606 current or lapsed users and 516 never-certified organisations, with common fieldwork from 2 October to 6 December 2023, complemented by 33 interviews. It documents perceptions, behaviours and contractual uses while explicitly discussing difficulties in measuring attack frequency and establishing full causality. Users participate non-randomly through certification bodies, with an unknown response rate; no detailed matching and potential confounding. Size/nation weighting of the comparison group does not neutralise all selection. The user group comprises 532 current and 74 lapsed users. The report finds value without demonstrating a quantified ROI or recovery days saved. Published October 2024; surveys October–December 2023; three case studies extended into December 2023–January 2024. Costs repeated in section 10 come from the process evaluation published in June 2023.
13. [13] National Cyber Security Centre · NCSC Annual Review 2025: Empowering organisations : NCSC tools and services · Document: 2025-10-14 ; Published: 2025-10-14. Cyber Essentials section, paragraph before “10 years of Cyber Essentials”: 92% statistic attributed to the insurer. The 15 November 2024 NCSC supplement identifies it as the provider of the insurance bundled with certification. The NCSC relays a 92% lower likelihood of an insurance claim for certified organisations, based on the insurer’s data. The endpoint is a claim, with no recovery duration supplied. The same statistic was published in 2024 and remains on the GOV.UK page updated in March 2026. The precise comparison period, group sizes, detailed coverage and group adjustment are not provided in the consulted documents. The scheme’s promoter relays insurer data; no public microdata were found enabling its causal effect to be isolated. The Annual Review’s coverage period must not automatically be assigned to this statistic. Annual Review covering September 2024–August 2025, published 14 October 2025; the 92% statistic’s observation period is not specified. A 15 November 2024 NCSC post already contains the same value.
14. [14] Financial Conduct Authority (FCA) · Operational resilience: insights and observations one year on · Document: 2026-03-27 ; Published: 2026-03-27. Introduction; “Operational resilience and boards’ decision-making”; section 3 “Scenario testing”, especially “Areas for improvement”; “Impact tolerance” glossary entry. Following the 31 March 2025 transition deadline, the FCA reports progress and investment but also firms claiming to recover from every scenario without documenting sufficiently severe tests. It values clear methods, assumptions, recovery times and confidence levels in test outputs. Observations from some firms’ self-assessments, without a stated sample size or quantified frequency of weaknesses. The findings cannot count vulnerable firms. The regulatory scope is financial services, not all industrial businesses.
15. [15] Bank of England / Prudential Regulation Authority · Thematic findings from the 2024 Cyber Stress Test · Document: 2025-07-09 ; Published: 2025-07-09. Pp. 1–2: protocol and three variants; pp. 3–4: workarounds, priority transactions and reconciliation; p. 6: reconnection. CST24 was voluntary and exploratory: data submissions and workshops modelled compromised transaction integrity. Some participants preferred to stop processing because workarounds would complicate reconciliation; assurance for safe reconnection could take longer than their own impact tolerances. Scenario findings, not a company’s actual outage duration or a sector average. The source does not show that every workaround delays recovery; it records a trade-off and calls for available capabilities to be tested. The letter is publicly published despite a standard classification notice.

Original text and illustrations: l0g · CC BY 4.0. Cited documents retain their publishers’ rights.