What Happens When the Person Who “Knows the IT” Leaves?

Most companies do not realize how much of their technology environment lives inside one person’s head until that person is no longer available.

It might be an IT director who has been with the company for a decade. It might be an operations leader who gradually became responsible for Microsoft 365, vendors, and half the company’s applications. It could be a founder who created the original accounts, an outside consultant who designed the environment years ago, or simply the employee everyone calls because they know how everything works.

As long as that person is there, the arrangement can appear remarkably effective. Problems get solved. Vendors know whom to call. Someone remembers why a system was configured a certain way. When something unusual happens, there is a person who knows the history.

Then that person resigns, retires, changes roles, becomes unavailable, or simply stops remembering decisions made years earlier.

The company still owns the devices. It still pays the subscriptions. The contracts are still in its name. But leadership discovers that ownership of the technology and control of the technology are not necessarily the same thing.

The departure did not create the problem.

The problem already existed. Their departure simply revealed it.

The Company Should Own More Than the Accounts

Technology ownership is easy to misunderstand because businesses usually own the visible assets.

The company purchased the laptops. It pays Microsoft or Google. It owns the domain. It signs the vendor contracts. The accounting system, CRM, security platforms, network equipment, and cloud services all exist for the benefit of the organization.

But practical control depends on more than whose name appears on an invoice.

Could another qualified person determine who has administrative authority across the company’s critical systems? Could they identify which vendors have access to the environment and what those vendors are responsible for? Could they determine where the domain and DNS are controlled, which systems are business-critical, how important integrations work, and what would need to happen if a major platform became unavailable?

More importantly, could they understand why the environment works the way it does?

That final question is where key-person dependency becomes more than a documentation problem.

An inventory can tell someone that a system exists. A password manager can provide access to it. A contract can identify the vendor. None of those things necessarily explains why the company depends on the system, what other technology depends on it, what decisions shaped its configuration, or what would happen if it changed.

A business does not fully own important technology knowledge if that knowledge cannot be transferred.

Key-Person Risk Often Looks Like Competence

One reason this risk survives for so long is that the person at the center of it is often very good at what they do.

They know the environment because they helped build it. They remember unusual dependencies because they were there when those dependencies were created. They know which vendor representative can actually solve a problem, which old configuration cannot be changed yet, and which application behaves differently from everything else.

That knowledge makes the company more effective.

It can also make the dependency harder to see.

When every difficult question has an answer, there is little pressure to ask whether the organization itself could produce that answer without the individual. The better the person is at compensating for missing documentation, unclear ownership, or architectural complexity, the longer those weaknesses can remain invisible.

This creates an important distinction for leadership. The objective is not to make experienced people less important. Expertise should be valuable.

The objective is to prevent expertise from becoming an irreplaceable component of the technology environment.

A mature organization captures enough of that person’s knowledge, authority, relationships, and architectural context that the business retains the benefit of their experience even after their role changes.

Administrative Access Is Not the Same as Organizational Control

Passwords are often the first concern when a key technology person leaves.

They matter, but the deeper issue is whether administrative control was designed to belong to the company in the first place.

Modern environments can contain privileged access across identity platforms, cloud services, domain registrars, DNS, security products, network infrastructure, device-management platforms, backup systems, SaaS applications, vendor portals, automation tools, and dozens of other services.

If one person is the only known administrator for several of those systems, the obvious risk is losing access.

There is another risk: the organization may not know how much authority that person accumulated.

Access tends to expand over time. Someone receives administrative rights for a project and keeps them. A vendor is granted elevated access to troubleshoot a problem. A personal phone number becomes the recovery method for a company account. A critical service is registered under an employee’s identity because that was the fastest way to get it running.

Years later, each decision still exists even though nobody would intentionally design the environment that way today.

The goal is not to distribute every privileged password to several people. That creates a different problem. The stronger model is company-controlled administrative ownership, individually attributable access where appropriate, defined recovery paths, and enough redundancy that control does not disappear with one person.

Microsoft’s own guidance for employee departures reflects this broader lifecycle approach. Removing access can involve revoking sessions, disabling accounts and devices, removing application access, reviewing group membership, and handling licenses and data deliberately rather than treating departure as a single password change. Microsoft Learn: Revoke user access in an emergency

