What technical due diligence on a SaaS vendor should actually cover

Key takeaways

• The security questionnaire is table stakes, not diligence. A SOC 2 report is an attestation of controls over a period against a scope the vendor chose (AICPA), not a guarantee you won't get breached.
• Vendor risk is now your risk. Third-party involvement in breaches doubled to 30% in the latest Verizon data (Verizon, 2025), and the average breach costs $4.44M (IBM, 2025).
• Test the exit before you sign the entry. GDPR gives a right to data in a "structured, commonly used and machine-readable format" (GDPR Art. 20), but machine-readable is not the same as usable.
• Viability is a technical question. 966 venture-backed startups shut down in 2024, up about 26% year over year (Carta via TechCrunch, 2025). Diligence the roadmap and the runway, not just the demo.

TL;DR

Most SaaS evaluations stop at the security questionnaire and a SOC 2 badge, then get surprised three years later by a broken API, an impossible data export, or a vendor that got acquired and sunset the product. Real technical due diligence looks past the checkbox: how stable and extensible is the API, can you actually get your data out in a usable form, is the company going to exist in five years, and what do the contract terms do to you on the day you leave? This is the consultant's version of that checklist, framed as the questions to ask and how to tell a good answer from a rehearsed one.

Isn't a SOC 2 report enough to prove a vendor is safe?

No. A SOC 2 report tells you a vendor had controls and an auditor looked at them; it does not tell you those controls are strong, comprehensive, or relevant to you. SOC 2 attests to controls against the AICPA's Trust Services Criteria, and critically, the vendor chooses the scope (AICPA). Read the report, not the logo. A Type I only assesses the design of controls at a single point in time; a Type II assesses whether they operated effectively over a period, usually six to twelve months. Ask which one you're looking at, when it was issued, and what was in scope. A current Type II covering the systems that actually hold your data is meaningful. A two-year-old Type I covering the marketing site is theater.

The same caution applies to ISO/IEC 27001. Certification means the vendor runs an information security management system, a process for managing risk, not that a specific product is secure (ISO/IEC 27001). These frameworks are useful filters. They are not the diligence; they're the ticket that lets a vendor into the room where diligence happens.

Why does vendor risk count as my risk?

Because when your vendor gets breached, your customers' data is what leaks, and your name is on the incident. Third-party involvement in breaches doubled to 30% in the 2025 Verizon Data Breach Investigations Report, drawn from analysis of more than 22,000 security incidents (Verizon, 2025). The financial exposure is real too: the global average cost of a data breach was $4.44M in 2025 (IBM, 2025). You are inheriting the vendor's security posture whether you diligence it or not.

So the useful questions go past "do you have SOC 2." Ask where your data physically lives, who their subprocessors are, how they'd notify you of a breach and within what window, and whether they've had one. A vendor that answers those crisply has thought about it. A vendor that deflects to the certificate has told you something too.

How do you assess whether a vendor's API is stable and extensible?

Look at the API's track record and its rules, not its feature list. An impressive API you can't rely on is worse than a modest one you can. Reliability is trending the wrong way industry-wide: average API uptime slipped from 99.66% to 99.46% between early 2024 and early 2025, with average weekly downtime rising from 34 to 55 minutes, across more than two billion monitoring checks (Uptrends, 2025). That's the environment your integration will live in.

Concretely, ask for and inspect: the published uptime history and status page (does it look honest, with real incidents, or suspiciously green?), the versioning and deprecation policy (how much notice before a breaking change?), rate limits and how they're enforced, and whether the API is the same one they build their own product on or a thinner second-class layer bolted on for customers. The last one is the tell. Vendors who consume their own API keep it good. If you rely on webhooks, apply the same rigor to their delivery guarantees, retries, and signing that you'd apply to your own systems. Extensibility is only worth anything if it doesn't break every quarter.

Can you actually get your data out, and in a usable form?

Usually less easily than the sales team implies, so test it during evaluation, not during the divorce. There is a legal floor: GDPR Article 20 grants a right to receive personal data in "a structured, commonly used and machine-readable format" and to have it transmitted to another controller "where technically feasible" (GDPR Art. 20). But that floor is lower than it sounds. A machine-readable export can still be a nightmare: 400 CSVs with opaque IDs, no relationships, no attachments, no history. Machine-readable is not the same as usable.

During evaluation, ask for a real export of a realistic dataset and try to make sense of it. Can you reconstruct the relationships? Are attachments and audit history included, or just the top-level records? Is there an API to pull it programmatically, or only a manual button that times out on large accounts? For high-stakes dependencies, consider data or source-code escrow, where a third party holds materials released on defined triggers like insolvency (Escode). Just know its limit: escrow grants you rights to materials, not instant continuity. You still have to be able to run what you receive.

What viability signals actually predict whether a vendor survives?

Runway, ownership, and momentum, all of which are technical concerns disguised as business ones. A vendor that dies or gets sunset takes your integration with it. The base rate is sobering: 966 venture-backed startups shut down in 2024, up roughly 26% from 769 the year before (Carta via TechCrunch, 2025). Acquisition is the quieter risk; the product you love gets absorbed, the roadmap freezes, and prices climb at renewal.

