台灣的 SaaS 業者、IT 服務商，以及接美國、歐洲、日本訂單的製造業，越來越常在簽約前收到這類要求：「請提供你們的 SOC 2 報告」、「你們有 ISO 27001 嗎？」，或是一份好幾百題的資安問卷。客戶這樣要求並不奇怪：供應商的資安漏洞可能變成客戶的入口，這正是供應鏈攻擊的典型路徑。

麻煩的是，「資安認證」背後可能是完全不同的東西。搞錯方向，可能花了預算做出客戶用不上的報告，或在問卷上勾了做不到的「是」。這篇寫給要回應這類要求的業務、專案經理與 IT、資安負責人：SOC 2 與 ISO 27001 各是什麼、怎麼判斷客戶真正要什麼、雲端業者的報告能幫你到哪裡，以及如何建立可重複使用的問卷答案庫與證據資料夾。

SOC 2：會計師出具的查核報告，不是證書

SOC（System and Organization Controls）是由美國會計師協會（AICPA）制定專業標準、由會計師（CPA）提供的一系列確信服務，讓使用者取得評估委外風險所需的資訊[1]。SOC 2 針對服務組織（例如 SaaS、資料中心、代管服務），由會計師依 AICPA 鑑證準則（AT-C 105、AT-C 205）執行檢查，對三件事表示意見：服務組織對系統的描述是否依描述準則如實呈現、控制的設計是否適當，以及在 Type 2 中，控制是否確實有效運作[2]。所以 SOC 2 的產出是一份包含會計師意見、系統描述（Type 2 還有測試結果）的報告，不是證書；常聽到的「SOC 2 認證」嚴格說是誤稱。

SOC 2 以 AICPA 的信任服務準則（Trust Services Criteria）評估控制，分為五個類別：安全性（Security）、可用性（Availability）、處理完整性（Processing integrity）、機密性（Confidentiality）與隱私（Privacy）[2]。查核範圍可以只選其中一個或幾個類別，但不論怎麼選，都必須涵蓋五類共用的「共同準則」（common criteria），而安全性適用的準則就是共同準則[2]，這就是業界常說「安全性一定要做」的原因。其他類別要不要納入，最好對應你在合約裡的承諾，例如保證服務可用率，就考慮納入可用性。AICPA 已公開 2027 年版信任服務準則與描述準則的修正草案（exposure draft）[3]；草案不是現行規定，正式版本與適用時間以 AICPA 公告為準。

Type 1 與 Type 2

  • Type 1：評估「某一時間點」的系統描述與控制設計是否適當[2]。
  • Type 2：另外評估控制在「一段期間內」是否有效運作，報告中並詳列會計師的控制測試與結果[2]。

期間長度由服務組織管理階層決定[2]。第一次做的公司可以先做 Type 1 確認設計，再進入 Type 2 的觀察期；但收到要求時要問清楚，只證明設計的 Type 1，未必能滿足想看到控制持續運作證據的客戶。

誰可以看、還有哪些 SOC 報告

SOC 2 報告的讀者需要了解服務內容、內部控制的限制與互補性控制等背景才能正確解讀，所以報告限於具備這些知識的「特定對象」使用，例如服務組織人員、現有客戶、合作夥伴、主管機關，以及在評選廠商時已取得相同理解的潛在客戶[2]。想放在官網給一般大眾看，要另外出具 SOC 3：它是一般用途報告，不含系統描述與測試細節[2]。SOC 1 則處理與客戶「財務報導內部控制」有關的控制，主要是客戶的財報查核會計師需要[2]；客戶指名要 SOC 1，通常代表需求來自對方的財報查核，而不是資安部門。

報告品質不一

據 AICPA 旗下《Journal of Accountancy》2026 年 5 月的報導，AICPA 在同業評鑑（peer review）的審查人員提示中，要求審查人員檢視 SOC 2 案件的時程是否合理、事務所如何使用外部 SOC 平台，並留意報告、風險評估、抽樣數與測試程序完全相同、沒有針對受查組織自身風險設計的案件[4]。不論是自己委託會計師，或是審閱供應商交來的報告，這些都是警訊。

ISO 27001：驗證的是管理系統

ISO/IEC 27001:2022 規定的是建立、實施、維持與持續改善「資訊安全管理系統」（ISMS）的要求，包括依組織需要評鑑與處理資訊安全風險；這些要求適用於任何類型、規模與性質的組織，宣稱符合時不得排除第 4 到第 10 章的任何要求[5]。證書由第三方驗證機構稽核後核發。在台灣，驗證機構可以向財團法人全國認證基金會（TAF）申請認證；TAF 只做認證，不做稽核與驗證，其管理系統驗證機構的認證範圍包括 ISO/IEC 27001 資訊安全管理系統驗證[6]。所以除了看證書，也要確認發證的驗證機構是否經過認證，可以到 TAF 官網的認證名錄查詢；TAF 也提醒，有未獲認證的機構濫用其認證標誌出具非認證報告[6]。導入流程與驗證週期見 ISO 27001 專文。

