2026.10.15(更新日:2026.11.07)

情報漏洩が相次ぐ今，企業の信頼を守る法務の備え―平時の体制，発覚後の初動，報告・通知・公表（AI作成）

第１　企業の信頼を守る法務の備えとは

１　事故を完全になくす約束ではなく，発見して説明できる体制を整える

情報漏洩が相次ぐ今，企業の信頼を守る法務の備えは，「事故を一件も起こさない」と表明することではない。
保有する情報と利用するシステムを把握し，異常を早期に発見し，被害拡大を止め，証拠を残し，必要な相手へ期限内に報告・通知し，確認済みの事実を継続して説明できる体制を平時から整えることである。

本記事は，一般企業が個人データ等の漏えい，滅失又は毀損のおそれを把握した場合を中心に，企業法務が確認する順序を整理する。
金融，医療，通信，上場会社等には業法上の報告又は適時開示が加わることがあるため，個別業種の規制は別に確認する必要がある。

２　「情報漏洩」と法令上の「漏えい等」を区別する

一般に「情報漏洩」と呼ばれる事象には，外部への流出だけでなく，誤送信，紛失，盗難，不正アクセス，設定不備，内部不正，ランサムウェアによる利用不能及びデータの改変が含まれ得る。
個人情報保護法の実務では，個人データの「漏えい，滅失又は毀損」を分け，それぞれ発生又は発生のおそれがあるかを判断する。

第２　なぜ今，企業法務が平時から関与する必要があるか

１　攻撃経路と委託関係が複雑になっている

近時の公的注意喚起は，既知の脆弱性，認証情報の窃取，クラウド設定，APIの認可不備，グループ会社，委託先及び個人用領域など，事故の入口が一つではないことを示している。
法務部門は，情報システム部門だけに対応を委ねず，誰がどの情報をどのサービスで扱い，誰に委託し，異常時に誰が決定するかを契約と社内体制の両面から確認する必要がある。

２　令和８年１０月の注意喚起と現行義務を混同しない

個人情報保護委員会が令和８年１０月７日に示した資料は，大規模漏えい等を踏まえ，異常の早期検知，横展開防止，ログ取得・保存・分析及び遮断等を重視している。
同資料は，見直しの内容の確定を令和９年４月に予定すると説明し，見直し予定の内容を先取りして示している。
この記載を令和９年４月からの適用開始が確定したという意味に読み替えず，現行の義務，手法の例示及び今後の見直しを区別する。

その後，令和８年１１月６日に決定された「サイバーセキュリティ緊急対策パッケージ」は，個人情報保護委員会が安全管理措置に関するガイドラインの全項目の「手法の例示」の改正作業を加速させ，令和９年１月中の施行を目指すとした。
これも施行の目標であり，改正の内容と施行日が確定したものではない。
同パッケージと国家サイバー統括室の令和８年１１月５日の注意喚起の内容は，国家サイバー統括室の注意喚起（令和８年１１月５日）と緊急対策パッケージで整理している。

個人情報保護法上の安全管理措置義務，現行ガイドライン，将来改正の予告及びMFA・EDR等の技術上の手法例は，根拠と時点を分けて検討する。
具体策は，取り扱う情報の性質，件数，システム構成，事業規模，委託関係及び当時の技術水準に応じて選ぶ。

第３　最初に情報と法的関係を分類する

１　個人情報だけを見ない

初動では，氏名や連絡先を含む個人情報だけでなく，要配慮個人情報，決済情報，認証情報，営業秘密，契約上の秘密，顧客から預かった資料，マイナンバー，知的財産及び業務継続に必要なデータを分類する。
同じファイルでも，個人情報保護法，番号法，不正競争防止法，秘密保持契約，委託契約及び業法上の義務が重なることがある。

２　自社，委託元，委託先及びクラウド事業者の役割を固定する

クラウド又は委託先で事故が起きても，自社の本人通知，行政報告，契約通知及び顧客対応が当然に不要になるわけではない。
平時の契約では，事故の定義，第一報の期限，提供すべきログと事実，調査協力，証拠保全，再委託，費用負担及び対外公表の調整方法を確認する。

