Tijdens een overname, investeringsronde of vendor audit onderzoekt een technische due diligence de daadwerkelijke staat van software. Kopers kijken voorbij verkoopverhalen om broncode, externe libraries, architectuurknelpunten en teamprocessen te controleren op verborgen risico's die de bedrijfswaardering verlagen of na de transactie tot onvoorziene kosten leiden.
Hoe het Due Diligence-proces Verloopt
Een technisch onderzoek duurt doorgaans twee tot vier weken en volgt vier vaste fasen:
- Data room en documentbeoordeling: De koper vraagt architectuurdiagrammen, infrastructuuroverzichten, SOC 2- of ISO-certificaten, incidentenlogs, herstelplannen en teamorganigrammen op.
- Geautomatiseerde statische analyse en scans: Auditoren draaien scans over repository-kopieën om open-source licenties te indexeren, kwetsbaarheden (CVE's) te detecteren, gelekte API-tokens in de git-geschiedenis op te sporen en de codecomplexiteit te meten.
- Interviews met technisch leiderschap: Gesprekken met CTO's, lead architects en engineering managers over systeemknelpunten, releasefrequenties, sleutelfiguurafhankelijkheid en clouduitgaven.
- Code walkthroughs en detailanalyse: Auditoren bekijken concrete pull requests, kerndomeinlogica, data-toegangspatronen en database-migraties om het werkelijke kwaliteitsniveau vast te stellen.
De Belangrijkste Auditdomeinen
Auditoren beoordelen technische activa binnen vijf categorieën om operationele stabiliteit en toekomstige onderhoudskosten in te schatten.
1. Kwaliteit en Onderhoudbaarheid van de Codebase
Auditoren inspecteren de broncode om toekomstige ontwikkelingssnelheid en onderhoudskosten in te schatten. Ze willen weten of nieuwe ontwikkelaars snel en veilig aanpassingen kunnen doorvoeren.
- Testdekking en testkwaliteit: Er wordt gecontroleerd of geautomatiseerde tests daadwerkelijk bedrijfsregels en integraties valideren of enkel simpele mocks bevatten. Een betrouwbare suite in CI geeft kopers de zekerheid dat wijzigingen geen onverwachte productiefouten veroorzaken.
- Actuele frameworks en runtimes: Gebruik van ondersteunde versies (.NET 10, actuele LTS Node) toont structureel beheer. Verouderde runtimes betekenen directe technische schuld die de koper na afronding van de deal moet financieren.
- Dode code en achtergebleven modules: Repositories met uitgecommentarieerde codeblokken, verlaten feature flags en ongebruikte microservices wijzen op gebrekkige discipline in het ontwikkelproces.
- Code churn en knelpunten: Hoge wijzigingsfrequenties geconcentreerd in enkele grote klassen tonen een te hechte koppeling waarbij ontwikkelaars elkaar voortdurend in de weg zitten.
2. Open-Source Licenties en de Software Bill of Materials (SBOM)
Externe afhankelijkheden vormen een belangrijk juridisch en operationeel risico. Juridische teams letten scherp op mogelijke besmetting van intellectueel eigendom.
| Auditonderdeel | Wat Auditoren Verwachten | Rode Vlag |
|---|---|---|
| Copyleft Licenties | Permissieve licenties (MIT, Apache 2.0, BSD) voor directe en transitieve libraries | GPL-3.0 of AGPL componenten gekoppeld aan propriëtaire software |
| Kwetsbaarheden (CVE's) | Geautomatiseerde updates (Dependabot/Renovate) en snelle patchcycli | Kritieke ongepatchte kwetsbaarheden ouder dan 60 dagen in productie |
| SBOM Volledigheid | Machinaal leesbare CycloneDX- of SPDX-overzichten per release | Niet-geversioneerde binaire bestanden direct gecommit in git |
| Geheimen in Git | Geautomatiseerde secret scanners en managed identities (Azure Key Vault, Workload Identity) | Productieconnectiestrings, API-sleutels of certificaten in de commit-geschiedenis |
| Databaseschema | Geversioneerde migratiescripts (Flyway, EF Core migrations) | Handmatige schema-aanpassingen direct op productiedatabases zonder versiebeheer |
3. Architectuur, Schaalbaarheid en Single Points of Failure
Auditoren vergelijken de systeemarchitectuur met de verwachte groeicijfers na de overname. Een structuur die werkt voor 1.000 gebruikers kan bezwijken wanneer het transactievolume door verkoopactiviteiten verdrievoudigt.
- Gedeelde database-knelpunten: Meerdere services die zonder domeingrenzen naar dezelfde tabellen lezen en schrijven, veroorzaken database-locks en complexe deployments.
- Synchrone aanroepketens: Lange ketens van HTTP-aanroepen tussen interne services verhogen de latency en maken het gehele proces kwetsbaar voor het uitvallen van één schakel.
- Single points of failure: Achtergrondtaken of cache-lagen die draaien op individuele servers zonder automatische failover of replicatie.
- Stateful applicatielagen: Websessies opgeslagen in lokaal servergeheugen in plaats van gedistribueerde caches, waardoor horizontaal schalen achter een load balancer niet mogelijk is.
4. Cloudinfrastructuur, Kostenbeheersing en Disaster Recovery
Hostingomgevingen worden geëvalueerd op kostenefficiëntie en herstelbaarheid bij calamiteiten.
- Infrastructure as Code (IaC): Omgevingen die declaratief zijn vastgelegd in Terraform of Bicep garanderen dat infrastructuur betrouwbaar opnieuw kan worden opgebouwd in een nieuwe cloudregio of tenant.
- Kosten per gebruiker of transactie: Auditoren toetsen of hostingkosten lineair blijven stijgen of dalen naarmate het volume toeneemt.
- Bewezen herstelprocedures: Gedocumenteerde Recovery Point Objectives (RPO) en Recovery Time Objectives (RTO), onderbouwd met geteste herstelprocedures in plaats van niet-gevalideerde back-upbestanden.
5. Teamstructuur, Governance en Sleutelfiguren
De werkelijke continuïteit van software ligt bij het team. Auditoren analyseren commit-statistieken om te controleren hoe kennis is verdeeld over de organisatie.
Een repository waarin 80% van de code door één enkele ontwikkelaar is geschreven, vormt een aanzienlijk risico. Bij vertrek van deze persoon na een overname verdwijnt cruciale systeeminzicht. Goed bijgehouden Architecture Decision Records (ADR's), verplichte code reviews en gedeeld eigenaarschap tonen aan dat het team de applicatie zelfstandig kan doorontwikkelen.
Een 30-Dagen Voorbereidingsplan voor je Codebase
Door repositories voor te bereiden voordat de auditoren starten, voorkom je dealvertragingen en discussies over waardevermindering.
Week 1: Supply Chain en Secret Scans
Genereer een actuele SBOM met CycloneDX of Trivy. Scan alle repositories met Gitleaks of TruffleHog om blootgestelde tokens of wachtwoorden in de geschiedenis op te sporen en in te trekken.
Week 2: Architectuur en Datastromen
Stel C4 context- en containerdiagrammen op die systeemgrenzen, externe koppelingen en data-opslaglocaties weergeven. Documenteer hoe klant- en betaalgegevens door het systeem stromen.
Week 3: Repository-Opschoning en Teststabiliteit
Verwijder verouderde git-branches, archiveer ongebruikte experimentele repositories, los instabiele tests op die af en toe falen in CI en ruim dode code op.
Week 4: Technische Schuld en Beheeroverzicht
Breng bekende technische beperkingen in kaart met realistische inschattingen voor herstel. Een open en geprioriteerd overzicht van technische schuld toont professionaliteit aan auditoren.
Onafhankelijke Pre-Investment Audits
Door voorafgaand aan een transactie of investeringsronde een interne gezondheidscheck uit te voeren, pak je risico's op je eigen tempo aan.
Onze Software Architecture Assessment biedt een objectieve evaluatie van broncodekwaliteit, cloudarchitectuur, beveiliging en opleveringsprocessen. We leveren concrete bevindingen met een geprioriteerd verbeterplan. Bekijk ons voorbeeldrapport om de opzet en diepgang van een assessment te bekijken.