NIS2-leverancierscontracten met ISO 27001-bewijsmateriaal

Het is maandag 07:40. De CISO van een logistiek platform met cloudfunctionaliteit opent een e-mail van een leverancier voor managed detection and response. Het bericht is kort, voorzichtig en ongemakkelijk: de leverancier heeft verdachte toegang gedetecteerd tot een supportomgeving die door meerdere klanten wordt gebruikt. De details zijn beperkt. De leverancier belooft een update “zo spoedig als praktisch mogelijk”.

Om 08:15 vraagt de compliance manager of dit NIS2-rapportage kan activeren. Om 08:40 zoekt inkoop naar het contract. Om 09:10 wil de secretaris van de raad van bestuur een briefing over de verantwoordingsplicht van het management. Om 10:00 vraagt de juridische afdeling of het contract bepalingen bevat over melding binnen 24 uur, auditrechten, beheersmaatregelen voor onderaannemers, toegang tot bewijsmateriaal, verplichtingen voor bedrijfscontinuïteit, teruggave van gegevens en verwijdering.

Niemand wil tijdens een live incident ontdekken dat een overeenkomst met een kritieke leverancier niet verder gaat dan “redelijke beveiligingsmaatregelen”.

Hier houden NIS2-contractclausules voor leveranciers op juridische standaardtekst te zijn en worden zij operationele beheersmaatregelen. Voor essentiële en belangrijke entiteiten is leveranciersgovernance inmiddels onderdeel van bestuurlijke verantwoordingsplicht, bewijsmateriaal voor toezichthouders, paraatheid voor incidenten, assurance richting klanten, privacycompliance en weerbaarheidsplanning. Een ondertekend contract is niet voldoende. De organisatie moet aantonen dat leveranciersrisico’s zijn geïdentificeerd, goedgekeurd, behandeld, gemonitord en met bewijsmateriaal onderbouwd.

De aanpak van Clarysec begint met een eenvoudig principe: als een leveranciersclausule niet kan worden gemonitord, onderbouwd en getest, is het geen beheersmaatregel.

De Zenith Blueprint: een 30-stappenroadmap voor auditors plaatst leveranciersrelaties in de fase Beheersmaatregelen in de praktijk, stap 23, waarin overeenkomsten, monitoring, onboarding, herbeoordeling en auditbewijsmateriaal worden vertaald naar uitvoerbaar ISMS-werk. De Zenith Controls: de gids voor mapping over meerdere compliancekaders mapt vervolgens ISO/IEC 27002:2022-beheersmaatregelen voor leveranciers op NIS2, DORA, GDPR, NIST, COBIT 2019, ondersteunende ISO-normen en auditmethodologieën.

Het resultaat is een model voor leveranciersgovernance dat inkoop, juridische zaken, beveiliging, privacy en de raad van bestuur allemaal kunnen gebruiken.

Waarom NIS2 leverancierscontracten verandert in registraties van bewijsmateriaal

NIS2 Article 20 vereist dat leidinggevende organen van essentiële en belangrijke entiteiten maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren, toezicht houden op de implementatie daarvan en aansprakelijk zijn voor inbreuken. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentenafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving en onderhoud, beoordeling van doeltreffendheid, cyberhygiëne, cryptografie, personeelsbeveiliging, toegangscontrole, beheer van bedrijfsmiddelen en MFA waar passend.

Article 21(3) maakt leveranciers-due diligence expliciet. Organisaties moeten rekening houden met kwetsbaarheden die specifiek zijn voor directe leveranciers en dienstverleners, de algemene kwaliteit van producten en cyberbeveiligingspraktijken, en veilige ontwikkelprocedures.

Die formulering creëert een praktische verplichting: leveranciersrelaties moeten risicogebaseerd, contractueel afdwingbaar en beoordeelbaar zijn. Een leveranciersvragenlijst die in een map is opgeslagen, is niet voldoende. Een generiek contract zonder incidenttijdlijn, zonder rechten op bewijsmateriaal en zonder zicht op onderaannemers is niet voldoende. Een leverancierscertificering die niemand heeft beoordeeld, is niet voldoende.

