1. Einleitung
Bei einer Akquisition wechseln nicht nur Verträge, Mitarbeitende und Produkte den Besitzer, sondern auch eine gewachsene IT-Landschaft – inklusive Altlasten. Genau diese Altlasten entscheiden später oft darüber, ob der Betrieb stabil läuft, Daten geschützt sind und die Integration planbar bleibt.
IT-Due-Diligence wird im Deal-Alltag dennoch häufig unterschätzt: Dokumente wirken vollständig, Systeme laufen „irgendwie“, und kritische Abhängigkeiten sind nicht sichtbar. Die Überraschung kommt dann nach dem Signing: unerwartete Lizenzkosten, Sicherheitslücken, fehlende Notfallkonzepte oder Anwendungen, die niemand mehr sauber betreuen kann.
Eine IT-Due-Diligence schafft hier Klarheit, bevor Sie verbindliche Entscheidungen treffen. Ziel ist nicht „perfekte IT“, sondern ein realistisches Bild von Risiken, Kosten, Handlungsbedarf und Integrationsaufwand.
2. Kurzantwort
IT-Due-Diligence ist die strukturierte Prüfung der IT eines Zielunternehmens vor einer Akquisition. Sie bewertet Risiken, Kosten, Verträge, Sicherheitslage und Integrationsfähigkeit entlang der geschäftskritischen Systeme. Das Ergebnis ist eine belastbare Entscheidungsgrundlage für Kaufpreis, Maßnahmenplan und Integration.
3. Warum das wichtig ist
IT ist im M&A-Prozess ein „stiller Deal-Treiber“: Sie beeinflusst, wie schnell Synergien realisiert werden, ob Prozesse nach dem Closing stabil bleiben und wie hoch die Folgekosten ausfallen. Wenn zentrale Systeme veraltet sind, Schnittstellen nicht dokumentiert wurden oder Berechtigungen über Jahre „mitgewachsen“ sind, steigt das Risiko für Ausfälle und Sicherheitsvorfälle deutlich.
Hinzu kommt der Zeitfaktor: Wenn Sie erst nach der Übernahme feststellen, dass Kernanwendungen nicht integrierbar sind oder Cloud-Verträge die Nutzung einschränken, geraten Zeitpläne ins Rutschen. Das kostet nicht nur Geld, sondern bindet Ressourcen auf Management- und IT-Ebene.
Wert und Risiko liegen oft in Details
Typische Kostentreiber sind nicht geplante Lizenznachkäufe, technische Schulden (End-of-Life-Software, fehlende Wartung), externe Abhängigkeiten sowie Sicherheits- und Compliance-Nacharbeiten. Eine gute IT-Due-Diligence macht diese Punkte früh sichtbar, damit Sie sauber verhandeln und realistisch integrieren können.
4. Schritt für Schritt
- Zielbild und Fokus festlegen: Definieren Sie, welche Systeme und Prozesse für den Deal kritisch sind (z.B. ERP, CRM, Produktions-IT, Datenplattform, Identity).
- Scope und Tiefe abstimmen: Legen Sie fest, welche Bereiche geprüft werden (Infrastruktur, Anwendungen, Security, Verträge, Organisation) und wie tief (Red Flags vs. Deep Dive).
- Informationsanforderung (Request List) erstellen: Fordern Sie zielgerichtet Dokumente an: Architektur, Asset-Listen, Verträge, Lizenzen, Security-Policies, Betriebsprozesse, Notfallkonzepte.
- Dokumente prüfen und Lücken markieren: Identifizieren Sie fehlende Nachweise, veraltete Dokumentation und Widersprüche (z.B. Lizenzumfang vs. tatsächliche Nutzung).
- Interviews durchführen: Sprechen Sie mit IT-Leitung, Security-Verantwortlichen und Schlüsselrollen zu Betrieb, Abhängigkeiten, Incidents, Roadmap und externen Dienstleistern.
- Technik- und Risikoanalyse konsolidieren: Bewerten Sie Reifegrad, technische Schulden, Sicherheitslage, Vertragsrisiken und Integrationsaufwand entlang der „Kronjuwelen“.
- Ergebnis in Deal-Logik übersetzen: Liefern Sie Red Flags, Kosten-/Aufwandsabschätzung, Maßnahmenplan (Day-1/Day-30/Day-100) und klare Entscheidungsempfehlungen.
5. Checkliste
- Aktuelle IT-Architekturübersicht inkl. Cloud/On-Prem und Datenflüssen liegt vor.
- Inventar: Systeme, Anwendungen, Schnittstellen, Endpunkte und Zuständigkeiten sind nachvollziehbar.
- Lifecycle-Status: End-of-Life/End-of-Support-Komponenten sind identifiziert und bewertet.
- Identity & Access: Rollen, Admin-Modelle, MFA-Status und Berechtigungslogik sind dokumentiert.
- Sicherheitslage: EDR/AV, Patch-Stand, Logging/Monitoring und Incident-Prozesse sind bewertet.
- Backup/Restore: Backup-Strategie, Wiederherstellungszeiten und letzte Restore-Tests sind bekannt.
- Vertrags- und Lizenzlage: Lizenzen, Laufzeiten, Kündigungsfristen, Nutzungsrechte sind geprüft.
- Third Parties: Kritische Dienstleister, Abhängigkeiten und SLA/Exit-Regelungen sind erfasst.
- Eigenentwicklungen: Code-/Betriebsverantwortung, Dokumentation, CI/CD und Bus-Faktor sind bewertet.
- Integrationsfähigkeit: Zielarchitektur, Migrationspfade und grober Umsetzungsplan sind skizziert.
6. Häufige Fehler
- Fehler: Nur „Red Flags“ ohne Kontext.
Korrektur: Red Flags immer mit Impact, Wahrscheinlichkeit und Kosten-/Zeitfolgen einordnen. - Fehler: Fokus nur auf Infrastruktur.
Korrektur: Anwendungen, Datenflüsse, Verträge, Organisation und Betriebsprozesse gleichwertig prüfen. - Fehler: Lizenz- und Vertragsprüfung wird zu spät gemacht.
Korrektur: Laufzeiten, Nutzungsrechte, Audit-Risiken und Exit-Klauseln früh priorisieren. - Fehler: Abhängigkeiten von Schlüsselpersonen werden übersehen.
Korrektur: Bus-Faktor, Wissensträger, externe Dienstleister und Übergabepläne explizit bewerten. - Fehler: Security wird als „Tool-Frage“ behandelt.
Korrektur: Detektion, Reaktion, Berechtigungen, Patch-Disziplin und Notfallfähigkeit als Kette betrachten. - Fehler: Ergebnis bleibt technisch und nicht verhandlungsfähig.
Korrektur: Findings in Deal-Sprache übersetzen: Kaufpreis-/SPA-Hebel, Maßnahmenplan, Integrationsaufwand.
7. Praxisbeispiel
Ein Käufer plante die Übernahme eines Software-nahen Dienstleisters und erwartete eine „moderne Cloud-IT“. In der IT-Due-Diligence zeigte sich, dass zwar mehrere Systeme in der Cloud liefen, aber zentrale Identitäten und Berechtigungen historisch gewachsen und kaum nachvollziehbar waren. Zudem existierten Eigenentwicklungen ohne klare Code-Ownership und ohne belastbare Dokumentation. In den Verträgen fanden sich Laufzeiten und Kündigungsfristen, die eine schnelle Konsolidierung verhindert hätten. Backup und Restore waren zwar eingerichtet, aber es gab keinen aktuellen Nachweis eines Restore-Tests. Im Ergebnis wurde ein Maßnahmenplan definiert, der die Day-1-Stabilität absicherte und die kritischen Punkte für die ersten 100 Tage priorisierte. Parallel konnten konkrete Aufwände in die Verhandlung eingebracht werden, statt sie erst nach dem Closing „überraschend“ zu bezahlen.
Was ist das konkrete Ziel einer IT-Due-Diligence?
Sie soll transparent machen, welche IT-Risiken, Folgekosten und Integrationshürden im Zielunternehmen stecken. Gleichzeitig zeigt sie, welche Systeme geschäftskritisch sind und wie belastbar Betrieb, Sicherheit und Verträge wirklich sind. Das Ergebnis dient als Grundlage für Kaufpreis, Maßnahmenplan und Integration.
Welche Unterlagen sollte das Target bereitstellen?
Typisch sind Architektur- und Systemübersichten, Asset-Listen, Lizenz- und Vertragsunterlagen, Security- und Backup-Konzepte, Betriebsprozesse sowie Informationen zu Dienstleistern. Wichtig ist auch eine Übersicht über Schnittstellen, Datenflüsse und Eigenentwicklungen. Fehlende oder veraltete Dokumente sind bereits ein Signal für zusätzlichen Klärungsbedarf.
Wie lange dauert eine IT-Due-Diligence?
Das hängt von Scope und Verfügbarkeit der Informationen ab. Eine Red-Flag-Prüfung kann in kurzer Zeit erste Deal-Stopper zeigen, ein Deep Dive benötigt mehr Interviews und Nachweise. Entscheidend ist, dass Ergebnis und Maßnahmenplan rechtzeitig für Verhandlung und Integration vorliegen.
Was sind typische „Red Flags“ in der IT?
Häufig sind das End-of-Life-Systeme, fehlende Restore-Tests, unklare Admin-Berechtigungen, nicht dokumentierte Schnittstellen und starke Abhängigkeit von Einzelpersonen oder Dienstleistern. Auch unklare Lizenzrechte, auslaufende Verträge oder fehlendes Monitoring können erhebliche Folgekosten erzeugen. Red Flags sollten immer mit Impact und Aufwand bewertet werden.
Wie bewertet man Cloud- und SaaS-Verträge im Deal?
Wichtig sind Nutzungsrechte, Mandantenfähigkeit, Datenstandorte, Kündigungsfristen, Preismodelle und Exit-Regelungen. Prüfen Sie außerdem, ob Abhängigkeiten von Integrationen, APIs oder bestimmten Identitätsanbietern bestehen. Ziel ist, Migrations- und Konsolidierungsrisiken früh zu erkennen.
Sollte IT-Security Teil der IT-Due-Diligence sein?
Ja, weil Sicherheitsrisiken direkt in Ausfallzeiten, Datenverlust und Reputationsschäden münden können. Relevant sind u.a. Patch-Disziplin, Identity & Access, Logging/Detektion, Incident-Prozesse und Notfallfähigkeit. Die Prüfung sollte dabei risikobasiert und entlang der kritischen Systeme erfolgen.
Wie hilft das Ergebnis bei Kaufpreis und Integration?
Sie erhalten eine priorisierte Liste von Risiken und Maßnahmen inklusive Aufwandsschätzung, die in die Verhandlung eingebracht werden kann. Gleichzeitig entsteht ein realistischer Integrationsfahrplan (Day-1/Day-30/Day-100). So vermeiden Sie, dass versteckte IT-Kosten erst nach dem Closing sichtbar werden.
9. Fazit
IT-Due-Diligence bringt Transparenz in einen Bereich, der im Deal oft zu spät betrachtet wird. Wenn Sie Risiken, Kosten und Integrationshürden vorab sauber bewerten, vermeiden Sie teure Überraschungen nach der Unterschrift. Lassen Sie Ihre IT-Due-Diligence vor dem Unternehmenskauf strukturiert begleiten – Kontakt: info@optimit.de