事故発生後は，事実を知らないまま責任の押し付け合いをしないよう，意思決定者，技術調査担当，法務担当，広報担当及び外部専門家の連絡線を一本化する。

第４　平時に整える六つの備え

１　情報資産・システム・委託先の台帳

どの情報を，何の目的で，どこに，いつまで保存し，誰がアクセスできるかを一覧にする。
サーバー，SaaS，クラウドストレージ，VPN，API，バックアップ，個人端末及び委託先を含め，契約名と実際のデータの流れを一致させる。
ルーター，防犯カメラ，録画機及び複合機も確認対象とし，保存データ，管理者，更新担当，外部から接続できる機能及びサポート終了日を記録する。
防犯カメラの画角や録音と機器の管理は，店舗・法律事務所に防犯カメラを設置するときを参照されたい。

保存期間を過ぎた不要データを削除すれば，漏えい時の対象人数と被害範囲を小さくできる。
法定保存義務，訴訟・監査上の必要性，利用目的及び削除の証跡を情報区分ごとに確認する。

飲食店の会員アプリや予約システムでは，予約の確定，順番の通知，販促，問い合わせ対応を分け，機能ごとに必要な取得項目と保有期間を決める。
ゆで太郎システムは，バースデークラブを終了すると発表し，最後のクーポン発送後に対象の個人情報を消去する方針を公表した。
物語コーポレーションは，公式アプリ会員管理システムへの不正アクセスによる個人情報漏えいを受け，焼肉きんぐを含むグループが運営する計１１の公式アプリで氏名と電話番号を保持しない仕組みへの変更を令和９年上半期に予定しており，予約機能等のためメールアドレスの取得は継続する予定としている。

入力欄を減らす場合は，旧システム，委託先及びバックアップに残るデータも棚卸しする。
項目，目的，保存先，削除の起算点，保存が必要な場合の理由及び削除の確認方法を記録しておけば，移行後に残存範囲を確認しやすい。
個人情報保護法２２条は，利用する必要がなくなった個人データを遅滞なく消去するよう努めることを求めており，個人情報保護委員会の通則編３－４－１は，保存期間の設定等により個人データを正確かつ最新の内容に保つよう努めることも求めている。

暗号への将来的な影響を検討するためには，自社で情報を保存する期間に加え，外部に知られては困る期間を整理する方法が考えられる。
長期間秘密を守る必要がある情報については，通信・保存・鍵の受渡し・電子署名のどこで暗号を使っているか，更新に誰が関わるかも確認する。
これは将来の暗号移行に備える実務上の提案であり，保存不要な情報を長期間残すという提案ではない。

金融庁が事務局を務めた検討会の預金取扱金融機関の耐量子計算機暗号への対応に関する検討会報告書は，主として預金取扱金融機関を対象に，秘密を保持すべき期間や暗号の使われ方に応じた優先順位を検討している。
一般企業では，自社の業務・保有情報に合わせて参考にする。
暗号化データを今取得して将来解読する脅威と準備の考え方は，量子コンピューターで暗号は破られるのか―耐量子暗号と企業の備え（AI作成）で詳しく整理している。

２　権限・認証・ログ・バックアップ

権限は業務上必要な範囲に絞り，退職，異動，委託終了及び長期未使用のアカウントを速やかに見直す。
管理者権限，多要素認証，接続元制限，パッチ，API認可，ログの取得・保存・改ざん防止及びバックアップ復元試験を組み合わせる。

特定の製品名又は方式名を導入するだけで法的義務を果たしたことにはならない。
事故時に必要なログが残り，誰が確認し，異常を検知したときに連絡できるかまで運用を確認する。

外部サービスとの連携のため，自社環境へのアクセスを許可したアプリについても，利用目的，社内の管理責任者，アプリID，サービスプリンシパルID，付与権限，管理者同意，資格情報の管理主体及び契約終了時の失効手順を整理しておくとよい。
これらは委託先への質問を具体化するための点検項目であり，すべての項目が一律の法定台帳事項であるという趣旨ではない。

