ペネトレーションテスト外部委託｜脆弱性診断との違いと発注判断

「経営会議でペネトレーションテストの実施が決まった」「取引先の監査でペンテストを求められた」——そんな状況で委託先を探し始めた発注担当者の多くが、最初につまずくのが費用と提案内容のばらつきです。同じ「ペネトレーションテスト」という言葉を掲げる会社でも、見積もりは100 万円台から数千万円まで幅があり、提案書に書かれている「シナリオ」「レッドチーム」「TLPT」などの用語も会社ごとに定義が微妙に違います。

さらに悩ましいのは、脆弱性診断とペネトレーションテストの違いが分かりづらいことです。脆弱性診断は定期的に実施している企業も多く、費用も数十万〜200 万円程度に収まりますが、ペンテストになると桁がひとつ増える。「本当にペンテストでないとダメなのか」「脆弱性診断で足りるのではないか」と社内で問われても、専門家でない発注担当者が自信を持って答えるのは簡単ではありません。

しかも発注は一度で終わりません。委託先を選び、スコープを決め、事前情報を提供し、実施中の連絡ルートを整え、報告書を受け取ってから開発会社・運用担当・経営層それぞれに展開する——ここまでを見通しておかないと、報告書を受け取った瞬間に「これをどう使えばいいのか」で止まってしまいます。

本記事では、ペネトレーションテストを外部委託する発注担当者に向けて、脆弱性診断との使い分けの判断フロー、委託先3タイプの見極め方、費用が数百万〜数千万円と幅広くなる構造、依頼から報告書受領・再テストまでの発注者側タスクリスト、そして陥りやすい失敗パターンと回避策を、会社ランキング型ではなく発注実務ガイドの視点で解説します。読み終えたときに、脆弱性診断で十分なケースはそちらを勧め、ペンテストが必要なケースでは自信を持って予算とスコープを組み立てられる状態を目指します。

ペネトレーションテストの外部委託とは？発注者が最初に押さえたい要点

ペネトレーションテスト（侵入テスト）の外部委託とは、「攻撃者の視点で、特定のゴール（顧客情報の窃取・特権昇格・業務停止など）を達成できるかを検証してもらう」ことを、専門会社に依頼する行為です。ツールでのスキャンを中心にする脆弱性診断とは目的が異なり、実際の攻撃シナリオを組み立てて手動で試行する「疑似攻撃演習」だと理解すると輪郭が掴みやすくなります。

発注者視点で脆弱性診断の委託と比較すると、費用は数十万〜200 万円程度から数百万〜数千万円へと桁が変わり、期間も 1〜2 週間から 1〜3 ヶ月に伸びます。成果物も「発見した脆弱性の一覧」から「攻撃シナリオの再現ログ・侵入経路の相関・悪用可能性の評価」へと変わります。委託先に求められるスキルセットも、スキャン精度から攻撃者視点でのシナリオ設計力・レッドチーム経験にシフトします。

こうした違いを踏まえずに「とりあえずセキュリティ会社に依頼すればよい」と進めると、脆弱性診断で十分な案件に高額なペンテスト予算を割いてしまったり、逆にペンテストを名乗るがスキャン中心のサービスを購入してしまったりする事故が起きます。まずは発注者が押さえるべき要点を整理します。

前提として、ペネトレーションテストそのものの概念や脆弱性診断との違いをより体系的に理解したい方は、基礎を解説したペネトレーションテストとはもあわせて参照してください。本記事はその先の「委託の実務」に集中します。

ペネトレーションテストの外部委託で得られるもの・得られないもの

外部委託で得られるものは、大きく次の3つです。

• 自社の資産（Web アプリ・内部ネットワーク・クラウド環境・従業員端末など）に対して、想定される攻撃シナリオがどこまで通用するかの実証結果
• 発見された脆弱性の単体評価ではなく、複数の弱点を組み合わせた「侵入経路の相関」と、それが業務・顧客データにどこまで到達するかの影響評価
• 攻撃再現ログを含む報告書と、経営層・開発担当・運用担当それぞれに展開できる推奨対策

