【2026年10月】個人情報保護委員会の注意喚起を解説｜企業の漏えい対策

2026.10.09

はじめに――相次ぐ個人情報漏えいを受け、国が注意喚起

近年続発する企業サイトへの不正アクセス事例を受け、2026年10月7日、個人情報保護委員会は、「大規模な漏えい等事案を踏まえた対応について（注意喚起）」を公表した。

併せて、過去の漏えい事案を分析した資料「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」も改訂している。

注意喚起のポイントは、大きく3つに整理できる。

① 安全管理措置は、会社が保有する情報の量や性質、漏えいした場合のリスクに応じて考える。
② パスワードやウイルス対策だけでなく、侵入の防止・検知・被害拡大防止まで考える。
③ そもそも必要のなくなった個人情報を、いつまでも保存し続けない。

本記事では、この3つのポイントを中心に、具体例を交えながら今回の注意喚起の内容を解説する。

なお、今回の公表は新たな法律の施行ではなく、既存の個人情報保護法上の義務の再確認であり、今後予定されているガイドライン改訂の方向性を先行して示したものである。

個人noteの方でも近時話題になっているタイムズカー情報漏洩に関する技術的な解説をアップしています。

タイムズカー個人情報漏洩に学ぶ｜自社の被害規模（ブラストラジアス）試算と対策チェックリスト20選

1．ポイント① 安全管理措置は「会社ごとのリスク」に応じて考える

1-1．個人情報保護法は、具体的な対策をすべて決めているわけではない

個人情報保護法23条は、個人情報取扱事業者に対し、個人データの漏えいなどを防ぐために必要かつ適切な安全管理措置を講じるよう求めている。

しかし、会社によって取り扱う個人情報の種類や量、事業内容が大きく異なるため、法律そのものに「パスワードは何文字以上にする」「すべてのパソコンに特定のソフトウェアを導入する」といった詳細が列挙されているわけではない。

例えば、従業員数名の地域の小さな雑貨店と、全国展開するオンラインサービス会社にまったく同じ安全管理措置を求めることが合理的とは限らない。

つまり、安全管理措置は、単に会社の規模だけでなく、保有する情報の量や性質、漏えいした場合の被害の大きさに応じて考える必要がある。

今回の注意喚起も、この考え方を改めて強調している。

1-2．特に注意を求められている企業とは

今回、個人情報保護委員会は、特に注意が必要な事業者として、いくつかの類型を挙げている。

１　国民の多くが利用するサービスを提供し、大量の個人情報を保有している事業者である。
２　顧客が事業者を自由に選びにくいサービスを提供する事業者である。
３　機微性の高い情報や、財産的被害、詐欺などに利用されるおそれのある情報を保有する事業者である。

ここで重要なのは、個人情報の漏えいリスクを、単純に「何件漏れたか」だけでは判断できないことである。

例えば、顧客のメールアドレスが1,000件漏えいした場合と、免許証やパスポート画像が1,000件漏えいした場合では、想定される被害が異なる。

今回の注意喚起は、こうした情報の性質と保有量を踏まえ、必要な対策を検討するよう求めている。

1-3．「講じなければならない措置」と「手法の例示」は違う

今回の注意喚起で、法律上特に重要なのがこの区別である。

個人情報保護委員会のガイドラインには、安全管理措置について、次の2種類の記載がある。

講じなければならない措置：事業者が実施すべき基本的な措置
手法の例示：その措置を実現するための具体的な方法の例

例えば、「適切なアクセス制御を行わなければならない」というのが前者である。
一方、「特定のIPアドレスからのアクセスだけを許可する」「アクセス権限を定期的に監査する」といった方法は、後者に当たる。

ここを混同してはいけない。

今回の注意喚起は、「講じなければならない措置」に従わなければ法違反と判断される可能性がある一方、「手法の例示」をすべて実施しなければ直ちに法違反になるわけではないと説明している。

