Most companies without a security team describe their situation as having no security. That's not quite right, and the distinction matters for what to actually do about it. What they have is security decisions being made constantly, by whoever happens to be touching the relevant code at the time — whether to log a sensitive field, how much a new integration should be allowed to read, whether an internal tool really needs to be reachable from outside the office network. Those decisions get made whether or not anyone is watching. What's missing isn't the activity. It's any shared, repeatable version of it that survives the one engineer who happened to think it through.
That reframing matters because it changes the goal. You're not building a security function from nothing. You're taking something already happening — informally, unevenly, invisibly — and giving it enough structure to be consistent and enough visibility to be reviewed. None of what follows requires a security title, a budget line, or a headcount request.
The short version: A "security team" is one way to get consistent security decisions. It isn't the only way, and for most companies without one, the actual failure isn't an absence of security judgment — it's that the judgment being exercised lives entirely in individual heads, isn't reviewed, isn't shared, and leaves the building when the person carrying it does. Fix the distribution problem and you've done most of what a small dedicated team would have done anyway.
Name an owner, not a hire
Someone at your company is already the person who asks the awkward question in review, who remembers the incident from two jobs ago, who notices when a PR adds an endpoint with no auth check. That person is doing security work without the title, and usually without any protected time for it — it happens on top of their actual job, which means it happens exactly as often as their patience holds out.
The cheapest structural fix available to a company with no security budget is naming that role explicitly and giving it a protected slice of time — often 10 to 20 percent — rather than leaving it as an unpaid, unacknowledged habit. This isn't a security engineering job. It's a facilitation and ownership role: keep the threat models current, run the recurring review cadence, be the person a confused engineer asks first. The title doesn't need to say "security" — "security champion," "the person who owns the risk register," or simply naming it in the team's own language all work. What matters is that the time is real, protected on the calendar, and known to the person's manager, so it isn't the first thing sacrificed under deadline pressure.
Attach it to rituals you already have
A standalone security process is a process people have to remember exists. A team without dedicated security headcount rarely has the discipline to sustain something that isn't already load-bearing for other work — which is exactly why it should never be standalone in the first place. Our shift-left post made this argument in the abstract: attach the model to the design document your team already writes, not to a separate security artifact nobody opens voluntarily.
The same logic extends past the design doc. A security-shaped section in the pull request template — did this touch auth, does it add a new external input, does it change what data crosses a trust boundary — turns review into something that happens by default rather than something someone has to remember to request. A recurring ten-minute slot in sprint planning to ask "does anything we're building this sprint change the diagram" keeps a model from going stale between the rare occasions someone schedules a dedicated workshop. None of this requires new infrastructure. It requires deciding that the rituals you already run will carry a little more weight than they used to.
Borrow a framework's authority instead of a title's
Without a security team, "because I think this is risky" doesn't travel very far in a room full of peers who don't report to you and have their own deadlines. "Let's run this through STRIDE" travels further, not because the framework is magic, but because invoking a named, external standard doesn't require organizational authority the way a personal objection does. Anyone can point at a checklist. Not everyone can unilaterally block a merge.
This is a genuinely underused lever for teams without a dedicated function. STRIDE, the OWASP Top 10, or a specific compliance framework your customers already ask about all function as borrowed authority — a shared vocabulary that makes "we should check this" sound like due diligence rather than one person's personal risk tolerance, which is often the actual difference between an objection that gets a hearing and one that gets steamrolled by the sprint deadline.
Make peer review carry the weight, explicitly
A dedicated security team's most basic function is a second pair of eyes with a specific, adversarial mandate — someone whose job is to ask "what could go wrong here" about work they didn't write. Without that team, ordinary code review has to carry that weight instead, and most teams never say so out loud, which means it happens only when the reviewer happens to be in a security-minded mood that day.
Making this explicit is a small, concrete change: a handful of specific prompts in the review checklist — does this endpoint check that the caller is authorized for the specific object requested, not just that they're logged in; does new input get validated before use; does anything here handle a secret. A generic "review this PR" leaves security-shaped bugs to chance. A checklist that names the two or three failure modes your codebase actually tends to produce catches far more of them, for the cost of writing the list down once.
Treat culture as a habit, not a poster
The failure mode worth naming directly: a security-awareness training video everyone clicks through once a year, a values statement in the employee handbook, a slogan on a slide at the all-hands. All of that is easy to produce and does almost nothing, because none of it is attached to a moment where an actual decision gets made. Culture, in the sense that changes outcomes, is a habit embedded in existing work — the PR template's question, the design doc's section, the ten-minute agenda item — not a statement of values layered on top of work that continues exactly as before.
The test for whether a security culture initiative is real: can you point to a specific artifact — a template, a checklist, a recurring calendar invite — that changed because of it? If the honest answer is "we talked about caring more," it hasn't become a habit yet, regardless of how well-attended the talk was.
Plan the first hire as a promotion, not an invention
Eventually, for many companies, the informal practice outgrows what a 10-to-20-percent owner can carry — a customer's security questionnaire demands evidence the part-time role was never built to produce, an incident needs a response capability broader than one person's calendar, or the owner is simply burning out under a load nobody sized realistically. That's the point to hire, and the useful framing is that the first hire scales a practice that already exists rather than inventing one from a blank page.
A company that has spent a year running real, if informal, threat modeling and review has something valuable to hand a new security hire: existing diagrams, an existing risk register, a review habit already embedded in the PR process, and a team that already expects security-shaped questions in review rather than treating them as new and unwelcome. A company with a values poster and no habits hands the same hire a blank page and six months of building basic credibility before any real work starts. The practice described in this article isn't a placeholder to run until you can afford a real team — done well, it's the foundation that makes the first real hire effective quickly instead of slowly.
Where this argument overreaches
The usual caveats, stated as plainly as everywhere else in this series:
- Some capabilities genuinely require dedicated expertise and cannot be distributed. A formal incident response function on call at 3 a.m., a real penetration testing program, deep specialization in a specific compliance regime — a part-time owner with 10-20% of their time is not a substitute for these, and pretending otherwise is how a company discovers the gap during an actual incident.
- An unprotected "part-time" role becomes an unpaid full-time one under pressure. Naming an owner only helps if their manager actually defends the protected time when a deadline gets tight — otherwise the role exists on paper and nowhere else, which is arguably worse than not naming it, because it creates the appearance of coverage that doesn't exist.
- This is a starting point sized for a company without dedicated headcount, not a permanent ceiling. As the company, its data sensitivity, and its regulatory exposure grow, the honest answer to "do we need a dedicated person" eventually becomes yes, and treating this framework as a reason to indefinitely defer that hire is a different mistake than the one this article is arguing against.
Regulatory frameworks increasingly expect evidence of who owns security decisions, even without a dedicated title -- see the industry threat modeling guides for what applies in fintech, healthcare, and critical infrastructure. The free templates are a reasonable way to start the first shared diagram this practice needs.