Een technical due diligence vóór de deal begint niet bij technologie, maar bij het beslismoment. U staat op het punt een waardering af te geven, exclusiviteit te verlenen of een bieding te onderbouwen. Op dat moment is “de IT functioneert” geen voldoende antwoord. De vraag is of de digitale omgeving aantoonbaar ondersteunt wat in het investeringsmemorandum staat: groei, schaalbaarheid, continuïteit, compliance en beheersbare integratie.
Waarom technical due diligence vóór signing dealinformatie is
In een due diligence onderzoek overname is digitale afhankelijkheid zelden volledig zichtbaar in de eerste managementpresentatie. Kritieke applicaties draaien op leverancierscontracten die niet overdraagbaar zijn. Beheerdersrechten liggen bij één persoon. MFA is alleen actief voor kantoorapplicaties, niet voor beheerportalen. Back-ups bestaan, maar zijn nooit hersteld getest. Logging wordt verzameld, maar niemand beoordeelt afwijkingen. Dat zijn geen technische details. Dit zijn directe risico’s voor closing, waardering, garanties en post-deal kosten.
Het NCSC benadrukt dat cyberrisico, net als financieel en juridisch risico, op bestuursniveau thuishoort. Cybersecurity is geen geïsoleerde IT-functie, maar onderdeel van governance, risicomanagement, bedrijfscontinuïteit en besluitvorming. Voor een investeerder betekent dit dat technische due diligence niet alleen kijkt naar systemen, maar naar de mate waarin risico’s eigenaarschap, rapportage en opvolging hebben binnen de organisatie.
Het probleem met “voldoende security”
In veel transacties wordt security beoordeeld op basis van losse signalen. Er is een firewall. Er is antivirus. Er is een externe IT-partij. Er is ooit een pentest uitgevoerd. Los van de vraag of die informatie klopt, zegt dit weinig over de actuele risicopositie. Een technische due diligence checklist moet daarom niet vragen of maatregelen bestaan, maar of zij werken, actueel zijn en passen bij het risicoprofiel van de onderneming.
NIST beschrijft informatiebeveiliging als onderdeel van sound management: maatregelen moeten in verhouding staan tot risico, verantwoordelijkheden moeten expliciet zijn en beveiliging moet regelmatig worden beoordeeld en gemonitord. In dealtaal betekent dit dat u niet genoeg heeft aan beleidsdocumenten. U heeft toetsbaar bewijs nodig: actuele assetlijsten, IAM-inrichting, MFA-dekking, patchrapportages, logging, monitoring, incidentregistratie, back-upresultaten en hersteltests.
Daarom hoort technical due diligence vóór de deal een verschil te maken tussen verklaarde volwassenheid en aantoonbare volwassenheid. Een target kan zeggen dat er “geen incidenten” zijn geweest. Zonder logging, monitoring en incidentproces kan dat ook betekenen dat incidenten niet worden gezien. Een target kan zeggen dat “alles in de cloud staat”. Zonder inzicht in configuratie, toegangsbeheer, dataresidentie, contractuele exitrechten en leveranciersafhankelijkheid zegt cloudgebruik weinig over risico.
Wat er onder de oppervlakte speelt
De digitale waarde van een onderneming zit vaak in systemen die niet op de balans staan. Denk aan klantdata, broncode, configuraties, operationele data, API-koppelingen, automatisering, rapportages en historische datasets. Als deze assets onvoldoende beschermd, slecht gedocumenteerd of juridisch onduidelijk gepositioneerd zijn, raakt dat de waardering. U koopt dan niet alleen een onderneming, maar ook achterstallig onderhoud, integratierisico en mogelijk een compliancepositie die na closing direct moet worden hersteld.
Bij cyber en data privacy due diligence is het uitgangspunt dat de koper inzicht krijgt in IT-infrastructuur, technologie-inventaris, datamapping, cybersecuritymaatregelen, contractuele verplichtingen, eerdere incidenten, verzekeringen en verklaringen die de target aan klanten of toezichthouders heeft gedaan. Bevindingen kunnen leiden tot aanvullende garanties, pre-closing covenants, prijsaanpassingen of specifieke integratieacties.
Voor de deal is vooral relevant of risico’s materieel genoeg zijn om de transactievoorwaarden te beïnvloeden. Een verlopen end-of-life omgeving kan een capex-correctie vragen. Onvoldoende MFA op beheeraccounts kan een closing condition worden. Onvoldoende scheiding tussen koper, verkoper en carve-out omgeving kan de TSA-structuur beïnvloeden. Een ontbrekend incident response plan kan leiden tot aanvullende warranties of een separate escrow. Een onduidelijke verwerkersketen kan de privacy due diligence verdiepen.
Waarom regelgeving en governance vóór closing meetellen
Regelgeving zoals de Cyberbeveiligingswet (NIS2) is binnen Pravus geen zelfstandig implementatietraject, maar een due-diligence-risicogebied. Als de target binnen scope valt of contractueel aan keteneisen moet voldoen, kunnen tekortkomingen leiden tot extra kosten, beperkingen of vertraging.
Daarom toetsen we alleen wat voor de deal relevant is: scope, aantoonbare risicobeheersing, bestuurlijk eigenaarschap, incidentverplichtingen en de mogelijke impact op waardering, garanties en post-deal acties.
Van technische bevinding naar investeringsbesluit
De kracht van technical due diligence zit in prioritering. Niet elk IT-probleem is dealkritisch. Een verouderd ticketsysteem is meestal geen reden voor prijsaanpassing. Een niet-geteste back-up van een primair productiesysteem kan dat wel zijn. Een incompleet beleid is minder relevant dan een ontbrekende controle op privileged access. Een pentest zonder opvolging is geen assurance, maar bewijs dat risico’s bekend zijn en mogelijk niet zijn opgelost.
NIST CSF 2.0 biedt hiervoor een bruikbaar raamwerk. De functies Govern, Identify, Protect, Detect, Respond en Recover moeten niet na elkaar worden gezien, maar gelijktijdig. Govern staat centraal omdat het bepaalt hoe de organisatie de andere functies aanstuurt. Voor een dealteam is dat praktisch: u beoordeelt niet alleen bescherming, maar ook governance, detectie, response en herstelvermogen.
Voor closing moet die opgave financieel en operationeel worden gemaakt. Welke acties zijn nodig in de eerste 30, 60 en 100 dagen? Welke risico’s moeten vóór closing worden opgelost? Welke kosten horen in het model? Welke garanties zijn nodig? Welke afhankelijkheden moeten in de SPA, TSA of servicecontracten worden vastgelegd? Welke risico’s accepteert u bewust, en welke risico’s zijn niet acceptabel binnen de beoogde waardering?
Conclusie
Technical due diligence is geen poging om alle IT-risico’s weg te nemen. Dat kan niet en dat hoeft niet. De waarde zit in het feitelijk en toetsbaar maken van wat u koopt. U wilt weten welke digitale risico’s de waardering raken, welke maatregelen vóór closing nodig zijn en welke integratie-inspanning direct na closing uitvoerbaar moet zijn.
Wie vóór de deal alleen vraagt of “IT op orde is”, krijgt meestal een geruststellend antwoord. Wie vraagt naar IAM, MFA, logging, monitoring, back-ups, RTO, RPO, leveranciersafhankelijkheid, privacy governance en besluitvorming, krijgt dealinformatie. Dat verschil bepaalt of digitale risico’s later als verrassing opduiken, of vooraf onderdeel zijn van prijs, planning en governance.
