內部稽核不是把全部文件打勾，也不是專門找某個部門的錯。真正要回答的是：管理系統是否符合預定要求，而且在日常營運中有沒有持續運作。
開始之前，先定義查核範圍
一家電商品牌可能同時使用購物車、CRM、客服系統、電子報與物流 API。稽核範圍如果只寫「資訊部門」，很容易漏掉真正操作會員資料的行銷、客服與門市。
一份基本的內稽計畫應包含：稽核目標、依據的政策或標準、系統與作業範圍、稽核員獨立性、樣本選擇方式、執行時間，以及報告與複查負責人。
先抽樣，再判定
| 查核問題 | 可取得的抽樣 | 可能判讀 |
|---|---|---|
| 離職人員是否停權？ | 最近一季離職名單與各系統帳號停用日 | 有延遲、時間記錄缺漏或正常 |
| 誰可以匯出會員名單？ | 角色清單、審核工單、匯出日誌 | 權限過大、查核受限或符合程序 |
| 委外資料如何處理？ | 合約、資料交付紀錄、刪除證明 | 有管理措施、契約缺口或證據不足 |
| 重大異常是否回報？ | 事件單、通報時序、演練記錄 | 程序有落實或需改善 |
四種狀態，不要全部寫成「不符合」
- 符合且有支持證據： 抽樣與已定義標準一致。
- 已確認不符合： 有具體證據顯示未符合適用要求。
- 證據不足： 現有資料不足以形成結論，需要補查。
- 查核受限： 例如平台不提供特定日誌，需記錄限制與替代證據評估。
查核受限不能自動算成符合，也不能不經調查直接推定違規。
一份能用的稽核發現怎麼寫？
過度籠統：「離職帳號管理不佳，建議改善。」
可追蹤：「依公司停權程序，離職日應完成停用。抽查 15 件離職紀錄，發現 2 件 CRM 帳號於離職後第三日才停用；缺少延遲核准及例外處理紀錄。請由責任單位於指定期限提出根因、補救措施及再抽樣結果。」
數字只是教學樣本，不指涉真實客戶。這個寫法重點是要求、樣本、事實、風險、改善與複驗條件六個部分都清楚。
內部稽核與第三方驗證稽核有何不同？
內部稽核屬組織治理機制，目的在持續發現問題並改善；正式 ISO 驗證則由適格第三方驗證機構依相應規範執行。兩者不能互相冒充。
可以讓 AI 協助建立抽樣表、整理證據與發現草案，但不要讓 AI 捏造日期、案件或歷史簽核。沒有實際做過的稽核，不應寫成已完成。
抽樣要能說明為什麼選這些案件
抽樣可以結合高風險和隨機案件，例如最近一季的離職人員、具會員匯出權限者、近期新增的委外串接，以及上次查核曾發現問題的控制措施。報告應寫清楚樣本母體、期間、選取理由與可取得證據；抽到 10 件都正常，不等於保證全年所有案件都正常。
發現缺口後，改善報告要拆成三階段：立即處置（先控制風險）、根因修正（改流程或系統）、效果驗證（再次抽樣並核對證據）。例如帳號停權延遲，不能只補做停權就結案，還要查為何人事資料沒有同步到所有 SaaS 工具，以及下次怎麼發現同類異常。
來源：ISO/IEC 27001:2022；本篇為實務方法與示例，不代表正式驗證意見。
同主題延伸閱讀：iso 27001 management review、iso 27001 risk assessment。