SLA’s voor remediatie van kwetsbaarheden voor NIS2 en DORA

Om 08:17 op een dinsdagochtend begin 2026 ontvangt Anna, de CISO van een snelgroeiende fintech, het eerste bericht nog voordat haar koffie op is.

Het SOC heeft signalen van discussies over actieve exploitatie vastgesteld rond een kwetsbaarheid in een klantgerichte API-gateway. Engineering geeft aan dat de patch beschikbaar is, maar risicovol, omdat de gateway vóór de betaalworkflows staat. De compliance manager stuurt een formeel verzoek door van een nationale bevoegde autoriteit die vraagt om bewijsmateriaal voor “vulnerability handling and disclosure” en om bewijs dat het proces de afgelopen 12 maanden doeltreffend is geweest. Inkoop voegt een derde probleem toe: de gateway wordt beheerd door een MSP, en in het contract staat alleen dat de leverancier “security updates in a timely manner” zal toepassen.

Om 09:00 is dit niet langer alleen een patchingvraagstuk. Het is een bewijsvraagstuk voor ISO/IEC 27001:2022, een NIS2-cyberhygiënevraagstuk, een ICT-risicobeheervraagstuk onder DORA, een leveranciersgovernancevraagstuk en mogelijk een incidentmeldingsvraagstuk als exploitatie gevolgen heeft voor de continuïteit van diensten of voor persoonsgegevens.

Dit is het praktische compliancehiaat waarmee veel organisaties in 2026 te maken krijgen. Ze hebben scanners, dashboards, tickets en patchtools, maar kunnen de auditvragen niet duidelijk beantwoorden:

• Wie heeft de remediatie-SLA goedgekeurd?
• Hoe is de SLA risicogebaseerd?
• Wat gebeurt er wanneer een kritieke patch de deadline mist?
• Hoe krijgen vanaf internet bereikbare bedrijfsmiddelen prioriteit?
• Hoe worden leveranciers aan dezelfde termijnen gehouden?
• Waar staat de registratie van risicoacceptatie voor een niet-gepatcht systeem?
• Welk bewijsmateriaal toont aan dat de beheersmaatregel daadwerkelijk heeft gewerkt, en niet alleen bestond?

Het antwoord is niet nog een spreadsheet met vervaldatums. SLA’s voor remediatie van kwetsbaarheden moeten worden beheerd als een levend beheersingssysteem dat eigenaarschap van bedrijfsmiddelen, kwetsbaarheidsscores, dreigingsinformatie, wijzigingsbeheer, leveranciers-SLA’s, afhandeling van uitzonderingen, monitoring, incidentrespons en directiebeoordeling met elkaar verbindt.

Daar worden Clarysec’s Enterprise Beleid voor kwetsbaarheden- en patchbeheer (VPMP), mkb Beleid voor kwetsbaarheden- en patchbeheer voor mkb (VPMP-SME), Beleid voor beveiliging van derde partijen en leveranciers voor mkb (TPSSP-SME), Zenith Blueprint (ZB) en Zenith Controls (ZC) nuttig. Samen maken zij van “sneller patchen” een verdedigbaar governanceproces dat bestand is tegen audittoetsing volgens ISO, NIS2, DORA, GDPR, NIST en de ISACA-benadering.

Waarom SLA’s voor remediatie van kwetsbaarheden bewijsmateriaal op bestuursniveau zijn geworden

Remediatie van kwetsbaarheden werd vroeger behandeld als een IT-hygiënemetriek. In 2026 ligt het dichter bij een gereguleerde verplichting voor operationele weerbaarheid.

NIS2 maakt cyberbeveiliging tot een kwestie van verantwoordingsplicht van het management. Essentiële en belangrijke entiteiten moeten beschikken over bestuursorganen die cyberbeveiligingsrisicobeheersmaatregelen goedkeuren, toezicht houden op de implementatie en training ontvangen, zodat zij risico’s en de impact van beveiligingspraktijken op diensten begrijpen. NIS2 Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentenafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving en onderhoud, afhandeling en openbaarmaking van kwetsbaarheden, cyberhygiëne, training, toegangscontrole, beheer van bedrijfsmiddelen en authenticatie.

Voor financiële entiteiten is DORA het gespecialiseerde regime voor digitale operationele weerbaarheid. Het vereist governance- en beheersingsregelingen voor ICT-risico, waarbij het bestuursorgaan ICT-risicobeheer definieert, goedkeurt, bewaakt en er verantwoordelijk voor blijft. Het vereist ook identificatie van ICT-activa en afhankelijkheden, beschermende en preventieve beheersmaatregelen zoals patching en wijzigingsbeheer, beheer van ICT-gerelateerde incidenten, testen van digitale operationele weerbaarheid en risicobeheer voor ICT-dienstverleners van derden.

De praktische impact is aanzienlijk. Een gemiste patchtermijn kan wijzen op falen van:

• Governance, als het management geen risicogebaseerde SLA’s heeft goedgekeurd
• Beheer van bedrijfsmiddelen, als de systeemeigenaar van het getroffen systeem onbekend is
• Wijzigingsbeheer, als noodpatching niet beheerst verloopt
• Leveranciersmanagement, als de termijnen van de dienstverlener vaag zijn
• Incidentrespons, als signalen van exploitatie niet worden getrieerd
• Beheer van bewijsmateriaal, als tickets en logboeken sluiting niet kunnen aantonen
• Risicobehandeling, als uitzonderingen niet zijn goedgekeurd en beoordeeld

ISO/IEC 27001:2022 biedt de ruggengraat van het managementsysteem. Clausules 4.1 tot en met 4.3 vereisen dat organisaties interne en externe kwesties, eisen van belanghebbenden, wettelijke en contractuele verplichtingen en interfaces met andere organisaties begrijpen. Clausules 6.1.1 tot en met 6.1.3 vereisen risicobeoordeling, risicobehandeling, een Verklaring van Toepasselijkheid en goedkeuring van restrisico door de risico-eigenaar. Clausules 9.1, 9.2, 9.3, 10.1 en 10.2 vereisen monitoring, interne audit, directiebeoordeling, voortdurende verbetering, corrigerende maatregelen en bewaard bewijsmateriaal.

Kort gezegd: als u wilt dat SLA’s voor remediatie van kwetsbaarheden auditklaar zijn, moeten zij onderdeel zijn van het ISMS, niet alleen een DevOps-metriek.

Het SLA-model dat auditors verwachten

Een SLA voor remediatie van kwetsbaarheden moet drie vragen beantwoorden:

1. Hoe snel moeten we handelen?
2. Wie is verantwoordelijk?
3. Welk bewijsmateriaal toont de uitkomst aan?

Het Beleid voor kwetsbaarheden- en patchbeheer definieert een praktisch startpunt voor risicogebaseerde remediatietermijnen:

De organisatie moet alle gedetecteerde kwetsbaarheden classificeren met een gestandaardiseerde methodologie (bijv. CVSS v3.x) en remediatietermijnen toepassen die zijn afgestemd op bedrijfskritikaliteit: 5.2.1 Kritiek (CVSS 9.0-10.0): onmiddellijke beoordeling; patchtermijn van maximaal 72 uur. 5.2.2 Hoog (7.0-8.9): respons binnen 48 uur; patchtermijn van 7 kalenderdagen. 5.2.3 Middel (4.0-6.9): respons binnen 5 dagen; patchtermijn van 30 kalenderdagen. 5.2.4 Laag (<4.0): respons binnen 10 dagen; patchtermijn van 60 kalenderdagen.

Deze clausule is krachtig omdat zij responstijd scheidt van patchtermijn. Een kwetsbaarheid met hoge ernst mag niet zes dagen onopgemerkt blijven en vervolgens op dag zeven worden gepatcht. De responsklok bevestigt triage, eigenaarschap, impactbeoordeling en remediatieplanning. De patchtermijn bevestigt technische sluiting of een goedgekeurde uitzondering.

Voor kleinere organisaties gebruikt het Beleid voor kwetsbaarheden- en patchbeheer voor mkb eenvoudiger, maar nog steeds auditeerbare taal:

Kritieke patches moeten binnen 3 dagen na vrijgave worden toegepast, vooral voor systemen die vanaf internet bereikbaar zijn

En voor het bredere patchlandschap:

Alle overige patches moeten binnen 30 dagen worden toegepast, tenzij een geldige uitzondering is gedocumenteerd

Het punt is niet dat elke organisatie identieke deadlines moet hanteren. ISO/IEC 27001:2022, NIS2 en DORA ondersteunen allemaal proportionaliteit. Het punt is dat remediatie-SLA’s moeten worden gedefinieerd, goedgekeurd, risicogebaseerd, gemonitord en met bewijsmateriaal onderbouwd.

Hier gaat het bij veel bedrijven mis. Zij definiëren de SLA, maar niet het bewijsmateriaal. Vanuit het perspectief van een auditor is beleid zonder operationele registraties een belofte, geen beheersmaatregel.

Eigenaarschap van bedrijfsmiddelen is de verborgen afhankelijkheid

Een scanner kan u vertellen dat een CVE op een server aanwezig is. Hij kan u niet vertellen of de server een kritiek betalingsproces ondersteunt, bijzondere categorieën persoonsgegevens opslaat, verbinding maakt met een afwikkelingsprovider of gepland staat voor buitengebruikstelling.

Die context komt uit beheer van bedrijfsmiddelen, gegevensclassificatie, leveranciersinventaris en risicobeoordeling.

