Compliance Manager 四階段稽核流程

角色由上往下繼承（專案 → 群組 → 控制項），下層可覆寫。 Job 層級只有「被指派 = 執行者」和「is_approver = 問卷核准者」。

專案與稽核週期的關係

一個專案 = 一個組織對一套合規框架的持續管理，不會因為稽核結束就關閉。 每次外部稽核來就是新增一個 AP（Assessment Plan），不是開新專案。 每個 AP 對應一輪完整的 Phase 1-4 流程。

Project（永久存在）
├─ SSP（持續更新的活文件，跨 Round 共用）
├─ Profile（不變）
│
├─ AP #1 (2025 年度稽核) ← project_assessment_plan_mapping
│   ├─ ap_groups → ap_controls → ap_tasks（從 Profile snapshot）
│   ├─ workflow_executions + job_executions + job_evidences
│   ├─ review_marks（內部審核記錄）
│   ├─ AR #1（外部稽核結果：ar_controls + ar_findings + ar_evidences）
│   │   ├─ ar_data run_no=1（首次稽核）
│   │   ├─ ar_data run_no=2（覆核，verdict 繼承/重置）
│   │   └─ ar_data run_no=N...
│   └─ POA&M #1（矯正追蹤：自動從 not-satisfied findings 產生）
│
├─ AP #2 (2026 年度稽核) ← 第二筆 project_assessment_plan_mapping
│   ├─ ap_groups → ap_controls → ap_tasks（重新 snapshot，反映最新 SSP）
│   ├─ workflow + job + evidence（全新的，跟 AP #1 完全獨立）
│   ├─ AR #2
│   └─ POA&M #2
│
└─ AP #3 (2027) ...

核心原則

• 每一輪的 AP、job、evidence、AR、POA&M 都是獨立的一整組資料，互不干擾
• 執行人員看到的永遠是當前 Round 的任務，不會跟歷史 Round 混在一起
• 歷史 Round 的資料完整保留，管理者可以切換查看改善軌跡
• GRC API 以 ap_uid 為核心查詢參數，決定查看哪一輪的資料

API 查詢模式

所有 GRC 控制項相關 API 的 URL 結構：

/grc/project/<project_uid>/ap/<ap_uid>/control-groups/list
/grc/project/<project_uid>/ap/<ap_uid>/control-group/<group_uid>/controls/list
/grc/project/<project_uid>/ap/<ap_uid>/task-setup/tree
...

• project_uid：用於權限驗證（確認使用者有權限存取該專案）
• ap_uid：用於決定查詢哪一輪稽核的資料（查 AP → groups → controls → tasks → jobs）

前端進入專案後，先呼叫 AP 列表 API 取得所有稽核輪次，再以選定的 ap_uid 查詢後續資料。

操作者：管理者

首次建立專案

1. 管理者建立專案，選定 Profile（如 CMMC L2 baseline）
2. 系統執行 create_project（POST /api/1.0/grc/projects/create）：
   • 從 Profile snapshot：ap_groups → ap_controls → ap_tasks
   • 建立空白 SSP（或關聯既有 SSP）
   • 建立 Assessment Plan（AP #1），status = preparing
   • 初始化 SSP control implementations（每個控制項的實作狀態追蹤）
   • 建立 workflow_executions + job_executions（每個 AP task 一個 workflow）
   • 建立 project_assessment_plan_mapping
   • 不建立 AR（Phase 3 才建立）
3. 管理者編輯 SSP：
   • system_characteristics（系統名稱、邊界、FIPS 199 三軸分類）
   • 每個控制項的實作描述（現況說明）
   • 每個 AO（檢查項目）的具體實作方式 + 關聯程序書
4. 管理者定義每個 AP Task 的 job（上傳文件、填問卷等）
5. 管理者指派執行人員到各 job
6. 管理者確認設定完成，點擊「啟動專案」（POST /api/1.0/grc/project/<pid>/ap/<ap_uid>/activate）
   • 系統檢查是否所有 task 都有 job（可 force bypass）
   • AP status → active
   • 通知 BPMN 第一個任務的指派人員（專案名稱 + 任務數量）
   • 後續任務由 complete_job 流程推進時自然通知

注意：preparing 狀態下 My Jobs 不會顯示該專案的任務，執行人員看不到也無法操作。

開啟新一輪稽核（Round 2+）

管理者在既有專案上點擊「開啟新一輪稽核」→ launch_new_round：

• 建立新的 AP（基於最新 SSP 重新 snapshot ap_groups / ap_controls / ap_tasks）
• 新增 project_assessment_plan_mapping
• 為新 AP tasks 產生新的 workflow + job（全部空白）
• AP status = preparing（需再次 activate）
• 重新走一次 Phase 1 → 2 → 3 → 4

API 對應

操作者：執行人員 + 審核人員

1. 執行人員收到通知，登入看到被指派的 job 清單
2. 執行人員完成 job：
   • 上傳文件 → job_evidences
   • 填寫問卷 → task_surveys + question_answers
   • 如果問卷需要核准 → 通知 is_approver 的人核准