逆に「得られないもの」も明確にしておく必要があります。ペネトレーションテストは、依頼したスコープ内で「決められた期間内に見つかった攻撃経路」を示すものであり、そのシステムに脆弱性が存在しないことを保証する試験ではありません。同時に、24 時間 365 日の常時監視・脅威検知の役割も担いません。恒常的な監視は SOC 運用・EDR・SIEM など別の仕組みで担保するものだと切り分けて依頼することが、発注品質の起点になります。

発注者がまず整理すべき3つの前提

委託先に相談を始める前に、以下の3点を社内で言語化しておくと、見積もりと提案の質が大きく変わります。

• 実施目的: 監査・ガイドライン対応か、標的型攻撃を想定した実戦検証か、リリース前の受け入れ検証か。目的が違えばシナリオ・報告書の書き方・報告会の相手も変わります
• 対象システムの範囲: Web アプリ 1 本か、内部ネットワーク全体か、クラウド環境（AWS・Azure・GCP のアカウント構成含む）か、従業員端末や物理侵入まで含めるか
• 制約条件: 実施可能な時間帯（本番影響を避けるための夜間・休日のみか）、テスト環境を用意できるか本番実施か、業務停止許容度、社内で共有できる範囲（レッドチーム型では社内広報を絞る）

この3点を整理せずに相見積もりに入ると、各社が自社の得意領域で提案を書いてくるため、金額と内容が比較不能な状態になります。最初の30 分をこの整理に投資することが、相見積もり全体の効率を左右します。

脆弱性診断とペネトレーションテストの委託上の違い｜どちらを外部委託すべきかの判断軸

競合記事の多くは「脆弱性診断とペネトレーションテストの違い」を概念比較で説明して終わりますが、発注者が本当に知りたいのは「自社のケースではどちらを委託すべきか」です。ここでは概念比較を委託実務の観点に置き換えたうえで、判断フローを提示します。

委託上の違いを比較表で整理する（費用・期間・成果物・委託先の選定軸）

同じ「セキュリティ委託」として扱いがちですが、発注者から見た違いを一枚にまとめると次のようになります。

費用レンジの出典: 中規模Webアプリの数十万〜数百万円レンジはLASSIC ペネトレーションテスト外注の費用相場、一般ベンダー依頼で数百万円以上・重要インフラ規模で数千万円規模との整理はGMO サイバーセキュリティ byイエラエ 費用解説、脆弱性診断側の費用感はY's ペネトレーションテストガイドを参考にしています。

費用・期間・成果物のいずれもひと桁違うため、「両方まとめて発注」と一括りにする前に、どちらが今回の意思決定に必要かを切り分ける必要があります。脆弱性診断の外注全般について整理したい場合は、姉妹記事の脆弱性診断の外部委託ガイドも参考になります。

どちらを外部委託すべきか｜判断フロー

次の順序で自問すると、多くのケースで委託種別が決まります。

1. 監査・ガイドライン・取引先要件で「ペネトレーションテスト」が名指しされているか
   • 名指しされている場合はペンテスト必須。ただし要件書に「脆弱性診断でも可」と書かれているケースもあるため文言を確認する
   • PCI DSS の一部要件、金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」等では TLPT（後述）が求められる場合がある（金融庁 諸外国のTLPTに関する報告書、東京都産業労働局 TLPT解説）
2. 対象システムに「重大インシデントで事業継続が困難になる資産」があるか
   • 顧客情報・決済・機密データ・基幹業務など、被害インパクトが極大の資産がある場合はペンテストの検討対象
   • なければまずは脆弱性診断で網羅的にカバーし、次年度以降にペンテストを検討する順序でよい
3. 脆弱性診断は直近で実施済みか
   • 未実施ならまず脆弱性診断を先に行う（既知の脆弱性が大量に残っている状態でペンテストしても「攻撃シナリオ以前の指摘」に埋もれて費用対効果が下がる）
   • 実施済みで指摘対応も終わっている場合は、標的型攻撃を想定したペンテスト実施の意義が出てくる
