IT-leveranciersovereenkomst na NIS2: beveiligingsclausules, SLA’s en incidentmeldingen

Een IT-leveranciersovereenkomst na NIS2 mag niet beperkt blijven tot een conformiteitsverklaring, een algemene beveiligingsclausule en een maandelijks beschikbaarheidspercentage. De overeenkomst moet de risico’s van de dienst vertalen naar een heldere verdeling van verantwoordelijkheden, meetbare serviceniveaus, snelle informatie-uitwisseling bij incidenten, toegang tot bewijs en een uitvoerbaar exitplan. Het vertrekpunt is de kritikaliteit van de dienst en de feitelijke verdeling van beheersmaatregelen tussen de partijen. Pas daarna kan worden bepaald welke beveiligingsmaatregelen, termijnen, verificatierechten en meldverplichtingen contractueel moeten worden vastgelegd.

De overeenkomst als instrument voor risicobeheersing

Een contractreview begint niet met een standaardtekst voor een beveiligingsclausule, maar met een overzicht van de afhankelijkheden van leveranciers. Per leverancier moeten de ondersteunde diensten, processen, systemen, gegevens en locaties in kaart worden gebracht. Vervolgens wordt beoordeeld wat de gevolgen zijn van onbeschikbaarheid of een beveiligingsinbreuk. Prioriteit ligt bij afhankelijkheden waarvan verstoring de bedrijfsvoering kan stilleggen, de nakoming van verplichtingen kan beperken of de incidentrespons kan belemmeren. Niet iedere IT-dienst vraagt daarom om dezelfde contractuele waarborgen.

De kritikaliteitsclassificatie van een leverancier moet voortkomen uit een bedrijfsimpactanalyse en risicobeoordeling, niet uitsluitend uit de contractwaarde. Bijzondere aandacht is nodig wanneer de organisatie verantwoordelijk blijft voor continuïteit en incidentafhandeling, terwijl de leverancier beschikt over de technische informatie, logbestanden, back-ups of infrastructuur die nodig zijn om de dienst te herstellen. Binnen de organisatie moet bovendien een eigenaar worden aangewezen voor het leveranciersrisico. Zonder duidelijk eigenaarschap blijven de verantwoordelijkheden van inkoop, IT, informatiebeveiliging en de proceseigenaar versnipperd.

De inhoud van de overeenkomst moet worden ontworpen op basis van verstoringsscenario’s, zoals een dienstuitval, aanval, verlies of beschadiging van gegevens, uitval van personeel van de leverancier, onderbreking in de keten van onderaannemers en beëindiging van de samenwerking. Per scenario worden de acties van beide partijen, de verantwoordelijkheden, de informatiestromen en de voorwaarden voor herstel vastgesteld. Daaruit volgen onder meer de beschikbaarheidsniveaus, reactie- en hersteltijden, vereiste documentatie en verificatierechten.

Een toezegging van hoge beschikbaarheid maakt niet duidelijk hoelang een productieaansturingssysteem buiten bedrijf mag zijn, vanaf welk moment de uitvaltijd wordt gemeten of wie de gegevens levert die nodig zijn om een incident te beoordelen. Evenmin garandeert zo’n toezegging toegang tot kopieën van logbestanden, informatie over onderaannemers of gegevens waarmee de dienst veilig kan worden gemigreerd. Deze tekortkomingen worden doorgaans pas zichtbaar tijdens een storing, wanneer verantwoordelijkheden niet langer impliciet kunnen blijven.

Een verwijzing naar NIS2 of de toepasselijke KSC-vereisten hoort de analyse van risico’s en verantwoordelijkheden af te ronden, niet de operationele inhoud van de overeenkomst te vervangen. De bredere managementcontext wordt toegelicht in NIS2 voor productiebedrijven: op wie de regels van toepassing zijn, welke verplichtingen zij invoeren en hoe de organisatie zich kan voorbereiden zonder het onderwerp uitsluitend als IT-vraagstuk te behandelen. De contractuele aanpassingen moeten steeds aansluiten op de rol van de organisatie, de kritikaliteit van de dienst en de feitelijke verdeling van beheersmaatregelen tussen de partijen.

