SaaS Security Checklist: What Enterprise Buyers Check Before Signing

Enterprise procurement has one job: don't let a vendor breach put their company on the front page of the Wall Street Journal. That's why every deal over a certain size triggers a vendor security review. Understanding what buyers check — before they ask — is the difference between a fast deal and one that stalls for three months in IT security review.

This checklist mirrors the structure of the most common vendor security questionnaire formats: SIG Lite, CAIQ, and bespoke enterprise questionnaires. For each area, you'll see what buyers ask and what answers they're looking for.

---

1. Security Certifications & Audits

This is usually the first section and the fastest filter. Many enterprise security teams will not proceed without at least one of these.

What they ask:

• Do you have a current SOC 2 Type II report?
• Do you have ISO 27001 certification?
• When was your last penetration test, and can you share the executive summary?
• Do you have PCI DSS compliance (if handling payments)?

What they want to see:

• SOC 2 Type II with a report date within the last 12 months
• A pentest from a recognized firm completed within 12 months, with no outstanding critical findings
• Remediation evidence for any high/critical findings from the pentest

If you don't have SOC 2 yet: Be honest and proactive. State your target date, describe the controls you have in place, and offer to complete a security questionnaire in detail. Many buyers will proceed if the answer is "we're targeting SOC 2 Type II by Q3 and here is our current control environment."

---

2. Data Handling & Storage

Buyers want to know where their data lives and who can access it.

What they ask:

• Where is customer data stored (country/region)?
• Can data residency be specified or restricted to a region?
• What types of data does your service process (PII, PHI, financial)?
• How long is data retained, and what is your deletion policy?

What they want to see:

• Clear answer on data residency (AWS us-east-1, eu-west-1, etc.)
• Ability to request data deletion and a process for fulfilling it
• Data classification policy that distinguishes between confidential, internal, and public data
• A data retention schedule with documented retention periods

Common pitfalls: Saying "the cloud" or "US-based servers" without specifics will slow a deal. Buyers, especially those with EU customers, need region-level specificity. If you use multiple regions or replicate globally, say so and explain the implications.

---

3. Encryption Standards

What they ask:

• Is data encrypted at rest?
• Is data encrypted in transit?
• What encryption algorithms and key lengths do you use?
• Who manages encryption keys and how are they stored?

What they want to see:

Scenario	Acceptable Standard
Data in transit	TLS 1.2 minimum, TLS 1.3 preferred
Data at rest	AES-256
Encryption keys	Managed by AWS KMS, GCP KMS, or HSM — not hardcoded
Password storage	bcrypt, Argon2, or PBKDF2 with appropriate work factor

What gets you flagged:

• TLS 1.0 or 1.1 still enabled
• MD5 or SHA-1 for password hashing
• Self-managed encryption with keys stored alongside the data

---

4. Access Control & Authentication

What they ask:

• Do you enforce MFA for employee access to production systems?
• Do you use SSO with SAML/OIDC for internal access?
• How is access to customer data controlled internally?
• Do you perform access reviews?

What they want to see:

• MFA required for all access to production environments and customer data
• Principle of least privilege documented and enforced
• Quarterly or semi-annual access reviews with documented evidence
• A formal off-boarding process that revokes access within 24 hours of termination

For your product: Buyers also check that their own users can be managed properly. They want RBAC, SSO/SAML support (or a roadmap for it), and the ability to force MFA on their team members.

---

5. Incident Response & Breach Notification

What they ask:

• Do you have a documented incident response plan?
• What is your SLA for notifying customers of a security incident?
• Have you had any security incidents in the past 24 months? If yes, describe.
• Do you conduct incident response drills?

What they want to see:

• A documented IRP that has been tested (even a tabletop exercise counts)
• Breach notification SLA of 72 hours or less (GDPR sets this as the regulatory floor)
• Honesty about past incidents with clear descriptions of what happened and what was fixed
• A designated security contact or CISO-equivalent who owns incident response

Template language for your questionnaire:

