寫在前面
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。
今天談 ISO/IEC 27001 與 CRA 的關係，也不是要做逐條 Mapping（對照），而是想從企業已經有 ISMS（Information Security Management System，資訊安全管理系統）的角度，談談我自己在實際參與 CRA 導入時逐漸形成的一個想法：
哪些既有能力可以沿用？哪些需要延伸？又有哪些事情，確實是 CRA 帶來的新工作？

做 CRA 做到這裡，我一直有一種「這個我好像做過」的感覺
Day 23 談到 KPI（Key Performance Indicator，關鍵績效指標）、KRI（Key Risk Indicator，關鍵風險指標）與 Management Review（管理審查）時，如果本來就在做 ISO/IEC 27001，應該多少會開始產生一種熟悉感。
再回頭看前面 CRA 談過的 Risk Assessment（風險評估）、Vulnerability Management（漏洞管理）、Incident Management（事件管理）、Supplier Security（供應商資安）、Access Control（存取控制）、Change Management（變更管理）、Security Monitoring（安全監控）與 Continual Improvement（持續改善），其實很多概念都不陌生。
所以很自然會出現一個問題：
公司已經有 ISO/IEC 27001，是不是 CRA 就不用重新做了？
我自己目前的理解是：ISO/IEC 27001 很有幫助，但不能直接跟 CRA 畫上等號。
原因不是誰比較嚴格，而是兩者主要管理的「主角」不太一樣。

一、ISO 27001 的主角，我會先想到 Organization
ISO/IEC 27001 是 Information Security Management System，所以平常做 ISMS，我們很熟悉 Scope（範圍）、Organization Context（組織情境）、Interested Parties（利害關係人）、Information Assets（資訊資產）、Risk Assessment、Controls（控制措施）、Internal Audit（內部稽核）、Management Review 與 Continual Improvement。
如果要用一句話描述，我自己會把它理解成：
Organization（組織）如何系統化地管理 Information Security Risk（資訊安全風險）？
因此我們平常管理的對象可能包括 ERP、Email、Server、Network、Cloud Service、Source Code Repository、Employee、Supplier，以及各種 Information Asset。
這是很多做企業資訊安全的人非常熟悉的世界。

二、到了 CRA，主角開始變成 Product
CRA 關注的核心則是 Products with Digital Elements（具數位元素產品）。
所以問題逐漸變成：Product 有哪些 Cybersecurity Risk？有哪些 Attack Surface（攻擊面）？使用哪些 Third-party Components（第三方元件）？產品在設計與開發時如何考量 Cybersecurity？Vulnerability 發生後如何處理？Support Period（支援期間）如何規劃？又要如何證明 Product 符合適用的 CRA 要求？
因此，從 ISO 27001 走到 CRA，我自己覺得很重要的一個轉換就是：
Risk 的主角變了。
原本我們很習慣從 Enterprise（企業）或 Information Asset（資訊資產）的角度看 Risk；到了 CRA，很多事情則需要進一步落到 Product。
CRA Annex I 對 Product Cybersecurity Requirements 與 Vulnerability Handling Requirements 都有相關要求。對我而言，這正是一般 ISMS 與 CRA 很重要的差異之一。

三、同樣都叫 Risk Assessment，其實不一定是同一份
例如公司在 ISO 27001 的 Risk Assessment 中，可能識別出 Source Code Repository 存在 Unauthorized Access（未授權存取）的風險，因此導入 MFA（Multi-Factor Authentication，多因素驗證）、Access Control、Logging、Backup 等控制措施。
這完全合理，而且很重要。
但到了 CRA 的 Product Cybersecurity Risk Assessment（產品資安風險評估），問題可能會變成：Product 有哪些需要保護的 Asset？有哪些 External Interface（外部介面）？Attack Surface 在哪裡？Threat Actor（威脅行為者）可能透過什麼方式攻擊？Product 被利用後可能造成什麼影響？又需要哪些 Security Requirement（安全要求）降低 Risk？
兩者當然有很多共通的 Risk Management 思維，但 Risk Object（風險評估對象）並不完全相同。
這也是為什麼，即使公司已經有一份非常成熟的 Corporate Risk Register（企業風險清冊），我自己也不會直接把它當成 CRA Product Cybersecurity Risk Assessment。
但反過來說，這並不代表原本 ISMS 做的 Risk Management 沒用了。
成熟的 ISMS 通常已經知道什麼是 Risk Owner（風險負責人）、Risk Treatment（風險處理）、Risk Acceptance（風險接受）、Control、Evidence（證據）、Review（檢視）與 Continual Improvement。
也就是說，CRA 不需要重新教組織什麼叫 Risk-based Management（風險導向管理）。真正需要做的，比較像是把既有 Risk Management 能力：
從 Enterprise Information Security 延伸到 Product Cybersecurity。
我自己覺得，這比從零開始建立一套管理機制容易很多。

