IT-Projekte & technische Due Diligence
Eine technische Due Diligence ist keine pauschale Qualitätsprüfung „der IT“. Aussagekraft entsteht erst durch einen definierten Untersuchungsgegenstand: Produkt, Quellstand, Architektur, Betriebsmodell, Daten, Sicherheitspraktiken, Abhängigkeiten und relevante technische Risiken müssen zum Transaktions- oder Entscheidungszweck passen.
Kurzantwort
Der Due-Diligence-Scope wird risikoorientiert festgelegt. Zuerst werden Produktgrenzen, Systemstand und kritische technische Annahmen dokumentiert. Danach werden Evidenzklassen, Stichproben und vertiefende Prüfungen ausgewählt. Nicht untersuchte Bereiche werden ausdrücklich benannt, damit aus einer Teilprüfung keine Vollabdeckung abgeleitet wird.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Untersuchungszweck und technische Entscheidungsfrage klären
Der gleiche Softwarebestand kann für einen Unternehmenskauf, eine Investition, eine Lieferantenbewertung oder eine interne Reifegradentscheidung unterschiedlich untersucht werden. Der Zweck bestimmt, welche technischen Risiken wesentlich sind.
Eine Begutachtung sollte deshalb nicht mit einer generischen Checkliste beginnen. Zuerst werden die technischen Annahmen identifiziert, die für die konkrete Entscheidung relevant sind: Skalierbarkeit, Wartbarkeit, Sicherheit, Lieferfähigkeit, IP-/Provenienznachweise oder betriebliche Abhängigkeiten.
2. Produkt- und Systemgrenzen eindeutig festlegen
Viele Produkte bestehen aus mehreren Repositories, SaaS-Diensten, mobilen Clients, Datenpipelines und externen Plattformen. Der Scope dokumentiert, welche Komponenten einbezogen und welche nur als Abhängigkeit betrachtet werden.
Auch der Zeitbezug ist wesentlich. Ein aktueller Hauptbranch kann von dem tatsächlich verkauften oder produktiv eingesetzten Release abweichen. Aussagen werden deshalb an einen konkreten Stand oder klaren Stichtag gebunden.
3. Evidenzklassen und Zugriffstiefe bestimmen
Repository-Zugriff, Buildsysteme, Architekturunterlagen, Sicherheitsbefunde, Incident-Historie, Cloud-Konfiguration und Monitoring besitzen unterschiedliche Aussagekraft. Vor Beginn wird geklärt, welche Quellen direkt geprüft und welche nur durch bereitgestellte Exporte beurteilt werden können.
Fehlender Zugriff ist kein automatischer Negativbefund, aber eine Begrenzung. Der Bericht sollte kenntlich machen, ob eine Aussage auf eigener technischer Prüfung, dokumentarischer Evidenz oder ungeprüfter Selbstauskunft beruht.
4. Softwarelieferkette und Entwicklungspraktiken untersuchen
Abhängigkeiten, Build-Prozess, Paketquellen, Secrets-Handling und Release-Provenienz können wesentliche technische Risiken darstellen. NIST SSDF und SLSA liefern hierfür strukturierende Referenzen, ohne dass jede Due Diligence eine formale Konformitätsprüfung sein muss.
Auch die Fähigkeit zur reproduzierbaren Weiterentwicklung ist relevant: Sind Build- und Deploymentschritte nachvollziehbar, existieren Tests, sind kritische Wissensinseln sichtbar und lassen sich Releases auf Quellstände zurückführen?
5. Architektur-, Betriebs- und Sicherheitsrisiken zusammenführen
Ein Risiko kann aus Architektur, Infrastruktur und Organisation gemeinsam entstehen. Beispielsweise kann ein technisch stabiler Dienst dennoch kritisch sein, wenn nur eine nicht dokumentierte manuelle Deploymentkette existiert oder eine zentrale Drittanbieterabhängigkeit keinen Ersatzpfad besitzt.
Die technische Bewertung beschreibt Ursache, betroffene Fähigkeit und vorhandene Gegenmaßnahmen. Wirtschaftliche Bewertung, Kaufpreis oder Transaktionsentscheidung bleiben davon getrennt.
6. Befundtiefe und Restunsicherheit transparent machen
Due-Diligence-Zeitfenster sind häufig begrenzt. Stichproben und risikoorientierte Vertiefungen sind deshalb legitim, müssen aber transparent beschrieben werden. Ein positives Ergebnis in einer Stichprobe darf nicht als vollständige Prüfung aller Repositories ausgegeben werden.
Offene Punkte, nicht bereitgestellte Evidenz und nicht reproduzierbare Befunde werden als Restunsicherheit dokumentiert. Dadurch kann die technische Entscheidungsebene erkennen, welche Aussagen belastbar und welche nur vorläufig sind.
Bei daten- oder KI-intensiven Produkten sollte zusätzlich geklärt werden, ob zentrale Modelle, Trainingsdaten, Drittanbieter-APIs oder proprietäre Datenpipelines zum Wertversprechen gehören. Dann kann der technische Scope um Reproduzierbarkeit, Datenprovenienz, Modellabhängigkeiten und Betriebsgrenzen erweitert werden, ohne die Prüfung in eine allgemeine KI-Compliance-Bewertung umzudeuten.
Die Priorisierung kann als Risiko-Evidenz-Matrix dokumentiert werden: hoher potenzieller Einfluss bei schwacher Evidenz erhält typischerweise höhere Vertiefungspriorität als ein gut belegter, begrenzter technischer Punkt. Diese Methode macht transparent, warum bestimmte Bereiche intensiver untersucht wurden als andere.
Neben technischen Risiken kann die Nachweisbarkeit selbst ein Befund sein. Wenn kritische Releases, Datenherkünfte oder Berechtigungsmodelle nur durch mündliche Erläuterung, nicht aber durch technische Artefakte belegt werden können, wird diese Evidenzlücke separat ausgewiesen. Sie ist nicht gleichbedeutend mit einem technischen Fehler, beeinflusst aber die belastbare Reichweite der Due-Diligence-Aussage.
Kann eine technische Due Diligence „keine Risiken“ bestätigen?
Nein. Jede technische Prüfung ist durch Scope, Zeitpunkt, verfügbare Evidenz und Prüftiefe begrenzt.
Sie kann festgestellte Risiken, geprüfte Bereiche und nicht erkannte Auffälligkeiten in diesen Bereichen dokumentieren.
Eine absolute Risikofreiheit oder Vollständigkeit lässt sich daraus nicht seriös ableiten.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Sind Zweck, Stichtag und Produktgrenzen der Due Diligence dokumentiert?
- Sind kritische technische Annahmen und Risiken vor der Vertiefung priorisiert?
- Ist je Befund erkennbar, ob er auf eigener Prüfung, Dokumentenprüfung oder Selbstauskunft beruht?
- Sind Softwarelieferkette, Build- und Release-Prozess angemessen berücksichtigt?
- Sind Architektur-, Betriebs- und Sicherheitsabhängigkeiten zusammen betrachtet?
- Sind Stichprobenumfang und nicht untersuchte Bereiche ausdrücklich benannt?
- Sind technische Befunde von wirtschaftlicher und rechtlicher Transaktionsbewertung getrennt?
Konstruiertes Beispiel
Bei einer Softwareplattform werden drei von zwölf Repositories risikoorientiert vertieft, weil sie Authentisierung, Abrechnung und Deployment steuern. Der Bericht beschreibt diese Auswahl, prüft Build- und Release-Nachweise und kennzeichnet die übrigen Repositories als nicht im gleichen Detailgrad untersucht.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- NIST-Leitlinie NIST SP 800-218 SSDF Version 1.1 als strukturierender Rahmen für sichere Softwareentwicklung. Quelle öffnen.
- Technische Spezifikation SLSA v1.2 für Provenienz und Integrität der Softwarelieferkette. Quelle öffnen.
- Technischer Sicherheitsrahmen OWASP SAMM v2 zur strukturierten Betrachtung von Software-Sicherheitspraktiken. Quelle öffnen.
- Eigene Methodik Quellen und Methodik der Wissensplattform. Quelle öffnen.
Weiterführende Beiträge
- Architekturentscheidungen und technische Risiken
- Git-Historie und Software-Provenienz
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zum Themenbereich IT-Projekte & technische Due Diligence
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
Technische Due Diligence