退職者のアカウント削除を徹底する!IT管理者向け退職時チェックリスト
退職者のアカウント、ちゃんと消していますか?——放置が招くセキュリティ事故
「退職した社員のアカウント、まだ生きてるかも……」
そう思ってドキッとした方は、決して少なくないはずです。
IPA(情報処理推進機構)の「情報セキュリティ10大脅威」では、内部不正による情報漏洩が毎年上位にランクインしています。そして、退職者のアカウントが残っていることは、この内部不正を引き起こす最大のリスク要因のひとつです。
実際に起きている事例を見てみましょう。
- 退職した元社員が、残っていたVPNアカウントで社内ネットワークに不正アクセスし、顧客情報を持ち出した
- 退職者のGoogle Workspaceアカウントが削除されず、共有ドライブの機密資料に半年間アクセスできる状態だった
- SaaSツールのライセンスが退職者分も課金され続け、年間数十万円のコストが無駄になっていた
こうした問題は、大企業だけの話ではありません。むしろ、IT担当者が一人しかいない「ひとり情シス」の中小企業ほど起きやすい問題です。担当者が日々の業務に追われ、退職時の対応が後回しになる。マニュアルがなく、何を消せばいいか担当者の頭の中にしかない——これはまさに属人化の典型です。
そして最も怖いのは、アカウントを管理していたIT担当者自身が退職したときです。退職処理のやり方を知っている唯一の人がいなくなれば、何のアカウントが存在するのかすら把握できなくなります。これが退職リスクの本質です。
「うちは大丈夫」が一番危ない——アカウント削除漏れの実態
「退職時にはちゃんと対応しているつもり」という会社でも、実態を調べると驚くほど漏れがあるものです。
以下のような状況に心当たりはありませんか?
- 退職処理の手順がドキュメント化されていない(担当者の記憶頼み)
- SaaSツールの契約一覧が存在しない(部署ごとに勝手に導入している)
- 退職者のメールアドレスが転送設定のまま残っている
- 共有アカウント(admin@やinfo@)のパスワードが退職後も変更されていない
- 退職月のSaaSライセンス費用が変わっていない(=削除されていない証拠)
一つでも当てはまるなら、それは「対応できている」のではなく、たまたま事故が起きていないだけです。
特にひとり情シスの環境では、退職対応はIT担当者にとって「割り込みタスク」です。通常業務に加えて突然発生し、しかも退職日までの限られた時間で完了させなければなりません。手順が整備されていなければ、漏れが生じるのは当然です。
さらに厄介なのは、アカウント削除漏れは発覚しにくいということ。退職者がアクセスしなければ問題は表面化しません。しかし、それは「安全」なのではなく、爆弾の導火線がまだ燃えていないだけです。
属人化した退職処理は、退職リスクそのものです。担当者が代わった瞬間、過去の対応履歴も、対象アカウントの一覧も、すべてが失われます。
この記事でわかること——退職時のアカウント削除を「仕組み」で徹底する方法
この記事では、IT管理者が退職時に確実にアカウント削除を行うための実践的なチェックリストと、それを属人化させない仕組みづくりの方法を解説します。
具体的には、以下の内容をカバーします。
- 退職時に削除・対応すべきアカウントの完全チェックリスト
- 削除漏れを防ぐための運用フローの作り方
- ひとり情シスでも実践できるアカウント台帳の整備方法
- 退職リスクに備える引き継ぎの仕組み化
「担当者が変わっても、退職処理の質が落ちない」——そんな状態を目指しましょう。
退職時アカウント削除の仕組み化
退職時アカウント削除 完全チェックリスト
ここからは、退職時に対応すべき項目をカテゴリ別のチェックリストとして整理します。自社の環境に合わせてカスタマイズし、そのまま運用に使える形を目指してください。
カテゴリ1:メール・コミュニケーションツール
退職者のアカウントで最も急ぎの対応が必要なのが、メールとチャットツールです。これらは退職後も外部からの連絡が届き続けるため、放置すると情報漏洩リスクが高まります。
| 対応項目 | 詳細 | 期限目安 |
|---|---|---|
| メールアカウント無効化 | Google Workspace / Microsoft 365 のアカウント停止 | 退職日当日 |
| メール転送設定 | 必要な場合、後任者への転送を設定(期限付き) | 退職日当日 |
| メーリングリスト除外 | 所属していたML・配布グループから削除 | 退職日当日 |
| チャットツール無効化 | Slack / Teams / Chatwork のアカウント停止 | 退職日当日 |
| チャットチャンネル確認 | 退職者がオーナーのチャンネルの権限移譲 | 退職3日前 |
← 横にスクロールできます →
ポイント: メールアカウントは「削除」ではなく、まず「停止(サスペンド)」にしましょう。過去のメールデータが必要になるケースがあるため、一定期間(3〜6ヶ月)はデータを保持し、その後に完全削除するのが安全です。
カテゴリ2:クラウドサービス・SaaS
近年、最も漏れやすいのがこのカテゴリです。部署やチームが独自に導入したシャドーITが存在する場合、IT管理者が把握していないアカウントが残り続けるリスクがあります。
| 対応項目 | 詳細 | 期限目安 |
|---|---|---|
| グループウェア | Google Workspace / Microsoft 365 のライセンス解除 | 退職日当日 |
| クラウドストレージ | Google Drive / OneDrive / Dropbox のデータ移行と削除 | 退職3日前 |
| プロジェクト管理ツール | Backlog / Notion / Asana / Jira のアカウント削除 | 退職日当日 |
| CRM・SFA | Salesforce / HubSpot / kintone のアカウント削除 | 退職日当日 |
| 会計・経費精算 | freee / マネーフォワード / 楽楽精算 のアカウント削除 | 退職日当日 |
| デザイン・開発ツール | Figma / GitHub / AWS のアカウント削除・権限剥奪 | 退職日当日 |
| Web会議 | Zoom / Google Meet の有料ライセンス解除 | 退職日当日 |
← 横にスクロールできます →
ポイント: 「うちの会社で使っているSaaSの全リストが存在しない」という状態こそが最大のリスクです。まずは**SaaS台帳(アカウント台帳)**を作ることが、チェックリスト運用の大前提になります(後述)。
カテゴリ3:社内システム・インフラ
社内ネットワークやサーバーへのアクセス権は、不正アクセスに直結するため、確実に対応する必要があります。
| 対応項目 | 詳細 | 期限目安 |
|---|---|---|
| Active Directory / LDAP | ドメインアカウントの無効化 | 退職日当日 |
| VPN | VPNアカウントの削除・証明書の失効 | 退職日当日 |
| リモートデスクトップ | RDP接続権限の削除 | 退職日当日 |
| ファイルサーバー | 個人フォルダのバックアップと権限削除 | 退職3日前 |
| 業務システム | 基幹システム・ワークフローのアカウント無効化 | 退職日当日 |
| Wi-Fi | 社内Wi-Fiの認証情報変更(共有パスワードの場合) | 退職日当日 |
← 横にスクロールできます →
ポイント: VPNアカウントの放置は、退職後のリモートからの不正アクセスを可能にする最も危険な項目です。退職日当日の対応が必須です。
カテゴリ4:物理的なアクセス・デバイス
デジタルだけでなく、物理的なアクセス手段の回収も忘れてはなりません。
| 対応項目 | 詳細 | 期限目安 |
|---|---|---|
| 入退館カード | ICカード・セキュリティカードの回収 | 最終出社日 |
| PC・モバイル端末 | 貸与デバイスの回収とワイプ(初期化) | 最終出社日 |
| USBメモリ・外部デバイス | 貸与した記憶媒体の回収 | 最終出社日 |
| 多要素認証デバイス | セキュリティキー・認証アプリの解除 | 退職日当日 |
| 共有アカウントのパスワード | 退職者が知っている共有パスワードの変更 | 退職日当日 |
| 名刺・社員証 | 社名入り名刺、社員証の回収 | 最終出社日 |
← 横にスクロールできます →
ポイント: 見落としがちなのが共有アカウントのパスワード変更です。admin@やinfo@などの共有メール、共有のクラウドアカウントのパスワードを退職者が知っている場合、必ず変更しましょう。
カテゴリ5:データの引き継ぎと保全
アカウント削除の前に、業務データの引き継ぎを完了させることが重要です。削除してからでは取り返しがつきません。
| 対応項目 | 詳細 | 期限目安 |
|---|---|---|
| メールデータ | 重要なメールのエクスポート・引き継ぎ | 退職1週間前 |
| クラウドストレージ | 個人ドライブのファイルを共有フォルダへ移動 | 退職1週間前 |
| ブックマーク・ナレッジ | 業務に必要な情報源の共有 | 退職1週間前 |
| 進行中の案件 | プロジェクトの引き継ぎドキュメント作成 | 退職2週間前 |
| 取引先への連絡 | 後任者の紹介・連絡先変更の通知 | 退職1週間前 |
← 横にスクロールできます →
退職時チェックリストの運用フロー
削除漏れを防ぐ「仕組み」の作り方——属人化しない退職処理フロー
チェックリストがあっても、それを毎回確実に実行できなければ意味がありません。ここでは、ひとり情シスでも運用できる仕組みづくりのポイントを解説します。
ステップ1:SaaS台帳(アカウント台帳)を作る
すべての出発点は、**「自社で使っているサービスの一覧」**を把握することです。
台帳に記載すべき項目は以下の通りです。
| 項目 | 記載例 |
|---|---|
| サービス名 | Google Workspace |
| 管理者 | 田中(情シス) |
| 契約形態 | 年契約(2026年3月更新) |
| アカウント数 | 50名分 |
| 利用部署 | 全社 |
| 退職時の対応 | アカウント停止→3ヶ月後に削除 |
← 横にスクロールできます →
このSaaS台帳があれば、退職時に「何を消すべきか」が一目瞭然になります。逆に言えば、台帳がなければ、チェックリストを作っても漏れるのです。
ステップ2:退職処理フローを定型化する
退職の連絡を受けてからアカウント削除完了までのフローを時系列で整理しましょう。
退職2週間前
- 人事部門からIT管理者へ退職通知
- 対象者のアカウント一覧をSaaS台帳から抽出
- データ引き継ぎ計画の策定
退職1週間前
- データの引き継ぎ・バックアップ実施
- 後任者へのアカウント権限移譲
- 取引先への連絡
退職日当日
- 全アカウントの停止・無効化
- VPN・リモートアクセスの即時遮断
- 物理デバイスの回収
- 共有パスワードの変更
退職後1週間
- 削除漏れの最終確認
- SaaS台帳の更新
- ライセンスコストの見直し
退職後3ヶ月
- 停止状態のアカウントの完全削除
- メール転送設定の解除
ステップ3:「退職処理の引き継ぎ」自体を仕組み化する
最も見落とされがちなのが、退職処理を行うIT管理者自身が退職するケースへの備えです。
これは属人化の極みです。チェックリストがあっても、その存在場所や運用方法が一人の担当者にしか分からなければ、担当者の退職と同時に仕組みが崩壊します。
対策として、以下を実施しましょう。
- チェックリストと台帳をクラウド上の共有フォルダに保管(個人のPCに保存しない)
- 退職処理の手順書を作成し、上長と共有
- 年に1回、退職処理のリハーサルを実施(IT担当者以外が手順書だけで実行できるか確認)
こうした仕組みづくりは、日常業務に追われるひとり情シスにとって「やりたいけど手が回らない」項目の筆頭かもしれません。もし社内のリソースだけでは難しい場合、外部の力を借りることも選択肢のひとつです。たとえば、月額制で情シス業務を支援するDX推進サービスを活用すれば、台帳整備やフロー構築を専門チームと一緒に進めることができます。
こんなIT管理者の方におすすめ
- ひとり情シスで、退職時の対応を一人で回している方
- 退職処理の手順が明文化されておらず、毎回記憶に頼っている方
- SaaSの契約数が増えて、全体像が把握できなくなっている方
- 過去に退職者のアカウント削除漏れでヒヤリとした経験がある方
- 情シス担当の引き継ぎに不安がある経営者・管理職の方
退職者のアカウント放置は、「いつか起きる事故」ではなく「いつ発覚するか」の問題です。
情報漏洩が起きてからでは遅すぎます。個人情報保護法の改正により、漏洩時の報告義務や罰則も強化されています。**「事故が起きていないから大丈夫」ではなく、「事故が起きない仕組みがあるから大丈夫」**と言える状態を今すぐ作りましょう。
まとめ
退職時アカウント管理のまとめ
退職者のアカウント削除は、やるべきことが明確なのに、仕組みがないから漏れる——そんな典型的な「属人化リスク」です。
この記事のポイントを振り返ります。
- 退職者のアカウント放置は、情報漏洩・不正アクセス・コスト増の原因になる
- 対応すべき項目は5カテゴリ(メール・SaaS・インフラ・物理・データ)に整理できる
- チェックリストだけでなく、SaaS台帳と退職処理フローの整備が不可欠
- IT管理者自身の退職に備えた「仕組みの引き継ぎ」まで考慮する
まずは今日、自社で使っているSaaSの一覧を書き出すことから始めてみてください。台帳がなければチェックリストは機能しません。逆に、台帳さえあれば、この記事のチェックリストをベースに、自社に合った退職処理フローをすぐに構築できます。
「退職が発生してから慌てる」のではなく、「いつ退職が起きても対応できる」仕組みを今のうちに整えましょう。