CRA 導入規劃

• CRA 是再加一本框架。 我們「規劃 → 執行 → 外部稽核 → 矯正」的主流程，已完整覆蓋 CRA 最重的兩步：落實 Annex I 的資安要求、做符合性評估。
• 真正要新做的只有三件東西加一個底層機制：
  1. 產品主檔加「版本」與「支援期」
  2. 風險登錄
  3. 法規通報模組
  4. 底層機制：資源庫第四件「表單設定」（勾了 CRA 的專案才出現 CRA 專用欄位）
• 其餘全是既有畫面加欄位、加資料、加文件範本。
• 第〇步（拿自家產品試跑）與框架入庫零開發，現在就可以先跑。
• 「感覺很龐大」的回應：分三期，每期各自可交付。

1. 開 FR-135 母卡，涵蓋第〇步、框架入庫、資源庫表單設定、產品側寫與風險、文件。通報模組與跨框架對應各另開整數號 FR；「不適用沒排除稽核範圍」這個連動 bug 獨立開小卡。
2. 風險評估第一版做手填登錄表雛形。表單預留「威脅來源」與「元件連結」兩個欄位，下一階段接「依 SSP 元件類型建議威脅」。
3. 表單設定做成合規資源庫的第四件，與控制項選集、SSP 範本、稽核流程範本並列，隨資源庫複製。擴充欄位的「定義」（欄位名、型別、必填）隨資源庫走，「值」存在專案 SSP 的擴充屬性。之後 SEMI E187 這類產品型框架，複製 CRA 資源庫微調即可。
4. 評估目標（AO）第一版不寫，每條控制項入庫時附「建議證據」；第〇步跑完再決定拆哪幾條。
5. 通報第一版只做建案、三個期限倒數、寄信、回填送件紀錄、時間軸。不對接 ENISA。
6. 第〇步第一期就開，與 31 條控制項灌入同一張卡。
7. 稽核階段對 CRA 專案當作「檢查」：不跳過，稽核員由顧問擔任，判定的意思是文件與證據做對了沒。系統不改，這套用法寫進資源庫說明與使用手冊。

誰要遵守：把會連網的硬體或軟體（法條叫「具數位元素產品」）賣進歐盟市場的製造商。符合後貼 CE 標誌才能上市。

我們的客戶多數是 Default 類，走自評。

控制項來源共 31 條：Annex I Part I 產品安全要求 14 條（第 1 條加第 2 條 a～m 十三款）、Part II 漏洞處理要求 8 條、Annex II 使用者資訊 9 項。

不進控制項但系統要支援的兩件：Art. 13 風險評估（製造商要做、要留存）、Art. 14 通報（被積極利用的漏洞與嚴重事件要在期限內向 ENISA 通報）。

• 本質是引導式填表工具，像報稅軟體：精靈一步步帶你填適用判定、用途、分級、架構、威脅、每條要求的狀態與措施、支援期，最後按一鍵產出一包 PDF。
• 不稽核：沒有稽核員角色，沒有判定，也沒有矯正。
• 文件只在最後產出一次，每個產品版本一包；前面各步都只是輸入。
• 也沒有評估目標（AO），只有「要求」這一層；證據很輕，稽核軌跡記下每個措施與證據即可。
• 工作單位是「一個產品的一個版本」，等於我們的「一個專案」。

他們的 11 步分三段：

1. 圈範圍：適用判定、預期用途、判角色、產品分級
2. 做到：風險評估、落實 Annex I、漏洞處理與支援期、通報
3. 證明：三份文件、符合性評估、符合性聲明與新版本繼承

✅ 已有　🟡 部分有　❌ 沒有

風險評估頁籤要填的欄位：威脅、資產、衝擊、可能性、對應控制項、適用與否；另預留「威脅來源」與「元件連結」，給下一階段的依元件類型建議威脅使用。

組織層（系統管理）

• 資訊系統盤點加「版本」子清單：版號、上市日、支援期結束日與理由。
• 資訊系統盤點加漏洞揭露政策、通報窗口、通報人員。
• 「風險登錄」第一版不開獨立頁：資料掛在系統主檔，由專案的風險評估頁籤寫入。GRC 時再開獨立頁。
• 「法規通報」新模組：入口在側選單合規稽核群，以及資訊系統盤點每列的按鈕。

