Most Security Controls Assume a Team You Don't Have

TL;DR: Security checklists are written either by vendors selling tooling or by people whose job is to avoid blame, and neither author is ever penalized for recommending a control a five-person startup can’t staff. A control you can’t run is worse than no control, because it teaches the team that security artifacts are theater — a lesson that generalizes to the controls that actually matter. This is the pre-hoc companion to what I check when I inherit a vibe-coded app (post-hoc: what’s already broken) and what enterprise reviewers ask you (buyer-driven: reacting to someone else’s checklist). This one is proactive, regardless of whether anyone’s asking yet — which four controls to defer and at what headcount they stop being theater, and the three-part test for telling a real control from a paper one.

The asymmetry nobody names

Open any “AI security checklist for startups” published in the last year and count the items. They only ever go up. Nobody publishes a checklist that says “drop these five, they’re not worth it at your size” — because the two kinds of people who write these documents have no incentive to say that.

The first kind sells tooling. A checklist item that maps to a product category is marketing with a bow on it; a checklist item that says “skip this until you have 30 engineers” sells nothing. The second kind is avoiding blame — a security lead, a consultant, an auditor writing for an audience of one imagined future incident where someone asks “was this on the list.” Adding an item costs the author nothing. Leaving one off costs them everything if it’s ever the item that mattered. So the list only grows, checklist over checklist, because the asymmetry is structural, not personal — nobody in that chain is rewarded for saying “no.”

Aikido’s “State of AI in Security & Development 2026” is a fair example, and I want to be clear it’s a genuinely good document — the underlying survey (450 CISOs, AppSec engineers, and developers across the US and EU) found 69% had identified a security vulnerability introduced by AI-generated code, and 20% had suffered a serious incident linked to it. Those are real, useful numbers. But the checklist built around them assumes an AppSec function, a platform team, and a training function to hand items to. Fencer’s 8-item founder checklist makes the same assumption in smaller print, written for a founder who has — or is assumed to have — someone to hand each item to.

None of this is an argument against the underlying advice. It’s an argument that the advice was never priced against your staffing, because the people writing it don’t pay the bill when you follow it and nobody’s there to run it.

What a paper control actually costs

The instinct is to read “adding a control I can’t staff is worse than not having it” as hyperbole. It isn’t, and the mechanism is specific.

Attention is the scarce resource at a five-to-fifteen-person company, not risk tolerance. Every control you adopt is a claim on someone’s attention forever — not once, at setup, but every week it exists, because a control nobody’s watching drifts out of date, and a stale artifact is worse than an honest absence. A prompt-provenance log nobody reads is a line item in a runbook that says “check the log” during an incident, written by someone who’s about to discover the log stopped being written to three months ago. Nobody caught it, because nobody’s job was to catch it.

That’s the mechanism I’ve written about from the trust side in psychological safety as a security control — a control’s value depends entirely on whether the humans around it treat it as real, and a team learns what’s real by watching what gets enforced versus what gets checked off and ignored. A dead control doesn’t just fail to help; it actively trains the team that the category — security paperwork — is decorative. That lesson doesn’t stay contained to the one dead control. It generalizes to the rotation policy that does matter, the incident review that does matter, because the team has already learned that this kind of document doesn’t get read.

The four to defer — and where each one turns real

Deferring isn’t skipping. Each of these becomes worth adopting at a specific point, and the point is almost always “a specific person’s job now includes this,” not “we bought the tool.”

Prompt-provenance inventories. Logging which model, which prompt version, and which agent produced a given piece of code or a given customer-facing output is good practice — once somebody’s job includes reading it back during an incident. Below that, it’s a table nobody queries, growing forever, that gives false comfort in a postmortem where the actual question — “what changed and who approved it” — still gets answered by grepping git history because that’s the log that was actually maintained. The threshold: adopt it when you’ve named the person who opens it when something goes wrong, not before.

Separate workforce and customer production environments. Splitting the environment your team touches from the one customers’ data lives in is a real control against a real failure mode — an internal tool with broad access becoming the path into production data. It also requires a platform team to build and run two environments instead of one, with the deploy pipelines, access boundaries, and on-call coverage that implies. At five engineers, that’s a second infrastructure project competing for the same three people who are also shipping the product. The threshold: when you have someone whose job is platform, not “whoever’s free.”