例えば、ある企業が特定のセキュリティ製品を導入していなくても、別の適切な方法で同じ目的を達成している場合がある。

反対に、ガイドラインに名前が出ている製品や技術を導入しただけで、安全管理措置が十分になるわけでもない。

重要なのは、何を導入したかではなく、どのようなリスクに対して、どの程度有効な対策を実施しているかである。

なお、ガイドラインの例示は法的義務そのものではないとしても、「例示だから何もしなくてよい」という意味ではない。
企業が漏えい事象に巻き込まれた場合、事前に対策をするコストと比較してその何十倍もの損害が発生する可能性がある。
事前対策のプライオリティを見極める上でも、実際の安全管理措置の適切性を判断する際には重要な参考となる。

1-4．ガイドラインの見直しは2027年4月に確定予定

今回の注意喚起には、もう一つ重要な情報がある。

個人情報保護委員会は、安全管理措置に関するガイドラインの例示について、現代化を含めた見直しを予定している。

その内容の確定予定は、2027年4月である。

今回公表された別紙は、その見直し予定の内容を先取りして示したものであり、委員会が今後どのような対策を重視するのかを知るうえでは、非常に参考になる。
企業としては、改訂が確定してから慌てて対応するのではなく、現在の安全管理体制と照らし合わせ、改善すべき部分を洗い出しておくことが望ましい。

2．ポイント② 不正アクセス対策は「侵入防止」だけでは足りない

2-1．会社のセキュリティを建物の防犯に例えてみる

今回の注意喚起では、技術的安全管理措置として、次の5項目が示されている。

アクセス制御
アクセス者の識別と認証
外部からの不正アクセス等の防止
情報システムの使用に伴う漏えい等の防止
不正アクセス等の検知等

これを、会社の建物の防犯に例えて考えてみよう。

建物の入口に鍵を設置したとしても、従業員が誰でも金庫室に入れる状態であれば、内部の情報は守られない。
侵入者が建物に入っても警報が鳴らなければ、被害の発見が遅れる。
さらに、一つの部屋から建物全体に自由に移動できる構造であれば、被害は大きくなる。

情報システムも同じである。

外部からの侵入を防ぐだけでなく、侵入された場合にどこまで情報を取得できるのか、異常を検知できるのか、被害を途中で止められるのかを考える必要がある。

2-2．アクセス制御――誰が、どの情報まで見られるのか

アクセス制御とは、情報システムや個人データにアクセスできる人・システム・範囲を制限することである。

例えば、顧客管理システムを利用する会社の営業担当者は、自分が担当する可能性のない、全国すべての顧客の本人確認書類を閲覧できる必要はない。

今回のガイドライン見直し案では、ユーザーIDに付与する権限の最小化、特権アカウントの利用範囲の限定、定期的な権限の棚卸しなどが例示されている。
ここでいう「棚卸し」とは、現在の権限が本当に必要なのかを定期的に確認することである。

人事異動や退職によって不要になった権限を、そのまま放置してはいけない。

2-3．認証――パスワードだけで十分なのか

次に重要なのが、アクセスする人を正しく識別・認証する仕組みである。

例えば、会社の管理者アカウントに、IDとパスワードだけでログインできるシステムだと、攻撃者が何らかの方法でそのパスワードを入手すれば、正規の管理者になりすましてログインできてしまう。
そこで重要になるのが、多要素認証である。

多要素認証とは、パスワードに加えて、認証アプリや生体認証など、異なる種類の要素を組み合わせて本人確認する方法である。

今回の見直し案では、組織外ネットワークからのアクセス、管理者権限によるアクセス、重要な個人データへのアクセスについて、フィッシング耐性のある方式を含む多要素認証が例示されている。

ただし、先ほど述べたとおり、これは具体的な手法の例示であり、あらゆる場面で同じ方式を一律に義務付けるものではない。

企業が確認すべきなのは、「多要素認証という機能があるか」だけではない。

特に重要な情報にアクセスする際、その認証が実際に適用されているかという点である。

