存取申請與權限開通流程圖
存取申請流程圖：以角色為本的申請、直屬主管與系統負責人審批、職責分隔檢查、按最低權限開通，以及定期重新認證。
運作方式
寫下你們真實的審批人
把五條泳道改成你們實際擁有的角色。在規模較細的機構裡，系統負責人和保安檢視人往往是同一個人；把這兩條泳道合併，而不是畫一次根本不會發生的審批。每個決策者一條泳道，而不是每個人一條，這樣有人轉職時圖仍然用得上。
界定甚麼算特權或敏感權限
「是否屬於特權或敏感權限？」這個決策，只有把判定準則寫在它旁邊才有作用。常見的觸發條件包括管理員和 root 帳戶、服務帳戶、個人資料或財務資料的存取權限，以及任何可以改動生產環境的權限。門檻要訂在只有少數申請會觸發保安分支的位置，否則這一步就會淪為蓋章。
把職責分隔規則寫下來
列出任何一個人都不得同時持有的組合——例如建立供應商與批准付款，或撰寫程式碼與把程式碼發布到生產環境。沒有這份矩陣，衝突檢查只是做樣子。同時決定：當衝突無法避免時，由誰批准補償性控制，並把它記錄在這條權限上。
決定存取權限登記冊放在哪裡
把登記這一步指向你們真正會維護的系統——身分管治工具、你們的 ITSM 平台，或一份受控的試算表。要確保收回權限的分支會更新同一條紀錄，否則登記冊會慢慢變成一份「曾經批出過的權限」清單，而不是「現時實際存在的權限」清單。
訂下重新認證的周期和它的負責人
把籠統的「既定覆核」換成你們自己的頻率和觸發條件——例如特權帳戶每季一次、標準角色每年一次，另加職位變動時的額外覆核。寫明由誰催促覆核人，以及覆核限期過了會怎樣；沒有負責人的覆核，正是那種會悄悄停下來的步驟。
讓這張圖獲得批准，並只保留一個現行版本
把圖分享給圖中列名的審批人，取得他們的批准紀錄，並從你們的存取控制政策連結到已批准的版本。當圖表處於版本控制之下、而且附有已記錄的批准時，大家實際遵循的流程，和你們拿給審核員看的流程，就是同一個。
常見問題
甚麼是存取申請流程？
它是一條已界定的路徑：一項系統權限申請，由有人提出，到被批出、被記錄、並在日後被覆核。一個完整的流程有四個部分：一份寫明已界定角色和業務理由的申請；由對該員工負責的人和對該系統負責的人分別審批；由持有管理權限的人完成開通；以及一條附有覆核日期的權限紀錄。申請與開通被刻意分成由不同的人完成的兩個步驟，這樣就沒有人可以為自己開通權限。
存取申請應該由誰審批？
兩位審批人足以應付大多數情況。直屬主管確認這個人工作上確實需要這項權限，這是關於申請人的問題。系統或資料負責人確認這個角色實際授予哪些權限、這個人是否應該持有，這是關於系統的問題。來自保安團隊的第三道審批，只有在特權或敏感權限的情況下才值得加上——本範本正是這樣分流的。加多審批人很少能改善決策，卻一定會拉長等候時間，而等候時間正是共用密碼之類非正式變通做法的來源。
存取管理中的職責分隔檢查是甚麼？
它檢驗的是：申請的角色加上此人已有的權限，會不會令一個人在沒有任何獨立環節的情況下，由頭到尾完成一宗敏感交易。常見的例子是建立供應商並批准其付款，或者撰寫程式碼並把它發布到生產環境。這項檢查需要一份事先議定的衝突組合清單作為比對依據。當衝突無法避免時——例如在一個小團隊裡——通常的做法是採用一項有文件紀錄的補償性控制，一般是由另一個人事後檢視，並記錄在這條權限上。
使用者權限應該多久重新認證一次？
頻率應該由風險決定。一種常見做法是：特權帳戶和管理員帳戶每季一次，標準業務角色每年一次，而且每當有人轉換職位或組別時立即進行一次額外覆核。ISO/IEC 27001:2022 控制項 A.5.18 要求定期檢視存取權限，但沒有訂明具體間距，頻率要由你們自己給出理由。另外要留意，流程圖記錄的是意圖，而不是合規本身：審核員索取的證據，是這個流程產出的審批紀錄和權限登記冊。