SOC 2 for start-ups and small teams: a right-sized control set that earns a clean opinion

What the criteria actually ask of a 10 to 60 person company

The Trust Services Criteria apply to any service organisation and say nothing about company size. Each criterion describes an outcome: access is restricted and reviewed, changes are authorised and tested, risks are assessed, incidents are handled. The points of focus beneath each criterion are illustrations, not a list of mandatory controls, so a small team can choose controls proportionate to its system and risks.

What does not shrink with size is the need for proof. A founder who reviews every pull request is exercising change control, but unless the review leaves a dated, named record, the examiner cannot test it. The task is less about adding activities than making existing ones leave a trail. The full criteria are set out in our guide SOC 2 Trust Services Criteria explained, criterion by criterion; this guide concerns what a lean team needs to put in place against them.

A right-sized programme usually rests on one coordinator, often the CTO, three to six control owners spending a few hours a month on recurring checks, and a chief executive who chairs a short quarterly review.

Which trust services categories to include first

Security, examined through the common criteria, is in every SOC 2 report. Availability, processing integrity, confidentiality and privacy are optional, and each one you add brings its own criteria, controls, evidence and examination effort. For a first report, the discipline is to add a category only where there is a concrete reason: a customer contract with an uptime commitment points to availability; a client who asks you to protect designated confidential information points to confidentiality.

Most small SaaS and service teams start with Security alone, or Security with availability or confidentiality, and extend in a later period once the first report has settled the evidence routine. Where the choice is not obvious, the questions to settle it belong to SOC 2 scope: system boundaries, trust services categories and carve-outs.

One person, several control roles: keeping segregation of duties evident

In a team of fifteen, the engineer who deploys the code may also administer the cloud console and approve access requests. SOC 2 does not forbid that. The control activities criteria expect you to consider segregation of duties, and where full separation is impractical, to put a compensating control in place. What the examiner tests is whether any single person could make a significant change, grant access or alter data without another person knowing, and whether that second look is recorded.

Where the chief executive is the only possible reviewer of the technical lead, that is acceptable, provided the review happens on schedule and is signed off. The usual patterns are these.

Type 1 first, or straight to Type 2

The choice turns on how soon a client needs something and how settled your controls are. A Type 1 report, which covers the design of the controls as at a date, can be in hand months earlier and gives a sales team a document to share while the Type 2 period runs. Going straight to Type 2 saves an examination and suits teams whose tooling already produces reliable evidence. The start-up trap is treating the Type 1 as the finish line; clients who accept it in year one expect a Type 2 in year two. The full comparison sits in SOC 2 Type 1 vs Type 2: which report, and when.

Relying on your cloud providers: subservice organisations and carve-out

A small SaaS company runs on other people's infrastructure: a hyperscale cloud platform, a managed database, an identity provider, a payment or e-mail service. These are subservice organisations when their controls are needed, together with yours, to meet the criteria. Most small companies use the carve-out method: the provider's controls are excluded from the examination, the system description names the provider and states what it is relied on for, and the CPA firm does not test the provider. The inclusive method, which brings the provider's controls into your report, needs cooperation large platforms rarely give.

Carve-out does not mean the provider is none of your concern. Three duties remain yours. First, obtain the provider's own SOC 2 report each year and read it: the opinion, the exceptions, and the complementary user entity controls the provider expects its customers to operate. Second, operate those controls, since settings such as multi-factor authentication for your console users, encryption options and logging are usually your responsibility, not the provider's. Third, record the review. Ongoing oversight is covered in SOC 2 vendor management and subservice organisations.

Worked example: a right-sized control set for a 25-person SaaS team

Take a business-to-business SaaS company with 25 people, one product hosted on a single cloud platform, code in a hosted repository, identity managed through a single sign-on provider, and a first enterprise client asking for SOC 2 with Security in scope. The owners below are illustrative; five people carry it.

Roughly a dozen short policies support this set, and the CTO coordinates without a separate compliance hire.

Mistakes small teams make on their first SOC 2

• Adopting an off-the-shelf policy pack unchanged. Generic policies describe controls you do not run, and each becomes something the examiner can test.
• Putting all five categories in scope. Each extra category adds controls and sampling.
• One person owning everything. When that person is away, evidence stops and the gap becomes an exception.
• Treating the cloud provider's report as your own. Your configuration, access and monitoring are still yours to evidence.
• Letting tooling replace judgement. An access review nobody reads is still a failed control. Our guide SOC 2 common mistakes: the ten that produce exceptions covers the rest.

SOC 2 for small teams: questions buyers ask