Closing Access Without Breaking the Handover
A staged sequence for closing system access at the end of employment, what cannot be revoked person by person, and the accounts nobody has a list of.
An access close-down, as one organisation sequenced it
The organisation could not say which external services the person held accounts with, and still cannot. This is one organisation's own record, not a statement of what any rule requires.
Close access in stages rather than at a single moment, because the two obvious approaches both fail: cutting everything at nine in the morning makes the handover impossible, and leaving it until somebody remembers leaves a working account open for a fortnight. The workable version is a sequence with times against it, agreed before the last week starts.
The handover issue in “Closing Access Without Breaking the Handover” is easier to manage when current projects, recorded time and unfinished work can be reviewed before access closes. A team evaluating employment of relatives policy with accountable controls for employment of relatives policy should set a clear cutoff, export what is genuinely required and avoid retaining unnecessary activity data after the departure workflow is complete.
Access is also the part of a departure where the organisation discovers things about itself — that one person was the only administrator of a production system, that nobody knows which vendors the team has accounts with, that a shared password has been in use since 2019.
For an independent reference relevant to “Closing Access Without Breaking the Handover”, consult the EEOC retaliation guidance. Use it to test record quality, access, retention, fair process and exception handling against the organisation’s real departure workflow.
The sequence that works
- Produce the list of what the person actually holds, from the systems rather than from memory.
- Identify anything they own or administer personally and reassign it by name, before the last day.
- Agree with the manager what access the handover needs and until when.
- Disable interactive sign-in at an agreed time on the last working day.
- Divert mail and calendar rather than deleting them, and retain to the schedule.
- Rotate anything shared, because it cannot be revoked for one person.
- Close third-party and vendor accounts, which requires the list from step one.
The first step is the one that fails. Most organisations can tell you what somebody was granted when they joined and cannot tell you what they have accumulated since.
What cannot be revoked person by person
Shared credentials are not access, they are knowledge, and knowledge cannot be withdrawn. The only response is rotation, and rotation is disruptive, which is why it does not happen.
The same applies to anything the person could have copied: an exported client list, a document saved locally, an API key written down. These are not solved on the last day; they are solved by not having created the exposure, which is a different project and one worth starting the next time somebody resigns.
Mail, which is the hardest one
Deleting a mailbox on the last day destroys records the organisation may need and may be obliged to keep. Leaving it live lets a former employee read company mail. Forwarding it to a manager means somebody is reading another person's correspondence, including whatever is personal in it.
The usual middle course is to disable the person's access, set an auto-response pointing to a named colleague, divert new mail to a shared address, and retain the mailbox itself to the retention schedule with access controlled and logged. What is permissible differs by jurisdiction and is a question for somebody qualified in the place concerned — but whatever is decided should be decided as a policy, once, rather than improvised per departure.
Personally held administrator rights
The most expensive discovery in this whole area is that a system has exactly one administrator and they are leaving on Friday. It is also the most preventable.
Reassignment has to happen while the person is still there, because the alternative — recovering an account after the fact — ranges from tedious to impossible depending on the vendor. Ask the question at the point notice is given, not in the final week.
The accounts nobody has a list of
Software bought on a card, a free tier signed up for during a project, a vendor portal, a shared document in somebody else's organisation. These rarely appear in any inventory and they outlive the employment.
Asking the person directly, as part of the handover, produces a better list than any system will. It works best framed as help rather than audit: what are you signed up to that we would not know about? Most people answer honestly and are mildly embarrassed by the length of the list.
Building access, and the physical side
Badges, keys, fobs, parking, lockers, alarm codes and anything held by a third party such as a building manager. Alarm codes are the shared-credential problem again: if the person knows the code, changing it is the only remedy.
Record what came back and what did not, with the same care as any other property, and tell whoever administers the building. A deactivation that happens three weeks later, because nobody told facilities, is the kind of thing that turns up in an audit long afterwards.
Writing it down
Every step above should produce a dated record of what was done and by whom. Not because anyone will read it routinely, but because the one time somebody asks — an auditor, a client, an investigation into something else entirely — the answer has to be more than a recollection.
That record is also the only thing that improves the process. An organisation that can see it took eleven days to rotate a shared credential can do something about it. One that cannot see it will take eleven days again.