The exact technical process will vary by environment. The governance principle does not: organizational authority should survive personnel changes.

The Hardest Dependencies Are Often the Ones Nobody Documented

The obvious systems are usually not the most surprising part of a departure.

Leadership knows the company uses Microsoft 365. Finance knows the accounting platform exists. Someone knows who provides internet service. Major applications usually appear on invoices, budgets, or vendor lists.

The more dangerous dependencies can be much smaller.

An automation may run under an employee’s account. A vendor portal may send authentication requests to their phone. A critical spreadsheet may contain logic nobody else understands. An integration may use credentials created years earlier. A recurring business process may depend on a manual step the employee performs without anyone realizing it is part of the process.

There may also be architectural knowledge that never looked important enough to document.

A system cannot be changed until another application is retired. A particular group exists because of an old access requirement. A vendor manages one component but another provider owns the dependency beneath it. A seemingly unused account is required by an integration.

These conditions are rarely created through negligence. They accumulate because organizations naturally optimize for getting work done.

The risk appears when the business can no longer distinguish between something that looks unnecessary and something that is quietly holding part of the environment together.

That is why a mature continuity model documents more than what exists. It preserves enough context to understand what depends on what, who owns it, and why consequential decisions were made.

Vendor Relationships Can Become Key-Person Dependencies Too

Technology knowledge does not exist only inside systems.

It also exists in relationships.

One employee may know the history of a telecom contract, which support path actually works with a particular vendor, why a security service was configured a certain way, which provider owns a piece of hardware, or what was promised during the last renewal.

If those relationships exist primarily through one person’s inbox and memory, the business can lose significant operational context without losing a single password.

This becomes increasingly important as organizations rely on multiple technology providers.

A company may have internal IT, an IT provider, a cybersecurity provider, software vendors, telecommunications companies, cloud providers, consultants, and specialized industry platforms. Each relationship may be documented individually while nobody has documented how responsibilities fit together.

When the person who understood those boundaries leaves, the business may discover that several capable providers each know their own piece of the environment but nobody knows the whole picture.

This is not an argument against using outside providers. Specialized providers are a normal and often valuable part of modern technology environments.

It is an argument for ensuring that the company retains ownership of the relationships between them.

Vendor contacts, administrative ownership, responsibilities, dependencies, renewal information, and important historical decisions should not disappear because one employee’s mailbox was disabled.

Documentation Should Preserve Decisions, Not Just Configuration

Most organizations understand that documentation is part of the answer to key-person risk.

The quality of that documentation matters.

A collection of screenshots can help someone reproduce a configuration. It may not explain whether that configuration should still exist.

An application inventory can show which products the company owns. It may not explain which are strategically important, which contain critical data, which duplicate another capability, or which the business intends to retire.

A network diagram can show how systems connect. It may not explain why a particular exception was necessary or what business process would fail if it disappeared.

Useful documentation preserves several layers of knowledge.

It establishes what exists and who owns it. It explains how important systems are operated and recovered. It identifies meaningful dependencies. And for consequential decisions, it preserves enough rationale that a future technology leader does not have to reverse-engineer the company’s history before making a safe change.

This is where documentation becomes part of architecture rather than administrative housekeeping.

The goal is not to capture every keystroke performed by the technology team. Documentation that attempts to record everything often becomes impossible to maintain and quickly loses value.

The goal is to preserve the knowledge another qualified person would need to take responsibility without guessing.

Continuity Is an Architectural Property

Business continuity is often discussed in terms of backups, disaster recovery plans, and emergency procedures.

Those things matter.

But continuity begins much earlier.

An organization is more resilient when critical authority is not concentrated in one account, when vendor relationships belong to the company, when important systems and dependencies are understood, when business-critical automations are not unnecessarily tied to individual employees, and when another qualified person can understand the environment without reconstructing years of undocumented decisions.

In that sense, continuity is partly a property of the architecture itself.

