員工存取申請流程圖（入職與調職）
面向入職與調職的員工存取申請流程圖：由人力資源部觸發的申請、角色權限設定檔、主管與系統負責人審批，以及舊角色權限的回收。
甚麼是員工存取申請流程圖（入職與調職）流程
員工存取申請流程之所以授予權限，是因為僱傭上發生了某件事，而不是因為有人開口要。人力資源部確認某人已經入職或者轉了職位，掛在這個職位上的角色權限設定檔說明這個角色應該做得到甚麼，直屬經理確認角色沒有認錯，系統負責人審批當中一切敏感的部分，IT 負責開通。申請的單位是一個職位而不是一個系統，正因如此，結果在一年之後仍然覆核得到：「這個人持有財務分析師的角色權限設定檔」是一句別人檢驗得到的陳述，而「他們在 2023 年要過資料庫權限」不是。
這不是通用的存取申請流程——在那個流程裡，已經在職的員工還差一個系統，於是自己提出申請。那條路徑連同定期的權限覆核，由另一份獨立的存取申請流程範本涵蓋；如果你們正在設計一張服務台表格，那一份才是更好的起點。它亦不是員工入職流程，入職涵蓋合約、背景審查、設備和第一日；更不是離職流程，離職處理的是離開的人。本範本涵蓋的正是那三者留在中間的部分：給新入職員工的第一次權限授予，以及有人內部調職時的權限重建。
內部調職，正是大多數存取流程靜靜失效的地方。一次角色變更同時是一次入職和一次離職，而實際上跑得起來的只有入職那一半。新的權限加了上去，沒有人寫低舊的是哪些，兩三次調動之後，一位資深員工手上仍然握着他們多年前就離開的職位的權限。流程本身永遠不會報告有問題，因為它並沒有壞掉；這種累積要到一次權限覆核或一項審核發現裡才浮出來。因此下面這張圖把調職路徑分成兩條帶標籤的連線：「新增」和「回收」，並把兩者都引回存取權限登記冊的同一條紀錄，令回收和授予一樣顯眼。
本流程圖涵蓋的內容
本範本包含
- 五條泳道，即員工、直屬經理、人力資源部、系統負責人與 IT，橫跨五個階段：生命周期觸發、角色權限設定檔、審批、開通與確認。
- 觸發點在人力資源部泳道而不是一張申請表格：直屬經理確認職位角色和到職日期，人力資源部登記這次入職或調職事件，然後由「入職還是調職？」這道判斷分流。
- 調職分支由「列出原角色的權限」分出兩條帶標籤的連線：「新增」繼續走向角色權限設定檔，「回收」則直接交給 IT，去清除原角色的權限。
- 「角色權限設定檔是否涵蓋這個職位？」這道判斷，它的「否」分支把員工送去「提出額外權限申請並寫明理由」，之後再回到直屬經理審批。
- 「是否涉及敏感系統？」這道判斷只把那部分申請送到系統負責人，其「拒絕」分支終止於「存取申請被拒絕」；一般的角色權限設定檔權限則直接進入職責檢查。
- 開通之前在 IT 泳道中的「是否存在職責分離衝突？」檢查，衝突分支會收窄範圍或加上一項控制措施後重新檢查；隨後是開通本身、一次同時涵蓋授予與回收的存取權限登記冊更新、對改動內容的確認，以及員工在新角色下親自驗證權限。
何時使用本範本
- 你們正在編寫入職、調職與離職程序中關於權限的那一半，需要把入職與調職兩條路徑放在一頁上，而不是散落在兩份互不相干的檢查表裡
- 內部調職一再令人留着前一個職位的權限，你們需要說明回收這一步在哪裡、由誰負責
- 你們正在設定由人力資源系統驅動的開通：一條人力資源紀錄在身分管理工具或服務管理工具中啟動一個工作流程；你們希望在自動化搭起來之前先把流程定下來
- 審核員、客戶的保安問卷或者認證評審問過你們，入職時權限是如何授予的、角色變更時又是如何調整的
- 職責散落在人力資源部、直屬經理、系統負責人與 IT 之間，目前沒有人由頭到尾對調職事件負責
運作方式
把觸發點指向你們真實的人力資源紀錄
把「登記入職或調職事件」換成真正啟動這個流程的那條紀錄，例如一張新入職員工表格，或者你們人力資源系統裡一條帶生效日期的職位變更。寫明由誰輸入，以及它必須在生效日期之前多久存在。正是這段提前期，決定了權限能否在新角色的第一日就準備好。
在發布這張圖之前，先把角色權限設定檔寫出來
「查閱角色權限設定檔」只有在設定檔確實存在時才有用。先由你們最常招聘、亦最常把人調進去的那些角色開始，列出每一個角色需要的權限，並為每一份設定檔指定一位具名負責人和一個覆核日期。沒有負責人的設定檔會慢慢漂移成「所有人曾經要過的東西的總和」，這樣一來，按職位而不是按系統提出申請的意義亦就沒有了。
定義甚麼算是敏感系統
「是否涉及敏感系統？」這條分支旁邊需要一份成文準則。典型的觸發條件是薪酬與財務系統、個人資料或健康資料、生產環境，以及任何帶管理員權限的權限。把門檻訂到令這條分支只對少數申請生效；如果它對甚麼都生效，系統負責人的審批就變成蓋橡皮圖章，而一般事項亦會被拖慢。
把回收那一半做成一項有負責人、有期限的任務
「回收」這條連線，是大多數機構並不具備的一步。決定由誰產出原角色權限的清單——通常是原來的經理，或者由你們的身分管理工具匯出——由誰執行回收，以及相對於調職日期在甚麼時候完成。如果調職者需要舊權限去完成交接，就把它作為一次帶截止日期的延期授予，而不是讓那項權限一直開着。
就職責分離規則以及誰可以接受衝突達成共識
列出一個人不得同時持有的組合，例如既建立供應商又審批向其付款，或者既寫程式又自己把程式碼發布到生產環境。沒有這份清單，這道檢查只是裝飾。然後寫明誰可以接受一項無法避免的衝突，以及他們必須在該權限上記錄甚麼樣的補償性控制措施——在一個細團隊裡，衝突有時是唯一行得通的答案。
把它發布出去，然後拿接下來幾次調職去檢驗
把圖分享給人力資源部、圖中具名的那些經理、系統負責人和 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 關於邏輯存取的通用準則立場相似：期望權限在認證資料發放之前獲得授權，並在角色變更時被修改或回收。它們都沒有訂明某個覆核周期或者某種特定工具，亦都不把一張圖視為證據——真正被檢驗的是審批紀錄、開通紀錄，以及這個流程產生的存取權限登記冊。