Your deal is done. Pricing is agreed, the champion is bought in, legal is redlining. Then it goes to the customer's security team and stops for nine weeks.
This is the most expensive gate in enterprise software sales and the one engineering teams prepare for last. It is also almost entirely predictable: the same artifacts get requested, in roughly the same order, by every enterprise buyer. This post is the list, what each one is actually for, and what to do when you do not have it yet.
Written for the founder or engineering lead at a software vendor selling upmarket for the first time.
What the review is actually testing
Not whether you are secure. Nobody can determine that from a document set.
It is testing whether you are a manageable third-party risk: whether you know what you run, whether someone is accountable, whether you will tell them when something goes wrong, and whether their own auditor will accept you in the vendor inventory. The reviewer's job is not to find your bugs. It is to be able to defend having approved you.
That reframing changes what a good answer looks like. A confident "we do not do that yet, here is what we do instead, here is when it lands" is a better answer than a vague yes, because the reviewer can write the first one down.
The seven artifacts, in request order
1. The security questionnaire. SIG Lite, CAIQ, or the customer's own spreadsheet. Between 80 and 400 questions. It arrives first because it is cheap for them to send.
Answer it once, properly, and keep the answers in a document you own. Most of the questions repeat across customers. The teams that suffer here are the ones answering from scratch each time, because inconsistency between two questionnaires is itself a finding.
2. Your SOC 2 report, or a credible explanation of its absence. Type I means the controls existed on one day. Type II means they operated over a period, usually three to twelve months. Enterprise buyers want Type II and will often accept Type I plus a date.
If you do not have one, say so in those words: which type you are pursuing, which auditor, which observation window, and the expected report date. Vague timelines read as no timeline. What loses deals is not the absence of the report, it is the discovery that you implied you had one.
3. A penetration test summary. Not the full report. The full report is a list of live findings and you should not be emailing it around, which is a point worth making to the reviewer because it demonstrates you understand what it is.
The summary version: scope, dates, who performed it, methodology, a count of findings by severity, and remediation status. One to two pages. Most reputable testing firms will produce this on request, or will let you produce it from their report.
4. An architecture and data flow diagram. Where their data lives, which regions, which subprocessors touch it, what is encrypted at rest and in transit, and how it is segregated from other customers' data.
Multi-tenancy is the question under the question. If you are shared-tenant, say so plainly and explain the isolation mechanism. Reviewers are not hostile to shared tenancy. They are hostile to discovering it in week six.
5. Your subprocessor list. Every third party that touches customer data: cloud provider, email sender, analytics, error tracking, support tooling, any AI model provider.
That last one has become the most scrutinised line on the list. If customer data reaches a model API, expect specific questions about retention, training use, and regional processing, and expect a clause about notifying them before you change providers.
6. An SBOM. Increasingly requested, and non-optional if your buyer is a US federal agency, a medical device manufacturer, or an EU-facing manufacturer under the CRA.
SPDX or CycloneDX, generated from your build rather than hand-assembled, and regenerated per release. A stale SBOM is worse than none, because it is a document asserting something untrue about the thing you shipped.
7. Policy documents. Incident response, access control, secure development, business continuity, vendor management. The reviewer is checking existence and ownership, not prose quality.
Write short ones that describe what you actually do. A twelve-page policy copied from a template, describing a change advisory board you do not have, fails the moment they ask for evidence of the last meeting.
The four questions that stall deals
From watching these go wrong, the recurring blockers are narrow.
"Do you have SOC 2 Type II?" covered above. Have a date.
"Can we see your last pen test?" If the answer is that you have never had one, that is a hard stop at most enterprises. A scoped external test is a few thousand dollars and weeks of lead time. Book it before you need it, not when the questionnaire arrives.
"How do you handle a vulnerability in a dependency?" They want a process, not a tool name. Who is notified, what the severity thresholds are, what your remediation SLA is by severity, and how you tell customers. Having an SLA you meet 80 percent of the time beats claiming one you invented for the questionnaire.
"What happens to our data when we leave?" Deletion timeline, backup retention, and what you do about the copies in backups that outlive the deletion request. Answering this precisely, including the honest backup lag, is one of the fastest credibility wins available.
What to do six months before you need it
The pattern that works is to stop treating this as a sales problem.
Assign one owner, an engineer, not a salesperson. Keep a single source of truth for answers, versioned, in the repository if you like. Regenerate the SBOM in CI so it is never stale. Book the pen test annually on a calendar rather than reactively. Write the four policies you will actually be asked for, short, and review them once a year.
The compounding effect is real. The first enterprise review costs six to nine weeks. The fifth costs two, because the artifacts exist, they agree with each other, and the answers have been given before.
The concession
Some of this is theatre. A questionnaire cannot distinguish a company with real controls from one with good documentation, and everyone involved knows it. Reviewers know their process has limited signal, which is why the good ones spend their time on the two or three answers that suggest you have thought about your own failure modes.
So do not optimise for passing. Optimise for being the vendor whose answers are specific, consistent, and occasionally admit a gap. That is the profile that clears review fastest, and it happens to be the same profile as actually being competent.
The implication
Enterprise security review is a documentation exercise about a real thing. Teams lose weeks because they treat it as a surprise, and the artifacts take weeks to produce because they were never produced before.
None of the seven items above takes long if it is created ahead of the request. All of them take a quarter if they are created in response to one. The cost of preparing early is a few engineering days. The cost of preparing late is measured in delayed revenue, and it lands in the quarter you least wanted it.
