員工存取申請流程圖（入職與調職）
面向入職與調職的員工存取申請流程圖：由人力資源部觸發的申請、角色權限設定檔、主管與系統負責人審批，以及舊角色權限的回收。
運作方式
把觸發點指向你們真實的人力資源紀錄
把「登記入職或調職事件」換成真正啟動這個流程的那條紀錄，例如一張新入職員工表格，或者你們人力資源系統裡一條帶生效日期的職位變更。寫明由誰輸入，以及它必須在生效日期之前多久存在。正是這段提前期，決定了權限能否在新角色的第一日就準備好。
在發布這張圖之前，先把角色權限設定檔寫出來
「查閱角色權限設定檔」只有在設定檔確實存在時才有用。先由你們最常招聘、亦最常把人調進去的那些角色開始，列出每一個角色需要的權限，並為每一份設定檔指定一位具名負責人和一個覆核日期。沒有負責人的設定檔會慢慢漂移成「所有人曾經要過的東西的總和」，這樣一來，按職位而不是按系統提出申請的意義亦就沒有了。
定義甚麼算是敏感系統
「是否涉及敏感系統？」這條分支旁邊需要一份成文準則。典型的觸發條件是薪酬與財務系統、個人資料或健康資料、生產環境，以及任何帶管理員權限的權限。把門檻訂到令這條分支只對少數申請生效；如果它對甚麼都生效，系統負責人的審批就變成蓋橡皮圖章，而一般事項亦會被拖慢。
把回收那一半做成一項有負責人、有期限的任務
「回收」這條連線，是大多數機構並不具備的一步。決定由誰產出原角色權限的清單——通常是原來的經理，或者由你們的身分管理工具匯出——由誰執行回收，以及相對於調職日期在甚麼時候完成。如果調職者需要舊權限去完成交接，就把它作為一次帶截止日期的延期授予，而不是讓那項權限一直開着。
就職責分離規則以及誰可以接受衝突達成共識
列出一個人不得同時持有的組合，例如既建立供應商又審批向其付款，或者既寫程式又自己把程式碼發布到生產環境。沒有這份清單，這道檢查只是裝飾。然後寫明誰可以接受一項無法避免的衝突，以及他們必須在該權限上記錄甚麼樣的補償性控制措施——在一個細團隊裡，衝突有時是唯一行得通的答案。
把它發布出去，然後拿接下來幾次調職去檢驗
把圖分享給人力資源部、圖中具名的那些經理、系統負責人和 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 關於邏輯存取的通用準則立場相似：期望權限在認證資料發放之前獲得授權，並在角色變更時被修改或回收。它們都沒有訂明某個覆核周期或者某種特定工具，亦都不把一張圖視為證據——真正被檢驗的是審批紀錄、開通紀錄，以及這個流程產生的存取權限登記冊。