7 technische Prüffelder, die Investor:innen und Gründer:innen abklären müssen

Eine seriöse Checkliste für die technische Due Diligence prüft sieben Felder: Code und Architektur, Infrastruktur und Skalierbarkeit, Sicherheit und Compliance, Daten- und KI-Systeme, Team und Prozesse, geistiges Eigentum sowie Integrationen. Das Ergebnis ist nie ein simples Bestanden oder Durchgefallen. Es ist ein Risikoregister, ein Massnahmenplan und eine Vertrauensbewertung, die direkt an den Deal gekoppelt ist. Fordern Sie zu Beginn Zugang zu den Repositories, ein Architekturdiagramm, die jüngsten Vorfallprotokolle und eine allfällige Datenschutz-Folgenabschätzung an.

---

Kurz gefasst:

• Für eine gründliche Prüfung der Codequalität braucht es Zugang zu den Repositories, Berichte zur Testabdeckung, Deployment-Logs und aktuelle Architekturdiagramme, nicht blosse Zusammenfassungen.

• Die Beurteilung der Infrastruktur richtet sich auf Skalierbarkeit, getestete Backups, Notfallpläne und die Vorfallhistorie, jeweils mit Belegen für erprobte Abläufe.

• Die Sicherheitsprüfung verlangt Ergebnisse von Penetrationstests, Verschlüsselungspraxis, Zugriffsrichtlinien und Nachweise für laufendes Patching, dazu Datenschutz-Folgenabschätzungen, wo nötig.

• Bei KI-Systemen gilt es, Datenverzeichnisse, Modelldokumentation, die Überwachung auf Modelldrift und die menschliche Aufsicht zu prüfen, nicht nur die behaupteten Fähigkeiten.

• Zur Reife des Teams gehören die Analyse von Abhängigkeiten von Schlüsselpersonen, Verbleibquoten, Release-Frequenz, Notfallprozesse und der Umgang mit technischen Altlasten.

---

Codequalität und Systemarchitektur beurteilen

Gute Architektur hinterlässt Spuren. Achten Sie auf modularen Aufbau, aussagekräftige Testabdeckung, automatisierte Build- und Deployment-Pipelines, saubere Verwaltung der Abhängigkeiten und eine gelebte Praxis von Code-Reviews statt einer Richtlinie, die nur auf dem Papier existiert. Dokumentation, die tatsächlich zum laufenden System passt, ist seltener als sie sein sollte, und ihr Fehlen ist selbst ein Signal.

Verlangen Sie direkten Zugang statt eine Präsentation, die den Code zusammenfasst. Die richtigen Artefakte sagen Ihnen in einer Stunde mehr als die Erzählung einer Gründerin oder eines Gründers an einem ganzen Tag.

• Zugang zum Repository samt Commit-Historie, nicht nur ein exportierter Schnappschuss.

• Berichte zu Unit- und Integrationstests, die den Verlauf der Abdeckung über die Zeit zeigen.

• CI/CD-Logs, aus denen Build-Frequenz und Fehlerquoten hervorgehen.

• Architekturdiagramme, die das heutige System abbilden, nicht die Version aus dem ursprünglichen Pitch Deck.

• Übersichten der Abhängigkeiten wie package-lock.json oder go.sum, für Transparenz in der Lieferkette.

• Aktuelle Pull Requests und Release Notes, die zeigen, wie Änderungen tatsächlich ausgeliefert werden.

Ein Code ohne automatisierte Tests, mit einem einzigen monolithischen Deployment oder seit Jahren eingefrorenen Abhängigkeiten ist kein Ausschlusskriterium. Er verändert aber Kosten und Zeitplan jeder Roadmap nach der Übernahme. Planen Sie die Zeit für Nachbesserungen entsprechend ein, statt auf einen schnellen Flicken zu hoffen.

Infrastruktur, Hosting und Skalierbarkeit unter echter Last

