脆弱性診断のベンダー切り替え｜引継ぎで確認する対象・報告・未解決事項

脆弱性診断の依頼先を切り替えるとき、前回の対象や実施条件が分からないまま新しい見積書を受け取ると、何が変わったのかを比較できません。会社の評価から始めるより、前回確認した対象、対象外、過去報告、未解決事項、再確認条件を引継ぎ表にすることが先です。

結論から言うと、ベンダー切り替えでは会社評価より先に、前回の対象・未解決事項・報告条件を引継ぎ表にします。前回と今回の対象差分を明示し、過去報告は必要な担当者だけで安全に扱い、新しい発注条件を改めて合意します。

引継ぎ表を作れば、前回の条件をそのまま使うのではなく、現在の資産、認証、連携、変更予定に合わせて見直せます。この記事では、対象情報、過去報告、新しい発注条件を分けて整理する方法を説明します。

本記事で分かること

• 前回と今回の対象差分の残し方
• 過去報告と未解決事項の扱い
• 共有・保管・返却の条件
• 新しい見積・再確認・連絡条件のそろえ方

結論：前回条件を引継ぎ表にする（早見表）

ベンダー切り替えでは、前回の対象、対象外、実施条件、報告、未解決事項を引継ぎ表にします。今回の対象表と並べ、何が同じで何が変わったかを確認してから新しい発注条件を作ります。

引き継ぐ対象情報

前回の対象と今回の対象の差分を明示します。資産と範囲、認証・実施条件、対象外の記録を分け、前回の資料を現在の対象表へ対応付けます。

資産と範囲

前回の対象情報から、資産、画面、機能、認証後の範囲、API、外部連携を引継ぎ表へ写します。名称だけでなく、どの業務機能に関係するか、誰が管理するか、どの環境で確認したかを記録します。今回の対象表と並べ、追加・削除・変更を分けます。

前回の対象をそのまま今回の前提にしません。管理者、利用目的、構成、認証・連携の条件が変わっている場合は、対象表を更新します。セキュリティ診断の発注ガイドを参照し、目的、対象、承諾、成果物を現在の条件でそろえます。

認証・実施条件

認証・実施条件では、利用者区分、テスト用情報、対象環境、実施時間帯、通常時と判断時の連絡先を確認します。前回使用した情報や環境が現在も使えるとは限らないため、対象ごとに管理者と条件を見直します。変更予定がある場合は、確認する版と連絡方法を記録します。

実施条件を引き継ぐ際は、前回の制約と今回の制約を同じ欄で比較します。たとえば連携先の管理者が変わった、認証後の機能が増えた、運用時間が変わった場合は、今回の依頼条件として整理します。前回の記録を保管することと、今回の条件を確定することを分けます。

対象外の記録

対象外の記録には、前回確認しなかった資産・機能・権限・外部連携と、その理由を残します。今回も対象外にするのか、管理者や条件の変更により見直すのかを引継ぎ表で判断します。対象外を空欄にせず、前回の範囲との違いを説明できる形にします。

Webアプリ診断の対象範囲を参照し、対象と対象外を画面、権限、API、連携ごとに整理します。対象外を引き継ぐ場合も、誰が確認し、どの変更があれば再評価するかを記録します。新しい依頼先には、現在の対象表を基に条件を伝えます。

過去報告を安全に扱う

未公表の弱点を広く配布せず、必要な担当者だけで確認します。共有できる報告、未解決事項、保管・返却条件を分け、前回の報告を今回の発注条件へ必要な範囲で反映します。

共有できる報告

過去報告を共有する場合は、誰が何の目的で確認するかを整理し、共有可能な範囲を決めます。実在の対象情報や未公表の詳細を広く配布するのではなく、発注条件を確認するために必要な担当者だけが扱う体制にします。共有する資料と共有しない資料を分けます。

新しい依頼先へ情報を渡す場合も、対象、確認時点、今回の条件との関係を整理します。前回の報告書をそのまま新しい仕様に置き換えず、今回の対象表のどの行と関係するかを確認します。共有前に保管・返却の条件と窓口を決めます。

未解決事項

未解決事項は、前回の対象、対応状況、現在の担当、確認が必要な点を引継ぎ表に残します。未対応の理由を一般化せず、対象の変更、修正予定、確認すべき条件を整理します。新しい依頼先に伝える情報は、必要な範囲と共有条件を確認して決めます。

未解決事項を今回の対象に含める場合は、対象、実施条件、報告・再確認の条件を新たに合意します。前回と同じ対象に見えても、版、認証、連携、管理者が変わっていれば前提が変わります。引継ぎ表で差分を確認し、今回の判断として記録します。

保管・返却条件

保管・返却では、過去報告をどこに保管し、誰が閲覧し、共有後にどう扱うかを整理します。自社の情報管理のルールと契約上の条件を確認し、保管する担当、返却を確認する担当、質問窓口を決めます。保管場所と共有範囲を別の項目にします。

保管・返却の条件を引継ぎ表に残すことで、前回の資料を扱う担当が変わっても経緯を確認できます。新しい依頼先へ渡す資料は、今回の対象・条件と関係するものに限定します。確認が終わった後の扱いも、発注前に関係者で確認します。

新しい発注条件をそろえる

再確認、報告会、連絡フローを改めて合意します。前回の条件を参考にしつつ、今回の対象、実施制約、成果物、連絡体制を新しい仕様表へ整理します。

見積前提

見積前提には、現在の対象、対象外、環境、認証後の範囲、連携先、承諾窓口を記載します。前回の対象表と差分がある場合は、どの変更が今回の条件に関係するかを明記します。前回の見積書だけで比較せず、今回の対象表をすべての依頼先へ渡します。

脆弱性診断の費用構造を参照し、対象、確認の深さ、実施条件、成果物、再確認を同じ比較表で確認します。前提差がある場合は、質問事項として残し、同じ条件として扱いません。

再確認条件

再確認条件では、修正した対象、関連する変更、確認する版、結果を受け取る担当を決めます。前回の再確認の記録がある場合も、今回の対象と条件に合うかを確認します。修正担当と確認担当が異なる場合は、対応表に役割を記載します。

再確認しない範囲がある場合は、理由と次に見直す条件を残します。対象・版・連携が変わった場合は、当初の対象表との差分を記録します。前回の結果を今回の完了条件として扱わず、今回の発注条件として整理します。

連絡窓口

連絡窓口は、通常の質問を受ける担当と、判断が必要な場合の相談先を分けます。依頼先が変わると、連絡方法や共有する資料の条件も変わるため、前回の窓口情報をそのまま使いません。通常時、変更時、発見時の連絡先を今回の条件表に記載します。

窓口が不在の場合の引継ぎ先も決め、対象や条件の変更を誰が記録するかを整理します。連絡体制を発注前に合意しておくと、実施中や報告後の質問を対象表の条件に沿って確認しやすくなります。

まとめ

脆弱性診断のベンダー切り替えでは、前回の対象、対象外、実施条件、過去報告、未解決事項を引継ぎ表にします。機微情報の共有範囲と保管条件を決め、現在の対象差分を確認してから、再確認・報告・連絡の新しい発注条件をそろえましょう。

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