Most owners find out how much of their business is registered in somebody else’s name at the worst possible moment: when that person stops answering, or when a bill fails and the recovery email goes to an address nobody controls.
This is a list you can work through yourself in an afternoon, without any technical knowledge, in the order that matters.
Start with the bank statement, not the software
Every service your business depends on is being paid for, and payment leaves a trail your accountant can produce in ten minutes. Ask for every recurring charge on the business card and the business account for the last twelve months.
That list is more accurate than anybody’s memory, including your developer’s. It surfaces services that were signed up for once and forgotten, and it catches the ones nobody would think to mention.
Then, for each line, establish two facts and write them down: whose name is the account in, and whose card pays for it.
Anything not in the company’s name is not currently yours, regardless of who pays.
The order of urgency
1. The domain name. If nothing else gets fixed this month, fix this. If your domain is registered in a contractor’s personal account, they control your website and your company email, and reclaiming a domain through a registrar’s dispute process takes weeks in the best case. Get the company named as registrant and get an address you control on the account.
2. DNS. The settings that point your domain at your server and your email at your mail provider. It is very often a different account from the domain registration itself and is the single most common thing to be overlooked, because it is invisible when it works and catastrophic in the ten minutes after somebody changes it.
3. The email provider. Losing access to company email while you argue with a contractor is a bad position from which to argue with a contractor.
4. Hosting. The machine or service everything runs on, and the billing account attached to it.
5. The code. Get yourself added as an owner of the repository and confirm you can see the whole history, not just the current state. If no repository exists, the code is on the server and can be retrieved; what is lost is the history, which makes the next developer slower but is survivable.
6. Everything that touches money. Payment provider, invoicing, subscriptions. These are usually in the company’s name already because a bank account was needed to open them, but check who the administrative users are.
7. The rest. Error reporting, analytics, text messaging, file storage, whatever else the statement turned up.
The part nobody tells you: the passwords inside the code
Once you have the accounts, there is a second layer, and it is the one that survives a handover.
Older systems very often hold their passwords inside the code itself — the database password, the payment provider key, the credentials used to send email as your company. It is there because on the day it was written there was one server and one developer and putting the value in a file was the obvious thing to do.
The problem is not the file. It is every copy of the file. Code gets copied to laptops, into backups, to contractors during a three-week engagement. Once a password has lived in code, it exists in more places than anybody can list.
Which leads to the only question that matters here: has each of those values been changed since the last time somebody could have copied it?
If the answer is no, then everybody who has ever had a copy of your code still has a working password to your live systems. Not necessarily in bad faith. Usually just sitting in an old folder on a machine you cannot see. We wrote up exactly this situation, including the uncomfortable part — moving the values out took about a day, and changing them took longer, because reissuing a key depends on the provider’s schedule rather than on anybody’s engineering.
So the practical version of this task is:
- Ask for a list of every credential that appears in the code or its history.
- For each one, ask when it was last changed.
- Get dates against the ones that have never been changed, remembering that some of them need the provider to reissue and that has a lead time.
What to do when the person is still around
Ask in writing, specifically, and make it easy to answer.
A numbered list of five questions gets answered far more often than “can we schedule a handover call”. Which registrar, which hosting account, where is the code, is there a list of the other services, who else has worked on this. Somebody can answer that in ten minutes between other things. An open-ended request for their time competes with everything else in their week and loses.
Keep the tone neutral. You want information, not an explanation of why they stopped replying.
What to do when they are not
You can establish more than you would expect from the outside.
Public records show who a domain is registered through and where its mail is pointed, and they are free to look at. A registrar lookup takes a minute and needs no account, no permission and nobody’s cooperation.
That will not tell you who owns the hosting account. It will tell you where to send the recovery request, and it will tell you whether the software behind it is years past its support date, which is a separate problem you would rather know about now. Here is what that one looks like when it has gone unattended.
The version of this that is worth doing anyway
Even when nobody has disappeared and nothing is wrong, this list is worth one afternoon a year.
It is the difference between an inconvenience and a crisis on the day something changes — a contractor moves on, a card expires, a provider closes an account for inactivity. Nothing on it requires technical knowledge. All of it requires somebody to decide it is their job.
If you would rather have it established and written down properly, that is part of what an audit produces, and you can tell us what you are dealing with first. The reply is free and it will say honestly whether you need us for it.