4. 社内に IR/対応体制が最低限あるか
   • ペンテスト報告書は「侵入経路の相関」を示すため、それを受けて修正計画を組める人員（自社または委託先）が必要。対応体制が整っていない場合は、まず脆弱性診断＋対応運用の型を作ることが優先

このフローで「今回はペンテストが必要」と判断できたら、次章以降の委託先選定と費用構造に進みます。逆に「今回は脆弱性診断で十分」と判断した場合は、脆弱性診断の外部委託や脆弱性診断とはを参照して、脆弱性診断側の発注準備に切り替えてください。無理にペンテスト予算を組む必要はありません。

併用が推奨されるケース（脆弱性診断→ペンテストの二段階発注）

実務では「脆弱性診断→修正→ペネトレーションテスト」の二段階発注が推奨されるケースが少なくありません。特に以下の状況では、二段階での発注を検討する価値があります。

• 直近 1 年以内に脆弱性診断を実施していない、または大規模改修があった
• 監査対応でペンテスト報告書が必須だが、既知脆弱性の残存状況が不明
• 予算は確保できるが、シナリオ設計に集中してもらいたい

先に脆弱性診断で「見つけやすい脆弱性」を潰しておくことで、ペンテスト側のリソースをシナリオベースの攻撃検証に集中させられます。二段階に分けると総額は増えるように見えますが、ペンテストの試行時間が既知脆弱性の再指摘に費やされる無駄を防げるため、実質的な費用対効果はしばしば高まります。

外部委託先の選定軸｜開発会社・脆弱性診断会社・ペンテスト専門会社の使い分け

ペネトレーションテストの委託先は、大きく3つのタイプに分けられます。同じ「ペンテスト対応可」と書かれていても、得意領域と苦手領域が明確に違うため、目的に合わせた選び方が必要です。

委託先の3タイプと得意領域

「Web アプリ 1 本の受け入れ検証」なら脆弱性診断会社の派生でも十分ですし、「グループ全体を対象にした標的型攻撃演習」ならペンテスト専門会社が本命になります。開発会社の系列は「実装コンテキストの共有コストを下げたい社内案件」向けで、監査対応など第三者性を求められる案件では選ばないほうが安全です。

選定軸チェックリスト

相見積もり時に評価すべき項目を、発注者側の観点でまとめると次のようになります。

• 実施実績業種: 自社と近い業界（金融・EC・SaaS・製造など）での実績があるか。業種特有の攻撃シナリオ（決済フロー悪用・在庫改ざん等）を組めるか
• 保有資格: OSCP・GXPN・CREST など攻撃者側視点の資格を保有するエンジニアが在籍しているか。組織として PCI DSS QSA・情報処理安全確保支援士などの資格を持つか
• シナリオ提案力: 見積書に「実施するシナリオ例」が具体的に書かれているか。「Web アプリ診断一式」だけの提案は避ける
• 第三者性: 自社開発物のペンテストなら、開発会社と別系列の会社を選ぶ
• 報告書サンプル: 実際の報告書サンプル（サニタイズ済み）を見せてもらえるか。攻撃シナリオ再現ログ・侵入経路の相関図が含まれているか
• 再テスト対応: 修正後の再テスト範囲と費用が事前に合意できるか
• NDA・データ取扱: 実施中に取得した情報の取扱い、実施後のデータ廃棄方針が契約に明記されているか
• 報告会の実施: 経営層向け・技術者向けに分けた報告会を実施してもらえるか

このチェックリストを 3 社の提案に当てはめると、金額差の意味が可視化されます。特に「シナリオ提案力」「報告書サンプル」の2 項目は金額に直結するため、必ず確認してください。

相見積もり時に必ず聞く質問リスト

見積もり金額の妥当性を判断するには、以下を全社に同じ表現で質問し、回答の差分を比較するのが有効です。