ISO/IEC 27001:2022 Annex A-beheersmaatregel 8.8, Beheer van technische kwetsbaarheden, staat centraal, maar werkt niet op zichzelf. De maatregel is sterk afhankelijk van configuratiebeheer, wijzigingsbeheer, leveranciersmonitoring, cloudgovernance, logging, monitoring en risicobehandeling.

NIST CSF 2.0 formuleert hetzelfde probleem in termen van uitkomsten. De GOVERN-functie verwacht dat wettelijke, regelgevende en contractuele cyberbeveiligingseisen worden begrepen en beheerd, dat risicobereidheid en risicotolerantie worden gedocumenteerd, dat rollen en middelen worden toegewezen en dat cyberbeveiligingsbeleid wordt vastgesteld, toegepast, beoordeeld en geactualiseerd. IDENTIFY-uitkomsten omvatten inventarissen van hardware, software, diensten, systemen, gegevens en levenscycli, naast identificatie van kwetsbaarheden, risicoanalyse, uitzonderingsbeheer en processen voor openbaarmaking van kwetsbaarheden.

In Anna’s dinsdagochtendscenario is de eerste technische vraag: “waar bevindt zich de kwetsbare component?” De eerste governancevraag is: “welke dienst en welk risico raakt dit?”

De Zenith Blueprint, fase Risicobeheer, stap 13: Risicobehandelingsplanning en Verklaring van Toepasselijkheid, adresseert dit door risico’s te koppelen aan beheersmaatregelen, eigenaren en tijdlijnen:

Wijs ook voor elke actie een Eigenaar en Tijdlijn toe (eventueel in een aparte kolom of in de opmerkingen). Bijvoorbeeld: “Eigenaar: IT-manager, Tijdlijn: uiterlijk Q3 2025.” Daarmee wordt het een echt plan.

Dat is precies wat remediatie van kwetsbaarheden vereist. Een bevinding zonder eigenaar wordt backlogruis. Een bevinding met een eigenaar, tijdlijn, risicobehandelingsbesluit en bewijsroute wordt een auditeerbare beheersmaatregel.

Hoe Zenith Controls de relaties tussen beheersmaatregelen in kaart brengt

Zenith Controls behandelt ISO/IEC 27002:2022 beheersmaatregel 8.8, Beheer van technische kwetsbaarheden, als een preventieve beheersmaatregel ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid. De maatregel wordt gekoppeld aan de cyberbeveiligingsconcepten Identify en Protect, de operationele capability voor dreigings- en kwetsbaarhedenbeheer en de beveiligingsdomeinen governance, ecosysteem, bescherming en verdediging.

Dit is relevant omdat remediatie-SLA’s niet alleen een beschermingsmechanisme zijn. Ze zijn ook een governancemechanisme en een ecosysteemmechanisme. Uw blootstelling wordt gevormd door leveranciers, cloudplatformen, managed services, opensourcecomponenten en vanaf internet bereikbare afhankelijkheden.

Zenith Controls koppelt 8.8 aan meerdere ondersteunende beheersmaatregelen:

Zenith Controls koppelt kwetsbaarhedenbeheer ook aan ISO/IEC 27005:2024, met name aan identificatie van kwetsbaarheden en risicoscenario’s met niet-gepatchte systemen. Dit versterkt het argument dat patchtermijnen risicogebaseerd moeten zijn, niet willekeurig. Het koppelt leveranciersmonitoring ook aan ISO/IEC 27036-4:2016 voor beveiligingsniveaus in clouddienstovereenkomsten en aan ISO/IEC 20000-1:2018 voor planning van dienstverlening en wijzigingsbeheer.

Die structuur over meerdere normen heen is belangrijk tijdens audits. Als een organisatie zegt: “kritieke kwetsbaarheden worden binnen 72 uur gepatcht”, zal de auditor toetsen of die uitspraak wordt ondersteund door risicobeoordeling, classificatie van bedrijfsmiddelen, leveranciersverplichtingen, wijzigingsregistraties en monitoringbewijsmateriaal.

NIS2-cyberhygiëne: van kwetsbaarheidsafhandeling naar corrigerende maatregelen

NIS2 Article 21 vereist een all-hazards-benadering voor netwerk- en informatiesystemen. Voor SLA’s voor remediatie van kwetsbaarheden zijn meerdere elementen van Article 21 direct relevant:

• Risicoanalyse en beveiligingsbeleid voor informatiesystemen
• Incidentenafhandeling
• Bedrijfscontinuïteit en crisisbeheer
• Beveiliging van de toeleveringsketen
• Veilige verwerving, ontwikkeling en onderhoud, inclusief afhandeling en openbaarmaking van kwetsbaarheden
• Procedures om de doeltreffendheid van cyberbeveiliging te beoordelen
• Basiscyberhygiëne en training
• Toegangscontrole en beheer van bedrijfsmiddelen
• Multifactorauthenticatie of continue authenticatie waar passend

