寫在前面
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA，歐盟網路韌性法案）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security（產品安全）的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission（歐盟執委會）後續 Guidance（指引）、Harmonised Standards（調和標準）及主管機關實務為準。
今天會談到 Market Surveillance（市場監督），但我不打算討論個別情況是否違規、產品是否可能被限制或下架，以及實際處分與罰則如何認定，因為這些都涉及主管機關權限、個案事實與法律判斷。
我比較想從企業導入 CRA 的角度思考另一個更實際的問題：
如果有一天真的有人要求我們說明，某個 Product 為什麼符合 CRA，我們準備好了嗎？

CE 貼上去，CRA 專案是不是就可以 Close？
前面幾天一路談過 Product Classification（產品分類）、Risk Assessment（風險評估）、Technical Documentation（技術文件）、Conformity Assessment（符合性評估）、EU Declaration of Conformity（EU DoC，歐盟符合性聲明），最後來到 CE Marking（CE 標示）。
做到這裡，很容易產生一種感覺：產品上市了，CE 也貼了，CRA Project 應該就可以結束了。
但我自己研究到 Market Surveillance 之後，反而越來越不這樣想。
因為 CRA 不只是要求 Manufacturer（製造商）在產品上市前完成一系列 Conformity 工作。產品進入市場之後，還有 Vulnerability Handling（漏洞處理）、Security Update（安全更新）、Support Period（支援期間）、Article 14 漏洞與重大事件通報，以及 Market Surveillance 等機制持續運作。
所以我現在比較會把 CE Marking 看成 一個重要的里程碑，而不是 Product Security Lifecycle（產品安全生命週期）的終點。

一、Market Surveillance 讓我開始換一個角度看 CRA
前面我們大部分都是站在 Manufacturer 的角度思考：公司要做什麼？文件要準備什麼？Risk Assessment 怎麼做？SBOM（軟體物料清單）怎麼建立？
但 Market Surveillance 讓我開始換一個方向思考：如果今天不是我們自己檢查自己，而是有人從外部問我們問題呢？
例如，有人要求公司說明某個 Product 的 CRA Conformity Basis（符合性依據）。這時真正考驗的，可能不是公司有沒有一份 CRA Procedure，而是我們能不能快速回答：這是哪一個 Product、哪一個 Version？為什麼適用 CRA？Product Classification 是怎麼判斷的？Cybersecurity Risk Assessment 在哪裡？Annex I 的要求怎麼 Mapping？採用了哪些 Standards？Verification Evidence 在哪裡？EU Declaration of Conformity 又放在哪裡？
走到這裡我才發現，前面十幾天談過的東西，其實全部又接回來了。

二、Self-assessment 不代表 Evidence 可以比較少
Day 15 談過，部分 CRA Product 可以採用 Internal Control，也就是大家比較常說的 Self-assessment（自我評估）。
第一次看到 Self-assessment，很容易產生一個錯覺：既然不用第三方驗證，是不是準備簡單一點就好？
我自己現在反而不會這樣理解。Self-assessment 比較像是 Manufacturer 依適用程序自行完成 Conformity Assessment，但背後仍然需要有足夠的 Technical Documentation 與 Evidence，支撐 Manufacturer 為什麼認為這個 Product 符合適用的 CRA Requirements。
所以對我來說，Self-assessment 並不等於沒有 Evidence 的 Self-declaration。
這兩件事情差很多。

三、真正困難的可能不是「有沒有文件」，而是「找不找得到」
這是我自己做 Governance 工作時特別有感的一件事。
假設公司其實什麼都有：R&D 有 Security Design，QA 有 Test Report，Product Security 有 Risk Assessment，Legal / Compliance 有 Regulatory Assessment，PM 有 Product Information，Supply Chain 有 Supplier Information，PSIRT 也有 Vulnerability Handling Record。
問題是，這些 Evidence 很可能全部散在不同地方。
有些在 Confluence、有些在 SharePoint，有些存在 PLM、Jira 或 Engineering Repository，甚至還有一些 Evidence 留在 Email 裡。
這時即使公司真的做過很多事情，當需要把它們重新組成一條完整的 Conformity Evidence Chain（符合性證據鏈）時，還是可能非常痛苦。
所以我現在覺得 CRA Documentation 的重點之一，不一定是把所有東西重新寫一份，而是：
知道 Evidence 在哪裡，而且需要的時候找得到。

