個人情報の漏えいニュースを見て、「うちの会社も点検した方がいい」と感じても、何から始めるか迷うものです。
まず確認したいのは、個人データの保存場所、外部から入れる入口、管理者アカウント、異常を見つけた後の連絡先です。製品選びの前に、この4つを答えられる状態にしましょう。
個人情報保護委員会は2026年10月7日、大規模な漏えい等事案を踏まえた注意喚起を公表しました。多要素認証やEDRなどの対策例とともに、不要になった個人データの消去にも言及しています。
この記事では、公式発表の要点を確認したうえで、総務や経理とIT管理を兼務する担当者向けに、点検の進め方を具体化します。以下の点検表・質問例・優先順位は、公式資料を踏まえた本記事の実務提案です。
今回の注意喚起で何が示されたのか
今回の発表は、今後のガイドライン見直しに向けた技術的安全管理措置の例示などを先取りして示したものです。見直し内容の確定は2027年4月を予定しています。
特に押さえたいのは、次の点です。
- 外部からの接続や管理者権限などの認証を強化すること。例示には、フィッシングに耐性のあるものを含む多要素認証が示されています。
- ログの分析やEDRなどによる早期検知、被害拡大防止を検討すること。
- 保有する個人データについて、保存の必要性や法令上の根拠を確認すること。
例示された製品・手法をすべて導入しないと、直ちに法違反になるという発表ではありません。扱う情報の性質・量や事業の状況に応じた、必要かつ適切な措置が求められます。
中小企業が最初に使える点検表
最初の点検は「できている・いない」だけで終わらせず、確認した根拠と次の担当者を残すと進めやすくなります。
| 点検対象 | 最初に確認すること | 確認に使うもの |
|---|---|---|
| 個人データの保存場所 | 顧客・職員・応募者の情報がどこにあるか | 利用システム一覧、各部署への聞き取り |
| 外部からの入口 | VPN、管理画面、クラウドへの接続方法 | 機器一覧、管理画面、保守業者の回答 |
| 管理者・利用者アカウント | 誰が管理者か、退職者の利用権限が残っていないか | アカウント一覧、所属・退職情報 |
| 認証方法 | 管理者にも多要素認証が適用されているか | 認証設定、適用対象・例外の一覧 |
| 更新・脆弱性対応 | 誰が情報を受け取り、誰が修正するか | 保守契約、更新履歴、作業記録 |
| 異常の検知 | 通知を誰が受け、誰が判断するか | 通知先設定、運用手順、契約内容 |
| 保存期間 | 古いデータを残す理由が説明できるか | 保存規程、利用目的、関係法令 |
| 委託先・クラウド | 自社と業者の作業分担が明確か | 契約書、サービス仕様、問い合わせ回答 |
分からない項目は「未確認」と記録します。空欄や推測で埋めると、次に見る人が確認済みと誤解してしまいます。
1．まずは管理者アカウントの認証を確認する
担当者が多忙なら、すべてのシステムを同じ深さで調べるのは難しいでしょう。本記事では、メール・クラウドの管理者、VPNなど外部接続に関わるアカウントからの確認を提案します。
確認の際は、「多要素認証を設定済みです」という回答だけで終わらせず、対象アカウントと除外設定を見せてもらいます。一般職員には適用されていても、別の管理者アカウントの状況は確認が必要です。
フィッシング耐性とは？
偽のログイン画面に誘導されても、認証情報を利用したなりすましを防ぐための性質です。米国CISAの資料では、FIDO/WebAuthnを用いた認証が紹介されています。
SMSや認証アプリのコードを使う方式と、FIDO/WebAuthnを使う方式を同じものとして扱わず、利用中のサービスがどの方式に対応しているか確認しましょう。
出典：CISA・Implementing Phishing-Resistant MFA
業者へは、次のように聞くと具体的な回答を得やすくなります。
現在の管理者認証の方式、フィッシング耐性のある方式への対応状況、適用対象から外れているアカウントの有無を教えてください。変更する場合の費用と、端末紛失時の復旧手順も確認したいです。
導入作業では、日常のログインだけでなく、担当者不在時や機器故障時に誰が復旧できるかまで決めておきます。
2．EDRは「入っているか」と「対応できるか」を確認する
EDRは、端末上の活動を監視し、異常の検知や調査・対応を支援する仕組みです。検知通知を受けた後の判断や隔離をどう行うかは、製品と運用体制によって異なります。
ここで担当者が確認したいのは、製品名よりも次の3点です。
- 対象端末はどこまでか。サーバーや普段使わない端末も含まれているか。
- 通知先は誰か。担当者の休暇中や夜間はどうするか。
- 誰が端末の隔離や調査を行うか。業者の対応範囲はどこまでか。
「警告メールが届くこと」と「業者が対応してくれること」は、契約で別々に確認します。運用を外部へ依頼する場合は、監視時間、初動連絡、隔離の判断権限を見積書や仕様書に明記してもらいましょう。
予算がすぐに付かない場合も、既存のセキュリティ製品の通知先や、異常発生時の連絡網の確認から着手できます。追加導入の判断に必要な未対応項目を、上司に示せる形にしておきます。
3．古い個人データは「残す理由」を点検する
公式資料は、利用する必要がなくなった個人データの消去について努力義務を説明し、法令で保存期間が定められている場合を区別しています。
そのため、点検で見つけた古いファイルを、担当者の判断だけで一括削除する進め方は避けます。
まずは業務担当部署に、用途と保存期限を確認しましょう。
例えば、過去の応募者一覧、終了したイベントの参加者名簿、システムから出力した作業用CSVについて、次の項目を記録します。
| 記録項目 | 書き方の例（架空） |
|---|---|
| データの名称 | 2023年度イベント申込一覧 |
| 保存場所 | 部署の共有フォルダ |
| 残している目的 | 問い合わせ対応用。現在も必要か確認中 |
| 保存期限・根拠 | 担当部署へ確認中 |
| 確認責任者 | イベント担当部署の責任者 |
| 次の処理 | 期限確認後、削除対象と方法を決定 |
バックアップやメール添付など、別の場所に複製があるかも確認対象にします。すべてを即座に消せるとは限らないため、保存・更新の仕組みを確認して、実施日を決めるのが現実的です。
4．保守契約とクラウドの役割分担を確認する
同日に改訂されたWARNING資料では、脆弱性対応が保守契約に含まれていなかった事例や、クラウド利用時の確認不足などが紹介されています。また、クラウド利用が個人データの取扱いの委託となる場合についても説明されています。
出典：個人情報保護委員会・WARNING（2026年10月7日改訂）
業者へ「セキュリティ対策は大丈夫ですか」と聞くより、作業ごとに担当を分けて確認する方が、その後の対応につながります。
- 脆弱性情報を収集し、自社への影響を判断するのは誰か。
- 修正作業は契約内か。別料金なら、誰へ見積もりを出すか。
- 緊急時の作業承認と停止の判断を誰が行うか。
- 利用者の権限や共有設定を確認するのは、自社か業者か。
- 事故の連絡先、連絡方法、提供してもらえる調査情報は何か。
回答はメールや議事録に残し、確認日を台帳へ記録します。認証や第三者評価の有無を調べる場合も、名称だけでなく、自社が契約しているサービスが対象範囲に含まれるかを確認しましょう。
情報資産台帳に「次の行動」を追加する
システム名だけ並べた一覧では、確認漏れが見つかっても作業が止まりがちです。既存の台帳には、次の列を追加する使い方を提案します。
認証方式／ログ・監視の担当／保存期限と根拠／未確認事項／対応担当／対応期限／確認日・根拠資料
台帳へパスワードや復旧コードそのものを記載する必要はありません。秘密情報の値と、対策状況を共有する一覧は分けて管理します。
具体的な台帳の作り方は、情報資産台帳の作り方｜ひとり情シスが進めるシステム総点検で紹介しています。
兼務担当者が進めるなら、今日・今週・今月に分ける
以下は、作業を始めるための進め方の例です。事故の兆候や重大な未対応が判明した場合は、この順序を待たずに責任者へ報告します。
| 時期の目安 | 作業 | 残す成果 |
|---|---|---|
| 今日 | 保存場所、外部接続、管理者、連絡先を洗い出す | システム一覧と未確認項目 |
| 今週 | 管理者認証、更新担当、通知先、古いデータの用途を確認する | 部署・業者の回答と担当者 |
| 今月 | 必要な変更を見積もり、承認・実施・確認を進める | 対応計画、作業記録、次回点検日 |
上司への説明は、「EDRを購入したい」だけでなく、「異常の通知先は決まっているが、不在時の対応者がいない」など、確認した事実から始めると判断材料になります。
バックアップと復元の確認も別途進める
今回の注意喚起とあわせて参照したいのが、IPAの中小企業向けガイドラインです。第4.0版では、基本対策にバックアップが追加されています。
自社の点検では、バックアップの取得状況に加え、必要なデータを戻せるか、復元を誰へ依頼するかも確認項目にするとよいでしょう。
最初の一歩は、重要な1システムの確認から
すべての調査を終えてから対策する必要はありません。顧客情報や職員情報を扱う重要なシステムを1つ選び、保存場所・管理者・認証方式・連絡先を確認してみてください。
そこで判明した未確認事項に、担当者と期限を付ける。次のシステムにも同じ手順を使う。この進め方なら、兼務担当者でも点検を業務の中に組み込みやすくなります。
クラウドが止まった場合の業務継続は、ひとり情シスの初動対応と代替手段もあわせて確認してください。
確認日：2026年10月8日。公式資料の記載と、本記事が提案する点検方法を区別して構成しています。
