2026.08.22

セキュリティ診断の選び方は？範囲・費用・進め方

経営リスクナビ編集部

セキュリティ診断（第三者チェック）の必要性は感じていても、脆弱性診断とペネトレーションテストのどちらを選ぶべきか、どこまでを対象にすべきかで判断が止まりやすいものです。対応を先送りすると、クラウドの公開権限や境界機器など「設定不備・未管理資産」を起点に、事故時の説明責任や取引先対応で不利益が出るおそれがあります。実際に、JPCERT/CCの公開情報ではインシデント受領件数が2014年20,284件とされ、増加傾向が読み取れます。以下では、セキュリティ診断の判断材料として種類の違い・対象の絞り方・進め方を示します。

セキュリティ診断の基本
- セキュリティ診断の位置づけ
- 脆弱性診断とペネトレーションテストの違い
必要になる背景とリスク
診断対象と手法を選ぶ
セキュリティ診断の進め方
レポート確認と対策の進め方
セキュリティ診断の費用と選定
よくある質問
セキュリティ診断への対応で次にすべきこと

セキュリティ診断の基本

セキュリティ診断の位置づけ

セキュリティ診断は、再構築したパソコン・サーバ・クラウド・ネットワーク等について、第三者である外部専門組織により「セキュリティが確保されているか」を確認する第三者チェックとして位置づけられます。自社だけの自己点検では見落としやすい設定不備や運用上の抜け穴を、外部視点で洗い出すことで、事故の予防（事前対応）と説明責任の補強につながります。

対象は、外部公開サーバや通信機器に対する脆弱性診断、社内ネットワークのネットワーク環境診断、クラウド移行後の「利用者側設定（公開権限・共有設定等）」の不備を確認するクラウド環境診断などに整理できます。また、サイバー攻撃だけでなく、内部からの情報漏えい、組織的・人的リスクを下げる目的で、ルールや権限、ログ管理等を含む全体的な診断（運用・組織面の点検）も実務上重要です。

脆弱性診断とペネトレーションテストの違い

脆弱性診断は、OS・ミドルウェア・Webアプリケーション・ネットワーク機器などに存在する弱点を洗い出し、どこに不備があるかを把握するための技術点検です。一方のペネトレーションテスト（侵入テスト）は、攻撃者の視点で侵入できるかを実際に試すことで、現状の対策の有効性（侵入が成立するか、ゴール到達が可能か）を確認する方法です。

参照情報でも、侵入テストは「弱点を把握する最もシンプルで効率的な方法」とされる一方、業務影響を考慮した調整・準備が必要で、診断範囲設定や疑似攻撃の事前準備、実施そのものに期間を要し、依頼から完了まで数カ月かかるのが一般的で「すぐに実施できるものではない」点が注意事項として示されています。したがって、

観点	脆弱性診断	ペネトレーションテスト
主目的	弱点の洗い出しと可視化	侵入可否・対策有効性の実証
進め方の特徴	定義した観点で広く点検し一覧化しやすい	攻撃シナリオに沿って連鎖悪用も含め深掘り
実務上の注意	検出結果の改修・再確認の運用設計が重要	業務影響を踏まえた調整が必要で完了まで数カ月が一般的

目的と実施特性の整理

のように、目的と時間軸・調整体制の違いを前提に使い分けるのが合理的です。

必要になる背景とリスク

サイバー攻撃とインシデントの増加

サイバー攻撃は報道ベースの印象論にとどまらず、インシデント対応支援を行うJPCERT/CCの公開情報からも増加傾向が読み取れます。JPCERT/CCが受領したインシデントは、2014年が20,284件で、2004年の5,196件と比べ約4倍とされています。攻撃対象領域（インターネット公開資産、VPN装置等の境界機器、クラウド設定、委託先経由の接続等）が広がるほど、設定不備や未管理資産が侵入口になりやすく、結果として攻撃機会も増えます。