四、這也是為什麼我越來越喜歡 Evidence Index
Day 14 談 Technical Documentation 時，我開始思考一件事：如果重新做一次，我可能不會要求所有部門把 Evidence 全部複製到一個巨大的 CRA Folder。
我反而會先建立一份 CRA Evidence Index（CRA 證據索引）。
這份 Index 不一定很複雜，核心只是把重要 Evidence、Owner、System / Location，以及對應的 Product Version 串起來。例如 Product Description 可能由 PM 維護在 PLM；Cybersecurity Risk Assessment 由 Product Security 維護在 GRC 或文件 Repository；Threat Model 由 R&D / Security 放在 Engineering Repository；SBOM 放在 SBOM Platform；Security Test Report 由 QA 保存在 Test Repository；Supplier Component Evidence 由 Procurement / R&D 維護；EU DoC 則由 Compliance 保存於正式文件系統。
重點不是把所有文件搬到同一個地方，而是建立一張「地圖」，讓公司知道每一份 CRA Evidence 是誰負責、放在哪裡，以及它到底對應哪一個 Product 或 Version。
這當然不是 CRA 官方要求的 Template，只是我自己覺得，它可能比把所有 Evidence 都塞進同一個 Word 檔，更符合企業實際運作。

五、但光找得到還不夠，Version 要對得起來
這是另一個我覺得很容易踩坑的地方。
假設有人問 Product Version 3.2 的 Risk Assessment 在哪裡，結果我們找到的是 Version 1.0 的 Risk Assessment；SBOM 是 Version 3.1；Penetration Test 是 Version 2.5；EU DoC 卻是 Version 3.2。
每一份文件都有，但彼此對不起來。
這種情況，我自己反而會覺得比單純「缺一份文件」更難處理。
所以 CRA Evidence Management 還有一個很重要的概念，就是 Configuration / Version Traceability（組態／版本可追溯性）。我們不只要知道 Evidence 在哪裡，還要知道這份 Evidence 到底是在證明哪一個 Product Configuration。

六、這又讓 Day 17 的 Change Management 回來了
Product 不會永遠停在 Version 1.0。Firmware 會更新、Third-party Component 會更換、Security Patch 會發布、Hardware 可能 Revision，Risk Assessment 可能重新評估，SBOM 當然也可能跟著改變。
因此，我現在會希望 Product Change Process 至少能留下幾件事情：這次 Change 是什麼？Cybersecurity Impact 有沒有重新評估？哪些 Evidence 需要更新？Technical Documentation 是否受到影響？
如果這些問題沒有進入既有的 Change Management，而是每次 Release 完成之後才回頭問一句「CRA 文件要不要跟著改？」，我覺得很容易漏掉。

七、Market Surveillance 讓我更重視「當初為什麼這樣判斷」
有些 CRA Decision 不一定有一個簡單的 Yes / No 答案。
例如，為什麼這個 Product 判定為 Default Category？為什麼某個 Annex I Requirement 判定為 N/A？為什麼 Support Period 設定成這個期間？又或者，為什麼這次 Product Change 被認為不影響原本的 Conformity Assessment？
如果系統裡最後只留下「Default」、「N/A」、「5 Years」或「No Impact」這些結果，幾年後可能已經沒有人知道當初為什麼這樣決定。
所以我現在越來越重視 Decision Rationale（決策理由）。
不是每一個 Decision 都要寫十頁報告，但至少要讓未來接手的人看得懂：當時依據什麼資訊、誰參與評估、最後結論是什麼，以及相關 Evidence 在哪裡。
我覺得這就是很實際的 Governance。

八、尤其 Semiconductor Product Lifecycle 很長
這件事情放到 Semiconductor（半導體）產業，我覺得更值得注意。
有些 Product 的 Lifecycle 可能非常長。當年參與 Product Development 的 Engineer，幾年後可能已經換 Team，甚至離開公司；原本使用的 Tool 可能已經換掉，Repository 可能經過 Migration，Supplier 也可能已經 EOL，但 Product 還在市場上。
所以我自己會開始問一個問題：
十年後，我們還找得到今天的 CRA Evidence 嗎？
我覺得這個問題，可能比「今天 Technical Documentation 有沒有完成？」更值得思考。

