离职账号停用的关键，是把离职事件作为唯一触发源，由HR系统或统一身份平台驱动各下游系统完成停用，减少各系统管理员逐个手工处理带来的遗漏和口径不一。本文给出一条可执行的主流程、各角色的交付物、一次完整走查示例，以及验证停用是否真正生效的检查清单。流程中的状态流转与确认记录，可以借助ONES这类工具承载，具体能力以官方资料为准。
要点总览（TL;DR）
- 离职账号停用以经确认的离职事件为唯一触发源，由HR系统或统一身份平台驱动下游系统停用，避免多入口手工处理造成停用时间不一致。
- 动手前先定判定口径：覆盖哪些账号类型和系统、哪些场景停用、哪些场景删除，停用与删除作为不同动作分别定义。
- 主流程分五步：离职事件采集、身份源状态变更、下游系统停用、会话与令牌失效、记录归档，每步明确输入、动作、输出与完成标志。
- HR、IT或身份平台管理员、各系统管理员、安全审计各自承担明确动作并交付记录，例外上报接收人指定到岗位。
- 停用生效需逐项检查账号状态、活跃会话、令牌与API密钥、共享账号与委托授权、群组归属和证据留存，未通过且无法当场修复的记为阻断项。
离职账号停用的核心流程与关键动作
停用流程的起点只有一个：经确认的离职事件。招聘网站、部门口头通知、系统管理员自行发现等入口都不应直接触发停用，否则同一名员工在不同系统会出现停用时间不一致、责任无法追溯的情况。身份源（HR系统或统一身份平台）是唯一的状态权威，下游系统只接收并执行身份源下发的停用指令。
动手前先确定停用范围与判定口径，这一步决定后续所有动作的边界：
- 账号类型：正式员工账号、外包与实习账号、共享账号、服务账号、测试账号是否纳入同一流程，各自适用什么审批。
- 系统清单：以身份平台纳管的系统为准，列出已接入单点登录或已同步账号的系统，以及尚未接入、需要单独处理的系统。
- 停用与删除的区分：停用保留账号数据、阻断登录，适用于离职后仍需保留审计记录或交接资料的场景；删除清除账号及关联数据，通常需要更严格的审批和留存要求。两者在流程中作为不同动作定义，不能混用。
主流程可拆为五步，每步的输入、动作、输出与完成标志如下表：
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 离职事件采集 | HR确认的离职申请、最后工作日、生效时间 | HR在HR系统或身份平台登记离职状态与生效时间，形成唯一事件记录 | 带生效时间的离职事件单 | 事件单状态为“已确认”，生效时间明确到日或时 |
| 2. 身份源状态变更 | 离职事件单 | 身份平台管理员将账号状态置为停用或待停用，触发下游同步任务 | 身份源账号状态变更记录 | 身份源中该账号状态为停用，同步任务已下发 |
| 3. 下游系统停用 | 同步指令、系统账号清单 | 已接入系统自动执行停用；未接入系统由系统管理员按清单手工停用并回填结果 | 各系统停用结果回执 | 清单内每个系统均返回“已停用”或登记例外 |
| 4. 会话与令牌失效 | 该账号的活跃会话、访问令牌、API密钥清单 | 强制注销活跃会话，吊销令牌与API密钥，回收长期凭证 | 会话与凭证吊销记录 | 会话列表为空，令牌与密钥状态为已吊销 |
| 5. 记录归档 | 前四步的操作记录 | 汇总停用时间、操作人、各系统回执、例外说明，归档到可查询的位置 | 离职停用归档记录 | 归档记录完整，可按员工或时间检索 |
第3步是容易出问题的一环。已接入身份平台的系统通常能自动完成停用，未接入的系统需要人工兜底，因此系统清单必须维护准确，新增系统上线时同步登记是否接入身份源。第4步常被忽略：账号停用后，此前签发的令牌和已登录会话可能仍在有效期内，需要单独吊销，否则停用只挡住了下一次登录。
角色分工与交付物清单
停用流程跨多个部门，每个角色需要明确“做什么、交什么、交给谁”。分工不清时，最常见的结果是HR以为IT会自动处理，IT以为系统管理员会逐个确认，最终部分系统账号长期处于可用状态。
| 角色 | 主要动作 | 交付物 | 交付对象与时机 |
|---|---|---|---|
| HR | 确认离职事实，登记最后工作日与账号停用生效时间 | 离职事件单（含生效时间） | 提交至身份平台，离职生效前完成 |
| IT / 身份平台管理员 | 变更身份源账号状态，触发并监控下游同步，处理同步失败 | 身份源状态变更记录、同步结果报告 | 同步完成后反馈给系统管理员与安全审计 |
| 各系统管理员 | 确认本系统账号已停用；未接入系统手工停用；上报无法停用的例外 | 本系统停用确认记录、例外上报单 | 停用生效后提交至归档负责人 |
| 安全审计 | 抽查停用记录与系统实际状态是否一致，复核例外处理是否合规 | 抽查报告、例外复核结论 | 按周期或按事件输出给IT负责人 |
分工确认时有两个细节值得写进流程文件。其一，离职事件单的生效时间由HR负责准确填写，IT不自行推断；其二，例外上报的接收人需要指定到岗位而非个人，避免人员变动导致例外无人处理。安全审计的抽查频率可按组织规模设定，例如按月抽查一定比例的离职事件，重点核对未接入身份平台的系统。
这些状态流转和确认记录如果散落在邮件和即时消息里，追溯成本会很高。ONES提供工作项与状态流转的管理能力，可以把离职停用登记为一条工作项，由HR发起、IT更新状态、系统管理员回填确认结果，形成带时间戳的处理记录；具体字段配置与集成方式以ONES官方资料为准。
示例：一次离职账号停用的完整走查
以下为演示情景，用于说明流程如何落地。某研发人员提出离职，最后工作日为当月20日，涉及代码托管、项目管理、文档协作、邮件四类账号，其中代码托管与项目管理已接入统一身份平台，文档协作与邮件为独立账号。
第1步，事件采集。HR在HR系统确认离职，登记最后工作日与停用生效时间为20日18时，生成离职事件单。输入是离职审批结果，输出是带生效时间的事件单，完成标志是事件单状态为已确认。
第2步，身份源变更。身份平台管理员核对事件单，将账号状态置为停用，平台向已接入的代码托管与项目管理系统下发停用指令。输出是状态变更记录与同步任务，完成标志是同步任务执行成功。
第3步，下游停用。代码托管与项目管理系统自动完成停用并返回回执。文档协作与邮件未接入身份平台，由对应系统管理员按清单手工停用，回填停用时间与操作人。此时发现该员工在文档协作中有一个团队共享空间的成员身份，需要一并处理，见下文例外部分。
第4步，会话与凭证失效。身份平台管理员吊销该账号的访问令牌，强制注销活跃会话；代码托管系统管理员检查并吊销该员工创建的长期访问密钥。输出是吊销记录，完成标志是会话列表为空、密钥状态为已吊销。
第5步，归档。汇总事件单、同步回执、手工停用记录、吊销记录与例外说明，归档到统一位置，供后续审计抽查。
走查中出现的两类例外需要单独处理：
- 共享账号与服务账号：该员工曾使用一个团队共享账号发布构建产物。共享账号不随个人离职停用，但需要更换凭据并确认新的保管人，同时在记录中注明该员工已不再持有凭据。
- 交接未完成：该员工负责的一个项目文档尚未移交。处理方式是账号按计划停用，登录能力不恢复；交接通过管理员导出资料或由接手人申请权限转移完成，交接进度作为独立事项跟踪，不与账号停用绑定。
这个示例说明一个原则：账号停用以离职生效时间为准，交接、资料移交属于并行事项，不应成为延迟停用的理由；确有需要保留访问的场景，应走单独的临时授权审批，并设定明确的到期时间。
完成检查：停用是否真正生效
流程走完不等于停用生效。以下检查清单用于逐项核对，每项给出通过标准，未通过且无法当场修复的记为阻断项。
| 检查项 | 检查方法 | 通过标准 | 未通过时的处理 |
|---|---|---|---|
| 账号状态 | 在身份源与各目标系统中查询该账号状态 | 清单内所有系统均为已停用或已删除，与判定口径一致 | 阻断项：定位未停用系统，由对应管理员补做并回填 |
| 活跃会话 | 查看身份平台及各系统的在线会话列表 | 该账号无活跃会话 | 阻断项：强制注销并记录操作人 |
| 令牌与API密钥 | 检查访问令牌、刷新令牌、API密钥状态 | 全部为已吊销，无长期有效凭证残留 | 阻断项：逐项吊销，涉及第三方集成的确认调用方已切换 |
| 共享账号与委托授权 | 核对共享账号凭据保管人、委托授权列表 | 共享账号已更换凭据并登记新保管人；委托授权已解除 | 阻断项：更换凭据或解除授权后复核 |
| 群组与归属 | 检查该账号在群组、邮件列表、项目成员中的归属 | 已按规则移除或转移，无遗留的高权限归属 | 一般项：限期清理，涉及审批流程的登记跟踪 |
| 证据留存 | 抽查归档记录 | 停用时间、操作人、各系统确认记录完整可追溯 | 阻断项：补齐记录后方可关闭事件 |
| 例外处理 | 核对例外上报单与复核结论 | 每个例外均有处理结论与责任人 | 阻断项：未完成交接、系统无停用接口等情况需明确临时措施与到期时间 |
检查中有一类情况需要提前约定处理方式：部分系统没有提供停用接口，只能人工在管理后台操作。这类系统应列入人工兜底清单，由指定管理员在停用生效后一个工作日内完成并回填；如果系统连管理后台操作都受限，则需要评估是否通过修改密码、回收凭据等方式降低风险，并在例外记录中写明依据。
检查结果建议按事件归档，而不是只记录“已完成”。归档内容至少包括：离职事件单编号、停用生效时间、各系统停用时间与操作人、会话与凭证吊销记录、例外说明及复核结论。这样在审计抽查或出现安全事件时，可以直接回答“这个账号什么时候停的、谁确认的、有没有遗漏”。
常见问题
离职员工的账号停用时间应该以什么为准？
以HR确认的离职事件单上登记的生效时间为准，精确到日或时，由HR负责填写，IT不自行推断。账号停用以该时间为节点执行，交接、资料移交属于并行事项，不构成延迟停用的理由。确有需要保留访问的场景，走单独的临时授权审批，并设定明确的到期时间。
员工离职后账号应该停用还是删除？
两者在流程中作为不同动作定义。停用保留账号数据、阻断登录，适用于离职后仍需保留审计记录或交接资料的场景；删除清除账号及关联数据，通常需要更严格的审批和留存要求。建议在流程文件中先写明判定口径，按账号类型和业务场景分别规定适用哪种动作，避免执行时混用。
账号已经停用，为什么还要单独处理会话和令牌？
账号停用挡住的是下一次登录，此前签发的访问令牌、刷新令牌、API密钥和已登录会话可能仍在有效期内继续可用。因此停用后需要单独吊销令牌与长期凭证、强制注销活跃会话，并把会话列表为空、凭证状态为已吊销作为完成标志。涉及第三方集成的，还要确认调用方已切换到新凭据。
部分系统没有停用接口，只能人工在后台操作，怎么保证不漏？
把这类系统列入人工兜底清单，指定管理员在停用生效后一个工作日内完成操作并回填停用时间与操作人。系统清单需要随新系统上线同步维护，登记是否接入身份源。如果连管理后台操作都受限，则评估通过修改密码、回收凭据等方式降低风险，并在例外记录中写明依据和临时措施。
交接没完成，可以先不停用账号吗？
建议账号按计划停用，登录能力不恢复；交接通过管理员导出资料或由接手人申请权限转移完成，交接进度作为独立事项跟踪，不与账号停用绑定。这样既保证离职生效时访问被切断，也不让交接拖延成为账号长期可用的理由。
