What enterprise customers actually check during security review (and how to not fail)

Here's something that surprises a lot of founders in their first enterprise sales cycle: the security questionnaire usually comes before anyone asks for your SOC 2 report. Prospects send it early -- sometimes before you've even done a proper demo -- because their security team requires a baseline review before the deal can progress.

And it can kill deals at a stage where you thought you were just getting started.

I've filled out a lot of these questionnaires from the vendor side, and I've reviewed a lot of them from the buyer side. The questions are remarkably consistent across companies. The answers that kill deals are also remarkably consistent. Here's what enterprise buyers are actually asking, what good answers look like, and how to get there.

The baseline: what is a VSQ?

A Vendor Security Questionnaire (VSQ) -- also called a Third-Party Risk Assessment or Vendor Risk Assessment -- is a structured form that enterprise buyers use to evaluate the security posture of their software vendors. They range from 20 questions to 300+ questions depending on the buyer's industry and risk appetite.

The most common standardized format is the Consensus Assessments Initiative Questionnaire (CAIQ) from the Cloud Security Alliance. Some companies use their own proprietary forms. Many use SIG (Standardized Information Gathering) questionnaires. The specific format varies, but the underlying questions are remarkably similar.

Below are the top 20 questions that appear on virtually every VSQ, along with what good answers actually look like.

1. Do you have a SOC 2 report?

What they're asking: Do you have independent third-party verification that your security controls work?

Good answer: Yes, Type 2, covering the Security trust services criterion, observation period ending [date], available under NDA. Or: "We're currently in our observation period targeting a Type 2 report in [quarter]."

How to get there: This is the entire premise of the compliance process. If you don't have one, say you're working toward it and give a credible timeline.

2. Do all users have multi-factor authentication enforced?

What they're asking: Can a stolen password alone compromise your systems?

Good answer: MFA is enforced at the IdP level for all users accessing production systems, with no bypass. Hardware keys required for privileged access.

How to get there: Enforce MFA in your IdP (Okta, Google Workspace, etc.) with no exceptions. For AWS, enable MFA on the root account and all IAM users, and require MFA via SCPs if you're using Organizations.

3. How do you handle encryption at rest and in transit?

What they're asking: Is our data protected if your storage is compromised, and is it protected in transit?

Good answer: All data at rest encrypted with AES-256 (RDS encrypted, S3 encrypted, EBS volumes encrypted). All data in transit over TLS 1.2 or higher, with TLS 1.0/1.1 disabled. Internal service-to-service communication also encrypted.

How to get there: Enable encryption on all RDS instances and S3 buckets. Use ACM for certificates. Disable old TLS versions at the load balancer level.

4. Do you have a penetration testing program?

What they're asking: Have you had an adversary try to break your systems recently?

Good answer: Annual penetration test by a named third-party firm. Most recent test [month/year], no critical findings open, all findings remediated or in remediation with tracked timelines.

How to get there: Engage a pen test firm. The first test usually surfaces real findings. Fix them. The test itself is less important than your remediation process.

5. How do you manage access to production systems?

What they're asking: Who can get to customer data, and what's preventing unauthorized access?

Good answer: Production access limited to engineers with a documented business need, enforced via IAM roles. No shared credentials. Access reviewed quarterly. All access logged and monitored. Breakglass procedures documented for emergency access.

How to get there: Audit your IAM policies. Implement least privilege. Set up CloudTrail with alerts on sensitive API calls.

6. What is your incident response process?

What they're asking: If something goes wrong, will you catch it, contain it, and tell us about it in a reasonable timeframe?

Good answer: Documented incident response plan including detection, containment, eradication, recovery, and post-mortem phases. Incident response team defined with on-call coverage. Customer notification within [X hours] for incidents affecting customer data.

How to get there: Write an incident response policy. Define your on-call rotation. Make sure you have alerting in place (CloudWatch, GuardDuty) so you actually detect incidents. Practice a tabletop exercise once a year.

7. Do you conduct background checks on employees?

What they're asking: Have you verified that your employees are who they say they are?

Good answer: Background checks conducted on all full-time employees before start date, including identity verification, criminal history, and employment history verification. Contractors working with customer data subject to the same requirements.

How to get there: Use a background check service. This is a $30-50 per-person cost. There's no good reason not to do it.

8. How do you manage third-party vendor risk?

What they're asking: Do your vendors' security failures become our problem?

Good answer: Vendor inventory maintained with security classification. SOC 2 reports or equivalent reviewed annually for vendors with access to customer data. Vendor contracts include security and data handling requirements. Annual vendor risk review conducted.

How to get there: Make a list of every third-party tool that touches customer data. Check which ones have SOC 2 reports (most do -- look on their security pages). Note the ones that don't and decide whether that's acceptable.

9. What is your data retention and deletion policy?

What they're asking: Will you delete our data when we stop being your customer, and are you keeping data longer than you need to?

Good answer: Customer data retained for [X days/months] after contract termination, then securely deleted. Data deletion upon request within [X business days]. Retention periods defined per data classification in our data retention policy.

How to get there: Write a data retention policy. Implement a data deletion process. Make sure you can actually execute it when a customer offboards.

10. Do you have a vulnerability management program?

What they're asking: Do you have a systematic process for finding and fixing security vulnerabilities?

