Security and Compliance Review: What a Mid-Market Buyer Should Actually Check

The legal team handed the SOC 2 report to IT, IT confirmed the badge was current, and procurement marked security review complete. Standard procedure. The vendor was a well-funded Series B company with a reasonable-looking security page and a logo wall of recognizable customers.

Eleven months later, a zero-day exploit in the vendor's API middleware exposed 40,000 customer records. The SOC 2 had covered the vendor's access controls, change management procedures, and availability monitoring. It had not covered the specific third-party component that failed. And because the contract contained a broad liability limitation clause, the company's legal recovery was minimal.

Nobody had been negligent. The SOC 2 was genuine. But a certification that tells you a vendor had good controls at audit time doesn't tell you whether those controls cover the specific risk that materializes at month eleven.

This guide is the security review that goes beyond the badge.

Why Certifications Are Starting Points, Not Finish Lines

Security certifications serve an important purpose: they create a documented record that a vendor applied certain controls at a specific point in time, verified by a third party. That's meaningful. The AICPA's explanation of SOC reporting clarifies exactly what each report type attests to — and what it explicitly does not.

But certifications have structural limitations:

They're backward-looking. A SOC 2 Type II covers a 6-12 month observation period that ended before you signed. The vendor's security posture today may be different from what the report reflects, due to staffing changes, infrastructure migrations, or new third-party dependencies. For a plain-language breakdown of what SOC 2, ISO 27001, and GDPR each cover and where they overlap, the compliance framework guide for buyers is the best starting point.

They cover defined scopes. A vendor's SOC 2 may cover their core product but explicitly exclude certain third-party integrations, data processing partners, or infrastructure components. Reading the scope section of a SOC 2 report often reveals surprises.

They don't tell you what happens when things go wrong. A certification tells you about controls and processes. It doesn't tell you how quickly the vendor will notify you of a breach, what their incident response playbook looks like, or how they've historically handled security events.

AI-enabled tools collect more. Traditional SaaS tools processed the data you gave them. AI-enabled tools increasingly process inferred data (patterns, behaviors, aggregate signals across customers) in ways that may not be covered by existing certification frameworks.

The five-layer review below addresses all of these gaps.

Layer 1: Certifications: Read the Report, Not the Badge

SOC 2 Type II

The standard expectation for any SaaS tool handling business or customer data. Confirm:

• Report period. The report should cover the 6-12 months immediately preceding your review. A SOC 2 from 18 months ago is not current.
• Trust Service Criteria included. SOC 2 has five criteria: Security (CC), Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P). Most vendors cover Security and Availability only. Confirm which criteria are covered and verify that the ones relevant to your use case are included.
• Scope. Read the scope section carefully. What systems, products, and infrastructure are included? What's excluded?
• Qualified opinion. If the report contains exceptions or qualified opinions, understand what they are. A minor exception in change management is different from an exception in access control.

What to ask:

• Can I receive the full SOC 2 Type II report under NDA?
• Which trust service criteria does your report cover?
• What was the audit period, and when is your next audit scheduled?
• Are there any exceptions or qualifications in the current report?

ISO 27001

Relevant if you operate in international markets or regulated industries. ISO 27001 covers an information security management system (ISMS), which isn't the same as SOC 2 and isn't interchangeable. A vendor with ISO 27001 but no SOC 2 has a different profile than one with SOC 2 but no ISO 27001.

Check the certificate scope — it should match the products and infrastructure you're buying.

Penetration Testing

Ask for the date and scope of the most recent penetration test, who conducted it, and what the material findings were. Vendors who have never run a pen test or refuse to share summary results are a meaningful risk signal.

A credible answer: "We run annual pen tests with [external firm]. The most recent was [date] and the summary report is available under NDA. Material findings have been remediated."

Layer 2: Data Handling and Residency

This layer is about what happens to your data once it's inside the vendor's systems.

Data Storage Geography

Where your data lives affects your compliance obligations, your exposure to foreign government data requests, and your rights under privacy regulations like GDPR.

Questions to ask:

• Where are production databases hosted geographically?
• Where are backups stored?
• Do you offer a data residency option for US/EU/specific region if required?
• If you use AWS, Azure, or GCP, which regions?

Data Retention and Deletion

• How long is customer data retained during an active contract?
• How long is customer data retained after contract termination?
• What is the deletion process, and can you provide verification that deletion occurred?
• Are backups deleted on the same timeline as production data?

Third-Party Sub-processors

Every SaaS vendor uses third-party infrastructure, analytics, support, and AI providers. Each of those providers is a potential data exposure point. Ask for a current list of sub-processors and check whether any are in jurisdictions with significant privacy concerns.

AI Training Data (Critical for AI-Enabled Tools)

If the vendor's tool includes AI features, this becomes the most important data handling question:

• Is customer data used to train vendor AI models? (Shared model, or isolated per customer?)
• If yes, can customers opt out?
• Are inference results from customer data shared with other customers?
• What is the data processing addendum for AI-specific handling?

Layer 3: Access Control Model

