ISO/IEC 27001:2022 认证标准解读 4.3 确定信息安全管理体系的范围

本文系统解读ISO/IEC 27001:2022第4.3条,围绕ISMS范围界定原则、边界和接口识别、范围过宽或过窄的风险、成文信息要求以及审核常见关注点展开,帮助组织把范围写得真实、清晰、可审核。

一、ISO/IEC 27001:2022 4.3 标准原文

ISO/IEC 27001:2022 4.3 确定信息安全管理体系的范围
条款要求:组织应在考虑4.1中的内外部议题、4.2中的相关方要求以及与其他组织和职能的接口和依赖关系后,确定信息安全管理体系的边界和适用性,并将该范围作为形成文件的信息予以保持并可获得。
范围界定的本质,不是画一个“尽量小”的认证圈,而是明确组织究竟对哪些业务、信息、资产、人员、场所和技术环境承担体系化的信息安全管理责任。
提示:完整原文请参阅 ISO/IEC 27001:2022 正式文本
引用:4.3决定了ISMS到底覆盖什么。如果范围失真,后续风险评估、控制适用和审核结论都会偏离真实经营风险。

二、条款解读说明

2.1 4.3是管理边界,也是责任边界

很多组织第一次做ISO 27001时,最先想到的是“范围能不能缩小一点,认证更容易通过”。这种思路短期看似节省成本,长期往往制造更大风险。因为范围并不是一个对外展示的文字游戏,而是组织管理责任、资源投入、控制覆盖和审计抽样的基础。把关键业务系统排除在范围外,短期可能减少工作量,但如果这些系统一旦出事仍然会影响客户交付、监管合规或品牌声誉,那么这个范围就是失真的。

4.3要求组织在范围界定时综合考虑内外部议题、相关方要求、接口和依赖关系,原因就在这里。信息安全风险往往跨边界传播。一个看似“外包给第三方”的模块,如果它处理核心数据、连接生产环境或掌握管理员权限,组织就不能简单以“不是我们自己开发”或“不是自有机房”为由把它排除掉。

2.2 范围界定的四个核心判断

判断维度 需要回答的问题 常见失误 建议表达方式
业务边界 哪些产品、服务、业务流程纳入ISMS 只写部门名称,不写具体业务 明确业务活动和关键流程
资产边界 哪些信息、系统、网络、设备和数据纳入管理 漏掉云资源、外包平台和共享系统 写清核心资产和技术环境
组织边界 哪些人员、岗位、组织单元承担职责 忽略集团共享职能和第三方支持 写清组织单元与接口关系
地理和逻辑边界 覆盖哪些场所、区域、租户、环境或网络段 把逻辑边界写得模糊不清 写清地点、平台和环境边界

2.3 范围不是越大越好,也不是越小越好

范围过大,会导致组织在资源不足、控制未成熟的情况下承诺过多,造成体系运行质量下降;范围过小,则会让风险从边界外渗透进来,导致体系丧失公信力。合适的范围应满足三个条件:第一,与经营实际一致;第二,覆盖主要信息安全风险和关键相关方要求;第三,组织有能力在该范围内实施、保持和改进ISMS。

注意:审核员通常允许组织分阶段扩大范围,但前提是当前范围必须真实、自洽,并且没有故意规避关键风险和关键要求。

三、实施要点

3.1 先从价值链和资产流转看范围

  • 梳理产品或服务从销售、交付、运维到退出的全流程,识别数据和控制权的流动。
  • 关注与核心业务相关的共享平台、支撑系统、外部云环境和第三方服务接口。
  • 不要只按组织架构画范围,因为信息安全问题更常沿着数据流和权限流扩散。

3.2 对接口和依赖做穿透分析

  • 识别与范围内业务直接相关的集团共享IT、HR、采购、法务、数据平台和第三方服务商。
  • 判断这些接口是否会影响访问控制、日志、备份、变更、事件响应和合规义务。
  • 即便某些对象不全部纳入范围,也要在范围说明中写清接口控制和依赖关系。

3.3 把范围文字写得审核员和业务人员都看得懂

  • 避免只写“某事业部相关业务”这类模糊表达,要写具体服务、地点、系统类型和组织单元。
  • 如果是多地点、多租户或多环境架构,要明确哪些纳入,哪些排除,以及排除理由。
  • 范围说明应能让不熟悉内部组织的人读后仍能判断边界。

3.4 处理“部分纳入”场景时要说明逻辑

  • 对于集团公司、共享服务中心和混合云环境,常见做法是“关键业务及其直接支撑环境纳入,集团共享控制通过接口管理承接”。
  • 此时要写清职责归属、服务边界和证据来源,避免形成控制真空。
  • 对于外包开发、托管运维等场景,应明确第三方虽不在组织边界内,但其活动通过合同、审计和访问控制纳入管理。

