Van scans naar auditbewijs: ISO 27001:2022, NIS2, DORA

Het is 08:16 op een maandag. Op het dashboard is zojuist een kritieke kwetsbaarheid voor uitvoering van code op afstand verschenen voor een applicatieserver die vanaf internet bereikbaar is. Het infrastructuurteam meldt dat de leverancierspatch beschikbaar is. De applicatie-eigenaar waarschuwt dat de server een omzetkritische klantworkflow ondersteunt. De juridische afdeling vraagt of exploitatie kan leiden tot meldplichten onder NIS2, DORA of GDPR. De CISO, Maria, opent de auditkalender en ziet het echte probleem: de ISO 27001:2022-surveillanceaudit start volgende week, een NIS2-gereedheidsbeoordeling loopt al en een grote fintechklant heeft DORA-bewijs opgevraagd.

De scanner staat op rood. Het ticketboard toont activiteit. De spreadsheet toont inspanning. Maar niets daarvan bewijst automatisch dat de beheersmaatregel werkt.

Dit is de kloof die veel organisaties te laat ontdekken. Kwetsbaarheidsscanning is niet hetzelfde als auditgereed kwetsbaarhedenbeheer. Een scan laat zien dat er mogelijk iets mis is. Auditbewijs toont aan dat de organisatie wist wat zij had, het risico heeft beoordeeld, eigenaarschap heeft toegewezen, binnen beleid heeft gehandeld, wijzigingen heeft beheerst, uitzonderingen heeft gedocumenteerd, resultaten heeft geverifieerd en de uitkomst heeft beoordeeld.

Voor ISO/IEC 27001:2022, NIS2 en DORA is die bewijsketen net zo belangrijk als de technische oplossing. De scanner start het verhaal. De inventaris van bedrijfsmiddelen, het kwetsbaarhedenregister, het ticket, het risicobesluit, de wijzigingsregistratie, het patchlogboek, het validatiebewijs, de goedkeuring van de uitzondering en de directiebeoordeling maken het verhaal compleet.

De aanpak van Clarysec is eenvoudig: behandel kwetsbaarhedenbeheer niet als een maandelijks technisch ritueel. Behandel het als een governancegestuurde workflow voor bewijsvoering.

Waarom scanrapporten tekortschieten als auditbewijs

Een kwetsbaarheidsscan is een technische waarneming op een bepaald moment. De scan kan een CVE, ontbrekende patch, niet-ondersteunde bibliotheek, blootgestelde dienst of zwakke configuratie vaststellen. Dat is nuttig, maar niet volledig.

Een auditor stelt andere vragen:

• Viel het getroffen bedrijfsmiddel binnen de scope?
• Wie is eigenaar van het bedrijfsmiddel en de bedrijfsdienst?
• Is de kwetsbaarheid beoordeeld op basis van blootstelling, exploiteerbaarheid, bedrijfsimpact en gevoeligheid van gegevens?
• Is de remediatie binnen de vastgestelde termijn voltooid?
• Als remediatie is uitgesteld, wie heeft dan het restrisico geaccepteerd?
• Is de patch uitgerold via gecontroleerd wijzigingsbeheer?
• Is de oplossing geverifieerd met een herscan of technische validatie?
• Is het bewijs bewaard en beoordeeld door het management?

Een map met scannerexports beantwoordt deze vragen zelden. In een ISO 27001:2022-audit toetst de auditor of het ISMS werkt zoals ontworpen. Onder NIS2 moeten bestuursorganen maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren en hierop toezicht houden. Onder DORA hebben financiële entiteiten een gedocumenteerd ICT-risicobeheerkader, een incidentlevenscyclus, weerbaarheidstesten en beheersmaatregelen voor ICT-risico’s van derde partijen nodig. Onder GDPR gaat het erom of passende technische en organisatorische maatregelen persoonsgegevens hebben beschermd en of verantwoordingsplicht kan worden aangetoond.

