情報漏洩のインシデント対応マニュアルの作り方｜起きてからでは遅い、今整備すべき手順とは

サイバー攻撃や情報漏洩のニュースは、もはや特定の業界だけの話ではなくなりました。個人情報保護委員会に報告された2025年度の個人情報漏えい等事案は、民間事業者だけで約1万7000件と、過去2番目の多さに達しています。2026年7月にも、国内外で情報漏洩・サイバー攻撃に関する事案が相次いで公表されました。

本記事では、こうした直近の事例と統計を踏まえながら、「起きてから考える」のでは遅い、事前に定めておくべきインシデント対応マニュアルについて、mayclassの視点から解説します。

情報漏洩はどの会社でも起こり得る｜まず知っておきたい「インシデント」とは

「インシデント」とは、会社の情報やシステムに関して起きた、事故やトラブルのことです。

たとえば、

個人情報を誤って別の人に送ってしまった
パソコンやUSBメモリを紛失した
不正アクセスを受けた
ウイルスに感染した
システムが停止し、業務ができなくなった

といったケースが該当します。

「インシデント＝大規模なサイバー攻撃」と考えがちですが、メールの誤送信など、日常業務の中で起こる小さなミスも含まれます。

個人情報の漏洩は、年間1万件を超えて報告されている

2025年度に報告された個人情報の漏洩等の事案は、民間事業者だけで約1万7,000件、行政機関等を含めると約1万9,000件にのぼりました。

つまり、情報漏洩は一部の大企業だけに起こる問題ではありません。

企業の規模や業種に関係なく、どの会社でも起こる可能性があるため、「起きないようにする対策」だけでなく、起きたときにどう動くかを事前に決めておくことが重要です。

発生直後には、被害の全体像が分からないこともある

2026年7月には、国内企業で不正アクセスによるシステム障害が発生し、商品の入出庫や出荷業務に影響が出る事案もありました。

発生直後は個人情報の流出が確認されていなかったものの、その後の調査で、被害を受けたサーバーに個人情報が保存されていたことが分かり、漏洩の可能性がある事案として届け出られています。

このように、インシデントが起きた直後には「何が起きたのか」「どこまで影響しているのか」が分からないこともあります。

だからこそ、担当者がその場で判断するのではなく、「誰に報告するか」「何を確認するか」「誰が対応を判断するか」まで、あらかじめマニュアルで決めておくことが大切です。

参照：個人情報保護委員会への報告状況を集計した調査

なぜ「起きた後」の対応で被害が拡大するのか

CISAが公表した教訓｜手順書未整備がもたらした遅れ

2026年7月11日、米国のサイバーセキュリティ・インフラセキュリティ庁（CISA）は、自らの認証情報が個人のGitHubリポジトリ上に約6か月間公開されていたインシデントについて、対応の経緯と教訓を公式に公表しました。同庁が公表した内容によると、GitHubやクラウドサービスに関するインシデント対応手順があらかじめ整備されていなかったこと、外部からの報告経路が分かりにくく発見者が複数の連絡手段を試す必要があったことなどが、明確な課題として挙げられています。国の専門機関ですら、手順書の未整備によって対応に遅れが生じることがあるという事実は、多くの企業にとって重い教訓だといえます。

「誰が・何を・どの順に」が決まっていないことの怖さ

情報漏洩やサイバー攻撃が疑われる事態が発生した際、多くの現場でまず起きるのは「誰に報告すればよいか分からない」「誰が対応方針を決めるのか分からない」という混乱です。この初動の遅れが、被害範囲の拡大や、報告・公表の遅れにつながり、結果として企業の信頼を大きく損なうことになります。

インシデント対応マニュアルに盛り込むべき項目

インシデント対応マニュアルでは、単に「問題が起きたら上司に報告する」と決めるだけでは不十分です。

発見 → 初動対応 → 状況確認 → 社内外への報告 → 復旧 → 再発防止まで、誰が・何を・どの順番で行うのかを整理しておきます。

実際にトラブルが発生すると、「これは情報漏洩なのか」「パソコンを止めてもよいのか」「顧客へ連絡すべきか」など、判断に迷う場面が多く発生します。

そのため、担当者の経験だけに頼らず動けるよう、次の項目を具体的に決めておくことが重要です。

検知・初動対応（発見時の連絡フロー）

異常を発見した従業員が、誰に、どの手段で、何を報告するのかを明文化します。

たとえば、次のような情報です。

いつ発見したか
何が起きているか
どの端末・システムで起きたか
個人情報や機密情報が関係している可能性があるか
現在も異常が続いているか
発見後に何か操作を行ったか

あわせて、夜間・休日や責任者不在時の連絡先も決めておきます。

さらに重要なのが、「発見者が自己判断で何をしてはいけないか」まで決めておくことです。

たとえば、不審なメールやファイルを慌てて削除すると、原因調査に必要な記録まで失われる可能性があります。インシデントの種類に応じて、「ネットワークから切り離す」「メールやファイルを削除しない」などの初動ルールを事前に定めておくことが重要です。IPAも、インシデント発生時には証拠保全を含めた初動対応を平時から決めておくことを推奨しています。

被害範囲の特定と社内外への報告基準

次に確認するのが、「何が、どこまで影響を受けているのか」です。

マニュアルには、少なくとも次の確認項目を入れておきます。

漏洩・紛失した可能性のある情報
個人情報が含まれているか
対象となる人数・件数
影響を受けた端末・サーバー・クラウドサービス
外部へ情報が送信された可能性
不正アクセスが継続している可能性
業務への影響
顧客や取引先への二次被害の可能性

そのうえで、「情報システム部門へ報告」「経営者へ報告」「個人情報保護委員会へ報告」など、被害の内容に応じたエスカレーション基準を決めておきます。

