OSCAL 稽核生命週期

一頁全景

六份文件,三種「能不能改」的規則。記住這張表,後面每一節都是它的展開。

文件	一句話	誰寫的	裡面的證據	能不能改
catalog	這個框架包含哪些控制項	框架方／平台	—	很少改
profile	從 catalog 挑出這次要用哪一組	框架方／平台	—	很少改
SSP	我的系統每條控制是怎麼做到的	受評公司	自己準備的佐證（平常一直在補）	隨時能改
AP	稽核員打算怎麼查	稽核員	沒有證據,只有計畫	查核當下定版
AR	稽核員實際看到什麼、判定過或沒過	稽核員	查核記錄（引用佐證＋稽核員的判讀）	寫完就定版
POA&M	沒過的怎麼補、補到哪了	受評公司	整改的證據（一直更新）	隨時能改

一句話記住 文件分三種:框架的規則（平台先建好,大家共用,很少改）、我的 SSP（我自己的文件,平常隨時在改）、查核留下的記錄（AP／AR／POA&M,某個時間點定版存證,之後不回頭改、只往後追加）。整份教材都圍著這個區分。

六份文件實際長什麼樣

用「精誠機械申請 CMMC Level 2」這條故事,各舉一個具體例子,讓抽象的名字落地。

catalog 很少改

框架方／平台建立 · 大家共用

內容像是一整份控制清單的官方定義,例如 NIST SP 800-171 的 110 條,每條長什麼樣、要求什麼。它是「控制的字典」,本身不規定你這次要用哪些。

profile 很少改

框架方／平台建立 · 大家共用

內容像是從 catalog 裡挑出「這次要用哪些」。最典型的例子是 NIST 800-53 同一份大清單,挑成 Low／Moderate／High 三種不同強度的組合,各自是一個 profile。

SSP 隨時能改

精誠機械自己寫

內容像是「我們的 CUI 隔離區包含 1 台檔案伺服器、5 台工作站；針對 3.1.7,一般帳號不屬於任何特權群組,特權操作要另外用 -adm 帳號並經申請」＋附上 PIM 設定截圖當佐證。

AP 定版

稽核員（衛安認證）寫

內容像是「7/6 上午看存取控制文件、7/7 下午用一般帳號實測能不能執行特權功能、機房抽 2 台工作站來看」——一張行程＋抽查名單,但裡面沒有任何證據。

AR 定版

稽核員（衛安認證）寫

內容像是「實測特權隔離 → 過；但檔案伺服器發現一個沒人管的廠商帳號、找不到授權單 → 3.1.1 沒過」。每條控制過或沒過都記,連同看到的事實與佐證。

POA&M 隨時能改

精誠機械自己寫

內容像是「PM-001 休眠帳號治理:① 立刻停用該帳號(7/15) ② 修訂帳號管理程序(8/31) ③ 全帳號盤點(9/30)」——只把沒過的那幾條挑出來,排出補救步驟並追蹤進度。

文件鏈與時間動力學

六份文件不是並排的清單,而是一條有方向的鏈。後面一份會引用前面一份;越左邊的越少改、越右邊的越固定。

實線=資料往哪流；藍虛線=對著某份定版文件查；琥珀虛線=整改完回頭更新 SSP

常見認知誤區 CMMC 比 ISO 更嚴格,不是更寬鬆。CMMC 控制集固定、受評者無裁剪權；ISO 反而是唯一允許受評者用 SoA 自選排除控制的框架。

SSP 與 SoA：受評方的聲明

SSP 是受評公司自己寫的:「我的系統每條控制是怎麼做到的」。六份文件裡,只有它是平常隨時可以改的。

四大區塊

區塊	回答的問題
`import-profile`	我這次要遵循哪一組控制（哪個 baseline）
`system-characteristics`	系統是什麼、範圍邊界到哪裡、資料有多敏感
`system-implementation`	系統由哪些設備、人員、資產組成
`control-implementation`	每條控制具體是怎麼做到的（這裡是主體）

重點:證據在 SSP 階段就要準備好了 合規工作的八成都在準備期。實作說明和佐證（政策文件、設定截圖、權限審查表）在稽核之前就一直在累積,掛在這份 SSP 上。所以常見的誤會「稽核計畫(AP)那一步才上傳證據」是錯的——AP 裡一份證據都沒有。

SoA（適用性聲明）放在哪

很多人以為 SoA 要在 SSP「之前」先聲明好。其實不是——

SoA 不是獨立的一步,它就是 SSP 的一部分:在 SSP 裡,每條控制旁邊標上「適不適用、為什麼」。對外要交一份 SoA 文件時,從這些標記直接匯出就好。

