脆弱性診断の見積り方法と依頼前にそろえる条件や費用の注意点

脆弱性診断の見積りに必要な準備

見積りの目的と提出先を決める

最初に決めたいのは、診断を受ける理由です。サービス公開前の確認、取引先から求められた第三者評価、改修後の確認では、必要な範囲や提出する資料が異なります。「セキュリティを確認したい」だけでなく、誰が何を判断するための診断なのかを一文にします。取引先の要求書があるなら、対象システム、必要な検査、報告書の形式、提出期限を確認しましょう。

例えば「公開前の会員向けWebサービスについて、ログイン後の画面を含めた診断結果を、社内の公開判断に使いたい」という書き方です。これは依頼内容の整理例であり、特定企業の実績ではありません。診断だけで安全や取引先の要求への適合が確定するわけではないため、提出先が求める要件と、診断会社が提供する内容を照合します。

Webアプリケーションの確認なのか、サーバーやクラウド設定の確認も必要なのかも分けます。名称が似ていても、ソースコードの確認や権限設計の検証まで含むとは限りません。社内で判断できない点は「対象に含めるべきか相談したい」と記載すれば、必要な範囲を確認する質問につながります。予算だけを先に固定して重要な機能が外れることを避け、優先順位を伝える準備をしましょう。

画面数と通信の数を分けて整理する

画面、URL、API、HTTPリクエストは、それぞれ違う数え方です。同じ画面に検索、登録、更新の操作があれば、複数の通信が発生することがあります。反対に、URLが違っても、診断会社が同じ機能としてまとめて扱う場合があります。自社で数えた画面数を、そのまま各社共通の課金単位と考えないことが重要です。

パナソニックの公式案内では、ツール診断・手動診断の対象となるURLやAPIの数量が見積金額に関係し、HTTPリクエストは実際に送信する通信を数えると説明されています。診断メニューごとに算出方法が異なるため、依頼時にはパナソニックの見積りに必要な情報と通信の数え方のような公式説明を確認し、候補会社へ定義を尋ねます。

用意する一覧には、画面名、操作、通信先、利用者の権限、対象にしたい理由を並べます。例えば検索画面なら「初期表示」「条件を付けて検索」「結果の詳細表示」を分けて記録します。ただし、この例をそのまま三つの課金対象と断定するものではありません。認証状態や入力項目、同等機能のまとめ方を含めて、最終的な対象数量を診断会社と確認します。

資料が未完成なら概算条件を分ける

画面遷移図やAPI一覧がそろっていない場合も、何も相談できないとは限りません。GMOサイバーセキュリティ byイエラエの公式FAQでは、デザインデータを使った概算に対応し、正式な見積りでは遷移図などの詳細資料が必要になる場合があると案内しています。これは同社の対応例であり、どの会社でも同じ資料だけで見積りが確定するという意味ではありません。

資料は「最新版」「作成中」「未作成」に分けて渡します。画面設計が固まっていても、管理者機能や外部連携が追加される予定なら、その部分は未確定です。概算の対象に含まれているか、変更時に再見積りになるかを確認します。資料の日付と版をそろえておけば、後から仕様が変わった際に、当初の前提との差分を説明できます。

開発途中で予算を確保したい場合は、予算検討用の概算が必要であることを伝えます。正式見積りをいつまでに確定したいか、対象一覧をいつ提供できるかも共有しましょう。現時点で断定できない数量を確定値として埋めるより、想定する範囲と未確定事項を分ける方が、追加確認の内容を把握しやすくなります。

依頼条件シートを一枚にまとめる

候補会社ごとに違う説明を送ると、比較の前提がずれます。先に共通の依頼条件シートを作り、各社のヒアリング様式にも同じ内容を転記すると整理しやすくなります。次の表は記入項目の例です。実在企業の案件や見積額ではなく、自社用に項目を調整するためのひな型として使ってください。

対象外は空欄にせず、判断が必要なものも記録します。例えば外部の決済基盤そのものと、自社が実装した連携部分は管理主体が異なります。自社の担当だけで試験の許可を出せない領域を区別し、診断会社へ確認する項目にします。対象一覧の合計だけでなく、この境界が見積りの前提になります。

条件シートには更新日と担当者を付け、変更した箇所が追えるようにします。権限の種類や公開予定日が変わったら、候補会社へ同じ版を送り直しましょう。古い版の見積書が混在したまま社内承認へ回ることを避け、回答を受けた日と、どの資料を前提にした回答かも一緒に残します。

窓口は社内の意思決定者と技術的な確認者を分けておくと、質問を回す先が明確です。会社選びの観点は脆弱性診断会社を比較するときの対象範囲と選定条件でも整理しています。会社の知名度だけで決めず、今回の依頼条件に対して具体的な回答が得られるかを見ていきましょう。

初回相談では秘密情報を渡さない

初回の見積相談では、担当者の連絡先、システムの用途、対象範囲の概要、資料の有無を伝えることから始めます。本番のパスワード、APIキー、顧客情報、実際の個人情報を含む画面データを、一般の問い合わせ欄やメール本文へそのまま書く必要はありません。画面資料にはサンプル値を使い、非公開情報は伏せた状態で相談しましょう。

詳細資料やテスト用アカウントが必要になった段階で、受領する担当者、利用目的、共有方法、保管・削除の条件を確認します。秘密保持の取り決めも、共有する情報に合わせて相談します。共有先が正規の窓口かどうかは、公式サイトに案内された連絡方法と照合し、届いたメールの案内だけで新しい送信先を信頼しないようにします。

診断会社による対象確認のアクセスと、実際の診断の許可も区別します。見積依頼だけで試験の実施まで依頼したことにならないよう、アクセスしてよい環境、確認する操作、連絡する時期を明らかにしておきます。まず送る情報を絞り、必要な資料を確認してから段階的に共有する流れが基本です。

