You've been building for a year, maybe two. The product is good, you have customers, you can see the momentum, and then a prospect that could actually change your trajectory sends you a note: "We'd love to move forward. Our security review team requires all vendors to hold an active SOC 2 Type II report."
You forward it to your co-founder. One of you Googles it. The first result is a software platform charging $24,000 a year. The second is a 47-step guide. The third is a law firm.
You close the laptop and go make a coffee.
We talk to founders in exactly this situation. Small teams who are very good at what they do and have never once thought about compliance frameworks. The deal is real, the timeline is real, and nobody has any idea where to start.
What most of those search results won't tell you: a two-person founding team can get through a SOC 2 audit. We have seen it. No dedicated security hire, no compliance background, no six-figure software budget. It takes work and a clear picture of what's actually required, but team size isn't the barrier most people assume it is. The path for a two-to-ten person company is just different from what the enterprise-focused guides describe.
What SOC 2 actually is
SOC 2 is an audit. A CPA firm reviews how you operate and produces a report. That report is what your prospect's security team wants to see before they sign a contract with you.
There are two types. Type I is a point-in-time snapshot: as of a specific date, these controls are in place. Type II covers a window of time, usually six to twelve months, and confirms you ran those controls consistently throughout. Enterprise buyers almost always want Type II eventually. Type I is a legitimate first step, and if you need to keep a deal alive while working toward Type II, that conversation is worth having directly with your prospect. Most security teams at larger companies have been through this with small vendors before and will work with you if you're visibly in process.
The audit covers what's called the Trust Services Criteria. Security is the only mandatory category. Privacy and availability are optional, and most companies skip them on a first audit.
"We're probably mostly compliant already, right?"
This is the most common thing I hear. "We use AWS, we're not sloppy about this stuff. We're probably close."
Maybe. But probably not close enough.
The gap is almost never the technical stuff. Your engineers are likely doing reasonable things. The problem is documentation. An auditor needs evidence, not just that you encrypt data at rest, but a written policy that says you do, and something showing the practice is actually followed. If it's not documented, it didn't happen as far as the audit is concerned.
The policies are almost always the biggest gap, and for an obvious reason: nobody had time to write them. You need an acceptable use policy, an access control policy, an incident response plan, and a data classification policy. None of them need to be long. They just need to exist and be findable.
Alongside the policies, access controls need actual evidence. Who has access to your production environment right now, when that access was last reviewed, and whether you can show it's limited to the right people. The auditor will also want to see your process when someone joins or leaves: does their access get provisioned and removed in a documented way, and is there a record? Security awareness training needs to exist in some form, even minimal, with dates showing employees completed it. And some kind of vulnerability management: a scanner and a documented process for reviewing what it finds.
That's most of it. Not 200 things. Closer to 30, depending on your setup. The technical controls often just need to be documented and made consistent. The policies usually need to be written from scratch.
The part that trips up nearly every small team
SOC 2 expects controls around who can make changes to your systems and who oversees those changes. The textbook model: one person requests a change, someone else approves it, someone else implements it. Works fine if you have 50 engineers.
If there are two of you, it falls apart immediately. Auditors know this.
They're not looking for a change control board from a two-person startup. What they want to see is that you've thought about it honestly, put something real in place, and written down what you're doing and why.
The most practical answer is required pull request approvals. GitHub and GitLab both let you set branch protection rules so nobody can merge code to your main branch without at least one other person signing off. Neither founder can push to production alone. Your PR history becomes an automatic change log showing who reviewed what and when. If you're not doing this already, set it up before your audit engagement starts. It's the single most useful thing you can do in an afternoon.
Keep a simple change log alongside it. A ticketing system or even a shared doc. The point is that changes are tracked: what changed, when, who requested it, who approved it.
For separation of duties more broadly, the concept you need is compensating controls. When a traditional control genuinely isn't feasible for a company your size, you document why, what risk that creates, and what you're doing to reduce it. A compensating controls narrative is completely standard for small companies. Auditors accept it when the reasoning is honest and the alternative controls are real.
Here is what that looks like in practice:
"Given our current team size, complete separation of duties for system changes is not feasible. To compensate, all production changes require a peer-reviewed pull request with at least one approval, changes are logged in our change management system, and we maintain automated monitoring and alerting on production infrastructure. This is reviewed quarterly."
That's what they're looking for.
The companies that get into trouble aren't the ones with small teams. They're the ones who either skip this entirely or write up a process that looks thorough and then don't follow it. A simple, honest process you actually stick to will hold up in an audit. A complicated one that lives only in a document won't.
On the GRC software question
You're going to get pitched on compliance platforms. They'll be expensive and will promise to automate your entire program. Some of them are good tools.
You don't need one yet.
They make sense once you have a dedicated compliance function and a large enough team that manual tracking breaks down. At five or six people doing your first audit, you'll spend more time learning the platform than getting compliant. Everything you need can live in Google Drive or Notion or whatever you already use to run the company. The key is knowing what to put there and how to structure it so an auditor can navigate it.
Come back to this after you close the deal. Once you're working toward your first renewal audit, automation starts to pay off. There's a real difference between loading a working, documented security program into a GRC tool and trying to build the program inside an expensive platform from scratch. Build the program first.
Do you need to hire?
Probably not for the audit itself. Two founders have done this. Five-person teams have done it.
Your engineers can handle the technical controls. Whoever is most organized on your team can own the policy documentation. What you actually need is someone outside your team who knows the framework and can tell you what it means for a company your size: what to focus on, what you can reasonably defer, and what an auditor is actually going to look at. Without that, someone ends up reading the AICPA framework document, which is written for auditors and not a how-to guide, and either over-builds half of it or gets stuck entirely.
Someone on your team still needs to own the effort. That's probably you.
The timeline
Type I readiness and the audit itself runs four to six months for a small team that stays on it. It won't be comfortable, because you're doing it alongside everything else. But it's not a year-long project.
Type II takes longer because of the observation period. You have to show that controls ran consistently over time, not just that they were set up. Get Type I done and use it to hold the deal while you work toward Type II. Tell your prospect where you are in the process. Most of the time that's enough to keep things moving.
What you actually end up with
The controls and documentation you build for the first audit don't disappear after the report comes out. They become how you operate. Policies that didn't exist now do, new hires have something to read on day one, and your next prospect gets a real answer when their security team asks.
Most founders look back on the first audit as something that forced them to run a tighter operation. Not just on security. The whole business. Work they should have done earlier and probably knew it.