ISO/IEC 27001:2022-clausules 4.1 tot en met 4.4 vereisen dat de organisatie haar context, belanghebbenden, vereisten en ISMS-toepassingsgebied begrijpt. Kwetsbaarheden- en patchbeheer kan niet geïsoleerd worden ontworpen. Het moet klantcontracten, toezichthouders, cloudafhankelijkheden, uitbestede ICT-diensten, gegevensbeschermingsverplichtingen en kritieke diensten weerspiegelen.

ISO/IEC 27001:2022-clausules 6.1.1 tot en met 6.1.3 vereisen risicobeoordeling, risicobehandeling, selectie van beheersmaatregelen, een Verklaring van Toepasselijkheid en goedkeuring door de risico-eigenaar voor restrisico. Dit betekent dat bewijs over kwetsbaarheden moet aansluiten op het risicoregister, het behandelplan en de SoA.

ISO/IEC 27005:2022 versterkt dit model door organisaties aan te moedigen vereisten uit Annex A, sectorverplichtingen, regelgeving, contracten, interne regels en bestaande beheersmaatregelen te consolideren in de baseline voor risicobeoordeling. De norm benadrukt ook criteria voor waarschijnlijkheid, gevolgen, wettelijke verplichtingen, leveranciersrelaties, privacy-impact en impact op derde partijen. Praktisch gezien is een kwetsbaarheid niet alleen een CVSS-score. Het is een risicogebeurtenis die is verbonden met bedrijfsmiddelen, verplichtingen, stakeholders en bedrijfsgevolgen.

De regelgevingsdruk achter patchbewijs

Moderne cyberbeveiligingsregelgeving laat steeds minder ruimte voor informele patching.

NIS2 is van toepassing op veel middelgrote en grote entiteiten in hoogkritieke en kritieke sectoren, en kan ook bepaalde entiteiten ongeacht hun omvang omvatten. De reikwijdte omvat aanbieders van digitale infrastructuur, zoals cloudcomputingdiensten, datacentrumdiensten, content delivery networks, aanbieders van openbare elektronische communicatiediensten, vertrouwensdiensten, DNS- en TLD-diensten, plus aanbieders van ICT-dienstbeheer, zoals managed service providers en managed security service providers. Ook belangrijke digitale aanbieders zoals online marktplaatsen, online zoekmachines en socialenetwerkplatforms vallen eronder.

Article 20 van NIS2 maakt cyberbeveiliging een verantwoordelijkheid van het bestuursorgaan. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving, veilige ontwikkeling, veilig onderhoud, behandeling en openbaarmaking van kwetsbaarheden, beoordeling van doeltreffendheid, cyberhygiëne, toegangscontrole, beheer van bedrijfsmiddelen en authenticatie. Article 23 creëert een gefaseerd meldproces voor significante incidenten, waaronder een vroegtijdige waarschuwing binnen 24 uur, melding binnen 72 uur en, waar van toepassing, een eindrapport binnen één maand.

DORA creëert vanaf 17 januari 2025 een rechtstreeks toepasselijk regelboek voor digitale operationele weerbaarheid voor financiële entiteiten. Het omvat ICT-risicobeheer, melding van majeure ICT-incidenten, testen van operationele weerbaarheid, delen van cyberdreigingsinformatie, ICT-risicobeheer van derde partijen en toezicht op kritieke ICT-dienstverleners van derde partijen. Articles 5 en 6 plaatsen ICT-risicogovernance onder het bestuursorgaan en vereisen een gedocumenteerd, geïntegreerd en periodiek beoordeeld ICT-risicobeheerkader. Article 8 versterkt de noodzaak om door ICT ondersteunde bedrijfsfuncties, informatieactiva, ICT-activa en afhankelijkheden te identificeren. Articles 17 tot en met 20 vereisen detectie, registratie, classificatie, escalatie, rapportage, communicatie, remediatie en leren voor ICT-gerelateerde incidenten. Articles 28 tot en met 30 vereisen dat ICT-risico’s van derde partijen worden beheerst via registers, due diligence, contractuele waarborgen, auditrechten, exitplanning en toezicht.

