一、ISO/IEC 27001:2022 附录A.5.8 控制原文

二、条款解读说明

2.1 为什么项目是信息安全失控的高发场景

很多组织的信息安全问题并非源于日常运维，而是源于项目阶段的遗漏。新系统上线时没有充分识别访问控制要求，供应商实施时没有约定开发和测试边界，数据迁移项目没有提前界定敏感信息处理规则，业务创新项目只关注交付速度忽视日志、审计和恢复要求。这些问题一旦在项目阶段被放过，后续再修补通常成本极高。

A.5.8的价值就在于把安全嵌入项目治理。这里的“项目”范围很广，不仅包括软件开发项目，也包括基础设施改造、云迁移、外包实施、系统替换、并购整合、流程重构和新业务落地等。只要项目会引入新资产、新流程、新接口或新依赖，就可能带来新的信息安全风险。

2.2 关键要点拆解

2.3 为什么安全不能只放在“上线评审”环节

因为很多项目中的关键安全决策在更早阶段就已经发生了。例如，是否需要采集某类数据、是否引入外部接口、如何设计身份体系、是否允许供应商远程接入、日志和审计是否纳入需求、恢复目标是什么。这些问题若在立项和设计阶段未被确认，后续即便做上线检查，也只能在很窄的空间里“打补丁”。因此，A.5.8要求的是项目全过程的安全嵌入，而不是尾端把关。

三、实施要点

3.1 在立项阶段明确安全影响

• 项目启动时识别是否涉及敏感数据、关键系统、第三方接入、远程访问、云资源或合规要求。
• 将信息安全影响评估纳入立项模板和评审机制。
• 高风险项目应尽早拉入安全、法务和架构角色。

3.2 设定阶段性安全控制点

• 在需求、设计、开发、测试、上线和交付阶段设置安全检查点。
• 每个检查点明确输入材料、责任人和通过条件。
• 不要把所有问题压到上线前统一解决。

3.3 建立项目安全责任矩阵

• 项目经理负责推进，业务负责人明确需求边界，安全团队提供审查和建议，技术团队落实措施。
• 对外包项目尤其要明确供应商的安全责任和交付要求。
• 没有主责人，安全事项很容易在项目压力下被牺牲。

3.4 把安全要求纳入验收和例外机制

• 把关键安全要求作为上线或交付门槛之一。
• 对确需例外上线的项目，应走正式风险接受和补偿控制机制。
• 避免临时口头承诺“上线后再补”。

3.5 做项目后评估和经验沉淀

• 项目结束后复盘哪些安全控制前移有效，哪些环节仍有缺口。
• 将成熟做法沉淀到项目管理模板和方法中。
• 让项目安全能力随组织经验不断演进。

四、常用工具与实施方法

五、典型案例

案例一：新系统上线前才发现日志要求缺失

1. 背景：业务系统开发接近完成。
2. 问题：上线前才发现未设计关键操作日志，补做成本高。
3. A.5.8动作：将日志、权限和审计要求前移到需求和设计评审。
4. 结果：后续项目中安全设计更早被纳入。
5. 启示：项目安全必须前移到需求阶段。

案例二：云迁移项目通过阶段控制减少返工

1. 背景：企业开展核心系统迁云。
2. 问题：若只在上线前检查，很多架构性问题难以修正。
3. A.5.8动作：在设计阶段加入身份、日志、备份和网络隔离检查点。
4. 结果：后续返工显著减少。
5. 启示：阶段控制能明显降低安全补救成本。

案例三：外包开发项目未纳入安全验收

1. 背景：项目由供应商开发并交付。
2. 问题：交付时发现测试环境和生产环境边界处理不当。
3. A.5.8动作：将安全验收条件写入合同和验收标准。
4. 结果：外包项目交付质量更可控。
5. 启示：项目管理中的安全要求必须外部化到供应商交付中。

六、成文信息管理要求

A.5.8的证据通常围绕项目安全影响识别、阶段检查、验收门槛和例外管理展开。成熟组织一般会让这些要求进入项目方法论和项目档案，而不是依赖个人经验。

七、常见误区及踩坑提醒