SOC 2 when the whole company fits in one room.

The criteria describe outcomes, not tooling. Nothing in TSP section 100 asks for a ticketing suite, a security operations centre or a forty-page policy. An auditor judges whether your controls are suitably designed for the risks you have and, in a Type 2, whether they operated across the period. A lean design that fits a lean company passes that test.

• Fewer tools. One identity provider, one code host, one tracker. Evidence lives where the work happens, so fewer systems means fewer populations to keep complete.
• Combined roles. One person may hold several jobs, if a compensating control covers the conflict each combination creates.
• Peer review for separation. A second engineer approving a pull request is a real segregation of duties control, even with no separate change board.
• Short policies. A two-page policy that states what you actually do beats a borrowed template describing a team you don't have.
• Lighter governance. A quarterly leadership meeting with minutes can carry the oversight that a large company gives to a committee.

Short is fine. Fictional is not. Every sentence in a policy becomes something the auditor may ask you to prove.

Access reviews

Someone checks who can reach production and customer data, on the schedule your control states, and records the result.

Change approval

Changes to the in-scope system are reviewed by someone other than the author before they reach production.

Risk assessment

At least once a year, a written look at what could go wrong and what you're doing about it (CC3).

Vendor management

You know which vendors touch the system and you review the important ones (CC9.2).

Incident response

A written plan, a way to log incidents, and evidence that you followed it when something happened (CC7.3 to CC7.5).

Onboarding and offboarding

Access granted on approval and removed promptly when someone leaves (CC6.2). Small teams lose this one most often, because leavers are friends.

In many early companies the founder is the admin of every tool, approves every change, reviews every access list and also holds the keys to production. Each of those is fine alone. Together they mean nobody checks the person with the most power. An auditor reading that design will ask who reviews the founder's own access and who approves the founder's own changes.

1. List every control and write the performer and the reviewer side by side.
2. Circle every row where the same name appears twice.
3. For each circled row, move the review to someone else, even a part-time advisor or a board member, or add a detective control that would expose misuse.
4. Put the founder's own accounts into the access review, reviewed by someone else.
5. Write the result into the control description, so the design the auditor reads is the design you run.

Compensating controls must leave evidence too. A review that happens in a hallway conversation is, for the auditor, a review that didn't happen.

• Keep the control set just large enough to meet the criteria. Every extra control is another population to keep complete.
• Put recurring controls on a shared calendar with a named owner, so they survive a busy month.
• Prefer controls the tools enforce (required reviews, single sign-on, automatic deprovisioning) over controls that rely on memory.
• Write down where each control's evidence lives the day you design it, not the week before fieldwork.

Sources: AICPA TSP section 100, 2017 Trust Services Criteria with revised points of focus (CC1 to CC9, including CC5.1 on segregation of duties); AICPA DC section 200; AICPA guide, SOC 2 Reporting on an Examination of Controls at a Service Organization.