四、Incident Management 可以沿用，但不能直接照搬
ISO 27001 做得比較成熟的公司，通常已經有 Security Event（資安事件）、Security Incident（資安事故）、Severity（嚴重度）、Escalation（升級通報）、Response（應變）、Recovery（復原）與 Lessons Learned（經驗學習）等機制。
所以第一次看到 CRA Article 14，很自然可能會想：「我們公司已經有 Incident Response SOP 了。」
但繼續往下看，就會發現 CRA 關心的情境包括 Actively Exploited Vulnerability（遭主動利用的漏洞）、Severe Incident Having an Impact on the Security of the Product（對產品安全造成影響的嚴重事件），以及相應的 Reporting Obligations（通報義務）。
這時就會發現，CRA 有自己的 Product Context（產品情境）與 Regulatory Reporting Trigger（法規通報觸發條件）。
因此我自己的想法不會是重新發明一套 Incident Management，而是思考：
怎麼把 Product Security / PSIRT 接到既有 Incident Management。
例如 Corporate Security 發現 Cyber Incident，如果只影響 Internal IT（內部資訊環境），就走既有 ISMS Incident Process；但如果調查過程發現事件涉及 CRA Product，就應該能夠 Trigger Product Security / PSIRT Assessment。
反過來也一樣。PSIRT 收到 Product Vulnerability Report，如果分析後發現問題同時影響 Corporate Infrastructure（企業基礎設施），也應該能夠 Trigger Corporate Incident Response。
所以我不會把 ISMS Incident Team 與 PSIRT 想成二選一，而會把它們理解成：
Scope 不同，但 Information Flow 與 Escalation Path 必須互通的兩套機制。
這也是我覺得 CRA 導入很容易遇到的跨部門問題。真正困難的往往不是「有沒有 SOP」，而是兩套流程碰到同一件事情時，誰先接、誰判斷、什麼時候轉交。

五、Supplier Security 也會從「企業供應商」延伸到「產品元件」
ISO 27001 原本就很重視 Supplier Relationship（供應商關係）。很多公司可能已經有 Supplier Security Assessment、NDA、Security Clause（資安條款）、Access Control 與 Service Review 等機制，這些對 CRA 都是很好的 Foundation（基礎）。
但 CRA 又多了一個很重要的 Product Security Perspective（產品資安視角）。
以前我們可能比較常問：
「這個 Supplier 能不能安全地存取我們公司的資訊或系統？」
到了 CRA，可能還要多問：
「這個 Supplier 提供的 Component，會不會影響我們的 Product Security？」
例如 Component 是否存在已知 Vulnerability？Supplier 能不能提供 Security Fix？Support Lifecycle（支援生命週期）多久？EOL / EOS 怎麼通知？Product Team 能不能取得必要的 Component Security Information？
CRA Article 13 對 Manufacturer 使用 Third-party Components 也涉及相應的 Due Diligence（盡職調查）要求。
對我而言，這是一個很大的視角轉換：
Supplier Security 不再只是「保護公司」，還開始進入「保護產品」。

