Customer Asked for SOC 2: What Should a Startup Do First?

When a customer asks for SOC 2, do not start by buying software or promising a date. Ask what report the customer will accept, which service it must cover, which criteria matter, and when the request affects the deal. Record those answers, assess the work you already do, and take a bounded plan to a qualified CPA firm before committing to a report schedule.

TL;DR

• Reply with your current status, not a claim that the company is “SOC 2 compliant.”
• Ask whether the customer requires Type 1 or Type 2 and what product, entity, criteria, and timing it expects.
• Ask whether a questionnaire, security documents, or another review can support the deal while the report work proceeds.
• Name one internal owner to coordinate the decision and collect facts.
• Define the smallest truthful service boundary before choosing controls or software.
• Inventory current policies, controls, source systems, owners, and evidence.
• Discuss the proposed report and coverage with a qualified CPA firm.
• Give the customer a date for your next factual update, not an untested report delivery promise.

What is the customer asking for?

The request may be one sentence in a questionnaire, a contract condition, or a note from procurement. “Send us your SOC 2” still leaves the decisions that shape the project unanswered.

The AICPA describes SOC as a suite of services that CPAs provide in connection with controls at service organizations. A SOC 2 report is the output of an independent CPA firm’s examination. It is not a badge that a GRC tool can issue.

The customer may care about the report because it needs information about the controls behind a service it plans to use. That does not tell you which report type, scope, criteria, or delivery date will answer its review. Ask before you build a plan.

Question	Why it changes the plan
Will you accept Type 1, or do you require Type 2?	Type 1 addresses a specified date. Type 2 also addresses operation across a period.
Which product or service must the report cover?	The answer sets the starting boundary for systems, people, data, and providers.
Do you expect only Security or any optional categories?	The selected Trust Services Categories affect the criteria and controls in scope.
What date affects the purchase or renewal?	The business deadline must be tested against implementation, evidence, and CPA capacity.
How recent must the report be?	A report outside the customer’s age requirement may not answer the request.
Will another security review work in the meantime?	The customer may have a separate process for a company that does not yet have the report.
Who can confirm acceptance?	A named person prevents the plan from relying on a vague sales summary.

Record the customer’s exact requirement and keep an approved reference to its source. Do not copy raw emails, contracts, questionnaires, attachments, customer data, or confidential deal terms into Git unless the repository’s access, retention, and deletion rules allow it. Keep the source material in its approved system and store only the minimum facts the SOC 2 plan needs. If the customer’s security or procurement team cannot answer yet, record that uncertainty instead of filling it with an assumption.

Send an accurate first response

Your first response should keep the conversation moving without overstating the company’s position. A short note can do that:

Thanks for raising the SOC 2 requirement. We do not currently have a SOC 2 report. To confirm the right plan, could you tell us whether you require Type 1 or Type 2, which service and criteria must be covered, the date that affects your review, and whether you have an interim security review process? We will confirm our current controls and proposed next step by [date].

Change the first status sentence to match the facts. If a CPA firm is engaged, an examination is underway, or a report has been issued, state the exact stage. If none of those things has happened, do not imply otherwise.

“SOC 2 is in progress” is useful only when the phrase has a real meaning. Be ready to say who owns the work, which report is planned, what stage is complete, and what remains uncertain. Keep management’s target date or candidate Type 2 period separate from dates agreed in a CPA engagement.

Make a go, wait, or alternate-review decision

A customer request is strong evidence of a business need, but it is still an input to management’s decision. Write down:

• the customer and opportunity affected;
• the exact report or review requested;
• the covered service and any known criteria;
• the decision deadline and requested delivery date;
• the consequence if the company cannot supply the report;
• any interim review the customer will consider;
• the internal owner, budget authority, and available team capacity;
• the current state of security work and evidence.

Management can then choose to pursue the report, negotiate a different review or schedule, or decline the requirement. Do not claim that a questionnaire, penetration test, policy set, or security document is equivalent to a SOC 2 report. It may answer an interim customer question only when the customer says it does.

The broader SOC 2 guide for startups explains when waiting may be reasonable and why headcount, revenue, or funding stage should not decide the issue by themselves.

Choose the report goal before the tool

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