2-4．侵入経路は、本社のシステムだけではない

今回改訂された「WARNING」では、過去の漏えい事案を9種類に分類している。

その中で注目したいのが、グループ会社や海外拠点を経由した侵入である。

例えば、本社では最新のセキュリティ対策を実施しているが、海外子会社では古いVPN装置を使い続けている場合を考えてみよう。
攻撃者は、必ずしも本社の正面入口を狙う必要はない。
警備の弱い海外子会社に侵入し、そこから本社のネットワークへ移動できればよい。

これは、厳重に警備された本社ビルに直接侵入する代わりに、警備の緩い別館から連絡通路を通って入るようなものである。
実際に「WARNING」の事例4では、海外拠点の子会社を足がかりにした不正アクセスと、親会社のデータセンターへの侵害の横展開が紹介されている。
原因として、海外拠点の脆弱性対策が不十分だったことや、貸与されたVPN装置が管理台帳に記載されていなかったことなどが挙げられている。

この事例から分かるのは、会社全体のセキュリティ水準は、本社だけを確認しても判断できないということである。
グループ会社、海外拠点、委託先、クラウドサービスまで含めて考える必要がある。

2-5．APIの設定ミスで、他人の情報が見えてしまうこともある

今回の「WARNING」では、APIが悪用される事例も取り上げられている。

APIとは、アプリやWebサービスが別のシステムと情報をやり取りするための仕組みである。
例えば、スマートフォンの会員アプリで、自分の登録情報を表示する場面を考えてみよう。
アプリは裏側でサーバーに問い合わせ、会員情報を取得している。

このとき、会員番号を指定して情報を取得する仕組みがあったとする。
本来であれば、ログイン中の本人の情報しか取得できないようにする必要がある。
しかし、会員番号を変更するだけで他人の情報まで取得できる設計になっていたらどうだろうか。

攻撃者は、正規の会員としてログインした後、番号を次々に変更して、他の利用者の情報を集められる可能性がある。

「WARNING」の事例9は、まさにこうした問題を扱っている。
原因として、APIの管理漏れ、アクセス権限の確認不足、不要な情報を含む応答、連番の会員ID、アクセス回数制限の欠如などが挙げられている。

対策としては、APIの棚卸し、アクセスするたびの権限確認、不要な情報を返さない設計、大量アクセスを制限する仕組みなどが挙げられている。

ここで重要なのが、「認証」と「認可」の違いである。

認証：アクセスしてきた人が誰なのかを確認すること
認可：その人が要求した情報にアクセスする権限を持っているかを確認すること

例えば、ホテルの宿泊客がフロントで本人確認を済ませたとしても、すべての客室に入ってよいわけではない。
本人確認が「認証」であり、自分の部屋だけに入れるようにすることが「認可」である。

情報システムでも同じである。正規の利用者としてログインできたからといって、他人の個人情報まで取得できてよいわけではない。

なお、会員IDをランダムな値に変更することは、情報の推測を難しくする対策の一つである。
しかし、それだけで認可の不備が解消するわけではない。
アクセスのたびに、その情報を取得する権限があるかを確認することが基本となる。

2-6．不正アクセスを早く発見し、被害の拡大を止める

今回の見直し案で特に注目したいのが、「不正アクセス等の検知等」という項目である。

ここでは、不正アクセスを早期に検知するための措置を平時から講じ、組織内ネットワークにおける被害の拡大を防止できるようにすることが示されている。

具体的な手法として、次のようなものが例示されている。

認証ログ、アクセスログ、操作ログ、通信ログなどを一定期間保存する
ログが改ざんされたり、不正に削除されたりしないよう保護する
ログを定期的に分析して異常を発見する
IDS・IPS（不正な通信を検知・遮断する仕組み）やEDR（端末の不審な動作を監視する仕組み）などを利用する
侵害されたシステムの停止・隔離やアカウントの無効化によって被害の拡大を防ぐ

ここでも、建物の防犯に例えて考えると分かりやすい。

