障害時の情報発信を事後対応から運用能力へ　米英など6機関が指針

本稿は、CISAなど6機関の指針の要点を知り、自社の障害時コミュニケーションに活用したい実務者向けの記事です。本指針が示す最大の結論は、障害時の情報発信を事後対応ではなく平時からの運用能力として整備することです。実務上の要点には、曖昧な表現の排除、事実と調査中事項を分けた時刻付き更新、規制報告との同期が含まれます。

何が起きたか：CISAなど6機関による障害時コミュニケーション指針の策定

2026年9月2日、米国のサイバーセキュリティ・インフラセキュリティ庁（CISA）は、各国の治安機関と共同で実務指針を公表しました[1]。共同作成には、米連邦捜査局（FBI）、豪州ASD傘下のサイバーセキュリティセンター（ACSC）、カナダCCCS、ニュージーランドNCSC、英国NCSCが参加しています[1]。この指針は、IT（情報技術）やOT（Operational Technology：工場やインフラの設備を制御・運用する技術）が停止した際、事業者が明確で適時かつ正確な情報発信を行うための手順を示しています[1, 2]。

対象組織は、政府機関、連邦文民行政部門（FCEB：軍事機関を除く連邦政府の文民省庁）、州・地方・部族・準州政府（SLTT）、重要インフラ企業です[3, 4]。対象セクターには、重要製造、情報技術、エネルギー、水・廃水、運輸、通信が含まれます[3, 4]。想定される役割は、防御サイバーセキュリティ分析担当、経営層や幹部責任者、法務アドバイザー、技術サポート担当、インシデント対応担当、広報担当です[5]。

この指針が目指す最大の転換は、障害時の情報発信を単なる事後対応ではなく、事前の運用能力として整備する点にあります[6]。サービス事業者は、発動閾値（しきい値：対応を開始する基準値）やエスカレーション経路、通知テンプレート、訓練などを事前に整備しておく判断が求められます[6]。

なぜ今指針が必要なのか：複雑化するシステム障害と規制報告の交錯

指針が適用されるトリガー（発動契機）は、事業者が設定したインシデント閾値に達するか、これを超えるサービス停止です[7, 8]。停止の原因は、サイバー攻撃に限りません[7, 8]。人為的ミスや機器故障、自然災害などの非悪意の事象による障害も広く対象となります[7, 8]。さらに、攻撃の拡大を防ぐためにOTシステムを防御目的で隔離し、サービスの可用性が変化した場合も含まれます[7, 9]。

システム障害が発生した際、外部向けの情報発信は企業の法的義務と密接に交錯します[10, 11]。事業者は、インシデント報告規則や業種別義務、顧客と結んだSLA（Service Level Agreement：サービス品質保証契約）に直面します[10, 11]。そのため事業者は、広報メッセージを法務やコンプライアンス部門と整合させ、公開声明と規制当局向け報告の一貫性を保つ必要があります[10, 11]。

米国SECやEU NIS2など、複数の法域で報告義務が設けられています。たとえば米国証券取引委員会（SEC）の登録企業は、重要と判断したサイバーインシデントについて「Form 8-K Item 1.05」（重大サイバーインシデントの臨時報告書）を、重要性判断から原則4営業日以内に提出しなければなりません[14]。この報告は、米司法長官が国家安全保障や公共安全への重大なリスクがあると書面で判断した場合に限り遅延が認められます[14]。

欧州連合（EU）の「NIS2指令」（重要事業者にセキュリティ対策を義務付ける指令）の対象組織には、重大インシデント認知後24時間以内の早期警告、72時間以内の通知、1か月以内の最終報告という多段階の報告が義務付けられています[15]。事業者は、一般向けの情報開示と規制当局への報告を別個のトラックとして並行して動かしつつ、内容を正確に同期させる必要があります[15]。

規制・枠組み	対象組織	報告・開示の期限	主な例外規定や報告内容
米SEC Form 8-K Item 1.05	SEC登録企業（米国上場企業など）	インシデントが重要と判断された後、原則4営業日以内 [14]	司法長官が国家安全保障や公共安全への重大リスクを書面判断した場合に遅延可能 [14]
EU NIS2指令（早期警告）	NIS2対象の重要・基本事業者	重大インシデントの認知後24時間以内 [15]	初期的な警戒情報とインシデント発生の事実を通報 [15]
EU NIS2指令（インシデント通知）	NIS2対象の重要・基本事業者	重大インシデントの認知後72時間以内 [15]	初期評価、重大度、影響の概要を報告 [15]
EU NIS2指令（最終報告）	NIS2対象の重要・基本事業者	インシデント通知から1か月以内 [15]	根本原因、影響の詳細、実施した緩和策を含む報告 [15]