兩者的差別可以這樣記：

  • 出具者與產出：SOC 2 是會計師出具、限特定對象使用的查核報告[2]；ISO 27001 是驗證機構核發的證書。
  • 回答的問題：SOC 2 Type 2 回答「這些控制在這段期間有沒有有效運作」，並詳列控制測試與結果[2]；ISO 27001 回答「這個組織有沒有一套符合標準要求的資訊安全管理系統」[5]。
  • 範圍：兩者都有範圍。ISO 證書要看涵蓋哪些據點與服務，SOC 2 要看系統描述的邊界與選了哪些類別。

先弄清楚客戶真正要什麼

投入預算之前，先把這幾件事問清楚：

  1. 要求寫在哪裡：請客戶提供書面依據，例如採購規範、合約條款或供應商評鑑表。若寫的是「SOC 2 Type 2、ISO 27001 或同等證明」，你就有選擇空間。
  2. 誰要看：客戶的資安或供應商風險管理團隊、財報查核會計師（通常代表要 SOC 1）[2]，還是主管機關？讀者不同，可接受的證明也不同。
  3. 涵蓋哪項服務：只涵蓋總公司辦公室的 ISO 證書，未必涵蓋客戶要用的 SaaS 平台。
  4. 目前什麼都沒有：誠實說明現況，提供問卷答案、相關政策與導入時程；可以附上雲端業者的報告作為基礎設施層的證明，但要說明它涵蓋不到你的應用程式（見下一節）。

製造業若被問到設備或產線的資安要求，客戶要的可能是另一套標準，見 IEC 62443 與 SEMI E187。

報告期間已過：橋接函

SOC 2 只涵蓋報告期間。期間結束到客戶需要的日期之間的空檔，常用「橋接函」（bridge letter）補上。以 Google Cloud 為例，它說明橋接函是服務提供者管理階層出具的聲明，用來銜接 SOC 報告期間結束日到客戶需要的期末日，摘要這段期間內部控制環境的重大變動或問題，SOC 1 與 SOC 2 都有提供[7]。橋接函是管理階層自己的聲明，不是會計師的查核意見，只適合銜接短暫空檔，不能取代下一期報告。

台灣公部門客戶：資安法對受託者的要求

客戶若是公務機關或特定非公務機關（範圍見資通安全管理法重點整理），要求可能直接來自《資通安全管理法》。第 10 條規定，這些機關委外辦理資通系統建置、維運或資通服務時，應選任適當的受託者，並要求、監督其建立有效的資安管理機制；受託者辦理受託業務的程序及環境，應具備完善的資通安全管理措施，或通過公正第三方驗證；雙方並應簽訂書面契約，載明權利義務及違約責任[8]。法條沒有指定驗證標準，可接受的證明要看委託機關的招標文件與契約。TAF 的認證範圍中另有針對資通安全管理法的 ISO/IEC 27001（CNS 27001）驗證方案特定要求[6]，要拿證書回應公部門客戶時，可以先問清楚委託機關是否要求這個方案。

現行施行細則（2026 年 1 月 5 日修正）第 7 條列出委託機關選任及監督受託者時應注意的事項，與供應商直接相關的包括[9]：

  • 配置充足且受過適當資格訓練、擁有資安專業證照或具類似業務經驗的資安人員；可否複委託，以及複委託廠商應有的資安措施。
  • 客製化資通系統開發應提供安全性檢測證明；屬委託機關核心資通系統或委託金額達新臺幣 1,000 萬元以上者，委託機關應自行或另委第三方檢測；使用非自行開發的系統或資源，應標示來源並提供授權證明。
  • 違反資安法令或知悉資安事件時，立即通知委託機關及採行的補救措施；委託關係終止時，返還、移交、刪除或銷毀履約持有的資料。
  • 委託機關會定期，或在知悉受託者發生可能影響受託業務的資安事件時，以稽核等方式確認執行情形。

ISO 27001 證書證明的是管理系統，和第 7 條要求的系統安全性檢測證明是兩回事，要分開準備。

雲端業者的 SOC 2 不等於你的 SOC 2

