主题 3.9 — 业务连续性与灾难恢复

在医疗与照护领域,一次重大系统中断首先是一起患者安全事件,其次才是一个 IT 问题,因此你在系统宕机期间维持照护交付、并全面快速地恢复它的能力,是一项核心的临床与公众信任能力,而不是一个技术性的脚注。

为什么这在医疗与照护领域很重要#

照护不会因为技术停止而停止。当一份电子病历、一个电子处方平台,或一个化验结果系统在一家医院范围内失效时,临床医生不能在工程师工作期间暂停治疗。他们必须继续接诊患者、开具药物、做出决策——常常没有那个失效系统通常会提供的过敏警报、剂量检查与既往病史。这就是为什么一次中断不仅仅用宕机小时数与服务积分来衡量;它是用延迟的诊断、遗漏的药物相互作用、被取消的手术,以及每一位盲目工作的临床医生所承担的额外风险来衡量的。业务连续性是确保在最坏的情况发生时,照护依然尽可能安全的学科。

其利害关系是全国性的,且有据可查。2017 年的 WannaCry 勒索软件攻击扰乱了英格兰大约三分之一的 NHS 信托机构,迫使数千次预约与手术被取消,救护车被改道,并把员工锁在了他们治疗患者所需的设备之外——包括一些影像与病理设备。它让 NHS 付出了估计 9200 万英镑的代价,更重要的是,它表明一次针对医疗基础设施的网络攻击,落地时是一场临床危机,而不仅仅是一起数据安全事故。从那时起,韧性问题已经从服务器机房走上了董事会的议事桌,这是理所当然的。

本主题延伸了主题 3.8——服务管理与线上运营中的运营学科,但把重点从日常运行转向重大中断:威胁让一项关键服务瘫痪数小时或数天的火灾、洪水、网络攻击、供应商倒闭,或区域性中断。它与主题 1.7——信息治理、数据保护与网络安全紧密相连(因为勒索软件恢复现在是一个核心的连续性场景),与主题 4.0——技术架构、云与遗留系统相连(因为韧性是被设计进去的,而不是事后附加的),也与主题 6.4——治理与保证相连(因为必须有人拥有、测试并对这份计划负责)。把这件事做对,一次中断就会变成糟糕的一天;把它做错,它就会变成一场公开调查。

核心概念#

业务连续性与灾难恢复。 业务连续性规划(BCP)是在一次破坏性事件期间及之后,以预先定义的可接受水平持续交付产品或服务——在你的情境中,即安全的照护——的能力。IT 灾难恢复(DR)是更狭窄的技术子集,关注恢复支撑这些服务的系统、数据与基础设施。业务连续性是更宽泛的承诺("患者持续获得治疗");灾难恢复是其中一种手段("结果系统在四小时内恢复")。你两者都需要,而且绝不能把一台已恢复的服务器与一项已恢复的服务混为一谈。

业务连续性管理与业务影响分析。 业务连续性管理(BCM)是一个持续的管理过程——而不是一份一次性的文件——用于识别威胁并构建组织韧性。它的基础是业务影响分析(BIA):对每一项服务的结构化评估,追问失去它会以多快的速度造成不可接受的伤害、它依赖什么,以及你能够承受多长时间的数据损失。BIA 是临床判断进入工程领域的地方:必须由临床医生、而不仅仅是技术人员来定义,一个产科系统与一个员工内网,"不可接受"分别意味着什么。

恢复时间目标与恢复点目标。 两个数字支撑着每一份恢复计划。恢复时间目标(RTO)是一次失效后恢复一项服务的最大可接受时间。恢复点目标(RPO)是以时间表达的最大可接受数据损失量——15 分钟的 RPO 意味着你最多能容忍丢失最后 15 分钟的录入内容。对于一个关键临床系统,这些可能是几分钟;对于一个报表仓库,可能是几天。诚实地、逐项服务地设定它们,是你将做出的单一最有用的连续性决策。

备份与经过测试的恢复。 备份是存放在别处的数据副本,以便原始数据丢失后能够被恢复。行业的基准是3-2-1 规则:三份副本,存放在两种类型的介质上,其中一份存放在异地(在勒索软件时代,还有一份保持不可变或离线)。至关重要的是,一份你从未恢复过的备份,只是一种期望,而不是一项管控。勒索软件常规地加密任何能从网络访问到的备份,未经测试的恢复也常规地在那一天失败。这门纪律不是"我们做备份了吗?",而是"我们上一次成功地端到端恢复是什么时候,花了多久?"

