Vor einem Kauf, einer Beteiligung oder einer Nachfolge steht die Frage, was die Software wirklich trägt. Die technische Due Diligence beantwortet sie mit Belegen statt mit Eindrücken. Dieser Beitrag zeigt, was geprüft wird, welche Befunde den Preis bewegen und worin der Unterschied zum Systemaudit liegt.
Eine technische Due Diligence prüft ein fremdes System im Auftrag dessen, der es kaufen oder sich daran beteiligen möchte. Sie beschreibt nicht, wie das System gemeint war, sondern was tatsächlich vorliegt. Der Bericht muss einer Verhandlung standhalten, deshalb zählt bei jedem Punkt der Beleg und nicht der Eindruck.
Geprüft werden sechs Felder:
In fast jedem Mandat steht am Anfang dieselbe Frage: Was steckt eigentlich drin? Eine Softwarekomponentenliste, kurz SBOM, beantwortet sie. Sie führt die verwendeten Bausteine mit Version und Lizenzangabe auf. Das Bundesamt für Sicherheit in der Informationstechnik beschreibt in der Technischen Richtlinie TR-03183-2, wie eine solche Liste aufgebaut sein soll, und nennt dafür die Formate SPDX und CycloneDX. Die Richtlinie ist ausdrücklich eine Hilfestellung ohne verbindlichen Charakter, sie gibt aber einen brauchbaren Maßstab.
Fehlt die Liste, fehlt mehr als ein Dokument. Ohne sie lässt sich weder sagen, welche bekannten Schwachstellen im Produkt stecken, noch welche Lizenzpflichten daran hängen. Beides ist im Zweifel eine Frage von Tagen, nicht von Monaten. Ein Verkäufer, der die Liste nicht liefern kann, verhandelt deshalb ab diesem Punkt aus einer schwächeren Position.
Für die Lizenzseite gibt es einen eigenen Maßstab. ISO/IEC 5230 beschreibt, wie ein Programm zur Einhaltung von Open-Source-Lizenzen aussieht. ISO/IEC 18974 ist das Gegenstück für die Sicherheitsseite. Beide stammen aus dem OpenChain-Projekt der Linux Foundation, das seit 2016 an dieser Frage arbeitet. Wer keines von beiden vorweisen kann, hat damit noch kein Problem, aber auch keinen Nachweis.
Nicht jeder Befund verändert eine Bewertung. Preiswirksam wird ein Fund dann, wenn er nach der Übernahme Geld kostet, wenn eine Frist daran hängt oder wenn er den Weiterverkauf erschwert. Vier Muster tauchen dabei immer wieder auf.
Der Cyber Resilience Act ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten für aktiv ausgenutzte Schwachstellen gelten ab dem 11. September 2026, die vollständigen Herstellerpflichten ab dem 11. Dezember 2027. Erfasst sind Produkte mit digitalen Elementen, also auch reine Software. Nicht kommerzielle Open-Source-Produkte sind ausgenommen. Wer ein Produkt kauft, kauft diese Pflichten mit. Artikel 64 der Verordnung sieht für Verstöße gegen die grundlegenden Anforderungen Geldbußen bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist.
Das ist kein Grund zur Aufregung, aber ein Grund zum Rechnen. Ein Produkt ohne Komponentenliste, ohne geordnetes Schwachstellenmanagement und ohne Meldeweg braucht bis Ende 2027 Arbeit. Diese Arbeit gehört in die Bewertung und nicht in die Zeit nach der Unterschrift.
Richtet sich das Produkt an Verbraucher, kommt das Barrierefreiheitsstärkungsgesetz dazu. Es gilt seit dem 28. Juni 2025 und erfasst unter anderem Software, E-Books und den elektronischen Geschäftsverkehr. Die Ausnahme für Kleinstunternehmen greift nur bei Dienstleistungen und nicht bei Produkten. Kleinstunternehmen sind dabei Unternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz oder Jahresbilanzsumme. Verstöße gegen die Barrierefreiheitsanforderungen können nach § 37 mit bis zu 100.000 Euro geahndet werden. Für bestehende Dienstleistungsverträge läuft eine Übergangsfrist bis zum 27. Juni 2030.
In der Praxis ist das ein häufiger Fund. Eine Anwendung, die für Verbraucher gedacht ist und die Anforderungen nicht erfüllt, hat einen Nachrüstbedarf mit bekanntem Umfang. Ein solcher Umfang lässt sich beziffern und damit verhandeln.
Ein fremder Baustein unter einer starken Copyleft-Lizenz kann, je nachdem wie er eingebunden ist, Pflichten auf den eigenen Quelltext ausdehnen. Ob das im konkreten Fall so ist, ergibt sich aus dem Lizenztext und aus der Art der Einbindung. Genau deshalb gehört die Lizenzprüfung an den Anfang. Der Fund selbst kostet nichts, der Umbau danach schon.
Ein System, das nur bei einem Anbieter läuft, ist teurer im Betrieb und schwerer weiter zu verkaufen. Der Data Act der Europäischen Union gilt seit dem 12. September 2025 und setzt einen Rahmen dafür, dass Kunden zwischen Anbietern von Datenverarbeitungsdiensten wechseln können. Das erleichtert den Wechsel, es erspart ihn nicht. Wer die Abhängigkeit erst nach dem Kauf entdeckt, zahlt sie zweimal.
Verarbeitet ein Dienstleister personenbezogene Daten im Auftrag, verlangt Artikel 28 DSGVO einen Vertrag in Schrift- oder elektronischer Form mit festem Inhalt: Gegenstand und Dauer, Art und Zweck der Verarbeitung, Kategorien der Daten und betroffenen Personen sowie die Pflichten des Auftragsverarbeiters. Unterauftragsverarbeiter dürfen nur mit Genehmigung eingesetzt werden und müssen dieselben Pflichten übernehmen. Fehlt ein Glied in dieser Kette, ist das kein technischer Befund, aber einer, der in die Verhandlung gehört.
Die technische Due Diligence steht bei uns in der Gruppe Analyse, neben dem Systemaudit. Beide sehen sich Systeme an. Sie haben aber verschiedene Adressaten, und daraus folgt alles Weitere.
Wer beides verwechselt, bekommt entweder einen Plan, den niemand braucht, oder einen Bericht, der in der Verhandlung nicht trägt. Wie ein Audit im Einzelnen abläuft, steht im Beitrag Systemaudit: Ablauf, Dauer und Kosten.
Der Zuschnitt bestimmt den Aufwand, deshalb steht am Anfang die Abgrenzung. Danach sichten wir Unterlagen, Umgebung und, soweit der Zugang es zulässt, den Quelltext. Wir sprechen mit den Menschen, die das System betreiben und weiterentwickeln. Jeden Befund ordnen wir nach Wirkung und Aufwand und schreiben dazu, was er im Fall der Übernahme kostet. Der Preis für die Prüfung steht vor Beginn fest.
Berührt die Prüfung auch die Frage, wie angreifbar das System von außen ist, grenzen wir ab, wo ein eigener Penetrationstest tiefer ansetzen müsste. Eine Due Diligence liest und bewertet. Sie greift nicht an.
Wir prüfen nicht nur für andere. ORDO erwirbt, entwickelt und betreibt selbst Unternehmen und digitale Produkte. Ein fremdes System sehen wir deshalb mit einer einfachen Frage an: Würden wir es selbst betreiben wollen. Was wir dabei gelernt haben, steht im Portfolio.
Eine technische Due Diligence ersetzt weder die kaufmännische noch die rechtliche Prüfung. Sie liefert den technischen Teil und sie liefert ihn belegt. Wer früh prüft, verhandelt über Zahlen statt über Eindrücke. Die übrigen Positionen von der Analyse bis zum Betrieb stehen offen auf der Seite Leistungen. Wenn eine Transaktion ansteht, genügt ein kurzes Erstgespräch.
Antwort in zwei Werktagen, mit einem konkreten Vorschlag zum weiteren Vorgehen.