Home › Guides › No security team

SOC 2 when nobody's job title says security

Updated 2026-09-14 · 8 min read · by Deepak Gandhi, who builds SOC2Starter

This is the normal case, not the exception

The tooling and the advice in this market are largely written for companies with a compliance function. Most companies that need SOC 2 do not have one. They have a CTO who already has a full-time job, an enterprise customer waiting on an answer, and no obvious person to hand the work to.

That situation is workable. SOC 2 does not require a security team; it requires that controls exist, are appropriate to your size, and actually operate. An auditor assessing a twelve-person company is not expecting a security operations centre. They are expecting the controls you claimed to have to be real.

What genuinely does not work is leaving it unassigned. The failure mode for small companies is never a refusal to do the work — it is that nobody in particular was responsible during a busy quarter.

Give it to one person, with time

Pick one owner. Usually the CTO, or the engineer who already owns infrastructure. Not a rotating responsibility, and not “the team”, because auditors ask who performed a control and “we all did” is not an answer that survives follow-up.

Then give them actual time. A realistic budget for a first audit at a small company is a meaningful chunk of one engineer's week during readiness, dropping to a few hours a month once the recurring controls are running. Treating it as something to absorb between feature work is how deadlines get missed by a quarter.

Founders consistently underestimate this line because it is the only cost with no invoice attached. It is nearly always the largest one.

Scope is the biggest lever you have

SOC 2 has five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is the only mandatory one. Almost every startup should do Security alone for a first report.

Each additional criterion adds controls, evidence and audit fee. Teams add Availability because it sounds reassuring, then discover they have committed to uptime monitoring and capacity planning evidence nobody asked them for. Your customer almost certainly asked for “SOC 2”, not for a specific criteria set — and if they did ask for more, that is a question worth confirming before you buy it.

Narrowing scope is the single largest reduction in work available to you, and it costs nothing.

Start the things that need calendar time

This is the distinction that decides whether your timeline holds. Some evidence can be produced on demand. Some has to accumulate, and no amount of effort later compresses it.

Start these immediately, before you feel ready:

• Access reviews. Quarterly. The most common finding for startups, and impossible to create retroactively.
• Offboarding records. Every departure needs a dated record that access was actually revoked. You cannot reconstruct one for somebody who left last year.
• Change management. If code review is already your habit, you may already be generating this evidence in your pull requests — check that branch protection enforces it rather than relying on convention.
• Security awareness training. Annual, with completion records.

These four are cheap to start and expensive to backfill. Everything about your timeline follows from when you begin them.

What can genuinely wait

Plenty, and knowing this is what keeps a small team from drowning in the first month.

• Policy writing. Ten or so documents. They need to be approved, dated, and actually followed — but they can be written in a focused week rather than spread over six months. Write them close to the audit so they describe what you really do.
• The risk assessment. A documented exercise, not a continuous programme at your size.
• Vendor reviews. Assemble the subprocessor list and review the material ones. This is a day's work, not a quarter's.
• Most tooling decisions. You do not need a full security stack to pass a first audit. Buying tools before you know which controls you are short on is how budgets get wasted.

The instinct at a small company is to start with policies because they feel like the visible part of compliance. That is backwards: policies are the deferrable half, and the recurring controls are the urgent half.

The technical gaps that actually come up

Auditors at this size are not looking for sophistication. The findings that recur at small companies are unglamorous and cheap to fix once somebody looks.

• MFA that is available but not enforced. Particularly on the cloud root account and on any admin console reachable from the public internet. “Everyone has it turned on” is not the same claim as “it cannot be turned off”, and only the second is a control.
• Production access that made sense at four people. Broad permissions granted when the team was tiny and never narrowed. Least privilege is mostly a tidying exercise, not a project.
• Backups nobody has restored. Having backups is not the control; demonstrating you can restore from them is. Run one restore, document it, and you have closed a finding that catches a surprising number of companies.
• Code review by convention rather than enforcement. If branch protection does not require review, your change management control depends on everyone remembering. Turn on the setting and the evidence generates itself.
• Laptops with no disk encryption or screen lock policy. Trivial to fix centrally, and routinely asked about.

None of these needs a specialist. They need an afternoon and somebody willing to check the actual configuration rather than the assumed one.

Where outside help is actually worth paying for

You do not need a consultant to get SOC 2, and many small companies do it without one. Where money genuinely buys time:

• The auditor conversation, early. Free, and the highest-value hour available. A small CPA firm will tell you what they expect to see, which beats any generic checklist. Get three quotes; prices for the same report vary by multiples.
• A penetration test, if your auditor or your customers expect one. Not something to do in-house.
• A few hours of advisory at the scoping stage, if the decisions feel genuinely unclear. Rarely worth a full engagement at this size.

Where it is usually not worth it: paying someone to write policies that describe a company they have not observed. You will end up editing them into truth anyway, and a policy that does not match reality is worse than none, because now the gap is documented.

A workable sequence for a team of ten

Roughly, and in this order:

1. Confirm with the customer which report they actually need. Type 1 plus a committed date often unblocks a deal that seemed to require Type 2.
2. Choose Security-only scope. Name the owner. Put their time in the calendar.
3. Talk to two or three auditors. Ask what they expect for your size, including on penetration testing, and get it in writing.
4. Start the recurring controls this week: first access review, offboarding record template, branch protection, training.
5. Close the obvious technical gaps — MFA everywhere including cloud root, least privilege on production, encrypted backups with a restore you have actually tested.
6. Write and approve the policies, describing what you now genuinely do.
7. Run the penetration test if required, remediate, then open the observation window.

Nothing in that list requires a security specialist. It requires one accountable person and enough calendar time to be honest about what is true.

Questions people ask

Can a startup get SOC 2 without a security team?

Yes, and most do. SOC 2 requires controls appropriate to your size that genuinely operate, not a dedicated function. An auditor assessing a twelve-person company expects proportionate controls, not a security operations centre. What matters is that one named person owns the work and has real time for it, because the common failure is that nobody in particular was responsible.

Who should own SOC 2 at a small company?

One named individual, usually the CTO or the engineer who already owns infrastructure. Not a rotating duty and not the team collectively, because auditors ask who performed a given control and a collective answer does not survive follow-up. Give the owner explicit calendar time rather than expecting the work to fit between feature deadlines.

How much engineering time does SOC 2 actually take?

Expect a meaningful share of one engineer's week during the readiness period, falling to a few hours a month once the recurring controls are running. It is the largest cost of SOC 2 for most small companies and the one nobody budgets, because it is the only line item that never generates an invoice.

Should a startup do more than the Security criteria?

Usually not for a first report. Security is the only mandatory criterion, and each additional one adds controls, evidence and audit fee. Teams often add Availability because it sounds reassuring, then find they have committed to monitoring and capacity evidence no customer requested. Confirm what your buyer actually asked for before widening scope.

Do I need a compliance consultant for SOC 2?

Not necessarily. The highest-value outside conversation is with the auditor, and it is usually free: a small CPA firm will tell you what they expect for a company your size. Paying someone to write policies describing a company they have not observed is rarely worth it, since you will edit them into truth anyway and a policy that does not match reality is worse than none.