入口に頑丈な鍵を付けることは重要である。
しかし、泥棒が侵入したときに警報が鳴らず、監視カメラの映像も保存されていなければ、侵入に気付くのが遅れる。
さらに、侵入者が建物内のすべての部屋に自由に入れる状態であれば、被害は拡大してしまう。

情報システムも同様である。

例えば、普段は1時間に数十件しか顧客情報を閲覧しない担当者のアカウントから、突然数万件のデータが取得され始めた場合を考えてみよう。
そのアクセスが正しいIDとパスワードによって行われていたとしても、通常業務とは明らかに異なる。
こうした異常を検知できれば、被害がさらに拡大する前に、アカウントを停止したり、通信を遮断したりすることができる可能性がある。

もっとも、ログを保存しているだけでは十分とはいえない。
ログが誰にも確認されず、異常を検知しても担当者に通知されないのであれば、実際の事故対応にはつながらない。
「侵入されない仕組み」に加えて、「侵入されたことに気付く仕組み」と「被害を途中で止める仕組み」が必要なのである。

今回の見直し案は、こうした考え方を明確に示している。

2-7．システム開発会社に任せていれば安心、とは限らない

今回改訂された「WARNING」では、技術的な問題だけでなく、企業とシステム開発会社との役割分担の問題も取り上げられている。

例えば、事例1では、システムに脆弱性が存在していたにもかかわらず、適切な対応が行われず、不正アクセスによる個人情報漏えいを防げなかったケースが紹介されている。
その原因の一つとして、システム開発の契約は締結していたものの、セキュリティ対策を含む保守契約を締結していなかったことが挙げられている。
また、保守契約は存在していても、その内容に脆弱性への対応が含まれていなかったケースも紹介されている。

例えば、ある会社が外部の開発会社に顧客管理システムを作ってもらったとしよう。
システムは問題なく稼働しており、毎月の保守費用も支払っている。

ところが、ある日、システムに重大な脆弱性が発見された。
このとき、誰が脆弱性の情報を収集するのか。誰が修正の必要性を判断するのか。誰が修正作業を行い、その費用を負担するのか。

こうした点が契約上明確になっていなければ、双方が相手方の対応を待つうちに、脆弱性が放置されるおそれがある。

今回の注意喚起が示すのは、セキュリティ対策が技術だけの問題ではないということである。
開発会社との契約内容、役割分担、社内の管理体制、事故発生時の連絡方法なども、安全管理措置の実効性を左右する。
「開発会社に任せている」という説明だけでは、十分な管理が行われていることの証明にはならない。
また、個人データの取扱いを委託している場合には、個人情報保護法25条に基づく委託先の監督も問題となる。

今回の「WARNING」では、親会社に個人データの取扱いを委託していた子会社が、親会社に対する監督を十分に行っていなかった事例も紹介されている。

グループ会社であっても、必要な監督が不要になるわけではない。

なお、クラウドサービスの利用については、サービス提供事業者が個人データを取り扱うかどうかなど、具体的な利用形態によって委託該当性が異なる。
クラウドを利用しているという理由だけで、すべての契約が個人データの取扱いの委託になるわけではない点にも注意が必要である。

3．ポイント③ 不要になった個人情報は、保存し続けない

3-1．情報漏えい対策は、情報を守ることだけではない

今回の注意喚起では、技術的な安全管理措置と並んで、不要になった個人データの消去が独立した項目として取り上げられている。

これは非常に重要な点である。

情報漏えい対策というと、多くの人は、パスワードの強化、ウイルス対策ソフトの導入、不正アクセスの監視などを思い浮かべるだろう。

しかし、もう一つ、根本的な対策がある。
そもそも、漏えいして困る情報を必要以上に持たないことである。

例えば、会社の倉庫に重要書類が100箱保管されているとしよう。
倉庫の鍵を強化し、監視カメラを設置することはもちろん重要である。
しかし、そのうち80箱が既に保存する必要のない古い書類だった場合、不要な80箱を適切に廃棄すれば、被害はそもそも発生しえない。