3. Job 完成後 workflow 自動流轉（complete_job）
4. 當某個 AO 底下所有 job 都完成 → 系統自動通知管理者/審核人員
5. 審核人員在 Control 層級審閱：
   • 瀏覽 SSP 描述 + 所有證據（control/detail API）
   • 通過 → 標記「審查通過」（review sign-off）
   • 不通過 → 在 job comment 留言說明原因 → 退回該 job（revert_job）→ 執行人員收到退回通知重做
6. 管理者在 dashboard 監控進度
7. 管理者確認就緒，點擊「啟動外部稽核」→ 觸發 launch_audit

API 對應

操作者：稽核人員

launch_audit 系統動作

• 檢查 AP status = active
• 檢查未完成 tasks（可 force bypass）
• 建立 assessment_result_datas（run_no=1）+ 從 AP controls 初始化 ar_controls（verdict=null）
• AP status → auditing
• 通知稽核人員

稽核流程

1. 稽核人員看到快速瀏覽介面，每個控制項顯示：
   • SSP 實作描述（唯讀）
   • 所有 job_evidences（準備期上傳的佐證）
   • 內部審核的意見（job comments）
   • 關聯的設備和部門
2. 稽核人員逐項審查，寫入 ar_controls verdict：
   • pass → 控制項合規
   • fail / partial → 記錄缺失，建立 ar_findings
3. ar_evidences 引用 job_evidences（不複製檔案）
4. 全部控制項審查完畢後，管理者確認 AR（confirm_audit）：
   • 全部 pass/na → 直接結案（跳過 Phase 4），AP status → closed
   • 有 fail/partial → 進入矯正（Phase 4），AP status → remediation

設計決策記錄

補件機制： 稽核期間不即時退回補件，稽核員只做標記和記錄。全部審查完畢後，由 confirm_audit 批次處理所有不通過的項目。

退回粒度： 以 AO（Assessment Object）為單位退回。一個 AO = 一個 workflow，退回時呼叫現有 revert_job(revert_to=第一個 job)，整個 workflow 下所有 job 回到初始狀態。不影響同一控制項下其他 AO。

API 對應

操作者：管理者 + 執行人員 + 審核人員 + 稽核人員

confirm_audit 系統動作（從 Phase 3 進入）

• 從每個 not-satisfied finding 自動建立 POA&M（status=open）
• 對每個有缺失的 AO 呼叫 revert_job（退回到第一個 job，整個 workflow 重做）
• AP status → remediation
• 通知執行人員開始補件

POA&M 管理

POA&M 是 finding 的追蹤視圖：

AR finding（缺失事實）
  → POA&M（自動建立，追蹤狀態）
  → revert AO jobs（實際補件走既有 job 機制）

POA&M 記錄：
  - 缺失來源（對應哪個 AR finding / 控制項）
  - 改善計劃（remediation_plan）、到期日（due_date）、負責人（assignee_uid）
  - 狀態追蹤（open → in_progress → closed）

矯正流程

1. 管理者填寫改善計劃（remediation_plan、due_date、assignee_uid）
2. 執行人員在 My Jobs 看到被退回的任務
3. 執行人員補上證據 / 重新填寫問卷
4. Job 完成後自動流轉 → 通知審核人員
5. 審核人員驗證矯正到位：
   • 通過 → sign-off
   • 不通過 → 退回重做（同 Phase 2 流程）
6. 管理者將 POA&M 標記為 closed

多輪覆核（Stage 4）

所有 POA&M 都 closed 後，觸發 close-round：

1. 系統建立新的 ar_data（run_no = N+1）
2. 複製 ar_controls 到新一輪：
   • 有 POA&M 的控制項 → verdict=null（需重新稽核）
   • 無 POA&M 的控制項 → verdict 繼承（已通過的不重複稽核）
3. AP status → auditing（回到外部稽核）
4. 稽核人員只需覆核失敗的控制項（可參考 previous_findings）
5. 再次 confirm_audit：
   • 全部通過 → AP status → closed（結案）
   • 仍有缺失 → AP status → remediation（再次矯正，可多輪循環）

API 對應

project.status — 由 AP 的狀態推導

AP 狀態流轉

preparing → active → auditing → remediation → closed
                        ↑           │
                        └───────────┘（close-round 多輪循環）

2025 — 首次認證

2026 — 年度複評

2027 — 年度複評 + 框架更新

不需要改的 API：

• GET/PUT/DELETE /grc/project/<uid> — 專案本身
• POST /grc/jobs/my/list — My Jobs（透過 workflow_execution_uid 直查）
• GET/PUT /grc/project/<uid>/job/<job_uid> — 單一 job 操作（by job_uid）
• POST /flow-engine/task/complete/<id> — 完成 job
• POST /flow-engine/task/revert/<id> — 退回 job
• job comment CRUD — by job_execution_uid
• job evidence CRUD — by job_execution_uid