セキュリティーレビューの進め方

セキュリティーレビューは、ベンダーのセキュリティーの状況を評価し、記録し、継続して追うための仕組みです。レビューはベンダーの情報の画面に残り、質問票、SOCレポート、アップロードした資料、最終的な判断を含められます。ベンダーを取引に加えるときの評価、定期的なレビュー、レビューの状態と期限の追跡、監査に備えた記録に使います。このページでは、ベンダーのセキュリティーレビューとして、SOCレポートのレビューの手順、確認すべき範囲と例外の読み方、社内メモと所見の残し方、次回のレビュー期限の管理を説明します。

レビューの種類

レビューは、ベンダーの情報の画面のSecurity reviewsタブで作成します。

1. Vendorsを選びます。
2. Current vendorsかProspective vendorsを開きます。
3. ベンダーを選びます。
4. Security reviewsタブを開きます。
5. Create reviewを選びます。
6. 次のいずれかを選びます。

種類	使う場面
Security review	資料を集めて評価を記録する。ファイルのアップロード、Drataからの質問票の送付、Drataの外で受け取った回答のアップロードができる
SOC report review	ベンダーのSOCレポートを、決まった項目に沿って正式にレビューして記録する
Upload review report	Drataの外で済ませたレビューの報告書をアップロードする

Security reviewsタブには、そのベンダーの完了したレビューと進行中のレビューの履歴が全て残ります。

TPRM Agentを使える場合は、エージェントが評価基準に照らして資料を評価するレビューになります。手順はTPRM Agentによるレビューで説明します。

レビューの名前は、作成するときに入力するか、日付とレビューの種類を組み合わせた既定の名前をそのまま使います。後から変えるときは、Security Reviewsの表で、レビューの行の⋯からRenameを選び、Review nameを入れてSaveを選びます。名前は191文字までです。案件ごとの名前にしておくと、一覧で見分けやすくなります。

セキュリティーレビューで判断を記録する

Security reviewの種類のレビューでは、次の資料を集めて評価します。

資料	内容
ファイル	SOC 2レポートなどをアップロードする
質問票	Drataから質問票を送る（質問票の送付と回収）
Drataの外で受け取った回答	質問票の回答をアップロードする
AIの要約	有効にしている場合に表示される

ベンダーの資料と質問票の回答を確かめたら、自社のリスクと取引の条件をもとに、最終的な判断を選びます。

判断	選ぶ場面
Pending	レビューが続いている、またはベンダーからの追加の情報、資料、回答を待っている
Approved	ベンダーが自社のセキュリティーとコンプライアンスの要件を満たし、取引の前に必要な対応がない
Approved with conditions	取引を進めていいが、完全に承認する前に、是正、契約の条項、追加のコントロールなどの対応が必要
Rejected	ベンダーが自社のセキュリティーの要件を満たさないか、受け入れられない水準のリスクがある

判断の理由は、メモに書いておきます。条件付きで承認した場合は、必要な対応や条件も書きます。レビューを終えた後は、レビューの概要を確かめ、レビューの一式をダウンロードできます。直す必要があれば、レビューを開き直せます。

SOCレポートのレビュー

SOCレポートのレビューは、次の手順で進めます。

1. Create review → SOC report reviewを選びます。
2. SOCレポートを見ながら、各項目を入力します。
3. 途中で保存して閉じることもできます。
4. 全ての項目を入力したら、Finish reviewを選びます。

進行中のSOCレポートのレビューを完了するか削除するまで、新しいSOCレポートのレビューは始められません。

ヘルプでは、SOC 2の対象範囲に入っていて、自社の事業への影響が大きいベンダー（主要なベンダー）のSOC 2レポートを入手することを勧めています。主要なベンダーのうちリスクが高いと判断したベンダーは、入手するだけでなく、レポートをレビューする必要があります。

【注意】 ヘルプでは、リスクの高いベンダーのSOCレポートを読んで評価することは、SOC 2の要件であり、一度きりではなく少なくとも年に1回行う必要があるとしています。

以下は、ヘルプの記事「Reviewing Your Vendors' SOC 2 Reports Using Drata」に沿った、項目ごとの確かめ方です。

レポートの範囲を確かめる

項目	確かめること	レポートのどこを見るか
SOC Report Issue Date	レポートの発行日。Type 1の基準日や、Type 2の対象期間ではない	監査人の報告書（監査法人のレターヘッドに記載）。Section 1かSection 2の末尾の、ベンダーの経営者が署名した確認書の日付でも分かる
SOC Report	SOC 1、SOC 2、SOC 3のどれか	表紙
Type	Type 1か、Type 2か。Type 1は、システムの記述とコントロールの設計についての意見だけを含む。Type 2は、それに加えてコントロールの運用の有効性についての意見を含む	表紙。Section 1かSection 2の意見（Opinion）の段落に書かれていることもある
Trust Services Categories Included	SOC 2レポートの場合に、含まれるトラストサービス規準のカテゴリー。全てのSOC 2レポートは、少なくともセキュリティーのカテゴリーを含む	監査人の報告書の範囲（Scope）の段落（Section 1かSection 2）
Bridge Letter Received To Provide Full Coverage of our Audit Period	ブリッジレターを受け取ったか。ブリッジレターは、ベンダーのレポートの発行から自社のレポートの対象期間の終わりまでの間に、コントロールに重要な変化がなかったかを伝える、ベンダーの経営者の書面。受け取ったブリッジレターをアップロードする	SOCレポートには含まれない。顧客の依頼に応じてベンダーの経営者が発行する

