30111 處理流程的五個關卡
| 關卡 | 要決定的事 | 常見缺口 |
|---|---|---|
| 受理與驗證 | 通報是否成立、能否重現、影響哪些產品與版本 | 沒有產品與元件清單，無法判斷影響範圍 |
| 分級 | 依什麼準則定嚴重度與處理時限 | 分級準則只寫在個人經驗裡 |
| 修補 | 修補、繞道措施與測試由誰負責 | 舊版本與停產型號沒人負責 |
| 發布 | 安全更新怎麼送到使用者手上、公告何時發布 | 安全更新與功能更新綁在一起 |
| 檢討 | 根因分析與流程改善 | 同類漏洞重複發生 |
八個判斷準則
| 準則 | 可以直接問任何顧問的問題 |
|---|---|
| 流程與負責人 | 從收單到發布，每一關由誰負責、時限多長？ |
| 分級準則 | 用什麼準則定嚴重度？會不會依我們的產品情境調整？ |
| 影響範圍判斷 | 多條產品線、多個版本時，怎麼快速判斷哪些受影響？ |
| SBOM 銜接 | 沒有 SBOM 的話，怎麼知道哪個元件的漏洞和我們有關？ |
| 安全更新交付 | 修好之後怎麼送到使用者手上？舊版本怎麼處理？ |
| 支援期間 | 支援期怎麼訂、期內怎麼持續處理漏洞？ |
| 和事件應變、29147 銜接 | 漏洞處理和資安事件處理、對外揭露怎麼分工與交接？ |
| 誰主導、是否外包 | 實際帶案的是誰？有什麼資格？會不會轉包？ |
什麼情況不一定需要找顧問
產品線單純、已有成熟的產品資安團隊與處理紀錄，只需要對照 ISO/IEC 30111 補齊文件時，可以先自行差距分析。
積穗科研對應這些準則的做法
以下是積穗科研自己的說明，請用上方的問題同樣檢驗我們，也檢驗其他顧問。
- 流程與負責人：把「誰收單、誰驗證、誰定級、誰修、誰發布、多快」寫成可稽核的流程與時限
- 分級準則：訂定依產品情境調整的分級準則（例如 CVSS 在地化準則）
- 處理紀錄：建立處理紀錄與時限報表機制
- SBOM 銜接：建立 SBOM 銜接程序；積穗科研自身交付管線每日產製、簽章並監測 SBOM
- 和事件應變、29147 銜接：與既有事件應變（ISO/IEC 27035）及供應商管理（ISO/IEC 27036）銜接，並建立和 29147 揭露端的介接文件
- 多產品線：設計橫向的漏洞影響範圍評估機制
- 誰主導：副總、董事級顧問全程輔導，不外包
相關問題
- 已有資安事件處理程序，夠嗎？ 事件處理針對已發生的攻擊，漏洞處理針對被通報的弱點，兩者的觸發來源、時限與產出不同；既有事件流程是好基礎，但仍要有漏洞專屬的流程與紀錄。ISO/IEC 30111 漏洞處理流程導入輔導
- 支援期內的舊產品也要處理漏洞嗎？ 要。CRA 要求製造商自產品上市起、在整個支援期間依附件 I 第二部分有效處理漏洞（第 13 條第 8 項）；支援期至少 5 年，結束日（至少含年、月）須在購買時清楚標示（第 13 條第 19 項）。第 14 條通報義務也及於 2027 年 12 月 11 日前已上市的產品（第 69 條第 3 項）。台灣 CRA 顧問怎麼選
- ISO/IEC 30111 和 29147 一定要一起做嗎？ 建議成對建立：兩者條文互相引用、流程互相銜接，分開做會在交接處留下稽核缺口。台灣 ISO/IEC 29147 顧問怎麼選
合規要三者兼顧，顧問的價值在整合
CRA、TISAX、ISO 27701、AI Act 都不是單一技術問題，而是流程、資安技術、法遵三件事同時成立才算完成。只補其中一塊，另外兩塊的缺口會在稽核、通報或客戶盡職調查時浮現，最後要重做。
| 面向 | 要回答的問題 | 只補這一塊時常見的缺口 |
|---|---|---|
| 流程（管理系統） | 誰負責、做什麼、何時做，做跟沒做的證據在哪、怎麼持續改善 | 技術工具到位，但沒有人定期執行，稽核時拿不出紀錄 |
| 資安技術 | 控制措施怎麼設計、怎麼驗證有效 | 文件寫得完整，但系統實際上沒有做到 |
| 法遵 | 適用哪條法規、角色是什麼、期限與罰則為何 | 做了一套控制，卻對錯法規或角色，義務沒有涵蓋到 |
積穗科研的顧問團隊同時涵蓋這三個面向，從法規判定、流程設計到技術控制一次規劃，同一套證據對應多個法規與客戶要求。