SOC 2は、AICPA（米国公認会計士協会）のトラストサービス規準に照らして、公認会計士の事務所がサービスを提供する組織のシステムとコントロールを評価し、その結果をレポートにまとめる仕組みです。Drataでは、SOC 2のフレームワークの要求事項にDCFのコントロールがあらかじめマッピングされていて、テストと証跡で準備状況を確かめながら監査に備えられます。このページでは、DrataでSOC 2の準拠を進める手順として、トラストサービス規準の選び方、Type IとType IIの進め方の違い、システム記述書の準備、監査人の選定で確認することを説明します。
Drataで進める順序
ヘルプセンターでは、システムをDrataに連携した後、次の順にSOC 2の準備を進めることを勧めています。
| 順序 | 作業 | 内容 |
|---|---|---|
| 1 | ポリシーの管理 | SOC 2に必要なポリシーを、GovernanceのPoliciesで作成、確認、承認する |
| 2 | 要員の受け入れ | 全ての従業員をDrataに招待し、端末の設定、バックグラウンドチェック、ポリシーへの同意、セキュリティー研修を済ませてもらう |
| 3 | トラストサービス規準の決定 | 自社に当てはまるトラストサービス規準のカテゴリーを決める |
| 4 | リスク管理 | リスクを洗い出し、評価し、対応を決める |
| 5 | リスクアセスメントの記録 | リスクアセスメントの報告書とリスク対応の計画を、DCF-16（定期的なリスクアセスメント）とDCF-17（リスク対応計画）の証跡として登録する |
| 6 | モニタリングテスト | モニタリングテストの完了率100％を目指す。各テストのLearn Moreから、ヘルプの記事と是正の手順を確かめられる |
| 7 | 自動で確かめられないコントロールの証跡 | モニタリングで自動で確かめられないコントロールに、証跡を登録する |
| 8 | ベンダー管理 | 重要なベンダーをVendorsに登録し、SOC 2レポートやISO 27001の認証の書類を確かめる。どちらもない場合は質問票を送る |
| 9 | 監査人の選定 | 監査人を選び、面談で確認する（下の「監査人の選定で確認すること」の通り） |
| 10 | 監査の手配 | 監査の日付を決め、Drataで監査を作成して監査人を招待し、監査を受ける |
監査の作成と監査人の招待は、監査を作成して監査人を招待するで説明します。
【注意】 承認したポリシーがマッピングされているために準備ができた（Ready）状態に見えても、ほかの証跡が必要なコントロールがあります。代表的なものは次の通りです。準備状況の表示だけで判断せず、証跡がそろっているかを確かめてください。
| コントロール | 必要な証跡 |
|---|---|
| DCF-16、DCF-17 | リスクアセスメントの報告書とリスク対応の計画 |
| DCF-18 | 最新の脆弱性スキャンの結果 |
| DCF-19 | 年1回のペネトレーションテストの結果 |
| DCF-21 | システムの構成図 |
| DCF-22 | ネットワーク構成図 |
| DCF-26 | 事業継続と災害復旧の計画 |
| DCF-154 | 最新の机上演習またはインシデント対応の訓練の記録 |
コントロールの準備状況の条件は、コントロールの準備状況で説明します。
トラストサービス規準の選び方
トラストサービス規準のカテゴリーをどれにするかは、監査の範囲、つまり評価を受けて顧客に示すコントロールを決める、最初の大事な判断です。SOC 2のトラストサービス規準には、次の5つのカテゴリーがあります。
| カテゴリー | 対象 | 含めることを検討する場面 | 例 |
|---|---|---|---|
| セキュリティー（共通規準） | 全ての領域の基礎となるコントロール | 必ず含める | アクセス制御、変更管理、システムの運用（監視、脆弱性の管理、インシデント対応）、リスク管理 |
| 可用性 | 稼働時間、性能、災害からの復旧 | 顧客がサービスの継続的な稼働を前提にしている。契約やSLAで稼働時間や性能を約束している | 性能と容量の監視、バックアップと復元、事業継続と災害復旧の計画と訓練 |
| 機密保持 | 機密の情報や独自のデータの保護 | 顧客の知的財産、NDA（秘密保持契約）の対象の情報、漏れると損害が出るデータを扱う | データの分類、アクセス制御と暗号化、データの安全な廃棄 |
| 処理のインテグリティー | データの処理の正確さと信頼性 | 重要な計算、変換、取引を行い、誤りが顧客に大きな影響を与える | 入力、処理、出力の確認、変更が既存の処理を壊さないことの確認 |
| プライバシー | 個人情報の扱い | 顧客やその利用者から大量の個人情報を集めたり処理したりしている | プライバシーの方針の通知、同意の取得と管理、本人からの開示や削除の求めへの対応 |
セキュリティーは全てのSOC 2レポートで必須のカテゴリーです。ほかのカテゴリーと重なるコントロールを含むため、共通規準（Common Criteria）とも呼ばれます。5つのカテゴリーを全て含めれば完全なレポートになるように見えますが、必ずしも必要ではなく、最も得策とも限りません。顧客の要望、提供しているサービス、監査人との話し合いをもとに、事業上の判断として決めてください。
【注意】 プライバシーのカテゴリーを含めたSOC 2レポートは、データのプライバシーへの取り組みを示す手段になりますが、GDPR、CCPA、HIPAAなどの法令への正式な準拠に代わるものではありません。法令への準拠を示すには、別の監査やフレームワークが必要になることがあります。監査人と相談してください。
Drataでの設定
新しくDrataを使い始めてSOC 2を有効にした場合や、ワークスペースを使っている組織が新しいワークスペースでSOC 2を有効にした場合は、セキュリティーのカテゴリーの要求事項だけが対象（In Scope）になっています。ほかのカテゴリーの要求事項は、既定で対象外（Out of Scope）です。SOC 2の要求事項の画面を初めて開いたときには、この既定の範囲を説明する案内が表示されます。
ほかのカテゴリーを含める場合は、SOC 2の要求事項の一覧を対象外の要求事項で絞り込み、含めるカテゴリーの要求事項を対象に戻します。要求事項の一覧は、トラストサービス規準のカテゴリーでも絞り込めます。この操作は、Admin、Workspace Manager、Information Security Leadのロールのユーザーが行えます。手順は対象と対象外の管理で説明します。
セキュリティーだけに絞った範囲でも、自社に求められる要件を満たせているかは、監査人に確かめてください。
Type IとType IIの進め方の違い
SOC 2レポートには、Type IとType IIがあります。違いは次の通りです。
| 観点 | Type I | Type II |
|---|---|---|
| 評価の対象 | 特定の時点でのコントロールの設計 | 一定の期間にわたるコントロールの設計と運用の有効性 |
| 対象の期間 | 1つの日付（基準日） | 一般に3〜12カ月の期間 |
| 証跡 | 少ない。ポリシーやスクリーンショットなど、その時点の証拠 | 詳しい。ログ、チケット、監査証跡など、期間中の運用をサンプリングして確かめる |
| 完了までの期間 | 短い（1〜3カ月ほど） | 長い（運用の期間があるため、一般に6〜12カ月以上） |
| レポートの第4部 | コントロールが並ぶが、テストの手続きと結果は含まない | 監査人のテストの手続きと結果を含む |
例えば、データベースを毎日バックアップしている場合、Type Iの監査では、監査人は1回分のバックアップを確かめるか、ポリシーにバックアップを毎日行うと書かれているかだけを確かめることがあります。Type IIの監査では、監査対象期間の中から無作為に日を選び、その日にバックアップが成功していたかを確かめます。選ばれた日にバックアップが行われていなければ、例外としてレポートに記載されることがあります。
SOC 2をよく知る顧客の多くは、Type IIのレポートを求めます。Type Iを経ずにType IIから始めることもでき、監査が1回で済むため費用を抑えられます。一方で、初めての監査では、Type Iで設計の明らかな不備を見つけておくと、Type IIの準備になります。Type IとType IIで評価を受けるコントロールは同じで、Type Iのレポートは、Type IIに取り組んでいることを顧客に示す材料にもなります。
証跡を登録する時期
| レポート | 証跡の登録の時期 |
|---|---|
| Type I | 評価は1つの時点で行われるため、監査の日付までに全てのコントロールの証跡を登録し終える |
| Type II | 監査対象期間の間、コントロールが運用されていたことを示す証跡が必要。一般に期間中か期間の後に登録できるが、監査人に何を求めるかを確かめる |
ペネトレーションテストやセキュリティー研修のような年1回のコントロールを、監査対象期間が始まる前に実施した場合の扱いは、監査人によって異なります。期間の中でやり直す必要があるかを、監査人の選定のときに確かめてください。監査対象期間の決め方は、監査対象期間とサンプリングで説明します。
システム記述書の準備
システム記述書は、SOC 2レポートの第3部にあたる文書で、監査の対象としたシステムとその境界を説明します。境界の中に含まれる人、業務の流れ、技術、コントロールを書きます。ポリシーを書き、コントロールを整えた後に、長い説明文を書く必要があることに、監査の終盤になって気付く組織が少なくありません。早めに準備を始めてください。
システム記述書が必要な理由
監査人は、システム記述書が正確で完全か、記述の基準を満たしているかについて意見を述べる必要があります。また、システム記述書には、組織の構造、統治の仕組み、サービスの提供に使っているシステム、顧客の側で実施する必要があるコントロール、システムのセキュリティーに影響する第三者など、顧客が知らなくても、システムの管理に関係する情報が含まれます。
誰がどう書くか
システム記述書を書くのは、サービスを提供する組織の側です。監査人はひな形や質問票で手引きをしますが、一から書くことはしません。監査人の手引きの仕方には、主に次の2つがあります。
| 手引きの仕方 | 内容 |
|---|---|
| ひな形 | 各節の書き方の手引きを含むひな形を受け取り、組織が記入する |
| 質問票 | 組織が質問に答え、その回答をもとに監査人がシステム記述書の案を作り、組織が確かめる |
どちらの場合も、宣伝のような主観的な表現は避けて、監査の対象のシステムを客観的に説明します。AICPAも、SOCの手引きでこうした誇張した表現に注意を促しています。エンジニアリング、運用、セキュリティー、コンプライアンスなどの部署を巻き込むと、システムを正確に表し、書き漏れを防げます。
いつまでに書くか
システム記述書は、監査が終わる前であれば、いつ書いても構いません。Type Iでは監査の実査が終わる前に、Type IIでは運用の期間の終わり近くに書くことが多くあります。ただし、システム記述書は監査と同じ品質の管理を受けるため、完成していないとレポートの作成に進めず、最終的なレポートの受け取りが遅れることがあります。
完成したシステム記述書は、監査人が確かめられるように、DrataのEvidenceページに登録しておきます。
【注意】 システム記述書が不正確だと、限定付きの意見につながることがあります。例えば、サービスの一部を担う外部の委託先（再受託会社）の説明を記述に含めず、監査人がそれでは誤解を招くと判断した場合は、記述の不正確さを理由に意見が限定されることがあります。
監査人の選定で確認すること
SOC 2の監査人は、Drataの監査人のディレクトリーから探せます。監査人とは、どの段階で相談を始めても構いません。範囲やコントロールに関する疑問の多くは、監査人に確かめると解決するため、早めの相談をおすすめします。
面談では、次のことを確かめます。
| 観点 | 確かめること |
|---|---|
| 範囲 | 自社のような会社には、どのトラストサービス規準のカテゴリーを勧めるか。Type IとType IIのどちらにすべきか |
| 作業の分担 | Drataのダッシュボードのほかに、何を済ませる必要があるか。システム記述書は自社で書くのか、監査人が作るのか。コントロールのうち、どのくらいをDrataで確かめられ、どのくらいの証跡を手作業で集める必要があるか |
| 進め方 | 計画からレポートの受け取りまで、どのような流れで、どのくらいの期間がかかるか。監査の間、どのくらいの頻度で連絡があるか |
| 例外の扱い | 例外を見つけたときに、どのように知らされるか。最終的なレポートを出す前に、結果について話し合う機会はあるか |
| 技術の構成 | 自社の技術の構成をどう監査するか（例えば、Amazon S3やKubernetesで重要なコントロールは何か） |
| 期間 | Type IIの監査対象期間は最短でどのくらいか。年1回のコントロールを監査対象期間の前に実施した場合、どう扱うか。期間の前にType Iを受けていた場合、扱いは変わるか。期間の中で実施しなかった場合、レポートはどう変わるか。期間の中でやり直す以外の方法はあるか |
正式な監査の前に不備を洗い出すレディネスアセスメントを、監査人が別のサービスとして提供している場合があります。通常は別料金のため、内容と費用を監査人に確かめてください。
レポートを受け取るとき
監査の後には、レポートの草案が届きます。草案では、次の点を確かめます。
| 部 | 内容 | 確かめる点 |
|---|---|---|
| 第1部 | 監査人の報告 | 監査の結果の全体を表す文面に同意できるか |
| 第2部 | 経営者が署名する確認書 | 変えられない定型の文面だが、疑問があれば確かめておく |
| 第3部 | システム記述書 | 提出したものから大きな変更がないか |
| 第4部 | コントロールとテストの結果 | コントロールとテストの結果が正確に記載されているか |
監査人は、例外を見つけた場合は知らせるはずです。知らされていなければ、例外のないレポートになっている可能性が高いと考えられます。
ブリッジレター
SOC 2レポートの対象期間は、顧客の暦年や会計年度と一致しないことがあります。そのずれを補うのがブリッジレターです。ブリッジレターは、前回のレポートの対象期間の後も内部統制を保っていることを顧客に示し、期間の後に変更があればその内容を説明します。通常は3カ月以内の短い期間を対象にします。
ブリッジレターを出すのは組織の側で、監査を行った公認会計士の事務所は作成しません。一般に、次の内容を含めます。
- 前回のSOCレポートの対象期間の開始日と終了日
- 内部統制の重要な変更とその説明（変更があった場合）
- 監査人の意見に影響する重要な変更を把握していないことの表明（変更がなかった場合）
- ブリッジレターはSOC 2レポートに代わるものではないこと
- その顧客のためだけに作成したものであること