# CRA 框架評估目標（AO）矛盾掃描

- 掃描對象：DEV 庫 framework_version 207（CRA 2024/2847，catalog 2112），以庫內實際內容為準：3 群組、31 控制項、25 個 AO（拆在 7 條控制項）、31 份建議證據（共 116 點）。
- 對照依據：Annex I／II 原文、Article 13 與 Article 14(1)～(5) 原文、ENISA 對照底稿、AO 拆分說明。
- 本文代號：AO 以畫面字母寫（例 I.1 [a]），括號內附資料庫編號（obj.3）；建議證據以「控制項#第幾點」寫（例 I.2.c#3），點序依資料庫原文由上往下數。
- 矛盾編號格式 `M<類別>-<序號>`，對照表 Excel 的「矛盾標記」欄引用同一編號。
- 證據來源類別：**①系統內產生**（客戶在系統其他頁填完就有，不該再上傳）／**②客戶自有檔上傳**／**③系統範本產出**（系統給範本，客戶填完產出）。

---

## 一頁結論：最嚴重的 5 件

| # | 問題 | 影響 | 建議 |
|---|---|---|---|
| 1 | **CRA.I.1 的 4 個 AO 有 3 個法源在 Article 13，不在 Annex I Part I (1)。** [a] 風險評估有文件、[c] 逐條判定適用與不適用理由、[d] 生命週期內更新評估，分別出自 Art. 13(2)(3)、13(3)(4)、13(3)(7)。Part I (1) 本身只講「依風險設計出適當資安水準」，只有 [b] 對得上。 | 顧問或稽核拿條文對 AO 會對不上；Art. 13 的其他義務（支援期至少 5 年、更新保存 10 年、Art. 14 通報）反而整份框架沒有落點。 | 決策者裁：另開「Article 13 製造商義務」群組承接，或 I.1 留著但依據欄改寫成 Art. 13。I.1 本身補一條「每個風險都有對應措施」。（M1-1～M1-3） |
| 2 | **系統內已經產生的資料，建議證據仍要客戶上傳。** 116 點建議證據中有 16 點全部或部分屬①（風險評估、逐條適用判定、產品名稱版本與支援期、製造商與漏洞通報窗口、揭露政策與安全通告網址、SBOM 與弱點比對）。I.1 [c] 的「適用性聲明」其實就是 SSP 每條控制項的「不適用」狀態與理由。 | 客戶要把系統裡的東西匯出再上傳，同一件事兩份真相，改了一邊另一邊不會跟著變。 | 建議證據改寫為「系統自動帶入：〇〇頁」，不收上傳；平台要有「系統資料當證據」的機制，本期沒有的先註明（見第 6 節）。（M6-1） |
| 3 | **建議證據多是概念描述，做事的人不知道要交什麼檔。** 22 點以「Description of…／List of…／Commitment…／Inventory of…」開頭，沒說是哪一種文件、誰產出、哪個版本；另有 2 點根本不是證據（I.2.k#4「交叉參照」、I.2.m#4「與 A2.8(d) 一致」）。 | 準備期工作的人只能猜，稽核也無法判斷交的東西夠不夠。 | 每點改成「檔案類型＋最少要有的內容」，例如「架構圖（PDF 或圖檔），標出網段、容器、沙箱邊界」。概念句搬去 AO 本身。（M5 全節） |
| 4 | **畫面字母與資料庫編號對不上，內部標記外露給客戶。** AO 畫面寫 [a]，資料庫是 obj.3；建議證據每點前面卻寫 [obj.3]，客戶看到的是另一套編號。另有 28 處「[beyond ENISA – legal text／practice]」寫在給客戶看的建議證據裡。 | 客戶看不懂 [obj.3] 指哪一個 AO；「beyond ENISA」是我們內部拆分依據，不是給客戶的資訊。 | 建議證據前綴改成畫面字母 [a][b]；兩種內部標記從 guidance 文字移除，改存 props 或只留在 md。（M7-1、M7-2） |
| 5 | **拆不拆 AO 沒照自己的判準。** ENISA 底稿列的「一條包多件事」排行，第 2 名 I.2.c（五件事）、第 3 名 II.4、第 5 名 II.8、第 6 名 I.2.f、第 10 名 I.2.m 都沒拆；第 12 名 II.2 卻拆了。另外 I.2.c、II.7、II.8、A2.8 [c][e] 四處都在講「自動更新、通知使用者」，彼此重疊。 | 同樣性質的控制項，有的開 4 筆準備期工作，有的只開 1 筆；重疊處客戶要交好幾次同一份東西。 | 再拆 7 條（I.2.c、I.2.f、I.2.m、II.1、II.4、II.6、II.8），並劃清 I.2.c／II.7／II.8 的分工。（M2、M8 全節） |

**各類數量**：1 法源錯位 6 項｜2 重疊或互斥 9 項｜3 AO 與條文不對 12 項｜4 可判定性 8 項｜5 證據證明不了 AO 15 項｜6 來源類別 116 點全標（以主要來源計 ① 15、③ 14、② 85、不是證據 2；有 10 點是混合來源）＋問題 4 項｜7 用語 9 項（其中 2 項檢查後無問題）｜8 未拆 AO 再掃：建議拆 7 條、可拆可不拆 2 條。

---

## 1. 法源錯位（AO 要的事不在它掛的那條）

