摘要
- Advanced Computer Software Group 2022 年 8 月的勒索软件事件影响了用于 NHS 111、非工作时间护理和社交护理工作流程的产品,包括 Adastra。
- 同期报告描述了运营中断、备用活动以及逐产品逐步恢复的过程。它们并未确定全国所有 NHS 111 服务统一不可用的时间段。
- 信息专员办公室(ICO)的最终材料显示,658 个数据控制者客户的可用性受到影响。这是运营可用性群体,而非数据外泄群体。
- ICO 单独指出,个人数据从 16 个控制者使用的系统中被窃取,影响 79,404 人。这些数字不得扩展到所有 658 个受可用性影响的控制者。
- 执法记录将 Advanced 视为数据处理者,并审查技术和组织安全措施的适当性,包括访问和漏洞管理方面的弱点。
- 公开记录支持服务中断、个人数据泄露和监管结论。但并未确认事件导致死亡、具体患者伤害或量化的国家临床结果。
- 2024 年宣布的 609 万英镑临时罚款并非最终罚款。2025 年 3 月的结果为 3,076,320 英镑,经过自愿和解,ICO 称 Advanced 同意不上诉。
- 恢复不仅仅是基础设施恢复。受影响的產品必须针对每个控制者客户单独恢复、检查和重新连接,因为其护理工作流程和本地备用安排各不相同。
- 持久的修复需要证据表明供应商访问已加固、漏洞得到管理、备份可恢复、产品可安全重新连接,并且控制者组织获得关于运营中断和个人数据泄露的精确证据。
护理责任仍由本地承担,而工作流控制则不然
紧急护理专业人员可以了解患者的需求,但仍然可能无法使用通常用来组织这些需求的软件。临床医生或呼叫处理人员可能保留判断力。NHS 组织可能保留法定和运营责任。然而,记录、路由或共享信息的工作流可能依赖外部运营的产品。
这种依赖在 2022 年 8 月变得明显,当时 Advanced 的勒索软件事件影响了卫生和社会护理领域使用的软件。同期报告将此次中断与支持 NHS 111 和非工作时间工作流程的 Adastra 以及其他护理管理系统联系起来。NHS 机构与网络当局合作,在供应商评估和恢复受影响服务的同时,使用备用、重新路由或变通安排。
该事件并非简单的一家医院的内部 IT 问题。也非所有 NHS 111 服务的统一关闭。这是一起供应商事件,通过产品影响到多个控制者组织,而这些产品是本地服务所依赖的。
这一区别改变了责任分析。控制者组织可以启动连续性程序、进行本地沟通,并决定何时安全地恢复工作流。但他们无法独立重建供应商运营的产品、检查供应商的每一项安全控制,或在没有 Advanced 证据的情况下自行重新连接。供应商拥有单个客户不具备的能力。
反过来,Advanced 并不控制所有公共服务结果。NHS 组织和公共当局负责路由、人员配备、本地记录、临床决策和公共沟通。某些服务可以以其他服务无法做到的方式回退。因此,护理连续性依赖于供应商、客户和公共当局之间分布的控制链。
当这条链正常运作时,专业化是有益的。供应商可以为许多组织维护软件和基础设施,而每个控制者则专注于提供护理。当供应商失败时,同样的集中化可能使恢复证据成为共享瓶颈。数百个客户可能同时需要从同一个运营商那里获得关于可用性、数据和重新连接的答案。
核心问题不是谁拥有“护理”这个词,而是谁能够改变失败的控制,并且谁能够证明下一步是安全的。
两个证据期不得混淆
公开记录主要有两个阶段。第一个是 2022 年 8 月的运营记录,当时各组织试图了解故障并维持服务。第二个是监管记录,最终以 ICO 2025 年 3 月的执法结果告终。
同期报道在描述运营者和客户遭遇方面最为有力。The Record 报道称 NHS 机构正与英国网络当局合作评估事件。Digital Health 描述了重大故障和产品特定状态进展。The Register、Guardian、Computer Weekly 和 GP 的报道记录了 NHS 111 相关的中断以及部分服务恢复可能漫长的前景。公共部门和专业来源则提供了远程健康建议和后续服务影响的背景。
这些报道是在最终监管调查完成之前制作的。不应重写为好像 2022 年 8 月的记者已经知道 ICO 将在 2025 年发布的所有结论。早期描述可能使用了 Advanced、客户和当时当局提供的信息。
ICO 最终的强制执行页面、新闻稿和处罚通知具有不同功能。它们提供了最终罚款、受影响控制者群体以及监管者关于安全措施的结论的权威数据。还记录了自愿和解和不上诉协议。
2024 年 ICO 公告界于这两个阶段之间。它描述了一项临时决定,并提出 609 万英镑的罚款。临时决定是执法过程的一部分,并非最终的法律和财务结果。Advanced 进行了陈述,该事项于 2025 年以 3,076,320 英镑通过自愿和解结束。
议会书面证据也需要适当的地位。它可以说明提交者向议会报告了事件及其影响。但这并不自动是委员会采纳的结论。监管者的处罚通知、公司的事件更新、同期新闻和提交的议会证据,其证明作用不可互换。
保持各阶段分离可以防止后见之明扭曲运营故事。也可以防止早期不确定性削弱后来的结论。2022 年,各组织需要在信息不完整的情况下保持护理路径的运行。到 2025 年,ICO 已经形成了成熟的执法记录。两者都应包含在记录中,但它们回答的是不同问题。
2022 年 8 月:一家供应商事件,多种本地影响
事件始于 2022 年 8 月,影响了卫生和社会护理客户使用的 Advanced 产品。Adastra 成为公开记录中突出的部分,因为它支持 NHS 111 和非工作时间护理。其他 Advanced 护理产品也被报告受到影响。
记录中确定的事件机制是勒索软件。后果包括软件可用性丧失,以及在较小范围的系统中,个人数据被窃取。产品恢复和客户重新连接持续到最初公开报告之后。
现有证据并未确定一个全国性的故障时间表。不同产品有不同的角色。不同的控制者组织有不同的部署、依赖和备用安排。一个呼叫服务、一个非工作时间提供者和一个社会护理组织可能以不同方式体验供应商软件的丢失。
因此,安全的时间线是产品和客户感知的。事件影响了供应商系统。Advanced 和公共当局评估了事件。客户启动了本地变通和连续性流程。恢复在受影响的产品和组织中逐步进行。每个客户的确切顺序和持续时间在公开记录中并未完全确定。
人们可能会倾向于使用一个戏剧性的全国性表述:“NHS 111 瘫痪了。” 这种说法过于粗糙。它可能暗示每个地方的每个 NHS 111 功能同时瘫痪并持续相同时间。证据支持与 NHS 111 相关软件的重大中断,而非统一的全国状态。
较窄的描述仍然重要。紧急护理工作流程依赖于及时的信息和协调。当供应商运营的产品不可用时,工作人员可能需要使用手动流程、替代路线或功能减少的系统。这可能增加摩擦和延迟,而不一定证明特定的临床伤害。
因此,即使没有量化的健康结果,护理连续性也是一个合法的问责视角。连续性是在中断期间维持服务的能力,而不仅仅是事后伤害的计数。在因果关系链被记录为伤害之前,失败可能揭示薄弱的依赖控制。
数字描述两种不同范围
ICO 的数字是核心,但容易被误用。
执法材料显示,658 个数据控制者客户的可用性受到影响。在数据保护术语中,控制者决定处理个人数据的目的和方式,而处理者代表控制者处理数据。这里,658 描述的是 Advanced 客户的服务可用性受到影响。
ICO 还单独指出,个人数据从 16 个控制者使用的系统中被窃取,影响 79,404 人。这是与较窄控制者系统相关的机密性和数据主体范围。
这些数字并不构成一个可互换的群体。658 个控制者不是 658 个人。他们不一定是 658 个 NHS 111 组织。他们并非都是已确认的窃取受害者。16 个控制者不是一个可以通过平均人数来估算其他地方暴露程度的子集。79,404 人不是运营故障的总数。
这一区别可以表述为两个独立的问题:
- 哪些人的供应商服务访问被中断?
- 哪些系统被窃取了个人数据,涉及多少人?
第一个问题涉及可用性。第二个问题涉及机密性。一个事件可能同时影响两者,但每个问题所需的证据不同。
一个组织可能在数据未被窃取的情况下失去软件访问权限。数据可能从一个系统中被窃取,即使另一个客户的服务仅遭受可用性中断。合并数字会夸大数据泄露并掩盖运营范围。
ICO 新闻稿称受影响材料包括来自健康和护理环境的敏感数据。还描述了可能使某些接受护理者的住址被访问的信息。这一细节解释了为什么机密性风险超出了普通账户信息。但并未确认任何人使用该信息进入住所或造成身体伤害。
因此,正确的解释同时保留严重性和精确性。可用性影响涉及 658 个控制者客户。执法记录中确认的窃取涉及 16 个控制者使用的系统和 79,404 人的个人数据。任何一个范围都不应用另一个来扩大。
这不仅仅是数字卫生。控制者需要根据自身位置获取不同证据。受可用性影响的客户需要恢复和重新连接信息。系统在窃取范围内的控制者还需要用于数据泄露评估、通知和对受影响人员支持的可信证据。将每个人都视为面临相同事件会削弱两种响应。
运营中断不等于临床伤害
卫生服务事件往往让人从系统故障直接跳到患者伤害。这里的公开记录不支持这种跳跃。
消息来源确认了紧急护理和社会护理工作流程中使用的软件中断。它们描述了组织如何绕开不可用的系统并管理恢复。ICO 确认了个人数据泄露和安全结论。但没有任何证据证明该事件导致死亡、具体伤害或量化的国家临床结果。
缺乏此类证据并不意味着运营影响微不足道。手动流程可能需要更多时间。重新路由可能增加其他地方的工作量。熟悉软件的丧失可能降低可见性并使协调复杂化。工作人员可能需要在系统恢复后核对记录。这些都是合理的连续性压力,但确切的临床后果需要证据。
因此,负责任的分析应避免两个相反的错误。不应捏造患者结果以使事件听起来严重。也不应暗示影响紧急护理工作流程的事件无足轻重,因为无法获得可归因的死亡人数。
适当的衡量标准是服务在供应商故障下是否保留了安全可行的路径。哪些功能能够继续?哪些需要替代系统?记录如何维护和核对?组织如何决定何时重新连接?特定产品依赖持续受限多长时间?
这些问题聚焦于能力。它们使护理提供者和供应商能够改进连续性,而不需要将不确定性转化为指控。
它们也澄清了责任。Advanced 控制着受影响供应商产品的运营和恢复。控制者组织控制着本地服务连续性和临床治理。公共当局可以在系统层面进行协调。临床结果可能取决于该链条中的行动,因此没有证据不能将其归因于任何一方。
处理者关系使供应商控制变得重要
ICO 记录将 Advanced 视为控制者客户的数据处理者。这一角色并不使供应商成为被动载体。运营软件和基础设施的处理者可以直接控制访问、漏洞管理、监控、备份、恢复和技术事件响应。
控制者组织仍然负责其个人数据的使用以及选择和管理处理者。他们可以设定合同要求、审查保证、维护连续性程序并做出通知决定。但他们无法独立检查供应商环境中的每一项实时控制。
这造成了证据依赖。事件发生前,控制者需要可信的保证,即处理者的控制措施与服务敏感性和运营重要性相匹配。事件期间,他们需要关于可用性和数据范围的准确事实。恢复期间,他们需要产品特定的证据,证明恢复和重新连接是安全的。
ICO 执法材料审查了 Advanced 在 UK GDPR 安全义务下的技术和组织措施的适当性。现有记录在更广泛的评估中指出了访问和漏洞管理方面的弱点。将监管机构的案件压缩为一项缺失控制或一个简单原因将是不准确的。
勒索软件事件通常涉及一个链条:访问机会、权限提升、接触有价值系统、执行破坏性或窃取活动、检测、遏制和恢复。公开摘要并未将每个环节的因果份额分配给 Advanced 的某项控制。监管机构更广泛的措施框架很重要,因为安全性取决于控制措施如何协同工作。
例如,访问加固可以减少进入或滥用。漏洞管理可以关闭已知路径。隔离可以限制影响范围。监控可以缩短停留时间。备份可以保护可恢复性。没有一项能完全替代其他。
因此,处理者责任应通过供应商控制的能力及其能产生的证据来评估。不应简化为“客户最终仍是控制者”这一命题。法律角色分配了职责,但并未抹去运营控制。
根本原因、触发因素和后果需要分开标记
勒索软件描述了恶意事件。它本身并不能解释所有促成条件。
ICO 对安全措施做出了结论,包括访问和漏洞管理。公开材料也记录了运营不可用、数据窃取和长期恢复。这些结论指出了重要的控制失败和后果。不应重写为某一缺失措施是唯一根本原因。
触发因素可以理解为迫使系统退出正常运行的恶意活动。确切的初始访问和完整攻击序列需要处罚通知中的详细证据,并应仅报告至监管记录支持的程度。
促成条件涉及控制环境:访问如何保护、漏洞如何管理、系统如何隔离、活动如何检测以及恢复如何准备。ICO 的措施分析属于此范畴。
运营后果包括产品对控制者客户不可用以及需要备用和重新连接。机密性后果涉及监管机构识别的较窄系统组窃取的数据。
响应包括遏制、调查、沟通和重建。恢复包括产品功能恢复和单个客户的安全重新连接。这些可能以不同速度进行。
这种分类防止了反复出现的问责失败。如果攻击者被视为唯一原因,供应商的可控制破坏半径就消失了。如果一个技术弱点被命名为全部根本原因,组织措施和恢复能力就消失了。如果服务恢复被称为完整响应,数据泄露和客户特定重新连接就消失了。
Advanced 案例需要完整链条。恶意活动导致了事件。监管机构后来发现供应商的措施在相关方面不足。可用性广泛影响控制者客户。窃取在较窄群体中得到确认。恢复需要的不只是重启基础设施。
控制者组织控制了本地连续性层
Advanced 拥有供应商端技术控制权,但控制者组织并非旁观者。
每个组织都必须了解哪些本地工作流程依赖于受影响产品。它必须决定如何继续服务、在系统不可用时如何记录行动、如何与员工和用户沟通,以及恢复后如何核对信息。
控制者还承担供应商治理责任。事件发生前,他们可以定义安全要求、恢复目标、事件通知和证据。他们可以评估集中风险并测试关键功能是否有可行的备用方案。
这些控制的实际有效性各不相同。小型护理组织可能对主要供应商的杠杆作用有限。可能无法获得详细的架构证据或维护一个可立即使用的替代产品。采购条款并不会自动创造运营能力。
这种不对称使得精确的供应商证据更加重要。控制者不能基于“服务正在恢复”的通用声明而负责任地重新连接系统。它需要知道哪个产品实例已恢复、执行了哪些完整性检查、数据是否已核对以及存在哪些残留风险。
窃取范围内的控制者还面临数据治理决策。他们需要关于受影响系统、数据类别和所涉人员的证据。这些决策与那些服务不可用但系统未被确定在窃取范围内的客户所面临的连续性选择不同。
因此,658 对 16 的区别直接映射到控制者职责。受可用性影响的客户不一定面临与确定在窃取范围内的控制者相同的数据泄露响应。数据暴露决策不能从一般性故障中推断出来。
控制者层的责任应通过准备和证据使用来衡量,而非假装控制者可以运营供应商基础设施。组织是否了解其依赖?能否继续关键工作?是否保留了本地记录?是否要求了产品特定的重新连接证据?是否向其所负责的人员准确沟通?
NHS 和公共当局持有协调层
影响多个卫生机构的供应商事件可能超出任何一个客户的视野。公共当局和行业机构可以协调网络评估、共享信息、管理路由并在系统层面进行沟通。
同期报道称 NHS 机构正与英国网络当局合作。这种协调很重要,因为产品不可用可能影响使用相关工作流程的多个组织。中央视图可以识别备用容量承受压力的地方以及恢复优先顺序
系统级协调并不意味着每个服务都经历相同影响。公共沟通应避免抹平局部差异。应识别受影响的产品和功能,解释可用的替代方案,并在服务重新连接时更新情况。
当局还需要区分网络安全响应和临床连续性。技术团队可能专注于遏制和证据保全。服务领导可能关注呼叫路由、人员配置和安全变通。数据保护团队可能关注受影响人群和通知。这些线索必须交换证据,而不应变成一个模糊的危机标签。
公开记录并未提供覆盖所有组织的完整 NHS 事后报告。因此,无法对每个备用措施的有效性做出最终判断。有记录的中断足以表明供应商依赖应纳入行业连续性规划。
恢复需要客户特定的重新连接证据
供应商恢复并非单一时刻。基础设施可以重建,而应用程序仍然不可用。应用程序可以在客户数据不完整的情况下运行。产品可以通过供应商检查,而控制者仍需验证本地集成和记录。
Advanced 记录描述了受影响客户的长时间重新连接期。公开报道也预计部分服务恢复漫长。由于每个产品和组织的确切序列不完整,因此无法支持一个通用的恢复日期。
安全重新连接需要多种证据。供应商需要证明恢复的环境可信、相关漏洞和访问路径已受控、备份或恢复的数据具有完整性,并且监控处于活动状态。控制者需要知道发生了什么变化以及还有哪些本地检查需要完成。
数据核对在护理工作流中尤其重要。在主产品不可用时,操作可能已手动记录或记录在备用系统中。重新连接可能导致重复、空白或排序问题,如果这些记录未对齐。公开来源并未确定 Advanced 存在特定的核对失败;它们说明了为什么重新连接不能仅用服务器正常运行时间来衡量。
优先级排序也需要透明度。服务数百个控制者的供应商可能需要分阶段恢复产品和客户。标准应反映安全性、依赖性、技术准备和可用备用,而非仅仅是哪个客户能施加最大压力。
控制者特定证据减少了两种风险。它防止组织基于通用状态更新而过早恢复;也防止当相关产品和数据实际已安全恢复时无休止地谨慎拖延。
因此,恢复记录应为每个受影响的服务保留哪些内容不可用、哪些已恢复、通过了哪些验证、哪些数据区间可能需要核对以及谁接受了重新连接。这是供应商恢复和护理连续性之间的桥梁。
可用性和机密性需要分开沟通
在勒索软件事件中,组织通常用一个标题沟通:网络攻击。客户需要更精确的分类。
可用性更新应说明哪些产品或功能不可用、存在哪些备用、下一次评估何时进行以及客户应做什么。不应仅仅因为系统瘫痪就暗示数据被盗。
机密性更新应确定个人数据是否被访问或窃取、涉及哪些控制者系统、受影响的數據类别人群以及仍存在哪些不确定性。不应使用广泛的故障群体作为调查的替代。
Advanced 数字说明了为什么这种区分很重要。向 658 个受可用性影响的控制者客户发送更新可能适合服务连续性。但这本身并不意味着所有 658 个都应告知人们其数据已被窃取。监管机构确认的窃取范围涉及 16 个控制者使用的系统和 79,404 人。
部分受影响信息的敏感性提高了风险。ICO 称一些数据可能使访问护理者住所成为可能。沟通应支持保护性行动,而不暗示此类访问实际发生。
精确的语言也保护可信度。“目前没有证据”不同于“没有发生”。“服务已恢复”不同于“本地记录已核对”。“受可用性影响的控制者”不同于“在窃取范围内的控制者”。
这些区别不是公关的细枝末节。它们决定了哪些运营、法律和个人行动是合理的。
执法时间线是问责记录的一部分
ICO 于 2024 年 8 月宣布了一项临时决定,考虑罚款 609 万英镑。这一数额吸引了注意力,但并未成为最终罚款。
2025 年 3 月的最终结果为 3,076,320 英镑。ICO 称其遵循了自愿和解,且 Advanced 同意不上诉。最终金额而非临时提议才是正确的执法数字。
只有在其程序差异保持清晰的情况下,解释两个数额才有用。监管机构可能在陈述、法律分析和和解后修订拟议罚款。较低的最终金额并不抹去结论。较高的临时金额并非额外罚款。
不上诉协议也结束了一个常见的不确定性。当前记录不支持关于针对这一已和解结果待上诉的猜测。
监管问责并不等同于运营问责。ICO 的角色是评估数据保护安全义务的合规性并处以最终罚款。监管机构并未运营 NHS 111、恢复 Advanced 产品或运行控制者备用流程。
尽管如此,执法记录加强了运营学习,因为它通过正式证据流程确定了措施缺陷。它将事件的某些部分从早期指控或解释转化为监管结论。这些结论应精确表述,同时保留公司的陈述和和解背景。
ICO 结论确定的内容和未确定的内容
ICO 结论确定,在监管机构分析的相关方面,Advanced 的技术和组织措施不适当。现有材料在更广泛的结论中指出了访问和漏洞管理方面的弱点。
它们确定了最终罚款以及监管机构报告的受影响群体。确定了 Advanced 的处理者角色和自愿和解。
它们并未确定某一项控制措施单独导致了所有后果。安全事件是通过交互的技术和组织条件出现的。因此,适当的修复比安装一个工具更广泛。
它们并未确定统一的临床影响。ICO 的数据保护结论不是临床结果研究。
它们并未使每个控制者的情况相同。控制者系统、产品、数据和连续性安排各不相同。
它们并未将所有责任转移到处理者身上。控制者和公共当局保留各自的职责,尽管只有 Advanced 能够运营和恢复供应商环境。
这一界限很重要,因为执法摘要可能成为简写。“罚款证明 X”常被用来填补处罚通知未决定的问题。ICO 记录应被用于其确定的内容,同时运营未知因素保持可见。
修复必须在四个控制层面得到证明
第一个修复层属于供应商的安全控制。
访问应根据账户可行使的权限进行加固。能够访问关键健康软件基础设施的凭证需要比普通用户账户更强的保护、监控和恢复。漏洞管理应将已知弱点与暴露资产、利用风险和修复截止日期联系起来。隔离应限制对一个系统的入侵如何影响其他系统。
修复不需要指定特定产品。证据标准是 Advanced 能否证明相关访问路径和漏洞得到持续控制,而不仅仅是有政策。
第二层是恢复。
备份应可在不依赖受损管理的情况下恢复到可信环境。恢复测试应证明应用程序、配置和数据协同工作。恢复目标应按产品和客户衡量,因为一个总目标可能隐藏一个花费更长时间的关键工作流。
第三层是重新连接。
Advanced 应能提供客户特定的记录,说明哪些已恢复、通过了哪些完整性检查、哪些数据区间需要核对以及保留哪些监控。控制者组织应有定义好的验收程序,包括运营和数据治理检查。
第四层是跨公共服务的连续性。
控制者应维护可行的备用程序、本地依赖清单以及在供应商软件不可用时保留所采取行动的方式。NHS 和公共当局应能协调路由和优先级排序,而不假设每个本地服务具有相同的备用能力。
这些层面需要联合演练。排除客户的供应商恢复测试可能证明基础设施,但无法证明重新连接。假设供应商能按需提供干净系统的控制者桌面推演可能无法测试长期供应商故障。将“NHS 111”视为一个系统的国家演练可能忽略本地和产品差异。
演练还应区分可用性和机密性。参与者应练习如何在许多服务不可用但数据泄露仅在较窄系统中得到确认的情况下进行沟通。Advanced 数字为此类场景提供了清晰的模型。
证据应持久。事件时间线、访问日志、漏洞决策、备份测试、恢复结果、客户通知和重新连接批准应可供调查和改进。如果证据随服务消失,问责就变成了凭记忆重建。
最后,修复应在组织和产品变更后进行测试。健康软件供应商通过收购、迁移、平台整合和产品更新而发展。适用于一种架构的控制可能在依赖关系变更后不再有效。
目标不是承诺勒索软件永远不会成功。而是证明访问、漏洞、恢复和连续性控制使下一次事件更难启动、范围更小、检测更快、恢复更安全。
仍然未知的内容
公开记录并未提供完整的逐产品故障和重新连接时间线。部分同期报道描述了预期或观察到的恢复期,但每个客户的最终顺序尚未确定。
记录并未量化可归因于该事件的直接临床伤害。不得从软件中断推断死亡、伤害和国家患者结果数字。
完整的初始访问和攻击序列不应被缩减到 ICO 既定结论之外。不应将一项缺失控制宣布为唯一原因。
控制者特定的通知和修复结果各异。658 可用性群体不能用作通用数据窃取群体,16 控制者窃取范围也不能在没有证据的情况下推广。
完整的 NHS 事后报告在此不可得。每个本地变通、路由决策和核对流程的有效性仍处于已确定记录之外。
这些限制并未削弱核心案例。它们界定了证据能够负责任地支持的内容。
责任遵循对依赖的控制
Advanced 2022 年的勒索软件事件使供应商运营的医疗工作流成为问责对象。
供应商控制访问加固、漏洞管理、基础设施、恢复和产品重新连接。控制者组织控制采购、本地连续性、数据治理决策和恢复服务的验收。NHS 和公共当局控制更广泛的协调和路由。ICO 控制回顾性监管流程。
事件影响 658 个控制者客户的可用性。窃取涉及 16 个控制者使用的系统和 79,404 人的个人数据。保持这些数字分离,保留了运营连续性和已确认数据访问之间的区别。
记录支持严重中断和敏感数据泄露。并不支持捏造的死亡、统一的全国停机或单一原因故事。
最终 3,076,320 英镑罚款提供了一个正式的问责终点。但并未完成运营修复。这需要证据表明供应商控制已改进、备份可恢复、客户能安全重新连接,以及当一家供应商系统不可用时公共服务能够继续运行。
在分布式护理系统中,责任可以共享而控制不均等。能够改变控制措施的组织应能证明该改变。被迫依赖该控制的客户应能测试证据。Advanced 使这种交换——而非软件可用性本身——成为连续性的衡量标准。
来源
- https://ico.org.uk/action-weve-taken/enforcement/2025/03/advanced-computer-software-group-limited/
- https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2025/03/software-provider-fined-3m-following-2022-ransomware-attack/
- https://ico.org.uk/media2/gdlfddgc/advanced-penalty-notice-20250327.pdf
- https://therecord.media/nhs-working-with-u-k-cyber-authorities-to-assess-ransomware-attack-on-it-vendor
- https://www.digitalhealth.net/2022/08/advanced-major-outage/
- https://committees.parliament.uk/writtenevidence/114499/html/
- https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2024/08/provisional-decision-to-impose-6m-fine-on-software-provider-following-2022-ransomware-attack/
- https://www.theregister.com/2022/08/12/nhs_111_services_provider_msp_advanced_confirms_ransomware/
- https://www.theregister.com/2022/08/05/major_outage_at_it_service_provider_that_hosts_nhs_111/
- https://www.theguardian.com/technology/2022/aug/11/nhs-ransomware-attack-what-happened-and-how-bad-is-it
- https://www.theregister.com/2022/10/14/it_was_lockbit_that_forced_nhs_tech_supplier_to_shut_down/
- https://www.digitalhealth.net/2022/08/advanced-status-updates-products-ransomware-attack/
- https://www.nhsprocurement.org.uk/news/supplier-fined-3m-cyber-breach-ico-first
- https://www.computerweekly.com/news/252523700/NHS-may-take-a-month-to-recover-from-supply-chain-attack
- https://www.gponline.com/nhs-111-systems-offline-until-next-week-following-cyber-attack/article/1795644
- https://www.bmj.com/content/386/bmj.q1759
- https://www.bleepingcomputer.com/news/security/uk-fines-software-provider-307-million-for-2022-ransomware-breach/
- https://assets.publishing.service.gov.uk/media/6322ec948fa8f57795d5c269/UKHSA_Remote_Health_Advice_Weekly_Bulletin_2022_Week_36.pdf
- https://www.hertsandwestessex.ics.nhs.uk/wp-content/uploads/2024/04/Meeting_Book___ICB_Board_Meeting__Public_Session__Friday_22_September_2023_v1_for_website.pdf

