ペネトレーションテストのレポートの書き方｜経営層に伝わる報告書作成術

ペネトレーションテストを実施し、診断レポートが届いたものの、専門用語だらけで内容が理解できず困っていませんか。CVSSスコアや脆弱性の詳細な技術解説を見ても、結局どこから対応すればいいのか判断できず、経営層への報告に悩む担当者は少なくありません。この記事では、ペネトレーションテストのレポートを正しく読み解き、ビジネスリスクに翻訳して経営判断に活かすための報告書作成術を解説します。

ペネトレーションテストのレポートに必ず含まれる5つの構成要素

ペネトレーションテストのレポートには、一般的に5つの主要な構成要素が含まれています。それぞれの役割を理解することで、レポート全体を正しく把握できます。

エグゼクティブサマリー（経営層向け要約）

エグゼクティブサマリーは、経営層が最初に目を通すべき1〜2ページの要約部分です。ここには技術的な詳細ではなく、診断結果の全体像とビジネスへの影響が簡潔にまとめられています。

具体的には以下の内容が記載されます：

• 診断対象システムの概要
• 発見された脆弱性の総数と深刻度別の分布
• 最も重大なリスクと推奨される対応
• 全体的なセキュリティ評価（例：5段階評価）

IPAの調査によると、経営層の約7割が技術詳細よりもビジネスへの影響を重視しているため、このセクションが適切に作成されているかが報告書の価値を左右します。

診断スコープと実施内容

この部分では、何を対象に、どのような方法で診断を実施したかが明記されています。診断範囲が明確でないと、「調べていない部分にもリスクがあるのでは」という誤解を招く可能性があります。

記載される主な項目：

• 診断対象のシステム・ネットワーク範囲
• 使用したテスト手法（ブラックボックス/ホワイトボックス）
• 診断期間と実施時間帯
• 除外項目や制約事項

例えば、ECサイトのペネトレーションテストで「決済システムは対象外」と明記されていれば、その部分のセキュリティは別途検証が必要だと判断できます。

発見された脆弱性リスト

診断で発見された脆弱性が、CVSSスコア（Common Vulnerability Scoring System）に基づいて一覧化されています。CVSSは脆弱性の深刻度を0.0〜10.0の数値で評価する国際標準です。

一般的な分類：

• 緊急（Critical）：CVSS 9.0〜10.0 → 即座に対応必須
• 重要（High）：CVSS 7.0〜8.9 → 早期対応が必要
• 警告（Medium）：CVSS 4.0〜6.9 → 計画的に対応
• 注意（Low）：CVSS 0.1〜3.9 → 余裕があれば対応

ただし、CVSSスコアだけで優先順位を決めるのは危険です。自社のシステム環境や扱うデータの性質によって、実際のビジネスリスクは異なるためです（詳しくは後述）。

詳細な技術的解説と再現手順

このセクションは開発者やシステム管理者向けの技術情報で、各脆弱性について以下が詳述されます：

• 脆弱性が存在する箇所（URL、ソースコードの行数など）
• 攻撃者がどのように悪用できるか
• 実際に攻撃を再現した手順とスクリーンショット
• 悪用された場合の具体的な影響

例えば、SQLインジェクションの脆弱性であれば、「ログイン画面の入力フォームに特定の文字列を入力することで、データベースの全顧客情報を取得できる」といった具体的な攻撃シナリオが示されます。

このセクションは技術的に高度なため、経営層への報告では別紙として添付し、要点のみを抜粋して説明するのが効果的です。

推奨される対応策と優先順位

発見された脆弱性に対して、具体的な修正方法と対応の優先順位が提示されます。単に「脆弱性がある」と指摘するだけでなく、「どう直せばいいか」まで示されることで、実際のセキュリティ改善につながります。

記載される内容：

• 各脆弱性に対する技術的な対策方法
• 対応の緊急度（即時/1ヶ月以内/3ヶ月以内など）
• 暫定対策と恒久対策の両方
• 対応にかかる想定工数や難易度

質の高いレポートでは、「ファイアウォールのルールを変更する（即時対応可能）」や「アプリケーションの根本的な設計変更が必要（2〜3ヶ月）」など、対応の現実性まで考慮した提案がなされています。

経営層に伝わるレポート作成の3ステップ

ペネトレーションテストのレポートをそのまま経営層に提出しても、専門用語の壁で理解されないケースが多いです。ここでは、技術的な診断結果を経営判断に活かせる形に変換する3つのステップを解説します。

【STEP1】ビジネスリスクへの翻訳

最も重要なのは、脆弱性を「金銭的損失」や「事業継続リスク」というビジネス言語に翻訳することです。経営層は「SQLインジェクションがある」と言われても具体的な危機感を持ちにくいですが、「顧客10万件の個人情報が流出し、損害賠償と信用失墜で推定5億円の損失が発生するリスク」と説明すれば理解が進みます。

翻訳の具体例：

