近几年系统上云几乎成了默认选择，但一个常见的误解是：把服务器搬进云上，等保这件事就跟自己没关系了。实际情况恰恰相反——《网络安全法》规定的等级保护义务落在系统的运营使用单位身上，云平台只是把机房、物理环境、基础网络这些「地基」承担了过去，定级备案、建设整改、等级测评、年度复测这一整套动作，仍然要由企业自己走完。上云改变的是合规的做法，不是合规的义务。

一、先厘清前提：定级备案的责任主体仍是企业

不少企业第一次接触云上等保，会先去问云厂商「能不能给我出一张等保证明」。这个思路的偏差在于：云平台通常持有的是云服务平台的等保证书，证明的是平台自身合规；而你部署在云上的业务系统，是一个独立的定级对象，需要单独定级、单独备案、单独测评。两者是并列关系，不能相互替代。

所以正确的第一步仍然是内部盘点：系统承载什么数据、涉及多少用户、被破坏后影响哪些客体，据此形成定级报告；涉及三级及以上或定级存疑的，按属地要求组织专家评审；随后到属地公安机关备案。这一步没有因为上云而省掉，只是后续的整改动作可以借力云平台，少走一些重复建设的弯路。

二、责任分担模型：云平台承担什么，企业承担什么

云上等保的核心逻辑是「责任分担」——把等保 2.0 的控制项按「谁有能力控制谁来落实」拆成两半。可以粗略对照下面这张表：

层面主要承担方典型控制内容
物理与环境云平台机房出入控制、防灾、电力与温湿度保障
基础网络与虚拟化云平台网络边界防护、虚拟化隔离、平台侧安全审计
主机与系统层企业（云平台提供工具能力）镜像加固、补丁管理、账号权限、日志留存
应用与数据层企业身份鉴别、访问控制、数据备份、个人信息保护
安全管理与制度企业安全责任制、人员管理、应急预案与演练记录

读表的关键是看第二列：凡是落在云平台一侧的，企业通常只需引用云平台已有的合规材料作为符合性证据；凡是落在自己一侧的，才是整改投入真正要花力气的地方。

三、云上整改清单为什么更短，周期怎么估

与传统自建机房相比，云上方案的整改清单明显更短，主要因为三项能力由云平台或云化产品直接提供，企业不必再自购设备：

剩下的工作更偏向软件与管理层面——账号权限梳理、数据分类分级、备份策略、应急预案与演练记录等。这部分以人力和时间投入为主，不需要机房改造，也不用等设备到货，整体节奏通常更快。就周期而言，云上等保从定级备案到取得测评报告，一般约 1~2 个月，具体仍以属地公安机关的备案节奏和测评机构的排期为准。

如果系统目前还停留在自建或混合架构，比较稳妥的做法是先把官网、对外服务门户这类入口系统迁到云上做一轮验证，再逐步迁移核心系统，既缩短单次合规周期，也让后续建设更统一。建站与上云的衔接细节，可以参考网站建设服务的说明。

另外提醒一点：云上等保最容易出问题的环节往往不在技术整改，而在定级——定高了投入浪费，定低了备案退回重来，反而拖长周期。建议动手前先做一次系统盘点和定级论证，把边界画清楚，再决定哪些控制项引用云平台材料、哪些由自己补齐。等保证书服务可以承接从定级、备案、整改到测评的全过程；如果还在评估投入量级，也可以先获取参考报价，按系统数量和定级等级摸清大致范围，再安排内部预算与排期。

💡 提示：等保的实际周期与费用受系统数量、定级等级、现有安全基础和属地公安要求影响较大，文中时间口径仅为一般参考，请以备案地公安机关的要求和测评机构的实际排期为准。