4、审查计划制定：范围界定、时间线规划、资源分配、风险预评估

好，咱们直接进入正题。审查计划这东西，说白了就是一张作战地图。没有它，你连从哪下手都不知道。我见过太多团队，上来就拿着合规清单一条条对，结果对到一半发现设备类型搞错了，或者人手根本不够用。嗯，这就是典型的「计划缺失综合症」。

我个人习惯，在动手写计划之前，先问自己三个问题：查什么？谁去查？查多久？ 这三个问题捋清楚了，计划就完成了一半。

4.1 范围界定：别想一口吃成胖子

范围界定是第一步，也是最容易翻车的一步。你想想看，一个中型企业的设备资产少说几百台，大型数据中心更是成千上万。你不可能一次性把所有设备都审一遍，那不叫审查，那叫自虐。

我建议按以下维度来切分范围：

• 按设备类型：服务器、网络设备、安全设备、终端设备、IoT设备。每种设备的合规要求差异很大，混在一起审你会疯掉。
• 按业务重要性：核心生产系统、一般业务系统、测试环境。核心系统优先，这是铁律。
• 按地理位置：总部机房、分支节点、云上资源。不同地点的物理安全要求不同。
• 按合规要求来源：等保2.0、ISO 27001、行业监管要求。不同标准覆盖的设备范围不一样。

范围界定完成后，一定要输出一份《审查范围确认书》，让业务方和主管签字。为什么？因为后面如果有人问「为什么这台设备没审」，你可以拿出这份文件说：「这是当时大家确认过的。」

4.2 时间线规划：别把战线拉太长

时间规划的核心就一句话：给每个阶段留够缓冲，但别给整个项目留太多时间。

我一般把审查分成四个阶段：

阶段	内容	建议时长
准备期	范围确认、工具准备、人员培训、基线文档整理	3-5天
执行期	现场检查、配置核查、漏洞扫描、访谈	5-10天
分析期	数据整理、差距分析、风险评级	3-5天
报告期	报告撰写、整改建议、汇报	3-5天

你看，一个完整的审查周期，控制在两周到三周是比较合理的。超过一个月，审查人员的注意力会下降，业务方也会不耐烦。

4.3 资源分配：人、工具、时间，一个都不能少

资源分配这块，我踩过的坑最多。你以为两个人就能搞定？太天真了。

资源分配要考虑三个维度：

• 人力资源：审查组长（1人）、技术审查员（2-3人）、业务接口人（每个部门1人）。别让一个人干所有事，那会出人命。
• 工具资源：配置核查工具（如OpenSCAP）、漏洞扫描器（如Nessus）、资产管理系统。手工核查效率太低，我建议能用工具的就别用手。
• 时间资源：每个设备预留30-60分钟的审查时间。别排得太紧，因为现场总会有意外情况。

4.4 风险预评估：提前想好「万一」

风险预评估，说白了就是「先想好最坏的情况」。我每次做计划，都会花半天时间专门做这件事。

常见的风险点：

• 业务中断风险：扫描或配置变更可能导致设备宕机。解决方案：在业务低峰期操作，提前备份配置。
• 数据泄露风险：审查过程中会接触到敏感配置信息。解决方案：签署保密协议，数据加密传输。
• 人员配合风险：业务方不配合，或者关键人员请假。解决方案：提前沟通，指定备选接口人。
• 工具兼容性风险：扫描工具不支持某些老旧设备。解决方案：准备手工核查清单作为兜底方案。

嗯，说到这里，我想起一个案例。有一次我们在审查一家医院的设备，结果扫描工具把一台老旧的PACS服务器搞宕机了。幸好我们提前做了备份，半小时内就恢复了。如果当时没有风险预案，那后果...你想想看，医院系统宕机半小时是什么概念？

4.5 输出物：计划文档长什么样？

最后，审查计划一定要形成书面文档。我习惯的文档结构是这样的：

1. 审查背景与目标
2. 审查范围（设备清单、业务系统、地理位置）
3. 审查时间线（甘特图或表格）
4. 资源分配表（人员、工具、预算）
5. 风险预评估与应对措施
6. 审批签字页

这份文档不需要太长，5-8页就够。关键是让所有人都能看懂，并且达成共识。