NIS2 Article 20 maakt bestuursorganen verantwoordelijk voor het goedkeuren van en toezicht houden op cyberbeveiligingsrisicobeheersmaatregelen. Dat betekent dat metrieken voor remediatie van kwetsbaarheden niet alleen in een engineeringdashboard mogen staan. Ze moeten terugkomen in managementrapportages, risicocommissiestukken of registraties van ISMS-managementbeoordelingen.

Article 21 verwacht ook dat entiteiten die niet-naleving van vereiste maatregelen vaststellen, zonder onnodige vertraging corrigerende maatregelen nemen. Die formulering is belangrijk. Als uw dashboard achterstallige kritieke kwetsbaarheden toont, mag het compliancebewijs niet stoppen bij “we weten het”. Het moet escalatie, risicobeoordeling, zichtbaarheid voor het management, corrigerende maatregelen en herbeoordeling laten zien.

NIS2 Article 23 voegt nog een dimensie toe. Als exploitatie van een niet-gepatchte kwetsbaarheid ernstige operationele verstoring, financieel verlies of schade aan andere personen veroorzaakt of kan veroorzaken, kan dit een significant incident worden. De rapportagelevenscyclus omvat een vroege waarschuwing binnen 24 uur nadat men kennis heeft gekregen van het significante incident, incidentmelding binnen 72 uur, tussentijdse rapportages op verzoek en een eindrapport binnen één maand na de incidentmelding. Dat eindrapport moet ernst, impact, vermoedelijke oorzaakanalyse, mitigerende maatregelen en, waar van toepassing, grensoverschrijdende impact bevatten.

Het SLA-proces moet dus verbonden zijn met incidentrespons. Een kritieke kwetsbaarheid met bewijsmateriaal van actieve exploitatie moet beveiligingstriage, monitoring, bewaring van bewijsmateriaal en een rapportagebeoordeling activeren, niet alleen een regulier patchticket.

DORA ICT-risico: remediatietermijnen als bewijsmateriaal voor weerbaarheid

Voor financiële entiteiten geldt DORA vanaf 17 januari 2025 en creëert het uniforme eisen voor ICT-risicobeheer, melding van majeure ICT-gerelateerde incidenten, testen van digitale operationele weerbaarheid, informatiedeling en risicobeheer voor ICT-dienstverleners van derden. Voor gedekte financiële entiteiten die onder nationale NIS2-regels zijn geïdentificeerd, wordt DORA behandeld als de sectorspecifieke rechtshandeling van de EU.

Het operationele model van DORA ligt dicht bij een geïntegreerd ISMS. Articles 5 en 6 vereisen governance, beleid, procedures, tools, jaarlijkse of periodieke beoordeling, audit, remediatie van kritieke auditbevindingen en een strategie voor digitale operationele weerbaarheid. Article 8 vereist identificatie en inventarisatie van door ICT ondersteunde bedrijfsfuncties, informatieactiva, ICT-activa, afhankelijkheden, processen van derden en legacy-ICT-risico’s. Article 9 vereist beschermende en preventieve beheersmaatregelen, waaronder patching en wijzigingsbeheer. Articles 11 en 12 vereisen continuïteit, respons, herstel, back-up, herstelactiviteiten en hersteldoelstellingen.

DORA Articles 17 tot en met 19 vereisen een beheerproces voor ICT-gerelateerde incidenten dat detecteert, beheert, registreert, classificeert, escaleert, rapporteert, communiceert, oorzaakanalyse uitvoert en veilige bedrijfsvoering herstelt. Articles 24 tot en met 26 vereisen testen van digitale operationele weerbaarheid, inclusief passende testen van ICT-tools en -systemen, kwetsbaarheidsbeoordelingen, beoordelingen van netwerkbeveiliging, gap-analyses, broncodebeoordelingen waar haalbaar, penetratietesten en dreigingsgestuurde penetratietesten voor bepaalde financiële entiteiten. Articles 28 en 30 vereisen beheer van ICT-risico’s van derden, registers van ICT-dienstverleningscontracten, due diligence, audit- en inspectierechten, serviceniveaus, assistentie door providers tijdens incidenten, beëindigingsrechten en exitregelingen.

Voor remediatie-SLA’s verandert DORA de verwachtingen voor bewijsmateriaal op drie manieren.

Ten eerste moeten kwetsbaarheidsbevindingen uit testen terechtkomen in een geprioriteerd remediatieproces. Een scanrapport alleen is niet genoeg.

Ten tweede moet remediatie van kritieke bevindingen via governance en audit worden gevolgd. DORA verwacht formele remediatie van kritieke auditbevindingen voor niet-micro-ondernemingen.

Ten derde moeten ICT-dienstverleners van derden aan meetbare verplichtingen worden gehouden. Als uw cloud-, SaaS- of MSP-provider het patchvenster beheerst, moeten uw contract en register laten zien hoe hun remediatietermijnen uw weerbaarheidsverplichtingen ondersteunen.