高可用性、冗余与故障转移。 高可用性(HA)是一种设计属性,让一个系统在组件失效时依然保持运行,通常以正常运行时间的"9"的个数来衡量。它是通过冗余——刻意复制关键组件——以及故障转移——在主组件失效时自动切换到一个备用组件或站点——来实现的。高可用性降低了中断的频率;灾难恢复处理那些依然穿透过来的中断。它们是互补的,而不是替代的,把它们混为一谈会留下危险的缺口。

单点故障与关键依赖。 单点故障(SPOF)是任何一个其失效会让整项服务停摆的组件——一条网络链路、一项身份验证服务、一个供应商、一个数据库,或唯一一个知道某件事如何运作的人。绘制单点故障与关键依赖(你的服务默默依赖的上游服务与第三方)是韧性分析的核心。在现代医疗 IT 中,依赖关系很少是本地的:一个单点登录服务、一条国家脊柱连接,或一个云区域,可能同时拖垮许多系统。

临床宕机与业务连续性流程。 医疗与照护领域拥有一个通用 IT 所没有的独特管控:临床宕机流程,一个经过演练的、安全的——通常是纸质的——在一个数字系统不可用时交付照护的后备方案,加上一旦系统恢复,把那份纸质记录核对回系统中的重新录入流程。这是业务连续性在病床边被具体化的地方,也是连续性计划最常与现实相遇的地方。

勒索软件与网络恢复。 勒索软件加密你的数据并索要赎金,它已经成为医疗系统面临的决定性连续性威胁。2017 年的 WannaCry 勒索软件攻击是参考案例:这就是为什么网络恢复——隔离、从干净的备份重建,并在重新连接之前验证完整性——如今是每一份严肃计划中的头等场景。

连续性标准。 ISO 22301 是业务连续性管理体系的国际标准。它提供了一个公认的结构——情境、领导力、规划、支持、运营、评估、改进——用于构建与审计连续性能力,无论你是否寻求正式认证,它都是一个有用的支柱。

最佳实践#

1. 从一份由临床医生、而不仅仅是 IT 拥有的业务影响分析出发。 按一项服务失效所造成的临床伤害、以及这种伤害变得无法容忍的速度,对每一项服务进行排序,然后为每一项分配一个具体的 RTO 与 RPO。与承担后果的临床医生及运营经理一起做这件事,因为"我们能安全地在没有它的情况下运行多久?"是一个照护问题,而不是一个基础设施问题。产出是一份有优先级的清单,告诉你应当把有限的韧性预算首先花在哪里。

2. 让韧性与关键性相称地设计。 让工程与影响相匹配:任务关键型系统(急诊科、患者管理、电子处方)值得拥有高可用性、地理冗余与自动故障转移;关键性较低的系统可以接受更长的恢复时间与更简单的备份。要抵制对关键系统工程不足、也要抵制对琐碎系统过度设计。架构与连续性必须一起设计(见主题 4.0——技术架构、云与遗留系统),因为你无法在事后把韧性附加到一个脆弱的设计上。

3. 搜寻单点故障与隐藏的依赖关系。 系统性地绘制每一项关键服务的依赖关系——网络、身份验证、DNS、国家连接、电力、冷却、关键供应商与关键人员——并识别一次失效会在哪里引发连锁反应。特别关注诸如单点登录或一个共同集成引擎之类的共享服务,它们的失效会同时拖垮许多系统。一个你没有绘制出来的依赖关系,就是你将在中断期间才发现的依赖关系。

4. 备份要能挺过勒索软件,并通过测试来证明恢复能力。 遵循 3-2-1 规则,并至少保留一份不可变或物理离线的备份副本,这样一个抵达你网络的攻击者就无法加密你最后一道防线。然后按计划测试恢复,依据你的 RTO 计时,并依据你的 RPO 验证数据完整性——一次花了两天、却对照一个四小时目标进行的恢复,是一项你只是还没注意到的失败管控。把"上一次成功的完整恢复"当作一项你报告的指标,而不是一项你想当然的任务。

5. 编写、配置资源并演练临床宕机流程。 为每一个关键临床系统维护一份经过测试的纸质(或离线)后备方案,让员工能在中断期间继续交付安全的照护,再加上一个之后重新录入这些数据、不遗漏也不重复的清晰流程。把宕机表格存放在网络与打印机也宕机时依然能够取用的地方。与一线员工一起演练它们,因为一个只存在于文件夹里的流程,不会在凌晨三点的危机中被找到、被理解,或被信任。

