De vraag gaat over wijzigbaarheid, tests en concrete codeproblemen.
Codebase Audit →OXIAE / TECHNISCH ADVIES
Technical Due Diligence.
Onderzoek de technische basis vóór een investering of overname.
Bespreek jouw projectWelke technische beoordeling heb je nodig?
Je wilt het systeem inclusief architectuur en beheer beoordelen.
Software Audit →Een investering of overname vraagt om onderbouwde technische risico’s.
Technical Due Diligence (deze dienst)DE DIENST UITGELEGD
Wat onderzoekt technische due diligence bij een overname?
Technical due diligence toetst de technische aannames achter een investering of overname. Naast code en architectuur onderzoek ik afhankelijkheden van leveranciers en mensen, de manier van opleveren en de onderbouwing van schaalbaarheidsclaims. De uitkomst is een overzicht van aangetoonde risico’s, onbeantwoorde vragen en voorwaarden voor vervolgbesluiten. Het onderzoek is geen juridische beoordeling of garantie op toekomstige prestaties.
Wanneer is dit passend?
Een koper, investeerder of directie wil begrijpen welke technische verplichtingen en onzekerheden bij een platform horen.
Wanneer kies je beter anders?
Gaat de vraag uitsluitend over een module of een herstelbacklog? Dan is een codebase- of software-audit meestal gerichter. Juridische contract- en licentievraagstukken vragen passende aanvullende expertise.
PRAKTISCHE VERDIEPING
Technical due diligence maakt technische aannames controleerbaar
Technical due diligence onderzoekt de technische onderbouwing van een onderneming of product. Ik vertaal de onderzoeksvraag naar controleerbare onderwerpen: architectuur, ontwikkelproces, beveiliging, afhankelijkheden, beheer en continuïteit. Claims over schaalbaarheid of overdraagbaarheid worden waar mogelijk getoetst aan code, configuratie, documentatie en gesprekken met verantwoordelijken. [1]
De rapportage onderscheidt aangetoonde feiten, uitspraken van het team en onbevestigde aannames. Leveringshistorie kan tonen hoe wijzigingen en incidenten worden beheerd, maar wordt in context beoordeeld. Het resultaat benoemt technische aandachtspunten, onderzoekslimieten en vervolgvragen; financiële waardering en juridische beoordeling vragen hun eigen specialistische onderzoek. [2][3]
Vragen om vooraf te beantwoorden
- Welke technische claim is wezenlijk voor de voorgenomen beslissing?
- Welke toegang en bewijsstukken ontbreken om die claim te toetsen?
Maak de oplevering meetbaar
- Een bewijsregister per belangrijk onderwerp met bron, datum en onzekerheid.
- Een prioriteitenoverzicht met technische gevolgen en gerichte vervolgvragen.
Fictief claim- en bewijsregister — geen transactieonderzoek
Welke technische claim is bevestigd en welke vraag blijft open?
Een investeerder of koper krijgt vaak technische uitspraken, documenten en demonstraties met een verschillende bewijskracht. Dit zelfbedachte register laat zien hoe je een claim, onderzocht bewijs en resterende onzekerheid naast elkaar kunt zetten. Het beschrijft geen onderneming, waardering of advies over een echte investering.
Op een smal scherm kun je de tabel horizontaal verschuiven om alle kolommen te lezen.
| Technische claim | Beschikbaar voorbeeldbewijs | Wat is hiermee bevestigd? | Resterende onzekerheid | Passend vervolgonderzoek | Wie beoordeelt de vervolgstap? |
|---|---|---|---|---|---|
| Een andere ontwikkelaar kan het product overnemen en uitbrengen. | Een repository en bouwinstructie zijn beschikbaar. Alleen de huidige hoofdontwikkelaar heeft tot nu toe een uitrol gedemonstreerd. | De broncode en een beschreven bouwroute zijn beschikbaar; de demonstratie toont een uitrol door die ontwikkelaar. | Zelfstandige overdracht, beschikbare rechten, externe accounts en kennis buiten de documentatie zijn niet aangetoond. | Laat een aangewezen opvolger binnen afgesproken toegang een nieuwe testomgeving opzetten en een versie uitbrengen. Noteer ontbrekende stappen en benodigde bevoegdheden. | De technische onderzoeker rapporteert bevindingen; koper of investeerder beoordeelt de betekenis voor het besluit en benodigde voorwaarden. |
| Het platform kan de verwachte groei verwerken. | Een architectuurschema en een demonstratie met weinig gebruikers; geen representatieve belastingsmeting. | De beschreven componenten en het gedemonstreerde scenario zijn zichtbaar. | Capaciteit, knelpunten, externe limieten en herstel bij piekbelasting blijven onbevestigd. | Maak het gebruiksprofiel expliciet en spreek een representatieve capaciteitsproef af met meetgrenzen, omgeving en kosten van de proef. | Technische verantwoordelijken onderbouwen de proef; de beslisser bepaalt hoe de resterende onzekerheid wordt meegewogen. |
| De gegevens zijn na een storing herstelbaar. | Meldingen van back-uptaken, zonder volledige herstelproef of controle van de applicatie daarna. | De meldingen ondersteunen dat de genoemde taken zijn uitgevoerd. | Volledigheid, bruikbaarheid, benodigde configuratie en haalbare herstelduur zijn niet bevestigd. | Onderzoek een toegestane geïsoleerde herstelproef met representatieve gegevens en een afgesproken gebruikershandeling. | De beheerder levert bewijs; de onderzoeker beschrijft de uitkomst en grenzen; de beslisser beoordeelt vervolgvoorwaarden. |
| Belangrijke leveranciersafhankelijkheden zijn beheersbaar. | Een lijst met externe diensten en enkele facturen; accountbeheer, vervangingsroute en technische limieten zijn nog niet volledig uitgewerkt. | De genoemde diensten en een deel van het huidige gebruik zijn zichtbaar. | Continuïteit bij vertrek van een beheerder, wijzigende toegang of uitval van een dienst is niet aangetoond. Contractuele overdraagbaarheid is afzonderlijk te beoordelen. | Controleer technische accountverantwoordelijkheid, toegangsherstel, data-export en afhankelijk gedrag bij uitval. Laat contract- en licentievraagstukken door passende juridische expertise beoordelen. | Technische en juridische onderzoekers rapporteren ieder binnen hun scope; koper of investeerder neemt het transactie- of investeringsbesluit. |
Wat je hiermee kunt beslissen
Het register voorkomt dat een demonstratie of teamuitspraak ongemerkt als bewijs voor een bredere claim geldt. Een onbevestigde claim is geen aangetoond defect; het is een informatiehiaat of onderzoeksvraag. Dit voorbeeld levert geen financiële waardering, rapportcijfer, investeringsadvies of garantie op toekomstige prestaties. Conclusies gelden voor het onderzochte bewijs, de versie, omgeving en datum.
Gebruik dit voor je eigen vraag
- Formuleer de technische aannames die het voorgenomen besluit daadwerkelijk kunnen beïnvloeden; maak de scope smaller dan 'controleer alles'.
- Leg per claim bron, datum of versie en type bewijs vast: direct onderzocht, gedemonstreerd, verteld door een teamlid of nog niet aangeleverd.
- Vraag naast architectuur en broncode ook naar release- en herstelverantwoordelijkheid, externe diensten en overdracht van technische toegang.
- Maak ontbrekende informatie expliciet, met eigenaar en een mogelijke vervolgstap. Afwezig bewijs ondersteunt geen automatische positieve of negatieve conclusie.
- Scheid technische bevindingen en onderzoekslimieten van juridische beoordeling, financiële waardering en het uiteindelijke besluit.
Welke aanpak past bij jouw vraag?
Kies op basis van het werk, de betrokken mensen en wat je kunt beheren.
| Aanpak | Geschikt wanneer | Afweging |
|---|---|---|
| Codeonderzoek | Onderhoudbaarheid van de broncode is de hoofdvraag. | Geeft geen volledig beeld van organisatie en exploitatie. |
| Technical due diligence | Techniek beïnvloedt een transactie of investeringsbesluit. | Vraagt bewijs vanuit code, beheer, documentatie en interviews. |
| Architectuuradvies | Het besluit om door te bouwen staat al vast. | Richt zich op de toekomstige inrichting en migratiestappen. |
Wat is nodig om te starten?
- Een afgebakende onderzoeksvraag en vertrouwelijke toegang tot bewijs.
- Architectuur-, release- en beheerinformatie plus relevante incidenten.
- Beschikbaarheid van technische verantwoordelijken voor interviews.
Hoe beoordelen we het resultaat?
- Materiële claims zijn gekoppeld aan bewijs of als onbevestigd gemarkeerd.
- Risico’s beschrijven impact, afhankelijkheden en mogelijke vervolgstappen.
- Ontbrekende informatie en grenzen van het onderzoek zijn zichtbaar voor de beslisser.
SCOPE & INVESTERING
Wat bepaalt de kosten?
Een bruikbare kosteninschatting begint bij de scope. Ik onderscheid ontwikkelwerk van terugkerende gebruiks- en beheerkosten. Dit zijn de belangrijkste factoren:
- Omvang van platform, teams en leverancierslandschap.
- Kwaliteit en beschikbaarheid van de aangeleverde informatie.
- Onderzoeksdiepte en tijd voor interviews en verificatie.
TOEPASSING EN AFBAKENING
Jouw uitdaging.
Een concrete toepassing.
Illustratief scenario; geen gepubliceerde klantcase.
Een investeerder of koper wil technische aannames toetsen.
Technical due diligence begint bij de technische aannames achter de investering of overname. Een software-audit kan de bredere oplossing onderzoeken; een codebase-audit geeft verdieping in code en onderhoudbaarheid. Leg vooraf vast welke onderdelen toegankelijk zijn en welke conclusies daardoor wel of niet onderbouwd kunnen worden.
DE VRAAG DIE IK EERST STEL
Welke claims zijn relevant voor de transactie en welk bewijs is beschikbaar?
Spreek de eerste stap af
Gebruik de randvoorwaarden, oplevercriteria en kostenfactoren hierboven om je opdracht af te bakenen. Spreek af wie het resultaat beoordeelt en wie de oplossing beheert. In onze werkwijze lees je hoe verkenning, uitvoering en overdracht samenhangen.
Bekijk onze werkwijzeVRAGEN OVER DEZE DIENST
Jouw vragen.
Heldere antwoorden.
Kunnen jullie bevestigen dat een platform miljoenen gebruikers aankan?
Niet op basis van een architectuurplaat of code-inspectie alleen. Zo’n claim vraagt representatieve belastingmetingen, capaciteitsgegevens en expliciete aannames over het gebruik.
Wat als de verkoper alleen een demonstratie toestaat?
Een demonstratie kan de getoonde handeling onder de getoonde omstandigheden onderbouwen. Zonder aanvullende toegang blijven bijvoorbeeld codekwaliteit, operationele configuratie en zelfstandige overdracht beperkt toetsbaar. Het rapport hoort die beperking bij de relevante claims te benoemen; de beslisser bepaalt of aanvullend onderzoek of een voorwaarde nodig is.
Is afhankelijkheid van één ontwikkelaar automatisch een negatief oordeel?
Nee. Onderzoek welke werkzaamheden, toegangsrechten en kennis van die persoon afhangen en welke overdracht aantoonbaar mogelijk is. De betekenis hangt af van het product, beschikbare alternatieven en het voorgenomen besluit. Alleen het aantal ontwikkelaars ondersteunt geen uitspraak over continuïteit.
Bevat technical due diligence ook een oordeel over contracten en softwarelicenties?
Een technisch onderzoek kan zichtbare componenten, diensten en afhankelijkheden inventariseren en vragen voor vervolgonderzoek aanwijzen. Juridische rechten, contractuele overdraagbaarheid en licentieconformiteit vragen passende juridische beoordeling. Leg vast wie die beoordeling uitvoert en welke informatie technische en juridische onderzoekers daarvoor mogen delen.
Bronnen en technische onderbouwing
Deze primaire bronnen onderbouwen de technische principes in deze uitleg. De projectaanbevelingen zijn de interpretatie van OXIAE; de uitgevers bevelen OXIAE daarmee niet aan. Productdocumentatie geldt voor het genoemde platform.
- Secure Software Development Framework, SP 800-218NIST
Gedeelde taal voor ontwikkelpraktijken en leveranciersonderzoek.
Link en relevantie gecontroleerd: - DORA’s software delivery performance metricsDORA
Contextuele beoordeling van softwarelevering en instabiliteit.
Link en relevantie gecontroleerd: - Application Security Verification StandardOWASP
Kader voor afgebakende verificatie van applicatiebeveiliging.
Link en relevantie gecontroleerd:
JOUW VOLGENDE STAP
Bereid je projectgesprek voor.
Verken je Technical Due Diligence? Gebruik de projectchecklist om je taak, systemen en gewenste uitkomst te beschrijven. Verzamel open vragen en download een brief voor je gesprek.
Maak je projectbrief