Het Beleid voor kwetsbaarheden- en patchbeheer adresseert dit rechtstreeks:

Patching door derden en toezicht op SaaS-risico 6.6.1 Alle systemen van derden (SaaS, PaaS, door MSP beheerd) moeten aantonen dat zij beschikken over toereikende beheersmaatregelen voor kwetsbaarheden- en patchbeheer. 6.6.2 Leveranciers-SLA’s moeten remediatietermijnen bevatten die gelijkwaardig zijn aan intern gedefinieerde, op kritikaliteit gebaseerde drempels.

Die clausule is vaak de ontbrekende brug tussen intern ISO-bewijsmateriaal en DORA-toezicht op leveranciers.

GDPR: wanneer patchvertragingen falen in verantwoordingsplicht voor persoonsgegevens worden

GDPR is geen standaard voor kwetsbaarhedenbeheer, maar verandert wel de gevolgen van patchfalen.

GDPR Article 5 vereist dat persoonsgegevens veilig worden verwerkt en dat de verwerkingsverantwoordelijke naleving kan aantonen. Article 32 vereist passende technische en organisatorische maatregelen om een beveiligingsniveau te waarborgen dat op het risico is afgestemd. Wanneer niet-gepatchte systemen persoonsgegevens verwerken, vooral identiteitsgegevens, financiële gegevens, biometrische gegevens, gezondheidsgegevens, personeelsgegevens of KYC-informatie, worden remediatie-SLA’s onderdeel van de verantwoordingsplicht voor beveiliging van de verwerking.

Een vertraagde patch kan verdedigbaar zijn als het risico is beoordeeld, compenserende beheersmaatregelen zijn toegepast en het restrisico door de juiste persoon is geaccepteerd. Dat is veel moeilijker te verdedigen als de kwetsbaarheid achterstallig was, vanaf internet bereikbaar was en geen eigenaar had.

Zenith Controls koppelt kwetsbaarhedenbeheer aan GDPR Articles 32 en 5(1)(f), omdat tijdige patching risico’s voor de vertrouwelijkheid en integriteit van persoonsgegevens vermindert. Het koppelt wijzigingsbeheer ook aan GDPR Article 24 en Article 32, omdat wijzigingen aan systemen die persoonsgegevens verwerken risicobeoordeeld, goedgekeurd, gedocumenteerd en beoordeeld moeten worden.

De complianceles is duidelijk: als persoonsgegevens betrokken zijn, moet uw patchbewijsmateriaal de gegevenscontext bevatten. Auditors en toezichthouders zullen niet alleen vragen “is het gepatcht?”, maar ook “welke gegevens stonden bloot aan risico, hoe lang, en welke beheersmaatregelen hebben dat risico beperkt?”

Een praktische Clarysec-workflow voor auditklaar SLA-bewijsmateriaal

Een volwassen proces voor remediatie van kwetsbaarheden begint niet wanneer een auditor om registraties vraagt. Het is ontworpen om elke maand registraties op te leveren.

Stap 1: Keur het SLA-beleid goed

Begin met het Beleid voor kwetsbaarheden- en patchbeheer of het Beleid voor kwetsbaarheden- en patchbeheer voor mkb, afhankelijk van uw operationele model. Stem SLA-drempels af op uw risicobereidheid, regelgevingsscope, servicekritikaliteit, gegevensgevoeligheid en technische beperkingen. Zorg voor goedkeuring door de CISO, risicocommissie of het bestuursorgaan.

Gebruik voor enterprise-omgevingen CVSS, kritikaliteit van bedrijfsmiddelen, exploiteerbaarheid, internetblootstelling, gegevensgevoeligheid en bedrijfsimpact. Houd het model voor mkb eenvoudig maar expliciet: kritieke patches binnen drie dagen, overige patches binnen 30 dagen tenzij er een geldige uitzondering bestaat.

Stap 2: Koppel bedrijfsmiddelen aan eigenaren en kritieke diensten

Elke kwetsbaarheidsbevinding moet te herleiden zijn tot:

• Naam en unieke identifier van het bedrijfsmiddel
• Bedrijfsdienst of toepassing
• Systeemeigenaar
• Technische eigenaar
• Gegevensclassificatie
• Internetblootstelling
• Leveranciersafhankelijkheid, indien van toepassing
• Kritikaliteit van de ondersteunde functie

Dit ondersteunt risico-eigenaarschap onder ISO/IEC 27001:2022, beheer van bedrijfsmiddelen onder NIS2, de ICT-asset- en afhankelijkhedeninventaris onder DORA en IDENTIFY-uitkomsten van NIST CSF.

Stap 3: Trieer de kwetsbaarheid

Maak een ticket aan voor elke bevinding of gegroepeerde set bevindingen. Neem CVSS-score, bronscanner, getroffen bedrijfsmiddel, exploitatiestatus, dreigingsinformatie, bedrijfskritikaliteit en vereiste SLA op. Als exploitatie wordt vermoed, koppel het ticket dan aan een incidentbeoordeling.

