インシデントの時系列を残す。発生・発見・判断の時刻を分ける

いつ起きたか、いつ知ったか、誰が何を判断したかを別の欄へ。後から訂正しても履歴を残す。

最初に気付いた時刻を、発生時刻にしない

NCSCの対応計画は、事象、作業、連絡などの記録と追跡を重視しています。SONAEは、小規模な会社でも使える経過表として、事象の時刻、気付いた時刻、記録した時刻を分ける方法を提案します。社員が朝に不審な送信を見つけても、実際の送信は前夜かもしれません。分からない時刻を推測して一つの欄へ埋めず、未確認として残します。発見の連絡が早かったかどうかも、異なる時刻を区別しなければ評価できません。

時計の基準と、情報の出どころを添える

NCSCの技術対応資料は、記録の時刻やタイムゾーンをそろえる重要性も説明しています。自社の表には、表示の基準、参照したログや報告、取得した担当を残します。日本時間の連絡とUTCのログを、そのまま同じ時刻として並べません。変換した場合は、元の値を参照できるようにします。端末の時計がずれていた可能性も、確認せずに補正しないことが大切です。正確な秒まで分からない報告には、その精度の限界を書きます。

事実・申告・推測を区別する

管理画面に残る記録、社員から聞いた操作、担当が考える原因は、それぞれ確認の仕方が違います。架空の例では、九時に社員が送信を発見し、九時十分に窓口が受け付け、前夜の送信時刻を記録で確認した、と別々に書きます。侵入が前夜だったという結論は、その送信だけでは確定しません。誰が述べた情報か、どの根拠と照合したかを付け、担当が交代しても推測が事実へ変わらない経過表にしましょう。

判断と実行にも、独立した行を使う

利用停止を決めた時刻と、実際に設定を変えた時刻、効果を確認した時刻を分けます。承認が出たから停止できた、操作が完了したから全経路で反映した、という省略を避けます。担当、対象、承認の記録、観測した結果を対応させます。業務への連絡や代替の手配も、技術操作と同じ経過表から参照できると判断がつながります。操作した人の記憶だけに頼らず、途中の失敗や取り消しも残すことが重要です。

訂正は、古い説明を消さずに行う

後から新しい事実が見つかったら、変更した内容、理由、確認者、訂正時刻を残します。最初の表をきれいな結論へ書き換えるだけでは、当時どの情報で判断したかが分からなくなります。閲覧者と編集者を決め、秘密や個人情報を必要以上に一枚へ集めないようにします。調査用の詳しい原本と、経営者へ共有する経過の要約を分け、同じ事象の番号でたどれる形にします。外へ渡す場合は、承認と共有の範囲を確かめます。

次の担当が再構成できることを目標にする

完了の目安は、発見から現在の判断までを、根拠と未確認を含めて次の担当が追えることです。行数の多さや空欄の少なさだけを品質にしません。終息後は、連絡が滞った時間や確認が重複した場所を見直します。演習でも架空の時刻と報告を渡し、時計の違いを誤って一つにしないか確認できます。経過表を作ったことを侵入原因の特定や証拠の法的な適格性の保証にせず、調査を支える記録として使いましょう。

相談前の確認表

• 発生と発見を同じ時刻にしない
• 元の値とタイムゾーンを残す
• 判断・実行・反映の確認を分ける
• 訂正前の情報と理由をたどれるようにする

参考資料（確認日：2026年10月23日）：NCSC：Your cyber incident response processes ↗ ／ NCSC：Develop — Technical response capabilities ↗

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