Microsoftの公式説明は，利用者に代わる委任アクセスと，アプリ自身のIDで行うapp-onlyアクセスを区別している。
利用者のMFA設定に加え，アプリ側の権限・資格情報・ログと，疑わしい接続を停止する担当及び復旧の判断手順を確認する。
ConnectWise事案を題材とする仕組みと点検事項は，Microsoft 365の外部アプリ権限と情報漏えい―ConnectWise事案から学ぶ点検事項で扱う。
公式仕様：https://learn.microsoft.com/en-us/entra/identity-platform/app-only-access-primer

３　社内規程と教育

電子メール，クラウド，生成AI，USB，私物端末，個人アカウント及びテレワークの利用条件を明確にする。
禁止事項だけでなく，誤送信又は不審な挙動に気付いた従業員が，評価や処分を恐れず速やかに報告できる窓口と報告項目を示す。

教育は年一回の受講記録だけで終わらせず，実際の業務で起こり得る誤送信，不審メール，アカウント乗っ取り及び委託先からの第一報を使って訓練する。

IT技術者の採用選考や転職活動を装う攻撃も，教育の具体例に加えるとよい。
警察庁等の令和８年９月１８日付共同注意喚起は，採用担当者を装って求職者に不正なコードを実行させる手口と，感染により本人だけでなく所属企業の情報が窃取される可能性を説明している。
会社の端末で採用課題のコードを実行した場合などに，相談をためらって初動が遅れないよう，速やかに連絡できる窓口を用意することが考えられる。

出典：警察庁等の共同注意喚起２～４頁。
手口と実行前・感染後の確認事項は，採用課題を装うWaterPlumの攻撃で整理している。

４　初動連絡網と判断票

夜間・休日を含む連絡先，代行順位，経営者へのエスカレーション基準及び外部専門家への連絡条件を決める。
個人情報保護委員会への報告要否，本人通知，警察・所管官庁・取引先への連絡及び対外公表を，誰がいつ判断するかを一枚の判断票にする。

技術上の警告を経営判断につなぐ記録を残す
平時の脆弱性の指摘や改善提案についても，技術担当者が受け取った段階から，誰に報告し，誰が実施又は延期を判断し，いつ再確認するかまで追跡できるようにしたい。警告内容，対象システム，想定被害，実施可能な対策，費用・停止の影響，代替措置，担当者及び期限を判断票に残し，対応完了を確認する運用が考えられる。

これは本記事の体制整備の提案である。警告を受けたという事実だけで，取締役等の義務違反や事故との因果関係が確定するわけではない。調査後に判明した事実と，当時知っていた又は確認できた情報も分けて整理する。

５　契約とサイバー保険

委託契約，クラウド利用規約，秘密保持契約及び顧客契約の事故通知条項を台帳化し，法令上の期限より短い契約期限がないかを確認する。
サイバー保険は，補償対象，免責，初動業者の指定，事前連絡，フォレンジック，休業損失及び広報費用の条件を確認する。

事故が起きる前の脆弱性対応についても，契約で役割を確認しておくとよい。
対象のシステム・機能，脆弱性情報を受け取る窓口，影響の調査，更新の実施者，暫定措置，修正後の確認及び費用を整理する。
通知した時点で対応完了とせず，受領，判断，実施及び確認の各段階に担当を置く。

SCS評価制度の★取得を契約条件とする場合は，要求する水準だけでなく，登録の有効期間と，本業務の対象システムが評価範囲に含まれるかを確かめる。
★の取得は制度上は任意であり，取得を取引条件にするかは当事者が決める。
評価を取得したことだけで，他の法制度の要件を満たすことまで保証されるものでもない。

制度資料が示す更新・是正の期限は，対象，起算点及び例外を含めて契約上の連絡・作業期限と対応付ける。
延期が必要な場合の理由，リスク低減策，承認者及び見直し日を記録し，取引先との協議が制度上の適合性の判断に代わると考えないことが重要である。
これらは，公式資料を踏まえて契約・運用を具体化するための提案であり，一律の法定契約事項ではない。
SCS評価制度を委託契約で使う際の確認事項は，SCS評価制度の契約実務―★３・★４の取得，脆弱性対応期限及び委託先管理で整理している。

