Organisations should support both permanent offboarding and temporary suspension. When someone leaves abruptly, access should be revoked immediately across all resources. When a contractor, freelancer, or employee on leave may return, the identity should be suspended instead of deleted so access can be restored cleanly later. That approach preserves control without forcing manual rebuilds.
Why sudden departures need immediate revocation
When a person leaves without notice, the main operational question is not whether the departure is “official” yet, it is whether any live access remains. If credentials, sessions, inboxes, VPN paths, shared accounts, or delegated permissions stay active, the organisation has an avoidable exposure window. Immediate revocation reduces the chance of unauthorised use, accidental access, or confusion about who is still entitled to act.
Fast revocation is also about scope. A clean process should remove access across the full stack, including application access, privileged access, and any standing exceptions that were granted for the role. The practical goal is to stop authentication and authorisation at the same time, so a departing person cannot continue to use a valid session or a forgotten entitlement elsewhere.
Why temporary suspension is different from deletion
Temporary suspension is the better pattern when someone is expected to return, such as during leave, suspension pending review, or a contractor pause. Deleting the identity can create unnecessary rebuild work later, especially if the record carries approvals, history, or access relationships that are expensive to reconstruct. Suspension preserves the identity record while removing active access until it is needed again.
The key distinction is that suspension should disable access, not merely mark the record inactive in one system while leaving related access paths intact elsewhere. Organisations need a reversible state that blocks use now and supports clean reactivation later. That is especially useful when the person’s return is likely and the organisation wants to avoid reissuing every entitlement from scratch.
What a clean offboarding-and-suspension process should preserve
A good process should separate identity lifecycle handling from business HR events. The access decision should be driven by the security state of the person’s relationship to the organisation, not by whether the person has completed paperwork. That means the workflow should support immediate deprovisioning for abrupt exits and a reversible hold for temporary absence.
The process should also preserve enough record detail to support auditability, restore access safely, and explain why a status changed. In practice, that means keeping clear ownership, documenting the reason for suspension or removal, and confirming that the change reached all connected systems. Where access is distributed across cloud services, SaaS tools, and internal platforms, completeness matters more than the label applied to the identity.
Risk and Threat Considerations
Residual access after a sudden departure can turn into account misuse, data exposure, or privilege abuse, especially when passwords, tokens, or delegated access are not removed everywhere at once. Temporary suspension carries a different risk: if the identity is only partially disabled, an attacker or former insider may retain enough access to act quietly through a forgotten path.
Failure mechanism: Incomplete revocation leaves live credentials, active sessions, or linked application permissions behind, while over-deletion breaks the ability to restore access cleanly and may encourage workarounds or shadow accounts.
Impact: Organisations face avoidable exposure, slower recovery, audit gaps, and higher operational friction when people return or when access needs to be re-established under pressure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Covers account disablement, suspension, and removal during offboarding. |
| IA-5 — Authenticator Management | Supports revoking or rotating authenticators and tokens after sudden departures. | |
| Recommendation — Disable or remove accounts promptly when access is no longer authorized. Revoke and reissue authenticators to cut off remaining access paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Addresses managing user accounts through joiner-mover-leaver lifecycle events. |
| Recommendation — Enforce account disablement and access removal in offboarding workflows. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Requires removal or adjustment of access rights when employment or contracts change. |
| A.5.16 — Identity management | Supports maintaining identity states for suspension and reactivation without deletion. | |
| Recommendation — Review and revoke access rights immediately when status changes. Maintain identity records so suspended users can be reactivated safely. | ||
Practitioner Guidance
What to prioritise: Treat abrupt exits as a revocation event and planned absence as a suspension event. The first question is whether the person can still authenticate anywhere, then whether any privileged, shared, or delegated access remains available.
What to verify: Confirm that the change reached identity stores, applications, remote access, and any systems that cache or mirror entitlement data. A record marked “inactive” is not enough if downstream access still works.
Common mistake: Deleting the account because it feels cleaner. That often trades short-term tidiness for longer-term recovery pain and makes it harder to restore the right access set later.
Practitioner takeaway: The best control is a lifecycle state that matches the business event, immediate removal for unexpected departure, reversible suspension for temporary absence, and verified propagation everywhere access exists.
Related resources from NHI Mgmt Group
- How can organisations reduce the risk of stale API keys and machine tokens?
- How should organisations govern access when employees, contractors and partners all need systems access?
- How should organisations manage joiner-mover-leaver processes across employees and contractors?
- Who should own deprovisioning when employees, contractors, and vendors leave?