意見を読む

Report Opinionには、監査人の意見を記録します。意見は、Section 1かSection 2の意見（Opinion）の段落にあります。

意見	意味
無限定の意見	システムの記述が適正に表示され、コントロールが対象期間を通じて有効に運用されていた（Type 2）か、ある時点で有効に設計されていた（Type 1）と監査人が判断した。例外が記載されていても、意見を修正するほどではないと判断されている
限定付きの意見	システムの記述とほとんどのコントロールは適正だが、有効に運用されていなかったコントロールがあると監査人が判断した。意見の中に、修正の原因になった例外の詳細が書かれている
否定的意見	ベンダーに広範で重要な問題があり、1つ以上のコントロールの目的（SOC 1）や規準（SOC 2）を満たしていないと監査人が判断した
意見の不表明	監査の範囲の制約のために、監査人が意見を出せなかった

あわせて、次の項目も入力します。

項目	記録すること
Do Control Objectives or Trust Principles Encompass Business Needs	レポートが自社の事業の必要を満たすか。例えば、インフラの提供元に99.999％の稼働率を求めているのに、レポートに可用性のカテゴリーが含まれていなければ、必要を満たさないことがある
Follow Up Activity if Opinion is Qualified	限定付きの意見の場合に、自社が行う追加の対応。例えば、重要な例外をベンダーがどう是正したか、どう是正する予定かを確かめるために、追加の情報を求める

例外を読む

コントロールの例外は、レポートのSection 4に、コントロールの横に「Exception Noted」や「Deficiency Noted」などと書かれています。

1. 例外が1つもなければ、No Findings Identified in the Reportを選びます。
2. 例外があれば、List of Findings in Reportに記録します。複数あるときは、Add Findingで加えます。
3. 例外ごとに、自社のコントロールの環境に重要な影響があるかを判断し、Do the Findings Have Any Material Impact on your Control Environmentで選びます。

例えば、インフラを提供するベンダーで、サーバーへのパッチの適用に関するコントロールに例外があれば、自社に影響します。一方で、全ての従業員に行動規範への同意を求めるコントロールの例外は、自社が使っているサービスには影響しないことがあります。

利用者側のコントロールを確かめる

End User Controlsには、ベンダーのコントロールの効果を十分に得るために、自社の側で必要なコントロールを記録します。レポートのSection 3（システムの記述）の末尾にあり、complementary user entity controlsと呼ばれることもあります。

状況	操作
自社に関係する利用者側のコントロールがない	チェックボックスにチェックを入れる。このセクションでそれ以上の作業は不要
当てはまる利用者側のコントロールを全て実施している	Yes to Allを選ぶ（任意）
当てはまる利用者側のコントロールを実施していない	No to Allを選ぶ（任意）
個別に記録する	+ add Controlで、レポートにある利用者側のコントロールを1つずつ加え、実施していればYes、していなければNoを選ぶ

サービス、拠点、監査法人、再受託会社を確かめる

項目	確かめること
サービス	レポートの対象のサービスのうち、自社が頼っているサービスだけを加える。サービスは、Section 3のシステムの記述にある
拠点	レポートの対象の拠点に、自社が使っているデータセンターの拠点が全て含まれているか。例えば、AWSのUS-East 1を使っているなら、その拠点が含まれていることを確かめる。拠点は、Section 3の概要（Overview）の段落にある
監査法人	監査法人の名前（Section 1かSection 2）と、監査法人が信頼できるかを確かめるために行った手続き（ウェブサイトの確認、検索、ピアレビューの結果など）
再受託会社	ベンダーが使っている再受託会社（ベンダーのベンダー）をSubservice Organizations in Reportに記録する。Section 3の末尾の「Use of Subservice Organizations and Complementary Subservice Organization Controls」のようなセクションにある

再受託会社は、レポートにあるコントロールの一部を担います。例えば、ベンダーが他社のデータセンターを使っているなら、物理的なアクセスの制限に関するコントロールを担うデータセンターの事業者が再受託会社です。

状況	操作
Section 3に再受託会社の記載がない	N/Aにチェックを入れる
署名された経営者の確認書が1つ（1つのサービス組織だけ）	一体方式（inclusive method）が使われていないため、Noを選ぶ
署名された経営者の確認書が2つ以上	Yesを選ぶ

