The departing lead may be the person who can reset administrator accounts, reach the password vault, restore a backup, approve a production change, call a key vendor or explain why a system was set up the way it was. If those capabilities sit with one individual, the resignation exposes a continuity problem that existed long before notice was given.
A senior executive's departure creates one access problem; the departure of the person who administers everyone else's access creates another. Executive Transitions: Who Still Has Access When Leaders Change? looked at whether permissions still matched a changing leadership role. Here, management has to prove that administrative control no longer depends on one technical employee.
A sole IT lead often becomes indispensable by degrees. They may have created the first cloud tenant, set up the domain, chosen the backup service, become the main contact for suppliers and kept solving problems faster than anyone could write them down.
That can work for years. The weakness shows when nobody can say with confidence who else can perform the same critical actions.
None of this requires assuming the departing employee is hostile. The risk exists in a completely cooperative resignation. A phone can fail, an MFA device can be handed back, an account can be disabled too early, or a forgotten renewal can arrive after the person has gone.
NIST's contingency-planning control (CP-2 in SP 800-53) offers a useful governance benchmark. It calls for organizations to identify essential mission and business functions, set recovery objectives and restoration priorities, assign contingency roles and responsibilities, and plan to maintain essential functions despite a system disruption, compromise or failure.
A resignation is not a cyber incident, but the principle carries over: continuity should survive one person's absence.
A U.S. federal audit shows what that dependency can look like when a key systems role turns over. A 2021 performance audit published by the U.S. Railroad Retirement Board Office of Inspector General found that a Financial Systems Section manager with more than 40 years of experience retired while the analyst succeeding him had not been adequately trained on the full scope of the role.
Auditors also found that management could not provide a written succession plan and warned that the resulting key-person dependency could threaten operations around the agency's core financial system. The organization is very different from a growing company, but the control lesson is the same: critical operations become fragile when knowledge, responsibility and transition planning remain concentrated in too few people.
Start with the administrative layer. Can anyone other than the departing lead administer every environment the company depends on?
Microsoft's Entra emergency-access guidance makes the redundancy point explicit. It recommends maintaining at least two emergency access accounts, so an organization keeps a way in when normal administrator accounts cannot be used, and it lists the departure of the person with the most recent Global Administrator access as one of the scenarios where that matters.
NIST's privileged-account controls (AC-2(7) in SP 800-53) take the same line more broadly: establish and administer privileged accounts, monitor role assignments and revoke access when those assignments are no longer appropriate.
Map the administrative layer across identity, email, cloud infrastructure, network equipment, device management, domains and DNS, finance systems, core SaaS platforms and anything else that could stop the company operating. Before the lead leaves, another authorized person should sign in to each one and perform a controlled administrative action.
An administrator account is only as good as the company's ability to recover it.
Check where password resets go, which phone or authenticator app receives MFA prompts, who holds hardware security keys, where recovery codes are stored, and whether a personal device or personal email address sits anywhere in the recovery chain.
Then look past the ordinary account list: the registrar that controls the company domain, the DNS provider, certificate-management accounts, emergency access to the password vault, cloud root credentials and the recovery contacts held by major SaaS suppliers.
Resist the urge to rotate everything the day notice arrives. Establish independent access and map the dependencies first. A rushed credential reset can turn a manageable resignation into a self-inflicted lockout.
A backup that only the departing lead knows how to restore protects very little.
CISA's Cyber Essentials guidance recommends regular automated backups and redundancies for key systems, including a solution that continuously backs up business-critical data and system configurations. It also says organizations should test the backup strategy before they need it.
CISA's StopRansomware guidance reinforces the recovery side of that control. It recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity in a disaster-recovery scenario.
For a sole-IT-lead handover, the practical question is therefore not simply whether backups exist, but whether another authorized person can locate them, understand what they contain and complete a recovery without relying on the person leaving.
Run the restore test on the systems whose failure would hurt the business most. It should also show who receives backup-failure alerts, who can change retention or deletion settings, and whether recovery depends on credentials that are themselves part of the handover.
Control goes beyond passwords. The departing lead may be the named account owner, billing contact, support contact or authorized requester for software, telecoms, cloud services, domains, security tools and hardware suppliers. Some subscriptions may be paid on their personal card or registered to a personal email address, and those need to be moved onto company billing and company accounts before the person leaves.
Move every relationship to company-controlled contacts, and confirm who can approve purchases, request support, renew licenses, change service plans and receive security or outage notices.
A company can keep technical access and still lose practical control. If a supplier will only speak to the person who set up the account, the handover is incomplete.
Work already in motion carries its own risk.
List the deployments, migrations, infrastructure changes, certificate renewals, hardware replacements, security fixes, vendor projects and other technical work scheduled around the departure date. For each, record what is changing and why, the rollback plan, the decision-maker and who can stop or approve the work once the lead has gone.
NIST's CM-3 configuration-change control supports that approach: review and approve or reject proposed changes, document decisions, implement approved changes, and monitor and review change activity. In a departure, that makes approval authority part of continuity as well as project administration.
A temporary freeze may be sensible for high-risk work that nobody else understands well enough to recover from failure. That is a judgment call for the business. The aim is to avoid finding, after the departure, that an important change is halfway done and nobody knows whether to finish it or reverse it.
Order matters as much as coverage. The sequence below is illustrative and assumes a cooperative notice period of a few weeks; shorter notice compresses the same steps without changing their order.
| Stage | What to do | Done when |
|---|---|---|
| First days | Map critical systems; confirm or create independent administrative and emergency access; agree with HR when the departing lead's access will change | Another authorized person has signed in to every critical system |
| Middle of the notice period | Move recovery methods, MFA devices, security keys and recovery codes to company control; transfer vendor, domain and billing ownership, including anything paid on a personal card | Recovery paths and supplier contacts point to the company |
| Before the last week | Run restore tests on the most important systems; agree owners and rollback paths for in-flight changes; decide on any change freeze | A restore has been completed without the departing lead's help |
| Final days | Run the operational handover tasks; reduce the departing lead's privileges as planned; record any open gaps | Someone else has completed the key tasks using the documentation |
In an ordinary cooperative notice period, access reduction comes after independent control has been established because the earlier steps may rely on the departing lead's knowledge and cooperation. The timing is partly an HR decision, too. If the company pays out the notice period or asks the employee to stop working early, access changes sooner and the earlier stages have to move faster.
Some loose ends can wait. The priority is removing the dependencies that could stop the business administering or recovering its own environment.
Before the final day, management should be able to confirm:
Recruitment, better documentation and architectural cleanup can continue after the departure. The urgent task is making sure the company no longer depends on the employee's continued availability, and resisting the temptation to turn the handover into a modernization project.
A folder of diagrams, passwords and notes can create false confidence. The stronger test is operational. Ask another person to perform a handful of essential tasks using the documentation: restore a test file, reach the domain registrar, add an administrator, open a priority support case, check the current backup status or explain the rollback plan for an active change.
Every failed attempt exposes a dependency while the original expert is still around to fix it. That beats discovering the gap during an outage two weeks later. The company does not need every technical detail written down before the final day. It does need the critical operating paths to be transferable.
A growing company may have nobody internally who can absorb the technical work right away. An outside provider can bridge the gap while management recruits, restructures the role or settles on a longer-term model.
If management decides to hire Creative Consultants Group or another provider, start with a defined handover scope. Creative Consultants Group's site lists managed IT services, cybersecurity, cloud services and IT consulting, and any provider will need time to learn the environment before it can take over safely.
Support models also differ, and according to Citadel Blue its service includes 24/7 U.S.-based support and proactive monitoring. Whichever provider you use, establish exactly which systems it will administer, what credentials it will receive, what stays with internal management and how the eventual handover to a new employee or another supplier will work. An emergency provider with undocumented control of every system is simply a new single point of failure.
The same split between execution and control runs through What Should a Growing Company Keep In-House—and What Should It Outsource? A provider can perform defined work while the company keeps ownership of priorities, risk acceptance, credentials, data and the ability to replace the provider.
Replacing one indispensable IT lead with another recreates the same problem. The departure has shown management exactly where the operating model leaned too heavily on one person, and that evidence should shape the new role and the controls around it.
That may mean separating day-to-day and emergency administration, keeping recovery credentials in company hands, maintaining a vendor register, testing restores, documenting critical changes, naming deputies for essential systems and reviewing which work genuinely needs an internal owner.
Growing companies will always depend on knowledgeable people. The goal is to stop expertise from turning into exclusive control.
A resignation letter does not create a single point of failure. It reveals one.
Management has handled the transition well when the company can administer critical systems, recover access, restore important data, reach its suppliers and make controlled changes without relying on the departing lead's memory, device or credentials. At that point the hiring decision gets much easier, because the business is choosing what capability it wants next instead of trying to win back control it should already have had.
Not as a reflex. In an ordinary cooperative notice period, first prove that the business has an independent administrative and recovery path, then reduce or remove privileges according to company policy and the agreed handover. A security concern or a policy requiring immediate revocation may justify restricting access sooner.
Independent administrative control, including recovery methods and emergency credentials. Every other step depends on it.
No. Passwords do not show how systems depend on one another, where MFA is registered, who owns vendor relationships, how backups are restored or which changes are in progress. The handover should be proven through real administrative and recovery tasks.
It can make sense when no internal person can safely cover the work, but define the provider's scope first: which systems it will administer, what access it receives, who inside the company remains accountable and how knowledge and credentials will be handed back or transferred later.
Design redundancy into the role from the start, then check it periodically. A scheduled restore test and a regular review of who holds administrator rights will show whether a new dependency is forming.