退職者アカウント放置のサイバーリスク

退職者のビジネスチャットアカウントやクラウドサービス権限が適切に無効化されないまま放置されると、情報漏洩や不正アクセスの入口になります。社内の管理ミスが原因で発生するインシデントは、外部からのサイバー攻撃に比べて見過ごされやすいと現場では指摘されており、被害が起きてからではサイバー保険でも対応が難しいケースが少なくありません。

退職者アカウントが残っていることに気付いていない企業は珍しくありません。年間数名から十数名の入退社がある中小企業ほど、ChatworkやSlack、Microsoft Teams、Google Workspaceなど複数のクラウドサービスを横断的に管理する仕組みが整っておらず、停止漏れが日常的に発生しています。半年前に退職した社員のアカウントが、今もプロジェクトの機密チャットにアクセスできる状態だった、という発覚はそれほど珍しいものではありません。

退職者のチャットアカウント放置による情報漏洩や不正アクセスは、外部からの攻撃に比べて見落とされやすい領域です。本人による不正利用と第三者の乗っ取り、両方のリスクが重なり、ずさんな管理体制と判断されればサイバー保険の補償対象外となる可能性もあります

この記事では、サイバーリスクの法人コンサルティングを担当する平涼太へのインタビューをもとに、退職者アカウント放置で実際に起きているトラブル、サイバー保険の補償可否の境界線、そして中小企業でも明日から取り組めるID管理の整備手順を解説します。総務・人事担当者と情報システム部門が連携してチェックする際の指針として活用いただける構成です。

退職者アカウント放置で起きるインシデントの実態

退職者アカウントの管理不備が原因で起きるインシデントは、メディアで大きく報道されるサイバー攻撃と比べて表面化しにくい性質があります。社内のミスが起点になっているため公表が控えられ、被害の全体像が見えづらいまま、各社で似たトラブルが繰り返されている状況です。

実際にあった事例として多いのが、退職者のアカウントにオーナー権限が残ったままだったために、退職後に勝手にグループを削除されてしまうトラブルです。共有していたスプレッドシートの権限が退職者個人のアカウントに紐づいたまま放置され、後日アカウント自体を削除した際に、共有データごと消えてしまうといったケースも報告されています。

退職者アカウント関連のインシデントには、大きく分けて2つのリスクがあります。1つは退職者本人による不正利用、もう1つは第三者によるアカウント乗っ取りです。本人が悪意を持っているとは限らず、操作ミスやアカウントの整理過程で意図せず社内データを消してしまうこともあります。

退職者アカウント問題は「サイバー攻撃」というよりも「内部統制の不備」という位置づけになります。攻撃者が外から狙ってくる前に、自社のミスでデータが消える、もしくは漏れる構造を放置していないかを点検することが先決です。

メールは止めるのにチャットを忘れる構造的な理由

退職者対応で「メールアカウントは止めたが、Chatworkはそのままだった」という事象が頻発しています。メールには長年の運用フローがある一方、ビジネスチャットは比較的新しいツールであり、社内の停止プロセスに組み込まれていないケースが多いためです。

GoogleWorkspaceやMicrosoft 365のようなIDaaSで一元管理されているサービスは、メインアカウントを止めれば連動して止まる仕組みになっているのが一般的です。一方、Chatwork・Slack・Notion・Boxなど個別契約のSaaSは、それぞれの管理画面でアカウントを無効化する必要があり、停止忘れが発生しやすくなっています。

退職時のチェックリストが「PC回収」「IDカード返却」「メール停止」までしか定義されていない企業では、SaaSの数が増えるほど停止漏れリスクが拡大します。次のような構造が、停止忘れを生みやすい典型パターンです。

• IT部門と総務部門の役割分担が曖昧で、SaaSアカウント停止の責任所在が不明確
• SaaSの契約担当者が部署ごとに分散し、退職時に全社横断で見直す仕組みがない
• アカウント情報を管理するスプレッドシートが古く、新規導入したSaaSが反映されていない
• 退職者の引き継ぎを優先する間に、アカウント停止のチェックが後回しになる

退職者のアカウント停止は、本人のセキュリティ意識やITリテラシーとは関係なく発生する管理プロセスの問題です。仕組みを整備しないまま個人の注意に頼ると、人事繁忙期には停止漏れが発生しやすくなります。

メール停止に長年の運用が定着している企業ほど、ビジネスチャットや新興SaaSへの対応が遅れがちです。新しく導入するSaaSを契約する段階で、退職時の停止プロセスもセットで設計しておくと、のちの停止漏れを未然に防げます。