デジタルデータでも同じである。

保存する個人情報の量が増えれば、ひとたび不正アクセスを受けた際の潜在的な被害も大きくなる。

今回の注意喚起は、この問題を改めて取り上げている。

3-2．個人情報保護法22条は、不要データの消去を努力義務としている

個人情報保護法22条は、個人情報取扱事業者に対し、利用する必要がなくなった個人データを遅滞なく消去するよう努めなければならないと定めている。

ここで重要なのは、「消去しなければならない」という一律の義務ではなく、「消去するよう努めなければならない」という努力義務であることである。

したがって、利用目的を達成した個人データを直ちに消去しなかったからといって、その事実だけで当然に法22条違反となるわけではない。
また、法令によって保存期間が定められている場合などには、その保存の必要性も考慮しなければならない。

例えば、取引に関する記録は、税法や会社法などの関係法令によって一定期間の保存が必要になる場合がある。
一方、本人確認のために取得した画像については、本人確認が完了した後も原画像を保存し続ける必要があるのか、別途検討すべき場合がある。

このように、個人情報の保存期間は、情報の種類や利用目的、関係法令などに応じて判断する必要がある。

今回の注意喚起では、利用目的が達成され、その目的との関係で保有する合理的な理由がなくなった場合や、利用目的の前提となる事業自体が中止された場合などについて、消去の努力義務を改めて説明している。

さらに、不要な情報が保存され続けた結果、漏えい事故が深刻化した事例があることも指摘している。
つまり、保存する理由を定期的に確認することが重要なのである。

3-3．退会した会員の情報は、本当に削除されているのか

例えば、会員制のオンラインサービスを運営する会社を考えてみよう。

ある利用者がサービスを退会した。
画面には「退会手続が完了しました」と表示され、利用者は自分のアカウントが削除されたと思っている。
しかし、システムの内部では、必ずしもすべてのデータが消去されているとは限らない。
システム開発では、データを物理的に削除せず、データベース上で「削除済み」という印を付けるだけの方法が使われることがある。

これは「論理削除」と呼ばれる。
論理削除には、誤って削除したデータを復元しやすいなどの利点がある。
しかし、データそのものは残っているため、データベースへのアクセス権限を奪われた場合には、退会者の情報も漏えいする可能性がある。

ここで区別すべきなのは、次の2つである。

利用者がサービスを退会したこと
その利用者の個人データが実際に消去されたこと

両者は同じではない。

もちろん、退会後も一定期間の保存が必要な情報はある。
しかし、保存する必要があるとしても、通常のWebシステムからいつでも取得できる状態にしておく必要があるだろうか？
例えば、紛争対応などのために保存が必要な情報を、日常業務のシステムとは分離し、限られた担当者だけが承認を経て閲覧できるようにする方法も考えられる。

これは、重要書類を日常的に誰でも開けられる棚に置くのではなく、必要な場合に限って取り出せる保管庫に移すようなものである。

情報を保存する必要性と、日常的にアクセスできる必要性は、分けて考えるべきなのである。

3-4．削除したつもりでも、コピーが残っていることがある

個人データの消去を考える際には、もう一つ注意すべき問題がある。
それは、データの複製である。

例えば、会社の顧客管理システムから、ある利用者の情報を削除したとしよう。
しかし、その情報が別の場所にも保存されていたらどうだろうか。
営業担当者がダウンロードしたCSVファイル、問い合わせ対応のために保存した添付ファイル、開発時に使用したテストデータ、バックアップなどが考えられる。

元のデータベースから情報を削除しても、こうした複製が残っていれば、漏えいリスクは残る。

今回改訂された「WARNING」の事例6では、従業者が業務で使用する個人データを、各自のデスクトップ端末など、個人が管理する領域に保存していたケースが紹介されている。
その結果、組織として管理されていない古いデータなども漏えいし、被害の範囲が大きくなったとされている。
対策としては、個人情報管理台帳の整備、保存場所の明確化、定期的な監査、従業者へのルールの周知などが挙げられている。

