脆弱性診断の頻度はどう決める？変更イベントごとに見直す判断表

脆弱性診断の頻度を、年に一度のような固定回数だけで決めようとすると、対象資産や機能が変わった場合の扱いが分かりにくくなります。変更がない場合と、公開範囲・認証・外部連携が変わった場合では、確認すべき対象と優先順位が同じとは限りません。

結論から言うと、診断頻度は一律の回数ではなく、公開範囲・認証・連携・構成変更の影響から決めます。変更イベントを一覧にし、対象資産、利用者への影響、取り扱う情報、修正体制を同じ判断表で確認します。

診断を実施しない判断も、理由と次に見直す条件を残します。回数を先に固定するのではなく、何が変わったか、どの対象を見直すか、誰が判断したかを記録することで、関係者が同じ前提で検討できます。

本記事で分かること

• 頻度を左右する変更イベント
• 変更の影響と優先順位の見方
• 実施・見送りを判断表に残す方法
• 次回見直しの条件の決め方

結論：変更イベントから見直す（早見表）

診断頻度は一律の回数ではなく、公開範囲・認証・連携・構成変更の影響から決めます。変更の種類と対象を記録し、実施するか、追加情報を確認するか、次の見直しに残すかを関係者で判断します。

頻度を左右する変化

対象資産の変化を把握してから優先度を決めます。何かが変わったという事実だけで実施の結論を急がず、変更がどの画面・機能・連携・利用者に関係するかを対象表に対応付けます。

公開範囲の変更

公開範囲に変更があった場合は、新しい画面、公開経路、利用者、関連する連携先を一覧に追加します。公開されたことだけで自動的に診断対象と決めず、管理者、利用目的、承諾範囲、変更の安定度を確認します。対象外にする場合も、理由と見直す条件を残します。

Webアプリ診断の対象範囲を参照し、公開画面、認証後の機能、API、外部連携を分けて整理します。対象表を更新したら、発注条件に影響するか、既存の報告書の対象外だったかを確認します。公開範囲の変更と実施判断を別の欄に残すことが重要です。

認証・権限の変更

認証や権限に変更がある場合は、どの利用者区分、どの機能、どのデータに関係するかを整理します。権限名だけで判断せず、利用者が行う操作、認証後に使う画面、関連するAPIを対象表に対応付けます。変更の管理者と承諾範囲も確認します。

テスト用アカウントや実施条件が変わる場合は、対象の確認方法も見直します。変更が小さく見えても、対象となる利用者や連携が変わる場合は、判断表に記録します。実施するかどうかにかかわらず、変更内容と判断の根拠を残せば、次の見直しで経緯を確認できます。

外部連携の変更

外部連携が追加・変更された場合は、連携先の管理者、利用目的、自社が確認できる範囲を整理します。外部サービスを利用しているだけの場合は、自社だけで対象に含めません。対象に関する承諾を得る窓口と、発注仕様へ反映する担当を確認します。

連携変更では、対象となるAPIや画面だけでなく、実施時間帯や変更管理の制約が変わる場合があります。対象表、連携一覧、連絡体制を見直し、何を追加確認するかを記録します。連携先が変更されたという事実と、診断の対象として確定したという判断を分けて管理します。

見直しの優先順位を決める

影響と変更の大きさを同じ表で確認します。利用者への影響、取り扱う情報、修正体制を分けて記録し、対象ごとに誰が判断するかを決めます。

利用者への影響

優先順位を考えるときは、変更がどの利用者、業務機能、公開範囲に関係するかを確認します。利用者が多いか少ないかだけで決めず、どの機能を使い、どの担当が説明できるかを整理します。対象表に利用目的と管理者を記載すると、変更の影響を共有しやすくなります。

判断表には、確認済みの事実と、確認が必要な事項を分けて書きます。影響が分からない項目は、推測で優先順位を決めず、確認先と期限を残します。実施の判断をする担当は、技術的な変更と業務上の影響を同じ対象表で確認します。

取り扱う情報

取り扱う情報に関する変更がある場合は、どの機能・権限・連携で扱うかを整理します。情報の名称だけでなく、管理する担当、利用者、対象環境を記録します。診断頻度を法律上の固定義務として扱わず、自社の対象と変更の状況を踏まえて見直します。

情報の扱いが変わる場合は、対象表、運用記録、取引先への説明に影響するかを確認します。新しい情報を扱うことになったからといって、すべての対象を同じ条件で扱うのではなく、関係する画面・機能・連携を特定します。判断の理由と確認日を残します。

修正体制

修正体制では、変更や診断結果に対応できる担当、通常時の連絡窓口、判断が必要な場合の相談先を確認します。対象が変わっても修正や再確認の担当が決まっていなければ、実施後の対応を予定に入れにくくなります。発注前に体制を整理します。

セキュリティ診断の発注ガイドを参考に、対象、実施条件、成果物、連絡体制を同じ仕様表にそろえます。判断表に修正体制を入れることで、対象の変化だけでなく、対応できる状態かも確認できます。

実施記録を残す

診断しなかった対象も、判断理由を含めて残します。対象一覧、実施判断の根拠、次回見直しの条件を分けて保管し、変更があったときに前の判断を確認できるようにします。

対象一覧

対象一覧には、対象資産、管理者、利用目的、認証や連携の有無、対象外にした理由を記載します。診断を実施した対象だけでなく、候補として確認したが今回含めなかった対象も分けて残します。対象外の理由があれば、後から見直すときに確認の経緯を追えます。

対象一覧は、資産の棚卸しと発注仕様を結び付ける資料です。新しい画面や連携が追加された場合は、一覧を更新し、既存の対象表との差分を確認します。対象名だけでなく、管理者と確認日を残すことで、判断を担当者の記憶に依存しにくくなります。

実施判断の根拠

実施する場合も見送る場合も、変更内容、影響、確認した担当、判断日を記録します。「前回から変更がない」と考えた場合も、どの対象を確認したか、誰が確認したかを残します。見送りを空欄にすると、後から実施済みと未確認を区別しにくくなります。

判断の根拠は、対象ごとに整理します。変更がある対象と、変更がない対象を一つの結論にまとめず、必要な確認を分けます。未確認の事項がある場合は、確認先と次の判断時点を記載し、完了のように扱わないことが重要です。

次回見直しの条件

次回見直しの条件には、新規公開、認証・権限の変更、外部連携の追加、環境や管理者の変更などを記載します。回数や日付だけを固定せず、どのイベントが起きたら対象表を見直すかを関係者で共有します。運用の変化を発見した担当が連絡する窓口も決めます。

プラットフォーム診断の費用構造を参照し、対象単位や成果物の条件を比較表で確認します。次回見直しの条件を残せば、対象や構成が変わったときに、どの資料と見積条件を更新すべきかを判断しやすくなります。

まとめ

脆弱性診断の頻度は、固定回数ではなく、公開範囲、認証・権限、外部連携、構成の変更イベントから見直します。対象と影響、修正体制、実施・見送りの根拠を記録し、次に見直す条件を残すことで、判断を共有しやすくなります。

頻度の判断と発注準備は、セキュリティ診断の発注ガイドと、進め方の記事一覧から確認できます。