New: The startup CTO's field guide to running security
Read the guide
Many startup CTOs run security as a separate program and watch velocity slow down. Here's how to budget it as part of engineering capacity instead.
By Tim Olshansky, Co-founder, Fencer
Engineering capacity at a startup is finite, and security is one of the things asking for a piece of it.
Many CTOs run security as a separate program from product work and watch product velocity slow down. At my last startup, I started treating security as part of engineering capacity instead, budgeting it alongside features, infrastructure, and tech debt.
This post walks through how to size that bucket, prioritize what's in it, and avoid running security as a parallel program to product.
The usual posture, at companies without a dedicated security team, is to treat security as a side workstream. Here's what happens:
Both your product and your security progress end up behind plan.
Bandwidth gets the blame, but the framing is what creates the chaos. Security is the operational side of building software.
The same way DevOps shifted onto engineering teams over the last fifteen years, security has shifted with it. You build the software, you operate it, and securing it is the operational side of the same work.
Every fix is a few lines of code, a config change, a toggle in a console. It's all the same work. You're just routing it through a different bucket and pretending it's distinct.
This holds until you're big enough to hire a security team or a dedicated CISO. Until then, it's engineering work.
Every engineering team is making the same allocation decision quarter after quarter: how much capacity goes to shipping new features, and how much goes to everything else.
The "everything else" bucket holds:
That bucket has a name in my head: the technical work bucket. It's the slice of capacity I'm not pointing at the next customer-visible feature. Security is one of the things inside it, alongside everything else competing for the same hours.
You don't have to decide "is this security work or product work" every time something hits the queue. You decide how big the technical bucket is this quarter, and what's getting prioritized inside it.
The right size depends on the stage of your company, and getting it wrong in either direction is expensive.
Whatever you land on, name the percentage, write it down, and revisit it at the start of each quarter so it doesn't drift.
A bucket size you've decided is one you can defend. A bucket size that emerged through accident isn't.
Inside the technical bucket, security itself flexes quarter to quarter based on what's surfacing.
Running this at Zenput, the security portion of the bucket ebbed and flowed. Some quarters we'd use 10% of capacity fixing security issues that had piled up because a pen test had come back or an audit was coming up. Other quarters, once the work was done, we'd drop to 2% and put the rest of the technical bucket toward infrastructure or platform work.
Don't lock in a fixed "security tax" as a percentage of engineering. It implies the work is constant, when in practice security operations have a natural cadence. Budget the bucket once, then let the slice inside it respond to reality.
Allocate the work, not the worry.
If nothing critical is surfacing, don't manufacture security work to justify the bucket. The capacity that isn't going to security in a quiet quarter goes to other technical work that's been waiting.
Even with a sized bucket and a priority threshold, things happen that aren't in either. A major supply chain breach forces you to upgrade dependencies or switch libraries on a deadline. Credentials get exposed and you have to rotate secrets across the stack. A critical CVE drops on a library you've been running for years.
These don't slot into a quarterly plan. They're the kind of work where the budget for them is "whatever it takes, starting now."
Build reserve capacity for them into your bucket sizing. If your sweet spot is 20% technical work, plan as if it's 18%, with the remaining 2% as buffer for the unplanned. When the buffer goes unused, that capacity rolls into the next quarter's plan. When something does pop, you can absorb it without scrambling outside the cadence.
The team needs to know this slack exists. Otherwise the first time something major hits, they'll treat the response as a brand-new fire drill instead of the kind of work the capacity model already accounted for.
The hardest part of any limited-resource environment is deciding what gets your attention first. For security, the trick is to set a prioritization threshold up front, ideally in writing, so you don't have to debate it case by case.
My threshold has three tiers:
Articulating the threshold removes the debate. Critical findings get fixed; middle findings get sequenced later; low findings get ignored. You're not relitigating priorities every time something hits the queue.
When something genuinely ambiguous lands, hire someone to try to hack you.
You walk into the head of product's office and say "we had a pen test, they got customer data out by doing X, we need to fix it." I've never had anyone in my career push back on that kind of issue.
The threshold tells you, by design, what doesn't deserve fire-drill energy. Critical findings get the urgency they merit; most findings don't.
At companies that run security well (Zenput was one), there isn't a critical issue every day or every week. If you're treating every finding like a three-alarm fire, you risk burning out the team, and after a few cycles they may stop responding when there actually is a fire to put out.
Setting the priority bar and modeling the right energy is part of the CTO's job.
Treating security as a product exercise means you plan it, sequence it, and ship it like any other engineering work. You set the technical bucket's size, you name the priority threshold, and the work gets sequenced from there.
It protects velocity, and it protects the team from burnout. The alternative, running security as a side workstream, pulls capacity unpredictably, generates fire drills, and trains the team to expect chaos.
Capacity allocation is one of the topics I cover in more depth in a longer field guide I wrote for the CTO who's just inherited security and is figuring out how to run it without trading it against product: Startup security: a field guide for startup CTOs.
It covers what to do before any of this gets serious, what to put in place first, where the duct tape starts to wear when the stack outgrows the manual approach, and a few other things I wish someone had handed me while I was a CTO owning security on top of everything else at my last startup.