3.5 把范围作为动态对象管理

  • 新业务上线、并购整合、迁云、数据中心调整或组织拆分时,应重新评估范围。
  • 每年至少在管理评审中检查范围是否仍反映经营实际。
  • 当认证范围和内部管理范围不完全一致时,应避免对外传播产生误导。
成功:高质量的4.3通常能够用一段清晰范围描述加一张边界示意图,就让管理层、审核员和业务负责人对“管到哪里”为何这样划定达成一致。

四、常用工具与实施方法

工具/方法 应用目的 实施建议 输出成果
业务价值链梳理 识别应纳入的业务活动 以关键交付和数据流转为主线 业务边界清单
系统和资产映射图 识别核心技术边界 覆盖本地、云、外包和共享系统 资产边界图
接口依赖分析表 识别跨组织和跨系统影响 重点关注共享职能和第三方依赖 接口和依赖清单
范围适宜性评审 判断范围是否真实可管 由业务、IT、安全、法务共同复核 范围评审结论
边界示意图 提升可理解性和沟通效率 同步展示纳入、排除、接口和责任 范围说明附图
扩展:对于集团型组织,建议单独写一页“认证范围与集团共享能力关系说明”,这是减少审核争议的有效做法。

五、典型案例

案例一:SaaS公司避免把核心外包平台排除在外

  1. 背景:企业核心产品部署在公有云,部分运维监控由第三方平台承担。
  2. 问题:初版范围只写“研发中心和自有应用系统”,未体现云基础设施和第三方运维平台接口。
  3. 4.3动作:重新界定范围,将生产环境、日志平台、CI/CD、云账号管理和第三方运维接口纳入边界描述。
  4. 结果:风险评估和控制适用性更完整,审核时不再因“边界不清”被追问。
  5. 启示:只要它对核心业务安全有实质影响,就不能轻易排除。

案例二:集团企业处理共享IT中心接口

  1. 背景:子公司做认证,但邮箱、身份管理和终端基线由集团统一提供。
  2. 问题:子公司想把这些完全排除,导致访问控制和日志责任说不清。
  3. 4.3动作:在范围中明确子公司覆盖自身业务和数据处理活动,同时通过接口说明引用集团共享控制,保留SLA、职责矩阵和证据获取方式。
  4. 结果:范围保持聚焦,但控制责任没有悬空。
  5. 启示:共享能力可以不全部纳入组织边界,但不能不纳入管理逻辑。

案例三:制造企业将OT与IT边界一并说明

  1. 背景:企业既有办公IT系统,也有与生产相关的工业控制网络。
  2. 问题:早期范围只覆盖办公IT,忽视生产数据和远程维护链路。
  3. 4.3动作:重新评估后,将涉及生产计划、质量参数、远程维护接入和备份恢复的OT相关系统纳入管理范围。
  4. 结果:事件响应和变更控制开始兼顾生产连续性,体系更贴近业务实际。
  5. 启示:范围界定必须以真实风险边界为准,而不是以传统部门归属为准。

六、成文信息管理要求

4.3明确要求范围作为形成文件的信息予以保持并可获得,这是少数明确提出成文信息要求的基础条款之一。因此,组织不仅要“想清楚”,还必须“写清楚、管清楚、更新清楚”。

建议文件或记录 关键内容 责任部门 审核价值
ISMS范围说明 业务、地点、系统、组织单元、边界和适用性 体系负责人 证明范围已正式确定
范围界定依据记录 与4.1、4.2关联的分析依据和决策逻辑 安全/业务/法务/IT 证明范围不是拍脑袋决定
接口与依赖清单 共享职能、第三方依赖、边界控制方式 IT/采购/安全 证明边界外对象已被识别和管理
范围更新记录 组织变化、系统变化、业务变化后的修订痕迹 体系办 证明范围持续适宜
警告:范围说明如果只有一句模糊表述,既无法支撑审核抽样,也无法指导内部职责分配,最终会导致“认证有范围、管理没边界”的空转状态。

七、常见误区及踩坑提醒

误区 问题表现 正确做法
为了通过审核故意缩小范围 关键系统和关键流程被排除,但实际风险仍存在 以真实经营风险和相关方要求为依据界定范围
只按组织架构,不看数据和系统流 边界与风险传播路径脱节 用业务流、数据流和权限流辅助界定范围
忽略共享服务和第三方接口 控制责任悬空,证据获取困难 在范围中单列接口和依赖关系
范围写得过于抽象 审核员无法判断纳入对象,内部也容易误解 写清业务、地点、系统、组织单元和排除逻辑
范围长期不更新 业务早已变化,文件仍停留在旧版本 将范围复核纳入管理评审和重大变更触发机制
警告:避免范围过窄、边界模糊或接口关系不清,确保第4.3条得到有效实施,防止信息安全管理体系与真实业务风险脱节。
小结:第4.3条决定信息安全管理体系究竟“管到哪里”。只有把业务活动、关键资产、组织单元以及接口和依赖关系界定清楚,后续的风险评估、控制适用、审核抽样和资源投入才能建立在真实可靠的基础上。