Er is een vreemde paradox in de Europese ICT-markt. Hoe kritischer de dienst, hoe groter de gesproken belofte. En hoe groter deze belofte, hoe kleiner de verantwoordelijkheid die uiteindelijk contractueel wordt vastgelegd.

Wie vandaag een SOC, MSSP of andere businesskritische ICT-dienst inkoopt, krijgt doorgaans een verhaal van totale ontzorging. Vierentwintig uur per dag waakzaam. Volledige cyberweerbaarheid. “Jij focust op je kernactiviteit, wij regelen de rest.” Het klinkt overtuigend, bijna geruststellend. Tot het moment waarop het contract wordt opengeklapt.

De enige belangrijke vraag is Waarom deze aanbieder nog niet NIS2 compliant is en jouw een contract herziening in jouw voordeel heeft aangeboden?

Immers, onder de waterlijn van marketing en sales, verschijnt steeds vaker een andere realiteit. Aansprakelijkheid wordt begrensd tot bedragen die geen enkele verhouding hebben tot de mogelijke schade. Essentiële risico’s verdwijnen onder juridische labels als “indirecte schade” of “uitzonderlijke omstandigheden”. Incidentrespons wordt zogenaamd gedeeld, maar in de praktijk doorgeschoven. En bijna altijd staat er zwart op wit dat de klant eindverantwoordelijk blijft.

Het is die structurele spanning die wij de 180/20-regel noemen: honderdtachtig procent belofte, twintig procent verantwoordelijkheid.

“Wat verkocht wordt als een schild, blijkt juridisch vaak een paraplu.”

Aan elke CEO, bestuurder en directie van een Important of Essentiële organisatie:

“Als jouw kritieke ICT-leverancier morgen faalt,
ben jij dan beschermd — of alleen goed verzekerd tegen het topje van de ijsberg?”

NIS2 maakt één ding onontkoombaar duidelijk:
je kan operationele verantwoordelijkheid niet outsourcen zonder ze contractueel, bestuurlijk en aantoonbaar te borgen.

Wie dat vandaag niet doet, betaalt morgen.
Niet alleen in euro’s, maar in toezicht, reputatie en continuïteit.

Dit artikel is geen karikatuur, maar een spijtig patroon dat zich al jaren herhaalt. Contracten die niet ontworpen zijn om falen samen op te vangen, maar om falen juridisch te neutraliseren. Niet om risico’s te beheersen, maar om ze beheersbaar te laten lijken. En wanneer het dan fout loopt, volgt het bekende scenario: lange procedures, botsende interpretaties en advocaten die uiteindelijk de enige constante winnaars blijken.

Waarom NIS2-certificatie van jouw SOC, MSSP , pentest leverancier en software leverancier het verschil gaat maken.

In nieuwe realiteit van 2026 volstaat “vertrouwen” niet meer. Bewijs wordt de munteenheid.

NIS2 eist:

• cybersecurity-certificatie,
• aantoonbare controls,
• onafhankelijke assurance.

“In een gereguleerde keten wint niet wie het luidst roept, maar wie het best kan aantonen 360 graden doorgelicht te zijn.”

Leveranciers zonder certificatie of assurance zullen steeds vaker:

• extra contractuele druk krijgen,
• uitgesloten worden uit kritieke ketens,
• of alleen nog als “niet-kritisch” mogen fungeren.

Het verhaal dat certificatie enkel geldklopperij is mag opgeborgen worden. Enkel ICT Struisvogels dragen deze T shirts en niet voor lang.

Het is dan ook begrijpelijk dat zulke struisvogels ook stellen dat contracten enkel dienen om dure juristen te verrijken. Dat is te simplistisch, maar het raakt wel een pijnpunt: slechte ICT-contracten lossen geen risico’s op, ze stellen ze uit.

Net daar verschuift NIS2 het speelveld onomkeerbaar. Voor het eerst zegt Europese wetgeving expliciet dat organisaties niet alleen verantwoordelijk zijn voor hun eigen cyberweerbaarheid, maar ook voor die van hun digitale toeleveringsketen. Important en Essentiële entiteiten kunnen zich niet langer verschuilen achter leveranciers. De vraag is niet langer wie iets beloofde, maar wie kan aantonen dat risico’s daadwerkelijk beheerst zijn.