出典：IPA「よくある質問」（SCS評価制度）Q１－３～Q１－５，SCS－６２０「★３・★４要求事項・評価基準解説書」６頁～１１頁・９２頁～９４頁。
公式FAQ
公式掲載ページ

委託先の法人名だけでなく，実際の作業者，端末の管理者及び再委託関係も確認したい。
警察庁等の令和８年９月１８日付共同注意喚起は，北朝鮮IT労働者が国内支援者の名義や遠隔操作用PCを利用する手口を紹介し，アクセス権を必要最小限に制限するよう呼び掛けている（５～６頁）。
また，取引相手や関係者が北朝鮮IT労働者である可能性を把握した場合は速やかな警察への相談を，外注先が北朝鮮IT労働者とみられる者又は悪意を持つ者である可能性を把握した場合は，速やかな業務アカウントやセッションの無効化を求めている（６頁）。

企業の契約・運用への落とし込みとしては，担当者・再委託先の変更連絡，事故の疑いを把握した段階での連絡，アクセス停止と記録保全への協力，再接続を認める判断者と条件を決めておくことが考えられる。
これらは本記事の実務上の提案であり，注意喚起にそのまま記載された契約条項ではない。
緊急のアクセス停止と，契約解除や報酬の支払拒絶が認められるかどうかは別に判断する。

出典：警察庁等の共同注意喚起５～７頁。
確認項目と公表事例は，北朝鮮IT労働者への業務委託を防ぐための対策を参照されたい。

身代金や情報公開を止める対価を要求された場合の支払前の法令確認，取締役の判断記録及び保険の確認事項は，ランサムウェアの身代金を要求されたら―支払い判断，役員責任，保険と証拠保全で整理している。

長期に使うクラウドや電子契約等の契約では，暗号方式の変更に関する情報提供，移行への協力範囲，費用負担，試験環境，停止等の影響及び既存データの取扱いを確認することも考えられる。
「耐量子暗号に対応」という説明が，通信，保存，署名又は一部の機能のどれを指すかを分け，事業者の回答日，対象範囲及び未定事項を残す。
これは本記事の契約・運用上の提案であり，既存契約に無償での移行対応義務が当然に含まれると断定するものではない。

６　机上訓練と更新

経営，法務，情報システム，広報，総務，人事及び主要委託先で，架空事案の第一報から公表までを机上訓練する。
訓練では，「誰が決めるか分からない」「契約期限を見落とした」「ログが取れない」「本人連絡先が古い」といった詰まりを記録し，期限を定めて是正する。

第５　発覚直後の初動

１　被害拡大防止と証拠保全を並行する

不正な通信，アカウント又は端末を隔離し，認証情報の停止・変更等によって被害拡大を防ぐ。
同時に，日時，発見者，端末，アカウント，IPアドレス，操作，画面，メール，ログ及び連絡内容を保全する。

フォレンジック対象となり得る端末は，専門家と調整する前に一律に電源断，再起動，初期化，更新又はウイルススキャンをすると，揮発情報や痕跡を失うことがある。
生命・身体の安全又は事業継続のため直ちに操作が必要な場合を除き，目的と影響を確認して記録する。

侵害の兆候がない段階の予防的な更新と，侵害が疑われる環境での証拠保全を区別する。
重大な脆弱性について更新が勧告された場合に，証拠保全への配慮を理由として，危険にさらされた環境の対応を一律に先送りすることは適切でない。
外部公開の制限，必要な記録の保全，修正及び再起動等の順序を，技術担当者及び必要な専門家と調整し，判断者，判断理由，対象，実施時刻，失われる可能性のある記録を残す。
これは危険と証拠への影響を調整する運用上の提案であり，全ての環境に同じ順序を義務付けるものではない。