このため診断は、単に「脆弱性があるか」だけでなく、資産管理やログ監視、アップデート運用といった周辺の管理も含め、侵入の糸口になりやすい箇所を優先して点検することが重要です。

法令とガイドライン対応の考え方

法令・ガイドライン対応は、単なる形式対応ではなく、事故時に「必要かつ適切な安全管理措置を講じていた」と説明できる状態を作る実務です。個人データの漏えい等を防ぐための安全管理措置は、個人情報保護法で「必要かつ適切な安全管理措置」を求める枠組みとして整理されます（個人情報保護法20条（個人情報保護法第20条））。

また、経済産業省とIPAのサイバーセキュリティ経営ガイドラインは、経営の観点でサイバーリスクに向き合う枠組みを示しており、第三者チェック（脆弱性診断等）を含む実効的な仕組みとして、対策の点検・改善を継続する考え方と整合します。さらに、CSIRT（インシデント対応組織）に関するJPCERT/CCのガイド類では、インシデント情報の受付窓口整備など、対外的な情報交換を一元的に扱うことが円滑な対応につながるとされています。

対応設計で押さえる実務ポイント

法令は「安全管理措置を講じる義務（個人情報保護法20条）」という枠に対し、診断結果・改修履歴・再診断結果を証跡として残す設計にします。
ガイドラインは「経営が関与して継続改善する」趣旨に合わせ、単発診断ではなく棚卸・脆弱性管理・教育・監視までを管理サイクルに組み込みます。
CSIRT等の体制整備は、インシデント発生時の窓口や判断の遅れを防ぐため、診断と並行して検討します。

個人情報・決済・医療情報で診断優先度が上がる判断基準

診断優先度は「漏えいしたら困る」ではなく、取り扱う情報の性質と、事故時の義務・影響の大きさで決めるのが実務的です。特に健康情報は、漏えい・滅失・毀損を防ぐための安全管理が重く扱われ、個人情報保護法上の安全管理措置（個人情報保護法20条（個人情報保護法第20条））に加え、健康情報についての安全管理の考え方（「安全管理6措置」等）を前提に運用設計が求められる領域です。

また、医療・決済に限らず、社内に広く存在する「情報資産」（人事・労務・給与、財務、業務データ等）は見えにくく、情報システム部門だけに押し付けると責任分界が曖昧になりがちです。参照情報でも、ネットワークプリンタや監視カメラのような周辺機器を含め、どの部門が管理するかが不明確だと、日常運用から将来計画まで担当が振り回されるリスクが示唆されています。

優先度が上がりやすい条件（例）

健康情報など要配慮性の高い情報を扱い、漏えい等のリスクに対する安全管理措置の説明責任が重い場合（個人情報保護法20条（個人情報保護法第20条））。
インターネット公開領域や外部接続点（VPN装置等）を持ち、侵入の糸口になりやすい資産がある場合。
部門・委託先をまたいで権限管理や保守責任が分散し、設定不備や未更新が起きやすい場合。

診断対象と手法を選ぶ

診断対象となるシステムの整理

診断範囲の設計は、まず資産管理（棚卸し）で「何があるか」を確定させることから始まります。参照情報でも、脆弱性管理状況の把握として「資産管理にて整理できたIT資産について普段から脆弱性情報の収集を行う」こと、脆弱性が判明したら「できるだけ早くパッチ適用や緩和策」を行うことが示されています。これは、診断（発見）と運用（修正・緩和）の接続が切れると、結局リスクが残るためです。

また、冗長化のための予備機でもアップデートを怠ると、障害時の切替で「脆弱性を放置した予備機」に置き換わり侵入される可能性があると指摘されています。診断対象を決める際は本番系だけでなく、切替先やバックアップ系、境界機器、管理用端末も資産として同列に扱うべきです。

棚卸しで最低限そろえる観点

インターネット公開資産（Web、API、公開サーバ、公開設定のクラウドストレージ等）。
境界・中継資産（VPN装置、ルータ、Firewall/UTM等）。
管理系資産（運用端末、管理者アカウント、監視・ログ基盤）。
冗長化・予備機・検証環境（切替時に弱点が顕在化しやすい領域）。

