政策、審批與治理

所有受管轄操作均遵循相同路徑，無論是移動資金還是變更組織自身的設定：

1 - 發起。工作流程個人檔案持有該工作流程「發起」（或「執行」）權限的成員，可發起請求。對於提款及轉帳，成員還需持有相關帳戶的對應資金移動權限。

2 - 即時完成檢查。若成員持有「執行」權限，且工作流程的「始終要求審批」設定為關閉，請求將即時完成。完成。有一個例外：變更已鎖定政策的請求，無論請求人持有何種權限，均須等待審批。詳見下方「鎖定政策」。

3 - 審批佇列。否則，請求將等待審核。持有該工作流程「審批」權限的成員可在其佇列中查看待審請求。

4 - 處理結果。達到所需的獨立審批數量後，請求即告完成並生效。任何審批人均可拒絕請求，請求將即時終止且不生效。

已完成的請求將記錄為 安全事件，並關聯至該請求及其審批記錄。

成員不能批准自己的請求。此規則適用於所有工作流程，任何權限、設定檔或政策配置均無法覆蓋。

單一成員獨立完成受治理操作的唯一途徑，是持有 Execute 權限，且僅在工作流程政策允許即時完成的前提下方能生效。

每個工作流程的政策包含兩項設定：

Execute 與「Always require approval」的交互關係：

Execute 權限不會因政策設定而移除，始終保留於設定檔中。當「Always require approval」開啟時，系統會標示其為休眠狀態；待該設定關閉後，Execute 即恢復生效。

1. 請前往 政策 並選擇工作流程（例如，提款請求）。
2. 設定所需的審批人數。
3. 選擇是否開啟「永遠要求審批」。
4. 請查看目前持有各級別權限的成員。政策編輯器會在設定旁顯示各成員的級別，讓您在儲存前確認配置切實可行。
5. 請確認。

政策變更本身屬於「管理政策」工作流程下的受管操作。若該工作流程需要審批，您的變更將與其他請求一樣在佇列中等候。

每項政策均保有其專屬的變更歷史紀錄：每次更新、鎖定及解鎖均會連同相關審批請求一併列出，讓您隨時查閱變更內容、發起人及審批人。已完成的變更同樣會記錄為安全事件。

鎖定是治理的承諾步驟。日後對該工作流程政策的每項變更（包括修改所需審批數量、變更「Always require approval」設定或解除鎖定）均須獲得獨立審批。

無論目標政策是否已鎖定，所有政策變更均以 Manage Policies 請求的形式執行。鎖定不會改變變更的提交位置，只影響其完成方式：

• 針對未鎖定政策的變更，遵循正常的請求流程。若持有 Manage Policies 的 Execute 權限，且該工作流程的「Always require approval」設定為 OFF，成員可即時完成變更。
• 針對已鎖定政策的變更（包括修改所需審批數量、變更「Always require approval」設定或解除鎖定），一律須等待持有 Manage Policies 之 Approve 權限的成員審閱。鎖定會針對該政策覆蓋 Execute 權限，且對所有人一視同仁：即使是 Owner 的變更，也須經過相同的審閱流程。

一旦鎖定，任何人均無法單獨削弱該工作流程的治理。變更流程本身仍屬常規操作，工作流程配置中具備 Manage Policies 審批權限的成員均可審閱及批准，但每次變更至少須有兩人參與。

鎖定以工作流程為單位。鎖定 Withdrawal Request 不會影響 Transfer Request 或其他工作流程，您可按自己的節奏逐一收緊各工作流程。如需了解建議的推行順序，請參閱推行治理。

鎖定與解鎖同樣屬於請求

Manage Policies 工作流程下共有三類請求。您可在審批佇列、各政策的變更歷史紀錄及安全事件中查看相關名稱：

鎖定不能豁免於自身的規則：鎖定請求與任何其他 Manage Policies 請求遵循相同的生命週期。若您在 Manage Policies 上持有 Execute 權限，且其「Always require approval」設定為 OFF，鎖定將即時生效；否則請求將進入審批佇列，政策維持解鎖狀態，直至請求獲批為止。

政策變更的完成方式

綜合以上各點，任何 Manage Policies 請求的結果如下：

管理政策變更的兩種方式

