AWS 有認證,購物車平台有認證,但品牌營運自己匯出的會員 Excel 呢?外包系統能節省維運成本,卻不會讓自己操作資料的責任一起消失。

企業租用了雲端或 SaaS(軟體即服務),確實可以把一部分基礎設施維運工作交給供應商。但工作可以委外,自己的風險評估與可控制的管理流程不會自動消失。

雲端與品牌的責任通常怎麼分?

以第三方購物車為例,下表只是可能分工,仍須依供應商架構、合約與實際功能確認。

工作項目常由平台處理常由品牌控制
主機、資料庫底層更新是應確認合約與證據
會員後台帳號開通平台提供機制品牌決定誰能操作
行銷人員資料匯出平台實作功能品牌決定用途、授權與保存
資料給 CRM/物流平台可能有串接品牌通常決定合作對象和資料範圍
事故發現與通知依服務架構和契約仍需自有應變與對外處理窗口

常見盲點:平台管伺服器,品牌管的是資料行為

假設某品牌使用已取得資安認證的購物車,但會員名單每週由門市主管手動匯出,再寄到外部行銷代理商。平台是否有通過 ISO,不能直接證明這份名單的使用目的、保存位置與停用流程合理。

另一個反例:即使某平台發生資安事件,也不能沒調查就推論品牌端有過失。事故來源、雙方義務及損害責任應按實際事實和適用法規判定。

查核時先問五個問題

  1. 使用的服務與資料中心是否在供應商驗證範圍內?
  2. 品牌自己有哪些最高權限帳號?多久複查一次?
  3. 平台提供什麼操作日誌、能保留多久?
  4. 會員資料還流向哪些平台外的工具與廠商?
  5. 合作終止後如何撤銷權限、返還或刪除資料?

這五題比只問「你們有沒有 ISO 證書」更能辨識實際風險。

是否一定要讓品牌自己取得 ISO 27001?

不一定。若合約、招標或供應鏈明確要求品牌本身出具有效的正式認證,應依要求規劃。沒有外部取證要求的品牌,則可以先以資料流、權限、委外證據查核建立基線,不一定需要立即投入完整管理系統驗證。

延伸:ISO 需求分流評估;電商品牌個資風險診斷。資料來源:ISO 27001、個人資料保護法。

責任分工要在「可驗證」這一欄落地

把供應商文件當成起點,另外做一張雙方責任矩陣:作業名稱、平台負責人、品牌負責人、可取得的證據、查核頻率、事故聯絡窗口。例如「登入記錄」可能由平台保管,但品牌仍應知道能否匯出、保存多久、可由誰提出查詢;「離職停權」則可能由品牌發起、平台系統執行。

更容易忽略的是跨系統傳遞。在購物車匯出報表後,用人員電腦轉傳給外部代理商,這一段風險與紀錄通常不會出現在購物車供應商的資安驗證文件中。查核時應追蹤資料從平台到品牌人員,再到第三方工具的全鏈,而不是只看雲端主機。

直接拿來開會的責任對照表

需要處理的項目雲端平台可能負責品牌通常仍需核對
基礎設施備份與維運依服務條款提供備份、可用性承諾備份範圍能否滿足自己的復原目標
平台管理者權限平台內部特權帳號控管品牌人員對商店後台的帳號分配
資料匯出與外部分享可提供不同程度的操作記錄或權限功能哪些員工可匯出、匯到何處、如何驗證
資安事故應變平台維運、通報及調查機制品牌如何接收通知與確認自己的會員影響
合約終止依契約安排平台端返還、刪除品牌外部 CRM、試算表及其他副本是否同步處理

這張表的「可能/通常」不是法律上統一分配的責任表。真正要依契約、資料實際控制權及各方角色查證。若涉及台灣受委託處理個資,也應同時檢視 《個資法施行細則》第 8 條。

同主題延伸閱讀:ISO 27001 供應商風險管理怎麼做?SaaS、CRM、物流委外查核清單、ISO 27001 證照怎麼取得?個人稽核員證書與企業認證差在哪。