三月离职的那位分析师

一句话结论： 一家香港券商的合规主管，把过去十八个月里所有离职人员列成一张表，拿去和仍然有效的账号对了一遍。两张表对不上：两个邮箱还在收信、一个 VPN 账号还能认证通过、四台笔记本电脑下落不明，而公司仍在为九个挂在已离职者名下的授权付费。这些都不是失职——这是把离职处理当成"一件事"而不是"一份记录"的可预期结果。

为什么在香港券商里，访问权限是一项受监督的控制，而不是 IT 的家务事

一家在香港持牌的证券公司，所处的环境里"谁能接触到什么"是一个受监督的问题。客户资料、指令与交易记录、进行中的研究，以及任何触及这些内容的系统，都受制于公司应当能够描述并举证的控制措施。本文不试图解释任何具体的监管义务或门槛——那属于公司自己的合规与法务顾问的范畴。本文描述的是底下那层运营现实：无论要求最终是什么，公司能答到多好，取决于它的记录做到多好。

这门生意里让事情更复杂的一点是：人员流动是常态。分析师会走。交易员会走。这个行业里一家四十到七十人的公司，可能在两年窗口内更换掉相当比例的员工，而这既不例外，也不代表哪里出了问题。因此，离职处理并不是一件"发生时小心处理一下"的偶发事件。它在背景里持续运行，与其他所有事情并行——而这恰恰是那种"一旦依赖某个人记得，就会悄悄退化"的流程。

而且范围已经扩大了。十年前，离职处理意味着一个邮箱、一个网络登录和一台笔记本电脑。现在它意味着：一个邮箱、单点登录、一个 VPN、若干共享盘、一套文档管理系统、一个行情终端、一套 CRM、一个电子签名账号、几个用信用卡买下来的部门级 SaaS 工具、一部装着公司邮件的移动设备，以及这个人手里那些没有别人在用的系统凭据。上面每一项都是一次独立的撤销。其中任何一项被漏掉，就会是审阅时被翻出来的那一项。

场景：四十八个人，十一位离职者，没有一张统一的清单

以下是一个复合情境——不是具名客户，而是这个市场上常见到值得直说的一种形态。

一家香港证券经纪公司，四十八名员工，办公室在中环。研究、交易、运营、财务，外加一个小型合规职能。IT 外包给一家服务商，服务台和基础设施都处理得称职；公司内部有一位名义上的 IT 对接人，但他的实际工作是运营。

离职处理归 HR 管，而且是一个文书流程。有一份离职表。它覆盖雇佣侧——通知期、最后一笔薪资、假期结余、归还大楼门禁卡——并在靠底部的位置有一行"IT 权限已撤销"，配一个勾选框。这个框由当天下午运营部门里谁有空，谁来勾。

然后这个人做他记得要做的事。他会请 IT 服务商停用邮箱。VPN 通常也会记得。行情终端可能记得也可能不记得，因为那是单独计费、由交易台管理的。他一定不会记得研究团队八个月前开始用的那个部门级项目工具，因为他根本不知道它存在。如果当事人最后一天在办公室，他会把笔记本电脑收回来；如果对方在家办通知期，或者已经进入园艺假，那台电脑就是"再另行安排"。

没有一张清单，能说明某位员工实际拥有过什么。信息是存在的——它散落在 IT 服务商的工单历史里、一张资产表格里、Microsoft 365 管理中心里、三四个 SaaS 管理面板里，以及当初配置这些东西的人的记忆里。它只是从来没有被按人汇总到一个地方，并保持更新。

十八个月后，因为一次审阅将至，合规主管第一次把它汇总起来。这个动作花了两周，产出了前面那些发现。那两个还在收信的邮箱，原来是被转换成共享邮箱而不是删除，之后没有人复查过委派访问权限。那个 VPN 账号属于一位合约已结束的外部顾问，而他从头到尾就没进过 HR 的离职流程——因为外部顾问不走 HR。四台不知去向的笔记本电脑里，三台其实就在办公室某处，一台还在某位离职者家里。至于那九个授权，只是从来不是任何人的份内事去回收。

底下的四种失效，按它们叠加的顺序

没有一份权威的、按人索引的清单。 这是根因，其余一切都由它衍生。没有人能按需拿出一份清单，列出与某个具名个人关联的每一个账号、设备、授权和凭据。没有这份清单，撤销就是一次记忆练习；而记忆练习总是在边缘处失效——某个团队在用的那个工具、那个从没进过 HR 系统的外部顾问、硬件故障期间发出去而再没收回的第二台设备。

