SOC 2との比較
30.6.1. SOC 2の概要
SOC 2（Service Organization Controls 2）は、サービス組織の内部統制を検証する監査フレームワークです。米国公認会計士協会（AICPA, American Institute of Certified Public Accountants）が制定したTrust Services Criteriaに基づいており、主にSaaS、クラウドサービス、データセンターなどの技術サービスを提供する組織を対象としています。
SOC 2はISO 27001やISMS-Pとは異なり、「認証」ではなく「監査報告書」です。独立した監査人（CPA法人）が組織の内部統制を審査し、その結果を報告書として発行します。この報告書に基づいて、顧客（主にB2B顧客）がサービス提供者のセキュリティおよび運用統制レベルを判断します。
SOC 2は米国市場を中心に発展しましたが、グローバルSaaS市場の成長に伴い世界的に需要が増加しています。特に北米、欧州市場でB2B SaaSサービスを提供するにはSOC 2報告書が事実上必須の要件です。韓国国内でも海外顧客を相手にするSaaS企業がSOC 2監査を受けるケースが増えています。
SOC 2報告書は非公開文書です。NDA（秘密保持契約）の下で顧客にのみ共有され、一般には公開されません。これは報告書に組織の内部統制の詳細が含まれているためです。
30.6.2. Trust Services Criteria
SOC 2はAICPAのTrust Services Criteria（TSC）に定義された5つの原則を基準に監査を実施します。
| 原則 | 英文 | 説明 | 必須の有無 |
|---|---|---|---|
| セキュリティ | Security | システムが不正アクセスから保護されているか | 必須（Common Criteria） |
| 可用性 | Availability | システムが合意されたレベルで運用され使用可能か | 選択 |
| 処理の完全性 | Processing Integrity | システム処理が完全かつ正確で適時に行われているか | 選択 |
| 機密性 | Confidentiality | 機密として指定された情報が保護されているか | 選択 |
| プライバシー | Privacy | 個人情報が収集、使用、保持、開示、廃棄時に保護されているか | 選択 |
30.6.2.1. セキュリティ（Security）- Common Criteria
セキュリティ原則はすべてのSOC 2監査に必須で含まれます。「Common Criteria」とも呼ばれ、以下の領域を含みます。
| 領域 | 主要内容 |
|---|---|
| 統制環境（CC1） | 組織のセキュリティ文化、ガバナンス、倫理、責任 |
| コミュニケーションおよび情報（CC2） | 内部/外部の利害関係者に対するセキュリティ情報の伝達 |
| リスク評価（CC3） | セキュリティリスクの識別、分析、対応 |
| モニタリング活動（CC4） | 内部統制の有効性の継続的モニタリング |
| 統制活動（CC5） | セキュリティポリシー履行のための統制活動 |
| 論理的/物理的アクセス制御（CC6） | システムアクセス権限管理、認証、物理的セキュリティ |
| システム運用（CC7） | 変更管理、インシデント検知、インシデント対応 |
| 変更管理（CC8） | システム変更の設計、開発、テスト、承認、デプロイ |
| リスク軽減（CC9） | ビジネスパートナーおよびベンダーリスク管理 |
30.6.2.2. 選択的原則
可用性、処理の完全性、機密性、プライバシーは組織のサービス特性に応じて選択的に含めます。
- 可用性: SLA（Service Level Agreement）が重要なサービスに該当します。アップタイム保証、障害対応、災害復旧能力を検証します。
- 処理の完全性: 金融取引、データ処理など正確性が核心的なサービスに該当します。データ処理の完全性と正確性を検証します。
- 機密性: 顧客の機密情報を扱うサービスに該当します。機密情報の分類、保護、廃棄統制を検証します。
- プライバシー: 個人情報を収集/処理するサービスに該当します。AICPAのプライバシー基準に基づく統制を検証します。
30.6.3. Type I vs Type II
SOC 2監査報告書にはType IとType IIの2つのタイプがあります。
| 区分 | Type I | Type II |
|---|---|---|
| 評価時点 | 特定時点（時点検証） | 特定期間（期間検証、通常6〜12ヶ月） |
| 検証内容 | 内部統制の設計適合性 | 内部統制の設計適合性 + 運用有効性 |
| 質問 | 「統制が適切に設計されているか？」 | 「統制が適切に設計されており、期間中に効果的に運用されたか？」 |
| 所要期間 | 2〜4週間（監査期間） | 6〜12ヶ月（観察期間）+ 4〜8週間（監査期間） |
| 信頼レベル | 相対的に低い（時点スナップショット） | 高い（期間中の運用有効性の立証） |
| 費用 | 相対的に低い | 相対的に高い |
| 活用シナリオ | 初期SOC 2導入、迅速な市場参入が必要な場合 | 長期的な顧客信頼の確保、エンタープライズ顧客要求への対応 |
30.6.3.1. 一般的な導入経路
ほとんどの組織は以下の順序でSOC 2を導入します。
- 準備段階: 内部統制の現状診断、ギャップ分析、統制の設計および実装（3〜6ヶ月）
- Type I取得: 統制設計の適合性確認、迅速な市場参入（1〜2ヶ月）
- Type II移行: 統制の運用有効性立証のための観察期間運用（6〜12ヶ月）
- 年次更新: 毎年Type II監査を繰り返し、継続的な統制の有効性を立証
Type Iは「出発点」であり、Type IIが「目標」です。顧客、特にエンタープライズ顧客はType II報告書を要求する場合がほとんどです。
30.6.4. TQSとの比較分析
以下の表は、SOC 2とTQSを核心的な比較軸に基づいて整理したものです。
| 比較軸 | SOC 2 | TQS |
|---|---|---|
| 目的 | サービス組織の内部統制検証（顧客信頼の確保） | コードレベルの技術品質検証（内部品質保証） |
| 検証レベル | サービス運用統制レベル | コード/設定/ビルドレベル |
| 検証対象 | サービス組織のセキュリティ、可用性、完全性、機密性、プライバシー統制 | プロジェクトのソースコード、CI/CDパイプライン、ビルド成果物 |
| アクセス制御検証 | 「アクセス権限が適切に付与/解除されているか」（運用統制） | 「Spring Security RBACがコードに実装されているか」（コード検証） |
| 変更管理検証 | 「変更が承認手順を経てデプロイされているか」（統制手順） | 「GitHub Flowが適用され、CI/CDが正常動作しているか」（自動化検証） |
| モニタリング検証 | 「セキュリティイベントが検知され対応されているか」（運用モニタリング） | 「SLF4Jロギングが適用され、Lighthouseスコアが90点以上か」（コード/パフォーマンス） |
| 成果物 | SOC 2監査報告書（非公開、NDA下で共有） | ソースコード、CI/CDレポート、カバレッジ報告書 |
| 審査方法 | CPA法人の監査人が証跡確認 + インタビュー | 自動化ツール検証 + 技術標準委員会コードレビュー |
| 認証費用 | 高コスト（数千万〜数億ウォン） | 無料（自社内部認証） |
| 更新周期 | 年1回（Type II） | メジャーバージョン単位（CI常時検証） |
| 認証機関 | AICPA公認監査人（CPA法人） | ティエニピア技術標準委員会 |
| 主要顧客 | B2B顧客（SaaSサービス利用企業） | 内部プロジェクトチーム |
30.6.4.1. 統制検証 vs コード検証
SOC 2とTQSの根本的な差異は、検証の視点にあります。
SOC 2はサービス組織が「内部統制を効果的に運用しているか」を検証します。アクセス権限管理、変更管理、インシデント対応などの統制が設計されており、実際に運用されているかを証跡（ログ、承認記録、手順書）を通じて確認します。
TQSはサービスの基盤となるコードが「技術規格を満たしているか」を検証します。Spring Securityの設定、SQLパラメータバインディング、テストカバレッジ、コードコンベンションなどをソースコードとビルド結果から直接確認します。
SOC 2が「統制の運用有効性」に焦点を当てるのに対し、TQSは「コードの技術的整合性」に焦点を当てています。
30.6.4.2. 外部信頼 vs 内部品質
SOC 2の主な目的は、外部顧客にサービスのセキュリティおよび運用レベルに対する信頼を提供することです。SOC 2報告書はB2B営業、エンタープライズ契約、ベンダー評価において核心的な文書として活用されます。
TQSの主な目的は、内部プロジェクトのコード品質を保証することです。TQS認証は組織内部でプロジェクトの技術的成熟度を判断する基準として活用されます。
この差異は、2つの認証が相互排他的ではなく補完的であることを意味します。SOC 2は「外部に向けた信頼」を、TQSは「内部に向けた品質」を担当します。
30.6.5. 適用シナリオ
30.6.5.1. SaaSサービス提供時の組み合わせ戦略
SaaSサービスを提供する組織は、SOC 2とTQSを併用するのが最も効果的です。
| 階層 | 担当認証 | 役割 | 対象 |
|---|---|---|---|
| 外部信頼階層 | SOC 2 | サービス運用統制検証、顧客信頼の確保 | B2B顧客、パートナー |
| 内部品質階層 | TQS | サービスコード品質検証、技術的健全性の保証 | 内部開発チーム |
30.6.5.2. SOC 2統制とTQSの連携
SOC 2のCommon Criteriaのうち技術的統制に該当する項目は、TQSチェックリストと連携します。
| SOC 2統制領域 | SOC 2検証内容 | TQS検証内容 |
|---|---|---|
| 論理的アクセス制御（CC6） | アクセス権限の付与/解除手順、認証メカニズム | Spring Security RBAC実装、SecurityFilterChain設定 |
| 変更管理（CC8） | 変更承認手順、テスト後のデプロイ、ロールバック手順 | GitHub Flow、PRレビュー、CI/CDパイプライン、ビルド成功率 |
| システム運用（CC7） | インシデント検知、ロギング、対応手順 | SLF4Jロギング、標準エラーレスポンス形式、例外処理 |
| 統制活動（CC5） | セキュリティポリシー履行、暗号化適用 | TLS 1.2以上、BCryptハッシュ、SQLパラメータバインディング |
| 可用性 | SLA充足、パフォーマンスモニタリング、障害対応 | Lighthouseパフォーマンス90点以上、Core Web Vitals、バンドル最適化 |
30.6.5.3. 組み合わせ適用時の期待効果
SOC 2とTQSを併用すると、以下のような効果が期待できます。
- 双方向の品質保証: SOC 2でサービス運用の健全性を、TQSでサービスコードの健全性を同時に保証します。
- 監査対応力の強化: SOC 2監査時に変更管理（CC8）領域でTQSのCI/CD自動化検証結果を補助証拠として活用できます。
- 開発-運用品質の連結: TQSが開発段階のコード品質を保証し、SOC 2が運用段階の統制有効性を保証することで、ソフトウェアライフサイクル全体を網羅します。
- 市場信頼 + 技術的自信: SOC 2報告書で顧客に信頼を提供し、TQS認証で内部開発チームにコード品質に対する自信を付与します。
30.6.5.4. 対象組織
SOC 2とTQSの組み合わせは、以下のような組織に最も適しています。
- 海外（特に北米）市場にSaaSサービスを提供する企業
- エンタープライズ顧客を対象にB2Bサービスを提供する企業
- 顧客がベンダーセキュリティ評価（Vendor Security Assessment）を要求する環境の企業
- クラウドベースのサービスを運営しデータセキュリティが核心的な企業
SOC 2は「サービスを安全に運用していることを顧客に証明」し、TQSは「サービスを安全に実装したことを内部で保証」します。2つの認証は外部信頼と内部品質という2つの軸をそれぞれ担当する補完的な関係にあります。