Your First Enterprise Customer Asked for SOC 2: A 90-Day Plan, a Budget, and What to Send Them This Week

The email says something like "Please send your SOC 2 Type 2 report as part of our vendor review." You have a product the buyer wants, a few engineers, and no report. That moment is what this page is for.

It is not a cost guide or an auditor comparison. Those live on sister pages. This is the action plan: what to send in the next five days, what to say about timing, and the order of work for the next thirteen weeks. I read the auditor, directory and standards-body pages behind every claim on 2 October 2026. aliteq has never been through a SOC 2 audit or received an enterprise SOC 2 request, so nothing here is a war story. It is what the published guidance says, put in the order you'll need it.

What to send an enterprise customer this week

Send a packet, not a promise. Your answers to their security questionnaire, a one-page security overview, your subprocessor list and data processing agreement, your vendors' SOC 2 reports, and a dated plan for your own audit. Do not send your cloud provider's report as if it were yours.

That list follows the "what to send before you have a report" advice from SOC2Auditors.org, an ad-supported directory of audit firms. Its point is blunt: deals that die in the months before a report usually die from a vague answer, not from the missing report.

Item by item:

• Their questionnaire, answered. Most buyers have one. Answer it fully, even if they asked for a report. Specific answers are what make a self-assessment believable.
• A one-page security overview. What the product does, where customer data lives, how it is encrypted, how long you keep it, who on your team can reach it, and how code gets reviewed and deployed. If your app was built with AI tools, say how AI-written code is reviewed.
• Your subprocessor list and DPA. SOC2Auditors.org calls these the two documents a reviewer asks for immediately, and the two most startups cannot produce on demand.
• Your vendors' evidence. Request each vendor's SOC 2 report and, where they publish one, its bridge letter. Anthropic's trust center lists a 2026 SOC 2 bridge letter, and Lovable's lists one too. Label them clearly as your vendors' reports. Which plan unlocks which platform's report is covered in is your vibe-coding stack SOC 2 ready.
• A pen test summary, if you have one. It is not required for SOC 2, but enterprise reviewers ask for it.
• A dated commitment. The report type, the audit start date, the auditor if you have one, and the expected issue date. A date is something your champion can defend inside their company. "We're working on it" is not.

The bridge letter you can't send yet

Founders often reach for a "bridge letter" here. It doesn't fit. A bridge letter, also called a gap letter, covers the months between the end of a SOC report you already have and the buyer's own year end. Linford & Co., a CPA firm, says it is "signed by the service organization, not the service auditor" and that "most bridge letters typically cover a period of no more than three months."

So it needs a report to bridge from. SOC2Auditors.org adds that a bridge letter "does not extend the CPA firm's opinion." For a first-time company the directory is direct: "It cannot substitute for a report you have never had." Your vendors' bridge letters are fine to attach. Writing your own, with no report behind it, would mislead the buyer.

The letter you can send once you sign an auditor

An engagement letter is different. It is the contract you sign with a CPA firm before an audit, and Linford describes it as "a legally binding document." Some firms will give you a version to show customers. Johanson Group, a CPA firm, writes: "If your organization would like a letter of engagement to share with your customers, we would happily provide one."

Compliance platforms offer a similar document. Vanta generates an "engagement letter" PDF that confirms your compliance program "to prospects and stakeholders before your audit is complete." That is a vendor's letter, not an auditor's opinion. Present either one for what it is: proof that an audit is booked, not proof that you passed one.

How to negotiate the timeline with the buyer

Ask before you promise. Find out in writing what the buyer will accept and by when: a Type 1 or a Type 2, which criteria, and whether a completed questionnaire plus a dated audit plan is enough to sign now. Then offer a date you can hit, not the date they asked for.

SOC2Auditors.org advises getting that answer "in writing before you scope anything," because teams routinely buy a Type 2 when the buyer would have taken a Type 1. Founders on a 2026 Hacker News thread said the same thing from experience: some buyers accept a security policy and a filled-in questionnaire for now, and a "we need SOC 2" can turn out to be a polite no.

The questions to send back the same day:

1. Which report? Type 1 checks your controls on one date. Type 2 checks they worked over months. If they need a Type 2, ask whether a Type 1 now, with the Type 2 window starting right after, can carry the first contract.
2. Which criteria? Security is required in every SOC 2. The other four add cost, so add them only if the buyer asks.
3. By when, and for what? Is the report a condition of signing, of go-live, or of the first renewal? Those are three very different deadlines.
4. Their questionnaire. Ask for it now, whatever the answer to the first three.

Then make the offer concrete. Something like: completed questionnaire this week, security overview and vendor reports attached, auditor signed by a named date, Type 1 report expected by a named month, Type 2 window starting the day the Type 1 is issued. Whether they accept that is the buyer's call, and some regulated buyers won't. If they will, it may be worth putting in the contract, so the commitment is written down on both sides.

Be honest about the floor. Cherry Bekaert, a CPA firm, puts a Type 2 observation window at three to twelve months, and three is the shortest typically seen. Nobody can hand over a Type 2 in 60 days. If a buyer insists on one by then, it is better to know now.

The 90-day plan to a Type 1 audit start

In about 13 weeks a small team with modest gaps can go from "they asked" to Type 1 fieldwork. Week 1 is the buyer. Weeks 2 to 4 are scope, auditor and readiness. Weeks 5 to 11 are fixes and evidence. Weeks 12 and 13 are the audit start. The report itself arrives a few weeks later.

