When Someone Leaves, Can the Company Still Get In?

Startups have an accidental owner problem.

At the beginning, someone does whatever needs to be done. A founder registers the domain. The first engineer creates the cloud account. A contractor sets up the code repository. An early employee becomes the administrator for the customer-support platform, accounting system or advertising account.

That is usually reasonable. The company is moving quickly, responsibilities are informal and the fastest path is to let the person doing the work create the account.

The arrangement works until the person leaves.

Then the company discovers that an important system is connected to a personal email address, an old phone number, a device nobody else can access or a recovery process only one person understands.

The company may pay for the account. It may own the underlying work. It may have used the system for years. But when control lives with one individual, ownership can become surprisingly theoretical.

Paying for an account is not the same as controlling it.

Most companies think about access in terms of who has a username and password. That is only the first layer.

The more important question is who controls the account when the ordinary login stops working.

Who receives the recovery email? Whose phone receives the authentication code? Who can add or remove administrators? Who controls the domain connected to the company’s email? Which account owns the integrations that keep information moving between systems?

Those details are easy to ignore because they rarely matter during an ordinary week. Everyone logs in, the product runs and the company keeps moving.

Their importance becomes visible when something changes. A founder separates from the company. An employee is terminated. A contractor becomes unresponsive. A device is lost. A personal email account is closed. The company needs to recover information, preserve records or transfer responsibility quickly.

A system is controlled by whoever can recover it after everyone else has been locked out.

That person should not be a former employee, a departed founder or a contractor who finished the engagement six months ago.

Offboarding is a transfer, not just a shutdown.

The natural offboarding instinct is to remove access. That matters, particularly when a departure is abrupt or the company has security concerns.

But removing access is only half the job.

The company also needs somewhere safe for the access, information and responsibility to go. Otherwise, it can successfully lock out the departing person while accidentally locking out itself.

A practical transition identifies the systems the person used, the accounts they created, the administrative permissions they held and the records that need to remain available. Control is then transferred to company-managed identities, recovery methods are updated, necessary records are preserved and another person is given enough authority to keep the system operating.

The order matters.

If the company disables an email address before transferring the accounts connected to it, password recovery may become harder. If it removes the only administrator before adding another one, routine access can turn into a support escalation. If it collects a laptop without understanding what was stored locally, the company may preserve the device while losing the operating context.

Good offboarding protects both sides. The company retains control of its systems and records. The departing person is no longer treated as the permanent emergency contact for a business they no longer work for.

That is a cleaner ending than discovering three weeks later that the only way into an important account is to ask the former employee for another authentication code.

The first departure is too late to build the system.

A startup does not need an enterprise security program on the day it is formed. It does need a few habits that prevent individual convenience from becoming permanent company dependency.

Critical accounts should be created through company-controlled email addresses whenever possible. Important systems should have more than one authorized administrator. Recovery methods should belong to the company rather than to one person’s private email account or phone. Credentials should be stored in a managed system, not scattered across browser profiles, text messages and old onboarding emails.

The company should also maintain a simple record of its most important systems and who controls them.

That record does not need to catalog every tool anyone has ever tested. The focus should be on systems that can stop the company from communicating, collecting money, delivering its product, supporting customers, accessing its code or proving what happened.

This is not bureaucracy for its own sake. It is a way to make sure the company can survive ordinary changes in personnel without turning each departure into a technical investigation.

It also makes growth easier. New employees can be given appropriate access without inheriting someone else’s personal credentials. Contractors can complete their work without becoming permanent account owners. Founders can delegate without losing visibility into the systems on which the company depends.

The goal is not to make every account equally important. It is to know which ones actually are.

Control should survive the person.

Early-stage companies are built through individual effort. One person often carries an extraordinary amount of knowledge, responsibility and access. That concentration can be necessary for a period of time.

It should not quietly become the company’s permanent operating model.

This is not primarily a question of trust. A company can trust someone completely and still need its systems to remain under company control. In fact, a structure that depends on personal credentials is unfair to trusted people because it makes them responsible for the company’s access long after their role may have changed.

The practical test is continuity.

Can the company replace a device without losing access? Can another administrator recover the account? Can the business continue operating if the person who originally configured the system is unavailable? Can the company identify what needs to be transferred before someone leaves?

Founders naturally ask who needs access today so the company can move quickly.

The better question is:

If this person were gone tomorrow, could the company still get in, recover what it needs and keep operating?

If the answer is no, the company does not fully control the system. It is borrowing control from a person.