SoA 範本改個公司名字，看似半天搞定。稽核時卻答不出為什麼某些控制被排除，或已勾選的措施怎麼執行。真正昂貴的是臨時補證據。
準備 ISO 27001 時常聽到 SoA（Statement of Applicability，適用性聲明）。它不是一張「93 個控制項全部打勾」的表格，而是讓組織能解釋：哪些控制措施適用、為什麼適用、是否已實施，以及不納入的理由。
SoA 的價值，在於把組織的風險評鑑與控制設計串起來。只拿別人的 SoA 範本改公司名稱，往往會出現「表格說有做、現場卻沒證據」的落差。
SoA 跟控制清單有何不同？
| 文件 | 回答的問題 | 常見錯誤 |
|---|---|---|
| 風險評鑑 | 哪些資產／流程面臨什麼風險？ | 只有風險分數，缺乏情境與理由 |
| 風險處置計畫 | 決定如何降低、避免、移轉或接受風險？ | 沒有人、期限、資源 |
| SoA 適用性聲明 | 哪些控制措施納入管理？為何？執行到哪？ | 每項一律勾「適用」卻無證據 |
| 稽核證據 | 控制真的有運作嗎？ | 只有政策文件，沒有執行紀錄 |
適用性聲明建議保留六個欄位
- 控制措施識別與名稱。
- 適用或排除判定。
- 納入／排除理由。
- 實施狀態（已完成、部分完成、未完成）。
- 連結的風險與處置計畫。
- 主要執行證據及責任人。
電商公司的簡化示例
| 控制議題 | 是否適用 | 為何 | 實作與證據 |
|---|---|---|---|
| 使用者存取與授權 | 是 | 員工可進入會員資料系統 | 權限清冊、複查紀錄、離職停權工單 |
| 供應商資訊安全 | 是 | 訂單與會員資料委外代管 | 合約、供應商審查、事件通知條款 |
| 資訊安全事件處理 | 是 | 異常存取可能影響消費者 | 通報流程、演練及處理紀錄 |
| 實體機房維護控制 | 待範圍判定 | 品牌不一定自有機房 | 需檢視實際資訊資產與委外邊界 |
上表是控制議題示意，不是官方 Annex A 逐項名稱或適用性判定。正式 SoA 需要依合法取得的現行標準、組織 ISMS 範圍和風險評鑑逐項決定。
排除控制項會讓稽核失敗嗎？
不是「排除就違規」，也不是「理由隨便寫就可以」。關鍵在於風險和實際業務範圍能否支持排除，是否仍有其他必要控制必須採行，以及稽核員能不能依文件與現場事實理解判定。
特別要注意：系統外包不等於風險被外包。 若第三方購物車承接了主機維運，品牌還要評估供應商審查、員工權限、資料匯出、終止服務時資料刪除等控制。不能把整個資訊安全責任一行「SaaS 已處理」就打發掉。
什麼時候應更新 SoA？
當新增客戶資料系統、委外平台、重要業務流程、關鍵風險處置，或發現稽核不符合事項時，應評估是否需要更新。SoA 不是第一次拿證書時填完就永遠不變的文件。
延伸閱讀：同主題的「ISO 27001 風險評鑑與風險清冊」文章；正式內部連結由網站維護對話依最終網址加入。
資料來源： ISO/IEC 27001:2022、ISO/IEC 27002:2022。
SoA 實際怎麼填？一筆可回查的教學示例
| 欄位 | 虛構範例 |
|---|---|
| 控制主題 | 存取權審查（應依正式版本確認對應控制編號） |
| 是否適用 | 適用 |
| 選擇理由 | 員工與委外人員可接觸客戶訂單及會員資料 |
| 現有措施 | 角色分權、離職停權、定期覆核 |
| 執行狀態 | 部分落實，批次覆核紀錄不足 |
| 支持證據 | 權限清冊、離職清單、抽樣查核紀錄 |
| 待改善事項 | 指定覆核負責人與例行紀錄方式 |
| 例外與風險處理 | 若未落實，須回到風險清冊由權責者決策 |
不要為了通過驗證，就把不方便做的控制標示成「不適用」。 不適用的理由應能與組織風險處理及驗證範圍一致，並且留下可解釋的判斷依據。詳見 ISO 27001 官方標準說明。
同主題延伸閱讀：iso 27001 risk assessment、iso 27001 required documents。