「対応済み」を誰が確かめる？改善後の記録の残し方

依頼を出した、設定を変えた、意図した結果を確かめた。それぞれの状態を記録に残す。

対応したという返事の、対象を確かめる

NCSCの侵入テストの指針は、結果を組織の弱点管理の改善へつなぐことを重視しています。SONAEは、その後の作業を確認する際、元の指摘番号と変更した対象を対応させる方法を提案します。依頼の受付、実施、反映の確認、業務の受入を一つの対応済みにまとめません。誰かが直したと言ったことを疑うためではなく、同じ対象と結果を見ているかをそろえるためです。元の条件が変わっている場合も、先に確認しましょう。

何が変わったかを、元の条件から照合する

外部共有の見直しなら、対象の資料、リンクや権限、利用者、確認した時点をそろえます。別の資料で開けなかった結果や、違うアカウントで見た画面を、元の課題の解決として扱いません。変更した設定の名前だけでは足りない場合は、意図した状態を担当が説明します。架空の例では、共有リンク一件の終了と、社内担当が正規の権限で参照できることを組にします。具体的な確認方法は利用製品と承認された範囲で決めます。

実行する確認には、影響と許可が必要になる

レポートの指摘を再確認するためでも、無断の侵入試験や実送信を行ってよいわけではありません。対象、方法、実行する人、利用者への影響、止める条件を合意します。画面や記録で確認する項目と、限定した試験が必要な項目を分けましょう。試験のために広い権限を追加し、結果だけ通す方法は避けます。今回の制作で使う例はローカルの架空対象で、実顧客の設定やアクセスを確認した結果ではありません。

反映待ちと、確認できない理由を残す

変更がすぐ全体へ反映するとは限りません。製品の条件、参照する記録、確認した時刻を残し、まだ確かめられない場合は確認待ちにします。必要な権限がない、担当の回答がない、対象が利用されていないなどの理由も区別します。証拠を増やすためだけに機密画面を広く保存せず、必要な担当が参照できる記録を選びます。確認できなかった状態を、報告の締め切りの都合で合格へ置き換えないようにしましょう。

技術の結果と、仕事が続くことを両方見る

望ましくない権限を減らしても、必要な社員まで使えなくなれば別の影響が生じます。業務の担当が通常の入口で必要な作業を続けられるかを確認します。運用ルールの改善なら、変更した文書の存在だけでなく、連絡する役割と受ける窓口が同じ理解かを確かめます。すべての仕事を一度に試したと主張せず、選んだ範囲と限界を残します。作業の完了を、将来も設定が変わらない保証にしないことが大切です。

閉じる根拠と、再び見る条件を付ける

完了の目安は、元の指摘、変更、確認方法、結果、確認者、残課題がつながっていることです。委託先が作業する場合は、会社と相手の結果確認の分担も合意します。暫定の対応なら、その期限と本来の改善を続けて追います。次の担当は、閉じた理由から、どの変更があれば再確認すべきかを理解できます。単に一覧の完了件数を増やすことより、意図した改善と業務の結果を、同じ根拠で説明できることを目標にしましょう。

相談前の確認表

• 元の指摘と同じ対象を確認する
• 再確認の方法と影響を合意する
• 反映待ちと未確認を合格にしない
• 業務の結果と閉じる根拠を残す

参考資料（確認日：2026年10月23日）：NCSC：Penetration testing — scope and follow-up ↗ ／ NCSC：Choosing a managed service provider ↗

一般的な説明とSONAEの運用提案です。製品の公式条件と自社の管理責任者の判断を確認してください。