The SaaS Vendor Security Audit Checklist: What to Ask Before You Buy

#The vendor questionnaire everyone lies on

I've filled out vendor security questionnaires from the inside of an MSP and the outside of a SaaS vendor. Both sides know the game. The questionnaire asks if you have a SOC 2 Type II. You mark "yes" because your audit is in progress. The questionnaire asks about encryption at rest. You mark "yes, AES-256" because that's what the cloud provider does by default, even though your own app-layer encryption is missing.

That's why vendor security questionnaires don't prevent breaches. The questions are a ceremony. The real work is knowing what to dig into.

This post is the checklist we actually use when a client asks us to audit a prospective SaaS vendor. The questions, the followups, the red flags, and the ones we walk away from.

#Why this matters

The average mid-size company uses 150+ SaaS vendors. Email, CRM, HR, payroll, analytics, customer support, document management, collaboration tools, specialized vertical software, and dozens of other categories. Each vendor has some of your data.

The 2024-2026 period has repeatedly demonstrated that vendor breach is a primary breach vector:

• Change Healthcare (2024): ransomware affected tens of thousands of healthcare provider customers
• Snowflake customer breaches (2024): customers without MFA exposed via credential stuffing
• Okta breach (2022-2023): affected thousands of customer organizations' IAM posture
• SolarWinds (2020): compromised vendor software used as supply chain entry point
• Conduent (2026): 25 million+ affected through downstream customer exposure
• 3CX (2023): software supply chain attack via VoIP vendor
• MOVEit (2023-2024): file transfer vendor vulnerability affected thousands

For your organization, the question isn't "could a vendor get breached." It's "when they do, how exposed are you?"

This post is the practical vendor security audit framework. What to ask before you buy. What to require in contracts. What to monitor ongoing. And how to decide whether a specific vendor is worth the risk.

#The procurement security question

When your procurement process is evaluating a new SaaS vendor, the security review should be explicit and structured. Skipping it (or doing it as an afterthought) is how vendor risk accumulates.

A proper vendor security review has three phases:

1. Due diligence. Before signing the contract
2. Contractual protections. What's in the agreement
3. Ongoing monitoring. What happens after onboarding

#Phase 1: Due diligence questions

The specific questions to ask every SaaS vendor before purchase. If a vendor can't answer these, they're not mature enough to trust with sensitive data.

#Tier 1 questions (mandatory)

1. What certifications does your organization hold?

Expected answers for a serious vendor:

• SOC 2 Type 2 (table stakes for enterprise SaaS)
• ISO 27001
• Industry-specific: HIPAA BAA capability, PCI DSS compliance, FedRAMP (for government), HITRUST (healthcare)

Request copies of current certifications. Ask for the most recent assessment report (SOC 2 reports are under NDA typically but available).

2. Where is my data stored?

Specific answers needed:

• Primary region (AWS us-east-1, GCP europe-west3, etc.)
• DR region
• Any secondary data locations (backup, analytics, logging)
• Whether any data is processed or stored outside the primary region

Data residency affects regulatory applicability. EU-based customers need EU processing for GDPR; US healthcare needs US processing for HIPAA in most cases. Etc.

3. How is data encrypted?

• At rest: specific algorithm (AES-256), KMS used, key management approach
• In transit: TLS 1.2 minimum, preferably 1.3. Cipher suites
• Backup data: same encryption standards
• Database-level encryption: Transparent Data Encryption (TDE) or equivalent
• Field-level encryption: for particularly sensitive fields

"Encrypted" as a single word is insufficient. Require specifics.

4. What's your authentication model?

• MFA support (SMS, TOTP, FIDO2/WebAuthn)
• SSO via SAML/OIDC
• Service account management
• Session management and timeout
• Password policy

Phishing-resistant MFA (hardware keys) is increasingly table stakes for enterprise vendors.

5. What's your incident response plan?

• Detection capability (what triggers an incident?)
• Response time targets
• Customer notification timelines (per breach severity)
• Evidence preservation
• Forensics capability
• Regulatory notification handling

Request a summary of the IR playbook. Don't accept "we've one" as sufficient detail.

6. What's your access control model?

• Role-based access within the vendor's team
• Least-privilege principle applied
• Background checks for employees with data access
• Access reviews
• Separation of duties
• Privileged access management

Ask specifically: "How many of your employees can access our data in plaintext?" The answer should be a small number with clear justification.

7. What's your patch management and vulnerability response?

• Patch cadence for critical vulnerabilities
• Zero-day response capability
• Vulnerability disclosure program or bug bounty
• Dependency scanning
• Security testing (pen testing, source code review)

8. How do you handle subprocessors?

