個人情報事故事例を原因別に整理｜傾向と初動対応の要件を確認

個人情報事故（情報漏えい・流出）のリスクが現実味を帯びると、まず「どんな事故が起き得るのか」「自社はどこで漏えい等に至りやすいのか」を原因別に把握し直す必要があります。これを曖昧なまま進めると、漏えい該当性の見誤りや報告・本人通知の要否判断の遅れにより、対外説明の整合性が崩れたり、再発防止策が的外れになったりしがちです。たとえば本人の数が1,000人を超える漏えい等は報告対象事態になり得るため、件数・データ項目・経路を早期に切り分ける視点が欠かせません。以下では、個人情報事故の整理と初動対応の判断材料として、類型・傾向・事例・実務対応を示します。

個人情報事故の定義と類型

個人情報と個人データの違い

実務では、個人情報と個人データの差は「データベース等として検索できる状態か」にあります。個人情報は、生存する個人に関する情報で、氏名・生年月日などにより特定の個人を識別できるものを含みます。一方で個人データは、個人情報のうち個人情報データベース等（検索できるよう体系的に構成されたもの）を構成するものを指し、企業の管理義務が強く意識される領域です。

たとえば、名刺や手書きメモが散在している段階は「個人情報」にとどまることが多い一方、顧客管理システムやダイレクトメール送付先リストのように「氏名・住所・電話番号」等が一覧化され、検索・抽出して使える状態にすると、個人データとしての性格が明確になります。参照例でも「約1,500人分の氏名・住所・電話番号等が記載されたダイレクトメール送付先リスト」がメール誤送信の対象になっており、まさに個人データが実務事故の中心になりやすいことが分かります。

個人データに該当すると、漏えい等が起きた場合に個人情報保護委員会への報告や本人通知が問題になります。一定の条件を満たす漏えい等については、個人情報保護法第26条（個人情報保護法第26条）に基づく報告・通知義務が論点化するため、法務・情シスは「どの情報が個人データとして運用されているか」を棚卸ししておく必要があります。

個人情報事故に含まれる態様

個人情報事故は、外部への「漏えい」だけではなく、滅失（消失）や毀損（改ざん・破壊）も含めた「漏えい等」として整理されます。個人情報保護法上も、一定の条件を満たす個人データの漏えい・滅失・毀損が発生した場合に、報告・通知が問題になります（個人情報保護法第26条（個人情報保護法第26条））。

とくに見逃しがちなのは、メール誤送信が起きた場合に「常に漏えいになる」と決め打ちしないことです。ガイドライン上は、誤送信先が社内の者にとどまる場合は漏えいに該当しないと整理され、また誤送信先から「閲覧前に削除した」旨の申告を受けるなどして閲覧していないことを確認できれば、漏えいに該当しないと解され得ます（個情法GL（通則編）3-5-1-1、Q&Aの整理）。したがって、初動では「事故態様の分類」だけでなく、漏えい該当性の事実認定が重要です。

個人情報事故の件数と傾向

漏えい件数と被害規模の推移

個人情報漏えいは、サイバー攻撃・委託網・クラウド活用の拡大により、単一事故でも影響範囲が大きくなりやすい構造です。参照例でも、標的型攻撃の具体例として、2015年の日本年金機構へのサイバー攻撃により約125万件の個人情報が外部流出した事案が示されています。これは、一定の組織を狙い撃ちする攻撃が現実に大規模被害につながり得ることを示す材料です。

標的型攻撃は「不特定多数を狙う攻撃」と異なり、目的情報を得るまで執拗に試行される特徴があるとされます。そのため、対策を講じていても侵入を完全に排除する前提ではなく、侵入後の検知・封じ込め・復旧までを含めた実務設計が不可欠です。