六、Vulnerability Management 也從 Server 走向 Product
做企業資訊安全的人對 Vulnerability Management 通常不陌生。Server Vulnerability Scan（伺服器弱點掃描）、CVSS（Common Vulnerability Scoring System，通用漏洞評分系統）、Patch SLA、Exception（例外）、Remediation Tracking（改善追蹤），這些可能每天都在做。
但 CRA 的 Vulnerability 對象變成 Product 之後，問題也跟著改變。
哪些 Product Version 受到影響？Customer 已經拿到哪些 Version？Third-party Component Vulnerability 是否真的影響 Product？有沒有 Exploitation（遭利用）跡象？是否需要 Security Update？是否涉及 Article 14 Assessment？是否需要進一步進行 CVD（Coordinated Vulnerability Disclosure，協調式漏洞揭露）或 CVE（Common Vulnerabilities and Exposures，常見漏洞與曝露）處理？
因此 Corporate Vulnerability Management 可以提供很多 Methodology、Tool 與實務經驗，但 Product Vulnerability Management 還是需要 Product Team、R&D 與 PSIRT 真正加入。

七、Asset Inventory 跟 Product Inventory，能整合在一起嗎?
ISO 27001 很多公司都有 Information Asset Inventory（資訊資產清冊），裡面可能是 Server、Database、Application、Laptop、Network Device 等。
CRA 我自己則會另外建立 Product Inventory（產品清冊），記錄 Product Family、Part Number、Firmware Version、Product Owner、EU Market、CRA Applicability、CRA Classification、Support Period 等必要資訊。
兩張 Inventory 當然可以互相參考，甚至部分資料來源可以整合，但我自己不太會為了「制度整合」而硬把它們做成同一張表，原因很簡單：
管理目的不同。
ISMS Asset Inventory 主要服務 Information Security Management；CRA Product Inventory 則需要支撐 Product Scope、Classification、Risk Assessment、Technical Documentation、Support Period 等後續 Product Compliance Activity。

八、Change Management 能否共用?
Day 17 談過 Substantial Modification（實質修改）。
這件事情我自己不太想另外建立一個「CRA Change Process」，反而會希望把 CRA Assessment 接進公司既有的 Product Change / Engineering Change Process（產品／工程變更流程）。
例如 Product 發生 Change 時，可以進一步確認：是否改變 Intended Purpose（預期用途）？是否增加新的 Interface？是否改變 Attack Surface？Cybersecurity Risk 是否改變？原本的 CRA Conformity 判斷是否可能受到影響？
這其實跟 ISMS 很熟悉的 Change Impact Assessment（變更影響評估） 概念非常接近，只是評估對象從 Information System 進一步延伸到了 Product。

九、Internal Audit 與 Management Review，要重新再蓋一套?
如果公司已經有成熟的 Internal Audit Mechanism（內部稽核機制），我自己不太想為 CRA 再創造另一套完全獨立的 Audit Administration，比較可能的方式，是逐步把 CRA 放進既有 Assurance Mechanism（確信／查核機制）。
例如未來 Audit 可以抽樣某個 Product，檢視它的 Classification、Risk Assessment、SBOM、SSDLC Evidence、Vulnerability Handling、Technical Documentation 與 Support Period。
Management Review 也是一樣。Day 23 才談過 CRA KPI / KRI，如果公司本來就有 ISMS Management Review，我會思考 CRA Major Risk、Article 14 Case、重大 Product Vulnerability、Supplier / Component Risk、Conformity Assessment Issue 等資訊，是否可以適度整合進既有 Management Review。
因為我自己最不希望看到的狀況是：ISO 一個 Governance Meeting、CRA 一個、AI Governance 又一個、Cloud Security 再一個，最後 Governance 做得越多，大家反而整天都在開 Governance Meeting。
所以能共用的管理機制，我自己會傾向：
盡量整合。

十、但有些事情，ISO 27001 可能真的幫不了太多
這裡也要避免另一個極端：不是什麼 CRA Requirement 都可以塞進 ISMS。
例如 CRA Product Classification，ISO 27001 不會幫你判斷 Product 的 CRA Category；Conformity Assessment（符合性評估）也是一樣，ISO 27001 不會替 Product 決定適用的 CRA Conformity Assessment Route。
再往後的 EU Declaration of Conformity（EU DoC，歐盟符合性聲明）、CE Marking（CE 標誌）等，也已經進入 EU Product Compliance Framework（歐盟產品合規架構）的世界。
因此：
有 ISO/IEC 27001 Certification，不代表 Product 自動符合 CRA。
公司取得 ISO/IEC 27001 Certification，代表其 ISMS 在 Certification Scope（驗證範圍）內依 ISO/IEC 27001 建立並維持相應的 Information Security Management System；CRA 關心的則是 Product with Digital Elements 是否符合 CRA 適用要求。
所以：
ISO/IEC 27001 Certificate ≠ CRA Conformity。
也不代表 Product 因此就不需要進行 CRA 要求的 Product Classification、Risk Assessment、Technical Documentation 或適用的 Conformity Assessment。
我自己會把 ISO 27001 看成 Strong Foundation（很好的基礎），而不是 Compliance Shortcut（合規捷徑）。

