自社からの情報漏洩が発覚した場合、全容不明の状況でも初動の公表で何を出すべきか

システムへの不正アクセスや個人情報漏洩の疑いが発覚した直後は、被害人数も侵入経路もすぐには確定しません。原因の特定やログの解析には数日から数週間かかるのが一般的です。

しかし、「全容が解明されるまで対外公表を控える」という判断は、かえって二次被害の拡大や組織への不信感を招きます。初報で伝えるべき内容は、調査の最終結論ではなく「現時点で判明している事実（現在地）」と「利用者が直ちに取るべき自衛手順」です。

直近の公表事例の傾向や個人情報保護委員会への報告ルールを踏まえ、被害の全貌が見えない段階でどのような初報を出すべきかを整理します。

初報までの期間は短期化している

国内の公開情報を集計した2026年10月の調査によると、セキュリティ事案を認知してから最初の公表を行うまでの日数は急速に短くなっています。2026年5月時点では認知から公表まで平均10.9日を要していましたが、9月には平均2.9日、中央値ではわずか1日となりました。

公表件数が増加している背景には、攻撃自体の増加だけでなく、被害の確定を待たずに初報を速やかに出す組織が増えた影響があります。

直近1週間の公表を見ても、次のような対応が目立ちます。

• 侵入を検知した当日に該当機能を停止し、数日後に被害人数の上限の「可能性」をデータ種別ごとに公表した事例
• 被害件数は空欄のまま、外部送信された可能性があるデータの種類と認証情報の鍵のみを明記して即座に注意喚起を行った事例
• 最初の公表で漏洩の可能性を公表して機能を遮断し、その後の調査で「外部流出の痕跡なし」と判明して続報で訂正・報告した事例

いずれも「全容が分かるまで待つ」のではなく、「現時点で確認できた事実と対処」を即座に知らせる姿勢をとっています。

個人情報保護委員会への報告と、利用者への対外公表の違い

事故対応にあたっては、監督官庁への法的な報告義務と、利用者に向けた注意喚起・対外公表の手続きを分けて考える必要があります。

個人情報保護委員会への報告は、漏洩が発生したとき、または発生したおそれがある場合に義務づけられます。具体的には、次の4つの要件のうち1つでも該当する場合です。

• 要配慮個人情報（病歴や信条など）が含まれる事案
• 財産的被害が生じるおそれがある事案（クレジットカード番号や不正送金につながる口座情報など）
• 不正の目的で行われたおそれがある事案（不正アクセスやランサムウェア攻撃など）
• 本人の数が1,000人を超える事案

報告は2段階に分かれています。事態を認知してから速やかに提出する「速報」（ガイドライン上の目安はおおむね3〜5日以内）と、認知から30日以内（不正アクセスの場合は60日以内）に詳細を提出する「確報」です。この日数は経営会議で承認された日ではなく、社内のいずれかの部署が事故の発生を知った時点から起算されます。土日や祝日も日数に含まれます。

一方で、利用者への対外公表は、法令報告の文面が完成するのを待つ必要はありません。利用者をフィッシングやアカウント乗っ取りから守るため、速報と並行して速やかにお知らせを出す判断が求められます。

初報を出さずに調査を待つことで生じる4つのリスク

全容が確定するまで沈黙を続けると、次のような深刻な実害が生じます。

1. パスワード使い回しによる二次被害
   漏洩の可能性が公表されない間、利用者は他サービスで同じパスワードを変更するきっかけを持てません。その間にも不正ログインの被害が拡大します。

2. 偽の注意喚起メールへの便乗被害
   事故が水面下で進んでいる間に、公式を騙るフィッシングメールが出回る危険があります。公式サイトに公式の初報が掲載されていないと、利用者はどの連絡を信じてよいか判断できません。

3. 利用企業や委託先が対応不能に陥る
   クラウドや委託先サービスで事故が起きた場合、一次提供元が初報を出さない限り、そのサービスを利用している企業は自社の顧客へ説明ができません。

4. 後からの修正が「隠蔽」と受け取られる
   最初は沈黙し、後から「実は数万人分漏洩していました」と公表すると、調査に時間を要しただけであっても意図的に隠していたと受け取られやすくなります。

断定的な「安全宣言」を避ける

初報を作成する際、もっとも注意すべき点は「まだ確認できていないことを、否定形で断定しない」ことです。

「外部への情報流出は一切ありません」と言い切ってしまうと、その後のフォレンジック調査で持ち出しの痕跡が見つかった場合、信頼の失墜は避けられません。「現時点の調査では、外部への持ち出しを示す痕跡は確認されていません」と書くことで、調査の進捗に合わせた正確な状況報告が可能になります。

また、攻撃の手法や脆弱性の詳細を初報に書く必要はありません。同一のソフトウェアを使っている他社への模倣攻撃を誘発する恐れがあるためです。初報で重要なのは、攻撃の手口を解説することではなく、停止した機能の範囲と利用者が取るべき対策を明示することです。

被害人数が未確定でも初報に盛り込める7項目

被害の規模や人数が正確に分からなくても、次の7項目が揃っていれば初報として十分成立します。

• 発生した事象の概要：何が起きたのか（不正アクセスを検知した、情報流出の可能性があるなど）を端的に記述
• 認知した日時：社内でいつ異常に気づいたか
• 実施済みの緊急措置：外部通信の遮断、該当サーバーの停止、管理者権限の失効など、すでに講じた一次対応
• 対象となる可能性がある情報項目：流出が疑われるデータの種類と、現時点で対象外と判断している範囲（どちらにも「現時点」と明記）
• 利用者が直ちに取るべき対応：同一パスワードの変更、公式を装う不審メールへの警戒、公式サイトの正規URLの案内
• 現在調査中の事項：正確な対象人数や根本原因など、まだ判明していない項目
• 次回報告の予定：続報をいつ出すか、または情報が更新される告知ページのURL

調査を担当するエンジニアと、公表文を作成して承認する担当者は通常異なります。有事の当日に承認ルートや公表場所を議論していると時間は過ぎていきます。誰の判断で初報を出すのか、どのURLに掲載して続報を更新していくのかは、平時の運用手順として決めておく必要があります。

自社サイトの確認手順や委託先への確認項目については、前回の記事「情報漏洩が続いている状況で、法人として優先して確認すべきこと」でも詳しく解説しています。

生成AIの導入活用支援では、業務システムやクラウドツールを安全に利用するための社内ルール策定や、セキュリティ運用体制の整理も支援しています。

参照

この記事で解説した報告期限や法令基準は、2026年10月23日時点で施行されている個人情報の保護に関する法律施行規則および個人情報保護委員会の各種ガイドラインに基づきます。2026年7月17日に公布された改正法（令和8年法律第56号）の見直し事項は、公布から2年以内の施行日以降に適用されます。

• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
• 個人情報保護委員会「漏えい等の対応」
• 個人情報保護委員会「大規模な漏えい等事案を踏まえた対応について（注意喚起）」（2026年10月7日）

認知から初報公表までの平均日数のデータは、国内のWebシステム・アプリにおける不正アクセス事案を対象とした2026年10月15日公表の公開集計資料に基づきます（5月平均10.9日、9月平均2.9日、中央値1日、対象119件）。