How the vendor controls access to your data — and to its own infrastructure — is a direct indicator of security maturity.

Vendor-side access controls:

• Who at the vendor has access to customer data? (Support, engineering, data teams?)
• What's the approval process for vendor-employee access to production data?
• Is access logged and audited?
• Is multi-factor authentication required for vendor employees accessing production systems?

Customer-side access controls:

• Does the product support role-based access control (RBAC)?
• Is single sign-on (SSO) available, and is it included in the base tier or an add-on?
• Is multi-factor authentication required for end users, available, or optional?
• What happens to data access when a user is deprovisioned?

The SSO tax issue: Many SaaS vendors charge extra for SSO, which is a security control that should be standard. This practice is widely documented in the security community — Wikipedia's overview of single sign-on explains why identity federation is a foundational security control rather than a premium feature. If your company uses an IdP (Okta, Azure AD, Google Workspace), SSO is a meaningful security requirement. Find out if it's included before you see the price for it in the order form. This kind of hidden-cost pattern is exactly what TCO modeling for SaaS captures in the Category 3 integration cost line.

Layer 4: Breach Notification Policy

When something goes wrong (and statistically, something will go wrong with any vendor you use long enough), what you're entitled to know and when matters significantly.

Questions to ask:

• What is your contractual commitment for breach notification timelines? (72 hours is the GDPR standard; many contracts offer 30 days, which is far too slow)
• What constitutes a reportable breach under your definition vs. a security incident?
• Have you had a reportable breach in the past two years? If so, what happened and what was the outcome?
• What is your incident response procedure and who is the designated contact?
• Does your cyber liability insurance cover customer notification costs?

Minimum contractual standard: Get a breach notification SLA in writing. 72 hours from discovery for anything involving personal data is the standard to negotiate to — it mirrors the requirement set by Article 33 of the GDPR regulation text. If the vendor pushes back, understand why.

Layer 5: Vulnerability Disclosure History

Past security incidents, when handled well, are evidence of maturity, not a disqualifier. A vendor that has never disclosed a vulnerability either hasn't been attacked (unlikely) or doesn't have a disclosure program (a problem). The NIST Cybersecurity Framework defines responsible disclosure and vulnerability management as core practices of the "Respond" and "Recover" functions — vendors who can't reference them are likely not operating at that maturity level. For AI-enabled tools, these questions extend to model inference and training data exposure, which the AI-enabled SaaS evaluation guide addresses in detail.

Questions to ask:

• Do you have a bug bounty program or responsible disclosure policy?
• Have you disclosed any CVEs (Common Vulnerabilities and Exposures) in the past two years?
• If yes, what was the timeline from discovery to patch and disclosure?
• What third-party libraries or components does your product depend on, and how do you track for vulnerabilities in them?

The Security Review Questionnaire (20 Questions)

Send this questionnaire before the security review call. It surfaces gaps before your time is spent on them.

Certifications

1. Do you have a current SOC 2 Type II report? What trust service criteria does it cover?
2. Is ISO 27001 certification in scope for the products we're buying?
3. What was the date of your most recent penetration test, and is a summary available?

Data Handling 4. Where is production data stored geographically? Where are backups? 5. Do you offer data residency options for [our region]? 6. What is your data retention policy during and after contract termination? 7. What sub-processors handle our data and where are they based? 8. Is customer data used to train your AI models? Can customers opt out?

Access Control 9. Who at your company can access production customer data, and what is the approval process? 10. Is production access logged and auditable? 11. Is SSO/SAML available, and is it included in the base tier? 12. Does the product support role-based access control (RBAC)?

Breach Notification 13. What is your contractual breach notification timeline? 14. Have you had a reportable breach or material security incident in the past two years? 15. Who is the designated security contact in the event of an incident?

Vulnerability Management 16. Do you have a bug bounty or responsible disclosure program? 17. Have you disclosed any CVEs in the past 24 months? 18. How do you track and patch third-party library vulnerabilities?

Contract and Compliance 19. Can I receive the DPA and all data processing addenda before signing? 20. What is your liability limitation for a security breach that affects our customer data?

Vendor Security Scorecard

Use this to summarize the review for a non-technical decision-maker:

Score of 4-5: Proceed with standard contract review. Score of 3: Proceed with specific remediation requirements in contract. Score below 3: Escalate to IT leadership before proceeding; consider whether this vendor can meet your requirements.

Learn More

• SOC 2, ISO 27001, and GDPR for Buyers: What Each Actually Covers — a plain-language breakdown of the three frameworks you'll encounter most often
• The Pre-Purchase Vendor Diligence Checklist for Mid-Market Buyers — how security review fits into the broader diligence process
• SaaS Contract Red Flags: Auto-Renewal, Usage Caps, and Termination Clauses to Watch — the contract clauses that affect your security and data rights
• Evaluating AI-Enabled SaaS: What's Real, What's Marketing — the expanded data handling questions specific to AI-enabled tools
• AI governance policy for departments — internal policy framework for governing AI SaaS access and data sharing
• SaaS contract negotiation — how to convert security review findings into contractual protections