これは大企業だけの問題ではない。

例えば、中小企業でも、顧客一覧をExcelファイルにして各担当者が自分のパソコンに保存していることは珍しくない。
そのファイルが何年前のものなのか、誰が持っているのか、現在も必要なのかを会社が把握していなければ、情報管理の対象から漏れてしまう。

個人情報を適切に消去するためには、まず、どこに何が保存されているのかを把握する必要がある。

3-5．「持たない設計」は被害の規模を減らす

ここまでの議論を整理すると、情報漏えいの被害を小さくするためには、少なくとも2つの方向性がある。

第一に、一度の侵害でアクセスできる情報の範囲を小さくすることである。
第二に、そもそも保有する情報の量を必要最小限にすることである。

例えば、100万人分の個人情報を保有する企業が、すべての情報を一つのシステムから取得できる状態にしていた場合を考えてみよう。
そのシステムが侵害されると、最大100万人分の情報が取得される可能性がある。

一方、不要な情報を適切に消去し、保存が必要な情報についても権限を分離しておけば、同じ侵害が起きた場合でも、取得される情報を減らせる可能性がある。

このように、一つの侵害によって被害が及ぶ範囲は、情報セキュリティの分野で「ブラスト・ラジアス」と呼ばれることがある。

今回の注意喚起自体が、この用語を用いているわけではない。
しかし、アクセス制御の最小化、被害拡大の防止、不要データの消去という今回の内容は、侵害が発生した場合の被害範囲を小さくするという考え方と整合する。

侵入を100％防ぐことだけを目標にするのではなく、侵入された場合の被害をどこまで小さくできるかという視点も重要なのである。

4．企業は今回の注意喚起を受けて何をすべきか

4-1．まずは、自社がどのような個人情報を持っているか確認する

今回の注意喚起は、すべての企業が直ちに高額なセキュリティ製品を導入すべきである、という類のものではない。
自社がどのような個人データを、どこに、どの程度保有しているのかを把握し、必要な安全管理措置を行い、有事の際にすぐに適切な報告、二次被害防止ができる態勢を整備しているかどうかである。

例えば、次のような点を確認するとよい。

顧客や従業員の個人データは、どのシステムに保存されているか
運転免許証やパスポートなど、機密性の高い情報を保有しているか
退会者や過去の取引先の情報が残っていないか
個人データを閲覧・取得できる担当者やシステムは限定されているか
開発会社やクラウドサービスなど、外部事業者が取り扱う個人データはどこまで把握できているか

こうした基本的な情報を整理するだけでも、管理上の問題が見えてくる場合がある。

例えば、会社の顧客管理システムは適切に管理されていても、担当者が個人的に保存した古い顧客一覧が残っているかもしれない。
あるいは、顧客情報の保存先は把握していても、外部の開発会社が保守作業のためにどのような権限を持っているのか、会社側が理解していない場合もある。

重要なのは、「個人情報を管理している」という抽象的な説明ではなく、具体的に何を、どこで、誰が管理しているのかを説明できる状態にすることである。

4-2．開発会社・システム担当者に確認すべき5つの質問

次に、情報システムの開発会社や社内のシステム担当者に、今回の注意喚起を踏まえた確認を行うことが考えられる。

専門的な技術知識がない経営者でも、次の5つの質問から始めることができる。

質問①：重大な脆弱性が発見された場合、誰が対応するのか。
脆弱性情報の収集、影響の調査、修正作業、対応完了の確認について、担当者と役割分担が決まっているかを確認する。
保守契約がある場合には、脆弱性への対応が契約内容に含まれているかも重要である。

質問②：一つのアカウントが不正利用された場合、何人分の個人情報を取得できるのか。
管理者、一般従業員、外部委託先、Webアプリケーションなど、それぞれの権限で取得できる情報の範囲を確認する。
特に、通常業務では必要のない大量の情報を、一つの権限で取得できる状態になっていないかが重要である。

