soc2-compliance

SOC 2 コンプライアンス

SaaS 企業向けの SOC 2 Type I および Type II コンプライアンス準備です。Trust Service Criteria の対応付け、コントロールマトリックスの生成、証拠の収集、ギャップ分析、監査準備状況の評価を網羅しています。

目次

• 概要
• Trust Service Criteria
• コントロールマトリックスの生成
• ギャップ分析のワークフロー
• 証拠の収集
• 監査準備チェックリスト
• ベンダー管理
• 継続的なコンプライアンス
• アンチパターン
• ツール
• 参考資料
• 相互参照

---

概要

SOC 2 とは？

SOC 2（System and Organization Controls 2）は、サービス組織が顧客データをどのように管理しているかを評価する、AICPA が策定した監査フレームワークです。顧客情報を保存、処理、または送信するあらゆるテクノロジー企業が対象となり、主に SaaS、クラウドインフラストラクチャ、マネージドサービスプロバイダーに適用されます。

Type I と Type II の違い

項目	Type I	Type II
対象範囲	ある時点でのコントロールの設計	期間を通じたコントロールの設計と運用上の有効性
期間	スナップショット（単一日）	観察期間（3〜12 か月、通常は 6 か月）
証拠	コントロールの説明、ポリシー	コントロールの説明と運用上の証拠（ログ、チケット、スクリーンショット）
費用	20,000〜50,000 ドル（監査費用）	30,000〜100,000 ドル以上（監査費用）
期間	1〜2 か月（監査フェーズ）	6〜12 か月（観察と監査）
最適な対象	初めてのコンプライアンス対応、迅速な市場ニーズ	成熟した組織、エンタープライズ顧客

SOC 2 が必要なのは？

• SaaS 企業：エンタープライズ顧客に販売する企業
• クラウドインフラストラクチャプロバイダー：顧客のワークロードを扱うプロバイダー
• データ処理者：PII、PHI、または財務データを管理する事業者
• マネージドサービスプロバイダー：顧客システムにアクセスするプロバイダー
• あらゆるベンダー：顧客から第三者保証を求められるベンダー

一般的な進め方

Gap Assessment → Remediation → Type I Audit → Observation Period → Type II Audit → Annual Renewal
    (4-8 wk)      (8-16 wk)     (4-6 wk)       (6-12 mo)          (4-6 wk)       (ongoing)

---

Trust Service Criteria

SOC 2 は、5 つの Trust Service Criteria（TSC）カテゴリで構成されています。セキュリティはすべての SOC 2 レポートで必須です。残りの 4 つは任意で、ビジネスニーズに応じて選択します。

セキュリティ（共通基準 CC1〜CC9）— 必須

すべての SOC 2 レポートの基盤です。COSO 2013 の原則に対応しています。

基準	ドメイン	主なコントロール
CC1	コントロール環境	誠実性・倫理、取締役会の監督、組織構造、能力、説明責任
CC2	コミュニケーションと情報	内部・外部コミュニケーション、情報の品質
CC3	リスク評価	リスクの特定、不正リスク、変更影響分析
CC4	モニタリング活動	継続的なモニタリング、不備の評価、是正措置
CC5	コントロール活動	ポリシー・手順、テクノロジーコントロール、ポリシーを通じた導入
CC6	論理的・物理的アクセス	アクセス権の付与、認証、暗号化、物理的制限
CC7	システム運用	脆弱性管理、異常検知、インシデント対応
CC8	変更管理	変更の承認、テスト、承認、緊急変更
CC9	リスク軽減	ベンダー・ビジネスパートナーのリスク管理

可用性（A1）— 任意

基準	対象	主なコントロール
A1.1	キャパシティ管理	インフラストラクチャのスケーリング、リソースのモニタリング、キャパシティ計画
A1.2	復旧オペレーション	バックアップ手順、災害復旧、BCP テスト
A1.3	復旧テスト	DR 訓練、フェイルオーバーテスト、RTO/RPO の検証

次の場合に選択します： 顧客がサービスの稼働時間に依存している場合、SLA がある場合、ダウンタイムがビジネスに直接的な影響を与える場合。

機密性（C1）— 任意

基準	焦点	主な統制
C1.1	識別	データ分類ポリシー、機密データのインベントリ
C1.2	保護	保存時および転送時の暗号化、DLP、アクセス制限
C1.3	廃棄	安全な削除手順、メディアのサニタイズ、保持期間の徹底

次の場合に選択： 営業秘密、専有データ、または契約上機密情報として扱う情報を取り扱う場合。

処理の完全性（PI1）— 任意