A fragile environment can have excellent documentation and still be difficult to transfer. A critical system may depend on a configuration that only one person understands. Administrative access may technically be documented while recovery still relies on that person’s phone. A backup may exist while nobody else knows how the surrounding business service is restored.

NIST’s contingency-planning guidance similarly treats continuity and recovery as organizational capabilities that should be planned before disruption rather than improvised after it. NIST SP 800-34 Rev. 1: Contingency Planning Guide

That principle applies even when the disruption is not a cyberattack or natural disaster.

Sometimes the disruption is simply the departure of the person who knew how everything worked.

The Bus-Factor Test Is Uncomfortable for a Reason

Software engineering has a deliberately blunt concept known as the bus factor: how many people could suddenly become unavailable before critical knowledge disappears with them?

For business technology, the question can be made less dramatic and more useful:

If the person who understands your technology best became unavailable tomorrow, could another qualified person take control without guessing?

That does not mean they should immediately know every detail.

They should be able to establish control.

They should know where administrative authority resides, which systems matter, which vendors are involved, how important services are recovered, where documentation lives, what major dependencies exist, and which areas require additional investigation before changes are made.

If the answer is no, the organization has identified something valuable.

It has found a dependency before a resignation, emergency, acquisition, or incident forced it to discover the same dependency under pressure.

The exercise is particularly useful because it shifts the discussion away from whether a specific employee is likely to leave. That is not the point.

The risk exists regardless of the person’s intentions.

A company should not need an employee to resign before determining whether it can operate without their memory.

Reducing Key-Person Risk Does Not Mean Creating Bureaucracy

The answer is not to build a giant documentation program or require several people to approve every technical change.

That can create more work without creating more resilience.

The appropriate response depends on the importance of the system and the consequence of losing control.

Critical administrative services should have company-controlled ownership and recoverable access. Important vendor relationships should be visible beyond one person’s inbox. Significant systems and dependencies should be documented. Business-critical automations should be understood. Major architectural decisions should preserve enough rationale to support future change.

Less consequential technology may require very little formal structure.

This is the same principle that applies throughout good technology governance: the amount of process should be proportionate to the consequence of the decision or dependency.

A ten-person company does not need the continuity program of a multinational enterprise. It may still need to know who controls its domain, where its critical business information resides, who has administrative authority, which vendors can access its systems, and how control would transfer if its primary technology person became unavailable.

Those are not enterprise requirements.

They are basic conditions of organizational ownership.

The Strongest Technology People Should Make Themselves Transferable

There can be an uncomfortable cultural dimension to key-person dependency.

Being the only person who knows how something works can feel valuable. Organizations can reinforce that behavior by rewarding the person who repeatedly saves the day without asking why only that person could save it.

Strong technology leadership should create the opposite outcome.

The most valuable technology person is not the one the company can never survive without. It is the one whose work leaves the environment more understandable, more controlled, and easier for another qualified person to inherit.

That does not diminish expertise.

It demonstrates it.

A well-architected environment should retain the benefit of someone’s judgment after they move on. Their decisions should create standards. Their knowledge should become organizational knowledge. Their work should reduce the number of situations where the company needs them personally to explain what happens next.

That is how individual expertise becomes institutional capability.

The Departure Should Be Boring

There is a useful standard for evaluating technology continuity:

When an important technology person leaves, the event should be operationally significant but structurally unsurprising.

Their access is removed through a known process. Responsibilities transfer. Administrative ownership remains with the company. Vendor relationships continue. Important systems do not unexpectedly stop because they depended on the person’s identity. Another qualified resource can understand the environment and continue operating it.

There will still be transition work. Knowledge transfer still matters. Replacing experienced people is rarely effortless.

But the company should not discover during the departure that it never truly controlled parts of its own technology.

That is the distinction.

People will leave. Roles will change. Providers will change. Businesses will acquire companies, reorganize teams, and replace systems.

A resilient technology environment is designed with that reality in mind.

The objective is not to make people interchangeable.

It is to make organizational control durable.

If the person who “knows the IT” left tomorrow, the most important question is not whether somebody else knows everything they know.

It is whether the business knows enough to take control without them.

If it does not, their departure is not the risk. It is simply the moment the existing risk becomes visible.