Reikwijdte van de dienst en verantwoordelijkheden

De taakverdeling moet worden uitgewerkt in een technische bijlage en mag niet verborgen blijven in een algemene omschrijving van het contractonderwerp. De bijlage moet vermelden welke assets en omgevingen worden ondersteund, welke soorten gegevens worden verwerkt, waar verwerking en dienstverlening plaatsvinden, welke interfaces gelden, wanneer ondersteuning beschikbaar is en welke uitsluitingen van toepassing zijn. Zonder deze informatie kan niet eenduidig worden vastgesteld waar de verantwoordelijkheid van de leverancier eindigt, welke gebeurtenis de SLA-meting activeert en wie de beveiliging van systeemkoppelingen verzorgt.

Beveiligingsmaatregelen kunnen het best worden beschreven aan de hand van het vereiste resultaat, de verantwoordelijke partij en het bewijs van uitvoering. Technische details kunnen worden opgenomen in beheerste technische documentatie. Zo wordt voorkomen dat de overeenkomst snel veroudert. Een standaardpakket aan beheersmaatregelen van de leverancier kan pas worden aanvaard nadat het is vergeleken met het risicoprofiel van de specifieke dienst en vastgestelde lacunes zijn aangevuld. De verantwoordelijkheidsmatrix moet onderscheid maken tussen de eigenaar van de beheersmaatregel, de uitvoerende partij en degene die afwijkingen mag goedkeuren.

Wanneer de leverancier de omgeving beheert, moet de overeenkomst ook regels bevatten voor geprivilegieerde toegang: functiescheiding, authenticatiemethode, registratie van beheerhandelingen en onmiddellijke intrekking van rechten na een functiewijziging of beëindiging van de samenwerking. Een verklaring dat back-ups worden gemaakt is onvoldoende wanneer de klant niet weet wie deze versleutelt, waar ze worden bewaard, wie ze kan herstellen en welk document de uitkomst van een hersteltest bevestigt.

De leverancier moet een actueel overzicht bijhouden van onderaannemers die invloed hebben op de dienst, inclusief hun rol en verwerkingslocaties. Aan deze partijen moeten eisen worden opgelegd die ten minste gelijkwaardig zijn aan de afspraken met de klant. In de overeenkomst moet staan welke wijzigingen voorafgaande toestemming vereisen en voor welke wijzigingen een kennisgeving en nieuwe risicobeoordeling volstaan. Een managementsysteemcertificaat kan deze beoordeling ondersteunen, maar vervangt niet de verantwoordelijkheden die voor de concrete dienst zijn vastgelegd. Deze relatie wordt verder behandeld in NIS2 en NEN-EN-ISO 27001: wat een certificaat biedt en wat nog ontbreekt voor overeenstemming met KSC.

Beveiligingsclausules die verifieerbaar zijn

Een beveiligingsclausule wordt pas toetsbaar wanneer zij het verwachte resultaat, het toepassingsgebied, de uitvoeringsfrequentie, de wijze van bewijsvoering en de behandeling van afwijkingen vastlegt. Formuleringen als “volgens best practices” of “met inachtneming van passende zorgvuldigheid” kunnen concrete eisen aanvullen, maar maken op zichzelf niet aantoonbaar of de leverancier zijn verplichting correct is nagekomen. Voor iedere beheersmaatregel moeten de eigenaar van de eis, de bewaartermijn van het bewijs en de partij die een uitzondering mag accepteren worden aangewezen.

De eisen moeten ten minste betrekking hebben op kwetsbaarheids- en patchmanagement, veilige configuratie, versleuteling, bescherming en bewaring van logbestanden, back-ups, hersteltests, wijzigingsbeheer en toegangsbeveiliging. De frequentie van toegangsreviews, hersteltests en rapportages en de termijnen voor het verhelpen van kwetsbaarheden moeten worden afgeleid uit de risicobeoordeling van de dienst. Deze eisen horen niet voor alle leveranciers identiek te zijn.

