Hand over and revoke technical access in an orderly way
Record application accounts, service access and recovery paths separately. A completed handover plan identifies decisions, checks and responsible roles.
When someone leaves or changes roles, technical work must continue while permissions that are no longer needed are effectively removed. Start with the actual access to your application and infrastructure. A single “account disabled” entry does not describe the whole transition.
Record access and dependencies
In this fictional example, a person who looks after a customer portal leaves the team. Their responsibilities include application account U-71, hosting administration and a service connection using key K-71. They were also the recovery contact for an administrator account.
NIST treats account management, departure and reassignment as related control topics. Use that structure for your technical process. The inventory records the system, access type, purpose and responsible role; the document itself is not a store for passwords or secret keys.
Document a decision for each access route
Specify which permission ends at the agreed time and which technical task will continue using another authorised account or access route. A personal account, service connection and recovery path may need different actions. The following table is a completed plan for the example, rather than the result of changes already carried out.
Access | Handover decision | Technical check | Responsible role |
|---|---|---|---|
Application account | Remove memberships and permissions no longer needed; give the new responsible person their own account. | Old access is denied; new authorised access works. Existing sessions are checked separately. | Application owner |
Service connection | Use authorised technical access with a named owner and plan to replace the previous key. | The connection works after the change; the retired key is no longer accepted. | Integration and operations |
Administration and recovery access | Assign administration to authorised people and establish an accessible recovery path. | Access and recovery are checked using an approved procedure. | Operations owner |
Check the change and its effect separately
Blocking sign-in does not automatically answer every question about existing sessions, independent access keys or other systems. Include those cases in the approved test. A changed service connection needs its own evidence that it works; a person's successful sign-in does not prove that.
NIST also covers changing shared authenticators when members leave a group. Check which technical access credentials were actually known or assigned. Transfer the task using suitable authorised access, rather than passing on the previous personal login.
Finish the handover with a clear record
Record the decision, implementation status and check result for each access route. Keep an unresolved recovery path open and assign responsibility for it. Anyone providing cover must be able to see who may make technical changes and where to escalate unresolved cases.
After the agreed transition, also check the affected background tasks and connections. This aligns the removal of a person's permissions with the operations that must continue. No access was blocked, keys changed or recovery tests performed as part of this example.
Sources
Read more
All articles
Cloud & Operations with ASES
Hosting, deployment, maintenance and support