監査前の証跡パッケージ

監査前の証跡パッケージは、監査の前に監査人に渡す情報をまとめたものです。監査人が自社の環境、範囲、コントロールを前もって理解できるため、監査を効率よく進められます。Drataでは、パッケージを送るかどうかと、含める情報のカテゴリーを選べます。このページでは、監査の前に証跡をまとめて渡す方法として、証跡パッケージの作成、含めるべき内容、監査人との事前の確認の進め方、パッケージを作る前に準備状況を点検する手順を説明します。

監査前の証跡パッケージの役割

監査前の証跡パッケージは、多くの場合、監査人が自社のコンプライアンスの取り組みを最初に詳しく見る資料になります。パッケージの中身を選ぶことで、監査に関係があり、正確で、適切なものだけを示せます。

• 機密の情報や、範囲の外の情報を共有せずに済む
• 余計な情報を減らし、監査人が関係するシステム、ベンダー、資産、コントロールに集中できる
• 最小権限と知る必要のある範囲（need-to-know）の原則に沿った、成熟したコンプライアンスの取り組みであることを示せる

監査人が前もって求める情報

多くの監査人は、自社の環境を理解できるだけの情報を前もって求めます。目的は、細かすぎる情報で負担をかけずに、整理された全体像を示すことです。監査人は一般に、次のことを行うために情報を求めます。

監査人が行うこと	内容
環境の理解	主なシステム、連携、インフラストラクチャー、範囲に入るベンダーを把握する
コントロールの設計の確認	コントロールがフレームワークと要求事項にどう対応付けられているかを確かめる
範囲の網羅の確認	監査対象期間について、関係するシステム、データの流れ、第三者が含まれていることを確かめる
サンプリングとテストの計画	実地の作業で、どのシステム、ユーザー、期間を確かめるかを決める

監査人は一般に、全てのアーティファクトやログを前もって必要とはしません。実地の作業を効率よく進めるための、整理された全体像と代表的な証跡を求めています。

監査の作成時にパッケージを設定する

監査前の証跡パッケージは、監査の作成の途中で設定します。監査の作成の手順は、監査を作成して監査人を招待するで説明しています。

1. 新しい監査の作成を始めます。
2. 監査前の証跡パッケージの欄で、パッケージを含めるかどうかを選びます。
3. パッケージを含める場合は、含めるカテゴリーを選びます。
4. 監査の作成を終えます。Drataが、選んだカテゴリーをもとにパッケージを作ります。

Include pre-audit packageの設定	動き
オン	パッケージを作って共有する。作成時にオンにすると、その監査では後からオフにできない。含めるカテゴリーは後から変えられる
オフ	パッケージを作らず、共有しない。カテゴリーは選べない

【注意】 監査の作成時にパッケージをオンにすると、後からオフに戻せません。パッケージを送らずに実地の作業から始めたい場合は、監査人と相談したうえで、作成時にオフにします。

選べるカテゴリー

カテゴリー	内容
Assets	会社の資産の一覧と、その属性
Company info	会社の概要と識別のための情報
Control mapping	Drataのコントロールとフレームワークの要求事項の関係
Evidence library (manual only)	手作業でアップロードした証跡
Infrastructure accounts	インフラストラクチャーのプロバイダーのアカウントと、環境ごとのユーザーのアクセス
Personnel	要員の名簿と雇用の情報
Policies	コンプライアンスと統治を支える会社のポリシー
Vendors	自社が使っている第三者のベンダー
Version control accounts	バージョン管理のプロバイダーのアカウントと、メンバーのアクセス
Public documents and contacts	公開しているポリシー、規約、サポートのページ、連絡先

含めるカテゴリーの考え方

ヘルプでは、カテゴリーを含めるかどうかの目安として、次のような考え方が示されています（提案としての目安です）。

カテゴリー	含めるのに向いている内容	含める前に整理するもの
コントロールと要求事項の対応付け	範囲に入るフレームワーク（SOC 2、ISO 27001など）とコントロールの対応付け。分かりやすいコントロールの説明と目的	下書きや廃止したコントロール。監査人向けではない社内のメモ
ベンダー	範囲に入るデータや重要なサービスを扱う第三者（ホスティング、ログ、メールの配信など）。フレームワークや監査人が決めた範囲に入るベンダー	範囲に入るデータを扱わないマーケティングのツールやリスクの低いツール。監査対象期間に使っていないベンダー
資産	本番環境など、範囲に入る資産（アプリケーションのサーバー、データベース、中核のサービスなど）	範囲に明示的に入っていない開発や検証の環境。廃止した資産
手作業でアップロードした証跡	承認済みの最終版のポリシーと手順。監査対象期間の中の画面のキャプチャーや書き出し	下書き、古い版、重複したアーティファクト。監査人向けではない社内の検討資料やチケット
インフラストラクチャーのアクセス	範囲に入る環境の特権アクセス（本番環境へのアクセスなど）の概要。アクセスの付与、レビュー、取り消しの方法を示す証跡	認証情報、シークレット、機密の運用の詳細。範囲に入る環境と関係のないアクセスの記録
バージョン管理	範囲に入るサービスの開発のライフサイクルと変更管理を支えるリポジトリー、ワークフロー、証跡	範囲に入る製品やサービスと関係のないリポジトリー。監査と関係のない試験的なリポジトリーや社内専用のリポジトリー