退職者アカウントが乗っ取りの入口になるメカニズム

退職者アカウントは、放置されているだけで乗っ取りリスクが時間とともに高まっていきます。退職後にパスワード変更が行われない、二段階認証が解除されたままになるなど、本人すら使わないアカウントは攻撃者にとっては格好の標的になります。

攻撃者の視点では、退職者アカウントは次のような特徴が魅力的に映ります。

• アクティブな本人がいないため、不審ログイン通知に気付かれにくい
• 二段階認証が未設定のままになっているケースが多い
• 過去のチャット履歴や共有ファイルから、社内の人間関係や業務プロセスを把握できる
• 取引先のチャットグループに残っており、なりすまし詐欺の踏み台にできる

退職者アカウントから侵入された場合、攻撃者は退職者本人になりすまして社内に潜伏できます。社内の業務フローや決裁ルートを把握したうえで、適切なタイミング（決算期や長期休暇直前など）に振込指示や情報抜き取りを行うため、被害の発見が遅れる傾向があります。

ビジネスチャットの場合、本人になりすました攻撃者が「久しぶりに復帰しました」と挨拶を装って社内に再登場することもあります。退職前のやり取り履歴がそのまま残っているため、文体や呼びかけ方を真似しやすく、社内のメンバーが違和感に気付きにくい構造があります。

加えて、外部の取引先とのチャットグループに退職者アカウントが残っていると、対外的な信頼関係まで悪用されかねません。取引先の経理担当者にとって「いつもの連絡相手」が偽の振込指示を出してきた場合、本人確認なしに送金してしまう被害も想定されます。

退職者アカウント管理の不備はサイバー保険でどこまで補償されるか

サイバー保険を契約していても、退職者アカウント放置による被害は補償対象になるとは限りません。事故対応費用や情報漏洩対応費用そのものは補償対象に含まれる設計が一般的ですが、被害発生の原因が「ずさんな管理体制」と判断されると、免責事項が適用される可能性があります。

サイバー保険の補償可否を分けるポイントは、被害原因が「外部からの予測困難な攻撃」だったか、それとも「自社の管理プロセスの欠如」だったかです。一般的に、サイバー保険は前者の事故に備える商品設計になっています。退職者アカウント管理の不備は内部統制上の問題であり、保険会社にとっては「予防可能だったリスク」と評価されることが多くなります。

補償対象になり得る費用としては、情報漏洩発覚時のフォレンジック調査費用、被害者への通知費用、コールセンター開設費用、再発防止のためのコンサルティング費用などが挙げられます。これらは保険会社や契約内容によって範囲が異なるため、加入前にサイバー保険の調査・復旧費用補償も合わせて確認しておくと安心です。

退職者アカウント関連の被害でサイバー保険を活用したい場合は、加入時に「内部不正リスク」「アカウント管理不備に起因するリスク」が特約や本体補償に含まれているかを確認してください。商品によっては、内部統制要件を満たしていることが補償の前提条件として明記されているケースもあります。

退職時に停止すべきアカウント・権限のチェック項目

退職者対応で停止漏れを防ぐには、退職時チェックリストの粒度を上げることが効果的です。メール停止やPC回収だけでなく、SaaS別の停止項目を網羅することで、運用品質が安定します。

退職時に確認すべき主要なチェック項目を整理すると次のとおりです。

• メールアカウントの停止と転送設定の解除
• ビジネスチャット（Chatwork、Slack、Microsoft Teamsなど）のアカウント無効化
• クラウドストレージ（Google Drive、Dropbox、Boxなど）のアクセス権限剥奪
• 共同編集ツール（NotionやFigmaなど）のメンバー削除
• グループウェアのオーナー権限の他メンバーへの引き継ぎ
• VPN・社内システムへのアクセス権剥奪
• スマホ用MDM（モバイルデバイス管理）からの端末除外
• SaaSのSSO設定上のユーザー無効化
• 取引先・顧客向けの共有チャネルからのメンバー削除

特に注意したいのが、オーナー権限の引き継ぎです。退職者がチャットグループや共有ドライブのオーナーになっている場合、本人のアカウントを削除する前にオーナー権限を別の在籍メンバーに移譲しておく必要があります。順序を間違えるとデータが消失するリスクがあるため、停止前に「オーナー権限の有無」を確認するステップを設けておくのがおすすめです。