CISAの共同指針自体は情報提供目的の資料であり、少なくとも豪州法や豪州企業の報告義務を反映するものではありません[12, 13]。事業者の個別義務を免除するものではなく、各国の法的義務を別途確認する必要があります[12, 13]。また本稿では、顧客とのSLAと透明性の両立が必要になると解釈します[16]。契約ごとに発動閾値や通知先、公開可能な内容を事前にマッピングして整理する運用が必要になると考えられています[16]。

何が変わるのか：事後対応から平時準備と段階的開示への転換

指針は、障害が発生する前の平時準備を重視しています[17, 18]。事業者は、発動閾値、エスカレーション経路、対応手順をあらかじめ定義しておく必要があります[17, 18]。ステータスページ、顧客やパートナー向けの通知、規制当局向け連絡のテンプレートを準備しておくことが推奨されています[17, 18]。

体制面では、平時から横断的なインシデント対応チームを組織しておくことが求められます[19]。チームにはエンジニアリング・運用、広報、法務、リスク・コンプライアンス、顧客サポート・営業を含め、正担当と代替担当を置きます[19]。政府機関が影響を受ける事案に備えて「政府関係リード」を任命し、公開発信と当局向け連絡の整合性を担保すべきであるとしています[20]。

組織内の権限設計としては、「インシデントリード」「コミュニケーションリード」「スポークスパーソン」の3役を事前任命し、承認経路と判断基準を定めます[21]。インシデントリードは対応全体を統括します[22]。コミュニケーションリードは社内外の情報調整を担います[22]。スポークスパーソンは承認済み声明の発表や記者対応を行う単一窓口となります[22]。

対応現場では、「技術復旧」「広報・利害関係者対応」「経営判断・規制当局対応」の3つのワークストリームを並行して動かし、同期させます[23]。専任リエゾン（連絡窓口）や定例同期を設け、単一の情報受付経路を使うことで、調査や復旧にあたる技術者を外部からの割り込みから保護します[23]。

主系統のメールやチャットが障害や侵害で使えなくなった場合に備え、代替通信手段の準備も不可欠です[24]。バックアップメールやメッセージング、SMS、電話連絡網、無線、帯域外通信（主ネットワークから分離されたバックアップ通信網）、会議ブリッジなどを整備し、定期テストを実施します[24]。また、計画は机上演習などの訓練を繰り返して検証し、見直します[25]。

障害発生の初動において、事業者は曖昧な表現を排除しなければなりません[26, 27, 28]。「サービス劣化」といった表現や、安心感を演出する広報的表現は避けるべきとされています[27, 28]。初動では、影響を受けているシステム、利用者が経験した事象、影響範囲、判明している既知の原因を、憶測なしで簡潔に提示します[26, 28]。

対応継続中は、ステータスページなどの単一の公式情報源から時刻付きで情報を更新します[29, 30, 31]。発表では「分かっていること」「分かっていないこと」「調査中のこと」を明示します[29, 30]。顧客が取るべき具体的行動、または「行動不要」である旨を明確に示します[29, 30]。新情報がない場合でも時刻を付けて更新を継続します[29, 31]。なお指針は、更新頻度について固定の間隔は定めていません[32]。

情報発信の主眼は、安心感の演出や評判管理ではなく、顧客が判断できる行動情報の提供に置くべきです[33]。影響を認め、復旧措置とマイルストーンを提示することに注力します[31, 33]。

サイバー攻撃が疑われる、または確認された事案では、透明性と運用上の安全確保のバランスが重要になります[34, 35]。検知、調査、封じ込めを妨げるような過度の詳細公開は避けるべきです[35, 37]。米司法省のガイドラインでも、修復を阻害する技術情報の開示は不要とされています[38]。また、原因の帰属（攻撃者の特定）を性急に行うことは避け、公表にあたっては政府や法執行機関と調整しなければなりません[36, 39]。

