2026.08.23

ISMSインシデント報告の進め方と報告義務

経営リスクナビ編集部

ISMS（ISO27001）の事故報告は、インシデント発生時に「社内の意思決定」と「外部への説明・法令対応」を同時に回すための運用設計が求められます。報告窓口やトリアージ、法務・広報・経営の連携順序が曖昧なままだと、夜間休日の15分・30分といったエスカレーション基準が形骸化し、報告遅延や説明ブレが実務上の不利益になり得ます。ISMSの要求事項と個人情報保護法等の報告義務を並走させたうえで、どの情報をいつ・誰が・どこまで確度を分けて報告するかを決めておくと、平時の教育訓練にも落とし込みやすくなります。以下では、事故報告フローの判断材料として社内外の報告設計ポイントを示します。

ISMS事故報告の基本
ISMSインシデント報告フロー
事故報告書の作成項目
外部報告義務と報告先
ISMS運用と業務復旧
事故報告ルールの定着
- 報告遅延と証拠不足の防止
- 教育訓練でルールを浸透させる
よくある質問
ISMS事故報告への対応で次にすべきこと

ISMS事故報告の基本

セキュリティインシデントの定義

ISMSにおけるセキュリティインシデントは、情報セキュリティ方針や管理策からの逸脱、または情報の機密性・完全性・可用性（CIA）を損なう（もしくは損なうおそれがある）事象を指します。インシデントは「実害が確定した事故」だけではなく、将来の事故につながり得るイベント（予兆・異常）も含めて整理するのが実務的です。

特にISMSは規格として要求事項が整理されており、日本では JIS Q 27001:2014（「技術情報–セキュリティ技術–情報セキュリティマネジメントシステム––要求事項」）において、附属書A.16でインシデント管理の考え方が扱われています。インシデント対応を「事故が起こり得る」前提で継続運用する点が、ISMSの運用設計では重要です。

インシデントとして扱う代表例

マルウェア感染や悪質なコードの検出（EDRやアンチウイルス等の検知を含む）
不正アクセスの形跡（認証失敗の多発、未知端末からの管理者ログイン等）
クラウド／SaaSの設定不備による意図しない公開（共有設定や公開権限ミス等）
Webサイト改ざん、フィッシングへの誘導、DDoS攻撃等の外形的な攻撃兆候
個人情報を含む端末・媒体の紛失、誤送信、誤共有

事故報告の目的と報告対象

事故報告の目的は、(1)被害の拡大防止、(2)業務復旧の加速、(3)原因究明と再発防止、(4)対外説明・監査対応に耐える記録化、の4点を同時に満たすことです。ISMSはPDCA（Plan/Do/Check/Act）で管理の質を上げる枠組みであり、事故報告は「Check〜Act」を成立させる基礎データになります。

報告対象は、明確な漏えい・停止などの実害に限られません。継続的なモニタリングで検知したサイバーセキュリティイベント、異常なアラート、設定変更の不整合など、後工程の分析でインシデントに格上げされ得るものも含め、一定の基準に沿って受付・記録します。

報告対象に含めるべき情報（例）

侵害・漏えい・滅失・毀損の発生またはそのおそれ（個人データを含む場合は法令評価に直結）
ネットワークの異常監視で検知されたイベント（検知情報の関係者伝達を含む）
復旧優先順位に影響する停止・性能劣化（事業継続への影響があるもの）
外部サービス利用に起因する事故の兆候（設定ミス、権限付与ミス、アクセス急増等）

ヒヤリハットと正式インシデントの線引きを誰がどの時点で判断するか

ヒヤリハット（危ないことが起こったが幸い重大事故に至らなかった事象）と正式インシデントの線引きは、現場の主観で決めないことが重要です。ISMSでは「報告を受ける窓口」と「優先順位を決める役割」を分け、第一報直後の初期アセスメントで機械的に分類できるようにしておくと運用が安定します。

