はじめに：なぜ今、SaaS監査が重要なのか#
クラウドサービスの普及により、企業が利用するSaaS（Software as a Service）の数は年々増加しています。2025年現在、1社あたり平均130以上のSaaSを利用しているというデータもあり、その管理と監査の重要性は以前とは比較にならないほど高まっています。
従来のオンプレミス環境では、自社でシステムを管理・運用していたため、セキュリティ対策や監査も自社の責任範囲で完結していました。しかし、SaaSを利用する場合、データの保管・処理をサービス提供事業者（ベンダー）に委ねることになります。この「見えない領域」に自社の重要なデータを預けることには、固有のリスクが伴います。
本記事では、IT監査やセキュリティの実務担当者に向けて、SaaS監査の具体的な方法と外部サービスのリスク評価について詳しく解説します。監査のフレームワークから実務で使えるチェックリストまで、明日から活用できる内容をお届けします。
背景・概要：SaaS監査を取り巻く環境#
SaaS利用拡大がもたらすリスクの変化#
SaaSの利用が急拡大した背景には、導入の容易さ、初期コストの低さ、スケーラビリティの高さなどのメリットがあります。しかし、これらのメリットの裏側には、以下のようなリスクが潜んでいます。
主なリスク要因：
- データ所在地の不透明性 - 自社データがどの国・地域のサーバーに保管されているか把握しづらい
- アクセス管理の複雑化 - 複数のSaaSにまたがるID・アクセス管理が煩雑になる
- ベンダーロックイン - サービス終了時のデータ移行リスク
- サプライチェーンリスク - SaaSベンダーが利用する下請け業者のセキュリティ
- シャドーIT - IT部門が把握していないSaaSの無断利用
責任共有モデルの理解#
SaaS監査を行う上で最も重要な概念が「責任共有モデル（Shared Responsibility Model）」です。これは、クラウドサービスにおけるセキュリティ責任を、ベンダーと利用者で分担するという考え方です。
SaaSの場合、一般的な責任分担は以下のようになります：
| 責任領域 | ベンダー | 利用者 |
|---|---|---|
| 物理セキュリティ | ◎ | - |
| ネットワークセキュリティ | ◎ | △ |
| アプリケーションセキュリティ | ◎ | △ |
| データ暗号化 | ◎ | ◎ |
| アクセス管理・認証 | △ | ◎ |
| データ分類・管理 | - | ◎ |
| コンプライアンス対応 | △ | ◎ |
（◎：主たる責任、△：一部責任、-：責任なし）
この責任分担を正しく理解した上で、ベンダー側の対策状況を監査し、利用者側の対策が適切かを評価することがSaaS監査の本質です。
関連する法規制・ガイドライン#
SaaS監査を実施する際には、以下の法規制やガイドラインを意識する必要があります：
- 個人情報保護法（日本）
- GDPR（EU一般データ保護規則）
- ISMAP（政府情報システムのためのセキュリティ評価制度）
- SOC 2 Type II報告書
- ISO/IEC 27001認証
- CSA STAR認証
これらの認証・報告書の有無は、SaaSベンダーのセキュリティ成熟度を判断する重要な指標となります。
SaaS監査の具体的な手順と要点#
1. SaaS利用状況の可視化（インベントリ作成）#
SaaS監査の第一歩は、自社で利用しているSaaSの完全なリストを作成することです。これは「SaaSインベントリ」または「クラウドサービスカタログ」と呼ばれます。
収集すべき情報：
- サービス名・ベンダー名
- 契約形態（有償/無償、年間契約/月額契約）
- 利用部門・担当者
- 利用目的・用途
- 取り扱うデータの種類（個人情報、機密情報等）
- 連携している他システム
- 契約開始日・更新日
- 年間利用コスト
実務のポイント：
シャドーITを発見するため、以下の方法を組み合わせることをお勧めします：
- ネットワークログ分析 - プロキシやファイアウォールのログからSaaSへのアクセスを特定
- SSO/IdP連携状況の確認 - Azure AD、Oktaなどの認証基盤との連携有無
- 経費精算データの分析 - クレジットカード明細からSaaS利用料を抽出
- 従業員アンケート - 各部門に利用中のサービスを申告してもらう
多くの企業では、この可視化プロセスで把握していなかったSaaSが20〜30%程度発見されます。
2. リスク分類とティアリング#
すべてのSaaSを同じ深度で監査することは現実的ではありません。リスクベースアプローチに基づき、SaaSをリスクレベルで分類（ティアリング）します。
ティアリングの例：
| ティア | リスクレベル | 特徴 | 監査頻度 |
|---|---|---|---|
| Tier 1 | 高リスク | 機密情報・大量の個人情報を扱う、業務停止の影響大 | 年1回以上 |
| Tier 2 | 中リスク | 一部の個人情報を扱う、業務影響あり | 年1回 |
| Tier 3 | 低リスク | 機密情報なし、代替手段あり | 2〜3年に1回 |
リスク評価の観点：
- データの機密性 - 取り扱うデータの機密レベル
- データ量 - 保管されるレコード数・ユーザー数
- 業務重要度 - サービス停止時の業務影響度
- 代替可能性 - 他サービスへの移行の容易さ
- 法規制要件 - 業界固有の規制対象かどうか
実務のポイント：
スコアリングモデルを作成し、客観的にティアリングできる仕組みを構築しましょう。例えば、各観点を1〜5点で評価し、合計点で分類する方法が一般的です。
評価例：Salesforce（CRM）
- データの機密性：4点（顧客情報含む）
- データ量：5点（10万件以上）
- 業務重要度：5点（営業活動の根幹）
- 代替可能性：2点（移行コスト大）
- 法規制要件：3点（個人情報保護法対象）
合計：19点 → Tier 1（高リスク）に分類
3. ベンダーセキュリティ評価（デューデリジェンス）#
SaaSベンダーのセキュリティ対策状況を評価するプロセスです。新規導入時と定期的な再評価の両方で実施します。
評価の情報源：
第三者認証・報告書
- SOC 2 Type II報告書（最も詳細な情報が得られる）
- ISO 27001認証
- CSA STAR認証
- ISMAP登録（政府機関向け）
セキュリティホワイトペーパー
- ベンダーが公開しているセキュリティ概要文書
セキュリティ質問票（SIG/CAIQ等）
- 標準化された質問票への回答
契約書・SLA・DPA
- 利用規約、サービスレベル契約、データ処理契約
SOC 2報告書の読み方：
SOC 2 Type II報告書は、SaaS監査で最も価値のある情報源です。以下のポイントに注目して読みましょう。
- 監査対象期間 - 最新のものか（理想は6ヶ月以内）
- 監査範囲 - 利用するサービスが含まれているか
- 適用されたトラストサービス基準 - Security、Availability、Confidentiality等
- 例外事項・限定事項 - 監査人の意見に留保はないか
- 補完的ユーザー組織統制（CUEC） - 利用者側で対応すべき統制
実務のポイント：
SOC 2報告書の入手を契約前の必須条件とすることを推奨します。報告書の提供を拒否するベンダーは、セキュリティ意識が低い可能性があります。
4. セキュリティ質問票の活用#
第三者認証だけでは確認できない詳細事項について、セキュリティ質問票を使って確認します。
代表的な質問票フレームワーク：
| フレームワーク | 特徴 | 質問数 |
|---|---|---|
| SIG（Shared Assessments） | 金融業界で広く採用、詳細 | 約800問 |
| CAIQ（CSA） | クラウド特化、無償で利用可 | 約260問 |
| VSAQ（Google） | シンプル、自己評価向け | 約140問 |
質問票で確認すべき重要項目：
データ暗号化
- 保管時暗号化（AES-256等）
- 通信時暗号化（TLS 1.2以上）
- 暗号鍵の管理方法
アクセス制御
- 多要素認証（MFA）のサポート
- シングルサインオン（SSO）対応
- ロールベースアクセス制御（RBAC）
データ保護
- バックアップ頻度・保持期間
- データ所在地（リージョン指定可否）
- データ削除・エクスポート機能
インシデント対応
- インシデント通知のSLA（例：72時間以内）
- 過去のインシデント履歴
- 障害時の連絡体制
事業継続性
- SLA（稼働率保証、例：99.9%）
- DR（災害復旧）サイトの有無
- サービス終了時のデータ返却ポリシー
実務のポイント：
質問票の全項目を毎回確認するのは非効率です。ティアリングに応じて質問項目を絞り込んだ「簡易版」「詳細版」を用意しておくと運用しやすくなります。
5. 契約条項の精査#
SaaSの利用契約には、セキュリティ・監査に関連する重要な条項が含まれています。法務部門と連携して、以下の点を確認します。
確認すべき契約条項：
データ所有権
- 利用者のデータは利用者に帰属することの明記
- ベンダーによるデータ利用の制限
データ処理契約（DPA）
- GDPR対応が必要な場合は必須
- 処理の目的・範囲の明確化
- サブプロセッサー（再委託先）の開示
監査権
- 利用者による監査の実施可否
- SOC 2報告書等の提供義務
セキュリティ義務
- ベンダーが遵守すべきセキュリティ基準
- 脆弱性対応のSLA
インシデント通知
- 通知期限（例：発覚後72時間以内）
- 通知すべきインシデントの範囲
解約・終了条項
- データエクスポートの期間・方法
- 解約後のデータ削除の保証
実務のポイント：
大手SaaSベンダーの標準契約は修正交渉が難しいことが多いです。その場合は、補完的な覚書（サイドレター）で重要事項を追加合意する方法を検討しましょう。
6. 技術的検証の実施#
可能な範囲で、SaaSの設定状況やセキュリティ機能を技術的に検証します。
検証項目の例：
認証設定
- MFAの強制設定
- パスワードポリシーの強度
- SSO連携の設定状況
権限設定
- 管理者アカウントの棚卸し
- 過剰な権限付与の有無
- 離職者アカウントの残存確認
ログ・監視
- 監査ログの取得状況
- ログの保持期間
- SIEM連携の可否
データ保護設定
- DLP（データ損失防止）機能の設定
- 共有設定の制限状況
- 外部共有リンクの管理状況
CSPM（Cloud Security Posture Management）の活用：
複数のSaaSを一元的にセキュリティ監視できるCSPMツールの導入も検討価値があります。代表的なツールとして、以下があります：
- Microsoft Defender for Cloud Apps
- Netskope
- Zscaler
- AppOmni
これらのツールは、SaaSの設定不備や異常なアクセスパターンを自動検出し、継続的な監視を可能にします。
7. 監査証跡の文書化と報告#
監査結果を適切に文書化し、経営層や関係者に報告します。
文書化すべき内容：
監査計画書
- 監査目的・範囲
- 監査手法・スケジュール
- 担当者・役割分担
監査調書（ワーキングペーパー）
- 確認した証跡・エビデンス
- 評価結果・判断根拠
- 発見事項の詳細
監査報告書
- 総合評価（適切/要改善/不適切等）
- 主要な発見事項・リスク
- 改善勧告事項
- フォローアップ計画
リスク評価の表現例：
| リスクレベル | 定義 | 対応期限目安 |
|---|---|---|
| 高（Critical） | 即座に重大な影響を及ぼす可能性 | 1週間以内 |
| 中（High） | 放置すると重大な影響に発展 | 1ヶ月以内 |
| 低（Medium） | 改善が望ましい | 3ヶ月以内 |
| 情報（Low） | 参考情報として記録 | 次回評価時に確認 |
実務のポイント：
監査報告書は、技術的な詳細だけでなく、ビジネスへの影響を分かりやすく説明することが重要です。経営層向けのエグゼクティブサマリーを別途作成することをお勧めします。
8. 継続的モニタリング体制の構築#
SaaS監査は一度きりではなく、継続的に実施する必要があります。効率的な運用のために、以下の体制を構築しましょう。
継続的モニタリングの要素：
定期評価スケジュール
- Tier 1：年1回以上
- Tier 2：年1回
- Tier 3：2〜3年に1回
- 契約更新時：全ティア再評価
トリガーベース評価
- ベンダーでのセキュリティインシデント発生時
- 重大な機能変更・アップデート時
- 利用用途の変更時
- 新規法規制の施行時
自動監視の活用
- CSPM/SAASMツールによる設定監視
- セキュリティレーティングサービスの活用（SecurityScorecard、BitSight等）
- ベンダーのステータスページ監視
実務のポイント：
すべてを手動で実施するのは限界があります。自動化できる部分は積極的にツールを活用し、人的リソースは判断が必要な部分に集中させましょう。
よくある質問（FAQ）#
Q1. SOC 2報告書を提供してくれないベンダーはどう評価すればよいですか？#
SOC 2報告書がない場合でも、以下の方法で評価を行うことは可能です。
代替アプローチ：
- ISO 27001認証の確認 - 認証範囲にSaaSサービスが含まれているか確認
- 詳細なセキュリティ質問票の送付 - CAIQ等を利用して直接確認
- ペネトレーションテスト報告書の要求 - 第三者による脆弱性診断結果
- 経営陣との面談 - セキュリティに対する姿勢を直接確認
- セキュリティレーティングの参照 - 外部から観測可能な情報に基づく評価
ただし、SOC 2報告書に代わる十分な証跡が得られない場合は、そのリスクを受容するか、代替サービスを検討するかの判断が必要です。高リスク（Tier 1）のSaaSについては、SOC 2報告書の提供を必須条件とすることを強くお勧めします。
Q2. 海外SaaSを利用する場合、特に注意すべき点は何ですか？#
海外SaaSの利用には、国内サービスとは異なる追加的な考慮事項があります。
主な注意点：
データ越境移転の問題
- 個人情報保護法に基づく越境移転規制への対応
- GDPRの適切な根拠（SCCs、十分性認定等）
- 米国の場合：Data Privacy Frameworkへの準拠確認
準拠法・管轄裁判所
- 契約書の準拠法がどの国か
- 紛争時の管轄裁判所がどこか
- 日本法での対応が可能か
政府によるデータアクセス
- CLOUD Act（米国）による法執行機関のアクセス可能性
- 各国の政府アクセス法制の理解
サポート体制
- 日本語サポートの有無
- タイムゾーンの違いによる対応遅延
- インシデント発生時の緊急連絡体制
サービス継続性
- 日本市場からの撤退リスク
- 為替変動による価格変動リスク
実務のポイント：
海外SaaSを利用する場合は、契約書にデータ所在地（リージョン）の指定が可能か確認しましょう。多くのグローバルSaaSは、日本リージョンまたはアジアリージョンを選択可能です。
Q3. 小規模企業でもSaaS監査は必要ですか？どこまで行うべきですか？#
企業規模に関わらず、SaaSを利用する以上、何らかのリスク管理は必要です。ただし、リソースに応じた現実的なアプローチが重要です。
小規模企業向けの簡易アプローチ：
最低限実施すべきこと
- 利用中のSaaSリストの作成と定期的な更新
- 重要なSaaS（顧客データ、財務データを扱うもの）の特定
- 基本的なセキュリティ機能（MFA、SSO）の有効化
優先的に確認すべき項目
- SOC 2報告書またはISO 27001認証の有無
- データ暗号化の実施
- バックアップ・データエクスポート機能の確認
- 契約終了時のデータ削除ポリシー
活用できるリソース
- ベンダーが公開しているセキュリティページ
- 無償のセキュリティ質問票（CAIQ等）
- IPAや業界団体が公開しているチェックリスト
コスト対効果の考え方：
監査にかけられるコスト・時間と、リスク顕在化時の損失を比較して、適切な投資レベルを判断しましょう。例えば、年間売上の1%程度をセキュリティ対策（監査含む）に投資するという目安があります。
まとめ：実効性のあるSaaS監査に向けて#
SaaS監査は、単なるチェックリストの消化ではなく、外部サービスに預けた自社データを守るための重要な取り組みです。本記事で解説した8つのステップを実践することで、体系的かつ効率的なSaaS監査が可能になります。
本記事の重要ポイント：
- 可視化が出発点 - シャドーITを含む全SaaSの把握から始める
- リスクベースで優先順位付け - すべてを同じ深度で監査する必要はない
- SOC 2報告書を最大限活用 - 最も詳細な情報が得られる証跡
- 契約条項も監査対象 - 技術面だけでなく法務面もカバー
- 継続的なモニタリング - 一度きりではなく、定期的な再評価を行う
明日から始められるアクション：
- 利用中SaaSの棚卸しを開始する
- Tier 1（高リスク）のSaaSを3つ特定する
- 特定したSaaSのSOC 2報告書を入手する
- 簡易セキュリティ質問票のテンプレートを作成する
- 次回の契約更新時に確認すべき条項をリスト化する
SaaS監査は、最初は負担に感じるかもしれません。しかし、一度フレームワークを構築すれば、効率的に運用できるようになります。本記事が、皆様のSaaS監査実務の一助となれば幸いです。
参考資料・リンク：
- Cloud Security Alliance (CSA) - CAIQ質問票
- AICPA - SOC 2報告書の基準
- IPA - クラウドサービス安全利用のための手引き
- 経済産業省 - クラウドセキュリティガイドライン