Voor financiële entiteiten die onder DORA vallen, vervangt DORA doorgaans gelijkwaardige NIS2-verplichtingen voor risicobeheer en rapportage. NIS2 blijft echter relevant voor ecosysteemcoördinatie en voor entiteiten buiten de DORA-dekking. Voor SaaS-, MSP- en MSSP-aanbieders die financiële klanten bedienen, is de praktijk direct: klanten kunnen uw bewijs over kwetsbaarheden nodig hebben om aan hun DORA-verplichtingen te voldoen.

GDPR voegt nog een laag toe. Articles 2 en 3 kunnen van toepassing zijn op in de EU gevestigde organisaties en op organisaties buiten de EU die goederen of diensten aanbieden aan personen in de EU of hun gedrag monitoren. Article 5 vereist bescherming van persoonsgegevens en verantwoordingsplicht voor naleving. Article 4 definieert een inbreuk in verband met persoonsgegevens als een beveiligingsincident dat leidt tot accidenteel of onrechtmatig verlies, vernietiging, wijziging, ongeoorloofde bekendmaking van of toegang tot persoonsgegevens. Een uitgestelde patch op een databank, identiteitsplatform of klantportaal kan uitgroeien tot een kwestie van privacyverantwoording.

Van beleid naar bewijs

De eerste stap is het vaststellen van de regels. Een sterk beleid voor kwetsbaarheden- en patchbeheer is niet alleen een auditdocument. Het is het operationele kader voor de beheersmaatregel.

Voor grote organisaties verbindt Beleid voor kwetsbaarheden- en patchbeheer technische patching expliciet met compliance over meerdere raamwerken:

Dit beleid ondersteunt naleving van ISO/IEC 27001 Annex A-beheersmaatregel 8.8 en de richtlijnen van ISO/IEC 27002, en adresseert wettelijke en regelgevende vereisten onder DORA Article 8, NIS2 Article 21, GDPR Article 32 en de COBIT 2019 DSS- en APO-domeinen.

Uit de sectie “Doel”.

Hetzelfde beleid stelt de governanceverwachting vast voor het centrale bewijsartefact:

Een centraal kwetsbaarhedenregister moet worden bijgehouden door het Security Operations Team en maandelijks worden beoordeeld door de CISO of een gedelegeerde bevoegde functionaris.

Uit de sectie “Governancevereisten”, beleidsclausule 5.1.

Het definieert ook de scanfrequentie:

Alle systemen moeten ten minste maandelijks worden gescand; bedrijfsmiddelen met een hoog risico of externe blootstelling moeten wekelijks worden gescand.

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

En het voorkomt dat urgente patching onbeheerste technische activiteit wordt:

Alle remediatieactiviteiten moeten worden gecoördineerd via het wijzigingsbeheerproces (conform P5 - Wijzigingsbeheerbeleid) om stabiliteit en behoud van de audittrail te waarborgen.

Uit de sectie “Governancevereisten”, beleidsclausule 5.5.

Voor mkb-organisaties kunnen dezelfde bewijsprincipes eenvoudiger worden geïmplementeerd. Beleid voor kwetsbaarheden- en patchbeheer voor mkb stelt:

Houd nauwkeurige registraties bij van toegepaste patches, openstaande kwesties en uitzonderingen om auditgereedheid te waarborgen

Uit de sectie “Doelstellingen”, beleidsclausule 3.4.

Daarna definieert het beleid het patchlogboek als auditbewijs:

Een patchlogboek moet worden bijgehouden en beoordeeld tijdens audits en incidentresponsactiviteiten

Uit de sectie “Governancevereisten”, beleidsclausule 5.4.1.

Ook specificeert het de minimale inhoud:

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

Uit de sectie “Governancevereisten”, beleidsclausule 5.4.2.

Voor urgente blootstelling via internet stelt het mkb-beleid een meetbare eis:

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

Uit Beleid voor kwetsbaarheden- en patchbeheer voor mkb, sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.

Deze clausules zetten technisch werk om in bewijs. Het beleid definieert verwachtingen. Het register legt bevindingen vast. Het ticket wijst werk toe. De wijzigingsregistratie beheerst de uitrol. Het patchlogboek toont actie aan. Het risicoregister legt uitzonderingen vast. De notulen van beoordelingen tonen toezicht aan.

