soc2-prep

SOC 2 準備

使用するタイミング

創業者が SOC 2 認証の準備をしているとき、顧客または見込み顧客から SOC 2 レポートを求められたとき、取締役会や予算の議論に向けてセキュリティリスクを定量化する必要があるとき、事業価値を考慮した順序でコンプライアンスロードマップを作成したいとき、またはセキュリティ体制全体を評価する必要があるときに有効にしてください。また、ユーザーが「SOC 2」「コンプライアンス監査」「トラストサービス規準」「セキュリティ予算」「この商談を成立させるには SOC 2 が必要」「CISO」と言及した場合も有効にしてください。

必要なコンテキスト

• startup-context から： 製品の種類、技術スタック、クラウドインフラプロバイダー、チームの規模、現在のセキュリティ対策、ビジネスモデル、顧客セグメント（エンタープライズ顧客は SOC 2 を求めることがよくあります）。
• ユーザーから： 対象となるトラストサービス規準、文書とポリシーの現在の状況、既存のセキュリティツール（SSO、MDM、監視）、Type I と Type II のどちらを目指すか、希望するスケジュール、予算上の制約、監査人を選定済みかどうか、上位 3 社の見込み顧客が求めるコンプライアンス要件。

ワークフロー

1. 事業上の根拠を定量化する — ALE（年間損失予測＝単一損失予測 x 年間発生率）を用いて、セキュリティ投資を金額で示します。取締役会向けの言葉に置き換えます：「このリスクによる年間予想損失は $X です。軽減にかかる費用は $Y です。」セキュリティは単なるチェック項目ではなく、営業を後押しするものです。
2. スコープの定義 — 対象となるトラストサービス規準を決定します。セキュリティ（共通規準）は必須です。可用性、処理の完全性、機密性、プライバシーは任意です。顧客の要件と製品の種類に基づいてスコープを定めます。
3. 現状評価 — 既存のポリシー、管理策、ツールを棚卸しします。存在するもの、一部しか存在しないもの、まったく存在しないものを特定します。以下の危険信号リストを確認します。
4. ギャップ分析 — 現状を適用される各 TSC 規準に照らし合わせます。準拠、一部準拠、非準拠の領域を示すギャップマトリクスを作成します。
5. コンプライアンスロードマップ — 事業価値を考慮した順序で進めます：SOC 2 Type I（3〜6 か月）、次に SOC 2 Type II（開始から 12 か月後）、その後は顧客の需要に応じて ISO 27001 または HIPAA。基本的なセキュリティ衛生が整う前に認証取得を目指してはいけません。
6. ポリシーの作成 — 会社の規模に合わせて必要なポリシーを作成します。創業初期のスタートアップに必要なのは、実用的な 2〜5 ページのポリシーであり、50 ページのエンタープライズ向け文書ではありません。
7. 管理策の実装計画 — 各ギャップについて、管理策、担当者、ツール、スケジュールを定義します。
8. 証拠収集のガイダンス — 管理策ごとに監査人が求めるものと、それを体系的に収集する方法を定義します。
9. 準備状況のレビュー — 監査人に依頼する前に模擬評価を実施します。

出力形式

# Security & Compliance Assessment: [Company Name]

## Risk Quantification — top risks with ALE, mitigation cost, expected value
## Gap Analysis Matrix — TSC criterion, requirement, current state, gap, priority, remediation
## Compliance Roadmap — sequenced timeline: SOC 2 Type I > Type II > ISO 27001/HIPAA
## Policy Documents — generated as needed, each with purpose/scope/roles/statements/procedures
## Implementation Timeline — phased checklist with milestones
## Evidence Collection Checklist — per-control artifacts, storage location, refresh cadence
## Security Metrics Dashboard — table of key metrics with current values and targets

フレームワークとベストプラクティス

リスクの定量化（CISO アプローチ）

技術的なリスクを、収益損失、規制上の罰金、評判への損害といった事業上の影響に置き換えます。優先順位付けには ALE を使用します。

計算式： ALE = SLE x ARO（単一損失予測 x 年間発生率）

取締役会向けの説明：「年間発生確率 40% の 200 万ドルの侵害を防ぐ 20 万ドルのセキュリティプログラムは、80 万ドルの期待価値をもたらします。このプログラムの費用対効果は 4 倍です。」

セキュリティ支出は、間接費ではなくリスク移転のコストとして位置づけます。

セキュリティ指標

カテゴリ	指標	目標
リスク	ALE カバー率（軽減済み / 合計）	> 80%
検知	平均検知時間（MTTD）	< 24 時間
対応	平均対応時間（MTTR）	< 4 時間
コンプライアンス	監査に合格した管理策	> 95%
セキュリティ衛生	SLA 内に適用された重大なパッチ	> 99%
アクセス	四半期ごとにレビューされた特権アカウント	100%
ベンダー	年次評価を受けた Tier 1 ベンダー	100%
トレーニング	フィッシングシミュレーションのクリック率	< 5%

信頼性サービス規準の概要

セキュリティ（共通規準――常に対象）： CC1-CC2（統制環境、コミュニケーション）、CC3（リスク評価）、CC4-CC5（モニタリング、統制活動）、CC6（論理的／物理的アクセス、暗号化）、CC7-CC8（システム運用、脆弱性管理、インシデント対応、変更管理）、CC9（ベンダー管理、事業継続）。

任意： 可用性（A1）、処理の完全性（PI1）、機密性（C1）、プライバシー（P1-P8）。

必須ポリシー（最低10項目）