6. 维护一份带有真实站点故障转移的灾难恢复计划。 为每一个关键系统记录它究竟如何恢复:什么在哪里运行、以什么顺序,谁决定启动它,以及之后你如何故障回退。在影响足以证明其合理性的地方,运行一个真正独立的恢复站点或云区域,并证明你能够切换到它——恢复顺序很重要,因为系统之间的依赖关系决定了顺序。一个未经测试的灾难恢复站点,是一个昂贵的假设。

7. 演练这份计划;一份从未测试过的计划就是一份会失败的计划。 在一个谱系上运行定期演练:桌面式场景走查、技术性故障转移测试,以及偶尔的、包括临床后备方案在内的全面实景模拟。演练会揭示出缺口——过时的联系人清单、需要一个没有人拥有的密码的恢复步骤,以及员工知道纸质流程这个假设——趁着发现它们是安全的时候。捕捉教训,修复它们,并重新测试;一次没有后续行动的演练只是一场表演。

8. 把连续性延伸到你的供应商与云端。 你的韧性,只与你关键服务所依赖的第三方一样强,因此要把连续性当作一项合同与保证事项:要求供应商提供他们自己的 RTO/RPO、DR 测试与网络恢复证据,并理解你的云提供商的共担责任模型——可用区与区域能防范一些失效,但无法防范你自己造成的一次配置错误或账户被攻破。要为供应商自身的失效做规划,包括一个关键供应商自己就是被勒索软件攻击的对象这一场景(见主题 6.3——采购与商务)。

9. 采纳一项公认的标准,并把连续性置于治理之下。 用 ISO 22301 作为一个结构化的支柱,用 NHS 与国家指导作为行业层面的覆盖,并指定一位具名的高管对业务连续性负责,向董事会汇报。没有人拥有、资助或审查的连续性,会悄悄腐坏,直到事故揭示出这一点。把它接入你的保证框架(见主题 6.4——治理与保证),这样计划才能作为一项常规事务被维护、测试与改进,而不是在一场危机中才被重新发现。

与团队讨论的问题#

1. 对于我们每一个关键临床系统,我们实际上与临床医生商定了什么样的 RTO 与 RPO——我们目前能达到它们吗? 这个问题把愿景与能力之间的差距摆到了台面上。许多机构从未设定过明确的恢复目标,或是在没有临床方面输入的情况下由 IT 单独设定的,因此"可接受的"宕机实际上只是当前架构恰好能够交付的东西。讨论临床需求(一个紧急系统需要几分钟)与你的备份与灾难恢复实际能够达到的水平(也许是一天)相冲突的地方,因为这个差距是你无论是否说出它,都在承担的、未被管理的临床风险。具体地审视你上一次真实或经过测试的恢复:花了多久,你本会损失多少数据,谁签核了这是安全的?一个好的、诚实的答案会为每个系统说出具体的数字,承认你目前还无法达到它们的地方,并把每一个缺口转化为一项获得资助的行动,而不是一种舒适的沉默。

2. 如果勒索软件今晚加密了我们的核心系统与我们的备份,我们明天要如何保持患者安全——我们要多久才能完全恢复? 这是一个已经打击过真实医疗系统的场景,因此它值得一次具体的、毫不退缩的走查,而不是安慰性的话语。诚实地探索这两个方面:即时的临床连续性(宕机流程是否经过演练、配置了资源,是否足够可信到能让整个医院靠纸质运行数天?)与技术恢复(备份是否不可变且离线,你是否测试过从干净副本重建,你是否知道恢复顺序?)。揭示令人不安的依赖关系——如果单点登录、集成引擎或一个关键供应商宕机了,还有多少其他东西会随之倒下?考虑谁宣布重大事故,谁与员工、患者与媒体沟通,谁决定一个系统重新连接是安全的。一个有力的答案会描述一份经过演练的计划,拥有具名的角色与经过测试的恢复;一个薄弱的答案会假设备份没问题、纸质流程自然会起作用。