Het evidence-first-model van Clarysec

Het evidence-first-model van Clarysec begint met één principe: elke kwetsbaarheidsbevinding moet traceerbaar zijn van ontdekking tot besluit.

In Zenith Blueprint: de 30-stappenroadmap voor auditors behandelt de fase Beheersmaatregelen in de praktijk, Stap 19: Technologische beheersmaatregelen I, kwetsbaarhedenbeheer als een herhaalbare beheersmaatregel in plaats van een theoretische eis:

Het beheren van kwetsbaarheden is een van de meest kritieke onderdelen van moderne cyberhygiëne. Hoewel firewalls en antivirus tools bescherming bieden, kunnen zij worden ondermijnd als niet-gepatchte systemen of verkeerd geconfigureerde diensten blootgesteld blijven.

Dezelfde stap licht toe dat organisaties reguliere patchschema’s, kwetsbaarheidsscanners, triage, toewijzing, opvolging van remediatie, compenserende beheersmaatregelen en acceptatie van restrisico moeten gebruiken. Belangrijker nog: de auditmindset wordt juist neergezet:

De beheersmaatregel gaat niet over perfectie, maar over een georganiseerd, transparant en verantwoordingsgericht proces.

Voor auditors is dat onderscheid belangrijk. Een volwassen organisatie kan openstaande kwetsbaarheden hebben en toch aantonen dat zij in control is, mits er sprake is van risicogebaseerde prioritering, gedocumenteerd eigenaarschap, goedgekeurde uitzonderingen, compenserende beheersmaatregelen en geverifieerde remediatie.

De Zenith Blueprint waarschuwt ook dat auditors dit gebied nauwkeurig zullen beoordelen:

Dit is een beheersmaatregel met hoge prioriteit voor auditors, en zij zullen hier doorgaans 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.

Daarom moet een CISO een audit niet ingaan met alleen een scannerdashboard. Het bewijspakket moet governance, proces, uitvoering, verificatie en verbetering aantonen.

ISO 27002-beheersmaatregelen koppelen aan auditbewijs

Zenith Controls: de gids voor compliance over meerdere raamwerken fungeert als compliancekompas door ISO/IEC 27002:2022-beheersmaatregelen te mappen en te laten zien hoe zij samenhangen met auditverwachtingen. Voor kwetsbaarheden- en patchbeheer vormen drie ISO/IEC 27002:2022-beheersmaatregelen de operationele driehoek.

ISO/IEC 27002:2022-beheersmaatregel 8.8, Beheer van technische kwetsbaarheden, is de centrale beheersmaatregel. Deze is preventief, ondersteunt vertrouwelijkheid, integriteit en beschikbaarheid, sluit aan op de cyberbeveiligingsconcepten Identify en Protect en verbindt met dreigings- en kwetsbaarhedenbeheer.

ISO/IEC 27002:2022-beheersmaatregel 8.32, Wijzigingsbeheer, is eveneens preventief. Deze verbindt patching met gecontroleerde uitrol, testen, goedkeuring, rollback en auditeerbaarheid.

ISO/IEC 27002:2022-beheersmaatregel 5.36, Naleving van beleid, regels en normen voor informatiebeveiliging, waarborgt dat het proces niet optioneel is en niet afhankelijk is van individuele heldendaden. Deze verbindt kwetsbaarhedenbeheer met naleving van beleid, assurance en toezicht.

Deze mapping voorkomt een veelvoorkomende auditbevinding. Security zegt: “We hebben gepatcht.” Operations zegt: “We hebben uitgerold.” Compliance zegt: “We kunnen de volgorde niet aantonen.” Een gemapte bewijsketen geeft alle drie de teams hetzelfde verhaal.

De bewijsketen die auditors willen zien

Een verdedigbare bewijsketen voor kwetsbaarhedenbeheer heeft zeven fasen.

