How to answer a SOC 2 request before you have a report
What a prospect means when the security questionnaire asks for SOC 2, how Type I and Type II differ in evidence and time, and what you can honestly send while the report is months away.
Question forty-three of the security questionnaire: please attach your SOC 2 report.
You don't have one.
The deal is the biggest on your pipeline, and it suddenly feels like it just died in a spreadsheet cell.
It hasn't. That line is a request for evidence, not a verdict, and there are honest ways to supply some of the evidence while the report itself is still months out.
By the end of this post you'll know what the report actually is, how the two types differ, how long each one really takes, and what you can send the buyer on Monday.
What the buyer is actually asking for
Most companies get one thing wrong on the first try. SOC 2 is less a certificate you win and hang on the wall than an attestation, which means an independent firm looks at how you run your system, then writes up its professional opinion.
The framework comes from the AICPA, the US accounting profession's governing body. A licensed firm examines the controls around the system you sell to customers and measures them against the AICPA's Trust Services Criteria. "Controls" here just means the things you do to keep the system safe and running: how you grant access, how you review changes, how you take backups.
There are five criteria: security, availability, processing integrity, confidentiality and privacy. Every report covers security. You add the others when they matter to what you sell.
So nobody certifies you, and there is no pass mark. What you get is a document describing your system, the controls you claim to run, the tests the auditor performed, and any exceptions, which is the auditor's word for places where a control didn't do what you said it does. The buyer's security team reads all that to work out how much risk you add to their own vendor list.
Which is also why they ask. In Vanta's State of Trust Report 2024, a survey of business and IT leaders, plenty of them had already been let down by a supplier:
Type I and Type II are two different products
A restaurant inspector can do this two ways. Walk in on a Tuesday morning and look around. Or review six months of temperature logs, delivery records and staff sign-offs. Both are real checks, but only the second one tells you what the kitchen is like on an ordinary Thursday.
That is the gap between the two report types. A Type I looks at a single date and asks whether your controls are well designed and actually in place that day. A Type II covers a stretch of time. The auditor samples evidence from across that window to see whether the controls kept working the whole way through, meaning every departing employee's access actually removed, every access review actually done, every change actually approved.
The difference shows up hard in the results. KPMG's UK practice looked back at the controls assurance reports it had issued over a three-year stretch, and published what it found in its SOC Reporting Benchmarking 2024:
Roughly four in ten Type I reports came back with nothing to flag. Among Type II reports, almost none did. The only thing that changed is that somebody checked whether the work kept happening over months, rather than on one well-prepared morning.
Two things follow. A Type I is a sensible first step and some buyers will take it from a young company, but it is weaker evidence and any good security reviewer knows it.
And your first Type II will probably have exceptions in it. That is normal, even expected. What matters is that they are small, explained and already fixed. Which is the real argument for running your controls properly well before the audit window opens, rather than tidying up once it has.
How long does this actually take?
You can't rush a Type II, since the passage of time is the evidence. No amount of weekend work compresses six months of access reviews into a fortnight.
Platforms that helps companies prepare for these audits, put the minimum window at three months, and suggest at least six for a first report if you aren't racing a specific deal. Established companies settle into a rolling twelve-month cycle.
Then comes the part most teams forget. When the window closes, the auditor hasn't finished. They still have to test the samples, chase the gaps and write the thing. In a benchmark of SOC reports by the audit firm CBIZ, reports landed on average 69.9 days after the period ended. That is ten weeks of nothing you can do anything about, after the audit you thought was over.
| Stage | What happens | What drives the length |
|---|---|---|
| Readiness | Decide scope, write policies, fix gaps in access, logging, backups and change control | How far your current setup is from what you will claim |
| Type I | Auditor checks design and implementation on one date | Auditor availability and how organised your evidence is |
| Type II window | Controls run while the auditor's sample period runs | Agreed with the auditor; three months at the shortest |
| Type II report | Testing, findings, drafting, issue | About ten weeks on average after the window, per CBIZ |
Add it up carefully before you promise anyone anything. Readiness, plus a three-month window, plus roughly ten weeks of writing, puts a first Type II about six months away. And that's if your controls are nearly ready today. A Type I can arrive far sooner, since it only needs one good day. But that day has to be a good one.
Ask them which one they need
The most useful thing you can do this week costs you one email. Ask the prospect directly whether their review accepts a Type I. A Type II in progress with a committed date? Or do you need a completed Type II before anyone signs?
Companies almost always assume the strictest answer and start planning around it. Often that is not the answer. Plenty of security teams have a documented path for vendors who don't have a report yet, and the only way to find out is to ask.
The replies tend to land in one of three buckets.
- Type I now, Type II later. They'll take the single-date report today and expect the full one by renewal.
- Proceed with a commitment. The contract moves forward with a security addendum that ties you to a Type II by a specific date.
- No report, no deal. Common in regulated industries. They need a completed Type II and they will not budge.
You want to know which bucket you're in before you build a plan, not three months into one.
What to send while the report doesn't exist
You can't hand over a report you don't have. What you can do is make the reviewer's file as complete as you truthfully can, and that counts for more than most companies expect.
Answer the questionnaire straight. For every control, say whether it is in place, partly in place or planned, and put a date on the planned ones. "Yes" to all of it from a company with no report reads as either careless or untrue. Worse, it becomes a contract representation you may have to defend later.
Use a standard format if they'll allow it. The Cloud Security Alliance's CAIQ is a widely recognised self-assessment for cloud services, essentially the industry's shared version of this questionnaire. Fill it in once and you have a reusable answer bank for the next buyer.
Separate what AWS covers from what you cover. AWS publishes its own SOC reports, free to download from AWS Artifact, and they handle the data centre and infrastructure questions nicely. They say nothing about your application, your permissions setup or your people. The shared responsibility model spells out that split. AWS secures the building, you secure what you put inside it. Present their reports as the bottom layer, never as yours.
Show the documents that do exist. Your access control, incident response and change management policies. An architecture diagram showing where customer data actually lives. The date you last tested restoring a backup. If none of that exists yet, writing it is part of readiness anyway, so you lose nothing by starting now.
Name a date only once you have one. "We have engaged an audit firm and our Type I fieldwork is booked for March" is evidence. "We are working towards SOC 2" is a feeling. And steer clear of the phrase "SOC 2 compliant" until a report is in your hands. Without one, there is no such status to claim.
The second questionnaire is much cheaper
Know this before you start. The questions barely change from one buyer to the next. Who can reach production. How you remove someone's access when they leave. What you log. Whether you have ever actually restored a backup. Who reviews code before it ships.
Once the controls really exist and your evidence is organised against them, every questionnaire after the first is mostly retrieval. In my experience that is the moment this stops feeling like a tax and starts feeling like plumbing you already installed.
A compliance platform helps keep that evidence current, as long as you are clear about what it does. It monitors controls you already run. It will not decide your scope or fix your permissions setup for you.
What to do this week
Reply to the prospect within a day or two and tell them plainly that you don't hold a SOC 2 report yet. Ask which report type their review accepts, and tell them when your completed questionnaire will land.
Then fill it in accurately, marking planned controls as planned. Ask two or three audit firms what their availability looks like and what Type II window they'd accept for a first report.
Do that and the date you eventually give the buyer is one you can actually hit. Which, when a security reviewer is deciding whether to trust you, matters rather more than the report itself.