---
title: FR-142 卡 8 分析——「帶入不符合事項」要帶哪些檢討資訊
status: 分析定稿，等決策者看過範例後開工（2026-10-18）
---

# 「帶入不符合事項」要帶哪些檢討資訊

## 現在帶什麼

稽核報告頁籤按「帶入不符合事項」，後端 `ar_objective_view.conclusion_draft()` 只對每條不符合的評估目標組一行：

```
AC.L1-3.1.1 授權存取控制 [a]：（稽核發現）；風險（高）：（風險說明）；改善建議：（建議）
```

三樣東西：稽核發現、風險、改善建議。這是「結果」，PM 開檢討會或跟老闆報告時要的是「過程」——誰做的、誰看過、什麼時候、為什麼會不符合、是不是第二次了。這些資料系統裡都有，只是沒拼起來。

## 系統裡有、而且能對到「這一條不符合」的資料

從一條評估目標往外抓，資料分五圈。每圈標「對檢討的用處」與「資料來源」。

### ① 判定本身（已帶一半）

| 資料 | 檢討用處 | 來源 |
|---|---|---|
| 稽核發現 | 不符合的事實 | finding.description |
| 風險等級／風險說明／改善建議 | 影響與對策 | risk |
| **判定人、判定時間** | 誰下的結論、什麼時候 | finding.updated_user／updated_at（畫面已有，草稿沒帶） |
| **查核方法**（檢視／訪談／測試） | 稽核人員是怎麼查的——文件看過就判不符合，和實際測過才判，可信度不同 | objective.methods（計畫階段設的） |
| 評估目標原文 | 老闆沒背 CMMC，看代碼不知道在講什麼 | objective.text |

### ② 客戶自述（SSP）——「自己說做到了，但稽核說沒有」

| 資料 | 檢討用處 | 來源 |
|---|---|---|
| SSP 實作狀態（已實施／部分／未實施） | 自評與稽核結果的落差——客戶自認「已全面實施」卻被判不符合，是檢討會最常追的點 | 本次稽核凍結的 SSP，`get_control_ssp()` 已有讀法（`ap.import_ssp_id`） |
| SSP 現況說明（評估目標層） | 客戶當初聲稱怎麼做的 | 同上 |

### ③ 佐證——「交了什麼、誰交的」

| 資料 | 檢討用處 | 來源 |
|---|---|---|
| 採用的佐證名稱、件數、來源（任務／專案／現場） | 判定依據的材料是什麼；0 件採用卻判不符合＝根本沒交東西 | objective.evidence（已組好） |
| 每件佐證的上傳人、上傳時間 | 誰負責交、交得多晚 | evidence.created_user／created_at |

### ④ 任務執行——「誰做、誰審、什麼時間、順不順」

這一圈是你要的「任務的執行資訊」，資料全在 `compliance.job_executions` 與周邊表，目前草稿完全沒碰。

| 資料 | 檢討用處 | 來源 |
|---|---|---|
| 任務名稱、所屬部門 | 歸屬 | job_executions.name；job_execution_org_units |
| 執行人（第 1 關指派人） | 誰負責做 | task_assignees（user_id、role） |
| 開始時間、完成時間、**期限、有沒有逾期** | 做得及不及時——逾期交的東西品質差是檢討常見結論 | start_time／end_time／due_at |
| **重做次數** | 被退回幾次、重開幾次 | attempt_no（重開會 +1） |
| 任務狀態 | 不符合的任務是不是根本沒做完 | status（TODO／PROCESSING／COMPLETED） |
| **關卡設定**（FR-148）：幾關、每關誰 | 審核鏈長什麼樣 | job_review_steps＋job_review_step_assignees（第 1 關＝task_assignees） |
| **關卡紀錄**（FR-148）：每次送審／核可／退回的人、時間、退回理由 | 主管退回過幾次、退回理由是什麼、顧問核可卻還是不符合——這是「檢查的人有沒有把關」的證據 | job_review_step_logs（`review_step_service.get_overview()` 已組成 steps＋logs 形狀，可直接複用） |

### ⑤ 歷史——「是不是重複發生」

| 資料 | 檢討用處 | 來源 |
|---|---|---|
| 同一條評估目標在前幾次稽核（第 1 次內稽、第 2 次內稽…）的判定 | 重複不符合＝改善沒落實，報告給老闆時最該標紅的 | `audit_round_passes` 每次的 ar_result_id → findings；pass 順序已有 |
| 前次的稽核發現摘要 | 對照「上次說什麼、這次還是什麼」 | 同上 |

### 有但不建議帶的

- 任務討論串（`survey_discussions` 只有問卷有，一般任務沒有）——沒有統一來源，先不碰。
- 佐證的 AI 分類結果——與檢討無直接關係。
- 任務指南（FR-147 的「指南」欄）——是給執行人看的操作說明，不是檢討材料。

## 設計

### D1 帶入後長什麼樣：每條不符合一個區塊，不再是一行

原本一行塞三樣，再加十樣會變一坨。改成每條不符合一個區塊，標題行＋固定順序的子行，**子行沒資料就不印**（不印「無」）。輸出改成 HTML（既有 `toEditorHtml` 會原樣接進編輯器；報告 Word 第 7 章走 `rich_to_plain` 轉純文字，格式自動變成逐行）。