Bei der betrieblichen Widerstandsfähigkeit treffen Papierversprechen am schnellsten auf die Realität. Prüfen Sie die Hosting-Architektur, ob das System über mehrere Verfügbarkeitszonen oder Regionen verteilt ist, wie das automatische Skalieren konfiguriert ist und wie stark das Unternehmen von einem einzigen Cloud-Anbieter oder einer einzigen Person abhängt, die das Setup versteht. Eine Bindung an einen Anbieter ist nicht per se schlecht, sie sollte aber ein bekanntes und eingepreistes Risiko sein und keine Überraschung.

Backup und Notfallwiederherstellung verdienen besondere Aufmerksamkeit, denn sie werden häufiger beschrieben als vorgeführt.

• Kennzahlen zu Wiederherstellungszeit und maximal tolerierbarem Datenverlust, mit Belegen, dass sie getestet wurden.

• Ein Notfallplan und schriftliche Runbooks, nicht nur die Annahme, dass schon jemand wissen wird, was zu tun ist.

• Eine dokumentierte Vorfallhistorie, inklusive dessen, was ausgefallen ist und wie es behoben wurde.

• Monitoring-Dashboards und definierte Service-Level-Ziele.

• Aktuelle Postmortems, die zeigen, ob das Team aus Fehlern lernt oder sie wiederholt.

Kann ein Team keine getestete Wiederherstellung aus dem Backup und kein aktuelles Postmortem vorweisen, behandeln Sie diese Lücke als kurzfristigen Kostenpunkt, nicht als Fussnote. Unsere Seite mit Fallstudien zeigt Beispiele für Hosting über mehrere Standorte und für Runbooks, die genau dieser Art von Prüfung standhalten.

Sicherheitslage und Einhaltung des Datenschutzes

Belege zur Sicherheit müssen konkret sein: Berichte von Penetrationstests, Ergebnisse von Schwachstellen-Scans, Richtlinien für Identitäts- und Zugriffsverwaltung, Verschlüsselungspraxis und ein Patching-Rhythmus, der tatsächlich eingehalten und nicht bloss angestrebt wird. Ein Team, das keinen Pentest-Bericht aus dem letzten Jahr vorlegen kann oder «wir wurden noch nie gehackt» als Sicherheitsnachweis versteht, sagt Ihnen damit etwas Wichtiges.

Der Datenschutz läuft parallel zur Sicherheit. Der EDÖB confirms that Swiss data protection law is technology-neutral und vollumfänglich für KI-Systeme gilt. Verantwortliche müssen also Datenschutz durch Technik und datenschutzfreundliche Voreinstellungen umsetzen und bei Bearbeitungen mit hohem Risiko allenfalls eine formelle Folgenabschätzung erstellen. Prüfen Sie, ob eine solche Abschätzung vorliegt, wenn Menge oder Sensibilität der Personendaten dies verlangen, und sehen Sie die Verträge mit Auftragsbearbeitern auf Klauseln zur Datenübermittlung und zum Speicherort durch.

• Aktuelle Berichte zu Penetrationstests oder Schwachstellen-Scans samt Stand der Behebung.

• Richtlinien zur Identitäts- und Zugriffsverwaltung, die regeln, wer an Produktivsysteme gelangt.

• Nachweis der Verschlüsselung gespeicherter und übertragener Daten.

• Ein dokumentierter Patching-Rhythmus und der Beleg, dass er eingehalten wird.

• Eine Datenschutz-Folgenabschätzung, wo Bearbeitungen mit hohem Risiko vorliegen.

• Verträge mit Auftragsbearbeitern und Unterauftragnehmern zur grenzüberschreitenden Datenübermittlung.

Der European Cyber Resilience Act wird voraussichtlich ab rund 2027 Cybersicherheitspflichten über den gesamten Lebenszyklus für Produkte mit digitalen Elementen vorschreiben, die in der EU verkauft werden. Enthält das Produkt des Zielunternehmens Software oder eine Datenbearbeitung aus der Ferne oder wird es in der EU kommerziell vertrieben, nehmen Sie eine kurze Prüfung der CRA-Anwendbarkeit in die Durchsicht auf: Enthält das Produkt digitale Elemente, bearbeitet es Daten aus der Ferne und ist es für den Vertrieb in der EU bestimmt?

