品牌說自己一直有在管理會員資料。稽核人員問：「上個月匯出完整會員清單的帳號是哪個？當初誰核准？名單給了誰？」
客服說會去問資訊，資訊說平台沒有完整匯出報表，行銷則在舊資料夾找到一份檔名叫「會員最終版-新版2.xlsx」的 Excel。
檔案存在，不表示能知道誰下載、保存多久或是否還被使用。
個資稽核不能停在『有沒有 SOP』，也不能把沒有證據一律寫成違規。真正要做的是讓資料流、權限、實際操作與查核結果互相對得上。
以上為去識別化（脫敏）之典型電商稽核訪談現場還原。
個資稽核要查什麼？先分三層
| 層次 | 你要確認的問題 | 常見證據 |
|---|---|---|
| 制度設計 | 公司有沒有明確規則、責任人與適用範圍？ | 政策、SOP、權限矩陣、委外管理規範 |
| 執行事實 | 現場人員是否按規則處理資料？ | 帳號異動、核准申請、交付與刪除紀錄 |
| 證據品質 | 這些紀錄能否追溯時間、對象、動作？ | 系統日誌、簽核、可核對的報表或工單 |
文件寫「離職當日移除權限」，但人資名單與實際後台帳號對不起來，是執行缺口。平台沒有提供必要紀錄、目前無法證明是否按規則執行，則可能是證據不足或查核受限，不能任意推論為已違規。
先畫資料流，不要從寫報告開始
以使用第三方購物車的品牌為例，查核範圍不應只看購物車管理後台，至少要確認：
圖解：沒有紀錄不等於可以事後補造紀錄
- 會員與訂單資料存在哪些系統；
- 何時會匯出成 Excel、CSV 或其他檔案；
- 哪些資料流到物流、客服、CRM、廣告或簡訊供應商；
- 誰有管理權限、誰核准權限變更；
- 資料保留多久、如何刪除或停止利用。
這張資料流地圖的用途，是決定後續應該抽查哪些環節，而不是為了把報告畫得漂亮。
八項最先應該找得到的個資查核證據
開始抽樣之前，先盤點現在究竟拿得到什麼。這八項是電商品牌很實用的起點，而不是每家公司的法定固定八件套。
| 項目 | 不只看有沒有，還要驗證什麼 |
|---|---|
| 1. 後台帳號清冊 | 帳號是否仍有效？是否存在共用帳號？ |
| 2. 角色與權限設定 | 誰可以讀取、匯出完整會員資料？由誰核准？ |
| 3. 離職與調職停權紀錄 | 人資名單能否對上各系統停權時間？ |
| 4. 會員資料匯出紀錄 | 何時、由誰、因何目的匯出哪些欄位？ |
| 5. 委外廠商與次委外清單 | CRM、物流、行銷與客服各取得哪些資料？ |
| 6. 資料交付與介接紀錄 | CSV、API、共用連結如何管理及撤銷？ |
| 7. 事故處理紀錄 | 事件、客訴、平台回覆、通知與處理時間線能否重建？ |
| 8. 教育訓練與稽核紀錄 | 誰做過、查出什麼問題、後來如何改善？ |
沒有日誌時先區分「證據不足」與「查核受限」，不能事後補造不存在的操作歷史。部分適用《零售業個人資料檔案安全維護管理辦法》的業者，依該辦法第 15 條對特定使用紀錄、設備軌跡及其他相關證據有至少五年的保存要求；這不是所有電商所有資料一律保存五年的規則。法規原文。
五個步驟，讓稽核有辦法重複執行
第一步：界定範圍與依據
列出公司適用的法規、產業安全維護管理辦法、內部政策、委外合約及實際涵蓋的系統。不是每一家企業都適用同一套管理辦法，不能從別人的查核表直接複製「法定必備」標籤。
第二步：建立查核項目及抽樣計畫
例如選取：近期離職帳號、會員資料匯出申請、委外資料交付、客戶刪除資料請求與一次系統異動。樣本數應考慮風險、交易量與可取得證據；沒有放諸四海皆準的「抽幾筆就合法」答案。
第三步：取得證據並交叉核對
以「離職停權與帳號盤點」為例，不能只看 IT 提供的單一系統停權截圖。實務上應以離職生效日為基準，比對三方資料：人資 HCM/離職名冊、購物車後台／CRM／雲端主機（如 AWS/GCP IAM、G Suite/Workspace）的實際使用者清單，以及 SSO 登入日誌（SAML/OAuth），清查離職日後是否仍有成功認證或殘留有效 Session Token、API Key，並確保外部顧問與代操廠商期滿後已徹底收回 Super Admin 權限。
以「權限對帳與會員資料匯出」為例，不只看 SOP 是否要求主管核准，還應對照後台真實 Audit Log 匯出事件：確認匯出時間戳記、操作者 IP、執行帳號、匯出欄位清單（是否包含身分證字號或明碼電話等非必要資訊），並核對是否有對應之工單申請與主管核准紀錄，清查是否存在共用管理員帳號（如 admin@、marketing@）導致日誌無法歸責。
第四步：把結果分成不同狀態
| 查核結果 | 代表什麼 | 下一步 |
|---|---|---|
| 已驗證符合 | 在本次抽樣與查核範圍內，有足夠支持資料 | 保存查核紀錄並依週期複查 |
| 已確認缺口 | 有具體證據顯示規則未落實或控制不足 | 指定負責人、期限與改善措施 |
| 證據不足 | 資料尚不足以支持符合或不符合結論 | 補件或改善紀錄機制 |
| 查核受限 | 因平台權限、合約或技術限制無法驗證 | 記錄限制、評估替代證據或補強控制 |
這四種狀態不能混成「通過／不通過」兩格。對法遵及事故責任而言，「沒有證據」不等於「確定沒有執行」，但也絕不能當成「已經驗證通過」。
第五步：追蹤改善是否真的關閉
報告寫「建議加強管理」沒有驗收價值。至少應有缺口描述、證據來源、風險、負責人、改善措施、期限及複查結果。
可以直接套用的稽核紀錄表
以下為去識別化之電商實務查核拆解（已隱去品牌與系統名稱）：
圖解：沒取得證據時應記錄查核限制而非補造
| 控制項目 | 本次抽樣 | 預期證據 | 查核結果 | 後續動作 |
|---|---|---|---|---|
| 離職人員停權與帳號對帳 | 抽近期 3 名離職人員，對帳人資清冊與購物車／CRM 帳號 | 離職生效日、SSO 停權時間、後台帳號狀態、最後登入紀錄 | 1 筆離職 14 天後購物車後台帳號仍為 Active：已確認缺口 | 立即停權並清查其離職後是否有存取紀錄；建立人資與 IT 自動化對帳機制 |
| 會員資料匯出與權限清查 | 抽近期 3 次全欄位匯出 Audit Log | 工單申請單、主管核准、匯出欄位最小化、下載紀錄 | 其中 1 件由共用行銷帳號匯出且未附核准工單：已確認缺口 | 廢止共用帳號改採具名授權；匯出功能限縮欄位並強制工單簽核 |
| 委外資料交付與 Token 控管 | 抽 2 家外部行銷與簡訊供應商 | 委外監督紀錄、API Token 權限範圍、合約資料保護條款 | 其中 1 家 API Token 具備全域讀寫且超過 1 年未輪替：待改善缺口 | 縮小 Token 存取 Scope 至最小必要範圍；設定 90 天強制輪替機制 |
實際抽樣數量與判定標準，應由查核人依案件風險及範圍決定。這張表的核心不在樣本數，而在每個結論都有可回查的依據。
三個最常見的稽核錯誤
一、只檢查制度，沒有測試實際操作。 SOP 寫得再完整，只要帳號共用、資料任意匯出，風險仍然存在。
二、把平台沒有提供日誌，直接寫成品牌違法。 平台端與品牌端的資訊可得性不同；應先確認誰持有、誰能調閱，以及是否有替代管理措施。
三、為了讓報告全綠，補造過去不存在的紀錄。 補強未來程序是改善；捏造歷史證據則會破壞調查可信度。
個資稽核和 ISO 27001 驗證有什麼差別？
企業可以針對會員資料、權限與委外流程進行個資稽核，確認管理缺口；這不等同於完成 ISO/IEC 27001 資訊安全管理系統的全部要求，也不能替代第三方正式驗證。
相反地，拿到 ISO 證書也不表示每一項品牌端資料匯出、CRM 串接或客服外包操作都已經被逐件查核。
若想先知道品牌的資料流、權限與執行紀錄究竟缺在哪裡，可參考電商品牌個資風險與證據健診的查核範圍與交付項目。
參考法規：個人資料保護法已施行條文、零售業個人資料檔案安全維護管理辦法、數位經濟相關產業個資安全維護管理辦法。
法規查核日期：2026-10-22。本文為稽核方法說明，實際適用法規、抽樣範圍與稽核結論仍須依個案確認。
同主題延伸閱讀：個資安全維護計畫怎麼做？零售業適用門檻、72 小時通報與五年紀錄、個資外洩賠償多少？判賠 84,935 元，一場官司的成本怎麼算。