Procedures Performed to Assess Subservice Organizationsには、再受託会社が何をしていて、ベンダーとどう関わるかを理解するために行った手続きを書きます。再受託会社がベンダーにとってどれだけ重要かによっては、再受託会社のSOCレポートもレビューすることがあります。

Drataの外で済ませたレビューを残す

Drataの外で済ませたレビューは、完了した報告書をアップロードしてDrataに残せます（Upload review report）。アップロードした報告書は、監査のために、ベンダーのレビューの履歴に保存されます。

社内メモと所見を残す

TPRM Agentを使ってレビューを進めるときは、評価基準ごとに、気づいたことや判断の理由を2種類の注記で残せます。監査で判断の根拠を説明しやすくなり、社内の考えをベンダーに見せずに、ベンダーに固有の事情を記録できます。

注記	内容	見える範囲
社内メモ（Internal Note）	判断の理由を残す。特に、AIの評価を変えたときの理由を書く	自社だけ。ベンダーには共有されない
所見（Observation）	レビューで分かった、ベンダーに固有のセキュリティーの状況を残す	レビューの参加者に見える。ベンダーには共有されない

取引中のベンダーでは、レビューを確定した後に、所見をリスクに変えられます。取引を検討中のベンダーにはリスクを割り当てられないため、所見は記録されますが、リスクには変えられません。

残し方	手順
評価基準によらない	進行中のレビューで、右側のパネルの本のアイコンを選び、Internal NoteかObservationのタブを選んで、文章を入れる。Contextには、レビューの名前の後に（general）と入る。Saveを選ぶ
特定の評価基準について	進行中のレビューで評価基準を選び、評価基準のパネルでAdd internal noteかAdd observationを選んで、文章を入れる。Contextには、評価基準の名前が入る。Saveを選ぶ

注記は30,000文字まで入力でき、入力した人の名前と日時とともに保存されます。

進行中のレビュー。右側のパネルの本のアイコンから、社内メモ（Internal Note）と所見（Observation）を残せる

全ての評価基準の評価を終えたら、レビューを確定します。

1. レビューの右上のFinalize reviewを選びます。
2. Finalize Security Reviewの画面で、Decision（判断）を選びます。
3. 必要なら、Noteに全体の評価や確定の理由をまとめます。
4. Mark review as completeを選びます。

確定すると、評価基準の状態、社内メモ、所見は、レビューの記録として固定されます。所見は、確定したレビューからリスク登録簿に加えられます。

【運用のポイント】 AIが出した評価を人が変えたときは、その理由を社内メモに残します。ベンダーとの打ち合わせで分かった、質問票には出てこない事情も、社内メモに書いておくと、後から判断を説明できます。

次回のレビュー期限を管理する

レビューの状態と期限の表示

Current vendorsの一覧には、レビューの状況を追うためのSecurity review statusとNext review deadlineの列があります。どちらの列でも絞り込めます。

状態	内容	定期レビュー
Up to date	直近の期限の90日以内にレビューを済ませた	有効
Needs review	レビューの期間が始まっていて、進行中のレビューがない	有効
In progress	レビューを進めている	有効か無効
Completed	レビューが完了していて、定期レビューが有効でない	無効
No past reviews	一度もレビューを済ませていない	有効か無効

期限の表示	内容
Due soon	レビューの期限まで7日以内
Overdue	レビューの期限を過ぎた
Deadline not set	定期レビューが有効でない

Current vendorsの一覧。Security review statusとNext review deadlineの列で、レビューの状況を確かめて絞り込める

定期レビューの全体の設定

1. Vendors → Vendor settingsを開きます。
2. Recurring reviewsのセクションまでスクロールします。
3. 期限の何日前にレビューの期間を始めるかを設定します。既定は30日です。

定期レビューで送る質問票は、レビューの期間が始まる日に自動で送られます。

ベンダーごとに定期レビューを設定する

1. Vendors → Current vendorsを開きます。
2. ベンダーを選びます。
3. Manage recurring reviewsを選びます。
4. Schedule recurring reviewsを有効にします。このベンダーのセキュリティーレビューを定期的に行うよう、リマインダーが届くようになります。
5. レビューの頻度を設定します。
6. 必要なら、Scheduled questionnairesを有効にします。
7. 送る質問票と、ベンダーの連絡先のメールアドレスを選びます。
8. レビューの開始日と期限を確かめます。

Manage recurring reviewsの画面。レビューの頻度、自動で送る質問票、レビューの開始日と期限を確かめる

複数のベンダーの期限と頻度をまとめて変える方法は、ベンダーの登録と分類で説明します。

期限の自動の調整

レビューの周期を保つために、今の期限の90日以内にレビューを済ませた場合は、次の期限が、レビューを済ませた日ではなく、元の予定をもとに計算されます。

例	日付
元の期限	6月25日
レビューを済ませた日	6月10日
レビューの頻度	6カ月ごと
次の期限	12月25日（12月10日ではない）

期限の90日以内であれば、期限より早めにレビューを済ませても、周期が前にずれていくことはありません。