soc2-compliance-expert

SOC 2 コンプライアンスエキスパート

すべての Trust Services Criteria（TSC）を対象とする SOC 2 Type I および Type II のコンプライアンス管理、インフラストラクチャのセキュリティ検証、証拠収集、監査準備をエンドツーエンドで支援します。

---

SOC 2 の概要

Type I と Type II の比較

項目	Type I	Type II
対象範囲	ある時点における統制の設計	一定期間にわたる設計および運用の有効性
期間	単一の日付（スナップショット）	観察期間（3～12 か月、通常は 6～12 か月）
費用	20,000～60,000 ドル（初回監査）	40,000～150,000 ドル（初回監査）
期間の目安	1～3 か月	6～15 か月（観察期間を含む）
顧客の選好	立ち上げ初期の企業には許容される	エンタープライズ顧客が必須とする

まず Type I で統制の設計を検証し、その後 6 か月以内に Type II へ移行します。

Trust Services Criteria の概要

カテゴリ	焦点	統制
CC1-CC5	共通基準（COSO ベース）	統制環境、コミュニケーション、リスク、モニタリング、統制活動
CC6	論理的および物理的アクセス	認証、認可、物理的セキュリティ、暗号化
CC7	システム運用	脆弱性管理、モニタリング、インシデント対応、BCP
CC8	変更管理	承認、テスト、デプロイの統制
CC9	リスク軽減	ベンダー管理、事業中断、リスク移転
A1	可用性	キャパシティプランニング、DR、復旧テスト
PI1	処理の完全性	データ検証、エラー処理、照合
C1	機密性	分類、暗号化、廃棄
P1	プライバシー	通知、同意、データ主体の権利、保持

カテゴリごとの詳細な統制要件については、REFERENCE.md を参照してください。

---

まず確認すること

準備状況の評価を実施する前に、以下の入力項目を確認してください。項目が未指定または曖昧で、評価結果が変わる場合は質問してください。結果に影響しない場合は、妥当なデフォルト値を使用し、使用した値を明記してください。

• レポートタイプ： Type I（ある時点における設計）と Type II（一定期間にわたる運用の有効性）のどちらか（観察期間の要件とスケジュールを決定します）。
• TSC の対象範囲： 必須の Security に加えて、どの基準を対象にするか（Availability、Processing Integrity、Confidentiality、Privacy）（必要な統制と証拠を決定します）。
• サブサービス組織： カーブアウト方式か包括方式か（対象範囲とシステム記述に影響します）。

リクエストに最も影響する 2～3 項目について質問し、すべての項目を一度に尋ねないでください。ユーザーがすぐに結果を求める場合は、結果を提示し、冒頭に前提条件を記載してください。

準備状況評価のワークフロー

エージェントは、ギャップ分析から監査完了まで、組織の SOC 2 準備を支援します。

ワークフロー：フェーズ 1 -- ギャップ分析（第 1～4 週）

1. 対象範囲を定義する -- 対象に含める TSC カテゴリ（Security は必須）を決定し、システム境界を定義し、サブサービス組織（カーブアウト方式か包括方式か）を特定し、主要なサービスコミットメントを文書化します。
2. 現状を評価する -- 既存のポリシーと手順を一覧化し、現在の統制を TSC 要件に対応付け、プロセスの責任者と統制の運用担当者にヒアリングします。
3. scripts/soc2_readiness_checker.py を使用して、自動ギャップ分析を実行する。
4. ギャップを文書化する -- 不足している統制、証拠が不足している統制、効果的に運用されていない統制を記録します。
5. リスクレベルと修正に必要な作業量に基づいて、ギャップに優先順位を付けます。
6. 検証チェックポイント： ギャップ分析で対象範囲内のすべての TSC カテゴリが網羅されていること。各ギャップに重大度が設定され、修正担当者が割り当てられていること。

ワークフロー：フェーズ 2 -- 是正（5～16 週）