基準	焦点	主な統制
PI1.1	正確性	入力検証、処理チェック、出力の検証
PI1.2	完全性	トランザクションの監視、照合、エラー処理
PI1.3	適時性	SLA の監視、処理遅延アラート、バッチジョブの監視
PI1.4	承認	処理承認の統制、職務の分離

次の場合に選択： データの正確性が重要な場合（財務処理、医療記録、分析プラットフォームなど）。

プライバシー（P1-P8）— 任意

基準	焦点	主な統制
P1	通知	プライバシーポリシー、データ収集の通知、目的の制限
P2	選択と同意	オプトイン／オプトアウト、同意管理、設定の追跡
P3	収集	最小限の収集、適法な根拠、目的の明示
P4	利用、保持、廃棄	目的の制限、保持スケジュール、安全な廃棄
P5	アクセス	データ主体からのアクセス要求、訂正の権利
P6	開示と通知	第三者との共有、漏えい通知
P7	品質	データの正確性の検証、訂正の仕組み
P8	監視と徹底	プライバシープログラムの監視、苦情への対応

次の場合に選択： PII を処理し、顧客がプライバシーの保証を期待する場合（GDPR への準拠を補完します）。

---

統制マトリックスの生成

統制マトリックスは、各 TSC 基準を具体的な統制、担当者、証跡、テスト手順に対応付けます。

マトリックスの構成

フィールド	説明
統制 ID	一意の識別子（例：SEC-001、AVL-003）
TSC への対応付け	統制が対応する基準（例：CC6.1、A1.2）
統制の説明	統制の内容
統制の種類	予防、検知、または是正
担当者	責任者／チーム
頻度	継続、毎日、毎週、毎月、四半期ごと、毎年
証跡の種類	スクリーンショット、ログ、ポリシー、設定、チケット
テスト手順	監査人が統制を検証する方法

統制の命名規則

{CATEGORY}-{NUMBER}
SEC-001 through SEC-NNN  → Security
AVL-001 through AVL-NNN  → Availability
CON-001 through CON-NNN  → Confidentiality
PRI-001 through PRI-NNN  → Processing Integrity
PRV-001 through PRV-NNN  → Privacy

ワークフロー

1. ビジネスニーズに基づいて該当する TSC カテゴリーを選択します
2. control_matrix_builder.py を実行してベースラインのマトリックスを生成します
3. 実際の環境に合うように統制をカスタマイズします
4. 担当者と証跡の要件を割り当てます
5. 網羅性を検証します — 選択したすべての TSC 基準に、少なくとも 1 つの統制が必要です

---

ギャップ分析のワークフロー

フェーズ 1：現状評価

1. 既存の統制を文書化する — すべてのセキュリティポリシー、手順、技術的統制を一覧にします
2. TSC に対応付ける — 既存の統制をトラストサービス基準に対応付けます
3. 証跡のサンプルを収集する — 統制が存在し、運用されていることを示す証拠を集めます
4. 統制の担当者に聞き取りを行う — 統制の理解度と実施状況を確認します

フェーズ 2：ギャップの特定

現在の統制を対象に gap_analyzer.py を実行し、以下を特定します。

• 統制の欠落 — 対応する統制がない TSC 基準
• 一部のみ実装 — 統制は存在するものの、証跡または一貫性が不足している
• 設計上のギャップ — 統制は設計されているものの、基準に十分対応していない
• 運用上のギャップ（タイプ II のみ）— 統制は正しく設計されているものの、効果的に運用されていない

フェーズ 3：是正計画

各ギャップについて、次の項目を定義します。

項目	説明
ギャップ ID	参照用識別子
TSC 基準	影響を受ける基準
ギャップの説明	不足している内容、または不十分な内容
是正措置	ギャップを解消するための具体的な手順
担当者	是正を担当する人
優先度	重大／高／中／低
目標日	完了期限
依存関係	先に完了する必要がある他のギャップやプロジェクト

フェーズ 4：タイムラインの計画

優先度	是正の目標期間
重大	2～4 週間
高	4～8 週間
中	8～12 週間
低	12～16 週間

---

証拠の収集

管理カテゴリ別の証拠の種類