撤销依赖某个人记得某个系统。 因为清单不存在，流程就变成"停掉我们想得起来的那些"。这对显而易见的项目有效，而恰恰对审阅时最要紧的那些项目失效：长期存在的服务账号、带委派权限的共享邮箱、部门自行采购的 SaaS 工具。失效率并不高，但它不是零；而在十一位离职者上，一个非零的失效率会累加成审阅发现。

硬件安静地消失。 不是因为有人不诚实。一台笔记本电脑在通知期被带回家，然后没人收，因为收回它不是任何人的职责。一台作为临时替换发出去的设备，一临时就是两年。一台显示器和一个扩展坞在混合办公安排里搬到了某人家里，人走了它们还在那里。单个来看都微不足道；合起来就是一份属于虚构的资产台账——更重要的是，一批装着公司数据、而公司已不再掌控的设备。

授权支出只增不减。 没有人回收席位，因为回收席位的前提是知道这个席位存在、且它的持有人已经离开。四十八人公司里的九个闲置授权，绝对金额不大，但它是一笔永久性的、持续累加的多付款项，而且它精确地指示了底下的问题：如果公司看不见一个闲置授权，它同样看不见一个闲置账号——而后者才是要紧的那个。

这四点合起来的后果，是一个建立在"保证"而非"证据"之上的合规回答。被问到离职者是否仍保有访问权限时，公司可以说"没有，人员离职时我们会撤销权限"。它做不到的，是拿出一份按离职者、带日期的记录，说明撤销了什么、何时撤销、由谁撤销。在多数审阅里，这两个回答之间的差距，就是整个发现本身。

Brocent 的看法：离职处理之所以失败，是因为它被当成一个结尾

面对这类审阅发现，通常的反应是做一份更好的检查清单。更长、更周全、列上更多系统、由两个人而不是一个人签字。

这在边缘上有帮助，然后就会退化，原因很直白：一份检查清单，是写它的人在当时能想到的东西的集合。某个团队采用一款新工具的那一刻，它就过期了。如果外部顾问不进入生成它的那个流程，它就覆盖不到外部顾问。而且它产出的是签名，不是证据——它留下的凭证证明"一张表被填完了"，而不是"访问权限确实被移除了"。

更耐用的框架是这样的：离职处理之所以失败，是因为它被当作末端的一项任务，而不是一路维护下来的一份记录。 如果"入职"是那个创建记录的事件——这个人、这些设备、这些账号、这些授权、这些凭据——那么"离职"就只是把这份记录倒着跑一遍。检查清单不再是某个人凭记忆拼出来的东西，而变成系统按人产出的东西，因为这套记录是被持续维护的，而不是在离职面谈那天重建的。

由此推出的另一条同样重要：留下的凭证比检查清单更重要。 公司在审阅时需要的不是一张填完的表，而是一份带日期的离职报告，列明每一个被停用的账号、每一台被回收或被擦除的设备、每一个被释放的授权、每一份被交回的凭据——并且由那套日常治理环境的同一份记录生成，因而它本质上就是准确的，而不是另行编纂出来的。

落到实处是什么样子

六项机制，每一项都对应 Brocent 实际在运行的东西，而不是一张通用流程图。

一份从第一天起就把设备与授权绑到具名个人身上的资产台账。 BCS Beam 是 Brocent 的终端服务客户端，一次安装的单一签名代理。它让工程师获得以同意为前提、全程审计的远程支持通道，并持续上报每台设备的安全与健康状态——磁盘加密、杀毒、防火墙与补丁状态对照 CIS 基准检查，已安装软件每日与 CVE 目录比对。对离职处理而言，关键属性是：一台纳管设备就是一台已知设备——它在记录里，是因为它自己在上报，而不是因为有人把它敲进了一张表格。

能把"没人登录过的席位"浮出来的授权治理。 "一个引擎，而不是一堆工具"这个论点，不只是架构偏好——它正是让横向问题变得可回答的原因。一个九十天无人登录的席位，是环境自己就能浮出来的事实。这一个信号，能在同一次查询里同时抓到：被漏掉的离职者账号、从没进过 HR 流程的外部顾问，以及真实的超额支出。

