NIS2 IT-leveranciers: wat de richtlijn werkelijk vereist

NIS2 vereist leveranciersrisicobeheer, niet het mechanisch verzamelen van een identiek dossier voor elke dienstverlener. Artikel 21 van de Europese richtlijn verwijst naar de beveiliging van de toeleveringsketen, met inbegrip van aspecten die verband houden met de relaties tussen een entiteit en haar rechtstreekse leveranciers of dienstverleners. Het vereist ook een passende en proportionele all-hazardsbenadering.

De officiële pagina van de CCB over de NIS2-wet bevestigt deze verplichting in België. Ze verduidelijkt dat de entiteit rekening moet houden met de specifieke kwetsbaarheden van elke rechtstreekse leverancier en met de algemene kwaliteit van diens producten en cyberbeveiligingspraktijken, met name beveiligde ontwikkelingsprocedures wanneer die van toepassing zijn.

Aankoop, logistiek en privégebruik moeten worden geregeld.

4. Bedrijfstoestel de audit- en bewijzencollectiemethode van GVISION legt het verschil uit tussen een aanwijzing, een bevinding en een aanbeveling.

Leveranciers classificeren vóór u hen een vragenlijst stuurt

Criticaliteit wordt gemeten aan de hand van impact en blootstelling, niet aan de hand van het factuurbedrag. Een kleine dienstverlener met een beheerdersaccount kan een groter risico vormen dan een grote leverancier van kantoorbenodigdheden. Begin met een register van derde partijen: geleverde dienst, interne eigenaar, gegevens, systemen, toegangen, bekende onderaannemers, hostinglanden, afhankelijkheden en vervangingsoplossing.

Stel vier vragen. Kan de leverancier een belangrijke activiteit onderbreken? Kan hij gevoelige informatie lezen, wijzigen of verwijderen? Beschikt hij over externe, geprivilegieerde of permanente toegang? Zou hij moeilijk te vervangen zijn binnen de termijn die voor de business aanvaardbaar is? Hoe meer positieve antwoorden er zijn, hoe recenter, nauwkeuriger en beter controleerbaar het bewijs moet zijn.

Een eenvoudige classificatie werkt vaak beter dan een complex model. Het kritieke niveau omvat diensten waarvan het uitvallen een grote onderbreking, een uitgebreide compromittering of een moeilijk herstel veroorzaakt. Het hoge niveau betreft belangrijke toegang of gevoelige gegevens met beperkte terugvalmogelijkheden. Het standaardniveau omvat vervangbare, beperkt gekoppelde diensten zonder significante toegang.

De 15 te verifiëren bewijzen bij een IT-leverancier

4. Bedrijfstoestel Een oud document of een document dat beperkt is tot één dochteronderneming kan correct zijn zonder uw dienst te dekken.

1. Governance en verantwoordelijke voor beveiliging

Vraag een goedgekeurd beveiligingsbeleid, de datum van de laatste herziening en de verantwoordelijke rol op. Het document mag geen interne geheimen onthullen; het moet aantonen dat er verantwoordelijkheden zijn, dat het management toezicht houdt op de risico’s en dat uitzonderingen worden behandeld. Controleer voor een kritieke dienst ook de frequentie van de reviews en de escalatie naar het management.

4. Bedrijfstoestel

Aankoop, logistiek en privégebruik moeten worden geregeld.

3. Inventaris van geprivilegieerde toegangen

De leverancier moet toelichten wie uw omgeving kan beheren, via welk kanaal, met welk privilegeniveau en gedurende welke periode. Zoek naar persoonlijke accounts, phishingresistente multifactorauthenticatie waar mogelijk, een secrets vault, tijdelijke privilege-escalatie en een noodprocedure. Vraag eerder een geanonimiseerd voorbeeld van een toegangsreview dan een eenvoudige verklaring.

4. Indiensttredingen, functiewijzigingen en uitdiensttredingen

Controleer het proces voor het toekennen en verwijderen van accounts voor medewerkers en onderaannemers. Een nuttig bewijs kan een geanonimiseerd voorbeeld zijn van een onboarding- en offboardingticket, ontdaan van persoonsgegevens, met goedkeuring en doorlooptijd. Controleer ook toestellen, API-sleutels, tokens en out-of-bandtoegang die soms actief blijven nadat het hoofdaccount is verwijderd.

5. Kwetsbaarheids- en patchbeheer

Vraag het beleid voor scanning, beoordeling en remediatie op, evenals recente samengevatte resultaten. De termijnen moeten variëren volgens de ernst, blootstelling en het bestaan van actieve exploitatie. Een rapport zonder actieplan volstaat niet: controleer uitzonderingen, compenserende maatregelen, verantwoordelijken en streefdata.