Look for signals you can verify: shipping cadence over the last year (changelogs don't lie), whether the founders are still there, funding stage and how recently they raised, and whether the company is profitable or burning. Then weigh concentration. The average company already runs a sprawling SaaS estate, from around 152 applications at smaller companies to 660 at large enterprises (Zylo, 2025). You already depend on more vendors than you think, so each new one deserves scrutiny proportional to how hard it would be to replace.

Which contract terms matter most on the day you leave?

The exit terms, because they're the ones you negotiate from the weakest position later if you skip them now. The single best discipline in vendor diligence is to plan the exit before signing the entry. Regulators have made this explicit for financial firms: the EU's Digital Operational Resilience Act requires documented exit strategies for critical ICT third-party services, in force since January 2025 (DORA Art. 28). It's a good template for everyone.

Get specific in the contract. What is the guaranteed data-export format and the SLA for producing it after termination? How long do they retain your data post-termination, and how is deletion certified? What are the price-escalation caps at renewal? Is there source-code or data escrow for a business-critical dependency? Who owns configurations and integrations you build on top? "We'll help you migrate" in a sales call is not a contract term. A named export format with a delivery deadline is.

What does downtime actually cost, and are SLA credits real compensation?

Downtime costs far more than the SLA credit refunds, which is the whole point to internalize. For over 90% of mid-to-large enterprises, a single hour of downtime now exceeds $300,000, and 41% put it between $1M and $5M or more (ITIC, 2024). Against numbers like that, a typical SLA credit, a small percentage of one month's fee, is a rounding error. It is not compensation for your losses; it's a token gesture that also caps the vendor's liability.

So read the SLA for what it excludes and how it's measured. Does "uptime" exclude scheduled maintenance and "degraded" performance? Who declares an incident, and how is duration measured? What's the actual remedy, and is your only recourse a credit? The mature move is to treat the SLA as a signal of the vendor's confidence, then architect as if it'll be missed: graceful degradation, retries, and a fallback for the moments the vendor is down and you still have customers.

A technical due-diligence checklist

Run this alongside the security questionnaire, not instead of it. If a vendor can satisfy all of it, you're buying with your eyes open.

1. Attestations: current SOC 2 Type II covering the right systems; ISO 27001 if relevant. Read the report and its scope, not the badge.
2. Third-party exposure: data location, subprocessor list, breach-notification window, incident history.
3. API: honest status page and uptime history, versioning and deprecation policy, rate limits, dogfooded or not.
4. Data export: a real test export of realistic data, with relationships, attachments, and history intact; programmatic access.
5. Viability: shipping cadence, funding and profitability, founder tenure, acquisition risk.
6. Exit terms: guaranteed export format and SLA, post-termination retention and deletion, price caps, escrow for critical dependencies.
7. Reliability economics: what an outage costs you, and a fallback that doesn't depend on the vendor being up.

What we got wrong: Early on we signed off on a vendor almost entirely on a clean SOC 2 and a slick API demo. We never tested a real data export. Two years later the client wanted to migrate, and the "export" turned out to be a manual CSV dump that dropped every file attachment and flattened the relationships between records. Reconstructing the data model took a month of engineering nobody had budgeted. Now the first thing we do in any SaaS evaluation is ask for a sample export and try to actually use it. It has killed more deals than the security questionnaire ever did, and saved more migrations.

Frequently asked questions

How long should technical due diligence on a SaaS vendor take?

Scale it to the dependency. A peripheral tool needs an afternoon; a system of record that would take months to replace deserves weeks, including a real data-export test and a reference call with a customer who has actually left the vendor. The cost of over-diligencing a small tool is a wasted afternoon; the cost of under-diligencing a core system can be a multi-month migration, against a backdrop where breaches average $4.44M (IBM, 2025).

Is SOC 2 or ISO 27001 more important?

They answer different questions, so it's not either/or. SOC 2 (via the AICPA Trust Services Criteria) attests to how controls operated over a period (AICPA); ISO 27001 certifies that a security management system exists (ISO/IEC 27001). For a US-centric SaaS buyer, a current SOC 2 Type II usually carries more operational detail; ISO 27001 signals process maturity. Neither substitutes for reading the report and testing reality.

What's the most overlooked part of SaaS due diligence?

Data export realism. Teams verify security and functionality but rarely test whether they can leave. GDPR guarantees a "structured, commonly used and machine-readable format" (GDPR Art. 20), yet a compliant export can still be unusable in practice. A ten-minute test export during evaluation surfaces problems while you still have negotiating leverage.

How do we judge a small or early-stage vendor?

Weigh the upside against the survival risk deliberately. With 966 startups shutting down in 2024 (Carta via TechCrunch, 2025), a young vendor needs compensating controls: escrow for critical data or code, a genuinely tested export, and a contract that lets you exit fast. If the product is worth the risk, buy it with a parachute, not on faith.

Diligence is cheapest before you sign

The pattern behind every question here is the same: the leverage, and the honesty, are highest before money changes hands. After you sign, the vendor has your data and your dependency, and every one of these questions gets harder to ask. So ask them now. Read the SOC 2 instead of admiring it. Test the export. Diligence the roadmap and the runway. Negotiate the exit into the entry. None of it is glamorous, and all of it is far cheaper than discovering the gaps during a migration you didn't choose.

If you're evaluating a vendor that a big part of your product will lean on, and you want a second set of eyes trained on the parts sales decks skip, that's exactly the kind of technical diligence we run with clients.