NIST 网络安全框架 2.0 为组织理解、排序和沟通网络安全风险提供高层结果框架；美国能源部的 C2M2 则用于评估包括信息技术和运行技术在内的相关能力。[1][2] 本文将这些公开材料作为管理方法参考，不将其视为中国企业的强制合规要求，也不以框架名称代替适用法律、行业规定和现场制度。

信息技术通常关注应用服务、身份、数据与平台的可靠运行，运行技术则直接关联设备与物理过程。二者可以共享治理目标，但不能简单复制操作节奏。适合办公应用的更新方式，未必适合连续生产环境；现场对稳定性的要求，也不能成为长期不识别依赖、不安排改进的理由。

管理层需要建立共同的问题表达：某项服务受影响时，哪些生产或经营活动将受到影响，允许怎样降级，谁能够决策，恢复需要什么条件。这样，双方讨论的对象就从“哪一类系统更重要”转向“怎样维持可接受的业务结果”。技术团队仍保留专业判断，但资源配置有了共同基础。

支策建议先选择一项关键业务服务形成样板，例如设备状态监测、生产计划协同或经营结算支持。选择应依据实际业务影响和边界清晰程度，而不是为了展示技术复杂度。样板的目标是验证跨部门协作方式，识别责任和证据缺口，再将有效机制扩展到其他服务。

服务依赖视图不能只是一张网络拓扑。除了应用、网络、现场设备和数据，还应包含身份认证、时间同步、配置管理、专业人员、外部服务与供应商支持等关系。某个看似边缘的共同服务，可能同时影响多个关键业务；如果只按部门资产清单分开管理，这类共同依赖容易被忽略。

绘制关系时，应从业务过程逐步向下展开，并标记责任人与证据状态。每个依赖至少说明它提供什么能力、失效会怎样影响业务、是否存在替代方式，以及谁能够确认当前情况。对于无法核实的部分，明确标记未知，而不是根据架构设计图推定现场已经按图运行。

还应把正常运行依赖与恢复依赖分开。某系统平时不常被使用，却可能在恢复时提供配置、凭据、安装资料或专业支持。若这些条件本身依赖正在恢复的服务，就可能形成循环等待。通过桌面推演可以发现部分问题，但仍需要在批准的环境与范围内验证关键条件是否真实可用。

依赖视图的精细度应服务于决策。管理层需要看到关键业务、共同依赖和责任边界，专业团队需要能够进一步查看配置与技术记录。没有必要把所有细节放进同一张图，也不能为了图面简洁删去重要关系。服务发生变更、供应商变化或恢复方案调整时，视图应同步更新并留存版本。

NIST 的 OT 安全指南明确提出，相关工作需要考虑性能、可靠性与安全等特殊要求。[3] 截至本文资料日期，NIST 官方目录将 Rev.3 标为正式版本，将 2026 年发布的 Rev.4 标为草案。[4] 因此本文依据正式版本讨论管理原则，不把草案内容描述为已经生效的要求，也不提供现场控制系统的具体操作指令。

每项涉及 IT 与 OT 连接的变更，都应说明业务目的、影响范围、依赖关系、验证方式、实施窗口与回退条件。项目团队需要解释预期收益，运行团队需要确认现场约束，安全与技术团队需要识别新的风险。评审结果可以是同意实施、补充验证或调整设计，但必须明确依据，避免形成只收集签名的审批流程。

变更窗口应由实际业务安排决定，不能只看技术人员何时有空。验证环境与实际环境之间的差异也应记录，例如设备版本、网络条件、负荷状态或外部服务不同。测试通过只能证明在已验证条件下达到预期，不能自动扩展为所有现场状态都安全可用。实施前应明确差异如何处理、哪些事项仍需观察。

紧急变更同样需要可执行的责任边界。应预先明确哪些情形可以走紧急流程、谁拥有批准权、如何记录临时措施，以及何时补充复核。不能因为情况紧急就失去基本记录，也不能让过于复杂的程序使团队无法应对实际事件。日常机制越清晰，异常情况下越容易保持协调。

外部供应商经常掌握专业知识、维护工具和关键配置。合作能够补充能力，但企业仍需理解关键业务的依赖与风险。合同应明确服务范围、响应责任、访问条件、知识移交和退出安排，尤其关注设备或产品停止支持后如何维持可接受的运行状态，而不是把责任简化为“由厂家保障”。

远程维护应围绕明确任务授权，说明访问对象、有效时间、责任人及必要记录。任务完成后需要确认权限是否仍有理由保留。长期合作关系不能自然替代每次任务的边界确认；同样，禁止所有外部支持也未必符合实际业务需要。治理重点是让访问有依据、过程可追溯、结束可确认。

资产管理应覆盖版本、配置、支持状态、维护责任与业务归属。仅有设备数量和采购日期，无法支撑韧性判断。对于老旧或无法采用常规更新方式的设备，应记录限制条件、替代措施、复核时间和退出路径。接受风险需要明确依据与责任，而不是把长期未解决的问题默认视为已经接受。

