How to Get a SOC 2 Report: A Startup Plan

To get a SOC 2 report, define the customer request and system in scope, agree on the report goal with a qualified CPA firm, implement and operate the needed controls, keep dated evidence, prepare management’s description and assertion, and support the firm’s examination. Your company owns the system and controls. The CPA firm tests them and issues the report.

TL;DR

• Ask what the customer will accept before choosing Type 1 or Type 2.
• Engage a CPA firm early enough to check the planned scope, criteria, coverage, and schedule.
• Define the whole system, including people, procedures, data, software, infrastructure, and material providers.
• Tailor policies and controls to real work. A template is a proposal, not proof.
• Test evidence sources before relying on a Type 2 period.
• Preserve each task, event, exception, review, and source population across the exact period.
• Reconcile the system description and management assertion to current records.
• Let the CPA firm choose its tests and samples, judge the evidence, and issue the report.

What does it mean to get SOC 2?

People often say they want to “get SOC 2” or “become SOC 2 compliant.” The deliverable is a SOC 2 report from an independent CPA firm, not a badge issued by software.

The AICPA describes SOC as a suite of services that CPAs provide in connection with controls at service organizations. A SOC 2 examination addresses management’s description of its system and controls relevant to security, availability, processing integrity, confidentiality, or privacy.

Management and the CPA firm have different jobs:

Party	What it owns
Management	The service, scope proposal, criteria selection, risks, policies, controls, operation, evidence, system description, and assertion
CPA firm	The engagement terms, examination procedures, samples, evaluation of exceptions and evidence, opinion, and issued report
Customer or report user	The business requirement and its decision about whether the resulting report meets that requirement

This split should shape the plan. A consultant or tool can help management prepare, but neither can issue the report or promise that a CPA firm will accept the evidence.

The eight steps to get a SOC 2 report

Use these steps as gates. Work may overlap, but each gate should produce a reviewable decision or record before the team relies on the next stage.

Step	Output	Gate
1. Confirm the request	Named customer need, product, report type, criteria, and target timing	The team knows what business question it must answer
2. Choose the report goal	Planned Type 1 date or Type 2 period and CPA discussion	Management and the firm agree that the plan is plausible
3. Define scope	Bounded system, criteria, people, data, systems, providers, and exclusions	Every planned control has a clear boundary
4. Build the program	Approved policies, risks, controls, owners, tasks, and evidence sources	Controls describe real work and are implemented
5. Test evidence	Source access, retrieval steps, fields, dates, counts, review, and retention	The team can reproduce complete evidence
6. Operate controls	Dated tasks, events, evidence, populations, exceptions, and follow-up	Records support the specified date or period
7. Prepare management material	Reconciled system description, assertion, control set, and evidence index	Management can support each statement and control
8. Support the examination	Secure responses, requested samples, explanations, and resolved open items	The CPA firm completes its work and issues the report

The startup SOC 2 checklist breaks these gates into detailed program tasks. This guide focuses on the decisions that determine whether the process reaches an issued report.

1. Turn the customer request into a written goal

Start with the request that triggered the work. Ask the customer, partner, or procurement team:

• Does it require a SOC 2 report, or will another security review work now?
• Will it accept Type 1, or does it require Type 2?
• Which product, service, region, or legal entity must the report cover?
• Does it expect only Security or any optional Trust Services Categories?
• What delivery date affects the deal?
• Who will confirm that the final report meets the requirement?

Record the answers and their source. “Enterprise wants SOC 2” is too vague to set scope, buy tools, or promise a delivery date.

If the customer cannot answer every question, document the uncertainty. Take that record to a CPA firm rather than filling the gaps with assumptions.

2. Choose Type 1 or Type 2 with the CPA firm

A Type 1 examination addresses control design and implementation as of a specified date. A Type 2 examination also addresses operating effectiveness over a specified period. The AICPA’s illustrative Type 2 report shows the main parts of the deliverable, including management’s assertion, the system description, the service auditor’s report, and tests of controls and their results.

Do not assume every startup must get Type 1 first. Ask what the customer will accept, then discuss these facts with a qualified CPA firm:

• the service and legal entity under consideration;
• the planned criteria and any optional categories;
• current control implementation and evidence history;
• the proposed Type 1 date or Type 2 period;
• provider and subservice organization dependencies;
• management’s responsibilities and expected deliverables;
• fieldwork timing, request handling, fees, and report review.

Use the SOC 2 Type 1 versus Type 2 guide to compare the evidence burden. Keep management’s early target as a candidate date or period until the engagement establishes the formal coverage.

3. Define one complete system in scope

Scope is more than a cloud account list. Define the service and trace the five system component categories used by the AICPA Description Criteria: infrastructure, software, people, procedures, and data.

Record:

• the service customers rely on and the commitments made about it;
• production and supporting systems;
• information handled and its classification;
• people and teams who build, operate, secure, support, and govern the service;
• manual and automated procedures;
• providers that supply material service or control functions;
• criteria and controls under consideration;
• explicit exclusions with a reason.

