同一張 ISO 27001 風險表，資訊部把「會員資料被未授權讀取」評成中風險：系統已有登入密碼。
客服認為是高風險：若消費者接到冒名電話，可能天天有人打來問。
財務問：「到底要預留多少事故處理成本？」
三個部門都不是亂評分，只是各自衡量不同的影響。
風險評鑑不是投票決定高、中、低，而是先統一事件情境、可能性、衝擊與接受條件。 分數若無法支持優先順序和處置決策，清冊再厚也沒辦法幫公司降低損失。
此為不同部門評分口徑的情境示意。
先定評估口徑，再評風險
在同一張風險清冊中，每個部門對「高風險」的理解不能不同。開始前先約定：
圖解：先統一情境與評分口徑才能決定優先順序
- 評估範圍： 哪些業務流程、資料、系統與第三方廠商納入？
- 可能性基準： 評估的是未有控制時，還是既有控制後的可能性？
- 影響基準： 客戶權益、營運中斷、契約違約、法令責任如何判定？
- 接受條件： 哪些風險可以接受，誰有權決定？
- 複查時機： 系統上線、重大委外變動或事故後是否重新評估？
範例：同一個品牌的三種風險
| 事件情境 | 可能影響 | 既有措施 | 處理方向 |
|---|---|---|---|
| 營運人員誤把會員完整名單寄給外部 | 個資不當揭露、處理事故成本 | 匯出有權限但無二次簽核 | 限縮角色、審核大批量匯出 |
| 離職員工仍可登入 CRM | 非授權存取 | 離職流程未與 CRM 自動連動 | 人事與系統停權對帳 |
| 物流串接帳密未更換多年 | 帳密濫用、資料不當存取 | 合約有保密條款 | 管理憑證、輪換與異常監測 |
這些不是一定要投入大型資安設備才能改善。先看風險造成的損失，以及低成本控制是否足以降低可能性。
Risk Register 至少保留八欄
| 欄位 | 實務用途 |
|---|---|
| 風險 ID | 後續能追蹤同一情境 |
| 資產與流程 | 確認風險發生在哪裡 |
| 事件情境 | 「誰在什麼條件下造成什麼後果」 |
| 既有控制 | 不要把尚未執行的措施寫成已存在 |
| 風險評分與理由 | 可回溯方法、不能只填 9 分 |
| 處理方案 | 降低、避免、轉移或接受，寫清理由 |
| 風險負責人及期限 | 防止表格無人跟進 |
| 殘餘風險與核准 | 改善後的風險是否在可接受範圍 |
為什麼不能只問「是否有 ISO」？
外包平台提供的認證，可能涵蓋其特定服務和場域；你的品牌內部匯出、名單共用與跨系統串接未必在它的驗證範圍。供應商證書是風險評估輸入之一，不是風險清冊的替代品。
如何判斷差距分析是否做對？
對重大風險，應能找出三筆可以回查的資料：評估依據、執行措施及複查結果。當風險分數降低時，要能說出是哪一個措施改變了可能性或影響，而不只是季度報表想讓紅色變少。
圖解：風險分數只是排序工具不是結案證明
分數不能代替風險理由
假設公司採用 1 至 5 分的可能性與影響尺度，將兩者相乘作為內部排序工具：即使同樣得到 12 分，「低頻但可能造成大量個資外洩」和「高頻造成短暫服務中斷」需要的處置方式也可能不同。分數是會議的起點，不是法律或驗證標準規定的固定答案。
評估時最好同時寫下定分依據，如最近三個月的帳號異常紀錄、備份測試結果、資料類型及對營運的實際影響。若資料不足，就標記評估不確定性，不要因為沒有事故紀錄就直接把可能性設為最低。
來源：ISO 27001；實務方法可參考 ISO 27005。以上範本為教學示例，並非正式標準條文全文。
可驗收的風險處理：把一件事追到結果
以「離職員工 CRM 帳號未停權」作為虛構範例：
- 風險判定： 離職人員仍可能登入及接觸會員資料。評估影響與可能性時，把既有帳號清單與歷史案例當依據。
- 改善承諾： 新增人資離職流程與 CRM 管理員的停權交接，明定負責人及驗收期限。
- 第一次驗收： 抽樣近期離職員工，對照離職日期與各系統停權時間；若找不到紀錄則標記證據不足。
- 第二次驗收： 更換系統或委外廠商後，重新確認是否出現新的未納管帳號。
- 殘餘風險： 即使改善已做，也要由有權責者按組織風險接受條件重新判斷，不能由 AI 自動代替決策。
追蹤的單位是同一個風險情境與改善措施，不是每個月把風險清冊全部重新填一遍。
同主題延伸閱讀：ISO 27001 Gap Analysis 怎麼做？企業導入前差距分析與改善清單、ISO 27001 適用性聲明 SoA 怎麼寫？從風險到控制措施的對照範例。