脆弱性診断の予算を立てる方法｜見積条件と社内説明の整え方

脆弱性診断の予算を社内で説明するとき、見積書の合計だけでは何を比べているのかを伝えにくくなります。対象範囲、確認の深さ、実施条件、報告、再確認が違えば、同じ発注目的に見える依頼でも前提が異なります。

結論から言うと、予算は見積の比較から始めず、対象範囲と実施条件を同じ前提で並べて説明します。診断で何を確認するか、いつ実施するか、どのように報告を受けるかを一つの説明表にまとめると、判断者が差分を確認しやすくなります。

この記事では、社内説明に残す項目、見積書を受け取る前にそろえる条件、予算の根拠を関係者へ伝える方法を整理します。費用を比べる前に、比較できる条件を作ることが目的です。

本記事で分かること

• 予算表に残す対象・実施・報告の条件
• 見積書の差分を読む順番
• 再確認を説明表へ入れる方法
• 社内の判断記録の残し方

結論：予算表は前提条件からそろえる（早見表）

予算は見積の比較から始めず、対象範囲と実施条件を同じ前提で並べて説明します。見積書の合計を見る前に、何を含めるか、何を対象外にするか、誰が確認するかをそろえます。

社内説明に残す項目

対象・確認の深さ・再確認・報告を一つの表にします。各見積書の条件を同じ欄へ移すことで、違いがどの前提から生じているかを社内で確認できます。

診断対象

診断対象は、資産名だけでなく、画面、機能、認証後の範囲、API、外部連携を分けて整理します。対象に含める理由、管理者、対象外にする理由を記載し、見積書の対象と対応付けます。対象の定義が違えば、同じ依頼目的でも比較の前提が変わります。

脆弱性診断の費用構造を参照し、対象、確認の深さ、認証後の範囲などを同じ仕様表にそろえます。対象の数え方を先に統一するより、何を対象として数えるかを明確にすることが重要です。対象の変更があった場合は、説明表と見積条件を更新します。

実施条件

実施条件には、確認する環境、避ける時間帯、テスト用情報、通常時の連絡窓口、判断が必要な場合の相談先を記載します。対象が同じでも、実施環境や変更予定が異なれば、依頼先に求める準備が変わります。条件を見積書の外に置かず、比較表の項目として残します。

本番に近い環境を使う場合は、利用できる操作と運用上の制約を確認します。別の環境を使う場合も、確認する版と本番との差を記録します。実施条件が未確定のときは、確定したように扱わず、確認先と次の対応を説明表に残します。

報告と再確認

報告と再確認では、報告書に対象・対象外・確認時点を記載するか、誰が結果を受け取るか、修正後にどの範囲を確認するかを整理します。報告会や質問対応が必要な場合も、必要な参加者と判断者を記載します。成果物の条件を対象条件と分けて比較します。

セキュリティ診断の発注ガイドを参考に、対象、承諾、成果物、連絡体制をそろえます。修正担当と再確認の担当が異なる場合は、対応表に役割を記載します。報告を受けることと、修正後の確認が完了することを同じ扱いにしません。

見積を比べる前の確認

見積書の合計だけを並べず、含むもの・除くものを確認します。対象範囲、確認方法、連絡・報告条件を同じ順番で読み、前提差を質問事項として残します。

対象範囲の差

対象範囲の差は、画面や機能の数だけでなく、認証後の領域、API、外部連携、対象外の扱いに現れます。見積書ごとに対象の定義が異なる場合は、合計を比較する前に対象表へ戻り、どの範囲が含まれているかを確認します。対象外の理由も同じ欄に残します。

対象が追加・除外された場合は、どの見積書の前提が変わるかを整理します。依頼先へ条件を追加で伝える場合は、すべての候補に同じ情報を渡します。比較表は順位を付けるためだけでなく、前提差を見つけるための資料として使います。

手動確認の比率

確認方法は、名称だけでなく、人が確認する範囲と自動的な確認が担う範囲を分けて読みます。対象、確認目的、成果物に対して何が含まれるかを確認し、同じ条件で比較表に記載します。方式が異なる場合は、どの対象にどの確認を行うのかを質問します。

手動診断とツール診断の違いを参照し、方式の呼び方だけで判断しないようにします。確認したい機能、認証後の範囲、報告書に求める内容を依頼条件に置き、回答を同じ欄で受け取ります。条件が違うものを一行にまとめません。

連絡・報告条件

連絡・報告条件では、通常時の窓口、判断が必要な場合の相談先、報告書の共有先、修正後の確認方法を整理します。対象と確認方法が同じでも、連絡体制や報告の受け方が異なれば、社内で必要な準備が変わります。見積書に記載がない場合は、質問事項として残します。

報告を受ける担当、修正を担う担当、再確認の結果を受ける担当を分けます。条件を比較表に残せば、社内説明では「どの依頼が何を含むか」を対象・実施・成果物の順に説明できます。未確認の条件を仮の前提で埋めないことが重要です。

予算の根拠を社内で説明する

予算の根拠は、見積書に書かれた対象と条件を、社内の対象表・実施条件表・対応表に対応付けて説明します。見積書ごとの前提差を可視化し、判断に必要な確認事項を残します。

対象表と見積書を対応付ける

社内説明では、対象表の各行と、見積書に書かれた対象・対象外を対応付けます。画面、機能、認証後の範囲、連携先を分け、どの条件で確認するかを示します。対象が一致していない見積書は、比較の前に質問すべき項目として扱います。

対象表を使えば、事業責任者、開発、運用、調達の担当が同じ範囲を見て判断できます。見積書の文言だけを説明の中心にせず、自社が何を確認したいかを起点にします。対象の変更があれば、見積書と説明表のどちらも更新します。

条件差を質問事項にする

見積書の前提が異なる場合は、条件差を質問事項として整理します。たとえば認証後の範囲、実施環境、連絡体制、報告書、再確認の条件を同じ順番で確認します。差分を解消するのか、差分を残したうえで判断するのかを関係者で決めます。

質問の回答は、対象表や条件表のどの行に関係するかを記録します。回答を受けて対象や実施条件が変わった場合は、比較表を更新し、他の候補へ渡す情報もそろえます。条件が違う理由を可視化すれば、社内で判断する前提を共有しやすくなります。

判断記録を更新する

判断記録には、対象、実施条件、報告・再確認、未確認事項、判断した担当、確認日を残します。発注を決めた後に条件が変わった場合も、何が変更され、誰が影響を確認したかを記録します。以前の前提を消さず、変更の経緯を追える形にします。

判断記録を更新すると、次の発注や再確認を検討するときに、対象と条件を再利用できます。見積書を保管するだけでなく、社内でどのように比較し、どの条件を採用したかを残します。これにより、予算の説明を一度きりの作業にせず、条件管理へつなげられます。

まとめ

脆弱性診断の予算は、対象範囲、実施条件、報告、再確認を同じ前提でそろえて説明します。見積書の合計を見る前に条件差を確認し、対象表・条件表・判断記録を対応付けることで、社内の判断を共有しやすくなります。

予算と見積条件の整理は、脆弱性診断の費用構造と、費用の記事一覧から確認できます。