Every SaaS purchase should include a security evaluation. But not every SaaS purchase needs the same depth of scrutiny.

A marketing analytics tool that sees anonymized web traffic doesn’t need the same security review as a CRM that stores all your customer data. Applying the same heavyweight process to everything creates two failure modes: vendor fatigue that slows legitimate purchases, and rubber-stamp approvals that miss actual risk.

This standard provides a tiered approach to SaaS security evaluation—matching assessment depth to actual risk.

The Risk Tiering Model

Before evaluating security, determine the vendor’s risk tier.

Tier 1: High Risk

Vendors that access, process, or store sensitive data or have high organizational impact.

Characteristics:

• Access to PII, PHI, financial data, or intellectual property
• Access to authentication credentials or identity systems
• Administrative access to your infrastructure
• High business criticality (downtime significantly impacts operations)
• Regulated data handling (HIPAA, PCI, etc.)

Examples: EHR systems, financial platforms, identity providers, CRM with customer data, HR systems, cloud infrastructure providers.

Tier 2: Medium Risk

Vendors with some data access or moderate organizational impact.

Characteristics:

• Access to internal business information (non-sensitive)
• Integration with internal systems (limited scope)
• Moderate business criticality
• No regulated data

Examples: Project management tools, collaboration platforms, internal analytics, expense management, most SaaS productivity tools.

Tier 3: Low Risk

Vendors with minimal data access and limited organizational impact.

Characteristics:

• No access to sensitive data
• Minimal or no integration with internal systems
• Low business criticality (easily replaceable)
• No regulatory implications

Examples: Simple utilities, design tools without file storage, standalone applications with no data exchange.

Tier 1 Requirements: High Risk

For high-risk vendors, comprehensive security evaluation is required.

Documentation Requirements

SOC 2 Type II report (required)

• Must be current (within 12 months)
• Review for exceptions or qualified opinions
• Verify scope covers the services you’ll use
• Alternative: SOC 2 Type I (if Type II isn’t available yet) plus detailed questionnaire

Penetration test report (required)

• Annual pentest from independent third party
• Review for critical/high findings and remediation status
• At minimum, executive summary; full report if available

Security questionnaire (required)

• Complete industry-standard questionnaire (CAIQ, VSAQ, SIG, or equivalent)
• Or Adversis questionnaire if vendor doesn’t have pre-completed

Specific Requirements

Authentication and access:

• SSO support (SAML/OIDC) required
• MFA available for all users
• Role-based access control

Data protection:

• Encryption at rest and in transit
• Clear data retention and deletion policies
• Data residency transparency

Incident response:

• Documented incident response plan
• Customer notification commitments (timeframes)
• Contact information for security issues

Compliance (if applicable):

• HIPAA BAA (for PHI)
• PCI compliance (for payment data)
• Other certifications as required by your industry

Contractual Requirements

• Security requirements included in contract
• Right to audit (or access to independent audit reports)
• Breach notification provisions
• Data handling and deletion provisions
• Indemnification for security failures

Ongoing Requirements

• Annual security review
• Notification of material security changes
• Access to updated SOC reports and pentest summaries

Tier 2 Requirements: Medium Risk

For medium-risk vendors, streamlined evaluation with key checkpoints.

Documentation Requirements

SOC 2 (preferred)

• Type II preferred, Type I acceptable
• Alternative: detailed security questionnaire if SOC 2 unavailable

Security questionnaire (if no SOC 2)

• Abbreviated questionnaire covering essentials
• Focus on authentication, data handling, incident response

Specific Requirements

Authentication:

• SSO strongly preferred
• MFA available

Data protection:

• Encryption in transit (TLS)
• Encryption at rest
• Reasonable data handling practices

Security practices:

• Evidence of security program (dedicated team, policies)
• Vulnerability management process

Contractual Requirements

• Standard security terms in contract
• Breach notification provisions
• Data handling provisions

Ongoing Requirements

• Review at renewal (typically annual or per contract term)
• Monitor for significant security incidents

Tier 3 Requirements: Low Risk

For low-risk vendors, verification rather than comprehensive review.

Documentation Requirements

Self-attestation acceptable

• Vendor statement of security practices
• No formal audit required

Specific Requirements

• Encryption in transit (verify HTTPS)
• No known security incidents or concerns
• Acceptable privacy policy and terms

Contractual Requirements

• Standard vendor terms acceptable
• Basic data provisions if any data is exchanged

Ongoing Requirements

• Review at renewal
• Ad hoc if concerns arise

The Security Questionnaire

For vendors without SOC 2 (or to supplement SOC 2 for high-risk vendors), use a security questionnaire.

Essential Questions

Organization and Governance

1. Do you have a dedicated security team or designated security responsibility?
2. Do you have documented security policies?
3. Do you conduct security awareness training for employees?

Access Control

4. Do you support SSO (SAML 2.0 or OIDC)?
5. Do you offer MFA for all users?
6. How do you manage administrative access (named accounts, MFA, access logging)?
7. How is customer data segregated from other customers?