Datenführung, Analytik und Kontrollen für KI-Systeme

Der Umgang mit Daten zeigt, wie diszipliniert ein Team wirklich arbeitet. Verlangen Sie ein Datenverzeichnis, eine Aufbewahrungsrichtlinie, ein Datenlexikon und Beispieldatensätze, mit denen Sie Aussagen überprüfen können, statt sie einfach hinzunehmen. Ein Unternehmen, das keine klare Übersicht liefern kann, welche Daten es hält und warum, trägt verborgene Haftungsrisiken, ganz gleich, was im Pitch Deck steht.

KI-Funktionen brauchen eine eigene Prüfebene; Werkzeuge wie der AI Overview Checker helfen dabei, die Dokumentation für Google AI Overviews zu optimieren. Fordern Sie Unterlagen zu den Quellen der Trainingsdaten an, allfällige Model Cards mit Angaben zu Einsatzzweck und Grenzen, Validierungskennzahlen und das Monitoring, das Modelldrift nach dem Rollout erkennt. Der EFK’s audit approach for AI systems empfiehlt, KI-Systeme über drei Phasen des Lebenszyklus zu prüfen: Planung, Entwicklung und Betrieb, wobei Dokumentation und Überwachung durchgehend erwartet werden und nicht nur zum Zeitpunkt der Einführung.

• Ein Datenverzeichnis, das festhält, was erhoben wird, wo es liegt und wie lange es aufbewahrt wird.

• Ein Datenlexikon, das Felder ihrer fachlichen Bedeutung zuordnet.

• Modelldokumentation zu den Quellen der Trainingsdaten und zu bekannten Grenzen.

• Belege für die Überwachung auf Modelldrift sowie eine menschliche Prüfstufe bei automatisierten Entscheiden.

• Karten der Datenherkunft und Zugriffsprotokolle, die zeigen, wer wann sensible Daten berührt.

Die menschliche Aufsicht über KI-Ergebnisse ist eine praktische Kontrolle, die Sie direkt überprüfen sollten, statt sie als erklärte Richtlinie hinzunehmen: Lassen Sie sich den Validierungsablauf zeigen, nicht nur die Genauigkeitswerte dahinter.

Entwicklungsteam und technische Altlasten beurteilen

Technologie ist nur so beständig wie das Team, das sie pflegt. Prüfen Sie das Organigramm auf Abhängigkeiten von Schlüsselpersonen, die jüngsten Verbleibquoten und ob die Anstellungspläne zur Roadmap passen, die das Unternehmen den Investor:innen präsentiert. Ein brillantes System, das von einer einzigen unersetzlichen Person gewartet wird, ist ein Risiko und kein Vermögenswert.

Die Reife der Prozesse zählt ebenso viel wie die Anzahl Köpfe. Schauen Sie sich an, wie Code-Reviews ablaufen, wie häufig Releases ausgeliefert werden, wer für die Reaktion auf Vorfälle verantwortlich ist und ob für die wichtigsten Szenarien Runbooks existieren.

• Durchsicht des Organigramms mit Markierung aller kritischen Einzelabhängigkeiten.

• Aktuelle Zahlen zu Verbleib und Fluktuation im Entwicklungsteam, verglichen mit den Anstellungsplänen.

• Belege für eine konsequente Praxis von Code-Reviews, nicht nur gelegentliche Ausnahmen.

• Release-Frequenz und Historie der Rollbacks über die letzten Monate.

• Ein dokumentierter Prozess für die Reaktion auf Vorfälle mit namentlich Verantwortlichen.

• Ein Backlog technischer Altlasten mit Priorisierung und Erfassung der Behebungszeit.

