数据安全管理制度 操作规程及技术规范

很多团队一到写制度就卡住：要么把三层揉成一份文档，要么只写制度不写操作步骤，出事时没人知道该点哪个按钮。这篇把三层拆开讲清楚——制度管原则和责任、规程管动作和顺序、规范管配置和参数，每层给一份可对照的目录框架和落地检查点，适合正在做合规自查或准备上线前补文档的团队直接用。

很多团队一到写数据安全文档就卡住，要么把三层揉成一份几十页的东西发下去，要么只写制度不写操作步骤，真出事时没人知道该点哪个按钮、该找谁批。这篇把制度、规程、技术规范拆开讲清楚，制度管原则和责任，规程管动作和顺序，规范管配置和参数。

下面的框架适合正在做合规自查、或者上线前补文档的团队直接用。每层给一份可对照的目录骨架和落地检查点，照着填就行，不用从零想。

三层各管什么：先分清，再动笔

分不清三层的边界，写出来的一定是互相打架的文档。制度层回答的是「谁负责、什么不能做、违规怎么办」，读者是管理层和全员，里面不该出现具体命令和系统按钮。规程层回答「遇到某件事按什么顺序做」，读者是具体岗位，写成步骤和判断分支，能照着执行。规范层回答「具体配成什么样」，读者是运维和开发，写参数、阈值、字段、日志保留口径。

• 对应关系：一条制度要求往下必须能找到一条规程和一个技术配置兜底，找不到就是空条款
• 读者不同：制度给全员，规程给岗位，规范给系统和设备
• 颗粒度不同：制度管原则，规程管顺序，规范管数值
• 更新频率不同：制度一年动一次，规程跟着流程变，规范跟着配置变

制度层：目录骨架与责任划分

制度层最容易写空的地方是职责分工。只写一个「安全部门负责」等于没写，出事时没人认领。至少要写清三类角色：谁拍板做决策，谁日常执行，谁负责回头审计执行情况。这三类角色可以是同一个人兼任，但职责描述要分开。

• 总则与适用范围：说明覆盖哪些业务、哪些数据、哪些岗位
• 数据分类分级：先定级，后面规程和规范才有对象，分级口径可参照站内数据脱敏相关的判定思路
• 职责分工：决策者、执行者、审计者三类角色分别是谁
• 访问与授权：谁能申请、谁审批、多久复核一次
• 第三方与外包：外部人员能碰什么数据、走什么流程
• 事件报告与审计考核：发现异常后多久上报、漏报怎么处理

制度里出现的每一条禁止性要求，都要能在规程里找到一个对应的动作来兜底。

操作规程：写成能照着执行的步骤

规程写不好的典型症状是写成职责描述的翻版，比如「负责账号管理」这种句子，新人看完还是不知道该点哪里。正确的写法是按「触发条件—操作步骤—确认人—留痕位置」四段来，每一段都要能被人验证。

优先补三类最高频的动作：账号开通与回收、数据导出与对外提供、异常与泄露的初步处置。这三类覆盖了日常绝大部分风险场景，先写这三份，其余按优先级往后排。

1. 账号开通与回收写清申请入口、审批人、开通后多久内复核、离职或转岗后多久内回收；验证方式是抽查几个已离职账号的状态
2. 数据导出与对外提供写清导出申请的触发条件、谁批、导出了哪一批数据记在哪；验证方式是随便挑一次历史导出，看能不能追溯到审批记录
3. 异常与泄露初步处置写清发现后第一步做什么、多久内上报、由谁对外沟通；验证方式是做一次桌面推演，看参与人是否知道自己的动作

规程和制度的一个硬区别是：规程里允许出现具体系统名、页面名、按钮名，制度里不要出现。因为系统会换，制度不该跟着换版本。至于这类工具本身的可信度，可以到 /tools/speed-test 这类站内页面对照当时的检测结果再决定用哪个。

技术规范：配置、参数与留痕口径

规范层写的是可被检查项，每一条都要能落到一个可验证的对象上，比如某类接口、某类账号、某类日志表。写不出验证对象的条款，说明它本该属于制度层，放错地方了。

• 权限最小化：某类账号默认拿到什么权限、超出的怎么申请
• 传输与存储加密：哪些链路必须加密、密钥怎么管
• 脱敏规则：哪些字段对外展示时必须处理、按什么规则处理
• 日志口径：不该出现什么字段、留存多久、谁能查

日志部分容易写反，先明确「不该出现什么」比先定留存时长更重要。具体字段口径可以对照站内日志脱敏与留存相关页面，各家云厂商在不同时期的默认策略会变，到 /price-watch 这类页面核对当时的数字更稳妥。

落地顺序与自查对照

推进顺序建议是先定分级和责任，再补三类高频规程，最后逐条落到技术配置。一上来就写参数，往往写到一半发现分级还没定，前面的都得返工。

什么情况下这套框架不适用：业务完全离线、不接触外部数据时，技术规范可以大幅缩减，但账号管理和数据导出这两份规程仍然要保留，因为这两块是内部风险的主要来源。