把轉職視為兩項決定
銷售同事調任營運主管時，最顯眼的工作是開通新職位所需工具；較容易忽略的，是移除舊職務才需要的權限。兩項決定同樣重要。員工即使有有效登入和多因素驗證，仍可能保留已不再需要的資料存取。OWASP 區分身份驗證與授權，並建議採取最小權限及定期檢查權限累積。小企可先建立附日期的變更申請，列明員工、原有及新職責、生效時間和核准人。不要只寫「升為管理員」；應逐項指明新職務需要做甚麼，例如查看出貨清單或修改供應商訂單，因為兩種操作的資料風險和問責要求並不相同。
按系統與操作盤點權限
列出該員工可使用的應用，包括身份供應商群組、網店後台、客服、會計、共享雲端硬碟、分析工具、雲端託管及供應商入口。每項記錄帳戶身份、目前角色或群組、可存取資料範圍，以及獲准執行的操作。閱讀、匯出、新增、批准、修改和刪除要分開看。「經理」等角色名稱可能隱藏大量權力，舊項目遺留的群組也可能帶來主控制台以外的權限。OWASP 建議定義授權時列出使用者類型、資源與操作，轉職審查亦可沿用同一個對照表。這是權限清單，不是收集密碼或秘密令牌。若有人使用共用帳戶，應另列為改善事項：多人共用同一身份，個別授權和操作追查都會變得困難。
由負責人訂立新權限基準
接收員工的主管應確認新職務的必要工作和所需資料；涉及敏感系統的例外，則由系統擁有人核准。標準角色若確實吻合，可先以此為基礎，再只調整有書面理由的差異。OWASP 建議預設拒絕，除非有明確依據才授權。當產品只提供過於寬泛的「管理員」角色，這個原則尤其有用。例如營運負責人或許需要查看訂單地址和更新出貨狀態，卻未必需要匯出全部顧客資料或修改付款結算設定。這只是判斷框架，不是所有企業通用的職位說明；每間公司須按自己的職責分工決定。臨時項目權限也要有負責人和到期日，避免員工再次調職後仍永久保留。
有計劃地撤銷舊權限
把舊職務權限清單與新職務已核准基準對照，逐項標記保留、更改或撤銷。移除一個舊群組未必足夠：直接授權、代管郵箱、供應商帳戶或 API 工具，可能仍提供相同能力。應同時檢查應用程式與負責自動開通帳戶的身份供應商；只在本地改設定，可能被下一次群組同步覆蓋。撤權生效時間要與主管協調，特別是員工仍在交接工作時。不能為方便而無限期保留高權限。若確有短期重疊需要，寫明仍可接觸的資料及操作、結束日期和負責核實撤銷的人。持續營運應靠指定接手者，而非靠任何人日後都可能重新使用的未經審查權限。
核對真正受保護的操作
選單項目消失是有用的介面訊號，但不能證明底層操作已被阻止。OWASP 指出每次要求都應檢查權限；其授權模式指引亦強調在接近受保護資源的位置執行檢查，讓系統能核對動作、資料對象及租戶。轉職後應實際測試員工原可使用的閱讀、匯出、編輯和批准途徑，確認已撤權限即使經舊書籤、直接 API 要求或另一工作流程也會被拒絕，同時新的合法工作仍能完成。測試應使用受控帳戶或已核准的測試資料，不應為證明拒絕而隨意翻閱真實顧客資料。若系統按機構或分店區分資料，也要核實新角色只可接觸目標範圍，而非同類型的所有紀錄。
以一次調職作演練
假設客服員星期一轉任倉庫協調。星期五主管列出新需要：查看已付款訂單及送貨地址、更新出貨狀態、上報存貨異常。該員工不再需要客服郵箱、退款批准或匯出投訴紀錄。系統擁有人把需求對照實際角色，檢查相關群組會否同時帶來退款權限，並為尚未完成的個案設定有明確結束時間的短暫交接。調職後以受控測試確認倉庫功能正常，舊退款與匯出入口則拒絕該帳戶。負責人還要核對共用客服郵箱的代管權限已移除，未完結個案亦已指定接手者。本文不規定必須用多少小時完成；時間表屬營運安排，真正需要保留的證據是核准範圍與測試結果。
避免自己批准自己的權限
員工可說明自己需要完成甚麼工作，但涉及重要權限，應由負責的主管或系統擁有人核准。退款、撥款、改價、顧客資料匯出及用戶管理，更需要清楚分工。小團隊即使只有一位系統管理員，也應記下誰覆核申請，以及何時重新檢視例外；人手有限不能把沒有紀錄的全面授權變成合理控制。工單應記錄高權限的原因與核准人，但不應包含秘密憑證。也要檢查新角色會否批准自己的變更，或建立另一個高權限帳戶。核心問題不是職銜聽起來有多高，而是每項敏感操作是否有合理工作需要、負責人和有效界線。
留下可覆核的紀錄
結案紀錄應包括舊及新權限清單、生效時間、核准人、例外、測試個案，以及確認撤權的人。保留足以重建決定的資料便可，不要把顧客檔案複製進工單。OWASP 建議定期檢查權限累積，因此調職紀錄應成為下一輪定期覆核的輸入，而不是只留在收件箱。臨時授權要設定按日期重新檢查。若系統無法顯示直接授權對象，或無法安全測試拒絕，應如實記錄限制，安排人手覆核或產品改善。只新增了新群組，不能便寫「權限已審查」。有用的完成描述應列明已查的系統、開通與撤銷的能力，以及尚未處理的例外。
把流程變成可重用程序
小企起步毋須先購買複雜管治平台。可為重要系統保留簡單的職責權限表，指定每個系統的擁有人，並讓每次調職都觸發同一套核對。實際工作內容改變時要更新權限表，不能把它當成與工作脫節的固定圖表。新增工具時，派發帳戶前先訂明誰可閱讀、匯出、修改及批准；處理舊工具時，先看影響最大的操作及最近曾調職的人員。臨時項目完結後重查，並確認自動同步沒有重新加入舊群組。這套程序讓主管有具體事項可決定，技術同事也清楚要改哪項設定。員工如欠缺必要功能，亦有明確途徑提出申請，而不用要求全面管理員權限。
處理難以即時撤銷的例外
有些工具只提供範圍很廣的內建角色，也有工具把直接授權藏在項目或資料夾內。應記下限制，以及因此開放的敏感操作。主管才可決定延後開通、由另一人分擔工作，或批准有到期日並加強覆核的例外。產品若沒有細分權限，不能憑空聲稱已設定較窄角色。若交接未完結而需要暫留舊帳戶，應指定負責人、結束日期及尚待完成的工作。期滿後要在身份供應商及應用程式兩邊確認撤權。紀錄必須分清已安全完成的變更與仍存在的風險，讓下一位覆核者知道哪些項目真正測過，以及哪些仍須改進產品或程序。
正式推出前的核對
- 按操作及資料範圍對照舊權限與新工作。
- 由系統擁有人核准敏感例外及到期日。
- 測試舊入口已拒絕存取，新工作入口仍可正常使用。