参照情報として、ハインリッヒの法則では1件の重大事故の背後に29件の軽傷事故、300件の無傷事故（ヒヤリハット）があると言われます。これをセキュリティにそのまま数理適用はできないものの、「軽微に見える兆候の蓄積が重大化につながる」という運用上の教訓として、ヒヤリハット報告をリスクアセスメントに回す設計が有効です。

また、優先順位づけ（トリアージ）は、インシデント対応での必須機能です。トリアージ担当（優先順位選定担当）は、受け付けた報告に対して復旧・調査の優先度を判断し、判断できない場合は上位層へエスカレーションします。重要なのは、トリアージ担当が影響範囲の詳細調査などの「役割外の作業」に踏み込まず、他の案件の滞留を防ぐことです。

区分	主目的	判断主体とタイミング	次アクション
ヒヤリハット	危険の早期発見と共有	第一報の受付時点で一次分類し、定例で見直し	リスクアセスメント表へ記録し、周知・教育に反映
正式インシデント	封じ込め・復旧・対外対応	第一報直後の初期アセスメントで、責任者／CSIRTが確定	対応計画を起動し、分析・低減・改善・復旧の手順へ

ヒヤリハットと正式インシデントの扱い（運用の目安）

ISMSインシデント報告フロー

発生時の初動と現場報告

初動では、原因究明よりも被害拡大の防止と事実の保全を優先し、定められた報告窓口に速やかに上げます。ISMS運用では、検知（監視・アラート）→伝達→対応計画の実施という流れが前提になるため、現場は「分かる範囲での客観的事実」を揃えて第一報を出せるようにしておきます。

現場が行う第一報（最低限）

検知時刻・発覚時刻と、検知手段（監視アラート、ユーザー申告、外部通報など）
事象の種類（不正アクセス疑い、マルウェア検知、誤公開、誤送信、端末紛失など）
影響を受ける可能性のある対象（システム名、アカウント、クラウドサービス名、端末識別など）
現時点の影響（停止、データ参照可能性、改ざん兆候、外部流出の可能性など）
直ちに実施した封じ込め（ネットワーク遮断、アカウント停止、共有リンク無効化等）と未実施事項

重大性評価と影響範囲の整理

重大性評価は、意思決定者（経営・法務・広報）へのエスカレーションや、外部報告の要否判断に直結します。評価は「主観」ではなく、発生可能性と影響度で測るというリスク評価の原則に沿って、複数者レビューで客観性を確保します。発生可能性は「数年に1回程度〜月次」といった過去頻度が基準に使われることが多く、影響は業務停止・情報の機微性・法令/契約の帰結などから整理します。

トリアージ基準は組織の実情に合わせて定義します。参照例として、影響度と重要度をそれぞれ高・中・低に分類し、影響度も重要度も「高」の場合を最優先（インシデント高）とする、といった運用が示されています。

観点	高	中	低
影響度	事業継続に直接影響、または外部への実害が大きい	限定的な業務影響、代替手段あり	影響が局所・短時間で収束見込み
重要度	機微情報（個人データ等）や重要システムに関与	社内限定だが重要資産に触れる可能性	検証により誤検知の可能性が高い

トリアージ基準の例（影響度×重要度）

夜間・休日の発生時に誰へ何分以内で上げるかを決める当番設計

夜間・休日でもインシデントは発生し得るため、当番設計は「いつでも回る」ことが要件です。参照運用例として、検知から15分以内に一次窓口当番へ、そこから重大性判定を行い30分以内に経営幹部やCSIRT責任者へ連絡する、といった時間基準が挙げられます。時間基準は厳格にしつつ、連絡不通時の代替ルート（副当番、部門長直通等）まで文書化しておくことが実務では重要です。

当番設計に最低限含める要素

一次窓口（当番）と二次窓口（副当番）の指名と連絡手段（電話・SMS・緊急チャット等）
15分・30分のエスカレーション基準（例外条件と、例外時の判断権者も含む）
受電後に行うトリアージの範囲（優先順位づけまで、詳細調査は別担当へ）
休日・深夜の現地対応（オンサイト支援）の要否判断と、招集基準