6. Beveiligde ontwikkeling en wijzigingsbeheer

Zoek bij een softwareleverancier, agentschap of maatwerkintegratie naar code reviews, dependencybeheer, scheiding van omgevingen, secrets buiten de code, tests vóór ingebruikname in productie en goedkeuring van wijzigingen. Vraag hoe gemelde kwetsbaarheden worden ontvangen en behandeld. Een SBOM kan voor bepaalde software nuttig zijn, maar de aanwezigheid ervan alleen bewijst niet dat de componenten veilig zijn.

7. Logging en monitoring

Controleer welke administratieve handelingen, verbindingen, wijzigingen en beveiligingsgebeurtenissen worden gelogd, hoelang de logs worden bewaard en wie ze monitort. Vraag een geanonimiseerd voorbeeld van een rapport of alert. Logs moeten een onderzoek kunnen ondersteunen zonder toegankelijk te zijn voor dezelfde accounts die ze mogelijk kunnen wijzigen.

8. Detectie en respons op incidenten

Mobile Application Management past regels toe op professionele apps en gegevens zonder het toestel volledig in te schrijven. Microsoft beschrijft MAM for unenrolled devices als een model waarbij appconfiguratie en appbeveiligingsbeleid bedrijfsdata binnen ondersteunde toepassingen beschermen. Mogelijke maatregelen zijn een app-pincode, beperkingen op kopiëren naar privéapps, voorwaarden voor lokale opslag en selectieve verwijdering van werkdata.

9. Melding en samenwerking

De contractuele melding van de leverancier moet vroeg genoeg gebeuren zodat uw organisatie haar eigen verplichtingen kan beoordelen. Vermeld niet automatisch overal “24 uur”: definieer de trigger, minimale informatie, updates en beveiligde kanalen in functie van de dienst. De richtlijn voorziet voor betrokken entiteiten in een vroegtijdige waarschuwing binnen 24 uur nadat zij kennis hebben genomen van een significant incident, gevolgd door verdere stappen; uw contract moet voldoende tijd laten om te beslissen en te melden.

10. Back-up, herstel en scheiding

Een back-upbeleid bewijst niet dat herstel mogelijk is. Vraag naar de scope, retentie, bescherming tegen wijzigingen, scheiding van accounts en het resultaat van een hersteltest. Controleer ook wie waarvan back-ups maakt: in een SaaS-omgeving beschermt de leverancier vaak het platform zonder uw vereiste granulariteit, zakelijke retentie of export te garanderen.

11. Continuïteit en herstel

Zoek naar een impactanalyse, gedefinieerde hersteldoelstellingen, een getest plan en geïdentificeerde afhankelijkheden. Vergelijk RTO en RPO met de bedrijfsbehoeften in plaats van met marketingclaims. Vraag wat er tijdens de laatste oefening is gebeurd, welke tekortkomingen zijn vastgesteld en of deze zijn verholpen.

12. Onderaannemers en cascade in de toeleveringsketen

De leverancier moet de onderaannemers kunnen identificeren die daadwerkelijk bijdragen aan de dienst, evenals hun rol, locatie en het mechanisme voor informatieverstrekking bij wijzigingen. Het doel is niet om elke leverancier van kantoorbenodigdheden te kennen, maar om afhankelijkheden zichtbaar te maken die de beschikbaarheid, vertrouwelijkheid, integriteit of incidentrespons kunnen beïnvloeden.

4. Bedrijfstoestel

Een ISO/IEC 27001-certificaat, een CyberFundamentals-attest of een assurance-rapport kan de inspanning beperken als het document geldig is en de dienst dekt. Controleer de uitgevende instantie, datums, locaties, activiteiten, uitsluitingen en eventuele voorbehouden. Een certificering neemt de risico’s die specifiek zijn voor uw configuratie, toegangen of contract niet weg.

14. Gegevensbescherming en bewaring

Wanneer de leverancier persoonsgegevens verwerkt, controleer dan de verwerkersovereenkomst, categorieën van gegevens, bewaartermijn, ondersteuning bij rechten van betrokkenen, beveiligingsmaatregelen en doorgiften. De AVG en NIS2 overlappen op bepaalde praktijken zonder hetzelfde te zijn. Betrek de DPO of juridisch advies bij complexe clausules en doorgiften.

15. Reversibiliteit, verwijdering en exit

Vraag hoe gegevens en configuraties kunnen worden geëxporteerd, in welk formaat, binnen welke termijn en tegen welke kosten die in het contract zijn vastgelegd. Voorzie in het intrekken van toegangen, het teruggeven van assets, aantoonbare verwijdering en transitieondersteuning. Een zeer beveiligde dienst die onmogelijk kan worden verlaten, blijft een continuïteitsrisico.

