上一篇說明了 CRA Article 14 的通報時限與觸發條件，規則本身其實不複雜。真正困難的，是將其轉化為一套組織內部每個人都清楚如何運作的流程。弱點是研發部門先發現，還是客服接獲用戶反應？由誰判定這是否構成「積極被利用」？24 小時的計時自何時起算？第一份通報又由誰負責提交？這些問題若平時未曾演練，真正遭遇弱點事件時，光是釐清「此事歸屬何人」，便可能耗去大半個 24 小時。本篇要談的，正是這套內部流程實際上應如何設計與落實。
多數較成熟的弱點管理流程，可拆解為以下幾個階段。
接受：對外須設有公開、明確的漏洞回報窗口，讓研究人員、客戶、合作夥伴均能找到管道通報疑似弱點。此窗口須由專人受理，不能僅以自動化表單接收後無後續處理。
驗證：收到通報後，先確認是否為真實存在的弱點，濾除誤報。
風險分析：確認為真實弱點後，評估其風險等級。此步驟並非主觀評斷，而是依循一套既定方法，將影響程度與被利用的可能性一併納入考量，最終落於高、中、低。至於實務上如何權衡、界線如何拿捏，往往是各家差異最大、也最需要專業判斷之處。
分岔點：判為高風險者，進入修復路徑——修復、驗證修復是否確實有效、對外報告、將更新分發予客戶，最後於客戶端進行市場驗證，確認弱點確已排除，方能結案。判為低風險者——部分情形可採風險轉移，在產品文件或使用說明中明確告知：「於特定且發生機率極低的情境下如此操作可能帶來何種風險，建議避免。」此亦屬有紀錄、可交代的處理方式。
此處有一項平時無感、稽核時卻常被查核的重點：整套流程必須落地成文。僅以「已有工具在運作」並不足夠，尚須有文件明載每一步驟如何執行、由誰負責、判斷標準為何。稽核邏輯通常是先檢視文件所載，再回頭驗證企業是否確實照辦。文件與實作一致，流程方能通過檢驗。
另一項常被低估的面向，是同一家公司內部的風險基準，不應一體適用。實際舉例來說，當企業橫跨多條產品線時，各產品線可承受的風險程度往往存在實質差異，部署於關鍵基礎設施場域的產品，與面向終端消費者的周邊配件，兩者縱使發生同等技術嚴重度的弱點，其下游衝擊與被實際利用的可能性亦不在同一量級，自然不宜套用單一的風險接受標準。
這樣的差異，通常須沿數個維度個別評估：產品的實際部署環境與使用者暴露面、其在 CRA 下所屬的分類（Default、Important 或 Critical），以及發生弱點後的可修補性——例如能否透過 OTA 即時推送更新，或產品已大量鋪貨、實務上難以回收處理。這些維度共同決定了一條產品線在特定情境下「應否、以及能否接受某一風險」的判斷基準。因此，較穩健的做法是依產品線分別建立風險分級準則，而非於組織層級套用單一標準——後者容易導致以較寬鬆的基準，去衡量本應採取更保守立場的高風險場域產品。
許多企業初次接觸 Article 14 時，會將「通報主管機關」與「通知客戶」視為同一件事。這其實是兩項平行、性質亦不相同的義務。
通報主管機關，須經 ENISA 建立的單一通報平台（SRP），依製造商主要營業地所在會員國，送達指定的協調者 CSIRT。此一管道的對象是監管機關，使用電子郵件、電話等非正式管道將不予認可。
通知客戶則屬另一項義務，其法源為 Article 14(8)。製造商於得知弱點被積極利用或發生嚴重事故後，須讓受影響的用戶（適當時包含所有用戶）知悉此事，以及必要時可採取哪些緩解或修正措施。此項義務的重點在於，即使修復尚未完成，也須先讓用戶知悉當下應如何因應。常見做法是 OTA 推播、Email 通知、官網資安公告等並行採用，內容至少須涵蓋當下可行的緩解措施，以及修補程式是否已釋出或預計釋出的時間。
通知發出後，流程尚未結束。企業仍須有機制確認客戶端是否確實完成因應，可能是主動回訪，也可能是持續蒐集回饋；通知發出後客戶端未再回報問題，某種程度上亦屬佐證。「市場驗證」這一步常被省略，但它正是前述流程節點在實務上必須落實之事。
一、第三方元件的通報責任，不會因主產品被排除而一併消失。實務上常見的誤解是：零組件被整合進一項本身受其他法規規範、排除於 CRA 之外的產品後，該零組件即無須顧慮 CRA。但這牽涉到零組件是否落在 CRA 適用範圍的獨立判斷（涉及數個容易混淆的條件，將於後續談產品適用範圍時另行說明）。就通報義務而言，關鍵在於：一旦觸發通報，責任未必集中於單一窗口——產品製造商與零組件製造商可能各自負有通報義務，無法相互推諉為對方的責任。對半導體與模組廠而言，這意味著即使自身僅為供應鏈中的一環，仍可能是法規要求下的通報義務人之一。
二、CVD 政策與 Article 14 通報是兩回事，但會在關鍵時刻交會。協調式漏洞揭露（CVD）政策的義務來源在 Article 13(8)，其內容規範見 Annex I 第二部分第 5 點，均非 Article 14 本身。CVD 規範的是企業對外受理、確認、修復、揭露弱點的日常流程；Article 14 則是當其中某個弱點被判定為積極被利用時，方另外啟動的強制監管通報。兩者平時各自運作，唯有觸發積極利用的門檻時才會同步，並於修復與公告發布階段交會。釐清這層分工，才不會誤以為完成了日常的漏洞受理，即等同履行了 Article 14 的通報義務。
三、草案標準可作為建置藍圖，但尚不能作為合規證明。目前有一份專門規範弱點處理流程的草案標準（prEN 40000-1-3），對流程中每一步的輸入、產出與評估基準均規範得相當具體，適合用於建置一套可稽核、可追溯的流程。但該標準仍處草案階段，尚未列入歐盟官方公報（OJEU）的引用清單，現階段套用並無法取得合規推定的法律效力。建議將其作為流程建置時的參考底稿，而非對外主張「已符合規範」的證明文件。在 40000 系列定案之前，業界建置弱點處理流程時，通常仍以既有的成熟國際標準為基礎，例如 ISO/IEC 29147（弱點揭露）與 ISO/IEC 30111（弱點處理）。
Article 14 真正考驗的，是企業能否將這套流程實際建置起來，並留存經得起驗證的文件。多數製造商卡關之處也在於此：癥結不在於不了解該做什麼，而在於難以判斷現行做法是否充分、文件是否完備，以及多條產品線之間的基準落差應如何收斂。
實務上，企業導入這類流程時，一般會先做既有流程的落差分析（gap assessment）：若已具備自有的漏洞管理流程與工具，先檢視文件與實際執行是否一致，再指出待補強的環節；若尚未建立，則需要一套完整的流程框架，協助逐步對接自身的系統與組織分工。須特別說明的是，對外通報的法定責任始終歸屬製造商，顧問角色協助的是流程建置，並不能代為履行通報。
需要提醒的是流程建置與落地執行之間，往往還有一段距離——文件寫得再完整，若無人協助落地演練、確認每個環節真的能在時限內運作，遇到真實事件時仍可能卡關，這正是多數企業在導入初期最容易低估的部分。
歡迎參加 9 月 18 日（五）台北實體研討會，直接向來自西班牙的 CRA 專家提問，進一步說明 2027 合規規劃佈局及導入所需的時間與成本估算。報名連結：實體研討會報名連結
Q：漏洞通報的內部流程應如何建立？
基本架構是：建立公開漏洞受理窗口→驗證漏洞是否屬實→視影響程度與發生可能性做風險分級→高風險修復、低風險轉移→驗證修復→對外部通報及分發更新→市場驗證結案。整個流程必須被落地成文，才能在稽核時發揮效用。
Q：通知主管機關和通知客戶是同一件事嗎？
不是。通知機關使用的是 ENISA 的單一通報平台（SRP）；通知客戶是另一項平行義務（Article 14(8)），須告知受影響用戶知悉風險與可採取的緩解措施，通常透過 OTA、電子郵件及官方網站公告同步進行。
Q：誰負責申報第三方元件？
一旦觸發通報，責任可能不會集中於單一管道——產品製造商與元件製造商可能各自負有通報義務，無法互相推卸責任。即使企業只是供應鏈中的一個環節，仍可能成為法律要求下的通報義務人之一。
本文所引法規條文與時間點，均以下列官方文件為準：
文／安合規律 × Applus+ Laboratories 顧問團隊
＊本文為法規解讀性質，非法律意見。個案之最終認定，仍應以歐盟官方文件與主管機關解釋為準。
