A company of five has no system administrator and no processes. Access accumulates spontaneously: the domain is registered to one person, the hosting to another, the advertising account to a third, and everyone knows the email password. Until somebody leaves, this works.
What to do in one evening
-
Write a list of services
Domain, hosting, email, payment provider, advertising accounts, analytics, code repository, messenger. Against each: who it is registered to and who has access.
This step usually reveals that half of it is registered to one person and some of it to somebody who left.
-
Move ownership to the company
Not to a person but to a corporate account or an address like
admin@. A founder's personal email as the domain owner is the most common landmine. -
Set up a shared password vault
A team one, not forwarding in a chat. Access is granted and revoked in a single action, and who used what is visible.
-
Separate shared from personal
Personal accounts are not handed over: if a colleague needs access, they get their own. Otherwise, after someone leaves, nobody can tell who did what — and everything has to be changed at once.
-
A second factor on the critical things
Domain, hosting, payment provider, email. Team vaults offer shared access to the codes, so nobody has to wake one person up to sign in.
What to keep where
| Access type | Where | Who owns it |
|---|---|---|
| Domain and hosting | Shared vault | The company, not a person |
| Shared service accounts | Shared vault | The company |
| Personal work accounts | The employee's own vault | The employee |
| Keys and tokens | Shared vault or a secrets manager | The company |
| An employee's personal accounts | Theirs alone | The employee, and that is not up for discussion |
When someone leaves
What exactly to require of passwords, and why scheduled changes do harm, is in password policy. The boundary between personal and work from the employee's side is covered separately.