用戶存取權限撤銷流程圖（權限註銷）
用戶存取權限撤銷流程圖：離職與職位變動觸發、即時撤銷分支、共用與特權帳戶處理、授權回收，以及可供審核的證據與核對。
運作方式
寫清你們真實的觸發來源
圖裡有四種觸發：離職、合約期滿、職位變動與權限覆核發現。寫下每一種的權威來源是哪個系統或哪個人，例如員工看人力資源系統，供應商與外判人員看合約登記冊，覆核發現看覆核結果。如果今天某一種觸發沒有負責人，那就是最值得先補上的缺口——沒有人會去啟動的流程，是無法量度的。
把即時撤銷的規則寫下來
「是否需要即時撤銷？」這個判斷，只有當判定準則就擺在旁邊時才有用。常見的觸發是解僱、懷疑違規，以及任何持有管理員、生產環境或付款審批權限的人。加上你們自己的目標時限，並寫明非辦公時間由誰可以發動。遇上解僱時，撤銷通常與談話本身對時，所以這條分支講的既是速度，也是次序。
把你們的系統清單掛到梳理步驟上
把通用的帳戶清單換成你們真正在維護的那份清單，並標出哪些系統在單一登入後面、哪些不在。身分平台以外的一切，正是被遺漏的權限藏身之處：本機管理員帳戶、資料庫登入、SSH 金鑰、API 權杖，以及某個團隊用信用卡買下的工具。請離職者的經理把 IT 並不管理的東西一件件說出來。
在需要用到之前就定好停用還是刪除
把停用設為預設，並界定甚麼情況下容許刪除，例如過了訂明的保存期，或者合約期滿而協議有此要求。記下這個決定由誰來做。刪得太早，會毀掉郵件資料、檔案擁有權，以及核對步驟和日後任何調查所依賴的操作紀錄。
保持資料與授權步驟的次序
先移交郵箱與檔案擁有權，再回收授權。兩者一旦調轉，共用檔案與郵箱就會變成無主狀態，事後再找回來很慢。如果設定了郵件轉寄或代理人，就在同一步裡為它指定一位具名負責人和一個結束日期，否則這個臨時安排會靜靜變成永久的。
議定甚麼算是證據，以及由誰核對
訂明一條撤銷紀錄必須包含甚麼——通常是系統、動作、時間戳記和執行人——以及它存放在哪裡。然後指定誰來跑「是否仍有存取權限有效？」這項檢查，以及對着甚麼核對：只有對着開頭那份帳戶清單核對、而不是對着記憶核對，才捉得住遺漏。把批核過的圖與你們的存取控制政策一併發布，讓大家實際遵循的流程，和你們拿給審核員看的流程，是同一條。
常見問題
甚麼是用戶存取權限撤銷流程？
它是把一個人的存取權限收回來所走的那條已界定路徑，由觸發一直到經過確認並留有證據的收結。一條完整的流程有五個部分：一個有具名來源的觸發；一個關於權限必須多快消失的判斷；對這個人持有的每一個帳戶與每一項權限的梳理；在每個系統中的撤銷，而且資料與授權的後果都已處理；以及一次核對，顯示沒有任何東西被留着仍然有效。觸發比大部分團隊以為的要闊。除了離職，流程還應該在職位或團隊變動時、在合約或委聘結束時、在任何一次權限覆核發現時跑起來——正是這些路徑，製造出事後誰也解釋不了的權限。
有人離職時，存取權限應該多快被撤銷？
標準訂明的是要求，不是鐘點。ISO/IEC 27001:2022 控制項 A.5.18 要求在僱傭關係終止或變更時移除或調整存取權限，但沒有訂明時限，因此目標由你們自己設定並說明理由。常見的做法是：有計劃的離職在最後工作天結束時撤銷；解僱或任何持有特權權限的人則即時撤銷，並與談話對時。無論你們選哪一種，都把它寫進流程，量度由觸發到最後一次撤銷的實際時間，並把這兩者之間的差距當作值得上報的那個數字。
我們應該停用還是刪除帳戶？
停用是較安全的預設，也是大部分機構首先會做的。它關閉帳戶、結束活躍工作階段、阻止登入，同時保留郵箱內容、檔案擁有權、群組成員身分，以及一次調查或日後一次權限覆核可能需要的操作紀錄。刪除屬於訂明保存期結束時，或者合約期滿而協議或資料保障承諾有此要求時。無論選哪一種，結束活躍工作階段與撤銷權杖的重要性都不亞於帳戶狀態本身：一個已停用但仍帶着活躍工作階段或有效更新權杖的帳戶，在那個工作階段屆滿之前仍然擁有存取權限。
共用帳戶、服務帳戶與特權帳戶的權限應該怎樣撤銷？
共用帳戶或服務帳戶無法靠停用來註銷，因為其他人和其他系統都依賴它。撤銷的動作是輪換憑證：改掉密碼或金鑰，把這個人從保管它的密碼庫或群組中移除，撤銷他建立的 API 權杖、SSH 金鑰與個人存取權杖，並結束所有活躍工作階段。特權個人帳戶在一般停用之外，還需要同樣的工作階段與權杖處理。範本把這一情況放在由保安負責的獨立分支上，因為它是最常被遺漏的一種，而一旦被遺漏，波及面也最闊。
這條流程應該產出甚麼證據？
最少是每次撤銷一張工單或一條紀錄，顯示觸發及其日期、整理出的帳戶與權限清單、在每個系統中採取的動作及其時間戳記和執行人，以及核對檢查的結果。這份紀錄正是審核員抽查的對象，也正是讓你們能用一個日期而不是一段描述去回答保安問卷的東西。這裡有必要說清楚：流程圖做的是記錄預期的流程以及每一步歸誰負責，而合規的證據，是這條流程真正跑起來時產生的那些紀錄。