電商品牌導入 ISO 27001／27701 認證，最重要的不是購物車用哪一家，而是認證範圍內誰能接觸會員資料、資料流向哪裡、平台與品牌各自控制哪些作業，還有哪些證據拿得出來。
因為你租的是系統，不是把所有個資處理責任一併寄放到別人公司。
真實事故：平台發生攻擊，收到詐騙訊息的卻是品牌會員
2026 年 10 月 16 日，91APP 公告 Commerce Cloud 資料庫遭自動化攻擊，部分資訊被未經授權擷取，已報案並委託第三方調查。同一天，電商品牌大侑在官方網站發布提醒，表示已有會員收到冒用品牌名義的詐騙信件和訊息。
數位產業署於 10 月 20 日對外說明，已經行政檢查並要求 91APP 說明資料受影響範圍、權限、安全措施和偵測情形。截至該次官方公告，實際受影響人數及資料筆數仍待確認；品牌會員收到詐騙信，也不能直接推定每封信的資料來源及最終法律責任。
但站在品牌老闆的位置，有一件事不必等所有調查結果：客服電話已經響了。
參考：91APP 官方事件公告、大侑官方防詐聲明（2026/10/16）、數位產業署 2026/10/20 說明。
電商品牌需要管哪些資料流向？
| 資料流 | 品牌值得先問的事 | 能提出哪些證據 |
|---|---|---|
| 購物車與訂單 | 管理員有哪些權限？誰能匯出會員？ | 後台角色清單、權限調整紀錄 |
| CRM／會員分群 | 資料是否自動同步？是否含不必要欄位？ | 同步設定、欄位對照、存取紀錄 |
| 金流、物流、電子發票 | 每個供應商實際收哪些欄位？ | 契約、資料傳輸規格、處理範圍 |
| EDM／簡訊／客服 | 名單怎麼匯出、多久保留？ | 核准程序、委外管理、刪除或停止使用紀錄 |
| GA4／GTM 等追蹤 | 事件參數是否不當包含個資？ | 事件規格、容器變更紀錄、設定抽查 |
| 離職與外包權限 | 資料副本及 API Key 還在誰手上？ | 撤權紀錄、憑證管理、外包終止清單 |
這不是說每一項都必須放進證書範圍，而是確認它們是否影響驗證服務與個資處理活動。
ISO 27001 和 ISO 27701 在電商到底各管什麼？
**ISO 27001（ISMS）**重點是資訊安全風險管理，例如權限、弱點、備份、委外安全、事故通報與持續改善。
**ISO 27701（PIMS）**則進一步聚焦個資處理目的、隱私風險、控制者與處理者的責任、資料主體權利、委外個資使用與刪除等問題。2025 年新版可獨立導入，也能與 ISO 27001 整合。
例如客服可以合法查訂單，不代表他需要不受限制地下載全部會員名單；平台替你處理訂單，也不代表所有 CRM、廣告及客服資料副本都由平台管理。
延伸閱讀：ISO 27001 和 ISO 27701 差異。
如果今天真的接到會員詐騙客訴，先做什麼？
- 保留事實：客訴時間、原始訊息、訂單、收件內容及公司當時掌握的資訊。
- 別急著歸因：向供應商請求事故通知、涉及範圍、已確認與尚待查明事項。
- 確認品牌自己可控制的環節：後台權限、匯出紀錄、行銷資料副本、外包人員存取。
- 安排相應專業處理：若疑似真正的資安事故，應依情況找鑑識與法律專業，依法及依適用契約處理通知或通報。
- 保留改善軌跡：何時採取什麼措施、誰核准、如何確認有效，日後查核才能重建時間線。
不要為了對外說明而自行捏造「過去已定期查核」的紀錄。查不到就是查不到，先把查不到的原因寫清楚。
如果電商公司是為了正式取證，先做哪一步？
先拿客戶要求的證書標準、預定驗證範圍、平台與供應商清單、會員資料流向和現有制度來評估。若範圍不清，正式報價、驗證時程及實際工作量都很難準確。
我們可協助直接規劃 ISO 27001／27701 導入及驗證，或針對電商品牌端個資管理討論有明確交付範圍的獨立健診。後者不能代替全企業的 ISO 認證或事故鑑識。
參考資料
- 91APP：2026 年 10 月 Commerce Cloud 資安事件
- 大侑：會員遭冒名詐騙官方提醒
- 數產署：91APP 行政檢查說明（2026/10/20）
- ISO 官方：ISO/IEC 27001
- ISO 官方：ISO/IEC 27701:2025