A formal secure-prompting training program. Teaching engineers what not to paste into a prompt, how to handle a customer’s data in an AI-assisted workflow, what “never trust frontend input” actually means in practice — all real. Below roughly 30 people, it’s not a curriculum, it’s a conversation, and pretending otherwise means someone builds slides nobody revisits while the actual transmission mechanism — a senior engineer correcting a junior one in a PR comment — keeps doing the real work uncredited. The threshold: when onboarding stops being one person walking the next hire through it in an afternoon.

An internal catalog of pre-vetted security building blocks. A library of approved auth patterns, sanctioned secrets handling, blessed API client configs that engineers pull from instead of reinventing — genuinely valuable, and genuinely a platform-team output. Below that, “the catalog” is one file that goes stale the week after someone writes it, because no one owns keeping it current against what the codebase actually does now. The threshold: when a platform team exists to own artifacts as a job, not a project.

None of these four are wrong ideas. They’re right ideas with an unstated staffing precondition, and the checklist that recommends them never states it because the person writing the checklist doesn’t have to run it.

Do assurance levels matter under 20 engineers?

Mostly no — the five-level maturity ladders common in this space collapse under 20 engineers to one real question: does this code path touch auth, money, or customer data? If yes, it gets real review regardless of what tier the framework says you’re supposed to be at. If no, the five-level model is measuring a distinction that doesn’t exist yet at your size — you don’t have five people to staff five maturity levels, you have one review discipline, applied selectively to the paths where being wrong is expensive.

This isn’t an argument against assurance frameworks in general — they’re built for organizations large enough to have separate teams operating at separate maturity levels simultaneously, which is exactly the condition a pre-Series-A company doesn’t have. Importing the ladder without the org chart that makes it meaningful just produces a scorecard nobody’s accountable for filling in accurately.

The short list that isn’t optional

A handful of controls don’t get the “defer until you’re bigger” treatment, because the failure mode they prevent doesn’t wait for you to staff up — Base44’s authentication bypass, found by Wiz Research’s Gal Nagli and disclosed in July 2025, patched within roughly a day with no evidence of exploitation, existed because a guessable application ID was the only thing standing between an unauthenticated request and a full SSO bypass into private enterprise apps. That’s a fundamentals problem, and fundamentals don’t scale down. If you’re leaning on a frontend check as your actual security boundary, read what Lovable’s own docs say about it: the frontend “runs in the user’s browser, is always public, and must never be trusted.” I’m not going to re-argue the specific line items here — secrets management for agent-driven workflows covers the credential-handling piece, and enterprise security reviews for AI startups covers what a serious buyer is actually going to check. Both stay non-negotiable at any headcount. If you’re finding gaps like these after the fact instead of heading them off, what I check when I inherit a vibe-coded app covers the secrets-and-git-hygiene audit for a system already in that state.

If you’re trying to work out which of the two lists — defer, or non-negotiable — a specific control you’re staring at belongs on, the triage tool runs the same reasoning against your actual headcount and stack instead of a generic checklist’s assumptions.

The test

You don’t need a framework to tell a real control from a paper one. You need three names, and if any of the three is blank, the control is paper:

A control is real if you can name three things: the person who runs it, the artifact it produces, and what happens when it fails. If any of the three is blank, it is paper.

“Everyone’s responsible for security” fails the first name — everyone means no one, and the control has no owner the day it actually matters. A dashboard nobody’s job includes checking fails the second — an artifact that exists but that no process consumes isn’t a control, it’s a screensaver. A rotation policy with no defined response when a key doesn’t get rotated on schedule fails the third — a control with no failure mode is enforced in name only.

Run every item on whatever checklist you’re currently working through against those three questions before you adopt it. The ones that pass are worth the attention they’ll cost. The ones that don’t are worth naming out loud as deferred, with the headcount or hire that flips them real — which is a more honest artifact than a document that quietly went stale six months ago.

Where this fits with hiring the person who’d actually run these

Most of what turns a paper control real is a person whose job description includes it, which is the same tradeoff I’ve written about in security engineer or vCISO as the first security hire — the sequencing question of when a fractional or full-time security role stops being premature and starts being the thing that converts your deferred list into a real one. And the deeper version of “who actually enforces a control” is the trust question, not the tooling question — covered in trust as the operating system.

If you’re staring at a vendor checklist and trying to figure out which four to defer and which are non-negotiable regardless of your headcount, that’s exactly the conversation worth having before you adopt any of it wholesale. Let’s work out which controls are real for where you actually are.