Onder NIS2 wordt onduidelijkheid zelf een tekortkoming. Vage afspraken, impliciete aannames en contractuele mist zijn geen neutrale grijze zones meer, maar governance-problemen. Bestuurders kunnen zich niet langer beroepen op “we gingen ervan uit dat de leverancier dat deed”. Vertrouwen verschuift naar bewijs.

DORA duwt die evolutie nog verder, zeker voor wie actief is in of rond de financiële sector. Daar wordt contractuele vaagheid niet alleen problematisch, maar ronduit onaanvaardbaar. Verantwoordelijkheden moeten expliciet benoemd zijn, samenwerking bij incidenten vooraf vastgelegd, en exit-scenario’s realistisch uitgewerkt. “Best effort” verliest zijn onschuld en wordt een alarmsignaal.

Wat het geheel nog schrijnender maakt, is hoe weinig aantoonbare maturiteit er vandaag in de markt aanwezig is. Neem Duitsland, vaak gezien als industriële en technologische motor van Europa. Naar schatting beschikt amper een half procent van de ICT-leveranciers die businesskritische diensten leveren over een ISO 27001-certificaat. Dat betekent dat in een van de meest gereguleerde economieën van Europa het overgrote deel van de kritieke digitale dienstverlening gebeurt zonder onafhankelijk gecertificeerd informatiebeveiligingsmanagementsysteem.

“Dat is geen randfenomeen, dat is een structureel systeemrisico.”

En het probleem stopt niet bij infrastructuur- of managed service-providers. Ook businesskritische softwareleveranciers blijven opvallend vaak buiten schot. “Secure development by design” wordt gretig gebruikt als slogan, maar zelden onderbouwd met aantoonbare processen, onafhankelijke audits of certificatie. Secure SDLC’s bestaan op papier, niet in bewijs. Codekwaliteit wordt verward met security-maturiteit.

Wanneer zulke software een kernrol speelt in kritieke processen, verschuilen leveranciers zich vervolgens achter contracten die even vaag zijn als hun ontwikkelprocessen. Reputatieschade? Niet opgenomen. Verlies van NIS2-status of certificatie? Geen expliciete gevolgen. Boetes opgelegd door toezichthouders? Contractueel afgewenteld. De boodschap is impliciet maar duidelijk: de risico’s zijn van jou, niet van ons.

“Software mag kritisch zijn, aansprakelijkheid blijkbaar niet.”

De volgende realiteitscheck komt eraan. Met strengere handhaving onder NIS2, de doorontwikkeling van DORA en een aangescherpt GDPR-kader richting 2026, verschuift toezicht van theorie naar praktijk. Boetes worden niet langer aangekondigd, maar daadwerkelijk geïnd. Management zal niet langer geconfronteerd worden met hypothetische sancties, maar met concrete bedragen, publieke beslissingen en tastbare reputatieschade.

Daarbovenop komt de huidige golf van AI-functionaliteit in softwareproducten. AI wordt gepresenteerd als innovatie, differentiator en efficiëntie-hefboom. Maar in veel gevallen ontbreken elementaire garanties: geen duidelijke governance, geen afbakening van verantwoordelijkheden, geen secure LLM-architectuur, geen transparantie over trainingsdata, logging of modelgedrag. AI zit in de software, maar niemand lijkt eigenaar van de risico’s.

“AI zonder governance is geen vooruitgang, maar uitgestelde schade.”

Veel contracten die vandaag nog actief zijn, zijn opgesteld vóór 2024. Ze stammen uit een tijd waarin NIS2 nog toekomstmuziek was, DORA nog een ontwerp en supply-chain-verantwoordelijkheid vooral een theoretisch begrip. Ze zijn niet noodzakelijk fout, maar wel gevaarlijk verouderd. Ze zijn gebouwd voor een wereld waarin falen lokaal was, niet systemisch. Die wereld bestaat niet meer.