De diepgang van de controle aanpassen aan het risico

De beste controle is een controle die belangrijke onzekerheid vermindert zonder onnodig gevoelige documenten te vereisen. Een korte zelfverklaring kan volstaan voor een standaarddienst. Voor een leverancier met een hoog risico zijn gerichte bewijsstukken en een interview aangewezen. Een kritieke leverancier rechtvaardigt een diepgaandere gedocumenteerde review, tests, onafhankelijke assurance of een gecontroleerd auditrecht.

Bevindingen vertalen naar clausules en beslissingen

Een beoordeling zonder contractuele vertaling laat de belangrijkste risico’s zonder doeltreffende hefboom. 4. Bedrijfstoestel

Behandel minimaal toegang, vertrouwelijkheid, incidentmelding, samenwerking, continuïteit, back-ups, onderaannemers, belangrijke wijzigingen, reversibiliteit en verwijdering. Definieer wie bewijs kan opvragen, met welke voorafgaande kennisgeving en welke vertrouwelijkheidswaarborgen gelden. Een absoluut auditrecht kan bij een grote SaaS-provider onrealistisch zijn; een onafhankelijk rapport, een assurancegesprek en gerichte bewijsstukken kunnen alternatieven zijn.

Een reproduceerbare leveranciersreview organiseren

Een doeltreffende review volgt een gemeenschappelijke flow tussen business, aankoop, IT, security, legal en DPO. De business owner beschrijft het gebruik en de impact. IT bevestigt de integraties en toegangen. Aankoop verzamelt de documenten en onderhandelt. Security beoordeelt de controles. Legal en de DPO behandelen de clausules die binnen hun bevoegdheid vallen.

Bedrijfstoestel

Belgische situaties

Leveranciersprogramma’s mislukken wanneer ze formulieren opstapelen zonder de beslissingen te verbeteren.

1. Stuur 200 vragen naar iedereen. Vermoeidheid leidt tot generieke antwoorden en vertraagt de aankoop.
2. Een verklaring verwarren met bewijs. Vraag een relevante steekproef, geen ongedateerd “ja”.
3. 4. Bedrijfstoestel De dienst of regio kan uitgesloten zijn.
4. Aankoop, logistiek en privégebruik moeten worden geregeld. Noodaccounts, RMM-tools en partnerconsoles zijn kritiek.
5. Voor iedereen dezelfde termijnen vastleggen. Bij remediatie moet rekening worden gehouden met ernst, blootstelling en compenserende maatregelen.
6. De cascade in de toeleveringsketen negeren. Een robuuste leverancier kan afhankelijk zijn van een essentiële, slecht gedocumenteerde onderaannemer.
7. De exit nooit opnieuw testen. Een theoretische export kan onvolledig, onleesbaar of te traag zijn.
8. Het dossier na ondertekening archiveren. Zonder opvolging verlopen bewijzen en worden uitzonderingen permanent.

Een realistisch actieplan voor 30 dagen

In één maand kan een organisatie haar belangrijkste derde partijen identificeren, haar vereisten definiëren en prioritaire reviews opstarten. Ze kan binnen vier weken niet de conformiteit van een volledige complexe keten garanderen.

Week 1: inventariseren en classificeren

Verzamel contracten, facturen, SSO-verbindingen, beheerdersaccounts en applicaties. Wijs een business owner aan. Classificeer impact, gegevens, toegang en vervangbaarheid. Selecteer vijf tot tien leveranciers die het risico concentreren, in plaats van alfabetisch te beginnen.

Week 2: gerichte bewijsstukken opvragen

4. Bedrijfstoestel

Week 3: analyseren en beslissen

Vergelijk de bewijzen met de risico’s en verbintenissen. Formuleer elke afwijking met impact, aanbeveling, verantwoordelijke en datum. Laat uitzonderingen door het juiste bevoegdheidsniveau aanvaarden. Voor een omgeving met meerdere locaties of meerdere kritieke dienstverleners kan een Professionele Audit de verzameling van bewijzen, bevindingen en een geprioriteerde roadmap structureren zonder de oefening als een certificering voor te stellen.

Week 4: contractueel vastleggen en opvolgen

Werk de clausules bij bij de verlenging of via een addendum wanneer nodig. Registreer acties, reviewdatums en triggergebeurtenissen. Rapporteer aan het management over niet-afgedekte risico’s, afhankelijkheden zonder exitoplossing en de beslissingen die nodig zijn.