Stap 4: Voer uit via wijzigingsbeheer

Patching is een wijziging. Gebruik een standaardwijziging voor routinematige updates en een noodwijziging voor kritieke, actief misbruikte kwetsbaarheden. Neem testbewijsmateriaal, goedkeuring, implementatietijdstempel, rollbackplan en validatie na wijziging op.

Dit sluit aan op de relatie die Zenith Controls legt tussen 8.8 en 8.32, waarbij het toepassen van patches via wijzigingsbeheer wordt beheerst om urgentie en operationele stabiliteit in balans te brengen.

Stap 5: Valideer sluiting

Sluit tickets niet alleen op basis van “patch geïnstalleerd”. Vereis validatie via herscannen, versiebevestiging, configuratieverificatie of bevestiging van compenserende beheersmaatregelen. Open een uitzondering wanneer de patch niet kan worden toegepast.

Stap 6: Registreer uitzonderingen en restrisico

Het Beleid voor kwetsbaarheden- en patchbeheer definieert de vereiste inhoud van uitzonderingen:

Uitzonderingsaanvragen moeten het volgende bevatten: 7.2.1 Zakelijke rechtvaardiging voor de vertraging of niet-remediatie 7.2.2 Risicobeoordeling (op basis van CVSS, kritikaliteit van bedrijfsmiddelen, dreigingsinformatie) 7.2.3 Voorgestelde compenserende beheersmaatregelen 7.2.4 Tijdlijn voor remediatie of herbeoordeling

Het beleid definieert ook goedkeuring en beoordeling:

Uitzonderingen moeten worden goedgekeurd door de CISO of gedelegeerde risicocommissie en worden vastgelegd in het ISMS-uitzonderingenregister, met een beoordelingsinterval van maximaal 90 dagen.

Dat uitzonderingenregister wordt essentieel bewijsmateriaal voor ISO/IEC 27001:2022 Clause 6.1.3 risicobehandeling en restrisicoacceptatie, evenals voor directiebeoordeling.

Deze registratie toont aan dat de organisatie de kwetsbaarheid niet heeft genegeerd. Zij heeft het risico beoordeeld, compenserende beheersmaatregelen toegepast, restrisico goedgekeurd en een beoordelingsdatum vastgesteld.

Stap 7: Stel het maandelijkse bewijspakket samen

Uw maandelijkse bewijspakket voor remediatie van kwetsbaarheden moet het volgende bevatten:

Voor mkb kan het bewijsmateriaal lichter zijn, maar het moet nog steeds consistent zijn. Het Beleid voor kwetsbaarheden- en patchbeheer voor mkb vereist patchlogboeken met traceerbaarheid:

Logboeken moeten de apparaatnaam, toegepaste update, patchdatum en reden voor eventuele vertraging bevatten

Die ene clausule is goud waard voor audits. Zij maakt van patching geen claim, maar een registratie.

Patching door leveranciers: het contract moet aansluiten op uw SLA

Als een MSP, SaaS-provider, PaaS-provider of Cloud Service Provider (CSP) de patchuitrol beheerst, zijn interne SLA’s nutteloos tenzij leveranciersverplichtingen daarop aansluiten.

Het Beleid voor beveiliging van derde partijen en leveranciers voor mkb bevat informatiebeveiligingsverplichtingen als governancevereiste. Voor remediatie van kwetsbaarheden moeten die verplichtingen meetbare contracttaal worden:

• Meldtermijnen voor kritieke kwetsbaarheden
• Remediatietermijnen voor kritieke, hoge, middelhoge en lage kwetsbaarheden
• Proces voor noodwijzigingen
• Vereisten voor klantgoedkeuring bij downtime
• Bewijsformat voor voltooiing van patches
• Proces voor openbaarmaking van kwetsbaarheden
• Verplichtingen voor assistentie bij incidenten
• Auditrechten of het recht om assurancerapportages te ontvangen
• Patchverplichtingen voor subverwerkers of onderaannemers
• Exit- en transitieondersteuning voor kritieke diensten

De Zenith Blueprint, fase Controls in Action, stap 20, Control 8.21 Security of network services, formuleert het principe duidelijk:

Wanneer diensten extern worden geleverd, waaronder door ISP’s, SD-WAN-leveranciers of private cloudproviders, moeten beveiligingseisen worden opgenomen in contracten en SLA’s. Dit omvat uptimegaranties, responstijden voor incidenten, verplichtingen voor patching of mitigatie van kwetsbaarheden en duidelijke grenzen voor gegevensverwerking. Ga er nooit van uit dat een provider aan uw verwachtingen voldoet tenzij dit schriftelijk, meetbaar en auditeerbaar is vastgelegd.

