ISO 27001・SOC 2を契約実務でどう扱う?クラウド委託先のリスク管理と条項設計

はじめに

SaaSやクラウドサービスの選定では、「ISO 27001認証取得」「SOC 2対応」といった表示を目にする機会が増えました。こうした第三者認証や保証報告書は、ベンダーのセキュリティ体制を客観的に評価するうえで重要な資料です。

ただし、認証や報告書があるからといって、情報漏えいやサービス停止が起きないと保証されるわけではありません。また、認証の適用範囲に契約対象のサービスが含まれていなかったり、SOC 2報告書の対象期間が古かったりする場合もあります。

重要なのは、認証の有無だけで判断するのではなく、その内容を確認し、契約期間中の維持義務、事故時の通知、再委託先の管理、監査方法などを契約書へ落とし込むことです。

ISO 27001とSOC 2は何を確認する制度なのか

ISO 27001は組織の情報セキュリティ管理体制を評価する

ISO/IEC 27001は、情報セキュリティマネジメントシステム、いわゆるISMSに関する国際規格です。

情報の機密性、完全性、可用性を守るために、組織がリスクを把握し、必要な管理策を選び、継続的に改善する仕組みを構築しているかが評価されます。ISOの公式説明でも、ISO/IEC 27001はISMSを確立、実施、維持、継続的に改善するための要求事項を定める規格とされています。

2026年時点では、ISO/IEC 27001:2022と追補であるAmd 1:2024が適用され、日本ではこれに対応するJIS Q 27001:2025が示されています。ISMS適合性評価制度の公式情報で、ベンダーがどの規格に基づいて認証を受けているかも確認できます。

ただし、ISO 27001認証は必ずしも会社全体を対象とするものではありません。特定の事業所、部門、サービスだけが認証範囲になっている場合があります。

確認すべきなのは、認証マークではなく、次の情報です。

  • 認証を取得した法人名と契約先法人が一致しているか
  • 契約対象のサービスや事業所が登録範囲に含まれているか
  • 認証規格の版が現在の基準に対応しているか
  • 認証書の有効期限が切れていないか
  • 認定された認証機関から発行されているか

国内の認証状況は、ISMS認証取得組織検索でも組織名、登録範囲、認証登録番号などを確認できます。

SOC 2はサービスに関係する内部統制の保証報告書

SOC 2は、AICPA(米国公認会計士協会)が定める基準に基づき、独立した公認会計士がサービス提供組織の内部統制を検証する保証業務です。

厳密には「SOC 2認証」ではなく、「SOC 2保証報告書」と表現するのが適切です。

評価対象には、セキュリティ、可用性、処理のインテグリティ、機密保持、プライバシーというトラストサービス規準があります。AICPAの公式資料では、これらの観点から情報やシステムに関する統制を評価する基準が示されています。

SOC 2には主にType 1とType 2があります。

Type 1は、特定の時点における統制の設計を評価します。一方、Type 2では、一定期間にわたる統制の運用状況も検証され、統制テストとその結果が報告書に含まれます。AICPAのType 2報告書例の説明でも、システム記述、経営者確認書、監査人報告、統制テストと結果が主要な構成要素とされています。

したがって、継続的な運用実績を確認したい場合は、単に「SOC 2取得済み」と聞くだけでなく、Type 1かType 2かを確認する必要があります。

ISO 27001認証やSOC 2報告書だけでは不十分な理由

認証の対象範囲と契約対象が一致するとは限らない

ベンダーがISO 27001認証を取得していても、契約対象となるサービス、開発拠点、データセンター、運用部門が認証範囲外であれば、その認証をサービスの安全性の根拠としてそのまま利用することはできません。

SOC 2についても、報告書に記載された対象システムと、利用企業が契約するサービスプランが一致しているかを確認する必要があります。

認証や報告書は、企業全体を漠然と評価するものではなく、定められた範囲に対する評価です。

SOC 2報告書には例外事項が記載される

SOC 2 Type 2報告書では、監査人が実施した統制テストと結果を確認できます。

ここで重要なのが、例外事項です。例外があるから直ちに危険なサービスとは限りませんが、利用企業は次の点を確認する必要があります。

  • どの統制で例外が発見されたか
  • 例外は単発か、継続的に発生しているか
  • ベンダーが原因をどのように分析したか
  • 代替統制や改善策が実施されているか
  • 自社の利用目的や取り扱う情報に影響するか

