- Technische Due Diligence prüft Code, Wissenskonzentration, Abhängigkeiten, Sicherheit, Tests und Lizenzen, nicht nur die Bilanz.
- Laut der M&A-Due-Diligence-Studie 2026 von SRS Acquiom ist die Technologie-Prüfung für 51 Prozent der Dealmaker inzwischen der aufwendigste Teil der gesamten Due Diligence.
- Am häufigsten verzögern oder verbilligen ungeklärte IP-Rechte, veraltete Abhängigkeiten, dünne Tests und eine hohe Wissenskonzentration den Deal.
- Wer refactor, rewrite oder ship-as-is vorher selbst entscheidet, verhandelt aus einer stärkeren Position als jemand, der im Datenraum improvisiert.
1. Warum Due Diligence jetzt zum Preistreiber wird
Ein Investor öffnet den Datenraum, ein Board verlangt eine Freigabe vor der nächsten Finanzierungsrunde, ein Käufer schickt sein Technikteam für zwei Wochen in Ihr Repository. In allen drei Fällen prüft jemand von außen eine Codebase, die intern gewachsen ist, mit Entscheidungen, die niemand mehr vollständig erklären kann. Das Ergebnis wirkt sich direkt auf Preis, Zeitplan oder Struktur der Transaktion aus.
Technische Due Diligence ist längst kein Nebenschauplatz mehr. Laut der M&A-Due-Diligence-Studie 2026 von SRS Acquiom sagen 51 Prozent der befragten Dealmaker, die Technologie-Prüfung sei inzwischen der aufwendigste Teil der gesamten Due Diligence. 84 Prozent erwarten für die kommenden zwölf bis vierundzwanzig Monate eine noch stärkere Prüfung der Cybersicherheit, nicht weniger.
Die Folge zeigt sich im Zeitplan. Ein Fünftel der Befragten berichtet, dass sich die Dauer der Due Diligence in den vergangenen zwei Jahren spürbar verlängert hat, und wo das passiert, kommen laut Studie meist ein bis drei zusätzliche Monate dazu. Bei einer laufenden Finanzierungsrunde oder einer geplanten Übernahme ist das keine akademische Zahl, sondern eine Frist, die reißt.
2. Was Käufer und Prüfer tatsächlich prüfen
Die Prüfung folgt selten einem einzigen Dokument, sondern mehreren parallelen Spuren. Drei Bereiche tauchen in praktisch jeder technischen Due Diligence auf, unabhängig davon, ob ein strategischer Käufer, ein Investor oder ein eigenes Board die Fragen stellt.
Code, Architektur und technische Schulden
Geprüft wird, wie die Codebase strukturiert ist, wie oft ausgeliefert wird und wie viel davon manuell getestet werden muss, bevor ein Release rausgeht. Ein hoher Anteil an technischen Schulden ist dabei kein Ausschlusskriterium für sich. Entscheidend ist, ob das Team die Schulden kennt, benennen und beziffern kann. Wie sich Schulden systematisch erfassen und priorisieren lassen, steht in Technische Schulden abbauen.
Wissenskonzentration und Team
Prüfer fragen gezielt, wer welchen Teil der Codebase versteht, und was passiert, wenn diese Person morgen kündigt. Eine Plattform, die nur eine Person vollständig warten kann, ist ein Befund, unabhängig davon, wie gut der Code selbst ist. Bei Teams mit externen oder remote arbeitenden Entwicklern gehört inzwischen auch die Identitätsprüfung dazu. Wie gefälschte Identitäten in Remote-Teams die Vergabe unterlaufen, zeigt Fake-Entwickler beim IT-Outsourcing.
Abhängigkeiten, Lizenzen und Sicherheit
Dazu zählen veraltete Bibliotheken, unklare Open-Source-Lizenzen, kritische Verträge mit einzelnen Anbietern und der Umgang mit Zugangsdaten und Geheimnissen. Seit KI-Coding-Werkzeuge in vielen Teams mitschreiben, fragen Prüfer zunehmend auch, welcher Anteil des Codes KI-generiert ist und wie er geprüft wurde, bevor er in Produktion ging. Die häufigsten Risiken dabei beschreibt Vibe Coding und seine Sicherheitsrisiken.
| Prüfbereich | Frage der Prüfer | Häufiger Befund |
|---|---|---|
| Code & Architektur | Wie oft wird ausgeliefert, wie viel manuell getestet? | Technische Schulden ohne Backlog |
| Wissenskonzentration | Wer versteht welchen Teil, was bei Ausfall? | Ein Kopf trägt eine ganze Plattform |
| Abhängigkeiten | Welche Bibliotheken, welche Verträge, welche Lizenzen? | Veraltete oder unklar lizenzierte Pakete |
| Sicherheit | Wie werden Zugangsdaten und Geheimnisse gehandhabt? | Secrets im Klartext oder im Deploy-Pfad |
| Tests | Wie hoch ist die automatisierte Abdeckung? | Tests existieren, laufen aber nicht in CI |
| Team | Festangestellt, freelance, remote, verifiziert? | Ungeklärte Identität bei externen Kräften |
3. Welche Befunde verzögern oder den Preis drücken
Nicht jeder Befund kostet Geld. Die Befunde, die tatsächlich verzögern oder den Preis drücken, haben eines gemeinsam: Sie sind schwer zu beziffern, solange niemand nachgesehen hat, und genau das kostet im Datenraum Zeit. Häufig wiederkehrende Muster sind eine Architektur, die unter realer Last nie geprüft wurde, unvorhersehbare Cloud-Kosten, undokumentierte Abhängigkeiten zwischen Diensten und eine Notfall-Wiederherstellung, die nur auf dem Papier existiert.
Aus der Praxis: Ein einzelner ungeklärter Punkt bremst selten allein. Gefährlich wird die Kombination: eine Wissenskonzentration auf eine Person plus eine Sicherheitslücke, die genau diese Person zufällig kennt und nie gemeldet hat. Prüfer suchen deshalb nicht nach dem größten Einzelfund, sondern danach, ob ein Team seine eigenen Schwachstellen kennt.
Für den Zeitplan zählt vor allem, wie schnell ein Team Fragen beantworten kann. Wer erst während der Prüfung anfängt, Verträge zu suchen oder die Testabdeckung zu berechnen, verliert Wochen, die laut Studie ohnehin schon knapp bemessen sind.
Ein zweiter Effekt wird oft unterschätzt: Jede offene Frage, die das Team nicht sofort beantworten kann, erzeugt beim Prüfer den Eindruck, dass niemand die Antwort kennt, selbst wenn sie längst irgendwo dokumentiert ist. Struktur schlägt hier Vollständigkeit. Ein knappes, aktuelles Verzeichnis der bekannten Risiken wirkt glaubwürdiger als ein perfekter Code, zu dem niemand schnell Auskunft geben kann.
4. Wie Sie sich als CTO vorbereiten
Vorbereitung heißt hier nicht, jeden Befund zu beseitigen, sondern jeden Befund zu kennen, bevor ihn jemand anderes findet. Drei Schritte tragen die meiste Last.
Erstens: Unterlagen vorab sammeln. Verträge mit IP-Klauseln, Hosting-Vereinbarungen, Lizenzverträge, eine Architekturübersicht und ein aktuelles Abhängigkeitsverzeichnis gehören in eine klare Ordnerstruktur, bevor die erste Anfrage kommt.
Zweitens: die eigenen wunden Punkte benennen. Ein Team, das von sich aus sagt, wo die Wissenskonzentration liegt und welche Abhängigkeit veraltet ist, wirkt glaubwürdiger als eines, das erst auf Nachfrage antwortet. Für die Codebase-Bewertung braucht es dafür nicht zwingend eine Festanstellung. Wo interne Kapazität fehlt, übernimmt das ein Interim CTO auf Zeit.
Drittens: den Umgang mit KI-gestützter Entwicklung dokumentieren. Prüfer fragen zunehmend, wo Coding-Agenten mitschreiben und wie die Ergebnisse kontrolliert werden. Eine sauber eingeführte KI-Integration mit klaren Grenzen ist inzwischen eher ein Pluspunkt als ein Risiko, sofern sie dokumentiert ist.
5. Warum die eigene Entscheidung vor dem Datenraum steht
Die eigentliche Wahl ist nicht, ob eine Codebase gewachsen ist. Fast jede gewachsene Plattform hat unklare Stellen. Die Wahl ist, ob Sie selbst entscheiden, was mit diesen Stellen passiert, oder ob ein Käufer, Investor oder Board diese Entscheidung für Sie trifft, meist zu Ihren Ungunsten.
Refactor, Rewrite oder bewusst so ausliefern, wie es ist: Jede dieser drei Optionen lässt sich begründen. Keine davon lässt sich gut begründen, wenn die Entscheidung erst im Datenraum entsteht, unter Zeitdruck und mit jemandem, der ein Interesse am niedrigeren Preis hat. Was eine saubere Softwareentwicklung von einer Codebase erwartet, die eine Prüfung besteht, unterscheidet sich selten von dem, was ohnehin gute Praxis wäre.
Der Unterschied liegt im Zeitpunkt. Vor dem Datenraum entscheiden Sie mit Ihrem eigenen Zeithorizont und Ihrem eigenen Budget. Im Datenraum entscheidet der Kalender der Transaktion, und der gehört jemand anderem.
Fazit
Technische Due Diligence prüft keine Idealcodebase, sondern eine reale. Was zählt, ist nicht die Abwesenheit von Problemen, sondern ob Sie sie kennen, beziffern können und bereits eine Richtung dazu haben.
Wer diese Richtung vor der Prüfung festlegt, statt sie im Datenraum zu improvisieren, verhandelt aus einer anderen Position. Genau dafür gibt es die Codebase Decision: eine begründete Entscheidung zwischen Refactor, Rewrite und Ship-as-is, bevor der Käufer, Investor oder das Board die Frage stellt.