Unabhängige Prüfung mit Lesezugriff für Investoren und Käufer. Jeder wesentliche Befund verbindet Nachweise mit Investmentthese, Deal-Risiko und erforderlicher Maßnahme.
Ein Software-Target kann in der Demo überzeugen und die Investmentthese trotzdem verfehlen. Technical Due Diligence prüft, ob Produkt, eingesetztes System, Delivery-Team, Betriebskontrollen und Kostenbasis den Wachstums- und Integrationsplan des Käufers tragen.
Die Arbeit beginnt mit der Investmentthese und den offenen Entscheidungen. Daraus entsteht die Evidenzanfrage. Ein Product-SaaS-Kauf, eine Minderheitsbeteiligung und ein regulierter Carve-out benötigen unterschiedliche Prüftiefen.
Interviews erklären, wie das Unternehmen sein System versteht. Repositories, Infrastruktur, Records, Verträge, Logs, Rechnungen und Betriebsnachweise zeigen, was sich belegen lässt.
Fehlender Zugang bleibt eine Limitierung und führt zu keiner grünen Bewertung. Das Entscheidungsmemo trennt verifizierte Fakten, Management-Aussagen, Schlussfolgerungen des Reviewers und offene Nachweise.
Wir haben kein wirtschaftliches Interesse an einem empfohlenen Anbieter oder einer späteren Sanierung. Umsetzung nach der Transaktion wird getrennt beauftragt und freigegeben.
Dieses Engagement passt, wenn Software, Daten, Infrastruktur oder das Engineering-Team wesentlich für Wert, Integration, Wachstum, Resilienz oder Exit sind.
Recht, Finanzen, Commercial, Datenschutz und offensive Sicherheit bleiben eigene Fachprüfungen. Technical Due Diligence kann deren Befunde zusammenführen, während das jeweilige Urteil beim qualifizierten Owner bleibt.
Können Architektur, Produktgrenzen und Delivery-Modell die Wachstums-, Markt- und Integrationsannahmen des Deals erfüllen?
Welche Risiken bei Security, Resilienz, Datenschutz, Zugriff, Wiederherstellung oder Vorfällen können Kunden, Betrieb, Versicherung oder Verträge betreffen?
Wo begrenzen Code-Ownership, Review-Praxis, Release-Kontrollen, Dokumentation, Bereitschaftsdienst oder Schlüsselpersonen den Plan?
Welche Cloud-, Lizenz-, Daten-, Migrations-, Replatforming- und Sanierungskosten gehören in den Value-Creation-Plan oder die Kaufannahmen?
Wem gehören Code, Daten, Konten, Domains, Modelle und Lizenzen, und was geschieht beim Ausfall eines Anbieters oder einer Schlüsselperson?
Das Ergebnis unterstützt Investmententscheidung und ersten Betriebsplan nach der Transaktion. Die Detailnachweise bleiben hinter der Management-Sicht nachvollziehbar.
Jeder Befund dokumentiert geprüfte Deal-Annahme, betrachtete Nachweise, Ergebnis, Konfidenz, Risiko, Maßnahme und Limitierung. Der Review fordert den kleinsten Zugang an, der eine belastbare Aussage ermöglicht.
Ein kurzes Scope-Gespräch grenzt die Prüfung ein, bevor ein Datenraum geöffnet wird. Die Antworten bestimmen Tiefe, Fachleute, Zeitplan und Evidenz.
Der Scope folgt der Investmentthese. Häufig geprüft werden Produkt- und Architekturfit, Security und Resilienz, Engineering-Delivery, Betriebskosten, Daten- und Anbieterabhängigkeiten, Ownership sowie Integrationsrisiko. Ein Softwarekauf erfordert andere Nachweise als ein technologiegestütztes Dienstleistungsunternehmen.
Der Zeitplan entsteht aus Transaktionsphase, Target-Typ, offenen Entscheidungen, Zugang, Fachbedarf und Deadline des Investment Committees. Die Scope Note benennt, was sich in diesem Fenster verifizieren lässt und was als Limitierung verbleibt. Vor diesen Angaben versprechen wir keine pauschale Dauer.
Ein Technical Audit wird typischerweise vom Unternehmen selbst für interne Verbesserung beauftragt. Technical Due Diligence wird von oder für Investor oder Acquirer durchgeführt, um kommerzielles und technisches Risiko vor Transaktionsabschluss zu bewerten.
Ja. Gründerseitige Arbeit sollte als Pre-DD oder Readiness-Prüfung gekennzeichnet sein, damit ein späterer Investor-Review unabhängig bleibt. Die Technical Due Diligence Evidence Checklist zeigt fehlende Unterlagen und Zuständigkeiten, bevor ein externer Review beauftragt wird.
Standards strukturieren Fragen; Transaktionsnachweise und Zertifizierungen bleiben separat. NIST SP 800-218 strukturiert Nachweise zur sicheren Softwareentwicklung, CISA SBOM Resources die Transparenz über Softwarekomponenten und OWASP SAMM die Praxis im Softwarelebenszyklus. Für ein betroffenes Finanzunternehmen kann DORA zusätzliche Fragen zu IKT-Drittdienstleistern auslösen. Rechtsberater klären Anwendbarkeit und rechtliche Schlussfolgerungen.
Technical DD ist ein Engagement-Typ in unserer Tech Strategy & Consulting-Service-Linie. Verwandte Engagements: standalone Tech Audits, Vendor Due Diligence und Build vs Buy Memos.
Mit der kostenlosen Technical Due Diligence Evidence Checklist lassen sich Anfragen, Lücken, Konfidenz und Exposition zur Investmentthese erfassen. Als Investor, der ein Target evaluiert: Investor- und Portfolio-Teams. Als Gründer vor einer Runde: Startup- und Scale-up-Arbeit.
Lesen Sie den Fractional-CTO-Guide für Technical advisory im Fundraising-Kontext. Wenn KI-Systeme Teil des Risikoprofils sind: Some Tech Work in KI.
Sagen Sie uns, was nicht läuft
Wir lesen jedes Briefing und antworten innerhalb eines Werktags.
Lieber erst sprechen?oder Tech-Stack-Audit anfragen →oder direkt per E-Mail →
Unklar, wo Sie anfangen sollen? Schicken Sie die hängende Entscheidung, den Workflow oder die Seite. Wir sagen, ob ein Diagnosegespräch, ein Tech-Stack-Audit oder ein anderer erster Schritt passt.