十一、那既有 ISMS Evidence 到底能不能拿來支持 CRA？
我自己的答案其實很簡單：
可以，只要這份 Evidence 真的能支持對應的 CRA Requirement。
例如既有 Supplier Security Process 如果已經涵蓋 Product Component Security，就沒有必要為了 CRA 再寫一套內容完全相同的流程；Existing Incident Management 如果已經把 Product Security Reporting 與 PSIRT Escalation 整合進去，也可以成為 CRA Operating Model 的一部分；Existing Secure Development Process 如果本來就涵蓋 CRA Product 所需要的 Security Activity，也不需要因為法規名稱變成 CRA，就再複製一套「CRA SSDLC」。
所以我自己不太會問：
「這是不是一份 CRA 文件？」
我反而會問：
「這份 Process / Evidence 能不能支撐我們對 CRA Requirement 的處理？」
我覺得這個差別很重要。

十二、如果讓我自己做 Mapping，我可能只先分三類
如果公司已經有成熟 ISMS，我自己可能會先做一份 CRA → Existing ISMS Mapping，但一開始不一定需要做得非常複雜。
我可能先把 Requirement 分成三類。
第一類是 Existing（既有能力可沿用）。也就是原本制度已經可以支撐的能力，例如 Document Control、Internal Audit、Management Review、Corrective Action、Training Framework 等。這些機制如果本來就運作成熟，沒有必要因為 CRA 再重新建立一份幾乎相同的制度。
第二類是 Extend（既有能力需要延伸）。這一類其實可能最多，因為企業原本已經有管理基礎，只是需要加入 Product Context。例如 Risk Management 延伸成 Product Risk；Incident Management 接上 PSIRT 與 Article 14；Supplier Security 延伸到 Product Component Security；Vulnerability Management 從 Corporate IT 延伸到 Product Vulnerability；Change Management 則加入 Substantial Modification 的評估。
第三類才是 New（CRA 特有能力）。這些事情原本 ISMS 不一定存在，例如 CRA Product Classification、Annex I Mapping、CRA Technical Documentation、Conformity Assessment、EU DoC 與 CE Marking。
用這種方式整理之後，我自己反而不太會一開始就宣布：
「我們要建立一套全新的 CRA Management System。」
因為很多東西其實已經存在，只是管理對象與責任需要重新連接。

十三、我最想避免的，其實是「雙制度」
這可能是我自己做 Governance 類專案時很在意的一件事情。
如果最後變成 Corporate Security Procedure 一套、CRA Security Procedure 又一套；Supplier Security 一套、CRA Supplier Security 又一套；Corporate Incident Response 一套、CRA Incident Response 再一套，久了之後很容易出現同一件事情兩個 Owner、兩個表單、兩套 KPI，甚至兩個地方保存 Evidence。
剛導入的第一年可能還跑得動，但兩三年後，新人進來第一個問題很可能就是：
「所以我到底要走哪一份 SOP？」
因此，如果 Existing Process 可以合理延伸，我自己會優先 Extend；真的屬於 CRA 特有的 Requirement，再 Create New。
但我也不會走到另一個極端，把 CE Marking、Conformity Assessment、Product Classification、Technical Documentation 全部塞進 Information Security Management Procedure。這樣最後 ISMS 很可能變成一套什麼都管的巨大制度，更麻煩的是 Responsibility 也可能跟著錯位。
所以我自己比較喜歡的原則是：
Governance Integration（治理整合），但 Responsibility Separation（責任分工）。
例如 ISMS / Security Governance 可以提供 Management System Framework；Product Security 負責 Security Engineering；PSIRT 負責 Product Vulnerability Handling；Product / Regulatory Compliance 則負責適用的 Product Compliance、Conformity Assessment 與 CE 相關流程。
大家可以共用 Governance Mechanism，但不代表所有工作最後都變成：
Security Team 負責。
這點我自己覺得尤其重要。