Het praktische verschil tussen “we voeren scans uit” en “we zijn auditgereed” is continuïteit. Als een kwetsbaarheid niet van ontdekking tot afsluiting kan worden getraceerd, is de beheersmaatregel zwak. Als er uitzonderingen bestaan zonder goedkeuring, is het proces zwak. Als patches wijzigingsbeheer omzeilen, is de audittrail zwak. Als kritieke kwetsbaarheden open blijven zonder compenserende beheersmaatregelen, is de governance zwak.

Beleid voor audit en compliancemonitoring ondersteunt automatisering als onderdeel van dit model:

Geautomatiseerde tools moeten worden ingezet om naleving van configuraties, kwetsbaarhedenbeheer, patchstatus en geprivilegieerde toegang te monitoren.

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

Voor mkb-organisaties definieert Beleid voor audit en compliancemonitoring voor mkb verificatie van technische beheersmaatregelen in praktische termen:

Verificatie van technische beheersmaatregelen (bijv. back-upstatus, configuratie van toegangscontrole, patchregistraties)

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

Kleine organisaties hebben geen zware enterprise-tooling nodig om auditgereed te zijn. Zij hebben consistent bewijs nodig. Een lichtgewicht register, ticketboard, patchlogboek en maandelijkse beoordeling kunnen volstaan als ze volledig, actueel en gekoppeld aan risico zijn.

Voorbeeld: één kritieke bevinding, volledig auditgereed

Maria’s wekelijkse externe scan identificeert CVE-2026-12345 op een betalings-API-gateway die vanaf internet bereikbaar is. De scanner classificeert deze als kritiek. De dienst verwerkt klantidentiteit en transactiemetadata, waardoor implicaties voor GDPR en DORA mogelijk zijn. De gateway is eigendom van Platform Engineering, maar de patch vereist een korte onderbreking.

Dit is de auditgereede workflow.

1. Maak de registratie in het kwetsbaarhedenregister

Het beveiligingsteam legt de bevinding vast in het centrale register:

• Bevinding-ID: VULN-2026-0142
• Bron: wekelijkse externe scan
• Ontdekkingsdatum en -tijd
• Bedrijfsmiddel: api-gw-prod-01
• Eigenaar: Platform Engineering
• Blootstelling: vanaf internet bereikbaar
• Gegevenscontext: klantidentiteit en transactiemetadata
• Ernst: kritiek
• SLA: 72 uur of strenger op basis van beleid
• Ticket: SEC-4821
• Wijzigingsregistratie: CHG-10988
• Status: remediatie gepland

2. Voer triage uit op basis van zakelijke en regelgevende context

Het team controleert exploitbeschikbaarheid, aanvalsoppervlak, authenticatievereisten, bedrijfsimpact en gegevensgevoeligheid. Omdat het systeem vanaf internet bereikbaar is en klantworkflows ondersteunt, blijft de kwetsbaarheid kritiek. De risico-eigenaar is de Head of Platform, en de CISO wordt geïnformeerd vanwege mogelijke implicaties voor NIS2, DORA en GDPR.

ISO/IEC 27005:2022-clausules 7.1 tot en met 7.4 ondersteunen risico-identificatie, eigenaarschap, gevolgen, waarschijnlijkheid en prioritering. Clausules 8.2 tot en met 8.6 ondersteunen selectie van behandeling, bepaling van beheersmaatregelen, koppeling met de SoA, behandelplanning en goedkeuring van restrisico.

3. Open een gecontroleerde noodwijziging

De patch wordt voor dezelfde avond ingepland. De wijzigingsregistratie bevat de leveranciersreferentie, getroffen diensten, het testplan, rollbackplan, onderhoudsvenster, besluit over klantcommunicatie, goedkeuringen en de vereiste validatie na uitrol.

Dit ondersteunt direct ISO/IEC 27002:2022-beheersmaatregel 8.32 en de enterprise-beleidseis om remediatie via wijzigingsbeheer te coördineren.

4. Pas de patch toe en werk het patchlogboek bij