九、Evidence Retention 要能跟公司的 Document Management 接起來
如果 CRA Evidence 都只是存在 Project Folder，我自己會有點擔心。
因為 Project Close 之後，Folder 可能 Archive、System 可能汰換、Permission 可能改變，原本的 Owner 也可能已經離職。這些事情在企業裡其實都很正常，但如果沒有事先設計，幾年後就可能變成 Evidence 找不到。
所以比較成熟的做法，我自己會希望 CRA Evidence Management 能跟公司既有的 Document Control、PLM、Configuration Management、Record Retention 與 Access Control 接起來。
這也是我覺得 CRA 很有意思的地方。做到後面，它已經不只是 Cybersecurity Control，還會一路碰到 Document Governance（文件治理）。

十、另外一個問題是「誰來回答？」
假設真的收到一個 CRA 相關的外部詢問，第一封信可能根本不會直接寄到 Product Security。
它可能寄給 European Subsidiary、Sales、Customer Service、Legal、Importer，甚至某個 Business Unit。如果收到的人不知道 CRA 是什麼，信件很可能就在 Inbox 裡放了好幾天。
所以我現在覺得，除了 Evidence Repository 之外，公司還需要另一件事情：Escalation Path（升級與轉送路徑）。
例如可以建立一個很簡單的 CRA Contact Model：外部 CRA / Regulatory Inquiry 進來後，先由 EU Economic Operator、Sales 或 Compliance 接收，再轉給 CRA Coordinator，由 CRA Coordinator 找到正確的 Product Owner，接著串起 Product Security、R&D、QA、Legal 等相關單位。
實際組織當然每家公司不同，但我覺得至少要讓第一線的人知道：
看到 CRA 相關詢問，要送到哪裡。
這件事情看起來很小，真的遇到事情時可能非常重要。

十一、這跟 Vulnerability Intake 其實是同一種 Governance 思維
Day 9 談 PSIRT 時，我們說 Vulnerability Report 要有明確的 Intake Channel。現在回頭看 Market Surveillance 或 Regulatory Inquiry，其實也是類似的概念。
Product Security 世界裡可能同時存在 Vulnerability Intake、Customer Security Inquiry、Regulatory Inquiry、Supplier Vulnerability Notification，以及 Security Incident Escalation。
如果每一條 Information Flow 都只是依賴「大家應該知道要找誰」，我自己會覺得風險滿高的。
所以 CRA 導入做到後面，我開始越來越重視一個看起來不太技術、卻很重要的能力：
Information Routing（資訊路由與轉送）。

十二、我甚至會想做一次「找文件演練」
這不是 CRA 規定一定要做的事情，只是我自己覺得滿實用。
假設今天隨機挑一個 Product，請 Team 找出它的 Product Classification、最新 Risk Assessment、對應 SBOM、Security Verification Evidence、EU DoC、Support Period Decision，以及最新的 Change Assessment。
然後什麼都先不要討論，只看一件事：
多久找得齊？
這個 Exercise 不需要真的模擬主管機關，也不需要討論任何執法結果，單純測試公司自己的 CRA Evidence 到底 Ready 不 Ready，我覺得就很有價值。
而且還可以再多問一題：找到的是不是「正確版本」？
例如 Product 已經到 Version 4.0，找到的 SBOM 卻是 Version 3.2，Risk Assessment 是 Version 2.0，Test Report 沒寫 Product Version，Support Period Decision 也找不到當時的 Approval。
這時問題可能不是公司沒有做 CRA，而是：
Evidence Governance 沒有跟 Product Lifecycle 同步。
這也是我自己做到這裡，開始很想避免的情況。

十三、所以我會開始建立 CRA Readiness Checklist
這裡講的不是 Annex I Checklist，而是比較偏向 Operational Readiness（營運準備度）。
例如，我可能會確認 Product Owner 找不找得到、CRA Classification Record 放在哪裡、Risk Assessment 是不是最新版本、SBOM 能不能對應 Product Version、Annex I Mapping 有沒有 Owner、Test Evidence 找不找得到、EU DoC 放在哪裡、Support Period 有沒有留下紀錄、PSIRT Contact 是誰，以及收到 Regulatory Inquiry 時應該找誰。
這些問題看起來沒有很「Cybersecurity」，但我覺得它們反而很接近 CRA 真正落地之後的日常管理。