「適正意見が出ているから問題ない」と結論づけず、例外の内容と自社への影響を確認することが重要です。

報告書の対象期間には空白が生じる

SOC 2 Type 2は一定期間を対象とするため、利用企業の会計年度や監査時期と報告書の対象期間が一致しないことがあります。

この空白期間についてベンダーからブリッジレターが提出される場合がありますが、一般にブリッジレターは最新のSOC 2 Type 2報告書そのものではありません。

契約では、報告書の対象期間終了後に重大な統制変更やインシデントが発生していないことを確認する資料として位置づけ、次回のSOC 2報告書を取得するまでの暫定的な補完資料として扱うことが適切です。

SOC 2報告書を確認するときの実務チェックポイント

SOC 2報告書を受領したら、表紙や監査意見だけで判断せず、少なくとも次の項目を確認します。

監査人の意見

無限定意見か、限定付意見か、意見不表明などがないかを確認します。限定事項がある場合は、自社のデータや業務への影響を個別に評価します。

対象サービスとシステム記述

契約するサービス、機能、リージョン、データ処理環境が報告書の範囲に含まれているかを確認します。

対象期間

報告書の対象期間が古すぎないか、契約開始後に空白期間が生じないかを確認します。

CUEC

CUECとは、Complementary User Entity Controlsの略で、サービスを安全に利用するために利用企業側が実施すべき補完的統制です。

例えば、多要素認証の設定、管理者権限の定期的な棚卸し、退職者アカウントの削除、アクセスログの確認などが指定されることがあります。

CUECを実施していなければ、ベンダー側の統制だけでは十分な安全性を確保できません。IPAも、クラウドサービスのセキュリティは提供者と利用者がそれぞれの役割を果たすことで維持されると説明しています。中小企業のためのクラウドサービス安全利用の手引きを参考に、自社側の運用も確認する必要があります。

再委託先の扱い

SOC 2報告書では、データセンター、決済、認証、監視などを担う再委託先が、監査範囲から除外されている場合があります。これは一般にCarve-out方式と呼ばれます。

この場合、ベンダーのSOC 2報告書だけでは再委託先の統制まで確認できません。重要な再委託先について、別のSOC 2報告書やISO 27001認証、セキュリティ評価資料の提出を求める必要があります。

第三者認証を契約条項へ落とし込む方法

契約締結時の事実と契約期間中の義務を分ける

「契約締結日時点でISO 27001認証を取得している」という条項だけでは、契約締結後に認証が失効しても対応できません。

そのため、契約では次の二つを分けて規定します。

  • 契約締結時に、有効な認証や報告書を保有していること
  • 契約期間中も、定めた認証水準や統制を維持すること

さらに、認証の一時停止、取消し、更新断念、限定意見、重大な例外事項が発生した場合の通知義務も必要です。

最新資料の定期提出を求める

利用企業が継続的に確認できるように、契約では次の資料を定期的に提出する義務を定めます。

  • 最新のISO 27001認証書
  • 認証の登録範囲と有効期限
  • 最新のSOC 2 Type 2報告書
  • 必要に応じたブリッジレター
  • 例外事項に対する改善計画
  • 再委託先に関する認証・保証資料

SOC 2報告書は詳細なセキュリティ情報を含むため、秘密保持契約の下で開示されることがあります。なお、一般配布を想定したSOC 3は詳細情報が省略されており、AICPAもSOC 2と同じ水準の詳細を含まない一般利用向け報告書と説明しています。SOC 3の公式説明も確認しておくとよいでしょう。

監査権と代替確認方法を設計する

利用企業は委託先を監督する必要がありますが、マルチテナント型クラウドサービスでは、顧客ごとの立入監査を認めることが難しい場合があります。

そこで、契約では確認方法に優先順位を設けます。

  1. ISO 27001認証書やSOC 2報告書による確認
  2. セキュリティ質問票や改善報告書による追加確認
  3. 重大な事故や合理的な疑義がある場合の追加監査
  4. 必要に応じた独立専門家による監査

