---
title: "No SOC 2 yet? What to send when a customer asks"
canonical: "https://auditbadger.com/blog/no-soc-2-yet-what-to-send-when-a-customer-asks/"
last-updated: "2026-10-06"
---

# No SOC 2 yet? What to send when a customer asks

By Maciej • Published 2026-09-01 • 6 min read • Categories: Soc2, Compliance Governance, Knowledge Hub

Created with AI assistance. AuditBadger retains editorial control and responsibility.

**TL;DR:** When a prospect asks for a SOC 2 report you do not have, send a package rather than an apology: a one page security overview, the policies you actually operate, evidence that the basics are real (MFA enforced, access reviews, encrypted backups with a tested restore, documented offboarding, logging), a subprocessor list with your own vendors' reports attached, and a dated roadmap naming the framework and the target window. Say not yet in plain words with a date, because buyers accept an honest gap far more often than they accept a vague answer, and never claim an audit is in progress unless a CPA firm is actually engaged. What the buyer is really doing is a risk assessment, and the report is only a shortcut to it, so evidence of working controls answers the same question. Almost everything in that package becomes audit evidence later, which means none of the work is wasted, and the right moment to actually start is when a real deal is blocked or the second serious prospect asks.

A prospect just asked for your [SOC 2®](/blog/what-is-soc-2-compliance-the-complete-guide-for-founders-2026/) report. You do not have one. Before you panic or start pricing auditors, understand what actually just happened: they are running a risk assessment on you, and the report is a shortcut for it. Shortcuts are not the only route.

In our experience deals rarely die on the missing report. They die on the vague answer. "We take security very seriously and are working towards certification" tells a reviewer nothing, and it reads exactly like every company that is doing nothing.

Here is what to send instead.

## What the buyer is actually asking

Somebody on the other side has to sign off that adding you does not add unacceptable risk. If you have a report, they read the auditor's opinion and move on. If you do not, they have to do the assessment themselves, and their default assumption without information is the worst case.

Your job is to make their assessment easy, not to pretend you have something you do not. A small company with clear, specific, evidenced answers frequently clears review faster than a larger one hiding behind a PDF nobody reads past page four.

## The five things to send

### 1. [A one page security overview](/blog/trust-center-rebuilt-nda-access-branding-honest-claims/)

Not a brochure. One page covering: what data you hold and where it lives, who can access it, how you authenticate, how you encrypt in transit and at rest, your backup and recovery position, your subprocessors, and how to report a vulnerability to you.

Write it once. It answers the first half of most questionnaires and it is the single highest leverage document a small company can own.

### 2. The policies you actually operate

Access control, incident response, and a top level information security policy at minimum. The bar is not length. The bar is that they describe what you really do and someone can be seen to follow them.

Generic templates you have never read are worse than nothing, because reviewers recognise them and it costs you credibility on everything else you claim. If you need a starting point that reflects your actual company rather than a stock template, our [free policy generator](/free-policies/) builds a first draft from your context, and you edit from there.

### 3. Evidence that the basics are real

Claims are cheap; screenshots with dates are not. Show:

- MFA enforced across your identity provider and cloud accounts
- A recent access review, even if it was you and a spreadsheet on a Friday
- Encrypted backups, and a restore you have actually tested
- A documented offboarding checklist with one completed example
- Logging and alerting on your production environment
- Branch protection and code review on your main repository

That list is not arbitrary. Those are among the first things an auditor samples, so evidence you gather now is evidence you reuse later.

### 4. Your subprocessor list, with their reports

Name every vendor that can touch customer data, and attach the SOC 2 or ISO 27001 reports of the big ones. You inherit your vendors' security posture whether you assess it or not, and showing that you know who they are demonstrates the vendor management maturity the questionnaire is looking for. More on doing this properly in [vendor and third party risk management for startups](/blog/vendor-and-third-party-risk-management-for-startups/).

### 5. A dated roadmap

One short paragraph: which framework, which scope, what you have already done, and the window you are targeting. Dates make it a commitment. "Eventually" makes it a hope.