Webアプリケーションとクラウドの着眼点

Webアプリケーションは外部からの入力を受けるため、脆弱性があると攻撃が成立しやすい領域です。クラウドは、事業者側の基盤対策に加え、利用者側の設定ミスが事故に直結します。参照情報では、クラウドストレージの公開権限のミスにより、機密情報がネット上から広く閲覧・ダウンロード可能になるケースや、業務系クラウドの共有設定が「非公開」になっておらず、ゲストアカウント等で意図せず閲覧できるケース、URLリンクを知っていれば第三者が閲覧できる状態のまま機密データを置いてしまうケースが例示されています。

この前提に立つと、クラウド診断は「クラウドだから安全」ではなく、人的ミスが起こる前提で適宜監査する設計が重要です。

具体的な着眼点（例）

Web：CMSやWebアプリケーションの脆弱性対策が最新化されているか、管理アカウントの強度が確保されているか、WAF導入やログ取得・監視が整っているか。
クラウド：ストレージの公開権限、共有設定（非公開の徹底）、ゲストアカウントの権限、URL共有の扱い、SSO等によるアクセス制御が妥当か。
共通：ログ取得と閾値設定、EDRやSOCによる挙動監視等、検知と初動の仕組みがあるか。

本番停止を避けたい会社が診断範囲を絞るときの線引き

本番停止を避ける線引きは「診断をやらない」ではなく、業務影響を管理したうえで実施するという設計です。参照情報でも、ペネトレーションテストは業務影響への配慮が必要で、診断範囲設定を中心とした管理者との調整や疑似攻撃の事前準備が求められるとされています。

また、脆弱性対応では、パッチ適用の影響が懸念される場合に別途テスト環境を用意して影響有無を確認できることが示されています。診断も同様に、検証環境を用意して本番と切り離すのが最も安全です。

線引きの具体例

可能なら本番同等の検証環境で実施し、本番への高負荷スキャンや疑似攻撃を避けます。
本番で行う場合は、時間帯（業務影響が小さい帯）やリクエスト量、対象機能（更新系の抑制等）を事前に合意します。
ベンダー委託の場合、構築のみか保守まで含むかで「アップデートが放置される」事故が起き得るため、責任範囲（パッチ適用・設定変更・復旧対応）を契約仕様で明確化します。

セキュリティ診断の進め方

目的設定から見積取得までの流れ

見積精度を上げるには、目的・対象・制約を先に固め、同条件で比較できる形に整えることが重要です。特に、ペネトレーションテストは「即時に実施できるものではなく、依頼から完了まで数カ月かかるのが一般的」とされるため、目的が侵入実証なのか、まずは脆弱性診断で面を押さえるのかで、スケジュール設計が変わります。

見積取得までの実務フロー

実施目的を定義します（例：外部公開資産の第三者チェック、クラウド設定監査、侵入可否の実証など）。
対象資産を棚卸しし、診断対象（URL、グローバルIP、クラウドアカウント範囲、VPN装置等）と除外範囲を明文化します。
影響制約を整理します（本番可否、負荷制限、夜間実施、検証環境の有無、権限付与方式）。
比較条件を統一して複数社に提示し、診断範囲・手法・体制・再診断条件が同じ軸で比較できる見積を取得します。

手動診断と運用面診断の進め分け

技術面の診断だけでは、事故原因になりやすい「運用の抜け」を取り切れないため、手動診断（技術）と運用面診断（組織・プロセス）を分けて設計するのが実務的です。参照情報でも、サイバー被害だけでなく内部からの情報漏えいや人的リスクを回避する意味で、会社組織を網羅的にチェックする全体的な診断が重要とされています。

