What the questionnaire is actually asking
Security questionnaires exist because enterprise buyers have legal exposure when a vendor gets breached. Their security team is accountable for assessing vendor risk before the contract is signed. The questionnaire is how they document that they did the work.
Most questions fall into four buckets: application security (has anyone actually tried to break your app?), data handling (where does our data go, who can see it?), access controls (who can reach production?), and compliance posture (what certifications do you have or plan to get?).
The application security section is the one most startups stumble on — specifically the penetration testing questions. Not because the bar is unreachable, but because the expected answer is a document, not an assertion.
Why "we take security seriously" kills deals
The person reviewing your questionnaire assesses dozens of vendors per year. They know the difference between a startup that has done the work and one that has written confident-sounding answers with nothing behind them.
Vague answers to evidence-based questions — "we follow best practices," "our developers write secure code," "we haven't had any breaches" — are flagged, escalated, and used to push for a security addendum or risk acceptance waiver. That slows the deal and sometimes kills it.
A dated report with two confirmed findings and documented remediation is more credible than a claim of perfect security. Reviewers know production apps have vulnerabilities. A startup that found one, fixed it, and proved the fix is a startup that has a security process. That's what they're assessing.
What counts as acceptable evidence
Dated report
A PDF with a timestamp, the URL or scope tested, a list of findings with severity ratings, and remediation status for each. The date matters — it shows the test happened recently, not three years ago.
HTTP proof-of-concept for confirmed findings
The request that triggered the vulnerability and the response that proves impact. For example: GET /api/orders/2 → 200 OK (expected 403). This is the difference between 'we found a potential issue' and 'we confirmed this is exploitable.'
Remediation record
Evidence that findings were fixed and verified. Ideally a subsequent scan showing the same endpoint no longer returns a confirmed finding. Not just 'we fixed it' — a timestamp showing the fix was tested.
Testing cadence
The strongest questionnaire answer is 'after every deployment.' This tells the reviewer security is integrated into your release process, not a one-time checkbox. Automated attack simulation makes this feasible at any team size.
The questions — and what strong answers look like
The five penetration testing questions that appear in most enterprise security questionnaires.
"Do you conduct regular penetration testing?"
What they're assessing: They want external validation that someone has actively tried to break your application — not just that developers wrote careful code. 'Regular' means at minimum annually; ideally per-release.
Strong answer
Yes. We run automated attack simulation on every deployment covering OWASP Top 10, API authorization flaws, injection attacks, and authentication bypass. We can provide a dated report with confirmed findings and HTTP proof-of-concept evidence on request.
Stalls the deal
"We follow secure coding practices" or "our developers review code for security issues." These are not answers to this question. Reviewers will note the evasion.
"Can you provide a recent penetration test report?"
What they're assessing: They want a document, not a claim. A report with a date, scope, confirmed findings, severity ratings, and remediation status. Automated simulation reports satisfy this for most mid-market buyers; enterprise and regulated industries may require a named testing firm.
Strong answer
A PDF with a timestamp, the URL or scope tested, a list of confirmed findings with CVSS scores and HTTP evidence, and remediation status for each. If findings were open at time of report, include a note on remediation timeline.
Stalls the deal
"We don't have a formal report but we're confident in our security posture." This is the single most common answer that stalls deals. A report with two findings is more credible than no report.
"What vulnerabilities were found in your last test, and how were they remediated?"
What they're assessing: Reviewers are not expecting zero findings — they're assessing whether you have a process. Finding something, understanding its severity, fixing it, and verifying the fix is a stronger signal than claiming nothing was found.
Strong answer
"Our last simulation identified one critical finding — an IDOR on the orders endpoint where a user could access other users' order data by incrementing the ID. Confirmed with HTTP proof (GET /api/orders/2 → 200 OK, expected 403). Remediated with server-side ownership check within 24 hours, verified clean in the next scan."
Stalls the deal
"Nothing was found" from an automated scan. Experienced reviewers know this means the scope was too narrow or the tool didn't run properly. It raises more questions than zero findings answers.
"How frequently do you run security tests?"
What they're assessing: This is a question about cadence — they want to know security is ongoing, not a one-time checkbox. Per-deployment is the strongest answer. Annually is the minimum acceptable. Quarterly is common for growing startups.
Strong answer
"Every significant deployment. Our CI/CD pipeline triggers an automated attack simulation on every release to staging. Results are available within minutes."
Stalls the deal
"Once a year" — it's technically acceptable but signals security is a compliance checkbox rather than an integrated practice. If the deal is big enough, they may ask for the last three reports.
"Do you have a process for addressing security findings?"
What they're assessing: They want to know findings don't sit in a backlog forever. A defined severity-to-SLA mapping and evidence that you actually close findings matters more than the process being sophisticated.
Strong answer
"Critical findings are patched within 24–48 hours and verified in the next scan. High findings within one week. A fix is not considered closed until the vulnerability is confirmed absent in a subsequent test."
Stalls the deal
"We fix things when they come up." No defined timeline, no verification step. Leaves them uncertain about what happens if a finding affects their data.
The deal-saving move: run before you reply
Most security questionnaires give you 5–10 business days to respond. That's enough time to run an attack simulation, review the findings, remediate any critical issues, and attach a dated report to your response.
The sequence:
Run a simulation today
Free to start. Enter your target URL, complete domain authorization, and launch. Most scans complete in 3–15 minutes.
Review and remediate critical findings
If the scan finds a critical vulnerability, fix it before sending the questionnaire. A remediated finding is better than an open one — and a disclosed, remediated finding is better than a hidden one that gets found later.
Attach the PDF report to your response
Include it as an appendix. Label it 'Most recent penetration test report — [date].' This turns the vague penetration testing section into a documented, auditable answer.
Add a note on cadence
"We run automated attack simulation on every deployment. This report reflects our most recent run. Historical reports are available on request." This answers the frequency question and signals a mature process.
What if the scan finds something critical?
Fix it first, then respond. This sounds obvious but many founders fear that a finding will kill the deal. It won't. What kills deals is a finding that the reviewer discovers independently or that appears in a breach.
A report that shows a critical finding with a remediation timestamp 48 hours later demonstrates exactly the process enterprise buyers want to see: you test, you find things, you fix them fast. That's the mature answer.
If you're genuinely not sure you can remediate quickly, disclose the finding in your questionnaire response with the remediation plan and expected fix date. Buyers can often accept an open finding with a credible remediation timeline — they cannot accept discovering it later.
Get a dated report before you reply
Nautillo Pro runs an attack simulation against your web application and generates a PDF with confirmed findings, CVSS scores, and HTTP proof-of-concept evidence. Attach it to your next security questionnaire response. Free to start, results in minutes.