1. ポリシーを策定／更新する -- 情報セキュリティポリシー、管理策ドメインごとの補足手順、ポリシーのレビューおよび承認ワークフロー。
2. 技術的な管理策を実装する -- IdP を設定して SSO/MFA を適用し、エンドポイントセキュリティ（MDM、EDR、ディスク暗号化）を導入し、SIEM によるログ記録と監視を実装し、バックアップと DR を設定し、クラウドインフラを強化します。
3. プロセスを確立する -- アクセスレビュー手順、変更管理ワークフロー、インシデント対応手順、ベンダー管理プログラム、セキュリティ意識向上トレーニング。
4. 証拠収集を設定する -- 自動収集を設定し、リポジトリ構成を確立し、TSC カテゴリごとの更新頻度を定義します。
5. 検証チェックポイント： 特定されたすべてのギャップが是正済みであること。技術的な管理策が scripts/soc2_infrastructure_auditor.py によって検証済みであること。証拠収集によって成果物が生成されていること。

ワークフロー：フェーズ 3 -- 監査前準備（17～20 週）

1. 内部準備状況評価を実施する -- 対象範囲内のすべての TSC を対象に模擬監査を実施し、証拠の完全性と品質を検証し、インフラ監査ツールを実行して技術的な検証を行います。
2. 監査前の指摘事項を是正する -- 残っているギャップに対処し、証拠を強化します。
3. CPA 事務所を選定し、契約する -- 対象範囲、スケジュール、料金を交渉し、キックオフを予定し、システム記述書のドラフトを準備します。
4. 検証チェックポイント： 重大なギャップなしで模擬監査に合格していること。システム記述書がレビュー済みであること。監査人と契約済みであること。

ワークフロー：フェーズ 4 -- 監査の実施

1. タイプ I 監査（該当する場合） -- 監査人が管理策の設計をレビューし、経営陣が表明を提示します。タイプ II の前に指摘事項に対処します。
2. タイプ II の観察期間（3～12 か月） -- 管理策を一貫して運用し、証拠を継続的に収集し、四半期ごとに自己評価を実施し、監査人と定期的に確認を行います。
3. 実地調査（2～4 週間） -- 監査人がサンプルを選定し、管理策をテストし、担当者に聞き取りを行います。報告書ドラフトのレビューと最終報告書の発行を行います。
4. 検証チェックポイント： 無限定意見を受領していること。指摘事項がある場合は、経営陣の回答と是正計画があること。

---

証拠収集フレームワーク

TSC カテゴリ別の証拠

TSC	証拠の種類	収集方法	更新頻度
CC1	行動規範の確認記録	HR システムからのエクスポート	年次
CC2	セキュリティ意識向上トレーニングの記録	LMS からのエクスポート	継続的
CC3	リスク評価レポート、リスク台帳	GRC プラットフォーム	年次／四半期ごと
CC4	ペネトレーションテストレポート、脆弱性スキャン	サードパーティ／スキャナー	年次／月次
CC5	バージョン履歴付きポリシー文書	ポリシー管理	年次レビュー
CC6	アクセスレビュー、MFA 登録、オフボーディング	IAM/IdP/HRIS	四半期ごと／イベントごと
CC7	脆弱性の是正、インシデント記録	チケット管理／ITSM	継続的
CC8	承認付き変更チケット、コードレビュー	ITSM/Git	変更ごと
CC9	ベンダーリスク評価、ベンダーの SOC 2 レポート	GRC プラットフォーム	年次
A1	稼働時間レポート、DR テスト、バックアップログ	監視／バックアップ	月次／半年ごと
PI1	データ検証／照合レポート	アプリケーションログ	プロセスごと
C1	データ分類インベントリ、暗号化設定	手動／自動	年次／四半期ごと
P1	PIA、DSR 対応状況の追跡記録	プライバシーツール	イベントごと

例：証拠収集コマンド

# Generate evidence checklist for all TSC categories
python scripts/evidence_collector.py --generate-checklist --categories all

# Track evidence status
python scripts/evidence_collector.py --status evidence-tracker.json

