寫在前面
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA，歐盟網路韌性法案）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security（產品安全）的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission（歐盟執委會）後續 Guidance（指引）、Harmonised Standards（調和標準）及主管機關實務為準。
今天談的 Organization（組織）、Responsibility（責任）與 RACI，更不是 CRA 規定企業一定要採用的組織模式，而是我們在實際思考 CRA 如何落到企業既有流程時，慢慢整理出來的一些想法。每家公司組織、產品與既有 Product Security / Compliance Mechanism 都不同，因此以下內容比較適合作為實務交流，而不是一套標準答案。

Day 19 問「Evidence 找不找得到」，Day 20 開始思考「那到底誰負責？」
上一篇談 CRA Readiness 時，我留下了一個問題：如果有一天有人問「你為什麼認為這個 Product 符合 CRA？」，我們可能需要找出 Product Classification、Risk Assessment、Annex I Mapping、SBOM、Security Test Evidence、Technical Documentation、EU Declaration of Conformity，以及 Change Assessment。
但真的開始找這些 Evidence，就會發現一件很現實的事情：
它們通常不在同一個部門。
Product Information 可能在 PM，Architecture 在 R&D，SBOM 在 Engineering System，Security Test 在 QA，Supplier Information 在 Procurement，Vulnerability Record 在 PSIRT，EU DoC 又可能由 Product Compliance 管理。
所以做到這裡，我開始覺得，CRA Readiness 的下一個問題，其實就是 Organization Readiness。
如果每一份 Evidence 都有人做，但沒有人知道彼此怎麼接起來，最後還是很難回答一件事情：這個 Product 到底 Ready 了沒有？

一、名字裡有 Cyber，不代表全部都是 Security Team 的工作
我覺得這是 CRA 專案很容易出現的一個現象。
法規叫 Cyber Resilience Act，看到 Cyber，很自然就會先想到 Information Security Team。於是一開始 CRA 法規研究找 Security，接著 Product Classification 找 Security，再來 Risk Assessment 找 Security，慢慢地連 SBOM、PSIRT、Supplier Security、Technical Documentation 也全部往 Security Team 集中。
但一路做到 Day 20，我自己反而越來越確定：
這些事情不可能全部由資安單位自己完成。
原因其實很簡單，因為很多關鍵的 Product Knowledge 與 Evidence，根本不在 Security Team 手上。
例如 Product Classification（產品分類）。前面談 Classification 時，我們一直強調 Core Functionality（核心功能），但真正最清楚 Product Core Functionality 的，通常是 Product Team、R&D 或 Business Unit，而不一定是 Security。
問題是，Product Team 雖然很懂產品，卻不一定熟悉 CRA Annex III、Annex IV 或相關 Classification Logic；Compliance / Security 熟悉 CRA，卻未必知道某顆 IC 實際的 Architecture 與 Function；Legal 可以協助理解法規問題，也不一定掌握產品技術細節。
所以如果真的要做 Product Classification，我自己比較傾向把三種 Knowledge 放在一起：
Product Knowledge + Technical Knowledge + CRA Knowledge。
而不是讓任何一個部門自己猜。

