ランサムウェアや不正アクセスによる被害が後を絶たず、情報システムや総務の担当者にとって「もし自社が攻撃を受けたら、誰がどう動くのか」は切実な問いになっています。攻撃を受けてから対応の手順を考え始めると、初動が遅れて被害が広がり、復旧にも時間がかかります。
この「もしも」に備えて、検知から報告、復旧までの動き方を平時に文書化しておくものがインシデント対応計画（IRP：Incident Response Plan）です。事業を止めないための計画である事業継続計画（BCP）や災害復旧計画（DR）がシステム全体の復旧を扱うのに対し、インシデント対応計画はサイバー攻撃・情報漏えいといったセキュリティ事案への対応に焦点を当てます。
本記事では、計画に盛り込む構成要素のチェックリストから、NISTとSANSのフレームワークに沿った作り方、対応体制（CSIRT）の組み方、日本の個人情報保護法が定める漏えい報告の期限、そして計画を機能させるための運用までを解説します。専任のセキュリティ担当を置きにくい中堅・中小企業でも、自社の計画書を書き起こせる状態になることを目指します。
目次
一括ダウンロードする
インシデント対応計画とは
インシデント対応計画とは、サイバー攻撃やマルウェア感染、情報漏えいといったセキュリティインシデントが起きたときに、誰が・何を・どの順番で行うかをあらかじめ定めた文書です。検知してから報告・公表、復旧・再発防止までの一連の流れを決めておき、有事に迷わず動けるようにするためのものです。
独立行政法人情報処理推進機構（IPA）の手引きでは、インシデント発生時の対応を「検知・初動対応」「報告・公表」「復旧・再発防止」の3つの段階に分けて検討するよう示しています。段階ごとに「何を決めておくか」を事前に固めておくことが、計画づくりの出発点になります。
なぜ計画が必要か
計画が無い、あるいは実態に合っていないと、インシデント発生時の初動が遅れて被害が広がります。たとえば感染端末を調べずに再起動・初期化してしまうと、原因を特定するための痕跡（ログ）が消え、侵入経路や被害範囲がわからなくなることがあります。「誰に連絡し、どこを切り離し、何を証拠として保全するか」を事前に決めていないと、対応のたびに判断を一から行うことになり、その間にも被害は進みます。
近年のインシデントは手口が複雑化し、復旧までに数週間から数か月かかる例も珍しくありません。だからこそ、攻撃を受けてから考えるのではなく、平時に対応の型を決めておくことに意味があります。
出典・参考資料（1件）
- 参考資料：中小企業のためのセキュリティインシデント対応の手引き｜独立行政法人情報処理推進機構（IPA）（PDF）
計画に盛り込む構成要素（そのまま目次にできるチェックリスト）
ここからは、インシデント対応計画に盛り込む構成要素を整理します。以下の項目は、自社の計画書の目次としてそのまま使えるように並べています。それぞれの中身の決め方は、このあとの「作り方」「対応体制」「報告義務」の各章で具体的に解説します。
- 目的と適用範囲：何を守るための計画か、どの部門・システム・情報を対象とするか
- 対応体制と役割：対応チーム（CSIRT）の構成、責任者、各メンバーの役割と権限
- 連絡先とエスカレーション基準：社内外の連絡網、どの事態で誰に報告・判断を上げるか
- インシデントの分類と優先度：種別（マルウェア感染・不正アクセス・情報漏えい等）ごとの重大度の判断基準
- 種別ごとの対応手順：検知・分析から封じ込め・根絶・復旧までの具体的な手順
- 封じ込め・復旧の判断基準：いつ端末を切り離すか、どの状態をもって復旧とみなすか
- 外部への報告・公表：個人情報保護委員会への報告、本人通知、関係当局・取引先への連絡
- 事後分析と再発防止：原因の振り返り、教訓の記録、計画・対策への反映
- 訓練と見直し：計画が機能するかを確かめる演習の頻度、更新のタイミング
これらの項目は、米国国立標準技術研究所（NIST）が示すインシデント対応計画の要素や、セキュリティ各社が共通して挙げる構成要素と重なります。自社の規模や扱う情報に合わせて取捨選択しつつ、まずはこの一覧を土台に自社版の目次を作るのが近道です。
作成の進め方としては、守る対象と目的を決め、対応体制を固めてから、各要素の中身を順に埋めていくと書き上げやすくなります。次章からは、この手順に沿って中身の決め方を解説します。
インシデント対応計画の作り方（NISTの4フェーズ×SANSの6ステップ）
計画の手順は、ゼロから考えるより、広く使われているフレームワークに沿って埋めていくほうが抜け漏れを防げます。代表的なのが、NISTのインシデント対応ライフサイクル（4フェーズ）と、SANS Instituteが示すインシデントハンドリングの6ステップです。両者は呼び方が違うだけで、流れはほぼ対応しています。
下表は、NISTの4フェーズとSANSの6ステップを対応させ、各段で決めておくことを整理したものです。NISTが「封じ込め・根絶・復旧」を1つのフェーズにまとめているのに対し、SANSはこれを3つのステップに分けている点が主な違いです。
| NISTとSANSの対応と各段で決めること | 準備 | 検知と分析 | 封じ込め・根絶・復旧 | 事後活動 |
|---|---|---|---|---|
| NIST（4フェーズ） | 準備（Preparation） | 検知・分析（Detection & Analysis） | 封じ込め・根絶・復旧（Containment, Eradication & Recovery） | 事後活動（Post-Incident Activity） |
| SANS（6ステップ） | 準備（Preparation） | 特定（Identification） | 封じ込め（Containment）／根絶（Eradication）／復旧（Recovery） | 教訓（Lessons Learned） |
| この段で決めておくこと | 対応体制・連絡網・権限、検知の仕組み、手順書、訓練の整備 | 何を異常とみなすか、誰がどう一次切り分けするか、重大度の判断基準 | 端末を切り離す基準、原因（マルウェア等）の除去方法、業務再開の判断 | 原因と対応の振り返り、再発防止策、計画・手順への反映 |
注意したいのは、この4フェーズはNISTのガイドライン「SP 800-61」の従来版（Rev.2、2012年公開）で示されたモデルで、Rev.2は2025年4月に改訂版へ移行している点です。現行のRev.3では、米国のサイバーセキュリティフレームワーク（CSF 2.0）の6つの機能（統治・識別・防御・検知・対応・復旧）に沿って再構成され、従来の4フェーズは対応表の形で引き継がれています。
NIST自身も、自組織に最も合うライフサイクルのモデルを使えばよいとしており、4フェーズで計画を組むこと自体は現在も有効です。原典や日本語訳は、この章の末尾に挙げる参考資料から確認できます。
準備：体制・手順・訓練をそろえる
準備は、インシデントが起きる前に対応の土台を整える段階です。対応体制（CSIRT）と連絡網、権限者を決め、検知の仕組みや手順書を用意し、訓練で使えるようにしておきます。この段の作り込みが、実際のインシデント時の初動の速さを左右します。具体的な体制の組み方は後述の「対応体制（CSIRT）の作り方」で解説します。
検知・分析：異常に気づき、重大度を見極める
検知・分析は、不審な通信や端末の挙動に気づき、それが本当にインシデントか、どの程度の重大度かを切り分ける段階です。「何を異常とみなすか」「誰が一次切り分けを行い、どの基準で上位者へ報告を上げるか」を事前に決めておきます。たとえば「業務時間外に外部へ大量のデータが送られている」「普段使わない管理者権限が使われた」といった想定シナリオごとに、確認する項目を手順書にしておくと判断に迷いません。
封じ込め・根絶・復旧：被害を止め、原因を除き、業務を戻す
封じ込めは被害の拡大を止める段階で、感染が疑われる端末をネットワークから切り離すなどの対応を行います。このとき、原因を調べるための痕跡を残すため、いきなり初期化せず証拠を保全してから作業する手順にしておくことが重要です。
根絶ではマルウェアや不正アカウントなどの原因を取り除き、復旧では「どの状態をもって業務を再開してよいか」の判断基準に沿ってシステムを戻します。切り離す基準・復旧の判断基準を事前に決めておくと、現場が判断に迷わずに済みます。
事後活動：振り返り、計画に反映する
事後活動は、対応が一段落したあとに原因と対応を振り返り、再発防止につなげる段階です。「どこで気づけたか」「どの手順が機能し、どこで詰まったか」を記録し、手順書や計画そのものを更新します。この振り返りを次の準備に戻すことで、計画は一度作って終わりではなく、インシデントのたびに実態へ近づいていきます。
ここまでは平時に「流れを計画として決めておく」観点で各段を見てきました。実際にインシデントが起きたときの初動の順番、やってはいけないこと（証拠保全前の初期化など）、報告の具体的な進め方は、以下の記事で手順を追って解説しています。各段の手順を計画に書き込む際の肉付けとしても使えます。
出典・参考資料（4件）
- 参考資料：インシデント対応の推奨事項と考慮事項（NIST SP 800-61 Rev.3）｜米国国立標準技術研究所（NIST）（刊行ページ）
- 参考資料：サイバーセキュリティリスクマネジメントにおけるインシデント対応の推奨事項と考慮事項（NIST SP 800-61 Rev.3 日本語訳）｜独立行政法人情報処理推進機構（IPA）（PDF）
- 参考資料：Computer Security Incident Handling Guide（NIST SP 800-61 Rev.2、2025年4月に改訂版へ移行）｜米国国立標準技術研究所（NIST）（刊行ページ）
- 参考資料：Incident Handler’s Handbook｜SANS Institute（ページ）
一括ダウンロードする
対応体制（CSIRT）の作り方と巻き込む部門
インシデント対応は情報システム部門だけで完結しません。顧客や取引先への連絡は総務や広報、法的な報告義務の判断は法務、事業への影響の判断は経営層が担うなど、複数の部門が関わります。この横断的な対応チームがCSIRT（Computer Security Incident Response Team）です。
NISTのガイドラインも、インシデント対応の成否は、さまざまな役割を持つ社内外の多くの関係者の参加にかかっていると述べています。IPAの手引きでも、経営者がインシデントの影響を踏まえて速やかに対応体制を立ち上げ、役割を明確にすることが求められています。
専任のチームを置けない場合でも、「誰が対応の責任者か」「どの事態で誰の判断を仰ぐか（エスカレーション）」「社外の専門業者や関係当局の連絡先」を平時に決めておけば、兼任の担当者でも動けます。重要なのは、インシデント時に判断できる権限を持つ人を事前に決めておくことです。
出典・参考資料（2件）
日本の報告義務との接続（個人情報保護法の漏えい報告）
海外発のフレームワークやテンプレートをそのまま使うと、日本の法律が定める報告義務が抜けがちです。計画には「誰に・いつ報告するか」を日本の制度に合わせて盛り込む必要があります。個人データの漏えいなどが起きた場合、個人情報保護法は個人情報保護委員会への報告と本人への通知を義務づけています。
個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失、毀損その他の個人データの安全の確保に係る事態であって個人の権利利益を害するおそれが大きいものとして個人情報保護委員会規則で定めるものが生じたときは、個人情報保護委員会規則で定めるところにより、当該事態が生じた旨を個人情報保護委員会に報告しなければならない。
出典：個人情報の保護に関する法律 第26条第1項｜e-Gov法令検索
報告が必要になる「個人の権利利益を害するおそれが大きい事態」は、個人情報保護委員会によって次の4類型が定められています。
- 要配慮個人情報（健康・信条など）が含まれる漏えい等（またはそのおそれ）
- 不正に利用されると財産的被害が生じるおそれがある漏えい等（またはそのおそれ）
- 不正の目的をもって行われたおそれがある行為による漏えい等（またはそのおそれ）
- 本人の数が1,000人を超える漏えい等（またはそのおそれ）
サイバー攻撃や不正アクセスによる漏えいは、通常3つ目の「不正の目的をもって行われたおそれがある行為による漏えい」に当たります。報告には、まず速やかに行う速報と、詳細を示す確報の2段階があります。速報の期限について、個人情報保護委員会のガイドラインは次のように示しています。
「速やか」の日数の目安については、個別の事案によるものの、個人情報取扱事業者が当該事態を知った時点から概ね 3～5 日以内である。
出典：個人情報の保護に関する法律についてのガイドライン（通則編）3-5-3-3｜個人情報保護委員会
確報の期限は、原則として事態を知った日から30日以内です。ただし、サイバー攻撃など「不正の目的をもって行われたおそれがある行為」による漏えいの場合は60日以内となります。
前項の場合において、個人情報取扱事業者は、当該事態を知った日から 30 日以内（当該事態が前条第 3 号に定めるものである場合にあっては、60 日以内）に、当該事態に関する前項各号に定める事項を報告しなければならない。
出典：個人情報の保護に関する法律についてのガイドライン（通則編）3-5-3-4｜個人情報保護委員会
あわせて、漏えいが生じた本人に対しても、事態の状況に応じて速やかに通知する必要があります（通知が難しい場合は公表などの代替措置が認められています）。EU一般データ保護規則（GDPR）で知られる「72時間以内の報告」は日本の確報期限ではありません。日本では速報（概ね3〜5日以内）と確報（30日／60日以内）という枠組みで定められているため、計画にはこの日本の期限を書き込みます。
報告先・報告内容・期限を計画の中で明確にしておくことが、いざというときの判断の遅れを防ぎます。
実際に個人データの漏えいが発覚したとき、初動から事実調査、個人情報保護委員会への報告・本人通知までを具体的にどう進めるかは、以下の記事で対応フローとして整理しています。報告対象となる4類型や報告期限も根拠条文つきで確認できます。
出典・参考資料（3件）
どの粒度で書くか（1枚サマリー＋詳細手順書の2階層とひな形イメージ）
計画は、細かく書き込むほど良いとは限りません。詳細すぎる計画は、いざというとき読み込む時間がなく、現場で使われないまま棚に眠りがちです。ここでは、実際に使える粒度と、最小限のひな形のイメージを示します。
「1枚サマリー＋詳細手順書」の2階層で書く
実用的なのは、初動が1枚で分かるサマリーと、必要なときに参照する詳細手順書の2階層に分ける書き方です。1枚サマリーには「異常に気づいたら誰に連絡するか」「最初にやること・やってはいけないこと（例：証拠保全前の初期化）」など、発生直後の数十分で必要な情報だけを載せます。
種別ごとの詳しい手順や連絡先の一覧は詳細手順書にまとめ、サマリーから参照できるようにします。こうすると、現場はまずサマリーで動き出し、落ち着いてから詳細を確認できます。
最小ひな形イメージ（連絡先リスト・初動フロー・判断基準）と中小・兼任での最小構成
専任担当を置けない中小企業でも、最低限そろえておきたいのは次の3つです。これらだけでも、初動の迷いは大きく減らせます。
- 連絡先リスト：社内の責任者・情報システム担当、外部のセキュリティ専門業者、個人情報保護委員会やIPA・警察などの相談先を一覧にする
- 初動フロー：「気づく→責任者へ報告→端末の切り離し→証拠保全→専門業者へ連絡」のように、最初に取る行動を順番で示す
- 判断基準：どの状態なら経営層へ上げるか、どの場合に外部報告が必要かといった、迷いやすい分岐の目安
ひな形のイメージとして、3つの最小構成の中身を例で示します。自社の体制に合わせて名前や連絡先を埋めれば、そのまま使えます。
連絡先リストは、役割ごとに担当と連絡先を並べます。
- 対応責任者：（氏名）／（内線・携帯）
- 情報システム担当：（氏名）／（連絡先）
- 外部のセキュリティ専門業者：（社名）／（窓口電話）
- 報告・相談先：個人情報保護委員会、IPA、警察（サイバー犯罪相談窓口）
初動フローは、気づいてから最初に取る行動を順番で書きます。
- 異常に気づいたら、まず対応責任者へ報告する（電話・チャット）
- 感染が疑われる端末はネットワークから切り離す（電源は切らない・初期化しない）
- 証拠を保全したうえで、外部の専門業者へ連絡する
- 影響範囲を確認し、必要に応じて経営層・法務へエスカレーションする
- 報告対象に当たる場合は、個人情報保護委員会へ速報する
判断基準は、迷いやすい分岐に具体的な目安を添えます。
- 経営層へ上げる：事業の停止につながるおそれ、または個人データ1,000人超の漏えいが疑われるとき
- 外部へ報告する：要配慮個人情報の漏えいや、不正アクセスによる漏えいなど報告対象に当たるとき
- 外部業者へ依頼する：自社で原因調査や証拠保全ができないとき
まずはこの最小構成から始め、訓練や実際のインシデントを通じて不足に気づいたところを足していくと、無理なく実態に合った計画へ育てられます。自社だけで手順の整備や事後の調査まで賄うのが難しい場合は、どこを外部の専門業者に任せるかを計画の中で決めておくと、有事に慌てずに済みます。
出典・参考資料（1件）
- 参考資料：中小企業のためのセキュリティインシデント対応の手引き｜独立行政法人情報処理推進機構（IPA）（PDF）
作ったあとの運用（訓練と定期見直し）
計画は作って終わりではなく、機能するかを確かめ、更新し続けてはじめて意味を持ちます。実際のインシデントを待たずに動き方を確認する手段が訓練です。関係者が集まって想定シナリオに沿って対応を口頭で確認する机上演習なら、大きな準備なしに実施でき、連絡網の抜けや判断の迷いどころを洗い出せます。一般には、少なくとも年1回以上の演習が推奨されます。
見直しは、定期的なタイミングに加えて、システムや体制が変わったとき、法令が改正されたとき、実際に重大なインシデントを経験したあとに行います。訓練や実対応で見つかった課題を計画に反映することで、計画は実態に合った使えるものに保たれます。
出典・参考資料（1件）
- 参考資料：インシデント対応の推奨事項と考慮事項（NIST SP 800-61 Rev.3）｜米国国立標準技術研究所（NIST）（刊行ページ）
計画を機能させる手段（検知・診断サービスの活用）
計画を実際に機能させるには、インシデントに「気づく」検知の仕組みと、起きたことを「調べる」手段が欠かせません。計画で決めた検知・分析や事後の調査を支えるサービスには、ネットワーク側で不審な通信を捉えるもの、端末側で不審な挙動を検知・対応するもの、すでに侵害が起きていないかを調べる診断などがあります。ここでは、それぞれの役割を担うサービスを紹介します。
どれから検討するかは、自社の状況で選べます。ネットワーク全体の通信を常時見張って侵入を捉えたいならNDR（ネットワークの検知・対応）、端末での検知から駆除・復旧までを自動化したいならEDR（端末の検知・対応）、すでに侵害や情報の持ち出しが起きていないかを区切って確かめたいならスポットの端末侵害診断が向きます。
| 検知・診断サービスの比較（対応レイヤー・役割・支える計画の段） | Network Blackbox | CoWorker 端末侵害診断サービス | Eye"247" Safety Zone |
|---|---|---|---|
| 対応レイヤー | ネットワーク（NDR） | 端末（フォレンジック診断） | 端末（EPP＋EDR） |
| 常駐／スポット | 常時（通信をミラーリングで収集・保存） | スポット／定期（一度きり・年1〜2回） | 常時（端末に常駐して監視） |
| 主な役割 | 通信を保存して不審な通信を検知し、保存したパケットを遡って調査する | 端末のログから、すでに侵害や情報の持ち出しが起きていないかを調べる | マルウェアを防ぎ、端末での不審な挙動を検知・対応する（EDR） |
| 支える計画の段 | 検知・分析／事後の調査（フォレンジック） | 検知・分析の裏取り／事後の調査 | 検知・分析／封じ込め・根絶・復旧 |
| 料金 | 要お問い合わせ | 1台あたり定価500,000円（税別） ※カタログ経由は初期費用200,000円＋診断費用500,000円／台（複数台は割引あり） | 要お問い合わせ |
| 詳細情報 | 公式資料を見る | 公式資料を見る | 公式資料を見る |
1. Network Blackbox（株式会社クワッドマイナージャパン）
Network Blackboxは、株式会社クワッドマイナージャパンが提供する、ネットワークを流れる通信を保存して検知・調査するNDR（Network Detection and Response）製品です。社内ネットワークの通信をミラーリングで取り込み、パケットを損失なく保存する点が特徴です。
検知は、既知の攻撃を捉えるシグネチャ検知に加え、ユーザーの行為パターンから異常を見つけるユーザー行為ベースの検出（BAD）、送受信データの内容を分析するコンテンツ分析を組み合わせます。
保存したパケットは高速に検索・再構成できるため、インシデントの「検知・分析」だけでなく、発生後に通信記録を遡って「いつ・どこへ・何が送られたか」を調べる事後調査にも役立ちます。EDRやSIEM（各種ログを集約して分析する仕組み）とはSyslog・REST APIで連携する設計です。料金は要お問い合わせです。
2. CoWorker 端末侵害診断サービス（CoWorker株式会社）
CoWorker株式会社の「端末侵害診断サービス」は、対象のPCから専用ツールでログを収集し、自社開発AI「Blue Agent」とセキュリティ専門家が解析する、スポット（一度きり）または定期で実施する端末フォレンジック診断です。
常駐してリアルタイムに防ぐEDRとは異なり、退職時やインシデントが疑われるとき、年1〜2回の定期棚卸しといったタイミングで「すでに侵害や情報の持ち出しが起きていないか」を調べる位置づけです。
マルウェア感染、認証情報の漏えい、USBやクラウド経由のデータ持ち出し、生成AIの利用ログに含まれる機密情報の痕跡などを検出し、リスクの優先度を付けたレポートと報告会を提供します。速報は1週間以内、最終レポートは1か月以内が目安で、Windows・Macに対応し最大100台まで一括で診断できます。
計画で定めた検知・初動が形だけになっていないか、実際に被害が起きていないかを確かめる手段として使えます。料金は1台あたりの定価が500,000円（税別、2026年11月時点）です。MCB FinTechカタログ経由では、初期費用200,000円（ヒアリング・導入稼働費）に診断費用500,000円／台を加えた形が案内されています（複数台は数量割引あり）。
常時動かすEDRなどとは異なり、事故が疑われたときや退職者の端末確認、年1〜2回の棚卸しなど、必要なタイミングに区切って使う前提の費用です。
計画で定めた事後の調査を、いつ・どの頻度で行うべきかについて、提供元のCoWorker株式会社は次のように述べています。
従来のフォレンジックは、何か大きな問題が起きてから重い腰を上げて対応するというイメージが強かったのですが、問題がまだ小さいうちに、より簡易でスピーディーに診断できるものが必要だと考えました。あわせて、攻撃者側もAIを使ってランサムウェアを高速化させていますので、年に1回ではなく、より定期的な診断が不可欠になってきているという背景もあります。
3. Eye”247″ Safety Zone（株式会社フーバーブレイン）
株式会社フーバーブレインが提供する「Eye”247″ Safety Zone」は、ウイルス対策（EPP）と、端末での検知・対応を担うEDRを1つにまとめたエンドポイントセキュリティソフトです。Bitdefenderと共同開発した検知エンジンを採用し、機械学習ベースの検知と、アプリケーションの動作を常時監視する振る舞い検知（ATC）で不審な動きを捉えます。
ランサムウェア対策として、ファイルを自動でバックアップし、直近のバックアップからリストアする機能を備えます。EDRでは不審な挙動の検知に加え、ログの収集・調査・分析や、マルウェアの駆除・復旧支援まで行えるため、計画の「検知・分析」と「封じ込め・根絶・復旧」を端末側で支えます。専任のセキュリティ担当を置きにくい中堅・中小企業でも扱いやすい構成です。料金は要お問い合わせです。
ここで紹介した検知・診断サービスは、社内セキュリティの中でも「気づく・調べる」部分を担う一部です。端末・ネットワーク・ID・データなど守る対象ごとにどのようなソリューションがあるかを一覧で見比べ、自社に足りない対策を見極めたい場合は、以下の記事が全体像の把握に役立ちます。
社内セキュリティソリューション比較｜守る対象別のタイプ・代表サービスと選び方
社内のセキュリティを強化したいものの、端末の保護から不正アクセス対策、情報漏えいの防止まで課題が広く、何から手をつければよいか判断がつかないという声は少なくありません。テレワークやクラウド利用が定着し、社外に持ち出される端末やIDが増えたこ…
まとめ
インシデント対応計画は、攻撃を受けてから考えるのではなく、平時に「誰が・何を・どの順で行うか」を文書にしておくための備えです。まずは構成要素のチェックリストを目次にし、NISTの4フェーズやSANSの6ステップに沿って手順を埋め、対応体制（CSIRT）と連絡網、権限者を決めます。
日本の個人情報保護法が定める報告先と期限（速報は概ね3〜5日以内、確報は30日／不正アクセス等は60日以内）も忘れずに盛り込みます。
計画は、初動が1枚で分かるサマリーと詳細手順書の2階層にまとめ、訓練と定期的な見直しで実態に合わせて育てていくのが現実的です。そして、計画を機能させるには、不審な通信や端末の挙動に気づく検知の仕組みと、侵害の有無を調べる手段がそろっていることが前提になります。自社の体制に合った検知・診断のサービスは、資料で機能や費用を見比べて検討してください。
一括ダウンロードする
よくある質問（FAQ）
Q. インシデント対応計画（IRP）とは何ですか？
A. インシデント対応計画（IRP）とは、サイバー攻撃や情報漏えいが起きたときに「誰が・何を・どの順番で行うか」を平時に定めておく文書です。検知から報告・公表、復旧・再発防止までの一連の流れをあらかじめ決めておき、有事に迷わず動けるようにするためのものです。
事業全体の復旧を扱う事業継続計画（BCP）や災害復旧計画（DR）と異なり、サイバー攻撃・情報漏えいといったセキュリティ事案への対応に焦点を当てる点が特徴です。
Q. インシデント対応計画は小規模な中小企業でも必要ですか？
A. インシデント対応計画は、専任のセキュリティ担当を置きにくい中小企業ほど必要です。規模が小さいほど、一度のインシデントで事業が止まったときの打撃が致命的になりやすいためです。大企業のような詳細な計画でなくても、連絡先リストと初動の手順を決めておくだけで、初動の遅れによる被害拡大を大きく防げます。まずは自社の規模に合ったシンプルな計画から始めるのが現実的です。
Q. インシデント対応計画に最低限そろえるべき項目は何ですか？
A. 最低限そろえておきたいのは、連絡先リスト・初動フロー・判断基準の3つです。連絡先リストは社内の責任者や外部のセキュリティ専門業者・報告先をまとめたもの、初動フローは「気づく→責任者へ報告→端末の切り離し→証拠保全→専門業者へ連絡」のように最初に取る行動を順番で示したもの、判断基準はどの事態で経営層へ上げるか・外部報告が必要かの目安です。
この3つだけでも、発生直後の迷いは大きく減らせます。そこから訓練や実際のインシデントを通じて不足を足していくと、無理なく実態に合った計画へ育てられます。
Q. インシデント対応チーム（CSIRT）には誰を入れるべきですか？
A. インシデント対応チーム（CSIRT）には、情報システム部門だけでなく、総務・広報・法務・経営層を含めた横断的なメンバーを入れるのが理想です。顧客や取引先への連絡は総務・広報、報告義務の判断は法務、事業への影響の判断は経営層が担うなど、技術対応以外の役割が多いためです。
専任のチームを置けない場合でも、「誰が対応の責任者か」「どの事態で誰の判断を仰ぐか（エスカレーション）」を平時に決めておけば、兼任の担当者でも動けます。
Q. インシデント対応は外部の専門業者に委託できますか？
A. 専門的な調査や復旧は外部の専門業者に委託できますが、完全な丸投げは避けるのが安全です。社内の連絡体制と初動対応は自社で準備したうえで、高度な原因調査（フォレンジック）や復旧を外部に依頼する形が現実的です。計画の中で「どこまでを自社で行い、どこから外部に任せるか」の線引きと委託先の連絡先を決めておくと、有事に慌てずに済みます。
Q. インシデント対応計画はどのくらいの頻度で訓練・見直しすればよいですか？
A. 一般的な推奨水準は、訓練が少なくとも年1回以上、見直しは定期的なタイミングに加えてシステムや体制の変更時・法令改正時・重大なインシデントの経験後に行うことです。関係者が集まって想定シナリオに沿って対応を確認する机上演習なら、大きな準備なしに実施でき、連絡網の抜けや判断の迷いどころを洗い出せます。訓練や実対応で見つかった課題を計画に反映することで、計画は実態に合った使えるものに保たれます。
Q. 情報漏えいが起きたとき、日本では誰に・いつ報告する必要がありますか？
A. 個人データの漏えい等が報告対象に当たる場合、個人情報保護委員会への報告と本人への通知が義務づけられており、報告は速報（事態を知ってから概ね3〜5日以内）と確報（30日以内。不正アクセスなど不正の目的による行為の場合は60日以内）の2段階で行います。
報告対象となるのは、要配慮個人情報が含まれる、不正に利用されると財産的被害が生じるおそれがある、不正の目的をもって行われたおそれがある行為による、本人の数が1,000人を超える、のいずれかに当たる漏えい等（またはそのおそれ）です。サイバー攻撃や不正アクセスによる漏えいは通常「不正の目的をもって行われたおそれがある行為」に該当するため、確報の期限は60日以内となります。
本人への通知が難しい場合は、公表などの代替措置が認められています。
Q. 「72時間以内に報告」というルールは日本にも当てはまりますか？
A. 「72時間以内の報告」はEUの一般データ保護規則（GDPR）の基準であり、日本の個人情報保護法が定める報告期限ではありません。日本では、個人情報保護委員会への報告を速報（概ね3〜5日以内）と確報（30日以内、不正アクセス等は60日以内）の2段階で行う枠組みが定められています。
海外発のテンプレートやフレームワークをそのまま使うと期限を取り違えるおそれがあるため、計画にはこの日本の期限を書き込みます。
Q. 計画どおりにいかない想定外の事態が起きたらどうすればよいですか？
A. 想定外の事態でも、「検知→分析→封じ込め→根絶→復旧→振り返り」という基本的な対応の流れは変わりません。計画は細かな手順を縛るものというより、有事に立ち返る「考え方の軸」として働きます。計画があることで、想定していなかった事態でも、誰に連絡し何を優先するかを冷静に判断できます。対応が一段落したあとの振り返りで想定外のケースを計画に反映すれば、次への備えも厚くなります。
Q. 計画書はどの程度詳しく書くべきですか？
A. 詳細に書き込むほど良いわけではなく、「初動が1枚で分かるサマリー＋詳細手順書」の2階層にするのが実用的です。詳細すぎる計画は、いざというときに読み込む時間がなく、現場で使われないまま棚に眠りがちです。
1枚サマリーには発生直後の数十分で必要な連絡先と最初の行動（やってはいけないことを含む）だけを載せ、種別ごとの詳しい手順は詳細手順書にまとめてサマリーから参照できるようにします。こうすると、現場はまずサマリーで動き出し、落ち着いてから詳細を確認できます。
インシデント対応を支える検知・診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、ネットワーク検知（NDR）・端末の検知と対応（EDR）・端末侵害診断など、インシデント対応計画を機能させるサービスの最新資料を無料で一括請求できます。検知の仕組み・対応範囲・費用を見比べて、自社に合うサービスを選べます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
