FR-151 · 討論稿 · 2026-10-19

從 Compliance 往上補成 GRC:組織與責任、公司層風險、總經理儀表板

底層都在,是補強不是重做;三層由下往上疊,每層可單獨上線

平台目前只有 GRC 的 C。PM 2026-10-19 定調:先把組織架構+責任矩陣(RACI)補齊,再補風險評估(R),最後做出總經理一眼看懂的 GRC 儀表板(以 PM 給的 Excel 範本為目標畫面)。本稿盤點既有底層(部門樹、角色、OSCAL 責任方、專案層風險表、POA&M)與缺口,提出三層規劃與拆卡,並對照 OCEG Red Book 與市面平台列出我們還缺什麼;位階設計採「一棵樹、一個標籤、一張對照表」,附未來不大改的鉤子表。D1~D14 待決策者裁。

三層:組織與責任 → 風險登錄 → GRC 儀表板 從零只有兩樣:RACI 表、公司層風險登錄 D1~D14 待裁 雛形待 D 項裁後刻

本頁為 2026-10-19 單頁討論稿 v4 的歷史版本,唯讀。 內容已重組為多頁站(需求/分析與決策/規劃),且「不做 RACI」等結論已被決策者推翻。請以站內新頁為準,本頁只供追溯當時推理。

狀態:討論稿(待裁 D1~D14;裁完刻雛形,雛形審過落 design.md) | 日期:2026-10-19 | 會議記錄:meeting-2026-10-19.md

路徑慣例:BE 路徑相對 compliance-manager-be/;pkg/ 代表 ~/Projects/Jedicogy/module/jedi-python-package/;FE 路徑相對 compliance-manager-fe/。

§1

變更紀錄

日期 變更 對應
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(控制項負責部門) 決策者提問

§2

分工概述(30 秒版)

整案一句話:在現有合規平台上面疊三層——部門有主管、風險與控制項有 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(風險接受權責)決定資料模型。


§3

給非工程讀者的 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 是四個英文字的縮寫,用來回答「這件事到底誰負責」。一件事(一條風險、一個控制項、一份政策)填四格:

字母 英文 白話 人數規則 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 裁對象與必填規則。

§4

需求背景

PM 2026-10-19 會議(完整整理見 會議記錄)交付三份資料:OCEG《GRC Capability Model v3.5》(Red Book)、《GRC Overview Dashboard.xlsx》範本、Workiva 入門文章。定調三件事:

  1. 目標畫面:「我們最終的目標就是做出這種感覺」——指 Excel 範本的 Dashboard 分頁(KPI 卡、風險熱圖、合規狀態分佈、部門記分卡、審查佇列)。
  2. CEO 的兩個動作:看哪個環節風險高;點進去知道哪個部門的哪個主管負責,把人叫過來問「處理了嗎、什麼時候完成」。
  3. 要補的兩塊:組織架構(部門、主管、核心人物)+責任矩陣 RACI;風險評估(怎麼評、誰負責、綁哪些控制項)。

找到人、給他責任了,這時候就可以做後面所有控制項的綁定,然後我也可以追責。 — PM(08:40)

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 成熟度 沒有(建議第二階段)

§5

套進系統的接點:不只部門要調

部門加主管只是起點,它的作用是「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 步,責任矩陣頁每條都要手填,顧問不會用。


§6

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 與市面平台都當核心功能。


§7

現況盤點:底層都在,缺的是上面幾層

結論:真正從零開始的只有「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 層複用元件

§8

三層規劃

%%{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 責任矩陣<br/>對象:風險、控制項]
  end
  subgraph L2[第 2 層 公司層風險登錄]
    RR[風險登錄表<br/>領域/部門/負責人/固有/控制有效性/剩餘/審查日]
    MX[五乘五矩陣]
  end
  subgraph L3[第 3 層 GRC 總覽]
    DB[總經理儀表板<br/>熱圖/記分卡/審查佇列/合規分佈]
    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 — 三層疊在既有合規平台上;箭頭是資料流向(下往上)

第 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 第一段的主管
重大 總經理+另一位指定核准人 樹根主管+字典指定的角色

三條邊界規則(第一版就寫進算法,不然做出來會卡)

  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 → ③ → ④ → ⑦(先用手填資料把儀表板撐起來)→ ⑨ → ⑤ → ⑥ → ⑧ → ⑩ → ⑪。


§9

與 OCEG Red Book、市面平台的對照

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 證據來源)

