退職者の対応で最も見落とされがちなのが、社内システム・SaaSアカウントの削除です。形式的なオフボーディングは済んでいても、実際にはアカウントが残り続け、退職者によるデータ持ち出しや不正アクセスにつながるケースが後を絶ちません。

現場で繰り返し聞かれるのは、「どこまで消せば対応完了と言えるのか」「削除漏れをどう確認するのか」「返却されたパソコンは初期化すべきか、アカウントを消すだけでよいのか」という3点です。いずれも退職日当日に判断を迫られる論点でありながら、明文化された基準がないまま担当者の記憶に頼っている企業が少なくありません。

この記事では、削除対象の洗い出しから5ステップの実行手順、端末の扱い、削除漏れの検知、運用の仕組み化、主要ツールの比較までを一気通貫で整理します。退職対応のチェックリストとしても、社内手順書のたたき台としても使える構成にしています。

資料ダウンロード：5分でわかるジョーシス

退職者アカウント削除とは

退職者アカウント削除とは、企業から退職する従業員が利用していたあらゆるシステム・SaaS・端末のアカウントとアクセス権を、退職日に合わせて確実に無効化・削除する一連の業務を指します。情報システム部門の入退社対応における重要工程のひとつであり、セキュリティ・コンプライアンス・コスト管理の3つの観点から欠かせないプロセスです。

近年は1社あたりの利用SaaS数が急増しており、削除対象アカウントの数と種類が複雑化しています。BetterCloudの2023年調査では、平均的な企業は130を超えるSaaSを利用しているとされ、退職者1人あたり数十のアカウントが削除対象になるケースも珍しくありません。

アカウント削除の目的

退職者アカウント削除の目的は、以下の3点に集約されます。

• 不正アクセス・情報漏洩の防止：退職者が在職中の認証情報を使い、社外から機密情報にアクセスし続けるリスクを断つ
• コンプライアンス・監査対応：個人情報保護法・GDPR・ISO 27001などが求める「不要なアクセス権の削除」要件を満たす
• ライセンスコストの最適化：使用されないアカウントへの月額課金を停止し、IT予算の無駄を削減する

削除と無効化の違い

実務上、アカウントは「無効化」「削除」「アーカイブ」の3つの状態に分けて扱われます。一定期間は無効化（サインインだけ停止）、その後アーカイブ（データ保管）、最終的に完全削除という3段階を踏むのが一般的です。即削除すると業務データが失われる場合があるため、退職者の所属部署と連携した手順設計が必要となります。

退職者アカウントを放置するリスク

退職者アカウントの削除を怠ると、企業は複数の深刻なリスクにさらされます。情報セキュリティの専門誌でも繰り返し警告されている内容を、4つの観点で整理します。

情報漏洩・データ持ち出しの被害

最大のリスクは、退職者による不正アクセスや情報持ち出しです。退職時の感情的トラブルが原因で、在職中に取得した認証情報を使って顧客データや機密文書を持ち出す事例が報告されています。IPAの「情報セキュリティ10大脅威」では「内部不正による情報漏えい」が長年上位に位置しており、退職者起因のケースが目立ちます。

退職前後の行動に絞った防止策は、退職者による情報漏洩を防ぐアカウント管理の手順で詳しく整理しています。

サードパーティ経由の侵入経路

退職者アカウントは、サイバー攻撃者が標的にしやすい存在です。長期間使われていないアカウントは監視が手薄になりがちで、認証情報の流出や弱いパスワードが残っていれば、攻撃者が侵入経路として悪用するケースが多発しています。実際、複数の大規模インシデントで「使われていないアカウント」が侵入起点になっています。

ジョーシスが2026年6月に公表した独自調査でも、この前提が裏づけられています。日経225構成企業を対象とした調査では、96.4%（217社）が過去3年以内に情報漏洩を経験し、74.6%（168社）で深刻な認証情報の漏洩が確認されました。認証情報はすでに外部へ出ているものとして扱い、使われていないアカウントを残さないことが現実的な防御線になります。

コンプライアンス違反のリスク

GDPR・改正個人情報保護法・SOC 2・ISO 27001など、多くの規制・標準が「不要となったアクセス権の適切な管理・削除」を求めています。退職者アカウントの放置はこれらの違反となり、監査での指摘・行政処分・契約解除の対象になりえます。特に金融・医療・公共領域では事業継続にかかわる重大事項です。