資源庫層（範本管理）

• 資源庫第四件：表單設定。與控制項選集、SSP 範本、稽核流程範本並列，決定勾選這本框架的專案要顯示哪些 SSP 區塊（含風險評估頁籤開關）、哪些擴充欄位。欄位的定義隨資源庫走、填的值存在專案 SSP，複製資源庫時表單設定一起帶走。
• 「文件範本」綁定：每個資源庫綁自己的匯出範本。
• 資源庫說明寫明 CRA 專案的稽核階段當「檢查」用：稽核員由顧問擔任，判定文件與證據做對了沒。
• Annex II 預設值走既有的「適用控制項預設值」。
• CRA 公版資源庫預先勾好，客戶開箱即用。

專案層（專案規劃頁）

• 受評標的頁多一段擴充欄位與適用判定。資源庫有勾才出現，CMMC 專案看到的畫面不變。
• 新增「風險評估」頁籤。
• 控制項現況編輯修「不適用」連動 bug。
• 文件匯出多三個按鈕。
• 掃描結果頁加處理狀態與揭露狀態。

資訊系統盤點（產品主檔）
├── 版本（版號、上市日、支援期）
├── 風險登錄（由專案風險評估寫入）
├── 法規通報（案件、期限、寄信、時間軸）
└── 專案（選系統與版本）
    ├── 資源庫表單設定（決定下面哪些區塊出現）
    ├── 受評標的（擴充欄位、適用判定、分級）
    ├── 風險評估
    ├── 控制項現況與稽核（既有）
    └── 文件匯出（技術文件、使用者資訊、符合性聲明）

製造商不用新欄位：SSP 參與單位加一個「製造商」角色即可。

法條只寫「要做到什麼」，不寫「怎麼證明」。三組控制項的證據性質不同：

• Part I 技術證據：設計文件、設定、測試報告、掃描結果。
• Part II 流程證據：政策、作業程序、執行紀錄。
• Annex II 文件證據：就是那份使用者資訊本身。

每條控制項入庫時附一段「建議證據」，放在控制項既有的說明位置。

AO 分三階段：

1. 第一版不寫。系統允許控制項沒有 AO，稽核員直接在控制項層判定。
2. 第〇步跑完後自己拆。只針對「一條包多件事」的條目，依法條自帶事項加 ENISA 對照報告的子要求拆成二到五個，對齊檢查、訪談、測試三種方法（Examine／Interview／Test）。用自己的話寫、附條號引用，不抄原文。
3. EN 40000-1-4 出版後替換（約 2027 秋）。以框架新版本替換，舊專案沿用舊版。

依據硬度的風險：自拆的 AO 對 Default 類自評客戶夠用；對要找公告機構的 Class I／II 客戶只能當準備用。資源庫說明要寫清楚這點。

第〇步順便驗證「建議證據」寫得對不對：FR-126 的 81 條安全需求與測試幾乎對得上 Part I 每一條，FR-134 的元件掃描對得上 Part II 第 1、2 條。

第一版功能：

• 建案：系統、版本、類型（被積極利用的漏洞／嚴重事件）、知悉時間、負責人、通報人員。
• 倒數：前兩個截止點從知悉時間算；最終報告的截止點在對應事件發生時才開始算（漏洞：回填修補可用日；事件：回填 72 小時通報送出時），起算前顯示「待起算」。
• 寄信：建案時寄、截止前提醒、逾期再寄；走既有郵件設定與通知頻道。
• 回填送件：每階段按「已送件」，填送件時間、ENISA 案號、附檔；回填後該階段停止倒數。
• 時間軸：建案、寄信給誰、回填、操作者全部留紀錄，這就是 Art. 14 要留存的證據。
• 填寫範本：三份報告各給一份範本，使用者複製貼到 ENISA 網站。
• 目的地欄位預設 ENISA 單一通報平台（SRP），預留其他 CERT。
• 不做對外自動送件。

工作量：一張清單頁、一個案件頁、一個狀態流轉、一支排程、三封信範本。

