Why enterprise security reviews happen
Enterprise companies have security and legal teams whose job is to assess vendor risk before signing contracts. A breach at a vendor is a breach of their customer data too — and their security team is accountable for it. The questionnaire is how they document that they did due diligence.
The good news: most enterprise security reviews are not trying to disqualify you. They're trying to assess your maturity and identify gaps they'll need to manage. A startup that has done basic security work, can demonstrate it with evidence, and has a credible roadmap to certification will pass most reviews.
The bad news: you can't fake your way through this with marketing language. Reviewers do this every day. Vague answers about "industry-standard security practices" will be flagged and escalated. Evidence closes deals. Assurances stall them.
The questions — and what good answers look like
For each question: what the reviewer is actually assessing, what a strong answer contains, and what answer will stall the deal.
Penetration Testing
"Do you conduct regular penetration tests? How frequently?"
What they're assessing: They want to know if you have any external validation of your security posture — not just internal confidence.
Strong answer
We run automated penetration testing on every deployment and conduct manual penetration testing annually. Automated tests cover OWASP Top 10, API exploit paths, authentication weaknesses, and injection attacks. Results are available on request.
Stalls the deal
"We follow security best practices" or "our developers write secure code" — these are not answers to this question.
"Can you provide a recent penetration test report?"
What they're assessing: They want evidence, not assurances. A report — even an automated one — is infinitely more credible than a verbal claim.
Strong answer
A dated report with findings, severities, and remediation status. Automated simulation reports with HTTP proof-of-concept evidence satisfy this for most mid-market prospects. Enterprise prospects and regulated industries may require a report from a named testing firm.
Stalls the deal
"We don't have a report but we're very confident in our security." This will stall or kill the deal.
"What vulnerabilities were found in your last test, and how were they remediated?"
What they're assessing: They're not expecting zero findings — they're assessing whether you have a process. A response that shows you found something, understood its severity, and fixed it is more credible than claiming nothing was found.
Strong answer
Honest summary: "Our last test identified 2 medium-severity findings — a CORS misconfiguration and a missing rate limit on a login endpoint. Both were remediated within 48 hours and validated in the subsequent scan."
Stalls the deal
Claiming zero findings from an automated scan. Sophisticated buyers know this means the scan wasn't comprehensive.
Data Security
"How is customer data encrypted at rest and in transit?"
What they're assessing: They want specifics: which encryption standard, which key management approach, whether backups are encrypted. Vague answers fail.
Strong answer
"Customer data is encrypted at rest using AES-256. All data in transit uses TLS 1.2 or higher. Database backups are encrypted with the same standard. Encryption keys are managed through [provider]."
Stalls the deal
"We use industry-standard encryption." This tells them nothing.
"Where is customer data stored? Which regions or data centers?"
What they're assessing: Data residency matters for GDPR compliance (EU customers), financial regulations, and some government contracts. If you use a cloud provider, name the specific regions.
Strong answer
"Customer data is stored in AWS eu-west-1 (Ireland). We do not replicate data outside the EU without explicit customer consent."
Stalls the deal
"On secure cloud servers."
"Do you have a data retention and deletion policy?"
What they're assessing: GDPR and similar regulations require data to be deleted when no longer needed. They want to know you can actually delete their data if they terminate.
Strong answer
A written policy with specific retention periods by data type and a documented process for customer-requested deletion within a defined timeframe.
Stalls the deal
No written policy, or a policy that doesn't include customer-requested deletion.
Access Control
"Who has access to customer data within your organisation?"
What they're assessing: They want to know you follow the principle of least privilege — only people who need access to do their job have it.
Strong answer
"Access to production customer data is limited to [N] engineers on a need-to-know basis. Access is reviewed quarterly and revoked immediately on role change or departure. All access is logged and auditable."
Stalls the deal
"Our whole engineering team has access." Or not knowing the answer.
"Do you enforce multi-factor authentication for internal systems?"
What they're assessing: MFA for production access is a baseline expectation for enterprise buyers. If your answer is no, they'll note it as a gap.
Strong answer
MFA enforced for all production system access, cloud consoles, and code repositories. SSO with MFA preferred.
Stalls the deal
Password-only access to production systems.
Compliance & Certifications
"Are you SOC 2, ISO 27001, or PCI DSS certified?"
What they're assessing: Certifications signal a third party has audited your controls. Not having them isn't always a dealbreaker — but you need a credible answer about your roadmap.
Strong answer
"We are currently pursuing SOC 2 Type II certification, expected [date]. In the interim, we can share our security policy documentation and penetration test reports." If you have a certification, share the report.
Stalls the deal
"No" with nothing further.
"How do you handle security incidents and breaches?"
What they're assessing: They want to know you have a process and that they'll be notified within a defined timeframe. GDPR requires notification within 72 hours — many enterprise contracts require faster.
Strong answer
A written incident response plan with defined severity levels, escalation paths, and customer notification timelines (e.g., within 24 hours for any incident affecting customer data).
Stalls the deal
"We'd deal with it at the time."
"Do you conduct employee security training?"
What they're assessing: Phishing and social engineering account for a significant proportion of breaches. They want to know your team knows how to recognise an attack.
Strong answer
Annual security awareness training with phishing simulations. New hire security onboarding. Specific training for engineers on secure coding practices.
Stalls the deal
No formal training program.
The single most common dealbreaker
Across every category, the same pattern kills deals: a question that requires evidence getting an answer that's just an assertion.
"Do you conduct penetration tests?" — "Yes, we take security very seriously." That's not an answer. It's a non-answer that signals you don't have anything to show. The reviewer notes it as a red flag and escalates.
The fix is straightforward: have the evidence before you need it. A penetration test report — even from automated simulation with HTTP proof-of-concept findings — is a document you can attach to your security questionnaire response. It shows dates, scope, findings, and remediation status. It's auditable. It closes the loop.
Building your security posture before the questionnaire arrives
Run a penetration test and get a dated report
This single item answers a third of the questionnaire. Even an automated simulation report with confirmed findings and remediation status is significantly better than no report. Attach it to every security questionnaire response.
Write down your security policies
Data retention policy, incident response plan, access control policy, password policy. These don't need to be long — a one-page incident response plan that defines severity levels and customer notification timelines is real. An unwritten plan that "everyone knows" is not.
Enforce MFA on production systems
Cloud console, code repository, production database access. This is a baseline expectation and simple to implement. Not having it is a red flag that's hard to justify.
Document who has access to customer data
Know the answer to 'who can access production customer data' before you're asked. It should be a small number with a business justification for each person. Document it and review it quarterly.
Start a SOC 2 roadmap
You don't need a SOC 2 certificate to pass most enterprise reviews — you need a credible roadmap with a target date. Starting the process, even six months from completion, is a material difference from not having started.
What reviewers know that startups often don't
Enterprise security reviewers assess dozens of vendors per year. They can tell the difference between a startup that has genuinely done the work and one that has written confident-sounding answers with nothing behind them.
They're not expecting enterprise-grade security from a 10-person startup. They're expecting honesty, a basic set of controls in place, and evidence that you take the responsibility of holding their data seriously. A startup that says "we have automated pentest coverage on every deployment, here's our most recent report, and we're targeting SOC 2 by Q4" is a startup that passes a security review — not because the answer is perfect, but because it's credible and documented.
Get a dated security findings report before the questionnaire arrives
Nautillo Pro runs automated vulnerability scanning against your web application and generates a dated report with confirmed findings, severity ratings, and HTTP proof-of-concept evidence. Attach it to your next security questionnaire. Free to start, results in minutes.