供应链变化也会影响恢复能力。更换维护商、合同到期、关键人员离职或产品停产，都可能使原有恢复方案失效。建议将这些变化纳入服务复核，确认资料、配置、授权和知识能否由企业或替代团队取得。采购验收应检查持续运行条件，而不仅是设备安装完成和功能演示通过。

恢复目标应由业务负责人和专业团队共同确定，区分恢复时间、可接受的数据损失、最低运行能力及恢复后的验证条件。目标不能只是从通用模板复制的数字，也不能完全由当前技术能力倒推。业务需求与现有能力存在差距时，应明确差距、临时安排及需要投入的改进事项。

备份成功是必要证据之一，但恢复还依赖配置、软件与硬件条件、身份权限、人员知识和服务顺序。备份存在却无法读取、资料齐全却没有具备授权的人员、单项系统恢复却缺少上游依赖，都可能影响业务。演练应围绕完整服务安排，而不是只验证某个文件可以被打开。

验证可以分为资料核对、桌面推演和受控恢复等不同层次。每一层都应写清已经证明什么、尚未证明什么。实际验证必须在批准的范围、环境与安全条件下开展，避免为了演练影响生产。若部分场景无法现场验证，应保留证据限制，并由管理层了解仍需承担的不确定性。

演练结束后，应记录实际耗时、等待原因、人员协作、缺失资料以及恢复后的业务检查结果。问题需要有责任人、完成条件和复核安排，不能只形成一份总结。真正有价值的演练可能暴露大量问题；这些发现能否进入持续改进，比演练当天是否顺利展示更能说明治理质量。

成熟度评估适合发现能力缺口和组织讨论，但不能直接表示某项关键服务已经具备韧性。企业可以在 C2M2 等公开方法的启发下构建内部改进清单，仍需将每个结果连接到具体服务、责任人和证据。[2] 分数提高如果没有改变实际依赖、变更或恢复能力，就不足以证明业务风险下降。

建议同时观察覆盖程度、执行情况和验证结果。覆盖程度说明哪些关键服务已经建立依赖与责任；执行情况说明变更、授权和交接是否按约定完成；验证结果则说明恢复目标是否在相应条件下得到支持。三类指标各自回答不同问题，不能用文档覆盖率替代实际能力，也不能只关注一次演练成绩。

指标分母必须清楚。关键服务清单是否经过业务确认，变更统计是否包含紧急变更，恢复验证是否区分桌面和实际操作，都会影响结果。对尚未验证、无法读取或数据缺失的事项，应单独列示，不能把它们从分母中删除后宣称全面达标。评价应帮助管理层理解剩余风险，而不是制造好看的完成率。

风险排序要兼顾业务影响、共同依赖、现有保护和改进成本。某些问题影响范围大但处理复杂，可以先安排可执行的临时措施，再推进长期治理；某些问题虽然容易修复，却未必应抢占关键资源。管理层需要看到选择依据、暂缓原因和复核时间，使资金与人员配置可以持续调整。

对于新建数字化项目，应将服务依赖、变更评审、供应商责任和运行交接纳入项目计划，从设计阶段就考虑恢复与持续维护。项目验收除了功能效果，还应检查运营团队是否取得必要资料、知识与权限。若持续责任尚未落实，项目虽然技术上完成，业务上仍可能处于无人承担的过渡状态。

对于存量环境，可以优先选择影响较大且依赖复杂的服务逐步补齐。无需等待全公司资产数据完全准确才开始工作，但必须标明证据缺口。先建立能够支撑决策的最小视图，识别共同依赖和紧迫问题，再逐步完善细节。大范围盘点如果长期无法进入改进，会消耗资源而不改变实际能力。

每一阶段都应交付能够使用的成果。首阶段明确服务、责任和主要依赖；随后补齐变更、访问与交接安排；再开展适当层次的恢复验证并关闭关键问题。完成阶段不意味着风险消失，而是形成下一轮决策需要的证据。企业可以根据业务变化重新调整顺序，避免固定路线图限制必要行动。

预算应同时覆盖改造和日常维护。依赖视图更新、供应商复核、资料管理、演练准备与问题关闭都需要持续投入。若只为工具采购安排资金，却没有运营责任和时间，治理成果会逐渐失效。建议把这些工作纳入业务与技术团队共同认可的计划，减少临时协调对个人经验的依赖。

联合治理机制应明确谁对业务可接受程度负责，谁负责专业评估，谁执行改进，谁在异常时作出协调决策。共同责任不能变成所有人都有责任但无人最终决定。对于跨部门争议，应规定升级路径和必要证据，使关键事项能够及时形成结论，并保留不同意见与限制条件。

管理层可以从一次真实项目评审或一次恢复桌面推演开始，观察团队能否使用同一份服务视图解释影响、边界和责任。如果无法回答，应把缺口转化为明确工作，而不是要求立即提交更复杂的报告。治理机制的价值，在于帮助团队作出更好的决定，并持续验证决定是否有效。

IT 与 OT 协同最终需要形成稳定的工作关系：业务变化时共同识别依赖，技术变化时共同确认影响，出现异常时共同执行已经准备的安排。工具与框架可以支持这一过程，但不能替代专业判断与实际验证。企业应保留对关键服务的理解与控制能力，并使其随组织、设备和供应商变化持续更新。