十四、做到這裡，我開始覺得 ISO 27001 最大的價值，其實不只是 Annex A
第一次做 CRA Mapping，很自然會拿 ISO 27001 Annex A Controls 逐條比對，這當然有幫助。
但做到後面，我自己反而越來越覺得，ISO 27001 對 CRA 最有價值的地方，可能不是某一個特定 Control，而是：
Management System（管理系統）的思維。
也就是從 Scope、Risk、Owner、Process、Evidence，一路走到 Audit、Management Review、Corrective Action 與 Continual Improvement。
CRA 告訴企業很多 Product Cybersecurity 必須處理的事情，而一套成熟的 Management System，則可以幫助企業把這些 Requirement 從一次性的 Project，慢慢變成可以長期運作的機制。
這也剛好接回 Day 22 與 Day 23。
Day 22 我們問的是：
「CRA Ready 了嗎？」
Day 23 問的是：
「Ready 之後，怎麼知道它還有效？」
到了 Day 24，我自己的答案開始變得更清楚：
如果公司本來就有成熟的 ISMS，其實不需要把所有管理能力重新發明一次。真正需要做的，是把原本已經存在的 Management System 能力，延伸到 Product Cybersecurity。

Day 24 小結｜ISO 27001 不完全是 CRA 的答案，但可以成為很好的底座
做到 Day 24，我自己已經不太會問：
「ISO 27001 能不能 Cover CRA？」
因為這個問題太容易讓人期待一個簡單的 Yes / No。
我反而比較會問：
「我們既有 ISMS 的哪些能力，可以拿來支撐 CRA？」
答案其實不少。
Risk Management、Supplier Management、Incident Management、Vulnerability Management、Change Management、Internal Audit、Management Review、Corrective Action、Evidence Management，這些都是很多成熟 ISMS 已經具備的能力。
但 CRA 還需要把 Product Security、Product Risk、SBOM、PSIRT、Support Period、Technical Documentation、Conformity Assessment 與 CE 等 Product Context 放進來。
所以我自己目前最喜歡的理解方式是：
ISO 27001 提供 Management System 的骨架；CRA 則把 Product Cybersecurity 的要求帶進這套管理思維。
兩者可以大量協同，但不能直接畫上等號。
如果公司已經有成熟 ISMS，我覺得最大的優勢不只是「CRA 可以少寫幾份文件」，真正的優勢可能是組織已經知道怎麼把 Risk、Process、Owner、Evidence、Audit、Management Review 與 Continual Improvement 變成日常管理。
接下來真正需要學習的，是怎麼把這套能力：
從 Enterprise Information Security 延伸到 Product Cybersecurity。
以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。

Day 25 預告｜CRA、NIS2、RED、ISO 27001 到底什麼關係？別再把所有 Cybersecurity 要求混在一起
做到 CRA，很快就會遇到另一組問題：
「這跟 NIS2 有什麼不同？」
接著可能又有人問：「我們 Product 已經做 RED Cybersecurity，還需要看 CRA 嗎？」
再來一句：「可是公司已經 ISO 27001 Certified 了啊？」
NIS2、CRA、RED Cybersecurity、ISO/IEC 27001 全部放在一起，確實很容易混亂。
但我自己慢慢整理之後，開始覺得第一步其實不用急著做一張超大的法規 Mapping Matrix，可以先問一個比較簡單的問題：
「它主要在管理誰？」
是 Organization（組織）？Product（產品）？還是 Radio Equipment（無線電設備）？
先把「主角」分清楚，後面的 Scope、Responsibility、Risk、Evidence 與 Compliance Requirement，通常就比較容易看懂。
Day 25，我們來聊 CRA、NIS2、RED Cybersecurity 與 ISO/IEC 27001 到底應該怎麼看，以及企業同時面對多套 Cybersecurity Requirement 時，我自己會怎麼思考它們之間可以共用的能力，而不是每來一個新要求，就重新建立一套制度。