二、Risk Assessment 與 SSDLC 更不可能由 Security 自己完成
Day 6 談過 Cybersecurity Risk Assessment（網路安全風險評估）。
Security Team 可以提供 Methodology、Threat Library、Risk Criteria 與 Review Mechanism，但 Product 到底怎麼運作、有哪些 Interface、有哪些 Asset、Trust Boundary 在哪裡，以及 Security Function 怎麼實作，真正最清楚的人通常還是 R&D / Engineering。
所以我自己會把 Product Cybersecurity Risk Assessment 看成 R&D 與 Product Security 共同完成的產物。
Security 可以 Challenge，可以問「這個 Interface 有沒有考慮 Unauthorized Access？」但不能在不知道 Architecture 的情況下，自己把整份 Threat Model 想完。否則最後很可能 Risk Assessment 寫得很漂亮，卻跟真正的 Product 不是同一件事。
SSDLC（安全軟體開發生命週期）也是類似的概念。
講到 Secure Development，Security Team 很容易被期待負責 Security Requirement、Threat Modeling、Secure Coding、SAST、SCA 與 Security Testing，但真正 Design Product、Write Code、Integrate Component、Fix Vulnerability 的人，還是 Engineering / R&D。
所以我自己很喜歡一個簡單的分工概念：
Security defines the guardrails; Engineering executes within them.
也就是 Security 建立最低安全要求、方法與 Review Mechanism，而 Engineering 則負責把這些 Requirements 真正做到 Product 裡。
當然，這只是我的管理理解，不是 CRA 規定企業一定要這樣分工。

三、SBOM 更能看出「Owner」其實不只一個
第一次說「我們需要建立 SBOM」，大家很容易又看向 Security Team。
但 Security Team 怎麼知道 Product 裡到底用了哪些 Library 或 Third-party Components？真正的 Source 很可能存在 Build System、Package Manager、Source Repository、Firmware Build 或 Third-party Component Inventory。
所以 SBOM Generation（SBOM 產生）很可能比較接近 Engineering / DevOps 的工作。
可是 SBOM 建出來之後，要拿來做 Vulnerability Monitoring、Component Impact Analysis 或 PSIRT Investigation，又會回到 Product Security / PSIRT。
因此我自己會把 SBOM 拆成三件事情：
Generate、Consume、Govern。
誰負責產生 SBOM？誰拿 SBOM 做漏洞分析？誰負責訂定格式、更新頻率、保存與品質要求？
這三件事情不一定是同一個 Team 負責。
我覺得這個觀念很重要，因為很多 CRA 工作其實都有類似的情況：我們一直想找一個 Owner，但真正需要管理的可能是一整條 Lifecycle。

四、PSIRT 看起來像 Security，背後其實也是跨部門機制
假設星期五晚上收到一個 Vulnerability Report，第一站可能是 PSIRT，但接下來真正開始處理，就會發現事情很快跨出 Security Team。
哪些 Product 受到影響，需要 R&D 判斷；哪些 Version 還在市場上，需要 Product Team 提供資訊；要不要修、怎麼修，主要還是 R&D；是否涉及 CRA Reporting Requirement，可能需要 PSIRT 搭配 Compliance / Legal；如果要對客戶溝通，又可能需要 Sales 或 Customer Support。
所以 PSIRT 並不是「Security Team 有一個信箱」就完成了。
真正能運作的 PSIRT，背後其實是一套 跨部門的 Product Vulnerability Response Mechanism（產品漏洞應變機制）。
這也剛好接回 Day 19 談的 Evidence 問題。
Product Description 的 Owner 可能是 PM，Architecture Evidence 在 R&D，Risk Assessment 可能由 Product Security 與 R&D 共同完成，Test Evidence 在 QA，SBOM 在 Engineering，Supplier Evidence 在 Procurement / R&D，而 EU DoC 又可能由 Product Compliance 管理。
所以我自己現在比較喜歡一個概念：
Central Coordination + Distributed Evidence Ownership。
也就是中央有人負責協調，但 Evidence 的 Ownership 分散在真正產生與管理它的單位。
不是叫一個 CRA Coordinator 把所有文件重新寫一遍，而是 每份 Evidence 都有真正的 Owner，同時有人負責確保整體能串起來。

五、Supplier Security 也是很典型的交界問題
Day 13 談過 Third-party Component（第三方元件）。
Supplier Requirement 如果只丟給 Procurement，我覺得可能也不太夠。Procurement 很適合處理 Contract、Supplier Communication 與 Commercial Terms，但它不一定知道 Component X 對 Product Security 到底有多重要。
R&D 知道 Component 用在哪裡，Security 知道需要哪些 Security Requirements，Legal 則知道相關 Contract Language 應該怎麼處理。
所以 Product Security Supply Chain 很可能需要 Procurement + R&D + Security + Legal 一起運作。
這也再次說明，CRA 很難被塞進單一 Function。

