兩家規模相近的公司，幾乎在同一個月被植入類似的攻擊手法，防護設備等級相近，備份頻率也差不多。但接下來的發展完全不同，一家在幾天內恢復上架、客戶幾乎沒有察覺，另一家的網站卻停擺了將近兩個星期，客服信箱塞滿詢問，合作的廠商也開始觀望要不要繼續往來。同樣面對網站被駭怎麼辦這個處境，兩家公司走出來的結果卻天差地遠。
差別看起來像是運氣，其實不是。真正拉開距離的，不是資安預算的多寡，而是被駭當下的頭一個小時裡，誰先做了哪些決定，又踩到哪些不該碰的地雷。多數經營者遇到這個處境時，腦中閃過的第一個念頭往往是趕快找人來修，但修復本身不是最急的事，順序錯了才是真正拉長停擺時間、放大損失的原因。
這篇要談的不是技術排錯手冊，伺服器怎麼抓漏洞、程式碼哪裡出問題，那是技術人員的工作。這裡整理的是給不懂程式的經營者一份判斷順序，先從怎麼確認自己是不是真的被駭講起。
網站真的被駭了嗎？先核對這幾個跡象
網站當機或是網頁跑得比平常慢，不代表就是被駭，這兩種狀況常常只是主機資源不足或程式衝突。真正被入侵時出現的跡象，通常有幾個具體、經營者自己就能對照的線索。
- 首頁或內頁的內容被竄改，例如冒出不認識的連結、廣告，或整個網站被替換成完全不相關的頁面
- Google 搜尋結果旁出現網站可能遭駭的警示，或是 Search Console 收到安全性問題通知
- 後台登入紀錄或流量出現異常，像是短時間內大量登入失敗，或後台多出不認識的管理員帳號
- 客戶反映收到看起來像是你寄出、卻要求對方點連結輸入資料的可疑信件
- 自己或客戶寄出的信件開始被對方的信箱系統列入垃圾信或黑名單
這五種跡象只要出現一種就該提高警覺，同時出現兩種以上，幾乎可以確定不是單純的技術故障。Google 官方對這類警示有明確說明，一旦系統判定網站遭到入侵、被用來散布惡意內容或竊取使用者資料，就會在搜尋結果與瀏覽器提示裡顯示警示，提醒使用者這個網站可能不安全。先把這幾項核對清楚，再往下讀網站被駭怎麼辦的應變流程，才不會把單純的主機當機或程式錯誤，誤判成資安事件處理。
發現後的第一個 30 分鐘，哪些事能做、哪些事千萬不能做
確認網站真的被駭之後，接下來這三十分鐘，決定的往往不是能不能修好，而是修好之後查不查得到漏洞在哪裡。這段時間該做的事其實不複雜。先讓網站下線或切換成維護頁面止血，避免更多訪客或客戶繼續受影響；接著更換後台、主機、資料庫等相關帳號密碼，尤其是曾經在多個服務共用過的密碼；同時把目前的狀態完整備份留存，當成案發現場保留，跟平常定期做的正常備份分開存放，不要互相覆蓋。
真正容易出錯的，反而是接下來這幾件看起來很合理、卻千萬不能做的事。第一個地雷是急著把看起來可疑的檔案刪掉，直覺上覺得刪掉就乾淨了，但駭客留下的入侵痕跡也會跟著一起消失，之後想追查到底是哪個漏洞被攻破，線索就斷了。第二個地雷是急著拿舊的備份直接覆蓋回去，同樣的道理，舊備份能讓網站看起來恢復正常，卻沒有解決漏洞本身，而且原本能拿來追查的證據也一併被蓋掉。第三個地雷是自己在社群或公開頻道貼出攻擊細節，這麼做沒有幫助，反而等於公開示範漏洞在哪裡，引來其他人跟著攻擊。
美國聯邦貿易委員會在企業資料外洩應變指南裡，把不要銷毀證據列為核心原則之一，強調止血動作與保留跡證要同時進行，而不是清乾淨就結案，這也是這段時間最容易被情急之下忽略的一點。
該先打給主機商，還是先打給客戶？
止血動作啟動之後，接下來的問題是聯絡順序，該先打給誰。多數經營者直覺會想先安撫客戶，或是先打給比較熟的朋友問意見，但真正該依循的是對止血與釐清真相有多急迫，而不是人情或職位高低。美國國家標準與技術研究院在資安事件應變指南裡，把技術處理、溝通對外與管理決策拆成不同角色分工，這套邏輯放到中小企業身上，往往是同一個人身兼多角，但順序的邏輯依然適用。順序一旦排錯，不只沒有幫上忙，反而可能讓場面更亂，例如員工各自對客戶或媒體講出不同版本的說法。
第一通：先聯絡能動主機與程式的人
不管網站是自己架設，還是委外由廠商維護，第一通電話都要打給真正能檢查伺服器與程式碼的人，可能是原本配合的維護方、主機代管商，或內部的資訊人員。這通電話該講的是看到的事實，不是猜測的原因，包括發生的大概時間、看到的異常畫面、有沒有被要求輸入資料、後台是否出現不認識的帳號。愈精確的描述，對方愈能快速判斷問題出在哪一層，不必浪費時間來回確認。
第二通：內部團隊，統一對外的說法
技術止血啟動之後，第二步是讓內部相關人員知道發生了什麼事，並且講清楚接下來由誰統一對外發言。小公司可能沒有正式的公關職稱，由老闆自己扛下這個角色也沒有關係，重點是所有人講的版本要一致。一旦員工各自對客戶、廠商或媒體講出不同說法，反而會製造更多混亂與謠言，讓原本單純的技術問題演變成信任危機。
第三通：受影響的客戶與合作夥伴
技術面止血、內部口徑統一之後，才輪到通知客戶與有資料串接的合作夥伴。這一步不是第一通電話，但也不能拖到最後才處理，判斷要不要通知、怎麼通知的細節，留到下一節專門展開；這裡先確認它在整個聯絡順序裡的位置，是排在第三順位，不是最優先，也不是可以無限期延後的事。
視情況：官方受理窗口
如果研判事件牽涉個資外洩，或屬於影響範圍較大的資安事件，可以視情況向官方協處窗口通報。依數位發展部的說明，民間企業遇到資安事件或個資外洩，可以通報 TWCERT/CC 尋求跨單位的協處資源與免費諮詢。這一步不是每次被駭都必要，但老闆該知道有這個管道存在，遇到規模較大的事件時可以派上用場。
客戶要不要通知？商譽與法律責任怎麼算？
聯絡順序裡的第三通電話，對象是客戶，但要不要通知，牽涉的不只是溝通技巧，還有法律責任。很多經營者的直覺反應是先別說，大事化小，但法律沒有給這個選擇的空間。依個人資料保護法第十二條規定，只要知悉客戶的個人資料遭到竊取、竄改或洩漏，就有通知當事人的義務，不是看情況決定要不要講的選擇題。個人資料保護委員會籌備處對通知方式也有具體說明，書面、簡訊、電子郵件或公告都可以，依受影響人數多寡調整，不必人人都寄一封正式公文。
不過通知義務不代表要等到查清楚所有細節才開口，反而是愈早讓客戶知道發生了什麼、你正在做什麼，愈能降低對方的不安與後續的糾紛。國際上對這件事的態度更嚴格，歐盟一般資料保護規則規定，企業必須在七十二小時內向主管機關通報資料外洩事件。台灣目前沒有這麼硬性的時限規定，但通知義務同樣存在，拖延本身就是風險，不會因為法規沒有訂出小時數，就代表可以慢慢處理。
通知內容不必等到查清全部真相
通知客戶不必是一次到位的公告，可以先講已經確認的事實，以及目前採取了哪些措施，後續有新進展再補充說明即可。真正該避免的，是為了安撫情緒而做出誇大或不實的保證，例如事情都還沒確認清楚，就先跟客戶說絕對安全，這種說法一旦後續狀況有變化，反而會讓客戶的信任流失得更快。
清除威脅這一關，老闆該確認什麼、不必自己動手
通知的溝通問題告一段落之後，回頭要面對的是技術面的清除工作。這一關最容易被誤解成刪掉可疑檔案、網站恢復運作就算結案，但老闆真正該確認的，是處理團隊有沒有把三件事做到位。第一，有沒有真正找到入侵路徑，而不是只刪掉表面看到的可疑檔案，只清掉症狀、沒找到根本原因，通常過沒多久就會再度中招。第二，資料庫與帳號權限有沒有一併檢查，駭客入侵後常常會留下額外的後門帳號，單看前台檔案很容易漏掉這一塊。第三，準備拿來還原的乾淨版本，確認的時間點是不是真的在入侵發生之前，如果選錯還原點，等於把已經被植入問題的版本重新放回去。
反覆被駭，通常代表前一次只清了表面，沒有真正堵住漏洞入口，這才是老闆該追問處理團隊的重點，而不是自己動手改程式碼。美國聯邦貿易委員會的指南也把驗證修復列為必要步驟，強調清除威脅之後還要確認漏洞真的被補上，而不是看網站恢復正常運作就直接結案。
重新上線後，接下來 48 小時要盯緊什麼
確認漏洞真的補起來，網站才算真正準備好重新上線，但上線不代表就可以完全放著不管，接下來的四十八小時同樣要盯緊幾個訊號。首先是有沒有再次出現異常登入或可疑的流量波動，這可能代表漏洞沒有真正補起來；接著是流量是否回到入侵前的正常水準，如果遲遲沒有恢復，可能還有客戶因為不安而觀望；最後是 Google 是否已經解除先前顯示的安全性警示。
如果網站曾經被標示為不安全，重新上線之後還要主動在 Search Console 提出安全性審查申請，系統確認網站清理乾淨後才會解除警示。這段審查不會馬上出結果，抓一到兩週的心理準備會比較實際，才不會誤以為畫面重新整理一下，警示就會馬上消失。
這次事件之後，老闆該建立的長期準備
熬過這段觀察期，確認網站真的恢復正常之後，這次事件才算真正告一段落。但比起鬆一口氣，更值得做的是留下三件事，當作長期準備，能實際降低下一次的損失。
第一，備份要定期實際測試還原，而不是只確認有備份檔案就安心，沒有驗證過能不能還原的備份，等於沒有備份。第二，把這次走過的聯絡順序寫下來，平常就讓團隊知道遇到狀況第一通打給誰、第二通換誰、什麼時候該對外統一發言，而不是每次事到臨頭才臨時決定。
第三，反應速度本身就是降低損失最關鍵的因素。IBM《Cost of a Data Breach Report 2025》這份研究指出，能在事件發生後較短時間內辨識並控制住問題的企業，承受的損失明顯低於拖得比較久的企業。換句話說，這篇一路講下來的判斷順序，價值不在於教你把每個細節都做到完美，而在於讓你下一次不必臨場從零想起，能立刻知道第一步該往哪裡走。
回到一開始那兩家公司。網站被駭怎麼辦的答案，從來不是看誰的資安預算比較高，而是被駭當下的頭一個小時裡，有沒有一份先做什麼、先打給誰、什麼絕對不能碰的順序表。與其等到真的出事才慌亂決定，不如現在就把這份順序想過一遍，寫下來，放在平常就找得到的地方。