ISO/IEC 27001:2022 biedt het operationele model. Clausules 4.1 tot en met 4.4 vereisen dat de organisatie haar context, belanghebbenden, wettelijke en contractuele verplichtingen, ISMS-toepassingsgebied en afhankelijkheden begrijpt. Clausules 5.1 tot en met 5.3 vereisen leiderschap, beleid, rollen en rapportage. Clausules 6.1.1 tot en met 6.1.3 vereisen risicobeoordeling, risicobehandeling en de Verklaring van Toepasselijkheid. Clausules 8.1 tot en met 8.3 vereisen operationele beheersing, herhaalde risicobeoordelingen en gedocumenteerde resultaten.

Voor leveranciersgovernance behoren de belangrijkste ISO/IEC 27002:2022 Annex A-beheersmaatregelen tot:

• A.5.19 Informatiebeveiliging in leveranciersrelaties
• A.5.20 Informatiebeveiliging opnemen in leveranciersovereenkomsten
• A.5.21 Informatiebeveiliging beheren in de ICT-toeleveringsketen
• A.5.22 Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten
• A.5.24 Planning en voorbereiding van incidentbeheer
• A.5.25 Beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen
• A.5.26 Respons op informatiebeveiligingsincidenten
• A.5.27 Leren van informatiebeveiligingsincidenten
• A.5.28 Verzameling van bewijsmateriaal
• A.5.29 Informatiebeveiliging tijdens verstoringen
• A.5.30 ICT-gereedheid voor bedrijfscontinuïteit
• A.5.31 Wettelijke, statutaire, regelgevende en contractuele vereisten
• A.5.34 Privacy en bescherming van persoonlijk identificeerbare informatie (PII)
• A.8.8 Beheer van technische kwetsbaarheden
• A.8.13 Informatieback-up
• A.8.15 Logging
• A.8.16 Monitoringactiviteiten
• A.8.24 Gebruik van cryptografie
• A.8.32 Wijzigingsbeheer

De kern is eigenaarschap. Een clausule heeft weinig waarde als niemand eigenaar is van het risico, niemand het bewijsmateriaal beoordeelt, niemand uitzonderingen opvolgt en niemand niet-naleving escaleert.

Het Enterprise Beleid voor beveiliging van derde partijen en leveranciers maakt dit expliciet:

“Rechten om te auditen, te inspecteren en beveiligingsbewijsmateriaal op te vragen”

Uit de sectie “Governancevereisten”, beleidsclausule 5.3.4.

Voor mkb-organisaties stelt het Beleid voor beveiliging van derde partijen en leveranciers voor het mkb dezelfde praktische verwachting:

“Auditrechten of de beschikbaarheid van compliancebewijsmateriaal”

Uit de sectie “Governancevereisten”, beleidsclausule 5.3.4.

Dit onderscheid is belangrijk. Een kleinere organisatie kan mogelijk niet elke grote cloudprovider op locatie auditen, maar zij kan wel toegang eisen tot assurancebewijsmateriaal, zoals het toepassingsgebied van ISO/IEC 27001:2022-certificering, SOC-rapporten, samenvattingen van penetratietesten, attesten voor remediatie van kwetsbaarheden, incidentsamenvattingen, testrapporten voor bedrijfscontinuïteit en bevestigingen van gegevensverwijdering.

De drie beheersmaatregelen als ruggengraat van NIS2-leveranciersassurance

In het model van Clarysec voor mapping over meerdere compliancekaders vormen drie ISO/IEC 27002:2022-beheersmaatregelen de ruggengraat van NIS2-leveranciersgovernance: 5.19, 5.20 en 5.22.

A.5.19 identificeert het leveranciersrisico

Beheersmaatregel A.5.19, Informatiebeveiliging in leveranciersrelaties, vormt de basis. Deze maatregel vereist dat organisaties informatie en bedrijfsmiddelen beschermen waartoe leveranciers toegang hebben, of die leveranciers verwerken, opslaan of beheren.

