すぐ直せない課題。例外の理由と見直し日を記録する

例外は安全になったという意味ではない。残す影響を責任者が理解し、期限と再判断の条件を決める。

例外を、未対応の隠し場所にしない

NCSCのリスク管理の資料は、業務の目的に沿ってリスクを評価し、軽減、受容、移転、回避などの判断を行う考え方を説明しています。SONAEは、すぐに対策できない一件について、判断した理由と残る影響を見える形にする方法を提案します。例外の登録は、安全になったという宣言ではありません。対策の依頼が止まっているだけの状態と、責任者が条件を確認して認めた状態を同じ欄にしないことが出発点です。

対象と、通常のルールとの差を狭く書く

会社全体の更新を延期するという説明では、どこまで例外が及ぶか分かりません。架空の例では、特定の業務端末一台について、対応ソフトの確認が終わるまで移行できない状況を対象にします。対象の識別、使う仕事、通常なら必要な対策、例外を求める理由を記録します。同じ名前の端末や後から追加されたサービスへ、自動的に例外を広げないようにします。関連する接続や扱う情報が変われば、前提も確認し直します。

残る影響と、代わりの対策を並べる

対策を遅らせる間にどの仕事や情報へ影響があるか、分かる範囲と未確認を分けます。利用する範囲を狭める、公開を避ける、確認を増やすなどの案は、実際に可能か担当が判断します。代替策を付けたことだけで、元の対策と同じ保護になったとは言いません。会社の判断に必要な費用、停止時間、移行先の条件を添えます。影響を誇張して急がせることも、業務の都合だけで小さく見せることも避けましょう。

判断する人と、監視する人を決める

残るリスクを認める責任者と、例外中の変化を見る担当を明確にします。IT担当だけが黙って引き受ける形にはしません。外部の保守会社へ相談しても、会社の業務上の判断がなくなるわけではありません。誰がどの情報を確認して認めたか、条件付きなら何を満たす必要があるかを残します。判断の権限がない人の返事を、承認として記録しないようにします。承認待ちの間に使ってよい範囲も別に決めましょう。

期限のほかに、途中で戻す条件を設ける

期限だけがあると、状況が悪化しても見直しまで待ってしまう場合があります。新しい脅威情報、公開範囲の変更、代替策の失敗、担当の交代など、再判断が必要な変化を決めます。延期を繰り返す場合は、前回から何が変わり、どの移行作業が進んだかを確認します。日付を更新するだけで承認を延長しないようにしましょう。例外を終える方法は、元の対策を実施する、対象の利用を終えるなど、具体的な選択肢にします。

終了は、対策と業務の結果を確認して記録する

完了の目安は、対象が通常の条件へ戻ったか、または別の判断で終了したかを説明できることです。例外を一覧から消す前に、変更、確認者、結果、残課題を対応させます。終了した対象を再利用するときには、以前の承認をそのまま流用しません。この管理表はSONAEの運用例で、法令や契約の義務を免除する書類ではありません。必要な専門家への確認も含め、判断の理由と次に見る条件を引き継げる状態にしましょう。

相談前の確認表

• 例外の対象を具体的に限定する
• 残る影響と代替策の限界を書く
• 責任者と途中の見直し条件を決める
• 延期と終了の根拠を残す

参考資料（確認日：2026年10月23日）：NCSC：10 Steps — Risk management ↗

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