---
title: "GRC 延伸 — 討論稿 (FR-151)"
brand: "Guidant AI · **FR-151** GRC 延伸"
eyebrow: "FR-151 · 討論稿 · 2026-10-19"
h1: "從 Compliance 往上補成 GRC：組織與責任、公司層風險、總經理儀表板"
subtitle: "底層都在，是補強不是重做；三層由下往上疊，每層可單獨上線"
lede: "平台目前只有 GRC 的 C。PM 2026-10-19 定調：先把**組織架構＋責任矩陣（RACI）**補齊，再補**風險評估（R）**，最後做出**總經理一眼看懂的 GRC 儀表板**（以 PM 給的 Excel 範本為目標畫面）。本稿盤點既有底層（部門樹、角色、OSCAL 責任方、專案層風險表、POA&M）與缺口，提出三層規劃與拆卡，並對照 OCEG Red Book 與市面平台列出我們還缺什麼；位階設計採「一棵樹、一個標籤、一張對照表」，附未來不大改的鉤子表。D1～D14 待決策者裁。"
chips: [
{text: "三層：組織與責任 → 風險登錄 → GRC 儀表板", kind: accent},
{text: "從零只有兩樣：RACI 表、公司層風險登錄", kind: ok},
{text: "D1～D14 待裁", kind: warn},
{text: "雛形待 D 項裁後刻", kind: warn}
]
footer: "FR-151 · 討論稿 · 2026-10-19 · 會議記錄 meeting-2026-10-19.md · 現況依據：scripts/init/02-schema.sql、app/oscal/service/ssp_risk_*.py、FR-132／135／145 文件（2026-10-19 查）"
---
::: {.callout .warn}
**本頁為 2026-10-19 單頁討論稿 v4 的歷史版本，唯讀。** 內容已重組為多頁站（需求／分析與決策／規劃），且「不做 RACI」等結論已被決策者推翻。請以站內新頁為準，本頁只供追溯當時推理。
:::
**狀態**：討論稿（待裁 D1～D14；裁完刻雛形，雛形審過落 design.md） ｜ **日期**：2026-10-19 ｜ **會議記錄**：[meeting-2026-10-19.md](meeting-2026-10-19.md)
路徑慣例：BE 路徑相對 `compliance-manager-be/`；`pkg/` 代表 `~/Projects/Jedicogy/module/jedi-python-package/`；FE 路徑相對 `compliance-manager-fe/`。
## 變更紀錄 {#changelog nav="變更紀錄"}
| 日期 | 變更 | 對應 |
|---|---|---|
| 2026-10-19 | v1：會議記錄整理、現況盤點、三層規劃、拆卡草案、市場對照、D1～D9 待裁 | 本稿 |
| 2026-10-19 | v2：決策者問「位階怎麼設計、外面怎麼做、未來會不會大改」——新增 §GRC 入門（給非工程讀者）、§位階設計（一棵樹＋標籤＋對照表、三條邊界規則、擴充鉤子表）、D10～D12 | 決策者提問 |
| 2026-10-19 | v4：決策者複述「找頭兒」場景——新增 D14 第一版範圍（四張卡最小版 vs 完整三層），建議最小版、資料表照完整設計 | 決策者提問 |
| 2026-10-19 | v3：決策者問「RACI 是什麼、套到系統怎麼套、PM 講的對不對」——新增 §RACI 怎麼讀、§套進系統的接點（六處改、三樣新）、§PM 說法對照來源、風險欄位加「關聯業務目標」、D13（控制項負責部門） | 決策者提問 |
---
## 分工概述（30 秒版） {#overview nav="概述"}
整案一句話：**在現有合規平台上面疊三層——部門有主管、風險與控制項有 RACI 四格負責人、公司層有一本風險登錄、最上面一頁總經理儀表板把高風險對到該找誰——全部沿用既有資料，不重做。**
給非工程讀者的背景：GRC 是老闆用上帝視角看公司。G（治理）是「誰負責什麼」，R（風險）是「哪些事會造成損失、多嚴重、控得住嗎」，C（合規）是「要滿足哪些法規才能賣產品」。我們整套系統在做 C；G 有一半（部門、角色都有，但沒有「主管是誰」與責任矩陣）；R 只有 CRA 專案裡一張風險表，公司層沒有。PM 原話：「我們是從下面做上來，現在要慢慢補回最上面的上帝視角。」
| 層 | 做什麼 | 產出 | 完成怎麼判定（決策者檢查法） |
|---|---|---|---|
| **第 1 層 組織與責任** | 部門加主管欄；新增 RACI 責任矩陣（對象＝風險、控制項）；結案報告加責任矩陣總表與每條負責人 | 部門頁多「主管」、新頁「責任矩陣」、結案報告多一節「責任歸屬」 | 開部門管理頁，任一部門能選主管並顯示；開責任矩陣頁，對一條控制項填 R／A／C／I 四格各一人，重整還在；下載結案報告，不符合的控制項旁印出負責人姓名與部門 |
| **第 2 層 公司層風險登錄** | 獨立模組，不綁專案；欄位照 Excel 主登錄表；風險可連控制項與專案；稽核 NOT MET 自動建風險 | 側選單新入口「風險管理」：登錄表、風險詳情、五乘五矩陣 | 新增一筆風險填完領域／部門／負責人／衝擊／可能性／控制有效性，列表自動算出剩餘風險與等級；在某專案稽核判一條 NOT MET，風險登錄多出一筆並連回該專案 |
| **第 3 層 GRC 儀表板** | 總經理一頁：風險矩陣、各部門記分卡、逾期審查、合規狀態分佈；點矩陣任一格列出負責主管 | 側選單「GRC 總覽」 | 開頁面與 PM 給的 Excel Dashboard 分頁對照，六個區塊都有；點右上角高風險格，彈出清單列出每筆風險的負責主管與部門；數字與風險登錄、稽核結果一致 |
### 分幾版、多久看到東西（給老闆的時程）
| 版 | 做什麼 | 老闆看到什麼 | 卡數 | 時間（累計） |
|---|---|---|---|---|
| **第一版 找頭兒** | 部門加主管、控制項對部門、責任矩陣只開當責／執行兩格、儀表板直接讀稽核缺失 | 總覽頁：幾條沒過、哪個部門幾條、點進去是哪個主管；結案報告多一張「誰扛哪幾條」總表 | 4 | 雛形 2～3 天；真資料上 DEV **約 2 週** |
| **第二版 風險評分** | 公司層風險登錄、衝擊×可能性評分、真熱圖、稽核不合格自動進登錄、專案風險升級、風險接受簽核 | 五乘五熱圖右上角點進去列風險與主管；手填稽核抓不到的風險；高風險關閉要上層簽 | 6 | 再 4 週，**累計約 1.5 個月** |
| **第三版 GRC 完整** | 政策文件生命週期、供應商風險、事件通報、意識訓練、KRI、三道防線報表 | 功能面與市面 GRC 平台看齊 | 另開 FR | 四塊各約 2 週、可挑做，**累計約 3.5～4 個月** |
估法前提：每張卡一個 session 一到兩天含驗收；決策者裁 D 項與審雛形不卡超過一天；無其他 FR 搶人，有平行工作乘 1.5。
一句話：兩週看到「哪些沒過、找誰」，一個半月看到「風險多大、先處理哪個」，三到四個月與市面 GRC 平台看齊。
依賴：第 3 層沒有第 1、2 層的資料是空頁，順序固定 1 → 2 → 3，但三層各自可獨立上線。決策者功課：先裁 D14（範圍），再裁 D1～D13，特別是 D2（RACI 對象）、D5（風險方法）、D12（風險接受權責）決定資料模型。
---
## 給非工程讀者的 GRC 入門 {#primer nav="GRC 入門"}
讀討論稿會碰到的名詞，每個一句白話、一句「在我們系統對應什麼」。
| 名詞 | 白話 | 在 Guidant AI 對應 |
|---|---|---|
| **GRC** | 老闆用上帝視角看公司：哪裡會造成損失（R）、誰負責管（G）、哪些法規非守不可（C）。三件事用同一套資料看，不各管各的 | 本案把 G、R 補到既有的 C 上面 |
| **G 治理 Governance** | 誰負責什麼、誰有權拍板、沒做好怎麼追。長期、策略層 | 部門樹＋主管、RACI、風險接受權責 |
| **R 風險 Risk** | 會造成損失的事，各自多可能發生、發生多嚴重、現在控得住嗎 | 公司層風險登錄、五乘五矩陣 |
| **C 合規 Compliance** | 要滿足哪些法規、框架、合約才能營運或賣產品；日常、操作層 | 既有整套：框架、SSP、稽核、POA&M |
| **合規是風險的一種** | 不合規的後果是罰款、不能賣、失去客戶，所以每條不合規都是一筆風險 | 稽核判 NOT MET 自動餵進風險登錄 |
| **OCEG** | 發明 GRC 這個詞的非營利組織，出的《GRC Capability Model》（Red Book）是這個領域的教科書 | PM 買的 PDF；本稿用它的 20 個元素當對照 |
| **LEARN／ALIGN／PERFORM／REVIEW** | Red Book 的四大步：了解環境 → 定目標並找出風險 → 做控制 → 回頭檢查 | 我們強在 PERFORM 的控制與 REVIEW 的稽核，弱在 ALIGN 的風險識別 |
| **固有風險 Inherent** | 什麼都不做時的風險＝衝擊 × 可能性 | 風險登錄「固有」欄 |
| **剩餘風險 Residual** | 做了控制之後還剩多少＝固有 × (1 − 控制有效性) | 風險登錄「剩餘」欄，儀表板熱圖預設看這個 |
| **風險矩陣／熱圖** | 橫軸可能性、縱軸衝擊的五乘五格子，右上角最危險 | 第 3 層儀表板；PM 說「老闆從右上往左下處理」 |
| **風險處置四式** | 接受（不處理、簽名負責）、降低（加控制）、轉移（保險、外包）、避免（不做那件事） | 風險登錄「處置方式」欄；「接受」要簽核 |
| **風險胃納 Appetite／容忍 Tolerance** | 公司整體願意承擔多大風險（胃納）、切到各部門可以放任多大（容忍）。超過容忍要往上報 | 第一版只做「超過等級要上層簽核」，額度制留第二階段 |
| **RACI** | 一件事的四種角色：R 執行（做的人）、A 當責（出事找他，只能一人）、C 諮詢（做之前要問他）、I 告知（做完要通知他） | 第 1 層責任矩陣表，對象是風險與控制項 |
| **三道防線 Three Lines** | 第一線：業務部門自己管自己的風險；第二線：風險與合規職能訂規則、監督；第三線：內部稽核獨立查證。外面還有外部稽核與董事會 | 角色加「第幾線」標籤，報表分組用 |
| **升級 Escalation** | 風險超過某人的權限或容忍，自動推到上一層的人桌上 | 風險接受權責對照表＋待辦 |
| **KRI 關鍵風險指標** | 風險的體溫計：一個可量測的數字加門檻，超過就警示 | 第二階段 |
| **政策 Policy／程序 Procedure** | 政策是「我們要怎樣」，程序是「具體步驟」。GRC 要求有核准人、生效日、定期審查、版本 | 程序書池只有掛檔，生命週期列第二階段 |
| **登錄表 Register** | 一種東西一本帳：風險登錄、議題登錄、供應商登錄 | PM 給的 Excel 主登錄表就是一本混合登錄 |
### RACI 怎麼讀 {#raci-primer nav="RACI"}
RACI 是四個英文字的縮寫，用來回答「這件事到底誰負責」。一件事（一條風險、一個控制項、一份政策）填四格：
| 字母 | 英文 | 白話 | 人數規則 | CEO 問責時 |
|---|---|---|---|---|
| **R** | Responsible | **動手做的人**：實際執行、交出結果 | 可多人 | 「做到哪了」問他 |
| **A** | Accountable | **拍板與扛責的人**：核准結果、出事找他 | **只能一人** | 儀表板點進去要秀的就是他 |
| **C** | Consulted | **做之前要問過的人**：雙向，意見要納入 | 可多人、可空 | 不問責 |
| **I** | Informed | **做完要告知的人**：單向，通知即可 | 可多人、可空 | 不問責 |
舉例，風險「供應商沒做資安評估就上線」：R＝採購部承辦；A＝採購部主管；C＝資安部；I＝財務部。排成表就是「責任矩陣」：橫列是事項、直欄是部門或人、格子填 R／A／C／I。
三個常見誤解：
- **A 不是「最大的主管」**，是「這件事出問題該找的那一個人」。同一個部門主管可以是十條風險的 A，也可以某條風險的 A 是他底下的課長。
- **R 與 A 可以是同一人**（小公司常見），但 A 仍只能一人，否則追責時互推。
- **PM 給的 Excel 範本只有一個 Owner 欄**，等於只有 A。本案做四格是比範本細，D2／D3 裁對象與必填規則。
---
## 需求背景 {#why nav="背景"}
PM 2026-10-19 會議（完整整理見 [會議記錄](meeting-2026-10-19.md)）交付三份資料：OCEG《GRC Capability Model v3.5》（Red Book）、《GRC Overview Dashboard.xlsx》範本、Workiva 入門文章。定調三件事：
1. **目標畫面**：「我們最終的目標就是做出這種感覺」——指 Excel 範本的 Dashboard 分頁（KPI 卡、風險熱圖、合規狀態分佈、部門記分卡、審查佇列）。
2. **CEO 的兩個動作**：看哪個環節風險高；點進去知道哪個部門的哪個主管負責，把人叫過來問「處理了嗎、什麼時候完成」。
3. **要補的兩塊**：組織架構（部門、主管、核心人物）＋責任矩陣 RACI；風險評估（怎麼評、誰負責、綁哪些控制項）。
> 找到人、給他責任了，這時候就可以做後面所有控制項的綁定，然後我也可以追責。
> [— PM（08:40）]{.attr}
### Excel 範本九張頁各是什麼
結構是「一本帳、七種看法」：只有 GRC Register 要人填，其餘全是公式從它算出。檔案位置 `~/Desktop/00_Compliance Manager/GRC/GRC Overview Dashboard.xlsx`。
| 頁 | 是什麼 | 對應我們 |
|---|---|---|
| Instructions | 使用說明：只填 Register；總分融合剩餘風險、合規狀態、未結議題、審查逾期、控制有效性 | 無 |
| Copyright | 版權頁，空 | 無 |
| Lookups | 七組下拉字典：Domain 八個、Category 九個、Business Unit 九個、Status 七個、Compliance Status 三個、Trend 三個、Risk Tier 四級 | `system_menus`（卡 ①）；Business Unit 用我們的部門樹 |
| **GRC Register** | 主帳，一條一筆 33 欄。五群：身分（編號／領域／類型／標題／部門／負責人／狀態／合規狀態）；風險計算（固有 1–25、控制有效性 %、剩餘＝固有×(1−有效性)、等級門檻 15／10／6）；議題（未結數／老化天數／嚴重度）；審查（審查日／距今／逾期・30 天內・正常）；指標與分數（預算曝險、控制覆蓋率、測試通過率、KRI 值／門檻／超標、加權分、健康指數、成熟度 1–5、升級旗標＝Critical 或 KRI 超標或狀態 Escalated） | 風險登錄 `grc.risks`（卡 ④）；議題群對應 POA&M；指標與分數群第二階段 |
| Domain Scorecard | 八個領域各一列：筆數、未結、升級、不合規、Critical 數、平均剩餘、平均健康、平均成熟度 | 儀表板「領域記分卡」區 |
| Business Unit View | 九個部門各一列：筆數、未結議題、平均剩餘、部分／不合規數、升級數、平均健康 | 儀表板「部門視圖」區；PM 說「點進去知道哪個部門」就是這頁 |
| Review Queue | 抽 Register 的審查欄排成清單 | 儀表板「審查佇列」區 |
| Risk Heatmap | 四張 KPI 卡＋五乘五格，每格數「固有風險落在該區間幾條」 | 儀表板「熱圖」區；點格列風險與負責人 |
| Trend | 按審查日月份排：筆數、Critical、不合規、升級、平均健康 | 儀表板「月趨勢」區 |
| **Dashboard** | 總覽：八張 KPI 卡（總數／Critical／不合規／未結／升級／逾期審查／平均健康／平均剩餘）、迷你熱圖、合規狀態分佈、各領域 Critical 數 | PM「做出這種感覺」的目標頁（卡 ⑦） |
兩個提醒：
- **範本沒存衝擊與可能性，只存乘積**，熱圖是用乘積反推格子。我們要存兩個原始值再算，格子才準。
- **健康指數、加權分、成熟度是範本自己發明的公式**，不是 GRC 標準。第一版儀表板只做件數與剩餘風險，不做合成分數，避免老闆問「這分數怎麼來」答不出。
### Excel 範本的骨架（目標畫面的資料需求）
主登錄表 `GRC Register` 33 欄，其中儀表板真正用到的：
| 欄 | 用途 | 我們有沒有 |
|---|---|---|
| Domain（Governance／Risk／Compliance／Audit／Cybersecurity／Privacy／Third Party／Operations） | 領域記分卡分組 | 沒有；進 `system_menus` |
| Category（Policy／Control／Risk／Issue／Obligation／KRI／Audit Finding／Vendor Oversight） | 登錄項目類型 | 沒有；進 `system_menus` |
| Business Unit、Owner | 部門視圖、點格列負責人 | 部門樹有、人有，**部門主管沒有** |
| Status、Compliance Status | 狀態分佈 | 專案層有、公司層沒有 |
| Inherent Risk、Control Effectiveness %、Residual Risk、Risk Tier | 風險矩陣、記分卡 | 專案 `ssp_risks` 有 impact／likelihood，**沒有控制有效性與剩餘風險** |
| Review Date、Days to Review、Review Alert | 審查佇列、逾期 | 沒有 |
| Open Issues、Issue Aging、Severity | 議題老化 | POA&M 有狀態與到期日，可對映 |
| KRI Value／Threshold／Breach | 關鍵風險指標 | 沒有（建議第二階段） |
| Maturity Score／Tier | 成熟度 | 沒有（建議第二階段） |
---
## 套進系統的接點：不只部門要調 {#touchpoints nav="接點"}
部門加主管只是起點，它的作用是「RACI 的 A 預設從哪來」。整條鏈五步，每步對應系統要動的地方：
| 步 | 要做到的事 | 動哪裡 | 既有／全新 |
|---|---|---|---|
| 1 | **事項要知道屬於哪個部門**。控制項現在只掛框架、SSP、專案，沒有部門概念 | 控制項加「負責部門」（控制項 × 部門對照，可按類別整批設）；風險登錄本來就有部門欄 | 既有改（D13） |
| 2 | **部門要有主管** | 部門表加主管欄、部門頁選人 | 既有改（D1） |
| 3 | **有地方填 RACI**，預設值由 1＋2 自動算：A＝負責部門主管、R＝任務處理人，人只改例外 | 新頁「責任矩陣」（主要填寫處，橫列控制項、直欄四格）；SSP 控制項實作頁加「責任」區塊；風險詳情加「責任」頁籤（預設繼承所綁控制項） | 全新 ＋ 兩處既有頁加區塊 |
| 4 | **有地方吃 RACI** | 總經理儀表板點格列 A；FR-145 結案報告加責任矩陣總表（不符合控制項 × 四格）＋每條明細印 A 與 R；建任務時 R 預帶處理人；A／R 在「我的待辦」看自己名下的風險與控制項（套 FR-132 部門範圍） | 儀表板全新；報告、任務、待辦既有改 |
| 5 | **字典與角色** | R／A／C／I、處置方式、風險等級、Domain／Category 進 `system_menus`；角色加「第幾線」標籤 | 既有機制加資料 |
「SSP 控制項實作頁加責任區塊」是指：顧問在專案 → SSP → 控制項實作 → 點開某一條控制項（例如 AC-2）那一頁，多一小塊顯示並可改這條的 R／A／C／I 四格。資料仍存 RACI 表，只是第二個入口：責任矩陣頁適合導入時整批填，控制項頁適合顧問做稽核時看到「這條其實是資訊部管」順手改。它與既有 OSCAL「責任方」並存：責任方是文件角色（system-owner 等），為 SSP 匯出符合 OSCAL 格式；RACI 是我們系統的真人與部門，為追責。
合計**既有要改六處**：部門表加主管、控制項加負責部門、SSP 控制項頁加責任區塊、FR-145 報告加責任節、任務建立預帶處理人、角色加標籤。**全新三樣**：RACI 表與責任矩陣頁、公司層風險登錄、GRC 儀表板。沒有第 1 步，責任矩陣頁每條都要手填，顧問不會用。
---
## PM 說法對照來源 {#pm-check nav="PM 對照"}
PM 的講法以 OCEG Red Book（pdftotext 全文）、Workiva 文章全文、Excel 範本欄位逐一核對，分三類。
**對的，照做**
| PM 說 | 來源 |
|---|---|
| 合規只是風險的一種 | OCEG、Workiva、ISO 31000 定義一致 |
| 組織架構要先進系統 | Red Book L2「內部環境」；市面平台一律以部門／業務單位為底層 |
| GRC 由上往下、我們由下往上補 | Red Book 順序：目標 → 風險 → 控制 → 檢查；平台只有後兩段 |
| 每條風險與控制要能追到負責人 | Red Book A5「設計」、P1「控制」要求明確責任人與當責者 |
**簡化了，實作時要補回**
| PM 說 | 來源怎麼說 | 對設計的影響 |
|---|---|---|
| GRC＝上帝視角保護會造成損失的東西 | Red Book 核心是「可靠地達成目標」（Principled Performance）；風險定義為「目標的不確定性」，包含機會 | 風險登錄加「關聯業務目標」欄（選填），否則登錄表會退化成問題清單 |
| 右上角先處理 | Red Book A4：排序除衝擊×可能性，還看風險胃納、控制有效性、發生速度 | 第一版五乘五可以；儀表板預設看「剩餘」不是「固有」 |
| R 我們從頭到尾沒做過 | 系統已有專案層 OSCAL 風險表與評估頁，缺的是**公司層**登錄 | 現況盤點已更正；專案風險可升級為公司風險 |
| 講 RACI 小弟就知道 | RACI 來自專案管理與 COBIT，Red Book 只要求「角色與責任明確」，沒指定用 RACI | 方向正確，但它是我們選的做法不是 GRC 規定；Excel 範本只有單一 Owner 欄 |
**PM 沒講、來源列為核心、本稿排第二階段**：政策文件生命週期（P2）、事件通報與調查（P6／P7）、意識訓練（P4）、供應商風險。Workiva 與市面平台都當核心功能。
---
## 現況盤點：底層都在，缺的是上面幾層 {#inventory nav="現況"}
::: {.callout .decided}
**結論：真正從零開始的只有「RACI 責任矩陣」與「公司層風險登錄」兩張表；其餘是加欄位、加頁面、串資料。**
:::
| 元件 | 現況（2026-10-19 查） | 本案動作 |
|---|---|---|
| 部門樹 `public.org_units` | jedi-iam 套件實作；`name／parent_id／path／description／metadata jsonb`；FE `views/org-unit/OrgUnitManage.vue`；人掛部門 `user_org_units`（含主要部門、起訖日） | **加「主管」**（D1 裁放法：欄位 vs metadata vs RACI 表） |
| 角色與權限 FR-132 | 三段式能力點、角色套用到部門範圍與起訖日、存取管理四頁已上線 v1.26.0 | 不動。「部門角色權限綁定」PM 說的缺口，實際 FR-132 已補；本案只補「主管」身分 |
| OSCAL 角色與責任方 | `oscal.roles` 種了 system-owner／system-security-officer／authorizing-official 等；`responsible_roles／responsible_parties` 是各 OSCAL 表的 jsonb 欄；資源庫與專案的 Party 面板（FR-135） | 保留當 SSP 文件的責任欄；**RACI 另立表**，不塞進 OSCAL jsonb（D2） |
| 專案參與者 `project_participants.role` | manager／auditor／viewer 單欄 | 不動 |
| 任務指派、FR-148 任務關卡 | 任務有處理人、每關可多人 | 不動；RACI 的 R 可預帶任務處理人（D3） |
| 專案層風險 `oscal.ssp_risks`（FR-135 R1） | 綁 SSP；`impact／likelihood`（facets）、`mitigating_factors／remediations／related_control_ids／threat_ids`、狀態五態、依據標準下拉；服務 `app/oscal/service/ssp_risk_app_service.py` | **保留**當專案內的風險；公司層風險登錄另立表並可「引用／升級」專案風險（D4） |
| 稽核結果風險 `oscal.assessment_risks`、FR-044 NOT MET 自動建中風險 | 稽核判定層的風險，掛 AR result 與 POA&M | 第 2 層的自動來源：NOT MET → 公司層風險一筆 |
| POA&M `compliance.poams` | `status／due_date／assignee_uid／org_unit_id` | 儀表板「議題老化」直接讀 |
| 資訊系統與設備（jedi-asset） | `information_systems.system_owner／org_unit_id`、安全目標 CIA 等級 | 風險登錄「資產」欄引用 |
| 結案報告 FR-145 | 一輪一份 Word／Excel | 第 1 層加「責任歸屬」一節 |
| 法規通報 FR-136 | 縮回 FR-135 第三期 | Category=Obligation 的來源之一，本案不碰 |
| 下拉字典 `system_menus` | 既有機制，FE `API.SYSTEM_MENU` | Domain／Category／Risk Tier／RACI 代碼全部進字典 |
| 專案儀表板、AI 儀表板 | 圖表元件已有 | 第 3 層複用元件 |
---
## 三層規劃 {#plan nav="規劃"}
```{.mermaid cap="圖 1 — 三層疊在既有合規平台上；箭頭是資料流向（下往上）"}
%%{init: {'theme':'base','themeVariables':{'primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86','secondaryColor':'#EEF2F3','secondaryTextColor':'#14201F','tertiaryColor':'#FBFCFC','tertiaryTextColor':'#14201F','lineColor':'#4A5A5C','textColor':'#14201F','mainBkg':'#E2F0F1','nodeBorder':'#0E7C86','nodeTextColor':'#14201F','edgeLabelBackground':'#FBFCFC','titleColor':'#14201F','clusterBkg':'#FBFCFC','clusterBorder':'#E4EAEB','actorBkg':'#E2F0F1','actorTextColor':'#14201F','actorBorder':'#0E7C86','actorLineColor':'#C7D1D2','signalColor':'#4A5A5C','signalTextColor':'#14201F','labelBoxBkgColor':'#EEF2F3','labelBoxBorderColor':'#C7D1D2','labelTextColor':'#14201F','loopTextColor':'#14201F','noteBkgColor':'#F6EBD5','noteTextColor':'#14201F','noteBorderColor':'#9C6B12','activationBkgColor':'#EEF2F3','activationBorderColor':'#C7D1D2','sequenceNumberColor':'#FFFFFF'}}}%%
flowchart BT
subgraph C[既有：Compliance（不動）]
FW[框架／控制項／AO]
SSP[專案 SSP＋專案風險 ssp_risks]
AR[稽核結果 NOT MET／POA&M]
RPT[結案報告]
end
subgraph L1[第 1 層 組織與責任]
OU[部門樹＋主管]
RACI[RACI 責任矩陣
對象：風險、控制項]
end
subgraph L2[第 2 層 公司層風險登錄]
RR[風險登錄表
領域／部門／負責人／固有／控制有效性／剩餘／審查日]
MX[五乘五矩陣]
end
subgraph L3[第 3 層 GRC 總覽]
DB[總經理儀表板
熱圖／記分卡／審查佇列／合規分佈]
DRILL[點格 → 負責主管清單]
end
FW --> RACI
OU --> RACI
AR -- NOT MET 自動建 --> RR
SSP -- 升級／引用 --> RR
RACI --> RR
RR --> MX --> DB
RACI --> DRILL
OU --> DRILL
AR --> DB
RACI --> RPT
```
### 第 1 層 組織與責任（G）
**1a 部門主管**：部門多一個「主管」（使用者），可選多位時第一位為主要。畫面：部門管理頁的編輯表單加「主管」選人；部門樹節點旁顯示主管姓名。資料放法見 D1。
**1b RACI 責任矩陣**：新表 `grc.responsibility_assignments`（schema 名見 D9）：
| 欄 | 說明 |
|---|---|
| `subject_type` | 對象種類：`risk`（公司層風險）／`control`（框架控制項）／`policy`（程序書，第二階段） |
| `subject_ref` | 對象識別：風險 uid、控制項識別碼＋框架版本 |
| `role_code` | `R`／`A`／`C`／`I`（字典 `grc_raci_role`） |
| `assignee_type`／`assignee_ref` | 人（user）或部門（org_unit）；A 限一人（RACI 慣例） |
| `tenant_id`／`org_unit_id` | 租戶隔離，照 RLS 慣例 |
畫面：新頁「責任矩陣」——左側選對象（風險列表／控制項樹），右側四格各選人或部門；也可從風險詳情、控制項詳情直接開「責任」頁籤編輯。批次：Excel 匯入（對象 × 四欄）。
**1c 結案報告責任歸屬**：FR-145 報告新增一節，兩部分：①**責任矩陣總表**——本次稽核所有不符合控制項為橫列，R／A／C／I 四欄填姓名與部門，老闆一頁看完誰扛哪幾條，依 A 分組排序；②每條不符合控制項的明細旁印 A 與 R。沒填 RACI 時退回印專案 manager，並在表尾註明「未指派」條數。
### 第 2 層 公司層風險登錄（R）
新模組（BE `app/risk_governance/`、DB schema `grc`、側選單「風險管理」；命名見 D9），不綁專案。表 `grc.risks`：
| 群 | 欄 |
|---|---|
| 識別 | 編號（`RISK-0001` 自動）、標題、描述、領域 Domain、類別 Category、**關聯業務目標**（選填文字，Red Book 定義風險為「目標的不確定性」）、來源（手填／稽核缺失／專案風險升級）、來源參照 |
| 歸屬 | 部門、負責人（A，同步寫 RACI）、相關資產（資訊系統／設備，選填）、相關控制項（多選）、相關專案（多選） |
| 評估 | 衝擊 1–5、可能性 1–5、固有風險＝衝擊×可能性、控制有效性 %、剩餘風險＝固有×(1−有效性)、風險等級（依門檻字典） |
| 處置 | 處置方式（接受／降低／轉移／避免）、處置計畫、目標日、狀態（open／monitoring／escalated／closed）、例外核准人（接受時必填） |
| 審查 | 下次審查日、審查週期、最近審查記錄（append） |
自動來源：
- **稽核 NOT MET**：FR-044／FR-142 判 NOT MET 時，已會建 `assessment_risks`；本案加一步「同步建或更新一筆公司層風險」，來源參照指回 AR 與 POA&M，POA&M 全部 closed 時公司層風險自動改 monitoring（D6 裁是否自動）。
- **專案風險升級**：`ssp_risks` 詳情加「升級為公司風險」按鈕，複製欄位、保留連結。
畫面：登錄表（列表＋篩選）、風險詳情（含 RACI 頁籤、關聯控制項、關聯專案、審查記錄）、五乘五矩陣（點格列風險）。
### 第 3 層 GRC 總覽儀表板
側選單「GRC 總覽」，只讀，照 Excel Dashboard 分頁六區：
| 區 | 資料來源 | 點擊 |
|---|---|---|
| KPI 卡：風險總數、重大風險、不合規數、未結議題、逾期審查、平均剩餘風險 | `grc.risks`、POA&M、稽核結果 | 跳對應列表 |
| 風險熱圖（固有或剩餘，可切） | `grc.risks` | **點格 → 清單：風險、部門、A 負責主管、狀態** |
| 領域記分卡 | `grc.risks` 依 Domain 彙總 | 跳登錄表篩該領域 |
| 部門視圖 | `grc.risks` 依部門彙總＋部門主管 | 跳部門篩選 |
| 合規狀態分佈 | 各專案最近一次稽核結果 MET／NOT MET／N/A 比例 | 跳專案 |
| 審查佇列 | `grc.risks.next_review_at` 逾期與 30 日內 | 跳風險詳情 |
權限：新能力點 `grc.dashboard.read`；預設給「稽核主管」與「系統管理員」角色，部門主管能否看自己那塊見 D7。
### 位階設計：一棵樹、一個標籤、一張對照表
決策者問「位階以系統面是不是要有設計、外面怎麼做」。市面平台（ServiceNow IRM、Archer、MetricStream）把位階拆成三件不同的事；我們**只用一棵樹解決三件事**，其餘兩件是掛在樹上的屬性，不另建結構。
| 位階 | 外面怎麼做 | 我們怎麼做 |
|---|---|---|
| **組織位階**（風險往上彙總） | 一棵「公司 → 事業群 → 部門」實體樹，風險掛底層節點，每層自動彙總，總經理看根節點逐層下鑽 | 既有 `org_units`（有 `path`）就是這棵樹；風險表加 `org_unit_id`，儀表板沿 `path` 加總。**唯一要畫出來的結構** |
| **責任位階**（三道防線） | 每個人站第幾線：一線業務、二線風險合規、三線內稽 | 角色加「第幾線」字典欄位，不是樹。稽核主管／稽核員＝三線、顧問／PM／合規人員＝二線、其餘預設一線。只在報表分組用 |
| **權限位階**（多大的風險誰能拍板） | 董事會定胃納，往下切容忍度；剩餘等級決定誰簽核才能「接受」或「關閉」，超限自動升級 | 一張四列對照表進字典，照部門樹**深度**算簽核人（下表）。這是 PM「老闆把人叫過來」的系統化版本：不是老闆去找，是系統把超過容忍的風險推到他待辦 |
**風險接受權責對照表（出廠預設，字典可改）**
| 風險等級 | 誰可以接受／關閉 | 系統算法 |
|---|---|---|
| 低 | 風險所屬部門的主管 | 取風險 `org_unit_id` 的主管 |
| 中 | 上一層單位的主管 | 沿 `path` 往上一層取主管 |
| 高 | 樹根（總經理） | 取 `path` 第一段的主管 |
| 重大 | 總經理＋另一位指定核准人 | 樹根主管＋字典指定的角色 |
::: {.callout .warn}
**三條邊界規則（第一版就寫進算法，不然做出來會卡）**
1. **自己簽自己**：部門主管同時是上層主管時，中風險會算到自己。規則是「往上找到**不同的人**為止」。
2. **樹不夠深**：小客戶只有「公司 → 部門」兩層，「上一層」會直接撞樹根。規則是「往上找，找不到就落到樹根」，不寫死層數。
3. **跨部門風險**：供應鏈中斷這種不屬任何部門。允許風險掛在父節點（事業群或公司層），簽核人就是那一層主管，不另設「跨部門」類型。
:::
### 未來不大改的保證：哪些現在定死、哪些留鉤子
決策者原話「我不希望補進去後未來要大改」。分兩類：
**現在就定對、以後不動**
| 設計 | 為什麼不會變 |
|---|---|
| 風險掛**組織節點**，不掛人 | 人會離職調動、節點不會；之後加任何結構，風險歸屬欄不用動 |
| 簽核人是**算出來**的，不存 | 每筆風險只存「誰核准、何時」這類事實；規則換了，舊資料不搬 |
| 「第幾線」是標籤欄位，不進關聯 | 要換分法改字典即可 |
| 風險登錄有 `source_type`／`source_ref` | 第二階段四塊（政策、供應商、事件、訓練）都是新的來源，純新增 |
**第一版留鉤子、不實作**
| 將來可能要的 | 第一版留什麼 | 將來怎麼加 |
|---|---|---|
| 矩陣式組織（一人兩主管、專案線與功能線） | `org_units` 加 `unit_type`（部門／事業群／委員會／專案組），第一版全填部門 | 同一棵樹多一種節點類型＋一張「人 × 節點 × 關係」表，不換樹 |
| 簽核規則變複雜（依領域、依金額） | 對照表多留 `condition` jsonb 欄 | 多填條件，不換表 |
| 風險胃納額度（每單位每年可接受總量） | 無 | 獨立新表「節點 × 期間 → 上限」，不碰既有 |
| 自動升級通知 | 待辦列表先做 | 掛既有通知機制（FR-137 條件通知） |
**真正會大改的只有一種情況**：簽核人存成固定值，或風險直接掛主管姓名。本設計兩者都不做。
### 拆卡草案（裁完 D 項再定）
| 卡 | 做什麼 | 層 | 規模 | 決策者先看到什麼 |
|---|---|---|---|---|
| ① | 字典種子：Domain／Category／Risk Tier／RACI 代碼／處置方式進 `system_menus` | 地基 | S | 無畫面，後續卡依賴 |
| ② | 部門主管：欄位＋API＋部門管理頁選人與顯示 | 1a | S | 部門頁能選主管 |
| ②b | 控制項負責部門：對照表＋API＋控制項頁選部門、按類別整批設；RACI 的 A 預設由此算 | 1b 前置 | S | 控制項頁多「負責部門」，責任矩陣頁 A 自動帶出 |
| ③ | RACI 表＋API＋責任矩陣頁（控制項對象） | 1b | M | 責任矩陣頁 |
| ④ | 公司層風險登錄：表、四層、CRUD、列表與詳情頁、矩陣頁 | 2 | L | 風險管理三頁 |
| ⑤ | 自動來源：NOT MET 建風險、專案風險升級 | 2 | M | 判一條 NOT MET 登錄多一筆 |
| ⑥ | 風險的 RACI 頁籤（對象 risk）＋ Excel 匯入 | 1b+2 | S | 風險詳情責任頁籤 |
| ⑦ | GRC 總覽儀表板 | 3 | L | 總覽頁 |
| ⑧ | 結案報告加責任歸屬節：責任矩陣總表＋每條明細印 A／R | 1c | S | 報告多一節，第一頁是誰扛哪幾條的總表 |
| ⑨ | 風險接受權責：對照表字典、簽核人算法（含三條邊界規則）、接受／關閉簽核、超限待辦 | 1+2 | M | 低風險主管可關、高風險被擋並出現在總經理待辦 |
| ⑩ | 角色「第幾線」標籤＋報表分組 | 1 | S | 角色頁多一欄 |
| ⑪ | SPEC 四頁＋手冊 | 文件 | S | spec-site |
排序以「決策者何時看到畫面」為準：② → ②b → ③ → ④ → ⑦（先用手填資料把儀表板撐起來）→ ⑨ → ⑤ → ⑥ → ⑧ → ⑩ → ⑪。
---
## 與 OCEG Red Book、市面平台的對照 {#market nav="市場對照"}
### OCEG GRC Capability Model v3.5 的 20 個元素
| 元件 | 元素 | 我們做完三層後 | 說明 |
|---|---|---|---|
| LEARN | L1 外部環境、L2 內部環境、L3 文化、L4 利害關係人 | L2 部分（部門、主管、資產） | L1／L3／L4 是顧問作業，不是軟體功能 |
| ALIGN | A1 方向、A2 目標、A3 識別、A4 分析、A5 設計 | **A3 識別、A4 分析（風險登錄）**；A5 設計（風險對控制項） | A1／A2（目標與策略）第二階段可加「目標」實體 |
| PERFORM | P1 控制、P2 政策、P3 溝通、P4 教育、P5 激勵、P6 通報、P7 調查、P8 回應 | P1 控制（既有）、P6 通報（FR-136 法規通報）、P8 回應（POA&M） | **P2 政策生命週期、P4 教育訓練、P7 事件調查**是最明顯缺口 |
| REVIEW | R1 監控、R2 保證、R3 改善 | R2 保證（稽核）、R3 改善（POA&M）、R1 部分（儀表板、審查日） | R1 的 KRI 持續監控第二階段 |
### 市面平台功能對照
| 功能模組 | Eramba | CISO Assistant | Drata／Vanta | ServiceNow IRM | 我們（三層做完） |
|---|---|---|---|---|---|
| 合規框架與控制項對映 | ✅ | ✅ 200+ 框架、控制跨框架複用 | ✅ | ✅ | ✅ 已有（框架、AO、SSP、稽核） |
| 稽核管理（計畫→執行→缺失→改善） | ✅ 內稽 | ✅ | 弱 | 中 | ✅ 已有，比多數強 |
| 風險登錄＋矩陣（固有／剩餘） | ✅ 自訂尺度 | ✅ 多方法（ISO 27005／EBIOS） | 基本 | ✅ | ✅ 第 2 層 |
| 責任／擁有者 | 單一 owner＋審查人 | 單一 owner | 單一 owner | 多角色 | ✅ **RACI 四格**（比多數細） |
| 組織架構＋部門視圖 | 部門 | 資料夾階層 | 弱 | ✅ | ✅ 第 1 層 |
| 高階儀表板 | ✅ | ✅ | ✅ | ✅ | ✅ 第 3 層 |
| **政策文件生命週期**（草稿→核准→發布→定期審查→版本） | ✅ | 部分 | ✅ | ✅ | ❌ 程序書池只有掛檔，無核准／審查週期 |
| **第三方／供應商風險** | ✅ | ✅ | 部分 | ✅ 強 | ❌ |
| **事件管理** | ✅ | ❌ | 弱 | ✅ | ❌（法規通報 FR-136 是對外通報，不是內部事件） |
| **資安意識訓練與追蹤** | ✅ | ❌ | ✅ | 部分 | ❌ |
| 帳號定期審查 | ✅ | ❌ | ✅ | ✅ | ❌（FR-132 有起訖日，無定期審查流程） |
| 業務持續計畫 BCP | ✅ | BIA | ❌ | ✅ | ❌ |
| KRI 持續監控 | 部分 | 部分 | ✅ 自動化測試 | ✅ | ❌ 第二階段 |
| 問卷／評估發送 | ✅ | ✅ | ✅ | ✅ | ✅ 已有（jedi-survey） |
| 資產盤點 | ✅ | ✅ | ✅ 自動 | ✅ CMDB | ✅ 已有（jedi-asset） |
| 自動證據收集 | ❌ | 部分 | ✅ 主打 | 部分 | 部分（檢測工具、證據分類、AO 證據來源） |
::: {.callout .warn}
**三層做完後還缺的四塊（建議列為第二階段，本案不做）**
1. **政策文件生命週期**：程序書池加「狀態（草稿／審核中／已發布／已過期）、核准人、生效日、下次審查日、版本」。這是 OCEG P2，也是 ISO 27001 稽核必問。
2. **第三方／供應商風險**：供應商登錄、問卷評估（可用 jedi-survey）、評等、連到風險登錄。
3. **事件管理**：內部資安事件登錄→調查→根因→連到風險與 POA&M；FR-136 法規通報變成它的「對外通報」步驟。
4. **資安意識訓練**：課程、名單、完成率；可先用任務機制代替。
四塊都能掛在第 2 層風險登錄底下（Category＝Policy／Vendor Oversight／Incident），資料模型預留 `source_type` 即可。
:::
### 參考來源
- OCEG《GRC Capability Model v3.5》Part II 元素清單（PM 提供 PDF）
- Workiva「什麼是 GRC」（PM 提供連結）
- [Help Net Security：CISO Assistant 介紹（2026-01）](https://www.helpnetsecurity.com/2026/01/14/ciso-assistant-open-source-cybersecurity-management-grc/)、[infosecflow 開源 GRC 比較（2026）](https://infosecflow.com/blog/open-source-grc-comparison/)
- [Eramba 官方學習中心模組清單](https://www.eramba.org/learning)、[thecybermatrix Eramba 模組總覽](https://thecybermatrix.com/eramba-open-source-governance-risk-compliance/)
- [vcso.ai 2026 GRC 工具比較](https://vcso.ai/learn/best-grc-tools-2026/)、[sprinto 2026 GRC 工具](https://sprinto.com/grc/tools/)
---
## 待決策 {#decisions nav="待裁"}
::: {.callout .pending}
**D1 部門「主管」放哪裡**
- **甲：`org_units` 加 `manager_user_id` 欄**——最直接，一個部門一位主管；jedi-iam 套件要改（套件 domain 的欄位，照規範在套件層改）。
- **乙：寫進 RACI 表**，對象＝部門、角色＝A——不改套件，但「主管」在部門頁要多一次查詢，且概念上部門主管不是「對某件事當責」。
- **丙：`org_units.metadata` jsonb 塞 `manager_uid`**——零 migration，但查不到、報表 join 不了。
**我的建議**：甲，並允許多位（`org_unit_managers` 子表，第一位主要）；儀表板「點格列主管」直接 join。
:::
::: {.callout .pending}
**D2 RACI 的對象是什麼**
- **甲：風險＋控制項**（本稿預設）——PM 原話「給了責任才能做控制項綁定、才能追責」，風險是儀表板要對人的單位。
- **乙：只有風險**——最省；控制項的負責人從風險推。但稽核缺失對到的是控制項，報告印負責人會對不上。
- **丙：風險＋控制項＋任務＋程序書**——一次到位，但任務已有處理人與關卡指派，重複。
**我的建議**：甲；程序書等第二階段政策生命週期時加。
:::
::: {.callout .pending}
**D3 RACI 四格要不要全填**
- **甲：A 必填、R 預帶、C／I 選填**——A 是儀表板要找的人；R 可從任務處理人或 POA&M 執行人預帶。
- **乙：四格全選填**——彈性但儀表板會有「沒人負責」的格。
**我的建議**：甲。A 限一人（RACI 慣例，追責才不會互推）。
:::
::: {.callout .pending}
**D4 公司層風險與專案層 `ssp_risks` 的關係**
- **甲：兩張表並存，專案風險可「升級」成公司風險**（本稿預設）——CRA 專案的風險評估是法規要求的文件內容，保持在 SSP 裡；公司層只收需要老闆看的。
- **乙：公司層就是唯一的風險表，SSP 風險改成引用**——單一真相，但 CRA SSP 匯出要跨表、且資源庫範本 SSP 的風險沒有租戶脈絡，改動大。
**我的建議**：甲。乙的收斂留到專案風險也要上儀表板時再談。
:::
::: {.callout .pending}
**D5 風險評估方法**
- **甲：固定五乘五，衝擊×可能性＝固有，固有×(1−控制有效性)＝剩餘**（Excel 範本的算法）——簡單、PM 看得懂。
- **乙：尺度可設定**（三乘三／五乘五、各格等級門檻進字典）——Eramba／CISO Assistant 都這樣做；多一頁設定。
**我的建議**：乙的「門檻進字典」＋甲的「固定五乘五」——尺度不開放，但等級門檻與顏色可調，成本接近甲。
:::
::: {.callout .pending}
**D6 稽核 NOT MET 自動建公司層風險，要不要全自動**
- **甲：全自動**——每條 NOT MET 一筆風險，POA&M 全關自動轉 monitoring。登錄表可能很多筆。
- **乙：半自動**——NOT MET 進「待納入」清單，稽核主管勾選才成為正式風險。
- **丙：以控制項歸併**——同一控制項多次 NOT MET 只更新同一筆風險。
**我的建議**：丙＋乙：按控制項歸併成一筆，先進待納入清單，稽核主管一鍵納入；避免老闆的儀表板被幾十條碎片淹沒。
:::
::: {.callout .pending}
**D7 GRC 儀表板給誰看**
- **甲：只給稽核主管與系統管理員**——最單純。
- **乙：部門主管看自己部門那塊**——FR-132 的部門範圍判定可直接套，列表自動縮到自己部門。
**我的建議**：乙，用既有部門範圍機制，不另寫邏輯；總經理角色拿全公司範圍。
:::
::: {.callout .pending}
**D8 Domain／Category 清單**
Excel 範本的八個 Domain 與八個 Category 直接當出廠預設種進 `system_menus`，客戶管理員可增刪。**我的建議**：照抄範本當預設，繁中譯名由 PM 定。
:::
::: {.callout .pending}
**D9 新模組落點與 schema 名**
- **甲：主專案新模組 `app/risk_governance/`、DB schema `grc`**——本專案獨有的業務，不急著套件化。模組名不能叫 `grc`：既有流程控管模組的對外 URL 前綴是 `/api/1.0/grc`、錯誤碼前綴 `GRC_*`（歷史命名，`config/app_modules.py:114` 註明），撞名會混。URL 用 `/api/1.0/risk-governance`，錯誤碼前綴 `RG_`。
- **乙：新 jedi 套件 `jedi-grc`**——照 jedi 套件切法，但首版還在摸欄位，套件化會拖慢。
**我的建議**：甲；欄位穩定後再抽套件（照 `feedback_jedi_package_extraction_pattern`）。
:::
::: {.callout .pending}
**D10 組織位階：風險沿部門樹往上彙總、儀表板逐層下鑽**
- **甲：做**——風險表加 `org_unit_id`（可掛任何層級節點），儀表板根節點彙總、點部門下鑽。
- **乙：不做彙總**，儀表板只列平面清單加部門篩選。
**我的建議**：甲。`path` 已經有，彙總是一句 SQL；這是「總經理視角」的核心。
:::
::: {.callout .pending}
**D11 三道防線標籤**
- **甲：角色加「第幾線」字典欄位**，出廠預設稽核主管／稽核員＝三線、顧問／PM＝二線、其餘一線；報表與儀表板可依線分組。
- **乙：第一版不做**。
**我的建議**：甲。成本一個欄位，但顧問做 ISO 27001／CRA 稽核報告時「三道防線」是標準章節。
:::
::: {.callout .pending}
**D12 風險接受權責與超限升級**
- **甲：第一版做簽核＋待辦**——對照表進字典（照上表預設），處置選「接受」或狀態改「關閉」時依樹算簽核人，不是本人就擋下並進該主管待辦；含三條邊界規則。不做自動通知（掛第二階段）。
- **乙：第一版只做前兩項（彙總、標籤），簽核留第二階段**。
- **丙：甲＋自動通知**。
**我的建議**：甲。少了它 G 只是標籤；自動通知等 FR-137 條件通知機制穩定後掛上去即可。
:::
::: {.callout .pending}
**D13 控制項要不要有「負責部門」**
RACI 的 A 預設要能自動算（負責部門的主管），控制項就得先知道自己屬於哪個部門。
- **甲：加「控制項 × 部門」對照表**，可按控制項類別（family）整批指定，個別控制項可覆寫。責任矩陣頁開出來 A 已預填，人只改例外。
- **乙：不加，每條控制項在責任矩陣頁手填 A**。少一張表，但一套框架上百條控制項，顧問要一條條點。
- **丙：用 SSP 的 responsible_roles jsonb 推**。不加表，但那是 OSCAL 文件角色不是部門，對不到主管。
**我的建議**：甲。這是「部門主管」有用的前提，沒有它主管欄只是顯示用。
:::
::: {.callout .pending}
**D14 第一版範圍：完整三層，還是「找頭兒」最小版**
決策者 2026-10-19 複述的需求：「公司要過 ISO 27001，報告顯示這麼多沒過，所以有風險；我要透過儀表板看出找誰來處理、找頭兒。」這個場景的資料鏈是：稽核 NOT MET 的控制項 → 控制項的負責部門 → 部門主管。不需要獨立的風險登錄，也不需要人評分。
- **甲：最小版，四張卡**——部門加主管（②）、控制項負責部門（②b）、責任矩陣頁只開 A／R 兩格（③ 縮）、儀表板直接讀稽核缺失與 POA&M 做統計與責任矩陣總表（⑦ 縮）。熱圖的嚴重度軸用 POA&M 逾期天數或控制項優先級代替評分。評分、獨立風險登錄、C／I、簽核升級、自動來源全往第二版排。
- **乙：完整三層，十二張卡**——照本稿原規劃。
甲產得出：數字卡、部門統計與主管、責任矩陣總表、點進去叫人、結案報告責任節。甲產不出：真正的衝擊×可能性熱圖（PM 說的 R），以及稽核抓不到的風險（供應商倒閉這類）。
**我的建議**：甲。先把「找頭兒」這條線做通讓決策者與 PM 看到畫面，再決定 R 要做到多深。資料表照乙設計（RACI 表四格、`grc.risks` 欄位齊），畫面只開甲的範圍，第二版加頁不改表。
:::
---
## 不做什麼 {#out-of-scope nav="不做"}
- 政策文件生命週期、供應商風險、事件管理、意識訓練、KRI、成熟度評分：第二階段。
- 不改 FR-132 權限模型、不改 BPMN 流程、不動 SSP 匯出。
- 不內建風險／威脅庫（延續 FR-135 D17：系統不是有公信力的單位）。
- 不做財務化風險（FAIR）。
- 不做矩陣式組織（第二棵樹）、風險胃納額度制、自動升級通知：留鉤子，見「未來不大改的保證」。
## 下一步 {#next nav="下一步"}
1. 決策者裁 D1～D14（D14 先裁，決定第一版是四張卡還是十二張）。
2. 首腦刻雛形：部門頁主管欄、責任矩陣頁、風險登錄三頁、GRC 總覽頁（假資料，照 Excel 範本與設計系統）。
3. 雛形審過 → design.md → 開 Notion 母子卡 → 派工 prompt。