SOC 2 Requirements for Startups: What You Actually Need

SOC 2 requirements for startups fall into four layers: define the system and report scope, address the applicable AICPA criteria with controls, operate those controls with evidence, and support an independent CPA firm’s examination. There is no universal control list. Your final controls depend on the service, risks, commitments, systems, selected criteria, and report type.

TL;DR

• Treat the AICPA criteria as evaluation benchmarks, not a ready-made controls list.
• Include the Security Common Criteria as the baseline, then add optional Trust Services Categories when the planned report calls for them.
• Prepare a system description that matches the actual service, people, procedures, data, software, infrastructure, and providers in scope.
• Design controls from the criteria, risks, commitments, and system requirements, then test each procedure and evidence source.
• For Type 2, keep dated operating evidence across the specified period and preserve complete populations when sampling may apply.
• Management owns the description, assertion, controls, and evidence. The CPA firm performs the examination and issues the report.

SOC 2 requirements are not one checklist

Search results often mix four different things under the word “requirements”:

Layer	What it answers	Main output
Report	What will the CPA firm examine?	Type 1 date or Type 2 period, system scope, criteria, and engagement terms
Criteria	Which benchmarks apply?	Security Common Criteria, Description Criteria, and selected optional categories
Management program	What must the company design and operate?	Risks, policies, controls, owners, procedures, recurring work, and evidence sources
Examination support	What must management provide?	System description, assertion, records, populations, evidence, and responses

The AICPA describes SOC as a suite of services provided by CPAs in connection with controls at service organizations. Its SOC overview explains that these reports help customers and other users understand controls at a service organization.

That means a startup should not start with a downloaded list of security tasks. Start with the report goal and scoped system, then connect the applicable criteria to controls the company can actually operate and prove.

Which AICPA criteria are required for SOC 2?

The AICPA publishes two sets of criteria that do different jobs.

Trust Services Criteria evaluate controls

The Trust Services Criteria are the benchmarks used to evaluate controls relevant to Security, Availability, Processing Integrity, Confidentiality, and Privacy.

For a SOC 2 report, Security is the baseline Trust Services Category. It uses the Common Criteria, organized as CC1.1 through CC9.2. A startup should plan for the complete Security Common Criteria set rather than selecting only the rows that resemble its current controls.

Availability, Processing Integrity, Confidentiality, and Privacy are optional categories. Add a category when the customer request, service, commitments, information, risks, or intended report make it relevant. An availability promise may support adding Availability. A service that processes information subject to a confidentiality commitment may support adding Confidentiality. Management and the CPA firm should confirm the planned criteria before the team relies on an evidence period.

Points of focus in the AICPA document help people understand the criteria. They do not turn into a universal one-control-per-point checklist. Management still has to design controls that fit its system.

Description Criteria evaluate the system description

The AICPA’s SOC 2 Description Criteria are used to prepare and evaluate management’s description of the service organization’s system.

The nine Description Criteria cover the nature of the business and service, service commitments and system requirements, system components, system incidents, applicable criteria and controls, complementary user entity controls, subservice organizations, omitted criteria, and significant changes.

Do not treat the description as marketing copy. It must agree with the exact service, coverage, systems, people, providers, controls, incidents, and changes under examination.

What must the startup define before controls?

Write the management scope proposal before copying any controls. Record:

• the legal entity and service being examined;
• the customer or business request behind the work;
• the planned Type 1 date or Type 2 period;
• the service boundary and material exclusions;
• infrastructure, software, people, procedures, and data;
• providers and subservice organization dependencies;
• customer and provider control responsibilities;
• service commitments and system requirements;
• the proposed Trust Services Categories and criteria.

Assess each system that materially operates or supports an in-scope control. A system that produces authoritative evidence may be relevant even when it does not process customer data, but evidence production alone does not settle the system boundary. Management and the CPA firm should assess its role. For example, a workforce system may supply the departure population used to test access removal. A source control system may supply the change population used to test approvals.

Use the SOC 2 scope workflow to trace the service through its systems and dependencies before management settles the control set.

Which controls does a startup need?

There is no reliable universal number. Build the control set from five inputs:

1. the applicable Trust Services Criteria;
2. the scoped service and system components;
3. risks identified by management;
4. customer, legal, policy, and service commitments;
5. approved system requirements.

Common control areas include governance, risk assessment, access management, change management, system operations, incident response, vendor oversight, business continuity, data handling, security training, monitoring, and corrective work. A topic belongs in the program because the scope, criteria, risk, or commitment calls for it, not because it appeared in a template.

Every control should state:

• the intended outcome and criteria it addresses;
• the systems, people, events, or populations in scope;
• who performs and reviews it;
• whether it runs continuously, on a schedule, or after an event;
• the current procedure;
• the authoritative evidence sources;
• how the team handles exceptions and follow-up.

The SOC 2 controls guide shows how to turn those inputs into an implementable control without confusing the criterion, policy, procedure, and evidence.