• スコープに含まれる対象（IP レンジ・URL・アカウント・クラウドリソース）と、明示的に含まれない除外項目は何ですか
• OSINT（オープンソースからの情報収集）は実施しますか。実施する場合、対象範囲はどこまでですか
• 攻撃シナリオは何本準備しますか。各シナリオの想定「ゴール」を具体的に教えてください
• 実施中に業務システムへ影響が出た場合の中断基準と連絡ルートを教えてください
• 報告書には「脆弱性一覧」だけでなく「攻撃再現手順」「侵入経路の相関図」「悪用可能性の評価」が含まれますか
• 修正後の再テストは含まれますか。含まれる場合、再テストの範囲と回数の上限はどう定義されますか
• 報告会は経営層向け・技術者向けに分けて実施してもらえますか

同じ質問を同じ形式で投げることで、各社が「何を含み・何を含まないか」を横並びで比較できるようになります。金額単独で判断するのではなく、単価×工数×提供物の3 次元で比較する足場ができます。

費用レンジと費用が変動する要因｜スコープと深度で予算を組み立てる

「ペネトレーションテストの費用は？」と問われれば、多くの会社が「100 万円〜3,000 万円」と回答します。この幅の広さは発注者を戸惑わせますが、幅が生まれる構造を理解すれば、自社の予算組みは可能です。

費用レンジ早見表

公開されている費用相場をもとに、対象範囲・深度別のおおよそのレンジを整理すると次のようになります。下表のうち、Webアプリ中規模および一般ベンダー依頼・重要インフラ規模のレンジは公開情報に基づく引用値ですが、内部ネットワーク・クラウド環境・レッドチーム演習の中間区分は本記事が公開情報と一般的な市場動向を参考に整理した目安値です。実際の見積もりは案件ごとに大きく変動するため、必ず複数社から個別に見積もりを取得してください。

出典: GMO サイバーセキュリティ byイエラエ 費用解説、LASSIC ペネトレーションテスト外注の費用相場、Y's ペネトレーションテストガイド。上記出典はいずれも「対象規模・シナリオ数・報告書粒度で費用が大きく変動する」と明記しており、レンジは参考値として扱ってください。

費用が変動する5つの要因

金額幅の 90% は次の 5 要因で説明できます。相見積もりの金額差を評価するときは、この 5 軸に沿って各社の提案を分解してください。

1. 対象範囲: URL 数・IP レンジ・アカウント数・クラウドリソース数が多いほど工数が積み上がる。ドメイン管理サーバーやクラウドの IAM を含めるかで大きく変わる
2. シナリオの深度: 「Web アプリ既知脆弱性の網羅」で終わるのか、「特権昇格→ドメイン管理者奪取→重要データ持ち出し」までシナリオで検証するのかで工数が倍以上変わる
3. シナリオ本数: 攻撃者役が事前に組み立てるシナリオが 2〜3 本か、10 本以上かで工数が変わる
4. OSINT・ソーシャルエンジニアリングの含有: 公開情報からの標的絞り込みや、フィッシング演習・物理侵入まで含めると別工数
5. 再テストの有無・範囲: 修正後の再テストを含むか、範囲を「初回で発見した項目に限定」するか「関連機能まで拡大」するかで再工数が発生

TLPT（Threat-Led Penetration Testing／脅威ベースのペネトレーションテスト）は、脅威インテリジェンスを起点にレッドチームが実際の攻撃者を模倣する高度な手法で、金融分野を中心に導入が進んでいます（金融庁 諸外国のTLPTに関する報告書、東京都産業労働局 TLPT解説）。TLPT はレッドチーム演習よりさらに深く、脅威インテリジェンスとブルーチーム（防御側）検証まで含めるため、費用は数千万円規模になることがあります。金融機関・重要インフラ以外で TLPT を選択する必要は原則ありません。

予算を抑える工夫

「今期の予算が限られているが、経営や監査の要件は満たしたい」というケースでは、以下の工夫で総額を抑えられます。