三層做完後還缺的四塊(建議列為第二階段,本案不做)

  1. 政策文件生命週期:程序書池加「狀態(草稿/審核中/已發布/已過期)、核准人、生效日、下次審查日、版本」。這是 OCEG P2,也是 ISO 27001 稽核必問。
  2. 第三方/供應商風險:供應商登錄、問卷評估(可用 jedi-survey)、評等、連到風險登錄。
  3. 事件管理:內部資安事件登錄→調查→根因→連到風險與 POA&M;FR-136 法規通報變成它的「對外通報」步驟。
  4. 資安意識訓練:課程、名單、完成率;可先用任務機制代替。

四塊都能掛在第 2 層風險登錄底下(Category=Policy/Vendor Oversight/Incident),資料模型預留 source_type 即可。

參考來源


§10

待決策

D1 部門「主管」放哪裡

  • 甲:org_units 加 manager_user_id 欄——最直接,一個部門一位主管;jedi-iam 套件要改(套件 domain 的欄位,照規範在套件層改)。
  • 乙:寫進 RACI 表,對象=部門、角色=A——不改套件,但「主管」在部門頁要多一次查詢,且概念上部門主管不是「對某件事當責」。
  • 丙:org_units.metadata jsonb 塞 manager_uid——零 migration,但查不到、報表 join 不了。

我的建議:甲,並允許多位(org_unit_managers 子表,第一位主要);儀表板「點格列主管」直接 join。

D2 RACI 的對象是什麼

  • 甲:風險+控制項(本稿預設)——PM 原話「給了責任才能做控制項綁定、才能追責」,風險是儀表板要對人的單位。
  • 乙:只有風險——最省;控制項的負責人從風險推。但稽核缺失對到的是控制項,報告印負責人會對不上。
  • 丙:風險+控制項+任務+程序書——一次到位,但任務已有處理人與關卡指派,重複。

我的建議:甲;程序書等第二階段政策生命週期時加。

D3 RACI 四格要不要全填

  • 甲:A 必填、R 預帶、C/I 選填——A 是儀表板要找的人;R 可從任務處理人或 POA&M 執行人預帶。
  • 乙:四格全選填——彈性但儀表板會有「沒人負責」的格。

我的建議:甲。A 限一人(RACI 慣例,追責才不會互推)。

D4 公司層風險與專案層 ssp_risks 的關係

  • 甲:兩張表並存,專案風險可「升級」成公司風險(本稿預設)——CRA 專案的風險評估是法規要求的文件內容,保持在 SSP 裡;公司層只收需要老闆看的。
  • 乙:公司層就是唯一的風險表,SSP 風險改成引用——單一真相,但 CRA SSP 匯出要跨表、且資源庫範本 SSP 的風險沒有租戶脈絡,改動大。

我的建議:甲。乙的收斂留到專案風險也要上儀表板時再談。

D5 風險評估方法

  • 甲:固定五乘五,衝擊×可能性=固有,固有×(1−控制有效性)=剩餘(Excel 範本的算法)——簡單、PM 看得懂。
  • 乙:尺度可設定(三乘三/五乘五、各格等級門檻進字典)——Eramba/CISO Assistant 都這樣做;多一頁設定。

我的建議:乙的「門檻進字典」+甲的「固定五乘五」——尺度不開放,但等級門檻與顏色可調,成本接近甲。

D6 稽核 NOT MET 自動建公司層風險,要不要全自動

  • 甲:全自動——每條 NOT MET 一筆風險,POA&M 全關自動轉 monitoring。登錄表可能很多筆。
  • 乙:半自動——NOT MET 進「待納入」清單,稽核主管勾選才成為正式風險。
  • 丙:以控制項歸併——同一控制項多次 NOT MET 只更新同一筆風險。

我的建議:丙+乙:按控制項歸併成一筆,先進待納入清單,稽核主管一鍵納入;避免老闆的儀表板被幾十條碎片淹沒。

D7 GRC 儀表板給誰看

  • 甲:只給稽核主管與系統管理員——最單純。
  • 乙:部門主管看自己部門那塊——FR-132 的部門範圍判定可直接套,列表自動縮到自己部門。

我的建議:乙,用既有部門範圍機制,不另寫邏輯;總經理角色拿全公司範圍。

D8 Domain/Category 清單

Excel 範本的八個 Domain 與八個 Category 直接當出廠預設種進 system_menus,客戶管理員可增刪。我的建議:照抄範本當預設,繁中譯名由 PM 定。

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)。