"We maintain a documented incident response plan with defined roles, escalation procedures, and communication templates. In the event of a confirmed data breach involving customer data, we commit to notifying affected customers within 72 hours of discovery. Our plan is reviewed annually and tested through tabletop exercises."

---

6. Network & Infrastructure Security

What they ask:

• Do you use a Web Application Firewall (WAF)?
• Is your infrastructure isolated with network segmentation?
• Do you perform vulnerability scanning?
• Is your cloud infrastructure configured according to CIS benchmarks?

What they want to see:

• WAF in front of customer-facing applications
• VPC/network segmentation separating production from development
• Regular vulnerability scanning (at least monthly) with a documented patch management process
• Infrastructure-as-code with security configurations in version control

---

7. Subprocessors & Third-Party Risk

What they ask:

• Who are your subprocessors (vendors with access to customer data)?
• How do you vet new vendors before onboarding?
• Do you have a formal third-party risk management program?
• Do you notify customers when subprocessors change?

What they want to see:

• A maintained, publicly available subprocessors list (like Stripe's or Notion's)
• A process for reviewing vendor SOC 2 reports or security questionnaires before onboarding
• Contractual notification of material subprocessor changes (30 days is standard)

Common subprocessors you should document:

• Cloud hosting (AWS, GCP, Azure)
• Database (MongoDB Atlas, PlanetScale, Neon)
• Email (SendGrid, Postmark, SES)
• Analytics (Mixpanel, Amplitude, PostHog)
• Support (Intercom, Zendesk)
• Monitoring (Datadog, Sentry, PagerDuty)

---

8. GDPR & Privacy Compliance

What they ask:

• Are you GDPR compliant?
• Will you sign a Data Processing Agreement (DPA)?
• Do you have a privacy policy that covers EU data subjects?
• How do you handle data subject access requests (DSARs)?

What they want to see:

• A signed DPA — this is legally required when processing EU personal data
• A privacy policy that covers lawful basis for processing, retention periods, and data subject rights
• A documented process for responding to DSARs within 30 days
• A record of processing activities (ROPA)

Important: If you use Google Analytics, you may be transferring data to the US without a valid transfer mechanism. EU enterprise buyers will ask about this specifically.

---

9. Business Continuity & Disaster Recovery

What they ask:

• What are your RTO and RPO for your production services?
• Do you have a business continuity plan?
• What is your uptime SLA?
• When was your last DR test?

What they want to see:

Metric	Typical Enterprise Expectation
Uptime SLA	99.9% or higher
RTO	< 4 hours
RPO	< 1 hour
DR test frequency	Annual minimum

If you're early stage: It's acceptable to have an uptime SLA of 99.9% (8.7 hours downtime/year) if you're transparent about your architecture. What kills deals is claiming 99.99% without the infrastructure to back it up.

---

10. Vulnerability Disclosure & Bug Bounty

What they ask:

• Do you have a vulnerability disclosure policy?
• Do you run a bug bounty program?
• How do you handle externally reported vulnerabilities?

What they want to see:

• A published security.txt file at /.well-known/security.txt or security.txt
• A public vulnerability disclosure policy with a response SLA
• A named security contact (security@yourdomain.com)

---

Mapping to Common Questionnaire Formats

Topic	SIG Lite Section	CAIQ Domain
Access Control	A	IAM
Encryption	E	EKM
Incident Response	I	SEF
Privacy/GDPR	P	PII
Third-Party Risk	G	STA
Business Continuity	F	BCR
Vulnerability Management	V	TVM

---

The Documents Enterprise Buyers Most Commonly Request

When you reach the security review stage, have these ready to share under NDA:

1. SOC 2 Type II report — or a letter of engagement if in progress
2. Most recent penetration test executive summary
3. Data Processing Agreement (DPA) — pre-negotiated template saves weeks
4. Subprocessors list — with links to their own security pages
5. Security policy documentation — information security policy, acceptable use policy
6. Business continuity/disaster recovery plan summary

Preparing these documents proactively is one of the highest-leverage things a security-focused SaaS startup can do. A security portal with documents ready to share under NDA can turn a 6-week security review into a 1-week review.