寫在前面

這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。

CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。

今天會一起談到 CRA、NIS2、RED Cybersecurity 與 ISO/IEC 27001。篇幅有限，我不打算逐條比較各項要求，而是想分享我目前怎麼區分這幾套經常被放在一起討論的制度。

做 CRA 一段時間後，我發現大家很容易問同一類問題

Day 24 談到 ISO/IEC 27001 與 CRA 的關係後，其實很自然會延伸出另一個問題：

「那 CRA、NIS2、RED Cybersecurity、ISO 27001 到底有什麼不同？」

例如有人會問：「公司已經有 ISO 27001，為什麼還要 CRA？」也有人會問：「是不是 NIS2 做完就好了？」甚至還會碰到：「產品已經符合 RED Cybersecurity，CRA 還需要做嗎？」

第一次碰到這些問題，我自己也會覺得有點混亂，因為大家都在談 Cybersecurity（網路安全）、Risk Management（風險管理）、Vulnerability（漏洞）、Incident（事件）、Supply Chain（供應鏈）與 Reporting（通報），看起來好像都在做差不多的事情。

但後來我慢慢找到一個自己比較容易理解的方法：

先不要急著逐條比較 Control，而是先問：「它到底在管誰？又在管什麼？」

如果先非常簡化地區分，我自己會把 CRA 的主角想成 Products with Digital Elements（具數位元素產品），主要關注 Product Cybersecurity（產品資安）；NIS2 的主角則是適用範圍內的 Essential / Important Entities（基本／重要實體），比較偏向 Organization / Service Cyber Resilience（組織／服務網路韌性）。

RED 的出發點是 Radio Equipment（無線電設備），屬於無線電設備的 Product Compliance 世界；ISO/IEC 27001 則是以 Organization 或定義的 ISMS Scope 為範圍，建立 Information Security Management System（資訊安全管理系統）。

這當然只是很簡化的第一層理解，但對我而言已經很有幫助。尤其 CRA 跟 NIS2 雖然都跟 EU Cybersecurity Framework 有關，兩者的出發點其實不太一樣。

CRA：我會先想到「這個 Product 安不安全？」

CRA 前面已經談過很多，它主要關注 Products with Digital Elements。

因此 Manufacturer（製造商）需要思考 Product Cybersecurity Risk Assessment（產品資安風險評估）、Secure by Design / Default（安全設計／預設安全）、Vulnerability Handling（漏洞處理）、Security Updates（安全更新）、Support Period（支援期間）、Technical Documentation（技術文件）、Conformity Assessment（符合性評估）與 CE Marking（CE 標誌）等議題。

如果要讓我用一句很簡化的話描述 CRA，我會說它在問：

「你放到 EU Market 的這個數位產品，在整個生命週期中是否持續符合適用的 Cybersecurity Requirements？」

也就是說，CRA 的視角會一路跟著 Product，從 Planning、Design、Development、Release，一直到 Maintenance、Vulnerability Handling 與後續 Support。

這也是為什麼 Day 24 我會一直強調：

CRA 的主角是 Product。

NIS2：我會先想到「這個 Organization 能不能持續安全營運？」

到了 NIS2，視角就不太一樣。

NIS2 主要針對其適用範圍內特定 Sector（產業）與 Entity（實體），包括 Essential Entities 與 Important Entities，要求組織採取適當且相稱的 Cybersecurity Risk-management Measures（網路安全風險管理措施），並對符合條件的 Incident 履行相應的 Reporting Obligation（通報義務）。

因此，如果 CRA 讓我先想到 Product Cybersecurity，那 NIS2 我會先想到 Organization / Service Cyber Resilience。

也就是組織所提供的重要服務，在面對 Cyber Threat（網路威脅）與 Incident 時，有沒有足夠的 Risk Management、Incident Handling、Business Continuity（營運持續）、Supply Chain Security 等能力。

所以兩者雖然都在談 Cybersecurity，但看的層次並不完全相同。