また、CSIRTに関するJPCERT/CCの整理では、インシデント情報を組織内外から受け付ける窓口整備により、対外的な情報交換を一元対応でき、結果として対応が円滑になるとされています。運用面診断では、このような窓口・連絡体制・判断権限の整理も対象になり得ます。

進め分けの要点

手動診断（技術）：専門家が攻撃手法やツール知識、パケット解析等のスキルを用いて深掘りし、自動検査では見落としやすい欠陥を評価します。
運用面診断（体制）：権限管理、ログ取得と閾値設定、教育、インシデント受付窓口など、ルールと実装が一致しているかを点検します。

情報システム部門・開発部門・法務が見積前にそろえる資料

見積前に資料をそろえる目的は、工数の算定精度だけでなく、診断実施の可否判断（本番影響、規約制約、責任分界）を早期に確定することです。参照情報では、アウトソーシング時に「保守までしてもらえると思っていたら構築のみの契約で、脆弱性が放置された」というケースがあり、ベンダー側の責任範囲を明確にする重要性が述べられています。

見積前に集約しておく資料（部門別）

情報システム：資産台帳、ネットワーク構成（VPN装置や境界機器を含む）、ログ取得・監視（閾値設定等）の現状、検証環境の有無。
開発：Web画面・API一覧、認証方式（SSO等）、テストアカウント準備、CMSやライブラリの更新方針。
法務・購買：委託契約の責任分界（構築のみか保守含むか）、診断行為の許諾（クラウド規約・委託先同意）、機密保持条件、再診断や瑕疵対応の取り決め。

レポート確認と対策の進め方

レポートの読み方とリスク優先順位

レポートは「検出された項目の羅列」ではなく、対策の順序を決めるための判断材料です。参照情報でも、外部からアクセスするためのネットワーク機器は一般的な侵入の糸口となりやすく、脆弱性対応が特に重要視されるとされています。つまり、同じ危険度表示でも、外部到達性（インターネットから到達できるか、境界機器か）や、対象資産の役割（認証基盤、重要データ保管）で優先度が変わります。

優先順位付けで見落としやすい観点

境界機器（VPN装置、ルータ、Firewall/UTM等）は侵入の糸口になりやすいため、優先度を上げて評価します。
予備機・冗長系もアップデート遅延が侵入口になり得るため、本番系と同等に扱います。
クラウドの公開権限や共有設定は、脆弱性というより設定事故で漏えいが成立するため、技術スコアだけでなく影響の大きさで判断します。

改修から再診断までの体制づくり

診断は「発見」よりも「是正して再確認する」までが価値です。参照情報の脆弱性管理でも、脆弱性が判明したら「できるだけ早くパッチ適用や緩和策」を行うこと、パッチ影響が懸念される場合はテスト環境で影響確認できることが示されています。診断レポートを受けた後は、同様に改修・緩和・検証を回す体制を作る必要があります。

改修から再判定までの役割分担

改修責任者（開発・インフラ）を定め、パッチ適用・設定変更・コード修正の担当を切ります。
影響確認のための検証環境や手順を用意し、本番影響が懸念される変更は事前検証します。
運用責任者が進捗とリスクをトラッキングし、外部到達性の高い領域から優先して是正します。
同条件で再診断（再スキャン・再検証）を行い、修正が有効であることを第三者的に確認します。

重大指摘でもすぐ改修できない場合の暫定対策と再判定の進め方

重大指摘が出ても、基幹業務の制約や改修リードタイムで即時修正できないことはあります。その場合は「放置」ではなく、暫定対策でリスクを下げ、再判定で効いていることを確認する流れに落とし込みます。

参照情報には、Webサイト対策としてWAFの導入、ログ取得とサイバー攻撃監視、クラウドではSSOの利用、CASBやSASEの利用、サーバではEDRとSOC活用による挙動監視などが例示されています。これらは恒久対策の代替ではありませんが、改修までの期間における現実的な緩和策になり得ます。

暫定対策と再判定の進め方

