担当者不在でも使える復旧手順。記録と見直しの進め方

入口、前提、承認、止める条件、結果をそろえ、次の担当が迷う場所を見つける。

操作の順番だけでは、引き継げないことがある

NCSCの対応計画の資料は、連絡先、判断、記録、特定の場面に対応する手順などを説明しています。SONAEは、復旧手順を作るとき、何を入力して実行するかだけでなく、いつ使い、誰が認め、何を見て次へ進むかを書く方法を提案します。担当者の記憶がないと読めない略語や画面名を減らします。すべてを一枚へ詰め込むのではなく、緊急時に必要な入口と、製品ごとの正式な手順への参照を整理しましょう。

最初のページに、対象と前提を置く

対象の業務、想定する停止、使ってよい条件、利用するバックアップ、復元先、必要な担当を載せます。別の障害にも同じ手順が使えると推測しないよう、対象外も書きます。架空の例では、誤削除した資料を別の場所へ戻す手順と、侵害が疑われるアプリを戻す計画を分けます。認証や鍵、必要なソフトの管理先は参照として残し、秘密の値を本文へ貼りません。手順書が読める人の全員へ秘密を配る構成にしないことが大切です。

一つの段階に、入力・判断・結果をそろえる

何が必要か、誰が操作するか、何が出ればよいか、違う場合にどう止めるかを段階ごとに書きます。成功する画面だけの写真集にしません。表示が変わったときやエラーが出たときは、正式な窓口へ戻せるようにします。試験用の値を本番の値と取り違えない表記も必要です。製品の手順を参照する場合は、確認した版や日付と、自社の前提を残します。古い画面と違うからという理由で、担当が勝手に広い権限を使って進めない計画にしましょう。

読める場所も、停止の影響から考える

手順書の保存先、連絡先、認証の入口が、使えなくなる仕組みの中だけにないかを確認します。非常時の参照方法と、更新する原本を決めます。紙や別の保管先を用意する場合も、古い版が残り続けない管理を考えます。必要な人だけが参照できる条件と、担当不在でも引き継げる条件を両立させます。この制作で秘密や顧客の実データを複製することはありません。架空の手順書から、入口と承認の担当を説明できるかを確認します。

別の担当に、机上で読んでもらう

作成者が説明を足さなくても、目的、対象、前提、次の判断が分かるかを確かめます。実際の復元を行わず、架空の結果を渡す読み合わせでも、不明な用語や欠けた連絡先を見つけられます。読めたことと実操作で成功したことは別に記録します。分からない段階を推測で進めず、質問と回答、直した内容を残します。担当者が不在の状況を演習へ入れ、承認や問い合わせが一人だけに依存していないかも確認しましょう。

変更した日と、確かめた日を区別する

手順書の所有者、改訂日、確認した製品の条件、演習日、未検証の箇所を記録します。アプリや認証、保存先、契約が変わったら、影響する段階を見直します。完了の目安は、次の担当が判断の入口をたどれ、操作の結果と限界を追えることです。手順書を作成したという一件だけで、復旧の準備全体を完了にしません。読み合わせ、限定した試験、業務の受入をそれぞれ残し、改善を続ける資料にしましょう。

相談前の確認表

• 対象と使ってよい条件を書いた
• 期待結果と停止の条件を付けた
• 手順と秘密の保管を分けた
• 別担当の読み合わせと未検証を残す

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

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