六、CE 與 EU DoC，Security Team 要自己另建一套流程嗎?
Day 15、Day 16 談過 Conformity Assessment、EU DoC 與 CE Marking。
如果公司本來就已經有 EMC、RED、RoHS、Product Certification 等既有 Product Compliance Process，我自己反而比較希望：
CRA 接進既有的 Product Compliance Mechanism。
Security 可以提供 Annex I Compliance Evidence、Cybersecurity Risk Assessment，以及相關 Product Security Evidence，但最後的 Conformity Assessment Coordination、EU DoC 與 CE Governance，可以跟既有 Product Compliance Team 一起設計。
而不是因為 CRA 名字裡有 Cybersecurity，Security Team 就另外建立一套「CRA CE Process」。
否則未來反而可能產生兩套 Product Compliance Mechanism，一套處理既有產品法規，一套專門處理 CRA。我自己會覺得這樣長期維運的成本可能更高。

七、那 CRA 到底誰是 Owner？
做到這裡，可能還是會有人問：
所以到底誰負責 CRA？
我自己其實不太想直接回答某一個部門，因為每家公司真的不同。
有些公司的 Product Security 很成熟，有些 Regulatory Affairs 很強，有些 Product Compliance 在 QA，有些 Cybersecurity Governance 則放在 Security。
所以我不認為存在一張所有企業都適用的 CRA Organization Chart。
但我現在滿確定一件事：
需要有人負責把整體串起來。
否則很容易變成 R&D 做 R&D 的、Procurement 管 Supplier、PSIRT 管 Vulnerability、Compliance 管 CE。每個人都有做事，但沒有人知道整個 Product 到底 Ready 了沒有。
這也是為什麼，我們實際開始做 CRA 之後，慢慢不再只把它看成一個 Security Project，而比較像是一個跨部門的 Program。

八、我們開始把 CRA 當成 Program，而不是單一專案
如果是跨產品、跨 Business Unit，甚至跨國企業，我自己會比較傾向用 Program Governance 來思考 CRA。
概念上可以分成三個層次：上層由 Steering / Management 處理重大方向與決策；中間由 CRA PMO / Program Coordination 負責整體協調；下面則由不同 Working Teams / Workstreams 實際執行各項工作。
這當然不是 CRA 的法規要求，只是我覺得面對這種跨 Function 的 Requirement，比「全部指定給某一個部門」更容易管理。
Steering 也不需要討論 CVSS 8.8 的漏洞到底怎麼修。Management 比較適合處理的是 Scope、Resources、Major Risk、Cross-BU Conflict、Budget、Certification Strategy，以及重要 Business Decision。
例如 Support Period 如果延長，可能增加 R&D 長期維護成本；某個 Product 如果需要 Third-party Conformity Assessment，也可能涉及 Cost、Schedule 與 Market Plan。
這些已經不只是 Cybersecurity Technical Decision，而是 Business Decision。
所以 Management Sponsorship 對 CRA 很重要，不是為了讓專案看起來比較高階，而是很多問題本來就不是 Security Team 有權決定。