# Update specific evidence item
python scripts/evidence_collector.py --update evidence-tracker.json \
  --item CC6.1-MFA --status collected

# Generate readiness dashboard
python scripts/evidence_collector.py --dashboard evidence-tracker.json

# Export for auditor review
python scripts/evidence_collector.py --export evidence-tracker.json --format json

自動化の戦略

GRC プラットフォーム： Vanta、Drata、Secureframe、Laika、AuditBoard -- API 連携による証拠収集の自動化、管理策の継続的な監視、監査人との共同作業ポータル。

証拠としてのインフラ： クラウド設定のスナップショット（AWS Config、Azure Policy、GCP Org Policies）、設定の証拠としての Terraform の状態、変更管理の証拠としての Git 履歴、デプロイ管理の証拠としての CI/CD パイプラインログ。

---

インフラセキュリティの検証

エージェントは、SOC 2 の要件に照らしてインフラ設定を検証します。

クイックリファレンス：インフラストラクチャのチェック

ドメイン	主なチェック項目	SOC 2 との対応
クラウド（AWS/Azure/GCP）	暗号化、IAM、ログ記録、ネットワーク、バックアップ、シークレット	CC6、CC7、A1、C1
DNS	SPF、DKIM、DMARC、DNSSEC、CAA	CC6.6、CC2.2
TLS/SSL	TLS 1.2 以降、AEAD 暗号、HSTS、自動更新	CC6.7
エンドポイント	MDM、ディスク暗号化、EDR、パッチ適用、画面ロック	CC6.1、CC6.8、CC7.1
ネットワーク	セグメンテーション、WAF、DDoS、VPN/ZTNA、送信トラフィックのフィルタリング	CC6.6、A1.1
コンテナー	イメージスキャン、最小限のベースイメージ、特権モードの禁止、RBAC	CC6.1、CC7.1
CI/CD	署名付きコミット、ブランチ保護、SAST/DAST、SBOM	CC7.1、CC8.1
シークレット	Vault での保存、ローテーションポリシー、Git スキャン	CC6.1

プロバイダーごとの詳細な管理策マッピングについては、REFERENCE.md を参照してください。

例：インフラストラクチャ監査コマンド

# Full infrastructure audit
python scripts/soc2_infrastructure_auditor.py --config infra-config.json

# Audit specific domains only
python scripts/soc2_infrastructure_auditor.py --config infra-config.json \
  --domains dns tls cloud

# JSON output with severity ratings
python scripts/soc2_infrastructure_auditor.py --config infra-config.json --format json

# Generate sample configuration template
python scripts/soc2_infrastructure_auditor.py --generate-template

---

監査のタイムライン

一般的なタイムライン（初回の SOC 2）

フェーズ	期間	作業内容
スコープの設定	2～4 週間	TSC、システムの境界、監査人の選定を定義
ギャップ分析	2～4 週間	現在の管理策を評価し、ギャップを特定
是正措置	8～16 週間	不足している管理策、ポリシー、手順を導入
Type I 監査	2～4 週間	特定時点における管理策の設計評価
Type II の観察期間	3～12 か月	管理策を運用し、証拠を継続的に収集
Type II の監査作業	2～4 週間	監査人によるテスト、証拠の確認、インタビュー
報告書の発行	2～4 週間	ドラフトの確認、経営陣の回答、最終報告書

年次更新

• 観察期間終了の3か月前に更新計画を開始します
• 監査期間の合間も継続的なコンプライアンスを維持します
• 新たな観察期間が始まる前に、前年度の指摘事項に対処します
• 報告書間の空白期間を補うブリッジレターを利用できます

---

インシデント対応要件

IRP の構成

1. 準備 -- IR チームの定義、連絡チャネルの確立、一般的なインシデント向けランブックの整備、法務／PR 担当者との顧問契約。
2. 検知と分析 -- 監視／アラート対応範囲、重大度の分類（SEV1～SEV4）、トリアージ手順、エスカレーションマトリックス。
3. 封じ込め、根絶、復旧 -- 影響を受けたシステムの隔離、証拠の保全、根本原因の特定、復元と検証。
4. インシデント後 -- 5営業日以内に責任追及をしない事後検証を実施し、教訓を記録し、管理策を改善し、通知要否を評価します（MTTD、MTTR、MTTC を追跡）。