D10 組織位階:風險沿部門樹往上彙總、儀表板逐層下鑽

  • 甲:做——風險表加 org_unit_id(可掛任何層級節點),儀表板根節點彙總、點部門下鑽。
  • 乙:不做彙總,儀表板只列平面清單加部門篩選。

我的建議:甲。path 已經有,彙總是一句 SQL;這是「總經理視角」的核心。

D11 三道防線標籤

  • 甲:角色加「第幾線」字典欄位,出廠預設稽核主管/稽核員=三線、顧問/PM=二線、其餘一線;報表與儀表板可依線分組。
  • 乙:第一版不做。

我的建議:甲。成本一個欄位,但顧問做 ISO 27001/CRA 稽核報告時「三道防線」是標準章節。

D12 風險接受權責與超限升級

  • 甲:第一版做簽核+待辦——對照表進字典(照上表預設),處置選「接受」或狀態改「關閉」時依樹算簽核人,不是本人就擋下並進該主管待辦;含三條邊界規則。不做自動通知(掛第二階段)。
  • 乙:第一版只做前兩項(彙總、標籤),簽核留第二階段。
  • 丙:甲+自動通知。

我的建議:甲。少了它 G 只是標籤;自動通知等 FR-137 條件通知機制穩定後掛上去即可。

D13 控制項要不要有「負責部門」

RACI 的 A 預設要能自動算(負責部門的主管),控制項就得先知道自己屬於哪個部門。

  • 甲:加「控制項 × 部門」對照表,可按控制項類別(family)整批指定,個別控制項可覆寫。責任矩陣頁開出來 A 已預填,人只改例外。
  • 乙:不加,每條控制項在責任矩陣頁手填 A。少一張表,但一套框架上百條控制項,顧問要一條條點。
  • 丙:用 SSP 的 responsible_roles jsonb 推。不加表,但那是 OSCAL 文件角色不是部門,對不到主管。

我的建議:甲。這是「部門主管」有用的前提,沒有它主管欄只是顯示用。

D14 第一版範圍:完整三層,還是「找頭兒」最小版

決策者 2026-10-19 複述的需求:「公司要過 ISO 27001,報告顯示這麼多沒過,所以有風險;我要透過儀表板看出找誰來處理、找頭兒。」這個場景的資料鏈是:稽核 NOT MET 的控制項 → 控制項的負責部門 → 部門主管。不需要獨立的風險登錄,也不需要人評分。

  • 甲:最小版,四張卡——部門加主管(②)、控制項負責部門(②b)、責任矩陣頁只開 A/R 兩格(③ 縮)、儀表板直接讀稽核缺失與 POA&M 做統計與責任矩陣總表(⑦ 縮)。熱圖的嚴重度軸用 POA&M 逾期天數或控制項優先級代替評分。評分、獨立風險登錄、C/I、簽核升級、自動來源全往第二版排。
  • 乙:完整三層,十二張卡——照本稿原規劃。

甲產得出:數字卡、部門統計與主管、責任矩陣總表、點進去叫人、結案報告責任節。甲產不出:真正的衝擊×可能性熱圖(PM 說的 R),以及稽核抓不到的風險(供應商倒閉這類)。

我的建議:甲。先把「找頭兒」這條線做通讓決策者與 PM 看到畫面,再決定 R 要做到多深。資料表照乙設計(RACI 表四格、grc.risks 欄位齊),畫面只開甲的範圍,第二版加頁不改表。


§11

不做什麼

  • 政策文件生命週期、供應商風險、事件管理、意識訓練、KRI、成熟度評分:第二階段。
  • 不改 FR-132 權限模型、不改 BPMN 流程、不動 SSP 匯出。
  • 不內建風險/威脅庫(延續 FR-135 D17:系統不是有公信力的單位)。
  • 不做財務化風險(FAIR)。
  • 不做矩陣式組織(第二棵樹)、風險胃納額度制、自動升級通知:留鉤子,見「未來不大改的保證」。
§12

下一步

  1. 決策者裁 D1~D14(D14 先裁,決定第一版是四張卡還是十二張)。
  2. 首腦刻雛形:部門頁主管欄、責任矩陣頁、風險登錄三頁、GRC 總覽頁(假資料,照 Excel 範本與設計系統)。
  3. 雛形審過 → design.md → 開 Notion 母子卡 → 派工 prompt。
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 查)