软件企业做ISO 27001，最常见的误判是把它当成“多写几份制度、多配几台防火墙”的项目。
实际上，审核员最先问的是信息资产在哪里、谁负责、依据什么判断风险高低。这些答案在差距分析阶段没想清楚，后面文件写得越多越乱。
本文从ISMS范围、合规底账、角色分工和资源安排四个方面，说明软件企业摸底时应当核对的具体条款。
差距分析的产出不是文件清单，而是一份能说明“范围在哪、风险怎么算、谁来管、钱花在哪”的判断依据。
下面这张表适合首次申请、扩项和换版三种情形，用来判断差距分析是否做扎实。
| 核对维度 | 常见成熟做法 | 典型缺口 | 可用证据 |
|---|---|---|---|
| 体系范围 | 范围声明写明产品、系统、场所和支撑部门 | 只写公司名称，未界定系统和数据 | 范围声明、网络与系统清单 |
| 风险评估 | 有统一准则、赋值方法和接受阈值 | 各部门各用一套表格，结论无法比较 | 风险评估表、处置计划 |
| 适用性声明 | 控制项逐条说明纳入或排除的理由 | 直接套模板，排除理由一句话带过 | SoA与风险处置记录的对应关系 |
| 合规义务 | 把法规要求转成内部检查项 | 只收集法规文本，未落到流程 | 合规清单、检查记录 |
四个维度里，只要风险评估和适用性声明对不上，审核时几乎一定会被追问。
软件企业的研发流程通常比行政流程规范，差距往往出现在资产管理和供应商管理上。代码仓库、测试环境、生产数据库、第三方SDK都算信息资产。
差距分析要逐项确认：资产有没有责任人、有没有分级、访问权限是否按岗设置、离职和转岗是否及时回收。
开发、测试、运维之间的权限隔离也常被忽略。同一个账号能同时改代码和动生产库，是很难解释清楚的现状。
把已有合规成果用起来，是软件企业做差距分析的捷径。等级保护测评报告、渗透测试报告、隐私政策文本，都可以转为ISMS的输入。
涉及个人信息处理的业务，要梳理收集、存储、使用、共享、删除各环节的记录，并明确告知与同意的实现方式。
有海外客户的，还要看数据出境场景和合同中的安全条款，这些通常在客户二方审核时被重点查验。
ISO 27001要求最高管理者介入，不只是签一份文件。差距分析要确认信息安全方针由谁批准、资源由谁保障、风险处置由谁拍板。
日常执行层面，至少要有信息安全负责人、各系统资产责任人、人事与行政配合岗位，以及能独立开展内审的人员。
同创云在软件类项目中一般建议先画一张职责矩阵，把条款和岗位对应起来，避免所有事都压在运维一个人身上。
预算通常包括风险评估与渗透测试、备份与日志平台、终端安全、员工培训和外部辅导。
时间上要留出风险处置措施落地和运行记录积累的周期，尤其是日志留存、权限复核、供应商评价这类按月或按季执行的动作。
如果计划与等级保护测评或年度审计同步，建议把时间表合并排，避免同一批人反复应付检查。
取决于客户和投标要求。规模小不代表要求低，但可以把范围聚焦在核心系统和主要办公场所，降低落地难度。
通常要纳入。企业仍需对云上的配置、账号和数据进行管控，云服务商的责任不能替代自身管理责任。
不能直接替代，但可以作为重要输入。ISO 27001还要求从业务影响和威胁角度评价风险并形成处置计划。
取决于范围和配合程度，通常需要数周到数月。资产盘点和风险研讨占用的时间往往比写文件更多。
差距分析做得实，后面的文件、运行和审核都会顺；做得虚，问题只会在现场集中爆发。同创云长期做ISO 27001等体系认证咨询与审核辅导，官网 https://www.shtcyun.com。
首次申请的条件核对可参考申请条件里容易漏掉什么，文件清单的设计思路见文件化信息清单怎么设计，标准框架见ISO 27001标准页。
具体认证要求、审核安排和证书状态，以认证机构及国家认监委（CNCA）官方最新通知为准。更多问答见体系认证常见问题栏目。
本文由同创云体系认证研究中心整理，内容参考相关管理体系标准与认证认可通用规则；具体政策以认证机构和监管部门官方最新通知为准。