SOC 2 With a
Small Team

In practice a well-run eight-person company usually lands somewhere between forty and eighty controls for a Security-only Type 2, where a large enterprise might carry several hundred. That is proportionality working correctly. What the same company cannot do is carry forty controls and leave the ones covering privileged access to a single person with no second party anywhere in the design. Absence is not proportionality; it is an unaddressed criterion.

The useful realisation is that you do not have to break all three functions apart. You have to break the chain at one reliable point. If the founder still authorises and executes, but a second named person independently records and reviews what happened — against complete system-generated information, on a stated cadence, leaving a dated artefact — the concentration is addressed. Everything below is an application of that one pattern.

Three properties decide whether a review control here is real or decorative, and a service auditor asks about them in roughly this order. Did the reviewer have the competence to recognise a problem — could they tell an inappropriate grant from an appropriate one? Did they see complete and accurate information, produced by the system rather than assembled by the person under review? Did they have the authority to act, with evidence of at least one occasion where something was questioned or corrected? A review that has never found anything in twelve months invites the fourth question, which is whether it is performed at all.

The controls that come cheapest at eight people are the ones about people, and they are also where the small-population arithmetic bites hardest. Hire three people during a six-month period and you have created a population of three background checks, three training completions and three policy acknowledgements. One miss in any of them is a deviation rate of a third, and there is no sample to hide it in.

Background screening sits under CC1.4, the competence criterion, which carries a point of focus about considering the background of individuals before they are hired or engaged. What is actually checked varies by jurisdiction and by role. The control description has to say what your process genuinely does — identity and right to work, employment history, criminal record where lawful — and not repeat a template promising a check you never run. A description that over-claims produces an exception on your own words.

Security awareness training is evidenced by a completion export covering the full roster for the period, not by a screenshot of one certificate. The roster is the part teams get wrong: it has to include people who joined mid-period and the contractors who hold accounts. Policy acknowledgement records work the same way and are easiest to evidence when they run through the same platform, so one export answers two requests.

Contractors deserve their own paragraph, because almost every company this size has them and almost none puts them in the control description. A contractor with an account appears in the identity-provider reconciliation and needs a named internal owner and an engagement end date. When that engagement ends it is an offboarding event, tested against the same revocation window as an employee’s last day, and it needs the same confidentiality terms and device expectations behind it. An unrevoked contractor account is the most common single-item deviation we see at this size, precisely because nobody was watching a calendar.

Requirement or market practice: pen tests, scanning and training

Three items get asked about constantly, and it is worth being exact about which is which, because funding decisions follow from it.

No trust services criterion names a penetration test. That is a statement about the requirement, and it surprises people. What the criteria ask for is in CC7.1 — detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities, and susceptibilities to newly discovered ones — and in CC4.1, which contemplates ongoing and separate evaluations of whether the components of internal control are present and functioning. An annual third-party penetration test is how most companies satisfy the separate-evaluation half, and most service auditors and enterprise buyers now expect to see one. That expectation is market practice, not a stated requirement.

The small-team version follows. Authenticated vulnerability scanning on a stated cadence, with a documented remediation SLA by severity and evidence that the SLA was met, satisfies CC7.1 on its own — that is the requirement. The annual penetration test is what unblocks the buyer’s questionnaire — that is the practice. Security awareness training sits between the two: no criterion says “annual course”, but CC1.4 and CC2.2 between them expect technical competence and communicated responsibilities, and an annual completion record is the ordinary way to evidence both.

Every move above landed before 1 April. That is the point of the dates. The same four changes made in the first three weeks of April would have produced three design-period gaps instead of one late review: branch protection with nine days of unprotected merges sitting behind it, a break-glass control with no population before it existed, and a monthly access review whose first cycle fell outside the control description.

At fieldwork in October the populations are small and entirely legible. Six access reviews, all six tested. Four break-glass elevations, all four tested and each matched to an incident ticket. Two hundred and fourteen merges to the release branch, every one of them made under the protection rule that has been live since 6 February, of which the auditor selects twenty-five and confirms in each case that approver and author are different accounts. Three joiners and one leaver, every one of the four tested, with the joiners tested twice — once for access provisioning and once for the background check, training and acknowledgement set.

One exception is noted. The April access review was completed on 12 May, against a control description promising five business days from month end — 7 May. The evidence is complete and the review was genuinely performed; it was simply late against a self-imposed deadline. Management responds in the report, the remaining five reviews were on time, and the opinion is unmodified.

Note what the four moves have in common. None added headcount, none added a management layer, and the whole programme ran to roughly ten weeks of part-time work between January and mid-March. Two were configuration changes that removed a decision from a human entirely; the other two put a second name on a record that previously carried one. For how these land against the wider control set, see the SOC 2 controls list and the readiness checklist.

Two pieces of vocabulary make fieldwork much easier to follow. What the auditor is establishing about anything you export is its completeness and accuracy, and the artefact class has a name: information produced by the entity, usually shortened to IPE. That is the reason they want the query, the filter, the date range and the record count visible rather than the result alone — without them, the export is an assertion rather than evidence, and no amount of tidiness fixes it.

The mechanics are worth knowing in advance too. The request list arrives as a PBC schedule — prepared by client — typically a week or two before fieldwork opens; it is a document to read carefully and query, not to receive passively, because half the ambiguity in a first examination is in its wording. Screenshots have a standard: the system identifiable, the logged-in user visible, a date inside the period on the face of the image, and nothing cropped above the filter bar. And expect two or three rounds of follow-up requests rather than one, because the first round almost always surfaces a population that does not reconcile.

The request that surprises small teams most is that reconciliation. The auditor compares your identity-provider user list to payroll and contractors, and any difference has to be explained. Eight people and thirteen active accounts is not automatically wrong — service accounts, shared integrations and a founder’s second admin account are all legitimate — but each of those extra accounts needs a name, an owner and a recorded reason. Teams that write that inventory on day one spend an afternoon on it; teams that write it during fieldwork spend a week and find two accounts nobody can account for.

Where a third party operates part of your control environment, the treatment question is its own topic — start with subservice organizations and the complementary controls that come with it. Where you need a named external reviewer on an ongoing basis, that is what a fractional CISO engagement is for.

The variable that drives effort is not headcount. It is the number of production systems inside the boundary and the proportion of the control set that can be enforced by configuration rather than habit. A single-product company on one cloud account with a modern identity provider is a genuinely light engagement; the same eight people running four legacy environments are not.

For the light case, expect roughly six to ten weeks of readiness before the observation period opens, with one internal owner spending something like eight to twelve hours a week — most of it on system changes rather than documents, because policy templates are quick and splitting admin roles without breaking the release process is not. During the period the load drops to a few hours a month if tooling is collecting as it goes. Fieldwork then concentrates twenty to forty hours into two to four weeks of answering requests, and the report follows some weeks later.

On fees: TCSA readiness for an early-stage startup is a fixed fee from $4,000, quoted after scoping, and the CPA firm’s attestation fee is contracted and billed separately by that firm. Two firms, two engagements, two invoices — though the invoicing is a consequence rather than the rule. The separation independence actually requires is that the firm issuing the opinion neither designed nor operated the controls it examines, which is the shape set out in the responsibility table above, and a useful thing to be able to explain when a buyer asks who did what.

The most common planning error is treating the observation period as the start of the work. It is the exam, not the revision. The second admin, the branch protection, the monthly review, the log-retention check and the account inventory all belong to the weeks before day one, because a control that starts halfway through the window has, by definition, not operated throughout it.