NIS2 laat weinig ruimte voor vrijblijvendheid. Contracten die niet herbekeken worden, veranderen vanzelf in risico’s. Niet alleen juridisch, maar bestuurlijk. Niet alleen financieel, maar operationeel. Een herziening binnen negentig dagen is geen formele wettelijke verplichting, maar wel een rationele reflex voor elke organisatie die haar continuïteit ernstig neemt.

In die context wordt certificatie geen marketingbadge meer, maar een toegangsbewijs. ISO 27001 en Europese cybersecurity-certificatie verschuiven van “nice to have” naar “nodig om mee te mogen doen”. Niet omdat ze perfect zijn, maar omdat ze aantonen dat verantwoordelijkheden, processen en controles niet alleen bestaan op papier, maar ook getoetst worden.

“In een gereguleerde keten wint niet wie het luidst belooft, maar wie het meest kan aantonen.”

De kernvraag voor elke CEO van een Important of Essentiële organisatie blijft ongemakkelijk eenvoudig. Als jouw kritieke ICT- of softwareleverancier morgen faalt, ben jij dan beschermd tegen de volledige ijsberg, of alleen tegen het topje dat contractueel zichtbaar was?

NIS2 laat steeds minder ruimte om dat antwoord vaag te houden.

Korte CEO-vragenlijst

Businesskritische ICT- en maatwerksoftwarecontracten (NIS2-proof?)

Welke top-10 kritieke ICT- en softwarediensten kunnen bij uitval onze operatie (deels of volledig) stilleggen, en wat is per dienst de maximale aanvaardbare uitvaltijd (uren/dagen)?

Hebben we per kritieke leverancier een duidelijke RACI: wat doet de leverancier, wat doen wij zelf, wat is uitbesteed aan onderaannemers, en wie draagt eindverantwoordelijkheid bij falen?

Zijn incidentmelding en samenwerking bij beveiligingsincidenten contractueel scherp vastgelegd, inclusief maximale meldtermijnen, forensische ondersteuning, bewijsvorming, communicatie naar toezichthouders en klanten?

Beschikken we over afdwingbare auditrechten, inclusief toegang tot onafhankelijke assurance (ISO 27001, SOC 2), samenvattingen van penetratietests, secure code reviews en control-attestaties?

Zijn SLA’s gekoppeld aan reële remedies bij ernstige tekortkomingen (niet enkel service credits), en bestaat er een escalatiepad tot directie- of bestuursniveau?

Is de aansprakelijkheid van de leverancier begrensd op een niveau dat in verhouding staat tot de potentiële business-, compliance- en reputatieschade?

Sluiten contractuele uitzonderingen zoals “indirecte schade”, “data- of reputatieverlies” de kernrisico’s uit, waardoor we in de praktijk onbeschermd blijven?

Bestaat er een exit- en switch-plan dat technisch én contractueel uitvoerbaar is, inclusief overdracht van broncode, documentatie, data, kennis en redelijke ondersteuningstermijnen en -kosten?

Weten we exact waar data, logs en back-ups worden verwerkt en opgeslagen, en kan de leverancier locaties of cloudproviders wijzigen zonder onze expliciete goedkeuring?

Is subcontracting toegestaan, en zo ja: hebben we transparant zicht op de volledige keten, inclusief fourth parties en hun beveiligingsniveau?

Welke operationele verplichtingen nemen wij contractueel op ons (patching, configuratie, monitoring, back-ups) die in de praktijk onrealistisch of onvoldoende controleerbaar zijn?

Kunnen we aantonen dat leveranciersrisico’s periodiek worden geëvalueerd, opgevolgd en herzien in lijn met NIS2 supply-chain-governance?

Voor financiële entiteiten: zijn contracten aantoonbaar DORA-aligned op alle verplichte contractuele elementen (incidentcoöperatie, audit, exit, toezichtsondersteuning)?

Welke leveranciers positioneren zich als “kritisch”, maar leveren contractueel slechts “best effort” zonder harde, afdwingbare verplichtingen?