Iedere afwijking moet worden opgenomen in een register, met motivering, oplostermijn, risico-eigenaar en compenserende beheersmaatregelen. Acceptatie vraagt om een beoordeling of deze maatregelen het risico daadwerkelijk terugbrengen tot een niveau dat de organisatie aanvaardbaar acht.

Een bepaling over het regelmatig maken van back-ups blijft onvolledig als niet wordt vastgesteld welke gegevens en systemen daaronder vallen, welke bewaartermijn geldt, hoe bescherming tegen wijziging of verwijdering is geregeld, wie toegang heeft en hoe vaak hersteltests plaatsvinden. Ook moet worden bepaald hoe een mislukte back-up of hersteltest wordt gemeld, wie de herstelmaatregelen goedkeurt en welke rapportage de afsluiting daarvan aantoont. Op dezelfde manier vraagt een verplichting om kwetsbaarheden te verhelpen om afspraken over classificatie, risicogebaseerde reactietermijnen, uitstel van updates en documentatie van tijdelijke maatregelen.

Er moet onderscheid worden gemaakt tussen bewijs dat periodiek wordt aangeleverd en bewijs dat op verzoek beschikbaar is. Tot de eerste categorie kunnen kwetsbaarheidsoverzichten, updaterapporten, resultaten van hersteltests en bevestigingen van toegangsreviews behoren. Na een incident, ingrijpende wijziging of geconstateerde afwijking kunnen gedetailleerde testresultaten, logbestanden, wijzigingshistorie, het uitzonderingenregister en een corrigerend-actieplan nodig zijn. De reikwijdte, eigenaren en bewaartermijnen kunnen worden gekoppeld aan de uitgangspunten uit NIS2- en KSC-documentatie vóór een controle: welke beleidsstukken, registers en bewijzen werkelijk nodig zijn.

Het verificatierecht moet proportioneel en ook bij een cloudleverancier uitvoerbaar zijn. Het eerste niveau kan bestaan uit documentbeoordeling en een toelichtend overleg. Een volgende stap kan onafhankelijke rapportages of overeengekomen tests omvatten. Een audit op locatie kan worden voorbehouden aan verhoogd risico, een ernstig incident of het ontbreken van geloofwaardig bewijs. De overeenkomst moet termijnen, vertrouwelijkheid, technische reikwijdte en de afhandeling van bevindingen regelen, zonder de klant rechten toe te kennen die in een gedeelde omgeving feitelijk niet uitvoerbaar zijn.

SLA’s voor weerbaarheid, niet alleen voor beschikbaarheid

Een SLA moet voortkomen uit de bedrijfsimpactanalyse en niet uit de standaardcatalogus van de leverancier. De proceseigenaar bepaalt eerst de maximaal aanvaardbare onderbrekingsduur, het toegestane gegevensverlies en de gevolgen van onbeschikbaarheid voor productie, klantenservice, afrekening en wettelijke verplichtingen. Op basis daarvan worden hersteldoelstellingen, eisen aan vervangende dienstverlening en noodprocedures en de prioriteiten van meldingen vastgesteld. Een maandelijks beschikbaarheidspercentage geeft geen antwoord op de vraag of één storing op een kritiek moment een proces langer stillegt dan de organisatie kan accepteren.

Naast beschikbaarheid moet de overeenkomst termijnen vastleggen voor bevestiging van de melding, start van de diagnose, functioneel herstel en definitieve verwijdering van de oorzaak. Ook moeten de frequentie van statusupdates, escalatieniveaus en ondersteuning buiten reguliere werktijden worden bepaald. Reactietijd is niet hetzelfde als hersteltijd, en het activeren van een tijdelijke oplossing betekent niet dat het probleem definitief is verholpen. Door deze begrippen te scheiden weet het operationele team wanneer het werk kan worden hervat en weet de diensteigenaar wanneer de leverancier de oorzaakanalyse afrondt en een structurele corrigerende maatregel implementeert.

