At a recent buy-out signing, the celebration fizzled when the acquirer's CISO asked one last question: "Show me the log that proves your storage vendor patched the October CVE within 72 hours". The target had no such evidence, only an expired SOC2 report. The deal closed, but at a price cut to cover "supply-chain uncertainty".

Stories like this have multiplied since supply-chain attacks (from SolarWinds to MOVEit) showed that the easiest way to compromise a fast-growing SaaS is to slip through one of its many vendors. Regulators noticed. Europe's Digital Operational Resilience Act (DORA) now requires financial services to catalogue and monitor "critical ICT third-party providers" and empowers regulators to inspect them directly. In the US, the SEC cybersecurity-disclosure rule forces public companies to reveal material incidents irrespective of whose software caused them. Founders and investors can no longer assume that vendor risk is somebody else's problem.

Why third-party risk now sits on the due diligence critical path

Attack surface inflation: Modern stacks include hundreds of SaaS APIs, open-source libraries and cloud services. Each shortens delivery time but widens the blast radius when one link fails or gets breached.

Regulator reach-through: DORA, NIS2 and the AI Act all contain "look-through" clauses that make the primary business liable for vendors' missteps. If one of your vendors is breached and attackers exfiltrate the logs containing your customers' data, regulators (under DORA, NIS2, GDPR, or the AI Act) will still treat your company as responsible.

Investor math: Supply-chain incidents translate directly into churn, SLA credits and remediation capex. When diligence teams cannot model that exposure, they widen discount ranges or they pass on the deal.

What investors expect to see, no matter the term sheet

  • A living dependency map. A single page that lists every external service (commercial, open-source, data supplier, etc.), its business criticality, the data it touches and its current assurance level. Think of it as the SBOM's big sister.
  • Risk-tiered vendor assessments: Low-risk tools (internal analytics) may only need a questionnaire while high-risk vendors (payments, auth, LLM APIs) warrant audits, pen-test results and financial health checks.
  • Contractual safeguards: Clauses for data-breach notification (<24 h), the right to audit, encryption at rest and in transit, sub-processor disclosure, exit assistance and migration-support if the vendor is acquired or goes dark are important. Founders should consider their own risk while contracting vendors.
  • Continuous monitoring: Not a once-a-year PDF. Investors look for automated alerts on vendor status pages, real-time SBOM diffing and periodical tabletop exercises that simulate a compromised dependency in a vendor or on an open-source library.
  • Regulatory mapping. A short memo showing which vendors fall under DORA "critical ICT" scope, NIS2 essentials or the upcoming AI-Act GPAI transparency and how you flow those obligations down.

Stage, stake… and visibility

Minority Series A/B investors often accept a spreadsheet dependency list plus policy docs because they neither control operations nor bear integration cost.

Some series C and growth equity backers demand live dashboards and vendor-risk scores. They must defend brand equity once the startup appears on analysts' radars.

Control buy-outs and IPO prep trigger deep dives and demand a very high level of clarity including sampled vendor contracts, penetration tests for externally hosted code, financial viability analysis and even "shadow-copy SBOMs" (parallel SBOM you generate yourself to cross-check vendor-provided one) to detect hidden transitive risks.

Regulatory fines do not change with share ownership. Therefore, irrespective of stage/stake, visibility plays an important role here. The moment a company's logo lands on Gartner slides or front-page tech news, regulators and customers scrutinize every supplier in the chain. Investors calibrate their lenses accordingly.

Some red flags that lengthen negotiations

  • Dependency maps live in tribal knowledge.
  • No contractual right to retrieve customer data within 30 days of termination.
  • SaaS vendors with lapsed SOC2 Type II reports or ISO27001 certificates.
  • Open-source libraries pinned to versions with known critical CVEs and no patch plan exists.
  • A single cloud region for all workloads because "the provider is multi-AZ anyway".
  • Pen-tests leaving third-party integrations untested; third-party APIs mocked out "to save cost".

Two or more of these usually lead to escrow demands, hold-backs or sometimes even walk-aways.

Habits founders should adopt

  1. Publish a Vendor-Risk Register: Mirrors the risk register from Edition 1 but focuses on third parties: purpose, data scope, risk owner, criticality score, last review date, next action. Drop it in the data room before anyone asks for it.
  2. Automate SBOM watching: Tools like GUAC or Dependency-Track can ingest vendor software bills-of-materials and alert you to freshly disclosed CVEs.
  3. Run a periodical "assume vendor down" drill. Can you swap payment processors in 48 hours? Serve read-only mode if your feature-flag service dies? Document the recovery steps and capture real metrics.
  4. Negotiate exit clauses up front. Termination-assistance, data-export in machine-readable formats, potential escrow and the right to run a self-hosted version for up to 12 months are easier to secure before signing, not amid an incident.
  5. Link vendor risk scores to engineering workflow. If a library slips from "green" to "amber," create a ticket. Risk posture then improves as part of normal work, not a separate governance effort.

Common traps

  • Paper-only assurance: shiny SOC2 report is dated the moment it lands. Dig in deeper. Follow up on status pages and uptime stats. Continuous controls matter more.
  • Critical vendor concentration: hosting, database and observability all from the same cloud provider wipes out redundancy. Tempting, but not great.
  • Free-tier complacency: A startup might rely on the free plan of a feature-flag service that provides no uptime SLA, until the day an outage locks every user out.
  • Licenses without indemnity: Using a generative-AI model under a non-commercial license in production can trigger copyright claims during M&A disclosure.
  • Ignoring upstream sub-processors: Your CRM outsources search to a boutique provider that hosts in a different jurisdiction.

Mini-glossary

  • C-SCRM: Cybersecurity Supply-Chain Risk Management as defined by NIST.
  • DORA: Digital Operational Resilience Act (EU). DORA puts banks, insurers and fintechs on the hook for the resilience and security of all "critical ICT third-party providers."
  • CVE: Common Vulnerabilities and Exposures. The global ID system for publicly disclosed security flaws.
  • NIST: US National Institute of Standards and Technology publishing the Cybersecurity Framework, AI RMF and supply-chain guidelines that many investors treat as de-facto standards.
  • SBOM: Software Bill of Materials listing every component and its version.
  • Escrow (software or data): A neutral third party holds source code or critical data so the customer can access it if the vendor goes bust, changes ownership, or breaches contract.
  • NIS2: The EU's 2023 Network and Information Security Directive. It widens the original NIS scope to cover more sectors (energy, health, digital providers, etc.) and obliges "essential" and "important" entities to manage and report cybersecurity and supply-chain risks. Not yet equally enforced in all EU countries.
  • Flow-down obligation: Contractual requirements that a company must pass on to its subcontractors or downstream vendors.

Your turn

Which vendor surprise burnt you in a deal? An unpatched open-source library? A data-export clause that turned out optional? Share the scar, it may save someone else.

Founders: Want a quick stress-test of your vendor register or SBOM posture? Let's talk.

Investors: Need a second opinion on third-party exposure in a live deal? Happy to dive in.

Next in the Playbook

In Edition 10 I'll write about "Data Governance & Sovereign-Data Readiness". Subscribe so it lands in your inbox.

Originally published on the Tech Due Diligence Playbook newsletter on LinkedIn.