一句話摘要：
事故應變中最耗損時間的，往往不是找不到攻擊者，而是技術、法務、公關三方各自從自己的風險出發做決策，沒有共同作戰語言；跨部門作戰矩陣的價值，是把三種恐懼轉換成一套同步行動的節奏。
事故發生時，技術團隊的直覺是「趕快查清楚、趕快公開透明」；法務的直覺是「講話前先確認法律責任，避免自曝其短」；公關的直覺是「先控制敘事，別讓恐慌擴散」。三種直覺都合理，但如果沒有一套預先協調好的協作機制，三方會在事件現場互相踩剎車，技術想發公告，法務要求先審過每一個字，公關要求等到「更清楚狀況」才發聲。結果拖了六小時，社群上早已流傳各種未經證實的謠言版本。
第一線 IT/SecOps 心聲： 「我們技術面已經確認是哪個系統出問題、影響範圍多大，但要對外說一句話，法務跟公關來回改了四版還沒定稿，客戶已經在社群上炸鍋，我們卻連個安撫聲明都發不出去。」
決策層 / 業務單位迷思： 「法務覺得技術團隊講話太直白容易留下法律把柄，公關覺得技術團隊不懂輿情操作，最後乾脆什麼都不讓技術部門直接對外發言，結果資訊真空期，反而讓外界猜測往最壞的方向發展。」
當三個部門把彼此當成需要「防範」的對象，而不是「協作」的夥伴，事故應變的速度會被內部摩擦拖垮，這種內耗造成的損失，有時候比攻擊本身更傷企業。
跨部門作戰矩陣的核心設計原則，是讓技術、法務、公關三方在事件發生前，就針對「不同情境」預先協商好各自的角色分工與發言權限，而不是等到事件當下才臨時協調。
【跨部門作戰矩陣架構】
這套矩陣要真正落地，關鍵在於三方各自負責的是「輸入」，而不是互相「審查」技術負責把事實講清楚、法務負責標出法律紅線、公關負責把內容轉化成對外語言，最後彙整成一份，而不是各自寫一份互相修改到失去時效性。
以下是我實務上用來釐清三方分工邊界的對照表：
| 部門 | 應提供的輸入 | 不該做的事 | 常見衝突點 |
|---|---|---|---|
| 技術團隊 | 事實範圍、時間軸、影響系統 | 不該未經協調直接對外發言 | 想立刻公開透明，卻踩到法律紅線 |
| 法務團隊 | 監理通報義務、法律責任邊界 | 不該無限期卡住每一版文字 | 過度謹慎導致溝通 delay 到失去時效 |
| 公關團隊 | 對外語氣、輿情監控、發布時機 | 不該淡化事實或誤導受眾 | 想控制敘事，卻與技術事實脫節 |
實務設定範例（去識別化跨部門作戰群組對話節錄）：
【事故應變跨部門協調 Slack 頻道】
[14:02] IR指揮官： 確認為客戶資料庫異常存取，影響範圍約 12,000 筆帳號資訊，尚未確認是否外流。
[14:05] 法務： 依個資法第 12 條，若確認外洩需於 72 小時內通報主管機關。現在時間點屬「疑似」，建議先啟動內部通報，對外先不使用「外洩」字眼。
[14:07] 公關： 了解，那我先準備「已知悉異常，正在調查中」版本的初步聲明稿，等技術確認範圍後 30 分鐘內更新第二版。
[14:09] IR指揮官： 同意，技術團隊會在 16:00 前提供確認範圍，屆時三方對齊後統一發布。
[16:03] 技術團隊： 確認外流筆數約 3,200 筆，已鎖定並通知受影響帳號強制改密碼。
[16:15] 法務+公關： 已依確認數字更新聲明稿，16:30 統一發布，同步啟動主管機關通報程序。
這段對話的關鍵在於：每個角色都清楚自己該在什麼時間點提供什麼資訊，而不是等對方「先講」。法務沒有卡住整個流程不放行，而是給出明確的用字建議與時間框架；公關準備了「分階段更新」的聲明策略，而不是等到萬事底定才發第一份聲明。這正是預先協調機制帶來的速度優勢。
實戰行動清單：
事故應變不是技術團隊的獨角戲，法務與公關不是來扯你後腿的，他們是在保護公司不要在應變的同時又製造第二個危機。工具會換，攻擊手法會變，但三方能不能提前協調好各自的節奏，永遠決定了企業在鎂光燈下，是從容應對，還是自亂陣腳。
你的組織目前技術、法務、公關三個部門，是否曾經針對資安事件的對外溝通進行過事前演練？如果從未演練過，你覺得三方目前最大的認知落差會出現在哪個環節？
【明日 DAY 10 痛點預告】
你的公司訂閱了好幾個威脅情資（CTI）平台，每天湧入上百則 IOC 通知，但真正被用來阻擋一次攻擊的比例，可能低到讓你不敢跟老闆報告。明天拆解 CTI 落地的真相，找出為什麼「訂閱情資」跟「用得上情資」之間，隔著一條多數企業從未跨過的鴻溝。
iThome鐵人賽
看影片追技術