iT邦幫忙

2026 iThome 鐵人賽

DAY 18
1

一個案子在系統裡的狀態是「調查中」。

三天過去,狀態還是「調查中」,因為工程師還在復現那個條件。而法定的 72 小時,昨天就到了。

**這件事的可怕之處在於:沒有人做錯任何事。**研判在跑、修補在排、通報者也有收到回覆。壞掉的是設計——時鐘被綁在案件狀態上。

https://ithelp.ithome.com.tw/upload/images/20260918/20169113vfr9uNOXEN.png
為什麼大家都會綁在一起

因為直覺上很合理。案件流程是收件、研判、修補、結案,時限看起來就該掛在階段上:研判階段幾天、修補階段幾天。

但法定時鐘並不是流程裡的一個階段。它是一條平行跑的獨立軌道,起點在「知悉」,跟你的流程走到哪裡完全無關。

送修的機器有兩條線。維修進度是一條,保固期限是另一條。保固不會因為維修還沒完成就暫停,它從購買日起算,跟修到哪了無關。你不會把保固到期日寫在工單的狀態欄裡。

同一句話換成資安的講法:案件狀態描述的是你做到哪,合規時鐘描述的是世界過了多久。

合規時鐘要有自己的欄位

它不是一個狀態,是一組欄位。
https://ithelp.ithome.com.tw/upload/images/20260918/20169113wPLfvZ2p6n.jpg
**第一列是整組欄位的錨。**起算時間戳一旦寫入就不能改,要改必須留下誰改的、為什麼改、原值是什麼。這一格如果可以被隨手修改,後面所有紀錄的可信度都會歸零。

倒數第二列也值得多說一句。「內容快照」的意思是把當時真正送出去的那份東西存起來,而不是存一個會隨著案件更新而變動的連結。半年後你要證明的是「我們那時候送了什麼」,而不是「我們現在知道什麼」。

三個讓它真正脫鉤的設計

**一、時鐘由 L1 分軌時啟動,不等研判完成。**這是脫鉤的第一步,也是最關鍵的一步。分到軌一就開始計時,即使那時候你對這個弱點還一無所知。

**二、到期前的提醒發給決策人,不發給工程師。**工程師收到提醒也沒有用,他不能按送出鍵。提醒發錯對象,實際效果等於沒有提醒。

**三、案件結案不會關掉時鐘。**時鐘只有兩種結束方式:已送出,或已撤回。「案件已結案」跟「通報義務已履行」是兩件事,而且它們可以在不同的日子發生。

法務要在什麼時候進來

最常見的錯是等技術調查有結論才通知法務。

正確的時間點是分軌到軌一的那一刻。

理由有兩個。法務要準備的東西需要前置時間:對外措辭、與主管機關往來的窗口、留存與保密的要求。而且他們評估的角度跟工程師不一樣,早一點知道才來得及提出問題。

但有一句話要講清楚,否則這個設計會走樣:**通知法務不等於交給法務決定。**按送出鍵的還是 Day 12 那個有名字的決策人。法務提供的是意見與文字,不是決策權。

實務上這件事可以做得很輕:軌一啟動時自動發一則通知,內容三行就夠——案件編號、目前已知什麼、下一個到期時間。

稽核軌跡要留成什麼樣

查廠的時候,市場監管機關真正會問的只有三題:你什麼時候知悉的、你怎麼判斷的、你送了什麼。

對應要留的東西也就三類:原始通報(包含 Day 15 那批被 L0 判為垃圾、隔離九十天的)、L1 的五問卡、以及上面那組時鐘欄位與送出快照。

這裡有一個觀念要調整。留紀錄的目的,不在證明你做對了,而在證明你當時是怎麼判斷的。

判斷錯了但流程完整、依據清楚,那是一個可以解釋的錯誤。判斷對了卻說不出當時憑什麼,在稽核的場合反而更難處理,因為那代表下一次你也可能判錯,而且一樣說不清楚。

幕三收束:先跑最小可行流程,不要等平台

六天講完了流程。這時候最常見的下一步錯誤是:「我們來評估一個案件管理平台。」

平台採購、導入、串接要三到六個月,而時鐘已經在跑。

最小可行的版本是四樣東西:一個共用信箱、一份試算表、一份 L1 五問卡、一組行事曆提醒。

今天下午就能建好,而且它們產生的紀錄跟平台產生的一樣可以被稽核。市場監管機關不會問你用什麼系統,只會問你答不答得出那三題。

**先讓流程跑起來,再讓工具跟上。**倒過來做的公司,通常在平台上線那天才發現流程根本沒想清楚,然後把三個月的採購時間變成三個月的空白。

交付物:最小可行流程清單

四樣東西,今天就能開始。
https://ithelp.ithome.com.tw/upload/images/20260918/20169113sVyI3tCjVF.jpg

三個提醒。

**第一,試算表的起算時間戳那一欄請設成鎖定或受保護。**聽起來很小題大作,但這一格被改過的試算表,在稽核時什麼都證明不了。

**第二,行事曆提醒的受邀者要放名字,不要放群組信箱。**群組信箱的提醒,人人都以為別人會處理。

**第三,這四樣東西從第一天起就要留檔,即使你打算三個月後換平台。**換平台的時候這些紀錄要能搬過去,而不是重新開始。歷史紀錄的價值隨時間增加,斷掉一次就補不回來了。

幕三到這裡結束。

撤回來的部隊有了防線:入口統一、隊列分開、L0 過濾、L1 分軌、三級分流,最後是一條跟誰都不相干、只跟時間有關的獨立時鐘。

但防線守得住多久,取決於後方。接下來八天要談的,是造船廠裡的事。

明天 Day 19:長鬧鐘那頭在等的十三條要求與八條流程

Annex I Part I 的十三項必要要求、Part II 的八項流程要求,逐項對照,並標出哪幾項對硬體廠特別難。這是整個系列的大轉折:從「通報進來怎麼辦」轉向「產品本身站不站得住」。

順便問一句。你們現在如果要回答「這件案子是什麼時候知悉的」:

查得到一個精確到分鐘、而且沒有人能事後修改的時間戳嗎?

(a)查得到,而且鎖住了 (b)查得到,但可以被編輯 (c)要翻信箱推算 (d)查不到

留個字母就好,不用打長篇。(b)比(c)更值得處理,因為它給人一種已經做好了的錯覺。

這系列每天更新,覺得有用的話幫忙訂閱,謝謝。

參考:Regulation (EU) 2024/2847 第 14、31 條與 Annex I Part II(5)(6);ISO/IEC 30111。時鐘欄位規格、脫鉤設計與最小可行流程為個人整理,非法規明文。


上一篇
Day 17|分級不要做太細
下一篇
Day 19|我們解決的是門鈴,不是房子
系列文
時鐘從「知悉」開始:從零打造 PSIRT,三十天走完歐盟 CRA 的通報與 SBOM22
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

1
hunterlin
iT邦新手 5 級 ‧ 2026-09-18 10:51:07

最小可行的版本是四樣東西:一個共用信箱、一份試算表、一份 L1 五問卡、一組行事曆提醒。
--> 推精闢的整理,確實能夠在案件管理平台導入前直接動起來

resorce iT邦新手 4 級 ‧ 2026-09-19 08:06:35 檢舉

CRA就是跟時間還有流程賽跑

我要留言

立即登入留言