情報セキュリティ、アクセス制御（MFA、最小権限、アクセスレビュー）、変更管理（コードレビュー、ロールバック）、インシデント対応（検出から事後検証まで）、リスク評価（年次、リスク台帳を含む）、ベンダー管理、データ分類、事業継続／災害復旧（RTO／RPO、バックアップテスト）、利用規定、人事セキュリティ（身元調査、入社／退職時の手続き）。

ベンダーセキュリティ評価のティア

ティア	データアクセス	評価レベル
ティア1	PII／PHIへのアクセス	年次の包括的評価
ティア2	業務データ	質問票＋レビュー
ティア3	機密データなし	自己証明

積極的に指摘すべき警告サイン

• リスク分析ではなくベンチマークを根拠にセキュリティ予算を正当化している
• 基本的な衛生対策（パッチ適用、MFA、バックアップ）より先に認証取得を目指している
• 文書化された資産インベントリがない――把握していない資産は保護できません
• IR計画はあるが一度もテストされていない。セキュリティの報告先が経営幹部ではなくIT部門になっている
• セキュリティ質問票の処理が30日を超えて滞留している――エンタープライズ案件を気づかぬうちに失っている
• 機密データへのアクセス権を持つベンダーが評価を受けていない

スタートアップ向けガイダンス

Type IとType II： Type Iでは、ある時点での統制の設計を評価します（3～6か月。最初のエンタープライズ案件の成約に適しています）。Type IIでは、3～12か月にわたる統制の運用状況を評価します（高度な要件を持つ購入者が求めるもので、全体で12か月を計画してください）。すぐにType Iを開始し、統制を整えたらType IIの観察期間を開始します。

段階に応じた適正規模： シード（5～15人）：基礎的な統制、自動化を重視、簡潔なポリシー、パートタイムの担当者1人。シリーズA（15～50人）：専任のコンプライアンス担当者または非常勤CISO、正式なアクセスレビュー。シリーズB以降（50人以上）：フルタイムのセキュリティチーム、内部監査、GRCプラットフォーム。

費用対効果の高いツール： コンプライアンス自動化（Vanta、Drata、Secureframe――手作業を大幅に削減）、SSO（Google WorkspaceまたはOkta）、MDM（KandjiまたはJamf）、モニタリング（Datadog、PagerDuty）、脆弱性スキャン（Dependabot、Snyk、Trivy）。

タイムラインのテンプレート

• Type Iの短期計画（3か月）： 1か月目：対象範囲／ギャップ／ポリシー、2か月目：導入、3か月目：準備状況の確認＋監査。
• Type Iの標準計画（6か月）： 1～2か月目：対象範囲／ポリシー、3～4か月目：導入、5か月目：証拠の収集、6か月目：監査。
• Type II（12か月）： 1～6か月目：Type Iを完了、6～12か月目：観察＋証拠の収集、12か月目：監査。

出力の信頼度タグ付け

意思決定者に提示する前に、すべての調査結果にタグを付けます。確認済み（証拠と照合して確認済み）、中程度（報告されているが独立して検証されていない）、仮定（推論に基づくもので、検証が必要）。

関連スキル

• privacy-policy — SOC 2のプライバシー規準（P1-P8）は、プライバシーポリシーのコミットメントと直接対応します。整合性を確保してください。
• security-review — security-reviewの技術的なセキュリティ統制は、SOC 2の共通規準（CC6、CC7、CC8）に対応します。ギャップ分析に調査結果を活用してください。

例

例1：SOC 2が契約締結の条件となっているエンタープライズ案件

ユーザー：「見込み顧客から、20万ドルの契約を締結する前にSOC 2を取得するよう求められています。何も準備できていません。」

良い出力例：

**ビジネス上の根拠：**この20万ドルの案件を獲得できるなら、3万〜5万ドルのコンプライアンス投資を正当化できます。現在の段階では、SOC 2がないために見送られるすべてのエンタープライズ案件に機会損失が生じます。

領域	状況	主な不足事項
アクセス制御	部分的	AWSルートアカウントでMFAが強制されていない、SSOがない、正式なレビューがない
変更管理	部分的	GitHubのPRは利用しているが、文書化されたポリシーがない
インシデント対応	未対応	文書化された計画がなく、オンコール体制もない
リスク評価	未対応	正式なリスク評価を実施していない

**推奨アプローチ：**3か月でType Iを取得し、その後、Type IIの観察期間を開始します。 直ちに実施すること：（1）コンプライアンス自動化サービスに登録します。（2）すべての場所でMFAを強制します。（3）スタートアップの監査経験がある監査人を選定します。 **見込み顧客への暫定回答：**セキュリティ質問票への回答、SOC 2 Type Iの取得予定時期、およびセキュリティ条項を付記した相互NDAを共有します。

例2：セキュリティ態勢の評価

ユーザー：「すでにOktaでSSOを利用し、コードレビューも行っています。SOC 2に対してどの程度準備できていますか？」

良い出力例：

ギャップ分析の概要：準備度55％

**準拠：**CC6.1 Okta SSOとMFA、CC8.1 PRによるコードレビュー。 **部分的：**CC6.2 四半期ごとのアクセスレビューが文書化されていない、CC7.2 IRPが一度もテストされていない、CC6.3 正式なオフボーディングチェックリストがない。 **未対応：**CC3.1 年次リスク評価がない、CC2.1 セキュリティ研修がない、CC9.2 ベンダー管理がない、CC4.1 統制の監視がない。必要なポリシー10件すべての策定が必要です。

---

**免責事項：**このスキルは、計画を目的としたSOC 2準備のガイダンスを提供するものです。法務、監査、または専門的なコンプライアンスに関する助言を構成するものではありません。SOC 2レポートを発行できるのは、ライセンスを保有するCPA事務所のみです。監査の日程を設定する前に、資格のある監査人に準備状況を確認してもらってください。