An enterprise prospect's security team sends over a questionnaire, or a one-line email asking for your latest penetration test report, and the deal that was moving through your pipeline suddenly stalls on a document you don't have. This happens to almost every SaaS founder eventually, usually right when a deal is close to closing. Here's exactly what's being asked for, what to actually send back, and how to stop getting caught off guard by it.
What the request actually means
Enterprise buyers run vendor risk assessments before signing, and it's become close to universal for any deal involving customer data, financial information, or system integrations. The request usually shows up in one of three forms: a formal security questionnaire, sometimes a standardized format like SIG or CAIQ, sometimes custom to that company, a direct ask for your most recent penetration test or vulnerability assessment report, or a request tied to a broader vendor onboarding process, data handling practices, and incident response procedures.
The underlying question behind all three is the same: has an independent third party verified that your systems don't have exploitable vulnerabilities, and can you prove it with evidence rather than a verbal assurance. A line in your terms of service or a claim on your website that you "take security seriously" answers nothing here. What clears procurement is a dated, scoped report from an actual assessment.
Decoding what evidence is actually sufficient
Not every deal requires the same depth of proof, and knowing the difference saves you from either under-delivering or over-spending.
For mid-market deals, a recent vulnerability assessment, covering your web application, API, and cloud infrastructure, is usually enough to satisfy the request, especially if it's dated within the last twelve months and shows no unresolved critical or high-severity findings. This is the baseline most procurement teams are actually checking for.
For larger enterprise deals, particularly in regulated industries like finance, healthcare, or legal, expect the bar to move to a full penetration test, sometimes specifically requiring authenticated testing across identity and access controls, not just external, unauthenticated scanning.
The critical distinction to understand before you respond: an attestation letter and a full technical report are not the same document, and you should never send the second one to an external party.
What to actually send, and what to hold back
This is the part founders get wrong most often, and it creates a real security risk of its own. A full technical vulnerability assessment report contains exactly the kind of information an attacker would want: which endpoints were tested, what specific misconfigurations were found, how exploitability was verified, and detailed remediation status on issues that may not be fully closed yet. Sending that document to an external prospect, over email, before a contract or NDA is even signed, means handing a roadmap of your infrastructure to a party you don't have a formal relationship with yet, and to anyone who might see that email along the way.
What you actually share is a risk summary or attestation: confirmation that a scoped assessment was performed, by whom, when, what was covered, and the resolution status of findings, without the technical detail that makes those findings actionable to someone else. This is exactly why a properly structured audit deliverable separates the two from the start, a leadership-level risk summary built for exactly this kind of external sharing, and a technical breakdown, with affected assets, evidence, and specific remediation guidance, that stays internal with your engineering team. If your current report doesn't have that separation built in, you're stuck either oversharing or scrambling to redact something under deal pressure.
If you don't have an assessment yet
If a security questionnaire just landed and you have nothing to point to, the fastest path is scoping a vulnerability assessment against your core web app, API, and cloud account immediately. This doesn't need to take weeks. A properly scoped audit can start the same day and deliver a validated report quickly enough to keep a deal moving instead of stalling it in procurement for a month. For deals where the buyer is specifically asking for penetration testing rather than a vulnerability assessment, that requirement typically means scoping an extended audit with authenticated access, which takes more coordination but establishes the deeper evidence larger buyers expect.
If your last assessment is stale
An audit from eighteen months ago, even a clean one, doesn't carry the same weight it did when it was fresh, and a sharp procurement team will ask for the date before they ask for anything else. A stale report signals exactly what it is: evidence of what your environment looked like a long time ago, not what it looks like today after months of shipped code and infrastructure changes.
This is the strongest case for running vulnerability assessments on a recurring quarterly cadence instead of treating it as a one-time or annual event. When a customer request lands, you're not starting from zero. You're pulling a report that's current within the last quarter, which changes the entire dynamic of that conversation from reactive scrambling to a routine document exchange.
Getting ahead of the request instead of reacting to it
The founders who never get stuck on this step are the ones who treated security assessment as a standing part of their operating rhythm before a customer ever asked for it. A recurring audit, run quarterly rather than once a year, means you always have a current, verified report on hand, the moment a deal reaches the stage where a prospect's security team gets involved. That turns what's usually a deal-stalling scramble into a five-minute response: here's our most recent assessment, here's what it covers, here's confirmation nothing unresolved is outstanding.
The practical move
If you're facing this request right now with nothing to show, scope a core vulnerability assessment today, it's fast enough to unblock the deal in front of you. If this is the second or third time a customer has asked and you're tired of scrambling, move to a recurring quarterly cadence so the next request gets answered in minutes instead of weeks. Either way, when you do share results, send the risk summary built for external eyes, never the full technical report, and keep the detailed findings exactly where they belong: with your own engineering team, closing the gaps before anyone outside your company ever needs to know they existed.
