先畫出真實資料流，不要只閱讀功能清單
審查 SaaS 的第一步不是索取資安認證，而是確認企業究竟會把什麼資料交出去。除了使用者主動輸入的文字、檔案與表單，還要納入帳號資料、裝置資訊、IP 位址、操作紀錄、錯誤追蹤、客服附件，以及系統從內容產生的摘要、向量、索引或模型輸出。許多風險並不在主要功能，而是藏在除錯、分析、備份及支援流程裡。
工程團隊通常會把資料流拆成收集、傳輸、處理、儲存、備份、支援存取與刪除等階段，逐一標示資料類型、系統元件、地理區域、加密方式、保存期間及可存取角色。若產品含有 AI 功能，還要釐清輸入與輸出是否會被保留、是否用於訓練或人工品質檢查、向量資料存放在哪裡，以及停用 AI 功能後資料是否仍會流向模型供應商。
- 來源：資料來自員工輸入、客戶系統、瀏覽器外掛，還是 ERP、CRM、LINE 或檔案儲存服務的連接器？
- 目的地：資料會進入哪些區域、雲端帳號、備份系統、觀測平台與客服工具？
- 衍生資料：索引、快取、稽核紀錄、提示詞紀錄與分析事件能否識別個人或還原商業內容？
- 生命週期：停用帳號、終止合約或提出刪除要求後，正式資料、備份及日誌各自多久才會消失？
次處理商清單要能對應到用途與資料
供應商公布一長串公司名稱，不代表資訊已足夠。有效的次處理商清單至少應說明每一家服務商的處理目的、可能接觸的資料類型、處理地區，以及它是所有客戶必經的核心服務，還是只有啟用特定功能才會使用。雲端託管、內容傳遞、郵件發送、客服、錯誤監控、產品分析與生成式 AI 都可能形成不同風險，不能只用「基礎設施服務」一語帶過。
接著要檢查責任鏈是否完整。主供應商應透過合約要求次處理商提供相當的保密、安全、刪除及事件通報義務，並對其處理活動負責。若資料跨境，企業也要確認適用的傳輸機制、政府調取資料的處理原則，以及實際儲存地與遠端支援人員所在地。所謂「資料留在台灣」或「資料位於某區域」必須進一步確認是否涵蓋備份、日誌、客服工單與災難復原環境。
- 清單更新：新增或更換次處理商時，是否會提前通知並保留合理的異議或終止途徑？
- 選用範圍：可否關閉非必要的分析、AI、客服錄影或第三方整合，並避免資料繼續傳送？
- 證據品質：供應商能否提供資料處理附約、架構說明、稽核報告摘要與刪除流程，而不只是一份行銷式安全頁面？
依資料敏感度設定通過、限制與拒絕條件
不是每個 SaaS 都需要相同深度的審查。只處理公開內容的工具，可以接受較簡化的控制；涉及員工身分、客戶往來、原始碼、合約、財務資料或營運機密時，則需要更嚴格的身分管理、日誌、保存與跨境要求。工程與法務應先定義不可上傳的資料，再判斷遮罩、去識別化、權限分區或縮短保存期，是否能把風險降到可接受範圍。
實務上，我們會把結論分成通過、附條件通過與不通過。附條件通過必須寫成可執行的限制，例如只允許企業帳號、禁止公開分享、停用供應商訓練、不得連接正式客戶資料，或完成單一登入與稽核日誌串接後才能上線。若供應商無法說明核心資料流、拒絕承諾刪除、保留過度寬泛的內容使用權，或可隨時新增高風險次處理商而沒有通知機制，就不應以「業界常見」作為接受理由。
合約也要對應真正的技術風險。資料處理附約應涵蓋用途限制、保密、事件通知、資料主體請求、合約終止後的匯出與刪除，以及次處理商管理。資安認證與滲透測試報告可以提供信心，但不能取代產品設定與實際架構的確認；認證範圍若不包含正在採購的服務、區域或 AI 元件，參考價值就很有限。
把文件審查轉成上線前可驗證的控制
審查完成後，先以合成或低敏感資料試行，觀察網路連線、瀏覽器請求、管理後台與匯出內容是否符合文件描述。上線基線通常包含單一登入、多因素驗證、最小權限、管理員分離、分享限制、合理的保存期限、可匯出的稽核日誌，以及對高風險連接器採用獨立服務帳號。API 權杖應限制範圍並可輪替，Webhook 需要驗證來源，整合帳號也不應擁有整個 ERP 或 CRM 的讀寫權限。
最後要做一次退出演練：確認資料能以可用格式匯出、整合憑證能撤銷、帳號能批次停用，也要取得刪除完成的證明方式。供應商、次處理商或產品功能日後都可能改變，因此審查不該在簽約時結束；續約、重大功能啟用、資料類型增加與次處理商異動，都應觸發重新評估。若企業同時串接多個內部系統，可由整合團隊共同維護資料流圖與控制清單，讓採購判斷持續對得上實際架構。