ライセンスコストの無駄

主要なSaaSは月額課金型であり、未削除アカウントは課金され続けます。1ライセンス月額数千円のSaaSでも、退職者アカウントが100件残存すれば年間数百万円の損失となります。SaaSコスト管理の調査では、企業のSaaS支出の相当部分が「使われていないライセンス」に費やされているとされ、退職者アカウントはその主な要因のひとつです。

退職者分を含む余剰ライセンスの洗い出し方は、未使用SaaSライセンスの削減とコスト最適化の進め方で手順化しています。

参考：IPA — 情報セキュリティ10大脅威 

参考：【ジョーシス独自調査】日経225企業の96%が過去3年で情報漏洩を経験

退職時に削除すべきアカウントの種類

退職者対応では「メールとPCだけ」では不十分です。SaaS時代の現代企業では、削除対象アカウントが多岐にわたります。漏れを防ぐため、カテゴリ別に整理しておくことが重要です。

基幹システム系のアカウント

会社の基幹インフラに位置づけられるシステムのアカウントです。具体的には以下が含まれます。

• Active Directory／Entra ID：社内認証の起点
• メールアカウント：Microsoft 365、Google Workspace
• ファイル共有：OneDrive、Google Drive、SharePoint、Box
• VPN・リモートアクセス：社外からのアクセスを担う認証情報

これらは最優先で削除する必要があり、特にIDaaSやSSOの起点となるアカウントは退職日当日中に無効化することが基本です。

業務SaaSの個別アカウント

部署や職種により利用するSaaSは多岐にわたり、削除対応が漏れやすい領域です。

• 営業・CRM：Salesforce、HubSpot、Pipedrive
• 開発：GitHub、GitLab、Jira、Confluence
• コミュニケーション：Slack、Microsoft Teams、Zoom
• 業務管理：Asana、Notion、Trello
• 人事・労務：SmartHR、freee、マネーフォワード

これらは部署ごとに発生するため、IT部門だけでは把握しきれず、所属部署のマネージャーとの連携が不可欠です。

端末・物理デバイスのアカウント

物理端末も対象に含まれます。

• 業務PC・スマートフォン：本体の初期化、アカウント解除
• 共有プリンター：認証情報、印刷履歴
• ICカード・入退室カード：物理アクセス権

業務PCは初期化して再配布するケースが多く、退職者のデータが残らないようにディスク暗号化やワイプ手順を整備しておきます。

外部システム・サードパーティアクセス

意外と忘れがちなのが、社外の関連サービスです。

• クラウドベンダー管理コンソール：AWS、Azure、GCP
• 開発ツールAPI：個人発行のトークン・APIキー
• 外部委託先のシステム：取引先や代行業者のシステムアカウント

特にAPIキーや管理者トークンは流出時の被害が大きいため、ローテーション・無効化を確実に行います。

参考：NIST SP 800-53 — Access Control Family

退職者アカウント削除の進め方

退職者アカウントの削除は、退職決定から退職後一定期間までの一連のプロセスとして設計します。場当たり的な対応では漏れが発生するため、5つのステップに分けて運用するのが効果的です。

ステップ1：退職決定時のアカウント棚卸し

退職が決まった時点で、対象者のアカウント一覧を作成します。AD・IDaaS・SSO配下のアカウントは比較的容易に把握できますが、シャドーITや個別SaaSは部署ヒアリングが必要です。退職者本人にも、利用していたサービスとログインIDを申告してもらう仕組みを整えておくと精度が上がります。

ステップ2：退職前のデータ引き継ぎとバックアップ

退職日の1週間前から、業務データの引き継ぎを進めます。メール・ファイル・チャット履歴のうち会社資産にあたるものをアーカイブし、後任が参照できる場所に移動します。本人にしかわからない知識は、ドキュメント化しておくよう依頼しておきます。

ステップ3：退職日のアクセス無効化

退職日の業務終了時刻に合わせ、すべてのアクセス権を一斉に無効化します。具体的には以下の対応を行います。

• IDaaS・ADでのアカウント無効化（即時遮断）
• SaaSアカウントのSCIMデプロビジョニングまたはアプリ側での個別無効化（SSOだけ切ると未対応SaaSでローカルログインが残る場合があるため、アプリ側でのアカウント停止も確認する）
• VPN・リモートアクセス権の取り消し
• APIキー・個人トークンの無効化
• 物理カード・PC・スマートフォンの返却確認

