>
>
公開日
最終更新日
この記事を読むと、9事例を自社の権限・認証・ログの点検項目に置き換え、現行の義務と見直し案を分けて整理できます。
急ぐ場合は、①サポート切れや既知の脆弱性がある外部公開資産、②所有者不明の管理者ID、③退職者アカウントの残存、④他者のID指定で個人データを取得できるAPI、⑤認証・操作ログの保存期間の5点を、人事名簿や契約情報と突き合わせて抽出します。報告対象かどうかの判定、クラウドが委託に当たるかの整理、本人への通知は、法務と詰める項目です。
当日：外部公開資産と管理者IDの一覧を人事名簿・契約情報と照合し、所有者不明の対象を抽出します。
1週間以内：退職者アカウントの停止、他者のID指定で個人データを取得できるAPIの公開制限、ログ保存期間の一覧化を済ませます。
1か月以内：APIの認可修正と再試験、委託先・クラウドの事故連絡窓口の契約反映、速報・確報を想定した連絡訓練まで進めます。
個人情報保護委員会は2026年10月7日に「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」を改訂しました。この記事は、情報システム部門（情シス）とセキュリティ委員会の担当者向けに、9事例の点検方法と検知後の報告手順を整理します。
情報、および本文で引用する個人情報保護委員会・IPA・警察庁などの公開資料は、2026年10月22日時点の内容です。本文では「現行の義務」「推奨・手法の例示」「運用提案」を区別します。ガイドラインの見直し案は、現行の確定済み義務とは分けて扱います。原因の基本整理は「情報漏洩はなぜ起こる？原因や予防策・対策まで解説」も参照できます。
個人情報保護委員会のWARNINGとは
個人情報保護委員会が2026年10月7日に示した資料のうち、注意喚起は安全管理措置の再徹底とガイドライン見直し内容の先取り公表を、改訂版WARNINGは不正アクセス9事例の原因と対策を扱っています。
本記事のポイント
改訂版WARNINGは、API悪用を追加した全9事例で、不正アクセスの原因と対策を示しています。
現行の技術的安全管理措置は4項目で、先取り公表された見直し案は5項目です。
個人データへの不正アクセスを防ぐ際は、資産把握、権限管理、認証、検知を多層的に実施します。
報告対象の漏えい等を知ったら、調査完了を待たずに速報を行います。
情報は2026年10月22日時点のものです。2026年10月に各機関が出した注意喚起を「いつやるか」で整理した内容は不正アクセス対策の記事、現行の安全管理措置の義務の範囲は安全管理措置の記事で説明しています。
2026年10月7日の公表内容と位置づけ
同日の公表資料は、安全管理措置の考え方を整理する注意喚起と、具体的な原因・対策を示すWARNINGに分かれます。
個人情報保護委員会は「大規模な漏えい等事案を踏まえた対応について（注意喚起）」で、安全管理措置の再徹底、ガイドライン見直し予定内容の先取り、不要な個人データの消去を取り上げています。大量の個人情報や、漏えいによって本人に深刻な被害が生じる情報を扱う事業者は、データの性質と量を踏まえて対応します。
一方、同委員会の改訂版WARNINGは、2024年12月11日の初版を2026年10月7日に更新した資料です。この文書の意味は、個別の不正アクセス事案から安全管理措置の見直しにつなげる注意喚起として読む点にあります。「はじめに」では、対策は「どれか一つを講じればよいということではなく、多層的に講ずる必要があります」と明記しています。
現行の義務と手法の例示の区別
現行の義務を判断するときは、ガイドラインの「講じなければならない措置」と、実現方法を示す「手法の例示」を分けて読みます。
現行の通則編10-6「技術的安全管理措置」は、次の4項目です。特定の製品を導入したかどうかではなく、個人データの取扱状況に応じた安全管理措置を実施しているかを点検します。
現行の通則編10-6 | 情シスが点検する対象 | 運用で残す記録の例 |
|---|---|---|
（1）アクセス制御 | 個人データを扱う担当者と、利用できるデータの範囲 | 権限一覧、承認履歴、権限変更履歴 |
（2）アクセス者の識別と認証 | 利用者を識別し、正当な利用者かを確かめる仕組み | 認証方式、管理者一覧、認証設定の記録 |
（3）外部からの不正アクセス等の防止 | 不正アクセスや不正ソフトウェアへの対策 | 更新履歴、検知記録、対応履歴 |
（4）情報システムの使用に伴う漏えい等の防止 | 設計、通信、データ取扱いに伴う漏えい対策 | 設計レビュー、暗号化設定、取扱手順 |
委員会は、手法の例示をすべて同じ形で実装することではなく、事業の規模・性質、個人データの性質・量、本人への影響に応じて必要かつ適切な手法を選ぶ考え方を示しています。自社で別の方法を使う場合は、対象リスクと、その方法でリスクを抑えられる理由を記録します。
個人情報保護法改正と漏えい報告の関係
個人情報保護法改正による漏えい等報告の義務と、今回のガイドライン見直し案は別の論点です。
漏えい等報告では、不正の目的をもって行われたおそれがある個人データの漏えい等は、対象が1人でも報告対象になります。要配慮個人情報、財産的被害のおそれ、本人の数が1,000人を超える事態などにも報告対象の類型があります。個人情報保護委員会の「漏えい等の対応とお役立ち資料」に沿って判定し、人数だけで報告不要と扱わない運用にします。
▶ 関連記事: 情報漏洩はなぜ起こる？原因や予防策・対策まで解説
改訂版WARNINGの変更点と9事例の全体像
改訂版ではAPI悪用の事例が加わりました。資産台帳、脆弱性対応の担当、ログの保存ルールを見直す際の確認材料になります。
個人情報保護委員会の改訂版WARNINGの事例1〜9を、情シスの担当領域に対応づけると次のようになります。事例の見出しは、点検しやすいように要約しています。
事例 | 点検領域 | 着手する作業 |
|---|---|---|
1 脆弱性が放置された | 資産管理・保守契約 | 貸与品を含む資産と、脆弱性対応の契約範囲を突き合わせます。 |
2 脆弱性への対応が遅れた | 更新管理・サポート期限 | 社内ネットワークの機器も含めて更新漏れを抽出します。 |
3 不正ログイン | 認証・検知 | 認証強度、ログ保存期間、分析担当を調べます。 |
4 グループ会社・海外拠点が狙われた | 拠点横断の資産管理 | 海外拠点や外部事業者からの貸与機器を台帳に追加します。 |
5 グループ会社間のアクセス制御不備 | 管理者権限・接続範囲 | 会社間の接続経路と、個人データへ到達できる権限を整理します。 |
6 個人領域に保存したデータ | 保存場所・保存期間 | 端末内の業務データと古いデータの残存を調べます。 |
7 グループ会社への監督が不十分 | 委託先監督 | 親会社への業務集約を含めて、監督の担当と記録を整理します。 |
サービス選定・契約 | 利用規約、安全性評価、個人データの取扱態様を確認します。 | |
9 APIが悪用される | API管理・認可 | 公開APIと、利用者ごとのデータアクセス判定を点検します。 |
既存6事例で厚くなった原因と対策
既存事例への追記は、担当者個人の注意に依存せず、契約・台帳・ルールを整える方向で読むと実務につながります。
事例 | 追記・強化された論点 | 社内で使う点検資料 |
|---|---|---|
1 | 保守契約に脆弱性対応が含まれない、情報収集後の役割分担がない、貸与品を把握していない | 保守契約書、責任分担表、IT資産台帳 |
2 | 社内なら安全と考え、サポート期限切れの機器を使い続ける | サポート期限一覧、更新計画、例外承認記録 |
3 | ログの保存・監視ルールがなく、検知が遅れる | ログ取得一覧、保存規程、分析記録 |
4 | 海外拠点の貸与品VPN装置が台帳から漏れる | 拠点台帳、回線契約、貸与機器一覧 |
6 | 従業者への日頃の取扱ルールの周知・徹底 | 保存場所のルール、教育記録、監査記録 |
7 | グループ全体のポリシー改訂に子会社が対応していない | 適用状況一覧、是正計画、進捗報告 |
この表は事例1〜4・6・7の該当箇所を整理したものです。すべての事例で対策が一から変わったわけではありません。たとえば事例6は、保存場所の管理という従来の対策に、従業者へ継続してルールを浸透させる運用を重ねて読みます。
多層防御と法違反リスクの接続
9事例への対処を技術担当だけで閉じず、経営層と責任分担まで決めると、放置される作業を減らせます。
改訂版の「はじめに」は、各事例の問題点への措置が十分でない場合、安全管理措置の法第23条、従業者の監督の第24条、委託先の監督の第25条に違反すると判断する可能性を明記しています。情シスは「対策済み」という一欄だけを作るのではなく、担当部門、期限、証跡、未対応時の暫定措置を記録します。
貸与品のVPN装置も、所有者が自社でないという理由で対象外にしません。回線や保守の契約から機器を拾う際は「VPNとは？仕組み・種類から接続のやり方までわかりやすく解説」で接続の構成も整理できます。
▶ 関連記事: VPNとは？仕組み・種類から接続のやり方までわかりやすく解説
9事例に対応する権限・認証・APIの点検手順
点検は、外部から侵入できる経路と、侵入後に個人データへ到達できる権限を先に絞ると進めやすくなります。
以下は個人情報保護委員会のWARNINGの各事例と対策例に沿った整理です。担当や作業順は、自社の運用へ落とし込むための運用提案として示します。
IT資産と脆弱性の管理（事例1・2・4）
脆弱性対応では、資産の洗い出し、情報の収集・分析、速やかな対処までを同じ担当表でつなぎます。
購買台帳に載る自社保有機器に加えて、回線業者からの貸与品、保守業者の設置機器、海外拠点の機器を集めます。機器ごとに型番、バージョン、外部公開の有無、サポート期限、保守担当を記入し、脆弱性情報を受け取った担当者が影響判定から改修依頼まで進めます。保守契約に更新作業が含まれない場合は、自社で実施する担当を決めるか契約を改めます。
直ちに更新できない機器は、外部公開の停止や接続元の制限などを検討し、例外の期限を設けます。社内ネットワークにあることを理由に、サポート切れを放置してはいけません。用語の整理には「脆弱性とは？」、台帳の分散への対処には「端末管理台帳のエクセル限界とは？効率化とツールの選び方」を参照できます。
認証とアクセス制御の管理（事例3・5）
実務では、利用者本人の認証と、閲覧・操作できる範囲の制御を別々に点検します。
管理者権限の放置、退職者アカウントの残存、業務に不要な過剰権限は、不正アクセスを許し、被害を広げる主な管理上の原因になります。通常業務で使うアカウントに管理者権限が付いたままだと、認証情報を奪われた際に設定変更や大量取得まで許すおそれがあります。事例3・5の弱い認証への対策に加えて、アカウントの所有者と権限の妥当性を照合します。
抽出：人事名簿とサービスのアカウント一覧を照合し、退職者、所属不明、長期間利用のないアカウントを抽出します。
判定：データを管理する部門が、現在の職務で必要な閲覧・更新・出力権限を承認します。承認者がいない権限は、業務影響を調べて制限します。
是正：不要な権限を取り消し、退職者のアカウントを停止します。継続中のセッションや連携トークンも失効対象に含めます。
再発防止：入社・異動・退職の手続きに権限変更を組み込み、期限付きの特権と定期棚卸しを運用します。
管理者用と通常業務用のアカウントを分け、管理者権限を使う人・場面・時間を絞ります。共有管理者IDを残す場合は、利用者を追跡する手段と利用後の認証情報管理まで決めます。グループ会社間の接続では、接続できるネットワークとアクセスできるデータを分け、一社の侵害が他社へ広がる経路を制限します。
個人情報保護委員会が先取り公表した技術的安全管理措置では、組織外からのアクセス、管理者権限、重要な個人データへのアクセスに、フィッシング耐性のある多要素認証を挙げています。対応する環境なら、セキュリティキーや適切に構成したパスキーなどを導入候補にし、登録・紛失・復旧時に弱い経路へ戻らない手順も整えます。認証方式の名称だけで判断せず、採用方式がフィッシングサイトへの認証情報入力を防げる構成かを評価します。
ログには、認証成功・失敗、管理者権限の付与、データ出力を残し、想定外の大量取得や権限変更を調査します。認証が成功したという理由で、その後の操作を正常と扱わない設計にします。総当たり攻撃への対処は「ブルートフォース攻撃の対策とは？」、職務別の権限整理は「RBACとは？」で補えます。
個人データの保存場所の管理（事例6）
事例6への対策では、業務データを保存する場所を決め、端末内や個人領域へ複製が残る運用を見直します。
事例6の対策例には、個人情報管理台帳の整備、決められた保存場所での作成・加工・保存、監査部門による定期的な監査が含まれます。情シスは保存先を用意し、事業部門は保存対象と利用目的を登録し、監査部門は実態とルールの差を調べます。台帳の分類方法は「情報資産管理とは？定義・分類から2026年最新対策まで解説」も参考になります。
グループ・委託先・クラウドの管理（事例7・8）
親会社やクラウドサービスを使う際も、個人データを誰がどのように取り扱うかに沿って監督範囲を判定します。
事例7・8は、それぞれの事案で委託の認識や監督が欠けた例です。すべてのクラウド利用が一律に委託へ当たると扱わず、契約、機能、サービス提供者の取扱態様を法務と整理します。委託に当たる場合は選定・契約・定期評価の記録を残し、該当しない場合も安全なサービス選定と自社設定の管理を続けます。
利用規約や安全性評価資料で、アクセス管理、ログ、事故時の連絡、再委託を調べます。資料が不足する場合は、機微な個人データの投入を保留し、代替手段か契約上の補完を検討します。関連する運用は「サプライチェーン攻撃とは？手口・脅威の推移と中小企業の対策」と「【SCS評価制度対応版】セキュリティチェックシートの作り方」で整理しています。
APIの認可と公開範囲の管理（事例9）
APIでは、ログインできることと、指定した個人データを取得できることを別の判定として実装します。
事例9は、ログイン後にURLや会員IDなどのパラメータを書き換え、他の利用者の情報へアクセスできた事案です。事例9では、管理対象から漏れたAPI、連番の識別子、不要な情報を含む応答、アクセス回数制限の欠如などが問題点として挙がっています。対策例にはAPIの棚卸し、認可の実装、ランダムな識別子、レートリミットがあります。
実装・試験の対象 | 運用提案としての判定基準 | 担当 |
|---|---|---|
データ単位の認可 | リクエストごとに、認証済み利用者と対象データの所有者・所属組織・役割をサーバー側で照合します。 | 開発部門 |
パラメータ改変試験 | 別利用者のIDや別組織のIDに変更しても、本文・添付・一覧・件数から他者情報を取得できない状態にします。 | 開発・品質保証 |
応答と出力範囲 | 画面表示に不要な個人データは応答に含めず、検索・一括出力にも同じ認可を適用します。 | 開発・業務部門 |
公開APIの管理 | バージョン、所有部門、認証方式、利用目的を台帳化し、不要な旧APIを停止します。 | 開発・情シス |
異常取得への対応 | 利用者や接続元ごとの回数制限とログを設け、連続した他者ID指定を調査対象にします。 | 開発・監視担当 |
UUIDなど推測しにくい値へ変えても、認可処理の代わりにはなりません。画面でボタンを非表示にするだけの対策も避けます。委託開発なら、この判定基準を受入試験に含め、不合格のAPIは修正まで公開範囲を制限します。管理単位の考え方は「APIエンドポイントとは？URLとの違いから管理・セキュリティまで」を参照できます。
▶ 関連記事: 端末管理台帳のエクセル限界とは？効率化とツールの選び方
▲ アカウントおよびアクセス権限を点検・是正する実務の4ステップ
先取りされた見直し案と技術的安全管理措置の5項目
先取り公表された5項目は、2027年4月に内容の確定が予定されている検討資料（案）であり、まだ現行義務ではありません。現行の4項目と並べて、準備が必要な差分を洗い出す材料として使います。
個人情報保護委員会は、2026年10月7日の注意喚起の別紙「技術的安全管理措置」で、見直し予定内容を先取りして示しています。位置づけは、今後の対策検討に使う資料です。現行の通則編10-6との比較では、「不正アクセス等の検知等」が独立した項目になる点を押さえます。
検討資料上の5項目と手法の例示
次の表は、見直し案の項目名と、情シスが準備対象にできる手法を対応づけています。
根拠資料は、同委員会の第369回個人情報保護委員会・資料2「個人情報の保護に関する法律についてのガイドライン（通則編）等における安全管理措置の手法の例示の追加等の検討について」です。各行の参照箇所は同資料の技術的安全管理措置に関する見直し部分と、先取り公表別紙10-6の該当項目です。
見直し案の項目 | 見直し案における主な手法の例示 | 資料の参照箇所 |
|---|---|---|
（1）アクセス制御 | 特権アカウントの割当ての最小化、異動・退職時の権限変更、定期棚卸し、場所・時間・端末状態などに応じたアクセス判定 | 第369回・資料2の技術的安全管理措置「アクセス制御」、先取り公表別紙10-6（1） |
（2）アクセス者の識別と認証 | パスワードの使い回し防止、ログイン失敗時のID停止、フィッシング耐性のあるものを含む多要素認証 | 同資料「アクセス者の識別と認証」、別紙10-6（2） |
（3）外部からの不正アクセス等の防止 | ソフトウェアの最新化、許可していないソフトウェアの導入防止、組織の基準を満たす端末からのアクセス | 同資料「外部からの不正アクセス等の防止」、別紙10-6（3） |
（4）情報システムの使用に伴う漏えい等の防止 | 設計時の安全性確保、テストで扱う個人データの最小化、通信の暗号化、復元困難な方法による消去 | 同資料「情報システムの使用に伴う漏えい等の防止」、別紙10-6（4） |
（5）不正アクセス等の検知等 | ログの一定期間保管と保護、定期的な分析、IDS/IPSやEDRなどによる監視、侵害時の隔離やアカウント無効化 | 同資料の検知・被害拡大防止に関する見直し、別紙10-6（5） |
この表を監査に使う場合は、「現行基準への対応状況」と「見直し案への準備状況」の列を分けます。案に含まれる特定の手法を未導入という理由だけで、現行法への違反と判定する運用は避けます。
検知と被害拡大防止の準備
製品を選ぶ前に、何のログを残すか、異常時に誰が対応するかを決めます。ここが曖昧なままでは、導入後もアラート対応が止まります。
認証ログ、アクセスログ、管理操作ログ、通信ログについて、取得元、保存先、保存期間、分析担当を一覧にします。調査対象期間をさかのぼれないサービスは、エクスポートや外部保存が可能なら補完し、不可能なら調査できる範囲をリスクとして経営層へ報告します。保存期間は全社一律の日数を当てはめず、検知に要する時間、データの機微性、契約条件、保存容量を踏まえて定めます。
監視製品の役割は「IDSとIPSの違いとは？EDRとの比較や2026年の選定基準」、アクセス要求ごとの評価は「ゼロトラストとは？」で整理できます。常時監視を委託する場合も、アラートを受けた後に誰がサービス停止を判断するかは自社で決めます。
確定予定と社内準備の区別
社内の計画は、委員会の確定予定と、自社が先行して進める作業を分けて作ります。
注意喚起は、見直しの内容の確定を「来年４月」（2027年4月）の予定としています。確定した内容が公表されるまで、別紙の手法の例示をそのまま社内規程へ転記しない扱いにします。人事データとの照合やログ取得の可否調査は先行し、規程の最終改定は公表された確定内容との差分を反映して決裁します。
▶ 関連記事: 脆弱性とは？
不要な個人データの消去と保存場所の整理
不要な個人データを減らすには、事業部門が保存の必要性を判断し、情シスが保存先と削除手段を対応づけます。
個人情報保護委員会は注意喚起の「不要となった個人データの消去」で、利用する必要がなくなった個人データを遅滞なく消去する努力を取り上げています。情シスだけで一括削除を判断せず、利用目的、法令上の保存期間、係争や事故調査に伴う保全の必要性を整理してから実行します。
保存期間と消去担当の対応表
個人情報管理台帳には、保存先に加えて、保存する理由と消去を決める担当者を登録します。
登録する項目 | 判断・作業の担当 | 判断後の処理 |
|---|---|---|
データの種類と利用目的 | 事業部門 | 利用目的が続くならアクセス範囲を維持し、終了しているなら保存根拠を調べます。 |
法令・契約上の保存期間 | 法務・管理部門 | 保存義務があるなら期間とアクセス制限を設定し、満了後の処理を予約します。 |
本体・複製・バックアップの所在 | 情シス・サービス管理者 | 保存先ごとに削除、保持設定、バックアップの世代更新を組み合わせます。 |
消去の承認と実施記録 | データ管理責任者・実施担当 | 承認日、対象範囲、方法、結果を記録し、失敗した対象は再処理します。 |
アカウントの停止とデータの消去は分けます。退職者のログインを止めても、ストレージのファイル、外部共有リンク、連携先への複製が残る場合があります。逆に、退職者の業務データを承継せず削除すると、業務記録を失うおそれがあります。まず承継先を決め、不要な複製と共有権限から整理します。
クラウドと個人端末に残る複製の整理
保存先を減らすときは、ファイル本体と外部共有設定を別々に扱います。
利用を終えたSaaS、端末へのダウンロード、共有用のコピーを一覧にし、削除できる範囲と保持される範囲をサービスごとに記録します。バックアップから即時消去できない場合は、通常利用から隔離し、復元時に不要データを再び業務利用へ戻さない手順を設けます。
SaaS自体の棚卸しは「SaaS棚卸しの進め方と実践的ツール比較｜費用削減の5ステップ」で整理しています。外部公開されたファイルを調べる手段には、サービスの管理画面やAPIによる抽出、Adminaの外部共有コンテンツ管理があります。公開が業務上必要なら対象者と期限を設定し、不要なら共有を解除して履歴を残します。
▶ 関連記事: ブルートフォース攻撃の対策とは？2026年最新のパスワード新常識
IT資産・アカウント・データ置き場の可視化と役割分担
まず、台帳、人事情報、各サービスの実データを照合します。そのうえで、権限を見直す担当と異常を検知する担当を分けます。
全データを一つの製品へ集約しなくても、台帳間でサービス名と管理責任者を一致させれば、必要な照合は始められます。資産台帳、アカウント台帳、個人データの所在一覧に共通のサービス名と管理責任者を持たせれば、脆弱性対応、退職時の停止、漏えい時の影響調査をつなげられます。所有部門が不明なサービスは、費用負担部門や契約者から責任者を特定し、特定できるまで個人データの追加投入を止める扱いにします。
表計算から始める棚卸し手順
対象と担当を見渡せる組織なら、表計算でも照合と承認の流れを始められます。
契約・購買・回線・クラウド管理画面から、機器とサービスの一覧を集めます。
人事名簿とアカウント一覧を照合し、所属不明、退職済み、管理者権限を抽出します。
事業部門へ個人データの種類、保存場所、保存期間を照会します。
各部門が権限と保存の必要性を承認し、情シスが停止・変更・削除を実行します。
実行結果を台帳へ戻し、次回照合日と未解決事項の担当を設定します。
表計算の注意点は、ファイルを作る費用ではなく、実際の変更と記録のずれです。異動が頻繁、拠点が分散、サービス管理者が多数という条件では、担当者が毎回手作業で収集すると更新漏れが生じやすくなります。前回との差分を追えない、承認の履歴が残らない、退職日までに停止できない場合は、データ連携やワークフローへ置き換える対象を絞ります。
台帳・IDaaS・SIEM・EDRの比較
台帳は管理対象の把握、IDaaSは認証とID管理、SIEMはログ分析、EDRは端末の検知・対応をそれぞれ担います。
仕組み | 主な管理対象 | 実施する作業 | 単独では補えない範囲・注意点 |
|---|---|---|---|
表計算・資産管理台帳 | 機器、契約、サービス、責任者 | 管理対象と対応状況を一覧化します。 | 実機やサービスと照合しなければ、古い情報が残ります。 |
SaaS管理・ID管理の仕組み | サービス、利用者、退職者アカウント | 利用状況の収集や棚卸し、ライフサイクル管理を支援します。 | 未連携サービスは別の収集経路が必要です。 |
IDaaS | 認証、シングルサインオン、ID連携 | 認証ポリシーを適用し、対応サービスへID変更を連携します。 | サービス固有の細かな権限や、連携外のローカルIDは別途管理します。 |
SIEM | 認証・操作・通信などのログ | 複数のログを収集・関連づけし、調査へつなげます。 | ログを取得できないサービスの状況は分析できません。 |
EDR | 対応端末の挙動・侵害兆候 | 端末上の異常を検知し、隔離や調査を支援します。 | 未導入端末、SaaS内の権限設定、APIの認可不備は別途対処します。 |
監査・委託先評価 | ルールと実態、契約と運用 | 証跡を抽出し、未対応事項を是正します。 | 評価時点の確認だけでは日々の設定変更を追えません。 |
たとえば退職者アカウントを検知しても、停止する担当が決まっていなければ権限は残ります。SIEMが異常を検知しても、夜間に隔離を承認できなければ封じ込めが遅れます。導入前に、通知の受信者、実行者、承認者、休日の代行者を記入します。
効率化の一手段としてのマネーフォワード Admina
マネーフォワード Adminaは、台帳更新やアカウントの照合を効率化する選択肢として、監視・認証の仕組みと役割を分けて検討します。
マネーフォワード Adminaは当社の提供製品であり、以下の機能紹介は、注意喚起に書かれた特定製品の導入要件ではありません。既存の表計算、管理画面、API連携で運用できるなら、その手順を継続できます。情報収集や差分確認に遅れが出る対象があれば、次の機能と既存運用を対応づけます。
デバイス管理（Deviceプラン）は、PC・モバイル端末の台帳、MDM連携、複数台帳の集約、CSV取り込みを検討する際の候補です。
SaaSの利用状況可視化は、誰がどのサービスを利用し、2要素認証を設定しているかを整理する用途に対応します。
ID管理は、従業員マスターとの連携や、退職済みアカウントの検知・アラートを使った停止フローに組み込めます。
シャドーIT検出は、情シスが把握していないサービス利用を調べる手段です。
コンプライアンス対応機能は、SaaSごとの個人情報の有無や外部認証の取得状況を整理する用途で使えます。
評価時は、自社の対象サービスから取得できる項目と、別途収集する項目を分けます。取得できない情報は管理画面やCSVで補い、停止処理を自動化する場合も誤停止から復旧する担当を設けます。退職・異動の業務手順には「情シス向け入退社フローテンプレート」を利用できます。
なお、台帳で2要素認証の設定有無が見えても、その方式がフィッシング耐性を持つかは別の評価です。ログの長期保存、常時監視、端末隔離も、可視化機能だけで完結させず、SIEMやEDR、運用担当へ割り当てます。
▶ 関連記事: RBACとは？ABACとの違いや読み方・情シス向け設計手順を解説
経営層・法務への報告と損失の説明
経営報告では、改訂版の9事例のうち自社に当てはまるもの、未対応事項、想定する業務影響、是正に必要な判断を一枚にまとめます。
個人情報保護委員会はWARNINGの「はじめに」で、経営層を交えて組織体制の問題点や、漏えい時に生じうる損害を評価する方向を示しています。法第23条・第24条・第25条の違反リスクを伝える際は、「機器が古い」という技術説明にとどめず、「誰の判断がないため更新できないのか」まで書きます。
罰則と被害額を分けた説明
罰則と事故対応費用は発生条件が違うため、別々の項目として経営層へ示します。
IPAの「2024年度 中小企業における情報セキュリティ対策に関する実態調査 報告書」（2025年5月）は、情報漏えい時の損害の一つとして、個人情報保護法上の罰金が最大1億円であることを挙げています。これは委員会の命令に違反した場合などに法人に科される罰金の上限です。これは漏えいが起きれば自動的に1億円の罰金が科されるという規定ではなく、対象となる違反行為と適用条件を分けて説明します。
同報告書は、日本ネットワークセキュリティ協会の「インシデント損害額調査レポート」（2024年2月）をもとに、ウェブサイトからの情報漏えいの被害金額を、個人情報のみで2,955万円、クレジットカード情報を含む場合で3,843万円と掲載しています。事故対応に要した内部工数の平均は、それぞれ13.3人月、13.5人月です。同報告書は、社内の従業員の対応コストが被害金額に計上されていないケースが多いとしています。これらは自社の被害額を予測する数値ではありません。経営説明では約3,000万円規模の費用と長期の社内対応が生じうる参考値として使い、自社の費用は別途積み上げます。
対策予算の判断に使う報告様式
報告書は、未対応の件数よりも、個人データへ到達する経路と是正期限を判断できる形にします。
報告項目 | 記入する内容 | 経営・法務へ求める判断 |
|---|---|---|
対象リスク | 事例番号、対象システム、外部公開、管理者権限、データの性質と量 | 事業継続と停止・制限のどちらを優先するか |
現状と不足 | 未更新機器、所有者不明ID、未取得ログなどの具体的な状態 | 暫定措置を許容する期間と責任者 |
対応案 | 更新、廃止、権限制限、監視補完の選択肢と作業量 | 予算、要員、停止時間の承認 |
事故時の損失 | 調査、復旧、通知、問い合わせ、業務停止の費用と工数 | 外部専門家との契約や緊急支出の承認範囲 |
完了条件 | 設定変更の証跡、試験結果、残存リスク、再点検日 | 例外の継続か、対応完了か |
セキュリティ委員会では、保守部門だけで解決できない契約変更や、人事部門が持つ退職情報の連携を議題にします。法務は報告・通知の判断、事業部門は利用停止の影響、情シスは技術的な封じ込めを担当し、権限が競合する場面は経営層へ上げます。
▶ 関連記事: 情報資産管理とは？定義・分類から2026年最新対策まで解説
不正アクセス検知時の対応状況と報告の基準項目
不正アクセスを検知したら、封じ込めと証拠保全を進めながら、報告対象の判定と速報の準備を並行します。
「不正アクセスによる漏えい等の事案を踏まえた対応について」を社内で整理する際は、検知、初動、報告、復旧を一つの時系列に載せます。漏えい件数の確定を待ってから法務へ連絡する運用にせず、個人データへの不正アクセスや漏えいのおそれを把握した段階で連携します。
速報・確報の起算点と期限
期限は攻撃が始まった日ではなく、事業者が報告対象の事態を知った日を基準に管理します。
個人情報保護委員会の漏えい等報告の案内に沿うと、速報は事態を知った後「速やかに」行い、その目安が概ね3〜5日以内です。3〜5日は一律の法定日数としてではなく、速やかな報告の目安として扱います。確報は知った日から30日以内で、不正の目的をもって行われたおそれがある事態では60日以内です。
社内では、誰がいつ何を知ったかを受付記録へ残します。担当者が報告対象となる事実を把握してから、責任者への連絡が遅れた分を報告期限に上乗せしません。委託先から通知を受けた場合も、通知日時とその内容を記録し、委託元・委託先それぞれの報告関係を法務が整理します。
段階 | 時点・期限 | 主担当と実施内容 |
|---|---|---|
検知・受付 | 異常を把握した時点 | 情シス・監視担当が検知日時、対象、検知元を記録し、事故対応責任者へ連絡します。 |
封じ込め・保全 | 初動で並行実施 | 技術担当が接続制限やID停止を実施し、ログ、設定、証拠を保全します。 |
報告対象の判定 | 初動から継続 | 法務・個人情報管理担当がデータの種類、不正目的のおそれ、人数などを整理します。 |
速報 | 知った後、速やかに。概ね3〜5日以内が目安 | その時点で判明している内容を報告し、未判明部分は調査を継続します。 |
確報 | 知った日から30日以内。不正目的のおそれがある事態は60日以内 | 原因、影響、対応、再発防止策などをまとめます。 |
本人への通知 | 報告対象の事態について、状況に応じて速やかに実施 | 法務・広報・窓口担当が、本人の被害を抑える内容と連絡方法を整理します。 |
本人への通知は、確報が完成するまで待つ手続きとして扱いません。直接の通知が困難な場合の代替措置や、業種ごとの報告先の委任については、法務が委員会の案内と照合して提出先・手段を決めます。
企業資料に残す初動対応の基準項目
不正アクセス検知時の対応状況を説明する企業資料には、事実、判断、実施済み措置、未解決事項を分けて記載します。
基準項目 | 記録する内容 | 記録を使う判断 |
|---|---|---|
認知の経緯 | 検知日時、認知者、外部通報、アラートの内容 | 報告の起算管理と初動の検証 |
対象と範囲 | システム、アカウント、データの種類、対象期間、人数 | 報告対象の判定と利用者への影響評価 |
確認した事実 | 不正ログイン、取得操作、外部通信、ログの欠落 | 漏えいの有無・おそれと調査範囲 |
封じ込め | 停止・隔離・権限変更の実施日時と担当 | 継続中の被害と再侵入経路の評価 |
証拠保全 | 取得ログ、保存先、取得者、改変防止、専門家への引渡し | 追加調査、原因分析、説明の整合性 |
連絡と意思決定 | 経営・法務・委託元への連絡、報告先、通知方針 | 承認待ちによる遅延の解消 |
残る課題 | 未判明事項、次の調査、担当、期限 | 確報と再発防止計画への引継ぎ |
ログに記録がないことと、漏えいがなかったことを同一視しません。保存期間が短い、取得設定がないなどの欠落があれば、調査できない期間・範囲として記載し、別のログや委託先の記録で補います。
証拠保全と業務復旧の順序
復旧を急ぐ場合も、再インストールや設定初期化の前に、必要な証拠を確保する担当を置きます。
隔離で被害を止められるなら、端末やサービスの接続を制限してからログを取得します。緊急停止が必要なら停止を優先し、その判断者と理由を残します。攻撃経路、悪用アカウント、残存する認証情報を処理せずに再公開すると、同じ経路から再侵入されるおそれがあります。復旧承認には、経路の是正と監視再開を条件として含めます。
夜間や休日も含めた役割分担は「CSIRTとは？役割やSOCとの違い・構築手順を分かりやすく解説」で整理できます。外部支援を使う場合は、事故が起きる前に緊急連絡先と、ログ提供や端末引渡しの承認者を決めておきます。
▶ 関連記事: サプライチェーン攻撃とは？手口・脅威の推移と中小企業の対策
▲ 不正アクセス検知から個人情報保護委員会への報告要否および期限の判断フロー
リスク別の優先順位と着手チェックリスト
着手順は従業員数ではなく、外部公開、管理者権限、個人データの機微性・量、委託先からの接続で決めます。
次の優先度は運用提案です。下位の項目でも、不正アクセスが疑われる、ログが消失しかけている、大量の個人データへ直接到達できるといった条件があれば、最優先へ繰り上げます。
優先度高：外部公開資産・管理者アカウント
外部から侵入できる資産や、個人データを大量取得できる権限がある場合は、担当を割り当てた当日から影響判定と暫定措置を進めます。
インターネット公開資産に既知の脆弱性やサポート切れがあれば、更新・停止・接続制限のいずれを実施するかを決めます。
管理者IDの所有者と用途が不明なら、利用状況を調べ、代替管理者を確保してから権限を制限します。
退職者のアカウントや有効なセッションが残っていれば、業務承継と証拠保全を踏まえて停止・失効します。
他者のIDに変更すると個人データを取得できるAPIがあれば、公開範囲を制限し、認可処理の修正と再試験を行います。
要配慮個人情報や財産的被害につながる情報へ到達できる経路は、認証強度と出力権限を優先して見直します。
優先度中：ログ保管・委託先評価
直接の侵入経路を抑えた後は、検知の遅れと委託先経由の影響を減らす運用を整えます。
認証・アクセス・操作ログの保存期間と取得担当を一覧化し、取得漏れがあれば外部保存や代替ログを設定します。
委託先とクラウドサービスの事故連絡窓口、連絡期限、調査協力の範囲を契約・手順へ反映します。
個人データの保存場所と保存期間を整理し、利用目的が終わったデータを消去の承認へ回します。
グループ会社や海外拠点に、ポリシーの配布だけでなく適用結果の証跡を提出してもらいます。
速報・確報の期限を含む連絡訓練を行い、代理担当へ連絡できない箇所を修正します。
優先度低：見直し案の確定前準備
現在の高リスク事項を処理したうえで、見直し案への適合ギャップを調べ、今後の予算と規程改定の準備を進めます。
現行の通則編10-6の4項目と、先取り公表された見直し案の5項目を別列で管理します。
新しい検知項目に沿って、ログ取得、分析、隔離、アカウント停止の担当が連続しているかを試します。
認証方式を変更する場合は、端末対応、利用者登録、紛失時の復旧まで含めて限定検証を行います。
確定した公表内容との差分を反映してから、社内規程と監査基準を最終化します。
チェックが終わった項目には、設定画面、変更履歴、試験結果などの証跡を付けます。未対応項目は理由だけで閉じず、暫定措置、責任者、解消期限を記入します。
まとめ
個人情報保護委員会は2026年10月7日にWARNINGを改訂し、API悪用（事例9）を加えた9事例と、対策を多層的に講じる必要があることを示しました。措置が十分でない場合は法第23条・第24条・第25条の違反と判断される可能性があります。
同日の注意喚起の別紙は、ガイドラインの手法の例示の見直し予定内容の先取りで、確定は2027年4月の予定です。現行の通則編10-6の措置は(1)〜(4)の4つで、別紙の内容はまだ現行の義務ではありません。
まず外部公開資産と管理者アカウントから点検し、退職者アカウントの停止、ログの保存期間の確認、漏えい等報告（速報は概ね3〜5日以内、確報は30日以内、不正の目的のおそれがある場合は60日以内）の連絡体制を整えます。
まとめ
個人情報保護委員会が改訂した注意喚起の9事例は、資産、認証、権限、データの保存先、委託先、APIを横断して点検するための資料です。情シスは現行の義務と見直し案を分け、外部公開資産と管理者アカウントから是正を進めます。
最初の一歩は、資産・アカウントの一覧に責任者と個人データの有無を加える作業です。所有者不明の権限や未更新機器を抽出し、暫定措置と期限を決めます。あわせて速報・確報の連絡経路を試し、検知から報告まで担当者が途切れない体制を整えます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