加えて、退職者が個人で導入した（シャドーIT気味の）SaaSも見落としがちです。法人クレジットカードや経費精算の履歴をたどり、契約しているがIT部門に共有されていなかったSaaSがないか確認しておくと、後日「退職者しかアクセスできないツール」が発覚するトラブルを避けられます。

停止対象	主な確認方法	抜け漏れリスク
メール・PC	既存の退職フローで対応	比較的低い
主要SaaS	IT管理者がIDaaS経由で一括停止	中程度（SSO未連携で漏れ）
部門別SaaS・委託先	部署主導の運用が必要	高い（属人化しやすい）

中小企業でも整備できるID管理・アクセス管理の進め方

退職者アカウント問題に限らず、ID管理・アクセス管理の体系化は中小企業のサイバーリスク全般にとって基礎となる取り組みです。専任のセキュリティ担当者がいなくても、段階的に整備することで現実的なレベルまで引き上げることができます。

整備の進め方は次のような3ステップが目安になります。

• ステップ1: 利用しているSaaSを棚卸しして一覧化する
• ステップ2: 退職時チェックリストにSaaS別の停止項目を追加する
• ステップ3: SSOやIDaaSの導入で、停止操作を一元化する

ステップ1の棚卸しでは、契約しているSaaSと利用ユーザー数、管理者アカウント、契約形態を表にまとめます。経理の支払い履歴と、IT管理者が把握している管理画面の情報を突き合わせることで、シャドーITも含めて全体像が見えるようになります。

ステップ2では、棚卸しで出てきたSaaSごとに退職時の停止手順を追記します。アカウント停止だけでなく、共有データの所有権移譲、外部連携の解除、APIキーの失効なども項目に含めます。チェックリストはテンプレート化しておき、退職者が出るたびに使い回せる状態にしておきます。

ステップ3では、Google WorkspaceやMicrosoft Entra ID（旧Azure AD）などのIDaaSを軸に、各SaaSのSSO連携を順次進めます。SSO化が進めば「IDaaS側でユーザーを無効化すれば連動する各SaaSへのアクセスも止まる」状態に近づき、退職時の停止作業が大幅に省力化されます。

ID管理を整備する過程では、社内ルールの整備も重要になります。アカウント発行・変更・停止の申請フロー、権限レベルの定義、定期的な棚卸しの頻度などをドキュメント化しておくと、担当者が変わっても運用が継続しやすくなります。

退職者対応を組織的に運用するためのポイント

退職者アカウント管理の整備は、IT部門だけで完結するものではありません。人事・総務・各部門のマネージャーが連携して運用することで、初めて停止漏れのない体制が機能します。組織的に運用するための4つのポイントを押さえておきましょう。

• 退職決定時から退職完了まで、IT部門への通知タイミングを明確化する
• 退職者本人による業務引き継ぎと、アカウント停止のスケジュールを分けて管理する
• 部門マネージャーが「自部署で利用しているSaaSの一覧」を保有し、IT部門と共有する
• 退職後30日・90日のタイミングで、停止漏れがないか再点検する

ビジネスチャット上でのなりすましによる送金被害は、Chatworkを運営する株式会社kubellも2026年1月に注意喚起を公表しており、実際に発生している手口です（Chatwork上でのなりすまし詐欺にご注意ください（株式会社kubell））。被害の実例を社内に共有する際の参考情報として活用できます。

退職予定者本人とのコミュニケーションも重要です。退職日が決まった段階で「退職前に行う引き継ぎ」と「退職後に発生するアカウント停止作業」を明確に伝えておくことで、退職者本人もスムーズに業務移行できます。アカウント停止は退職者にとって不利益な扱いではなく、組織を守るための標準プロセスであることを共有しておくと、運用への理解が得やすくなります。

定期的な棚卸しも欠かせません。退職後30日・90日のタイミングで、SaaSのアクティブユーザー一覧と人事の在籍者一覧を突き合わせる運用を入れることで、見落としていた停止漏れに後から気付ける体制になります。年に1度は全社のSaaS棚卸しを実施し、契約サービスの追加・廃止に応じてチェックリストを更新します。

退職者管理を含む包括的なセキュリティ対策については、中小企業向けサイバー保険入門やセキュリティ優先度の判断基準も合わせて参考にしてください。

退職者アカウント問題で見落としがちな3つの盲点

退職時のアカウント停止に取り組み始めた企業でも、見落としやすい3つの盲点があります。チェックリストを更新する際の参考として、改めて確認しておきたい項目です。