The AICPA’s SOC 2 Description Criteria set the criteria for management’s description. The Trust Services Criteria set the criteria used to evaluate relevant controls. You need both parts of the model: a clear system and controls that address the selected criteria.

Use the SOC 2 scope guide to challenge exclusions and connect the boundary to controls and evidence sources.

4. Build controls around the work your company performs

Run a risk assessment against the scoped service, commitments, systems, providers, and data. Then write controls that explain:

1. who performs and reviews the work;
2. which systems, events, or populations it covers;
3. when it runs;
4. which source proves the result;
5. how the team records exceptions and follow-up.

Policies state what the company commits to do. Controls and operating records show how the company carries out that work. Approval of a policy does not prove that a control operates.

Treat starter policies and control records as proposals. Tailor them to actual practice, assign named owners, review the exact text, record approval, and set an effective date. Then implement each control in its real source systems.

Your identity provider still enforces sign-in and produces access data. Your source control system still records changes. Your cloud, monitoring, endpoint, backup, training, workforce, and vendor systems still operate their parts of the program. A GRC workspace connects those facts and keeps the review trail.

5. Test evidence before starting a Type 2 period

For each control, identify the authoritative source and run the collection process once. Record:

• the source system and current access owner;
• the exact report, query, filters, fields, timestamp, and timezone;
• the covered system, population, or period;
• the collector and collection date;
• how someone checks completeness and accuracy;
• where the fixed artifact or approved reference is kept;
• its classification, access, and retention rules.

A screenshot may prove a setting at one point in time. It rarely proves that a recurring control ran for a full period or that a sampled population is complete. The SOC 2 evidence examples guide shows what common control records should contain.

Do not start a candidate Type 2 period because the policies exist. Start when the controls are implemented, owners can perform the work, and the evidence process produces complete, reliable, dated records.

6. Operate the program and keep the full record

During the specified date or period, complete scheduled work and record events when they happen. Common records include access reviews, hires and departures, changes, incidents, vendor reviews, risk reviews, training, backup or recovery tests, vulnerability work, and management oversight.

Each record should show the scope, source inputs, performer, actual date, result, reviewer, exceptions, follow-up, and linked evidence. When a control uses a population, preserve the complete source set and explain its query, filters, count, exclusions, and reconciliation before samples are selected.

Do not hide late work or exceptions. Record what happened, assess the impact, assign follow-up, and preserve proof of the resolution. The CPA firm decides how an exception affects its testing and opinion.

Git can preserve authors, commit times, revisions, diffs, and messages for repository files. It does not replace the event, approval, collection, or completion dates inside the records.

7. Prepare the system description and assertion from current facts

Management prepares a system description for the exact service, date or period, and criteria under examination. Reconcile the draft to current scope, systems, providers, information, commitments, controls, incidents, and changes. Do not copy a generic narrative and assume it matches the program.

Management also prepares an assertion for the engagement. Treat the assertion as a conclusion that must agree with the final description, controls, evidence, period, known exceptions, and engagement facts. Keep review and approval tied to the exact document revision.

Before fieldwork, prepare an index that connects each control and request to the relevant record, fixed artifact, source, date, owner, and review status. Check every export for credentials, tokens, customer data, personal data, and other material that should not leave its source system or enter Git.

8. Support fieldwork through an approved channel

The CPA firm will set its request and testing process. Track each request, owner, due date, response, secure transfer, question, and final state without pretending that an internal “ready” status means the firm accepted the item.

For sampled controls, answer with the requested evidence tied to the complete population. Preserve which version was sent and when. Explain exceptions with the facts and management’s documented response. Do not invent missing history or recreate a record as though it existed earlier.

The firm evaluates the description, assertion, control design, implementation, operating evidence when applicable, and identified exceptions. It decides whether the evidence is sufficient and appropriate, then issues the report.

What FileGRC can handle in this process

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 can connect scope, policies, controls, owners, recurring work, events, evidence, readiness checks, management documents, and audit preparation in a dedicated private repository. An engineer or agent can use the same model through the browser, CLI, editor, or CI.

npx create-filegrc@latest company-grc
cd company-grc
npm run validate
npm run serve

Starter records are proposals, not compliance claims. FileGRC does not operate infrastructure controls, pull evidence from source systems, perform the examination, or decide whether evidence is sufficient. Your team and source systems still do the work, and the CPA firm still issues the report.

Plan the time and cost around dependencies

There is no dependable universal time or price for getting a SOC 2 report. The schedule and budget depend on the customer need, scope, report type, current control state, remediation, evidence history, people, source systems, outside help, CPA availability, specified date or period, fieldwork, and report review.

Build the schedule backward from the needed report date, but keep customer deadlines separate from dates agreed with the CPA firm. Use the SOC 2 timeline for startups to map dependencies and the SOC 2 compliance cost guide to include staff time, control systems, security work, remediation, outside help, and the CPA examination.

Start with one written customer request and one bounded service. Those two records give the rest of the SOC 2 process a concrete target.