Small company. Real operating model.

Multi-factor on email, money, and the domain

Email first, because email resets everything else. Then anything holding money, customer data, or your domain registration. If there is no central place to enforce it, enforce it application by application and keep a list of what is still uncovered. That list is your risk register for the quarter.

Why first: Credential attacks are the ordinary way small companies get breached, not the exotic way. Password reuse, phishing, a credential from someone else's breach that still works on yours. Multi-factor is the cheapest control that breaks that chain, and it is the only item on this page that costs almost nothing and pays immediately.

Done looks like: A stolen password is not enough to get into anything that matters, no matter whose password it is. Contractors and vendors are the test of that, because they are usually the exception someone made once, in a hurry, and never went back to.

A reset path that does not depend on recognizing a voice

Multi-factor makes one question urgent: how does someone get back in when they are locked out? At this size the answer is usually that they message you and you recognize them. That is not verification. It is familiarity, and it is the easiest thing about your company to imitate.

If you have an identity provider, turn on self-service reset gated on the factor the person already enrolled, so the strongest thing you have does the verifying and nobody has to judge a voice. If resets come to you personally, write the script down and use it every time. Verify possession, not knowledge: an approval on the enrolled device, a video call where you can see the person, or someone standing in front of you. Not the employee ID, not the manager's name, not the last four of anything, because all of those can be harvested.

Then decide in advance what happens when the factor itself is gone, the lost phone on a Sunday, because that is the path an attacker will claim to be on. Make it slower and more deliberate than the ordinary one instead of improvising it under pressure, and apply it to everyone, including whoever is in a hurry and outranks you. Especially that person.

Why here: The strongest login in the company is worth exactly what the reset process will give away. Caller verification is authentication, which makes your reset script an identity control rather than a habit you picked up once when someone was locked out.

Done looks like: Getting back in never depends on you recognizing a voice, including for your own administrative accounts, which are the most valuable reset path in the company.

The credentials that unlock everything, into a password manager

Not the passwords people use for their own accounts. The shared ones, and the top five before the rest: the domain registrar, the bank, the payroll portal, the vendor account with a single login and no concept of users, the break-glass admin login for anything that has one. Each goes in with an owner and a note saying what it is for, which is this page's one rule applied to a secret instead of an account.

One caution, and it is the same argument as the reset path above. A password manager concentrates every credential you own into a single target, and a recovery path is a back door to every front door it resets. So it gets the strongest multi-factor you have, a named owner, a second person who can get in, and a break-glass path that does not depend on one person's phone.

Two credentials should not live in the vault at all, because they are what you need when the vault or the provider is the thing that failed: the emergency administrator account for whatever authenticates your people, and the vault's own recovery code. Those go offline. A sealed envelope in a safe does it, signed across the seal and dated so anyone can see whether it has been opened, with a line written on the outside saying who opened it and when. No office, or nobody who reliably goes in, means a bank box or the owner's home safe instead. Rotate what is inside after any use, and after anyone who could reach it leaves.

Treat the password manager as one of your identity systems rather than as a utility, because that is what it is. When you get to the catalog in the ninth item, it belongs on the list.

Why here: Single sign-on will never reach these accounts. Some have no concept of a user, and some sell it back to you at a price you are not going to pay. The vault is the permanent home for the credentials your identity provider cannot hold, not a stopgap until you get one. If the registrar and the bank are in a spreadsheet today, that is live exposure today.

Done looks like: No shared credential exists only in a chat message, a spreadsheet, or somebody's memory, and you can name every person who can open the vault.

Everyone who already left

Go back a year or two. Every employee and every contractor who is gone, checked against every system you can name, starting with the ones from the two items above. Not a process. One afternoon, once, to find out what is already open.

Why here: Everything else on this page prevents the next gap. This one closes the gaps you already have, and at most small companies there are some, because informal offboarding fails silently and nobody files a ticket about access that was never removed. It is the highest-value hour on this page and it is the one nobody schedules.

Done looks like: A list of what you found and what you closed. Keep it. It is your evidence, and it is the most persuasive thing you will ever show a leader who wonders why identity deserves time.

Who holds administrative access on the few systems that matter

Email, the registrar, the bank, the identity provider, the password manager. Who has admin, why, and does it still need to be standing. Thirty minutes, not a review program.

