New: The startup CTO's field guide to running security
Read the guide
By Tim Olshansky, CTO and co-founder of Fencer
Practical lessons on running security when you become your startup's de facto CISO.
On this page
Stay in the loop
Get the next field guide
Notes from Tim on running engineering and security at startups.
Introduction
Welcome to the gig. You're already running engineering and shipping product, and security has joined the pile. As CTO, you're the de facto CISO until you're big enough to hire one, whether you like it or not.
At Zenput, the company I was CTO of before co-founding Fencer, that meant building and running the security program while I was also building the engineering team and shipping product. I picked the tools, integrated them, ran them, and led us through SOC 2.
I'm writing the guide I wish I'd had then. By the end you'll know when security stops being a someday problem, where your hours actually go when you're the one doing the work, what to put in place first, and how to keep the operation running without trading it against product (or losing your engineers to burnout).
%201.png)
Tim Olshansky
Co-founder, Fencer
Chapter 01
Security is always part of the CTO's job at first; what varies from startup to startup is when security moves into the foreground. For some businesses, that moment arrives on day one. For others, security sits in the background until something forces the issue. Here's how to know which one you are.
With some businesses, security can't sit in the background. The test is usually one of three things:
In cases where the data isn't regulated and the buyer doesn't see much risk, such as an entertainment app or an iPad tool that helps a restaurant track when the bathrooms were last cleaned, you can let security sit in the background for a while longer.
The obvious trigger is the bad one. If you've had a breach, security has already become the priority. The harder ones to recognize are the triggers that don't announce themselves, and in my experience they come in one of two forms.
My first startup, Topguest, was marketing technology for travel, and we gave away reward miles for taking certain actions. People figured out how to game the system with fake accounts and other tactics. The fraud became material enough that we had to invest engineering time into finding and stopping it, which meant bringing security into the foreground. Nobody was forcing us to do that work. The business was.
At Zenput, we sold to Fortune 500 and Fortune 1000 companies, and security showed up as a sales blocker in concrete ways:
Multiply that delay across the pipeline and security stops being something you'll get to when you have time. It becomes the reason you're missing your quarterly number.
The same pattern showed up earlier in my career, just further upstream. At Worksite, we sold to energy companies, major engineering firms, and construction companies, and their RFPs had explicit security requirements built in. If you couldn't address them up front, you didn't get on the selection list. Security wasn't slowing the deal; it was gating whether you'd be considered as a vendor at all.
Whichever way it lands, once security is the variable holding up revenue, it stops being optional.
The instinct when this pattern hits is often to chase a certificate that helps you meet buyers halfway. In B2B SaaS, that's usually SOC 2. I advocated for it at Zenput even though no customer was demanding it at the time, because I was tired of answering questionnaires from scratch and I saw the certificate as a way to clear most of the standard questions in one shot.
It didn't eliminate questionnaires entirely, but it did help us answer nearly all of a 300-question questionnaire with "yes, see our SOC 2 report," and let the reviewer go read it and come back. It was a leverage play.
It's worth noting that SOC 2 has become common enough that on its own it's no longer much of a signal, and the savvier buyers trust the report less because plenty of companies get certified without doing the work behind it.
A whole category of third-party risk management tools has also popped up. They send standardized questionnaires to vendors, use LLMs to grade the responses, and many won't let you opt out of a question by pointing to a SOC 2 report.
For most buyers today, SOC 2 gets you through the door to the next stage, but it doesn't get you past the questionnaire.
Chapter 02
So if SOC 2 doesn't get you past the questionnaires, where do you actually start? Not by going straight for the certificate, and not by buying a stack of tools. Start with discovery: figuring out what security needs to do for your business. A compliance framework may still be the right thing to anchor to, but it works because of the discovery, not in place of it.
Step one is gathering information: where security plays in your organization, what it affects, and where the concern is coming from across the executive team, the board, or the founders. That concern is usually one of three things: reputational risk, business risk, or specific deals at risk. The specific reason you're sitting here is the input that shapes everything that comes after.
Some questions to walk through:
The questions above are about where signals are already showing up. There's a second layer to walk through that's about the business itself:
The technical questions (what stack you're on, how it's built, what your network footprint looks like) matter, but they come after this layer.
The point of discovery is to figure out how much security your business actually needs before you start matching that need to tools.
Most startup CTOs don't have time to design their own security framework, and in the early stages it isn't the most crucial part of the business to be spending time on. That's why the highest-ROI move is to anchor your program to an established industry standard rather than build one from scratch. (The only case where I'd say otherwise is if you're already deeply familiar with your own threat model and have the expertise in-house to make security decisions without leaning on a framework. That's a small group, and if it's you, you already know it.)
Aligning to a standard will get you 80% of the way there for what you need, and you can spend your time on the remaining 20% that's specific to your business. That's a better use of your hours than building something from first principles. It also gives you a clear roadmap, a shared language with auditors and managed service providers, and clarity on what to do next.
The standard you select will depend on your business:
By aligning with a recognized standard, you meet the "minimums" of most Fortune 500 companies quickly and force standard requirements on the organization before the enterprise prospects arrive with security questionnaires.
With your standard chosen, the next move is putting the baseline tooling in place to meet it. Some of those tools are non-negotiable; almost all of them are far easier to put in place when you're small than to retrofit later.
Chapter 3
There's a baseline set of tools every startup needs in place. The depth and sophistication of each will differ by stage and industry, but the presence of them shouldn't.
If you're in a heavily regulated industry like healthcare and you're handling PHI, add data security tooling to that list. The visibility helps you avoid the rookie mistakes that happen when you're moving fast and nothing is paying attention.
A few of the items on the list deserve a closer look, because they're the ones where I've watched startups (mine included) get burned by skipping or deferring them.
It is much, much harder to add secrets management later than to do it at the very beginning, and people still get it wrong constantly: secrets committed to source code, secrets in unprotected environment variables, secrets sitting in the cloud console. Invest in separating your configuration from your code early and make it easy to inject while your application is running.
There's a tendency to believe that because you're built on Vercel and Supabase and your code was written by Claude using Claude Code, security is no longer something you have to worry about. That's completely and utterly false. The platforms harden a layer of the stack for you. They don't harden how you're using them.
When I joined Zenput at thirty people, the gap I felt most was visibility into where we had security issues. I brought in SonarCloud to give us at least some signal at the point we were writing code. It's the brush-your-teeth-for-two-minutes-a-day kind of stuff that compounds over time.
A lot of CTOs have a visceral fear of implementing it, usually because of bad experiences at other companies. It's not worth spending social capital fighting against. The tools exist, they're easy to use in 2026, and they're cheap. You'll also need to explain to customers why you haven't implemented one if you skip it, which is its own kind of pain.
Cloudflare is cheap, very flexible, and has great capabilities for defending your application from lots of common threats. Use at least the basic rules, and don't get cute: fix any errors if it's preventing your app from working. If you're exclusively on a hyperscaler, then use their technology with their baseline rules. It takes minutes, checks lots of boxes, and provides real security coverage.
You might think that having New Relic, Datadog, or some other application performance monitoring tool covers you for the various Logging and Monitoring controls that a security standard or framework references, but you'd be wrong when it matters most (in the middle of a security incident). SIEMs can be expensive when you're small (it's one of the reasons why we built the Security Monitoring capabilities into Fencer), so consider working with a managed security services provider to do the monitoring for you.
A meta-point worth holding onto: it's much easier to get all of this in place when you're small than when you're not. When you're a team of 100 engineers trying to retrofit a code security tool and it surfaces 5,000 findings, of which maybe 1,000 are actually legitimate, that's a lot of work. When you're a team of five doing the same exercise, the volume is manageable and you start with a clean baseline.
More from Tim
Get the next field guide
Notes from Tim on running engineering and security at startups.
Chapter 4
Once the foundations are in place, the work shifts from setup to operations. The challenge is keeping security operations running without trading off product velocity or burning out the team. Here's how I think about it.
Carve out some time to be proactive about security. Security is one of the many things that lives inside the technical work bucket of your engineering capacity. The trick is to set the right size for that bucket.
At the earliest stage, when you're going to be dead in six to twelve months if you don't ship new features, the bucket is small. Maybe 10% of your capacity will go to purely technical work, and 90% to features.
As you mature, the bucket grows. My sweet spot is 20 to 30% of engineering capacity going to technical work, with standard security work prioritized inside that block. Less than that and technical debt compounds faster than you can pay it down; more than that and you're under-investing in the product.
Running this at Zenput, the security portion of that block ebbed and flowed. Some quarters we'd spend 10% of capacity fixing security stuff; others, once the work was done, we'd drop to 2% for the rest of the year.
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.
A basic threshold to consider has three tiers:
Or if you want to more explicitly define your priorities, here's what I recommend (tweaking the numbers based on your size and stage):
Articulating the threshold removes the debate about what gets done and when so you're not relitigating priorities every time something hits the queue.
When the team can't decide between competing priorities, the easiest thing that breaks all ties is hiring somebody to try to hack you. A pen test will tell you, in concrete terms, what an attacker can actually exploit.
Critical findings from a pen test almost never get pushback. 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 pen test takes the ambiguity out: either something is exploitable or it isn't, and when it is, the prioritization argument falls into place around it.
Engineering teams usually split into two psychological camps when security findings surface. Your job is to leverage these personalities without causing burnout.
What I learned at Zenput is to lean on the perfectionists for the security work itself, and use the pragmatists as a sanity check on whether we were over-investing. That mix worked better for me than trying to assign security as a rotating responsibility across the whole team.
Critical findings deserve fire-drill energy; most findings don't. At companies that run security well (Zenput was one), there typically 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.
There will be parts of the program you can't realistically run with the team you have. The right move in those cases isn't to leave the gap open, and it isn't to buy a tool you don't have the time to tune. It's to bring in a managed service provider who owns that capability for you.
At Zenput, we couldn't afford Splunk on our own, and even if we could, we didn't have the time to build and tune the detection rules. So we hired an MSP that owned the SIEM license, ran the tuning, and sent us a weekly report. We traded a recurring cost for a capability we wouldn't otherwise have had, and we got our time back to spend on the work only we could do.
The same pattern shows up later for things like pen testing, GRC operations, and on-call rotations. If the choice is "we'll get to it eventually" versus "an MSP owns it next week," the MSP wins almost every time at this stage.
Chapter 5
The last few years have changed the security calculus for startups in three ways at once, and the three changes are converging into something different from anything I had to manage at previous companies.
The fundamentals from earlier chapters still apply. This chapter is the extra layer of considerations the AI shift forces every startup CTO to take seriously, no matter how small the team is.
The implication for the CTO is straightforward: you can't defer security on the basis of being small. That bet has gotten more expensive, and the math has flipped against you.
The customers you're selling to know this. Buyers, especially in the upper mid-market and enterprise tiers, are getting attacked themselves, and they're more sensitive to it. The expectations they bring to a vendor security review are rising, the questions they ask are more specific, and the questions about how you handle AI in your own product are getting more pointed. None of that is going to slow down.
The existing attack surfaces of open source dependencies, running application infrastructure, and cloud configuration are still there, and the fundamentals chapter covers how to address them. AI has introduced four new attack surfaces worth understanding alongside them.
Skills and prompts are text files that tell something with a lot of access to your system what to do. The marketplaces around them are immature, and someone not deeply focused on security can read a shared skill and believe it's safe when it isn't. Treat shared prompts and skills the way you'd treat any third-party code you didn't write: with skepticism, and ideally with a review before you put them in front of an agent that has access to your systems.
Prompt injection is the AI version of phishing. Instead of tricking a human into clicking a link, an attacker crafts input that tricks an LLM into ignoring its guardrails and acting on instructions it shouldn't. Model poisoning is a related concern at the training stage. These attack types didn't exist as practical concerns five years ago. They do now, and if your product uses an LLM in any capacity, you're exposed to them.
Agents sometimes hallucinate package names. If a particular agent consistently invents the same fake dependency, an attacker can register that name with malware inside, and your agent installs the malware on your behalf. It's a new flavor of typosquatting, automated by the very tool that's supposed to be helping you ship faster.
When you ask an LLM to set up cloud infrastructure for you, it'll often misconfigure it. The misconfiguration becomes a security hole the same way an unsafe IaC template would. AI-generated infrastructure needs the same review as AI-generated code.
The bigger concern isn't any one of those surfaces: it's the agent itself, when it has too much access. Think of it as having an easily phished executive on the team. The agent has elevated permissions, the ability to act on its own, and a steady stream of untrusted input flowing through it from users. That combination, without any boundaries, is the most dangerous pattern in a 2026 startup engineering team.
The lethal trifecta looks like this:
If you have all three at once and no constraints, you've built an insider threat into your own development environment.
The defense isn't to stop using agents. It's to constrain what each agent can touch. That means:
The fundamentals from Chapter 3 still apply, and a few of them matter more now than they did before AI:
That last point is the silver lining. The same tools that attackers use cheaply against you, you can use cheaply for yourself. The advantage in 2026 goes to whichever side has better visibility into what needs to be fixed.
If you're using a vendor's product that has agentic capabilities, ask hard questions about how they secure it.
I've had conversations with prospects who told me that one of their most critical vendors, doing something absolutely essential to their business, had told them they thought security was a joke and did nothing about it. That's not a defensible position in 2026.
The bar for a vendor's AI security posture is rising. The questions you should be asking:
Your buyers are going to start asking you these same questions. The vendors you trust should be able to answer them in detail.
Three patterns I've seen from startup CTOs that are worth flagging directly.
This was true once. It isn't anymore, and acting on outdated memory here costs you.
The same LLM that generates code can't be the verifier of that code. Even the smartest team members introduce flaws and need someone else to check their work. You can't blindly rely on Claude Code security running on code that Claude itself wrote to verify that Claude was secure. The Stanford 15% figure is the proof point. Use AI to help find issues, but don't let it be the only thing looking.
This one feels good because it saves a hundred bucks. The cost of a missed vulnerability is much higher than the cost of a security tool subscription, especially in a year when low-severity vulnerabilities are trivially exploitable with some clever prompting. Your peace of mind for a small amount of money seems like a no-brainer trade to me.
Things move a lot faster now than they did a year ago, and they'll move faster again a year from now. The "wait and see" posture has gotten expensive, and the cost is going to keep rising.
The rest of this guide still applies. AI doesn't replace the fundamentals; it adds a new layer of considerations on top of them. The good news is that the same tools you have to defend with are getting more capable too. The leverage matters for whichever side picks it up first.
Chapter 6
By the time the security fundamentals are in place, you've probably got 7 to 10 point solutions stitched together: scanners for code and cloud, an MDM, a secrets vault, a GRC tool, and a couple of free scanners running on the side.
This setup will get you a long way, but it won't last forever. Past a certain point, the duct tape between the tools starts to wear, and the stack you built to move fast can become the very thing slowing you down.
The three patterns below are the ones that wore me down most at Zenput, and they're a big part of why I co-founded Fencer. Here's what each one looks like, and what to do when you see it.
It starts innocently. A vulnerability scanner over here, a code quality tool over there, a CSPM looking at the cloud, and a few one-off reports that need to be reconciled. At some point, the only way to make sense of any of it is to dump exports from all of them and cross-reference in a spreadsheet.
At Zenput we had this exact ritual. I'd transform CSVs because half the time the export wasn't clean, collate everything into a master spreadsheet, and walk through it with the team every month. What's a duplicate, what's noise, what we're addressing by Friday, etc.
What I didn't see at Zenput until I was deep in it: 90% of my security hours went into figuring out what to fix. Only about 10% went into the fixes themselves, which were almost always small (a few lines of code, a toggle in a console, a new IAM rule) and quick once we'd decided what to do.
Tighten what you look at. Suppress whole categories of findings that aren't producing actionable signal, and raise the bar on your prioritization threshold. That buys time. But the ritual itself is structural. It's a sign your stack has outgrown what cross-referencing by hand can hold together, and the next move is either dedicating a person to it or moving to a platform that consolidates findings for you.
Native cloud tools and free scanners generate findings constantly: container CVEs from base images you haven't upgraded, misconfigurations from defaults nobody changed, alerts from rules that haven't been re-tuned in months. There is signal in there, but it gets buried under everything else the tools want to tell you.
A lot of my hours at Zenput went into deciding which findings to suppress, which to triage, and which needed a person. That isn't security work. It's the maintenance you do to keep the apparatus running while you wait for the thing you need to act on to surface above the noise.
Tune in batches, not one finding at a time. Take a half-day every quarter to suppress whole categories of repetitive findings rather than triaging them one by one. If you can afford it, a managed service provider can absorb this kind of work. What you can't realistically do is keep up by hand. If your weeks read like "tune three rules, suppress fifty findings, escalate two," the apparatus has stopped serving you and started consuming you.
The first time you go through SOC 2 or a comparable audit, you'll discover that every control needs evidence. Log retention policies, access reviews, change management. You'll have been doing most of these things. You won't have been documenting them in a form an auditor can review.
A meaningful chunk of audit prep, then, becomes retroactively producing evidence for work that was already happening. The work isn't the policy. The work is proving the policy existed in a format somebody else can verify.
Shift evidence collection upstream. Document what you're doing as you do it, not after the fact. A GRC tool like Vanta or Drata helps, but it works best when it has something to capture; it doesn't generate the evidence itself. If retroactive prep is the reality for your first audit, plan for it explicitly in your roadmap rather than letting it consume an unplanned month.
These patterns are what taught me what a platform built for this should look like. The moves I've described above buy you time, but they don't change the structural reality that the security tools we have today weren't designed to work together, and a small team ends up paying for that with their hours.
Fencer is what I would have built for myself at Zenput if I'd had the chance: one place to see findings across the stack, one place to make decisions about what to fix, and one place to produce the evidence somebody else will need to read.
Parting wisdom
Security work compounds. Every habit you build and every decision you make early pays back later, usually more than you'd expect. That's what taught me what a security platform should look like, and it's why I co-founded Fencer.
If you'd rather not cobble the stack together by hand, that's what we built it for.
Tim Olshansky
Co-founder, Fencer
Tim is President and co-founder of Fencer and a seasoned senior executive and entrepreneur. He served as Chief Product & Technology Officer at Crunchtime (after the Zenput acquisition), where he launched products serving safety and compliance-minded brands like Chipotle and Burger King; was CTO at Aconex (ASX:ACX, acquired by Oracle) working with security-conscious government agencies and contractors like the US DoD and Bechtel following the acquisition of his startup Worksite; among other successful exits and teams. He holds degrees in Law and Physics from the University of Sydney.
Fencer is full-stack security for startups. A single platform that replaces the patchwork of scanners, monitors, and spreadsheets growing startups cobble together: the duct-taped stack Tim describes in this guide.
It picks up where your compliance tools leave off: scanning across code, cloud, and infrastructure; threat detection through an integrated SIEM; vulnerabilities found, prioritized, and fixed.
One platform instead of ten. So you can spend your security hours where they matter.
Learn more →