PHP公式の令和８年１０月２１日付告知は，２件の重大脆弱性について，設定変更による緩和策には限界があり，修正を含む更新が必要であると説明している。
設定を変えたこと，サイトを復旧したこと又は修正を適用したことと，過去の侵害の有無を調査したことは分けて記録する。
出典：PHP「News Archive – 2026」。
https://www.php.net/archive/2026.php

２　確認済み事実，可能性及び不明を分ける

初動表には，発生日・発見日，対象システム，対象情報，対象人数，攻撃経路，外部送信の痕跡，利用不能又は改変，被害拡大防止措置，委託関係及び次の更新時刻を記載する。
「漏えいしたことを確認した」「アクセスされた可能性がある」「ログがなく判断できない」を分け，推測を確定事実として社内外へ伝えない。

３　関係者への連絡と守秘

経営者，法務，情報システム，広報，保険会社，外部フォレンジック，顧問弁護士及び委託先へ，必要な範囲で連絡する。
調査情報を広く共有すると二次漏えい又は証言の汚染を招くため，アクセス権と記録先を限定する。

第６　個人情報保護委員会への報告，本人通知及び公表

１　報告対象となる四つの類型

個人データの漏えい等が，要配慮個人情報，財産的被害が生じるおそれ，不正の目的による行為，又は本人の数が千人を超える事態に該当する場合，個人情報保護委員会への報告と本人通知が必要となることがある。
件数がまだ確定していなくても，対象データの性質とおそれを先に分類し，判断過程を記録する。

２　速報と確報

個人情報保護委員会は，報告対象事態を知った日から概ね三日から五日以内の速報を案内している。
確報は原則三十日以内であり，不正の目的をもって行われたおそれがある場合は六十日以内である。

速報の時点で全容が分からなくても，判明している事項を報告し，調査の進展に応じて続報又は確報を行う。
期限の起算点，知った主体，共同利用，委託関係及び報告先が不明な場合は，早期に法務確認を行う。

３　本人通知と対外公表は目的が異なる

本人通知は，本人がパスワード変更，カード停止又は不審連絡への注意など，被害を防ぐ行動を取れるようにするものである。
対外公表は，広く注意を促し，取引先，利用者，報道機関その他の関係者へ説明するために行う。

行政報告，本人通知及び対外公表は同じ文章を同じ時点で出す手続ではない。
法令，契約，業法，対象者への連絡可能性，二次被害の危険，捜査・調査への影響及び社会的影響を踏まえて別々に判断する。

基幹インフラの事業者として経済安全保障推進法の指定を受けている企業では，個人情報保護委員会への報告とは別に，重要電子計算機に対する不正な行為による被害の防止に関する法律５条により，所管大臣と内閣総理大臣への報告が必要になることがある。
関係省庁の申合せにより，同条の報告と個人情報保護法２６条１項の報告には共通の様式を使うことができるが，報告先と期限はそれぞれの法令で確認する。
同法の届出・報告の内容は，重要電子計算機防護法とはで整理している。

第７　信頼を損なわない対外説明

１　最初の発表で断定し過ぎない

初報では，確認した事象，発見日，対象となり得る情報，実施済みの被害拡大防止，利用者が取るべき行動，問い合わせ先及び次回更新予定を示す。
調査中の事項は調査中と書き，「現時点で確認されていない」を「発生していない」と言い換えない。

政府の「サイバー攻撃被害に係る情報の共有・公表ガイダンス」（令和５年３月８日）も，第一報や調査途中の公表で不確実な情報を確定情報のように伝えると誤解を与えるケースがあることを留意点に挙げ（Ｑ１７，印刷７６頁），第一報の段階で機微な情報の漏えい被害はないと公表した後の調査で漏えいが判明したケースもあると指摘している（印刷７８頁～７９頁）。
調査の段階とログの有無に応じた書き分けは，「現時点で漏えいの事実は確認されていない」と公表してよいか―調査段階・ログの有無で変わる書き方と個人情報保護法の「おそれ」で整理している。