| 編號 | 控制項 | AO | 問題 | 正確依據 | 建議 |
|---|---|---|---|---|---|
| M1-1 | CRA.I.1 | [a] (obj.3) 風險評估有文件、有版本與日期 | Part I (1) 沒有要求「風險評估要有文件」。Part I (2) 只說「依 Article 13(2) 的風險評估」，是引用，不是要求。 | Art. 13(2) 要做評估；13(3) 要有文件、最少要涵蓋什麼；13(4) 放進技術文件 | 移到 Art. 13 群組；留在 I.1 的話依據欄改 Art. 13(2)(3)，並補 13(3) 要求的內容（用途、可預見使用、使用條件、預期使用期間） |
| M1-2 | CRA.I.1 | [c] (obj.5) 逐條判定 Part I (2) 是否適用，不適用要有理由 | Part I (2) 的「where applicable」只是說「適用時才要做」，要求寫理由的是 Art. 13。 | Art. 13(3)「風險評估要指出 Part I (2) 是否適用、如何實作」；13(4)「不適用要在技術文件寫明確理由」 | 移到 Art. 13 群組；並補上漏拆的「如何實作」（見 M3-1） |
| M1-3 | CRA.I.1 | [d] (obj.6) 風險評估在生命週期內持續更新 | Annex I 完全沒有這句；拆分說明自己也註明法源在 Art. 13。 | Art. 13(3)「支援期內適當更新」；13(7)「知道新漏洞等資訊時更新風險評估」 | 移到 Art. 13 群組，並與 II.3#4「重新評估風險紀錄」合併（見 M2-3） |
| M1-4 | CRA.II.6 | 未拆；建議證據 #2「已通知主管機關（國家 CSIRT）如何聯絡製造商」 | Part II (6) 講的是「方便別人回報漏洞、提供聯絡地址」，沒有要通知主管機關。 | 無直接依據。最接近的是 Art. 14 的通報義務（對 CSIRT 與 ENISA 通報被利用的漏洞與重大事件），但那是另一件事 | 刪除此點；Art. 14 通報另立控制項（見 M3-10） |
| M1-5 | CRA.II.6 | 未拆；建議證據 #3「通知第三方元件維護者其元件有漏洞」 | Part II (6) 只說「促進資訊分享」；明確要求通知元件維護者的是 Art. 13(6)。 | Art. 13(6) | 留著，但註明依據是 Art. 13(6)；若開 Art. 13 群組就搬過去 |
| M1-6 | CRA.I.2.c | 未拆；建議證據 #1「承諾在支援期內提供安全更新」 | Part I (2)(c) 講的是產品要「能」用安全更新修漏洞（機制），支援期多長、承諾多久是 Art. 13(8) 與 Annex II 7。 | Art. 13(8)（支援期至少 5 年）；Annex II 7 | 移到 A2.7（或 Art. 13 群組的支援期控制項）；I.2.c 只留機制類證據 |

---

## 2. AO 之間重疊或互斥（含跨控制項）

| 編號 | 控制項／AO | 重疊對象 | 問題 | 建議 |
|---|---|---|---|---|
| M2-1 | I.2.c（自動安裝安全更新） | II.7（安全發送更新、適用時自動發送）、A2.8 [e]（說明如何關閉自動更新） | 三處都要「自動更新」的證據。I.2.c#3 截圖、II.7#4 設定，實際是同一畫面。 | 分工：I.2.c＝產品端（預設開啟、可退出、可延後、會通知）；II.7＝發送端（簽章、雜湊、發送管道）；A2.8 [e]＝給使用者的說明文字。II.7#4 刪除，改「見 I.2.c」 |
| M2-2 | II.4（公開已修漏洞，附通告） | II.8（附通告訊息發送更新） | II.4#3「安全通告範例」與 II.8#2「通告訊息範例」是同一份通告。 | 一份通告兩條共用：II.4 看「公開內容五要素」，II.8 看「隨更新發給使用者、含使用者該做的動作」。建議證據寫明同一份即可 |
| M2-3 | I.1 [d]（風險評估持續更新） | II.3#4（重大變化與每次發版的重新評估風險紀錄） | 同一份紀錄掛兩處。 | II.3#4 刪除，II.3 只留測試與審查；重新評估歸 I.1 [d]（或 Art. 13 群組） |
| M2-4 | I.2.l [b]（紀錄防竄改） | I.2.f（資料完整性） | 紀錄也是「儲存的資料」，防竄改屬 I.2.f 完整性範圍；I.2.l 法條沒有防竄改。 | I.2.l [b] 刪除，改在 I.2.f 建議證據加一點「稽核紀錄的防竄改」；或保留但標明依據是 ENISA 3.1.12 而非法條（決策者裁） |
| M2-5 | I.2.d [c]（偵測並回報可能的未授權存取） | I.2.l [c]（監控記錄的內部活動） | 回報未授權存取通常來自監控告警，兩者的證據（告警規則、通知範例）重複。 | I.2.d [c] 留著（法條字面要求），I.2.l [c] 證據寫「與 I.2.d [c] 同一套告警可共用」 |
| M2-6 | I.2.d [a]（有存取控制機制） | I.2.d [b]（管理功能與受保護資料只給已授權者） | [b] 是 [a] 做得好的結果，兩者無法分開判：有 [b] 就一定有 [a]。 | 合併成一條，證據＝設計＋授權測試；或 [a] 改成「機制已設計」、[b] 改成「授權測試通過」讓兩者可分開判 |
| M2-7 | I.2.m（永久刪除資料與設定） | A2.8 [d]（說明安全停用與刪除使用者資料） | 一個是功能、一個是說明，不算重疊；但 I.2.m#4「與 A2.8(d) 一致」把兩者綁成同一證據。 | I.2.m#4 刪除（不是證據）；兩條各交各的 |
| M2-8 | II.5（CVD 政策） | II.6（漏洞通報聯絡處）、A2.2（單一聯絡點與 CVD 政策位置） | 三條都要「聯絡點＋政策網址」。 | 分工：II.5＝政策內容與執行紀錄；II.6＝聯絡管道真的存在、可用；A2.2＝使用者資訊有寫出來。聯絡點與網址本身系統已有（①），三條共用 |
| M2-9 | I.2.a#1（上市前弱點評估報告） | II.1#4（SBOM 比對已知漏洞）、II.3#2（測試報告） | 同一批掃描報告三處都要。 | I.2.a＝「上市版本」那一刻的結果與放行紀錄；II.1＝元件清冊與漏洞清單；II.3＝定期執行紀錄。建議證據註明可共用同一份 |

