SOC 2 for Startups With Contractors: Scope People and Access

A startup can pursue SOC 2 while using contractors. Start by listing everyone who builds, runs, supports, secures, or governs the service customers use. Record what each person can reach, who approves that access, and when their work ends. If an outside firm supplies part of the service, assess that relationship too. Management can then propose a truthful boundary and controls for the CPA firm to review. A contractor’s payroll label alone does not settle scope.

Where contractors fit in a SOC 2 system

The AICPA SOC 2 Description Criteria ask management to describe the system that provides the service, including its people and procedures. The Trust Services Criteria provide criteria for the controls the CPA firm evaluates. Neither source makes employee status a shortcut for omitting a person who can deploy code, view customer data, or operate a control.

Start with the general SOC 2 scope workflow. For each contractor, ask whether their work affects the service, a relevant system, a control, or its evidence. Someone who only edits public marketing copy may need a different treatment from someone with production access. Write down the reason for inclusion or exclusion, then discuss uncertain cases with the CPA firm before relying on a candidate report period.

Separate the person from the provider relationship

A small company may hire an individual developer, buy a managed engineering service, or use a firm that assigns named developers to its team. Those arrangements can create different control work.

Arrangement	Management question	Records to check
Individual contractor using your accounts	Which duties, systems, data, devices, and approvals apply to this person?	Worker source, access requests, account exports, agreements, training, departure record
Outside firm operating a service for you	What capability does the firm supply, and what does your service rely on it to do?	Contract, service boundary, provider review, assurance material, risk decision
Firm’s developers using your repositories or cloud accounts	Which individuals can reach your systems, and who approves and removes their access?	Named account population, role approvals, source-control and cloud exports, access review

The same relationship can need both a provider review and individual access controls. A vendor record does not show that a specific developer’s cloud role was removed, while an account export does not show that management assessed the firm’s service and risks. A relevant firm is not automatically a subservice organization; management and the CPA firm decide how provider responsibilities appear in the engagement. Use the vendor review guide for that decision.

Build one complete contractor population

Before writing an access review or offboarding control, define the source list. If employees live in an HR system and contractors live in a spreadsheet or procurement tool, a single HR export is incomplete. Reconcile the contractor list to identity-provider users, source-control collaborators, cloud accounts, support tools, and any local accounts that matter to the scoped service.

For each person, keep an approved source and these facts:

1. A stable person or opaque workforce ID, sponsor, firm when applicable, role, start date, expected end date, and actual departure.
2. Systems, groups, privileges, customer-data access, and service duties.
3. Device route and the approved rule for that route.
4. Required agreements, policy acknowledgements, training, and review dates.
5. Open exceptions, owner, due date, and proof of closure.

Do not put a contract, personal address, identity document, or other sensitive personnel record in a broad Git repository just to make the list complete. Keep those records in an approved restricted source system and link a safe reference. The onboarding and offboarding checklist shows how to connect each start, role change, and departure to actual work and source evidence.

Set access and device rules by the work

Approve only the access needed for the assignment, and state who may approve a change. A short engagement does not make a shared admin account or an unreviewed production role safe. Check direct grants as well as central identity groups. Set a real end date or review trigger for temporary access, and compare the approved role to the account state in each system.

Contractor-owned devices need an explicit rule. NIST’s remote access and BYOD guide includes contractor-controlled devices in its scope and recommends defining permitted device types, remote access, and account provisioning. NIST guidance helps design the rule; it is not a separate SOC 2 requirement. Your rule may use a managed company device, a verified contractor device, or restricted browser access, depending on the data and privileges involved. Verify the actual state in the endpoint and identity systems. A signed policy alone does not prove a device was configured.

Keep the event and review trail complete

Plan three operating paths before the first contractor starts:

• Start: Capture the approved assignment, access request, applicable agreement and training, device decision, and actual provisioning records.
• Change: Compare the old and new roles when duties, firm assignment, or privileges change. Remove access the old role no longer needs.
• End: Use the confirmed departure event to remove accounts, sessions, keys, repository permissions, and assets within your approved windows. Check each authoritative system and record exceptions.

The SOC 2 access review evidence guide covers periodic review of the complete account population. For a Type 2 period, preserve the full set of contractor starts, changes, departures, and reviews before a CPA firm selects samples. If no event occurred, keep the source and checked count rather than inventing a completed checklist.

There is no universal quarterly review or 24-hour removal rule in the AICPA criteria. Management sets a control design from its risks and commitments, operates it, and confirms the proposed design with the CPA firm. Dates, timestamps, source counts, and actual system output let a reviewer test what happened against that design.

Keep the management record reviewable

FileGRC is a Git-native GRC workspace for SOC 2 work. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history. It can connect people, vendors, systems, access grants, controls, events, and evidence references so a small team can review the proposed boundary and the work it produces. Starter records are proposals, not compliance claims.

Identity, endpoint, source-control, training, signature, procurement, and other source systems still operate the controls and produce the original evidence. FileGRC does not grant or revoke accounts, manage laptops, sign agreements, or decide whether evidence is sufficient. An agent can help prepare and check records, but people must verify the facts and approve management decisions. The independent CPA firm performs the examination and issues the report.