不少技术团队把系统迁移上云，注意力都放在架构、成本和稳定性上，却忽略了"数据合规"这道隐形门槛。等监管检查、客户尽调或安全事件找上门，才回头补课，往往要推倒重来。下面结合实务，把上云过程中最常踩的 4 个数据合规坑讲清楚，供技术负责人和创业者参考。
一、等保不是可选，而是硬性门槛
只要系统涉及个人信息或重要数据，上线前通常就要做网络安全等级保护定级备案。很多团队误以为"我们只是个小应用，不用做等保"，结果在招投标、与政企客户签约时被一票否决。定级不是越高越好，但要定得准——业务影响面、数据规模、用户群体都是定级依据。建议在上云架构设计阶段就把等保要求同步进去，别等系统跑起来再补。
二、数据分类分级是后面所有动作的基础
《数据安全法》要求对数据实行分类分级保护。落到工程上，就是先弄清楚：系统里哪些是个人的、哪些是敏感的、哪些是核心业务数据。没有这层梳理，加密、访问控制、留存期限都无从谈起。常见做法是建立一张数据资产清单，标清字段级敏感度，再据此配置权限和脱敏策略。这一步偷懒，后面任何一个合规动作都会变成"盲操作"。
三、日志留存和审计轨迹必须留够时间
出安全事件时，最尴尬的是拿不出操作日志。监管对日志留存有最低期限要求，而不少团队为了省存储，把访问日志设成几天就轮转覆盖。正确的做法是对关键操作（登录、权限变更、数据导出）做独立、防篡改的审计日志，并满足法定留存期。这既是合规需要，也是事后厘清责任、自证清白的唯一依据。
四、云厂商和你之间的责任边界要写进合同
上云不等于把责任也"云"出去。基础设施层的安全归厂商，但业务数据、访问控制、应用漏洞的防护责任仍在你这边。很多团队签云服务协议时直接点"同意"，没看清责任划分和赔付条款，出事才发现关键损失不在理赔范围。建议在采购或续约时，把数据归属、泄露通知时限、应急处置配合义务明确写进商务条款，而不是只依赖平台默认协议。
落地建议：把合规动作前置到架构评审环节，而不是上线后补救。一张数据资产清单、一次等保定级、一套审计日志策略、一份责任边界清晰的云服务合同，四件事到位，上云才算真正"稳"。
（本文由执业律师从合规视角撰稿，仅供交流学习，不构成针对具体事项的法律意见。）