Zenith Controls classificeert dit als een preventieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid afdekt, met het cyberbeveiligingsconcept “Identify” en de operationele capability “Supplier Relationships Security”. De maatregel verbindt A.5.19 met A.5.20, A.5.21, A.5.14, A.5.36 en A.5.10. Praktisch betekent dit dat de organisatie leveranciersrisico identificeert, beveiligingsverwachtingen definieert, blootstelling in de ICT-toeleveringsketen beheerst, informatieoverdracht beschermt, compliance monitort en verplichtingen voor aanvaardbaar gebruik uitbreidt naar externe partijen.

Voor NIS2 mapt dit rechtstreeks op Article 21(2)(d) over beveiliging van de toeleveringsketen en Article 21(3) over leveranciers-due diligence. Voor GDPR ondersteunt het de vereiste om verwerkers te gebruiken die voldoende garanties bieden. Voor DORA ondersteunt het ICT-risicobeheer van derden, due diligence vóór contractsluiting, criticaliteitsbeoordeling, analyse van concentratierisico en toezicht gedurende de levenscyclus.

A.5.20 maakt de vereiste afdwingbaar

Beheersmaatregel A.5.20, Informatiebeveiliging opnemen in leveranciersovereenkomsten, zet beveiligingsverwachtingen om in contractuele verplichtingen. Zenith Controls legt de relatie tussen A.5.19 en A.5.20 helder uit:

“5.20 dient als contractuele formalisering van de beveiligingsbehoeften en risico’s die onder 5.19 zijn geïdentificeerd. Terwijl 5.19 ziet op het beoordelen van risico’s van derden en het definiëren van beveiligingsverwachtingen, zorgt 5.20 ervoor dat deze verwachtingen juridisch bindend zijn via contracten of Service Level Agreements (SLA’s). Zonder 5.20 zouden de in 5.19 geïdentificeerde beveiligingsmaatregelen niet afdwingbaar zijn.”

Hier worden NIS2-risicobesluiten omgezet in clausules: melding van inbreuken, auditrechten en rechten op bewijsmateriaal, encryptie, toegangscontrole, kwetsbaarhedenbeheer, goedkeuring van onderaannemers, beveiligde overdracht, continuïteit, samenwerking met toezichthouders, exitondersteuning en gegevensverwijdering.

A.5.22 toont aan dat het contract levend is

Beheersmaatregel A.5.22, Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten, voorkomt dat leveranciersassurance een eenmalige onboardingactiviteit wordt. Zenith Controls verbindt A.5.22 met A.5.19 en A.5.20, maar ook met A.5.29 informatiebeveiliging tijdens verstoringen, A.8.8 beheer van technische kwetsbaarheden, A.5.36 naleving van beleid, regels en normen voor informatiebeveiliging, A.5.15 toegangscontrole en A.8.27 veilige systeemarchitectuur en engineeringprincipes.

Dat is relevant omdat leveranciersdiensten veranderen. Gegevenslocaties veranderen. Subverwerkers veranderen. Kwetsbaarheden ontstaan. Certificeringen verlopen. Incidentpatronen worden zichtbaar. Een leverancier die vorig jaar aanvaardbaar was, kan vandaag te risicovol zijn.

Wat NIS2-contractclausules voor leveranciers moeten bevatten

De Zenith Blueprint, fase Beheersmaatregelen in de praktijk, stap 23, geeft een praktische set onderwerpen voor leveranciersovereenkomsten:

“Belangrijke onderwerpen die doorgaans in leveranciersovereenkomsten worden behandeld, zijn onder meer:

✓ vertrouwelijkheidsverplichtingen, waaronder reikwijdte, duur en beperkingen op verstrekking aan derden; ✓ verantwoordelijkheden voor toegangscontrole, zoals wie toegang heeft tot uw gegevens, hoe inloggegevens worden beheerd en welke monitoring plaatsvindt; ✓ technische en organisatorische maatregelen voor gegevensbescherming, encryptie, beveiligde overdracht, back-up en beschikbaarheidsverplichtingen; ✓ tijdlijnen en protocollen voor incidentmelding, vaak met gedefinieerde termijnen (bijvoorbeeld “melden binnen 24 uur”); ✓ auditrecht, waaronder frequentie, reikwijdte en toegang tot relevant bewijsmateriaal (bijvoorbeeld rapporten van penetratietesten, SoA, certificeringen); ✓ beheersmaatregelen voor onderaannemers, waarbij uw leverancier wordt verplicht gelijkwaardige beveiligingsverplichtingen door te leggen aan downstream partners; ✓ bepalingen voor het einde van het contract, zoals teruggave of vernietiging van gegevens, terugvordering van activa en deactivering van accounts.”

Uit de fase Beheersmaatregelen in de praktijk, stap 23: organisatorische beheersmaatregelen.

Een sterke NIS2-leveranciersclausule is specifiek genoeg om te testen. “Leverancier moet passende beveiliging handhaven” is zwak. “Leverancier moet het beveiligingscontact van de klant binnen 24 uur informeren over bevestigde of vermoedelijke incidenten die klantensystemen, klantgegevens, beschikbaarheid van diensten of wettelijke rapportageverplichtingen raken” is controleerbaar.

Incidentclausules moeten aansluiten op de NIS2-meldtermijn

NIS2 Article 23 introduceert een gefaseerd rapportagemodel voor significante incidenten: een vroegtijdige waarschuwing binnen 24 uur na kennisname, een incidentmelding binnen 72 uur, tussentijdse rapportages waar gevraagd en een eindrapport binnen één maand na de incidentmelding. Een significant incident is een incident dat ernstige operationele verstoring, financieel verlies of aanzienlijke materiële of immateriële schade aan anderen heeft veroorzaakt of kan veroorzaken.

Leverancierscontracten moeten die tijdlijn ondersteunen. Als een kritieke managed service provider vier dagen nodig heeft om te bevestigen of klantomgevingen zijn geraakt, kan de klant zijn eigen wettelijke meldtermijn missen.

Het Enterprise Beleid voor beveiliging van derde partijen en leveranciers vereist:

“Termijnen voor melding van inbreuken (bijvoorbeeld binnen 24 of 72 uur, afhankelijk van criticaliteit en regelgevende vereisten)”

Uit de sectie “Governancevereisten”, beleidsclausule 5.3.3.

Het mkb-Beleid voor beveiliging van derde partijen en leveranciers vereist eveneens gedefinieerde meldtermijnen voor inbreuken vanuit de sectie “Governancevereisten”, beleidsclausule 5.3.3.

Voor PII-incidenten verbindt het Enterprise Beleid voor incident- en datalekbeheer voor PII cyberbeveiligingsrapportage, financiële-sectorrapportage, klantrapportage en rapportage aan dienstontvangers:

“[Voorwaardelijk] De privacyverantwoordelijke / PIMS-manager MOET alle vereiste sectorale, cyberbeveiligings-, financiële-sector-, klant- of dienstontvangergerichte incidentrapportage coördineren wanneer een PII-incident met hoge impact een toepasselijke rapportagedrempel bereikt, en MOET de autoriteit, ontvanger, tijdlijn, indiening en het bewijsmateriaal van ontvangstbevestiging vastleggen in REG01 en REG10.”

Uit de sectie “Melding en communicatie”, beleidsclausule 4.4.6.

Dit is volwassen NIS2-bewijsmateriaal: niet alleen een meldingsmail, maar een registratie van de autoriteit, ontvanger, tijdlijn, indiening, ontvangstbevestiging, impact, oorzaakanalyse en opvolgacties.

Privacy- en DORA-afstemming zonder dubbele leveranciersprogramma’s

Veel NIS2-leveranciers verwerken ook persoonsgegevens. GDPR Article 28 vereist dat verwerkingsverantwoordelijken verwerkers gebruiken die voldoende garanties bieden en dat verwerkersverplichtingen in een schriftelijk contract worden vastgelegd. GDPR Article 5 vereist verantwoordingsplicht voor veilige en rechtmatige verwerking. De GDPR-verplichtingen rond datalekken vereisen ook snelle samenwerking wanneer leveranciersincidenten persoonsgegevens raken.