一套写下来的撤销顺序，而不是靠记的。 邮件与日历。单点登录及任何本地目录账号。VPN 与远程访问。共享盘与文档管理。第三方 SaaS，包括那些部门级工具。行情与交易系统访问。这个人持有的服务账号与 API 密钥。物理门禁。顺序很重要，因为有些撤销依赖于另一些——在导出应留存内容之前就先停用身份，是一种常见的自伤——也因为按固定顺序执行，正是它可被审计的原因。

设备回收，以及回收不成时的真实答案。 设备归还的，擦除后回到备品库，记录同步更新。没归还的——离职者带在家里、联系不上，或者关系闹得不愉快——MDM 提供兜底：公司数据可以在几分钟内从已注册设备上远程擦除，公司自有硬件用完全擦除，装着公司邮件的个人设备用选择性擦除。这就是"我们已经请他归还"和"公司数据已经不在上面了"之间的差别。后者才是一件你可以写下来的事实。

凭据交回到客户自有的文档里，而不是某位工程师的记忆里。 Brocent 托管 IT 每一层套餐都包含的那十三项里，有两项与此直接相关：密码与凭据管理，以及客户自有的文档与凭据。第二项是最容易被低估的一项。文档与凭据属于客户，这意味着当一个人离开时——无论这个人是客户的员工还是服务商的工程师——知识不会跟着他走。一家系统只记录在某位工程师脑子里的公司，已经有了一个它还没意识到的离职问题。

一份带日期、可以摆到审阅者面前的离职报告。 上述所有环节的产出，是一份按离职者生成的凭证：他有过什么、撤销了什么、何时撤销、由谁撤销、回收了什么、擦除了什么。它由运营记录生成，这正是它可信的原因。它与公司其余的安全态势一起，归在托管 IT 安全服务之下，商务结构见托管 IT 支持页面。

公司处理离职的三种方式

临时应付式——"周五把账号停了"

• 是什么： IT 相关动作由离职当天有空的人凭记忆处理，没有既定清单，事后也不留记录。
• 代价： 在被发现之前，看不见任何代价。之后的代价是一次补救行动、一场关于"某个账号活了多久"的尴尬对话，以及一个很难关闭的审阅发现——因为过去的证据并不存在，也无法追溯创造。
• 适合谁： 一家小到确实有一个人能把整个环境装在脑子里、并且稳定到这个人不会离开的公司。两个条件都要成立。

一份背后没有系统支撑的 HR 检查清单

• 是什么： 一份带 IT 章节的离职表。系统被列出来。框被勾上。签名被收齐。
• 代价： 它看起来像控制，并且产出了"证据的外观"——这才是危险的部分：公司相信自己已经覆盖了。但这份清单反映的是它被写下来那一刻为真的东西，覆盖不到此后新采用的工具，通常也覆盖不到外部顾问；而一个勾只确认了"有人说他做了某事"，不等于环境真的变了。表与现实之间的落差之所以看不见，恰恰是因为这张表存在。
• 适合谁： 相较于什么都没有，它是一次真实的改进，也是正确的第一步。当有人要的是证据而不是保证时，它就不够了。

一份纳管的资产与身份记录——Brocent 推荐的模型

• 是什么： 设备、账号、授权与凭据从入职当天起就绑定到具名个人，由治理环境的那些系统持续维护；离职按既定顺序对着这份记录执行，并把一份带日期的报告作为产出。
• 代价： 需要的是一套托管 IT 安排，而不是一张表；外加为已在职人员建立记录的前期工作——这是诚实的那个"但是"：这个模型从入职事件开始生效，所以一家已有历史的公司必须先做一次对账，才能到达一个干净的基线。
• 为什么站得住： 因为这份记录是通过运营环境本身来维护的，而不是靠记得去更新，所以它不会在两次审阅之间退化。新工具会出现在里面，因为它们出现在环境里。外部顾问会出现在里面，因为他们被发放了访问权限——不管 HR 有没有他们的档案。而证据是副产品，不是一个项目。

如果这就是你公司的样子，从哪里开始

不要从重写政策开始。从对账开始：把过去十二到十八个月里所有离职的人拿出来，逐一对照仍然有效的账号、设备与授权。这是一件两周的活儿，做起来不舒服，但它建立了基线，并且告诉你真实问题的规模，而不是想象中的规模。

然后修入职那一侧，因为记录是在那里被创建的；一个干净的入职流程，会让此后每一次离职流程都变得平淡无奇。先修离职侧是更符合直觉的顺序，也是更没效果的顺序。

