When an employee leaves a company, the usual checklist covers the laptop, badge, and email account. What often gets overlooked are the things that person quietly held together: the domain registered under their personal email, the cloud account they opened with their own card, and the API key that only they know about.
This is not negligence. It happens because, early on, speed matters more than ownership. Someone sets up something so the business can move forward, and no one revisits who is named on it.
This tends to come up on the worst possible day.
The accounts that are quietly not yours
Ask who legally owns each of these, meaning whose email address and payment method is associated with the account.
- Domain Name and Registrar Login
- DNS, where the records live and who can change them
- Cloud Account and Every Project and Subscription Inside It
- Hosting and Email Services
- Code Repositories and the Organization That Owns Them
- App Store Developer Accounts
- Payment Processors, Analytics, and Ad Accounts
- Third-Party Services That Send Email, SMS, or Notifications
The domain is the classic example. If it is registered under a developer’s personal account, getting it back can take weeks and cost real money if they leave on bad terms or simply stop answering. For many businesses, the domain encompasses the website, email, and brand.
What leaves with the person
Account ownership is the most visible aspect. A few less visible things are involved, too.
For example, keys and tokens that they created. An API key created under a personal login may stop working when the account is closed or continue to work long after the account holder has left the company. Neither scenario is ideal. I discussed where these end up in my post on secrets.
Two-factor codes tied to their phone are another issue. If the second factor of an account lives on a personal device, nobody else can access it, even with the password.
Scheduled jobs that run as them will fail the day their credentials are removed. A cron job, an automation, or a scheduled report that is authenticated with someone’s personal credentials will fail the day those credentials are removed. Often, nobody notices until the output is missing.
Billing on a personal card. Services paid for personally can lapse or be canceled without warning; usually, it’s the most important ones that were set up in a hurry.
Knowledge: This includes where things are, why they were set up that way, and what to do when something breaks. This is the hardest thing to recover, which is why documentation matters more than any tool.
An off-boarding order that works
When someone is leaving, whether they’re an employee, contractor, or agency, this is the order I’d work in:
- First, take an inventory. List every system that the person touches or owns. This is the slow step. For a small business, it typically takes two to four hours, and it nearly always turns up something unexpected.
- Then, move ownership before removing access. Transfer the domain, cloud account, repositories, and billing to company-controlled accounts while the person is still reachable and cooperative.
- Rotate what they knew. Replace any shared passwords, API keys, or tokens to which they had access.
- Remove their access. Disable their accounts and remove them from teams and organizations after the handover, not before.
- Check to see what breaks. Look for scheduled jobs, integrations, and automations that depended on their credentials and transfer them to service accounts.
- Capture the knowledge. Even a short document covering where things are located and how to access them is better than nothing.
- Test it. Ensure that someone else can log in to critical accounts and restore from a backup.
The common mistake is doing step 4 before step 2. Removing access first can lock you out of an account that only you could manage.
When it’s an independent professional or an agency
This applies to people like me, too. If you work with an independent professional or an agency, you should ask the same questions upfront.
The person who builds or manages your systems should have access to your accounts, not the other way around. You should be able to remove them without losing anything. If a provider insists on keeping the domain or cloud account under their name, you should question that, no matter how good the relationship is today.
I would rather my clients be able to easily replace me than depend on me. This approach builds more trust and is simply the safer way to run a business.
Set it up so it never becomes a crisis
The easiest offboarding is one that is planned from the beginning.
Use a shared company email address for important accounts instead of an individual’s. Keep billing on a company card. Store credentials in a team password manager. Store second factor codes in a location that isn’t one person’s phone. Document the essentials as you go, even in rough form.
None of this is expensive. Mostly, it just takes a few hours to set up and the habit of asking, “Whose account is this?” whenever something new is created.
Questions worth asking today
- Who is the registered owner of our domain, and would we be able to log in without them?
- Which accounts would we lose access to if a particular person left tomorrow?
- Are any important bills charged to someone’s personal card?
- Are there any scheduled jobs or integrations that run on someone’s personal credentials?
- Is there a document that tells a stranger where everything is located?
If the answer to any of these questions is a person’s name instead of the company’s, that’s the first thing to fix.