所以同一家公司，有可能 CRA 跟 NIS2 都適用

這點我自己覺得非常重要。

不要把它理解成 CRA 或 NIS2，有些情況反而可能是 CRA 加上 NIS2。

例如某家公司本身屬於 NIS2 適用範圍內的 Entity，因此 Organization Level（組織層級）的 Cybersecurity Risk Management 與 Incident Reporting 等事項需要評估 NIS2 要求。

同時，這家公司又製造 Products with Digital Elements，並將 Product 放到 EU Market，那些 Product 又可能需要評估 CRA。

因此我自己會先這樣切：

Organization Level → 先想到 NIS2。

Product Level → 先想到 CRA。

這當然只是方便理解的第一層分類，實際 Applicability（適用性）還是要回到各法規的 Scope、Entity、Product、Sector 與其他條件判斷。

但至少可以先理解一件事：同一家公司，完全有可能同時站在兩個不同的 Regulatory Perspective（法規視角）接受要求。

舉一個我自己覺得比較容易理解的例子

假設 Company A 生產某種 Digital Product。

Company A 自己的 ERP、Email、Network、Production Environment、Corporate Incident Response、Business Continuity、Supply Chain Cybersecurity 等，比較屬於 Organization Cybersecurity Governance（組織網路安全治理）的世界。

如果 Company A 本身屬於 NIS2 適用 Entity，就需要進一步評估相關 NIS2 Obligations。

但 Company A 賣到 EU 的 Product，則要另外問：

「這個 Product 是否落入 CRA Scope？」

如果答案是 Yes，後面看的就會是 Product Risk、CRA Annex I Requirements、Vulnerability Handling、Technical Documentation、Support Period、Conformity Assessment 等 Product-level Requirements。

所以，同一家公司，可以同時存在 Organization Security 與 Product Security 兩個不同視角。

這也是我自己開始理解 CRA 與 NIS2 差異之後，覺得很重要的一個概念。

那 ISO 27001 放在哪裡？

Day 24 剛談過，我自己會把 ISO/IEC 27001 放在 Management System（管理系統） 這個位置。

它提供 Risk Management、Policy、Roles & Responsibilities（角色與責任）、Supplier Security、Incident Management、Audit、Management Review 與 Continual Improvement 等管理機制。

因此 ISO 27001 跟 NIS2 在 Organization Security Governance 上，確實有不少可以互相支援的地方；跟 CRA 也可以共用很多 Management Capability（管理能力）。

例如，公司已經有 Incident Management，CRA 可以在既有機制上延伸 Product Security / PSIRT 與 Article 14 Assessment；公司已有 Supplier Management，可以再延伸到 Third-party Product Component（第三方產品元件）；公司已有 Risk Management，可以延伸到 Product Cybersecurity Risk Assessment；公司已有 Internal Audit，也可以考慮逐步納入 Product Security Process Review。

所以我目前的理解一直是：

ISO 27001 對 CRA 很有幫助，但 ISO 27001 Certified ≠ CRA Compliant Product。

因為 ISO 27001 不會自動替 Product 完成 CRA Classification、Annex I Conformity、Technical Documentation、Conformity Assessment 或 CE。

RED 又是另外一個 Product Compliance 世界

RED 是 Radio Equipment Directive（無線電設備指令），所以它的 Scope 首先跟 Radio Equipment 有關。

例如 Wi-Fi、Bluetooth、Wireless IoT 等具無線電功能的設備，在符合 RED 適用條件時，就會進入這套 EU Product Compliance Framework。

也因此，做過 RED 的 Product Compliance Team，對 Conformity Assessment、EU Declaration of Conformity（EU DoC，歐盟符合性聲明）、CE Marking 等概念通常不會完全陌生。

而 RED Article 3(3) 中部分要求又涉及 Cybersecurity-related Requirements，例如 Network Protection（網路保護）、Personal Data / Privacy（個人資料／隱私）與 Fraud Protection（詐欺防護）等。