IPAの「情報セキュリティ10大脅威 2024」によると、情報漏洩の平均被害額は約6億円と報告されています。こうした統計データを活用することで、リスクの規模を具体的にイメージしてもらえます。

【STEP2】対応優先度のマトリクス化

脆弱性が複数ある場合、「緊急度」と「影響度」の2軸でマトリクスを作成すると、どこから対応すべきか一目で分かります。CVSSスコアだけでなく、自社環境での実際の影響度を加味して評価することが重要です。

マトリクスの作成方法：

• 縦軸：影響度 → 顧客データ/売上/ブランドへの影響が大きいか
• 横軸：緊急度 → 悪用される可能性が高いか、すぐ対応できるか
• 右上（影響大×緊急高） → 最優先で対応
• 左下（影響小×緊急低） → 余裕があれば対応

例えば、「外部から誰でも攻撃可能な顧客データベースの脆弱性（CVSS 9.5）」は右上に配置される一方、「社内ネットワークの奥にある開発用サーバーの軽微な設定ミス（CVSS 6.0）」は左下に配置されます。CVSSスコアが高くても、攻撃経路が限定されていればリスクは相対的に低いという判断です。

この可視化により、経営層は「まず右上の3つに予算を集中投下し、残りは次四半期に対応」といった具体的な判断ができるようになります。

【STEP3】アクションプランの具体化

最後に、対応策を「誰が・いつまでに・いくらで実施するか」まで明確にしたアクションプランを提示します。「対策が必要」で終わらせず、実行可能な計画まで落とし込むことが重要です。

アクションプランの記載例：

このように期限と予算を明示することで、経営層は「今期の予算で対応できるか」「追加予算が必要か」を判断でき、承認プロセスがスムーズに進みます。

また、「暫定対策（1週間で実施可能）」と「恒久対策（3ヶ月かかるが根本解決）」の両方を提示すると、短期的なリスク低減と長期的な改善を両立できます。

よくある誤解と報告書作成時の注意点

ペネトレーションテストのレポートを扱う際、いくつかの誤解が対応の遅れや誤った判断につながることがあります。ここでは特に注意すべき3つのポイントを解説します。

「脆弱性ゼロ」を目指すのは非現実的

ペネトレーションテストで脆弱性が見つかると、「全てをゼロにしなければ」と考える方がいますが、完璧なセキュリティは存在せず、全ての脆弱性を解消するのは非現実的です。

重要なのはリスクベースアプローチ、つまり「ビジネスに与える影響が大きいリスクから優先的に対応する」という考え方です。例えば、CVSS 3.0の低リスク脆弱性を完璧に直すために2ヶ月かける間に、CVSS 9.0の緊急度が高い脆弱性を放置してしまっては本末転倒です。

情報処理推進機構（IPA）の「組織における内部不正防止ガイドライン」でも、**「リスクをゼロにすることは不可能であり、許容可能なレベルまで低減することが目標」**と明記されています。

経営層への報告では、「全ての脆弱性を解消します」ではなく、「重大なリスクを優先的に対応し、残存リスクは継続監視します」という現実的な方針を示すことが信頼につながります。

CVSSスコアだけで判断してはいけない理由

CVSSスコアは脆弱性の深刻度を示す重要な指標ですが、あくまで汎用的な評価であり、自社環境での実際のリスクとは異なる場合があります。

具体的な例：

• CVSS 8.0のリモートコード実行の脆弱性があっても、そのサーバーが外部ネットワークから完全に隔離されていれば、実際の攻撃リスクは低い
• CVSS 5.0の情報漏洩の脆弱性でも、クレジットカード情報や医療記録など機密性の高いデータを扱うシステムなら、ビジネスへの影響は甚大

IPAが公開する「共通脆弱性評価システムCVSS概説」でも、**「CVSS基本値は環境に依存しない評価であり、実際の対応優先度は現状評価基本値や環境評価基本値を加味すべき」**と説明されています。

そのため、報告書では「CVSSスコア」に加えて、「自社環境での評価」を併記することが推奨されます。例えば「CVSS 7.5（一般評価）/ 自社評価：重要度★★★★☆（顧客データへの影響大）」のように表現します。

技術詳細を経営層に見せない方がいい場合

ペネトレーションテストのレポートには、攻撃の再現手順やソースコードレベルの詳細が含まれていますが、経営層への報告でこれらを全て提示すると、かえって混乱を招きます。

経営層が知りたいのは「何が問題で、どう対応すべきか」であり、「どのような技術でハッキングされたか」ではありません。技術的な詳細は開発チームや外部ベンダーとの調整に必要ですが、経営判断には不要です。

効果的な報告方法：

• 本編：エグゼクティブサマリー、ビジネスリスク、アクションプランのみ（5〜10ページ）
• 別紙（技術詳細）：脆弱性の詳細、再現手順、ソースコードなど（参考資料として添付）

この構成により、経営層は意思決定に必要な情報だけを短時間で把握でき、技術担当者は別紙を参照して具体的な対応作業を進められます。

ペネトレーションテストと脆弱性診断の違いを説明に含める

