Solo founders need a SOC 2. Here's how.

yuan — Tue, 04 Aug 2026 22:59:56 +0000

A one-person company ships like a 20-person team now. That is the whole reason this problem exists. You are selling to companies big enough to have a procurement process, at a headcount that used to mean you were never in the room. So the questionnaire arrives, there is a SOC 2 line in it, and every control you read about assumes a team you do not have.

Five years at Deloitte auditing SOC 2 for tech companies across the US and Canada. 30+ of them, for names like LinkedIn, Affirm and Ripple.

In all that fieldwork I never once saw "too few people" written down as an audit failure. What I saw was auditors who never learned to translate big-company control language down to a small company, so they either invented busywork or wrote up a finding that did not need to exist.

So here is the useful version of the question. Not "can I pass" but "what does the auditor actually open when the company is one person and an agent."

Change management: I open your branch protection settings

The control everyone assumes they fail. Big-company guidance says a second engineer reviews every change before it ships. You merge your own code.

Except that is not quite what happens anymore. Your agent writes the change and you review it. It is worth being honest about what that does and does not buy you. It does not create separation of duties, because the agent runs under your direction and your credentials, so an auditor reads you and the agent as one principal. What it does buy you is a real review that leaves a record, which is more than a solo developer merging their own hand-written code ever had.

What I look at is whether the path from commit to production is constrained and recorded. Branch protection on the default branch. Required status checks that have to go green. Tests that run on their own. A deploy history showing what shipped and when, that nobody typed by hand.

An automated control can stand in for a second reviewer when it is designed well and it leaves records. That is not a loophole, it is a compensating control, and it holds up in the working papers as long as the safeguard is real and the trail exists.

One thing to check today: if your agent has push access to the repo, whether it can reach the default branch matters more than whether you read its output. Most people have never looked.

Separation of duties: I look for what catches you afterward

You cannot split the role, and adding an agent does not split it either. So the question moves to what catches a bad change after it happens.

This got more important, not less. An agent executes a lot of changes quickly, and the blast radius of one bad instruction is wider than it was when a human typed every command. The controls that matter are the ones that fire without you.

Deploy notifications posted somewhere that keeps history. Cloud audit logs on and retained. Alerts on the things that would actually hurt: a new IAM principal, a security group opened to the world, a production database touched outside a deploy. And a self-review you perform on a schedule and write down.

The criterion is about reducing risk. It is not about counting heads. One person reviewing one account is a valid review when it is written down and dated.

Access review: the one artifact nobody has

You are the only admin. Except you are not, and this is the part that has quietly changed.

Your agent has credentials. Your MCP servers hold tokens. Your CI has a deploy key. Every one of those is a principal with standing access to your systems, and almost nobody has ever reviewed them, because they arrived one at a time while you were shipping. Non-human identities are the access review of the moment and most solo setups have more of them than people.

The control is a written review, performed by you, on a schedule, that names what exists and confirms it should. List the accounts with production access. List the tokens your agent and your CI hold, and what each one can reach. List the SaaS tools holding customer data. Confirm each still needs what it has. Date it. Save it.

It feels absurd to write a memo to yourself. Write it anyway. Fifteen minutes a quarter, and it is the difference between a control that exists and a control you believe in.

SSO with MFA everywhere it is offered, and a hardware key or a password manager. Those are the controls. The review is the evidence they are working.

Vendors: you collect reports, you do not run a program

Big-company guidance assumes a procurement team with a vendor risk program and annual reassessments. You have a cloud provider, a dozen SaaS tools, and now a model provider.

That last one is new and founders miss it. If customer data reaches your model provider, it is a vendor in your scope like any other. Collect its report the same way you collect your cloud provider's.

The work is reading, not building. Your cloud provider is what auditors call a subservice organization, meaning part of your security genuinely lives inside their system. You collect their SOC 2 report. You do not audit AWS. Keep a short list of vendors that touch customer data, note which parts of your security depend on each, and hold their current reports.

Background checks: a population of zero is still a population

No employees means nothing to check. That is not a gap, it is an empty population, and it gets recorded as one.

An agent is not an employee and does not get a background check. It gets access, so it lands in the access control, not the HR one. Keep those straight and the HR section of your audit takes about ten minutes.

The distinction starts mattering when you bring on your first contractor. Then the control becomes a signed agreement plus the steps you follow to grant access and remove it when the work ends. Write those steps down before you need them, because doing it afterward is how a small thing turns into a finding.

The part that actually trips people up

It is almost never the controls. Solo founders on modern infrastructure usually have better security than they think, because the defaults improved and there is no legacy sprawl.

It is the evidence. A screenshot someone took three weeks ago is a picture of a moment that has passed. Configuration pulled from the live system is what the control state actually is. The gap between those two is where the pain in a first audit lives.

Here is the good news, and it is the same reason you ship like a 20-person team. Chasing evidence was miserable because a person doing it is rate limited by attention. Your agent is not. It already has access to your cloud, your identity provider and your repo, and it can pull current state instead of photographing it. The work that used to eat a month of engineering time is the work agents are best at.

The catch is that an agent left alone will hand you something that looks like evidence and falls apart on inspection. A policy nobody follows. A config that does not prove what the control claims. A log covering the wrong window. It has to know what counts, which is a different problem from having access.

If you change one habit: stop thinking in screenshots and start thinking in exports.

Start with Type I

Type I tests whether your controls are designed correctly at a point in time. Type II tests whether they actually operated over a stretch of time, usually three to twelve months.

Get Type I first. The scope is small, there is no observation window to wait out, and it gives you something to hand the prospect now. Most enterprise buyers accept a Type I with a Type II to follow. Get the design right, then prove it held.

What to turn on this week

If you do nothing else:

Branch protection on the default branch, with required checks and force-push disabled
An inventory of every token your agent, your MCP servers and your CI hold, and what each can reach
MFA on every account that offers it, SSO where you can
Cloud audit logging on, retained past the period you will be audited over
Deploy notifications going somewhere that keeps history
A dated access review, written by you, covering humans and non-humans both
Current SOC 2 reports from the vendors your security depends on, model provider included

That is most of a Security-only scope for a one-person company. Security is the only required category. The other four are optional and you add them only when a contract genuinely needs them.

The longer version of the standards reasoning, including how the AICPA treats smaller organizations and where the right-sizing is actually permitted: Can a solo founder pass SOC 2?

The methodology I test against is public, control by control, if you want to see what the questions actually are: github.com/Chiaro-HQ/methodology

Sources

Trust Services Criteria are evaluated at the criterion level. Points of focus are illustrative guidance, not requirements (2017 TSC with revised points of focus, 2022).
AICPA guidance allows smaller, less complex organizations to meet the criteria through active owner oversight rather than formal structure.
Under AT-C 205, inquiry alone is never sufficient. The practitioner has to inspect, observe or reperform.
Solo founders started 36.3% of new startups in the first half of 2025, up from 23.7% in 2019. About 82% of US businesses have no employees.

DEV Community: yuan