---

## 3. AO 與條文不對（AO 要的條文沒講，或條文講的沒拆到）

| 編號 | 控制項／AO | 問題 | 依據 | 建議 |
|---|---|---|---|---|
| M3-1 | I.1 [c] (obj.5) | 只要求判定「適用與否」與「不適用理由」，漏了 Art. 13(3) 的另一半：**適用的要寫「如何實作」**。 | Art. 13(3)「…whether and, if so in what manner, … are applicable … and how those requirements are implemented」 | 改句：「已逐條判定 Part I (2)(a)～(m) 是否適用；適用者已說明如何實作，不適用者已記錄理由。」 |
| M3-2 | I.1（整條） | Part I (1) 的核心是「**依風險**做到適當水準」，4 個 AO 沒有一個檢查「每個風險都有對應措施」，風險評估與控制項之間斷線。 | Part I (1)「based on the risks」；Art. 13(2)「take the outcome of that assessment into account」 | I.1 新增一個 AO：「已識別的每個風險都有對應的處理方式（措施、接受或轉移），並對應到 Part I (2) 的控制項。」系統風險表已有「對應控制項」欄，可直接當證據（①） |
| M3-3 | I.2.b [b] (obj.4) 初始帳密 | 法條沒有「初始帳密」字眼，是我們把 ENISA 的子要求解釋進「預設安全設定」。 | Part I (2)(b) 只寫 secure by default configuration；ENISA 3.1.3 | 可保留，但依據欄要註明「ENISA 解釋」，顧問可能要求併回 [a] |
| M3-4 | I.2.b [c] (obj.5) | AO 寫「reset to its original **secure** state」，法條是「original state」，多一個字。 | Part I (2)(b) | 改回「original state」，安全與否由 [a] 管 |
| M3-5 | I.2.l [b] (obj.4) 紀錄防竄改 | 法條沒講紀錄要防竄改；Basis 欄掛「provide security related information」是硬掛。 | ENISA 3.1.12 才有 | 見 M2-4，建議移到 I.2.f |
| M3-6 | II.2 [a] (obj.3) | 「依嚴重度訂修補期限」是實務做法，法條只說「依風險、不延遲」。 | Part II (2) | 可保留（[b] 的「不延遲」要靠它才能判，見 M4-7），依據欄註明「實務」 |
| M3-7 | II.2 [b] (obj.4) | 「包含第三方元件的漏洞」法條 Part II (2) 沒寫。 | Art. 13(5)(6) | 保留，依據欄補 Art. 13(6) |
| M3-8 | II.1#3 | 供應商與第三方元件的安全評估，Part II (1) 沒要求（它只要求找出並記錄漏洞與元件、做 SBOM）。 | Art. 13(5) 整合第三方元件的盡職調查 | 保留，依據改 Art. 13(5)；開 Art. 13 群組時移過去 |
| M3-9 | （框架缺） | **Art. 14 通報義務整份框架沒有**：被利用的漏洞與重大事件要在 24 小時預警、72 小時通報、14 天或一個月內交最終報告，送國家 CSIRT 與 ENISA。 | Art. 14(1)～(5) | 新增控制項（見調整草案 N-4），AO 至少三個：有通報程序與時限、重大事件判定標準、通報紀錄 |
| M3-10 | A2.7、I.2.c | 支援期的法定要求沒進 AO：**至少 5 年**、**結束日至少寫到年月並在購買時清楚告知**、**每個安全更新發布後至少保存 10 年**、可行時到期要通知使用者。 | Art. 13(8)(9)(19) | A2.7 改成拆 AO，或在 Art. 13 群組新增支援期控制項（見 N-2） |
| M3-11 | A2.2 | 單一聯絡點要讓使用者**自選聯絡方式、不能只有自動化工具**（例如只有聊天機器人不行），AO 與證據都沒檢查。 | Art. 13(17) | A2.2 建議證據加一點：「聯絡點提供的聯絡方式清單，至少一種非自動化」 |
| M3-12 | Annex II 整組 | 使用者資訊要**用使用者與主管機關看得懂的語言**、清楚易讀、**保存至少 10 年**，九條都沒檢查。 | Art. 13(16)(18) | Annex II 群組加一個共通 AO，或掛在 A2.8：「使用者資訊以目標市場語言提供，並保存至少 10 年」 |

---

## 4. 可判定性（能不能單獨判「有／沒有」）

25 個 AO 逐條看，下列 8 項判不了或判了也沒意義，其餘 17 個可判。