That shape is our plan, built on Cherry Bekaert's phase lengths: one to two months of readiness, one to six months of policy and control fixes, then a few weeks to two months of Type 1 fieldwork, and about three to four weeks to issue the report. Ninety days only works at the fast end of every range. If readiness finds big gaps, the fix phase stretches, and you should move the date you gave the buyer early rather than late.

Week 1: answer the buyer. Send the questions above and the packet. Name one person who owns SOC 2. Without one owner, the project stalls.

Week 2: freeze the scope and ask for quotes. Write down the systems, the criteria and the locations in scope. Send that same written scope to two or three licensed CPA firms. Decide whether a compliance platform will save more hours than it costs. The SOC 2 audit cost guide has the questions that make quotes comparable.

Weeks 3 to 4: sign the auditor and check readiness. Sign the engagement, ask whether the firm provides a letter you can share, and send it to the buyer. Run a readiness assessment or gap check. Pick the Type 1 "as of" date with the auditor, and tell the buyer.

Weeks 5 to 8: fix the gaps. Start with access, because it is what a reviewer looks at first. Turn on multi-factor sign-in everywhere, remove people who left, lock down your database with Row Level Security, and move any secret keys out of the browser. Write the policies your platform or auditor lists and have the team sign them. Record a vendor review for each provider you rely on. The six checks before you share an app are a good first pass.

Weeks 9 to 11: run the controls for real and collect evidence. Do the access review, test a backup restore, run security awareness training, and keep the records. If the buyer wants a pen test, this is when to run it, so the findings are fixed before fieldwork. Read each vendor report's complementary user entity controls, the controls the vendor expects you to run.

Weeks 12 to 13: start the Type 1. Do a last walk-through with the auditor, then let fieldwork begin. Send the buyer a dated update. When the Type 1 is issued, start the Type 2 observation window that day. SOC2Auditors.org's advice is plain: every month of delay moves the Type 2 date by a month.

If you build on an AI API, expect AI questions in the same review. Our SOC 2 for AI startups guide lists what auditors ask about LLM features, and how long the whole program takes after the Type 1.

What the first 90 days cost

Plan on four lines plus your team's time: a Type 1 audit fee of about $10,000 to $35,000 with a specialist firm, a compliance platform at $12,000 to $28,000 a year, a readiness check at $3,000 to $15,000, and a pen test at $5,000 to $15,000 if the buyer wants one. Low ends sum to about $30,000, high ends to about $93,000.

Where each number comes from: the audit fee bands are SOC2Auditors.org's directory estimates. The platform range is Vendr's buyer data for Vanta. Readiness is from The Pun Group, a CPA firm, and the pen test range from Drata, which sells a platform. The hours estimate is from SecureLeap, a consultancy. Drata puts a whole first year at about $28,000 for a 25-person startup, which suggests most small teams land toward the low end. That is still a seller's estimate.

A Type 1 is not the last bill. If the buyer needs a Type 2, that is a second audit at a higher fee. The full first-year picture is in SOC 2 for AI startups, and the fee by firm tier and company size is in what a SOC 2 audit costs. Build your own number here; the only input that is yours is what an hour of your team costs.

Questionnaires you can offer instead of a report

If the buyer will take a questionnaire for now, offer a standard one. The common ones are the SIG from Shared Assessments (in Lite, Core and Detail tiers), the CAIQ from the Cloud Security Alliance, and the VSA-Full and VSA-Core from the Vendor Security Alliance. Answer one once, keep the answers current, and reuse them.

Here is what each issuer says its questionnaire is, read on their own pages:

Shared Assessments describes the SIG as a questionnaire "used to evaluate the risk controls of an organization's vendors and service providers," and its product page says that for service providers "the SIG demonstrates your security posture to your customers and prospects." The CAIQ is, in the CSA's words, "a set of Yes/No questions" a cloud customer may ask "of a cloud provider." The STAR Registry is where you can publish your answers once instead of resending them. The VSA says it "issues two free questionnaires."

Why bother? Because questionnaires are long and every buyer's is a little different. CBIZ, a CPA firm, notes that many exceed 100 questions, "in some cases, even exceeding 1,000." Founders on an older Hacker News thread suggested standardizing on the CAIQ and keeping an answer bank. A self-assessment carries no auditor opinion, so say plainly that it is one. Some buyers will still insist on their own form; your answer bank makes that faster too.

What to put on a simple trust page

A trust page is one place a buyer can find your security documents without emailing you. For a company with no report yet, it lists what exists today, what is available on request, and the dated plan for your audit. It should never imply a report you don't have.

This outline is our suggestion, modeled on how vendors like Anthropic and Lovable lay out their own trust centers, with documents listed and access granted on request:

1. Status line. "SOC 2 Type 1 audit with [firm], fieldwork starting [month]." Only once it is true.
2. Security overview. The one-pager from your packet.
3. Subprocessors. Every vendor that touches customer data, with what it does and where.
4. DPA. Your standard data processing agreement.
5. Policies on request. Access control, incident response, vendor management.
6. Completed questionnaire. Your CAIQ or SIG Lite answers, or a link to your STAR Registry entry.
7. Contact. One security email that someone reads.

Update it the day anything changes. A stale date on a trust page reads worse than no date.

The buyer's email is the start of a sales conversation, not a pass-or-fail test. Answer fast, be exact about what exists, and give a date you can keep. Everything else on compliance, from audit fees to questionnaires, is on the Security & Compliance hub.