• スコープの段階的縮小: 全システムを一度に対象にせず、事業インパクトが大きい 1〜2 システムに絞る。次年度に別システムを追加する年次計画とセットにする
• 実施タイミングの分割: 1 回で全シナリオを実施せず、四半期ごとにシナリオを分ける（TLPT では逆に集中実施が推奨されるため注意）
• 過去診断結果の共有: 直近の脆弱性診断報告書を委託先に共有し、既知指摘の再確認工数を削減する
• 報告書粒度の合意: 経営層向けサマリ・技術者向け詳細のみで、部門別展開資料は自社で作成する
• 再テスト範囲の事前定義: 「初回で発見した Critical/High のみ再テスト」等の合意で再テスト費用の上限を確定させる

コストは削っても、シナリオ設計の質と報告書の質は削らないのが原則です。「安く済ませたペンテスト」の報告書は経営層への説明に耐えず、結局その説明のために追加で第三者コメントを依頼する事態を招きます。

依頼から報告書受領・再テストまでの流れ｜発注者側のタスクリスト

ペンテスト委託の全体フローは、委託先が主体で動く部分と発注者が主体で動く部分が交互に発生します。発注者側で何をいつやるのかを可視化しておくと、進行の主導権を保てます。

委託の全体フロー（9ステップ）

一般的なペネトレーションテスト委託は、次の9ステップで進みます。

1. 要件整理: 実施目的・対象システム・制約条件を社内で整理する（前述の「発注者がまず整理すべき3つの前提」を明文化）
2. RFI/RFP 送付: 3 社程度に情報提供依頼または提案依頼を送る。この段階で前述の「相見積もり時に必ず聞く質問リスト」を統一しておく
3. 見積比較・委託先選定: 5 要因に基づく金額分解と選定チェックリストで比較する
4. 契約締結: NDA・実施範囲・除外項目・データ取扱・再テスト条件を契約書に明記する
5. キックオフ: 実施チーム・連絡窓口・緊急連絡ルート・進行スケジュールを合意する
6. 事前情報提供: 対象システム情報・アカウント・実施環境・関係者調整の情報を委託先に渡す
7. 実施: 委託先がシナリオを実行。発注者側は業務影響のモニタリングと緊急連絡ルートの維持
8. 報告書ドラフト・報告会: ドラフト受領後にフィードバック、経営層・技術者向けにそれぞれ報告会を実施
9. 再テスト: 修正完了後、合意範囲で再テストを実施し、対応完了を確認

このうち発注者が主体で動くのは 1・2・3・4・6・7 の一部・8 のフィードバック・9 の実施範囲確認です。委託先に「進行はお任せします」と丸投げすると、事前情報提供の遅延やスコープ齟齬が起きやすくなります。

事前準備で発注者が用意するもの

キックオフ後、次のステップで委託先に提供する情報を先取りしておくと、実施開始が遅れません。

• 対象システム情報: 構成図（システム間の連携）、対象 URL/IP、認証方式、外部連携先
• アカウント: テスト用アカウント（権限別に複数）、管理者アカウントを共有する場合の管理方針
• 実施環境: 本番相当のステージング環境を用意できるか、本番実施の場合の影響範囲と切り戻し方針
• 関係者調整: SOC 委託先への事前通知（誤検知回避）、社内広報の範囲（レッドチーム型では絞る）、開発会社への通知の要否
• NDA・情報取扱: 提供する情報の機密区分、実施後のデータ廃棄期限、報告書の社内共有範囲

特に SOC 委託先への事前通知は忘れやすいポイントです。ペンテスト実施を SOC に知らせずに開始すると、SOC 側が真のインシデントとして扱ってエスカレーションが走り、本番運用に混乱をもたらすことがあります。

実施中の進行管理

実施期間中の発注者側の主な役割は、次の 3 点です。

