Drataの導入は、管理者が画面の設定を済ませれば終わるものではありません。IDプロバイダー、人事システム、クラウド基盤などの連携には各システムの担当者の協力が必要で、コントロールの運用には複数の部署の担当者が関わります。Drataのヘルプセンターは、導入を進める社内の推進役に向けて、段階ごとの進め方と体制の作り方をまとめた導入ガイド（Drata Rollout Toolkit）を用意しています。このページでは、その内容をもとに、導入を検討から稼働まで進める流れ、段階ごとに終える条件、GRCの責任者とコントロールオーナーなどの役割、巻き込む部署の決め方を説明します。
導入の全体の流れ
導入ガイドでは、導入を次の5つの段階に分け、順に進めることを勧めています。各段階は前の段階の成果を土台にしているため、順序を入れ替えずに進めます。
| 段階 | 時期の目安 | 主な作業 |
|---|---|---|
| 第0段階 | 第0〜1週 | 関係者と連携の担当者を特定し、経営層のスポンサーを確保する |
| 第1段階 | 第1〜2週 | キックオフで、適用範囲、日程、連携の優先順位、社内への案内の計画を決める |
| 第2段階 | 第3〜8週 | 主要な連携をつなぎ、コントロールのオーナーと対応の期限を決める |
| 第3段階 | 第9〜12週 | 部署ごとに使い方を説明し、社員向けの作業を始める |
| 第4段階 | 第13週以降 | テストと作業の流れを調整し、効果を測って定常の運用に移る |
時期は導入ガイドが示す目安です。対象のフレームワークの数や、次の監査までの期間に合わせて調整してください。
【運用のポイント】 導入ガイドは、導入の成否を最も左右するのは技術的な設定ではなく、関係者を巻き込めるかどうかだとしています。役割の割り当て、各部署への説明、社内への案内の計画を済ませてから、第2段階の連携の設定に入ってください。
段階ごとに終える条件
第0段階：関係者と連携の担当者をそろえる
技術的な作業に入る前に、導入に直接関わる人を特定し、経営層のスポンサーと連携の担当者を確保する段階です。次の項目がそろったら、第1段階に進みます。
| 確認すること | 内容 |
|---|---|
| 関係者の特定 | 導入に直接関わる部署と担当者を、部署ごとに洗い出している |
| 経営層のスポンサー | 経営層のスポンサーが決まり、目的と日程について合意している |
| Drataの主な管理者 | GRC（コンプライアンス）の担当者を、Drataの主な管理者として決めている |
| 連携の担当者 | 主要な連携（IDプロバイダー、人事システム、MDM、クラウド基盤、バージョン管理とCI/CD、課題管理、研修、バックグラウンドチェック）ごとに、つなぐ作業をする担当者を決めている |
| 担当者への事前の説明 | 連携の担当者に、連携の範囲、権限、セキュリティーについての資料を渡し、懸念を事前に出してもらっている |
| キックオフの日程 | 社内の主要なメンバーでキックオフの日程を決めている |
| 現状の記録 | 監査の準備にかかる時間、コントロールのテストの成功率、証跡を集める手間など、導入前の状態を記録している |
| 案内の時期の計画 | 営業部門と社員全体にいつ案内するかの計画を書き残している |
導入前の状態を記録しておくのは、第4段階で導入の効果を比べるためです。
第1段階：キックオフと計画
主要なメンバーで、適用範囲、日程、連携の優先順位、社内への案内の進め方をそろえる段階です。キックオフでは、次のことを決めます。
| 決めること | 内容 |
|---|---|
| 目的と日程 | 事業上の目的、対象のフレームワーク、次のSOC 2の監査やISO 27001の審査、顧客との約束などの重要な日付 |
| 適用範囲 | 対象とする環境、システム、連携のうち、第1・第2段階で扱うものと後に回すもの |
| 連携の順序と担当者 | 第0段階で洗い出した連携と担当者の確認、最初につなぐ連携の順序 |
| 対応の期限 | テストが失敗したときや連携に問題が起きたときに、部署ごとに何日以内に対応するか |
| 社内への案内 | 営業部門に案内する時期（Trust Centerの設定がほぼ終わった時点が目安）、社員全体に案内する時期（社員向けの作業の流れが整った後） |
| 会議の頻度 | 主要なメンバーの作業会議と、経営層への報告の頻度 |
適用範囲と対象のフレームワークの決め方は、フレームワークと適用範囲の決め方で説明します。
第2段階：連携の設定とオーナーの決定
Drataの自動化を支える連携をつなぎ、コントロールのオーナーと対応の期限を決める段階です。導入ガイドでは、連携を次の順序でつなぐことを勧めています。
- IDプロバイダー（SSO、ユーザーのID、多要素認証の設定）
- 人事システムとバックグラウンドチェック（要員の情報と入社・退職）
- クラウド基盤（AWS、Microsoft Azure、Google Cloudなど）
- 課題管理のツール（是正のためのチケット）
- MDMなどの端末の管理
- バージョン管理とCI/CD
- カスタム連携などの、そのほかの連携
連携とあわせて、次のことを済ませたら第3段階に進みます。
| 確認すること | 内容 |
|---|---|
| コントロールとオーナー | 対象のフレームワークとコントロール、コントロールとリスクごとのオーナー、各コントロールを支える連携と手作業の証跡を、関係する部署と整理している |
| 通知と対応の期限 | 失敗したテストや連携の問題が適切な部署に届くように通知を設定し、対応の期限を社内に示している |
| GRCの部署での試行 | フレームワーク、コントロール、ポリシーをDrataで対応付けて試し、ほかの部署に広げる前に確かめている |
| 手作業の証跡と是正の進め方 | 自動で集められない証跡の扱いと、失敗したテストの是正を既存のチケットの流れにつなぐ方法を検討している |
第3段階：部署ごとの利用開始
Drataで直接作業する部署ごとに、自分の担当と作業の仕方を理解してもらう段階です。部署ごとに説明の場を設け、次の内容を扱います。
| 部署 | 説明する内容 |
|---|---|
| GRCの担当者、管理者 | 全体の構成、フレームワーク、コントロール、モニタリング、証跡、監査 |
| IT、セキュリティー | ID、MDM、アクセス制御、連携の状態、是正の流れ |
| エンジニアリング、DevOps | クラウドとバージョン管理の連携、開発工程のテスト、是正の期限 |
| 人事 | 人事システム、バックグラウンドチェック、研修、ポリシーへの同意 |
| 法務・プライバシー、財務・ベンダー管理 | 該当する場合に、プライバシーとベンダーのリスク |
社員全体に案内する前に、IDプロバイダー、人事システム、MDMの連携が安定していることを確かめ、GRC、IT、人事などの少人数で、モニタリング、要員の作業、ポリシーと研修の流れを試します。問題がなければ社員全体に案内し、Drataにサインインして自分の作業を済ませてもらいます。案内の後は、部署ごとに作業の完了の状況を追い、遅れている部署の管理者に働きかけます。
【注意】 社員全体にDrataへのサインインを求めるのは、要員の設定が終わり、作業の流れを確かめた後にしてください。設定が整う前に案内すると、社員に不要な問い合わせや手戻りが生じます。営業部門への案内も、Trust Centerの公開が近づいてからにします。
第4段階：調整と定着
導入を一度きりの取り組みで終わらせず、日々の業務の進め方として定着させる段階です。
| 作業 | 内容 |
|---|---|
| テストの調整 | 最初の1カ月の失敗したテストと通知を見直し、本当のリスクと、対応の必要がないものを見分ける。意図して基準から外している箇所は例外として記録し、テストや対応付けを調整する |
| 効果の測定 | 第0段階で記録した導入前の状態と比べる |
| 定常の運用への移行 | 導入のための会議から、定例の運用の会議に移る |
| 成果の共有 | 期限内に連携をつないだ部署や、作業の完了率が高い部署の成果を社内で共有し、スポンサーの関与を保つ |
体制と役割
推進役と経営層のスポンサー
導入ガイドは、社内で導入を推進する人を「チャンピオン」と呼んでいます。推進役は全てを自分で進めるのではなく、経営層のスポンサーや各部署の責任者に必要な資料を必要な時期に渡し、各部署の中で導入を進める人を増やす役割を担います。
導入の前に最も重要なのは、部署をまたいで決定権を持つ経営層のスポンサーを確保することです。スポンサーには、CEO、COO、CFO、CRO、CISOなどの経営層が向いています。
| スポンサーが果たす役割 | 内容 |
|---|---|
| 障害を取り除く | 部署の抵抗や、ほかの業務との優先順位の争いを解消する |
| 経営資源を確保する | 関係する部署の予算、人員、作業の時間を確保する |
| 優先度を示す | 経営層が支持していることを示し、IT部門だけの取り組みではないと伝える |
| 対立を調整する | 業務の変更や連携の優先順位で部署の意見が分かれたときに調整する |
Drataのヘルプセンターでは、経営層のスポンサーが積極的に関わる組織は、導入の目標を達成する可能性が6倍高いと紹介しています。スポンサーには、キックオフでの発言や社内への呼びかけなど、目に見える形で関わってもらうようにしてください。
部署ごとの役割
SOC 2やISO 27001などのコンプライアンスは、1つの部署だけでは担えません。導入ガイドでは、部署ごとの役割を次のように整理しています。部署ごとに担当者の名前を書き入れ、導入の前に各部署の責任者と合意しておきます。
| 部署 | 導入時の役割 | 運用時の役割 |
|---|---|---|
| 経営層 | Drataをコンプライアンスの記録の基盤として支持し、主要なメンバーを承認する | 準備状況や未解決の課題の報告を確認し、部署間の対立を調整する |
| GRC、コンプライアンス、セキュリティー | Drataの主な管理者として、フレームワーク、コントロール、マッピングを設定し、ポリシーと証跡を取り込み、コントロールのオーナーを決める | コントロールの状況と是正の進み具合を見守り、適用範囲を保ち、監査の証跡を準備し、新しいオーナーに使い方を教える |
| IT、ITセキュリティー、IDと端末の管理 | IDプロバイダーやMDMなどの連携をつなぎ、データの範囲と権限が社内のセキュリティーの基準に合うかを確かめる | 多要素認証、SSO、パスワード、端末、特権アクセスのテストを担当し、入社・退職の流れが正しくDrataに反映されるようにする |
| エンジニアリング、DevOps、クラウド基盤 | クラウド基盤と開発のツールの連携をつなぎ、対象のリポジトリー、アカウント、環境を確かめる | 公開されたストレージや暗号化の不備などの技術的なテストを是正し、人の確認が必要な証跡を提供する |
| 人事 | 人事システムとバックグラウンドチェックの連携をつなぎ、取り込まれる項目がプライバシーの要件に合うかを確かめる | 在籍者の一覧、研修の受講、ポリシーへの同意に関するテストを担当し、退職者がシステムから速やかに外されるようにする |
| 法務、プライバシー | フレームワークとコントロールをプライバシーの要件に合わせ、プライバシーに関するポリシーを提供・確認する | プライバシーに関するコントロールの状況と証跡を確認する |
| 財務、購買、ベンダー管理 | ベンダーやシステムの一覧を提供し、フレームワークごとに対象のベンダーを合意する | Drataのベンダーの一覧と担当者を最新に保ち、ベンダーのリスク管理を支える |
| 営業 | 顧客と共有する資料をGRCの担当者と合意し、Trust Centerでの共有の仕方を覚える | 承認された最新の資料だけを顧客に渡し、顧客から追加の証跡を求められたらGRCの担当者に伝える |
| 社員全体 | 導入時の関与は小さく、主に何が求められるかを知ってもらう | 割り当てられたポリシーへの同意、研修の受講、端末の確認を期限までに済ませる |
法務・プライバシーの部署はプライバシーのフレームワークが対象の場合に、財務・購買の部署はベンダー管理の機能を使う場合に、特に関わりが大きくなります。
Drataの中での担当
Drataでは、コントロール、ポリシー、証跡のそれぞれに担当者（オーナー）を割り当てます。導入ガイドでは、それぞれの担当者に次のことを求めています。
| 担当 | 責任 | Drataで行うこと |
|---|---|---|
| コントロールオーナー | 担当するコントロールの目的と、それが支える要求事項を理解し、コントロールを準備完了（Ready）に保つ | 担当するコントロールの確認と編集、関係するテストの確認と是正、手作業の証跡の追加、タスクの処理、承認への対応 |
| ポリシーのオーナー | 担当するポリシーが実際の業務を反映し、予定した時期に作成、承認、公開、更新されるようにする | ポリシーの作成とアップロード、承認者の設定、更新期限の管理、コントロールへのマッピング、同意の状況の確認 |
| 証跡のオーナー | 担当する証跡が最新で、漏れがなく、正しくマッピングされているようにする | 証跡のアーティファクトの登録と更新、複数のコントロールへのマッピング、証跡の更新のタスクへの対応 |
コントロールオーナーと証跡のオーナーは別の人にできます。証跡を集める頻度（四半期ごとの確認など）は、コントロールオーナーとGRCの担当者が合意して決めます。各担当者に割り当てるロールは、ロールと権限の設計で説明します。
巻き込む部署の決め方
導入に直接関わる部署を洗い出す
導入ガイドでは、最初に、Drataや導入の作業に直接関わる人と部署を洗い出すことを勧めています。
| 部署 | 巻き込む条件 |
|---|---|
| GRC、コンプライアンス、セキュリティー | 常に巻き込む（コンプライアンスの取り組みの責任者） |
| IT、ID、端末の管理 | 常に巻き込む（IDプロバイダー、MDM、SSO） |
| エンジニアリング、DevOps、クラウド基盤 | 常に巻き込む（クラウド基盤と開発のツール） |
| 人事 | 常に巻き込む（人事システム、バックグラウンドチェック、研修） |
| 法務、プライバシー | プライバシーのフレームワークが対象の場合 |
| 財務、購買、ベンダー管理 | ベンダー管理の作業の流れが対象の場合 |
あわせて、主要な連携ごとに、つなぐ作業をする担当者を決めます。連携の担当者にはキックオフの前に資料を渡し、連携の範囲、権限、セキュリティーを確かめる時間を取ってもらいます。主要なシステムをつなぐことへの反対を、早い段階で解消するためです。
案内する順序と時期
導入ガイドでは、経営層のスポンサー、GRC、IT、エンジニアリング、人事、社員全体の順に巻き込むことを勧めています。前の部署の理解が、次の部署を巻き込む土台になるためです。
| 時期 | 案内する相手 |
|---|---|
| 第0段階 | 経営層のスポンサー、連携の担当者、キックオフに参加する主要なメンバー |
| 第3段階（要員の設定と作業の流れを確かめた後） | 社員全体 |
| 第3段階（Trust Centerの公開が近づいた時点） | 営業部門など、顧客に接する部署 |
初期の段階では、日々の作業でDrataを使わない部署に、全社への周知や参考のための案内を送らないようにします。早すぎる案内は、誤解や不要な問い合わせのもとになります。
部署ごとの懸念に答える
各部署には、それぞれの懸念があります。導入ガイドでは、部署ごとに次の点を伝えることを勧めています。
| 部署 | よくある懸念 | 伝える点 |
|---|---|---|
| GRC、コンプライアンス | 使い慣れたスプレッドシートや既存のツールから移ることへの不安、自動化を監査人が受け入れるかへの疑問 | 取り組みの設計と監督は引き続き担当者が担い、Drataは証跡の収集とモニタリングを自動化する。導入の初期は既存の進め方と並行して運用できる |
| IT | 認証情報やデータへのアクセス、連携のセキュリティー | 連携は読み取り専用で、権限は最小限。集めるのはメタデータで、システムを変更しない |
| エンジニアリング、DevOps | リポジトリーへのアクセスや、開発の妨げになること | チェックは読み取り専用で、ビルドを止めない。テストと通知は最初の30〜60日で調整できる |
| 人事 | 個人情報の取り扱い、業務の流れが変わること | Drataが読み取る社員の情報は、名前、メールアドレス、雇用状態、基本の日付、バックグラウンドチェックの状態に限られ、給与や評価の情報は含まない |
| 経営層 | コストがかかること、既に手作業で監査を通っていること | セキュリティーのレビューの短縮による売上への効果、作業時間の削減、監査と監査の間のリスクの低減 |
Drataのヘルプセンターには、経営層、GRC、IT、エンジニアリング、人事、営業、社員全体のそれぞれに向けた説明資料とメールのテンプレート（英語）があります。社内の資料を作るときの参考にしてください。
【運用のポイント】 担当者に余力がないときは、一度に全てを進めようとせず、効果の大きい連携から始めて少しずつ広げます。作業はGRCの担当者が抱え込まずに、IT、人事、エンジニアリングなど、そのシステムを日頃扱っている担当者をコントロールオーナーにして分担します。ほかの部署に協力を求めるときは、継続的な関与ではなく、特定の連携をつなぐための30分の作業のように、具体的で小さな依頼にすると受け入れてもらいやすくなります。
進み具合の測り方と定例
導入ガイドでは、次の4つの観点で進み具合を測り、毎月スポンサーと主要なメンバーで確認することを勧めています。
| 観点 | 測る指標の例 |
|---|---|
| 効率 | 監査ごとの準備にかかる時間（導入前と導入後）、ほかの部署に送った証跡の依頼の数 |
| リスク | コントロールの不備を検知するまでの時間、是正するまでの時間、監査の前に自分たちで見つけた問題の数 |
| 売上（Trust Centerを使う場合） | 質問票を受け取ってから回答するまでの時間、Drataの資料を使った商談の数 |
| 定着 | 接続済みの連携の割合、オーナーがサインインしたコントロールの割合、部署ごとの研修とポリシーへの同意の完了率 |
導入の後は、次の頻度で会議を続けます。導入から30日後と90日後には、スポンサーと主要なメンバーで指標を見直し、進め方を調整します。
| 頻度 | 内容 |
|---|---|
| 毎週（最初の1カ月） | GRC、IT、エンジニアリングの主要なメンバーで、連携の問題と優先度の高い失敗したテストを解消する |
| 毎月 | スポンサーと指標と状況を確認する。各部署の責任者と、定着の状況と障害を確認する |
| 四半期ごと | 削減できた作業、低減したリスク、早まった商談などの効果を振り返り、フレームワークやTrust Centerの拡大を検討する |