事故報告書の作成項目

報告書に入れる基本情報

事故報告書は、社内の意思決定、監査、対外説明（当局・取引先・本人通知）に転用される前提で、事実が追跡可能な形で統一します。特に「いつ・誰が・何を・どこで・どう検知し・何をしたか」を時系列で残すことが、後工程の分析（インシデント分析、フォレンジック、再発防止）に効きます。

基本情報（テンプレート項目）

作成日、版数、作成者（所属・氏名）、レビュー者、承認者
発生日時・発覚日時・初報日時（それぞれ分けて記録）
検知経路（監視検知、外部通報、内部申告等）と初動の封じ込め措置
対象資産（システム名、クラウドサービス名、端末、アカウント）
影響対象（個人データの有無、通信の秘密に関わる可能性等）
現状ステータス（対応中/封じ込め済/復旧中/収束）と次回報告予定

原因と再発防止の記録方法

原因と再発防止は「書いたら終わり」ではなく、ISMSのPDCAに組み込んで改善を回す前提で、実施管理できる粒度にします。原因分析は、直接原因だけでなく、プロセス・運用・教育・監査などの管理面まで掘り下げ、論理の筋道（なぜなぜ、変更管理の不備等）を残します。

また、インシデント対応には「インシデント分析」「オンサイトでの対応支援」「遠隔での対応支援」「関係者間の調整（対応調整）」などの作業が含まれるため、再発防止策は技術対策だけでなく、役割分担・連絡・調整の改善まで対象にします。

再発防止策を“実行管理できる形”で書く手順

原因を「直接原因」と「管理上の原因（運用・手順・教育・監査等）」に分けて記載します。
再発防止策は「誰が・いつまでに・何を・どの範囲に」実施するかを1文で書ける形にします。
効果測定（例：監査での確認、モニタリング条件の見直し、訓練での再現テスト等）と判定日を定義します。
他部門・他システムへの水平展開の要否を判断し、実施/非実施の理由も残します。

外部報告に転用できるよう事実・推定・未確認情報を分けて記載する

外部報告（当局・取引先・本人通知・メディア対応）に転用するには、報告書内で事実・推定・未確認を混在させないことが必須です。特に取引先対応では、「漏えいの可能性がある」という表現だけでも、相手側では「漏えいした前提」で質疑が進むことがあるため、根拠と確度をセットで整理しておく必要があります。

危機対応の初動では、メディア対応としてホールディングコメント（現時点で確定している範囲のみ述べ、調査中事項は調査中と明示する暫定コメント）を使う運用が参照例として示されています。これを社外説明の文案管理（法務レビュー→広報文案→承認）に組み込むと、情報の不整合を抑えやすくなります。

区分	根拠	書き方のポイント
事実	ログ、設定画面の状態、検知アラート、現物、第三者報告の原文等	日時・対象・操作・観測結果を断定で記載
推定	事実から合理的に導ける技術的推論	根拠となる事実を併記し、推定である旨を明示
未確認	真偽が未確定の情報	真偽未確認である旨と、確認手段・見込み時期をセットで記載

記載区分の切り分け（表現のルール例）

外部報告義務と報告先

個人情報漏えいの報告義務

個人データの漏えい、滅失、毀損（漏えい等）が発生した場合でも、常に当局報告が必須とは限りません。報告義務は「個人の権利利益を害するおそれが大きいもの」として特別に定められた報告対象事態に該当する場合に課されます（個人情報保護法26条、同法施行規則7条）。

したがって実務では、第一報の段階から「報告対象事態に該当し得るか」を法務・個人情報保護担当が並走評価し、該当可能性がある場合は、調査完了を待たずに速報（判明している事実の範囲）を準備する設計が必要です。

個人情報保護法対応で最低限おさえる論点

