Coordination reduces the chance of breaking business processes or leaving access behind. A manager or IT team can confirm whether an account should be transferred, disabled, or kept for limited personal use, and can help preserve files that need to move first. It also creates accountability, so security tasks are handled cleanly before access becomes a liability.
Why coordinated account changes matter when someone leaves
Departures are not just access-removal events. They are also ownership and continuity events, because the account may still hold business data, approvals, delegated access, shared mailbox rights, or other dependencies that need to be reassigned before it is disabled. Coordination lets IT and the manager preserve the right assets, remove the right access, and avoid an avoidable outage or data loss.
That coordination is especially important when the account has been used for multiple purposes. A quick disable can stop an active process, while a delayed change can leave a live account available longer than intended. The practical goal is to separate what must move, what must end, and what can be retained only under a clearly approved exception.
What goes wrong when departures are handled without coordination
The most common failure is treating the account as if it were only a login, when it may also be a work queue, file store, or access path into shared systems. If nobody confirms the business role of the account, you can disable something that still owns records, scheduled jobs, or customer-facing workflows, or leave behind access that should have been removed.
There is also a governance problem. Without a named reviewer, teams can assume someone else checked the account, which creates gaps in accountability and slows remediation after the person has already left. A coordinated handoff gives the organisation a clear decision trail for transfer, retention, and revocation.
How to coordinate the change so it is safe and clean
The cleanest approach is to make the manager or account owner confirm the business need, while IT executes the technical change and verifies the result. That split matters because the manager understands the operational dependency, and IT can see whether the account is tied to applications, mailboxes, shared drives, or permissions that need separate handling.
A good handoff usually answers three questions: should the account be transferred, should it be disabled, or should it remain active for a short, approved transition period? Once that decision is made, the team can move files and ownership first, then remove access, then confirm that no hidden dependencies remain. When the account is tied to privileged or shared access, a CIS Controls v8 style account-management process provides the right operational discipline, and formal control catalogs such as NIST SP 800-53 Rev 5 Security and Privacy Controls reinforce the need for controlled access changes and auditability.
Why this is really a control, not just an HR courtesy
Departure handling protects both security and continuity. If access is removed too early, the business may lose a needed file, mailbox, queue, or approval path. If access is removed too late, the former staff member or an attacker who finds the account can still reach systems that should no longer be available. That is why the process needs approval, timing, and verification, not just a ticket closure.
For organisations that rely on formal identity and access controls, the decision should be tied to the account lifecycle, not to an informal assumption that departure automatically means disablement. Standards and guidance that address access revocation and account lifecycle, including NIST SP 800-53 Rev 5 Security and Privacy Controls and CIS Controls v8, support the same basic idea: revoke access deliberately, confirm ownership transitions, and keep evidence of the change.
Risk and Threat Considerations
Departing staff accounts are a common source of residual access, unintended data exposure, and business disruption. The risk is highest when the account is shared, used for administration, or tied to sensitive files and approvals, because a missed dependency can either preserve access longer than intended or break a critical process after the person leaves.
Failure mechanism: The organisation disables or transfers an account without first identifying all dependent systems, permissions, and business assets, so either access remains behind or an essential workflow loses its owner.
Impact: Former users, or anyone who later obtains the account, may retain access to sensitive systems, while the business may also lose files, approvals, or service continuity if the account is removed too early.
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 | Departing staff account changes are an account lifecycle control issue. |
| AC-6 — Least Privilege | Offboarding should remove unneeded access and avoid retaining excess rights. | |
| Recommendation — Revoke or transfer accounts only after confirming ownership and required access. Remove unnecessary privileges and keep any exception tightly time-bound. | ||
| CIS Controls v8 | CIS-5 — Account Management | The question is about safe account lifecycle handling during departure. |
| Recommendation — Standardise offboarding checks for transfer, disablement, and access removal. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity changes on departure require controlled assignment and removal. |
| A.5.18 — Access rights | Leaving staff can retain access unless rights are reviewed and removed. | |
| Recommendation — Update identity ownership and revoke access as part of offboarding. Review and withdraw access rights when employment or role changes. | ||
Practitioner Guidance
What to verify: Confirm the account’s business role before any change, including whether it owns files, mailboxes, scheduled tasks, delegated permissions, or application access. If the answer is unclear, treat the account as a transition item, not a routine disablement.
Decision rule: If the account still supports work that must continue, transfer ownership or preserve the needed data first; if it no longer serves a business purpose, disable it and record the approval path. When the account has elevated or shared access, require explicit sign-off rather than assuming the departure notice is enough.
Practitioner takeaway: The safest offboarding change is the one that removes access only after the business dependency has been identified, transferred, and documented.
Related resources from NHI Mgmt Group
- How should security teams govern self-serve account changes without weakening identity assurance?
- How should security teams reduce the risk of Google Ad Manager account takeover?
- How should teams govern ServiceNow access when workflows drive account changes?
- Who should own help-desk verification policy when account changes affect IAM and PAM?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