誰に影響するのか：重要インフラ運用者から顧客企業までの役割変化

事業者が発信する情報は、受け手の属性に応じて調整される必要があります[41]。一般公開向け、経営層向け、技術担当者向けで提供すべき深度は異なります[41]。とりわけ重要インフラの運用者に対しては、単なる症状だけでなく、技術的な具体性と運用への実質的な影響を伝えるべきであると強調されています[41, 43]。

重要インフラ運用者は、事業者のステータス更新を単なる復旧見込みではなく、自社のリアルタイムのリスクベース運用判断の入力として扱います[43]。設備を停止すべきか、代替運用に切り替えるべきかといった即時判断が、事業者が開示する技術情報にかかっています[43]。

顧客企業のネットワーク防御担当者にとっても、事業者の公式情報は自衛措置の基礎となります[40]。提供された情報から自社への影響を評価し、不要な遮断を避けることができます[40]。また防御担当者は、障害発生時に安易に攻撃と断定せず、調査進捗を見極めながら冷静に対処する姿勢が求められます[42]。

事業者が行う公開発表は、法定報告や契約上の通知義務の代わりにはなりません[44]。政府や規制当局との連絡においては、公開声明、当局報告、法務確認を一貫したプロセスとして運用することが不可欠です[44]。また、メディアや一般利用者側も、未確認の憶測に惑わされず、公式情報源にある影響範囲や時刻付き更新を基に判断することが望ましいとされています[45]。

復旧後のポストインシデント局面においても、事業者の役割は大きく変わります[46, 47]。単に終了を報告して終わらせず、教訓を製品やプロセスの改善へ反映する方針を説明することが求められます[46, 47]。エンドユーザ向けに根本原因分析（RCA）を提供し、Secure by Design（設計段階からの安全性確保）の適用、安全機能をデフォルトで有効化する方針、脆弱性管理やパッチ適用手順の改善について透明に説明することが期待されています[47, 48, 49]。

こうした復旧後の説明は、顧客企業側にとっても重要な意味を持ちます。ガイダンスが顧客に直接義務を課しているわけではありませんが、事業者の説明姿勢は、次回のベンダー選定や契約条件、自社の事業継続計画（BCP）、冗長化設計を見直すための判断材料として実務上活用されると考えられています[50]。

実務上の課題と留意点：法的拘束力の限界と現場における実行可能性

本指針を実務に適用する上では、いくつかの課題や留意点が存在します。第一に、本指針は情報提供目的のベストプラクティス資料と位置付けられている点です[51, 52]。法的効果は適用法や個別制度を確認する必要があります。これを遵守しているからといって、各国や業種固有の法的義務、規制報告、契約上のSLAが免除されるわけではありません[51, 52]。多国籍に事業を展開する企業は、地域ごとの法制度を個別に確認して対応する必要があります[51, 52]。

第二に、中小事業者やOT現場における実行可能性の壁です[53]。指針は複数部門からなる横断チームの編成や、正担当・代替担当の配置、代替通信手段の常備、定期演習を推奨しています[53]。しかし米国立標準技術研究所（NIST）も指摘するように、OT事業者や小規模事業者は限られた資源の中で対応に苦慮する恐れがあります[53]。制御エンジニアや現場オペレーターを含む現実的な体制をどう構築するかが課題とされています[53]。

第三に、OT環境固有の優先順位との調和です[54]。一般的なITシステムでは可用性が重視されがちですが、NISTのOTセキュリティ原則では、安全性を再起動より優先する考え方が示されています[54]。NISTのガイドラインが示すように、人や環境の安全確保はシステムの再起動よりも先に位置付けられます[54]。CISAの指針にあるOT隔離時の情報発信方針を導入する際は、こうした安全原則と現場の復旧手順を齟齬なく結合させる必要があると論じられています[54]。

最後に、情報発信の有効性を評価する指標の未整備が挙げられます[55]。提示された指針の範囲では、取り組みの成果を客観的に測定するKPI（重要業績評価指標）や目標値、評価の頻度などは明示されていないように見えます[55]。初報までの所要時間、更新遵守率、代替経路到達率、顧客行動の正確性などを自社の評価指標としてどう落とし込むかは、各事業者の裁量に委ねられているのが実情です[55]。