管理領域	主な証拠	副次的な証拠
アクセス管理	ユーザーアクセスレビュー、プロビジョニングチケット	ロールマトリックス、アクセスログ
変更管理	変更チケット、承認記録	デプロイログ、テスト結果
インシデント対応	インシデントチケット、事後分析	ランブック、エスカレーション記録
脆弱性管理	スキャンレポート、パッチ記録	是正タイムライン
暗号化	設定画面のスクリーンショット、証明書インベントリ	キーローテーションログ
バックアップと復旧	バックアップログ、DR テスト結果	復旧時間の測定値
監視	アラート設定、ダッシュボードのスクリーンショット	オンコールスケジュール、エスカレーション記録
ポリシー管理	署名済みポリシー、バージョン履歴	トレーニング完了記録
ベンダー管理	ベンダー評価、SOC 2 レポート	契約レビュー、リスク登録簿

自動化の機会

領域	自動化の方法
アクセスレビュー	IAM とチケット管理システムを連携（四半期ごとのレビューを自動で開始）
設定証拠	Infrastructure-as-code のスナップショット、コンプライアンス・アズ・コードツール
脆弱性スキャン	スケジュールに沿ったスキャンとレポートの自動生成
変更管理	Git ベースの監査証跡（コミット、PR、承認）
稼働時間の監視	履歴データを含む SLA ダッシュボードの自動生成
バックアップの検証	成功／失敗を記録する復元テストの自動化

継続的な監視

その時点限りの証拠収集から、継続的なコンプライアンスへ移行します。

1. 証拠収集の自動化 — スケジュールに沿って証拠を取得するスクリプト
2. 管理ダッシュボード — 管理状況をリアルタイムで可視化
3. アラートベースの監視 — 管理がコンプライアンスに適合しなくなった際に通知
4. 証拠リポジトリ — タイムスタンプ付きの証拠を一元保管

---

監査準備チェックリスト

監査前の準備（4～6 週間前）

• すべての管理項目について、説明、担当者、実施頻度が文書化されている
• 観察期間全体（タイプ II）の証拠が収集されている
• 管理マトリックスをレビューし、ギャップを是正している
• ポリシーに署名し、過去 12 か月以内に配布している
• 必要な頻度でアクセスレビューを完了している
• 脆弱性スキャンが最新である（SLA を超えて未パッチの重大／高リスク項目がない）
• 過去 12 か月以内にインシデント対応計画をテストしている
• すべてのサブサービス組織について、ベンダーリスク評価が最新である
• 過去 12 か月以内に DR／BCP をテストし、文書化している
• すべての従業員がセキュリティトレーニングを完了している

準備状況のスコア

スコア	評価	意味
90～100%	監査準備完了	自信を持って進められます
75～89%	軽微なギャップ	監査の予定を立てる前に対処してください
50～74%	重大なギャップ	是正が必要です
< 50%	準備未完了	プログラムの大幅な構築が必要です

よくある監査指摘

指摘	根本原因	防止策
アクセスレビューが不完全	手作業で、リマインダーがない	四半期レビューのトリガーを自動化する
変更承認がない	緊急変更がプロセスを迂回する	事後承認を含む緊急変更手順を定義する
脆弱性スキャンが古い	スキャナーの設定ミス	アラート付きの週次スキャンを自動化する
ポリシーが未確認	追跡の仕組みがない	年次の電子署名ワークフローを導入する
ベンダー評価がない	ベンダー台帳がない	レビュー予定を含むベンダー台帳を管理する

---

ベンダー管理

サードパーティリスク評価

顧客データにアクセス、保存、または処理するすべてのベンダーを評価する必要があります。

1. ベンダー台帳 — すべてのサービスプロバイダーの台帳を管理する
2. リスク分類 — データへのアクセスレベルに応じてベンダーを分類する
3. デューデリジェンス — SOC 2 レポート、セキュリティ質問票、認証を収集する
4. 契約上の保護 — DPA、セキュリティ要件、侵害通知条項を確実に含める
5. 継続的なモニタリング — 年次再評価、ニュースの継続的なモニタリング

ベンダーのリスク階層

階層	データアクセス	評価頻度	要件
重大	顧客データを処理／保存	年次＋継続的なモニタリング	SOC 2 Type II、侵入テスト、セキュリティレビュー
高	顧客環境にアクセス	年次	SOC 2 Type II または同等のもの、質問票
中	間接的なアクセス、サポートツール	年次質問票	セキュリティ認証、質問票
低	データアクセスなし	隔年の質問票	基本的なセキュリティ質問票

サブサービス組織

SOC 2 レポートがサブサービス組織（例：AWS、GCP、Azure）の統制に依拠する場合：

• 包括方式 — レポートにサブサービス組織の統制を含めます（協力が必要です）
• 除外方式 — レポートからサブサービス組織の統制を除外しますが、その組織の SOC 2 レポートを参照します
• ほとんどの企業は除外方式を採用し、補完的なユーザー事業体統制（CUEC）を含めます

