脆弱性診断のRFPの書き方｜発注前にそろえる9つの入力情報

脆弱性診断のRFPが抽象的だと、依頼先ごとに対象や成果物の前提が異なり、見積書を比べにくくなります。「診断を依頼したい」とだけ書くのではなく、対象、承諾、実施制約、報告、再確認、連絡体制を先に整理する必要があります。

結論から言うと、RFPは「何を診断するか」だけでなく、許可・制約・報告・再確認を同じ入力票にそろえます。対象を管理する者の承諾範囲を確認し、管理下にある資産と連絡窓口を明確にすることが、発注前の基本です。

この記事では、RFPへ最初に書く入力情報を、対象と権限、実施・報告条件、比較できる回答形式に分けて説明します。依頼先へ渡す前に社内で入力票を確認すると、質問への回答と判断を進めやすくなります。

本記事で分かること

• RFPに入れる対象・権限・対象外
• 実施環境と連絡体制の整理
• 報告・再確認の条件
• 回答を比較できる形にそろえる方法

結論：RFPは9つの入力情報から作る（早見表）

RFPは、対象、所有者・管理者、対象外、実施環境、時間帯、テスト用情報、連絡窓口、報告、再確認を同じ入力票にそろえます。各項目に確認する担当と更新する条件を添えると、依頼先の回答を比較しやすくなります。

対象と権限を書く

対象資産と承認者を曖昧にせず、無断の確認を防ぎます。対象、所有・管理の関係、対象外を別の欄にし、誰が承諾するかをRFPに記載します。

URL・IP・アプリ・API

対象は、URL、IP、アプリ、APIなどの名称だけでなく、どの業務機能や利用者と関係するかを記載します。画面、認証後の機能、外部連携を分けると、依頼先が対象の役割を理解しやすくなります。対象名、管理者、確認する環境を対応付けます。

対象の一覧は、候補を並べるだけではありません。今回確認する対象、確認中の対象、対象外にする対象を分け、RFPの前提にします。Webアプリ診断の対象範囲を参照し、画面・権限・連携を対象表へ整理してからRFPに転記します。

所有者と管理者

対象を含める前に、誰が所有・管理し、誰が実施の承諾を確認するかを記載します。自社が利用しているだけのサービスや、委託先が管理する領域は、自社だけで対象に含めません。管理者の確認先と連絡窓口をRFPの対象行に対応付けます。

承諾の確認は、対象を発注仕様として確定するための前提です。対象の所有・管理の関係が不明な場合は、推測で対象に入れず、確認先と対応期限を残します。RFPを渡す前に、対象の承認者と通常時の窓口を社内で確認します。

対象外の範囲

対象外の範囲には、今回確認しない資産、機能、権限、外部連携を記載し、理由を残します。対象外を空欄にすると、依頼先が対象に含めない理由と、自社が確認中の範囲を区別できません。後で見直す条件も添えます。

脆弱性診断の費用構造を参照し、対象、確認の深さ、認証後の範囲、報告条件を同じ仕様表にそろえます。対象外の記録をRFPと比較表に残せば、見積書の前提差を確認しやすくなります。

実施・報告の条件を書く

実施制約と報告条件を見積比較の前提にします。環境・時間帯・テスト用情報・連絡窓口・報告・再確認を、対象表と対応付けてRFPへ記載します。

実施環境と時間帯

実施環境では、確認する版、環境、避ける時間帯、通常利用や保守の制約を記載します。いつでも実施できると仮定せず、対象に影響する変更予定と、変更が必要になった場合の連絡方法を整理します。環境名だけでなく、対象表のどの行と関係するかを示します。

本番に近い環境を使う場合は、利用できる操作と運用上の制約を確認します。別の環境を使う場合も、本番との差を記録します。実施環境と時間帯の条件をRFPに入れることで、依頼先の回答を同じ前提で比較できます。

テスト用情報と連絡窓口

テスト用情報は、利用者区分と必要な権限に合わせ、提供方法、利用できる範囲、取扱い条件を記載します。実在の利用者情報をそのまま扱う前提にせず、社内のルールに沿って準備できる情報を整理します。用意できない範囲は対象外とする理由を残します。

連絡窓口は、通常の質問を受ける担当と、判断が必要な場合に相談する担当を分けます。実施中に変更が起きた場合、誰が対象への影響を判断するかもRFPに記載します。窓口が複数ある場合は、最初に連絡する担当を一つに決めます。

報告・再確認・報告会

報告条件では、対象・対象外・確認時点を報告書に記載するか、誰が結果を受け取るか、質問をどう扱うかを整理します。修正後の再確認が必要な場合は、対象、確認する版、結果の受け方をRFPに記載します。報告会を設ける場合は、参加者と確認したい論点を整理します。

セキュリティ診断の発注ガイドを参考に、対象、承諾、成果物、連絡体制をそろえます。報告を受けること、修正すること、再確認することを別の条件として書くと、回答の差を確認しやすくなります。

比較できるRFPに仕上げる

回答形式をそろえ、見積書の合計だけで比較しません。回答期限、前提差の記載欄、確認日をRFPに入れ、依頼先ごとの回答を同じ比較表で確認します。

回答期限

回答期限は、依頼先の回答を受けてから社内で対象・条件を確認する時間も含めて決めます。期限だけを伝えるのではなく、質問を受ける窓口と、追加情報を共有する方法をRFPに記載します。回答が遅れた場合に誰が判断するかも整理します。

依頼先ごとに異なる情報を渡さないよう、追加の質問への回答は同じ条件で共有します。期限内に確認できない項目は、仮の条件として扱わず、比較表の未確認事項に残します。回答の時点と確認担当を記録すると、後から条件の更新を追いやすくなります。

前提差の記載欄

前提差の記載欄には、対象、実施環境、テスト用情報、報告、再確認などがRFPと異なる場合に、どの項目が違うかを書いてもらいます。差分を本文の説明だけに埋め込まず、比較表に写せる欄として設けます。前提が異なる回答を同じ条件で比較しないためです。

差分がある場合は、RFPを変更して全ての依頼先へ共有するか、差分を残して社内で判断するかを決めます。質問と回答の履歴を対象表と対応付ければ、どの条件で発注を判断したかを説明できます。

確認日の記録

確認日の記録には、対象、実施条件、連絡窓口、報告・再確認の条件を社内で確認した日と担当を残します。RFPの内容が更新された場合は、何が変わったかと、誰が影響を確認したかを記載します。以前の前提を消さず、変更の経緯を追える形にします。

RFPと比較表を同時に更新すれば、見積書を受け取った後も対象・条件の差分を確認できます。確認日を残すことは、資料を作成した事実だけでなく、判断の根拠を関係者で共有するための作業です。

まとめ

脆弱性診断のRFPは、対象、所有者・管理者、対象外、実施環境、テスト用情報、連絡、報告、再確認、回答形式を一つの入力票にそろえます。対象と承諾を明確にし、回答の前提差を比較表へ残すことで、発注判断を進めやすくなります。

RFPの作成は、セキュリティ診断の発注ガイドと、進め方の記事一覧から確認できます。