Die kurze Antwort
Eine technische Due Diligence prüft, ob ein Käufer die Technologie nach einer Transaktion verstehen, betreiben und weiterentwickeln kann. Verkäufer sollten ein Verzeichnis aus Aussagen und Belegen zu Architektur, Repositories, Releases, Sicherheit, Resilienz, Datenschutz, Lizenzen, Personen und technischen Schulden aufbauen. Das Ziel ist kein perfektes System und keine ungeordnete Dokumentensammlung, sondern eine aktuelle, widerspruchsfreie Faktenbasis mit Zuständigkeiten, Testdaten und transparent behandelten Ausnahmen.
Mit Aussagen, Belegen und Umfang beginnen
Die technische Prüfung ist Teil der gesamten Unternehmensprüfung. Das Schweizer KMU-Portal erklärt, dass Due Diligence Kaufentscheid, Preis und Vertrag beeinflusst. Der Umfang hängt auch davon ab, was übertragen werden soll. Bei einem Share Deal kann die gesamte Betriebs- und Haftungssphäre relevant sein. Bei einem Asset Deal stehen die übertragenen Technologien, Verträge und Rechte im Vordergrund. Den rechtlichen Umfang sollten qualifizierte Fachpersonen festlegen.
Erstellen Sie vor dem Hochladen einen Index. Jede wichtige Aussage im Verkaufsmaterial erhält einen Beleg, eine zuständige Person, ein Datum und bekannte Ausnahmen. Die Aussage «Deployments sind automatisiert» verweist beispielsweise auf Pipeline-Konfiguration, einen aktuellen Lauf und eine Stellvertretung.
| Aussage | Beleg | Verantwortung | Letzter Test | Status |
|---|---|---|---|---|
| Produktion ist wiederherstellbar | Runbook und Restore-Protokoll | Plattformverantwortliche Person | Tatsächliches Datum | Grün, gelb oder rot |
| Zugriffe sind kontrolliert | Rollenliste und Review | Sicherheitsverantwortliche Person | Tatsächliches Datum | Ausnahmen nennen |
Architektur, Inventar und Änderungen dokumentieren
Zeigen Sie Anwendungen, Datenspeicher, Hosting, Integrationen, kritische Anbieter und Vertrauensgrenzen in einem aktuellen Systembild. Ergänzen Sie ein Inventar mit technischer Verantwortung, Lebenszyklus und Abhängigkeiten. Ein Diagramm ohne Zuständigkeiten veraltet; ein Inventar ohne Beziehungen verdeckt Konzentrationsrisiken.
Käufer prüfen auch Reproduzierbarkeit. Dokumentieren Sie Repositories, Reviews, Build, Tests, Deployment und Rollback. Verfolgen Sie ein repräsentatives Release vom genehmigten Change bis zum Monitoring. Wenn nur der Gründer einen Schritt kennt, erfassen Sie dies als Massnahme.
- Architektur und Datenflüsse
- Applikations-, Infrastruktur- und Anbieterinventar
- Repository-Eigentum und Zugriffe
- Build-, Test-, Release- und Rollback-Belege
- Konfiguration und Umgebungen
- Roadmap, End-of-Life-Komponenten und technische Schulden
Sicherheit und Resilienz prüfbar machen
Die Grundschutz-Empfehlungen des BACS verbinden organisatorische und technische Verantwortung. Verknüpfen Sie deshalb Identitäten, privilegierte Zugriffe, Patches, Schwachstellen, Endgeräte, Cloud, Logging und Incident Response mit verantwortlichen Personen.
Backups werden erst durch einen Restore-Test überzeugend. Erfassen Sie Umfang, Frequenz, Aufbewahrung, Trennung von Produktion und letzte Wiederherstellung. Ordnen Sie Recovery-Ziele den Kundenversprechen zu. Listen Sie wesentliche Vorfälle mit Auswirkung, Reaktion, Korrektur und heutigem Status.
Die praktische Käuferfrage lautet: Kann eine zweite Person deployen, wiederherstellen und reagieren, ohne von undokumentiertem Wissen abhängig zu sein?
Daten und Offenlegung kontrollieren
Ein Datenraum hebt Datenschutz, Vertraulichkeit und Verträge nicht auf. Die EDÖB-Leitlinie betont Zweck, Verhältnismässigkeit und beschränkten Zugriff. Inventarisieren Sie Personendaten, Zwecke, Speicherorte, Auftragsbearbeiter, Fristen, Löschung und Auslandtransfers. Lassen Sie die Anwendung des Schweizer Datenschutzrechts auf die konkrete Transaktion fachlich prüfen.
Nutzen Sie Stufen: zuerst Kontrollbeschreibungen und aggregierte Daten, identifizierbare Kunden- oder Personaldaten erst bei Notwendigkeit. Definieren Sie Empfänger, Schwärzung, Ablauf des Zugriffs und Disclosure Log.
Lizenzen, Eigentum und Schlüsselpersonen prüfen
Technische und rechtliche Evidenz müssen zusammenpassen. Verknüpfen Sie Kernkomponenten mit Repository, Urheber oder Anbieter, Arbeits- oder Auftragsverhältnis, Abtretung oder Lizenz sowie Drittkomponenten. Führen Sie Open-Source-Komponenten mit Lizenz- und Hinweispflichten. Der Leitfaden zum Eigentum an Software-IP vertieft die Herkunftskette.
Ordnen Sie jedem kritischen System Haupt- und Stellvertretung zu. Erfassen Sie Mitarbeitende, Auftragnehmer, Anbieter, Kündigungsfristen, Übergabekapazität und privilegierte Zugriffe. So werden Abhängigkeiten von Einzelpersonen sichtbar.
Mit einem Ampelregister arbeiten
Illustratives Beispiel: Ein Schweizer SaaS-Unternehmen gibt an, Recovery werde quartalsweise getestet. Eine aktuelle Backup-Richtlinie liegt vor, doch der letzte vollständige Restore ist elf Monate alt und nur der Gründer besitzt einen Cloud-Recovery-Zugang. Die Aussage ist gelb oder rot, nicht grün. Das Register benennt einen Plattformverantwortliche Person, plant einen kontrollierten Restore, richtet einen separat verwalteten Notzugang ein und hält das Resultat fest.
Die Farbe ist nur interne Priorisierung. Definieren Sie jeden Status, bewahren Sie Fakten auf und ändern Sie keine Einstufung zur besseren Darstellung. Eine dokumentierte Ausnahme mit verantwortlicher Person und Termin ist glaubwürdiger als eine nicht reproduzierbare Zusicherung.
- Aussagen im Verkaufsmaterial auflisten.
- Aktuelle Artefakte und Verantwortliche zuordnen.
- Je kritischem Bereich einen Prozess testen.
- Ausnahmen und Relevanz dokumentieren.
- Wesentliche Lücken soweit sinnvoll beheben.
- Offenlegungen protokollieren.
Die Fragen hinter der Checkliste antizipieren
Ein Käufer prüft Technologie nicht isoliert. Er verbindet technische Fakten mit Kundenkontinuität, künftigem Investitionsbedarf und den diskutierten Zusicherungen oder Offenlegungen. Erstellen Sie für jedes kritische System eine kurze Erklärung zu Geschäftszweck, Nutzern, heutiger Last, Serviceerwartung, Verantwortung, wahrscheinlichem Ausfallmodus und geplanter Investition. Trennen Sie beobachtete Fakten von Prognosen. Wenn Kapazität über die heutige Last hinaus nicht getestet wurde, beschreiben Sie die vorhandene Evidenz und den nächsten Test statt unbegrenzte Skalierbarkeit zu behaupten.
Bereiten Sie Evidenzpfade für typische Anschlussfragen vor. Wie erhält ein neuer Engineer Zugriff? Welche Änderungen brauchen Peer Review? Wer darf einen Notfall-Release freigeben? Wie werden kundenspezifische Konfigurationen getrennt? Was passiert beim Ausfall eines kritischen Anbieters? Welche Komponenten erreichen das Lebensende? Wie werden Security Findings priorisiert? Jede Antwort sollte auf Richtlinie, Systemprotokoll, aktuelles Beispiel und verantwortliche Person verweisen. Lassen Sie den Ablauf von einer Person testen, die ihn sonst nicht ausführt.
Stimmen Sie Roadmap, Budgets, Kundenzusagen und technische Schulden ab. Eine Roadmap mit Produktfeatures, aber ohne Security-, Plattform- oder Lifecycle-Arbeit löst Fragen aus. Trennen Sie zugesagte Kundenarbeit, interne Prioritäten und optionale Ideen. Dokumentieren Sie Abhängigkeiten und Entscheidungsregeln bei Zielkonflikten. Käufer wollen erkennen, wie das Management Einschränkungen in einen belastbaren Plan übersetzt.
Qualitätskontrolle vor Öffnung des Datenraums
Prüfen Sie Daten, Gesellschaftsnamen, Umgebungen und Definitionen in allen Artefakten. Architektur, Anbieterliste, Incident Log, Personalübersicht und Finanzunterlagen müssen dasselbe Unternehmen zum gleichen Stichtag beschreiben. Entfernen Sie veraltete Duplikate, bewahren Sie aber die Historie. Kennzeichnen Sie Entwürfe. Wenn eine Richtlinie quartalsweise Zugriffsreviews nennt, müssen entsprechende Protokolle für die aufgeführten Systeme vorhanden sein.
Führen Sie während der Due Diligence ein Fragenregister. Jede Frage erhält eine verantwortliche Person, Termin, Quellunterlagen und Freigabe. Korrekturen werden sichtbar dokumentiert. Eine kontrollierte Korrektur schafft Vertrauen; ein lautlos ersetztes Dokument kann Zweifel am gesamten Datensatz wecken. Trennen Sie Fakten, rechtliche Interpretation und Managementprognose und leiten Sie sie an die richtige Fachperson.
Die Prüfung vorbereiten, ohne den Betrieb zu blockieren
Beginnen Sie bei Systemen, die Kunden, Umsatz, Rechte oder Kontinuität betreffen. Bestimmen Sie eine Koordination, lassen Sie Fachverantwortung im Team und nutzen Sie einen versionierten Index. Frühzeitiges Sammeln spart laut KMU-Portal Zeit und Kosten. Wahlloses Hochladen erzeugt dagegen Lärm und Offenlegungsrisiken.
Prüfen Sie intern: Was ist kritisch, was kann ausfallen, wer reagiert, welche Rechte werden übertragen, welche Zusagen begrenzen Änderungen und welche Investitionen sind geplant? Stimmen Sie Antworten mit Finanz- und Verkaufsunterlagen ab. Der Leitfaden zum Verkauf einer IT-Firma in der Schweiz ordnet die technische Vorbereitung in den Exit-Prozess ein.
Der technische Vorbereitungssatz ist für eine kontrollierte Käuferprüfung bereit, wenn jede wesentliche Aussage einen aktuellen Beleg, eine verantwortliche Person, ein Testdatum, dokumentierte Ausnahmen und eine freigegebene Offenlegungsstufe besitzt.
Fragen von Inhabern
Was ist technische Due Diligence?
Sie ist eine strukturierte Prüfung von Technologie, Betrieb, Sicherheit, Rechten, Personen und bekannten Risiken im Rahmen einer Transaktion. Der genaue Umfang hängt vom Unternehmen und der geplanten Struktur ab.
Wann sollte ein Verkäufer beginnen?
Vor einer breiten Käuferansprache. So bleibt Zeit, kritische Prozesse zu testen, Widersprüche zu korrigieren und sensible Offenlegung zu steuern.
Was gehört in den technischen Datenraum?
Ein strukturierter Index kann Architektur, Inventare, Release-Belege, Security- und Recovery-Nachweise, Datenschutz, Lizenzen, Rechte, Personen und technische Schulden umfassen. Zugriffe sollten stufenweise erfolgen.
Muss jedes Problem vor dem Verkauf gelöst sein?
Nein. Priorisieren Sie nach Kunden-, Kontinuitäts-, Rechts- und Transaktionswirkung. Dokumentieren Sie verbleibende Ausnahmen und Massnahmen korrekt.
Ist die Checkliste eine Rechts- oder Security-Garantie?
Nein. Sie dient der Vorbereitung. Sachverhaltsabhängige Fragen gehören zu qualifizierten Schweizer Fachpersonen.
Quellen und weiterführende Informationen
Continuum Redaktion
Recherchen und praktische Arbeitshilfen zur Orientierung für Inhaber. Continuum bietet eine unabhängige erste Perspektive und auf Wunsch Kontakte. Transaktionsbezogene Rechts-, Steuer- und Bewertungsfragen gehören zu qualifizierten Fachpersonen.
Ihr nächster Schritt