员工访问申请流程图（入职与调岗）
面向入职与调岗的员工访问申请流程图：由人力资源部触发的申请、角色权限配置、主管与系统负责人审批，以及旧角色权限的回收。
运作方式
把触发点指向你们真实的人力资源记录
把“登记入职或调岗事件”换成真正启动这个流程的那条记录，例如一张新员工入职表，或者你们人力资源系统里一条带生效日期的岗位变更。写明由谁录入，以及它必须在生效日期之前多久存在。正是这段提前量，决定了权限能不能在新角色的第一天就准备好。
在发布这张图之前，先把角色权限配置写出来
“查询角色权限配置”只有在配置确实存在时才有用。先从你们最常招聘、也最常把人调进去的那些角色开始，列出每一个角色需要的权限项，并给每一份配置指定一位具名负责人和一个复核日期。没有负责人的配置会慢慢漂移成“所有人曾经要过的东西的并集”，那样一来，按岗位而不是按系统提出申请的意义也就没有了。
定义什么算作敏感系统
“是否涉及敏感系统？”这条分支旁边需要一份成文标准。典型的触发条件是薪酬与财务系统、个人数据或健康数据、生产环境，以及任何带管理员权限的权限项。把门槛设得让这条分支只对少数申请生效；如果它对什么都生效，系统负责人的审批就变成盖橡皮图章，而普通事项也会被拖慢。
把回收那一半做成一项有负责人、有期限的任务
“回收”这条连线，是大多数组织并不具备的一步。决定由谁产出原角色权限的清单——通常是原主管，或者从你们的身份管理工具里导出——由谁执行回收，以及相对于调岗日期在什么时候完成。如果调岗者需要旧权限来完成交接，就把它作为一次带截止日期的延期授予，而不是让那项权限一直开着。
就职责分离规则以及谁可以接受冲突达成一致
列出一个人不得同时持有的组合，例如既创建供应商又审批向其付款，或者既写代码又自己把代码发布到生产环境。没有这份清单，这道检查只是装饰。然后写明谁可以接受一项无法避免的冲突，以及他们必须在该权限项上记录什么样的补偿性控制措施——在一个小团队里，冲突有时是唯一行得通的答案。
把它发布出去，然后拿接下来几次调岗来检验
把图分享给人力资源部、图中具名的那些主管、系统负责人和 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 关于逻辑访问的通用准则立场相似：期望权限在凭据发放之前获得授权，并在角色变更时被修改或回收。它们都没有规定某个复核周期或者某种特定工具，也都不把一张图视为证据——真正被检验的是审批记录、开通记录，以及这个流程产生的权限登记册。