這也是為什麼 CRA 出來後，企業很自然會問：

「那 RED Cybersecurity 跟 CRA 是不是重複了？」

這時我不太敢直接回答「做過 RED，CRA 就不用做」

這類問題，我自己現在會特別小心。

因為 CRA 並不是完全不考慮既有 EU Product Legislation（歐盟產品法規），它本身就存在與其他 Union Harmonisation Legislation（歐盟協調法規）之間的銜接設計。

因此，如果一個 Product 已經受到 RED Cybersecurity Requirements 管理，我自己不會直接下結論說：「CRA 完全不用管。」但我也不會看到兩套 Regulation，就直接認定所有事情都要重新做兩次。

比較合理的方式，還是回到 Product Scope、Applicable Requirements（適用要求）、既有 Conformity Evidence（符合性證據）、適用的 Transitional Provision（過渡條款），以及當時最新的 EU Guidance / Standards 進行判斷。

尤其這一塊涉及 Product-specific Applicability，我自己會把它留給實際產品情境逐案分析，而不是只靠一句：

「我們 RED 做過了。」

就結束 CRA Assessment。

我現在會用「Organization vs Product」先切第一刀

遇到一個 Cybersecurity Requirement，我現在會先問：

「它主要是在保護 Organization，還是在保護 Product？」

例如 Corporate Email Phishing（企業郵件釣魚），我會先想到 ISO 27001 / NIS2；Product Default Password（產品預設密碼）與 Product SBOM（產品軟體物料清單），我會先想到 CRA；Corporate Business Continuity（企業營運持續），比較容易聯想到 ISO 27001 / NIS2；Product Vulnerability Handling（產品漏洞處理），則會先想到 CRA；如果是 Wireless Product Radio Compliance（無線產品法規符合性），則會先想到 RED。

這當然不是正式的 Legal Applicability Test（法規適用性判定），只是我自己覺得很好用的第一層分類方式。

先把「主角」找出來，後面的 Requirement 通常就比較不容易混在一起。

Incident Reporting 是我覺得最容易混淆的地方之一

因為大家都叫 Incident Reporting（事件通報），但實際上 Reporting Trigger（通報觸發條件）不一定一樣。

例如 NIS2 關心的是符合適用條件的 Entity 所發生的 Significant Incident（重大事件）；CRA 則有自己針對 Product Security 的 Reporting Obligations，例如 Actively Exploited Vulnerability（遭主動利用的漏洞），以及 Severe Incident Having an Impact on the Security of the Product（對產品安全造成影響的嚴重事件）。

所以雖然中文都可以叫「資安事件通報」，但 Trigger 不完全相同、Subject 不完全相同，適用的 Reporting Requirement 也不完全相同。

而 CRA Article 14 Reporting Obligations 將從 2026 年 9 月 11 日開始適用。

這也是為什麼我自己不會直接把既有 Corporate Incident Reporting SOP 換個標題，就說：

「CRA Article 14 完成。」

甚至同一個 Incident，可能要從不同法規角度一起判斷

假設某個 Product Vulnerability 被實際 Exploit，同時又造成 Manufacturer 自己的 Network 或 Service 發生重大 Cyber Incident。

這時 Product Side 可能需要評估 CRA；Organization Side 如果公司又屬於 NIS2 Scope，也可能需要進一步評估 NIS2，甚至實務上還可能同時涉及其他 Regulatory Requirement。

所以如果是我，我不太希望建立兩套完全不知道彼此存在的 Incident Team，而會比較希望朝一個共同入口的方向設計。

事件先從 Single Incident Intake（單一事件入口） 進來，再進行 Multi-regulation Assessment（多法規適用性評估），判斷這次事件可能涉及 CRA、NIS2、GDPR 或其他 Requirement，最後才依實際適用的法規進入後續處理與 Reporting。

我覺得這樣比較接近大型企業真正需要的 Incident Governance。

這也是為什麼 Legal / Compliance Mapping 很重要