また、報告義務の観点では、本人の数が1,000人を超える個人データの漏えい等、またはそのおそれがある場合は、報告対象事態として整理されています（報告対象事態の類型「4」「5」）。たとえば参照例の誤送信事案では、ダイレクトメール送付リストに1,500人分が含まれているため、類型「4」を満たし、個人情報保護委員会への報告および本人通知が義務付けられる、と具体的に説明されています。

公表事例を読むときの見分け方｜漏えい確定・漏えいのおそれ・閲覧可能状態の違い

公表資料（プレスリリース等）を読む際は、「漏えい確定」「漏えいのおそれ」「閲覧可能状態」を切り分け、報告対象事態に該当するか（または該当のおそれがあるか）を見極める必要があります。報告対象事態は、次の類型（および「1〜4のおそれ」）として整理されています。

「おそれ」については、個情法GL（通則編）の説明として「その時点で判明している事実関係から漏えい等が疑われるものの確証がない場合」と整理され、個別事案ごとに蓋然性を考慮して判断するとされています。したがって、公表文に「漏えいは確認されていない」と書かれていても、類型5（おそれ）として報告・通知の要否が残ることがあり、表現だけで軽重判断しない姿勢が実務上重要です。

原因別の個人情報事故事例

不正アクセスとサイバー攻撃

不正アクセス・サイバー攻撃は、外部者が侵入して個人データを持ち出すだけでなく、ランサムウェア等によりデータが暗号化され、業務が停止する形でも顕在化します。個人情報保護委員会への報告対象事態の整理では、ランサムウェアによる被害は「不正の目的をもって行われたおそれのある個人データの漏えい等」（類型3）として報告義務の対象になると説明されています。

また、標的型攻撃の実例として、2015年に日本年金機構に対してサイバー攻撃が行われ、約125万件の個人情報が外部に流出したことが示されています。金銭目的の攻撃であれば、対象が対策を強化すると攻撃対象が変わる可能性がある一方、標的型攻撃では対策状況にかかわらず目的情報を得るまで執拗に攻撃され得る、という特徴が指摘されています。

初動の対外開示文面も、実務で参照される型があります。参照例では「2025年5月13日」「第一報」として、ファイルサーバがランサムウェアと思われる攻撃を受け、直ちにネットワーク遮断し、警察およびセキュリティ専門会社に相談して調査開始、取引先影響の可能性、詳細判明次第の開示、という骨子が示されています。公表の巧拙は別として、最低限「遮断・相談・調査開始・影響の見通し・続報方針」を含めることが、対外説明の一貫性確保に資します。

メール誤送信と誤表示の事故

メール誤送信や誤表示は、日常業務の人的ミスに起因しやすい一方で、個人データの漏えい等に直結し得ます。参照例では、X社担当者が、本来はY社難波支店宛てに送るべき「約1,500人分の氏名・住所・電話番号等」が記載されたダイレクトメール送付先リストを、同姓同名の別会社Z社京橋支店担当者宛てに誤送信したケースが示されています。

この種の事故は「送信前の誤添付確認」「大量送信・機微情報送信時のダブルチェック」「送信後に取り消せる遅延（保留）機能」など、工程設計でのミス低減が要点になります。一方、確認画面を常時出すだけの仕組みは、ボタン連打による形骸化が起き得るため、参照例では「一定条件のメール送信を検知した場合にのみ送信前確認を求める」設計のほうが望ましいと説明されています。

同じ誤送信でも報告要否が分かれる基準｜BCC漏れ・誤添付・送信先誤りをどう切り分けるか

誤送信時の報告要否は、「件数」だけでなく、報告対象事態の類型（要配慮・財産的被害・不正目的・1,000人超・おそれ）に該当するかで決まります。類型4は「本人の数が1,000人を超える個人データの漏えい等」であり、参照例の1,500人分の送付先リスト誤送信は、この観点で報告・本人通知が問題になり得ます。

BCC漏れはメールアドレス（個人データ）を広範囲に開示しやすく、人数が大きくなりがちです。ただし、実務上は「まず漏えい該当性が成立するか（閲覧の有無、社内宛か等）」を確定し、成立する場合に類型該当性を評価する順序が、判断の混乱を減らします。