侵入経路になっている箇所に暫定防御を入れます（例：WAF、Firewall/UTM、EDR+SOC監視、SSO、CASB/SASE等）。
ログ取得と閾値設定を確認し、検知から初動までの運用（連絡・遮断・証跡保全）を定義します。
暫定対策が入った状態で再スキャンや設定検証を依頼し、攻撃がどこまで防げるかを再判定します。
恒久改修（パッチ適用・コード修正・権限設計見直し）を計画に落とし、完了後に再診断でクローズします。

セキュリティ診断の費用と選定

コストの目安と見積の比較軸

費用は「総額」ではなく、範囲・深さ・体制・再確認まで含めた比較軸で評価する必要があります。参照情報が示すとおり、ペネトレーションテストは調整・準備・実施に期間を要し、依頼から完了まで数カ月が一般的であるため、短期で回したい場合は脆弱性診断中心の計画にし、別途重要領域のみ侵入テストを設計するなど、時間コストも含めて投資判断します。

また、参照情報には脆弱性情報を発見した際の報告先として、複数企業が「無償」で窓口対応している一覧も示されています（例：株式会社ラックは24時間、全国・海外、無償など）。これは「診断費用」とは別ですが、脆弱性・インシデント周りは外部リソースをどう組み合わせるかで、必要な診断範囲や体制コストが変わり得ることを示唆します。

見積比較の軸（例）

診断範囲の定義が明確か（公開資産、VPN装置等の境界機器、クラウド設定範囲、検証環境の扱い）。
手動の深度（ビジネスロジック確認、認証・権限の確認、パケット解析等）と自動スキャンの役割分担が説明されているか。
業務影響への配慮（負荷制限、時間帯、ロールバック、事前調整）の記載があるか。
再診断・再判定の条件（回数、範囲、追加費用条件）が明記されているか。

ベンダー選定と定期診断の設計

ベンダー選定は、診断品質そのものに加えて、脆弱性管理・運用改善まで支えられるかという観点が重要です。参照情報では、脆弱性管理として「脆弱性情報の収集」「早期のパッチ適用や緩和策」「予備機のアップデート」「委託時の責任範囲確認」が挙げられており、診断後の改善が回らないと意味が薄れます。

また、診断を担う人材像の例として、脆弱性診断士のスキルとして「OS・ネットワーク・アプリ・DBの脆弱性知識」「パケットレベル解析」「ペネトレーションテストやツール知識」「一般的攻撃手法知識」に加え、「自組織のセキュリティアーキテクチャ知識」「脅威情報知識」「評価ツール活用能力」などが整理されています。提案書・体制説明で、このようなスキルセットをどの役割が担うかが説明されるかは、実務上のチェックポイントになります。

観点	設計の考え方
変更点起因のリスク	大型改修・新規公開・認証変更の前後は手動診断や侵入テストを優先します。
既知脆弱性への追随	脆弱性情報収集とパッチ適用の運用を回し、影響懸念は検証環境で確認します。
委託の責任分界	構築のみ/保守含むを契約で明確化し、アップデート放置を防ぎます。

定期診断を崩さないための設計観点

情報セキュリティサービス台帳の掲載有無をどう評価に使うか

情報セキュリティサービス台帳は、調達時に「最低限の品質管理・体制を満たすか」を説明しやすくする材料です。一方で、台帳掲載の有無だけで、自社の要件（クラウド設定監査、WAF運用、ログ閾値設計、EDR+SOC連携、CSIRTとの連携など）に合致するとは限りません。

参照情報には、脆弱性診断の担当（脆弱性診断士）に求められるスキルが表形式で整理されており、台帳のような外形基準に加えて、提案体制が自社課題に刺さるかを確認することが重要です。

台帳以外に併せて確認したい観点

境界機器（VPN装置等）やクラウド設定事故（公開権限・共有設定）まで含む診断経験があるか。
診断後の是正支援が「パッチ適用・緩和策・再判定」までつながる提案になっているか。
インシデント受付窓口やCSIRT連携など、運用面の整備に踏み込めるか（必要な場合）。