Which policies and records are usually needed?

SOC 2 does not impose one set of policy filenames. The startup needs approved rules and records that match its control design and actual work.

Depending on scope, that often includes:

• information security and acceptable use rules;
• access approval, change, and departure procedures;
• risk assessment and risk treatment records;
• incident response and recovery plans;
• vendor review and provider oversight records;
• change management and secure development procedures;
• backup, recovery, monitoring, and vulnerability procedures;
• data classification, retention, and disposal rules;
• security training assignments and completion records;
• management oversight, exceptions, and corrective work.

Approval means management accepts the exact policy text. It does not prove that the related controls have been implemented or operated. Keep approval, effective date, implementation, task completion, evidence collection, and verification as separate facts.

What evidence is required for Type 1 and Type 2?

The report type changes the evidence question.

Evidence question	Type 1	Type 2
When is the subject examined?	As of a specified date	Across a specified period
What must management support?	Control design and implementation at the date	Control design, implementation, and operation across the period
What operating records matter?	Records that support implementation at the date	Complete dated records for each applicable occurrence or population in the period
Can one current screenshot prove the work?	Only when it supports the exact implementation fact being examined	Usually not for a recurring or population-based control

For each evidence source, record the source system, access owner, report or query, filters, fields, timestamp, timezone, covered scope, collector, verification, classification, and retention rule. Run the retrieval before starting a candidate Type 2 period.

When sampling may apply, preserve the complete source population, not only the items management expects the CPA firm to select. Keep the query, period, filters, exclusions, generation time, row count, and reconciliation with the fixed export.

Inspect and minimize every export before deciding where to keep it. Do not put plaintext credentials, private keys, tokens, recovery codes, or personal data that may need erasure into Git. Keep prohibited or retention-sensitive source data in an approved restricted evidence store, then put only an approved external reference and safe source, scope, date, classification, and review metadata in the GRC repository.

Use the SOC 2 evidence collection workflow to test the source-to-review chain and the SOC 2 audit populations guide to preserve a complete Type 2 source set.

What management must prepare for the examination

Management owns the system and the claims made about it. For the formal engagement, the startup should be ready to provide:

• the agreed system, criteria, controls, and specified coverage;
• a system description reconciled to current program records;
• management’s assertion for the exact engagement;
• the control set and related policies and procedures;
• dated operating records and linked evidence;
• complete populations when the firm’s testing uses samples;
• known incidents, exceptions, deviations, and corrective work;
• responses and evidence delivered through the approved request channel;
• a management representation letter when requested by the firm.

The AICPA’s illustrative SOC 2 report shows how management’s assertion and system description sit beside the service auditor’s report and tests of controls in a Type 2 report.

The CPA firm sets its procedures, selects samples, evaluates exceptions, decides whether the evidence is sufficient and appropriate, and issues the report. An internal readiness result means management completed its own checks. It does not mean the firm accepted the evidence.

A practical SOC 2 requirements matrix

Use this matrix to test whether each layer has a real owner and output.

Requirement area	Record or output	Readiness question
Business request	Customer need and report goal	Does the planned report answer the actual request?
Scope	Bounded system, components, data, people, providers, and exclusions	Can management explain why each item is in or out?
Criteria	Security baseline, Description Criteria, and selected optional categories	Has management reviewed the complete set with the CPA firm?
Risks	Dated assessment and owned risk records	Do current risks feed control design and treatment?
Policies	Approved text, effective date, owner, and review schedule	Do the rules match current practice?
Controls	Outcome, scope, owner, procedure, cadence, and evidence source	Can the assigned people perform and prove the control?
Operation	Recurring work, events, exceptions, and follow-up	Is every applicable occurrence recorded for the coverage?
Evidence	Fixed artifacts or approved references with source and review facts	Can management reproduce and verify the source record?
Type 2 populations	Complete exports and reconciliations	Can management explain the full set before sampling?
Management documents	System description and assertion	Do the statements match the final scope and evidence?
Fieldwork	Requests, responses, transfers, questions, and status	Can the team show exactly what it sent and when?

Track SOC 2 requirements as connected records

FileGRC is an open source, Git-native GRC workspace for SOC 2 work. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history.

FileGRC connects criteria, scope, risks, policies, controls, owners, procedures, evidence sources, recurring work, events, management documents, and audit preparation. Its readiness checks calculate gaps from those records.

npx filegrc program-path --next --json
npx filegrc program-readiness --summary --json
npx filegrc period-health --require-healthy --json
npx filegrc audit-readiness audit-id --json

Starter records are proposals, not compliance claims. Your team must review them, implement the controls in real source systems, and keep real evidence. FileGRC does not replace identity, infrastructure, monitoring, endpoint, backup, training, workforce, procurement, signature, vendor, or CPA systems. It does not perform the examination or decide whether evidence is sufficient.

Start by asking which service and report the customer needs. That answer sets the scope, which sets the criteria, controls, evidence, and management work that follow.