内部不正と委託先の流出

従業員の不正持ち出し事例

内部不正は、正規権限の悪用により検知が難しく、報告対象事態の整理でも「不正の目的をもって行われたおそれのある漏えい等」（類型3）として位置づけられています。参照例では、退職や転職を契機にした持ち出しが増えている旨が述べられ、技術的にUSB制御がされていても、個人クラウド（私用クラウドストレージ）にアップロードでき、ログ管理がない場合に「機会」が生まれる、という説明がされています。

また、営業秘密侵害に関しては、警察庁の整理として、相談受理件数が令和5年中に78件で、前年対比32.2%増とされています（参照例の数値）。個人情報事故そのものの統計ではないものの、内部持ち出しが「現実の相談・捜査対象」として増加していることを示す周辺材料として、経営者・法務は重く受け止める必要があります。

委託先管理不備で起こる流出

委託先で発生した漏えい等でも、委託元は「委託したから終わり」にはできません。報告事項の整理でも「委託元および委託先の有無」が報告項目に含まれており、委託構造の把握は初動から必要です（報告事項の「概要」に含まれる要素として整理）。

漏えい等が起きた場合の実務では、個人情報保護委員会への報告や本人通知に必要な事実（発生日・発覚日・原因・対象項目・対象人数・二次被害のおそれ等）を、委託先から迅速に吸い上げられる体制がないと、報告の品質が落ち、後日の説明整合性も崩れます。

退職者・委託先要員の見落としやすい失敗パターン｜権限停止、端末返却、ログ確認はどこで抜けるか

退職者・離脱要員は、内部者としての知識とアクセス権を持ったまま外部化するため、権限管理の抜けが事故に直結します。参照例でも、私用クラウドに会社データをアップロードして窃取するケースや、会社がクラウドサービスを利用している場合に「退職後も早急にIDを無効にしないと継続アクセスできる」点が指摘されています。

業種別にみる個人情報事故

金融とECの顧客情報リスク

金融・ECは、財産的被害に直結する情報を扱うため、報告対象事態の整理でも「不正に利用されることにより財産的被害が生じるおそれがある個人データ」（類型2）の典型例として、クレジットカード番号の漏えい等が明示されています。したがって、クレジットカード番号等を含む事故は、件数の大小以前に、財産被害のおそれという観点から報告・本人通知の要否が問題になり得ます。

医療と教育の要配慮個人情報

医療・教育は、要配慮個人情報を取り扱う場面が多く、報告対象事態でも「要配慮個人情報が含まれる個人データの漏えい等」（類型1）が明確に位置づけられています。参照例でも、医療上の個人情報は「健康情報等の取扱い者」が他の個人情報とは別途に保管すべきこと、収集目的に照らして保管不要となった個人情報は速やかに廃棄または削除すべきことが規程例として示されています。

個人情報事故の影響と対応

損害賠償と行政対応の範囲

個人情報事故は、民事（損害賠償）と行政（監督機関対応）が並行して発生します。行政面では、一定の条件を満たす漏えい等について、個人情報保護法第26条（個人情報保護法第26条）に基づき、個人情報保護委員会への報告および本人への通知が義務となります。

また、内部統制の観点では、情報管理が不十分なまま放置した結果としてハッカーに情報を盗まれた場合、取締役が善管注意義務（適切なリスク管理）を尽くさなかったとして、任務懈怠に基づく責任を問われ得る、という整理が参照例で示されています（会社法第423条第1項（会社法第423条）、会社法第429条第1項（会社法第429条）の可能性）。個人情報事故はIT部門だけの問題ではなく、経営判断・監督責任の問題として波及し得ます。

初動対応と報告公表の要件

