---
title: "01 需求背景 — 為什麼要做 GRC 延伸 (FR-151)"
brand: "Guidant AI · **FR-151** GRC 延伸"
eyebrow: "FR-151 · 一、需求 · 01 需求背景"
h1: "需求背景：老闆要在一頁看出「哪個部門幾條沒過、找哪位主管」"
subtitle: "平台只有 GRC 的 C，要往上補 G 與 R"
lede: "一句話需求、為什麼非做不可、誰會用、PM 的說法哪些已驗哪些待驗。看完這頁再看 02 領域知識與 03 使用情境。"
chips: [
  {text: "需求來源：PM 會議 2026-10-19", kind: accent},
  {text: "第一版：找頭兒", kind: ok},
  {text: "PM 說法：4 條已驗、4 條待驗", kind: warn}
]
footer: "FR-151 · 一、需求 · 01 需求背景 · 來源：meeting-2026-10-19.md、PM 交付三份資料"
---

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

| 日期 | 變更 |
|---|---|
| 2026-10-19 | 自 discussion.md v4 重組為多頁站，本頁為需求背景；加「誰會用」「PM 說法已驗／待驗」 |

---

## 一句話需求 {#one-liner nav="一句話"}

::: {.callout .decided}
**公司要過 ISO 27001 或 CRA，稽核報告顯示很多控制項沒過。老闆要在一頁儀表板看出「哪個部門幾條沒過、要找哪位主管」，把人叫來問進度。**
:::

這是決策者 2026-10-19 複述並由 PM 確認的版本。PM 原話是「用上帝視角看公司，任何會造成損失的東西都要保護它、管它、找得到人負責」。兩句的差別：PM 講的是整個 GRC 的理想，決策者講的是第一版要做到的那一條線。

---

## 為什麼要做 {#why nav="為什麼"}

**今天的痛點**：稽核結束後，顧問交出一份一百多條控制項的結案報告。老闆拿到報告只能自己翻、自己猜哪條該找誰。系統知道「哪條沒過」，但不知道「這條歸哪個部門、部門主管是誰」，所以沒辦法替老闆把人對上。

**不做會怎樣**：平台停在「合規工具」的位階，使用者是顧問與承辦。老闆不會打開它，因為裡面沒有他要的東西。PM 的判斷是市面 GRC 平台的賣點就在最上面那一頁，我們底層比多數對手強，缺的是上面。

**做了會怎樣**：老闆一頁看到部門 × 沒過數 × 主管，點進去是哪幾條、誰承辦、做到哪。結案報告第一頁多一張「誰扛哪幾條」總表，直接給董事會看。

---

## 本案補的兩個大類 {#categories nav="兩大類"}

| 大類 | 拿來幹嘛 | 一句話 |
|---|---|---|
| **G 責任歸屬** | 每條控制項、每筆風險都對得到部門與主管，老闆叫得到人 | 找頭兒 |
| **R 風險管理** | 老闆在意的事情總表：多嚴重、誰負責、控得住嗎；合規沒過自動進表 | 總表加排序 |

**C 合規不做**：平台本來就是 C（框架、控制項、證據、稽核、POA&M）。市面平台的「政策生命週期」「意識訓練」「三道防線」模組，前兩者在我們這是某些框架的控制項（CMMC AT.L2-3.2.2 訓練、CRA.II.5 揭露政策），證據掛上去即可；三道防線無任何框架要求。唯一小缺口是證據沒有有效期欄，另列獨立小需求。

---

## 誰會用、各自要什麼 {#stakeholders nav="誰會用"}

| 角色 | 在這件事裡做什麼 | 要的畫面 |
|---|---|---|
| **總經理／CEO** | 看結果、叫人 | GRC 總覽一頁：部門幾條沒過、主管是誰、點進去列清單 |
| **部門主管** | 被叫到之後回去追承辦 | 看自己部門（含子部門）沒過的控制項與承辦人 |
| **顧問** | 導入時設定部門主管、控制項分部門、填責任矩陣；稽核時順手改 | SSP 內的責任矩陣頁籤、單條控制項的責任區塊 |
| **稽核主管** | 看全公司、下載結案報告 | 總覽頁全範圖、報告責任歸屬節 |
| **承辦人（R）** | 不變，照既有任務做事 | 無新畫面 |
| **系統管理員** | 維護部門與主管 | 部門管理頁的主管欄 |

