
Enterprise Security Demands, Startup Budget: How to Meet the Bar Without a Security Department
By Tom Lang on September 17, 2025
I'm Tom Lang — I've built and scaled engineering organizations for three decades, through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.
Most writing about "AI security" is about adversarial machine learning — data poisoning, model evasion, stealing a model by querying it. It's real, and if you're an AI lab it matters enormously. But it is almost never the security problem a growth-stage company actually has.
The security problem you actually have looks like this: a big customer you badly want to close sends over a security questionnaire, or a vendor-risk review, or a flat "are you SOC 2?" — and you're a small team with no security department and a product to ship. Suddenly enterprise-grade security is a sales problem, and the clock is running.
I've been on the small-company side of that more than once, including taking a SaaS platform all the way through SOC 2. So let me tell you how I actually think about it — and why the first move is not to go buy security tools.
"Enterprise security requirements" is not one thing
Here's what almost nobody says out loud: there is no single, consistent bar that comes through the door. Every request is specific to the customer making it — their industry, their risk appetite, their own auditors, their particular questionnaire. And it's equally true that you, the company being asked, are always somewhere along the road to meeting it — never at zero, never fully there.
Which means the plan you need can't be written until you understand two things:
- What is this specific customer actually asking for? Not "enterprise security" in the abstract — the actual controls, evidence, and standards this customer requires to say yes.
- Where do you actually stand against it, honestly? A clear-eyed read of what you already do, what you sort of do, and what you don't do at all.
The gap between those two is your plan. Everything else — the tool you almost bought, the framework someone told you to adopt — is guessing until you've done that. Anyone who hands you a generic "enterprise security checklist" before understanding the specific ask and your specific starting point is selling you theater.
A small company can clear a serious bar
Here's a concrete one. I architected a SaaS platform for a company whose growth depended on clearing a serious external bar — SOC 2, both Type I and Type II. That's not a small ask for a small company; SOC 2 Type II in particular isn't a checkbox, it's an auditor verifying that your controls actually operated, over time. We got there — not by standing up a Fortune-500 security program, but by understanding exactly what the audit required, taking an honest inventory of where the platform stood, and closing the specific gaps between the two.
The lesson I took from that, and from years of running my own firm's security while serving insurance, healthcare, and government clients: a small team absolutely can meet a serious security bar. You do it by closing real gaps against a real requirement — not by buying a pile of tools and hoping they add up to "secure."
Doing it right — without waste or theater
So when the questionnaire lands, here's the posture I'd take:
Answer it honestly. This is the one I'll die on. Never claim a control you don't actually have. It's tempting when a deal is on the line, but overclaiming is how you lose — the customer's auditors will find the gap, and now you've lost the deal and the trust, and possibly created a liability you'll regret. A truthful "we don't do that yet — here's our plan and timeline" beats a confident lie every time, and serious buyers respect it.
Buy less than you think. Most small companies under security pressure over-buy tools — a wall of dashboards nobody watches. Controls that are actually operated beat tools that are merely purchased. Spend on the few things that genuinely reduce risk and satisfy the specific requirement; skip the rest.
Right-size to the company you are. A ten-person company should not run a five-hundred-person security program. Meet the bar this customer needs and reduce your real risks — no more, no less. Security theater is expensive, and it doesn't actually make you safer.
What about the AI in your product?
If AI is in your product, does that change the security picture? Sometimes a lot, sometimes barely at all — and the honest answer is that it depends, in a specific order.
It depends on your industry first — a health or financial product carries obligations a hobby app never will. Then on what the product actually does, and what data it handles. Work it in that order and the concerns sort themselves:
- Data first. What data are you handling — and, the AI-specific twist, does any of it leave your boundary to go to a third-party model provider? That single question resolves most of the real risk.
- Access and use second. Who can do what, and how is the AI actually used in the product, and by whom?
- Everything else third. The adversarial-ML material — poisoning, evasion, model theft — is real, but for most growth-stage products it's a distant concern, not a first one. Don't let it crowd out data and access, which are where your actual exposure lives.
Sometimes, when you work through it, there are almost no new security issues at all. Sometimes there are tons. The point is to find out which by looking at your data, access, and use — not by importing a lab's threat model you don't have.
The honest version
Meeting enterprise security demands as a small company isn't about the biggest stack or performing sophistication for the questionnaire. It's three things: understand what this specific customer is actually asking, know honestly where you stand against it, and close the gap with the controls that genuinely matter. Do that, and you can clear a serious bar — I've taken small platforms through SOC 2 — without a security department and without theater.
If a big customer's security requirements just landed on a small team and you're not sure where to start, that's exactly the kind of thing I help with. Book a call and we'll look at the actual ask and where you actually stand.
← Back to Our Insights