初動対応は、技術対応（封じ込め）と法令対応（報告・通知）を同時並行で組み立てる必要があります。個人情報保護法第26条（個人情報保護法第26条）に基づく報告・本人通知が必要となる「報告対象事態」は、要配慮個人情報、財産的被害のおそれ、不正目的、1,000人超、ならびにそれらの「おそれ」を含む類型で整理されています。

参照例では、報告・本人通知で整理すべき事項が具体的に列挙されています。外部公表の巧拙以前に、まずこの項目を埋められるだけの事実関係を確保することが、法務・情シス連携の実務になります。

さらに、誤送信などでは「そもそも漏えいに該当するか」を初動で詰める必要があります。誤送信先が社内にとどまる場合は漏えい非該当になり得ること、誤送信先から「閲覧前に削除した」旨の申告を得て閲覧していないことを確認できれば漏えい非該当と解され得ることが示されており、誤送信先への直ちの連絡が重要とされています。

発覚から72時間までの社内動線｜情シス・法務・広報・経営陣がいつ何を確定させるか

社内動線は「いつ何を確定させるか」を具体項目に落とし込むほど機能します。参照例の「第一報」文面では、少なくとも「直ちにネットワーク遮断」「警察・セキュリティ専門会社へ相談」「原因究明の調査開始」「取引先影響の可能性」「続報方針」を同時に示しており、72時間設計でも同様の粒度が求められます。

個人情報事故の予防と評価

防げない組織課題と対策優先度

「防げない前提」を置く場合でも、どの事態が報告対象事態になりやすいかを把握して優先度を決めると、投資対効果の説明がしやすくなります。報告対象事態の類型では、(1)要配慮個人情報、(2)不正に利用されることにより財産的被害が生じるおそれがある個人データ、(3)不正目的、(4)1,000人超、(5)これらのおそれ、が明確に示されています。したがって、予防策の優先度は「これらに該当しやすいデータ領域・業務経路」を上位に置くのが実務的です。

また、紛失・盗難は「定番」の情報事故であり、暗号化がないまま個人情報や機密情報が含まれていると「紛失＝事故」に直結する、と整理されています。公共交通機関での置き忘れ、飲み会後の紛失、海外持ち出し時の紛失、車上荒らし、自宅侵入、カフェでの置き引き等、発生場面が具体的に示されているため、端末・媒体の暗号化やMDM等を優先度高く位置づける根拠になります。

セキュリティ基準と教育活用法

基準・教育は「知識付与」よりも、事故パターンに合わせて行動を変える設計が重要です。参照例では、メール誤送信対策として、東京都港区の2021年6月のCC/BCC誤り事案で、再発防止策として「送信先および送信方法を他の職員と確認し合うルールの徹底」および「職員への研修の実施」が挙げられたことが示されています。さらに、デジタル庁の2021年11月の同種事案では、Outlookで「送信メールを送信トレイに1分保留」し、送信後も一定時間宛先を確認できる設定を庁内に周知することが再発防止策として挙げられています。

一方で、確認画面を常時表示させる方式は形骸化し得るため、参照例では「一定条件を満たすメール送信を検知した場合のみ送信前確認を求める」設計が望ましいとされています。教育・運用設計では「人の注意」に依存しない工夫（条件付き強制、遅延、配信システム化・自動化）を、規程と訓練に落とし込む必要があります。

グループ会社と本社で統制水準を分ける判断基準｜共通ID、委託網、海外拠点のどこから優先するか

グループ統制は、まず「事故時に何を報告しなければならないか」を基準に逆算すると優先順位が付けやすくなります。参照例の報告事項では、概要として「委託元および委託先の有無」を含めることが明示されており、グループ内・委託網の関係が複雑なほど、事実関係の収集と説明が難しくなります。

統制水準を段階化する場合でも、最低限「アカウント無効化の迅速性」「ログの取得と保全」「委託先から必要情報を回収できる契約・運用」は、報告・通知の実務に直結するため、全社共通の下限として設計しておくべきです。

よくある質問

個人情報が何件漏えいすると報告義務が生じますか