重大度レベルの定義と侵害通知のタイムラインについては、REFERENCE.md を参照してください。

---

ツール

SOC 2 対応状況チェッカー

# Full readiness assessment
python scripts/soc2_readiness_checker.py --config org-controls.json

# JSON output for programmatic use
python scripts/soc2_readiness_checker.py --config org-controls.json --format json

# Check specific TSC categories
python scripts/soc2_readiness_checker.py --config org-controls.json \
  --categories security availability

# Include cloud provider control mapping
python scripts/soc2_readiness_checker.py --config org-controls.json --cloud-mapping

証拠収集ツール

# Generate checklist and track status
python scripts/evidence_collector.py --generate-checklist --categories all
python scripts/evidence_collector.py --status evidence-tracker.json
python scripts/evidence_collector.py --dashboard evidence-tracker.json

インフラストラクチャ監査ツール

# Validate infrastructure against SOC 2 requirements
python scripts/soc2_infrastructure_auditor.py --config infra-config.json
python scripts/soc2_infrastructure_auditor.py --config infra-config.json --format json

---

避けるべきパターン

管理策が稼働する前に観察期間を開始する

誤り： 管理策の構築中に Type II の観察期間を開始します。 理由： 営業案件によって監査日が決まり、期間を開始することが進捗のように感じられるためです。 代わりに： 対象範囲内のすべての管理策を初日から運用する必要があります。観察期間中のギャップは、報告書の指摘事項になります。soc2_readiness_checker.py を実行し、期間の開始前に重大なギャップを解消してください。

監査作業の直前に証拠を集める

誤り： 監査人の到着前の数週間に、スクリーンショット、チケット、ログを収集します。 理由： 証拠は、求められるまで後回しにできる書類仕事のように感じられるためです。 代わりに： 証明できない管理策は、存在しない管理策として扱われます。観察期間の初日から収集し、各項目を evidence_collector.py で追跡してください。

すべての Trust Services Criteria カテゴリを対象範囲に含める

誤り： Security、Availability、Processing Integrity、Confidentiality、Privacy のすべてを対象範囲に含めます。 発生する理由： 対象範囲の広いレポートのほうが、購入者に強い印象を与えるように見えるためです。 代わりに： Security は必須です。他のカテゴリは、顧客から求められた場合にのみ追加します。カテゴリを追加するたびに、管理策、証拠、監査コストが増加します。

さらに7項目については、references/audit-preparation-playbook.md（避けるべきよくある間違い）をご覧ください。

参考資料

ドキュメント	説明
REFERENCE.md	詳細な TSC 管理策、インフラストラクチャチェック、アクセス制御の仕様、ベンダー管理、トレーニング、IRP、BC/DR
Trust Services Criteria Guide	管理目標と監査質問を網羅した TSC 完全リファレンス
Infrastructure Security Controls	クラウド、DNS、TLS、エンドポイント、コンテナ、CI/CD のセキュリティ構成
Audit Preparation Playbook	タイムライン、チェックリスト、コスト見積もりを含む、監査準備のエンドツーエンドガイド

---

トラブルシューティング

