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