Het patchlogboek registreert de apparaatnaam, de toegepaste update, de patchdatum en, indien van toepassing, de reden voor vertraging. Als patching was uitgesteld, zou het team compenserende beheersmaatregelen documenteren, zoals Web Application Firewall (WAF)-regels, tijdelijke toegangsbeperkingen, verhoogde logging, isolatie of verscherpte monitoring.

5. Verifieer en sluit af

Security scant de API-gateway opnieuw. De kwetsbaarheid verschijnt niet meer. Het ticket wordt bijgewerkt met bewijs van een schone scan, patchversie, uitroltijdstempel en koppeling naar de wijzigingsregistratie. De status in het kwetsbaarhedenregister wijzigt naar “Gesloten, geverifieerd.”

6. Beoordeel de rapportage-impact

Als er geen exploitatie en geen verstoring van dienstverlening was, wordt incidentrapportage onder NIS2 of DORA mogelijk niet geactiveerd. Als indicatoren van compromittering worden gevonden, moet het incidentproces impact en escalatie classificeren. Onder NIS2 kan een significant incident een vroegtijdige waarschuwing en gefaseerde rapportage vereisen. Onder DORA vereist een majeur ICT-gerelateerd incident classificatie en rapportage via het toepasselijke proces van de bevoegde autoriteit.

7. Verwerk lessen in de directiebeoordeling

Aan het einde van de maand noteert de CISO-beoordeling dat de kwetsbaarheid is gedetecteerd door wekelijkse externe scanning, binnen SLA is geremedieerd, met een herscan is geverifieerd en zonder incident is afgesloten. Als vergelijkbare problemen terugkeren, kan het behandelplan beveiligde configuratiebaselines, geautomatiseerde patchuitrol, leveranciersescalatie of modernisering van applicaties omvatten.

Wanneer een auditor naar CVE-2026-12345 vraagt, kan Maria een samengesteld pakket presenteren in plaats van e-mails en screenshots.

Dat is auditgereed. Niet omdat de organisatie geen kwetsbaarheden had, maar omdat zij beheersing kon aantonen.

Eén bewijspakket, meerdere verplichtingen

Een goed ontworpen programma voor kwetsbaarheden- en patchbeheer kan meerdere raamwerken ondersteunen zonder dubbel werk.

Voor ISO 27001:2022 ondersteunt het bewijs het risicogebaseerde ISMS, de implementatie van Annex A-beheersmaatregelen, de Verklaring van Toepasselijkheid, risicobehandelingsplannen, interne audit en voortdurende verbetering. Als ISO/IEC 27002:2022-beheersmaatregel 8.8 van toepassing is in de SoA, moet de organisatie de wettelijke, regelgevende, risico- of zakelijke onderbouwing kunnen tonen. Die onderbouwing omvat vaak NIS2 Article 21, DORA ICT-risicoverplichtingen, GDPR-verantwoordingsplicht, klantcontracten en behoeften aan operationele weerbaarheid.

Voor NIS2 helpt hetzelfde bewijs om Article 21-maatregelen aan te tonen, waaronder risicoanalyse, behandeling van kwetsbaarheden, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, cyberhygiëne, toegangscontrole en beoordeling van doeltreffendheid. Article 20 wordt aangetoond via CISO-beoordeling, rapportage aan het bestuur, managementgoedkeuring en cyberbeveiligingstraining. Article 23 wordt relevant als exploitatie ernstige operationele verstoring, financieel verlies of schade aan anderen veroorzaakt of kan veroorzaken.

Voor DORA ondersteunt bewijs over kwetsbaarheden en patches het ICT-risicobeheerkader, toezicht door het bestuursorgaan, de weerbaarheidsstrategie, incidentdetectie en -classificatie, weerbaarheidstesten en toezicht op ICT-derden. Wanneer een ICT-aanbieder het getroffen systeem host of beheert, vereisen Articles 28 tot en met 30 due diligence, contractuele bescherming, auditrechten, ondersteuning bij incidenten en exitoverwegingen.