よくある質問

中小企業でもセキュリティ診断は必要ですか？

必要です。攻撃者は企業規模よりも「侵入しやすい公開資産や設定不備」を狙うため、運用体制が手薄になりやすいほど標的になり得ます。実際、JPCERT/CCが受領したインシデントが2004年5,196件から2014年20,284件へ約4倍とされるように、インシデントは増加傾向で、業種や規模を問わず「起きるもの」として備える必要があります。

まずは外部公開サーバやクラウド設定の第三者チェック（脆弱性診断・クラウド環境診断）から始め、ログ取得や権限管理など運用面の弱点も並行して可視化すると、限られた予算でも優先順位を付けやすくなります。

診断の頻度はどのくらいが目安ですか？

頻度は「変更のたびに弱点が生まれる」前提で、資産の性質と変更サイクルに合わせて設計します。参照情報が示す脆弱性管理では、脆弱性情報の収集を普段から行い、判明したら早期にパッチ適用や緩和策を取ることが重要とされており、診断もこの運用と組み合わせて回すのが現実的です。

また、パッチ適用の影響が懸念される場合は、別途テスト環境を用意して影響有無を確認できるとされているため、診断頻度を上げたい企業ほど、検証環境整備とセットで計画すると業務影響を抑えやすくなります。

SaaS利用でも診断対象になりますか？

なります。クラウドサービスでは、事業者側の基盤対策とは別に、利用者側の設定不備で情報漏えいが起こり得ます。参照情報でも、クラウドストレージの公開権限のミスで機密情報が広く閲覧・ダウンロード可能になるケース、共有設定が非公開になっておらずゲストアカウント等で閲覧できるケース、URLリンクを知る第三者が閲覧できる状態に置いてしまうケースが挙げられています。

したがって、SaaSそのものへの脆弱性診断というより、

SaaS利用時に診断・点検すべき利用者側領域

公開範囲（外部公開、リンク共有、ゲスト招待）の設定が最小化されているか。
アカウント・権限（退職者ID削除、不要権限の剥奪、SSO等の適用）が適切か。
ログ取得と監視（閾値設定等）ができているか。

のような「利用者責任範囲」を中心に、設定監査として実施するのが合理的です。

診断中にシステム停止は起きますか？

ゼロではありません。特に疑似攻撃やスキャンは負荷を発生させるため、対象や方法によっては遅延や停止リスクが生じます。参照情報でも、ペネトレーションテストは業務影響を考慮した調整や事前準備が必要とされており、影響を管理する前提で進めるべきです。

停止リスクを下げるには、パッチ影響確認と同様に検証環境を用意して影響有無を確認する考え方が有効です。本番で実施する場合も、範囲設定、負荷制限、時間帯の調整、復旧手順・連絡体制（窓口）の整備を事前合意し、万一の影響を最小化します。

セキュリティ診断への対応で次にすべきこと

セキュリティ診断は、第三者チェックとして「何を守るために、どの範囲を、どの手法で点検するか」を決める工程が投資判断の中心になります。脆弱性診断とペネトレーションテストは目的と実施特性が異なり、後者は依頼から完了まで数カ月が一般的である点も踏まえて、スケジュールと期待成果をそろえる必要があります。判断の軸は、外部到達性（公開資産・境界機器）、クラウド設定事故の起こりやすさ（公開権限・共有設定）、取り扱う情報の性質（個人情報保護法20条（個人情報保護法第20条）の説明責任）を掛け合わせて優先順位を付けることです。次のアクションとしては、資産棚卸しで対象を確定し、業務影響の制約（本番可否・負荷制限・検証環境）と委託時の責任分界（構築のみか保守含むか）を整理したうえで、同条件で見積を比較できる形に落とし込みます。個別のシステム構成や契約条件によって適切な範囲・手法は変わるため、必要に応じて情報システム部門・開発部門・法務を交えて、専門家に相談しながら進めるのが安全です。