Het Enterprise Beleid voor beheer van verwerkers, subverwerkers en privacyrelaties met derden stelt de goedkeuringspoort vast:

“[Beide] De leveranciers-/inkoopeigenaar MOET ervoor zorgen dat contracten met verwerkers en subverwerkers vóór goedkeuring privacyondersteuning, beveiligingsassurance, een incidentinterface via PII15, teruggave of verwijdering via PII10, koppeling met doorgifte via PII13 en samenwerking bij audit of assurance omvatten.”

Uit de sectie “Beheersmaatregelen voor contracten en gedocumenteerde instructies”, beleidsclausule 4.3.6.

Het beleid vereist ook beoordeling van bewijsmateriaal vóór goedkeuring:

“[Alle] De informatiebeveiligingsverantwoordelijke MOET beveiligingsassurancebewijsmateriaal beoordelen voor elke relatie met een verwerker, subverwerker of derde partij met PII-toegang of hosting vóór goedkeuring, en MOET de uitkomst vastleggen in REG08 of REG12.”

Uit de sectie “Due diligence en risicobeoordeling”, beleidsclausule 4.2.2.

DORA voegt een extra laag toe wanneer de leverancier een financiële entiteit bedient. DORA Articles 28 tot en met 30 vereisen ICT-governance voor derden, registers van ICT-dienstverleningscontracten, risicogebaseerde due diligence, criticaliteitsbeoordeling, analyse van concentratierisico, audit- en inspectierechten, beëindigingsrechten, exitstrategieën en verplichte contractuele bepalingen. Article 30 is bijzonder relevant, omdat het contractinhoud vereist over dienstbeschrijvingen, locaties, gegevensbescherming, toegang en herstel, serviceniveaus, incidentondersteuning, samenwerking met autoriteiten, auditrechten, onderuitbesteding, noodmaatregelen en transitieondersteuning.

Het praktische antwoord is niet drie afzonderlijke leveranciersprogramma’s voor NIS2, GDPR en DORA. Het is één geharmoniseerd model voor leveranciersbewijsmateriaal, gemapt over kaders heen.

NIST CSF 2.0 is nuttig omdat de GOVERN-functie vereist dat afhankelijkheden, wettelijke verplichtingen, contractuele verplichtingen, risicobereidheid, beleid, verantwoordingsplicht en toezicht worden begrepen. De categorie voor de toeleveringsketen GV.SC omvat leveranciersrollen, criticaliteit, contractvereisten, due diligence, monitoring, opname in incidenten, monitoring gedurende de levenscyclus en bepalingen voor het einde van de relatie.

Een Clarysec-workflow voor onboarding van een kritieke leverancier

Stel dat u een aanbieder van beheerde beveiligingsdiensten onboardt die endpointtelemetrie gaat monitoren, waarschuwingen met gebruikersidentificatoren ontvangt en incidenttriage ondersteunt voor een organisatie die binnen de reikwijdte van NIS2 valt.

Stap 1: classificeer de leverancier

Leg de leverancier vast in uw leveranciersregister met de dienstbeschrijving, geraakte systemen en gegevens, betrokkenheid van PII, ondersteuning van essentiële of belangrijke diensten, geprivilegieerde toegang, landen van dienstverlening, onderaannemers, afhankelijkheden van vierde partijen, criticaliteitsclassificatie, risico-eigenaar, inkoopeigenaar en informatiebeveiligingsbeoordelaar.

Dit implementeert ISO/IEC 27001:2022 Clausules 4.2, 4.3, 6.1.2 en 8.1 door vereisten van belanghebbenden, afhankelijkheden, risico-eigenaarschap en operationele beheersing met elkaar te verbinden.

Stap 2: map het risico op de SoA

In de Zenith Blueprint, fase Risicomanagement, stap 13, raadt Clarysec aan om regelgeving in het risicoregister of de SoA kruisverwijzend op te nemen:

“Kruisverwijzing naar regelgeving: Als bepaalde beheersmaatregelen specifiek zijn geïmplementeerd om te voldoen aan GDPR, NIS2 of DORA, kunt u dat opnemen in het risicoregister (als onderdeel van de onderbouwing van de risico-impact) of in de SoA-notities.”

Uit de fase Risicomanagement, stap 13: planning van risicobehandeling en Verklaring van Toepasselijkheid.

Neem voor de MSSP ten minste A.5.19, A.5.20, A.5.21, A.5.22, A.5.24 tot en met A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 en A.8.24 op.

Stap 3: vereis afdwingbare clausules

Gebruik een beveiligingsaddendum voor leveranciers met eisen voor initiële incidentmelding binnen 24 uur, een gedetailleerde update binnen 72 uur, eindrapportage over incidenten, MFA voor geprivilegieerde toegang, persoonlijke gebruikersaccounts op naam, beheersmaatregelen voor onderaannemers, beveiligde overdracht, encryptie, assurancebewijsmateriaal, samenwerking met toezichthouders, BCP- en DR-bewijsmateriaal, exitondersteuning, teruggave of verwijdering van gegevens en intrekking van toegangsrechten.

Het Enterprise Beleid voor beheer van leveranciersafhankelijkheidsrisico’s bevat de continuïteitsvereiste:

“Waar van toepassing, een vereiste dat de leverancier zijn eigen bedrijfscontinuïteitsplannen (BCP/DRP) en incidentbeheerplannen onderhoudt, deze test en op verzoek samenvattingen of testrapporten aan ons verstrekt.”

Uit de sectie “Implementatievereisten”, beleidsclausule 6.8.4.

Stap 4: bouw het assurancebewijspakket

Vraag vóór goedkeuring om de ondertekende overeenkomst, SLA, het beveiligingsaddendum, de ISO/IEC 27001:2022-certificeringsscope of gelijkwaardige assurance, een SOC-rapport waar beschikbaar, een managementsamenvatting van penetratietesten, een samenvatting van kwetsbaarhedenbeheer, een samenvatting van incidentresponsprocedures, een BCP- of DR-testsamenvatting, attestatie van toegangscontrole en MFA, de lijst met onderaannemers, de procedure voor gegevensverwijdering en exit, en een DPA waar PII wordt verwerkt.

Het mkb-Beleid voor beveiliging van derde partijen en leveranciers maakt basaal contractueel bewijsmateriaal meetbaar:

“Ondertekende overeenkomsten en SLA’s”

Uit de sectie “Handhaving en naleving”, beleidsclausule 8.3.2.1.

Het beleid benoemt ook terugkerend leveranciersbewijsmateriaal:

“Geldige beveiligingscertificeringen of bijgewerkt bewijsmateriaal voor beheersmaatregelen”

Uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.3.1.2.

Voor bredere leveranciers-due diligence stelt het Beleid voor audit en compliancemonitoring:

“Leveranciers-due diligence moet een beoordeling omvatten van certificeringen (bijv. ISO 27001, SOC 2), beveiligingsvragenlijsten en incidentregistraties.”

Stap 5: monitor op basis van criticaliteit

Het Enterprise Beleid voor beheer van verwerkers, subverwerkers en privacyrelaties met derden vereist kwartaalmonitoring voor PII-relaties met hoog risico:

“[Alle] De leveranciers-/inkoopeigenaar MOET actieve hoog-risico-relaties met verwerkers en subverwerkers elk kwartaal monitoren en andere actieve PII-relaties met verwerkers en subverwerkers jaarlijks beoordelen aan de hand van due-diligencevoorwaarden, contractstatus, assurancestatus, openstaande kwesties en beoordelingsdatums in REG08.”

Uit de sectie “Doorlopende monitoring, ondersteuning, verstrekkingsinterface en exit”, beleidsclausule 4.5.1.