| 編號 | 控制項／AO | 問題 | 建議改句 |
|---|---|---|---|
| M4-1 | I.1 [b] (obj.4)「cybersecurity is addressed at each step」 | 「addressed」沒有標準，交一份流程說明就算有，無從判沒有。 | 「已訂安全開發流程，且本次上市版本有依流程執行的紀錄（設計審查、程式碼審查、安全測試）。」 |
| M4-2 | I.1 [d] (obj.6)「reviewed and updated across the lifecycle」 | 沒有觸發條件與頻率，任何時間點都無法判斷是否「已更新」。 | 「每次發版與威脅情勢有重大變化時已重新評估，最近一次評估日期晚於最近一次發版。」 |
| M4-3 | I.2.b [b] (obj.4)「cannot be guessed」 | 「猜不到」是絕對說法，無法證明；且「出廠沒帶帳密」的產品此題無從回答。 | 「出廠帶初始帳密者，帳密為每台／每次安裝唯一且隨機產生，或首次登入強制變更；不帶者標不適用。」 |
| M4-4 | I.2.d [a]／[b] | [b] 成立 [a] 一定成立，[a] 單獨判沒有意義（見 M2-6）。 | [a]「已設計存取控制機制（驗證、身分與權限管理）」；[b]「授權測試顯示各角色無法越權存取管理功能與受保護資料」 |
| M4-5 | I.2.h [a] (obj.3)「availability … is protected」 | 前提「哪些是基本功能」不在 AO 裡，只藏在建議證據第 1 點；沒清單就無從判。 | 「已列出基本功能，並對其採取抗阻斷服務的措施。」 |
| M4-6 | I.2.l [c] (obj.5)「is monitored」 | 沒說誰、多久、看什麼，交一句「我們有在看」也算。 | 「已定義監控方式（自動告警規則或定期審閱頻率），並有執行紀錄。」 |
| M4-7 | II.2 [b] (obj.4)「without delay」 | 「不延遲」沒有尺度。 | 「漏洞在 [a] 訂的期限內修補完成；逾期者有理由。」（讓 [b] 用 [a] 的期限判） |
| M4-8 | A2.8 [f] (obj.8)、I.2.b [b]、I.2.l [d] | 條件式 AO（「產品會被整合時」「出廠帶帳密時」），句子裡沒寫不適用時怎麼判。 | 統一句尾加「不適用者標不適用並記理由」，與 I.1 [c] 的適用判定接起來 |

---

## 5. 建議證據證明不了那個 AO

| 編號 | 證據點 | 對應 AO | 問題 | 建議 |
|---|---|---|---|---|
| M5-1 | I.1#2 安全開發流程說明 | I.1 [b] | 說明只證明「有規定」，證明不了「每個步驟都做了」。依 2026-10-12 裁示，流程說明屬程序書，不是證據。 | 改：「本版本的設計審查、程式碼審查、安全測試紀錄各一份」；流程說明掛程序書池 |
| M5-2 | I.1#3 適用性聲明 | I.1 [c] | 只寫「哪些適用、不適用理由」，證明不了「適用的如何實作」（M3-1）。 | 改由 SSP 每條控制項的實作說明＋不適用理由自動帶出（①） |
| M5-3 | I.2.b#4 預設設定儲存方式說明 | I.2.b [c] | 設計說明證明不了重設真的回得去；#5 的測試紀錄才是證據。 | #4 降為補充或併入 #5 |
| M5-4 | I.2.c#1 支援期內提供更新的承諾 | （I.2.c 未拆） | 承諾證明的是支援期，不是「能用安全更新修漏洞」（M1-6）。 | 移到 A2.7 |
| M5-5 | I.2.c#4「自動更新的安裝時限」 | （I.2.c 未拆） | 這是一個數值，不是檔案。 | 改：「更新政策或產品設定中寫明的自動安裝時限（文件頁或設定截圖）」 |
| M5-6 | I.2.e#1 演算法清單「確認沒有已淘汰的」 | （I.2.e 未拆） | 沒說依哪份清單判「已淘汰」，誰都能自稱沒有。 | 補基準：「對照的淘汰清單名稱與版本（例如 ECCG 加密機制建議、NIST SP 800-131A）」 |
| M5-7 | I.2.f#4「指令防未授權修改」 | （I.2.f 未拆） | 寫的是主題不是文件。 | 改：「指令通道的驗證設計（例如指令簽章或已驗證的管理連線）與測試紀錄」 |
| M5-8 | I.2.g#3 個資衝擊評估或 GDPR 處理紀錄 | （I.2.g 未拆） | 證明的是 GDPR 合規，不是產品只處理必要資料。 | 標「補充」，主證據是 #1 資料清冊 |
| M5-9 | I.2.h#3 壓力測試報告「若有做」 | I.2.h [a] | 選擇性證據證明不了 AO；[a] 實際只剩 #2 一份設定說明。 | [a] 的主證據要求「抗 DoS 設定＋測試紀錄（壓測或限流測試）」，二擇一不可都缺 |
| M5-10 | I.2.k#4、I.2.m#4 | （未拆） | 一個是「交叉參照其他控制項」，一個是「與 A2.8(d) 一致」，**都不是證據**，是給寫的人看的提醒。 | 刪除，提醒移到控制項說明 |
| M5-11 | I.2.l#2「證明存取或修改有被記錄的證據」 | I.2.l [a] | 循環定義，沒說交什麼。 | 改：「對資料、服務、功能各做一次存取與修改後擷取的紀錄樣本」 |
| M5-12 | II.5#3 政策執行的案件紀錄 | （II.5 未拆） | 新產品可能一件通報都還沒收到，就永遠交不出來。 | 補替代：「尚無外部通報者，交內部演練（模擬通報走完流程）紀錄」 |
| M5-13 | II.6#2 已通知國家 CSIRT 如何聯絡 | （II.6 未拆） | 法條沒這要求（M1-4），交了也不證明 II.6。 | 刪除 |
| M5-14 | A2.5#1 使用者文件列出風險情境 | （A2.5 未拆） | 設計把 A2.5 的落點定為系統風險評估表，但 Annex II 要的是「**隨產品給使用者**」的資訊；內部風險表證明不了使用者有拿到。 | 內容由風險表帶出（①），交付證明是使用者資訊文件那一節（③） |
| M5-15 | A2.1#1、A2.3#1、A2.4#1、A2.7#1 | （A2 未拆） | 同上：系統欄位有值，只證明內容存在，不證明有「隨產品提供」。 | 同 M5-14：內容①＋交付證明③（使用者資訊範本產出的那份文件，或產品「關於」頁截圖） |