Bij een systeem dat een productieproces aanstuurt, kan een kritiek incident onmiddellijke escalatie en continue communicatie vereisen totdat een noodoplossing operationeel is. Dezelfde storing in een trainingsomgeving kan een lagere prioriteit krijgen. De classificatie moet daarom gebaseerd zijn op de impact op de bedrijfsvoering en niet uitsluitend op de technische foutomschrijving. Als betrouwbare historische gegevens beschikbaar zijn, moeten bij het vaststellen van drempelwaarden ook de feitelijke reactie- en hersteltijden, beschikbaarheidsresultaten en het aantal terugkerende storingen worden betrokken.

Het meetmechanisme moet de gegevensbron, tijdzone, start en stop van de teller, overeengekomen service-uren, onderhoudsvensters en regels voor herclassificatie van incidenten vastleggen. Uitsluitingen moeten in een limitatieve en verifieerbare lijst worden opgenomen. Gebeurtenissen die binnen de verantwoordelijkheid van de leverancier vallen, mogen niet van de meting worden uitgesloten. De aansluiting van deze afspraken op de werkelijke operationele paraatheid kan worden beoordeeld met behulp van NIS2-audit in een productiebedrijf – beoordelen of de organisatie gereed is voor de nieuwe verplichtingen.

Service credits of symbolische vergoedingen herstellen een proces niet en beperken de gevolgen van uitval niet. Meer waarde hebben een verplicht herstelplan, escalatie naar het management, aanvullende weerbaarheidstests en het recht om de overeenkomst te beëindigen wanneer de afgesproken niveaus structureel of herhaaldelijk niet worden gehaald. Een financiële sanctie kan de aanspreekbaarheid versterken, maar vervangt geen mechanisme voor dienstherstel, oorzaakanalyse en het voorkomen van herhaling.

Incidenten en meldverplichtingen

De overeenkomst moet de leverancier verplichten om iedere gebeurtenis die gevolgen kan hebben voor de dienst, gegevens, bedrijfscontinuïteit of beveiliging van de klant onverwijld te melden. De eerste kennisgeving mag niet afhankelijk worden gemaakt van volledige bevestiging van de oorzaak, de omvang van de schade of de juridische kwalificatie van de gebeurtenis. De contractuele termijn moet voldoende marge bieden om de klant een eigen beoordeling te laten uitvoeren en eventuele externe meldtermijnen te halen. De termijn moet volgen uit de kritikaliteit van de dienst en de beschikbaarheid van een 24/7-contactpunt, niet uit het organisatorische gemak van de partijen.

De informatiestroom moet worden verdeeld in een eerste waarschuwing, periodieke statusupdates, een eindrapport en een oorzaakanalyse. Voor iedere fase moeten de vereiste gegevens, het toegestane communicatiekanaal, de ontvangers, de frequentie van updates en de escalatieregels bij uitblijvend contact worden vastgesteld. De eerste melding moet minimaal het detectietijdstip, de betrokken assets en diensten, de verwachte impact, de genomen maatregelen, beschikbare technische indicatoren, het risico op verdere verspreiding en het tijdstip van de volgende update bevatten. De contactlijst moet vervangers bevatten en periodiek worden getest, ook buiten reguliere werktijden.

Wanneer een leverancier ongebruikelijk netwerkverkeer vaststelt in een omgeving waarin een kritieke applicatie wordt beheerd, moet hij de klant waarschuwen voordat definitief is vastgesteld of sprake is van een inbreuk. De klant activeert zijn eigen incidentmanagementproces, wijst een beslissingsbevoegde aan, betrekt het responsteam en indien relevant de verzekeraar, en bepaalt wie externe meldingen en communicatie met klanten goedkeurt. De leverancier stelt de overeengekomen logbestanden en technische sporen veilig en ondersteunt de analyse, beheersing en afbakening van het incident, maar neemt de wettelijke verantwoordelijkheid van de klant niet over.