九、CRA PMO 不一定做所有事情，但要確保最後接得起來
我自己對 CRA PMO 的期待，不是「自己把所有 Deliverables 做完」。
PMO 更重要的工作，是持續掌握 Product Inventory 完成了嗎？Classification 還有哪些待確認？Risk Assessment 做到哪裡？SBOM Coverage 如何？Article 14 Process Ready 了嗎？Supplier Requirement 到哪裡？Technical Documentation 還缺哪些 Evidence？Conformity Assessment Route 決定了嗎？
換句話說：
PMO 不一定做所有事情，但要確保有人做，而且最後接得起來。
我覺得這個差別很重要。
如果是我們現在看到的 CRA 工作，我可能會拆成 Product Classification、SSDLC / Product Security、PSIRT / Vulnerability Handling、SBOM、Technical Documentation、Supplier Security、Conformity Assessment / Certification，以及 Training / Awareness 等不同 Workstreams。
不同企業當然可以拆得更細，也可以整併。重點從來不是一定要有幾個 Workstreams，而是不要把 CRA 想成：
Security Team 有一張超大的 To-do List。
比較合理的方式，是每一個 Workstream 都找到適合的 Functional Owner，再由 CRA Program 把它們串起來。

十、如果真的要談 RACI，我更在意 Responsibility Boundary
如果真的要畫一份 CRA RACI，我自己可能會先從幾個核心活動開始。
例如 CRA Applicability / Classification，需要 Product、Compliance 與 Security 一起參與；Cybersecurity Risk Assessment 與 Security Requirements / SSDLC，主要需要 R&D 搭配 Product Security；SBOM Generation 比較接近 R&D / Engineering，而 SBOM Vulnerability Monitoring 則會轉到 Product Security / PSIRT。
Vulnerability Handling 需要 PSIRT 與 R&D；Article 14 Assessment 可能需要 PSIRT、Compliance / Legal；Supplier Security 需要 Procurement、R&D 與 Security；Technical Documentation 則比較像 Compliance Coordination 搭配各個 Evidence Owner；Conformity Assessment、EU DoC 與 CE，則可能由既有 Product Compliance / QA、Product Team 及公司授權角色共同處理。
這當然完全不是 CRA 官方 RACI。甚至換一家公司，我自己可能就會重新畫一次。
對我來說，它比較像是：
讓大家開始討論 Responsibility Boundary（責任邊界）的起點。

十一、但 RACI 最重要的，可能不是 R 跟 A，而是 Handoff
RACI 很容易花很多時間討論誰是 Responsible、誰是 Accountable，但實際運作之後，我自己現在反而更關心：
Handoff（交接點）到底有沒有接起來。
例如 Supplier 發現 Vulnerability，誰把資訊送進 PSIRT？PSIRT 發現可能涉及 CRA Reporting，誰通知 Compliance / Legal？R&D Release 新版本，誰觸發 SBOM Update？Product 發生 Change，誰啟動前面談過的 Substantial Modification Assessment？Technical Documentation 需要更新時，又是誰知道哪些 Evidence 已經改變？
這些 Function 與 Function 之間的交界，才是流程最容易斷掉的地方。
所以我現在會希望 RACI 跟 Process Flow 一起看。
一個重要的 CRA Process，至少要能看出它的 Trigger、Owner、Activity、Decision、Evidence 與 Next Owner。
例如收到 Vulnerability Report 之後，進入 PSIRT Intake，再進行 Triage / Impact Assessment；如果可能涉及 CRA，再進入 CRA Reporting Assessment，留下 Decision Record，最後依結果進行 Reporting、Remediation 或 Customer Communication。
這樣 Organization 跟 Process 才真正接起來。

十二、那資安治理單位到底應該做到哪裡？
這是我自己做 CRA 時一直在思考的問題。
如果 Security Governance 什麼都接，最後可能變成 Product Inventory 是 Security 做、Classification 是 Security 判、Risk Assessment 是 Security 寫、SBOM 是 Security 追，連 Technical Documentation 都由 Security 整理。
短期看起來，CRA 專案進度可能很好。
但長期可能出現另一個問題：
真正的 Product Security Capability 並沒有進入 Product Organization。
所以我自己現在比較希望 Security Governance 扮演的是 Framework、Governance、Security Expertise、Coordination、Challenge / Review 與 Monitoring。
至於 Product、R&D、QA、Procurement 等角色，則應該對自己真正掌握的 Product Activity 與 Evidence 負責。
這樣 CRA 才比較有機會留下來，而不是隨著 Project Close 一起消失。

