Technical Due Diligence Evidence Checklist
Mit diesem Register werden technische Due-Diligence-Fragen zu nachvollziehbaren Evidence Requests. Es hält fest, welche Nachweise existieren, wem sie gehören, was verifiziert wurde, was offen bleibt und warum diese Unsicherheit für die Investmentthese relevant ist.
Eine Checkliste ist noch kein Ergebnis. Ein Dokument kann aktuell, veraltet, unvollständig oder durch das laufende System widerlegt sein. Nachweise möglichst nur lesend prüfen, Datum und Quelle festhalten und „nicht bereitgestellt“ von „existiert nicht“ trennen. Rechtliche, steuerliche, Datenschutz- und spezielle Sicherheitsfragen gehören zu entsprechend qualifizierten Berater:innen.
Investor Request
Mit der Investmentthese beginnen, nur entscheidungsrelevante Nachweise anfordern und die Wesentlichkeitsschwelle vor der Datenraumprüfung festlegen. Einschränkungen dokumentieren, damit ein fehlender Nachweis nicht stillschweigend zu einer beruhigenden Annahme wird.
Founder Readiness
Dasselbe Register vor dem Prozess durchgehen. Verantwortliche benennen, veraltete Dateien entfernen, echte Lücken erklären und bereits laufende Maßnahmen knapp dokumentieren. Keine Richtlinien erfinden und keine Nachweise rückdatieren.
Unternehmen und Transaktion[Unternehmen / Deal-Phase]
Investmentthese[Produkt-, Wachstums-, Margen- oder Integrationsannahmen, die Technik tragen muss]
Review-Verantwortung und Frist[Name / Datum]
Wesentlichkeitsschwelle[finanzielle, operative, regulatorische oder zeitliche Schwelle]
Zugriffsprotokoll[Lesezugänge, freigegebener Datenraum, Interviewregeln, Vertraulichkeitsgrenzen]
- Evidence Owner, Reviewer, Datenraum-Ort, Quelldatum und Prüfdatum.
- Status: nicht angefragt, angefragt, bereitgestellt, verifiziert, ersetzt, nicht verfügbar oder nicht relevant.
- Konfidenz: hoch, mittel oder niedrig – mit Beleg und Einschränkung für diese Einstufung.
- Beobachtete Tatsache, Aussage des Managements, Schlussfolgerung und offene Frage getrennt halten.
- Relevanz für die Investmentthese, plausible Exposition, Maßnahmenverantwortung, Termin und Entscheidungsauslöser.
| Zu klärende Frage | Anzufordernder Nachweis | Entscheidungsrelevanz |
|---|---|---|
| Trägt die aktuelle Architektur die Investmentthese und das erwartete Wachstum? | Aktuelles Architekturdiagramm, Systeminventar, Datenflüsse, Kapazitätstests und Produkt-Roadmap für zwölf Monate. | Zeigt, ob Wachstum eine begrenzte Verbesserung oder einen kostspieligen strukturellen Umbau erfordert. |
| Wo liegen bekannte Engpässe und Ausfallpunkte? | Störungshistorie, Post-Mortems, Fehlertrends, Performance-Berichte und aktuelles Register technischer Schulden. | Zeigt, welche Engpässe Umsatz, Lieferung oder den Wertsteigerungsplan gefährden können. |
| Zu klärende Frage | Anzufordernder Nachweis | Entscheidungsrelevanz |
|---|---|---|
| Kontrolliert das Unternehmen den Code und kann das Team ihn sicher ändern? | Lesezugriff auf Repositories, Eigentumsnachweise, Branch-Schutz, Build-Anleitung, Testergebnisse und Release-Historie. | Prüft Kontrolle, Reproduzierbarkeit, Änderungsrisiko und Abhängigkeit von undokumentiertem Wissen. |
| Ist die Lieferfähigkeit sichtbar und wiederholbar? | Deployment-Häufigkeit, Durchlaufzeit, Fehlerrate, Rollbacks, Alter des Backlogs und Release-Freigaben. | Zeigt, ob die Roadmap mit dem bestehenden Betriebsmodell realistisch ist. |
| Zu klärende Frage | Anzufordernder Nachweis | Entscheidungsrelevanz |
|---|---|---|
| Wird die Produktion beobachtbar und wiederherstellbar betrieben? | Cloud-Inventar, Infrastrukturkonfiguration, Monitoring-Abdeckung, Backup-Regeln, Restore-Tests und Notfallplan. | Identifiziert Ausfallrisiken und den Aufwand für eine akzeptable Wiederherstellbarkeit. |
| Wer kann auf Produktion zugreifen oder sie ändern? | Zugriffslisten, privilegierte Rollen, Ein- und Austrittsnachweise, Änderungslogs, Secret-Management und Notfallzugriff. | Prüft operative Kontrolle und Konzentration des Zugriffsrisikos bei einer Person oder einem Anbieter. |
| Zu klärende Frage | Anzufordernder Nachweis | Entscheidungsrelevanz |
|---|---|---|
| Welche wesentlichen Sicherheitsrisiken sind bekannt, geprüft und zugeordnet? | Risikoregister, Umfang und Behebung aktueller Assessments oder Penetrationstests, Schwachstellentrends und Incident-Übung. | Trennt belegte Kontrolllücken von allgemeinen Bedenken und verbindet sie mit plausibler Exposition. |
| Funktionieren zentrale Kontrollen praktisch und nicht nur auf dem Papier? | Stichproben zu MFA, Patching, Endpoint-Schutz, Logging, Zugriffsprüfung, sicherer Entwicklung und Lieferantenprüfung. | Prüft, ob deklarierte Kontrollen Risiken tatsächlich senken und was in den Maßnahmenplan gehört. |
| Zu klärende Frage | Anzufordernder Nachweis | Entscheidungsrelevanz |
|---|---|---|
| Welche Daten werden gehalten, wohin fließen sie und auf welcher Grundlage werden sie verarbeitet? | Dateninventar, Flussdiagramm, Löschfristen, Verarbeitungsverzeichnis, Datenschutzhinweise und Löschprozess. | Zeigt Verpflichtungen, unzugängliche Datenbestände und Grenzen für Produkt- oder Marktexpansion. |
| Sind Auftragsverarbeiter, Übermittlungen und Kundenzusagen bekannt? | Liste der Verarbeiter, relevante Verträge, Nachweise zu Übermittlungen, Kundenanforderungen und offene Anfragen oder Streitfälle. | Identifiziert vertragliche oder operative Fragen, die qualifizierte rechtliche Bewertung benötigen. |
| Zu klärende Frage | Anzufordernder Nachweis | Entscheidungsrelevanz |
|---|---|---|
| Was kostet die Plattform heute und wodurch verändern sich die Kosten? | Cloud-, Software-, Dienstleister-, Support- und Lizenzkosten der letzten 12–24 Monate samt Nutzungs- und Umsatztreibern. | Prüft Margenannahmen und trennt Wachstumskosten von Verschwendung oder aufgeschobener Wartung. |
| Welche kurzfristigen Verpflichtungen oder Ablösungen sind unvermeidbar? | Verlängerungskalender, Mindestabnahmen, End-of-Life-Systeme, Migrationsschätzungen und genehmigte oder vertagte Investitionen. | Zeigt Liquiditätsbedarf für Bewertung, Integration oder den ersten 100-Tage-Plan. |
| Zu klärende Frage | Anzufordernder Nachweis | Entscheidungsrelevanz |
|---|---|---|
| Kann das aktuelle Team die Plattform betreiben und weiterentwickeln? | Organigramm, Rollen, Betriebszugehörigkeit, offene Stellen, Rufbereitschaft, Kompetenzmatrix und Roadmap-Zuordnung. | Prüft, ob die Umsetzung von Einstellungen, Bindung oder zusätzlicher Führungskapazität abhängt. |
| Wo ist Wissen auf einzelne Personen konzentriert? | Bus-Faktor, Dokumentationsabdeckung, Systemverantwortung, aktuelle Übergaben und Interviews zu Schlüsselabhängigkeiten. | Deckt Kontinuitäts- und Integrationsrisiken auf, die eine reine Personalzahl verbirgt. |
| Zu klärende Frage | Anzufordernder Nachweis | Entscheidungsrelevanz |
|---|---|---|
| Welche Anbieter sind betriebsentscheidend und wie können diese Beziehungen verändert werden? | Anbieterverzeichnis, Verträge, Service Levels, Verlängerung und Kündigung, Unterauftragnehmer sowie Exit- oder Migrationspläne. | Prüft Lock-in, Konzentration, Change-of-Control-Bedingungen und Ablösungskosten. |
| Sind die Rechte an der eingesetzten Technologie dokumentiert? | IP-Regeln für Beschäftigte und Dienstleister, Code-Herkunft, Open-Source-Inventar, Lizenzprüfung, Domains und Softwareabtretungen. | Markiert Eigentumsfragen für die qualifizierte rechtliche Prüfung vor Transaktion oder Integration. |
Frage und Workstream[auf die Anfrage oben verweisen]
Verifizierter Nachweis[Quelle, Datum, Ort und Reviewer]
Finding[eine beobachtete Tatsache; Schlussfolgerung getrennt halten]
Status und Konfidenz[Status / hoch, mittel oder niedrig / Begründung]
Einschränkung[fehlender Zugriff, Stichprobe, Alter, Widerspruch oder Scope-Grenze]
Thesenrelevanz[welche Investmentannahme sich ändern könnte]
Geschätzte Exposition[Bandbreite, Zeitpunkt, operative Wirkung und Berechnungsbasis – keine pauschale Ampel]
Maßnahme und Verantwortung[Closing-Bedingung, Deal-Term, 100-Tage-Maßnahme, akzeptieren oder weiter prüfen]
- Nicht verfügbare Nachweise und die dadurch begrenzten Entscheidungen ausdrücklich auflisten.
- Bestätigte Exposition von plausiblen Szenarien trennen und die Berechnungsbasis jeder Bandbreite zeigen.
- Wesentliche Findings einer Closing-Bedingung, einem Deal-Term, einer 100-Tage-Maßnahme, akzeptiertem Risiko oder weiteren Test zuordnen.
- Verantwortung, Budget, Frist und Abschlussnachweis jeder Maßnahme benennen.
- Die wesentlichen Findings in ein kurzes Decision Memo überführen statt das Rohregister weiterzugeben.
Dieses Register unterstützt einen evidenzbasierten Review; es ist keine Rechts-, Finanz-, Datenschutz- oder Sicherheitsberatung. Zum Technical-Due-Diligence-Review oder die Findings in ein Technical Audit Decision Memo überführen.