SOC 2 for a small team: what actually changes

Read the criteria cold and they sound written for a company with a security function, a change advisory board, and enough people to approve each other’s work. You have four engineers. Two are contractors. Nobody carries a pager, because everybody does.

The usual answer is that the criteria are identical at any size, and it stops there. The useful part starts one step later. Which controls actually collapse at six accounts, and what will an examiner take in their place? That is the whole page.

What does not change

Two parts are fixed before headcount enters the conversation: what gets tested, and who tests it.

The Security category is the common criteria set every SOC 2 report contains,² and it is what Polara G.R.C. scopes. Security only. Fixed, not a setting. Adding Availability or Confidentiality is a contract decision rather than a headcount decision, and the scoping tool runs the four questions that settle it.

The examiner is size independent too. Your report comes from an independent partner auditor, a licensed U.S. CPA firm, whether the company is three people or three hundred. The evidence still has to exist. The policies still have to be yours. A tiny company does not get a shorter examination, and it does not get a softer one.

Segregation of duties when two people are the whole team

The control asks one thing: that the person who performs an action is not the only person who reviews it. At two engineers you can separate nearly all of it. At one you can separate none of it, and writing otherwise into a policy is how you manufacture your own exception.

Three responses work, in this order.

1. Separate what the tooling can separate. Branch protection that refuses a direct push to main. A required reviewer on every pull request. Production access through a second account rather than the one you write code with. Two engineers can cover each other completely this way, and the configuration screen is the evidence.
2. Add a detective control where you cannot. A solo founder cannot approve their own deploy and call that a review. What an examiner can test instead is a control that catches the action afterwards: a deploy notification into a channel a second person reads, a monthly review of the production change log signed off by someone outside engineering, an audit log nobody holds the permission to edit.
3. Write the conflict down. Name it in the policy. State that the company is too small for full separation, name the compensating control, and say who performs it. A documented conflict with a mitigation is a control. An undocumented one is a finding.

The second person does not have to be an engineer. A cofounder, an operations lead, or an outside advisor under a signed agreement can review what shipped. Three things matter: they did not perform the action, the review leaves an artifact, and the artifact carries a date and a name.

Access reviews when there are six accounts

A quarterly access review over six accounts takes about twenty minutes. It still fails, and it fails for a reason unrelated to scale: nothing gets written down. You know every person in the company, so reading the list feels like ceremony, so you do it in your head, and the period closes with no artifact behind the control.

The examiner is not testing whether the list is short. They are testing whether the review happened, on the cadence you defined, with a decision recorded against each account. Six accounts make that easy. They do not make it optional. Here is what the record has to hold.

Run it early in the window rather than in the final week. A review that removes nobody is a valid review when the record shows you looked, so the thing to avoid is silence. Five control failures covers the access review in more detail, along with the four others that turn up most often.

Screening and training when half the team is contractors

Two controls in the common criteria quietly assume employees: people are screened before they receive access, and people complete security training.¹ A small team is often half contractors, and contractors are where both controls break without anyone noticing.

Screening

The control is that people holding access were screened before they got it. For a contractor that means a check you ran, a record their agency ran and handed you, or a written risk acceptance naming the person and the reason you decided not to screen them. All three are testable. The fourth option, screening employees and skipping contractors without saying so, is the one that produces a finding.

Confidentiality and security obligations

An employee handbook does not bind a contractor. The obligations belong in the contractor agreement itself: confidentiality, acceptable use, device requirements, and the duty to return or destroy data when the engagement ends. The signed agreement is the evidence.

Training

Same module, same annual cadence, same completion record. A contractor with production access who never took the training is an access decision you made. Either they take it, or their access changes to match.

Offboarding

Contractors turn over faster than employees, which makes offboarding the control most likely to have real instances inside a short period. Keep the checklist and the timestamps. A revoked token with a date on it is strong evidence, and it costs nothing to capture at the moment you revoke.

None of this needs a human resources function. It needs a folder, a date, and a name.

Change management when the author is the approver

Change management is where a small team’s policy most often describes a company that does not exist. The template says every change is reviewed and approved by a second party before release. The commit history shows the founder merging their own pull requests at eleven at night. An examiner reads both documents.

The answer is not to ship less. It is to put the control where a machine can enforce it and to write the policy the process actually follows.

• Protected branches so nothing reaches production without passing the gate, including work by the person who configured the gate.
• Required status checks: tests, build, and whichever scans you run. A machine gate is a control, and it is the only kind that never gets busy.
• A review requirement that names the reviewer. Two engineers review each other. One engineer names a second reader for anything touching authentication, customer data, or production access.
• An emergency path you wrote down, with a rule that a self approved emergency change gets reviewed within a stated number of business days, and a record showing it happened.

Then write the frequency and the exception path you genuinely operate. An examiner tests you against your own stated procedure³ rather than against a larger company’s benchmark, so a policy that matches reality is the cheapest control you will ever own. What an exception actually does to a report explains why that gap matters more than the control itself.

Incident response with nobody on call

The criteria do not ask for a rotation. They ask that incidents get detected, triaged, recorded, communicated to whoever needs to know, and closed. A rotation is one way to reach a human at three in the morning. It is not the only way, and at five people it is rarely the one you have.

What a small team can evidence instead:

• An alert path that reaches a phone. Monitoring that pages a named person, a named backup, and a written statement of who those two people are this quarter.
• A plan short enough to follow half asleep. Severity levels, who declares, who tells the customer, on what clock, and where the record gets written.
• One tabletop exercise inside the observation period. Thirty minutes, one scenario, a written result naming what you would change.
• Every real incident logged, the small ones included. A period with no incidents and no records looks identical to a period where nothing was recorded.

Zero incidents is a fine outcome. Zero mechanism is not. The observation period is where all of this has to actually fire, which is why the tabletop belongs on the calendar rather than on a list.

Which controls collapse, and what stands in

The same five, every time, at every company small enough to fit around one table. Read the third column as what a competent examiner can test, not as a discount. Each substitute is more work to document than the original would be to perform at a larger company.

What it costs a company this size

Price does not move with headcount here either, which cuts both ways. You pay the same as a larger company, and the work is smaller because your surface is smaller. Six accounts, one production system, a handful of vendors.

Each Type 2 examination is $5,000, including your first, and it becomes available to subscribers once the 3-month observation window closes. The full cost breakdown separates the software fee from the auditor fee, which is the split most quotes leave joined.

Start with scope, then the five controls above, then the calendar. What a Type 1 requires of a small SaaS walks the specific decisions in order, and the timeline shows where each one lands. None of it requires hiring anybody. It requires writing down what you actually do, then doing it on a date somebody can point at.