作成した後にパッケージを変える

作成時にパッケージをオンにした監査では、いつでもカテゴリーを変え、パッケージをダウンロードできます。

1. 対象の監査を開きます。
2. Package downloads → Pre-audit package → Edit packageを選びます。
3. 含めるカテゴリーを変えます。
4. 変更を保存します。

監査の画面のPackage downloadsのメニュー。Pre-audit packageからパッケージの編集を開く

作成時にパッケージをオフにした監査では、Adminのロールのユーザーが有効にするまで、パッケージを設定することもダウンロードすることもできません。有効にするときは、Package downloads → Pre-audit packageでTurn on pre-audit packageを選びます。有効にすると、パッケージを編集してダウンロードできるようになります。

パッケージのダウンロードでは、監査の画面のメニューでRequest packageを選びます。DrataがこのZIPファイルを作り、ダウンロードの準備ができると知らせます。

パッケージが作り直されるとき

監査の次の内容を変えると、Drataは監査前の証跡パッケージを自動で作り直します。

• 監査の属性（範囲や監査対象期間など）
• 選んだカテゴリー

作り直すと古い版は削除され、監査人は今の範囲と設定に合った最新の版だけを見ることになります。監査人がDrataの監査人向けのAPI（Auditor API）でつながっている場合は、作り直したパッケージを自動で受け取れるため、送り直す必要はありません。

監査人との事前の確認

パッケージを作る前に、監査人と次のことをすり合わせておきます。

確認すること	内容
監査対象期間	監査対象期間は、監査人とよく相談して決める。期間の決め方は監査対象期間とサンプリングで説明している
パッケージの要否	監査前の証跡パッケージを送るか、パッケージを送らずに実地の作業から始めるか
含めるカテゴリー	監査人が環境を理解するのに必要なカテゴリーはどれか。範囲の外の情報を含めていないか

パッケージを作る前に準備状況を点検する

監査の前に、Drataの各ページを見直して、コントロールが適切で、証跡がそろい、監査人がアクセスできる状態になっているかを確かめます。次の点検の項目は、ヘルプの事前のチェックリストにある一般的な項目です。全ての場面を網羅したものではないため、フレームワークの要件や自社の環境に応じて、監査人と相談しながら進めます。

ページ	点検すること
Monitoring	監査が始まる前に全てのテストの成功を目指す。失敗しているテストは、詳細で要因（要員、資産、設定）と推奨される対応を確かめて直し、Drataの次の自動の同期（通常は毎晩）で状態が成功に変わるのを待つ
Controls	範囲に入れたコントロールが監査の目的に合い、正しい要求事項に対応付けられているかを確かめる。SOC 2ではセキュリティーだけが必須で、ほかのカテゴリーは事業の必要に応じて含め、範囲の外のカテゴリーに対応するコントロールは範囲の外にする。ISO 27001では、適用宣言書で適用するとした附属書Aの管理策だけを範囲に入れる。範囲の外にしたコントロールは、業務上の根拠が記録されているかを確かめる
Controls（モニタリングしないコントロール）	自動でモニタリングしないコントロールには、ポリシーだけでなく裏付けの資料をアップロードしたかを確かめる。ポリシーが結び付いているだけで準備完了に見えるコントロールがあるため、裏付けの証跡が必要な箇所を確かめる
Personnel	要員ごとの雇用状態（従業員か業務委託者か、在籍か退職か）が正しいか。監査の範囲に影響しない人を範囲の外にしているか。範囲に入る要員のポリシーへの同意、セキュリティー研修、多要素認証、バックグラウンドチェック、端末のセキュリティーがそろっているか
ポリシー	必要なレビューと承認を経ているか。版が記録されているか。正しい要員のグループに割り当てられ、最新の版に同意されているか。更新期限を見直し、関係するコントロールにマッピングされているか
Vendors	全てのベンダーの最新の一覧があるか。重要なベンダーのセキュリティーレビューが完了し、最新のSOC 2のType 2レポートか回答済みの質問票が添付されているか

各ページの見直し方は、テストの結果を読み解く、コントロールの準備状況、要員のデータの取り込み、ポリシー管理の全体像、ベンダー管理の全体像で説明しています。

【注意】 証跡が監査人に見えるのは、監査対象期間の中にある場合だけです。自動でモニタリングしないコントロールの証跡は手作業でアップロードする必要があるため、正しく結び付いていて、監査対象期間の中にあるかを確かめてください。