ISO 27001 認證要多久？沒有通用的固定天數。企業必須完成範圍界定、差距分析、制度運作、內部稽核、管理審查和第三方 Stage 1／Stage 2 驗證；時程取決於範圍、既有制度、改善量與驗證機構檔期。
對正在談合約的公司而言，問題通常不是「大家平均花幾個月」，而是：客戶要我在某一天交出證書，現在還來不來得及？
真實事故：10 月 14 日發現問題，19 日主管機關已到場
2026 年 10 月，91APP 公告 Commerce Cloud 資料庫遭自動化攻擊，部分資料被非法擷取。公開資訊顯示，10 月 14 日為重大訊息所列的事件日期，10 月 16 日公司公告，10 月 19 日數發部數產署已會同專家赴業者所在地行政檢查，20 日發布說明。
這是事故調查時程，不是 ISO 驗證時程。但它提醒管理層：出了事，外部要求來得很快；要整理完整的系統、權限與執行證據，卻不可能靠最後三天補寫文件。
截至 2026 年 10 月 20 日的官方公開說明，實際受影響個資類型、人數及筆數仍待查明，不能把未確認的數字當作定論。
來源：91APP 2026/10/16 官方聲明；數位產業署 2026/10/20 行政檢查說明。
ISO 27001 取證要經過哪些階段？
| 階段 | 企業要完成的事 | 最常拖延的問題 |
|---|---|---|
| 確認證書要求 | 對齊客戶指定標準、Scope、法人及期限 | 需求反覆改動 |
| 現況與缺口分析 | 盤點資產、作業、風險及證據 | 系統和負責人找不齊 |
| 建置與運作 | 政策、風險處理、SoA、日常控制 | 文件做完，但證據還沒開始產生 |
| 內稽與管理審查 | 驗證制度運作、矯正不符合 | 稽核人員、部門無法配合 |
| Stage 1 | 第三方確認管理系統準備情形 | 關鍵準備不足 |
| Stage 2 | 正式抽樣訪談與執行查核 | 缺失改善需延後確認 |
| 驗證決定與發證 | 由驗證機構依方案處理 | 機構排程與審核決策時間 |
表格是工作先後關係，不是承諾每個階段一定幾天。
用「交證書日期」倒推，而不是從今天亂估
假設客戶契約寫明 12 月 31 日前須提供 ISO 27001 證書。這是一個示例日期，實際應以你的合約為準。
你至少要倒推五個時點：
- 驗證機構完成證書決定、核發所需的處理時間。
- Stage 2 稽核與可能的不符合事項改善緩衝。
- Stage 1 和 Stage 2 可預訂的稽核檔期。
- 內部稽核與管理審查的完成日期。
- 風險評鑑、控制措施實際運作及證據累積所需期間。
最容易低估的是最後一項。管理制度必須真的被執行，不能把今天新寫的表單假裝成前三個月的稽核紀錄。
哪些情況會讓取證進度突然失控？
第一，驗證範圍與客戶要求不一致。只驗辦公室行政，客戶卻要 SaaS 維運，可能必須重新調整專案。
第二，IT 認為早就有做，稽核時卻拿不出紀錄。例如每月權限複核只是口頭說明，沒有時間、審查者及異常處理的紀錄。
第三，將第三方驗證當成顧問結案會議。顧問能協助準備，但獨立驗證機構仍有自己的人天、稽核與決策流程。
第四，預估成本時漏掉改善工程。缺少存取控制、供應商管理或備份還原測試，可能需要跨部門工作，而不是補一張文件就好。
如果客戶期限快到了，先做哪三件事？
先把客戶要求與服務範圍確認成文字；再指定有權協調 IT、營運、人資及採購的專案負責人；同時向顧問與驗證機構確認工作和檔期，避免一方準備好了、另一方根本排不到。
如果客戶願意在正式發證前接受階段性進度或其他佐證，應由客戶明確確認接受條件。專案進度報告不能冒充有效認證證書。
你真正需要的，是一份能執行的取證日程
把客戶要求的證書範圍、最後日期、既有 ISO 制度及主要系統提供給我們，就能針對當前條件評估時程、缺口和第三方驗證安排。
讓我們協助評估 ISO 27001 取證期限與導入計畫。如果已經決定要取證，就直接談如何完成，不需要先購買獨立健診。