Data Protection

8. Is data encrypted in transit? (TLS version?)
9. Is data encrypted at rest?
10. Where is data stored (geography/regions)?
11. What is your data retention policy?
12. How do you handle customer data deletion upon termination?

Security Operations

13. Do you conduct regular penetration testing? (Frequency? Independent tester?)
14. Do you have a vulnerability management program?
15. How do you handle security patches?
16. Do you have security logging and monitoring?

Incident Response

17. Do you have a documented incident response plan?
18. What is your breach notification timeframe?
19. Who should we contact for security issues?

Compliance

20. Do you have SOC 2, ISO 27001, or equivalent certification?
21. Do you support HIPAA/BAA requirements? (if applicable)
22. Do you maintain PCI compliance? (if applicable)

Business Continuity

23. What is your disaster recovery capability?
24. What SLA do you provide?

Red Flags in Questionnaire Responses

Watch for these concerning responses:

• “We don’t support SSO” (Tier ¹⁄₂ concern—access management will be challenging)
• “We don’t offer MFA” (Major concern for any tier)
• “We’ve never had a pentest” (Tier 1 disqualifier, Tier 2 concern)
• “We don’t have a security team” (Risk depends on size—acceptable for small vendors, concerning for established ones)
• “We can’t tell you where data is stored” (Compliance risk, transparency concern)
• “Our incident response is handled ad hoc” (Tier 1 concern)
• Evasive answers on basic questions (General concern about transparency)

The Review Process

Tier 1 Review Process

1. Request documentation: SOC 2 report, pentest summary, completed questionnaire
2. Review SOC 2: Check scope, exceptions, control descriptions
3. Review pentest: Assess findings and remediation status
4. Review questionnaire: Flag concerns, follow up on gaps
5. Risk assessment: Document residual risk and any conditions
6. Approval decision: Approve, approve with conditions, or reject
7. Documentation: Record decision and rationale

Timeline: 1-3 weeks depending on vendor responsiveness

Tier 2 Review Process

1. Request documentation: SOC 2 or completed questionnaire
2. Review for red flags: Check essential security practices
3. Quick risk assessment: Note any concerns
4. Approval decision: Approve or reject
5. Documentation: Record decision

Timeline: 3-7 business days

Tier 3 Review Process

1. Basic verification: Check website for security info, verify HTTPS
2. Review terms/privacy policy: Flag any concerning provisions
3. Approve unless concerns arise

Timeline: 1-2 business days

Avoiding Security Theater

The goal is risk management, not box-checking.

Focus on what matters. A vendor with a perfect SOC 2 but no MFA is less secure than one with a few exceptions but strong access controls. Don’t get lost in documentation completeness at the expense of actual security.

Read the SOC 2. Most organizations request SOC 2 and file it without reading. Actually review the control descriptions and exceptions. A SOC 2 with multiple exceptions around access control is different from one with clean opinions.

Pentest findings matter. A pentest that found critical vulnerabilities six months ago that haven’t been fixed is worse than no pentest at all (at least then you don’t have documented knowledge of unfixed issues).

Don’t accept questionnaires at face value. “Yes” on a questionnaire doesn’t mean the control is well-implemented. Follow up on anything that seems unlikely or important.

Consider operational security, not just documentation. A vendor with a small, focused security team may be more secure than one with impressive certifications but poor operational practices.

Exceptions and Edge Cases

Sometimes the standard doesn’t fit cleanly.

Vendor without SOC 2 for Tier 1 service:

• Possible only with executive risk acceptance
• Requires comprehensive questionnaire
• Requires compensating controls (enhanced monitoring, limited data exposure)
• Document the risk and rationale explicitly

Urgent business need:

• Accelerated review is acceptable
• Does not eliminate Tier 1 requirements—accelerates timeline
• Document any deferred items and follow up

Startup or early-stage vendor:

• Lower maturity is expected
• Focus on whether they’re building the right foundations
• May require contractual commitments for future compliance
• Consider business risk beyond security (vendor stability)

Single-purpose tool with minimal integration:

• May warrant tier reduction even if data touches are sensitive
• Requires justification and approval from security team

Program Operations

For this standard to work, it needs operational support.

Trigger the process: Integrate security review with procurement workflows. Don’t let purchases happen without appropriate review.

Track assessments: Maintain a register of vendor assessments, expiration dates, and conditions.

Review at renewal: Don’t just auto-renew. Check if the vendor’s security posture has changed.

Maintain questionnaire templates: Keep standard questionnaires updated and available.

Document decisions: Record approvals, rejections, and conditions. When something goes wrong, you’ll want the trail.

Report on the program: Track metrics—vendors assessed by tier, rejection rate, common gaps found.

The standard is a tool for making consistent, risk-based decisions—not a bureaucratic hurdle. Use it to enable good purchases while blocking risky ones.