Security Team 很容易專注在 Incident 本身：發生什麼？影響什麼？Severity 多高？怎麼 Contain？怎麼 Fix？

但 Regulatory Reporting 還要回答另一組問題：是哪一個 Legal Entity（法律實體）？哪個 Product？哪個 Country？適用哪個 Regulation？應該向哪個 Authority（主管機關）通報？Deadline 又是什麼？

所以 CRA Article 14 Process 如果完全跟 Corporate Regulatory Incident Process 分開，我自己會覺得有點可惜。

比較理想的方式可能是由 Security / PSIRT 負責 Technical Assessment，再由 Compliance / Legal 判斷 Regulatory Applicability，最後串成同一個 Escalation Mechanism（升級機制）。

這也再次回到前幾天一直談的事情：

CRA 很難只靠 Security Team 自己完成。

那這幾套制度到底可以共用哪些東西？

這可能才是企業真正關心的問題。

我自己不會先找 Common Requirement，反而比較喜歡先找 Common Capability（共通能力）。

例如 Risk Management、Incident Management、Vulnerability Management、Supplier Security、Access Control、Change Management、Training、Audit、Evidence Management 與 Management Review。

這些 Capability 不一定需要因為來了四套不同的 Regulation，就各做四次。

但這裡有一個很重要的前提：

Process 可以共用，不代表 Risk Context 與 Evidence 可以直接共用。

例如大家都叫 Supply Chain Security，但看的 Risk 不一樣

這是我自己覺得很好理解的例子。

Corporate ISMS 做 Supplier Security，可能很關心 Supplier 能不能安全存取公司的 Information Asset；NIS2 的 Supply Chain Security，可能會進一步關注 Supply Chain 對 Organization / Service Resilience 的影響；到了 CRA，則可能變成 Third-party Component 是否影響 Product Cybersecurity。

三個都可以叫 Supply Chain Security，但它們背後的 Risk Context（風險情境）並不完全一樣。

所以我現在比較喜歡的方式是：

共用 Process Framework，但保留不同的 Risk Context 與 Evidence。

這樣才不會為了 Integration（整合），反而把真正需要證明的 Product-specific Evidence 弄不見了。

如果不用表格，我會怎麼做 Regulatory Mapping？

我還是會做 Regulatory Mapping，只是不一定需要把所有東西塞進一張 Matrix 才能理解。

例如 Organization Risk Management，我會認為 ISO 27001 與 NIS2 的關聯最直接，而 CRA、RED 則可能因產品與法規情境而涉及。

到了 Product Cybersecurity Risk，CRA 與 RED 的 Product Compliance 視角就會更明顯；ISO 27001 與 NIS2 雖然可能提供 Risk Management 的底層能力，但不能因此直接取代 Product-level Assessment。

Incident Management、Supplier Security 這些能力，四套制度之間都可能存在不同程度的關聯；但到了 Product Vulnerability、SBOM，CRA 的 Product Security 特性就更突出。

再往後走到 Conformity Assessment 與 CE Marking，則明顯進入 CRA、RED 這類 EU Product Compliance 的世界，而不是 ISO 27001 或 NIS2 本身要處理的核心內容。

Internal Audit / Review 又是另一個例子。ISO 27001 本身就有成熟的管理系統稽核與審查機制，NIS2 Governance 也可能與組織層級的監督機制產生關聯；到了 CRA 與 RED，則要回到產品符合性、品質管理、技術文件與相關 Product Compliance Mechanism 來看。

這些都只是我自己用來理解制度關係的概念 Mapping，不是正式的 Legal Mapping。

我真正想找的是：

哪些地方可以共用 Capability，哪些地方必須保留 Regulatory-specific 或 Product-specific Requirement。

我現在反而不想建立「CRA Team、NIS2 Team、ISO Team、RED Team」

如果每來一套 Regulation 就成立一套完全獨立的 Team，很可能最後變成 CRA 問 Supplier 一次，NIS2 再問一次，ISO Audit 又問一次；Supplier 收到三份 Questionnaire，內部維護三份 Evidence，然後三個 Team 分別追同一件事情。

