In our last article, What Happens When Your One Technical Person Quits, we looked at what can happen when too much technical knowledge, access, and responsibility sits with one person.

The problem is that many companies only discover that dependency after the person has already resigned. By then, they are trying to recover passwords, understand undocumented systems, figure out vendor relationships, and reconstruct decisions under time pressure.

The better approach is to deal with the risk ahead of time.

If your business has a small IT team, a technical founder, or one employee who seems to know how everything works, there are a few things you should put in place now so that their eventual departure becomes a transition rather than an emergency.

Here are the areas we would start with.

1. Create a System Inventory

The first step is to know what technology the business actually depends on. This should include your major systems, applications, hosting environments, cloud platforms, vendors, domains, integrations, backup systems, security tools, and other key infrastructure.

This sounds basic, but it is surprising how often companies do not have one central list. Someone knows about the hosting account, another person knows about the CRM, the developer knows where the source code lives, and the IT person knows how the backup system works, but nobody has the complete picture.

You do not need every minor application listed on day one. Start with the systems that would materially affect the business if they became unavailable.

Once you know what exists, it becomes much easier to manage ownership, access, renewals, security, and documentation properly.

2. Centralize Administrative Access

The next priority is making sure the company actually controls its own systems.

Important credentials should be stored in a company-controlled password management system rather than inside one employee's browser, notebook, phone, or personal password manager. Smartt FlexHours clients, for example, have access to a hosted password management system.

The organization should also own the recovery methods, MFA configuration, administrative email addresses, and any backup authentication methods associated with critical accounts.

This is increasingly important because access is no longer just about knowing a username and password. Many systems now rely on passkeys, authentication apps, recovery codes, SMS, or devices tied to a specific person.

If one employee's phone is the only way to approve access to your domain registrar, cloud environment, or Microsoft 365 account, you do not really have resilient administrative access.

For critical systems, there should always be a company-controlled way to get in without depending entirely on one individual.

3. Document the Important Processes

You do not need documentation for every small technical task, because that usually creates a lot of paperwork that nobody maintains. Instead, focus on the things that would be difficult, risky, or time-consuming to reconstruct under pressure.

That normally includes backups and recovery, user account provisioning, security procedures, major integrations, infrastructure configuration, website deployment, vendor escalation processes, and anything highly customized.

The question we would ask is simple: if something broke and the person who normally fixes it was unavailable, what information would another competent technical person need in order to take over?

That is the documentation worth creating.

It is also worth documenting why certain decisions were made, not just how something works. A replacement can usually figure out that Server A talks to Server B, but it may be much harder to understand why the environment was designed that way or what problem a particular workaround was solving.

4. Centralize Vendor and Subscription Information

A lot of technology risk comes from the commercial relationships around it. The business should maintain a central record of major vendors, account numbers, renewal dates, contract terms, billing ownership, administrative portals, support contacts, and escalation information.

You should also know who is paying for each service and what happens if that payment method disappears.

We have seen situations where an employee leaves and a few months later a subscription stops renewing because it was charged to their personal credit card. Nobody noticed until the service stopped working.

These problems are completely avoidable when vendor and billing information belongs to the company instead of being scattered across individual inboxes and expense reports.

5. Eliminate Knowledge That Exists in Only One Person

For every critical system or process, ask one simple question:

If this person disappeared tomorrow, who else would know what to do?

If the answer is nobody, you have identified a risk.

That does not necessarily mean two or more people need to be experts in everything. For a smaller business, that may not even be realistic. But someone else should at least know where the documentation is, how to get administrative access, who the vendor is, how to escalate the problem, and what systems are involved.

There is a big difference between saying, "Only John really understands this system," and saying, "John knows it best, but we have the documentation, credentials, vendor contacts, and another technical resource who can take over."

6. Establish an External Backup or Partner Before You Need It

A small internal IT or technical team can be extremely effective, but it should not necessarily be the only technical resource available to the company. There are always going to be situations where you need more capacity, a different area of expertise, or simply another person who understands the environment.

An external technical partner can provide that additional layer of continuity. They can help maintain documentation, understand the infrastructure, provide specialist knowledge, and step in when the internal team is unavailable or overloaded.

The important part is establishing that relationship before there is an emergency.

Trying to find a new technical partner after your IT manager has resigned, nobody can access the firewall, and an integration has stopped working puts everyone in a much worse position.

Even a relatively lightweight ongoing relationship gives the external team time to understand your environment before they are expected to solve a crisis.

What to Do If the Person Has Already Given Notice

Of course, sometimes you do not get the opportunity to prepare in advance.

If the resignation has already happened, the priorities change because you now have a limited amount of time to capture access and knowledge before the employee leaves.

At that point, we would not start by trying to document everything. Start by making sure the business has control.

1. Secure Access

The first priority is confirming that the company has administrative access to every critical system.

That includes domains, DNS, hosting, email, cloud services, backup systems, security platforms, source code repositories, business applications, vendor portals, and anything else required to operate the business.

You also need to verify how MFA and account recovery work. Having the password is not enough if the verification code still goes to the departing employee's personal phone.

Do this before their final day.

2. Identify the Critical Systems

Once access is secured, figure out which systems matter most.

One question we like is:

What are the five things that would cause the biggest problem if they stopped working next week?

That question forces everyone to prioritize quickly.

You do not need to understand every system immediately. You need to know which ones could stop employees from working, interrupt customer service, affect revenue, create a security problem, or make it difficult to recover the business.

Start there.

3. Capture the Knowledge That Is Hardest to Recreate

Next, focus the remaining time on knowledge that another technical person would have difficulty reconstructing.

Highly customized systems should take priority. So should unusual configurations, custom integrations, automation scripts, undocumented infrastructure, and anything that only makes sense because the departing employee remembers why it was built that way.

Standard systems are usually easier to figure out later because there is documentation, vendor support, and a larger pool of people who know how they work.

The things unique to your company are usually much harder to recover. This is also where screen recordings can be extremely useful. In some cases, having the employee walk through an environment, explain how an integration works, or show how a recovery process is performed can be much faster and more useful than asking them to write a long document from scratch.

4. Bring in Additional Technical Support

If nobody internally can take ownership of the environment, bring in additional technical support from a provider like Smartt while the outgoing employee is still there.

Even a short period of overlap can be extremely valuable because a technical person will usually know which questions to ask another technical person. They can verify access, review the infrastructure, identify undocumented dependencies, check whether backups are actually working, and determine what information needs to be captured while it is still available.

This is much more effective than bringing someone in after the employee has already left and asking them to reconstruct everything without context.

Smartt Is Here to Help If You Need It

If your business is too dependent on one technical person, Smartt can help you reduce that risk before it becomes an emergency. We can help document your environment, centralize access, review critical systems and vendors, improve cybersecurity, and provide ongoing technical support through our managed IT services and FlexHours. The goal is to make sure your business keeps operating smoothly even when key people change.