資安長導入 ISO/IEC 30111：漏洞處理流程怎麼接上 CRA 通報？

已有資安事件應變程序，資安長為什麼還要建 ISO/IEC 30111 漏洞處理流程？

事件處理（ISO/IEC 27035）處理「已發生的攻擊」，漏洞處理（ISO/IEC 30111）處理「被回報的弱點」，兩者的觸發來源、時限與產出不同。既有事件流程是好基礎，但 CRA 稽核的是漏洞專屬的流程與證據。

上市櫃公司依《上市上櫃公司資通安全管控指引》第 34 條訂定的應變與通報程序，針對的是公司自身的資通系統；產品的 CRA 漏洞通報，要另外接上產品端的 30111 流程。非公開發行公司不受此指引規範，可自願參考。

產品漏洞遭主動利用時，資安長的法定通報時限是多少？

依 EU CRA 第 14 條：

• 經 ENISA 單一通報平台，24 小時內早期預警、72 小時內漏洞通報；矯正或緩解措施可用後 14 日內提交最終報告。
• 自 2026 年 9 月 11 日起適用，且及於 2027 年 12 月 11 日前已上市的產品。

同一起事件可能同時觸發 GDPR、NIS2、DORA 的時限，起算點與受理機關各不相同；應變程序要把各項並列，由同一個事件分類步驟判斷要通報哪幾項。沒有事前建好的內部流程，時限內很難來得及。

ISO/IEC 30111 能涵蓋 CRA 漏洞處理要求到什麼程度？哪些要另外補？

CRA 本身沒有指名 ISO/IEC 30111。依 JRC 與 ENISA 2024 年的對映分析：

報告也指出沒有任何單一標準能完整涵蓋所有面向；這份對映是分析文件，不是調和標準，不產生符合性推定。

客戶或公告機構稽核漏洞處理時，資安長要拿出哪些證據？

對資安長而言，30111 的重點是可稽核的流程與紀錄。典型導入產出：

• 漏洞處理政策與流程文件
• 分級準則（如 CVSS 本地化準則）
• 處理紀錄與 SLA 報表機制
• SBOM 銜接程序
• 與 29147 揭露端的介接文件

全部以「可被公告機構與客戶稽核」為標準。常見缺口：沒有產品與元件清單而無法判斷影響範圍、分級準則只寫在個人經驗裡、舊版本與停產型號沒人負責。

支援期內的舊產品也要處理漏洞嗎？資安長怎麼配置責任？

要。CRA 要求製造商自產品上市起、在整個支援期間依附件一第二部分有效處理漏洞（第 13(8) 條）：

• 支援期間至少五年（預期使用時間少於五年者，依其預期使用時間），結束日（至少含年、月）須於購買時清楚標示（第 13(19) 條）。
• 支援期間內發布的每一項安全更新，自發布起至少保留 10 年或至支援期間結束，以較長者為準（第 13(9) 條）。

資安長要把每一關的負責人與時限寫成流程與 SLA；維護多條產品線者，另需設計漏洞影響面評估的橫向機制。

30111 怎麼和 29147、ISO 27001 共用證據，並放進董事會報告？

• 和 29147 成對：29147 管對外受理與公告，30111 管內部處理；兩份標準互相引用、流程互相銜接，分開導入會在交接面留下稽核缺口。
• 掛在 ISMS 上：已有 ISO 27001 者，可把 CVD 流程掛載於既有 ISMS，文件與稽核機制共用。
• 董事會報告：《上市上櫃公司資通安全管控指引》第 37 條要求定期向董事會或管理階層報告資通安全執行情形，可把適用判定、通報演練與稽核結果放進同一份報告。非公開發行公司不受此指引規範，可自願參考。

積穗科研怎麼協助資安長處理 ISO/IEC 30111？

積穗科研的做法（請用上方問題同樣檢驗我們）：

• 副總、董事級顧問全程親自輔導、不外包
• 把收單到發布每一關的負責人與時限寫成可稽核的流程與 SLA，接上 ISO/IEC 27035、27036
• 建立 SBOM 銜接程序；積穗自身交付管線每日產製、簽章並監測 SBOM
• 29147 與 30111 成對導入

ISO/IEC 30111 導入輔導、30111 顧問怎麼選、CRA 由誰主導。申請免費機制診斷