---

## PM 說法對照來源 {#pm-check nav="PM 對照"}

PM 的講法以 OCEG Red Book 全文、Workiva 文章、Excel 範本欄位逐一核對。**標「待驗」的要去問顧問或客戶真實作法，不能從會議紀錄直接當需求。**

**對的，照做**

| PM 說 | 來源 | 狀態 |
|---|---|---|
| 合規只是風險的一種 | OCEG、Workiva、ISO 31000 定義一致 | 已驗 |
| 組織架構要先進系統 | Red Book L2「內部環境」；市面平台一律以部門為底層 | 已驗 |
| GRC 由上往下、我們由下往上補 | Red Book 順序：目標 → 風險 → 控制 → 檢查；平台只有後兩段 | 已驗 |
| 每條風險與控制要能追到負責人 | Red Book A5「設計」、P1「控制」要求明確當責者 | 已驗 |

**簡化了，實作時要補回**

| PM 說 | 來源怎麼說 | 對設計的影響 | 狀態 |
|---|---|---|---|
| GRC＝上帝視角保護會造成損失的東西 | Red Book 核心是「可靠地達成目標」，風險包含機會 | 風險總表加「關聯業務目標」選填欄 | 已驗 |
| 右上角先處理 | Red Book A4：排序還看風險胃納、控制有效性、發生速度 | 五乘五可以；儀表板預設看「剩餘」不是「固有」 | 已驗 |
| R 我們從頭到尾沒做過 | 系統已有專案層 OSCAL 風險表與評估頁，缺的是公司層 | 現況盤點已更正 | 已驗 |
| 講 RACI 小弟就知道 | RACI 來自專案管理與 COBIT，Red Book 只要求「角色與責任明確」 | RACI 是我們選的做法不是 GRC 規定；Excel 範本只有單一 Owner 欄 | 已驗 |

**待驗真實使用情境（寫規劃前要問 PM 或顧問）**

| 問題 | 為什麼重要 | 影響哪頁 |
|---|---|---|
| 顧問或客戶今天真的有在維護風險總表嗎，還是做 ISO 時交一份文件就結束 | 若後者，第二版「稽核自動餵入」最有價值，手填表單反而少人用 | 08 第二版 |
| 客戶的部門分工真的對得到框架群組嗎（附件一第二部分全是產品部？） | 決定「按群組整批設部門」是省力起點還是沒用 | 07 第一版 |
| 老闆真的會自己開系統，還是只看顧問印出來的報告 | 決定儀表板與報告總表哪個優先 | 07 第一版 |
| 一家客戶會同時開幾個專案 | 決定控制項對部門要不要做「跨專案複製」 | 07 第一版 |
| 客戶有沒有在管供應商、記內部資安事件 | 決定供應商評估與事件管理這兩種後續來源要不要做 | 08 後續來源 |

---

## PM 交付的三份資料 {#materials nav="資料"}

| 資料 | 是什麼 | 怎麼用 |
|---|---|---|
| OCEG《GRC Capability Model v3.5》（Red Book） | 發明 GRC 一詞的組織出的教科書，20 個元素 | 06 外部對照用它當完整度尺 |
| 《GRC Overview Dashboard.xlsx》 | 一本登錄表、七種看法，Dashboard 分頁是 PM 說「做出這種感覺」的目標畫面 | 08 第二版的欄位來源；九張頁各是什麼見 04 現況與缺口 |
| Workiva「什麼是 GRC」 | 入門文章 | 02 領域知識的用詞依據 |

會議完整整理與逐字稿見 [會議記錄](../meeting-2026-10-19.md)。