Patchbeheer is het proces van het identificeren, verwerven, testen en uitrollen van software-updates (patches) om beveiligingskwetsbaarheden, bugs en prestatieproblemen te verhelpen in de IT-omgeving van een organisatie. Het omvat besturingssystemen, applicaties, firmware en clouddiensten. Effectief patchbeheer is een van de meest kritieke beveiligingsmaatregelen, omdat ongepatchte kwetsbaarheden de aanvalsvector zijn bij het merendeel van de inbreuken.

Wat zijn patch-SLA's?

Patch-SLA's definiëren de maximale tijd die is toegestaan tussen het beschikbaar komen van een patch en de uitrol ervan, op basis van de ernst van de kwetsbaarheid. Gangbare SLA's zijn: kritieke kwetsbaarheden (CVSS 9.0-10.0) binnen 24-72 uur, hoge kwetsbaarheden (CVSS 7.0-8.9) binnen 7-14 dagen, gemiddelde kwetsbaarheden (CVSS 4.0-6.9) binnen 30 dagen en lage kwetsbaarheden (CVSS 0.1-3.9) binnen 90 dagen. SLA's moeten in het beleid worden gedocumenteerd en worden gevolgd als compliance-bewijs.

Wat is het verschil tussen patchbeheer en kwetsbaarheidsbeheer?

Kwetsbaarheidsbeheer is het bredere proces van het ontdekken, beoordelen, prioriteren en verhelpen van kwetsbaarheden — patchen is één herstelmethode. Kwetsbaarheidsbeheer omvat scannen op kwetsbaarheden, risicogebaseerde prioritering, herstel (dat patchen, configuratiewijzigingen of compenserende maatregelen kan omvatten) en verificatie. Patchbeheer richt zich specifiek op het uitrollen van door leveranciers geleverde software-updates om bekende kwetsbaarheden te verhelpen.

Hoe kunt u patchen zonder downtime te veroorzaken?

Strategieën om downtime te minimaliseren zijn onder meer: onderhoudsvensters gebruiken tijdens rustige perioden, blue-green of canary deployments implementeren voor applicaties, live patching van het besturingssysteem toepassen waar ondersteund (Linux kernel live patching, Windows hot patching), rolling updates gebruiken in gecontaineriseerde omgevingen, redundante systemen onderhouden die opeenvolgend kunnen worden gepatcht en patches testen in staging-omgevingen vóór productie-uitrol.

Wat is een compenserende maatregel voor patches die niet kunnen worden toegepast?

Wanneer een patch niet onmiddellijk kan worden toegepast (systeemincompatibiliteit, operationele beperkingen), verminderen compenserende maatregelen het risico totdat de patch kan worden uitgerold. Voorbeelden zijn: netwerksegmentatie om het kwetsbare systeem te isoleren, extra monitoring en waarschuwingen voor exploitatiepogingen, WAF-regels of virtuele patches voor kwetsbaarheden in webapplicaties, het uitschakelen van de kwetsbare functie of dienst, strengere toegangsbeperkingen en uitgebreide logging. Alle compenserende maatregelen moeten worden gedocumenteerd met een tijdlijn voor de uiteindelijke patching.

Hoe gaat u om met het patchen van applicaties van derden?

Het patchen van applicaties van derden vereist: het bijhouden van een inventaris van alle geïnstalleerde software met versies, het abonneren op beveiligingsadviezen van leveranciers, het gebruik van patchbeheertools die applicaties van derden ondersteunen (SCCM, Intune, Automox, Ivanti), het testen van patches van derden op compatibiliteit vóór uitrol, het apart volgen van patches van derden ten opzichte van OS-patching en het opnemen van applicaties van derden in kwetsbaarheidsscans. Applicaties van derden worden frequent misbruikt en mogen niet over het hoofd worden gezien.

Welke compliance-frameworks vereisen patchbeheer?

ISO 27001 (A.8.8 — Beheer van technische kwetsbaarheden), SOC 2 (CC7.1 — Kwetsbaarheidsbeheer), NIS2 (Artikel 21(2)(e) — Beveiliging bij het verwerven en ontwikkelen van netwerk- en informatiesystemen, inclusief afhandeling van kwetsbaarheden) en DORA (Artikel 9(2) — Bijgewerkte ICT-systemen) vereisen allemaal patchbeheer. Auditors letten specifiek op gedocumenteerd patchbeleid, SLA-nalevingsbewijs en uitzonderingsbeheerprocessen.

