SOC 2（System and Organization Controls 2）は米国公認会計士協会（AICPA）が策定した内部統制報告フレームワークで、サービス事業者の管理体制をTrust Services Criteriaに照らして第三者監査人が評価し、報告書として発行する仕組みである。2010年に当時のSAS 70を発展させた形で誕生し、SaaS／クラウド／BPOの普及とともに国際的なデファクト基準となった。本稿では成立の経緯、SOC 1／2／3の違い、Type IとType IIの差、Trust Services Criteriaの構造、運用上の実務を整理する。
この記事の目次
- SAS 70からSOC 2への発展
- Trust Services Criteriaの5原則
- Type IとType IIの違い
- 他規格との関係と運用上の実務
- まとめ
SAS 70からSOC 2への発展
AICPAは1992年にSAS 70（Statement on Auditing Standards No. 70）を公表し、サービス組織の内部統制を評価する基準として活用してきた。しかしSAS 70は本来財務報告に関連する統制が対象だったため、システムの可用性や機密性などの非財務統制を評価する場面では使い勝手が悪く、誤用が問題視されるようになった。これを受けて2010年6月にAICPAはSSAE 16を導入し、サービス組織レポートをSOC 1（財務報告関連）、SOC 2（運用統制関連）、SOC 3（一般向け要約）に再編した。
現在の根拠はSSAE 18（2017年5月発効）であり、Trust Services Criteriaは2017年に大改訂され2022年に再評価された。SOC 2はAICPAが定義する5つの信頼性原則を軸とする報告書で、SaaS・データセンタ・マネージドサービスの委託先選定における事実上の標準となった。日本でも上場企業や金融機関がベンダー評価の必須資料として要求する場面が増えている。
Trust Services Criteriaの5原則
SOC 2の中核となるのはTrust Services Criteria（TSC）と呼ばれる5つの信頼性原則である。Security（共通基準）は必須で、内部統制統合フレームワーク（COSO 2013）の17原則をベースに、論理・物理アクセス、変更管理、リスク評価、監視活動などを評価する。残る4原則はAvailability（可用性）、Processing Integrity（処理の完全性）、Confidentiality（機密性）、Privacy（プライバシ）であり、組織のサービス特性に応じて選択的に含める。
Securityの統制目標はCC1〜CC9のCommon Criteriaカテゴリで整理され、ID管理（CC6）、システム運用（CC7）、変更管理（CC8）、リスクの軽減（CC9）などにまとめられる。Privacyは2017年版TSCで独立した原則として再整理され、米国AICPAのGenerally Accepted Privacy Principles（GAPP）の流れを汲んでいる。GDPRやCCPAとも親和性が高く、グローバル展開を志す事業者がPrivacyを含めるケースが増えている。
Type IとType IIの違い
SOC 2にはType IとType IIの二種類が存在する。Type Iは特定時点（たとえば6月30日時点）における統制の設計の妥当性を評価する報告書で、比較的短期間で取得できることから初回認証時に選ばれる。Type IIは6〜12か月の評価期間における統制の運用有効性を評価し、サンプリングを通じて実際に統制が機能しているかを検証する。
委託元企業の多くは年次更新のType II報告書を要求するため、初年度にType I、翌年以降にType IIを発行する流れが一般的である。監査は米国公認会計士（CPA）またはAICPA加盟事務所が実施する必要があり、ISMS適合性評価制度（ISO 27001の認証）と異なり、報告書という形で詳細な統制内容と試験結果が記述される点が特徴である。報告書は秘密保持契約のもとで限定的に共有される。
他規格との関係と運用上の実務
SOC 2と組み合わせて取得されることが多いのがISO/IEC 27001である。前者は監査報告書（評価結果の開示）、後者はマネジメントシステムの第三者認証であり、目的と形式は異なるが統制内容は重なる部分が多いため、内部統制セットを共通化して運用する組織が多い。AICPAも「Mapping SOC 2 to ISO 27001」のような対照表を公開し、二重監査の負担を減らす取り組みを進めている。
SaaSベンダーが導入する代表的なツールにはVanta、Drata、Secureframe、Tugboat Logicなどがあり、統制の証跡収集を自動化することで小規模スタートアップでも数か月でSOC 2取得が可能になった。監査受審においては、ポリシー文書、組織図、構成管理、変更管理ログ、アクセスレビュー記録、インシデント対応記録、教育記録などが代表的な証跡となる。Type II取得後は、サブサービス組織（クラウド基盤事業者など）のSOC 2報告書も「Carve-Out」または「Inclusive」の形で参照し、責任分界を明確にすることが求められる。
まとめ
SOC 2は委託先の内部統制を客観的に確認するための共通言語であり、Trust Services CriteriaとType I／IIの構造を理解すれば、自社の体制説明と取引先評価の双方に活用できる。ISO 27001など他規格と統合運用することで、監査負担を抑えつつグローバル取引での信頼性を獲得できる。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント