三月離職的那位分析師

一句話結論： 一家香港券商的法遵主管，把過去十八個月裡所有離職人員列成一張表，拿去和仍然有效的帳號對了一遍。兩張表對不上：兩個信箱還在收信、一個 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 流程產生的。