「我們架在 AWS 上，AWS 有 SOC 2」並不能回答客戶的問題。AWS 的共同責任模型把責任分成兩半：AWS 負責「雲端本身」的安全，也就是執行雲端服務的硬體、軟體、網路與設施；客戶負責「雲端之中」的安全[10]。以 EC2 為例，客戶要負責客體作業系統的更新與修補、自行安裝的應用程式與安全群組防火牆設定；即使是 S3 這類代管服務，資料（包括加密選項）與權限設定仍由客戶負責[10]。AWS 也建議客戶審閱第三方稽核文件，找出哪些控制可以直接沿用、哪些還要自己實作[10]。雲端業者的報告證明的是機房與平台；你的程式碼、帳號權限、設定與資料處理流程，仍要靠你自己的控制與證明。

自己做 SOC 2 而系統建在雲端時，雲端業者在報告中是「次服務組織」。系統描述可以採包含法（inclusive method），把次服務組織的功能與控制納入描述；或採排除法（carve-out method），把它們排除在外[2]。採排除法時，雲端業者那一段不在你的報告範圍內，讀者得另外取得雲端業者自己的報告。

SOC 2 報告的讀者也必須了解兩種互補性控制如何和服務組織的控制一起運作：互補性使用者個體控制（CUEC）需要由使用服務的客戶端執行；互補性次服務組織控制（CSOC）預期由被排除的次服務組織執行[2]。這要雙向處理：讀雲端業者的報告時，把列出的 CUEC 當成自己的待辦清單逐項確認；寫自己的報告或回覆問卷時，把需要客戶配合的事項（例如客戶自己的帳號管理與 MFA 設定）寫清楚，避免出事時責任不明。

資安問卷：建答案庫，也建證據資料夾

還沒有報告或證書，或客戶想看更細的資訊時，就會收到資安問卷。有些客戶用自己的表格，有些用業界的標準問卷，例如 Shared Assessments 的標準化資訊蒐集問卷（SIG），超過二十年來被用來統一第三方風險評估的方式[11]；以及雲端安全聯盟（CSA）的共識評估倡議問卷（CAIQ），用來說明雲端服務如何實作雲端控制矩陣（CCM）的每一項控制，提交 CAIQ 即是 CSA STAR 的 Level 1 自我評估，結果會刊登在公開的 STAR Registry[12]。

答案庫與證據資料夾

  • 依主題分類（存取控制、加密、備份、弱點管理、事件應變、人員安全、供應商管理、營運持續）寫好標準答案，不要每份問卷都從頭寫。
  • 每個答案標註負責人、最後確認日期、適用範圍（哪個產品或據點）與對應的證據檔案，並對照到 SIG、CAIQ 或你已有的 SOC 2、ISO 27001 控制項目。
  • 換雲端業者、調整架構或發生資安事件後立即重新檢視；業務與資安共同維護，業務端不自行修改技術答案。
  • 證據資料夾放資安政策與程序文件、ISO 證書、SOC 2 報告與最新橋接函、弱點掃描或滲透測試摘要與修補紀錄（參考修補優先順序）、備份還原與營運持續演練紀錄、教育訓練紀錄，以及次服務組織清單與它們的報告。
  • SOC 2 報告限特定對象使用[2]，提供給客戶前先簽保密協議，並記錄提供對象與版本。

不要對沒做到的控制回答「是」

問卷答案不是行銷文案，要當成可能被寫進合約的承諾來回答；CAIQ 若提交到 STAR Registry，更是任何人都查得到[12]。只做到一部分就寫「部分符合」，說明現況、補償控制與預計完成時間；確實不適用就寫「不適用」並說明原因。寫「是」之前先確認拿得出證據，拿不出來就當作還沒做到。問卷中承諾的改善事項要列入內部追蹤，到期前主動向客戶回報。

行動清單

  1. 把過去一年收到的資安要求（報告、證書、問卷、合約條款）集中列表，記錄客戶、要求內容、書面依據與期限。
  2. 逐一確認客戶真正要什麼：SOC 2 Type 1 或 Type 2、ISO 27001、SOC 1，還是填問卷即可；有沒有「或同等證明」的彈性。
  3. 已有報告或證書的，確認範圍是否涵蓋客戶使用的服務，以及報告期間或證書效期；建立出具橋接函的流程。
  4. 取得雲端業者的 SOC 2 報告，把其中的 CUEC 列成待辦清單逐項確認。
  5. 決定要做 SOC 2 時，選擇會計師要留意不合理的短時程與套版報告，並決定次服務組織採包含法或排除法。
  6. 建立問卷答案庫與證據資料夾，指定負責人與檢視週期；對外提供 SOC 2 報告前先簽保密協議。
  7. 客戶若是公務機關或特定非公務機關，逐條對照資安法第 10 條與施行細則第 7 條備妥文件與程序。不確定差距在哪裡，可以先做一次資安健診。