Zo wordt A.5.22 werkelijkheid. De beoordeling moet bepalen of de leverancier binnen de risicobereidheid blijft, of het bewijsmateriaal actueel is, of er openstaande kwesties zijn, of zich incidenten hebben voorgedaan en of wijzigingen in de dienstverlening een herbeoordeling vereisen.

Hoe auditors NIS2-leveranciersclausules testen

Auditors beginnen zelden met het lezen van uw beleid in isolatie. Zij nemen een steekproef van leveranciers en volgen het bewijsspoor.

Een ISO/IEC 27001:2022-auditor zal vragen naar de leveranciersinventaris, risicoclassificatie, leverancierscriteria, due-diligenceregistraties, contracten, bewijsmateriaal, SoA-mapping en monitoringhistorie. Voor Annex A 5.20 beoordeelt de auditor of de geselecteerde contracten afdwingbare clausules bevatten. Voor Annex A 5.22 test de auditor of rapportages zijn beoordeeld, uitzonderingen zijn vastgelegd en acties zijn opgevolgd.

Een bevoegde autoriteit onder NIS2 kan zich richten op de vraag of cyberbeveiligingspraktijken van leveranciers en veilige ontwikkelprocedures zijn beoordeeld op grond van Article 21(3). Een DORA-georiënteerde beoordelaar kan vragen naar vermeldingen in het ICT-contractregister, exitstrategieën, analyse van concentratierisico en verplichte bepalingen uit Article 30. Een privacyauditor kan verwerkerscontracten, doorlegverplichtingen voor subverwerkers, interfaces voor datalekken en bewijsmateriaal van voldoende garanties testen.

Het Enterprise PII-beveiligings- en toegangscontrolebeleid laat zien hoe toegangscontrole, kwetsbaarheden, configuratie, monitoring en cryptografie terugkoppelen naar ISO/IEC 27001:2022:

“ISO/IEC 27001:2022 — Clausule 6.1.3; Clausule 8.1; Annex A-beheersmaatregelen 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Behandeld door clausules [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].”

Uit de sectie “Referentienormen en -raamwerken”, beleidsclausule 13.9.

Wanneer een leverancier toegang heeft tot PII, geprivilegieerde systemen of monitoringgegevens, staat bewijsmateriaal voor toegangscontrole niet los van leveranciersassurance. Het maakt deel uit van hetzelfde auditspoor.

De inkoopvalkuil: ondertekende contracten zonder assuranceprocessen

De meest voorkomende tekortkoming in NIS2-leveranciersgovernance is niet het ontbreken van contracten. Het is de kloof tussen contracttaal en dagelijkse uitvoering.

Een contract kan jaarlijkse samenvattingen van penetratietesten vereisen, maar geen eigenaar vraagt ze op. Het kan incidentmelding binnen 24 uur vereisen, maar de leverancier heeft alleen een generiek supportadres. Het kan goedkeuring van onderaannemers vereisen, maar inkoop ontvangt nooit wijzigingsmeldingen. Het kan auditrechten bevatten, maar de organisatie heeft geen proces om uitzonderingen in SOC-rapporten te beoordelen. Het kan gegevensverwijdering bij exit vereisen, maar IT valideert nooit de deactivering van accounts.

De Zenith Blueprint, fase Beheersmaatregelen in de praktijk, stap 23, legt uit hoe leveranciersbeheersmaatregelen tot leven komen:

“In de praktijk komt deze beheersmaatregel tot leven via:

✓ leveranciersrisicobeoordelingen, ✓ due-diligencevragenlijsten vóór opdrachtverlening, ✓ contractsjablonen met ingebedde beveiligingsvoorwaarden, ✓ onboardingchecklists voor leveranciers die toegangsverlening en inrichting van monitoring omvatten, ✓ doorlopende herbeoordelingen, vooral wanneer de leveranciersscope wijzigt, incidenten optreden of verlengingen aanstaande zijn.

En deze beheersmaatregel stopt niet bij eerstelijnsleveranciers. Uw leverancier kan zelf uitbesteden aan eigen aanbieders, en u kunt het risico nog steeds dragen.”

