An enterprise prospect requires SOC 2, but you don't have it. What now?

If an enterprise prospect requires SOC 2 and you don't have a report, first confirm the requirement with their security reviewer. Ask what report they need, when they need it, and whether they can accept current security evidence or a phased commitment. Then compare the cash required before payment with the deal's likelihood of closing and its expected gross profit. You may decide to start SOC 2, negotiate a limited pilot, or pursue smaller customers while preparing.

A promising demo is not a purchase order. Before buying a platform or promising an audit date, find out what would actually let this buyer sign.

Establish the buyer's actual requirement

"We need SOC 2" can mean a security questionnaire field, a firm procurement rule, or a condition for putting production data in your system. Ask your champion to introduce the person responsible for accepting security evidence. Their answer matters more than a salesperson's estimate of what procurement usually allows.

Get these questions answered in writing:

1. Which product, legal entity, hosting environment, and data flows must the report cover?
2. Do you require a SOC 2 Type II report, or would Type I be acceptable initially? Which Trust Services Categories and reporting period do you need?
3. Is the report required before a pilot, contract signature, production access, or a later renewal?
4. Do you have requirements for the CPA firm, report age, exceptions, or additional testing?
5. Who can approve an alternative or temporary exception, and what evidence would they review?
6. Once security review is complete, what other budget, legal, or procurement steps remain?

SOC 2 is a CPA examination and assurance report. Buying software, completing a readiness checklist, or scheduling an audit does not mean you have that report. The AICPA's SOC resources explain the assurance service and the CPA's role.

Type I addresses control design as of a specified date. Type II also addresses operating effectiveness over a specified period. A Type I is a useful interim step only if the buyer accepts it. Agree the reporting period and feasible schedule with your auditor before promising Type II delivery.

Ask about interim evidence and a phased commitment

Offer a proposal the reviewer can evaluate. "We're working on SOC 2" gives them little to approve.

Depending on the product's risk and the buyer's process, ask whether they would consider:

• A security evidence pack and a review call before deciding whether an exception is possible.
• A limited pilot with synthetic data, restricted access, a narrow user group, or another boundary the buyer approves.
• Type I as an interim milestone, followed by Type II on a separately agreed schedule.
• A contract with explicit readiness and audit milestones, reporting obligations, and agreed consequences if a milestone is missed.

The buyer may decline every option. Treat that as useful information for the spending decision. Do not assume an exception exists because another startup negotiated one.

For a phased plan, separate what you control from what depends on the auditor. You can own the scope review, remediation, evidence collection, and audit engagement. The CPA firm controls its examination and report issuance. Confirm milestones with the people doing the work, then have both parties review the contractual wording.

Buyer email template

Adapt the bracketed details to your current position. Do not say an auditor is engaged or controls are operating unless that is true.

Subject: Confirming the SOC 2 requirement for [product / pilot]

Hi [name],

We don't currently have a SOC 2 report. We want to confirm your requirements before we commit to a path or delivery date.

Could you introduce the security reviewer who can confirm the required report type, scope, reporting period, and the stage at which you need it? Is the report a condition of a pilot, signature, or production access?

We can share [list the current evidence you actually have] through a restricted channel. Our known gaps are [brief factual summary], and [owner] is responsible for the next steps.

Would your team consider reviewing that evidence for [a limited pilot / a temporary exception / a phased commitment]? If so, please tell us the approval criteria, restrictions, decision owner, and review date. If an issued Type II report is mandatory before we proceed, please confirm that too.

Separately, can we confirm the commercial scope, budget status, and remaining procurement steps? That will help us assess the work and timing together.

Thanks, [name]

After the call, send a short recap with the accepted evidence, any restrictions, the approver, and the next decision date. Have the reviewer correct it. Keep that record with the deal.

Security evidence pack checklist