Voor GDPR ondersteunt hetzelfde bewijs de verantwoordingsplicht van Article 5 en de beveiligingspositie die onder Article 32 wordt verwacht. Als een kwetsbaarheid leidt tot ongeautoriseerde toegang tot, wijziging, verlies of bekendmaking van persoonsgegevens, worden de tijdlijn van de kwetsbaarheid, patchregistraties, monitoringlogboeken en notities van de inbreukbeoordeling essentieel.

Voor COBIT 2019 en ISACA-achtige assurance wordt kwetsbaarhedenbeheer beoordeeld via operationele beveiliging, monitoring van beheersmaatregelen, wijzigingsenablement en governanceverantwoording. De compliance-overkoepelende verwijzingen in de Zenith Blueprint noemen COBIT 2019 DSS05.04 en BAI09.02, plus ITAF-assuranceverwachtingen voor kwetsbaarhedenbeheer, patching en veilig wijzigingsbeheer.

Ondersteunende ISO-normen versterken het operationele model. ISO/IEC 27005:2022 ondersteunt risicobeoordeling en -behandeling. ISO/IEC 27035:2023 ondersteunt incidentrespons wanneer kwetsbaarheden worden uitgebuit. ISO/IEC 30111 ondersteunt processen voor de behandeling van kwetsbaarheden. ISO/IEC 29147 ondersteunt openbaarmaking van kwetsbaarheden en adviezen. ISO/IEC 27017 ondersteunt kwetsbaarhedenbeheer in cloudomgevingen. ISO 22301 ondersteunt continuïteitsplanning wanneer technische kwetsbaarheden bedrijfsdiensten kunnen verstoren.

Hoe verschillende auditors hetzelfde proces toetsen

Verschillende beoordelaars gebruiken verschillende invalshoeken. Het bewijs kan hetzelfde zijn, maar de vragen verschillen.

Het beleid zegt wat er moet gebeuren. Het operationele bewijs toont wat er is gebeurd. De beoordelingsregistraties tonen dat het management kennis had, kritisch heeft getoetst en heeft gehandeld.

Veelvoorkomende redenen waarom patchbeheer faalt in een audit

De meeste bevindingen ontstaan niet door het ontbreken van een scanner. Ze ontstaan door gebrekkige traceerbaarheid.

De inventaris van bedrijfsmiddelen is onvolledig.
Als een scanner bedrijfsmiddelen vindt die ontbreken in de CMDB of het assetregister, kunnen eigenaarschap en bedrijfsimpact niet betrouwbaar worden beoordeeld. Dit ondermijnt de ISO 27001:2022-scope, risicobeoordeling en risicobehandeling.

Kwetsbaarheden worden alleen in de scanner gevolgd.
Scannerdashboards zijn geen governanceregisters. Ze missen vaak goedkeuring door de risico-eigenaar, onderbouwing van uitzonderingen, verwijzingen naar wijzigingen en bedrijfscontext.

Kritieke bevindingen hebben geen SLA-bewijs.
Een beleid kan stellen dat kritieke kwetsbaarheden binnen drie dagen worden opgelost. De auditvraag is of registraties aantonen dat dit is gebeurd.

Uitzonderingen zijn informeel.
Legacy-systemen, beperkingen door onderhoudsvensters en leveranciersvertragingen komen voor. Maar “we konden niet patchen” moet een gedocumenteerde uitzondering worden met compenserende beheersmaatregelen, vervaldatum en goedkeuring van restrisico.

Noodpatching omzeilt wijzigingsbeheer.
Noodwijzigingen blijven wijzigingen. Als er geen goedkeuring, test- of rollbackbewijs is, kunnen auditors concluderen dat remediatie operationeel risico heeft gecreëerd.

Systemen van derde partijen zijn onzichtbaar.
Onder NIS2 en DORA staan leveranciersrisico en ICT-risico van derde partijen centraal. Als een aanbieder het platform patcht, hebt u nog steeds bewijs, contractuele rechten, dienstverleningsrapportage en escalatieroutes nodig.

Niemand beoordeelt trends.
Terugkerende kwetsbaarheden kunnen wijzen op zwak configuratiebeheer, onvoldoende veilige ontwikkelpraktijken, niet-ondersteunde bedrijfsmiddelen of leveranciersfalen. Een maandelijkse beoordeling zet technische gegevens om in governanceactie.