兩件事要分清楚（混在一起是最常見的錯）

在問什麼	答案	後果
適不適用（這條我們要不要做）	適用／不適用	標「不適用」→ 不用準備證據、稽核時跳過、永遠不會變成缺失
做了沒（要做的,現在做到哪）	已完成／部分／規劃中／還沒做	標「還沒做」→ 是缺口,稽核會開不符合、要進整改清單

混在一起的後果:分不清「我們決定不做(有正當理由)」和「我們該做但還沒做」。標「不適用」也不是真的隱形——稽核員還是會檢查你的理由站不站得住腳,只是不用真的去驗那條控制(跳過查驗、但不跳過審查理由)。

會改的 vs 定版的：交卷的比喻

這是整套流程最容易搞混、也最關鍵的一點。想通這個,後面的二次稽核就全懂了。

定版鎖住的不是 SSP 本身,是「交出去的那一份副本」。你手上的 SSP 一直都能繼續改。

SSP 一直往前改;每次稽核時拍一張快照鎖定,鎖的只有那一輪用的那張

為什麼快照要鎖死 稽核員是針對「你交出去那一刻的說法」做判定。如果稽核期間偷偷改 SSP,那「沒過」的依據就被你抽掉了。稽核結論指向的,必須是一份不會再變的文件。這是公平性,不是系統限制。

為什麼手上的 SSP 還要能改 整改做完的終點,就是「把 SSP 更新成改好的樣子」。缺失補完 → 更新 SSP → 下一輪驗的是「改好之後的你」。如果 SSP 永久鎖死,整改完根本沒地方寫。

AP：稽核員的查核計畫

稽核員在開始查之前先講清楚:要查哪些控制、會碰到哪些東西、什麼時候查、怎麼查、有什麼規矩。裡面沒有任何證據,也還沒有任何結論。

AP 就回答四件事

只有「查哪些控制」一定要寫;碰什麼、何時、怎麼查都可省略——因為那些是稽核員臨場的專業判斷

為什麼系統能自動幫你生出一份基本的 AP AP 一定要有的三樣東西——標題、對著哪份 SSP 快照、查哪些控制——系統裡其實都有現成資料(專案名、剛拍的快照、適用性表)。所以一按下「開始稽核」,系統就先自動產一份草稿;等稽核員的正式行程寄來,再補上日期和抽查名單就好。PM 不用從一張白紙開始填。

「會碰哪些東西」白話講

它回答一個很具體的問題:稽核員那天會實際碰到哪些東西?——抽哪幾台機器來看、找哪些人訪談、進哪個機房。做法就是拿出 SSP 快照裡的資產清單,把這次要查的勾起來;抽查就是「只勾其中幾台」。

AR：稽核結果的三層記錄

稽核員的正式記錄。核心是這條鏈:先記下「看到什麼」,再判定「過或沒過」,最後說明「沒過會造成什麼問題」。

三層各自獨立、互相連結;只有「沒過」的那幾筆會往右走(變成風險 → 進整改清單)

finding 和 risk 為什麼要分成兩個

	finding（判定）	risk（風險）
在講什麼	對照規則,過了沒	沒過會造成什麼問題
答案形式	只有兩種:過／沒過	有輕重、有緩解、會變化
會不會改	當下定版 · 不再改	持續追蹤 · 從未解到關閉
給誰看	決定能不能發證	決定先修哪個、能不能接受不修

POA&M：錯題本

就像「錯題本」:只把沒過的那幾條挑出來,連同訂正需要的背景一起抄進去。由受評公司負責,一直更新到全部補完關閉。

錯題本不是整份考卷的影本——只抄錯的那幾題,加上訂正需要的背景

每個錯題只是一張「封面」,內容在風險裡 每筆整改項目(poam-item)其實只是一張封面,寫著「這是哪個缺失、為什麼要改」。真正的執行細節——什麼時候改完、分幾步、誰負責、改到哪了——都記在它連著的那筆風險(risk)裡。這樣設計是因為稽核員在 AR 裡寫的整改建議,可以原封不動接過來繼續用。

給工程的提醒:不要真的複製一份 畫面上看起來像「把沒過的內容複製進 POA&M」,但資料庫裡不該真的複製——用關聯(FK)指回原本的 AR 記錄就好,避免兩份資料各改各的、對不起來。只有在匯出成 OSCAL 檔案要交出去時,才把內容實際填進去湊成一份完整文件。

完整流程：稽核結束 → 整改 → 二次稽核

這是 PM 最常經手的一段。每一步標了:誰動手、動哪份文件、什麼時候從稽核員手上換到受評公司手上。