---

## 6. 證據來源類別

### 判定方式

- **①系統內產生**：客戶在系統其他頁（受評標的的 CRA 欄位、適用判定八題、風險評估頁、資訊系統版本子表、SSP 參與單位的製造商與漏洞通報聯絡人、SSP 網址欄、每條控制項的實作狀態與不適用理由、FR-134 原始碼掃描）填完就有。
- **③系統範本產出**：設計已定的五份文件範本（CVD 政策、安全通告、支援期聲明、Annex II 使用者資訊、更新與停用程序）填完產出。
- **②客戶自有檔上傳**：其餘，客戶自己的設計文件、測試報告、截圖、紀錄。
- 混合來源標兩個（例：①③＝內容系統裡有，但「有隨產品交給使用者」的證明要用範本產出的文件）。逐點標記見對照表 Excel「證據來源類別」欄。

### 統計

| 類別 | 主要來源點數 | 有涉及的點數 | 集中在 |
|---|---|---|---|
| ① 系統內產生 | 15 | 16 | I.1#1#3、II.1#1#4、II.4#2、II.5#1、II.6#1、A2.1～A2.7、A2.9 |
| ③ 系統範本產出 | 14 | 20 | A2.8 全部 6 點、II.2#1、II.4#3、II.5#1#2、II.8#2#3、I.2.c#1 |
| ② 客戶自有檔上傳 | 85 | 88 | I.2.a～I.2.l 大部分、II.2～II.8 的紀錄類 |
| 不是證據 | 2 | 2 | I.2.k#4、I.2.m#4 |

### 問題

| 編號 | 問題 | 建議 |
|---|---|---|
| M6-1 | 16 點①仍寫成要客戶提供的檔案（例 A2.3#1「標籤、關於頁、文件頁」、I.1#1「風險評估」、II.1#1「SBOM」）。客戶會把系統畫面截圖或匯出再上傳回來，兩份真相。 | 建議證據改寫為「系統帶入：〇〇頁的〇〇欄」；準備期工作畫面直接顯示該欄目前的值，不開上傳。需要平台支援「系統資料當證據」，本期沒有的先在建議證據註明「由系統帶入，待功能上線」 |
| M6-2 | I.2.a#1、II.1#1、II.1#4 屬 FR-134 原始碼掃描的產出，但「SBOM 轉證據」已裁為本期範圍外（D14）。 | 建議證據先寫「FR-134 掃描結果（匯出 CycloneDX／弱點清單）」，標②；D14 上線後改①。決策者確認此過渡寫法 |
| M6-3 | ③的範本只有五份，A2.8 [a]～[f] 六點都指向「說明文件某章節」，但五份範本中只有「Annex II 使用者資訊」與「更新與停用程序」兩份涵蓋，[b]「變更如何影響資料安全」、[f]「給整合者的資訊」兩節沒有範本章節。 | 文件範本補兩節，或這兩點標② |
| M6-4 | ①的「內容」與「有交給使用者」是兩件事（M5-14、M5-15）：Annex II 要的是隨產品提供，系統欄位有值不代表使用者拿到。 | Annex II 的 AO 統一寫成兩段：「內容已填（系統帶入）」＋「已隨產品提供（使用者資訊文件或產品畫面）」 |

---

## 7. 用語一致性