List of subprocessors. Their compliance posture. What data flows to each.

If the vendor uses subprocessors (almost all do. AWS, databases, email providers, analytics), your data flows to those subprocessors too.

9. What's the process for data deletion?

• On customer request (GDPR, CCPA compliance)
• At contract end
• Standard data retention policies
• Backup data lifecycle
• Confirmed deletion verification

10. What happens if you go out of business?

• Data escrow arrangements
• Contract terms for data return
• Bankruptcy protections
• Acquisition scenario handling

#Tier 2 questions (strongly recommended)

11. Can you provide your most recent penetration test report?

• Done by whom? (qualifications of the tester)
• What was in scope?
• What were the findings and remediation status?

A vendor without recent pen testing is cutting corners on security.

12. What logging and audit capabilities are available to customers?

• API call logs (every data access logged)
• Admin activity logs
• Login logs
• Export/download logs
• Retention period for logs
• SIEM integration available

You should be able to see what's happening with your data.

13. What's your SDLC security posture?

• Code review requirements
• Security testing in CI
• Dependency management
• Secrets management in build systems
• Production deployment process

14. Can we conduct our own security assessment?

Rights to conduct or commission third-party pentests. Typically includes limitations (timing, scope, notification requirements).

15. How is data segregated in your multi-tenant environment?

• Tenant isolation at data layer
• Query-level tenant filtering
• Authentication-tied data access
• Cross-tenant data leakage prevention

#Tier 3 questions (due diligence deep dive)

16. What's your DR and business continuity posture?

• RPO (Recovery Point Objective). How much data loss is acceptable
• RTO (Recovery Time Objective). How long to restore service
• DR testing frequency
• Multi-region failover

17. What's your change management process?

• Code change review
• Infrastructure change approval
• Customer notification for breaking changes
• Emergency change procedures

18. How do you handle insider threat?

• Background checks
• Monitoring of employee access to customer data
• Separation of duties on sensitive operations
• Offboarding procedures for terminated employees

19. What's your supply chain security posture?

• Vendor assessment program
• Software supply chain controls (SBOM, signed artifacts)
• Infrastructure provider security
• Hardware security (if applicable)

20. Do you have cyber insurance?

• Coverage amount
• What's covered (first-party vs. liability)
• Notification of claim
• Subrogation waiver (whether insurance reimbursement goes to you or to them)

#Phase 2: Contractual protections

Even with strong due diligence, the contract is your legal recourse if something goes wrong. Specific clauses to include or negotiate:

#Data processing agreement (DPA)

Should cover:

• Purpose limitation. Vendor only uses your data for the service, not for their own purposes (e.g., model training, analytics)
• Data categories and subjects. What data is being processed, about whom
• Subprocessor approvals. You have rights to approve or reject new subprocessors
• Cross-border transfer mechanisms. Standard Contractual Clauses for EU data. Other mechanisms as applicable
• Data subject rights handling. How requests are handled
• Return / deletion at contract end

#Security addendum / information security requirements

Specific security commitments from the vendor:

• Certifications they'll maintain
• Encryption standards
• Authentication requirements
• Incident notification timelines (typically 24-72 hours. Faster for certain data types)
• Pen testing requirements
• Vulnerability management
• Audit cooperation

#Breach notification requirements

Specific and enforceable:

• Notification timeline (e.g., within 48 hours of confirmation)
• Required content of notification
• Ongoing updates during investigation
• Coordination with your incident response
• Costs of response borne by vendor (for their fault)

#Indemnification

Vendor's liability for security failures:

• For vendor-caused breaches
• For regulatory fines resulting from vendor failures
• For third-party claims
• Cap on liability (typically negotiable)

#Right to audit

You retain rights to:

• Request security questionnaires and evidence
• Commission third-party assessments (possibly limited in scope)
• Review SOC 2 reports
• Access audit logs

#Exit provisions

• Data return at contract termination (format specifications)
• Data deletion after return confirmed
• Transition support
• Pricing for exit services (limited)

#Change notification

• Advance notice of material security changes
• Breach notification (covered separately)
• Subprocessor changes
• Acquisition / change of control (you may have termination rights)

#Phase 3: Ongoing monitoring

Vendor risk doesn't end at contract signature. Vendors' security posture degrades over time. Acquisitions, key staff departures, technical debt, changing business priorities. Ongoing monitoring catches degradation.

#Annual reassessment

Redo the due diligence at least annually:

• New security questionnaires
• Updated certifications (SOC 2 reports renew annually)
• Fresh pen test reports
• Subprocessor updates
• Security incident history during the year

#Continuous monitoring via security ratings services

Commercial services provide outside-in ratings:

