TEST NIS2 en softwarecontinuïteit: escrow als compliance-instrument

Organisaties die onder de NIS2-richtlijn vallen, weten inmiddels dat “we vertrouwen op onze leverancier” geen toereikend antwoord is op een toezichthouder. NIS2 vraagt om aantoonbare beheersmaatregelen, ook voor risico’s die buiten de eigen organisatie liggen. Softwareafhankelijkheid is zo’n risico, en het blijft structureel onderbelicht in continuïteitsplannen.

De kernvraag: voldoet jouw organisatie aan de NIS2-verplichting voor toeleveringsketens, ook als een kritieke softwareleverancier uitvalt?

Wat NIS2 concreet eist

De NIS2-richtlijn, sinds oktober 2024 omgezet in nationale wetgeving in de meeste EU-lidstaten, legt essentiële en belangrijke entiteiten een uitgebreide zorgplicht op. Artikel 21 verplicht organisaties onder meer tot maatregelen op het gebied van bedrijfscontinuïteit, back-upbeheer, crisisbeheer en beveiliging van de toeleveringsketen. Dat laatste punt is cruciaal: je bent als organisatie medeverantwoordelijk voor de risico’s die je leveranciers met zich meebrengen.

Concreet betekent dit dat je moet kunnen aantonen dat je bij uitval van een kritieke softwareleverancier, door faillissement, overname, staking of wanprestatie, in staat bent de operationele continuïteit te waarborgen. Een contractuele garantie van de leverancier volstaat niet. Toezichthouders verwachten technische en organisatorische maatregelen die onafhankelijk van de leverancier werken.

De blinde vlek in veel continuïteitsplannen

Veel organisaties hebben hun back-upinfrastructuur en disaster recovery op orde, maar vergeten één essentieel element: de broncode van bedrijfskritische software. Zonder toegang tot de broncode is het bij leveranciersuitval onmogelijk om software te onderhouden, aan te passen of over te dragen aan een andere partij. De applicatie draait misschien nog, maar elke bug, beveiligingslek of noodzakelijke aanpassing wordt onoplosbaar.

Dit is geen theoretisch scenario. Jaarlijks vallen softwareleveranciers om, worden overgenomen door partijen met andere prioriteiten, of staken de ondersteuning van een product. Voor organisaties in sectoren als energie, financiële dienstverlening of gezondheidszorg, die allemaal onder NIS2 vallen, is dit een direct bestuurlijk risico.

Escrow als structurele maatregel

Software escrow lost dit risico op een juridisch en technisch onderbouwde manier op. Bij een escrow-overeenkomst deponeert de softwareleverancier de broncode, inclusief documentatie en bouwomgeving, bij een onafhankelijke escrow-agent zoals Escrow4All. Zodra een contractueel vastgelegde vrijgaveconditie intreedt, zoals faillissement of het staken van ondersteuning, wordt de broncode vrijgegeven aan de gebruiker.

Escrow4All biedt daarbij verificatieniveaus die aantonen dat de gedeponeerde broncode daadwerkelijk werkt. VerifTwo controleert of de applicatie compileerbaar is in de bestaande ontwikkelomgeving; VerifThree gaat verder en test de volledige opbouw in een schone omgeving. Dit niveau van verificatie is precies wat toezichthouders bedoelen als zij vragen om aantoonbare continuïteitsmaatregelen.

Voor organisaties die zelf software ontwikkelen en afhankelijk zijn van interne teams of externe ontwikkelpartners, biedt My Source Code Escrow een vergelijkbare oplossing: onafhankelijke bewaring van eigen broncode, ISO 27001-gecertificeerd en direct inzetbaar als NIS2-controlemaatregel.

Escrow is geen sluitpost, maar een verplichting

NIS2-compliance is geen eenmalig project. Het is een doorlopende verplichting om risico’s in de toeleveringsketen te identificeren, beheersen en aantonen. Software escrow is daarbij geen nice-to-have, maar een van de weinige maatregelen die technische, juridische en organisatorische zekerheid combineren in één overeenkomst.

Wil je weten welke software binnen jouw organisatie in aanmerking komt voor een escrow-arrangement, of hoe escrow past binnen je bredere NIS2-documentatie? Neem contact op met Escrow4All voor een vrijblijvend adviesgesprek.