| 編號 | 問題 | 出現處 | 建議 |
|---|---|---|---|
| M7-1 | **兩套編號並存**：AO 句首是畫面字母 [a][b]，建議證據每點前是資料庫編號 [obj.3][obj.4]，客戶看不到 obj 編號，對不起來。共 38 處。 | I.1、I.2.b、I.2.d、I.2.h、I.2.l、II.2、A2.8 的 guidance | guidance 前綴改成 [a][b]；資料庫的對應關係由 sort_order 管，不靠文字 |
| M7-2 | **內部拆分依據外露**：「[beyond ENISA – legal text]」「[beyond ENISA – practice]」共 28 處，寫在給客戶看的建議證據裡。這是我們標「這點 ENISA 沒有、依法條補的」，對客戶無意義，且讓客戶以為這幾點較不重要。 | 21 條控制項的 guidance | 從 guidance 文字移除；依據留在 md 的 Basis 欄或存 part props |
| M7-3 | ENISA 草案編號（3.1.x、Article 10）**沒有**混進資料庫正文，md 的 Basis 欄才有，正常。 | — | 不用改；記錄為已檢查 |
| M7-4 | 「risk assessment」與「cybersecurity risk assessment」混用（21 次中 16 次有 cybersecurity）。 | I.1 [a][d]、I.2.d#3、I.2.j#4、II.3#4 等 | 一律「cybersecurity risk assessment」（法條用語） |
| M7-5 | 「product lifecycle」（I.1 AO）與法條「support period」意思不同：法條要求的是**支援期內**更新評估，不是整個產品生命週期。 | I.1 [d]、I.1#4 | 改「during the support period」 |
| M7-6 | 「Physical products:」開頭，與其他點格式不同，且軟體產品客戶不知道這點能不能跳過。 | I.2.d#3、I.2.j#4 | 改「Where the product includes hardware: …」並在句尾加「(not applicable to software-only products)」 |
| M7-7 | 「the instructions document」「user documentation」「user information」三種說法指同一份 Annex II 使用者資訊。 | A2.2、A2.4、A2.5、A2.7、A2.8 | 統一「the user information (Annex II)」 |
| M7-8 | 「advisory」三種說法：security advisory（II.4）、advisory message（II.8）、advisory sources（II.2，指外部 CERT 通報，意思完全不同）。 | II.2#2、II.4#3、II.8#2 | II.2#2 改「vulnerability alerts from CERTs and CVE databases」，避免與自家通告混淆 |
| M7-9 | 英式拼法（authorise、minimise、prioritise、behaviour）與法條一致，沒有混用美式，正常；控制項標題用 Title Case、AO 用句子，一致。 | — | 不用改；記錄為已檢查 |

---

## 8. 沒拆 AO 的 24 條，用同一判準再掃

**判準**（取自 AO 拆分說明「其餘 24 條不拆」的理由反推）：法條自帶兩件以上**證據不同**的獨立事項，或有條件式例外需要單獨判定 → 該拆。

| 編號 | 控制項 | 法條含幾件事 | 判定 | 建議拆法 |
|---|---|---|---|---|
| M8-1 | **I.2.c** | 5 件：能用安全更新修漏洞／自動更新預設開啟且在期限內安裝／清楚易用的退出機制／通知使用者／可暫時延後 | **該拆**（ENISA 排名第 2） | [a] 漏洞可透過安全更新處理（更新機制含完整性驗證）[b] 適用時自動安全更新預設開啟，並有安裝期限 [c] 有清楚易用的退出機制 [d] 會通知使用者有可用更新 [e] 可暫時延後更新 |
| M8-2 | **I.2.f** | 2 件：保護完整性（資料、指令、程式、設定）／回報損毀 | **該拆**（與 I.2.d 拆出「回報」同理，不拆不一致） | [a] 資料、指令、程式、設定受保護，不被未授權修改 [b] 偵測並回報損毀 |
| M8-3 | **I.2.m** | 2 件：永久刪除所有資料與設定／可轉移時安全轉移（條件式） | **該拆** | [a] 使用者可安全簡便地永久刪除所有資料與設定 [b] 資料可轉移者，轉移過程受保護；不可轉移者標不適用 |
| M8-4 | **II.1** | 2 件：找出並記錄元件（SBOM）／找出並記錄漏洞 | **該拆**（證據來源不同：SBOM 一份、弱點比對一份；且 FR-134 兩者分開產出） | [a] 已以機器可讀格式製作 SBOM，至少涵蓋頂層相依元件 [b] 已找出並記錄產品所含漏洞 |
| M8-5 | **II.4** | 3 件：修補後公開／公開內容五要素／延後公開的例外（條件式） | **該拆**（ENISA 排名第 3） | [a] 安全更新提供後已公開已修漏洞資訊 [b] 公開內容含說明、受影響產品、影響、嚴重度、修補指引 [c] 延後公開者有理由並在使用者可修補後公開 |
| M8-6 | **II.6** | 2 件：提供漏洞通報聯絡地址／促進分享（含第三方元件） | **該拆**（聯絡地址是系統①、分享紀錄是②，來源不同） | [a] 已公布漏洞通報聯絡地址 [b] 已採取措施分享產品及第三方元件的漏洞資訊 |
| M8-7 | **II.8** | 3 件：不延遲發送／免費（客製例外）／附通告與建議動作 | **該拆**（ENISA 排名第 5） | [a] 安全更新不延遲發送 [b] 免費提供，或與企業使用者另有約定 [c] 附通告說明使用者應採取的動作 |
| M8-8 | A2.7 | 2 件：支援類型／支援期結束日；另加 Art. 13 的 5 年、年月、購買時告知 | 可拆可不拆 | 若不開 Art. 13 群組就拆：[a] 已說明支援類型 [b] 結束日至少到年月，購買時清楚告知 |
| M8-9 | I.2.a | 1 件，但隱含「依 SBOM 與掃描找出漏洞」與「放行判定」兩步 | 可拆可不拆 | 不拆；證據寫清楚「放行紀錄」為主證據即可 |
| — | I.2.e、I.2.g、I.2.i、I.2.j、I.2.k、II.3、II.5、II.7、A2.1～A2.6、A2.9 | 1 件，或多件但證據是同一份 | 不拆 | 維持；II.7 依 M2-1 刪掉自動發送那點後只剩一件事。A2.1 雖列多個欄位，但都在同一份使用者資訊，不拆 |

---

## 建議的 AO 調整草案（逐條）

動作代號：**移**＝搬到別的控制項／**合**＝合併／**拆**＝新拆／**刪**／**改**＝改句／**新**＝新增。英文句供直接進資料庫，中文為意思。