這種模式短期可能可以運作，但長期很容易讓 Compliance Cost（合規成本）越來越高。

所以我自己更傾向：

Common Cybersecurity Capability 作為底座，上面再 Mapping 不同 Regulatory Requirements。

例如底層有成熟的 Risk Management、SSDLC、PSIRT、Vulnerability Management、Supplier Security、Incident Management、Evidence Management 與 Governance。

接著再去看 ISO 27001 要用到哪些能力、NIS2 要用到哪些、CRA 要用到哪些、RED 又需要哪些。

這樣同一個成熟 Process 可以支援不同 Compliance Requirement；真正不同的地方，再建立 Specialized Process（專門流程）。

我自己覺得，這比：

「一個 Regulation 蓋一套 Management System」

更有機會長期運作。

Day 25 小結｜不要先問「這四套能不能互相取代」，而是先問「它們各自在管什麼」

研究到 Day 25，我自己最大的心得是：

Cybersecurity Requirement 看起來很像，不代表 Regulatory Objective（法規目的）一樣。

如果很簡化地說，我比較把 ISO/IEC 27001 看成 Information Security Management System；NIS2 比較從 Entity / Service Cyber Resilience 理解；CRA 則比較從 Product Cybersecurity Lifecycle 理解；RED 則屬於 Radio Equipment Product Compliance 的世界。

所以 ISO 27001 不能直接取代 CRA，NIS2 也不能直接取代 CRA；RED Cybersecurity 與 CRA 雖然存在交集與法規銜接，也還是要依 Product、Applicable Requirement、Conformity Evidence 與當時適用的 Transitional Arrangement 個別判斷。

而對企業而言，我現在反而覺得真正有價值的事情，不是為每一套 Regulation 再蓋一套制度，而是先建立成熟、可重複使用的 Cybersecurity Capability，例如 Risk Management、SSDLC、PSIRT、Vulnerability Management、Supplier Security、Incident Management、Evidence Management 與 Governance，再把不同 Regulatory Requirements Mapping 到這些 Capability。

這樣未來即使又出現新的 Regulation，企業也不需要每次都從零開始。

做到這裡，我自己越來越覺得：

真正能長期支撐 Compliance 的，可能不是一張又一張的法規 Checklist，而是一套成熟、可重複使用，而且能留下 Evidence 的 Cybersecurity Capability。

而這個「Evidence」，其實也正好帶到下一篇。

以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。

實際法規適用性、法規間關係與符合性判斷，仍應依產品實際情境、最新 EU 法規、主管機關解釋、Guidance、Harmonised Standards（調和標準）及其他適用要求進行確認。

Day 26 預告｜CRA 做到最後，最難的是技術，還是「證據」？我開始思考 Evidence Management

假設 Product 真的做過 Threat Modeling（威脅建模），SAST（Static Application Security Testing，靜態應用程式安全測試）也真的掃過，SBOM 也產過，Penetration Test（滲透測試）也完成了。

兩年後，如果 Notified Body（公告機構）或 Market Surveillance Authority（市場監督機關）問：

「Evidence 在哪裡？」

大家開始找 Engineer 的 Notebook、Teams 裡的附件、SharePoint 的舊版本、Jira Ticket、Git Repository……

最後好不容易找到了，卻發現：

Product Version 對不起來。

這時我開始覺得，CRA 很大的挑戰也許不只是「有沒有做 Security」，而是：

「能不能長期證明自己真的做過，而且這些 Evidence 對得上正確的 Product、Version 與 Requirement？」

Day 26，我們來聊一個看起來比較不像 Cybersecurity，實際上卻可能非常關鍵的題目：

CRA Evidence Management（證據管理）——怎麼把 Risk Assessment、SBOM、Security Testing、Technical Documentation 與 Product Version 串成一條真的找得到、追得回去，也能說得清楚的 Evidence Chain（證據鏈）。