報告の際、「ペネトレーションテスト」と「脆弱性診断」の違いを明確にすることも重要です。両者はしばしば混同されますが、目的とアプローチが異なります。

• 脆弱性診断：既知の脆弱性を網羅的にチェックする健康診断のようなもの
• ペネトレーションテスト：実際の攻撃者の視点で侵入を試み、複数の脆弱性を組み合わせた攻撃シナリオを検証する

例えば、「脆弱性診断では個々の穴を見つけるが、ペネトレーションテストではその穴をどう悪用できるかまで検証する」と説明すると理解されやすいです。この違いを報告書の冒頭で説明することで、「なぜこのテストが必要だったのか」の根拠が明確になります。

実際のレポート例と社内報告テンプレート

理論だけでなく、実際の現場でどのように報告されているのかを知ることで、より実践的なレポート作成が可能になります。ここでは業種別の報告事例と、すぐに使えるテンプレートを紹介します。

製造業での報告事例

ある製造業A社では、生産管理システムのペネトレーションテストを実施した結果、工場の稼働を止める可能性のある脆弱性が発見されました。

報告のポイント：

• ビジネスリスクへの翻訳：「外部からの不正アクセスにより生産ラインが24時間停止した場合、生産損失は約3,000万円、納期遅延による違約金が約1,500万円発生するリスク」
• 具体的な対策：「産業用ネットワークと業務用ネットワークの物理的分離（工期2週間、費用500万円）」と「ファイアウォールの設定変更（即日対応可能、費用0円）」の2段階提案
• 経営層への説明：「まず即日対応でリスクを80％低減し、2週間後の設備停止日に恒久対策を実施」という段階的アプローチを提示

この報告により、経営層は「生産を止めずにリスク対策できる」と判断し、即座に承認されました。製造業では**「生産停止リスク」という経営にとって最も重要な指標で説明する**ことが効果的です。

医療機関での報告事例

医療機関B病院では、電子カルテシステムのペネトレーションテストで、患者情報の漏洩リスクが発見されました。

報告のポイント：

• 法的リスクの明示：「個人情報保護法違反により、漏洩1件あたり最大5万円の損害賠償、さらに病院の信用失墜により患者数が減少するリスク」
• 規制への対応：「厚生労働省の『医療情報システムの安全管理に関するガイドライン』で求められる水準を満たしていない」と明記
• 具体的な対策：「アクセスログの監視強化（月額30万円）」と「二要素認証の導入（初期費用200万円）」を提案

医療機関では法令遵守と患者の信頼が最優先されるため、「コンプライアンス違反のリスク」と「患者への影響」を前面に出した報告が効果的です。経営層は「訴訟リスクを回避できる」という観点で判断し、予算が承認されました。

すぐ使える社内報告用テンプレート

以下は、パワーポイント1枚で経営層に報告する際のテンプレート構成です。このフォーマットに沿って作成すれば、技術的な知識がない経営陣にも伝わりやすくなります。

【スライドタイトル】ペネトレーションテスト結果報告と対応方針

1. 診断結果サマリー（左上）

• 診断対象：○○システム（△△サーバー）
• 実施期間：2024年○月○日〜○日
• 総合評価：★★☆☆☆（5段階中2）

2. 発見された脆弱性（中央）

3. ビジネスへの影響（右上・赤枠で強調）

• 顧客データ○万件が漏洩した場合、推定被害額：約○億円
• サービス停止による機会損失：1日あたり約○○万円

4. 対応方針と予算（下部）

このテンプレートの特徴は、左上から右下へ視線が流れるZ型レイアウトで情報を配置し、経営層が短時間で「何が問題で、どう対応するか」を把握できる点です。色は赤（緊急）・黄（重要）・青（通常）で分類し、視覚的にも分かりやすくします。

まとめ

この記事では、ペネトレーションテストのレポートを経営層に伝わる形に再構成する方法を解説しました。重要なポイントは以下の3つです。

• ビジネスリスクへの翻訳：技術的な脆弱性を金銭的損失や事業継続リスクという言葉で説明することで、経営判断の材料になります
• 優先順位の明確化：CVSSスコアだけでなく、自社環境での実際の影響度を加味し、対応優先度をマトリクスで可視化することが重要です
• 実行可能なアクションプラン：「誰が・いつまでに・いくらで対応するか」を明記することで、経営層の承認がスムーズになります

ペネトレーションテストのレポートは、技術的な脆弱性情報をビジネスリスクに翻訳することで初めて価値を発揮します。「脆弱性ゼロ」を目指すのではなく、リスクベースアプローチで優先順位をつけ、段階的に対応する方針を示すことが現実的です。

次のステップとしては、まず自社で受け取ったレポートを見直し、この記事で紹介したテンプレートを使って経営層向けの1枚資料を作成してみることをおすすめします。技術詳細は別紙にまとめ、意思決定に必要な情報だけを簡潔に提示することで、セキュリティ対策の承認と実行が加速するはずです。