Good answer: Dependencies scanned on every build via [tool]. Container images scanned before deployment. Critical vulnerabilities remediated within 24 hours, high within 7 days, medium within 30 days, low tracked and triaged. Infrastructure vulnerability scanning via [tool].

How to get there: Add npm audit or pip-audit to your CI pipeline. Enable ECR scanning if you use containers. Enable AWS Security Hub for infrastructure-level findings.

11. Do you have a business continuity and disaster recovery plan?

What they're asking: If you go down, can you recover? And if so, how fast?

Good answer: Documented BC/DR plan with RPO of [X hours] and RTO of [X hours]. RDS automated backups enabled with [X days] retention. Multi-AZ deployment for critical services. DR tested [annually/semi-annually] with documented results.

How to get there: Write down what happens if your primary RDS instance fails. Set your RTO and RPO goals and verify your infrastructure can meet them. Enable Multi-AZ on RDS.

12. Is customer data logically isolated between tenants?

What they're asking: Could one of your customers accidentally or deliberately access another customer's data?

Good answer: Customer data isolated by [workspace_id / tenant_id] at the application layer, enforced on every query. Database-level row-security where applicable. Regular access control testing as part of the security testing program.

How to get there: Audit every data access path in your application. Make sure every query filters by tenant ID. Test this explicitly.

13. What security training do your employees receive?

What they're asking: Do your employees know how to recognize and avoid security threats?

Good answer: Annual security awareness training for all employees covering phishing, social engineering, password hygiene, and incident reporting. Phishing simulation conducted [quarterly/annually]. Role-specific training for engineers covering secure development practices.

How to get there: Use a security awareness training platform. There are affordable options. Conduct an annual training and document who completed it.

14. Do you have a patch management policy?

What they're asking: Are your systems running on software with known vulnerabilities?

Good answer: OS patches applied within [X days] of release for critical/high severity. Automated patching enabled for non-production systems. Production patching follows change management process. Container base images rebuilt and deployed on a regular cadence.

How to get there: Enable automatic minor patches on RDS. Set up a regular process for rebuilding container images with updated base images. Track patch status in your vulnerability management tooling.

15. How do you secure your development environment?

What they're asking: Could a compromise of your development pipeline result in malicious code reaching production?

Good answer: Code requires peer review before merge. Branch protection enforced on all production branches. CI/CD pipelines use separate credentials from production. Secret scanning enabled in version control. Production secrets managed via a secrets manager, not stored in code.

How to get there: Enable branch protection in GitHub. Set up secret scanning. Move any secrets out of .env files and into AWS Secrets Manager or equivalent.

16. What is your change management process?

What they're asking: Do untested or unapproved changes reach production?

Good answer: All changes to production systems go through code review (minimum one approver), automated testing, and a deployment pipeline. Emergency changes have a documented breakglass process and post-change review.

How to get there: Enforce pull request reviews in GitHub. Make sure your CI pipeline runs tests before deployment. Document your deployment process.

17. Do you have logging and monitoring in place?

What they're asking: Will you know when something bad happens?

Good answer: Application, infrastructure, and security logs centralized in [CloudWatch/Datadog/etc.]. Alerts configured for anomalous activity. Log retention [X days]. Privileged access and administrative actions logged and reviewed.

How to get there: Enable CloudTrail, VPC Flow Logs, and RDS logging. Set up CloudWatch alerts for suspicious activity. Make sure your application logs are going somewhere you can query them.

18. How do you handle data backup?

What they're asking: If your data is corrupted or deleted, can you recover it?

Good answer: Automated daily backups with [X days] retention. Backups stored in a separate AWS account or region. Backup restoration tested [quarterly/annually] with documented results.

How to get there: Enable automated backups on RDS. Test restoring from backup -- actually test it, don't just assume it works.

19. Do you have a process for managing privileged access?

What they're asking: Are your most powerful accounts (AWS root, admin accounts, etc.) locked down?

Good answer: Root AWS account credentials locked in a vault, MFA enforced, and not used for day-to-day operations. Privileged access follows just-in-time access patterns where possible. Privileged sessions logged and monitored.

How to get there: Lock your AWS root account credentials. Never use root for anything except account-level AWS tasks that require it. Use IAM roles for all day-to-day operations.

20. Do you have a responsible disclosure / vulnerability reporting policy?

What they're asking: If a security researcher finds a vulnerability in your product, do you have a way for them to report it responsibly?

Good answer: Responsible disclosure policy published at [yourcompany.com/security]. Security contact available at security@yourcompany.com. We acknowledge valid reports within 48 hours and provide a remediation timeline.

How to get there: Publish a simple security page. Create a security@ email alias. Write a brief policy stating you welcome responsible disclosure and will respond within 48 hours.

---

The goal of a VSQ isn't to prove you're perfect. Enterprise security reviewers know you're not. The goal is to demonstrate that you take security seriously, have thought through the main threat vectors, and have systematic processes -- not just good intentions.

The startups that fail VSQs aren't the ones with imperfect security. They're the ones that clearly haven't thought about it at all.

---

Sprala automates the monitoring and evidence collection behind most of these controls -- so when the next VSQ lands in your inbox, you can answer from a place of confidence rather than scrambling. Request early access.