• SecurityScorecard. Rates vendors on externally-observable security signals
• BitSight. Similar external ratings
• RiskRecon. Vendor risk monitoring
• UpGuard. Automated vendor risk assessments
• Black Kite. Financial + security risk ratings

These tools observe things like:

• SSL/TLS configuration on vendor's external services
• DNS health and DMARC configuration
• Leaked credentials on dark web
• Unpatched software indicated by banner grabs
• Historical breach disclosures

Useful for monitoring hundreds of vendors with limited staff.

#Incident monitoring

Subscribe to:

• Vendor's security bulletins
• Industry threat intel feeds (CERT/CC, ISAC for your sector)
• Dark web monitoring for your vendor's data
• Vendor's SEC filings (if public. Form 8-K cyber incidents)

When a vendor you depend on has a disclosed incident:

• Immediate assessment of your exposure
• Execute your incident response plan for vendor compromise
• Engage the vendor for specifics
• Consider interim controls (temporarily restrict access, increased monitoring)

#Contract review cadence

Annual contract review:

• Still meets your requirements?
• Still in use (or can you consolidate)?
• Pricing appropriate?
• Any renegotiation opportunities?

#Decommissioning

When a vendor relationship ends:

• Formal exit process
• Data return verified
• Data deletion confirmed in writing
• Access revoked (vendor's access to your systems)
• Access revoked (your users' access to vendor)
• Documentation updated

#The vendor risk decision framework

Not every vendor needs the full treatment. Use tiering based on data sensitivity and integration depth.

#Tier 1: Critical vendors

Definition: vendors with deep access to sensitive data, material to operations, difficult to replace.

Examples: primary CRM, payroll system, email provider, identity provider, major cloud provider.

Treatment:

• Full due diligence (all Tier 1 + Tier 2 questions)
• Negotiated contracts with strong security provisions
• Annual reassessment
• Continuous monitoring via security ratings
• Incident response plan includes specific scenarios for this vendor

#Tier 2: Important vendors

Definition: vendors with access to some sensitive data or meaningful operational dependency.

Examples: customer support platform, marketing automation, analytics.

Treatment:

• Due diligence questionnaire (Tier 1 questions)
• Standard contract with security addendum
• Annual review
• Periodic monitoring

#Tier 3: Low-risk vendors

Definition: vendors with limited data access, easily replaceable, narrow integration.

Examples: specialized analytics tools, single-use utilities.

Treatment:

• Abbreviated questionnaire
• Standard contracts
• Bi-annual review
• Minimal ongoing monitoring

#Tier 4: Minimal risk

Definition: vendors with no sensitive data, no integration.

Examples: certain small-scale tools, specific utility services.

Treatment:

• Basic checks (legitimate company, reasonable reputation)
• Standard click-through contracts acceptable
• Annual inventory review

#The red flags

Specific vendor signals that suggest elevated risk:

Organizational red flags:

• Recent leadership turnover, especially CISO or security head
• Acquisition in the last 12 months (pending integration changes)
• Funding distress (affects security investment)
• High employee turnover in security team
• Offshore development without clear oversight

Technical red flags:

• No SOC 2 (for enterprise SaaS)
• Refuses to provide assessment reports
• Recent disclosed breach without clear remediation story
• Publicly visible security issues (outdated TLS, missing headers, exposed admin panels)
• Outdated dependencies visible in their public-facing services
• Poor Security.txt or no vulnerability disclosure program

Contractual red flags:

• Refuses to negotiate security provisions
• Refuses to provide breach notification timelines
• Data residency they can't commit to
• Subprocessor lists refused

Operational red flags:

• Can't describe their own incident response process
• No documented change management
• Ad-hoc patching cadence
• Security mentioned only when prompted during sales process

#For different industries

#Healthcare (HIPAA)

Additional requirements:

• Business Associate Agreement (BAA) mandatory
• HIPAA Security Rule compliance
• Specific breach notification requirements
• Training documentation for vendor staff
• Medical device-specific requirements if applicable

#Financial services

Additional requirements:

• SOC 2 Type 2 + SOC 1 for financial controls
• GLBA compliance for data handling
• PCI DSS for payment-related vendors
• State banking regulator requirements (NY DFS, etc.)
• Resilience testing per regulatory guidance

#Defense / federal contractors

Additional requirements:

• CMMC 2.0 (discussed in our CMMC post)
• NIST 800-171 compliance for CUI handlers
• FedRAMP authorization for cloud services
• ITAR compliance for export-controlled data

#European operations

Additional requirements:

• GDPR compliance
• NIS2 if applicable (our NIS2 post)
• Standard Contractual Clauses for cross-border data
• Schrems II analysis for US vendors handling EU data

#Healthcare / pharma

• HIPAA BAA
• HITRUST CSF if working with specific customers who require it
• FDA-related requirements for regulated products

#The consolidation question

Your inventory says you've 150 SaaS vendors. A meaningful percentage is probably:

• Duplicate functionality (multiple project management tools, multiple analytics platforms)
• Shadow IT not sanctioned by central IT
• Abandoned but still paying for
• Legacy tools that should be deprecated

Vendor consolidation reduces risk. Fewer vendors = less attack surface, easier monitoring, lower cost, stronger relationships with remaining vendors.

Consolidation exercises:

1. Inventory all vendors (expense report reconciliation catches unknown vendors)
2. Categorize by function
3. Identify duplicates
4. Assess data access and integration depth
5. Consolidate where possible
6. Decommission redundant vendors cleanly

#For procurement teams

If you're in procurement and trying to build vendor risk capability:

Starting point:

• Establish a standard security questionnaire (SIG Lite or custom based on this post)
• Create vendor tiers and tier-specific requirements
• Build a vendor inventory (if one doesn't exist)
• Implement a basic vendor risk assessment at contract renewal

Intermediate maturity:

• Integrate with procurement workflow (security approval gate)
• Annual reassessment of Tier 1 vendors
• Security ratings service for Tier 1 and 2 vendors
• Standardized contract clauses

Mature program:

• Continuous monitoring
• Integration with GRC platform
• Formal vendor risk register
• Regular board reporting on vendor risk exposure
• Incident response integration

#Templates worth using

SIG (Standardized Information Gathering) questionnaire:

• SIG Core, SIG Lite, SIG+
• Industry-standard comprehensive security questionnaire
• https://sharedassessments.org/

CAIQ (Consensus Assessments Initiative Questionnaire):

• Cloud Security Alliance's cloud-focused questionnaire
• https://cloudsecurityalliance.org/research/caiq/

NIST CSF vendor risk assessment:

• Aligned with NIST Cybersecurity Framework
• Maps to many compliance requirements

DPA templates:

• European Commission's Standard Contractual Clauses
• IAPP template DPAs
• Your legal counsel's standard

Customize to your specific requirements, but start from established templates than from scratch.

#The common mistakes

#Mistake 1: security review only at initial purchase

Vendors' security posture changes. Reassess annually.

#Mistake 2: accepting vendor's self-report without verification

Certifications get verified. "We're SOC 2" should come with SOC 2 reports. Require evidence.

#Mistake 3: treating all vendors the same

Tiering is necessary. 150 vendors can't all get Tier 1 treatment. Focus effort where data sensitivity warrants.

#Mistake 4: no exit plan

When you onboard a vendor, plan the exit. How do you get your data out? How do you stop using them? This gets written into the contract.

#Mistake 5: ignoring subprocessors

Your vendor's vendor is functionally your vendor. If a subprocessor handles your data, they're in your risk picture.

#Mistake 6: no incident response plan for vendor breach

When a vendor gets breached, who does what? If you don't have an answer now, you'll be building the plan during the incident.

#Mistake 7: vendor risk owned by one person

If vendor risk is one person's job and they leave, the institutional knowledge disappears. Distribute ownership. Document processes.

#For Valtik clients

Valtik's vendor risk management engagements include:

• Vendor risk program design from scratch
• Security questionnaire templates customized to your industry
• Tiering framework for your vendor inventory
• Contract clause library for security provisions
• Ongoing monitoring setup
• Incident response plan for vendor compromise scenarios
• Vendor consolidation analysis

If you're building a vendor risk program (or your current one needs maturation), reach out via https://valtikstudios.com.

#The honest summary

Vendor risk is a meaningful and growing share of organizational risk. Your organization will be breached via a vendor, not your own systems, more often than the inverse in 2026 and beyond.

The framework in this post is the practical baseline. Due diligence questions that get real answers. Contracts with enforceable protections. Ongoing monitoring that catches degradation. Tiering that focuses effort where it matters.

It's work. But the alternative. Being at the mercy of whichever of your 150 vendors gets breached next. Isn't sustainable.

Start with your Tier 1 vendors. Expand from there.

#Sources

1. Shared Assessments SIG Questionnaire
2. Cloud Security Alliance CAIQ
3. NIST Cybersecurity Framework
4. SecurityScorecard
5. BitSight Security Ratings
6. Standard Contractual Clauses (EU)
7. IAPP Data Protection Agreement Template
8. SOC 2 Trust Services Criteria
9. OWASP Third-Party Components Risk Assessment
10. Vendor Risk Management Best Practices. NIST SP 800-161