AWS 有認證，購物車平台有認證，但品牌營運自己匯出的會員 Excel 呢？外包系統能節省維運成本，卻不會讓自己操作資料的責任一起消失。
企業租用了雲端或 SaaS（軟體即服務），確實可以把一部分基礎設施維運工作交給供應商。但工作可以委外，自己的風險評估與可控制的管理流程不會自動消失。
雲端與品牌的責任通常怎麼分？
以第三方購物車為例，下表只是可能分工，仍須依供應商架構、合約與實際功能確認。
| 工作項目 | 常由平台處理 | 常由品牌控制 |
|---|---|---|
| 主機、資料庫底層更新 | 是 | 應確認合約與證據 |
| 會員後台帳號開通 | 平台提供機制 | 品牌決定誰能操作 |
| 行銷人員資料匯出 | 平台實作功能 | 品牌決定用途、授權與保存 |
| 資料給 CRM／物流 | 平台可能有串接 | 品牌通常決定合作對象和資料範圍 |
| 事故發現與通知 | 依服務架構和契約 | 仍需自有應變與對外處理窗口 |
常見盲點：平台管伺服器，品牌管的是資料行為
假設某品牌使用已取得資安認證的購物車，但會員名單每週由門市主管手動匯出，再寄到外部行銷代理商。平台是否有通過 ISO，不能直接證明這份名單的使用目的、保存位置與停用流程合理。
另一個反例：即使某平台發生資安事件，也不能沒調查就推論品牌端有過失。事故來源、雙方義務及損害責任應按實際事實和適用法規判定。
查核時先問五個問題
- 使用的服務與資料中心是否在供應商驗證範圍內？
- 品牌自己有哪些最高權限帳號？多久複查一次？
- 平台提供什麼操作日誌、能保留多久？
- 會員資料還流向哪些平台外的工具與廠商？
- 合作終止後如何撤銷權限、返還或刪除資料？
這五題比只問「你們有沒有 ISO 證書」更能辨識實際風險。
是否一定要讓品牌自己取得 ISO 27001？
不一定。若合約、招標或供應鏈明確要求品牌本身出具有效的正式認證，應依要求規劃。沒有外部取證要求的品牌，則可以先以資料流、權限、委外證據查核建立基線，不一定需要立即投入完整管理系統驗證。
延伸：ISO 需求分流評估；電商品牌個資風險診斷。資料來源：ISO 27001、個人資料保護法。
責任分工要在「可驗證」這一欄落地
把供應商文件當成起點，另外做一張雙方責任矩陣：作業名稱、平台負責人、品牌負責人、可取得的證據、查核頻率、事故聯絡窗口。例如「登入記錄」可能由平台保管，但品牌仍應知道能否匯出、保存多久、可由誰提出查詢；「離職停權」則可能由品牌發起、平台系統執行。
更容易忽略的是跨系統傳遞。在購物車匯出報表後，用人員電腦轉傳給外部代理商，這一段風險與紀錄通常不會出現在購物車供應商的資安驗證文件中。查核時應追蹤資料從平台到品牌人員，再到第三方工具的全鏈，而不是只看雲端主機。
直接拿來開會的責任對照表
| 需要處理的項目 | 雲端平台可能負責 | 品牌通常仍需核對 |
|---|---|---|
| 基礎設施備份與維運 | 依服務條款提供備份、可用性承諾 | 備份範圍能否滿足自己的復原目標 |
| 平台管理者權限 | 平台內部特權帳號控管 | 品牌人員對商店後台的帳號分配 |
| 資料匯出與外部分享 | 可提供不同程度的操作記錄或權限功能 | 哪些員工可匯出、匯到何處、如何驗證 |
| 資安事故應變 | 平台維運、通報及調查機制 | 品牌如何接收通知與確認自己的會員影響 |
| 合約終止 | 依契約安排平台端返還、刪除 | 品牌外部 CRM、試算表及其他副本是否同步處理 |
這張表的「可能／通常」不是法律上統一分配的責任表。真正要依契約、資料實際控制權及各方角色查證。若涉及台灣受委託處理個資，也應同時檢視 《個資法施行細則》第 8 條。
同主題延伸閱讀：iso 27001 supplier risk、iso 27001 certificate vs certification。