Hoe meet u de effectiviteit van patchbeheer?

Belangrijke meetwaarden zijn: patchcompliancepercentage (percentage systemen volledig gepatcht binnen SLA), gemiddelde tijd tot patching (gemiddeld aantal dagen van patchrelease tot uitrol), kritieke patchdekking (percentage kritieke patches toegepast binnen SLA), aantal uitzonderingen (aantal systemen met goedgekeurde patchuitzonderingen), scan-tot-herstel-kloof (tijd tussen kwetsbaarheidsontdekking en oplossing) en patchfaalpercentage (percentage patches dat teruggedraaid moest worden). Volg deze maandelijks en analyseer de trend.

Patchbeheer: de complete gids voor compliance- en beveiligingsteams

Published 8 mrt 2026

By Emre Salmanoglu

Patchbeheer: de complete gids voor compliance- en beveiligingsteams

Leer hoe u patchbeheer implementeert dat voldoet aan ISO 27001, SOC 2, NIS2 en DORA. Behandelt patchstrategieën, SLA-termijnen, kwetsbaarheidspriorisering en compliance-bewijs.

patchbeheer

kwetsbaarheidsbeheer

beveiligingsupdates

compliance

cyberbeveiliging

Wat is patchbeheer?

Patchbeheer is het systematische proces van het identificeren, testen en uitrollen van software-updates om beveiligingskwetsbaarheden en bugs te verhelpen in de IT-omgeving van een organisatie. Ongepatchte kwetsbaarheden blijven een van de meest misbruikte aanvalsvectoren, waardoor patchbeheer een van de meest impactvolle beveiligingsmaatregelen is die een organisatie kan implementeren.

Voor compliance-gedreven organisaties is patchbeheer een kernmaatregel die wordt vereist door ISO 27001, SOC 2, NIS2 en DORA, waarbij auditors specifiek het patchbeleid, de SLA-naleving en het uitzonderingsbeheer onderzoeken.

SLA-kader voor patching

Ernst	CVSS-score	Patch-SLA	Voorbeeld
Kritiek	9.0-10.0	24-72 uur	Remote code execution, zero-day exploits
Hoog	7.0-8.9	7-14 dagen	Privilege-escalatie, authenticatie-omzeiling
Gemiddeld	4.0-6.9	30 dagen	Informatielekken, cross-site scripting
Laag	0.1-3.9	90 dagen	Kleine informatielekken, bugs met lage impact

Patchbeheerproces

Fase	Activiteiten	Resultaat
Ontdekking	Beschikbare patches van alle leveranciers identificeren	Patchinventaris met ernstniveaus
Beoordeling	Toepasbaarheid en risico van elke patch evalueren	Geprioriteerde patchlijst
Testen	Patches testen in staging-omgeving op compatibiliteit	Testresultaten en goedkeuring
Planning	Uitrolvensters plannen, rollbackplannen opstellen	Uitrolschema en wijzigingsverzoeken
Uitrol	Patches uitrollen naar productiesystemen	Bevestigingslogs van uitrol
Verificatie	Scannen om patches te bevestigen, functionaliteit testen	Post-patch scanresultaten
Rapportage	Compliance documenteren, uitzonderingen volgen	Patchcompliancerapport

Patchbeheertools

Categorie	Tools	Gebruiksscenario
Enterprise	SCCM/MECM, Ivanti, ManageEngine	Grote on-premises-omgevingen
Cloud-native	AWS Systems Manager, Azure Update Manager	Cloudinfrastructuur-patching
Geünificeerd	Automox, Tanium, NinjaRMM	Cross-platform en hybride omgevingen
Container	Dependabot, Renovate, Snyk	Patching van applicatie-afhankelijkheden
Linux	Canonical Livepatch, Red Hat Satellite	Linux-serveromgevingen
Kwetsbaarheid	Qualys, Tenable, Rapid7	Kwetsbaarheidgedreven patchprioritering