十三、真正的目標，是把 CRA 從 Project 變成 Operating Model
這也剛好接回 Day 19 最後那個問題。
三年後，新 PM 進來、新 R&D Team 接手、Supplier 換掉之後，CRA Requirements 還會不會繼續運作？
我現在覺得，答案很大一部分就在：
Responsibility 有沒有真正進入既有流程。
如果 CRA 只靠一群 Project Members 記得「這件事情要做」，等 Project Team 解散之後，很多要求可能就慢慢消失。
但如果 Product Release 本來就會檢查 CRA、Engineering Change 本來就會做 Cybersecurity Impact Assessment、Supplier Onboarding 本來就會考慮 Product Security Relevance、Vulnerability Intake 本來就會進 PSIRT、Product EOL 本來就會確認 Security Support，那 CRA 才真的開始從一個 Project，慢慢變成公司的 Operating Model（營運模式）。

Day 20 小結｜資安治理的價值，不是把 CRA 全部做完，而是讓整個公司做得起來
做到 Day 20，我自己最大的感受是：
CRA 如果最後只留下幾份 Security SOP，可能還不算真正落地。
我比較期待看到的是，Product Team 知道哪些產品需要進 CRA Process；R&D 知道 Security Requirements 怎麼進 Development；Procurement 知道哪些 Supplier Components 需要特別管理；PSIRT 知道 Vulnerability 進來後怎麼處理；Compliance 知道怎麼把各單位的 Evidence 串成 Conformity；Management 也知道哪些問題已經不是 Security Decision，而是 Business Decision。
而資安治理單位，不需要把所有事情都搶過來自己做。
它更重要的價值，可能是：
建立 Framework、把責任接起來、找到 Gap，並確保整個機制持續運作。
這也是我目前參與 CRA 導入後，一個很深的體會。
真正成熟的 CRA Governance，不是所有箭頭最後都指向 Security，而是每一個該負責的人，都知道自己的那一段要做什麼。
當這件事情發生，CRA 才開始從 Security Project 走向真正的 Product Compliance Operating Model。
以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。
CRA 規範的是 Economic Operators（經濟營運者）應履行的相關義務，並沒有規定企業內部一定要成立什麼部門、使用哪一套 RACI，或採用哪種 Organization Design。因此實際怎麼分工，我自己仍會依企業規模、產品特性、Business Model，以及既有 Product Security / Product Compliance Governance 來設計。

Day 21 預告｜組織有了、責任分了，接下來最現實的問題就是：來得及嗎？
Day 20 我們把 CRA 從 Security Team 的 Project，慢慢拉成跨部門的 Product Compliance Program。
但 Organization 與 RACI 畫完之後，我自己下一個遇到的問題非常現實：
這麼多事情，到底要什麼時候做完？
因為 CRA 的主要義務雖然在 2027 年 12 月 11 日開始全面適用，但 Article 14 的 Reporting Obligations 已經在 2026 年 9 月 11 日先開始。
也就是說，不是所有 CRA 工作都可以排到 2027 年再做。
PSIRT / Reporting 哪些能力要先 Ready？Product Inventory 與 Classification 什麼時候完成？Risk Assessment、SSDLC、SBOM 要從哪一批 Product 開始？Supplier Contract 修改要預留多久？Technical Documentation 什麼時候開始累積，才不會最後一年才回頭補 Evidence？Conformity Assessment 又需要預留多少時間？
而且現在 Harmonised Standards 還在持續發展。
那我們到底應該等 Standards 都確定再開始，還是先把不太會變的基礎能力建立起來？
Day 21，我想換成比較像我們實際做專案管理的角度來聊：
如果從 2027 年 12 月 11 日往回倒推，我會怎麼安排一份 CRA Implementation Roadmap。