---

継続的なコンプライアンス

一時点の対応から継続的な対応へ

項目	一時点の対応	継続的な対応
エビデンスの収集	手作業、監査前	自動化、継続的
統制のモニタリング	定期的なレビュー	リアルタイムのダッシュボード
ドリフトの検知	監査中に発見	アラートベース、即時
是正	事後対応	事前対応
監査準備	4～8週間の突貫作業	常に準備完了

実施手順

1. エビデンス収集を自動化する — cron ジョブ、API 統合、IaC スナップショット
2. 統制ダッシュボードを構築する — 統制のステータスを単一のビューに集約する
3. ドリフトアラートを設定する — 統制がコンプライアンスから逸脱した際に通知する
4. レビューの頻度を確立する — 統制責任者による週次チェックイン、月次の運営委員会
5. エビデンスリポジトリを維持する — 一元管理、タイムスタンプ付き、監査人がアクセス可能

年次再評価サイクル

四半期	活動
Q1	年次リスク評価、ポリシーの更新、ベンダー再評価の開始
Q2	内部統制テスト、指摘事項の是正
Q3	監査前の準備状況レビュー、エビデンスの完全性確認
Q4	外部監査、経営陣の表明、レポートの配布

---

アンチパターン

アンチパターン	失敗する理由	より良いアプローチ
特定時点でのコンプライアンス対応	監査の合間に統制が劣化し、監査中に不備が見つかります	継続的なモニタリングと証跡の自動収集を導入します
証跡の手動収集	時間がかかり、一貫性に欠け、エラーが発生しやすくなります	スクリプト、IaC、コンプライアンスプラットフォームで自動化します
ベンダー評価の不足	監査人からベンダーのデューデリジェンスが不十分だと指摘されます	リスク階層に応じた評価スケジュールを含むベンダー台帳を管理します
ポリシーのコピー＆ペースト	汎用的なポリシーは実際の業務に合致しません	実際の環境やテクノロジースタックに合わせてポリシーを調整します
セキュリティの見せかけ	統制が書類上は存在しても、実際には遵守されていません	統制の運用有効性を検証し、ワークフローに組み込みます
Type I の省略	基盤が整っていないまま Type II に進んでしまいます	観察期間に入る前に、まず Type I で統制設計を検証します
TSC のスコープの過剰設定	セキュリティのみが必要なのに、5 つすべてのカテゴリを含めてしまいます	実際の顧客や事業上の要件に基づいてカテゴリを選択します
監査をプロジェクトとして扱う	報告書の発行後にコンプライアンスが劣化します	日常業務とエンジニアリング文化にコンプライアンスを組み込みます

---

ツール

統制マトリックスビルダー

選択した TSC カテゴリから SOC 2 統制マトリックスを生成します。

# Generate full security matrix in markdown
python scripts/control_matrix_builder.py --categories security --format md

# Generate matrix for multiple categories as JSON
python scripts/control_matrix_builder.py --categories security,availability,confidentiality --format json

# All categories, CSV output
python scripts/control_matrix_builder.py --categories security,availability,confidentiality,processing-integrity,privacy --format csv

証跡トラッカー

統制ごとの証跡収集状況を追跡します。

# Check evidence status from a control matrix
python scripts/evidence_tracker.py --matrix controls.json --status

# JSON output for integration
python scripts/evidence_tracker.py --matrix controls.json --status --json

ギャップ分析ツール

現在の統制を SOC 2 の要件と照合して分析し、ギャップを特定します。

# Type I gap analysis
python scripts/gap_analyzer.py --controls current_controls.json --type type1

# Type II gap analysis (includes operating effectiveness)
python scripts/gap_analyzer.py --controls current_controls.json --type type2 --json

---

参考資料

• Trust Service Criteria Reference — 5 つすべての TSC カテゴリとサブ基準、統制目標、証跡の例
• Evidence Collection Guide — 統制ごとの証跡の種類、自動化ツール、文書化要件
• Type I vs Type II Comparison — 詳細な比較、タイムライン、コスト分析、アップグレードパス

---

関連項目

• gdpr-dsgvo-expert — SOC 2 のプライバシー基準は GDPR の要件と大きく重複します。EU の個人データを処理する場合は併用してください
• information-security-manager-iso27001 — ISO 27001 Annex A の統制は SOC 2 のセキュリティ基準と密接に対応しています。両方に取り組む組織は証跡を共有できます
• isms-audit-expert — 監査手法と指摘事項の管理パターンは、SOC 2 監査の準備にそのまま適用できます