---
title: CRA 導入規劃
subtitle: PM 決策與派工用，先讀這份
eyebrow: FR-135 CRA 合規框架 · 規劃定稿 · 2026-10-11
lede: 歐盟網路韌性法（CRA）對我們是**再加一本框架**，不是新產品線。真正要新做的只有三件東西加一個底層機制，分三期、每期各自可交付，第一期不用寫程式。
---

## 一頁結論

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

| 期別 | 做什麼 | 要寫程式嗎 | 做完能幹嘛 |
|---|---|---|---|
| 第一期 | 31 條控制項入庫、建 CRA 資源庫、自家產品試跑 | 不用（除一個獨立小 bug） | 顧問可以開 CRA 專案、照現有流程跑稽核 |
| 第二期 | 資源庫表單設定、產品版本與支援期、受評標的擴充欄位、風險評估頁籤 | 要 | 專案裡能填齊 CRA 要的產品資料與風險評估 |
| 第三期 | 通報模組、弱點處理狀態、三份文件範本、支援期到期提醒 | 要 | 能管通報期限、一鍵出三份法定文件 |

## 已裁的事（2026-10-11）

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

## CRA 一頁背景

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

| 時間 | 生效內容 |
|---|---|
| 2026-09-11 | 通報義務已生效，含已上市產品 |
| 2027-12-11 | 全部義務適用，之後上市的產品都要符合 |

| 分級 | 例子 | 評估方式 |
|---|---|---|
| Default | 絕大多數軟體與連網產品 | 製造商自評 |
| Class I | 瀏覽器、密碼管理、VPN、作業系統等 | 完整採用調和標準可自評，否則找公告機構 |
| Class II | 防火牆、入侵偵測、虛擬化平台等 | 必須找公告機構 |
| Critical | 硬體安全模組、智慧卡等 | 歐盟資安認證或公告機構 |

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

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

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

## 競品在做什麼（COMPLYD）

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

他們的 11 步分三段：

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

## 逐步對照

✅ 已有　🟡 部分有　❌ 沒有

| 競品步驟 | 我們對應 | 現況 | 缺什麼 | 補法 |
|---|---|---|---|---|
| 0 產品盤點、適用判斷 | 專案＝產品的一次評估；「資訊系統盤點」可當產品主檔 | 🟡 | 專案沒連到所屬系統；系統沒有版本 | 資訊系統盤點加版本子清單；建專案時選系統與版本 |
| 1 預期用途與誤用 | 受評標的頁的描述（自由文字） | 🟡 | 結構化欄位 | 受評標的頁加用途、誤用、環境、角色欄，由資源庫設定是否顯示 |
| 2 判角色與適用理由 | 無 | ❌ | 全缺 | 受評標的頁加「適用判定」區塊，八題各附理由欄 |
| 3 產品分級 | 無。頁上「安全分類等級」是系統重要性高中低，不是 CRA 分級 | ❌ | 全缺 | 受評標的頁加分級下拉 |
| 4 風險評估 | 稽核階段有「稽核風險管理」，規劃階段沒有入口 | ❌ | 規劃期風險登錄 | 規劃頁新增「風險評估」頁籤手填；資料掛產品主檔、專案引用 |
| 5a 落實 Annex I | 主流程：審閱頁標狀態、收證據、稽核員判定 | ✅ | 無 | 31 條灌進框架；修「不適用沒排除稽核範圍」bug |
| 5b Annex II 使用者資訊 | 可當控制項收證據 | 🟡 | 專門欄位 | 九項當控制項；資源庫範本放預設值 |
| 6a 元件清單與弱點 | 第三方元件風險模組 | ✅ | 無 | 無 |
| 6b 漏洞處理與揭露狀態 | 只有掃描結果 | 🟡 | 處理狀態、揭露狀態 | 掃描結果頁加兩個狀態欄 |
| 6c 漏洞揭露政策與窗口 | 無 | ❌ | 全缺 | 資訊系統盤點加政策文字與窗口 |
| 6d 支援期 | 無 | ❌ | 全缺 | 版本加結束日、理由、到期提醒；安全更新清單先用 Part II 第 8 條收證據 |
| 7 通報 | 無 | ❌ | 全缺 | 新模組，見「通報模組」一節 |
| 8 技術文件、使用者資訊 | SSP Word 匯出、摘要報表 | 🟡 | 三份範本 | 資源庫綁範本，走既有匯出 |
| 9 符合性評估 | 外部稽核、矯正 | ✅ | 無 | 稽核員由顧問擔任 |
| 10 聲明與新版本 | 專案複製、SSP 版本 | 🟡 | 聲明範本 | 補範本；版本繼承靠「所屬系統」串起 |

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

## 新東西放哪

**組織層（系統管理）**

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

**資源庫層（範本管理）**

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

**專案層（專案規劃頁）**

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

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

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

## 證據與評估目標（AO）

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

- **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 條。

## 通報模組（第一版）

| 階段 | 期限 | 內容 |
|---|---|---|
| 早期預警 | 知悉後 24 小時內 | 發生了什麼、可能影響哪些國家 |
| 正式通報 | 知悉後 72 小時內 | 產品、性質、已採取的措施 |
| 最終報告 | 漏洞：修補或緩解措施可用後 14 天內；事件：72 小時通報送出後 1 個月內 | 根因、影響、矯正措施 |

第一版功能：

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

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

## 三份文件

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

| 文件 | 給誰 | 怎麼交 |
|---|---|---|
| Annex VII 技術文件 | 製造商自己 | 留存十年，監管機關來查或找公告機構時拿出 |
| Annex II 使用者資訊 | 產品使用者 | 隨產品附上 |
| Annex V 符合性聲明 | 市場與使用者 | 隨產品附上或放網址，製造商自己簽 |

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`