Patchcompliancemeetwaarden

Meetwaarde	Doel	Hoe te meten
Patchcompliancepercentage	> 95%	Systemen gepatcht binnen SLA / totaal systemen
Gemiddelde tijd tot patching (kritiek)	< 72 uur	Gemiddeld aantal dagen van release tot uitrol
Kritieke patchdekking	100%	Kritieke patches toegepast binnen SLA
Aantal uitzonderingen	< 5% van assets	Systemen met goedgekeurde uitzonderingen
Patchfaalpercentage	< 2%	Patches die teruggedraaid moesten worden
Scandekking	100%	Assets opgenomen in kwetsbaarheidsscans

Compliance-eisen

Framework-mapping

Vereiste	ISO 27001	SOC 2	NIS2	DORA
Kwetsbaarheidsbeheer	A.8.8	CC7.1	Art. 21(2)(e)	Art. 9(2)
Tijdig patchen	A.8.8	CC7.1	Art. 21(2)(e)	Art. 9(2)
Wijzigingsbeheer	A.8.32	CC8.1	Art. 21(2)(e)	Art. 9(4)(e)
Risicobeoordeling	A.8.8	CC3.2	Art. 21(2)(a)	Art. 9(1)
Testen	A.8.29	CC8.1	Art. 21(2)(e)	Art. 9(4)(e)

Auditbewijs

Type bewijs	Beschrijving	Framework
Patchbeheerbeleid	Gedocumenteerd beleid met SLA's per ernstniveau	Alle frameworks
Patchcompliancerapporten	Maandelijkse rapporten die SLA-naleving tonen	Alle frameworks
Uitzonderingenregister	Gedocumenteerde uitzonderingen met risicoacceptatie en herstelplannen	Alle frameworks
Kwetsbaarheidsscanresultaten	Vergelijkingen van scans voor en na patching	Alle frameworks
Wijzigingsregistraties	Wijzigingstickets voor patchuitrollingen	ISO 27001, SOC 2
Testresultaten	Bewijs van patchtesten vóór productie-uitrol	Alle frameworks
Rollbackprocedures	Gedocumenteerde procedures voor mislukte patches	ISO 27001, DORA

Veelgemaakte fouten

Fout	Risico	Oplossing
Geen gedefinieerde patch-SLA's	Geen verantwoording voor patchsnelheid	Documenteer op ernst gebaseerde SLA's in het beleid
Wel het OS patchen, maar niet de applicaties	Kwetsbaarheden in applicaties van derden worden misbruikt	Neem alle software op in het patchbereik
Geen staging-omgeving voor testen	Patches breken productiesystemen	Test in staging vóór productie-uitrol
Firmware en IoT negeren	Netwerkapparaten en IoT blijven kwetsbaar	Neem firmware op in de patchinventaris
Alleen handmatig bijhouden	Patches worden gemist, compliancelacunes onopgemerkt	Gebruik geautomatiseerde patchbeheertools
Geen uitzonderingsproces	Ongepatchte systemen zonder documentatie of risicoacceptatie	Formeel uitzonderingsproces met compenserende maatregelen

Hoe Orbiq patchbeheercompliance ondersteunt

Orbiq helpt u patchbeheermaatregelen aan te tonen:

Bewijsverzameling — Centraliseer patchbeleid, compliancerapporten en uitzonderingenregisters
Continue monitoring — Volg patchcompliancepercentages en SLA-naleving
Trust Center — Deel uw kwetsbaarheidsbeheerspostuur via uw Trust Center
Compliance-mapping — Koppel patchmaatregelen aan ISO 27001, SOC 2, NIS2 en DORA
Auditgereedheid — Kant-en-klare bewijspakketten voor beoordeling door auditors

Verder lezen

Kwetsbaarheidsbeheer — Uitgebreide kwetsbaarheidslevenscyclus
Wijzigingsbeheer — Wijzigingscontrole voor patchuitrollingen
Endpointbeveiliging — Endpointbescherming inclusief patching
Cloudbeveiliging — Patching in cloudomgevingen
DevSecOps — Geautomatiseerde patching in CI/CD-pipelines