受付開始に向けた準備は、無料の会員登録から進められます。診断の新規受付は現在準備中です。

脆弱性診断の見積りから依頼へ進む

同じ条件で内訳と除外範囲を比べる

見積書が届いたら、最初に共通の条件シートから変わった点を確認します。同じシステムでも、対象の数量、権限の種類、手動確認の範囲が違えば、総額の差には理由があります。「一式」の表記だけで比較を終えず、基本料金に含む作業と、別途料金になる作業を分けてもらいましょう。

比較表には、対象機能と数量の定義、ツールと手動の役割、対象外、納品物、説明や再診断、追加作業の条件を並べます。記載がない項目は「含まれる」と推測せず、「要確認」として質問します。一方の会社が除外している機能を、もう一方が検査する見積りなら、その差を残したまま安さだけで順位を付けないことが大切です。

比較の記入例として、見積りAは「一般利用者の機能のみ、修正確認は別途」、見積りBは「管理者の機能も含み、条件内で修正確認を実施」と書かれていたとします。これは実在する会社の見積りではありません。この場合は対象と支援の範囲が違うため、金額だけで比較する前に、管理者機能と修正確認を今回必要とするかを決めます。条件をそろえた再見積りを頼むか、差分を残して比較するかを社内で明らかにしましょう。

税の扱い、交通費や環境準備の費用、夜間・休日対応などの付帯条件も確認します。これらが必ず追加費用になるという意味ではなく、必要な対応がある場合に見積りへ反映されているかを確かめるためです。予算に合わないときは、重要な機能を残した段階実施や対象の見直しを相談し、今回確認しない範囲を記録しましょう。

報告書と再診断の条件を確認する

診断の結果をどう受け取るかは、発注前に確認したい条件です。報告書のサンプルを見せてもらい、検出箇所、影響、再現の説明、推奨する対応、未確認の範囲がどのように記録されるかを確認します。社内や開発委託先へ渡す資料として使えるか、取引先から指定された形式に対応できるかも質問しましょう。

修正後の確認は、初回の診断とは別に条件を整理します。サイバーセキュリティクラウドの公式FAQには、再診断に期限・回数・対象サービスの条件があり、対象追加や仕様変更などでは別途見積りになる旨が示されています。各社共通の条件ではないため、無料という表記だけでなく、自社が利用するメニューの対象と例外を確認してください。

例えば、報告書を受け取ってから修正するまでに時間がかかると、無償確認の期限に間に合わない可能性があります。確認できるのは指摘箇所だけか、関連機能まで含むのか、未修正の項目を後から再度確認できるかも見積り段階で聞いておきます。報告会、結果への質問対応、再診断の報告書の有無を分けると、開発側の作業計画にもつなげられます。

診断日と納品日を別に押さえる

日程は、診断を開始できる日と、必要な報告書がそろう日を分けて確認します。公開日の直前を診断日にすると、結果の整理や改修、修正確認の時間が残らない場合があります。社内の承認日や取引先への提出日から逆算し、診断会社だけでなく開発・運用担当者の予定も合わせましょう。

見積りを取る段階では、対象資料を渡す日、環境へのアクセス確認、診断期間、速報と正式報告書の予定、修正確認の候補日を並べます。速報と正式な報告書の提出時期は同じとは限りません。納期の目安が書かれていても、対象の規模や環境準備によって前後するため、今回の条件でいつ提出できるかを確かめます。

環境の準備が遅れた場合の扱いも重要です。診断中に大きな仕様変更が入ると、当初の対象との差分確認が必要になります。日程の確定条件、対象を変更できる期限、延期やキャンセルの費用、見積書の有効期限を確認しておくと、発注後の認識違いを減らせます。緊急の問題が見つかった際の連絡先も、日程表に合わせて整理してください。

契約と実施許可を整えて発注する

依頼先が決まったら、見積書の対象範囲を契約や発注内容へ反映します。診断する環境、利用するアカウント、禁止する操作、実施時間、データの取扱い、障害時の停止連絡を確認します。第三者が管理する基盤や外部サービスは、自社の依頼だけで試験してよいと判断せず、必要な管理者や契約先に条件を確認しましょう。

診断は試験用の通信や操作を伴うため、影響を完全になくせると考えないことも大切です。検証環境の利用、テスト用データ、復旧方法などを、対象システムの事情に合わせて相談します。WAFやアクセス制限などの設定を変える必要がある場合も、変更する範囲と期間、元へ戻す担当を決め、恒久的な解除を前提にしないようにします。

発注後に対象追加が必要になったときは、差分の範囲と料金、日程への影響を文書で確認します。作業を先に進めてから精算するのではなく、追加の承認が必要な条件をそろえておくことが重要です。診断後は結果を開発・運用担当者へ渡し、対応する項目、保留する理由、修正確認の予定まで管理します。

脆弱性診断の見積りは条件をそろえる

脆弱性診断の見積りは、価格表を集めるだけではなく、何を確認して何を受け取るかを合意するための準備です。目的と対象、操作や通信の一覧、資料の完成状況を整理し、概算で残っている条件を正式見積りまでに確かめましょう。複数社の比較では、範囲と除外、報告書、再診断、日程と追加作業の扱いを同じ項目で並べます。

まずは依頼条件シートの空欄を確認し、分からない点を技術担当者や候補会社へ質問するところから始められます。セキュリティーナビの会社検索・比較・紹介機能は準備中です。また、会員向けの公開サイト診断と、専門会社へ個別に発注する診断は別のサービスです。会員向け診断の新規受付も現在準備中であり、ここで紹介した見積りや契約の確認を代替するものではありません。