Bijna elke week verschijnt er wel een melding over een kwetsbaarheid die snel aandacht vraagt. De toon is vaak hetzelfde: dit moet nu opgelost worden, anders loop je risico. Voor veel ondernemers voelt dat als een soort automatisme. Er komt een update binnen, en die wordt zo snel mogelijk geïnstalleerd. Begrijpelijk, maar ook riskant. Want wie heeft eigenlijk besloten dat dit nú moet gebeuren, op dit systeem, op dit moment? En wie houdt er rekening mee wat er gebeurt als die update iets anders raakt dan bedoeld?
Een update is een beslissing, geen reflex
Een update lijkt een technische handeling. Een knop die wordt ingedrukt, een systeem dat opnieuw opstart, klaar. Maar in een bedrijf met een productielijn, een warehouse-systeem of een planning voor transport ligt dat anders. Een update kan een koppeling verstoren, een machine stilzetten of een proces vertragen dat net op dat moment loopt. Soms is snel handelen nodig, bijvoorbeeld als een kwetsbaarheid actief wordt misbruikt. Maar snel handelen zonder proces is geen veiligheid. Het is gokken met een ander risico dan het risico dat je wilde voorkomen.
Eerst meten, dan pas kiezen
Je kunt niet beslissen over iets wat je niet in beeld hebt. Voordat je bepaalt of een update meteen wordt doorgevoerd of eerst wordt getest, moet je weten welke systemen er precies geraakt worden. Welke applicatie draait op welke server, welke afdeling is daarvan afhankelijk, en wat gebeurt er als dat systeem een paar uur niet beschikbaar is? Bij veel bedrijven ontbreekt dat overzicht, en dan wordt een update een gok in plaats van een afweging. Wij beginnen daarom altijd met die inventarisatie: wat heb je, wat raakt het, en wat is de impact als het misgaat.
Beleid vóór techniek: wie beslist, binnen welke termijn
Als het overzicht er is, volgt de volgende stap: vastleggen wie de beslissing mag nemen en binnen welke termijn dat moet gebeuren. Niet elke update heeft dezelfde urgentie. Een kritieke kwetsbaarheid die actief wordt misbruikt, vraagt om een andere aanpak dan een routinematige update van een kantoorapplicatie. Leg vast wie mag beslissen dat een update direct wordt doorgevoerd, en wie bepaalt dat er eerst getest wordt op een omgeving die niet in productie draait. Dat hoeft geen zwaar document te zijn. Het zijn een paar afspraken die voorkomen dat een beslissing wordt genomen onder tijdsdruk, door wie er toevallig als eerste de melding leest.
Mensen meenemen voordat je iets verplicht
Een beleid werkt pas als de mensen die ermee te maken krijgen het ook begrijpen. Een productieleider die midden in een draaiende order ineens hoort dat er een update wordt uitgerold, reageert anders dan iemand die vooraf weet wanneer dat soort momenten gepland staan. Wij nemen daarom altijd eerst de tijd om met de mensen op de vloer te bespreken wat een wijziging betekent voor hun werk, voordat we het verplicht stellen. Dat voorkomt weerstand, en het voorkomt dat een update stilletjes wordt uitgesteld omdat niemand het moment goed vond.
Denken in domeinen, niet in losse updates
Een patch staat nooit op zichzelf. Het hoort bij een breder domein van wijzigingsbeheer, waarin ook asset-beheer, toegang en herstelprocedures een rol spelen. Daarom kijken wij niet naar een update als losse taak die ergens op een lijstje wordt afgevinkt, maar als onderdeel van een proces dat we samen met jou vastleggen en kunnen aantonen. Dat is ook precies wat telt voor organisaties die aantoonbaar richting NIS2 willen werken: geen gevoel dat het wel goed zit, maar een proces waarin je kunt laten zien wie heeft beslist, wanneer, en op basis waarvan.
Wat je nu kunt doen
- Maak een overzicht van je systemen en hun onderlinge afhankelijkheden, zodat je weet wat een update kan raken.
- Leg vast wie mandaat heeft om te kiezen tussen direct uitrollen en eerst testen, en beschrijf de termijnen per urgentieniveau.
- Bespreek met de mensen die het werk doen wanneer wijzigingen passen in hun planning, en wanneer niet.
- Maak patchen onderdeel van een vast wijzigingsproces, in plaats van iets wat je pas regelt zodra er een melding binnenkomt.
Een paar vragen die we vaak krijgen
Betekent dit dat we kritieke updates altijd eerst moeten testen?
Nee, dat hoeft niet. Bij een kwetsbaarheid die actief wordt misbruikt, kan direct doorvoeren de juiste keuze zijn. Het punt is dat die keuze bewust wordt gemaakt door iemand met mandaat, op basis van wat je weet over de impact, in plaats van automatisch omdat de melding net binnenkwam.
Wie zou in ons bedrijf die beslissing moeten nemen?
Dat verschilt per organisatie, maar het moet iemand zijn die zowel de technische impact als de bedrijfsimpact overziet. Vaak is dat de directeur samen met degene die het ICT-beheer doet, met vooraf afgesproken criteria, zodat niet bij elke melding opnieuw gediscussieerd hoeft te worden.
Hoeveel tijd kost het om zo’n proces op te zetten?
De eerste inventarisatie en de basisafspraken zijn vaak binnen enkele weken te maken. Het is geen project dat je in één keer afrondt. Het groeit mee met je bedrijf, naarmate systemen veranderen en nieuwe afhankelijkheden ontstaan.
Wat als we helemaal geen testomgeving hebben?
Dat hoeft niet meteen een losstaande investering te zijn. Vaak kun je met een deel van je bestaande infrastructuur, of met een tijdelijke kopie van een systeem, al genoeg testen om de grootste risico’s eruit te halen voordat je live gaat.
Wil je weten hoe wijzigingsbeheer er in jouw bedrijf uitziet, en wie bij jullie nu eigenlijk beslist over updates? Wij denken daar graag met je over mee.