退職日の終業時刻に合わせて、自動化されたワークフローで一斉実行する仕組みが理想です。

無効化した直後に、主要SaaSでセッションを強制失効させたかまで確認してください。管理画面のステータス表示だけでは、セッションが生きたままのケースを見逃します。自動連携の仕組みと対応SaaSの見極め方はSCIMによるSaaSプロビジョニング自動化の仕組みで解説しています。

ステップ4：データのアーカイブと削除

無効化後、一定期間（通常30〜90日）はデータをアーカイブとして保管します。法律で保存義務がある記録（労務・経理関連）はそれに従い、保管期間が過ぎたら完全削除します。Microsoft 365やGoogle Workspaceには、リテンション機能で自動アーカイブが可能なものもあります。

ステップ5：削除完了の証跡保管

監査対応のため、削除作業のログ・チェックリスト・承認記録を保管します。誰が・いつ・どのアカウントを・どの手順で削除したかを記録し、最低でも数年間は閲覧可能な形で保存します。退職者本人とのコミュニケーションログも合わせて保管すると、後のトラブル時にも対応しやすくなります。

参考：個人情報の保護に関する法律についてのガイドライン（通則編）｜個人情報保護委員会

退職者が使っていたPCは初期化とアカウント削除のどちらを選ぶか

アカウントの停止と同時に発生するのが、返却された業務パソコンの扱いです。「ローカルアカウントを削除して後任に渡す」「新しいアカウントを追加する」「まるごと初期化する」のどれを選ぶかで、残るリスクと再セットアップの工数が変わります。

判断は「端末を次に誰へ渡すか」で決まる

端末の行き先が決まれば、取るべき対応はほぼ一意に定まります。

「アカウントを削除して新しいアカウントを追加するだけ」で足りるのは、同一端末を短期間だけ共用する場合など限定的な場面です。原則は初期化と考えてください。

アカウント削除だけでは足りない理由

ローカルアカウントの削除は、端末上の入り口をひとつ塞ぐ操作にすぎません。ブラウザに保存された業務SaaSの認証情報と有効なセッション、別ドライブの業務データ、退職者に紐づいたままのディスク暗号化の回復キー、管理者権限で導入されたソフトウェアは、いずれもアカウントを消しても残ります。初期化して再キッティングすれば、まとめて解消できます。ただし退職者による持ち出しが疑われる場合は例外です。初期化は証拠の消失につながるため、端末に触れずに封印し、人事・法務と相談してから対応を決めてください。

WindowsとMacの再配布手順

Windows端末は、クラウド管理下にあるかどうかで手段が変わります。

1. Entra IDまたはActive Directoryで退職者のアカウントを無効化し、端末へのサインインを止める
2. Intuneなどの管理ツールから遠隔で「ワイプ」またはAutopilotのリセットを実行する
3. 管理ツール配下にない端末は、Windowsの「このPCを初期状態に戻す」でドライブのクリーニングを選ぶ
4. BitLockerの回復キーの保管先を確認し、資産台帳の利用者と状態を更新してから引き渡す

Autopilotのリセットは組織の構成やアプリを保ったまま利用者データだけを消せるため、台数が多い企業ほど工数を抑えられます。

Macは、事前のサインアウト漏れが後工程を止めます。「探す」機能をオフにしてApple Accountからサインアウトし、アクティベーションロックを解除したうえで「このMacを消去」を実行してください。退職後にサインアウトしてもらえるとは限らないため、返却時にその場で確認する運用が確実です。

参考：Windows Autopilot のリセット｜Microsoft Learn

職者アカウントの削除漏れを検知して是正する方法

手順を整備しても、削除漏れがゼロになることはありません。部署が個別に契約したSaaSは台帳に載らず、SSOを切ってもサービス側の個別IDが生きている場合があり、退職日が前倒しになれば当日の作業は積み残されます。原因が構造にある以上、対策は定期的に照合する仕組みで解決します。

削除漏れを検知する3つの方法

実務で効果が出やすい順に整理しました。

最初に着手するなら人事マスタとの突合が有効です。退職者リストとユーザー一覧を突き合わせるだけで、残存アカウントが機械的に浮かび上がります。検出後の扱いは孤立アカウントの定義とセキュリティリスク、検出・削除手順にまとめています。

退職日当日に使うチェックリスト