十四、這也讓我重新思考 CRA 專案什麼時候才算完成
如果 CRA Project 的 Success Criteria 是 Procedure 寫完、Training 上完、Template 建完、Technical Documentation 做出第一版，那 Project 當然有一天可以 Close。
但 CRA Capability 不能跟著 Close。
因為 Product 還會持續經歷 Development、Release、Maintenance、Vulnerability Handling、Security Update，一直到 End of Support。
所以我自己現在比較傾向把 CRA 導入分成兩個階段：第一階段是 Build the Mechanism（建立機制），第二階段則是 Operate the Mechanism（持續運作機制）。
而我覺得第二階段反而更難。
Project Kick-off 的時候，大家通常都很認真。有 Steering Committee、有 PMO、有 Weekly Meeting、有 Consultant、有 Training，也有明確的 Deadline。
但三年後呢？
新的 Product 開始了、新的 PM 進來了、新的 R&D Team 接手了、Supplier 換了、Process 也改版了。這個時候，CRA Requirements 還有沒有被持續帶進 Product Lifecycle？
我覺得這才是 Governance 真正困難的地方。

十五、所以我現在比較喜歡談 CRA Readiness，而不是 CRA 專案完成率
Project Completion 很容易量化：完成幾份文件、辦完幾場 Training、多少 Product 做完 Classification。
但如果談的是 Operational Readiness，我自己反而會想問另一組問題：新 Product 進來時，大家知道要做什麼嗎？Product Change 時會觸發 CRA Review 嗎？Supplier Component 變更後會更新 SBOM 嗎？Vulnerability 進來會進到 PSIRT 嗎？Product Version 改變後，相關 Evidence 會同步更新嗎？幾年後還找得到當初的 Decision 與判斷理由嗎？
對我來說，這些問題可能更接近 CRA 是否真的進入公司的 Product Security Governance。

Day 19 小結｜Market Surveillance 讓我開始問「我們真的 Ready 嗎？」
研究到這裡，我自己對 Market Surveillance 最有感的部分，反而不是去猜主管機關未來會怎麼執法。因為這些涉及個案事實、主管機關權限與法律判斷，本來就不適合用一篇經驗分享文章簡單下結論。
我比較在意的是，它讓我開始反過來檢查公司自己的 CRA Readiness。
如果有一天有人問：
「你為什麼認為這個 Product 符合 CRA？」
公司能不能快速找到 Product Classification、Risk Assessment、Annex I Mapping、SBOM、Security Test Evidence、Technical Documentation、EU Declaration of Conformity，以及 Change Assessment？
而且不只是「找得到」。
這些 Evidence 的版本還要對得起來。
所以做到 Day 19，我自己越來越不把 CRA 看成一個「2027 年 12 月 11 日以前把文件做完」的專案。
我反而會把它看成：建立一套能長期運作、持續留下 Evidence，而且幾年後仍然能說明當初為什麼這樣做的 Product Security Governance Mechanism。
這可能也是我目前研究及參與 CRA 導入後，感受越來越深的一件事。
以上仍然只是我的個人心得、理解與實務思考，希望拿出來和大家交流，不代表主管機關對個別 Product 或實際情境的正式解釋。

Day 20 預告｜做到這裡，我開始發現 CRA 最大的問題可能不是技術，而是「到底誰負責？」
前面 19 天，我們已經遇到很多角色：R&D、Product Security、PSIRT、PM、QA、Compliance、Legal、Procurement、Sales、Customer Support……
做到這裡，我開始發現一個很現實的問題：
CRA 根本不是 Security Team 一個部門可以做完的事情。
但如果沒有先把 Responsibility 分清楚，最後很容易變成 SBOM 找 Security、Risk Assessment 找 Security、Article 14 找 Security、Technical Documentation 也找 Security，Supplier Requirement 最後還是找 Security。
結果只要名字裡有 Cybersecurity，好像全部都變成資安單位負責。
但這真的是最適合的做法嗎？
Day 20，我想換個角度，分享我們實際開始思考 CRA Organization 與 Responsibility 時，我自己最在意的一件事情：
資安治理單位到底應該負責什麼，又有哪些事情應該回到 Product、R&D、QA、Legal、Supply Chain 與其他 Owner？
下一篇來聊 CRA RACI，以及如何慢慢把 CRA 從「資安專案」變成真正的 Product Compliance Mechanism。