软件开发公司审27001,到底要不要抽样运维项目?最近，一个粉丝朋友的问题把我难住了。他问我：“只有ISO 27001一个体系审核，范围是软件开发的信息安全管理，是否必须要抽样一个运维项目？”我的第一反应是ISO 27001 的审核抽样，严格遵循文件化的审核范围。范围只覆盖软件开发，就只在软件开发活动里抽样。范围不含运维，就没有义务提供运维项目、运维记录、运维人员访谈。后来我琢磨了好久，觉得好像有哪里不对。虽然范围明确写了“软件开发”，运维活动似乎不在边界内。但如果不去碰运维，代码怎么发布？生产环境的安全谁负责？变更怎么执行？这些问题绕不过去。运维真的不用审吗？在审核中，应通过适当的抽样收集并验证与审核目标、范围和准则有关的信息，包括与职能、活动和过程间接口有关的信息。只有能够验证的信息方可作为审核证据。软件开发不是孤岛。代码写完了要部署，系统上线了要运行，出了故障要排查。开发与运维之间的接口，恰恰是信息泄露、权限失控、配置错误的高发地带。你如果完全绕过运维，就像只检查了流水线的前半段，后半段的质量根本不知道。多年前开发是开发，运维是运维，边界很清楚。现在不一样了。很多软件企业都在搞DevOps和CI/CD，开发写完代码直接提交，自动构建自动测试，一键部署到生产环境。整个过程行云流水。这时候你再把开发和运维当两个独立的“部门”来审，就脱离实际了。所以不是“要不要审运维”，而是在审核软件开发过程时，运维活动已经作为一个环节嵌在其中了。你不去看发布过程，不看看生产环境的变更管理，整个安全链条就是断的。回到最开始的判断。看企业提供的软件开发合同，如果合同中明确写了运维由客户自己负责。这种情况下，认证范围可以仅限于开发，审核时也不需要对运维现场抽样，因为风险在交付那一刻就转移了。但如果合同中明确了需要负责系统上线后的运行维护、安全监控及故障响应等，就算认证范围没包含这部分，审核时也要覆盖，因为失控的运维环节足以摧毁开发阶段所有的安全投入。还有一个更直接的答案，基于PDCA和基于风险的审核，安全测试发现的问题，最终需要通过变更管理进入生产环境。你不看运维环节，就看不到这条闭环是否真正打通。你怎么看？你在审核中遇到过范围与实际情况不符的情况吗？你是怎么判断该不该审的？来评论区聊聊，一起涨经验。记得关注收藏，不迷路！个人观点，仅供参考。
夜雨聆风
