>
>
公開日
2026年10月7日、個人情報保護委員会は「大規模な漏えい等事案を踏まえた対応について（注意喚起）」を公表し、あわせて「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」を改訂しました。大量の個人データを扱う事業者が外部から不正アクセスを受け、大規模な漏えいやそのおそれが生じる事案が続いていることを受けた対応です。
注意喚起の中身は、法務部門だけで受け止められるものではありません。IT資産の洗い出し、認証方式、ログの保存と分析、クラウドサービスの選定など、示された対策の多くは情シスが日々運用している領域そのものです。
本記事では、委員会が公表した一次資料をもとに、改訂で何が変わったのか、情シスがどの観点で自社を点検すべきかを整理します。情報漏洩の基本的な原因と対策については「情報漏洩はなぜ起こる？原因や予防策・対策まで解説」もあわせてご覧ください。
本記事のポイント
2026年10月7日に公表されたのは「注意喚起」本文と「改訂版WARNING」の2つ。注意喚起では、2027年4月に確定予定のガイドライン見直し内容が先取りで示された
改訂版WARNINGは事例が8つから9つに増え、「APIが悪用される事例」が加わった。既存8事例のうち6事例にも、貸与品のVPN装置やサポート切れ機器、ログ保存ルールの不在といった原因が追記されている
先取りされた技術的安全管理措置では、「不正アクセス等の検知等」が独立した項目となり、ログの一定期間保管と定期的な分析、フィッシング耐性のある多要素認証などが手法の例として並んだ
不要になった個人データの消去（法第22条の努力義務）も改めて求められた。どこに何のデータがあるかを把握していないと、消去も漏えい時の影響評価もできない
情シスの点検は、IT資産・アカウント・データの置き場所という3つの「台帳」を最新に保つことから始めるのが近道
2026年10月7日、個人情報保護委員会は何を公表したのか
今回公表されたのは、大規模漏えいを踏まえた「注意喚起」本文と、典型的な事案類型をまとめた「改訂版WARNING」の2つです。前者は法的な位置づけとガイドライン見直しの方向性を、後者は実際に起きた事案の原因と対策を示しています。
注意喚起本文は、個人情報取扱事業者全般に宛てたものです。そのうえで、国民の多くが使うサービスを提供して大量の個人情報を持つ事業者や、機微性の高い情報、財産的被害や詐欺につながりうる情報を持つ事業者に対しては、特に適正な取扱いを求めています。
本文は大きく4つのパートで構成されています。
パート | 内容 | 情シスにとっての意味 |
|---|---|---|
1 安全管理措置の全体像 | ガイドラインの「講じなければならない措置」と「手法の例示」の関係を説明 | 何が法違反の判断に関わり、何が例示なのかを区別できる |
2 今後の見直し予定 | 2027年4月確定予定の見直し内容のうち、技術的安全管理措置を先取りで提示 | 今後求められる水準を前倒しで把握できる |
3 不要となった個人データの消去 | 法第22条の努力義務を改めて注意喚起 | データの所在把握と消去手段の整備が問われる |
4 その他 | 改訂版WARNINGの参照を案内 | 事例ベースで自社の弱点を点検できる |
1つ目のパートは、点検の優先順位を考えるうえで押さえておきたい部分です。ガイドラインの「講じなければならない措置」に従わない場合は法違反と判断される可能性がある一方、「手法の例示」は文字どおり例であり、すべてを実施しなければ違反になるわけではないと説明されています。適切な手法は、漏えい時に本人が受ける権利利益の侵害の大きさや、事業の規模・性質、扱うデータの性質と量に応じて選ぶものとされています。
改訂版WARNINGの変更点｜8事例から9事例へ
改訂版WARNINGの最大の変更は、事例9「APIが悪用される事例」の追加です。あわせて冒頭の説明と、既存8事例のうち6事例（事例1〜4・6・7）に原因・対策の追記があり、2024年12月の初版と比べると「資産の把握漏れ」と「運用ルールの不在」に関する記述が厚くなっています。
冒頭には、脆弱性対応や強固な認証方式はどれか一つを講じればよいものではなく、多層的に講じる必要があるという一文が加わりました。さらに、技術的な対応にとどめず、経営層を交えて現状の組織体制の問題点や、漏えいが起きた場合に生じうる損害を評価し、組織的に対応する必要があると明記されています。
既存事例への主な追記は次のとおりです（初版PDFとの比較による）。
事例 | 追記された主な原因 | 追記・強化された対策 |
|---|---|---|
事例1 脆弱性が放置された | 保守契約に脆弱性対応が含まれていなかった／脆弱性情報を集めても対処の役割分担がなかった | 外部事業者から貸与されている物を含めてIT資産を洗い出す／脆弱性へ「速やかに」対処する |
事例2 脆弱性への対応が遅れた | 社内ネットワーク内なら安全と考え、サポート期限切れの機器を使い続けた | 外部からの侵入を想定し、社内ネットワーク上の機器にも脆弱性対策を徹底する |
事例3 不正ログイン | ログの保存・監視のルールがなく、不正アクセスの検知が遅れた | ログの保存期間を定め、定期的に分析する |
事例4 グループ会社・海外拠点 | 海外拠点の貸与品VPN装置が台帳に載っておらず、存在を把握できていなかった | 海外拠点を含め、貸与品も対象にIT資産を洗い出す |
事例6 個人領域に保存したデータ | （大きな変更なし） | 従業者へ取扱いルールを日頃から周知し徹底を促す |
事例7 グループ会社への監督 | グループ全体のセキュリティポリシーが改訂されたのに、子会社が対応できていなかった | （対策の趣旨は維持） |
事例5・8は表現の調整のみで、内容に大きな変更はありません。
追記された原因の多くは、「存在を知らない資産」と「誰がやるか決まっていない作業」に行き着きます。とくに事例4は、台帳に載っていない貸与品のVPN装置が足がかりになったことを示しています。VPN装置がなぜ狙われやすいのかは「VPNとは？仕組み・種類から接続のやり方までわかりやすく解説」で解説しています。
9つの事例を情シスの点検領域に置き換える
9つの事例は、情シスの業務に置き換えると「IT資産と脆弱性」「認証とアクセス制御」「データの置き場所」「グループ・委託先・クラウド」「API」の5領域に整理できます。自社でどの領域が手薄かを見極めると、点検の順番が決めやすくなります。
事例 | 点検領域 | 情シスがまず確認したいこと |
|---|---|---|
1 脆弱性が放置された | IT資産と脆弱性 | 保守契約の範囲に脆弱性対応が入っているか |
2 脆弱性への対応が遅れた | IT資産と脆弱性 | パッチ適用状況を一元管理できているか、サポート切れ機器が残っていないか |
3 不正ログイン | 認証とアクセス制御 | 多要素認証の適用範囲、アカウントロック、ログの保存期間 |
4 グループ会社・海外拠点が狙われた | IT資産と脆弱性 | 貸与品・海外拠点の機器まで台帳に載っているか |
5 グループ会社間のアクセス制御不備 | 認証とアクセス制御 | 管理者アカウントの認証強度、会社間のアクセス範囲 |
6 個人領域に保存したデータ | データの置き場所 | 個人データの保存場所が決まっているか、個人の端末に散らばっていないか |
7 グループ会社への監督が不十分 | グループ・委託先・クラウド | 親会社への委託も外部委託と同じ基準で監督しているか |
8 クラウドサービスからの漏えい | グループ・委託先・クラウド | 選定時にセキュリティ対策を確認しているか |
9 APIが悪用される | API | 管理対象から漏れたAPIがないか |
IT資産と脆弱性（事例1・2・4）
3つの事例に共通する対策は、⑴管理対象となるIT資産の洗い出し、⑵脆弱性情報の収集・分析、⑶脆弱性への速やかな対処、という脆弱性対策プロセスです。改訂版では⑴に「外部の事業者から貸与されている物を含む」という注記が付きました。
ここで効いてくるのは、台帳の網羅性と更新頻度です。回線事業者や保守業者から貸与されたルーター・VPN装置は、購買記録に残らず台帳から漏れやすい資産の典型です。表計算ソフトで台帳を管理している場合、拠点や子会社ごとに台帳が分かれ、更新も担当者頼みになりがちです。その限界と対処法は「端末管理台帳のエクセル限界とは？効率化とツールの選び方」で整理しています。
脆弱性そのものの考え方は「脆弱性とは？」を参照してください。
認証とアクセス制御（事例3・5）
事例3と5は、推測されやすいパスワードや弱い管理者パスワードが突破口になったケースです。対策としては、扱う個人データの性質と量に応じて多要素認証などの強い認証方式を採用すること、アカウントロックで総当たり攻撃を防ぐこと、漏えいした可能性があるIDとパスワードを初期化することが挙げられています。
改訂版の事例3には、ログの保存・監視ルールがなかったために検知が遅れたという原因と、ログの保存期間を定めて定期的に分析するという対策が加わりました。侵入を防ぐ対策と、侵入に早く気づく対策を、セットで見直すよう求めていると読めます。総当たり攻撃の具体的な対策は「ブルートフォース攻撃の対策とは？」、グループ会社間を含む権限設計は「RBACとは？」が参考になります。
データの置き場所（事例6）
事例6は、従業者が業務ファイルを各自のデスクトップ端末などに保存する運用が慣例化し、侵入を受けた際にそこからも漏えいした事案です。本来消すべき古いデータまで含まれていたため、被害の範囲が広がったと説明されています。
WARNINGは対策として、個人情報管理台帳を整備し、決められた保存場所でデータを作成・加工・保存すること、監査部門が取扱状況を把握して定期的に監査することを挙げています。台帳づくりの考え方は「情報資産管理とは？定義・分類から2026年最新対策まで解説」で解説しています。
グループ・委託先・クラウド（事例7・8）
事例7と8は、「委託に当たらないから監督は不要」という思い込みが原因になった点で共通しています。事例7では親会社への業務集約を委託と認識していなかったこと、事例8ではクラウドサービスの利用を委託と考えていなかったことが、監督の欠落につながりました。
クラウドサービスについてWARNINGは、利用規約や安全性評価の資料などでセキュリティ対策を確認したうえでサービスを選ぶよう求めています。SaaSの数が増えるほど、どのサービスに個人データが入り、どの第三者認証を取得しているかを一覧で持っておくことが、選定と監督の土台になります。委託先やグループ会社を経由した攻撃の全体像は「サプライチェーン攻撃とは？手口・脅威の推移と中小企業の対策」、委託先評価の具体的な進め方は「【SCS評価制度対応版】セキュリティチェックシートの作り方」が参考になります。SaaSごとに個人情報の有無や外部認証の取得状況を登録しておく方法は、Adminaのコンプライアンス対応機能でも紹介しています。
API（事例9）
新たに追加された事例9は、自社が提供するスマートフォンアプリやWebサービスのAPI（システム同士をつなぐ窓口）の設計・設定不備を突かれた事案です。ログイン後にURLや会員IDなどのパラメータを書き換えるだけで、他のユーザーの情報を取得できる状態になっていました。
原因として、管理対象から漏れたAPIの存在、連番の会員ID、レスポンスに含まれた不要な情報、アクセス回数制限（レートリミット）の欠如が挙げられています。対策は、定期的なAPIの棚卸し、認証に加えて「そのデータにアクセスする権限があるか」を毎回確認する認可の実装、UUIDなどランダムな値の採用、レートリミットの実装です。
APIの設計そのものは開発部門の担当であることが多いものの、「管理対象から漏れたAPI」はIT資産管理の問題でもあります。外部委託で開発したサービスや、過去に公開したまま担当者が異動したサービスがないか、情シス側の台帳と突き合わせておくと安心です。APIの基本は「APIエンドポイントとは？URLとの違いから管理・セキュリティまで」で解説しています。
先取りされたガイドライン見直し｜技術的安全管理措置の5項目
注意喚起本文の別紙では、2027年4月に確定予定のガイドライン見直しのうち、技術的安全管理措置（10-6）の内容が先取りで示されました。外部からの不正アクセスに直接関わる部分であり、情シスが今後の点検基準として参照すべき箇所です。
見直し後の「講じなければならない措置」は次の5項目です。
講じなければならない措置 | 情シスが押さえたい主な手法の例示 |
|---|---|
(1) アクセス制御 | 特権アカウントを割り当てる人・端末・場面の最小化／人事異動・退職時のアクセス権変更／アクセス権の定期的な棚卸し／アクセス要求ごとに場所・時間・デバイスの状態などを評価して可否を判断する仕組み |
(2) アクセス者の識別と認証 | パスワードの使い回し禁止と最低文字数／ログイン失敗時のID停止／組織外からのアクセス・管理者権限・重要データへのアクセスにはフィッシング耐性のあるものを含む多要素認証 |
(3) 外部からの不正アクセス等の防止 | ファイアウォール、ウイルス対策ソフトの運用／自動更新を含むソフトウェアの最新化／許可していないソフトウェアの導入防止と定期的な監査／組織が許可し基準を満たしたデバイスからのみアクセスを許可 |
(4) 情報システムの使用に伴う漏えい等の防止 | 設計時の安全性確保と継続的な見直し／テストデータとしての個人データ利用の最小化／通信の暗号化／クラウド上のデータは暗号化消去など復元困難な方法で消去 |
(5) 不正アクセス等の検知等 | 認証ログ・アクセスログ・操作ログ・通信ログ等を一定期間保管し、改ざんや不正消去から保護／ログの定期的な分析／IDS/IPS、EDRなどによる常時監視／侵害時のシステム隔離やアカウント無効化 |
注目したいのは(5)です。委員会が2026年9月16日の会合で示した検討資料によると、現行ガイドラインではログ分析による検知が(3)の手法の例示に含まれており、項目名からは読み取りにくい状態でした。見直し案では「不正アクセス等の検知等」が独立した措置となり、平時から早期検知の仕組みを講じ、組織内ネットワークでの被害拡大を防ぐことが求められています。侵入を前提にした横展開対策を盛り込むという、検討資料の方向性が反映された形です。IDS/IPSとEDRの違いは「IDSとIPSの違いとは？EDRとの比較や2026年の選定基準」で解説しています。
(1)のアクセス要求ごとに状況を評価する仕組みは、ゼロトラストの考え方を取り込んだものです。検討資料も、現行ガイドラインが境界型のセキュリティを念頭に置いていることを課題に挙げていました。考え方の全体像は「ゼロトラストとは？」を参照してください。
中小規模事業者向けにも手法の例示が用意されています。個人データを扱える機器と担当者を明確にする、OSとセキュリティ対策ソフトを自動更新で最新に保つ、ログを一定期間保管する、といった内容で、人手の限られた組織でも着手しやすい水準に絞られています。
見直しは今後、次のスケジュール（案）で進む予定です。
時期（案） | 内容 |
|---|---|
2026年11月頃 | 見直し案の委員会審議 |
2026年12月頃 | パブリックコメント開始 |
2027年2月頃 | パブリックコメント結果の報告、改正事項の決定 |
2027年4月 | 改正事項の施行 |
現時点の別紙は「見直し予定の内容を先取りしたもの」であり、パブリックコメントを経て変わる可能性があります。ただ、施行を待ってから準備を始めると、台帳整備やログ基盤の構築が間に合わないおそれがあります。今のうちに自社の現状とのギャップを洗い出しておくのが現実的です。
「不要な個人データの消去」を情シスはどう支えるか
注意喚起は、利用する必要がなくなった個人データを遅滞なく消去するという法第22条の努力義務を、改めて取り上げました。消去が徹底されず、漏えいが深刻化した事例に接していると委員会は述べています。
消去すべきかどうかの判断は、利用目的や法令上の保存期間に照らして行うものです。法令で保存期間が定められている場合は、その期間は消去の対象外になります。判断そのものは事業部門や法務が担うことが多いでしょう。
一方で、判断の前提となる「どこに、どの個人データが残っているか」を把握できるのは情シスです。退会者や退職者のデータが残るSaaS、利用を終えたのに解約されていないサービス、外部に公開されたままの共有ファイルは、いずれも漏えい時に被害を広げる要因になります。
情シスが支えられるのは、主に次の3点です。
個人データを保存しているSaaS・ストレージの一覧化と、各サービスでの保存期間の確認
使われなくなったSaaSやアカウントの棚卸しと停止
クラウド上のデータを消去する際の手段（サービス提供者の消去方法、暗号化消去など）の確認
棚卸しの進め方は「SaaS棚卸しの進め方と実践的ツール比較｜費用削減の5ステップ」で解説しています。意図せず外部公開されたファイルを洗い出したい場合は、Adminaの外部共有コンテンツ管理のように、クラウドストレージの公開ファイルを一覧で確認できる仕組みも選択肢になります。
点検の起点はIT資産・アカウント・データ置き場の可視化
9つの事例と5つの措置を見渡すと、どの対策も「何があるかを正しく把握している」ことを前提にしています。情シスの点検は、IT資産・アカウント・データの置き場所という3つの台帳を最新に保つことから始めるのが近道です。
台帳が古いままだと、脆弱性情報が出ても影響範囲を特定できず、退職者のアカウントも見落とします。漏えいが起きたときに「何件、どの情報が対象か」をすぐに答えられないのも、台帳が実態とずれている組織に多い状況です。
マネーフォワード Admina では、注意喚起の論点に沿って次のような可視化を支援しています。
IT資産の台帳：デバイス管理（Deviceプラン）で、PC・モバイル端末をSaaS情報と紐づけて管理できます。MDM連携による台帳の自動更新や、複数台帳の集約、CSVインポートにも対応しています
アカウントと認証状況：SaaSの利用状況可視化で、誰がどのSaaSのアカウントを持ち、2要素認証を設定しているかを一覧で確認できます
退職・異動時の権限変更：ID管理で従業員マスターと連携し、退職済みアカウントを検知してアラートを出せます
許可していないサービスの把握：シャドーIT検出で、情シスが把握していないSaaSの利用を見つけられます
なお、ログの長期保管や侵入の常時監視は、SIEMやEDRといった専用の製品が担う領域です。台帳による可視化と検知の仕組みを組み合わせることで、ガイドライン見直し案が求める多層的な対策に近づけます。退職・異動時の手順そのものを見直したい場合は「情シス向け入退社フローテンプレート」も活用できます。
企業規模別に今やるべきこと
対応の優先度は組織の規模で変わりますが、どの規模でも「台帳を最新にする」「認証を強くする」「ログを残す」の順で進めると手戻りが少なくなります。
50名未満の組織では、中小規模事業者向けの手法の例示が出発点になります。個人データを扱える端末と担当者を決め、OSとセキュリティ対策ソフトを自動更新で最新に保つことから始めましょう。管理者アカウントと社外からアクセスするアカウントに多要素認証をかけるだけでも、事例3・5のようなリスクは大きく下がります。
50〜300名の組織では、拠点や部門ごとに分散した台帳を一本化する段階です。回線業者からの貸与機器や、利用を終えたSaaSが台帳から漏れていないかを確認し、退職者アカウントの停止を入退社フローに組み込みます。あわせて、どのログをどこに何日保存しているかを棚卸しし、保存期間をルールとして明文化してください。
300名超の組織、とくにグループ会社や海外拠点を持つ企業では、事例2・4・5・7が直接の参考になります。脆弱性対応とパッチ適用状況をグループで一元管理し、親会社への業務集約も委託として監督する体制を整えます。アクセス要求ごとの評価やEDRによる常時監視など、見直し案の手法の例示とのギャップ分析も、この規模から着手しておきたい項目です。
経営層・法務への報告にどう使うか
今回の資料は、情シスが経営層に対策の必要性を説明する材料としても使えます。改訂版WARNINGは、9つの事例への措置が不十分な場合、安全管理措置（法第23条）、従業者の監督（法第24条）、委託先の監督（法第25条）の違反と判断される可能性があると明記しているためです。
報告の際は、技術的な不足点の列挙だけで終わらせず、WARNINGが求めるように「漏えいが起きた場合に生じうる損害」とあわせて示すと、投資判断につながりやすくなります。たとえば、保守契約に脆弱性対応が含まれていない、台帳に載っていない機器がある、といった事例の原因と自社の状況を対応づけて示す方法が有効です。
万一に備え、漏えい等報告の流れも確認しておきましょう。委員会の案内では、報告対象となる事態を把握したら、まず発覚日から3〜5日以内に速報を、次に30日以内（不正の目的で行われたおそれがある場合は60日以内）に確報を出すことになっています。不正アクセスによる漏えいやそのおそれ、本人の数が1,000人を超える漏えいなどが報告対象です。ランサムウェア事案などでは、関係省庁共通の様式で報告することもできます。社内の初動体制づくりは「CSIRTとは？役割やSOCとの違い・構築手順を分かりやすく解説」が参考になります。
よくある質問（FAQ）
Q. 今回の注意喚起は、大量の個人情報を持つ大企業だけが対象ですか？
A. 注意喚起は個人情報取扱事業者全般に宛てたもので、そのうえで大量の個人情報や機微な情報を持つ事業者に特に注意を促しています。改訂版WARNINGの9事例は業種や規模を問わず起こりうる内容で、ガイドラインには中小規模事業者向けの手法の例示も用意されています。
Q. ガイドラインの「手法の例示」をすべて実施しないと法違反になりますか？
A. なりません。法違反と判断される可能性があるのは「講じなければならない措置」に従わなかった場合です。「手法の例示」は例であり、事業の規模や扱うデータの性質・量に応じて、必要かつ適切な手法を選ぶものとされています。
Q. 見直し後のガイドラインはいつから適用されますか？
A. 注意喚起本文では、見直し内容の確定は2027年4月を予定しているとされています。委員会の検討資料では、2026年11月頃の審議、12月頃のパブリックコメントを経て、2027年4月に施行するスケジュール案が示されています。
Q. 自社でアプリを開発していなくても、事例9（API悪用）は関係ありますか？
A. 事例9は自社が提供するアプリやWebサービスのAPIが対象です。自社で開発していなくても、外部委託で開発・公開したサービスがあれば該当します。管理対象から漏れたAPIが原因の一つとされているため、委託先が運用しているサービスも含めて台帳に載っているかを確認してください。
Q. クラウドサービスの利用も、委託先として監督する必要がありますか？
A. 改訂版WARNINGの事例8では、クラウドサービスの利用を委託に当たらないと考えて監督しなかったことが原因として挙げられています。委託に当たるかどうかは契約内容などによって変わるため、法務と確認したうえで、少なくともサービス選定時には利用規約や安全性評価の資料でセキュリティ対策を確認することが求められます。
Q. 漏えいが起きた場合、どのくらいの期間で報告が必要ですか？
A. 委員会の案内では、発覚日から3〜5日以内に速報、30日以内に確報を提出します。不正の目的で行われたおそれがある場合、確報の期限は60日以内です。報告先は原則として個人情報保護委員会ですが、権限が事業所管大臣に委任されている業種では委任先の省庁に報告します。
まとめ：情シスが今すぐ確認したいチェックリスト
2026年10月7日の注意喚起と改訂版WARNINGは、不正アクセスによる漏えいの多くが「把握していない資産」と「決まっていない運用ルール」から生じていることを示しました。先取りされたガイドライン見直し案は、侵入を防ぐ対策に加えて、侵入に早く気づき被害の拡大を止める対策まで求めています。
まずは次の項目から、自社の状況を確認してみてください。
✅ 貸与品や海外拠点の機器を含め、IT資産の台帳が最新になっているか
✅ 保守契約の範囲に脆弱性対応が含まれ、パッチ適用の役割分担が決まっているか
✅ サポート期限切れの機器が社内ネットワークに残っていないか
✅ 管理者権限や社外からのアクセスに、フィッシング耐性のある多要素認証を適用しているか
✅ 退職・異動時のアクセス権変更と、アクセス権の定期的な棚卸しを実施しているか
✅ 認証ログやアクセスログの保存期間を定め、定期的に分析しているか
✅ 個人データの保存場所が決まっており、従業者の端末に散在していないか
✅ 個人データを扱うSaaSを一覧化し、選定時にセキュリティ対策を確認しているか
✅ 外部委託や過去に公開したサービスを含め、APIが台帳に載っているか
✅ 不要になった個人データやアカウントを棚卸しし、消去・停止しているか
台帳の整備と運用ルールの明文化は、ガイドラインの施行を待たずに始められます。マネーフォワード Admina のようなSaaS・デバイス管理プラットフォームを活用すれば、IT資産とアカウントの状況を一元的に把握し、点検の土台を短期間で整えられます。
出典
個人情報保護委員会「大規模な漏えい等事案を踏まえた対応について（注意喚起）」（2026年10月7日）
個人情報保護委員会「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」（2024年12月11日、2026年10月7日改訂）
個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）等における安全管理措置の手法の例示の追加等の検討について」（第369回個人情報保護委員会 資料2、2026年9月16日）
個人情報保護委員会「漏えい等の対応とお役立ち資料」
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
