---
title: "02 領域知識 — GRC、RACI、風險評分白話版 (FR-151)"
brand: "Guidant AI · **FR-151** GRC 延伸"
eyebrow: "FR-151 · 一、需求 · 02 領域知識"
h1: "領域知識：讀本站會碰到的名詞，每個一句白話"
subtitle: "給非工程讀者；每個名詞都標「在我們系統對應什麼」"
lede: "GRC 三個字各是什麼、RACI 四格怎麼讀（含 I 到底是誰）、風險怎麼評分、三道防線是什麼。看不懂規劃頁的名詞回來查這頁。"
chips: [
  {text: "GRC 三字", kind: accent},
  {text: "RACI 四格", kind: accent},
  {text: "風險評分", kind: accent}
]
footer: "FR-151 · 一、需求 · 02 領域知識 · 依據：OCEG Red Book v3.5、Workiva、ISO 31000"
---

## 變更紀錄 {#changelog nav="變更紀錄"}

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

---

## GRC 三個字 {#grc nav="GRC"}

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

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

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

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

---

## RACI 四格 {#raci nav="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 第一版規劃](../3-plan/07-phase1-organization-responsibility.md)。

---

## 風險評分 {#risk-scoring nav="風險評分"}

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

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

---

## 其他會碰到的名詞 {#misc nav="其他"}

| 名詞 | 白話 | 在系統對應 |
|---|---|---|
| **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** |