A security program you can actually staff

You sat down one quiet evening to get serious about security. You found a framework, maybe a template, maybe a checklist a peer swore by. It looked reasonable. It had a section for the person who owns identity, a section for the person who runs detection, a section for the person who manages vendor risk, and a line item for quarterly access reviews that someone, presumably, conducts.

Then you counted the people. There is you. There is the engineer who already does the work of two. There is an office manager who somehow also resets passwords. The plan assumed a security team, and you have a group chat.

So the plan goes in a folder. You will revisit it after the next hire, or the next round, or when things calm down, which they will not. The trouble is not that you lack discipline. The trouble is that the plan was built for a company that does not exist yet, and you are running the one that does. A security program you cannot staff is not a program. It is a wish with a table of contents.

Walk through one of those templates and notice who it quietly assumes. Every responsibility is written as though a named person will pick it up: a security lead, an identity administrator, an on-call rotation, a compliance owner. The framework is not wrong about the work. Standards like the AICPA Trust Services Criteria describe controls that genuinely need to operate. The gap is that they describe the work, not who does it at 11 people.

This is where founders lose the thread. You read a list of roles and conclude you need a list of hires. So you do the math on a security salary, decide it is out of reach this year, and shelve the whole thing. The program becomes all-or-nothing, and nothing wins.

The reframe is simple. A security program is a set of things that have to happen on a schedule. It is not a set of seats. Once you separate the work from the headcount, the question stops being "who do I hire" and becomes "how does each thing reliably get done." That second question has answers a small company can afford.

Before you add anyone, map the people already in the building against the work that has to happen. You will find three honest categories.

• Work your team should own. Anything that needs context only you have: who the new hire is, which vendor matters and which one the team only pretends to use, what is urgent this week. Judgment does not outsource well, and a small team is good at it.
• Work your team cannot keep current. Threat detection, identity architecture, audit evidence collected over months. This is depth work. A generalist doing it part time will do it part badly, through no fault of their own.
• Work no human should touch twice. Provisioning a new account, revoking a leaver's access, sending the access-review reminder. Same input, same output, every time.

The mistake is asking your two or three people to own all three categories at once. That is how the founder ends up answering questionnaires at midnight: the deep work and the repetitive work both land on the person who should only be doing the judgment work.

A security program you cannot staff is not too ambitious. It is pointed at the wrong unit. The unit is the work, not the org chart.

Once the work is sorted, the staffing answer falls out of the category, and almost none of it is a full-time security hire.

The repetitive work gets automated and then ignored on purpose. When someone joins, their accounts, groups, and device enrollment should provision from their role, not from your memory. When someone leaves, access should revoke on the effective date on its own. Microsoft documents how Conditional Access in Microsoft Entra ID can enforce sign-in rules without a person standing guard. You are likely paying for that capability already.

The depth work gets routed to people who do it all day. Detection is the clearest case: Amazon GuardDuty will produce findings around the clock, as AWS describes in its GuardDuty documentation, and findings nobody reads are a cost, not a control. Someone has to triage them with judgment. That someone does not need a desk in your office; they need to see the patterns every day across many environments.

The judgment work stays with your people, protected. First response, vendor calls, the decision about what is truly urgent this week. That is where a small team's context is an advantage, and it is exactly what gets crushed when the other two categories pile on top of it.

Worth saying plainly: if you carry a specialized risk profile or want to build a security function in-house and grow it, a dedicated hire may be right. For the long middle stretch, staffing by category beats staffing by salary.

Go back to that folder where the plan is sleeping. The reason it never started was never your discipline. It was that the plan was written for a team you do not have, and you tried to either hire your way to it or feel guilty for not doing so. Neither moves the work.

The version that runs is built around the people in the building right now. Your team owns the judgment. The repetitive work runs itself and leaves a record while it does. The depth gets routed to people who live in it daily, using tools you are already paying for. None of that waits on a hire or a round. It is a program sized to the company you are running today, which is the only company a program can protect.

So here is the question worth sitting with: if you designed your security program around the people you have, not the ones you keep meaning to hire, what would you stop carrying yourself by Friday?