粒度：少而清晰
三到五级加字段敏感标记，通常比十几级更好用。级别越多，业务记不住，配置也越容易出错；把细分需求放到字段标签或数据域上，而不是继续加级别。粒度设计的标准是业务能在一句话内说清自己该申请哪一级。
默认：够用的最小集
新员工、新系统默认只给完成工作所需的最小数据集，需要更多再申请。默认全开再回收的模式看起来省事，实际回收永远做不完；默认收紧、按需放开，长期摩擦更小，也更容易通过审计。新人上手也快。
审批：按风险分流
低风险数据自助取用并留记录，中风险由数据 owner 批，高风险上评审会。把所有申请都送同一个会，结果是排队与私下导表；分流的关键是把判定规则写进系统，由系统自动路由，而不是靠人判断。规则要写死到系统里。
打标：能自动就别手工
元数据、建表语句、数据血缘都能提供线索，自动打标加人工抽检，比纯手工登记可持续。手工台账在业务快速迭代时必然滞后；自动打标要有人复核例外，否则错标会一路传到权限配置。越往后改越贵。
底线：依据与识别
定级依据、重要数据识别、例外审批这三项不能为效率省略。效率优化的是做法，比如模板化、自动化、分流，而不是跳过判断；一旦重要数据被漏识别，后续出境与共享判断都会建立在错误前提上。后续补救代价很高。
适用与不适用
适合谁
- 分级执行被业务反复抱怨繁琐的企业
- 数据需求量大、审批排队明显的组织
- 正在做数据平台与权限中台建设的团队
不适合谁
- 尚未建立分级规则、无从分流的团队
- 希望用效率理由跳过重要数据识别的项目
典型场景
某企业的数据申请要填五张表、等两周，业务干脆找熟人导数据。治理组把级别压到四级，默认给最小集，低风险申请由系统自动放行并留记录，高风险才上会；打标改由元数据自动生成、按季度抽检。申请量没变，等待时间和私下导表都少了。
可执行步骤
- 把级别压到三到五级，另设字段敏感标记覆盖细分需求，不再增加级别，保持稳定
- 新账号与新系统默认给最小集，按需申请扩展并留记录与到期时间，到期回收
- 把风险判定规则写进系统，由系统自动路由到对应审批人，减少人工判断
- 用元数据与数据血缘自动打标，按季度抽检错标，发现问题立即修正，并留存记录
- 保留定级依据与重要数据识别，不随流程简化而删除，留档可查，便于审计
常见坑
- 级别越加越多，业务不知道申请哪一级，干脆绕过流程私下导表，风险反而更大，检查时也难解释，越滚越大。
- 默认全开再回收，权限越积越多，回收永远做不完，审计时谁也说不清谁有权限，离职人员也可能留着账号。
- 所有申请都上同一个会，排队两周，业务等不及，私下导表的情况反而更多，检查时很难解释，事后补材料也难。
- 为提效跳过重要数据识别，出境判断建立在错误前提上，事后补评估代价更高，问题会反复出现，越拖越贵。
自检与验收清单
- 级别数量是否少到业务能一句话说清自己要哪级
- 新账号与新系统开通时是否默认只给最小数据集
- 低中高风险是否按规则自动路由到对应审批人
- 打标是否由元数据自动生成，并按季度抽检，有抽检记录
- 定级依据与重要数据识别是否保留，纳入年度计划
常见问题
自助取用会不会失控？
关键在范围与留痕：自助只覆盖低风险数据，申请时自动记录用途与期限，到期回收，抽取部分申请做事后复核。完全无记录的自助才是失控；有边界、有记录、有抽检的自助，通常比层层审批更可控。
分级能不能只做一次？
不行。业务变化会带来新的数据集与用途，分级要年度复审、变更时增量复审。把复审挂到系统上线与共享审批上，比单独组织一次盘点更可持续；否则分级表会在半年内与现实脱节。
业务坚持要全量数据怎么办？
先问清用途与时限，能脱敏就脱敏，能查接口就不给批量。确实需要全量的，走高风险审批并限定使用范围、留存与删除要求；把理由与批准人记录下来，事后可追溯，也比口头同意更安全。