問題	考えられる原因	解決策
準備状況チェッカーのスコアがすべてのカテゴリで 0% になる	Controls JSON に config_key の値がないか、すべて false に設定されている	入力 JSON で各 TSC 管理策が、正しい config_key の下にブール値として対応付けられていることを確認してください。期待される構造を確認するには、--generate-sample > sample-config.json を実行してください。
インフラストラクチャ監査ツールがすべてのチェックを「fail」と報告する	インフラストラクチャ設定 JSON が空か、キー名が正しくない	有効なテンプレートを生成するには、--generate-template を実行してください。DNS、TLS、クラウド、エンドポイントなどのセクションに、実際のインフラストラクチャの状態を入力してください。
証拠収集チェックリストにカテゴリがない	--categories フラグによって出力がフィルタリングされている	完全なチェックリストを生成するには、--categories all を使用してください。利用可能なカテゴリ：security、availability、processing_integrity、confidentiality、privacy。
証拠トラッカーのステータスが更新されない	トラッカーファイルのパスが正しくないか、ファイルに書き込めない	--status または --update に指定したパスが、既存のトラッカー JSON ファイルを指していることを確認してください。ファイルのアクセス権限も確認してください。
準備状況レポートにクラウドのマッピングが表示されない	--cloud-mapping フラグが含まれていない	AWS/Azure/GCP の管理策マッピングを出力に含めるには、準備状況チェッカーのコマンドに --cloud-mapping を追加してください。
Type II の観察期間が監査人の求める期間より短い	観察期間が3か月未満	ほとんどの CPA 事務所では、Type II に最低3か月の観察期間を求めています。6～12か月の期間のほうが、より信頼性が高まります。スコープ設定の段階で観察期間を計画してください。
監査人から、トラッカーにない証拠を求められる	証拠カタログが、選択したスコープのすべての TSC 下位基準を網羅していない	自動生成されたチェックリストに、監査人固有の証拠要求を追加してください。CPA 事務所によっては、標準的な TSC 証拠項目以外にも要件がある場合があります。

---

成功基準

• 適用されるTSCカテゴリをすべて選択し、システム境界を文書化し、サブサービス組織を特定（カーブアウト方式か包括方式か）したうえで、SOC 2の対象範囲を定義していること
• ギャップ分析を完了し、特定されたすべてのギャップに重大度、是正担当者、目標完了日を割り当てていること
• CPA事務所への依頼前に、対象範囲内のすべてのTSCカテゴリで80％以上の準備状況スコアを達成し、Type II監査の実地調査開始前に95％以上を目指していること
• 一元化されたリポジトリ、TSCカテゴリごとに定められた更新頻度、可能な場合の自動収集を備えたエビデンス収集フレームワークが稼働していること
• DNS、TLS、クラウド、エンドポイント、アクセス制御の各領域で、重大または高重大度の指摘事項なくインフラストラクチャ監査に合格すること
• 少なくとも6か月のType II観察期間を設け、統制を継続的に運用し、四半期ごとに自己評価を実施し、重大な統制不備がないこと
• 指摘事項に対する経営陣の回答と文書化された是正計画を含む、無限定のSOC 2 Type II意見を受領すること

---

対象範囲と制限事項

対象範囲：

• すべてのTSCカテゴリ（CC1～CC9、A1、PI1、C1、P1）を対象とするSOC 2 Type IおよびType IIの準備状況評価
• インフラストラクチャのセキュリティ検証（DNS、TLS、クラウド、エンドポイント、ネットワーク、コンテナ、CI/CD、シークレット）
• エビデンス収集フレームワークの生成と追跡
• 重大度を評価した指摘事項と是正ガイダンスを含むギャップ分析
• 監査スケジュールの策定とCPA事務所への依頼準備
• インシデント対応計画の構成と要件
• 継続的なコンプライアンスプログラムの設計

対象外：

• CPA事務所による監査の実施（これらのツールは監査の準備を支援します。実際のType I／II報告書には独立したCPA事務所が必要です）
• SOC 1（ICFR）評価（SOC 1は財務報告に関する統制を対象としており、セキュリティ、可用性、プライバシーは対象外です）
• SOC 3報告書の作成（SOC 3はSOC 2監査完了後に作成される、一般公開向けの要約です）
• ペネトレーションテストの実施（infrastructure-compliance-auditorを使用するか、第三者のペネトレーションテスト事業者に依頼してください）
• GRCプラットフォームの選定または導入（このスキルはVanta、Drata、Secureframeなどと互換性がありますが、それらを導入するものではありません）
• SOC 2報告書に関する顧客との契約要件についての法的助言
• 物理セキュリティ評価（インフラストラクチャ監査ツールは論理的統制を対象とします。物理データセンターの監査には現地評価が必要です）

