国企等保责任划分：集团与下属单位分工-等保测评网

国有企业在推进等级保护时，最先卡住的往往不是技术，而是"这件事归谁"。一个集团下面有总部、二级单位、三级单位，还有参股和委托运营的机构；系统建设有的在信息中心，有的在业务部门，有的干脆外包给集成商。等级保护制度里责任主体是明确的，但落到这套组织结构里，需要先把分工说清楚，后面的定级、备案、整改、测评才有抓手。

一、责任主体是谁，先按制度确认

按照《网络安全法》与等保 2.0 标准的要求，信息系统的运营、使用单位是网络安全等级保护的责任主体，主管部门负管理责任。这句话在集团场景里的含义是：谁实际运营和使用这套系统，谁就对这套系统的定级、备案、整改和测评负责，而不是简单地由集团总部统一兜底，也不是由建设单位或集成商承担。

判断责任主体可以问三个问题：

这套系统由哪个法人单位持有资产、承担日常运维？
系统里的业务数据由哪个单位产生，并由谁对外承担责任？
发生安全事件时，谁是对外报告与处置的第一责任人？

三个问题的答案指向同一个法人单位，责任主体就清楚了；答案不一致，说明存在委托运营或共用系统的情况，需要在备案材料里写明主责单位和相关方的责任分担。定级与备案的具体口径，可对照等保定级与等保备案的说明。

二、集团总部与下属单位的分工

集团型企业通常有两种推进方式，实际操作中多是混合使用：

总部统筹型：总部统一制定定级口径、模板和整改基线，统一选型安全产品与服务商，各单位按统一标准执行、各自完成备案。适合系统同质化高、下属单位技术力量薄弱的集团。
分级负责型：总部定规则、定考核，各二级单位作为责任主体自行定级备案、自行组织整改。适合业务差异大、系统形态复杂的集团。

无论采用哪种方式，有三件事建议由总部统一：定级口径与模板，避免同类系统在不同单位定出不同等级；服务商与安全产品的准入名录，避免重复选型和价格混乱；整改基线与技术标准，避免各单位整改深度参差不齐。

预算也是绕不开的一环。集团统一立项、按单位分摊，还是各单位各自列支，直接决定整改能不能按期落地。相对稳妥的做法是：日志审计、堡垒机、边界防护这类共性安全能力由总部集中建设，差异化的业务系统整改由各单位按清单自行承担。整改投入与系统规模、等级和现状差距相关，一般为数万元到数十万元不等，涉及大规模改造的可能更高，具体以属地要求为准。整改优先级怎么排，可参考等保整改。

三、多法人场景下最容易扯不清的三件事

第一件是共用系统。集团统一建设的 ERP、OA、人力资源系统，往往是总部建设、下属单位使用。这类系统建议明确一个主责单位负责备案与整改，其他使用单位在系统清单中作为使用方列出，避免同一套系统在不同法人主体下重复备案，或者谁都以为别人备案过。

第二件是委托运营。系统交给第三方运维，责任并不随运维合同转移。运营使用单位仍需在备案材料中明确自身责任，并通过合同条款、保密协议和运维审计把外包环节管起来。测评中较常出现的扣分点，恰恰集中在外包运维账号、远程接入和变更记录无人监管上。

第三件是参控股单位。股权关系不等于管理关系。如果集团对其信息系统没有实际管理权限，就不宜把该系统纳入集团统一的备案范围，应由实际运营单位履行责任，集团仅在行业监管层面做督导。

四、云、信创与系统变更后的责任边界

系统上云之后，物理环境与部分安全能力由云服务商承担，但身份鉴别、访问控制、数据保护、安全管理制度的责任仍留在运营使用单位。云上等保的关键动作，是取得云服务商的相关资质与测评材料，并在定级报告里写清责任分担，否则备案审核和测评阶段容易反复补件。

信创改造与等保叠加推进时，建议先定级再改造。等级决定整改深度和测评项范围，等级未定就采购设备，容易出现改造方向与测评要求不匹配、需要二次投入的情况。

系统发生重大变更——业务功能调整、部署位置迁移、数据规模显著变化——原则上应重新审视定级结论，必要时组织专家重新评审。这是很多单位忽略的一环：系统早已不是当年的形态，等级却一直沿用最初结论。测评前的准备事项可参考等级测评。

五、监督检查与年度自查怎么形成闭环

等保不是做完一次测评就结束。三级系统一般每年测评一次，二级系统原则上两年一次，具体执行口径以属地要求为准；除此之外，运营使用单位还要面对主管部门的监督检查与年度自查。

建议把四件事做成固定动作：每年对照等保标准做一次自查并形成问题清单；整改项建台账，明确责任人和完成时限；在系统上线审批环节嵌入等级确认，避免新系统漏定级；把账号复核、基线核查、日志审计做成季度常态化检查。

把这些分工与机制确定下来，国企的等保工作就不再依赖某一次集中突击，而是一条能长期稳定运行的管理流程。