3. 我们上一次端到端地测试连续性与灾难恢复计划是什么时候?我们学到了什么? 这里的目的是把一种活的能力与一份搁在架子上的文件区分开来。一份从未被演练过的计划是未经测试的,而未经测试的计划在与现实接触时常规地失败——联系人清单过时了,恢复步骤需要一个没有人拥有的凭证,宕机表格存放在正宕机的那个系统里。讨论你实际开展的演练范围:桌面场景、技术性故障转移测试,以及包括一线临床后备方案、而不仅仅是服务器恢复的全面模拟。探究过去事故与演练中的教训是否真的被修复并重新测试,还是被记录下来就被遗忘了。一个好的答案会展示一份定期的演练日历,发现并关闭了缺口的证据,以及对计划中哪些部分依然未经证实的诚实。

4. 我们不掌控的关键依赖有哪些——如果它们中的一个失效了,我们的应对计划是什么? 现代医疗 IT 很少单独失效;它是通过其之下的服务与供应商而失效的。推动团队超越你所拥有的系统,去审视你仅仅依赖的那些:国家脊柱连接、单点登录提供商、云区域、集成引擎、外包的数据中心、握有恢复密钥的托管服务合作伙伴。对每一个,追问如果它消失一天,照护会怎样,合同是否要求这个第三方达到与你的临床需求相匹配的恢复目标,以及你是否真的看到过他们 DR 测试的证据、而不仅仅是投标书中一段令人安心的文字。令人不安的事实是,你可能正在承担一项从未被定价过的剩余风险,因为这次失效存在于别人的资产之中。一个诚实的答案会说出每项关键服务的具体外部依赖,说明哪些是有合同保证的、哪些仅仅是被信任的,并为你无法让其具备韧性的依赖关系指出一个后备方案——即使是手动的。

5. 当一次重大事故发生时,谁决定什么、谁与谁沟通、每个人在那一天到来之前是否都知道自己的角色? 连续性同样关乎指挥与沟通,而不仅仅是备份,这正是经过演练的计划与即兴的混乱分道扬镳的地方。梳理这套人类的编排:谁有权宣布一次重大事故并启动这份计划,谁运行运营响应,谁决定一个系统重新连接是安全的,以及谁与员工、患者、媒体、监管机构,以及——在一次网络攻击中——执法部门沟通。考虑你自己工具在事故期间的失效,因为这次中断可能会拖垮你平常用来协调的电子邮件、电话目录,或内网。揭示快速行动与安全行动之间的张力,以及把公众信息传达错误所带来的声誉风险。一个有力的答案会指向一个经过测试的、拥有具名的、有代理人的事故指挥结构、带外沟通渠道,以及预先商定的信息模板;一个薄弱的答案会假设正确的人会自然而然地聚集起来、知道该做什么。

6. 当两年内什么都没出过问题时,我们如何为连续性提供资金、拥有它、并让它保持活力? 韧性会在事故之间的间隙悄悄腐坏,这个问题直面了防止它腐烂的组织纪律。连续性要与可见的、紧迫的临床与数字优先事项争夺资金与关注,一个不成熟却幸运的机构,看起来与一个成熟的机构一模一样,直到有一天它不再幸运为止。讨论谁真正在高管层面拥有连续性,它是否有一条获得资助的预算线、而不是借来的善意,以及计划、依赖关系图与联系人清单是如何随着系统与员工的变化而保持最新的。追问董事会实际上看到的是什么——经过测试的保证与诚实的缺口,还是一个绿色的评级与一份归档的文件。一个好的答案会描述具名的问责、一份持续的预算与演练日历,以及一种把维护良好、经过测试的连续性当作常规、而不是在下一场危机中才重新发现的东西的治理节奏。

实践中:一个医疗与照护案例#

Meadowvale NHS 基金会信托机构运营着一家拥有 600 张床位的急症医院。一个周二早晨,员工到达时发现他们的电子病历(EPR)、病理与影像系统被一张勒索通知锁定;攻击者十天前通过一个供应商的远程访问账户进入。首席信息官在一小时内宣布了一次重大事故,该信托机构的业务连续性计划随即启动。

因为该信托机构已经完成了业务影响分析,它知道 EPR 与病理系统是其关键性最高的系统,拥有商定的恢复目标,而它的宕机流程在前一个秋天已经被演练过。病房切换到纸质用药图表与预先印制的观察表——这些刻意存放在每个病房的物理柜子里,而不是共享驱动器上——急诊科退回到它的纸质路径。本周的择期手术被推迟并通知患者;高峰时段的救护车被改道。照护得以继续,虽然打了折扣,但依然安全,因为员工已经练习过这种工作方式。