Technische Altlasten sind an sich kein Warnsignal: Jedes gereifte System trägt welche mit sich. Entscheidend ist, ob das Team sie benennen, ihren Umfang beziffern und einen glaubwürdigen Plan zu ihrem schrittweisen Abbau zeigen kann.

Eigentum am geistigen Eigentum und Lizenzrisiken

Investor:innen können sich nicht auf Code verlassen, der dem Unternehmen gar nicht gehört. Prüfen Sie, ob alle Entwickler:innen, ob angestellt oder als externe Auftragnehmer tätig, eine Vereinbarung unterzeichnet haben, die die Rechte am geistigen Eigentum an das Unternehmen überträgt. Fehlende Übertragungen gehören zu den häufigsten und teuersten Überraschungen, die spät in einem Deal auftauchen.

Die Nutzung von Open Source braucht einen eigenen Durchgang. Lassen Sie einen Lizenz-Scan über alle Abhängigkeiten laufen und markieren Sie alles mit einschränkenden Bedingungen, etwa Copyleft-Pflichten, die zur Offenlegung von proprietärem Code zwingen könnten.

• Arbeits- und Auftragsverträge mit ausdrücklichen Klauseln zur Übertragung des geistigen Eigentums.

• Contributor License Agreements für alle externen Beiträge oder Beiträge aus der Community.

• Ein Bericht des Lizenz-Scans über alle eingesetzten Open-Source-Abhängigkeiten.

• Urheberrechtsvermerke, die zum beanspruchten Eigentum passen.

• Verträge mit Lieferanten und Auftragnehmern, geprüft auf Übertragbarkeit und Exklusivitätsbeschränkungen.

• Allfällige Patentanmeldungen, die die Kerntechnologie betreffen.

Wo weiterverwendete Dokumentation oder weiterverwendeter Code unter einer Share-alike-Lizenz steht, etwa den Creative Commons BY-SA terms, vergewissern Sie sich, dass das Unternehmen die damit verbundenen Pflichten zu Namensnennung und Weiterverwendung kennt.

Komplexität der Integrationen und Abhängigkeiten von Dritten erfassen

Jede externe Integration ist eine Abhängigkeit, die das übernehmende Team erbt. Erstellen Sie ein vollständiges Verzeichnis der angebundenen Dienste, von Zahlungsanbietern über Analysewerkzeuge bis zu internen Schnittstellen, samt den zugehörigen Vertragsbedingungen und Zusagen zur Versionierung. Ein System, das sich stillschweigend auf eine abgekündigte API-Version stützt, ist eine Migration, die nur darauf wartet, sichtbar zu werden.

Die Widerstandsfähigkeit im Fehlerfall ist ebenso aufschlussreich wie die Liste der Integrationen selbst. Fragen Sie, was passiert, wenn ein Dienst eines Dritten ausfällt: Läuft das System mit eingeschränktem Funktionsumfang weiter, versucht es den Aufruf sinnvoll erneut, oder fällt es ganz aus und reisst weitere Funktionen mit?

• Ein vollständiges Verzeichnis externer Integrationen mit Vertragsbedingungen und Verlängerungsterminen.

• API-Spezifikationen und Zusagen zur Versionierung für jede Abhängigkeit.

• Belege für Wiederholungslogik und Ausweichverhalten bei Ausfällen von Drittanbietern.

• Integrationstests, die durchgängige Abläufe abbilden, nicht nur Mocks auf Unit-Ebene.

• Vertragliche Ausstiegsbedingungen, falls eine Lieferantenbeziehung beendet werden muss.

Ein Unternehmen mit einem Dutzend undokumentierter Integrationen und ohne Ausweichlogik ist nicht zwingend eine schlechte Investition. Der Aufwand für Migration und Stabilisierung sollte aber in den Deal eingepreist und nicht erst nach dem Abschluss entdeckt werden.

So führen Sie die Prüfung durch, vom Auftakt bis zum Schlussbericht