DORA maakt dit bijzonder belangrijk voor financiële entiteiten. ICT-regelingen met derden moeten serviceniveaus, assistentie door de provider tijdens ICT-incidenten, toegang tot en herstel van gegevens, samenwerking met autoriteiten, beëindigingsrechten en zwaardere bepalingen voor kritieke of belangrijke functies bevatten, inclusief monitoring, auditrechten, noodplannen en beveiligingsmaatregelen.

NIST CSF 2.0 zegt hetzelfde via uitkomsten voor risico’s in de toeleveringsketen: leveranciers moeten bekend zijn, op kritikaliteit worden geprioriteerd, vóór inschakeling worden beoordeeld, via contractuele eisen worden bestuurd, gedurende de relatie worden gemonitord, in incidentplanning worden opgenomen en bij beëindiging worden beheerd.

Wat auditors daadwerkelijk zullen vragen

Het auditgesprek verschilt afhankelijk van de achtergrond van de auditor.

Een ISO/IEC 27001:2022-auditor begint bij het ISMS. Hij controleert of kwetsbaarhedenbeheer is opgenomen in de Verklaring van Toepasselijkheid, of de risicobeoordeling niet-gepatchte systemen als risico identificeert, of risicobehandelingsplannen eigenaren en tijdlijnen hebben, of Annex A-beheersmaatregel 8.8 is geïmplementeerd, of bewijsmateriaal wordt bewaard en of interne audit en directiebeoordeling prestaties evalueren.

De Zenith Blueprint, fase Controls in Action, stap 19, maakt de auditverwachting expliciet:

Dit is een beheersmaatregel met hoge prioriteit voor auditors, en zij zullen er meestal diep op ingaan. Verwacht vragen over hoe vaak systemen worden gepatcht, welk proces u volgt wanneer een zero-day wordt aangekondigd en welke systemen het moeilijkst te patchen zijn.

Het vervolgt met praktische verwachtingen voor bewijsmateriaal:

Auditors zullen waarschijnlijk resultaten van kwetsbaarheidsscans opvragen. Als u tools zoals Nessus, OpenVAS of Qualys gebruikt, exporteer dan een rapport dat recente gedetecteerde kwetsbaarheden toont en laat zien hoe deze zijn aangepakt. Idealiter bevat dit risicoclassificaties (CVSS) en remediatietermijnen.

Een NIS2-gerichte auditor of bevoegde autoriteit zal zoeken naar bestuursgoedkeuring, proportionaliteit, cyberhygiëne, afhandeling van kwetsbaarheden, leveranciersbeveiliging, incidentenafhandeling, beoordeling van doeltreffendheid, corrigerende maatregelen zonder onnodige vertraging en besluitregistraties voor rapportage als exploitatie aanzienlijke impact heeft veroorzaakt.

Een DORA-toezichthouder zal toetsen of kwetsbaarheidsbevindingen zijn geïntegreerd in ICT-risicobeheer, testen van digitale operationele weerbaarheid, incidentclassificatie, oorzaakanalyse, registers van derden, contractuele verplichtingen, auditrechten en remediatie van kritieke bevindingen.

Een NIST CSF-assessor zal de beoordeling waarschijnlijk structureren rond GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND en RECOVER. Hij zal vragen of wettelijke en contractuele eisen worden begrepen, of risicotolerantie is gedocumenteerd, of kwetsbaarheden worden geïdentificeerd en geprioriteerd, of uitzonderingen worden beheerd, of monitoring exploitatie detecteert en of respons- en herstelacties worden gecoördineerd.

Een COBIT 2019- of ISACA-auditor richt zich op governancedoelstellingen, procescapability, managementpraktijken, metrieken, eigenaarschap, ontwerp van beheersmaatregelen, werking van beheersmaatregelen en toereikendheid van bewijsmateriaal. Hij zal vragen of remediatie van kwetsbaarheden herhaalbaar, gemeten, geëscaleerd, verbeterd en afgestemd is op ondernemingsdoelstellingen en risicobereidheid.

Escalatie en metrieken: hoe u bewijst dat de SLA wordt beheerd

Een SLA zonder escalatie is slechts een doel. Een verdedigbaar programma voor remediatie van kwetsbaarheden heeft escalatie nodig vóór overschrijding, bij overschrijding en na herhaald falen.

Clarysec adviseert een escalatiemodel met vier niveaus:

1. Operationele escalatie, ticketeigenaar en technisch verantwoordelijke worden vóór overschrijding geïnformeerd.
2. Risico-escalatie, asset-eigenaar en risico-eigenaar beoordelen de impact wanneer overschrijding waarschijnlijk is.
3. Escalatie naar beveiligingsgovernance, CISO of risicocommissie keurt uitzondering of noodactie goed.
4. Managementescalatie, herhaalde of kritieke SLA-overschrijdingen worden met corrigerende maatregelen gerapporteerd in de directiebeoordeling.

Het Beleid voor kwetsbaarheden- en patchbeheer versterkt deze auditverwachting:

