The direct answer is to separate the automation's identity from the departing person's access, inventory every dependency they could control, transfer accountable ownership, revoke their human access, rotate exposed credentials, and then test each workflow. Do not simply delete a shared service account: that can stop production while leaving other hidden access paths untouched.
Freeze the evidence before making changes
Record the departure date, systems in scope, service-account names, current owners, credentials, API keys, connected apps, mailboxes, repositories, cloud projects, billing roles, and recovery contacts. Export audit logs and configuration where the platform allows it. Preserve enough information to understand what the person changed, but do not copy secret values into the checklist.
NIST SP 800-53's account-management and least-privilege controls support managing system accounts, reviewing access, and limiting users and processes to what assigned tasks require. NIST's small-business security guide likewise advises organizations to determine who has or should have access to business information and technology and to review accounts and privileges.
Map human access to machine access
For each automation, identify four separate things: the named service account, the human administrators who can modify it, the secret or token the workflow uses, and the resources the account can reach. An employee may lose their ordinary login but still know a shared password, hold a personal access token, own an OAuth connection, control the recovery email, or be the only administrator of a vendor portal.
Search configuration records, password-manager sharing, cloud IAM, source-control secrets, no-code connections, scheduled jobs, deployment systems, and vendor dashboards. Look for credentials created by the departing person's personal account and for automations that send to their mailbox or rely on their multifactor device.
Transfer ownership before revocation
Assign a current employee as the accountable owner and a backup owner. Update recovery contacts, billing notices, security alerts, and escalation routes. If the platform supports workload identities or managed service accounts, plan a migration away from credentials tied to an individual. Confirm the new owners can view logs, pause the workflow, rotate credentials, and contact the vendor.
Do not grant broad administrator access merely to make the transfer easier. Review each permission against the workflow's actual read, write, send, or delete actions. Remove access to unused folders, projects, customers, environments, and administrative settings.
Revoke and rotate in a controlled order
First disable the departing person's interactive sessions, personal tokens, group memberships, and administrative roles according to the organization's offboarding policy. Then rotate any service-account password, API key, signing key, recovery code, or webhook secret the person could have viewed or exported. Update the consuming workflow through the approved secret store rather than pasting values into scripts or tickets.
When one secret is used by several jobs, change one dependency at a time or use a documented overlap period if the platform supports multiple active keys. Watch logs while rotating. Revoke the old key as soon as the new path is verified. Record only the credential identifier and rotation time, never the secret itself.
Prove the automation still works
Run a low-risk test for every critical workflow. Confirm the expected trigger, action, log entry, notification, and recovery path. Test that the former person's account cannot sign in, administer the service account, refresh an OAuth grant, or receive recovery messages. Check that scheduled jobs run under the intended machine identity instead of a cached personal session.
For high-impact workflows, test pause, rollback, and manual fallback. Monitor at least one normal execution cycle and review error queues or dead-letter destinations. An offboarding change is not complete merely because the old login is disabled; the machine access must be both secure and operational.
Close with a dated review record
Keep the service account, systems reached, current owner, backup owner, privileges retained, credentials rotated, tests performed, exceptions, and next review date. Unresolved dependencies should have a named owner and deadline. Schedule a follow-up review because forgotten personal tokens or vendor invitations often live outside the main identity system.
The goal is a clean chain of accountability: no access remains because of the former relationship, every automation has a current owner, and each retained permission is necessary and tested.
Sources
- Security and Privacy Controls for Information Systems and Organizations — National Institute of Standards and Technology, Sept. 23, 2020
- NISTIR 7621 Rev. 1: Small Business Information Security: The Fundamentals — National Institute of Standards and Technology