Do not assume that Type 1 is required first or that it will satisfy the buyer. Use the customer’s answer and a CPA discussion to choose the planned report. The SOC 2 Type 1 versus Type 2 guide covers the decision in detail.

Before signing a software contract, define what your team needs to manage:

1. The service and criteria in scope.
2. Risks, commitments, policies, and controls.
3. Named owners, approvals, recurring work, and event-driven work.
4. Source systems and the evidence they can produce.
5. Dated operating records, exceptions, and corrective work.
6. Management’s system description, assertion, and other audit documents.
7. Requests, populations, samples, and secure evidence delivery.

A tool can organize that work. It cannot operate infrastructure or workforce controls, create missing history, decide whether evidence is sufficient, or issue the report.

Define a truthful first scope

Start with the product or service behind the customer’s request. Then trace the people, procedures, data, software, infrastructure, and providers that deliver or protect it.

The AICPA’s SOC 2 Description Criteria cover the information management uses to describe the service organization’s system. Its Trust Services Criteria provide the criteria used to evaluate relevant controls.

A focused scope can reduce unrelated work, but an exclusion must still be true. Do not omit a shared identity provider, deployment path, support process, or other system when the scoped service materially depends on it. Use the SOC 2 scope guide to record the boundary and challenge each exclusion.

Inventory what already exists

Do not begin by marking a starter checklist complete. Build a factual baseline:

Area	Facts to collect
Governance	Program owner, decision makers, current policies, approvals, and review dates
Service	Product boundary, architecture, data flows, people, locations, and providers
Controls	What the team actually does, who does it, how often, and what happens on failure
Source systems	Identity, cloud, source control, deployment, monitoring, endpoint, workforce, vendor, and training systems
Evidence	Existing exports, logs, tickets, reviews, test results, dates, retention, and known gaps
Security work	Open risks, remediation, penetration testing, incidents, backups, access changes, and vendor decisions
Capacity	Owners, reviewers, source access, budget, outside help, and time available for recurring work

Treat templates and starter records as proposals. Review each one against how the company works. A polished policy does not prove that its control exists or operated.

This baseline lets a CPA firm or readiness adviser assess a real system instead of a generic checklist. It also gives management the inputs for a budget and the startup SOC 2 timeline.

Build the plan as connected records

For an engineering-led team, the plan should be reviewable in the same way as other operational work. 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.

A first pass can record:

• the derived customer requirement, an approved source reference, and management’s decision;
• the proposed Program and System boundary;
• people, Systems, Components, and providers in scope;
• candidate criteria, risks, policies, and Controls;
• Control owners, evidence sources, and recurring Obligations;
• gaps and corrective Actions;
• the planned Audit after the CPA engagement is known.

FileGRC’s starter records are proposals, not compliance claims. The team must tailor them, implement Controls in the real source systems, and collect evidence from those systems. FileGRC does not perform the examination or decide whether the evidence is sufficient.

You can start a private workspace locally:

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

An engineer or agent can inspect the next program step and current readiness without hiding the underlying files:

npx filegrc program-path --next --json
npx filegrc program-readiness --summary --json

Use a dedicated private repository. Do not put plaintext credentials, private keys, tokens, recovery codes, or personal data that may need erasure into Git. Source systems still operate the controls and produce much of the source evidence.

Do not make these promises

Avoid five common shortcuts in the first customer conversation:

1. Do not call the company SOC 2 compliant. State whether a report exists, its type, scope, period or date, and current status.
2. Do not promise a report date from a generic timeline. Test scope, remediation, evidence, staff capacity, CPA availability, and fieldwork first.
3. Do not backdate work or recreate missing Type 2 history. Record the gap and begin retaining honest evidence when the control operates.
4. Do not let a tool choose the business requirement. The customer defines what it accepts, management owns the system, and the CPA firm owns the examination.
5. Do not upload every security artifact into one repository. Keep secrets and data with erasure or handling needs in approved source systems, then retain or reference only what the evidence plan allows.

The useful next move is simple: turn the customer’s sentence into a written requirement, give the decision an owner, and test the plan before making a promise. That gives the sales conversation an honest update and gives the team a scope it can actually operate.