---

連携ポイント

スキル	連携内容
infrastructure-compliance-auditor	クラウド、DNS、TLS、エンドポイント、アクセス制御、CI/CDにわたるVantaレベルのインフラストラクチャチェックを提供し、SOC 2 TSC要件に直接対応付けます
nist-csf-specialist	NIST CSFの機能はSOC 2 TSCカテゴリに対応します。両方に取り組む組織は、コントロールマッパーを使用して統合コントロールマトリクスを作成できます
information-security-manager-iso27001	ISO 27001附属書Aの統制は、多くのSOC 2要件を満たすマネジメントシステムの基盤となります。エビデンスを共有することで監査負担を軽減できます
pci-dss-specialist	PCI DSS要件はSOC 2のCC6（アクセス）、CC7（運用）、CC8（変更管理）と重複します。決済処理を行う組織は統制を共有できます
gdpr-dsgvo-expert	GDPR要件はSOC 2プライバシー（P1）基準に対応します。EUの個人データを処理する組織は、共通のプライバシー統制を活用できます
nis2-directive-specialist	NIS2の最低限のセキュリティ対策はSOC 2セキュリティ基準と重複します。EUの事業体は、共通するインシデント対応、アクセス制御、暗号化の統制を対応付けることができます

---

ツールリファレンス

soc2_readiness_checker.py

SOC 2 Trust Services Criteria に照らして組織の統制を評価し、カテゴリごとにスコアを算出します。

フラグ	必須	説明
--config	はい（または --generate-sample）	各 TSC 統制のブール値を含む、組織の統制 JSON ファイルへのパス
--format	いいえ	出力形式：構造化出力には json を指定します。人間が読みやすいテキスト形式にする場合は省略します
--categories	いいえ	評価する TSC カテゴリをスペース区切りで指定します（例：security availability）。すべてのカテゴリを対象とする場合は省略します。
--cloud-mapping	いいえ	クラウドプロバイダー（AWS/Azure/GCP）の統制マッピングを出力に含めます
--generate-sample	いいえ	サンプルの統制 JSON テンプレートを生成します（> sample-config.json でファイルに出力します）

evidence_collector.py

証拠収集チェックリストを生成し、証拠収集の進捗状況を追跡します。

フラグ	必須	説明
--generate-checklist	いいえ	指定したカテゴリの証拠収集チェックリストを生成します
--categories	いいえ	TSC カテゴリをスペース区切りで指定します：security、availability、processing_integrity、confidentiality、privacy、または all
--status	いいえ	収集状況を表示する証拠トラッカー JSON ファイルへのパス
--update	いいえ	更新する証拠トラッカー JSON ファイルへのパス（--item および --status と併用します）
--item	いいえ	更新する証拠項目の識別子（例：CC6.1-MFA）
--dashboard	いいえ	準備状況ダッシュボードを生成する証拠トラッカー JSON ファイルへのパス
--export	いいえ	エクスポートする証拠トラッカー JSON ファイルへのパス
--format	いいえ	エクスポート形式：構造化出力には json を指定します

soc2_infrastructure_auditor.py

重大度を評価した検出結果を提示し、SOC 2 の要件に照らしてインフラストラクチャ設定を監査します。

フラグ	必須	説明
--config	はい（または --generate-template）	DNS、TLS、クラウド、エンドポイントなどのドメイン設定を含む、インフラストラクチャ設定 JSON ファイルへのパス
--format	いいえ	出力形式：重大度評価を含む構造化された検出結果には json を指定します。人間が読みやすいテキスト形式にする場合は省略します
--domains	いいえ	監査するインフラストラクチャのドメインをスペース区切りで指定します（例：dns tls cloud）。すべてのドメインを対象とする場合は省略します。
--generate-template	いいえ	インフラストラクチャ設定のサンプルテンプレートを生成します（> infra-config.json でファイルに出力します）