SOC 2 for a team of 1 to 10 people

Updated 22 October 2026

A SOC 2 examination tests whether your controls are designed well and, for a Type II report, whether they operated. Nothing in the Trust Services Criteria requires a security department, an on-call rotation or a change advisory board. A founder-led team of 1 to 10 can describe what it actually does, commit to what it can sustain, and document the compensating controls where one person holds several roles. This guide shows how, and exactly what changes in the Policyseed policies at that size.

What changes in the policies at 1 to 10 people

When the headcount answer in the generator is 1-10, the templates switch to a small-team mode with proportionate commitments. The table below is not written by hand: it renders all 22 policies from the Northwind Cloud Inc sample twice, once with 1-10 people and once with 11-50, and lists every sentence that differs. Highlighted words are the ones that change. If a template changes, this table changes with it.

7 sentences differ, all in Incident Response Policy, Business Continuity and Disaster Recovery Policy and Backup and Recovery Policy. The other 19 policies commit to the same things at every size; the Risk Assessment and Management Policy and the Human Resources Security Policy only restate the headcount band in their scope. Wording such as “the insurer, if any” is the same at every size, so a team without cyber insurance is not committed to one.

What the changes mean

• Response targets one or two people can meet. The larger version assumes a staffed rotation that can acknowledge a SEV1 within minutes. The small version gives SEV1 and SEV2 incidents longer targets that one or two people with phone alerts can realistically meet, and your incidents are measured against the targets you wrote, not against a larger company's.
• A cover schedule instead of a rotation. The Security Owner and a deputy, where one exists, share on-call duty under a written cover schedule. Where the Security Owner is the only responder, the schedule records when they are unavailable and how reports are acknowledged and escalated in that time.
• The notification clock starts at classification. Severity is assigned at triage, and with business-hour acknowledgment targets that can happen some hours after the event. The 4-hour window for telling Executive Management therefore runs from classification.
• One definition of “on call”. The backup and disaster recovery policies point at the arrangement in the Incident Response Policy instead of naming an Engineering rotation that does not exist yet.

Segregation of duties when one person writes, approves and deploys

Change management criteria (see CC8.1) expect changes to be authorized, tested and approved. In a larger team that means the author does not approve their own change. In a two-person team it usually still can; in a one-person team it cannot, and the policies say what happens then:

The author of a change never approves it, and self-approval is disabled in GitHub. Where team size leaves no qualified independent reviewer, the Security Owner or a technically competent member of Executive Management reviews; the requirement is never waived. (Change Management Policy, 4.9)

Access to GitHub is granted through organization membership enforced by single sign-on with Okta, repository permissions are assigned by team, and protected branches require a review from someone other than the author before code is merged and deployed by GitHub Actions. Where headcount makes this impractical, the Security Owner documents the compensating review. (Access Control Policy, 4.8)

Common approaches small teams use, alone or together:

• Review by the other founder or a contractor. Branch protection that requires one approving review from someone other than the author, even if the reviewer works part time. A trusted contractor or fractional engineer under contract and NDA can be the second reviewer.
• After-the-fact review of production changes. Where no second reviewer exists, someone else reviews the list of changes merged and deployed since the last review, on a fixed schedule, and signs off. The change record and the review record are both evidence.
• Logging the person cannot quietly change. Deployment history from the CI/CD system, Git host audit logs and cloud audit trails kept where the deployer cannot delete them. Logging does not prevent a bad change, but it makes one visible to the reviewer.
• A written exception. The Access Control Policy has an exception route for a team too small to separate authoring and deployment: written approval, a compensating control and an expiry date.

Whether a given compensating control is enough is the CPA firm's judgment, not the policy's. Describe the arrangement in your first conversation with the firm and ask how they will test it.

Who signs what

Every policy names an owner role (usually the Security Owner) and an approver who signs the revision history. The generator asks for both names. When they are different people, the approval is a real check on the owner's work. When a founder holds both roles:

• With two founders, one owns and the other approves. The CTO owning the policies and the CEO approving them is a common split.
• With one founder, a board member, investor or outside advisor can approve the policies and receive the quarterly security status report the Information Security Policy describes. A dated note of that review is evidence of oversight (see CC1.2).
• Where nobody else exists, record the approval anyway and describe the arrangement plainly. The firm decides how it affects the report; hiding it is worse than stating it.

Owners are roles, not departments. One person can be Security Owner, Engineering Lead and IT/Operations Lead at once; the policies still read correctly because each names the role, and the SOC 2 policies list shows which role owns which policy.

Access reviews with three people

Access is reviewed at least quarterly for production, source code, identity administration and any system holding Restricted data, and at each annual review for all other systems. Reviewers attest to each account and privileged role, and removals are completed within five business days. (Access Control Policy, 4.10)

With three people the review is short, but it still needs to happen on schedule and leave a record. Export the user and admin lists from the identity provider, the cloud console, the Git host and anything holding customer data; compare them with the people who work for you today; look for former contractors, shared logins and service accounts nobody owns; and have someone other than the main administrator confirm the administrator's own access. The access review template has the columns for this.

Vendor management with a handful of vendors

Northwind Cloud Inc maintains a vendor inventory recording, for every vendor, the business owner, service provided, data shared and its classification, systems accessed, tier, contract and renewal date, last review date and outcome, and assurance evidence held, and reviews it for completeness at least annually. (Vendor and Third-Party Risk Management Policy, 4.1)

A small team can easily have more vendors than people: a cloud host, a Git host, an email and identity provider, a payment processor, an error tracker. The inventory can be one spreadsheet. Tier each vendor by the data it holds, collect the assurance report of each one that holds customer data (see where to get your vendors' SOC 2 reports), note the complementary user entity controls those reports ask you to run, and review the list once a year. For a vendor without a report, the vendor security questionnaire is a starting point.

Incident response with one responder

The Incident Response Policy in its 1-10 form is written for this case: the Security Owner may be the Incident Commander, the responder and the person who notifies customers. What keeps that workable:

• A cover schedule that says who watches the incident contact when the responder is on a plane or on leave, even if the answer is an auto-reply and an outside incident response provider.
• A short runbook with the first steps already decided: how to rotate credentials, revoke sessions and preserve logs. The incident response plan template is a starting point.
• An incident log kept even when nothing serious happens. Low-severity entries (a phishing email reported, a lost laptop that was encrypted) show the process runs.
• A yearly tabletop exercise with whoever you have: the founders, the contractor, an advisor. Write down the decisions and the gaps.

Evidence a small team can produce cheaply

Most evidence is a by-product of doing the work and noting the date, and much of it comes straight out of tools you already use:

• Dated approval of each policy in its revision history, and signed acknowledgments (see the acknowledgment guide).
• Pull requests with their reviews and checks, and the deployment history from the CI/CD system.
• The quarterly access review record, from the access review template.
• A risk register reviewed at least once a year, from the risk register template.
• The vendor inventory with the reports you collected.
• A restore test record: what was restored, from when, how long it took.
• The incident log and the tabletop notes.

The SOC 2 evidence checklist lists the evidence for each criterion and the policy behind it.

Timeline

How long it takes depends on what is already in place and on the report you need. A Type I report looks at the design of your controls at a point in time; a Type II report covers a period during which the controls have to operate, and the CPA firm and your customers' expectations shape how long that period is (see Type I vs Type II). To see what is missing before you talk to a firm, take the SOC 2 readiness assessment, then work through the order in SOC 2 policies for startups. The SOC 2 timeline planner turns those answers into a dated, week-by-week plan sized for a 1-10 person team, with every duration shown as an assumption you can change.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.