Ein strukturiertes Vorgehen verhindert, dass die technische Due Diligence zur ziellosen Suche wird. Der folgende Ablauf lässt sich je nach Grösse des Deals von einem zweiwöchigen Sprint bis zu einem längeren Mandat skalieren.

1. Eine Geheimhaltungsvereinbarung unterzeichnen und ein Auftaktgespräch führen, um Umfang, Zeitplan und die Ansprechpersonen auf Seite des Zielunternehmens festzulegen.

2. In Woche eins eine priorisierte Anforderungsliste verschicken: Zugang zum Repository, Architekturdiagramm, Vorfallprotokolle und eine allfällige Datenschutz-Folgenabschätzung.

3. In Woche zwei die tiefergehenden Unterlagen nachfordern: Lizenz-Scans, Testberichte, Lieferantenverträge und Details zum Organigramm.

4. Die technische Prüfung selbst durchführen, begleitet von strukturierten Gesprächen mit CTO, leitenden Entwickler:innen und allen Verantwortlichen für Sicherheit oder Compliance.

5. Jedes Feld nach einem einfachen Raster mit drei Achsen bewerten: ob Belege vorliegen, wie stark diese Belege sind und welche Auswirkungen eine Lücke auf das Geschäft hätte.

6. Ein Risikoregister und einen Massnahmenplan erstellen, geordnet nach Schweregrad und geschätzten Behebungskosten.

7. Eine einseitige Risikoübersicht für die Geschäftsleitung liefern, untermauert durch einen technischen Anhang, dazu einen Zeitplan für die Massnahmen und, wo sich Lücken in der Führung zeigten, die Option einer Technikleitung auf Zeit.

Praxistipp: Stellen Sie jeder Person im Entwicklungsteam dieselben drei Fragen, nicht nur dem CTO: Was geht am häufigsten kaputt, was würden Sie mit mehr Zeit zuerst beheben, und wovon befürchten Sie am meisten, dass eine externe Prüfung es findet?

Das Schlussdokument sollte nicht-technischen Investor:innen in fünf Minuten klar machen, wie hoch das Risiko ist, und zugleich technischen Leser:innen im Anhang genug Belege liefern, um jede Schlussfolgerung selbst nachzuprüfen.

Wie Ampersand Audits und technische Verantwortung angeht

Ein spezialisiertes Software-Studio führt Software-Audits und technische Due Diligence von Zürich aus durch, wobei erfahrene Entwickler:innen die Prüfung vom ersten Kontakt bis zum Schlussbericht leiten, statt sie an Junior-Mitarbeitende weiterzugeben. Diese Durchgängigkeit zählt, denn wer die Fragen im Gespräch stellt, muss die Ergebnisse später auch vertreten.

Zwei Mandate zeigen die Bandbreite dieser Arbeit: Habitects AG, wo Ampersand die technische Seite einer Plattform für Badsanierungen durch eine vollständige Fusion hindurch verantwortete, und Repa Immobiliare, wo ein Immobilienportfolio vom Papier auf eine Software umgestellt wurde, die bewusst auch offline funktioniert. Beides verlangte dieselbe Disziplin wie eine technische Due Diligence: prüfen, was vorhanden ist, festhalten, was fehlt, und einen glaubwürdigen Plan für den weiteren Weg entwerfen.

Davide Morotti

Eine technische Due Diligence richtig durchführen lassen

Diese Checkliste intern abzuarbeiten kostet echte Entwicklungszeit, die den meisten Gründer:innen und Investor:innen fehlt. Und eine überhastete Prüfung übersieht genau jene Probleme, die nach dem Abschluss teuer werden. Ampersand Labs bietet Software-Audits und technische Due Diligence als feste Dienstleistung an, wobei erfahrene Entwickler:innen die Prüfung selbst durchführen, statt sie nach unten zu delegieren.