這三份的去向都不是「提交」：

Default 類產品沒有任何提交動作。

官方沒有範本，但法規定了每份必含的項目，那就是大綱：

• Annex V 符合性聲明（八項）：產品識別、製造商名稱與地址、全權負責聲明句、聲明標的、符合歐盟法規的聲明、引用的標準或規格、公告機構、補充資訊與簽名欄。Annex VI 簡化版只有兩句話，照填即可。
• Annex VII 技術文件（八章）：
  1. 產品描述（含用途與版本）
  2. 設計與漏洞處理（含架構圖、元件清單、漏洞揭露政策）
  3. 風險評估
  4. 支援期的決定依據
  5. 採用的標準：第一版由客戶自填，因調和標準還沒出版
  6. 測試報告：對應稽核判定與證據清單
  7. 符合性聲明副本
  8. 元件清單（監管機關要求時提供）
• Annex II 使用者資訊（九項）：製造商聯絡方式、漏洞通報窗口與揭露政策、產品識別、用途與安全環境、已知風險情境、聲明取得位置、支援方式與結束日、安全安裝與更新與停用說明、元件清單取得方式。

範本照法規章節排、內容從專案欄位自動帶入。欄位沒補的章節只能留白讓客戶手寫——這就是產品側寫與風險評估欄位要補的原因。

每個產品版本出一包，結案時下載。走既有 SSP Word 匯出管線，每個資源庫綁自己的範本，CMMC 範本不動。

第一期：第〇步與框架入庫（零開發）

做完能幹嘛：顧問可以開 CRA 專案、照現有流程跑完稽核；也拿到一份「哪些證據掛不上去」的實測清單，作為第二期的依據。

步驟：手工整理 31 條含建議證據 → 灌進 DEV → 建 CRA 公版資源庫與專案 → 掛上 FR-126 與元件清單證據 → 產出「掛不上去的清單」→ 修連動 bug。

可派的卡：

1. ENISA 對照底稿＋31 條建議證據草稿（顧問或 PM 主筆，runner 做底稿）
2. 31 條控制項灌入 DEV＋建 CRA 公版資源庫＋第〇步：掛上 FR-126 證據，產出「掛不上去的清單」
3. 「不適用沒排除稽核範圍」連動 bug（獨立小卡）

第二期：底層機制與欄位

做完能幹嘛：CRA 專案能填齊產品版本、支援期、用途、分級、適用判定與風險評估，其他框架畫面不受影響。

順序：資源庫表單設定（最小版）→ 資訊系統盤點加版本、支援期、漏洞揭露政策 → 受評標的擴充欄位與適用判定 → 風險評估頁籤。

第三期：新模組與文件

做完能幹嘛：客戶能管通報期限並留存證據、追蹤弱點處理，結案時一鍵下載三份法定文件。

順序：通報模組 → 弱點處理狀態 → 三份文件範本 → 支援期到期排程。

GRC 待辦（不在本 FR）：組織層風險登錄獨立頁、依元件類型建議威脅、畫架構圖自動生威脅、自評路線（跳過或簡化稽核）、跨框架對應、通報多目的地。

不做：

• 畫架構圖自動生威脅（留下一階段；本期風險表預留欄位，下一階段先做依元件類型建議威脅）
• 對接 ENISA 自動送件
• 把 EN 40000 或 ENISA 條文抄進框架
• 在框架內嵌 ISO 對照
• 把「自家產品符合 CRA」當成目標（第〇步只是拿現成材料當測試案例）
• 自評路線

未查清：

• 系統裡有兩套矯正計畫（POA&M）資料，哪一套是正式的。
• 規劃期風險登錄若沿用既有風險資料，與稽核結果的關聯要怎麼處理。

• 法規原文（EUR-Lex）：https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
• ENISA 單一通報平台（SRP）：https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp
• ENISA 要求與標準對照報告：https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping
• COMPLYD 指南：https://complyd.io/en/cyber-resilience-act-guide/
• repo 內研究筆記：docs/reference/CRA/cra-implementation-guide.md
• repo 內條文唯一來源：docs/reference/CRA/annex-I-II-original-text.md