当日の作業をそのまま記録に残せる形にしておくと、漏れの防止と証跡の作成を同時に満たせます。

確認者の欄を埋めておけば、監査での証跡としてもそのまま提示できます。

漏れを見つけたときの是正手順

残存アカウントを発見したら、削除する前に調査します。最終ログイン日時とアクセス元を記録し、退職日以降のアクセスがあれば監査ログで操作内容を確認します。そのうえでアカウントを無効化し、関連するトークンや共有リンクも失効させます。先にアカウントを削除するとログを参照できなくなるサービスがあるため、調査を先行させてください。

参考：組織における内部不正防止ガイドライン｜IPA

退職者アカウント管理を仕組みにする運用設計

退職者アカウント管理は、退職が発生してから動き出すイベント対応ではなく、入社から退職までを通したライフサイクル管理として設計すると漏れが減ります。属人化を防ぐために決めておくべき2つの要素を整理します。

管理台帳に持たせる項目

台帳は網羅性よりも、人事情報と自動で突合できることを優先して設計します。

人手での更新は続きません。SaaSのAPIから利用者一覧を取得して自動更新する形が理想です。棚卸しの進め方はアクセス権限の棚卸し方法とJ-SOX・ISMS対応で詳しく扱っています。

対応期限と役割を数値で決める

すべてを退職日当日に終わらせる必要はありません。リスクの大きさに応じて期限を分けます。

あわせて、人事部門が退職確定情報を何営業日前までに連携するかも数値で決めてください。ここが曖昧だと、退職日当日に初めて退職を知る事態が起こります。業務委託や派遣の契約終了日は人事マスタに載らないことがあるため、契約管理台帳との突合も組み込みます。

参考：アクセス レビューとは｜Microsoft Entra ID Governance

退職者アカウント削除を効率化するツール

退職対応を手作業で行っていると、ミス・漏れ・遅延が発生します。特にSaaS数が多い現代企業では、専用ツールの活用が現実的な解決策となります。代表的な6カテゴリ・製品を紹介します。

Active Directory / Microsoft Entra ID（旧Azure AD）

Microsoft環境の場合、ADまたはEntra IDの統合管理がアカウント削除の起点となります。Entra IDではPowerShellスクリプトやGraph APIを通じて、退職者の一括無効化・自動化が可能です。Microsoft 365との統合により、メール・OneDrive・Teamsのアクセス権も同時に制御できます。

Okta

Oktaは、IDaaSとして8,000以上のSaaSと連携実績を持ち、退職者の一括無効化を自動化します。HRシステム（Workday、SmartHR等）との連携により、退職情報をトリガーにすべてのSaaSアカウントを自動で停止する仕組みを構築できます。

Microsoft Entra ID Governance

Entra ID Governanceは、Microsoft Entra IDのアクセスレビュー機能で、定期的な権限棚卸しと自動的な権限取り消しを実現します。退職者対応というより、退職後の残存アカウント発見・削除に効果を発揮します。

Google Workspace 管理コンソール

Google Workspace環境では、管理コンソールで退職者アカウントの無効化・データ移管・最終削除を順序立てて実行できます。Vaultとの連携で、訴訟対応に必要なメール・ファイルの長期保管も可能です。

SailPoint IdentityIQ

SailPointは、エンタープライズ向けIGA（Identity Governance and Administration）の代表格です。退職者対応を含む全社のアクセス権ライフサイクルを統合管理し、SOXやGDPRなど厳格な規制対応が必要な大企業で広く採用されています。

Josys

JosysはAI駆動のアイデンティティセキュリティ基盤で、350以上のSaaSと連携して退職者アカウントの一括削除を自動化します。HRシステム連携により、退職情報をトリガーにアカウント無効化・ライセンス回収・データアーカイブまで実行できます。ITデバイスとSaaSの統合管理を出発点にしているため、アカウントの停止と端末の回収を同じ画面で追跡できる点が、退職対応では効いてきます。

参考：Josys 連携サービス一覧

よくある失敗パターンと対策

退職者アカウント削除の運用では、いくつかの典型的な失敗パターンがあります。事前に把握し、対策を組み込んでおくことで防げるものです。

個別SaaSの削除漏れ

部署で独自契約しているSaaSのアカウントが見落とされ、退職後も認証可能な状態が続くケースが最も多い失敗です。対策としては、SaaS利用台帳の整備、部署マネージャーへの確認手順の組み込み、SaaS可視化ツールの活用が有効です。