質問③：不正アクセスが発生した場合、どのように発見するのか。
ログの保存だけでなく、異常を検知する仕組み、通知先、確認担当者、対応方法が決まっているかを確認する。
「ログは保存しています」という回答だけでは、異常を早期に発見できるとは限らない。

質問④：退会者や古い顧客の個人情報は、いつ、どのように削除されるのか。
保存期間を確認するとともに、保存が必要な法令上・業務上の理由を整理する。
また、本番システムだけでなく、バックアップや一時ファイルなどに残るデータについても確認する。

質問⑤：不正アクセスが発生した場合、被害を途中で止められるのか。
侵害されたアカウントの停止、システムの隔離、外部との通信遮断などを、誰が判断し、どのように実行するのかを確認する。
これらは、今回の注意喚起で示された対策を、企業が実際に確認するための質問に置き換えたものである。

4-3．今回の注意喚起は、経営者にも関係する

情報セキュリティというと、情報システム部門や開発会社の仕事だと考えられがちである。
しかし、今回改訂された「WARNING」は、技術的な問題への対応にとどまらず、経営層を交えて組織体制の問題点や、漏えいが発生した場合の損害を評価し、組織的に対応する必要があると説明している。

例えば、古いシステムに重大な脆弱性が見つかったとする。
修正には費用がかかり、サービスを一時停止する必要もある。

その場合、修正の必要性を技術的に判断するのはシステム担当者であっても、費用を支出するか、サービスを停止するかという経営判断は、担当者だけでは決められないことがある。
また、不要な個人情報の削除についても、営業部門は過去の顧客情報を残したいと考え、法務部門は保存の必要性を確認し、システム部門は削除の実装を担当するというように、複数の部署が関係する。

このような問題は、一つの部署だけで解決できるとは限らない。
企業の経営層には、情報管理に必要な予算や人員を確保し、部門間の役割分担を明確にする役割がある。

個人情報の漏えいは、技術的な事故であると同時に、企業の管理体制が問われる問題でもある。

5．まとめ――「侵入を防ぐ」から「被害を小さくする」まで

2026年10月7日に個人情報保護委員会が公表した注意喚起は、大規模な個人情報漏えいが相次ぐ中で、企業に安全管理措置の見直しを促すものである。

その内容は、次の3つのポイントに整理できる。

１　安全管理措置は、会社が取り扱う個人情報の量や性質、漏えいした場合のリスクに応じて考える必要がある。
個人情報保護法23条は、必要かつ適切な安全管理措置を求めている。
一方、ガイドラインに記載された具体的な手法は例示であり、すべてを一律に実施しなければ直ちに法違反となるわけではない。
重要なのは、自社のリスクに応じた合理的な対策を講じることである。

２　不正アクセス対策は、侵入を防ぐだけでは足りない。
アクセスできる情報の範囲を限定し、不正アクセスを早期に発見し、被害の拡大を防止することが重要である。
今回示された技術的安全管理措置の見直し案では、多要素認証、アクセス権限の最小化、ログの分析、不正アクセスの検知、システムの隔離などが例示されている。
また、グループ会社や海外拠点、クラウドサービス、APIなど、従来の社内システムだけでは捉えきれない問題も取り上げられている。

３　必要のなくなった個人情報を保存し続けない。
個人情報保護法22条は、利用する必要がなくなった個人データについて、遅滞なく消去するよう努めることを求めている。
保存する合理的な理由があるかを確認し、不要な情報を適切に消去することは、漏えいした場合の被害を減らすうえでも重要である。

今回の注意喚起は、新たな法律上の義務を一斉に追加したものではない。

しかし、2027年4月に確定予定のガイドライン見直しの方向性を示すものであり、企業が現在の安全管理措置を点検するための重要な資料となる。

今回の注意喚起は、その基本に立ち返る機会といえるだろう。