AWS・Google Cloud・各種SaaSを多用する組織にとって、ISMSの統制整備は「自社サーバーを管理していた時代」のアプローチがそのまま使えないケースが増えています。「クラウドは安全なはずだから大丈夫」という誤解と、「何もかも自分たちで管理しなければ」という過剰統制の間で、整備の方向を見失っている組織が多いのが実態です。
この記事では、クラウド・SaaS環境における統制整備の考え方を、ISMSの実務レビュー観点から解説します。
1. 責任共有モデルを起点に「自社の統制範囲」を明確にする
クラウド利用における統制の基本は、責任共有モデル（Shared Responsibility Model）の理解から始まります。AWSを例に取ると、「クラウドのセキュリティ（インフラ）」はAWSが、「クラウド上のセキュリティ（データ、アクセス管理、設定）」は利用者側が責任を持つという分担になっています。
ISMSのリスクアセスメントでも、この責任分界に基づいて「どのリスクをクラウドベンダーが対処し、どのリスクを自社が管理するか」を明確にする必要があります。SoA（適用宣言書）の各管理策についても、「クラウドベンダーに依存している部分」と「自社で統制を設けている部分」を整理しておくことが重要です。
よくある誤り：「AWSを使っているから物理セキュリティは不要」とSoAに書く一方で、論理アクセス管理やログ管理の統制が曖昧なまま放置されているケース。物理的な責任はベンダー側でも、論理的な統制の整備は自社の責任です。
2. 委託先管理として「クラウドベンダー」を正しく位置付ける
ISMSでは、外部委託先のセキュリティ管理が求められています（ISO 27001:2022 附属書A 5.19〜5.22）。クラウドベンダーやSaaSプロバイダも「委託先」として管理対象に含める必要があります。
実務上の課題は、個々のSaaSプロバイダを全て詳細評価するのが現実的でない点です。重要度に応じてティアを設け、重要度の高いサービス（基幹業務データを扱うもの）は詳細評価を実施し、低リスクのものは簡易確認にとどめるリスクベースアプローチが現実的です。
評価に使える情報源
| 情報源 | 内容 | 評価の活用方法 |
|---|---|---|
| SOC 2 Type II レポート | セキュリティ・可用性等の統制に関する第三者監査報告 | 委託先の統制有効性の確認に活用 |
| ISO 27001認証 | 情報セキュリティマネジメントの国際認証 | 認証の有無・スコープ・有効期限を確認 |
| Trust Center / セキュリティページ | 各社が公開するセキュリティ対応情報 | 基本的な統制方針の把握に活用 |
| DPA（データ処理契約） | 個人データ処理に関する契約 | データの取り扱いと責任の明確化 |
実務では、SOC 2レポートを監査法人から求められて取り寄せ、中身を確認しないまま監査人にそのまま提出するケースが多く見られます。しかし本来、SOCレポートは自社の委託先評価の根拠として読み込むべき資料です。「取得して保管する書類」として処理してしまうと、委託先評価として機能していないことになります。
SOC 2レポートとは：クラウドサービス・SaaSプロバイダが、独立した第三者の監査機関にセキュリティ等の統制状況を審査してもらい、その結果をまとめた報告書です。「Type II」は一定期間（通常6〜12ヶ月）にわたって統制が有効に機能していたことを確認した、より信頼性の高い種類です。利用者側に求められることは、レポートを受け取るだけでなく、自社の利用範囲に関連する統制が有効に機能しているか、また自社側に実施を求められている統制（補完的ユーザー統制）はないかを評価することです。
3. SOC 2レポートの「どこを見るか」を押さえる
SOC 2レポートを取り寄せても「何を確認すればよいかわからない」という担当者は多いです。レポートは膨大なページ数になりますが、確認すべき箇所は限られています。ISMSとJ-SOX（内部統制報告制度）のいずれの文脈でも、以下の観点が基本になります。
- 適用範囲（Scope）：自社が利用しているサービス・環境が対象に含まれているか
- 審査期間：レポートの対象期間が直近1年以内であるか（古いレポートは評価の根拠として使いにくい）
- 例外事項（Exceptions）：統制上の不備が記載されていないか。記載がある場合は、自社への影響度を評価する
- 補完的ユーザー統制：利用者側（自社）が実施を求められている統制が記載されているため、自社側の対応状況を確認する
補完的ユーザー統制は特に重要：SOC 2レポートには「このサービスを安全に使うために、利用者側でも行うべき統制」が記載されています。ここを確認せずに「SOC 2取得済みだから安全」と判断するのは不十分です。補完的ユーザー統制への対応が自社統制として実装されているか確認してください。
J-SOX（内部統制報告制度）対応での活用
J-SOX対応においても、クラウドサービスの利用はSOCレポートの活用場面を生み出します。IT全般統制の評価では、リスクコントロールマトリクス（RCM）に記載されたIT統制のうち、実態としてクラウドベンダー側が実施している統制を識別することが出発点です。
たとえば、アクセス管理・変更管理・運用管理といったITGCの評価項目において、その統制を実質的に担っているのがクラウドベンダーである場合、SOCレポートに記載された当該統制の評価結果を、経営者評価の根拠として活用することができます。自社で直接検証する代わりに、第三者監査機関が検証した結果を合理的な根拠として使用できる点が、SOCレポートを活用する実質的な意義です。
一方、SOCレポートに記載された補完的ユーザー統制に相当する項目は、クラウドベンダー側の統制でカバーされるものではなく、事業会社側で内部統制を構築・運用することが求められます。この部分は通常のシステムと同様に、自社のRCMに統制として組み込み、評価の対象とする必要があります。「SOCレポートがあるから大丈夫」と判断してしまうと、この領域が評価の空白になりかねません。
4. 自社側で取得・保持すべき証跡を明確にする
クラウド環境では、証跡の取得方法がオンプレミス環境と異なります。「ログはクラウド側が持っているから大丈夫」ではなく、審査・監査で求められたときに提示できる形で自社が保持しているかが問われます。
- IAMユーザー・ロールの棚卸し記録（定期的な権限レビューの証跡）
- 不要なアカウント・権限の削除記録
- CloudTrail・アクセスログの保持期間と保存先の確認
- 設定変更の記録（誰がいつ何を変更したか）
- 委託先評価の実施記録と結果
5. 過剰統制にしないための考え方
クラウド統制の整備で陥りがちな問題のひとつが「過剰統制」です。オンプレミス時代の統制設計をそのままクラウドに持ち込み、現実的に運用できない手順書や証跡要件を作ってしまうケースがあります。
ISMSで求められているのは「リスクを許容水準以下に抑えること」であり、全てのリスクを0にすることではありません。クラウドベンダーが既に対処しているリスクに対して自社で二重の統制を設けることは、運用コストを増やすだけになります。
「この統制は、どのリスクを低減するために設けているのか」を常に問いながら、現実的に運用が回る統制設計をすることが重要です。
まとめ：クラウド統制整備のチェックリスト
- 責任共有モデルに基づいて「自社の統制範囲」を明確にしているか
- クラウドベンダー・SaaSを委託先として管理しているか
- 重要度に応じたリスクベースの評価を実施しているか
- SOC 2レポートを取り寄せて中身を確認し、補完的ユーザー統制への対応を評価しているか
- J-SOX対応では、RCMのIT統制のうちクラウドベンダー側が担う統制を識別し、SOCレポートを経営者評価の根拠として活用しているか
- SOCレポートの補完的ユーザー統制に相当する項目を、自社のRCMに組み込んで評価しているか
- 権限棚卸し・ログ保持など、自社側の証跡を適切に取得しているか
- 運用が回る現実的な統制設計になっているか