• 緊急連絡ルートの維持: 業務システムへの影響が疑われる事象が発生した場合、委託先の実施チームリーダーと発注者側の窓口が 30 分以内に連絡を取れる体制を維持する
• 業務影響の切り分け: 実施期間中に発生した障害・遅延が、ペンテストによるものか通常業務由来かを切り分ける。障害管理台帳に「ペンテスト期間中」のフラグを付与しておくと切り分けが速い
• 中断基準の共有: どのような事象が発生したら実施を一時中断するか（本番影響の閾値・監査対象データへの想定外アクセス等）を事前に合意し、実施期間中も社内で共有する

ここでの品質は、実施後の報告書の使いやすさに直結します。実施中に検知した業務影響を記録できていないと、報告書のシナリオ再現ログを見ても「業務側で何が起きたか」との突き合わせができず、修正計画の優先順位付けが難しくなります。

報告書の読み方と受領後の対応｜攻撃シナリオ再現ログをどう活かすか

ペネトレーションテストの報告書は、脆弱性診断報告書とは構造が大きく異なります。「見つかった脆弱性の一覧」だけでなく、「それらを組み合わせるとどこまで到達できたか」の再現ログが中心になります。この違いを踏まえて読み込まないと、報告書の価値を活かしきれません。

報告書の主要セクション

多くのペンテスト報告書は、以下のセクション構成をとります。

• エグゼクティブサマリ: 経営層向け。実施内容・主要な発見・ビジネスインパクトを 1〜2 ページで要約
• 発見脆弱性の一覧: 深刻度・CVSS スコア・影響範囲を含む
• 攻撃シナリオ再現ログ: 各シナリオがどのステップで進み、どこで停止したかの時系列記録
• 侵入経路の相関図: 複数の脆弱性を組み合わせた侵入経路の可視化（グラフやツリー）
• 悪用可能性の評価: 発見脆弱性がシナリオでどこまで悪用可能だったかの評価
• 推奨対策: 短期・中期・長期に分けた修正案。技術的対策と運用的対策を含む

読解の要点は、「発見脆弱性の一覧」だけを読んで満足しないことです。ペンテストの本質的価値は「攻撃シナリオ再現ログ」と「侵入経路の相関図」にあります。個別の脆弱性が Low であっても、組み合わせて Critical な結果に至るケースを可視化してくれるのがペンテスト報告書の役割です。

経営報告・開発会社への修正依頼・運用改善の3方向への展開

報告書を受け取ったあと、発注者は次の 3 方向に情報を展開する必要があります。

• 経営報告: エグゼクティブサマリと悪用可能性評価を軸に、事業インパクトの説明と修正優先順位の承認を得る。CVSS スコアだけでなく「実際にゴールに到達できたシナリオ」を伝えることが重要
• 開発会社への修正依頼: 発見脆弱性の一覧・攻撃再現手順・推奨対策を渡す。特に再現手順は開発会社が「なぜ Low ではなく Critical と扱うのか」を理解する材料になる
• 運用改善: 侵入経路の相関図から、SOC 検知ルール・EDR ポリシー・アカウント権限管理などの運用側で対処すべき項目を抽出する

3 方向の展開を発注者側でリードできないと、報告書が「情シスの引き出しに眠る資料」で終わります。委託先に対しては、報告書ドラフト時点で「経営層向け・技術者向け・運用担当向けの 3 種類の展開資料を出せるか」を確認しておくと、社内展開の負荷が軽減されます。

再テストの実施タイミングと範囲合意

再テストは、修正が完了した項目に対して修正の有効性を確認するために行います。実施タイミングと範囲は次のように合意しておくのが実務的です。

• タイミング: 修正完了報告の受領から 2〜4 週間以内に実施。長期化すると開発会社側の記憶や関連コードの記憶が薄れる
• 範囲: 初回で発見した Critical/High の全項目 + 修正で影響が及ぶ関連機能。Medium/Low は再テスト対象外とするケースも多い
• 回数: 再テストは 1 回とし、再々テストは別見積もりとするのが一般的
• 成果物: 再テスト報告書は「初回報告書のどの項目が対応済みか」の対応表形式で受領する

再テストの範囲と回数を契約時に確定させておかないと、修正フェーズで追加費用が発生しやすくなります。契約書のドラフト段階で確認してください。

