FR-151 · 一、需求 · 02 領域知識

領域知識:讀本站會碰到的名詞,每個一句白話

給非工程讀者;每個名詞都標「在我們系統對應什麼」

GRC 三個字各是什麼、RACI 四格怎麼讀(含 I 到底是誰)、風險怎麼評分、三道防線是什麼。看不懂規劃頁的名詞回來查這頁。

GRC 三字 RACI 四格 風險評分
§1

變更紀錄

日期 變更
2026-10-19 KRI 改水位線白話版;加供應商清單、事件紀錄兩條;「登錄」改「總表」
2026-10-19 自 discussion.md v4「GRC 入門」「RACI 怎麼讀」兩節搬出成頁;RACI 補 I 的 CRA 例子與判斷法

§2

GRC 三個字

GRC 是老闆用上帝視角看公司:哪裡會造成損失(R)、誰負責管(G)、哪些法規非守不可(C)。三件事用同一套資料看。

字 白話 在 Guidant AI 對應
G 治理 Governance 誰負責什麼、誰有權拍板、沒做好怎麼追。長期、策略層 部門主管、RACI 責任矩陣、第二版的風險接受權責
R 風險 Risk 會造成損失的事,各自多可能發生、發生多嚴重、現在控得住嗎 第二版公司層風險總表、五乘五矩陣
C 合規 Compliance 要滿足哪些法規、框架、合約才能營運或賣產品;日常、操作層 既有整套:框架、SSP、稽核、POA&M

合規是風險的一種:不合規的後果是罰款、不能賣、失去客戶,所以每條沒過的控制項都是一筆風險。這是「稽核 NOT MET 自動餵進風險總表」的理論基礎。

我們的位置:PM 原話「我們是從下面做上來,現在要慢慢補回最上面的上帝視角」。平台強在 C,G 有一半(部門、角色都有,但沒有「主管是誰」與責任矩陣),R 只有專案內一張風險表,公司層沒有。


§3

RACI 四格

RACI 用來回答「這件事到底誰負責」。一件事(一條控制項、一條風險)填四格:

字母 白話 人數 CEO 問責時
R Responsible 動手做的人:實際執行、交出結果 可多人 「做到哪了」問他
A Accountable 拍板與扛責的人:核准結果、出事找他 只能一人 儀表板點進去要秀的就是他
C Consulted 做之前要問過的人:雙向,意見要納入 可多人、可空 不問責
I Informed 做完要告知的人:單向,知道就好 可多人、可空 不問責

I 到底是誰(最常被問)

I 不是「出事通知誰」,是「這件事有進展或做完時,要讓他知道一下」的人。他不做、不被問,但做完他不知道會出包。

用 CRA 舉例:附件一「產品要有漏洞揭露與通報流程」這條判沒過。

格 誰 為什麼
R 產品安全工程師 要寫流程、架通報信箱
A 產品部主管 稽核沒過老闆找他
C 法務 通報期限 24 小時是法規要求,流程寫之前要法務確認
I 客服部、業務部 流程上線後客戶問「我發現漏洞要寄哪」他們要答得出來

流程改好、控制項從 NOT MET 變 MET 時:R 做完了、A 的部門沒過數少一條、C 的意見已納入、I 收到一封通知「流程已更新,客戶回報請導向 security@ 信箱」。

白話判斷法:這個人不做也不問,但做完他不知道會出包 → I;這個人的意見沒納入會出包 → C。

三個常見誤解

  • A 不是「最大的主管」,是「這件事出問題該找的那一個人」。同一位部門主管可以是十條控制項的 A,也可以某條的 A 是他底下的課長。
  • R 與 A 可以是同一人(小公司常見),但 A 仍只能一人,否則追責時互推。
  • PM 給的 Excel 範本只有一個 Owner 欄,等於只有 A。做四格比範本細。

在我們系統裡 RACI 掛在哪

掛在專案 SSP 的每條控制項實作上。A 由「控制項負責部門的主管」自動算出,R 預帶該控制項任務的處理人,C 與 I 人填。詳見 07 第一版規劃。


§4

風險評分

名詞 白話 在系統對應
固有風險 Inherent 什麼都不做時的風險=衝擊 × 可能性 風險總表「固有」欄(第二版)
控制有效性 現有控制措施擋掉幾成 風險總表欄(第二版)
剩餘風險 Residual 做了控制之後還剩多少=固有 × (1 − 控制有效性) 儀表板熱圖預設看這個
風險矩陣/熱圖 橫軸可能性、縱軸衝擊的五乘五格子,右上角最危險 第二版儀表板;PM 說「老闆從右上往左下處理」
風險處置四式 接受(不處理、簽名負責)、降低(加控制)、轉移(保險、外包)、避免(不做那件事) 風險總表「處置」欄;「接受」要簽核
風險胃納/容忍 公司整體願意承擔多大(胃納)、各部門可以放任多大(容忍)。超過容忍要往上報 第二版「超過等級要上層簽核」
升級 Escalation 風險超過某人的權限,自動推到上一層的人桌上 第二版簽核待辦
KRI 關鍵風險指標 Key Risk Indicator。水位線:替某個風險挑一個系統能自己數的數字(到期沒關的改善項幾件、離職帳號沒停用幾個),劃一條警戒線,超過就在那筆風險旁亮燈。水位每天自己量,警戒線設一次。價值是老闆不靠人回頭改分數也看得到惡化;不會發現新風險 不在計畫內,總表留「指標狀態」欄接口。要有幾個月資料才知道線該劃哪
供應商清單 像設備資料:一家一筆、問卷分數、合約到期、有無備援。評分差的自動進風險總表 不在計畫內,總表「來源」欄留接口
事件紀錄 像 log:發生一次記一筆。讓既有風險的可能性往上修 不在計畫內,總表留「關聯事件」欄接口

第一版沒有評分。第一版儀表板只能按「沒過幾條」排,分不出「沒過的那條嚴重不嚴重」。這是第二版存在的理由。


§5

其他會碰到的名詞

名詞 白話 在系統對應
OCEG 發明 GRC 這個詞的非營利組織,出的《GRC Capability Model》(Red Book)是教科書 06 外部對照用它的 20 個元素當尺
LEARN/ALIGN/PERFORM/REVIEW Red Book 四大步:了解環境 → 定目標並找出風險 → 做控制 → 回頭檢查 我們強在 PERFORM 與 REVIEW,弱在 ALIGN 的風險識別
三道防線 一線:業務部門自己管自己的風險;二線:風險與合規職能訂規則、監督;三線:內部稽核獨立查證 不做。IIA 治理模型,ISO/CRA 皆未要求
政策/程序 政策是「我們要怎樣」,程序是「具體步驟」 某些框架的控制項(CRA.II.5 揭露政策),程序書掛證據即可;「誰核准、何時過期」屬證據有效期小需求,不在本案
登錄表 Register 一種東西一本帳;本站把風險的那本叫「風險總表」 Excel 範本的 GRC Register 就是一本混合登錄
框架群組 OSCAL 格式規定控制項按章節分群,如 CRA 的「附件一第二部分 漏洞處理」16 條 已有,存 oscal.catalog_groups;第一版拿它當「整批設部門」的單位
OSCAL 責任方 SSP 文件格式裡的角色(system-owner 等),為匯出文件合規而存在 不是部門也不是真人,不能拿來當 RACI