Was ist technische Due Diligence?
Ein praktischer Leitfaden für Investoren und Software-Gründer
Technische Due Diligence ist eine unabhängige Prüfung der technologischen Verfassung eines Softwareunternehmens vor oder während eines Investment- oder M&A-Prozesses. Bei Software-Deals geht es darum, wie das Produkt gebaut und betrieben wird, wie das Team liefert und ob die Technologie den Investment Case tragen kann, nicht um Produktionsanlagen oder eine reine Inventur der IT-Bestände.
Venture-Capital- und Private-Equity-Investoren nutzen sie, um wesentliche Risiken und Potenziale für Wertsteigerung zu verstehen. Software-Gründer nutzen sie, um sich früh vorzubereiten, damit vermeidbare Lücken sie bei einer Finanzierungsrunde oder einem Verkauf nicht überraschen. Ich bin unabhängiger Berater mit Sitz in Berlin und arbeite mit Investoren und Softwareunternehmen in ganz Europa.
Diese Seite ist die Landkarte: eine verständliche Definition, wann die Arbeit wichtig ist, was eine Prüfung bei Software-Deals üblicherweise umfasst, eine praktische Checkliste und Links in das Tech Due Diligence Playbook für tiefergehende Beiträge, die auf Englisch erscheinen. Warum eine Due Diligence dem Deal dienen sollte statt einer Pflichtübung, lesen Sie in Ausgabe 1.
Was technische Due Diligence ist
Bei einer Software-Investition oder -Übernahme ist technische Due Diligence ein strukturierter Blick auf die technologische Verfassung des Unternehmens durch jemanden, der nicht das nächste Umsetzungsprojekt verkaufen will. Typische Bereiche sind Architektur und Produktplattform; Engineering-Umsetzung und Qualität; Sicherheit, Datenschutz und Compliance; Infrastruktur, Zuverlässigkeit und Betrieb; Daten, Analytics und KI; Team, Führung und Delivery-Modell sowie technische Governance und Kostenbewusstsein.
Sie ist keine Rechtsberatung, keine Finanzmodellierung, nicht bloß ein Penetrationstest, keine ISO-Zertifizierung und kein vollständiges Code-Audit Zeile für Zeile. Diese Tätigkeiten können in die Prüfung einfließen. Sie ersetzen aber keine entscheidungsorientierte Due Diligence, die Befunde nach geschäftlicher Auswirkung priorisiert.
Zu Zweck und Risikoregister lesen Sie Ausgabe 1: Deal-Maker, Not Checkbox.
Wann Investoren und Gründer sie einsetzen
- Vor einem Term Sheet, wenn Technologierisiken in Preis oder Struktur einfließen sollten.
- Während der Confirmatory Due Diligence, parallel zur finanziellen und rechtlichen Prüfung.
- Nach dem Closing, um aus den Befunden einen Plan mit klaren Verantwortlichen zu machen statt eines vergessenen PDFs.
Die Tiefe sollte zur Transaktion passen. Eine Minderheitsbeteiligung, ein Mehrheitserwerb und ein Carve-out erfordern unterschiedliche Prüfumfänge. Darum geht es in Ausgabe 2: One Size Never Fits All.
Gründer, die sich früh vorbereiten, verringern vermeidbare Reibung bei Finanzierung oder M&A. Siehe Investment Readiness für Software-Startups.
Was eine Prüfung bei Software-Deals üblicherweise umfasst
In gut gemachten Software-Due-Diligences tauchen immer wieder dieselben sieben Bereiche auf. Unten steht zu jedem ein kurzer Hinweis, worauf zu achten ist, mit einem Link in das Playbook. Auch Anbieterrisiken, APIs, Resilienz und der Plan nach dem Closing sind wichtig. Sie finden sich unter Weiterführende Lektüre.
Architektur und Produktplattform
Kann die Plattform das Wachstum aus dem Investment Case tragen, und wo erzeugen Kopplung oder technische Schulden gebündelte Risiken?
Engineering-Umsetzung und Qualität
Deuten Deployment-, Change-Failure- und Testsignale darauf hin, dass das Team in dem Tempo sicher ausliefern kann, von dem die Investmentthese ausgeht?
Sicherheit, Datenschutz und Compliance
Sind Sicherheitsaussagen durch Nachweise belegt, und ist der regulatorische Weg (einschließlich DSGVO und EU AI Act, wo relevant) verstanden?
Infrastruktur, Zuverlässigkeit und Betrieb
Passen Umgebungen, Resilienz, Observability und Cloud-Kostensignale zu einem Unternehmen, das ohne überraschende Ausfälle oder ausufernde Kosten skalieren kann?
Daten, Analytics und KI
Sind Datenverantwortung und Datengrundlagen klar, und sind KI- oder Analytics-Aussagen belegt statt nur vermarktet?
Team, Führung und Delivery-Modell
Wo konzentriert sich das Schlüsselpersonenrisiko, und ist die Nachfolgeplanung für kritische Rollen realistisch?
Technische Governance und Kostenbewusstsein
Sind die Entscheidungsrechte für Technik klar, und reicht die Kostentransparenz für die Investmentthese und für die Steuerung nach dem Closing?
Checkliste für die technische Due Diligence bei Software-Deals
Nutzen Sie diese Checkliste für die technische Due Diligence als erste Landkarte für Investoren und Gründer. Sie ersetzt keine passend zugeschnittene Due Diligence und erhebt keinen Anspruch auf Vollständigkeit oder Zertifizierung.
Umfang und Deal-Kontext
- Deal-Typ und Ticketgröße abgestimmt (Minderheit, Mehrheit, Carve-out und Ähnliches)
- Investmentthese und technikabhängige Annahmen schriftlich festgehalten
- Tiefe und Zeitplan mit allen Beteiligten abgestimmt
- Zugangsliste: Personen, Repositories, Cloud, Tickets, Dokumentation
Architektur und Produktplattform
- Plattform kann das Wachstum aus dem Investment Case tragen
- Wesentliche Kopplungs- und Modularitätsrisiken identifiziert
- Bekannte technische Schulden nach geschäftlicher Auswirkung eingeordnet
- Product-Tech-Fit auf hoher Ebene geprüft
Engineering-Umsetzung und Qualität
- Deployment-Frequenz und Signale zu fehlgeschlagenen Änderungen geprüft
- Test- und Release-Disziplin verstanden
- Lieferrisiken auf dem kritischen Pfad festgehalten
Sicherheit, Datenschutz und Compliance
- Zugriffskontrolle und Umgang mit Secrets geprüft
- Nachweise für Sicherheitsaussagen angefordert
- Relevanter regulatorischer Weg festgehalten (zum Beispiel DSGVO, EU AI Act, wo zutreffend)
Infrastruktur, Zuverlässigkeit und Betrieb
- Cloud-Setup und Umgebungen erfasst
- Resilienz und Incident-Historie geprüft
- Grundniveau der Observability geprüft
- Kosten- und FinOps-Signale stichprobenartig geprüft
Daten, Analytics und KI
- Datengrundlagen und Datenverantwortung klar
- KI- und ML-Aussagen belegt, nicht nur vermarktet
- Vorgaben zu Datenresidenz und Datensouveränität festgehalten, falls relevant
Team und Delivery-Modell
- Führung und Schlüsselpersonenrisiken erfasst
- Nachfolgeplanung für kritische Rollen berücksichtigt
- Delivery-Modell (Mix aus internem Team und Dienstleistern) verstanden
Governance, Anbieter und Kosten
- Entscheidungsrechte für Technik dokumentiert
- Wesentliche Anbieter und Lock-in geprüft
- Haltung zu Build vs. Buy verstanden
- Transparenz über Technikkosten ausreichend für die Investmentthese
Ergebnis und nächste Schritte
- Wesentliche Befunde nach geschäftlicher Auswirkung priorisiert
- Empfehlungen mit Verantwortlichen und Zeitpunkten
- Maßnahmen vor und nach dem Closing getrennt
- Befunde mit dem Investor und, wo angemessen, mit dem Unternehmen besprochen
Zur Erinnerung: Eine Checkliste ist kein Auftrag. Zu Zweck und Einordnung siehe Ausgabe 1. Wie aus Befunden ein Plan mit Verantwortlichen wird, zeigt Ausgabe 27.
Wie tief sollte die Prüfung gehen?
Passen Sie den Umfang an Ticketgröße, Unternehmensphase, Regulierung und Deal-Typ an. Für manche Minderheitsbeteiligungen kann ein schlanker, richtungsweisender Blick genügen. Größere oder komplexere Transaktionen brauchen meist tiefere Nachweise.
Ausgabe 2 behandelt das Scoping nach Transaktionstyp. Wie Aufträge in der Praxis zugeschnitten werden, steht auf der Seite Technische Due Diligence für Investoren.
Typische Fehler
- Technische Due Diligence als Pflichtübung statt als Entscheidungswerkzeug behandeln (Ausgabe 1).
- Für jeden Deal-Typ denselben Umfang verwenden (Ausgabe 2).
- Cloud-Kosten- und FinOps-Signale ignorieren (Ausgabe 5).
- Synthetische Lasttests mit einem realistischen Kapazitätsnachweis verwechseln (Ausgabe 25).
- Personen- und Nachfolgerisiken übergehen (Ausgabe 11, Ausgabe 26).
- Befunde ohne Verantwortliche oder ohne Plan für die Zeit nach dem Closing lassen (Ausgabe 27).
Weiterführende Lektüre aus dem Playbook
Das Playbook liefert fortlaufend Details aus der Praxis, diese Seite den Überblick. Beginnen Sie mit diesen Ausgaben und stöbern Sie dann im vollständigen Verzeichnis. Das Playbook erscheint auf Englisch.
- Ausgabe 1: Deal-Maker, Not Checkbox
The purpose of Technical Due Diligence and using a risk register as a deal-making tool
- Ausgabe 2: One Size Never Fits All
Right-sizing Technical Due Diligence scope by transaction type: minority stake, majority buyout, and carve-out
- Ausgabe 3: The Metrics That Matter
Key deployment, incident, and cost signals that predict platform scalability
- Ausgabe 4: Debt or Deal-Breaker?
Technical debt identification, classification, and its impact on deal valuation
- Ausgabe 5: Scaling Without Bleeding Cash
Cloud cost analysis, FinOps practices, and spend optimisation as due diligence signals
- Ausgabe 8: Security & Compliance in the AI Act Era
Security posture and compliance readiness under the EU AI Act and related regulation
- Ausgabe 11: The People Lens
Engineering team quality, leadership capacity, culture, and key-person risk in Technical Due Diligence
- Ausgabe 15: Platform Architecture Assessment
Platform architecture review: modularity, coupling, extensibility, and scalability
- Ausgabe 22: Tech Governance for Hypergrowth
Technology governance frameworks for rapidly scaling organisations
- Ausgabe 27: The Post-Close 100-Day Tech-Value Plan
Turning diligence findings into a sequenced, owned 100-day plan that reduces priced-in risk and builds the value thesis
Häufige Fragen
Was ist technische Due Diligence bei einem Software-Deal?
- Eine unabhängige Prüfung der technologischen Verfassung eines Softwareunternehmens vor oder während eines Investment- oder M&A-Prozesses. Ziel ist es, wesentliche Risiken und Potenziale für Wertsteigerung sichtbar zu machen, damit Investoren und Gründer klarere Entscheidungen treffen können.
Worin unterscheidet sie sich von einem Code-Audit oder einem Pentest?
- Ein Code-Audit konzentriert sich auf die Qualität des Quellcodes. Ein Penetrationstest konzentriert sich auf ausnutzbare Sicherheitslücken. Technische Due Diligence bei Software-Deals ist breiter: Architektur, Engineering-Umsetzung, Sicherheit und Compliance, Infrastruktur, Daten und KI, Team und Delivery sowie technische Governance. Code-Review und Sicherheitstests können einfließen, sie sind aber nicht die ganze Prüfung.
Wer gibt sie üblicherweise in Auftrag?
- Auf der Käuferseite geben sie meist Venture-Capital- und Private-Equity-Investoren in Auftrag. Auf der Verkäuferseite bereiten sich auch Software-Gründer frühzeitig vor, um vermeidbare Lücken zu schließen, bevor ein formaler Prozess beginnt.
Was gehört in eine gute Checkliste?
- Deal-Kontext und Zugänge, die sieben oben genannten Technologiebereiche, Transparenz über Anbieter und Kosten sowie ein klares Ergebnis: priorisierte Befunde, Verantwortliche, Zeitpunkte und eine Trennung von Maßnahmen vor und nach dem Closing. Eine Checkliste ist eine erste Landkarte, kein Ersatz für eine passend zugeschnittene Due Diligence.
Wo kann ich mehr dazu lesen?
- Das Tech Due Diligence Playbook auf dieser Website geht nach Themen in die Tiefe: Zweck und Risikoregister, Scoping nach Deal-Typ, Kennzahlen, technische Schulden, Cloud-Kosten, Sicherheit, Personenrisiken und Pläne für die Zeit nach dem Closing. Das Playbook erscheint auf Englisch.
Wie spreche ich mit jemandem über einen laufenden Deal?
- Investoren beginnen am besten auf der Seite Für Investoren. Gründer, die eine Finanzierungsrunde oder einen Verkauf vorbereiten, beginnen auf der Seite Für Startups. Sie können auch ein kurzes Gespräch buchen, um Umfang und Passung zu besprechen.
Sie brauchen das für einen laufenden Deal?
Investoren: siehe Für Investoren. Gründer in der Vorbereitung: siehe Für Startups. Oder buchen Sie ein kurzes Gespräch, um Umfang und Passung zu besprechen.
Gespräch buchen