Start with evidence relevant to the proposed use. This is an interim buyer-review pack, not a substitute SOC 2 report or a universal auditor request list. Label each document with its scope, owner, last review date, and limitations.

Include when relevant	What to put in the pack
Product and data scope	Architecture and data-flow diagrams, hosting regions, data types, subprocessors, and responsibility boundaries
Access controls	Current MFA and SSO settings, privileged-access list, a completed access review, and joiner/leaver process evidence
Change management	An approved change policy and a recent change with linked review, test, approval, and deployment records
Vulnerability management	Recent scan results, remediation status, and a penetration-test report or executive summary if one exists
Incident response	Named contact, escalation process, response plan, and the most recent exercise or incident follow-up if available
Availability and recovery	Backup configuration and an actual restore-test record, with the service commitments you can support
Vendor oversight	Critical vendor list and available assurance documents, with your review notes and unresolved gaps
Policies and training	Approved policies that match current practice, owners, review dates, and relevant completed training records
Readiness plan	Current gaps, remediation owners, milestones, and the audit engagement status stated accurately

Include supporting records rather than policy statements alone. For example, "we review access" is a claim; a dated review with the population, reviewer, decisions, and completed removals shows what happened. Our application evidence guide explains that distinction.

Share sensitive material through an access-controlled channel and an NDA where appropriate. Remove credentials and unnecessary personal data. Keep an original internally, document redactions, and agree whether a summary is sufficient before sharing full vulnerability or penetration-test details. If a document is missing or a control is incomplete, say so.

Decide whether the deal justifies starting SOC 2

Build the decision around cash timing and delivery capacity. Contract value alone can hide an expensive, uncertain commitment.

Write down the expected first-year gross profit, the probability of closing after all remaining reviews, the earliest realistic customer payment, and the cash you must spend before then. Include the audit, preparation software or advisory help, required remediation, any separately required penetration test, and renewal commitments. Estimate founder and engineering time separately from cash spending.

A useful screening calculation is:

Expected first-year deal contribution = probability of closing × first-year gross profit, minus incremental compliance costs.

Calculate gross profit after the cost of serving the customer, so those delivery costs are not subtracted twice. This is a planning model, not a forecast. Test a low-probability case, delayed payment, and a lost-deal case. Even a positive expected result can leave you unable to pay the next invoice. Include other qualified opportunities that need the same report, without counting speculative pipeline as committed revenue.

For the detailed cost assumptions and preparation paths, use the bootstrapped founder's SOC 2 guide. Keep quotes comparable by specifying the same scope, report type, period, support responsibilities, and exclusions.

Path	When it can make sense	What to resolve first
Start SOC 2 now	Several qualified buyers need it, or a credible deal supports the spend and you can fund a loss	Buyer acceptance criteria, scoped audit quote, cash schedule, remediation capacity, and a program owner
Negotiate an interim path	The reviewer can consider a restricted pilot or phased commitment	Written approval, permitted data and access, milestones, and what happens if approval or delivery slips
Focus on smaller buyers while preparing	Upfront spend threatens runway, the enterprise deal remains uncertain, or its deadline is infeasible	Which smaller customers can buy now, which security improvements still matter, and when to revisit SOC 2

Pursuing smaller buyers is a commercial choice, not permission to ignore security or contractual obligations. Continue fixing material risks and documenting how the product operates. Those records can support a later audit.

Assign someone to drive the work

If you proceed, name one person responsible for the plan and give them time to coordinate it. They need access to the buyer's reviewer, engineering owners, management, and the auditor.

Software can draft policies, collect evidence, and track work. People still approve scope, decide which risks to accept, implement remediation, and resolve questions about sufficient evidence. If those decisions are blocking progress, consider scoped expert help before adding another tool. The small-team SOC 2 advisory guide compares those support options.

Start with the SOC 2 readiness assessment to identify likely gaps. Bring the buyer's written requirement, your current evidence, and the cash deadline to the next discussion. That gives you something concrete to decide.