### 一、既有 25 個 AO

| 控制項 | 現 AO | 動作 | 建議句（英） | 中文 | 對應矛盾 |
|---|---|---|---|---|---|
| I.1 | [a] obj.3 | 移 | → N-1 [a] | 已有書面風險評估，涵蓋用途、可預見使用、使用條件、預期使用期間 | M1-1 |
| I.1 | [b] obj.4 | 改（留在 I.1） | a secure development process is defined, and records show it was followed for the released version (design review, code review, security testing). | 已訂安全開發流程，且本版有依流程執行的紀錄 | M4-1 |
| I.1 | [c] obj.5 | 移＋改 | → N-1 [b] | 已逐條判定適用性；適用者說明如何實作，不適用者記理由 | M1-2、M3-1 |
| I.1 | [d] obj.6 | 移＋改 | → N-1 [c] | 支援期內每次發版與重大變化時已重新評估 | M1-3、M4-2 |
| I.1 | — | 新 | each identified cybersecurity risk has a recorded treatment and is mapped to the Part I (2) requirements that address it. | 每個已識別的風險都有處理方式，並對應到 Part I (2) 控制項 | M3-2 |
| I.2.b | [a] obj.3 | 留 | （不改） | | |
| I.2.b | [b] obj.4 | 改 | where the product ships with initial credentials, they are unique per device or installation and randomly generated, or must be changed at first use; otherwise marked not applicable. | 帶初始帳密者唯一且隨機或首次強制變更；不帶者標不適用 | M3-3、M4-3 |
| I.2.b | [c] obj.5 | 改 | the product can be reset to its original state. | 可重設回原始狀態 | M3-4 |
| I.2.d | [a] obj.3 | 改 | control mechanisms against unauthorised access (authentication, identity or access management) are designed and implemented. | 已設計並實作存取控制機制 | M2-6、M4-4 |
| I.2.d | [b] obj.4 | 改 | authorisation testing shows that each role cannot access administrative or configuration functions, or personal or protected data, beyond its permissions. | 授權測試顯示各角色無法越權 | M2-6、M4-4 |
| I.2.d | [c] obj.5 | 留 | （不改） | | M2-5 |
| I.2.h | [a] obj.3 | 改 | the essential and basic functions are listed, and denial-of-service resilience and mitigation measures protecting them are in place and tested. | 已列出基本功能，抗 DoS 措施已就位並測試 | M4-5、M5-9 |
| I.2.h | [b] obj.4 | 留 | （不改） | | |
| I.2.l | [a] obj.3 | 留 | （不改） | | |
| I.2.l | [b] obj.4 | 刪（或留，決策者裁） | 移到 I.2.f 建議證據 | 紀錄防竄改併入完整性 | M2-4、M3-5 |
| I.2.l | [c] obj.5 | 改 | the way recorded activity is monitored (alert rules or review frequency) is defined, and records show it is carried out. | 已定義監控方式並有執行紀錄 | M4-6 |
| I.2.l | [d] obj.6 | 留 | （不改） | | |
| II.2 | [a] obj.3 | 留（依據註「實務」） | （不改） | | M3-6 |
| II.2 | [b] obj.4 | 改 | vulnerabilities, including those in third-party components, are remediated within the deadlines defined in [a], including by providing security updates; overdue cases have a recorded reason. | 漏洞在 [a] 期限內修補，逾期有理由 | M3-7、M4-7 |
| II.2 | [c] obj.5 | 留 | （不改） | | |
| A2.8 | [a]～[e] obj.3～7 | 留 | （不改） | | |
| A2.8 | [f] obj.8 | 改 | where the product is intended for integration into other products, the information the integrator needs to comply with Annex I and Annex VII is provided; otherwise marked not applicable. | 句尾加「不適用者標不適用」 | M4-8 |

### 二、新拆的 7 條（AO 句見第 8 節，英文如下）

| 控制項 | 建議 AO（英） |
|---|---|
| I.2.c | [a] vulnerabilities can be addressed through security updates, verified for integrity and authenticity before installation. [b] where applicable, automatic security updates are enabled by default and installed within a stated timeframe. [c] a clear and easy-to-use opt-out mechanism for automatic updates is available. [d] users are notified of available updates. [e] users can temporarily postpone updates. |
| I.2.f | [a] stored, transmitted or processed data, commands, programs and configuration are protected against modification not authorised by the user. [b] corruptions are detected and reported. |
| I.2.m | [a] users can securely and easily remove all data and settings on a permanent basis. [b] where data can be transferred to other products or systems, the transfer is done in a secure manner; otherwise marked not applicable. |
| II.1 | [a] a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies, is drawn up for each released version. [b] vulnerabilities contained in the product are identified and documented. |
| II.4 | [a] once a security update is available, information about the fixed vulnerabilities is publicly disclosed. [b] the disclosure includes a description, affected product identification, impact, severity and remediation guidance. [c] where disclosure is delayed, the justification is recorded and disclosure follows once users could apply the patch. |
| II.6 | [a] a contact address for reporting vulnerabilities is published. [b] measures are taken to share information about potential vulnerabilities in the product and its third-party components. |
| II.8 | [a] available security updates are disseminated without delay. [b] security updates are provided free of charge, or other terms agreed with the business user for a tailor-made product are documented. [c] security updates are accompanied by advisory messages stating the action users should take. |

### 三、建議新增（Article 13／14，需決策者裁要不要開新群組）