恢复比修复更难。安全团队隔离了网络以阻止扩散,然后从存放在离线的不可变备份中重建关键系统——攻击者无法触及的副本。这些备份每季度都经过恢复测试,因此团队知道这个流程有效,大致需要多久;EPR 在其 8 小时的 RTO 内恢复,而依赖关系更复杂的病理系统则花了两天。15 分钟的 RPO 意味着只有一小段窗口的数据丢失,员工在一个受控的重新录入流程下把纸质记录核对回系统,并对用药与结果进行了双重检查。

在事后总结中,该信托机构发现了真正的缺口:单点登录是一个单点故障,在恢复期间延迟了临床医生的访问,而那位供应商的远程访问没有被该信托机构自己的连续性保证所覆盖。两者都被列入董事会的风险登记册,配有负责人与日期,下一次全面演练也已被安排。这是艰难的一周——但不是一场灾难,因为这份计划存在、获得了资金,并经过了测试。

行业视角#

初创企业#

一家数字医疗初创企业很少有闲置的数据中心,因此它的连续性策略几乎完全依赖于云原生的韧性与有纪律的备份。使用在各个可用区内置高可用性的托管服务,用不可变的、脱离账户的副本自动化备份,以挺过勒索软件与一次被攻破的云账户,并真正地演练一次恢复到一个干净环境中。你的客户——NHS 信托机构与整合照护系统——将日益通过诸如 DTAC 与供应商保证之类的框架,要求 RTO、RPO 与 DR 测试的证据,因此要把连续性当作一项销售资产,而不是开销。对一家小型供应商而言,生死攸关的风险是单一一次事故,或那位唯一理解部署方式的创始人,变成了你的单点故障。

小型企业#

一家成熟的小型提供者——一家全科诊所、一家社区药房、一家养老院、一家居家照护机构,或一家单一场所的诊所——承担着与大型信托机构同样的、在一次中断中保持患者安全的义务,却有真实的患者、紧张的现金,而且通常根本没有专门的 IT 员工。这里的连续性是刻意务实的:知道哪一两个系统(临床记录、配药或电子用药管理系统)一旦失效就会阻止安全的照护,坚持要求你的系统供应商提供他们自己的备份、RTO 与 RPO 证据,并保留一份简单的、印刷出来的宕机资料包——纸质用药图表、关键电话号码、近期患者名单——放在员工在屏幕黑屏时依然能取用的地方。因为一位执业经理或一位独立 IT 承包商往往是唯一理解这套设置的人,要把恢复步骤写下来,并确保第二个人能够遵循它们。勒索软件与一条损坏的宽带线路是日常的威胁,因此一份离线或不可变的备份副本,以及一种后备的工作方式,比任何你负担不起或无法运行的精心设计的灾难恢复站点都更重要。

大型企业#

一家大型 NHS 信托机构、一个整合照护系统,或一家大型健康科技供应商,承载着一片庞大的、相互依赖的资产,最艰难的问题是绘制依赖关系与共享服务,而不是任何单一系统。要投资于一个与 ISO 22301 对齐的正式 BCM 项目、一份被维护的依赖关系图、为关键系统设立的 DR 站点或区域,以及一份包含临床后备方案在内的滚动演练日历。这个规模意味着单点故障常常是共享服务——身份、集成引擎、网络核心——它们的失效会在数十个系统中引发连锁反应。治理是那个具有约束力的因素:在有众多团队与供应商的情况下,连续性只有在一位具名的高管拥有它、董事会审查经过测试的保证而不是纸面计划时,才能站得住脚。

政府机构#

一个国家机构——NHS England、一个权力下放的卫生部门,或 UKHSA——必须在人群与系统规模上思考韧性,在这个规模上,一项国家级服务或一个被广泛使用的供应商的失效,本身就是整个行业的连续性事件。制定标准与期望(恢复目标、网络恢复、强制性演练)、为共享的保护能力提供资金,并协调整个行业对诸如全国性勒索软件活动这样的重大事故的响应。WannaCry 的应对重塑了国家政策,正是因为它的影响同时跨越了数百个机构,暴露出共同的弱点。这里的问责是公开且带有议会性质的,因此关于已知风险的透明度,以及对准备工作的诚实报告,与技术管控本身同样重要。

常见失败模式#

