Cross-SaaS lifecycle checklist with Microsoft 365 as a documented example. Use HR-authorised timing and current service-specific retention guidance.
Stuart Kerr Spindlow has confirmed personal use and testing of the software covered by Happy SysAdm. The assessments here distinguish documented behaviour from measured results; worked scenarios are labelled and are not personal test records.Transfer business ownership first where appropriate
Identify documents, mailboxes, workflows, code repositories and subscriptions that depend on the departing account. Assign a new owner through supported administration functions. Check automations and integrations that use the person’s token or credentials.
Preserve required data using the service’s supported process. Exporting a folder may not preserve permissions, version history or application relationships. For Microsoft 365, follow the workload-specific sequence and licence requirements rather than assuming all services retain data identically.
Revoke access across all layers
At the approved time, block or disable sign-in and apply the provider’s session and token revocation process. Remove groups, privileged roles, partner access and local or external accounts as applicable. Rotate shared secrets that the person knew where the risk assessment requires it.
Check persistent agents, mobile sessions, API keys and recovery methods. Single sign-on removal may not terminate every active session or separately managed credential immediately. Verify behaviour instead of treating a single directory action as complete offboarding.
Preserve business continuity while removing access
- Authorise
Confirm scope, effective time and retention decisions.
- Prepare ownership
Transfer authorised records and integrations where appropriate; use the service-specific process.
- Revoke on time
Block sign-in and handle sessions, tokens, roles and separately managed accounts.
- Verify and close
Test access removal and new ownership; remove licences or delete only after required conditions are met.
A disabled identity does not prove every downstream session or credential has been revoked.
Close with evidence and a retention review
Use the checklist below to record the outcome and remaining exceptions. Confirm that replacement owners can perform their work and that the departed identity cannot regain access through an old recovery path.
Remove licences and delete accounts only when the approved retention and transfer requirements have been met. Schedule any later deletion as a tracked task with an owner; do not claim it occurred because it was planned. Keep the completion record appropriately restricted.
| Step | Completion evidence |
|---|---|
| Authority | Approved scope and effective time |
| Ownership | New owners and validated workflows |
| Retention | Service-specific preservation decision |
| Access | Sign-in, sessions, tokens and downstream checks |
| Closure | Licences, later deletion tasks and exceptions |
Account for every access path
If a hypothetical leaver has eight SaaS accounts and six use the central identity provider, disabling that identity covers a configured sign-in path for six accounts, not proof that 75% of all access has ended. Active sessions, local passwords and API tokens can remain separate paths, and the two independent services need their own action.
Report each account and credential type with its verified outcome rather than collapsing the exercise into an unsupported success percentage. Microsoft’s offboarding guidance separates blocking access, preserving mail and OneDrive data, and eventual account or licence removal; retention behaviour must be checked for the actual service and configuration.