件数だけで一律に決まるのではなく、報告対象事態の類型に該当するかで判断します。参照例の整理では、本人の数が1,000人を超える個人データの漏えい等（類型4）や、そのおそれ（類型5）は報告対象となり得ます。実例として、1,500人分のダイレクトメール送付先リストの誤送信は類型4を満たすため、個人情報保護委員会への報告および本人通知が義務付けられると説明されています。

また、件数が少なくても、要配慮個人情報が含まれる場合（類型1）や、クレジットカード番号のように財産的被害のおそれがある場合（類型2）、サイバー攻撃・従業員持ち出し等で不正目的が疑われる場合（類型3）は、報告対象になり得ます。

さらに「おそれ」は、「漏えい等が疑われるが確証がない場合」であり、個別事案ごとに蓋然性を考慮して判断すると整理されています。したがって「漏えいは確認されていない」という表現だけで報告不要と判断せず、類型5の該当性を検討する必要があります。

委託先で情報漏洩が起きたとき自社はどこまで責任を負いますか

委託先起因の事故でも、委託元が報告・本人通知を含む対応の主体として動く必要が生じ得ます。参照例の報告事項でも、概要に「委託元および委託先の有無」を含めることが挙げられており、委託構造の把握は報告実務の必須項目です。

委託先に求償するかどうかとは別に、報告・通知に足る事実が揃わない状態が最も危険です。契約・運用の段階から、必要情報が期限内に上がる体制（ログ・証跡、一次報告フォーマット等）を整えることが重要です。

中小企業の個人情報漏えい対策は何から始めるべきですか

優先順位付けの起点として、報告対象事態の類型（要配慮、財産被害、不正目的、1,000人超、おそれ）に該当しやすいデータ・経路から着手すると、少ない投資でも実効性が出やすいです。たとえば、名簿や送付先リストなど「1,000人超」になり得るデータ（類型4）、健康情報等（類型1）、クレジットカード番号等（類型2）は、取り扱いの範囲・保管場所・持ち出し経路を最初に固定化する価値が高い領域です。

「高価なツール」より先に、事故パターン（誤送信・紛失・シャドーIT・退職者）を前提に、持ち出し経路を潰し、ログ・証跡を残すことが、再発防止と説明責任の両面で効果的です。

個人情報事故への対応で次にすべきこと

個人情報事故は、まず「個人情報」と「個人データ」を切り分け、漏えい等（漏えい・滅失・毀損）の態様と、漏えい該当性を事実に基づいて認定するところから始まります。判断の軸は、個人情報保護法第26条（個人情報保護法第26条）に関わる報告対象事態の類型（要配慮、財産的被害、不正目的、1,000人超、おそれ）に当てはまるかで、件数だけで結論を出さないことが重要です。次のアクションとしては、情シスは封じ込めとログ・影響範囲の一次推定、法務・コンプラは報告・本人通知に必要な項目（発生日・発覚日・対象項目・本人の数・委託元/委託先の有無等）の充足を、並行して進める体制を整えてください。委託先が関与する場合は、必要情報を期限内に回収できる契約・運用になっているかも同時に点検が必要です。個別事案の該当性や公表文面の設計は事情で変わるため、必要に応じて専門家への相談も検討してください。

Baseconnect株式会社
サイト運営会社

本メディアは、「企業が経営リスクを正しく知り、素早く動けるように」という想いから、Baseconnect株式会社が運営しています。

当社は、日本最大級の法人データベース「Musubu」において国内1200万件超の企業情報を掲げ、企業の変化の兆しを捉える情報基盤を整備しています。

加えて、与信管理・コンプライアンスチェック・法人確認を支援する「Riskdog」では、年間20億件のリスク情報をAI処理、日々4000以上のニュース媒体を自動取得、1.8億件のデータベース等を活用し、取引先の倒産・不正等の兆候の早期把握を支援しています。

運営会社情報ページへ