Dat is de NIS2-boodschap op bestuursniveau: uitbesteding van dienstverlening betekent niet dat verantwoordingsplicht wordt uitbesteed.

Remediatiechecklist voor NIS2-leverancierscontracten

Begin met uw 20 meest kritieke leveranciers en voer gerichte remediatie uit:

• Identificeer leveranciers die essentiële of belangrijke diensten ondersteunen.
• Bevestig of elke leverancier PII verwerkt, gereguleerde diensten ondersteunt of geprivilegieerde toegang heeft.
• Wijs een bedrijfseigenaar, inkoopeigenaar en beveiligingsbeoordelaar toe.
• Verifieer dat de leveranciersrisicobeoordeling actueel is en aansluit op de feitelijke scope van de dienstverlening.
• Bevestig dat het contract clausules bevat voor beveiligingsbaseline, incidentmelding, auditrechten of rechten op bewijsmateriaal, beheersmaatregelen voor onderaannemers, continuïteit, beveiligde overdracht, toegangscontrole, samenwerking bij kwetsbaarheden en exit.
• Bevestig waar relevant dat de meldtermijnen voor inbreuken de escalatiebehoeften van 24 uur en 72 uur ondersteunen.
• Vraag bijgewerkt assurancebewijsmateriaal op, waaronder certificeringen, SOC-rapporten, samenvattingen van penetratietesten, BCP- of DR-tests en incidenthistorie.
• Beoordeel bewijsmateriaal; sla het niet alleen op.
• Registreer uitzonderingen en wijs eigenaren voor remediatie toe.
• Werk de SoA en het risicoregister bij wanneer leveranciersbeheersmaatregelen NIS2, GDPR, DORA of klantverplichtingen ondersteunen.
• Plan de monitoringfrequentie op basis van de criticaliteit van de leverancier.
• Test één escalatiepad voor leveranciersincidenten.
• Test één beëindigingspad voor leveranciers, inclusief teruggave van gegevens, verwijdering, terugvordering van activa en intrekking van toegangsrechten.

Als u deze punten voor een kritieke leverancier niet kunt aantonen, is het contract nog niet auditgereed.

Zet leveranciersclausules om in bewijsmateriaal voor toezichthouders

NIS2-leveranciersgovernance is nu een actuele operationele discipline. Toezichthoudende autoriteiten, klanten, certificeringsauditors, privacyteams, partners in de financiële sector en raden van bestuur zullen niet alleen vragen of leveranciersclausules bestaan. Zij zullen vragen of de clausules risicogebaseerd, afdwingbaar, gemonitord, met bewijsmateriaal onderbouwd en verbonden zijn met incidentrapportage, continuïteit, toegangscontrole, kwetsbaarhedenbeheer, doorlegverplichtingen voor onderaannemers en exit.

Clarysec helpt organisaties die kloof te dichten met de Zenith Blueprint om leveranciersbeheersmaatregelen om te zetten in ISMS-fasen, risicobehandeling, SoA-vermeldingen, onboardingroutines en auditbewijsmateriaal. Zenith Controls mapt ISO/IEC 27002:2022-leveranciersbeheersmaatregelen A.5.19, A.5.20 en A.5.22 op NIS2, DORA, GDPR, NIST, COBIT 2019, ondersteunende ISO-normen en auditmethodologieën. Clarysec-beleid voor leveranciers en privacy biedt de clausulestructuur, verwachtingen voor bewijsmateriaal en monitoringroutines die leveranciersassurance verdedigbaar maken.

Uw volgende actie is eenvoudig: selecteer vijf kritieke leveranciers, neem een steekproef van hun contracten, map elke clausule op ISO/IEC 27001:2022-risicobehandeling en Annex A-beheersmaatregelen, vraag actueel assurancebewijsmateriaal op en voer een tabletop-oefening uit voor incidentmelding binnen 24 uur. Als het bewijsspoor breekt, geven de toolkits van Clarysec u de structuur om dit te herstellen voordat een incident, klantbeoordeling of verzoek van een toezichthouder dat voor u doet.