個人データの漏えい等について、個人の権利利益を害するおそれがある一定のケースでは、個人情報保護委員会への報告と本人への通知が必要です。報告対象となる場合、委員会は発覚後速やかな速報を求めており、目安は3〜5日以内、確報は原則30日以内、不正アクセス等の場合は60日以内とされています。

発生してから法令を調べるのではなく、「どのケースなら誰が法務・個人情報保護担当へ確認するか」までマニュアル化しておくことがポイントです。

被害拡大を防ぐための対応と証拠保全

インシデントを確認した後は、原因調査と並行して被害の拡大を防ぐ必要があります。

たとえば、

対象端末をネットワークから切り離す
不正利用されたアカウントを停止する
パスワードを変更する
外部公開しているシステムを一時停止する
委託先やシステム会社へ調査を依頼する

といった対応が考えられます。

ただし、対応方法を誤ると、調査に必要なログやデータを失う可能性があります。

そのためマニュアルでは、「誰がシステムを止める判断をするのか」「誰がログや端末を保全するのか」まで役割を決めておくことが重要です。IPAも、インシデント対応では「検知」「報告」「封じ込め」「復旧」という流れで対応し、被害状況の把握や証拠保全を行うことを示しています。

顧客への連絡・公表・メディア対応の判断基準

インシデントが発生しても、すべてのケースで記者会見が必要になるわけではありません。

一方で、被害規模や社会的影響が大きい場合には、顧客への通知、Webサイトでの公表、取引先への説明、場合によってはメディア対応が必要になります。

そのため、

誰が対外公表の必要性を判断するか
どの時点で経営者へ報告するか
顧客へどのように連絡するか
公表文を誰が作成・確認するか
問い合わせ窓口を誰が担当するか
メディアから連絡があった場合、誰が回答するか

まで決めておきます。

特に注意したいのは、調査途中の不確かな情報を各担当者が個別に発信しないことです。

「誰が情報を取りまとめ、誰の承認を受けて公表するのか」を一本化しておくことで、発表内容の食い違いや混乱を防ぎやすくなります。IPAも、平時から外部報告や公表のルールを定めておくことの重要性を示しています。

再発防止・是正措置の記録

インシデント対応は、システムが復旧した時点で終わりではありません。

発生から収束までの経緯を振り返り、

いつ何が起きたのか
どのように発見されたのか
どのような判断・対応をしたのか
被害範囲はどこまでだったのか
なぜ発生したのか
初動対応に問題はなかったか
再発防止のために何を変更するのか

を記録します。

IPAも、インシデント対応では5W1Hを意識して時系列で情報を整理し、証拠を保全したうえで復旧・再発防止につなげることを示しています。

さらに重要なのは、記録して終わらせないことです。

インシデントから得られた教訓をもとに、

「連絡先が分かりにくかった」
「判断者が不在で対応が止まった」
「担当者によって初動対応が違った」

といった課題が見つかれば、マニュアルそのものを更新します。

こうして、インシデントが発生するたびに対応方法を改善できる仕組みまで作っておくことが、実際に機能するインシデント対応マニュアルにつながります。

「機能する」インシデント対応マニュアルにするためのポイント

平時からの訓練・シミュレーション

マニュアルを作成しただけでは、実際の緊急時に落ち着いて対応できるとは限りません。定期的に模擬訓練を行い、手順の抜け漏れや分かりにくい部分を洗い出しておくことが重要です。

定期的な見直しと最新事例の反映

サイバー攻撃の手口は日々変化しています。CISAの事例のように、他社や海外機関で発生したインシデントの教訓を自社のマニュアルに反映し、定期的に更新し続けることが求められます。

【図表挿入：情報漏洩発覚から収束までのインシデント対応フロー】

情報漏洩対応は技術対策とマニュアル整備の両輪で

予防（技術）と対応（手順）は別の課題

情報漏洩対策というと、ファイアウォールやアクセス制御といった技術的な予防策に目が向きがちです。しかし、どれだけ予防策を講じても、インシデントの発生確率をゼロにすることはできません。「起きてしまった後、どう対応するか」という手順の整備は、技術的な予防策とは別に取り組むべき課題です。

判断基準の言語化が被害の拡大を防ぐ

mayclassでは、緊急時にこそ、現場の判断基準があらかじめ言語化されているかどうかが問われると考えています。ベテラン担当者の頭の中にしかない「こういう場合はこう動く」という暗黙知を、誰が見ても同じ判断ができるマニュアルとして落とし込んでおくことが、被害の拡大を防ぐ鍵になります。

まとめ｜インシデント対応マニュアルは「もしも」に備える経営課題

個人情報漏えいの報告件数が高止まりし、国内外で情報漏洩・サイバー攻撃の事例が相次ぐ今、情報漏洩のインシデント対応マニュアルの整備は、情報システム部門だけの課題ではなく、経営課題として位置づける必要があります。「起きてから考える」のではなく、平時のうちに対応手順を明文化し、訓練を重ねておくことが、いざというときの被害を最小限に抑える最も確実な備えです。

株式会社mayclassは、業務の可視化と暗黙知の抽出を通じて、緊急時にも機能する実践的なマニュアルづくりを支援してきました。情報漏洩やサイバー攻撃に備えたインシデント対応マニュアルの整備にご関心をお持ちの方は、ぜひ一度ご相談ください。支援実績の詳細はmayclassの支援事例集をご覧ください。また、サービス内容や費用感についてはお問い合わせページよりお気軽にご連絡ください。

防災マニュアルとは？作り方・テンプレート・整備のポイントまで徹底解説

カスハラ対応マニュアルの作り方｜2026年10月義務化に向けた企業対応と整備ポイント