前面三天在講問題有多大。今天講整個系列的骨架，也是我這半年想通的最重要一件事。

CRA 給製造商兩個期限，中間隔十五個月。

2026 年 9 月 11 日，第 14 條通報義務生效。發現產品有正在被利用的弱點，24 小時內送早期預警、72 小時內送漏洞通報、14 天內送最終報告。

2027 年 12 月 11 日，全面適用。所有進歐盟市場的產品都要符合 Annex I、備妥技術文件、完成符合性聲明、貼上 CE 標示。

看起來只是一個近、一個遠。實際上它們是兩種完全不同的工程。

一個是失火，一個是抗震補強

短鬧鐘像家裡失火。

失火的時候你不會先開會、排甘特圖、盤點資源、跑一輪需求訪談。你要的是三件事：**知道滅火器在哪、知道誰去拿、知道拿了往哪噴。**這三件事必須在起火之前就決定好，因為起火之後沒有時間決定。

長鬧鐘像房子要做抗震補強。

補強不會有人半夜打電話叫你起床。它需要結構技師、需要圖說、需要施工計畫、需要分階段驗收，而且做完之後外觀看不太出來。你不可能靠加班在兩週內補強完一棟樓，硬做出來的東西第一次驗收就會被打回票。

這兩件事都要做，但用同一種方法處理，一定會失敗其中一件。

失火用專案管理的節奏做，來不及。你還在排甘特圖，時鐘已經在跑。

補強用救火的節奏做，會做爛。安全開發流程不是熬夜兩週生得出來的東西，它得跟研發的既有流程長在一起，硬塞的那種查廠時撐不住。

最容易被搞混的是**「最需要的資源」那一列**。

很多人聽到 CRA，第一個反應是「我們要增加人力」。但短鬧鐘不需要新編制。它需要的是：一個被書面指定的通報決策人、一份寫好的 runbook、一條講清楚的升級路徑，還有一個判斷標準來決定什麼情況要按下送出鍵。

這四樣東西，用現有的人就能做完，只是需要有人拍板。做不完的原因通常不是人不夠，是沒有人被指定。

反過來，長鬧鐘再怎麼指定也沒用。SBOM 管線、安全開發流程、產品分類判定、技術文件，這些是真的要工時堆出來的，而且要跨部門。你可以指定一個人負責，但他一個人做不完。

為什麼一定要分開講

因為兩個鬧鐘的資源會互相搶。

我看過的常見失敗模式是這樣：團隊把力氣全押在長鬧鐘，因為它看起來比較「正規」——有專案、有里程碑、有交付物、可以寫進年度目標。結果九月十一號那天，通報流程還停留在「應該是資安負責吧」的階段。

反過來的失敗也存在：整個團隊被通報流程綁住，每天在處理案件，十六個月過去了，技術文件一頁都沒有。等到 2027 年第三季才想起來，那時候已經來不及。

正確的做法是兩條線並行，但用不同的節奏管理。

短鬧鐘用檢核表管：四件事做完沒有，沒有就補，不需要專案編號。

長鬧鐘用季度里程碑管：這一季要交出什麼、下一季要什麼，可以慢，但不能停。

交付物：這件事屬於哪個鬧鐘

接下來十六個月，會有很多事情丟到你桌上。這張表拿來分類。

三個提醒：

**兩邊都符合的，先當短鬧鐘處理。**例如既有產品盤點：它是長鬧鐘的基礎工程，但你 9/11 之後如果收到通報，第一件事就是查「這型號還在支援期內嗎」，答不出來就卡住。

**只符合長鬧鐘但很急的，通常是被誤判了。**回頭確認一次它有沒有法定時限，多數情況下那個「急」來自內部承諾，不是來自法規。

**如果一件事兩邊都不符合，很可能它根本不是 CRA 的事。**這一點在資源有限的時候特別重要，因為你的團隊會被塞進各種「跟資安有關」的雜事，而 CRA 剛好給了你一個很好的拒絕理由。

明天 Day 05：24 小時、72 小時、14 天

短鬧鐘的細節全解。三個時限分別要交什麼、時鐘從哪一刻開始跑、重大事件為什麼是一個月而不是 14 天。附一張可以印出來貼在牆上的時鐘卡。

順便問一句。如果現在你手上同時有這兩件事：

你會先做哪一個？

（a）先把通報流程弄好　（b）先做 SBOM 跟技術文件　（c）兩邊並行，但人力不夠　（d）老闆還沒決定

留個字母就好，不用打長篇。我自己是（c），而且對「人力不夠」那半句還沒有好答案。

這系列每天更新，覺得有用的話訂閱一下，我盡量不寫廢話。

參考：Regulation (EU) 2024/2847 第 13、14、28、30、31 條與 Annex I、Annex VII；通報義務生效日 2026/09/11、全面適用日 2027/12/11。