削除タイミングのズレ

「退職日の翌週に削除する」運用にすると、退職日から削除までの数日間に持ち出しリスクが生じます。退職日の業務終了時刻に合わせた即時無効化を徹底し、データ復元が必要な場合に備えてアーカイブを並行運用する設計が望まれます。

共有アカウントの放置

部署で1つのアカウントを共有運用しているケース（チームメール、共通ID）では、退職者対応が抜け落ちがちです。共有アカウントのパスワード変更・MFA設定見直しを退職対応のチェックリストに含めることが必要です。

APIキー・トークンの放置

開発者やシステム管理者が個人発行したAPIキー・トークンは、削除されずに残るケースが多くあります。クラウドベンダーの監査ログを定期的に棚卸しし、発行者が退職している場合は即座にローテーションする運用を整えます。

引き継ぎなしの即削除

業務データを十分に引き継がないままアカウントを削除し、後任が必要なメール・ファイルにアクセスできなくなる事故も頻発します。ステップ4の「アーカイブ」期間を必ず設け、削除前に引き継ぎ完了確認を行うプロセスを定着させましょう。

参考：NIST SP 800-46 — リモートアクセス管理

退職者アカウント削除関連の重要用語集

退職者対応の現場で頻出する6つの専門用語を整理します。情シス担当者として理解しておくと、社内外のコミュニケーションがスムーズになります。

オフボーディング（Offboarding）

オフボーディングは、退職者のシステム利用を終了させる一連の業務プロセスを指します。アカウント削除だけでなく、PC返却・データ引き継ぎ・退職面談まで含む広義の退職対応プロセスです。対義語の「オンボーディング」（入社時のシステム整備）と対をなします。

プロビジョニング／デプロビジョニング

プロビジョニングは入社時にアカウントを払い出す処理、デプロビジョニングは退職時にアカウントを削除する処理を指します。SCIM（System for Cross-domain Identity Management）プロトコルを使った自動デプロビジョニングが、SaaS時代のスタンダードとなっています。

アクセスレビュー

アクセスレビューは、定期的にユーザーのアクセス権を点検し、不要な権限を削除する活動を指します。退職者対応の不備で残存したアカウントを発見・削除する役割も担い、四半期に1回程度の実施が推奨されます。

IGA（Identity Governance and Administration）

IGAは、企業のアイデンティティ管理を「ガバナンス（統制）」と「管理（運用）」の両面から実現する仕組みを指します。退職者対応・アクセスレビュー・職務分掌（SoD）違反検知などを統合的に行い、SailPointやSaviyntが代表的なベンダーです。

SCIM

SCIMは、SaaS間でユーザー情報を同期するための標準プロトコルです。HRシステムが退職を検知すると、SCIMやAPIを介して各SaaSにアカウントの無効化・削除を連携でき、人手を介さずにデプロビジョニングを進められます（サービスにより無効化・削除・属性変更など挙動が異なる場合があります）。

リテンション（Retention）

リテンションは、削除前にデータを保管しておく期間を指します。退職者のメール・ファイルは法的義務や引き継ぎのため一定期間保管され、その後完全削除されます。Microsoft 365では「リテンションポリシー」、Google Workspaceでは「Vault」がこの機能を提供します。

参考：NIST SP 800-63 — Digital Identity Guidelines

退職者アカウント削除の自動化はSaaS統合管理がカギ

ここまで述べた退職者対応を、すべて手作業で実施するのは現実的ではありません。SaaS数が増え続ける現代企業では、退職対応の自動化が情シスの工数削減と漏れ防止の両立に直結します。

退職対応で発生する3つの工数

• アカウントの棚卸し：退職者ごとに利用SaaSを特定する作業
• 個別の無効化作業：各SaaSの管理画面を開いて手作業で停止する作業
• 監査証跡の作成：誰が何を削除したかをエクセル・チケットに記録する作業

これらは1人退職するごとに数時間〜十数時間の工数が発生し、退職者が複数重なる時期には情シスの大きな負担となります。

事例：クラスター株式会社が退職者アカウントの削除漏れを防いだ方法

メタバースプラットフォーム「cluster」を運営するクラスター株式会社では、直近1年間で従業員が100名ほど増加し、在籍224名に対してIT総務は2名という体制でした。利用SaaSは70以上あり、管理は部署ごとに任せていたため、退職者のアカウント削除はその都度、各部署の担当者を介す必要がありました。端末もスプレッドシート管理で、返却された端末を次に誰へ渡すかの管理が難しい状態だったといいます。