Welke contracten zijn opgesteld vóór oktober 2024 en moeten prioritair worden heronderhandeld om aantoonbaar NIS2-conform te zijn?

---

Aanvullende kernvragen specifiek voor maatwerksoftwareleveranciers

Is secure development by design contractueel onderbouwd met aantoonbare processen (secure SDLC, threat modelling, code-reviews, dependency-management), of blijft het bij marketingtaal?

Wordt beveiliging van maatwerksoftware onafhankelijk getoetst via periodieke penetratietests, secure code assessments en supply-chain-analyses van gebruikte libraries en frameworks?

Is vastgelegd wie verantwoordelijk is voor kwetsbaarheden in broncode, gebruikte open-source-componenten en third-party modules, inclusief patch- en hersteltermijnen?

Bevat het contract expliciete bepalingen over aansprakelijkheid bij verlies van NIS2-status, ISO-certificatie of andere compliance-vereisten door tekortkomingen in de software?

Is reputatieschade expliciet benoemd als contractueel risico, of volledig uitgesloten via standaardclausules?

Zijn boetes of sancties opgelegd door toezichthouders (bijv. NIS2-handhaving of toekomstige GDPR-boetes) volledig uitgesloten, of gedeeld wanneer de oorzaak aantoonbaar bij de software ligt?

Is vastgelegd wie eigenaar is van security-beslissingen in de applicatiearchitectuur, en wie finale zeggenschap heeft over risicovolle ontwerpkeuzes?

Wordt broncode-escrow voorzien voor bedrijfskritische maatwerksoftware, inclusief activeringscriteria en praktische toegankelijkheid?

Indien AI-functionaliteit is geïntegreerd: bestaan er duidelijke afspraken over AI-governance, datagebruik, model-risico’s, logging, explainability en beveiliging van LLM-componenten?

Is er contractuele duidelijkheid over wie verantwoordelijk is voor AI-incidenten, model-fouten, datalekken of compliance-overtredingen veroorzaakt door AI-functionaliteit?

Kan de leverancier aantonen dat AI-componenten veilig zijn ontwikkeld, getest en beheerd, of ontbreekt elke vorm van secure LLM-garantie?

---

Slotgedachte voor de CEO

“Als deze software morgen faalt, kan ik dan aantonen dat wij onze verantwoordelijkheid onder NIS2 hebben genomen — of ontdek ik dat risico’s contractueel zijn doorgeschoven?”

Draal niet langer dan 90 dagen om harde garanties te krijgen in volgende Addendums of contractherzieningen en bedenk als je bedrijfskritische leverancier ze niet wil ondertekenen is het tijd om je exit plan naarr een wel NIS2 gecertificeerde leverancier te starten.

Contractuele minimumvereisten

Voor businesskritische ICT- en maatwerksoftwareleveranciers (NIS2-proof)

1. Duidelijke scope en verantwoordelijkheidsafbakening

Het contract moet ondubbelzinnig beschrijven welke diensten, systemen, componenten en processen onder de verantwoordelijkheid van de leverancier vallen. Impliciete aannames of “industry standard”-formuleringen zijn onvoldoende. De leverancier erkent expliciet zijn rol in de continuïteit en beveiliging van de dienst.

2. Expliciete RACI-verdeling

Voor alle kritieke activiteiten (beveiliging, monitoring, patching, incidentrespons, back-ups, configuratiebeheer) wordt een RACI opgenomen. “Shared responsibility” zonder nadere uitwerking is niet toegestaan.

3. Incidentmelding en samenwerking

Het contract bevat bindende afspraken over:

• maximale meldingstermijnen bij beveiligingsincidenten,
• actieve ondersteuning bij forensisch onderzoek,
• beschikbaarheid van logs en bewijs,
• samenwerking met toezichthouders en CSIRT’s,
• afstemming van externe communicatie.
  Incidentrespons mag niet beperkt zijn tot “best effort”.

4. Beveiligingseisen en aantoonbaarheid

De leverancier verplicht zich tot aantoonbare informatiebeveiliging, ondersteund door:

• een actueel ISO 27001-certificaat of gelijkwaardig,
• periodieke onafhankelijke audits,
• penetratietests en kwetsbaarheidsbeheer.
  Het ontbreken van certificatie moet expliciet worden gemotiveerd en tijdelijk zijn.

5. Secure development by design (voor software)

Voor maatwerksoftware wordt een secure SDLC contractueel vastgelegd, inclusief:

• threat modelling,
• secure code reviews,
• dependency- en open-source-risicobeheer,
• patch- en vulnerability-management.
  “Secure by design” mag geen marketingterm zijn zonder bewijs.

6. Audit- en verificatierechten

De afnemer heeft het recht om:

• auditrapporten en assurance-verklaringen op te vragen,
• redelijke audits of assessments te laten uitvoeren,
• tekortkomingen op te volgen met bindende verbeterplannen.
  Auditrechten mogen niet illusoir of buitensporig beperkt zijn.

7. Aansprakelijkheid in verhouding tot risico

De aansprakelijkheidslimiet moet realistisch zijn in verhouding tot:

• business impact,
• compliance-risico’s,
• potentiële reputatieschade.
  Caps die enkel gebaseerd zijn op jaarlijkse fees zijn voor kritieke diensten onvoldoende.

8. Beperking van uitsluitingen

Uitsluitingen voor:

• dataverlies,
• reputatieschade,
• boetes,
• grove nalatigheid of structurele tekortkomingen
  mogen niet leiden tot een feitelijke vrijwaring van de leverancier bij kritieke incidenten.

9. Reputatieschade en certificatieverlies

Het contract bevat expliciete bepalingen over:

• gevolgen van verlies van NIS2-, ISO- of andere relevante certificatie,
• reputatieschade veroorzaakt door aantoonbare tekortkomingen van de leverancier,
• meldplicht bij compliance-issues die impact hebben op de afnemer.

10. Regulatory cooperation & boetes

De leverancier verbindt zich tot actieve medewerking bij:

• NIS2- en DORA-verplichtingen,
• audits door toezichthouders,
• informatieverzoeken van autoriteiten.
  Contracten mogen boetes niet automatisch en volledig afwentelen op de klant indien de oorzaak bij de leverancier ligt.

11. Data- en locatiecontrole

Het contract specificeert:

• waar data wordt verwerkt en opgeslagen,
• onder welke voorwaarden locaties of cloudproviders mogen wijzigen,
• dat dergelijke wijzigingen vooraf worden goedgekeurd door de klant.

12. Subcontracting en ketentransparantie

Subcontracting is alleen toegestaan met:

• voorafgaande kennisgeving,
• inzicht in de volledige keten (inclusief fourth parties),
• gelijkwaardige beveiligings- en compliance-eisen voor onderaannemers.

13. Exit- en continuïteitsregeling

Het contract bevat een uitvoerbaar exit-plan, inclusief:

• overdracht van data, configuraties en documentatie,
• redelijke ondersteuning bij transitie,
• continuïteitsgaranties tijdens exit,
• heldere en begrensde kosten.

14. Broncode- en kennisborging (software)

Voor bedrijfskritische maatwerksoftware:

• wordt broncode-escrow voorzien,
• zijn activeringscriteria duidelijk vastgelegd,
• en is toegang praktisch uitvoerbaar bij faillissement, wanprestatie of ernstige compliance-fouten.

15. AI-functionaliteit en governance (indien van toepassing)

Indien AI of LLM’s worden gebruikt:

• moet AI-governance contractueel zijn vastgelegd,
• is duidelijk wie verantwoordelijk is voor AI-gedrag en risico’s,
• bestaan er garanties rond datagebruik, logging, security en compliance.
  AI zonder governance is contractueel onaanvaardbaar voor kritieke processen.

---

Bestuurlijke ondergrens (onuitgesproken maar cruciaal)

Als deze bepalingen ontbreken, draagt het bestuur het risico — niet de leverancier.

Deze minimumvereisten vormen geen luxe, maar een noodzakelijke basis voor Important en Essentiële organisaties onder NIS2. Alles daaronder is geen partnership, maar een gok.