報告義務の対象は「漏えい等」そのものではなく、法令で定める報告対象事態への該当性（個人情報保護法第26条、施行規則7条）
当局報告と本人通知の要否はセットで評価し、評価根拠（該当条文・事実）を記録
「漏えい等またはそのおそれのある事案」では、内容に応じて必要な措置が求められるという整理がガイドライン（通則編 3-5-2）で示されている点

業法や契約による報告先

外部報告は個人情報保護法に限られず、業法・監督官庁ガイドライン・重要インフラのルール、さらに取引先契約（委託契約・SaaS利用契約・NDA等）で追加義務が発生します。

参照例として、電気通信事業者では、通信の秘密の漏えいその他重大事故が発生した場合に、電気通信事業法28条および施行規則57条に基づき総務大臣への報告が必要とされています。また、電気通信設備に関する情報の漏えい事故については都度報告不要でも、電気通信事業報告規則7条の3に基づき毎四半期経過後2カ月以内の報告が必要となる整理が示されています（この範囲には通信の秘密や個人情報は含まない旨のガイドライン上の位置付けも示されています）。

実務での整理順（外部報告先の棚卸し）

個人情報保護法の報告対象事態に該当するか（当局報告・本人通知）
自社業種の業法・監督官庁ルール（報告先、期限、様式、速報/確報）
取引先契約の通知義務（報告経路、猶予期間、再委託先の連絡義務、損害賠償条項）

委託先・SaaS起因の事故で自社がどこまで報告主体になるかの整理

委託先やSaaS事業者側でインシデントが起きた場合でも、個人データを取り扱う主体としての責任整理が重要です。自社が個人情報取扱事業者として個人データを利用しているなら、事故原因が委託先であっても、自社として当局報告・本人通知の要否判断を行い、必要な場合は自社が主体的に実施する運用が現実的です。

また、クラウド事故の典型として「サービス側の脆弱性」ではなく、利用者側の公開権限のミス（公開リンクを知っていれば第三者が閲覧できる等）で漏えいに至るケースが参照例として挙げられています。委託先・SaaS起因の切り分けでは、技術的原因だけでなく、契約・運用（設定変更権限、監査、定期点検）の不備も含めて整理します。

契約・運用で事前に決めておくべき事項

委託先から自社への第一報の期限と、提供させるべき事実情報（時系列、影響範囲、暫定対策）
調査協力義務（ログ提供、原因分析、再発防止策の提示）と費用負担の考え方
設定不備（利用者側ミス）を含めた監査・点検の頻度と、是正要求プロセス

上場企業と非上場企業で分かれる公表判断と法務・広報の連携順序

公表（対外開示）判断は、法令・契約・レピュテーション・二次被害防止の観点を統合して行います。上場企業では、投資家の投資判断に資する適時・適切な開示が求められ、証券取引所のルールに違反すると不適正開示として改善報告書の提出を求められたり、最悪の場合は上場廃止の可能性がある、という整理が示されています。

一方、非上場企業でも、公表の要否は「法令上の通知・報告」「取引先契約」「被害拡大防止（注意喚起）」の観点で実務判断が必要です。いずれの場合も、対外文案の統制は、法務が法的リスクと義務を評価し、広報が客観的文案（ホールディングコメントを含む）に落とし、経営が承認する順で統一すると、矛盾を抑えられます。

法務・広報・経営の連携順序（例）

法務が法令・契約・当局対応の要否と、言ってよい範囲（断定可/推定/未確認）を切り分けます。
広報がホールディングコメントを含む対外文案を作成し、想定Q&A（取引先が問う論点）を整備します。
経営が公表の要否・タイミング・チャネル（Web、メール、適時開示等）を決裁します。

ISMS運用と業務復旧

種別別の事故対応の違い

インシデント対応は「同じ手順書で全部処理する」より、種別により初動の優先事項を変える方が機能します。参照例では、対応（Respond）の下で「分析」「低減（封じ込め）」「改善（教訓の取り込み）」が整理され、復旧（Recover）では復旧計画の実施と、内部利害関係者・役員・経営陣への伝達が求められる、とされています。