Why here: This is where an incident becomes an emergency rather than a nuisance. Standing admin is also where the leftovers collect: the consultant from a past project, the account created for a migration, the founder who has not touched it in three years.

Done looks like: Every administrator on those systems is a person you can name, with a reason you can state, and yours is in the list too.

Whether you already have an identity provider, or are one

If the company uses Microsoft 365 or Google Workspace, you have one. It is already authenticating your people, whether or not anyone has ever called it that. You are not choosing a product, you are choosing to use what you already pay for.

If you have neither, then right now the identity provider is a person, and that person is probably you. Accounts get created in each application by hand, with a username someone invents and a password someone remembers, or does not. That is a real operating model. It is just an undocumented one that runs on a single person, and it fails the first week that person is out.

Either way, write down what that person actually does, step by step, for an arrival and for a departure, naming every application they touch. That is your lifecycle, and it is worth having on paper even if it never gets automated.

Done looks like: You can name the thing that authenticates your people, and if that thing is currently a person, what they do exists somewhere other than their head.

One answer to "who works here," even when it comes from two lists

If there is an HR system, that is your source of truth for employees. Your contractors are probably not in it. They arrive through a manager, a vendor, or a purchase order, and they leave without anyone filing anything, which is exactly why contractor access is the access most likely to outlive the work it was granted for.

One record does not have to mean one system. It means every population has a source, that source has an owner, and there is one place you can go to answer the question. Two lists is fine. Two lists that disagree is not, and one list plus memory is not.

Whatever the second list is, give it the same columns as the first: name, start date, end date, manager or sponsor, role, systems they need. The end date carries more weight here than anywhere else on this page. An employee's last day arrives as news. A contractor's end date is often the only thing that will ever tell you they are gone.

Why not sooner: Building this record is administrative work rather than risk reduction, and the exposure it would have caught is the exposure the fourth item already went and found. It ranks here because everything after it depends on it.

Done looks like: You can answer "who works here" from one place, for both populations, and you would bet on the answer. No contractor row has a blank end date.

How someone leaves, written down

Not a policy. A list, in order. Disable the account where people sign in, which is the identity provider if you have one and email first if you do not. Then work down the application list, revoke administrative roles, transfer what they owned, and rotate anything shared they knew, which is possible now because the vault knows what the shared things are.

Why here: Leaving is the highest-risk gap in a small company and the one that fails silently. For employees the trigger is a last day someone announces. For contractors the trigger has to be the end date on the record, because no one is going to announce it. If you automate nothing else, automate this, and until you can automate it, at least stop improvising it.

Done looks like: The same steps happen whether the person left on good terms, bad terms, or on a Friday, and whether they were on payroll or on a contract. Someone other than you could run it.

What you actually have, and one place to sign in

Catalog every system and application, who administers it, how people sign into it, and who the users are. Include the ones nobody approved. Especially those. Then put the top five to ten behind whatever authenticates your people, and if you had to start from a person rather than a provider, this is the step where you stop being the provider.

Why here: You cannot govern what you cannot see, and in a small company the invisible part is usually large. Untracked subscriptions someone expensed, admin accounts from a trial that never ended, tools a contractor brought with them. Single sign-on is not about convenience either. It is about one place where access begins and one place where it ends.

Done looks like: A list you would not be embarrassed to hand to an auditor, including the rows that embarrass you, and disabling one account meaningfully reduces what a departed person can still reach.

Three to five access shapes, and a review you keep

Not roles in a platform. Shapes of work: what a new person in each kind of job needs on day one. Three is a fine number. Five is plenty. One of them is almost certainly contractor, and it should be the tightest one you have, scoped to the engagement and dated to match it.

Then make the administrative check from the fifth item recurring, and widen it a little each time. You will not be reviewing with a governance committee. You will be reviewing with the person who owns the application or the manager whose team uses it, and that is a real review as long as someone other than you signs off on the answer. Your own access is the exception, and it goes to someone outside IT: the owner of the business, whoever signs the contracts, whoever would have to explain it if it went wrong.

Why last: Shapes and reviews are what make the first nine items stay true instead of decaying back to where they started. They need the record, the catalog and the sign-in point to already exist, which is why they are here and not sooner.

Done looks like: You can provision a new person from a named shape, explain any access that falls outside one, and point at a review that happened on a date, with a decision, signed by someone who is not you.