• 从未被恢复过的备份。 把"我们每晚备份"与"我们能够恢复"混为一谈。未经测试的恢复常规地失败或超出 RTO;衡量并报告成功的端到端恢复,而不是备份的完成情况。
• 可被勒索软件触及的备份。 把每一份备份都保持在线并连接网络,导致攻击者把它们与生产环境一起加密。至少保留一份不可变或离线的副本。
• 保护服务器、而不是服务的灾难恢复。 恢复了一个数据库,却没有恢复让它成为一项可用临床服务的依赖关系、集成与访问权限。按依赖顺序恢复并测试整项服务。
• 只存在于纸面上、关于纸质的宕机流程。 后备计划从未被演练过、被存放在会失效的系统上,或不为一线员工所知。要在照护实际发生的地方演练它们。
• 未被绘制的依赖关系与共享单点故障。 在中断期间才发现单点登录、DNS,或一个供应商支撑着一切。在事故之前、而不是期间,绘制依赖关系。
• 为审计人员而写、却从未演练的计划。 连续性成为一份合规文件,未经测试地腐坏,直到被需要的那一天。一份从未测试过的计划就是一份会失败的计划。
• 忽视供应商与云端的连续性。 假设你的第三方具有韧性、却没有证据,忘记了共担责任模型。让连续性成为合同性的、有保证的事项。

成熟度模型#

检查清单#

• 一份与临床医生共同拥有的业务影响分析,为每一项服务排序,并为每一个关键系统设定了明确的 RTO 与 RPO。
• 关键系统拥有与其临床关键性相称的高可用性与冗余。
• 单点故障与关键依赖(包括共享服务与供应商)已被绘制并被缓解。
• 备份遵循 3-2-1 规则,至少有一份勒索软件无法触及的不可变或离线副本。
• 恢复按计划被测试,并依据 RTO/RPO 计时,"上一次成功恢复"作为一项指标被报告。
• 每一个关键临床系统都有一份经过演练的宕机流程与一个受控的数据重新录入流程。
• 一份灾难恢复计划定义了恢复步骤、顺序、决策权与故障回退,DR 站点/区域已被测试。
• 一个网络恢复场景(隔离、从干净备份重建、验证、重新连接)已被记录并演练。
• 供应商与云端连续性在合同上被要求、被证明、并获得保证,包括共担责任模型。
• 连续性与 ISO 22301 对齐,由一位具名高管拥有,按日历演练,并向董事会报告。

关键来源#

• NHS England ——《业务连续性管理工具包》与应急准备、韧性与响应(EPRR)框架及核心标准。
• 国家网络安全中心(NCSC)——关于离线/不可变备份、勒索软件缓解与事故响应的指导。
• ISO 22301:2019 ——《安全与韧性——业务连续性管理体系——要求》(国际标准化组织)。
• ISO/IEC 27031 ——《信息与通信技术业务连续性就绪指南》。
• 业务连续性研究所(BCI)——《良好实践指南》。
• 国家审计署 ——《调查:WannaCry 网络攻击与 NHS》(2017)与卫生部经验教训审查。
• NHS England / 数据安全与保护工具包(DSPT)——包括业务连续性与事故响应在内的数据安全标准。
• GOV.UK 服务手册 ——线上服务的韧性、监测与恢复指导。

参考文献#

1. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
2. IT disaster recovery — Wikipedia — https://en.wikipedia.org/wiki/IT_disaster_recovery
3. ISO 22301 — Wikipedia — https://en.wikipedia.org/wiki/ISO_22301
4. Backup — Wikipedia — https://en.wikipedia.org/wiki/Backup
5. High availability — Wikipedia — https://en.wikipedia.org/wiki/High_availability
6. Redundancy (engineering) — Wikipedia — https://en.wikipedia.org/wiki/Redundancy_(engineering)
7. Failover — Wikipedia — https://en.wikipedia.org/wiki/Failover
8. Single point of failure — Wikipedia — https://en.wikipedia.org/wiki/Single_point_of_failure
9. Ransomware — Wikipedia — https://en.wikipedia.org/wiki/Ransomware
10. WannaCry ransomware attack — Wikipedia — https://en.wikipedia.org/wiki/WannaCry_ransomware_attack
11. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements — International Organization for Standardization — https://www.iso.org/standard/75106.html
12. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
13. Emergency Preparedness, Resilience and Response (EPRR) — NHS England — https://www.england.nhs.uk/ourwork/eprr/
14. Offline backups in an online world — National Cyber Security Centre — https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/