種別	優先する初動	報告上の注意点
ランサムウェア等の外部攻撃	封じ込め（ネットワーク遮断等）と証拠保全、分析着手	復旧可否・二次感染リスクを分けて報告し、推定は推定と明示
クラウド設定不備（誤公開等）	公開停止（権限修正・リンク無効化）と閲覧可能性の確認	「第三者が閲覧できた状態か」を設定画面等の事実で示す
端末紛失・誤送信	リモートワイプ、認証情報無効化、通知要否の評価	個人データの有無と、暗号化等の保護措置の有無を事実で整理

種別別の初動の違い（例）

バックアップとBCPの連携

業務復旧は、バックアップ単体ではなくBCP（事業継続計画）と一体で設計します。参照例としてBCPには基本計画、緊急対応計画、業務指示計画などの構成が示されており、復旧手順は「どの業務をどの順に戻すか」という優先順位の決定とセットで運用する必要があります。

また、ランサムウェア等を前提に、バックアップをネットワークから切り離した隔離環境に保管するなど、感染の影響を受けにくい保護が重要です。復旧計画の実施状況は、復旧（Recover）の「伝達」として、内部利害関係者・役員・経営陣に定期報告できる形にします。

BCPとバックアップを接続するための記載ポイント

BCP上の復旧優先順位（業務・システム）と、バックアップ復元手順を紐づけて文書化
緊急対応計画に「誰が復旧判断をするか」と「復旧状況の報告先（役員・経営）」を明記
復旧訓練で「復元できること」だけでなく「所要時間・手順逸脱・権限不足」を記録し改善へ回す

ログ保管とPDCAの回し方

ログは、分析（Analysis）と再発防止（Improvement）の根拠になるため、改ざん・消去に強い形で保管し、必要時に取り出せる運用が必要です。参照例として、継続的なモニタリングによりイベントを検知し、検知情報を適切な関係者へ伝達することが整理されています。ログ保管はこのモニタリングの裏付けであり、PDCAの「Check（点検）」を成立させる証跡でもあります。

また、ログ管理の仕組みとして Zabbix 等を用いたログ管理が例示されており、ツール選定以前に「どのログを、誰が、どの手順で、どの保全レベルで扱うか」を決めることが本質です。

ログをPDCAに接続する運用手順（例）

監視・検知で必要なログ種別（認証、操作、通信、クラウド監査ログ等）と取得範囲を定義します。
検知→伝達→対応の各段階で「参照すべきログ」と「保全すべきログ」を決め、保全手順を固定します。
収束後にログ解析結果と対応プロセスをレビューし、教訓を対応計画や管理策へ取り込みます。
改善内容を次回の訓練・監査で検証し、PDCAとして継続更新します。

事故報告ルールの定着

報告遅延と証拠不足の防止

報告遅延は被害拡大だけでなく、取引先・当局への説明困難（説明の一貫性欠如）を招きます。参照例では、報告が遅れた取引先に対して「なぜすぐ報告しなかったのか」と強く問われることが示されており、遅延はそれ自体が信用毀損の要因になります。

運用面では、心理的安全性（迅速な報告を評価する文化）と、遅延時の報告様式の標準化が有効です。参照例として、遅延が発生したときに「遅延しました」だけを禁じ、必ず遅延の理由・対策・リカバリ予定日の3点セットで報告させる運用が示されています。これをインシデントの状況報告（社内向けの状況報告書）にも適用すると、意思決定が前に進みます。

遅延と証拠不足を防ぐための運用ルール

報告窓口と報告基準（閾値）を明文化し、迷ったら報告を原則とする
遅延が起きた場合は「理由・対策・リカバリ予定日」の3点セットで状況報告する
証拠保全の観点から、ログや対象端末の操作を制限し、保全手順を初動手順に組み込む
トリアージ担当が詳細調査に踏み込まないなど、役割逸脱による滞留を防止する

教育訓練でルールを浸透させる