## How to say "not yet" without losing the deal

Three rules, learned the boring way.

**Be specific about the gap.**"We do not have a SOC 2 report today. We are targeting a Type I in Q1 and opening the Type II observation window immediately after." That is a sentence a reviewer can write into their file.

**Never imply you have it.** Do not say an audit is in progress unless a CPA firm is engaged and you can name the period. Security reviewers verify this, and getting caught converts a solvable gap into a trust problem that no report fixes.

**Offer something contractual.** A commitment in the agreement to deliver a report by a date, or to notify them of incidents within a set window, often carries more weight than the report itself. It costs you nothing if you were going to do it anyway.

## The good news about the work

Nearly everything in that package is audit evidence later. The one page overview becomes the seed of a SOC 2 system description. The access review is a control test. The restore test is continuity evidence. The subprocessor list is your vendor register.

This is the point of the whole exercise. You are not doing throwaway sales work to survive a questionnaire; you are doing the first third of the audit and getting paid for it in the meantime. When we built Quick Wins, this was the specific problem: staring at ninety three controls on day one is demoralising, and most teams have already done more than they think. Turning existing work into evidence is usually the fastest first move.

## So when should you actually start?

Our answer, and it is deliberately unexciting: when a real deal is blocked on it, or when the second serious prospect asks. One ask can be an inquiry. Two is a market signal, and by then you will pay for it in slipped deals rather than in audit fees.

Before that point, spend the money on hygiene instead. [SOC 2 for startups](/blog/soc-2-compliance-for-startups/) goes through the stage by stage version of that judgement, including what it realistically costs a small team.

One more thing worth doing early because it pays every time: put the security overview, the policy list and the subprocessor list on a page you can link to. A [Trust Center](https://auditbadger.com/features/trust-center/) on your own domain turns the whole conversation into a URL, and it stays useful after you have the report, because then it hosts that too.

For context on how long the second half takes: our own Type II observation window ran from 27 March to 27 June 2026, on AuditBadger, with no external consultants. Three months of the controls simply operating and being evidenced. Plan backwards from that, and start the package above today.


## Frequently asked questions

### What should I send to customers who ask for a SOC 2 report if I don't have one yet?

Send a five-part security package: a one-page security overview covering data storage and access controls, the policies you actually operate (access control, incident response, information security), evidence that basics are real (MFA screenshots, access reviews, backup tests), your subprocessor list with their compliance reports, and a dated roadmap to certification. This specific, evidenced approach clears security reviews faster than vague promises, and the evidence you gather now becomes audit evidence later when using tools like AuditBadger to organize it.

### Do we really need formal policies if we're only 10 people?

Yes. Policies aren't about company size—they're about demonstrating that you've thought through how you handle data, security, and operations. A 10-person startup seeking enterprise clients will face the same compliance questions as a 100-person company. Documented policies show maturity and reduce individual liability.

### How long does it take to prepare a security package for customer due diligence?

A credible security package can be assembled in days if you already operate basic controls—the work is documenting what you do, not inventing new practices. Using AuditBadger's policy generator and evidence library, small teams can create the one-page overview, policies, and evidence screenshots in a few focused sessions, then reuse that same package for every customer request and later for SOC 2 preparation.

### Can I use vendor SOC 2 reports in my own security reviews?

Yes—attaching your subprocessors' SOC 2 or ISO 27001 reports demonstrates vendor management maturity and helps you inherit their security posture. List every vendor that touches customer data and include reports from major ones. AuditBadger's vendor risk management features help track these reports and renewal dates so you always have current documentation ready for customer requests and audits.

### How long does it take to prepare for a SOC 2 audit?

Type I audits typically take 1–3 months total (preparation plus audit). Type II takes 6–15 months because it includes a mandatory 3–12 month observation period. Industry data shows 56% of organizations spend 3–6 months in the preparation phase alone, though companies using compliance automation platforms report cutting preparation time by roughly 40%. Starting from scratch with no documented policies will take longer than building on existing security practices.