2026年夏、通信、電力、ITサービス、ECなど、さまざまな業界で不正アクセスや情報漏えいが相次いで公表されました。これらのニュースを見ると、「自社では同じことが起きないように対策しなければ」と考えるのではないでしょうか。一方で、もし事故が起きてしまったとき、すぐに動ける準備はできているでしょうか。

もちろん、事故を防ぐための対策は重要です。しかし、どれだけ対策してもリスクを完全にゼロにすることはできません。だからこそ、「起きないための対策」と同時に、「起きたときの動き方」も考えておく必要があります。

9月は「防災の日」などをきっかけに、自然災害への備えを見直す機会が増える時期です。地震や豪雨と同じように、情報セキュリティ事故も発生する日時を選ぶことはできません。だからこそ、「起きないようにする」だけでなく、「起きたらどう動くか」「そのために普段から何を準備しておくか」まで考えておくことが重要です。

今回は、最近の情報セキュリティ事故における企業の対応を手掛かりに、情シス・情報セキュリティ担当者が知っておきたい「初動」と、万一に備えて平時から準備しておきたいことを考えます。

最近の情報事故をいくつか調べてみると、原因も発見のきっかけもさまざまでした。ところが、事故が分かってからの動きを追ってみると、各社に共通していることがあります。まずは、2026年夏に公表された3つの事例を見てみましょう。

業界	発覚のきっかけ	初動対応
通信	第三者製ソフトウェアの脆弱性を悪用した不正アクセスを確認	確認当日にシステムを改修し、技術的な防御措置を実施。影響範囲・原因の調査を継続し、第一報・続報を公表
電力	第三者機関からの情報提供をきっかけに、一部システムの資格情報の不正利用が判明	確認したその日のうちに資格情報を無効化し、不正アクセス元を遮断。重要システムへの影響を確認しつつ、外部専門機関と調査を進め、関係機関へ報告・相談
EC	不正アクセスの発生を確認	直ちにサイトを一時停止してアクセスを制限。外部委託業者と連携し、原因調査・ログ解析を開始

これらを比較して見ると、事故の原因も、発見のきっかけも異なりますが、発覚後の動きには共通点があります。各社とも、事故の全容が明らかになるまで待つのではなく、まず被害を広げない初動をしているということです。

ここで、もう一つ気になることがあります。最近の情報事故は、発覚してから企業が第一報を出すまでが、以前より早くなったように感じませんか。調査の途中でもまず公表し、新しい事実が分かると続報を出すケースがほとんどです。

ではなぜ企業の報告は早くなったのでしょうか。

その理由の一つに、個人情報漏えいに関する制度の変化があります。2022年4月に施行された改正個人情報保護法では、一定の要件に該当する個人データの漏えい等について、個人情報保護委員会への報告と本人への通知が義務化されました。対象となる事案では、発覚から概ね3～5日以内に「速報」を行い、その時点で把握している内容を報告します。その後、原則30日以内、不正な目的で行われたおそれがある場合などは60日以内に「確報」を行います。

発覚 → まず報告する → 調査を続ける → 詳細を確定して報告する、という考え方です。

IPA（情報処理推進機構）の「中小企業のためのセキュリティインシデント対応の手引き」でも、インシデントを検知した場合には、あらかじめ定めた対応方針に従って体制を立ち上げ、速やかに情報セキュリティ責任者や経営者へ連絡することが示されています。

情報セキュリティ事故は、もはや情シスだけで原因を調査して終わる技術的なトラブルではありません。顧客や取引先への影響、個人情報、事業継続、企業としての説明責任なども含めて対応する「企業の非常事態」として考える必要があります。

では実際に、自社で情報事故が発覚したら何をすればよいのでしょうか。

身近な例として、クレジットカードを紛失した場合を考えてみましょう。

カードが見当たらないとき、まず「どこで落としたか」「どこで盗まれたか」と考えるでしょう。しかし、原因を突き止めるまでカードを止めずに待つ、という人は少ないのではないでしょうか。

まず利用を停止する。そして利用履歴を確認し、不正利用がなかったかを調べ、必要に応じて再発行などの手続きを行うと思います。情報セキュリティ事故も基本的な考え方は同じです。

簡単に手順を並べると以下のとおりです。

最近の事例でも共通していましたが、ここで重要なのは、原因究明より先に被害拡大を止めることです。

米国国立標準技術研究所（NIST）が2025年に公開したインシデント対応ガイドライン「SP 800-61 Rev.3」では、インシデント対応を事故発生後だけの作業として捉えるのではなく、平時の準備やリスク管理、検知、対応、復旧を含めた継続的な活動として位置づけています。また、米国サイバーセキュリティ・社会基盤安全保障庁（CISA）のインシデント対応に関するプレイブックでも、「Containment（封じ込め）」が重要な対応として位置づけられています。

では、「まず被害を広げない」ことが共通なら、その後も同じように対応すればよいのでしょうか。ここからは、事故の原因によって変わってきます。原因が違えば、「何を止めるか」「何を確認するか」も変わります。代表的なケースを整理すると、次のようになります。

事故の主な原因	初動で確認・実施すること
認証情報（ID・パスワード等）の不正利用	該当アカウントの無効化、セッションの遮断
システムの脆弱性の悪用	対象システムのネットワークからの隔離、修正プログラムや暫定対策の適用
マルウェア感染	感染端末・ネットワークの隔離、他端末への感染拡大の確認
内部関係者による不正の疑い	アクセス権限の停止、操作ログなど証跡の保全