対外説明では，確認した漏えい，漏えいの可能性及び調査不能を分けるほか，対象件数がデータ行，アカウント，契約又は本人のいずれを数えたものかを示す。
流出した可能性のある全項目と，本人ごとに対象となった項目が異なる場合は，その違いも明記する。
認証情報が対象となる事案では，確認できた範囲で保存方式を説明し，未確認なら未確認とし，パスワードのリセットが予定，実施中又は完了のどの段階かを統一して表示する。

ソースネクスト株式会社の令和８年１０月１５日の公表は，対象件数２２５１万９９６０件と流出した可能性のある全項目を示す一方，全会員について全項目が対象となったわけではないと説明している。
同日の公表ページはログイン時の再設定を求める措置を記載し，FAQはリセットを順次実施すると記載している。
公表ページ，FAQ，個別通知及び実際の画面で表現又は進捗が変わる場合は，更新日と変更点を示し，利用者が現在取るべき行動を一つにそろえる必要がある。

２　更新履歴を残す

新しい事実が判明した場合は，過去の発表を黙って書き換えず，更新日と変更点を示す。
対象人数，情報項目，原因又は再発防止策が変わったときは，なぜ変わったかを説明する。

３　再発防止策を抽象語で終わらせない

「管理を徹底する」「教育を強化する」だけでなく，権限の縮小，保存期間の見直し，ログの追加，委託先監督，復元試験，連絡体制及び訓練の改善を具体化する。
もっとも，防御上公開できない設定又は調査中の事実まで明らかにする必要はなく，説明可能性と安全性を調整する。

第８　情報漏洩と企業法務に関するよくある質問

１　情報漏洩を防ぐ三原則は何ですか

対象情報を必要最小限にすること，アクセスできる人と権限を必要最小限にすること，異常を検知して直ちに対応できるようにすることが基本である。
これらをデータ台帳，認証・権限，ログ，教育，委託先管理及び初動訓練へ具体化する。

２　情報漏洩の原因一位は何ですか

一律の「原因一位」はない。
行政への報告，公表事案，社内インシデント又はサイバー攻撃など，調査対象と分類方法によって誤送信，紛失，不正アクセス，設定不備，内部不正等の順位が変わる。

３　情報漏洩で会社はどのような責任を負いますか

個人情報保護法上の行政対応だけでなく，契約責任，不法行為責任，委託先監督，営業秘密管理，業法上の報告及び役員の内部統制が問題となり得る。
責任の有無と範囲は，情報の内容，原因，予見可能性，防止措置，初動，被害及び契約により個別に判断される。

４　会社で情報漏洩が起きたら最初に何をしますか

被害拡大防止，証拠保全，事実確認及び社内エスカレーションを並行し，個人情報保護委員会への報告要否と契約上の通知期限を確認する。
端末を一律に初期化し，原因不明のまま「漏えいなし」と発表することは避ける。

５　従業員が漏えいさせたら直ちに解雇できますか

故意・過失，情報の重要性，漏えい範囲，職務，社内規程，教育，過去の処分例及び本人の対応を確認せず，直ちに懲戒解雇できるとは限らない。
証拠保全と被害対応を先行し，就業規則と処分の相当性を個別に検討する。

６　生成AIへ社内情報を入力することは情報漏洩ですか

入力しただけで常に法的な漏えいになるとは限らないが，入力する情報，利用目的，権限，契約及び社内規程を確認する必要がある。
「AIに入力してはいけない情報は何か」という実務上の問いには，パスワード・APIキー，顧客・依頼者の個人情報，未公表の契約・事件情報などを，取扱条件と入力する権限を確認せず送信しないことが基本となる。
氏名を消しただけで，ほかの記載から個人や事件を特定できる場合もあるため，形式的な伏字だけで安全と判断しない。

個人情報保護委員会の令和５年６月２日の注意喚起は，個人情報取扱事業者が個人情報を含む入力を行う場合に，特定された利用目的を達成するために必要な範囲内であることを十分に確認するよう求めている。
また，あらかじめ本人の同意を得ずに個人データを入力し，回答の出力以外の目的で取り扱われる場合は，法違反となる可能性があるとして，機械学習に利用しないこと等の十分な確認を求めている（PDF２頁（１））。
出典：https://www.ppc.go.jp/files/pdf/230602_alert_generative_AI_service.pdf