Periodieke audits moeten worden uitgevoerd door Interne Audit of een onafhankelijke derde partij om te verifiëren: 5.6.1 Naleving van SLA’s 5.6.2 Bewijsmateriaal van risicogebaseerde prioritering 5.6.3 Doeltreffendheid van uitgerolde patches 5.6.4 Beheersmaatregelen voor niet-gepatchte systemen

Metrieken moeten besluiten ondersteunen, niet dashboards versieren. De sterkste metrieken voor 2026 zijn onder meer:

• Nalevingspercentage voor kritieke SLA’s
• Nalevingspercentage voor hoge SLA’s
• Gemiddelde tijd tot triage
• Gemiddelde tijd tot remediatie per assetklasse
• Aantal achterstallige kritieke kwetsbaarheden
• Aantal geaccepteerde uitzonderingen naar ouderdom
• Uitzonderingen ouder dan 90 dagen
• Aantal kritieke blootstellingen op vanaf internet bereikbare systemen
• SLA-overschrijdingen door leveranciers
• Kwetsbaarheden die na validatie opnieuw zijn geopend
• Noodwijzigingen veroorzaakt door actief misbruikte kwetsbaarheden
• Patchfouten per platform of bedrijfseenheid

Koppel deze metrieken aan ISO/IEC 27001:2022 Clause 9.3 directiebeoordeling, DORA-governancerapportage en NIS2-managementtoezicht. Gebruik ze voor NIST CSF 2.0 om Current en Target Profiles, gap-analyse en actieplannen te actualiseren.

De Clarysec-checklist voor remediatie-SLA’s

Gebruik deze checklist om uw huidige programma te beoordelen:

• Is er een goedgekeurd beleid voor kwetsbaarheden- en patchbeheer?
• Zijn remediatie-SLA’s gedefinieerd op basis van ernst en bedrijfskritikaliteit?
• Worden vanaf internet bereikbare en actief misbruikte kwetsbaarheden versneld behandeld?
• Zijn bedrijfsmiddelen gekoppeld aan eigenaren, diensten, gegevens en leveranciers?
• Worden scannerbevindingen omgezet in toegewezen tickets?
• Worden patches uitgevoerd via wijzigingsbeheer?
• Worden noodwijzigingen gedocumenteerd en beoordeeld?
• Worden remediatieresultaten gevalideerd met herscans of versiecontroles?
• Worden uitzonderingen risicobeoordeeld, goedgekeurd en ten minste elke 90 dagen beoordeeld?
• Worden compenserende beheersmaatregelen voor niet-patchbare systemen gedocumenteerd?
• Zijn leverancierscontracten afgestemd op interne remediatiedrempels?
• Zijn patchlogboeken volledig genoeg om te bewijzen wat er is gebeurd en wanneer?
• Worden SLA-overschrijdingen geëscaleerd en gecorrigeerd?
• Worden metrieken door het management beoordeeld?
• Worden incidenten en beoordelingen van datalekken geactiveerd wanneer exploitatie wordt vermoed?

Als meerdere antwoorden “nee” zijn, is tooling niet het probleem. Het probleem is het ontwerp van de beheersmaatregelen.

Volgende stappen: maak van patchdeadlines auditklare weerbaarheid

SLA’s voor remediatie van kwetsbaarheden moeten in 2026 meer doen dan een scannerdashboard tevredenstellen. Ze moeten bewijzen dat uw organisatie blootstelling kan identificeren, risico’s kan prioriteren, binnen goedgekeurde termijnen kan handelen, uitzonderingen kan beheersen, leveranciers kan besturen en beslissingen met bewijsmateriaal kan onderbouwen binnen de auditverwachtingen van ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT 2019.

Clarysec kan u helpen om van versnipperde patchtickets naar een geïntegreerd, bewijsgericht programma voor remediatie van kwetsbaarheden te gaan met:

• Beleid voor kwetsbaarheden- en patchbeheer
• Beleid voor kwetsbaarheden- en patchbeheer voor mkb
• Beleid voor beveiliging van derde partijen en leveranciers voor mkb
• Zenith Blueprint: een 30-stappenroadmap voor auditors
• Zenith Controls: de cross-compliancegids

Begin met één dienst met hoog risico. Breng de bedrijfsmiddelen, leveranciers, kwetsbaarheden, tickets, wijzigingen, uitzonderingen en het bewijsmateriaal in kaart. Leg er vervolgens de auditvragen naast. Als u de SLA niet kunt aantonen van detectie tot sluiting, is dat uw eerste remediatieproject.

Het doel is niet perfect patchen. Het doel is bestuurde, risicogebaseerde, meetbare en auditeerbare remediatie. Download de Clarysec-beleidssjablonen, voer een gerichte gap-assessment uit of boek een Clarysec-demo om remediatie van kwetsbaarheden om te zetten van auditdruk naar operationele weerbaarheid.