能登录云盘，不等于已经证明可以恢复业务。备份能否取回要在平时验证，还要确认出了事能联系谁，以及恢复前需要检查什么。
本文依据 2026 年 11 月 2 日的 NIST CSWP 50 正式版，主要参考第 12、15、17、19–20 页。以下记录卡、演练方法和完成标准由作者整理，不是 NIST 原工作表，也不是一套适用于所有事故的处置命令。正在发生事件且无法判断影响范围时，联系预案中合适的专业人员，不要依赖本文完成取证或系统清理。
1. 先定义要恢复的交付
从第一篇资产清单选一项重要交付，填写下面的自编恢复卡：
| 项目 | 填写内容 |
|---|---|
| 要恢复的业务 | 哪项交付中断，涉及哪些数据、账号和设备 |
| 可接受的影响 | 业务最多能承受丢失多少更新、中断多久；由经营者决定 |
| 副本与保存方式 | 备份包含什么，在哪里，哪些人或账号可读取、修改或删除 |
| 备用恢复路径 | 日常设备或主要账号不可用时，如何按提供方流程恢复访问 |
| 验证办法 | 怎样确认恢复内容完整、版本正确且可以用于交付 |
| 帮助与沟通 | 服务商、专业人员和其他需要联系的对象 |
这些问题用于明确业务需要，不能据此自行承诺一个尚未测试的恢复时间。NIST 没有在这里为所有一人业务规定统一的备份间隔、可丢失数据量或恢复时限。
2. 检查副本是否受到保护，并做一次恢复测试
原文建议定期备份，考虑多个副本，其中至少一个在不连接日常设备的媒介上。文中举了外置硬盘和云的例子。它也建议保护和测试备份，并核实云服务商的备份政策。勒索软件的影响可延伸到云账号和 SaaS，不能只凭「存在云端」就认定已经隔离或一定可恢复。原文第 15、17 页
逐项核对备份包含的数据、可用版本、访问权限、删除权限和恢复流程。服务商的同步、版本保留、备份与恢复是否覆盖同一范围，应按实际政策确认。不要把云一概排除，也不要把云同步自动写成受保护的备份。
下面是作者建议的低风险演练方法：
- 选取不含敏感信息、内容已知的测试样本，记录预期版本。
- 按已核实的备份流程保存样本，记录位置和访问条件。
- 从备份恢复到不会覆盖工作数据的测试位置。
- 打开恢复内容，与预期内容和版本比较，确认能否完成预定用途。
- 记录实际结果和限制。失败或缺失的部分列出后续动作，再测试。
测试记录可填写「日期、样本、备份位置、恢复入口、预期结果、实际结果、问题、下一步」。一次样本成功只证明这次测试的范围，不证明全部系统都能恢复，也不代表经过安全取证或确认没有恶意内容。
3. 把联系表和应急办法放在离线可取的位置
NIST 建议事前准备响应计划并定期练习，保留打印或离线的关键联系人。先确认失去主要邮箱或电脑时，是否还能取得这些资料。原文第 2、12 页
自编联系表至少填写：
- 服务提供方：已经核实的支持或账号恢复入口，能协助什么。
- 专业支持：适合本业务的事件响应、法律及其他联系人。如有保险，核对保单要求、范围和联系办法。
- 业务沟通：需要联系的客户或合作方、可用的备用渠道，以及适用的通知要求在哪里。
联系表不存密码、令牌或恢复码。记录备用沟通方式和临时交付办法，核实是否实际可用。原文给出手工替代、临时服务方式和备用沟通渠道作为业务连续性的例子。不能把未验证的备用方式写成可用承诺。原文第 19 页
4. 怀疑被盗或中招时，先限制扩散并记录事实
原文的基本遏制措施包括断开设备网络、隔离受影响的设备或系统、撤销会话，并避免用疑似受损设备和账号做恢复操作。具体先后顺序需结合事件与预案，不应照抄一条通用清理命令。原文第 19 页
按预案联系服务商或专业人员时，同时整理时间线：
首次发现的时间及使用的时区：____
观察到的现象：____
已确认的账号、设备或业务影响：____
仍待核实的范围：____
可取得的日志、相关截图及受控保存位置：____
已经采取的动作、执行者及时间：____
已联系的对象与下一步：____这份自编记录区分观察、已确认事实和猜测。不要把一次异常登录通知直接写成全部客户数据已泄露。若需要恢复访问，使用未受影响的设备和已核实的服务商恢复流程。主要邮箱本身可疑时，不把它当作可靠的备用沟通渠道。
通知对象、内容和时限取决于实际法律、监管、合同或政策要求。本文不规定统一通知时限。按预案核对义务，需要时寻求法律帮助。下面的自编沟通草稿只用于组织已知信息，不能替代必要的正式通知：
我们在「时间及时区」发现「现象」。已确认「影响」，仍在核实「范围」。目前采取「措施」，后续通过「可信渠道」沟通。
5. 恢复前检查完整性和账号设置
NIST 建议在重新使用备份或其他资产前验证其完整性，并复查 MFA、用户账号、文件共享、活动会话和转发规则，降低恢复后再次受影响的风险。原文第 20 页
把这两类检查分开记录：恢复的数据能否正确用于业务；账号和系统设置是否已核实。仅修改密码或看到文件能打开，不能代表两类检查都完成。无法判断完整性、仍有异常会话或发现不明转发规则时，交给合适的专业人员确认，不把系统标为已恢复。
依照实际要求与客户、合作方协调恢复。结束后记录发生了什么、采取了哪些响应和恢复动作，以及哪些地方需要改进，再更新资产清单、设置和预案。
完成标准与限制
平时准备完成，应留下可访问的离线联系表、一次有范围和结果的恢复测试，以及有下一步的失败项。事件恢复是否可以结束，还要看资产完整性、账号设置、业务验证和适用的沟通义务是否已经处理。必要时需要专业判断。
没有统一的「做完这些就绝对安全」。本篇没有验证任何具体云服务、备份产品或真实事故，也没有复刻另附电子表格中的 NIST 附录 I。随着业务和依赖变化继续更新计划。
回到第一篇：资产与风险清单检查遗漏，或使用第二篇：账号与设备防护落实发现的设置问题。