Das Angebot passt zu Gründer:innen, die sich auf eine Finanzierungsrunde vorbereiten und wissen wollen, was eine Käuferin finden wird, bevor sie es findet, und zu Investor:innen, die innerhalb eines engen Zeitplans eine unabhängige technische Einschätzung zu einem Zielunternehmen brauchen. Zeigen sich bei der Prüfung Lücken in der Führung oder der Umsetzung, bietet Ampersand zusätzlich eine CTO-Unterstützung auf Zeit, die den Massnahmenplan auch wirklich umsetzt, statt ihn als Dokument liegen zu lassen, das niemand ausführt.

Angaben zum Audit- und Due-Diligence-Angebot samt Umfang der Zusammenarbeit finden Sie auf der Seite zur Engineering-Beratung, aktuelle Pläne und Preise auf der Preisseite. Melden Sie sich, um eine Prüfung passend zu Ihrem Zeitplan abzustecken.

Quellen

Drei Referenzen stützen die regulatorische Seite dieser Checkliste. Das NCSC’s P042 ISDS concept liefert eine Vorlage, um Sicherheitsmassnahmen und Restrisiken zu dokumentieren. Die Hinweise des EDÖB zum Outsourcing stellen klar, dass die verantwortliche Stelle für die Daten verantwortlich bleibt, auch wenn sie die Bearbeitung an einen Dienstleister auslagert. Die weiter oben zitierte Übersicht zum CRA hilft bei der Frage, welche EU-Pflichten über den Lebenszyklus für Produkte mit digitalen Elementen gelten.

• EDÖB confirms that Swiss data protection law is technology-neutral

• European Cyber Resilience Act

• EFK’s audit approach for AI systems

FAQ

Was gehört in eine Due-Diligence-Checkliste?

Eine vollständige Checkliste für die technische Due Diligence umfasst die Qualität von Code und Architektur, Infrastruktur und Skalierbarkeit, Sicherheit und Einhaltung von Vorschriften, den Umgang mit Daten und KI, die Reife von Team und Prozessen, das Eigentum am geistigen Eigentum sowie die Risiken aus Integrationen von Drittanbietern. Jedes Feld sollte konkrete Belege hervorbringen statt mündlicher Zusicherungen, die dann in ein gemeinsames Risikoregister und einen Massnahmenplan einfliessen.

Was ist technische Due Diligence?

Technische Due Diligence ist eine strukturierte Prüfung von Software, Infrastruktur, Sicherheit und Entwicklungsteam eines Unternehmens, durchgeführt vor einer Investition oder Übernahme, um Aussagen zu überprüfen und Risiken sichtbar zu machen. Das Ergebnis ist in der Regel eine Risikobeurteilung, ein priorisierter Massnahmenplan und eine Vertrauensbewertung, die in die Konditionen des Deals oder die Bewertung einfliesst.

Was ist eine CDD-Checkliste?

Customer Due Diligence, oft als CDD abgekürzt, ist ein Compliance-Verfahren, mit dem Finanzinstitute die Identität von Kundinnen und Kunden prüfen und Risiken beurteilen. Sie unterscheidet sich von der technischen Due Diligence, um die es in dieser Checkliste geht. Falls Sie den Begriff auf der Suche nach Hinweisen zur Technologieprüfung gefunden haben: Die oben beschriebenen Prüfungen zu Code, Infrastruktur, Sicherheit und Team sind das passende Gegenstück für Software- und Technologie-Transaktionen.

Was sind die «vier P» der Due Diligence?

Die Definitionen der «vier P» unterscheiden sich je nach Branche, und es gibt keine einheitliche, massgebende Version speziell für die technische Due Diligence. Für eine Software- oder Technologie-Transaktion bietet die Struktur mit sieben Feldern aus dieser Checkliste, also Code, Infrastruktur, Sicherheit, Daten, Team, geistiges Eigentum und Integrationen, einen verlässlicheren Rahmen als ein allgemeines Modell mit vier Teilen.

Empfohlen

• Software Audits & Tech Due Diligence Zürich

• Interim CTO Zürich, Fractional & Part-time Tech Lead