Drataは多くのフレームワークに対応していますが、最初にどのフレームワークに取り組み、どこまでを範囲に含めるかによって、作業の量と監査の費用が大きく変わります。範囲が広すぎれば不要な作業が増え、狭すぎれば監査で不備を指摘されるおそれがあります。このページでは、最初に取り組むフレームワークと適用範囲の決め方として、SOC 2とISO 27001の選び方、対象とするシステムと要員の範囲、ワークスペースを分けるかの判断を説明します。
最初に取り組むフレームワークを決める
Drataが対応するフレームワークには、要求事項があらかじめDCFのコントロールにマッピングされたものと、要求事項だけが用意されていて自分でコントロールにマッピングするものがあります。SOC 2とISO 27001（2013年版と2022年版）は、どちらもあらかじめマッピングされたフレームワークです。
最初に取り組むフレームワークは、事業上の目的と期限から決めます。導入のキックオフでは、次のことを確かめます。
| 確かめること | 内容 |
|---|---|
| 事業上の目的 | なぜフレームワークに取り組むのか（取引先からの要請、新しい市場への参入など） |
| 重要な日付 | 次の監査や審査の予定、顧客と約束した期限 |
| 求められている成果物 | 取引先が求めているのは、SOC 2レポートか、ISO 27001の認証か |
Drataのヘルプセンターでは、フレームワークの選定と日程は、顧客との信頼の窓口になる営業部門の要望で決まることが多いとしています。取引先から何を求められているかを、営業部門に確かめてください。
1つのフレームワークから始めても、後から別のフレームワークを追加したときに作業をやり直す必要はありません。DCFの1つのコントロールは、複数のフレームワークの似た要求事項に対応しているため、最初のフレームワークで整えたコントロールと証跡を、追加のフレームワークでも使えます。追加の時期と進め方は、複数のフレームワークを併用するで説明します。
【注意】 利用できるフレームワークは契約の内容によって異なります。契約に含まれていないフレームワークに取り組む場合は、正規販売代理店（デジタルアクセルズ）にご相談ください。
SOC 2とISO 27001の違い
SOC 2とISO 27001は、どちらも情報セキュリティーの取り組みを第三者に評価してもらう枠組みですが、評価する人、成果物、範囲の決め方が異なります。
| 観点 | SOC 2 | ISO 27001 |
|---|---|---|
| 評価する人 | 監査人（公認会計士の事務所） | 認定を受けた認証機関 |
| 成果物 | SOC 2レポート（Type IまたはType II） | 認証 |
| 基準 | AICPA（米国公認会計士協会）のトラストサービス規準。セキュリティーは必須で、可用性、機密保持、処理のインテグリティー、プライバシーは選んで加える | 箇条4〜10の要求事項と、附属書Aの93の管理策。適用宣言書で、各管理策を含めるか除外するかと、その理由を示す |
| 範囲の対象 | 特定のシステムと、関係する事業上の目的と顧客への約束。1つの製品だけを範囲にできる | 情報セキュリティーマネージメントシステム（ISMS）とその境界 |
| 範囲を決める人 | 範囲を示すシステム記述書は、監査人の承認が必要 | ISMSの範囲は組織が決める。審査員は範囲が適切かを確かめるが、範囲を決めはしない |
| 評価の進め方 | Type Iは特定の日付の時点でのコントロールの設計を、Type IIは一定の期間（一般に3〜12カ月）にわたるコントロールの設計と運用状況を評価する | 第1段階審査で文書、範囲、準備状況を、第2段階審査でコントロールの実施と有効性を評価する |
選ぶときの観点
どちらを選ぶかは、取引先から何を求められているかで決めるのが基本です。SOC 2を求められている場合、SOC 2をよく知る顧客の多くはType IIのレポートを求めます。Type Iを経ずにType IIから始めることもできますが、初めての監査では、Type Iで設計の不備を早く見つけてからType IIに進む進め方もあります。
| 進め方 | 期間の目安 | 向いている場面 |
|---|---|---|
| Type Iから始める | Type Iは1〜3カ月 | 初めての監査で、まず設計の不備を洗い出したい。Type IIに取り組んでいることを顧客に早く示したい |
| Type IIから始める | 運用状況を確かめる期間があるため、一般に6〜12カ月以上 | 顧客がType IIを求めていて、監査を1回にまとめて費用を抑えたい |
トラストサービス規準の選び方、Type IとType IIの詳しい違いはSOC 2を進めるで、ISMSの範囲と適用宣言書の作り方はISO 27001を進めるで説明します。
【運用のポイント】 監査人や認証機関とは、早い段階で相談を始めてください。範囲やコントロールに関する疑問の多くは、監査人に確かめると解決します。SOC 2では、正式な監査の前に不備を洗い出すレディネスアセスメントを、監査人が別のサービスとして提供している場合があります。
適用範囲を決める
Drataのヘルプセンターは、適用範囲（監査の対象に含める人、システム、業務の流れ、データ）を決めるためのチェックリストを用意しています。次の順に検討します。
対象の製品やサービスから始める
最初に、どの製品、プラットフォーム、サービスについてレポートや認証を取得するのかを決めます。顧客に提供するSaaSか、社内向けのツールか、サービスの提供かも確かめます。最初の範囲には、その製品やサービスを直接支えるシステム、データ、チームだけを含めます。
範囲に含めるものの基準
範囲に含めるかどうかは、直接関わっているかだけでなく、リスクにさらされる可能性も含めて判断します。
| 分類 | 範囲に含める条件 | 例 |
|---|---|---|
| システム、基盤 | 顧客のデータや機密のデータを保管、処理、送信する | AWS、Google Cloud、Microsoft Azure、本番のデータベース、CI/CDのパイプライン |
| 人 | 対象の製品やシステムを開発、管理、支援する | エンジニアリング、DevOps、セキュリティー、IT、サポートのチーム |
| 業務の流れ | 製品や機密のデータのセキュリティー、可用性、機密性、プライバシーに影響する | 変更管理、インシデント対応、入社・退職の手続き |
| ベンダー | データを保管・処理する、またはサービスの提供に欠かせない | クラウドの事業者、メールのツール、決済の事業者 |
| データ | 個人情報、医療の情報、財務の情報などを含む | 利用者のメールアドレス、請求の記録 |
| リスク | 製品や機密のデータに、セキュリティー、プライバシー、運用上の大きなリスクがある | 認証情報を扱う重要な社内ツール、暗号化されていないデータストア |
判断に迷ったときは、次のように問いかけます。
- そのシステム、人、業務の流れは、顧客のデータを扱うか、製品を直接支えているか
- そこで障害や侵害が起きた場合に、顧客やコンプライアンスの義務に影響するか
- 製品の構成から見て、監査人が範囲に含まれると考えるのが自然か
最終的な範囲は、必ず監査人と確かめます。
よくある失敗
| 失敗 | 内容 |
|---|---|
| 範囲を広げすぎる、狭めすぎる | 広げすぎると費用と作業が増え、狭めすぎると不備や不適合につながる |
| 承認を得ずに使われているツールを見落とす | 正式に導入していないツールでも、機密のデータを扱っていれば範囲に入ることがある |
| ベンダーとの接点を見落とす | 機密のデータがベンダーのシステムを通るなら、保管していなくても範囲に入ることがある |
| 関係する部署の意見を聞かない | セキュリティー、IT、法務などと合意していないと、重要な領域を見落としたり、後で摩擦が起きたりする |
要員の範囲と業務委託者
要員の範囲で迷いやすいのが、業務委託者を含めるかどうかです。最終的に決めるのは監査人ですが、ヘルプセンターでは、監査人と話すときの判断の材料を次のように示しています。
| フレームワーク | 業務委託者が範囲に入る条件 | 例 |
|---|---|---|
| SOC 2 | 監査の対象のシステム、事業上の目的、顧客への約束に影響する。顧客のデータに触れるか、対象のシステムを支えているか、触れない場合も事業上の目的や顧客への約束に直接影響するかで判断する | DevOpsの業務委託者は範囲に入る。セキュリティーの規程とリスクアセスメントだけを担当するコンサルタントも、事業上の目的に影響するため範囲に入ることがある。ロゴのデザインの委託先は入らないことが多い |
| ISO 27001 | 範囲に含めたISMSの部分に属するか、それを支えている。範囲に含めた資産を支えたり、扱ったりしている | ITサポートの業務委託者は範囲に入ることが多い。ISMSの範囲から営業部門を外している場合、営業の業務委託者は入らないことが多い |
範囲から外す要員をDrataでどう扱うかは、対象外の要員とサービスアカウントで説明します。
フレームワークごとの範囲の考え方
| フレームワーク | 範囲の中心 | 押さえておく点 |
|---|---|---|
| SOC 2 | トラストサービス規準に関わるシステムと業務の流れ | 1つの製品だけを範囲にできる。システム記述書は監査人の承認が必要 |
| ISO 27001 | ISMSとその境界 | 範囲は組織が決め、審査員はその適切さを確かめる |
| HIPAA | 医療の情報を扱うシステムと業務の流れ | 医療の情報を扱うシステムだけを含めればいい |
| PCI DSS | カード会員データを扱うシステムと業務の流れ | ネットワークを分離して範囲を狭める |
範囲を文書にする
決めた範囲は、何が範囲に含まれ、何が含まれないかが分かる形で文書に残します。
| 文書 | 内容 | 関係するDCFのコントロールの例 |
|---|---|---|
| データフロー図 | 機密のデータがどこから入り、どこで処理され、どこから出ていくか | DCF-204 |
| ネットワーク構成図 | ネットワークセグメントと、範囲に含まれるシステムの場所、システム間の通信 | DCF-22 |
| 資産の一覧 | 全てのIT資産と、範囲に含まれるかどうかの印 | DCF-20 |
文書ができたら、セキュリティー、IT、コンプライアンス、法務などの関係する部署と、範囲について合意します。
範囲は一度決めたら終わりではありません。業務の流れ、使うシステム、データの流れが変われば、範囲も変わります。年に1回や、システムの構成が大きく変わったときなどに、範囲を見直してください。
決めた範囲をDrataに反映する
自社の環境に当てはまらない要求事項（クラウドだけで運用している組織にとってのデータセンターの要求事項など）は、Drataで対象外（Out of Scope）にし、理由を記録します。準備状況の計算に入るのは、対象（In Scope）の要求事項だけです。要求事項を対象外にしたときのコントロールへの影響と手順は、対象と対象外の管理で説明します。
ワークスペースを分けるかを決める
アカウント、ワークスペース、MIMの違い
Drataでは、組織を次の3つの単位で表します。
| 単位 | 内容 |
|---|---|
| アカウント | 会社とDrataの関係を表す最上位の単位。Drataの環境全体を管理する |
| ワークスペース | アカウントの中の、独立した運用と監査の環境。ワークスペースごとに、適用範囲、フレームワーク、コントロール、テスト、連携、オーナー、運用の周期を持てる |
| Multiple-Instance Management（MIM） | 本当に別々のDrataの環境やアカウントを管理するための仕組み。1つの会社の中の部署や事業部門を表すためのものではない |
ワークスペースは、会社の組織図の階層を表すものではありません。部署、製品、地域、指揮系統ごとに分ける必要はなく、分けることでコンプライアンスの運用や監査の仕方が変わる場合に分けます。
1つのワークスペースで足りる場合
次の条件に当てはまる場合は、ワークスペースは1つにします。初めてコンプライアンスの取り組みを作る組織や、1つの取り組みを中央で管理する組織では、1つのワークスペースが最も簡単です。
- 同じチームがコンプライアンスの取り組みを担当している
- 同じ人が同じコンプライアンスのデータにアクセスする
- 同じシステムと証跡が、対象のフレームワークを支えている
- 同じコントロール、テスト、運用の周期が組織全体に当てはまる
- 分けても、監査やアクセスの意味のある境界がなく、重複が増えるだけ
ワークスペースを分ける場合
次のいずれかの境界が重要な場合は、ワークスペースを分けます。
| 境界 | 内容 |
|---|---|
| 監査の範囲 | 事業部門、製品、法人ごとに、別々に監査を受ける |
| オーナー | コントロールの運用と検出事項の解決に責任を持つチームが異なる |
| アクセス | 利用者に、特定の環境のコンプライアンスの作業だけを見せたり、管理させたりしたい |
| システムと証跡 | 環境ごとに、連携、対象の要員、証跡の取得元が異なる |
| 運用の周期 | グループごとに、コンプライアンスの作業の日程が異なる |
| 顧客や規制による分離 | 同じ組織に属していても、環境を独立して管理する必要がある |
逆に、部署や指揮系統ごと、同じチームが運用している製品ごと、監査の範囲とアクセスの仕組みが同じ地域ごと、一時的なプロジェクトのチームごと、コントロールの割り当て方の小さな違いのためだけに、ワークスペースを分けることは勧められていません。報告、オーナー、絞り込みが目的なら、1つのワークスペースで、オーナーや報告の機能を使います。
分ける前に確かめること
ワークスペースを増やすと、設定、テスト、証跡の確認、管理の作業をする場所が増えます。分ける前に、次のことを確かめます。
- グループごとに、監査の範囲や対象のフレームワークが異なるか
- グループごとに、管理者のアクセスを分ける必要があるか
- グループごとに、システム、対象の要員、証跡の取得元が異なるか
- グループごとに、コントロールオーナーや運用の周期が異なるか
- 分けることで増える管理の手間や重複に見合う理由があるか
- 同じコントロールが当てはまるなら、ワークスペースの間でコントロールをリンクするか
ほとんどの答えが「いいえ」なら、1つのワークスペースから始めます。分ける場合も、必要な分離が得られる最小の数にします。
【注意】 ワークスペースの間でコントロールをリンクすると、コントロールの情報、ポリシー、証跡（
Evidenceページで管理する証跡）を、選んだワークスペースの間で管理できます。ただし、テストとモニタリングの結果は、ワークスペースごとに分かれたままです。あるワークスペースのテストの結果が、別のワークスペースのテストの状態を変えることはありません。
ワークスペースの作り方、共有できるものとできないもの、後から構成を変える場合の注意は、ワークスペースの設計で説明します。