個人情報保護委員会も、個人データを委託する場合は、委託先において適切な安全管理措置が講じられるよう必要かつ適切な監督を行う必要があるとしています。個人情報保護法ガイドラインの委託先監督も踏まえ、報告書を受領するだけで監督を終わらせないことが重要です。

認証失効時の是正措置と契約終了条件を定める

認証の失効や重大な統制不備が発生した場合に備え、次の対応を契約で定めます。

  • 発生事実と原因の速やかな通知
  • 是正計画と進捗報告の提出
  • 代替統制の実施
  • 一定期間内の認証再取得
  • 是正されない場合の利用停止または契約解除
  • データの返還、移行、消去
  • 消去完了を確認する証明書の提出

契約上の維持義務や通知義務を明確にすれば、違反時に債務不履行として対応を検討する基準も明確になります。ただし、実際の損害賠償や解除の可否は、契約文言、免責・責任制限、損害との因果関係などによって異なります。

再委託先まで含めたサプライチェーン管理が必要

クラウドサービスは、単独のベンダーだけで完結しているとは限りません。インフラ、データセンター、決済、メール配信、認証、保守など、複数の再委託先によって構成されています。

契約では、少なくとも次の点を明確にします。

  • 主要な再委託先の名称、所在地、業務内容
  • データの保存国と処理国
  • 再委託先を追加・変更する場合の事前通知
  • 利用企業が異議を申し立てるための手続
  • 再委託先にも同等の安全管理義務を課すこと
  • 再委託先の行為についてベンダーが責任を負うこと
  • 重大なリスクがある場合のサービス変更・解約条件

個人情報保護委員会は、委託先に求める報告へ、再委託先の選定、契約、安全管理措置、取扱状況の把握を含める方法を示しています。再委託先の監督に関するFAQを参考に、契約と運用の両面から確認することが必要です。

まとめ

ISO 27001認証とSOC 2保証報告書は、クラウド事業者のセキュリティ体制を評価するための有力な証拠です。しかし、認証マークや「SOC 2対応」という表示だけで、安全性や事故時の責任まで保証されるわけではありません。

利用企業は、認証範囲、有効期限、SOC 2の対象期間、例外事項、CUEC、再委託先を確認し、自社のリスクに不足する部分を契約条項で補う必要があります。

一方、ベンダー側も、取得済みの認証を単なる営業資料にするのではなく、開示方法、更新時期、事故通知、再委託先管理、利用企業側の責任を整理しておくことが重要です。

第三者認証を契約上の義務、報告、是正、監査、終了時対応まで結び付けて初めて、認証は継続的なリスク管理の仕組みとして機能します。

コメント

この記事へのコメントはありません。

新着の記事
注目記事
お知らせ
  1. AI活用人材のスキルマップと社内認定制度の設計方法|評価・育成・配置をつなぐ実践手順

  2. AI時代の会社概要ページは「信頼データベース」へ|AEOとE-E-A-Tを両立する設計・実装戦略

  3. 生成AIとRPAの融合で製造業バックオフィスを変える|業務自動化からDXへ進む実践方法

  4. 自治体AI共同利用の責任分界点モデル|安全な共同基盤と実効的な利用規程の作り方

  5. RAG時代のAI検索最適化|生成エンジンに参照される記事構造とFAQ設計

  1. 中小企業のゼロトラスト導入は何から始めるべきか|現実的なステップと投資判断

  2. AI活用リーダー制度を人事評価につなげるには|資格認定・処遇・育成ロードマップの設計

  3. 業務委託契約の再委託管理とは?取適法・フリーランス法に対応する実務フローと契約条項

  4. 実データを使うAI研修のデータ匿名化ルール|個人情報保護と成果を両立する実務設計

  5. 自治体の三層分離とゼロトラストとは?違いと移行課題をわかりやすく解説

  1. 第1回JAIC無料AIセミナーを開催しました―AIを「知る」から「仕事で試す」へ

  2. 地方自治体に向けて、AI・AXを活用した複数の業務改善提案を行いました

  3. 自治体に向けて生成AI実装・定着支援の提案を行いました

  4. 【イベント開催のお知らせ】AI活用セミナーを開催します

  5. 自治体AX推進に向けたアンケートを作成しました

関連記事