兩項控制互為補充，互不衝突：無論哪一項適用，變更均須等待審批；同時啟用兩項亦不會產生額外效果。請使用鎖定功能逐步收緊管控；若希望所有政策變更均須通過審批，請在「管理政策」中啟用相關設定。

鎖定「管理政策」本身

「管理政策」與其他工作流程一樣，擁有本身的政策，而該政策亦有本身的鎖定功能。鎖定此工作流程是治理部署的最終確認步驟。一旦「管理政策」的政策鎖定後，組織內任何規則的變更（包括解鎖任何政策及解鎖「管理政策」本身）均須獲得獨立審批。此後，任何人均無法透過產品單獨放寬治理設定。

因此，建議您在鎖定前確認解鎖流程仍可執行，詳見下方「安全措施」一節。產品不會阻止您將政策鎖定至無人能變更的狀態。請參閱 治理部署指引，了解執行此步驟的適當時機。

請在鎖定前確認解鎖仍可正常進行。解鎖屬於針對已鎖定政策的「管理政策」請求，Execute 權限無法繞過此流程。請確保有一位成員可發起「管理政策」請求，另需有足夠數量持有該工作流程 Approve 權限的其他成員，且所有人均須完成驗證並處於活躍狀態。系統不會自動為您核查此項，若已鎖定的政策無法透過審批流程進行變更，則須聯絡 Kraken 客服團隊協助復原。

防止被鎖死。若某項變更會導致工作流程中無人能完成已發起的請求，系統將拒絕該變更。由於成員無法批准自己的請求，一旦所需審批數量超出任何單一發起人在其自身請求中可獲得的審批人數，系統即會拒絕該變更。此檢查在兩種情況下均會執行：編輯政策時，以及變更成員的 Workflow Profile 或帳戶角色時。

停用警告。在停用持有 Approve 權限的成員之前，請確認仍有足夠的審批人員。即使停用後工作流程的審批人數低於所需數量，停用操作仍會執行；待處理的請求將維持其建立時所適用的審批門檻。

政策設定妥當後，可參閱 治理部署指引，了解如何安全地逐步落實：依序完成配置、驗證與鎖定，每次處理一個工作流程，並附有實際操作範例。

該工作流程的「Always require approval」已開啟。此設定開啟期間，Execute 處於休眠狀態，所有請求均須排隊等候獨立審批。如需恢復即時完成，請在「政策」中將此設定關閉。請注意，此操作屬於 Manage Policies 的範疇，本身可能亦須經過審批。

若涉及的請求是政策變更，請同時檢查目標政策：對已鎖定政策的變更，無論 Execute 權限如何，一律須等候審批。這正是鎖定功能按設計運作的結果。

鎖定本身亦是一項 Manage Policies 請求。若 Manage Policies 的「Always require approval」已開啟，或您的 Workflow Profile 未持有其 Execute 權限，則鎖定請求與其他請求一樣，須等候獨立審批。在鎖定請求獲批之前，該政策將維持解鎖狀態。您可在審批佇列中找到該請求，請求完成後亦會記錄於政策的變更歷史紀錄中。

請統計該工作流程中持有 Approve 權限的有效成員數量（不包括您自己）。只有已接受邀請並完成驗證的成員，方可計入審批人數。已受邀但未同時完成兩項步驟的成員不計算在內，即使其已出現在您的團隊列表中。若某審批人在請求建立後被停用，其餘審批人可能已不足以達到所需數量。待處理請求將按其建立時的門檻計算，即使政策其後已作更改。請重新啟用該成員，或向另一位有效成員授予 Approve 權限，以解除阻滯。

請檢查您的 Workflow Profile：鎖定操作須在 Manage Policies 工作流程上持有 Initiate 或 Execute 權限。若鎖定請求已建立但未見任何變化，表示請求正在等候審批，而非被拒絕，請參閱上述說明。

系統不會因缺少獨立審批人而拒絕鎖定請求，因此請在鎖定前自行確認解鎖途徑：須有一位能發起 Manage Policies 請求的成員，加上該工作流程所要求數量的其他持有 Manage Policies Approve 權限的成員。

由於任何人均不得審批自己的請求，部分發起請求的成員所能獲得的審批人數，將少於所需數量。政策編輯器會列明原因：一位或多位成員同時持有 Initiate 和 Approve 權限，因此每位成員實際可用的審批人均比總數少一位。請降低所需審批數量，或向另一位不會在此工作流程發起請求的成員授予 Approve 權限。