• 業務委託先・派遣社員のアカウント停止が漏れがち
• 退職者がオーナーになっている外部共有リンクの失効忘れ
• 退職者個人のスマホに残ったSaaSアプリのログイン状態

業務委託先や派遣社員のアカウント管理は、契約終了の連絡が人事から情報システム部門に伝わらない構造になっていることが多く、停止のきっかけ自体が発生しない問題があります。委託契約書に「契約終了時のアカウント停止プロセス」を明記しておく、契約管理システムと連携してアラートを出す運用にしておくなどの工夫が有効です。

外部共有リンクの失効忘れは、退職者がGoogleドライブやBoxで取引先に共有したファイルのURLが、退職後もアクティブなままになっているケースを指します。共有リンクは本人のアカウントとは独立して動作するため、アカウント停止だけでは無効化されない仕組みです。SaaSの管理画面から「組織外との共有リンク一覧」を定期的に棚卸しすることで、停止漏れを発見できます。

3つの盲点はいずれも、退職者本人や外部関係者の協力が必要な領域です。社内のIT管理だけで完結しないため、契約管理・委託先管理・外部共有管理など、ガバナンス全体を見直す機会としても有効に活用できます。

平時にやっておくべき準備と、有事の対応フロー

退職者アカウント管理は、平時の整備が9割、有事の対応が1割といえる領域です。それでも「停止漏れによるインシデントが発覚したとき」の動き方を事前に決めておくと、混乱を抑えやすくなります。

平時にやっておくべき準備としては、次のような項目が挙げられます。

• SaaS別の退職時チェックリストの整備と、定期的な見直し
• IDaaS・SSOの導入による停止作業の一元化
• 業務委託先・派遣社員も含めた契約終了プロセスの統一
• 退職者リストとSaaSアクティブユーザーの定期突合
• サイバー保険の加入と、補償範囲の事前確認

有事の対応フローでは、「停止漏れに気付いた瞬間に何をするか」を整理しておきます。

• 該当アカウントの即時無効化と、ログイン履歴の確認
• 該当アカウントから操作されたデータ・グループの洗い出し
• 必要に応じてフォレンジック調査会社への相談
• サイバー保険の事故対応窓口への連絡
• 取引先や顧客への通知が必要かの判断と、初期対応

不正アクセス禁止法に基づき、他人の識別符号を不正に使用したアクセスは違法行為とされており、退職者本人が在職中の権限で不正アクセスを行った場合も処罰対象になり得ます。

不正アクセス行為の禁止等に関する法律（警察庁）

退職者本人による不正アクセスは、サイバーセキュリティの問題であると同時に法的問題でもあります。被害が判明したら、警察への相談・顧問弁護士への連絡を含めた対応を検討する必要があります。証拠保全のためにも、ログを保存したまま運用を進めることが大切です。

退職者アカウント管理を継続するための社内浸透のコツ

仕組みを作っても、運用に乗らなければ効果は出ません。退職者アカウント管理を社内に浸透させるには、IT部門だけが頑張るのではなく、経営層・人事・現場マネージャーを巻き込んだ運用設計が重要です。

浸透を進めるためのコツとして、次のような取り組みが効果的です。

• 経営層に対して「停止漏れによる損失リスク」を金額換算で説明し、優先度を共有する
• 退職時のチェックリスト運用を人事評価項目に組み込み、抜け漏れに対する責任を明確にする
• 半期に1回、退職者対応の振り返り会を開催し、改善点を共有する
• 新しいSaaSを導入する際の稟議に「退職時の停止プロセス」を必須項目として含める

経営層への説明資料を作る際は、Chatwork上でのなりすまし詐欺にご注意ください（株式会社kubell）のような、サービス提供元が公表している注意喚起を引用元として使うと説得力が増します。

社内浸透にあたっては、退職者本人の協力が得やすい雰囲気を作ることも大切です。退職時にアカウントを停止することは、退職者を信用していないからではなく、組織として標準的に行っているプロセスである、というメッセージを丁寧に伝えると、引き継ぎ時の協力度が変わります。

加えて、退職者管理を含む内部統制の取り組みは、サイバー保険の加入条件として求められるケースも増えています。保険会社側の引受基準が厳しくなる中で、「ID管理体制が整っているか」「退職時の停止プロセスがあるか」といった項目が事前審査で問われることもあるため、平時から整備を進めておく価値があります。

よくある質問