範例（真資料拼出來會長這樣；人名用暱稱）：

> **AC.L1-3.1.1 授權存取控制 [a]**　限制系統存取僅授權使用者
> 稽核發現：系統使用者清單中有 3 位已離職人員帳號仍為啟用狀態，未見停用紀錄。
> 風險（高）：離職人員可憑舊帳號登入內部系統。改善建議：建立離職當日停用帳號的流程並留存紀錄。
> 判定：潘稽核（稽核人員）2026-10-18 14:20；查核方法：檢視、訪談
> 客戶自述：已全面實施——「人資每季提供離職名單，IT 依名單停用」（與稽核發現不符）
> 佐證：採用 2 件——系統使用者清單.xlsx（王小明，10-16 上傳）、帳號盤點紀錄.pdf（王小明，10-18 上傳）
> 任務：上傳系統使用者清單｜資訊部｜執行 王小明｜10-16 開始、10-18 完成（期限 10-19，準時）｜重做 1 次
> 審核：
> 　10-17 主管審核　李主管　退回（清單缺離職人員）
> 　10-18 交證據　　王小明　重交
> 　10-18 顧問審核　陳顧問　核可
> 前次：第 1 次內部稽核同項不符合（「未提供使用者清單」）——**重複發生**

再舉一條沒關卡、沒前次、任務逾期的：

> **IA.L1-3.5.2 身分驗證 [b]**　在允許存取前驗證使用者身分
> 稽核發現：未提供雙因子驗證設定畫面，無法確認已啟用。
> 風險（中）：帳密外洩即可直接登入。
> 判定：潘稽核（稽核人員）2026-10-18 15:02；查核方法：檢視
> 客戶自述：部分實施
> 佐證：採用 0 件
> 任務：上傳雙因子驗證設定｜資訊部｜執行 張工程師｜10-18 開始、未完成（期限 10-19，**已逾期 3 天**）

審核紀錄一筆一行（日期、關卡、人、動作，退回帶理由），不用箭頭串成一行——理由一長就讀不了、關卡一多就看不出順序。

標題行之外只有一個粗體：「重複發生」與「已逾期」。檢討會上眼睛要先掉到這兩個。

### D2 同一顆按鈕，不加選項

不做「精簡／完整」兩種。理由：原本那行的三樣東西都還在（第 2、3 行），稽核人員要短版就把後面的行刪掉——刪比補快得多。

### D3 帶進第 7 章後，報告 Word 會印出整段

第 7 章就是報告正文，帶進去的所有行都會進 Word／PDF。這是**刻意的**：決策者要的是給 PM 開會、給老闆看，報告本來就是那份。稽核人員若覺得某些行不該給客戶看（例如「主管退回理由」），編輯器裡自己刪。**不另做「只給內部看」的版本**——那是另一份報告，不在本卡。

### D4 資料取法：接在既有 build_view 之後、只對不符合的條目多抓

`get_conclusion_draft` 已呼叫 `build_view` 拿到整棵樹（含判定、風險、佐證、methods）。多抓的只有四樣，而且**只對不符合的評估目標抓**（符合的不浪費查詢）：

1. SSP 自述：`get_control_ssp` 的核心讀法（`read_control_implementation_by_ssp_id`），按控制項批次。
2. 任務：`mapping_by_round` 已有「評估目標→workflow_execution」；每個 workflow 取最新一次各站（`PoamJobQuery.stations` 同規則）＋ `task_assignees`、`job_execution_org_units`、`due_at`／`attempt_no`。
3. 關卡：`review_step_domain_service.list_steps／list_step_assignees／list_logs` 按任務批次。
4. 前次：`audit_round_passes` 依 pass_no 排，取前面每一次的 findings（`findings.get_by_ar_result`），對同 part_id 比對。

人名一律走 `enrich_audit_nicknames`／`resolve_user_names` 轉暱稱，不印帳號。

### D5 落點：兩支新檔，不往 382 行的 app service 塞

- `app/flow_control/service/ar_review_context.py`：抓第 ②④⑤ 圈資料，回每個 part_id 一個 dict。
- `app/flow_control/service/ar_conclusion_draft.py`：把樹＋context 渲染成 HTML。原 `ar_objective_view.conclusion_draft()` 改成呼叫這支（保留函式名，呼叫端不動）。
- 任務／關卡的 SQL 若要新查詢，開 `infra/readmodel/audit/ar_task_context_query.py`（不往 `poam_job_query.py` 塞——那支是改善計畫頁的）。

## 被排除的做法

- **另開「檢討報表」頁或 Excel**：多一個出口、多一套守門與匯出；決策者要的是現有按鈕變豐富，不是新功能。
- **把任務資訊放進稽核結果頁每條評估目標旁**：那是填寫頁，資訊已經很多（佐證、發現、風險），再疊任務歷程會讓稽核人員填不下去；檢討資料集中在報告草稿一次拿齊比較對。
- **帶入任務討論串**：來源不統一（只有問卷有），先不做。

## 反悔條件

- 若稽核人員反映「每次都要刪一堆行」→ 再加「精簡／完整」選項（D2）。
- 若客戶反映報告不該出現內部審核退回理由 → 再做內部版報告（D3）。