泳道顏色 = 誰動手（藍=稽核員／琥珀=受評公司）· 每年的年度查核就是再走一輪:新快照＋新計畫

對回我們系統的資料表

這一節是給工程參考的:把 OSCAL 概念對應到 Guidant AI 的資料表。✓ 已經對好；⚠ 做 ISO 整合前建議調整。

OSCAL 概念	Guidant AI	狀態
SoA（applicability＋理由）	`project_control_applicability`	✓
SSP statements	assessment_objective 層描述	✓ 粒度對齊
SSP by-components	`ssp_component_mappings`	✓
SSP snapshot	launch_audit 的 snapshot	✓
AP reviewed-controls	applicability 表生成	✓
AR results[]	audit_rounds ＋ AR	✓
observation.relevant-evidence	`ar_evidences` → job_evidence_id（引用不複製）	✓ 教科書級
finding.target（objective）	`ar_findings`	⚠ 改全量判定矩陣
POA&M poam-item＋risk	`oscal.poams`（兩層壓一張）	✓ 合理
risk.remediations.tasks	`poam_milestones`	⚠ 加 assignee
risk.status 生命週期	poams status 五態	⚠ ISO 需擴充 deviation

ISO 整合動工前待拍板（精選）

round_type 分流:launch_new_round 區分 close-out（只含未關 POAM 控制）vs surveillance（抽樣／全量）。並確認是否重新 snapshot 當下 SSP(正確),而非沿用舊快照(bug)。
ar_findings 改全量判定矩陣:每個 in-scope objective 一筆（met／not_met／pending）。報表分母、進度追蹤、OSCAL 交付都需要。
deviation 狀態 / closure_type:ISO 風險接受（Clause 6.1.3）需要 risk_accepted 分支,目前五態未涵蓋。
source_identifier:control 表加原始出處編號（如 800-171r2:3.13.11、iso27001-2022:A.8.24）,支撐 L1→L2 升級證據沿用、跨框架 crosswalk。
L1/L2 重複資料:L1(15條)是 L2(110條)真子集、control_id 相同。目前分兩 catalog = 同條控制存兩份,升級時 FK 斷裂。
poam_milestones.assignee:每個 milestone 各別負責人（跨部門整改 M1 歸 IT、M2 歸採購要拆得開）。
ISO 版權:catalog 不可存 ISO 27001/27002 控制全文散布給租戶。只放 ID＋標題＋自寫摘要。動工前先問法務。

市場定位提醒 Phase 1-2(準備/收證)是 Vanta/Drata 主戰場,競爭最激烈;Phase 3(外部稽核員寫 AR/findings)是市場空白區,多數產品到此斷掉——這正是 Guidant AI 的機會。OSCAL 標準格式讓「稽核資料的結構化收斂點」成為可行的價值主張。

系統設計：三層架構與 clone 邊界

從概念進到實作。控制集在系統裡分三層存放,每層的邊界都做一次「複製並固定」,讓上游的改動不會波及下游正在進行的工作。

每個黑色橫條都是一次「複製並固定」的邊界;上游改動到此為止,不會波及下游正在進行的工作

為什麼控制集要獨立存,不攤進 SSP 同一份控制集會被 SSP、AP、AR、POA&M 同時依據。獨立存成一份,大家都指它(單一真相來源);攤進 SSP 的話,控制定義會散落各處、改一處對不齊其他,而且 SSP 會混扛「控制是什麼」和「我怎麼做」兩個職責。

clone 的是「挑選後的控制集」,不是整份母版 母版可能上千條,專案只用一個 baseline。所以專案 clone 的是 profile 挑選、解析後的結果(只含這專案要的),不是無腦複製整份母 catalog ── 兼顧單一來源與輕量。

這個設計順手解決了「母版被改/刪」的風險 因為每一層都有自己的副本,母版 catalog 怎麼改、甚至刪控制,都波及不到下游正在編輯的 SSP。要吸收新版時,是「專案主動決定升級」(重新解析 profile),而不是資料庫默默連動。前提:副本要存「內容」或指向「永不原地改的版本化控制」,不能只存 id 即時 join 回會變動的母表 ── 那正是會讓工作被抽換的地雷。

哪些是 OSCAL 規定 · 哪些是實作選擇 · OSCAL 官方:profile 從 catalog 挑選＋解析成控制集(resolved catalog)、各文件用 import 指向依據。 · 實作選擇(我們自己決定):分三層存放、每層 clone 一份、稽核時 snapshot 凍結。OSCAL 沒強制這些,但這是防止資料互相干擾的務實做法。