つまり、「まず被害を広げない」という初動の原則は共通していても、具体的に何を止め、何を確認するかは、事故の内容に応じて判断していく必要があるということです。

ここまでは実際の事例や初動の考え方を見てきました。では、これを自社に置き換えるとどうでしょうか。大企業で情報セキュリティ事故が発生した場合には、セキュリティ部門、法務、広報、経営層、外部のセキュリティ専門会社など、多くの関係者が対応にあたります。しかし、専任の情報システム担当者が少ない企業では、同じような体制を整えることは難しいかもしれません。

例えば金曜日の18時に、「自社システムに不正アクセスされた可能性があります」と連絡が入った時、あなたならどうしますか。

誰がシステムを止める判断をするのか。誰が経営者へ報告するのか。個人情報が漏えいした可能性がある場合、誰が関係機関への報告を判断するのか。顧客や取引先への連絡は誰が担当するのか。自社だけで原因を調査できない場合、どこへ相談するのか。

事故が起きてから、一つずつ調べて決めている時間はありません。情報セキュリティ事故への対応は担当者個人の知識や経験だけに頼るのではなく、企業として「誰が判断し、誰が動き、誰に相談するのか」を平時から決めておくことがとても重要です。

9月1日は「防災の日」です。地震や豪雨などの自然災害に備えて、避難経路や緊急連絡先を確認するように、情報システムについても「万が一」を想定してみてはいかがでしょうか。

情報事故への備えは、大きく3つに分けて考えることができます。

6-1．「誰が何をするか」を決めておく

まずは、事故発生時の連絡先や責任者、システムを停止する権限を持つ人、外部の相談先などを確認しておきます。特に重要なのは、「誰が判断し、誰が動くのか」を明確にしておくことです。夜間や休日でも対応を始められる体制になっているか確認しておきましょう。

6-2．「情報システムの防災訓練」をしてみる

ここまで読んで、「マニュアルを作っておけば大丈夫」と思うかもしれません。ただ、実際にその通り動けるかどうかは別の話です。そこで、簡単な机上訓練をしてみるのも有効です。

例えば「金曜日18時、不審なアクセスが見つかった」と仮定して、誰に連絡するか、誰がアカウントを止めるか、どのログを確認するかを順番に確認します。

実際にシミュレーションすることで、連絡先が古い、権限を持つ人が不在、必要なログの場所が分からないといった「準備の穴」を見つけることができます。

6-3．事故のリスクと、万一の損失に備える

もう一つ、事故が起きる前にできることがあります。平時から脆弱性診断などを活用して自社システムの弱点を把握し、優先順位を付けて改善しておくことです。

ただし、どれだけ対策しても情報事故の可能性を完全にゼロにはできません。原因調査や復旧など、事故によって生じる損失への備えとして、サイバー保険を活用する考え方もあります。ドコモソリューションズが提供する脆弱性診断サービスでは、システムの弱点を確認する診断に加えて、万一の場合に備えたサイバー保険も付帯しています。

事故を起こしにくくする備えと、事故が起きても動ける備え。その両方を平時から準備しておくことが重要です。

ここまで見てきたように、情報事故の原因はさまざまです。それでも、発覚した直後にまず被害の拡大を防ぐ、という考え方は共通しています。

そのとき迷わず動けるかどうかは、平時の準備にかかっています。誰が判断し、誰が動き、誰に相談するのか。実際に一度シミュレーションしてみると、自社に足りない備えも見えてくるはずです。

「明日もし起きたら、すぐ動けるか」。

9月の防災を考えるこの機会に、自社の情報システムについても「初動」と「備え」を確認してみてはいかがでしょうか。

参考情報・出典

2026年夏の情報セキュリティ事故事例

通信業界の事例：KDDI株式会社「ISP事業者向けメールシステムに対する不正アクセスについてのお詫びとご報告」（2026年7月6日）
https://newsroom.kddi.com/news/assets/2026/kddi_nr_s-73_4619/kddi_nr_s-73_4619_pdf_01.pdf

電力業界の事例：中部電力株式会社「不正アクセスによる情報漏えいの可能性について」（2026年8月4日）
https://www.chuden.co.jp/publicity/press/1218169_3273.html

ECサービスの事例：加賀ソルネット株式会社「当社ECサイトに対する不正アクセスに関するご報告とお詫び」（2026年7月1日）
https://www.kgem.co.jp/news/news260701/

制度・インシデント対応に関する資料

個人情報保護委員会「漏えい等の対応とお役立ち資料」
https://www.ppc.go.jp/personalinfo/legal/leakAction/

個人情報保護委員会「漏えい等報告・本人への通知の義務化について」
https://www.ppc.go.jp/news/kaiseihou_feature/roueitouhoukoku_gimuka/

IPA（情報処理推進機構）「中小企業のためのセキュリティインシデント対応の手引き」（中小企業の情報セキュリティ対策ガイドライン第4.0版 付録8、2026年6月）
https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_incidenttebiki.pdf

NIST「Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile（SP 800-61 Rev.3）」
https://csrc.nist.gov/pubs/sp/800/61/r3/final

CISA「Federal Government Cybersecurity Incident and Vulnerability Response Playbooks」
https://www.cisa.gov/resources-tools/resources/federal-government-cybersecurity-incident-and-vulnerability-response-playbooks