软件企业的ISO 27001文件常常写得很好看：手册结构完整、程序文件齐全、表单编号规范。
但审核员打开运维的工单系统、代码仓库和云控制台一对照，就会发现文件里写的流程和实际执行是两套。
本文挑出最容易脱节的四类内容，说明它们为什么会脱节、审核会怎么追问、企业该怎么改。
脱节的根源通常不是员工不执行，而是文件照着模板写，没有照着企业真实的技术栈和协作方式写。
下面四类脱节现象在软件企业中最常见，可以拿现有文件逐条对照。
| 脱节表现 | 现场真实做法 | 审核通常会怎么问 | 修正方向 |
|---|---|---|---|
| 制度写“机房每日巡检” | 业务已全量上云，无机房可巡 | 巡检记录在哪里，谁签字 | 改为云资源巡检与监控告警复核 |
| 变更要走纸质审批单 | 实际在工单系统走发布流程 | 抽查一次变更的完整审批链 | 以系统记录为准，文件描述同步调整 |
| 日志保存三年 | 平台默认保留三十天 | 调取半年前的登录日志 | 按实际能力改期限，或调整平台配置 |
| 权限每季度复核 | 只在入职离职时处理 | 最近一次复核记录和结论 | 设定固定复核节点并留痕 |
四类问题任选一条抽查，基本就能判断文件是“写给自己看”还是“写给现场用”。
一级文件讲方针和目标，二级程序讲跨部门流程，三级作业文件讲具体操作。软件企业容易把技术细节塞进程序文件，导致文件又长又空。
适用范围也要写准。集团有多条业务线时，文件要说明哪几条线在范围内，哪些系统只是被支撑，不能含糊带过。
如果研发、测试、运维分属不同主体，文件里应写清边界和接口，否则现场审核时各方都说不清责任。
软件企业的文档往往同时存在于Git仓库、在线文档和打印件中。受控的关键不是盖红章，而是唯一有效版本能被员工找到。
建议在文件首页写明编号、版本、生效日期、审批人和替代关系，并在在线文档系统中设置发布权限，历史版本只读归档。
代码、配置和基础设施脚本也可以纳入配置管理，审核时能通过提交记录证明变更经过评审。
记录要回答“谁、何时、做了什么、结果如何”。只有一句“已完成检查”，没有时间、人员和对象，很难作为证据。
保存期限要与业务和法规要求匹配。登录日志、操作日志、备份结果、权限审批都应明确保留时长，并确认系统配置真的支持。
同创云在软件客户现场常看到制度写三年、平台留三十天的情况。这类不一致改文件或改配置都行，但不能放着不管。
最有效的办法是做一次“反向验证”：从现场挑三条真实记录，倒查文件依据；再从文件挑三条要求，正查现场记录。
如果两边对不上，优先改文件去贴合合理做法，而不是强行让员工补一堆形式记录。补出来的记录经不起追问。
涉及外包开发和第三方组件的，还要确认供应商评价、代码交付和安全要求在实际合同中有所体现。
不一定。电子审批和电子签名同样可以作为证据，关键是能证明审批人身份、时间和版本，且不可随意篡改。
需要。清单要能一眼看出全部受控文件、当前版本和责任人，在线文档只是载体。
按业务需要、合同约定和法规要求综合确定，并确认平台配置能够支撑，不宜照抄其他企业。
通常要。交付物、版本、验收和安全要求应有记录，外包方访问权限也要纳入管理。
文件与现场一致，本质是让制度描述企业真实在做的事，再把不合理的地方改掉。同创云长期做ISO 27001等体系认证咨询与审核辅导，官网 https://www.shtcyun.com。
资产清单的编制范围可参考资产清单需要覆盖哪些信息类型，员工行为规范的考核要点见这篇说明，标准框架见ISO 27001标准页。
具体认证要求、审核安排和证书状态，以认证机构及国家认监委（CNCA）官方最新通知为准。更多问答见体系认证常见问题栏目。
本文由同创云体系认证研究中心整理，内容参考相关管理体系标准与认证认可通用规则；具体政策以认证机构和监管部门官方最新通知为准。