ルールは、文書化だけでは定着せず、教育訓練で「反射的に動ける」状態にして初めて機能します。インシデント対応は常に起こり得て予測が難しい、という前提に立ち、CSIRTを中心にチームとして協力して対応するコンセプトが参照例として示されています。

訓練は、一般従業員向けの「報告できる」訓練と、コアメンバー向けの「判断できる」訓練を分けます。PDCAの観点では、訓練結果（課題・遅延・判断のブレ）を次回の手順書と教育に反映し、改善（Act）まで回すことが重要です。

訓練設計に入れるべき観点

報告窓口の使い方と、第一報の書き方（事実のみ、推定は推定と明示）
夜間休日の当番連絡（15分・30分の時間基準で実際に連絡できるか）
トリアージ基準（影響度×重要度の高中低）に沿った分類の演習
役割分担（トリアージ、分析、低減、対応調整、復旧報告）の確認

よくある質問

軽微な事故も事故報告の対象ですか？

軽微に見える事象も、原則として事故報告（少なくとも受付・記録）の対象に含める運用が適しています。ヒヤリハットは、幸い重大事故に至らなかった事象であり、ハインリッヒの法則では1：29：300（重大事故：軽傷事故：無傷事故）という比率が示されています。セキュリティでも、ヒヤリハットの集約がリスクアセスメントに資するため、報告を蓄積し、傾向分析と是正処置に回すことが実務上の効果につながります。

軽微事象を報告対象に含める理由（実務面）

継続的モニタリングで得たイベントを集めることで、検知ルールや閾値の改善につながる
「設定不備」など人的ミス起因は再発しやすく、早期の水平展開が効果的
小さな兆候が重大化した際に、過去ログ・過去報告が説明根拠になる

報告書は誰が作成し承認しますか？

作成と承認は分離し、複数者レビューで客観性を確保します。特にCSIRTは「チーム（T＝Team）」として協力して対応する概念があり、報告書も単独作業にしない方が品質が安定します。

役割分担の例

下書き作成：当該部門責任者またはインシデント対応を主導した担当（分析担当等）
技術レビュー：CSIRTまたは情報システム部門（ログ根拠、影響範囲、封じ込め妥当性）
法務レビュー：対外説明・契約義務・当局報告（個人情報保護法26条等）の該当性
最終承認：経営（役員）としての公式判断（公表の要否・タイミングを含む）

疑い段階でも外部へ報告すべきですか？

疑い段階でも、法令・契約・被害拡大防止の観点から外部報告（少なくとも事前相談や速報の準備）を検討すべき場合があります。個人情報保護法では、漏えい等が発生した場合に常に報告義務があるわけではなく、報告対象事態に該当するときに報告義務が課されます（個人情報保護法第26条、施行規則7条）。

一方で、当局報告や取引先通知は「調査完了後に一度だけ」では実務上間に合わないことがあるため、確定している事実のみを速報し、未確認事項は未確認として次回報告予定を示す運用（ホールディングコメントを含む）にしておくと、報告遅延と説明ブレの双方を抑えられます。

ISMS事故報告への対応で次にすべきこと

ISMSの事故報告は、インシデントの定義と報告対象を広めに取りつつ、ヒヤリハットと正式インシデントの線引きを初期アセスメントで機械的に行えるようにしておくことが要点です。社内では第一報の最低限事項、トリアージ（影響度×重要度）、当番設計（検知から15分・30分の連絡基準）を一つの流れとして文書化し、役割逸脱による滞留を防ぐ軸を持たせます。社外対応は、個人情報保護法の報告対象事態の該当性や業法・契約上の通知義務を並走評価し、報告書では事実・推定・未確認を分けて説明ブレを抑えることが判断の軸になります。次のアクションとして、報告窓口とエスカレーション経路、法務・広報・経営の承認順序、委託先・SaaS起因時の報告主体の切り分けを、手順書と訓練計画に落とし込んで整合を取ってください。個別事案では法令・契約・業態で要件が変わり得るため、判断に迷う点は法務・個人情報保護担当や関係部門でレビューして確度を上げる運用が前提になります。