De clausules moeten ook regelen hoe bewijs wordt bewaard en verstrekt, hoe de integriteit ervan wordt beschermd, hoe besluiten worden gedocumenteerd en hoe informatie voor meldingen en de latere oorzaakanalyse wordt voorbereid. Termijnen, ontvangers en inhoud van externe meldingen moeten telkens worden geverifieerd aan de hand van de actuele wetgeving, de status van de organisatie en het type incident. Registers van meldingen, besluiten, escalaties en maatregelen moeten worden gekoppeld aan het document NIS2- en KSC-documentatie vóór een controle: welke beleidsstukken, registers en bewijzen werkelijk nodig zijn. De implementatieplanning kan worden afgestemd op Implementatie van NIS2 na opname in het KSC-register – actieplan tot 3 april 2027.

Implementatie, toezicht en een beheerste exit

Het ondertekenen van een addendum rondt het leveranciersmanagement niet af. De contracteigenaar moet periodiek de SLA-resultaten, incidenten, afwijkingen, corrigerende maatregelen, wijzigingen in onderaannemers en actualiteit van bewijsstukken beoordelen. De basis hiervoor is een contractregister met minimaal de verlengingsdatum, contracteigenaar, kritikaliteit van de dienst en status van de overeengekomen beveiligingsmaatregelen. Een conformiteitsverklaring vervangt geen rapportages, testresultaten of registraties waarmee de uitvoering van verplichtingen wordt aangetoond.

Vóór verlenging van de overeenkomst of een ingrijpende wijziging van de dienst moeten de kritikaliteit, technische en procesmatige afhankelijkheden, concentratie van diensten bij één leverancier, uitvoerbaarheid van maatregelen en mogelijkheid om over te stappen op een alternatief opnieuw worden beoordeeld. Deze review maakt duidelijk of een addendum volstaat of een nieuwe inkoopprocedure nodig is. Als een strategische leverancier een audit of aanpassing van voorwaarden weigert, moet de organisatie de lacune documenteren en kiezen tussen een compenserende maatregel, formele acceptatie van het restrisico of vervanging van de leverancier.

Het exitplan moet al vóór opzegging van de overeenkomst uitvoerbaar zijn. Het moet voorzien in teruggave en overdracht van gegevens in een bruikbaar formaat, migratieondersteuning, continuïteit tijdens de overgang, intrekking van toegangsrechten, verwijdering van kopieën en bevestiging van deze handelingen. Tegelijkertijd moeten registraties die voor juridische, bewijs- en auditdoeleinden nodig zijn behouden blijven. Een praktische test is het herstellen van gegevens bij een andere leverancier, inclusief verificatie van volledigheid, migratieduur en de mogelijkheid om bestaande accounts uit te schakelen.

De modernisering van het contractportfolio moet beginnen bij diensten met de grootste impact op de bedrijfsvoering. Geconstateerde lacunes worden geprioriteerd op basis van gevolgen en urgentie. De effectiviteit van de overeengekomen mechanismen kan worden getoetst tijdens een incidentoefening en een audit van een steekproef van bewijsstukken. De uitkomsten van SLA-reviews, incidentanalyses, afwijkingen, corrigerende maatregelen en exittests laten zien of de eisen in de praktijk functioneren of alleen op papier bestaan.

De reikwijdte van de beoordeling kan worden afgestemd op het document NIS2-audit in een productiebedrijf – beoordelen of de organisatie gereed is voor de nieuwe verplichtingen. Bij het vaststellen van de verplichtingen moet ook rekening worden gehouden met de status van de organisatie, zoals toegelicht in De NIS2-richtlijn – op wie is zij van toepassing en welke ondernemingen moeten aan de nieuwe eisen voldoen?