A customer just asked for our SOC 2 and we don't have one — what do I actually do?

You have been asked for a document that certifies how your company runs, by a buyer who will read its absence as a verdict on your product, because you sell security. A SOC 2 report says how a company runs itself. It says nothing about whether the product works, and a security buyer does not keep those two apart.

Find out which gate you are standing at.

You match the audit to the buyer who asked for it, not to a checklist. Compliance tooling is sold to seed-stage security companies as something everyone needs first. In our portfolio it has rarely blocked a design partner, who accepts immaturity as the price of shaping your roadmap. It becomes the constraint at large regulated companies, whose procurement gate is where the report actually gets consumed. And in companies that sell through partners to smaller businesses it has never mattered at all, because the partner handles the compliance conversation.

So the first move is a question to your champion, not a platform subscription. Who asked, which gate is it sitting in, what has their risk team accepted from other vendors without a report, and which audit firms do they accept? Large buyers deliberately separate the commercial yes, the legal review, the security review, and the final approval so that no one person can commit the firm, which means the security review starts after you have already won on the merits. Write the approval path down. Either it contains a third-party-risk gate that consumes a report or it does not, and everything below depends on which.

Send what you have this week.

You answer a request for a report you do not have with evidence that you run the company the way the report would say. Build that package now, whatever the buyer turns out to be, because for a security vendor it is the buyer's first look at whether you practice what you sell.

Send your written policies, dated and with owners named. Free templates exist, and each one still has to be edited to describe what your company actually does. The ones a reviewer opens first cover access control, incident response, vendor management, and secure development. Send the architecture page, the one-page description of what the product touches, what privileges it needs, what data it sees and stores, where it runs, the tenant boundary, how it fails, and what the buyer must run themselves. Send your latest penetration test letter. Send a completed MVSP self-assessment, which is the checklist that enterprise security teams wrote to be answered at RFP stage. Register a CSA STAR Level 1 entry, which is free and public. Publish a vulnerability disclosure policy with a security.txt file behind it.

Two things founders reach for do not belong in the package. A bridge letter assumes a completed report. A readiness dashboard's percentage is not an attestation. The one document that turns a no into a conditional yes is a signed engagement letter from a named CPA firm with a target date for a Type 1 report. Ask your champion whether their program allows a risk exception or a conditional approval, who signs it, and how long it runs. That signature, not your report, is what closes this deal, and it needs a date to work. Put all of it behind a trust center.

Sequence the audit to the deal.

You choose between a Type 1 report now and a Type 2 report later by what the order form needs to say, not by what a platform's onboarding suggests. A Type 1 says your controls are designed properly. A Type 2 says they operated over an observation window, and the window is calendar time that nothing shortens. Audit-ready in days means the evidence has been collected, not that an opinion exists. Enterprise and regulated buyers expect a Type 2. A Type 1 buys you a conversation and a date, and the observation window starts when your controls are operating and evidence is flowing, not when you sign a contract.

Define the boundary of the system before the criteria, because for a security product the boundary is the whole argument. It includes the control plane you operate, the agent or integration that runs inside the buyer's environment with the buyer's privileges, and the cloud underneath, which you carve out to its provider's own report. Then choose the criteria. Security always, and Confidentiality where you hold the buyer's data. The part of the report that lists controls the buyer must run themselves is the paragraph their reviewer reads hardest, because it describes the access you asked for.

Large buyers who want the deal will sign this shape: a Type 1 in hand or dated, a Type 2 window already running, both dates written into the order form, and a right to terminate if you miss them.

You are buying three things.

You are buying the software that collects evidence, the accountant who signs the opinion, and the penetration test. Some platforms leave the auditor to you. Some include a CPA firm in the price. Compare the platform plus an auditor against the bundle, never one platform against another, and nobody pays list price.

The auditor's fees for a Type 1 and a Type 2 overlap, so a Type 1 bought as the cheap option is a second invoice for the same buyer. Ask the auditor to price each factor separately: the scope, the report type, how mature your controls are, your locations, and your subservice providers. Buy the platform when you commit to an observation window, because a Type 1 alone can run on a spreadsheet. Buy fractional security leadership if you buy any, because a senior first hire in compliance produces a program document rather than hardened systems. We offer no house pick. Choose by the auditor, not by the dashboard.

The auditor's name is read before the opinion.

You will be judged on who signed. Risk teams now check that the CPA firm is licensed and peer-reviewed, has no business tie to the platform, designed its own tests, and dated the opinion after the window closed, because reports that failed those tests have been thrown out. Your champion's list of accepted audit firms is internal and real. Ask for it.

Then check the license yourself, in the state accountancy board's database and the accounting profession's public peer-review file, because a report from a firm the buyer has blacklisted gets thrown out.

The bar a security vendor is held to.

You are being reviewed by a peer, not by a procurement clerk, and the report is the least of what they read. A payroll vendor's report gets filed by a risk analyst who reads the opinion page. Yours gets opened by a security engineer who reads the exceptions, the scope, the auditor, and the penetration test, and then reads the product: the privileges it runs with, the data it sees, and how it deploys. A security product lands in the high-access tier by definition, and a weak report from a security company earns a yellow rating and a questionnaire rather than a green one.

Expect to be scanned, not only read. And expect the review to run again on events you do not control: a peer's breach, a new CISO, a champion who leaves partway through. Build a second champion before you need one, and keep the package current for the day a peer is breached.

Know when the answer is not yet.

You spend the audit's money and your own attention only when a written approval path contains a third-party-risk gate that consumes a report. A pipeline of logos whose approval paths nobody has asked about is a not-yet. The evidence package still gets built, because it is proof of the product. Starting the audit too early locks controls into a Type 1 before you know what the product needs, and pays for monitoring of an evidence trail that does not exist yet.

Geography changes the instrument, not the timing. European procurement names ISO 27001, and a European buyer may not accept SOC 2 as equivalent, so confirm it with the buyer rather than assuming. Pick the framework the next year of buyers will ask for, map your controls once, and never run two first audits at the same time.