In mijn vorige blogs heb ik het vooral gehad over risico’s: wat ze zijn, hoe je ze inschat en wat je ermee kunt doen. Vandaag wil ik een verder vooruit kijken. Niet naar het risico, maar naar het moment dat er al iets mis is gegaan. Een incident. Want hoe beter je begrijpt waarom iets misgaat, hoe beter je voorkomt dat het nog een keer gebeurt. En daar komt de Root Cause Analysis om de hoek kijken, met als bekendste (en meest misbruikte) techniek: de 5 whys.
Laten we eerst even scherp krijgen waar we het over hebben.

Incident ≠ pech
Als er een incident gebeurt — een datalek, een systeem dat uitvalt, een verkeerde betaling — dan is de eerste reflex vaak: “Dat was gewoon pech” of “menselijke fout”. En dat klinkt logisch, maar het is bijna nooit het echte antwoord. “Menselijke fout” is geen oorzaak, het is een symptoom. Net als “pech”.
Een Root Cause Analysis (RCA) draait precies om die vraag: wat is de onderliggende oorzaak waardoor dit incident kon gebeuren? Niet om schuldigen aan te wijzen, maar om patronen bloot te leggen.
De 5 whys: simpel, maar verraderlijk
De 5 whys is een simpele methode: je stelt steeds opnieuw de vraag “waarom?” totdat je bij de kern komt. Maximaal vijf keer, soms minder, soms iets meer. Simpel op papier. In de praktijk gaat het vaak mis.
Een voorbeeld.
Incident: een medewerker heeft per ongeluk gevoelige klantdata naar het verkeerde e-mailadres gestuurd.
- Waarom ging de mail naar de verkeerde ontvanger?Omdat de medewerker het verkeerde adres selecteerde in Outlook.
- Waarom selecteerde hij het verkeerde adres?Omdat er meerdere contacten met bijna dezelfde naam in het adresboek staan.
- Waarom staan die dubbele contacten daar?Omdat oude accounts nooit zijn opgeschoond.
- Waarom worden accounts niet opgeschoond?Omdat daar geen proces of verantwoordelijkheid voor is vastgelegd.
- Waarom is dat proces er niet?Omdat er nooit is nagedacht over dit risico, en het dus ook niet is meegenomen in het risicomanagement.
En daar zit je root cause. Niet: “medewerker maakte een fout”, maar: gebrek aan structureel beheer en risicobewustzijn. Overigens kan het natuurlijk nog steeds zo zijn dat een medewerker een vergissing maakt ondanks alle genomen maatregelen. Maar daar kom je dus achter door deze methodiek te gebruiken!
De koppeling met risicomanagement
Dit is het punt waar RCA en risicomanagement elkaar raken. Een incident is namelijk vaak niets anders dan een risico dat zich heeft gerealiseerd. Achteraf gezien kun je bijna altijd zeggen: “Ja, dit risico hadden we kunnen bedenken.”
Door de 5 whys goed toe te passen:
- ontdek je welk risico je over het hoofd hebt gezien, of
- zie je dat je een risico kende, maar het te laag hebt ingeschat, of
- blijkt dat je maatregelen had, maar dat ze in de praktijk niet werkten.
Dat maakt een incidentanalyse goud waard voor je risicoanalyse. Het is gratis feedback van de realiteit.
Veelgemaakte fouten bij de 5 whys
Een paar valkuilen die ik in de praktijk vaak zie:
- Te snel stoppen. Na twee keer “waarom” denken dat je er bent. Meestal zit je dan nog op symptoomniveau.
- Technisch blijven hangen. “De server viel uit.” Ja, maar waarom was dat een probleem voor de business?
- Oplossingen vermommen als oorzaken. “We hadden een extra controle moeten hebben.” Dat is geen oorzaak, dat is een maatregel.
- Schuld zoeken. Zodra mensen zich aangevallen voelen, krijg je geen eerlijke antwoorden meer.
De kwaliteit van je 5 whys staat of valt met veiligheid in het gesprek. Het doel is leren, niet veroordelen.
Van analyse naar actie
Een Root Cause Analysis is pas af als je er iets mee doet. De uitkomst moet landen in je risicomanagement:
- Voeg het nieuw ontdekte risico toe aan je risicolijst
- Herijk kans en impact
- Bepaal of dit binnen je risk appetite valt
- Neem (of heroverweeg) maatregelen
En schrijf het op. Niet alleen voor audits of “omdat het moet”, maar omdat je over een jaar anders echt niet meer weet waarom je destijds bepaalde keuzes hebt gemaakt.
Tot slot
De 5 whys is geen magische truc. Het is een denkoefening. Maar wel een hele effectieve, mits je hem eerlijk en consequent toepast. Incidenten zijn vervelend, kosten tijd en geld, en leveren gedoe op. Maar als je ze goed analyseert, maken ze je organisatie structureel sterker.