如果你希望有人陪你复核这次对账，或者一起看看以你公司的规模与监管画像，这份记录应当包含什么，联系我们——这是一场关于你实际环境的对话，不是一场产品推介。

常见问题

人员离职后，访问权限到底应该多快撤销？

运营层面的答案是：撤销应当在最后一个工作日内完成，而且这套机制不应依赖任何人当天必须在办公室。至于你所在的公司是否被要求在某个具体时限内完成，这是你的合规职能与你自己的监管顾问该回答的问题——本文不主张任何门槛。值得直说的是：现实中的约束几乎从来不是速度，而是完整性。公司很少因为一个邮箱是周一而不是周五停用而出问题；它们出问题，是因为一个没人列出来的账号活了一年。

如果员工始终没有归还笔记本电脑怎么办？

那么问题就从"回收硬件"变成了"移除数据"，而这两件事是可以分开的。设备如果已纳入 MDM，公司数据可以在下达指令后几分钟内被远程擦除——公司自有设备用完全擦除，个人设备用只移除公司内容的选择性擦除。务实的前提是：指令要在设备下一次联网时才会送达，这也正是"注册加加密"比"只有擦除"更重要的原因。此后，实体资产的回收就变成了一件 HR 与财务的事，而不是安全的事——这是一个好得多的归属位置。

离职处理到底该归谁——HR 还是 IT？

HR 拥有这个事件；IT 负责执行；而失效的方式，是以为两者之间的一次交接就等于一套流程。HR 知道有人要走、什么时候走。IT 知道这个人有过什么。两张清单单独看都不完整，而它们之间的缝隙，正是外部顾问、部门工具和第二台设备掉下去的地方。可行的安排是：HR 触发，记录提供清单，IT 对着清单执行，产出是一份两个职能都能指着看的、带日期的凭证。

我们怎么找出还在付钱的闲置授权？

可靠的信号是登录活动，而不是授权清单。一个九十天没有登录记录的席位，要么是一个被漏掉的离职者账号，要么是一位没人跟踪的外部顾问，要么是一笔真实的超额支出——三种都值得找出来。这与抓访问权限问题的是同一个查询，也正因如此，授权治理与访问治理不该被当成两件事来做。省下来的钱是真实的，但它是次要的；要点在于：一个没人登录的席位，就是一个没人在看的席位。

删除邮箱会不会丢掉我们必须留存的记录？

有可能，而这正是"顺序比速度更重要"的原因。业务记录的留存要求属于你的合规职能与法务顾问的范畴——我们不对适用于贵司的具体要求作任何主张。在运营层面，稳妥的模式是先保全、后撤销：先把邮箱置于适当的留存或保全安排之下，按公司政策转换或归档，然后才移除交互式访问。先删除、后重建，是那种能把一次离职处理变成一次事件的错误。

审阅时我们应当能拿出什么证据？

至少要能按离职者拿出：离职日期；他持有的账号、设备、授权与凭据清单；每一次撤销的日期与执行人；每台设备的去向（已归还并擦除，或已远程擦除）；以及他所持凭据已轮换的确认。关键属性在于，这些内容来自那套运行环境的记录，而不是为了这次审阅拼出来的——一份专门为审阅者编纂的文件，会立刻引出那个显而易见的追问：它是根据什么编出来的？

我们用的是外包 IT 服务商，这会改变问责归属吗？

不会。外包的是执行，不是问责；审阅者会问公司，而不是问服务商。服务商真正应该改变的，是你回答问题的能力——那份记录、那套写下来的顺序、那份凭证，都应当是你随时可以索取到的东西；而凭据与文档应当属于你，而不属于服务商。最后这一点值得在任何既有安排里核查一下：如果离开现有服务商就意味着失去关于你自己环境的文档，那你在上一层拥有的，是同一个离职问题的另一个版本。

我们的外部顾问从来不走 HR 流程，怎么才能覆盖到他们？

把记录锚定在"已发放的访问权限"上，而不是"雇佣状态"上。一位被给了 VPN 账号、邮箱或设备的外部顾问，不管 HR 有没有他的档案，他都已经在环境里了；而一份从"环境实际包含什么"构建出来的记录，自然会包含他。这是我们在这个规模的公司里最常见到的单一缺口，也是"检查清单"模型最稳定地失效的地方——因为那份清单，是由一个外部顾问从未进入过的 HR 流程生成的。