学習不使用という表示だけで全ての確認を終えず，入力・出力の保存期間，削除，人的アクセス，再委託，国外処理及びコネクタによる転送先を確認するとよい。
これはサービスの契約・設定を点検する実務上の提案であり，PPCの同注意喚起がこれら全項目を一律の法定義務として列挙しているという意味ではない。
会社が承認した環境，入力禁止情報，必要最小限の加工，ログ及び例外承認の手続を定め，利用条件を確認できない情報は入力を見合わせる。

７　情報漏洩の公表は必ず必要ですか

すべての事案について一律に一般公表が法律上義務付けられているわけではない。
行政報告，本人通知，契約通知，業法上の公表及び任意公表を分け，二次被害防止と説明責任から判断する。

８　法務部門だけで準備できますか

法務部門だけでは，ログ，ネットワーク，復旧及び原因調査を完結できない。
経営，情報システム，広報，総務，人事，監査，主要委託先，保険会社及び外部専門家の役割を平時に決める必要がある。

第９　企業法務の確認チェックリスト

平時には，情報・システム・委託先台帳，保存期間，権限，ログ，バックアップ，契約通知期限，緊急連絡網，判断票，対外説明ひな形及び机上訓練の記録を確認する。

発覚当日は，発見日時，確認済み事実，被害拡大防止，証拠保全，対象情報・人数，委託関係，行政・契約上の期限，経営報告，問い合わせ窓口及び次回更新時刻を確認する。

その後は，原因と影響の調査，速報・確報，本人通知，取引先対応，公表の更新，再発防止策，保険請求，費用記録及び取締役会・監査への報告を管理する。

脆弱性が関係する場合は，対応表を「修正適用の確認」と「侵害・影響の調査」に分けるとよい。
前者には対象環境，適用内容，時刻，必要な再起動等，確認者及び未対応対象を記載し，後者には調査期間，対象ログ，確認された操作，対象情報，未判明事項及び法務判断の担当を記載する。
修正適用が完了しても，過去の侵害不存在が確認されたことにはならず，漏えい等の報告や本人通知の検討を当然に終了するものではない。

個人情報保護委員会が示した不正アクセス９類型―API，クラウド，グループ会社，個人領域及びログ管理は，令和８年１０月の注意喚起を技術・運用別に整理している。

「情報漏えいゼロ」は安全の証拠かは，事故件数，検知率及び報告件数の読み方を扱っている。

クラウド事業者がランサムウェア被害に遭った場合の利用者側の報告義務は，委託・クラウド事故における利用者側の役割を扱っている。

タイムズカー約６６０万アカウントの個人情報漏えいから考える本人通知は，本人通知と公表の実例を扱っている。

シャドーITによる情報漏えいを防ぐにはは，私物サービス，USB及び個人メールの管理を扱っている。

個人情報漏えい等の通知を受けたときに本人が確認することは，通知を受けた側の初動を扱っている。

個人情報保護法の安全管理措置は機密性に偏っているかは，機密性，完全性及び可用性の均衡を扱っている。

IT関係メモは，法律事務所の情報セキュリティ関連記事への索引である。

重要電子計算機防護法とはは，基幹インフラ事業者の届出・報告義務と，警察・自衛隊によるアクセス・無害化措置を扱っている。

令和８年改正個人情報保護法対応の委託契約，クラウド利用契約及び生成AI利用契約は，契約条項とデータフローの確認を扱っている。

広く弱点を探す攻撃と個別のシステムを狙う攻撃の関係，AIによる効率化及び企業の対策は，AIを悪用した無差別サイバー攻撃とは―仕組みと企業の対策（AI作成）で整理している。

SCS評価制度の契約実務―★３・★４の取得，脆弱性対応期限及び委託先管理は，SCS評価制度の★取得を委託契約で求める場合の確認事項を扱っている。