Het Clarysec-auditpakket voor kwetsbaarheden

Voor een aanstaande ISO 27001:2022-, NIS2- of DORA-gereedheidsbeoordeling helpt Clarysec organisaties een auditpakket voor kwetsbaarheden- en patchbeheer samen te stellen met het volgende:

• Beleid voor kwetsbaarheden- en patchbeheer, inclusief scope, rollen, scanfrequentie, patch-SLA’s en uitzonderingsregels
• Uittreksel uit de inventaris van bedrijfsmiddelen met systemen binnen scope, eigenaren, criticaliteit en blootstelling
• Meest recente interne en externe kwetsbaarheidsscanrapporten
• Centraal kwetsbaarhedenregister met open, gesloten en uitzonderingsitems
• Patchlogboeken met apparaat, update, patchdatum en redenen voor vertraging
• Wijzigingsregistraties voor geselecteerde kritieke en hoge kwetsbaarheden
• Bewijs van herscans of validatie na remediatie
• Goedkeuringen van uitzonderingen en restrisico voor vertraagde of niet-patchbare systemen
• Proces voor monitoring van beveiligingsadviezen voor leveranciers, bibliotheken en cloudservices
• Maandelijkse notulen van CISO- of managementbeoordelingen
• Crosswalk naar ISO 27001:2022, NIS2, DORA, GDPR en COBIT 2019-verplichtingen
• Resultaten van interne audits of verificatie van technische beheersmaatregelen

In de Zenith Blueprint, de fase Audit, beoordeling en verbetering, Stap 24, benadrukt Clarysec de traceerbaarheid tussen de Verklaring van Toepasselijkheid, het risicoregister en het behandelplan:

Uw SoA moet consistent zijn met uw risicoregister en risicobehandelingsplan. Controleer nogmaals dat elke beheersmaatregel die u als risicobehandeling hebt gekozen, in de SoA als “Van toepassing” is gemarkeerd.

Dit is vooral belangrijk voor kwetsbaarhedenbeheer. Als beheersmaatregel 8.8 van toepassing is, moet het auditpakket niet alleen bewijzen dat scanning plaatsvindt, maar ook dat bevindingen via risicobehandeling en voortdurende verbetering worden bestuurd.

Een gereedheidssprint van 30 dagen

Als uw audit dichtbij is, begin dan niet met alles herschrijven. Begin met snel bewijs opbouwen.

Deze sprint elimineert niet alle technische schuld. Hij verandert wel het auditgesprek. In plaats van een rommelige scannerexport te verdedigen, kunt u een governancegestuurd proces tonen met eigenaren, termijnen, acties, besluiten en toezicht.

Van scans naar verdedigbaar bewijs

Auditgereedheid op het gebied van kwetsbaarheden- en patchbeheer gaat niet over bewijzen dat u geen kwetsbaarheden hebt. Het gaat erom te bewijzen dat u ze kunt vinden, begrijpen, prioriteren en oplossen, uitzonderingen kunt beheersen en toezicht kunt aantonen.

Clarysec’s Zenith Blueprint, Zenith Controls, Beleid voor kwetsbaarheden- en patchbeheer, Beleid voor kwetsbaarheden- en patchbeheer voor mkb, Beleid voor audit en compliancemonitoring en Beleid voor audit en compliancemonitoring voor mkb bieden de structuur om die bewijsworkflow op te bouwen.

Als uw organisatie zich voorbereidt op ISO 27001:2022-certificering, NIS2-gereedheid, digitale operationele weerbaarheid onder DORA, customer due diligence of interne audit, begin dan met één vraag:

Kan elke kritieke kwetsbaarheid worden getraceerd van scan tot afsluiting?

Als het antwoord nee is, kan Clarysec helpen bij het opzetten van het register, de beleidsset, de compliance-overkoepelende mapping, het managementbeoordelingspakket en de auditgereede bewijsworkflow die technische scanning omzet in verdedigbare governance.