Er verschijnt weer een melding over een kritieke kwetsbaarheid. Ergens in een systeem dat je waarschijnlijk gebruikt. Of misschien niet, dat weet je op dat moment nog niet eens zeker. Er volgt een hectische zoektocht: wie beheert dit systeem, staat het bij ons ook open, moet er nu iets gebeuren? Tegen de tijd dat je het antwoord hebt, is het weekend alweer voorbij en begint iedereen gewoon weer aan het werk. Tot de volgende melding.
Komt dit bekend voor, dan ben je in elk geval niet de enige. Het overkomt de meeste bedrijven die geen wijzigingsproces hebben. En dat is precies waar wij het verschil zien tussen bedrijven die telkens schrikken en bedrijven die rustig blijven.
Het patroon dat je vast herkent
De cyclus is bij vrijwel elk bedrijf hetzelfde. Een leverancier of overheidsinstantie meldt een kwetsbaarheid. Iemand binnen het bedrijf slaat alarm, vaak toevallig degene die het nieuws leest. Er wordt haastig gecontroleerd, gepatcht, en gehoopt dat er niets misgaat. Als het goed afloopt, is de opluchting groot en gaat iedereen door met de dagelijkse dingen. Tot de volgende melding zich aandient, en de hele cyclus opnieuw begint.
Het probleem hierbij is niet dat er kwetsbaarheden zijn. Die zijn er altijd, in elk systeem, bij elke leverancier. Het probleem is dat er geen vaste manier is om erop te reageren. Zonder proces reageer je op reflex, en reflexen zijn onvoorspelbaar: soms snel en grondig, soms te laat of half.
Het echte probleem is niet het lek, maar het ontbreken van beleid
Wat bedrijven die telkens in paniek raken meestal missen, is geen technische kennis maar een vastgelegd wijzigingsbeleid. Dat is niets anders dan heldere afspraken over wie mag beslissen dat een systeem wordt aangepast, hoe je test of die aanpassing geen nieuwe problemen veroorzaakt, en hoe je communiceert naar iedereen die ermee werkt.
Zonder die afspraken hangt alles af van wie er die dag toevallig aandacht heeft, wie er bereikbaar is, en hoeveel tijd er is voordat het weekend begint. Met die afspraken maakt het niet meer uit of het een kritiek lek is of een gewone software-update: het proces staat, en de techniek volgt daarna.
Eerst meten, dan beleid, dan pas techniek
Bij Motics draaien we die volgorde bewust om ten opzichte van hoe de meeste bedrijven het aanpakken. Veel bedrijven grijpen bij een nieuwe dreiging meteen naar een technische oplossing: een extra beveiligingstool, een nieuwe scanner, een noodpatch. Maar zonder overzicht van wat je eigenlijk hebt draaien, weet je niet waar die techniek op moet landen.
Daarom beginnen wij altijd met meten: welke systemen zijn er, wie is er verantwoordelijk voor, en wat is kritiek voor het draaien van je bedrijf. Pas als dat helder is, leg je beleid vast: wie mag wijzigen, hoe test je, wanneer communiceer je. En dan pas volgt de techniek die dat beleid ondersteunt. Wie deze volgorde omdraait, koopt techniek die niemand goed gebruikt omdat het proces er niet achter staat.
Mensen mee, voordat je iets verplicht
Een wijzigingsproces werkt alleen als de mensen die ermee te maken hebben, het ook begrijpen en accepteren. Een medewerker die een systeem gebruikt, moet weten waarom een update soms even wacht op een testmoment, en waarom een andere update juist met voorrang wordt doorgevoerd. Leg dat uit voordat je het verplicht stelt. Beleid dat als een dictaat naar binnen wordt gedrukt, wordt genegeerd zodra het lastig wordt. Beleid dat wordt uitgelegd, wordt gedragen.
Wat je nu concreet kunt doen
Je hoeft niet in één keer een compleet proces op te tuigen. Begin met deze stappen:
- Maak een lijst van je kritieke systemen: wat mag nooit uitvallen en wie is daarvoor verantwoordelijk.
- Leg vast wie binnen jouw bedrijf mag beslissen dat een wijziging of patch wordt doorgevoerd, en binnen welke termijn.
- Spreek af hoe je test voordat je iets live zet, ook als dat testen maar een paar uur duurt.
- Bepaal wie geïnformeerd moet worden als er iets verandert, en hoe je dat doet.
Deze vier punten leggen de basis. Ze kosten geen nieuwe techniek, alleen tijd en aandacht om het gewoon eens op papier te zetten.
Waarom dit ook telt richting NIS2
Onder NIS2 wordt van bedrijven verwacht dat ze aantoonbaar kunnen maken hoe ze omgaan met wijzigingen en kwetsbaarheden, niet dat ze op gevoel handelen. Een vastgelegd wijzigingsproces is precies het soort bewijs dat daar bij past: het toont dat je niet afwacht tot er iets misgaat, maar structureel werkt aan beheersing. Zo’n proces voelt misschien als een verplichting erbij, maar het volgt logisch uit hoe je toch al zou willen werken.
Een paar vragen die we vaak krijgen
Betekent een wijzigingsproces dat elke update nu langer duurt?
Niet per se. Kritieke kwetsbaarheden die actief worden misbruikt, kun je in je beleid juist als uitzondering benoemen met een kortere doorlooptijd. Het proces bepaalt de snelheid per situatie, in plaats van dat de snelheid steeds opnieuw wordt uitgevonden.
Is dit alleen zinvol voor bedrijven met een eigen ICT-afdeling?
Nee, juist bedrijven zonder eigen ICT-afdeling hebben er baat bij. Zonder vastgelegd proces hangt alles af van de ICT-partner die toevallig het snelst reageert, terwijl met een proces vooraf helder is wie waarvoor verantwoordelijk is.
Hoe voorkom ik dat het proces zelf weer een papieren tijger wordt?
Houd het klein en praktisch: een paar afspraken die iedereen kan navertellen werken beter dan een dik document dat niemand leest. Toets het proces regelmatig aan een echte situatie, dan blijft het levend.
Moet ik dit proces voor elk systeem apart inrichten?
Nee, wij kijken liever naar samenhangende domeinen dan naar losse systemen, bijvoorbeeld alles wat met je bedrijfskritieke werkplekken of je netwerk te maken heeft. Dat maakt het proces overzichtelijker en makkelijker om vast te houden.
Wil je weten hoe een wijzigingsproces er voor jouw bedrijf concreet uit zou zien? Wij denken graag met je mee, vanuit overzicht in plaats van paniek.
