员工访问申请流程图（入职与调岗）
面向入职与调岗的员工访问申请流程图：由人力资源部触发的申请、角色权限配置、主管与系统负责人审批，以及旧角色权限的回收。
什么是员工访问申请流程图（入职与调岗）流程
员工访问申请流程之所以授予权限，是因为用工上发生了某件事，而不是因为有人开口要。人力资源部确认某人已经入职或者换了岗位，挂在这个岗位上的角色权限配置说明这个角色应该能做什么，直属主管确认角色没有认错，系统负责人审批其中一切敏感的部分，IT 负责开通。申请的单位是一个岗位而不是一个系统，正因如此，结果在一年之后仍然可以复核：“这个人持有财务分析师的角色权限配置”是一句别人可以检验的陈述，而“他们在 2023 年要过数据库权限”不是。
这不是通用的访问申请流程——在那个流程里，已经在岗的员工还差一个系统，于是自己提出申请。那条路径连同定期的权限复核，由另一份独立的访问申请流程模板覆盖；如果你们正在设计一张服务台表单，那一份才是更好的起点。它也不是员工入职流程，入职涵盖合同、背景调查、设备和第一天；更不是离职流程，离职处理的是离开的人。本模板覆盖的正是那三者留在中间的部分：给新员工的第一次权限授予，以及有人内部调岗时的权限重建。
内部调岗，正是大多数访问流程悄悄失效的地方。一次角色变更同时是一次入职和一次离职，而实际上跑起来的只有入职那一半。新的权限被加了上去，没有人写下旧的是哪些，两三次调动之后，一位资深员工手上还握着他们多年前就离开的岗位的权限。流程本身永远不会报告有问题，因为它并没有坏掉；这种累积要到一次权限复核或一次审计发现里才浮出来。因此下面这张图把调岗路径分成两条带标签的连线：“新增”和“回收”，并把两者都引回权限登记册的同一条记录，让回收和授予一样显眼。
本流程图涵盖的内容
本模板包含
- 五条泳道，即员工、直属主管、人力资源部、系统负责人与 IT，横跨五个阶段：生命周期触发、角色权限配置、审批、开通与确认。
- 触发点在人力资源部泳道而不是一张申请表：直属主管确认岗位角色和入职日期，人力资源部登记这次入职或调岗事件，然后由“入职还是调岗？”这道判断分流。
- 调岗分支从“列出原角色的权限”分出两条带标签的连线：“新增”继续走向角色权限配置，“回收”则直接交给 IT，去清除原角色的权限。
- “角色权限配置是否覆盖这个岗位？”这道判断，它的“否”分支把员工送去“提出额外权限申请并写明理由”，之后再回到直属主管审批。
- “是否涉及敏感系统？”这道判断只把那部分申请送到系统负责人，其“拒绝”分支终止于“访问申请被拒绝”；普通的角色权限配置权限则直接进入职责检查。
- 开通之前在 IT 泳道中的“是否存在职责分离冲突？”检查，冲突分支会缩小范围或加上一项控制措施后重新检查；随后是开通本身、一次同时覆盖授予与回收的权限登记册更新、对改动内容的确认，以及员工在新角色下亲自验证权限。
何时使用本模板
- 你们正在编写入职、调岗与离职程序中关于权限的那一半，需要把入职与调岗两条路径放在一页上，而不是分散在两份互不相干的检查表里
- 内部调岗一再让人留着前一个岗位的权限，你们需要说明回收这一步在哪里、由谁负责
- 你们正在配置由人力资源系统驱动的开通：一条人力资源记录在身份管理工具或服务管理工具中启动一个工作流；你们希望在自动化搭起来之前先把流程定下来
- 审计人员、客户的安全问卷或者认证评审问过你们，入职时权限是如何授予的、角色变更时又是如何调整的
- 职责被分散在人力资源部、直属主管、系统负责人与 IT 之间，目前没有人从头到尾对调岗事件负责
运作方式
把触发点指向你们真实的人力资源记录
把“登记入职或调岗事件”换成真正启动这个流程的那条记录，例如一张新员工入职表，或者你们人力资源系统里一条带生效日期的岗位变更。写明由谁录入，以及它必须在生效日期之前多久存在。正是这段提前量，决定了权限能不能在新角色的第一天就准备好。
在发布这张图之前，先把角色权限配置写出来
“查询角色权限配置”只有在配置确实存在时才有用。先从你们最常招聘、也最常把人调进去的那些角色开始，列出每一个角色需要的权限项，并给每一份配置指定一位具名负责人和一个复核日期。没有负责人的配置会慢慢漂移成“所有人曾经要过的东西的并集”，那样一来，按岗位而不是按系统提出申请的意义也就没有了。
定义什么算作敏感系统
“是否涉及敏感系统？”这条分支旁边需要一份成文标准。典型的触发条件是薪酬与财务系统、个人数据或健康数据、生产环境，以及任何带管理员权限的权限项。把门槛设得让这条分支只对少数申请生效；如果它对什么都生效，系统负责人的审批就变成盖橡皮图章，而普通事项也会被拖慢。
把回收那一半做成一项有负责人、有期限的任务
“回收”这条连线，是大多数组织并不具备的一步。决定由谁产出原角色权限的清单——通常是原主管，或者从你们的身份管理工具里导出——由谁执行回收，以及相对于调岗日期在什么时候完成。如果调岗者需要旧权限来完成交接，就把它作为一次带截止日期的延期授予，而不是让那项权限一直开着。
就职责分离规则以及谁可以接受冲突达成一致
列出一个人不得同时持有的组合，例如既创建供应商又审批向其付款，或者既写代码又自己把代码发布到生产环境。没有这份清单，这道检查只是装饰。然后写明谁可以接受一项无法避免的冲突，以及他们必须在该权限项上记录什么样的补偿性控制措施——在一个小团队里，冲突有时是唯一行得通的答案。
把它发布出去，然后拿接下来几次调岗来检验
把图分享给人力资源部、图中具名的那些主管、系统负责人和 IT，让所有人依据同一个版本工作。等接下来几次内部调岗过去之后，拿一个真实案例沿着图走一遍，看看回收那一半是不是真的跑了。让这张图处于版本控制之下并保留审批记录，意味着大家实际遵循的流程，和你们拿给评审人看的流程，是同一个。
常见问题
什么是员工访问申请流程？
它是权限在由用工事件驱动、而不是由临时申请驱动时所走的路径。人力资源部登记某人已经入职或者换了岗位，这个岗位的角色权限配置定义了权限项，直属主管确认角色没有认错，系统负责人审批其中一切敏感的部分，职责分离检查跑一遍，然后 IT 开通权限并做好记录。如果是调岗，流程还会回收挂在原角色上的权限。它的区别性特征在于触发点：流程从一条人力资源记录开始，于是权限跟着岗位走，而不是跟着收件箱走。
为什么换过岗位的员工最后手上权限过多？
因为调岗被当成了一次新增。接收方主管提出这个人现在需要什么，而那场对话里没有任何一句提到他们不再需要什么。原来的主管已经走开了，系统负责人只看得到新的申请，旧的权限项从来没有被撤销。这样重复两三次，一位资深员工手上的权限就横跨了好几个岗位，通常被称为权限蔓延或权限累积。解决办法是流程上的而不是技术上的：像本模板中的“回收”分支那样，把回收做成一项有负责人、有到期日的步骤，并把两半都记在同一次调岗上。
新员工和调岗员工的访问申请，应该由人力资源部还是 IT 负责？
人力资源部负责触发，IT 负责执行；只要其中一方被要求两件事都做，这个流程就会断掉。人力资源部是唯一能可靠知道某人已经入职或换岗的职能，而人力资源记录承载着整条时间线所依赖的生效日期。IT 握有管理权限，是唯一能够开通或回收任何权限的职能。介于两者之间的判断，属于确认角色的直属主管，以及对某个具体系统负责的系统负责人。把这四方分放在各自的泳道里，同时也正是防止有人自己申请、自己开通权限的做法。
有人变更角色时，访问控制方面的标准期望看到什么？
ISO/IEC 27001:2022 附录 A 包含关于访问控制（A.5.15）、身份管理（A.5.16）和访问权限（A.5.18）的控制措施；最后一项覆盖访问权限的开通、复核、修改与回收，并把角色变更视为应当调整权限的时点。附录 A 还覆盖了在用工关系变更或终止之后仍然存续的责任（A.6.5）。SOC 2 关于逻辑访问的通用准则立场相似：期望权限在凭据发放之前获得授权，并在角色变更时被修改或回收。它们都没有规定某个复核周期或者某种特定工具，也都不把一张图视为证据——真正被检验的是审批记录、开通记录，以及这个流程产生的权限登记册。