| 代號 | 控制項 | 建議 AO（英） | 法源 |
|---|---|---|---|
| N-1 | Cybersecurity Risk Assessment | [a] a cybersecurity risk assessment is documented, covering the intended purpose, reasonably foreseeable use, conditions of use and the expected time in use, with a version and an assessment date. [b] for each requirement in Annex I Part I (2)(a)–(m), the assessment states whether it applies and, if so, how it is implemented; a justification is recorded for each requirement that does not apply. [c] the assessment is updated during the support period, at least for each release and each relevant change in threats or vulnerabilities. | Art. 13(2)(3)(4)(7) |
| N-2 | Support Period | [a] the support period is at least five years, or matches the expected use time where shorter, and the information used to determine it is recorded. [b] the end date (at least month and year) is clearly stated at the time of purchase. [c] each security update remains available for at least 10 years or the rest of the support period, whichever is longer. | Art. 13(8)(9)(19) |
| N-3 | Third-Party Component Due Diligence | [a] due diligence is exercised when integrating third-party components, including open-source components. [b] vulnerabilities found in an integrated component are reported to its maintainer. | Art. 13(5)(6) |
| N-4 | Reporting of Exploited Vulnerabilities and Severe Incidents | [a] a procedure is in place to notify actively exploited vulnerabilities and severe incidents to the coordinating CSIRT and ENISA via the single reporting platform, within 24 hours (early warning), 72 hours (notification) and the final-report deadline. [b] criteria for classifying an incident as severe are defined. [c] notification records are kept. | Art. 14(1)～(5) |

---

## 附：Article 13 各項與 Annex I／II 條文對應

| Art. 13 項 | 內容（白話） | 對應框架控制項 | 現況 |
|---|---|---|---|
| (1) | 上市時產品要符合 Annex I Part I | I.1、I.2.a～m | 有 |
| (2) | 要做風險評估，並在規劃、設計、開發、生產、交付、維護各階段納入結果 | I.1 [a][b] | 有，但掛在 Part I (1)（M1-1） |
| (3) | 風險評估要有文件、支援期內更新；最少要涵蓋什麼；要寫 Part I (2) 各項是否適用、如何實作 | I.1 [a][c][d] | 有，但掛錯、漏「如何實作」（M1-2、M3-1） |
| (4) | 風險評估放進技術文件；不適用要寫明確理由 | I.1 [c] | 有（M1-2） |
| (5) | 整合第三方元件（含開源）要盡職調查 | II.1#3 | 只有一點證據（M3-8），無 AO |
| (6) | 發現元件漏洞要通報元件維護者，並分享修補 | II.6#3 | 只有一點證據（M1-5），無 AO |
| (7) | 系統化記錄資安相關面向，含已知漏洞與第三方資訊；適時更新風險評估 | I.1 [d] | 部分 |
| (8) | 支援期內有效處理漏洞（依 Part II）；支援期至少 5 年；決定依據放技術文件；要有含 CVD 的處理政策 | II.1～II.8、II.5、A2.7 | Part II 有；**5 年與決定依據沒有**（M3-10） |
| (9) | 每個安全更新發布後至少保存 10 年或到支援期結束 | — | **沒有**（M3-10） |
| (10) | 軟體產品後續大改版，可只對最新版遵循 Part II (2)，前提是舊版用戶可免費升級 | — | 沒有；屬例外，可在 II.2 建議證據加一點 |
| (11) | 可保留歷史版本存檔，但要告知使用不受支援軟體的風險 | — | 沒有；選擇性，不必新增 |
| (12) | 上市前備妥技術文件、做符合性評估、出 EU 符合性聲明、貼 CE 標誌 | A2.6（只有聲明網址） | 整體流程不在框架範圍（屬 Annex VII／VIII） |
| (13) | 技術文件與聲明保存 10 年或支援期較長者 | — | 沒有 |
| (14) | 量產產品要有維持符合性的程序 | — | 沒有 |
| (15) | 產品要有型號、批號或序號等識別 | A2.3 | 有（Annex II 3） |
| (16) | 製造商名稱與聯絡方式標示在產品、包裝或隨附文件，也要放進 Annex II 資訊 | A2.1 | 有；語言要求沒檢查（M3-12） |
| (17) | 指定單一聯絡點，使用者易找到、可自選聯絡方式、不能只有自動化工具 | A2.2、II.6 | 有；「不能只有自動化」沒檢查（M3-11） |
| (18) | 隨產品附 Annex II 資訊，語言易懂、清楚易讀，保存 10 年 | A2.1～A2.9 | 內容有；語言與保存沒檢查（M3-12） |
| (19) | 支援期結束日至少到年月、購買時清楚告知；可行時到期通知使用者 | A2.7 | 只有「寫出結束日」，**年月與購買時告知沒有**（M3-10） |
| (20) | 附 EU 符合性聲明或簡化版（含完整版網址） | A2.6 | 有 |
| (21) | 知道不符合時立即矯正、撤回或召回 | — | 沒有 |
| (22) | 主管機關要求時提供文件並配合 | — | 沒有；屬程序，不必新增 |
| (23) | 停業前通知主管機關與使用者 | — | 沒有；屬程序，不必新增 |
| (24)(25) | 執委會訂 SBOM 格式；ADCO 可要求提供 SBOM | II.1 | 不是製造商義務，不必新增 |
| Art. 14(1)～(5) | 被利用漏洞與重大事件 24 小時／72 小時／最終報告通報 CSIRT 與 ENISA | — | **整份框架沒有**（M3-9） |