よくある失敗パターンと回避策｜発注時に避けたい5つの落とし穴

発注担当者がペネトレーションテスト委託でつまずくパターンは、実は 5 つに集約されます。事前に知っておくだけで、大半は回避可能です。

1. 脆弱性診断で十分な状況で高額なペンテストを発注してしまう: 「監査要件でペンテストと書かれているから」だけで判断せず、要件書の文言（「または同等の脆弱性診断」等）を確認する。前述の「どちらを外部委託すべきか｜判断フロー」を社内で共有し、経営層の説明資料に添えると意思決定の透明性が上がります
2. スコープ未確定のまま契約し追加費用が発生する: 「Web アプリ一式」「クラウド環境全体」のような曖昧な表現で契約すると、実施開始後に対象システムの追加が発生し追加見積もりになる。URL・IP・アカウント数・クラウドリソース ID を契約書別紙で列挙する
3. 開発会社に自作物のペンテストを頼み第三者性が担保できない: 監査対応や取引先要件の場合、第三者性が求められることが多い。開発会社の系列に頼む場合は、監査対応可否を事前に取引先・監査人に確認する
4. 実施環境と本番差分でシナリオが再現不能になる: ステージング環境でのペンテストは本番影響を避けられる反面、本番との差分（データ量・連携先・認証プロバイダ等）が大きいと重要シナリオが実行できない。本番実施か本番相当ステージングかの判断は、シナリオ設計に入る前に委託先と合意する
5. 報告書受領後の修正計画が組めず放置する: 報告書を受領しても、社内で修正計画を組めるリソース（自社開発チーム・保守委託先）が確保できていないと対応が進まない。委託先選定時に「報告会後の修正計画作成支援」の有無を確認し、必要ならスコープに含める

上記 5 点は、いずれも「発注準備段階で 30 分の議論」で回避できるものです。発注書を書き始める前に、この 5 点を社内で確認する時間を必ず取ってください。

まとめ｜自社に必要なのは脆弱性診断かペンテストか、次に取るべき3ステップ

本記事では、ペネトレーションテストの外部委託を、脆弱性診断との使い分け・委託先選定・費用構造・依頼フロー・報告書対応・失敗回避の観点で整理しました。最後に、発注担当者が次に取るべき行動を 3 ステップにまとめます。

1. 判断軸で自社に必要な診断種別を決める: 監査・ガイドライン要件、資産のインパクト、脆弱性診断の実施履歴、社内対応体制の 4 点から「今回はペンテストか脆弱性診断か」を判定する。脆弱性診断で十分な場合は無理にペンテスト予算を組まない
2. 委託先タイプとチェックリストで候補を絞る: 開発会社系列・脆弱性診断会社系列・ペンテスト専門会社の 3 タイプから、目的に合うタイプを選ぶ。相見積もりは 3 社程度に絞り、同じ質問リストで回答を並列比較する
3. スコープと費用構造を理解して相見積もり比較: 費用が変動する 5 要因（対象範囲・シナリオ深度・シナリオ本数・OSINT/SE の含有・再テスト有無）で各社の金額を分解し、単価×工数×提供物の 3 次元で比較する

ここまで整理できれば、経営層・監査対応担当・開発会社に対して「なぜこの委託先を選び、なぜこの予算なのか」を自分の言葉で説明できる状態になります。相見積もりの 3 社を客観的に比較でき、報告書受領後の対応まで見通せる状態が、発注担当者としての合格ラインです。

関連情報

外部委託の判断材料をさらに整理したい方は、発注者向けのお役立ち資料もあわせてご覧ください。要件整理・委託先評価・費用の考え方をまとめた資料をお役立ち資料一覧からダウンロードいただけます。

次のアクション

ペネトレーションテストや脆弱性診断の要件整理・委託先選定・スコープ設計にあたって、第三者視点での相談が必要な場合は、秋霜堂株式会社のお問い合わせフォームからご相談ください。要件の整理段階からご一緒できます。