Josysの導入後は、アプリ連携により利用状況がタイムリーに同期され、管理工数が削減されました。同社の担当者は、セキュリティ対応面で最もメリットを感じている点として「アカウント削除の抜け漏れを防げるようになったこと」を挙げています。

ジョーシスで実現する退職対応の自動化

Josysは、HRシステム連携により退職情報をトリガーに、350以上のSaaS連携を活用してアカウント無効化・ライセンス回収・データアーカイブを自動実行します。退職者1人あたりの対応時間を短縮し、人為的な漏れを抑えられます。Josysは2021年のサービス開始以来、国内外1,000社以上に導入されており、事例によってはIT工数を最大50%、ITコストを最大75%削減したケースもあります（効果は個社の状況により異なります）。

資料ダウンロード：5分でわかるジョーシス

無料デモを予約する

参考：クラスター株式会社 導入事例｜資産管理の効率化を実現

退職者アカウント削除に関するよくある質問

実務担当者からよく寄せられる質問を5つ取り上げ、実践的な目線で回答します。

Q1. 退職者のアカウントはどのタイミングで削除すべきですか

A. 即時無効化と段階的削除を組み合わせるのが基本です。退職日の業務終了時刻に「アクセス無効化」を実施し、その後30〜90日間はデータをアーカイブ保管したうえで「完全削除」に進めます。法律や業界規制で長期保管が必要なデータがある場合は、その期間に従います。

Q2. 退職者のメールはどう扱うべきですか

A. 一般的には「自動応答メールで退職を伝える」「アーカイブとして一定期間保管」「業務関連メールは後任に転送」の3段階が現実的です。Microsoft 365やGoogle Workspaceの管理機能で、退職者宛メールを自動転送する設定が可能です。

Q3. SaaSアカウントを削除する具体的な順序を教えてください

A. 優先度の高い順に対応します。具体的にはIDaaS・SSO起点アカウント → メール・ファイル共有 → コミュニケーションツール → 業務SaaS → クラウド管理コンソール → APIキー・トークンの順です。退職者がアクセスを継続できる経路を素早く塞ぐことが最優先です。

Q4. 退職者対応の自動化には何が必要ですか

A. HRシステムとIDaaS／SaaS統合管理ツールの連携が中核となります。HRシステムから「退職予定」のシグナルを受け取ったタイミングで、IDaaSが各SaaSに対してデプロビジョニング命令を送る仕組みを構築します。SCIMやAPI連携を活用することで、人手を介さず確実に削除を実行できます。

Q5. 退職者が使っていたパソコンは、アカウント削除と初期化のどちらが正しいですか

A. 別の従業員へ再配布するなら、原則は初期化です。ローカルアカウントの削除だけでは、ブラウザに保存された認証情報、別ドライブの業務データ、ディスク暗号化の回復キーの紐づけ、退職者が導入したソフトウェアが残ります。アカウントの追加だけで足りるのは、同一端末を短期間だけ共用する限定的な場面です。廃棄や下取りに出す場合は、暗号消去または物理破壊まで行い、証明書を保管してください。

参考：IPA — 中小企業のサイバーセキュリティ対策ガイドライン

まとめ：退職者アカウント削除はオフボーディングの最重要工程

退職者アカウント削除は、企業のセキュリティ・コンプライアンス・コスト最適化に直結する重要業務です。情報漏洩・不正アクセス・ライセンス無駄遣いというリスクを構造的に削減するため、対応プロセスを標準化し、自動化を進めることが情シス部門の重要課題となっています。

実効性のある退職対応のためには、SaaS利用の棚卸し、即時アクセス無効化、端末の初期化、データのアーカイブと完全削除、監査証跡の保管、削除漏れの定期検知という6つの要素を制度化することが欠かせません。手作業に頼ったオフボーディングはミスと漏れを生む温床となるため、IDaaSやSaaS統合管理プラットフォームの活用を検討すべき時代に入っています。

JosysのようなSaaS統合管理の仕組みを活用すれば、退職対応の大部分を自動化し、退職時のリスクを構造的に低減できます。情シスの工数を削減しながら、コンプライアンスとセキュリティを両立する仕組みづくりにぜひお役立てください。

資料ダウンロード：5分でわかるジョーシス