数据访问申请流程图（从提交申请到权限回收）
数据访问申请流程图：写明使用目的、查阅数据集分级、由数据责任人决定、完成个人信息核查、开通限期访问，再复核或回收。
什么是数据访问申请流程图（从提交申请到权限回收）流程
对数据的申请，往往被当成对软件的申请来处理。一张工单过来，说要开通数仓权限，谁手里有账号谁就把权限给了；一个原本只需要一张表来回答一个问题的人，最后能读到集群上的每一个库，包括装着薪酬、患者标识和银行卡号的那些。大部分损害来自三个习惯。审批人是按“谁在技术上给得了权限”挑出来的，而不是按“谁对这份数据负责”挑出来的。申请写的是一个系统而不是一个目的，于是最小权限根本没有可以对照检验的东西。授权没有结束日期，于是它熬过了项目、熬过了换团队，偶尔还熬过了离职。数据访问还是唯一一类几乎总有“更小的答案”可选的访问——一列脱敏字段、一条行级过滤、一张预聚合表——但没有人主动提，因为提这个比直接给原始表更费时间。结果就是：没有人说得清谁能读到什么，而回头一条条看，没有哪一次申请单独看是不合理的。
本图讲的是数据集，不是账号。如果一位在岗员工只是还需要多用一个应用系统，问题在于谁来审批、谁来开通，那属于 /zh/templates/访问申请流程 上的通用访问申请流程；由人事系统的入职或调岗事件驱动的那个版本，则在 /zh/templates/员工访问申请流程 这一页。身份本身的创建、变更与停用——账号、目录组、许可证——属于 /zh/templates/用户账号开通流程 上的用户账号开通流程；本图的一切都假定申请人已经有一个能用的账号，只问这个账号可以读到什么。它同样不是来自组织外部的请求：个人要求获取自己个人信息的副本，触发的是一项有法定时限、有身份核验要求、也有明确拒绝情形的义务，那画在 /zh/templates/数据主体权利请求流程 上。而如果数据已经流到了不该流到的地方，这张图就完全不对了——遏制、对个人权益的风险判断，以及是否在 72 小时内向监管机构报告，都在 /zh/templates/数据泄露响应流程 上。剩下留在这里的东西窄而具体：一位内部人员、一个具名的数据集、一个写明的目的，以及一位做决定的责任人。
多数成文的数据访问程序留给习惯去处理的那些判断，在这里被明确画了出来。“是否已登记并指定数据责任人？”排在任何评估之前，因为一个没有责任人的数据集，谁都批不了；而多数组织的真实情况是，某张表最终被定级，靠的正是针对它的第一次申请——“否”分支绕回登记与定级，而不是升级给当初恰好建了这条数据管道的人。“该目的需要哪一种访问？”是一个三岔分支，而不是一道是非题，于是脱敏或聚合这条路径实实在在地画在图上，必须被逐一排除，而不是从头到尾没人提起。流程也不止步于授权那一刻：“是否在到期前完成复核？”让到期成为默认、续期成为例外，这与大多数权限实际被持有的方式恰好相反；而“岗位或目的是否发生变化？”给了数据责任人第二个回收理由，它不必等到某个复核日期。应急路径被画出来也是同一个道理——线上出故障时，工程师总归会用某种方式碰到数据，所以“是否事后补批通过？”把补批与回收摆在应急通道访问的后面，而不是假装它不存在。
本流程图涵盖的内容
本模板包含
- 五条泳道——申请人、数据管家、数据责任人、隐私合规部、数据平台团队——铺在五个阶段上：申请、分级、责任人评估、开通、复核与回收。
- 一份必须带着理由的申请：“提交申请并写明使用目的”是唯一一条常规入口，而“是否为故障应急访问？”这条分支把线上故障场景直接送往“开通带日志的应急通道访问”，而不是任由它在图外发生。该授权随后要面对“是否事后补批通过？”，若无人补批，则终止于“应急访问已回收并上报”。
- 数据管家泳道中的“是否已登记并指定数据责任人？”，其“否”分支走“完成分级并指定数据责任人”，再绕回数据目录查找，因此一个无人负责的数据集不会被默认批准。
- 由数据责任人而不是 IT 掌握决定权：“评估使用目的与最小权限”，接着是“目的是否足以支撑该访问？”，其“否”分支终止于“申请被拒绝并记录理由”；而“是否涉及个人信息？”把案件路由进隐私合规部泳道。
- 一条真正有牙齿的个人信息分支：“记录合法性基础并最小化字段”，随后是三岔的“隐私合规评审是否通过？”——放行该申请、按同一个拒绝终点驳回，或者送去“完成影响评估并设定条件”，等剩余风险清楚之后再回来要第二次答复。
- 三岔的“该目的需要哪一种访问？”——脱敏或聚合、原始受限数据（额外增加一步“签署数据使用协议”）、原始内部数据——三条都汇合到“开通访问并设置到期日”、查询日志与台账登记。随后“岗位或目的是否发生变化？”与“是否在到期前完成复核？”把权限绕回一次新的授权，或者送出到“访问已回收并更新台账”。
何时使用本模板
- 你们要为数仓、湖仓或报表层撰写数据治理或数据管理制度中的访问章节，需要用一页说明白：做决定的是数据责任人，而不是手握账号的那个团队。
- 你们的分析师手上还留着两年前就已结项的项目权限，你们希望把到期与复核内建进流程，而不是每年搞一次谁都不爱做的大扫除。
- 你们正在数据目录或权限治理平台里配置申请流，希望在写进系统之前先把审批路径和分级门槛谈定。
- 工程师有一条进入生产数据的应急通道，事后却无人复核，你们需要把补批与回收这两步画在数据责任人和值班同事都看得见的地方。
- 你们的隐私合规团队和数据平台团队反复争论个人信息该由谁拍板，你们希望把合法性基础、最小化和影响评估这几步放进流程内部，而不是挂在流程末尾。
运作方式
把泳道改成你们自己的组织
把申请人、数据管家、数据责任人、隐私合规部和数据平台团队换成你们真实存在的角色。即便今天这两件事由同一个人在做，也要让数据责任人和平台团队保持分开——把它们合并，正是“开权限的人同时也是批权限的人”这类流程的由来。如果没有隐私合规部，就写上实际承担这项责任的那个人，而不是删掉这条泳道；如果数据管家的职责在你们这里还是非正式的，就把领域负责人放在那里，并把这件事写下来。
把你们的分级方案写进图里
在分级层级真正存在之前，“查阅分级与处理规则”是一个空步骤。给它们命名——公开、内部、机密、受限，或者你们方案里用的任何一套——并在每一级旁边写清楚它允许什么：只能在原地查询、允许导出、必须脱敏、需要签署协议。然后说明哪一级触发数据使用协议这条分支，哪一级永远不得离开分析环境。没有这张对照表，每一次申请都要从头辩一遍，而结论会随审批人漂移。
让目的说明真正承担作用
定义一份申请至少必须说清楚什么：要回答的问题、需要的表和字段、涉及谁的记录、希望用多久，以及导出的数据存放在哪里。写着“用于分析”的申请应当被退回，而不是被批准。这是整页上最便宜的一道控制，因为一段写得像样的目的说明，会让最小权限判断、脱敏决定和到期日几乎变成机械动作；而一段含糊的目的说明，会让这三件事全都变成随意裁量。
按分级设定默认有效期
为每一个分级给“开通访问并设置到期日”配一个默认值：应急通道取故障处理窗口，受限数据取九十天左右，内部数据取六到十二个月，与项目绑定的取项目结束日期。允许申请人要求更短的期限，而任何超过默认值的期限都要由数据责任人明确决定。到期日是那种能熬过组织调整、工具迁移、以及所有人都忘了这套流程曾经存在的控制手段。
在需要之前先把应急路径谈定
决定谁可以启用应急通道、它开通什么、从哪个账号运行、会话如何记录，以及在开通的那一刻通知谁。然后设定补批时限——一个不长的工作日数——而更要紧的是，决定没有人补批时会发生什么。只有到期自动回收这一种版本站得住，因为一个没有后果的事后审批队列，一个季度之内就会变成永久积压。
先走一遍，再发布一个版本
把画好的图拿给一位数据责任人、一位经常申请权限的分析师、执行授权的平台工程师，以及负责隐私合规的人，用上个季度的三次真实申请来检验它，其中包括一次被拒绝的和一次走了应急通道的。按实际发生的情况修正图，而不是按制度上写的情况。然后发布该版本、保留此前的版本，并从数据治理制度里链接过去，让读者知道自己看的是哪一版。
常见问题
数据访问申请流程包含哪些步骤？
提交一份写明目的而不是写明系统的申请；在数据目录中定位该数据集，查阅它的分级与处理规则；确认它已有具名的数据责任人，没有就先定级并指定责任人；由该责任人按最小权限评估目的并做出决定；涉及个人信息的，记录合法性基础、最小化字段，并走隐私合规评审或影响评估；在给原始数据之前先给出脱敏或聚合的方案；受限数据补一份签署的数据使用协议；开通访问并设置到期日；开启查询日志；把该权限登记进权限台账；然后要么在到期前完成复核，要么回收——本人岗位或使用目的一变，立即回收。实践中最常缺的三步，是脱敏这条替代方案、到期日，以及岗位变化触发的回收。
数据集的访问该由 IT 还是数据责任人来批？
由数据责任人，也就是这份数据所描述的那块业务里真正负责的那个人，而不是运维该平台的团队。这里要做的判断是“这个目的是否配得上这份数据”，只有真正懂这些记录含义的人做得了。平台团队执行授权、设置到期、打开日志；它不应当同时决定谁有资格读薪酬、患者或客户记录。直属主管的审批值得加在最前面做一道门槛，因为它确认了这次申请属于本人的工作范围，但它替代不了数据责任人的决定。如果一个数据集确实找不到责任人，这件事本身就是一条发现——所以本图把“是否已登记并指定数据责任人？”放在评估之前，而不是之后。
数据访问的有效期应该设多久？
够完成写明的目的，不多一天；默认值由分级决定，而不是每次申请单独谈。一套可行的做法是：应急通道取故障处理时长，受限数据或个人信息取九十天左右，普通内部数据取六到十二个月，与项目绑定的取项目结束日期。机制比数字更要紧：有了到期日，回收成为默认，续期成为需要主动去做的那一方，于是当流程被疏于维护时，权限会自己衰减；而没有到期日的权限只会不断累积。请数据责任人做复核时，把查询次数连同申请一起发过去——半年没人用过的权限会被毫无争议地拿掉，而一份不带使用数据的名单，几乎总是被整批批准。
什么样的数据访问申请需要做影响评估？
在中国内地，《个人信息保护法》第五十五条把个人信息保护影响评估（PIA）定为法定动作：处理敏感个人信息、利用个人信息进行自动化决策、委托处理或向其他处理者提供个人信息、向境外提供个人信息，以及其他对个人权益有重大影响的处理活动，都在其列。如果你们同时受欧盟或英国 GDPR 约束，那里的对应物是数据保护影响评估（DPIA）：当处理很可能对个人构成高风险时必须做，尤其是大规模处理特殊类别数据、系统性监控，以及产生法律或类似重大影响的自动化决策，各监管机构还会各自公布必须做 DPIA 的操作清单。落到一次内部分析申请上，真正的触发点通常是：涉及的人群规模有多大、数据是否属于敏感个人信息、个人是否合理预期得到这种使用，以及产出是否会反过来影响针对他们的决定。实践中有两件事最有用：对每一次涉及个人信息的申请都做筛查，而不是等有人提出疑虑；以及把评估结论当作授权上的条件来执行——哪些字段必须脱敏、保留多久、禁止重新识别——而不是当作一份归档之后再无人看的文档。
本页与通用访问申请流程有什么不同？
/zh/templates/访问申请流程 上的通用访问申请流程覆盖的是系统与应用：某个人需要业务系统里的一个角色，直属主管和系统负责人审批，跑一道职责分离检查，然后由 IT 开通。本页覆盖的是数据集，因此有三件事不同。审批人是数据责任人而不是系统负责人，因为问题在于这些记录的含义，而不在于某个应用的功能。中间多了一个分级步骤，因为答案取决于表里装的是什么。以及存在脱敏或聚合这种替代方案，而它在应用权限里没有对应物——你没法把一个财务模块的百分之六十给某个人，但你可以给他一个抹掉标识字段的视图。如果你们在设计应用权限的服务台表单，就从通用流程开始；如果你们要管的是谁可以查询数仓，就从这一份开始。