脆弱性が見つかったときの連絡フロー｜診断発注前に決める窓口と初報

脆弱性診断中に問題が見つかった場合、誰へ連絡し、誰が判断し、誰が修正を進めるかが決まっていないと、対応の確認が止まりやすくなります。技術的な確認方法を細かく決める前に、連絡窓口、初報、記録、修正確認の役割を合意することが必要です。

結論から言うと、発見時の対応は、検査操作ではなく、連絡窓口・初報・記録・修正確認の役割を事前に決めます。診断会社、事業者、開発・運用の判断者を一つの連絡表にし、通常時と判断が必要な場合の窓口を分けます。

発注前に連絡表と案件記録の形式を用意しておけば、対象、確認時点、影響の整理、次の連絡予定を必要な担当者へ共有できます。取引先や利用者への連絡は、事業者側の判断者と契約・社内の手続きに沿って扱います。

本記事で分かること

• 発見時に決める連絡窓口と役割
• 初報に入れる対象・確認時点・連絡予定
• 対応判断と修正の分担
• 報告から再確認までの記録方法

結論：連絡窓口と初報を先に決める（早見表）

発見時の対応は、連絡窓口、初報、記録、修正確認の役割を事前に決めます。誰が最初に受け、誰が事業上・運用上の判断をし、誰が修正と再確認を担当するかを連絡表にします。

発見時の役割を分ける

診断会社、事業者、開発・運用の判断者を一つの連絡表にします。役割を一人に集めず、初報を受ける窓口、判断と承認、修正の担当を別に記載します。

初報を受ける窓口

初報を受ける窓口は、診断会社から最初の連絡を受け、必要な担当者へつなぐ役割です。通常の質問を受ける担当と、判断が必要な場合に連絡を受ける担当を分け、連絡方法と不在時の引継ぎ先を整理します。窓口は対象表と実施条件表を参照できる状態にします。

窓口は、連絡を受けた内容を一人で判断する役割ではありません。対象、確認時点、次の連絡予定を記録し、事業上・運用上の判断が必要な場合は決めた担当へ共有します。連絡先が変更された場合は、発注条件と連絡表を更新します。

判断と承認の担当

判断と承認の担当は、対象となる資産、利用者や業務への影響、次の対応を確認します。技術的な説明を受けるだけでなく、対象の所有・管理の関係、実施条件、取引先や利用者への影響を踏まえて判断します。誰が最終判断をするかを連絡表に記載します。

判断の途中で追加確認が必要な場合は、何を誰に確認するか、次の連絡をいつ行うかを案件記録に残します。未確認の事項を完了のように扱わず、相談先と期限を記録します。対象外だった範囲に関係する場合は、対象表を見直します。

修正の担当

修正の担当は、報告された対象と、自社の変更管理の単位を対応付けます。画面、機能、API、外部連携、運用設定などに複数の担当が関わる場合は、作業の窓口と完了を確認する担当を決めます。修正の状況は案件記録で追います。

Webアプリ診断の対象範囲を参照し、修正が画面、認証後の機能、連携先にどう関係するかを整理します。修正担当と初報の判断担当を同じ役割にせず、対象・判断・対応を分けて記録します。

初報に含める情報を決める

機微な詳細を広く共有せず、必要な事実と次の連絡予定を記録します。初報の項目を決めておくと、対象と確認時点、影響の整理、判断が必要な点を必要な担当者へ共有しやすくなります。

対象と確認時点

初報では、対象となる資産、画面、機能、連携、確認した時点、実施条件を記録します。詳細な検査手順や未公表の情報を広く共有するのではなく、判断に必要な対象と事実を整理します。発注時の対象表と照合できる形にします。

対象が明確であれば、誰が管理し、どの環境・版に関係するかを確認できます。対象外だった範囲や変更予定が関係する場合も、当初の対象表との差分として記録します。初報の内容と追加で確認する事項を分けます。

影響の一次整理

影響の一次整理では、対象がどの業務機能、利用者、連携先、運用に関係するかを記録します。最終的な優先順位や対応を初報だけで決めず、判断担当が確認するための情報として整理します。対象に関係しない推測や詳細を広く配布しません。

事業上・運用上の影響を確認する担当を決め、追加の確認が必要な場合は相談先と期限を記録します。初報を受けた担当は、対象表、実施条件、連絡体制に照らして、誰へ共有すべきかを判断します。未確認の事項は未確認として残します。

次の連絡予定

初報には、次に何を確認し、誰が判断し、いつ連絡する予定かを記載します。連絡時刻を固定の手順として一般化せず、対象、影響、関係者の状況に合わせて決めます。通常時の窓口と判断時の窓口が同じ情報を確認できるようにします。

セキュリティ診断の発注ガイドを参考に、対象、実施制約、連絡先、成果物を発注前にそろえます。次の連絡予定を案件記録に残せば、誰が何を確認するかを関係者で共有しやすくなります。

修正確認までの記録を残す

報告、対応、再確認を同じ案件記録で追えるようにします。連絡履歴、対応判断、再確認の結果を対象表と対応付け、どの対象がどの条件で確認されたかを記録します。

連絡履歴

連絡履歴には、初報を受けた時点、共有した担当、確認した対象、次の連絡予定を残します。誰がいつ連絡したかだけでなく、対象表のどの行に関係するかを対応付けます。連絡先や判断者が変更された場合は、連絡表と案件記録の両方を更新します。

連絡履歴を残すことで、同じ内容を複数の担当が別々に確認することを避けやすくなります。詳細を広く共有せず、必要な担当が対象と判断の経緯を確認できる形にします。未確認の事項は、確認先と次の対応を記録します。

対応判断

対応判断では、対象、影響の整理、判断した担当、次に行うことを記録します。技術的な説明と、事業上・運用上の判断を分け、誰が何を決めたかを残します。対象が変更された場合は、発注条件や対象表に影響するかを確認します。

対応の決定を一度の連絡で終わらせず、修正、共有、再確認のどこに関係するかを整理します。判断が保留の場合も、保留の理由と確認先を残します。案件記録を更新すれば、次の連絡で前提を共有しやすくなります。

再確認の結果

再確認の結果では、どの対象、環境、版、条件を確認したか、誰が結果を受け取るかを記録します。修正した対象と、関連する変更がある範囲を分け、当初の対象表との差分を残します。再確認しない範囲がある場合も、理由を記録します。

脆弱性診断の費用構造を参照し、対象、実施条件、報告、再確認を同じ表で確認します。案件記録に結果を対応付ければ、次の発注やリリース判断で、確認した条件を追いやすくなります。

まとめ

脆弱性が見つかったときの対応は、連絡窓口、初報、記録、修正確認の役割を発注条件として事前に合意します。対象・確認時点・影響の整理・次の連絡予定を案件記録に残し、報告から修正・再確認までを同じ対象表で追えるようにしましょう。

連絡体制の作成は、セキュリティ診断の発注ガイドと、進め方の記事一覧から確認できます。