前言：拜 Vibe coding 之賜，市場上出現了一大堆的SaaS，每個都聲稱自己所開發的符合你的需求，當然也有些會打著—別人也 Vibe coding 過，但最後還是回來用我們的—這種聲稱，但是你真的確定你的資料放在別人那裡是安全的嗎？尤其是資料中包含個資 (特種個資更是重要) 時，當對方的 SaaS 發生資安事件導致資料外洩時，要怎麼處理及維護自己的權益？這些會遠比那些聲稱自己 Vibe coding 出來的 SaaS 有多好用要來得重要太多了—不怕一萬，只怕萬一。
一句話讓多數供應商露餡
「請說明在共同責任模型下，哪些控制是你的責任、你如何實施、以及你如何證明。」
這句話足以讓許多SaaS的供應商語塞。
我認為這句話的殺傷力在於：它不需要對方是大公司才答得出來，只需要對方真的想過這件事。
一個認真的兩人團隊會給你一張責任分界表，一個做表面工夫的供應商會開始講他們用某某雲端平台 (以下以AWS舉例)、資料有加密、非常重視資安；前者你可以繼續談，後者可以收線了。
而這句話之所以有效，是因為它同時戳破了目前市場上最流行的兩種合規外觀。
外觀一：「我們架在 AWS 上，所以我們合規」
這是我近年聽到最多、也最沒有根據的一句話。
AWS 官方的措辭其實寫得非常清楚：security of the cloud vs. security in the cloud。GCP 跟 Azure 的共同責任模型講的是同一件事。他們的 ISO 27001、SOC 2 涵蓋的是機房、虛擬化層、網路骨幹、員工背景審查——你租的是安全的房子，不是安全的生活習慣。
而且這件事有一個關鍵細節，多數人沒讀到：
每一份 SOC 2 報告都有一節叫 CUEC（Complementary User Entity Controls，互補之使用者實體控制）。
那一節逐條列出「以下控制必須由使用者自行實施，本報告不對其提供任何保證」。裡面有什麼？
- IAM 權限設計與最小權限
- 加密金鑰管理與輪替
- 應用層存取控制與多租戶隔離
- 日誌保存、監控與告警
- 備份與還原測試
- 網路分段與 WAF 規則
- 到職／離職權限管理
看出來了嗎？幾乎所有真正會出事的地方，都在這張清單上。
CUEC 這一節存在的唯一目的，就是預先擋掉「我跑在 AWS 上所以我合規」這種主張。所以當有人這樣講的時候，可以合理推論：他沒讀過那份報告，他只看過官網那個 logo。
想要證據的話，Capital One 2019 年那場外洩就是標準教材：AWS 端完全合規、零缺失，出事的是客戶自己的 WAF 設定錯誤加上過寬的 IAM 角色。基礎設施的合規對那次事件的幫助是零。
但也別把話講死：繼承本身是合法的
我要特別澄清一點，免得這篇變成無差別攻擊。
控制項繼承（control inheritance）在正規框架裡是有明文機制的，FedRAMP 就允許架在已授權 IaaS 上的服務繼承一部分控制項。差別在哪？在於它要求你逐項聲明繼承了哪些、剩下哪些是你的、你怎麼做的。
所以真正的判準不是「有沒有借用平台合規」，而是——
有沒有承認自己借了哪一半，並且把另一半補上。
一個做得對的團隊會給你三樣東西：責任分界矩陣、CUEC 逐條對應表、把 AWS 當供應鏈管理的程序文件。一個做擦邊球的團隊給你一面 logo 牆。
簡言之，雲端環境是一種風險分擔的平台，雲端供應商有自己的合規性要滿足，但在其服務類型 (IaaS/PaaS/SaaS) 之上，使用平台的人要自行負擔一部份風險，不能全部推給雲端供應商。
外觀二：ISO 27001 的範圍擦邊球
第二種更隱蔽，因為它真的有一張證書。
先講結論：不要問「你有沒有 ISO 27001」，要說「請提供證書正本與範圍聲明（scope statement），以及 SoA 的排除項目與理由」。
範圍聲明就印在證書上。看一眼就知道有沒有涵蓋你要買的那個服務。這是整個評估流程裡投報率最高的一個動作，成本是三十秒。
實務上看得到的擦邊球型態，至少有這幾種：
- 範圍寫得很小。 證書上的 scope 只寫「總部資訊部門之 IT 維運」或「機房設施管理」，完全不含產品開發與 SaaS 營運。但行銷素材上只寫「本公司通過 ISO 27001 驗證」。技術上沒說謊，實質上沒意義。
- 範圍在錯的法人身上。 集團母公司或某家子公司通過，實際跟你簽約、提供服務的是另一家。
- 驗證機構本身沒有認證資格。 這種最嚴重也最難察覺。ISO 27001 證書要看發證機構是否在 IAF MLA 架構下取得認證——台灣是 TAF，國際上如 UKAS、ANAB、JAB。市面上有不少「未經認證的驗證機構」發的證書，形式上長得一模一樣，但稽核上等同於沒有。
- 措辭偷換。 「符合 ISO 27001 標準」、「依 ISO 27001 建置」、「參照 ISO 27001 框架」——這些全都是自我宣稱，沒有第三方查證。真的通過驗證的人會寫「通過驗證」，因為那是他花錢花時間換來的，沒理由講得比較模糊。
- SoA 大量排除。 適用性聲明書把關鍵控制項標成「不適用」，理由寫得像敷衍（例如「本公司規模較小」）。範圍看起來完整，實際被挖空。
為什麼這比「沒有證書」更值得警覺
拿範圍外的證書當證明，透露的是這家公司對合規的心智模型：合規是「拿去給客戶看的東西」，而不是「拿來管住自己的東西」；反過來，一個誠實說「我們還沒有 ISO 27001，但我們做了這幾件事，這是我們的責任分界」的團隊，我會給更高的信任分數。因為前者已經證明了他願意在合規這件事上取巧，後者至少證明了他想過。
證書可以買，心智模型不行。
先分級，再決定要查多深
講到這裡可能會給人一種印象：所有小廠商都不能用。我不是這個意思，而且一刀切的政策在實務上會被繞過，因為沒人有那個時間。
比較務實的做法是依資料敏感度分級：
| 等級 | 內容 | 怎麼查 |
|---|---|---|
| D0 公開／可重建 | 格式轉換、公開資料查詢 | 關鍵條件檢查 (條件清單) 即可 |
| D1 內部營運 | 內部文件、專案管理 | 加問退場機制 |
| D2 個人資料 | 員工、客戶名單、交易紀錄 | 完整查核 |
| D3 特種個資／金流 | 病歷、醫療、基因、支付、未成年人 | 原則上不採用未驗證供應商 |
然後配上一個判定準則，這句話比任何評分表都好用：
如果這家供應商出事，我的公司要不要對主管機關或客戶負責？
依個資法架構，受託人在委託範圍內視同委託機關——委外不免責。這句話通常一問出來，決策就清楚了。
技術面：問對三個問題就夠了
如果你不是資安背景，不用背 OWASP TOP 10。這三題涵蓋了近年 AI 輔助開發環境中最常炸掉的地方：
第一題：「如果我的使用者手動改掉網址列裡的 ID，會發生什麼事？」
這在問多租戶隔離與 IDOR / BOLA。期望的答案是對方能明確講出授權檢查發生在哪一層，最好是資料庫層（RLS）加應用層雙重防護，而且有自動化測試在跑。
這題為什麼重要？因為破口高度集中在這裡。跨 5,600 個 AI 生成應用的掃描研究發現超過 2,000 個漏洞、400 多組外洩憑證、175 起 PII 曝光；Bolt.new 預設關閉 RLS；Moltbook 上線三天內被攻破，外洩 150 萬組 API token。同一類漏洞，一再重演。
第二題：「你們前端有沒有任何具寫入權限的金鑰？anon key 跟 service key 怎麼區分使用？」
答不出來的，基本上就是把 service key 塞在前端了。
名詞解釋：
anon key 指給前端使用的 key，基本上它會受控於 service，且基本上是透明的，因此外洩也不會影響平台 (anon 為 anonymous 的縮寫，亦即匿名)。
service key 則是後端服務存取使用的 key，它只能在後端服務使用，不可外洩，否則會有資安風險。
第三題：「你的存取日誌保存多久？包含哪些欄位？」
這題看起來平淡，但沒有稽核軌跡就無法履行個資法的通報義務——出事時你連「洩漏了哪些人的哪些資料」都答不出來，而通知當事人是法定義務。
還有一個 AI 時代的特殊風險值得補一句：用 prompt 重新生成一個元件，可能靜默改掉授權邏輯。 所以安全測試必須跑在每次 PR 與部署上，只在上線前測一次是擋不住的。
台灣的法規時鐘正在往前走
順帶提醒，這件事的緊迫性最近提高了。
個資法 2025 年 11 月修正公布，配合個人資料保護委員會（PDPC/個資會）成立。對企業影響最大的三點：
- 通報義務普及化——從各產業安維辦法提升到法律位階，不再只有金融、電信要遵守，而是所有非公務機關的普遍義務。
- 通知門檻降低——刪除「違反本法規定」及「查明後」兩個前提，只要知悉個資遭洩漏就應通知當事人。拖延戰術失效了。
- 裁罰可直接開罰——未依規定通報、未訂定安維計畫，個資會得毋庸先令限期改正即逕行處罰。
同時，安維辦法草案要求的東西本質上都是組織措施：定期清查個資、人員安全管理、教育訓練、應變機制、業務終止後的刪除銷毀。這裡面沒有一項是 AWS 能替你做的。
你不可能拿 GCP 的證書去證明「我有對員工做個資教育訓練」。
不可越雷池的條件清單：看到就該停下來
下列情況，出現任一項就應提高警覺：
合規面
- 以「我們架在 AWS 上」主張自身合規
- 展示雲端供應商的合規標章當作自己的
- 拒絕提供證書正本或範圍聲明
- 證書範圍與採購的服務明顯不符
- 用「符合／依照 ISO 27001」等未驗證措辭
- 發證機構無 IAF MLA 認證
- 答不出責任分界
技術面
- 說不清多租戶隔離機制
- 分不清 anon key 與 service key
- 前端有具寫入權限的金鑰
- 從沒做過還原測試
- 沒有存取日誌，或保存期太短
組織面
- bus factor = 1 且無代理安排
- 服務主體與簽約主體不一致
- 合約沒有退場與資料返還條款
- 對安全提問表現出防衛或迴避
- 過往事故的公開回應是卸責、否認或指責第三方
最後那一項我想特別講。事故人人會遇到，但事故發生時的反應，比事故本身更能說明一家公司的體質。 看到「我們沒有資料外洩，那是預期行為」、「是我們的文件寫得不夠清楚」、「是漏洞獎金合作夥伴誤判」這種連環甩鍋的，就知道下次出事會怎麼處理了。
五個快篩問題
時間不夠的時候，這五題可以篩掉多數不合格的供應商：
- 在共同責任模型下，哪些控制是你的責任？舉三個例子並說明你怎麼做的。
- 請提供 ISO 27001 證書，我想確認範圍聲明是否涵蓋這項服務。
- 我的使用者手動改掉網址裡的 ID 會怎樣？你怎麼驗證的？
- 你知悉資料外洩後多久內通知我？流程是什麼？誰負責？
- 如果你明天不做了，我的資料怎麼拿回來、什麼時候銷毀？
這五題的共同特性是：答得出來不需要公司規模，只需要真的想過。
而這正是我認為評估的核心——你篩的不是資源多寡，是心智模型。
本文為評估參考架構，不構成法律意見。個資法子法內容仍在發展中，涉及重大採購或特種個資時，建議諮詢專業法律意見。