Key takeaway
Een ISMS wordt niet matuur door alle vier de onderdelen van PDCA ergens te beschrijven. Die maturiteit ontstaat pas wanneer ze op elkaar aansluiten: risico’s leiden tot maatregelen, maatregelen worden uitgevoerd en gemeten, en de resultaten veranderen de volgende planning. Zonder die terugkoppeling heb je vier losse activiteiten. Met die terugkoppeling heb je een managementsysteem.
Vier letters. Vier stappen. Niets nieuws, zou je denken. Tot je begrijpt dat deze Plan-Do-Check-Act-cyclus (PDCA) al bijna een eeuw meegaat en vandaag nog steeds terug te vinden is in ISO 27001. De vier stappen doorlopen is één ding, ze goed toepassen binnen ISO 27001, dat is een ander verhaal. In deze blog ontdek je wat de PDCA-cyclus precies is, hoe die aansluit bij ISO 27001 en welke valkuilen je het vaakst tegenkomt bij het opbouwen van een informatiebeveiligingsmanagementsysteem.
Wat is de PDCA-cyclus?
PDCA staat voor Plan, Do, Check, Act: vier stappen die je telkens opnieuw doorloopt om een proces gestructureerd te verbeteren. Deze cyclus is geen quick fix. Er is geen moment waarop je “klaar” bent, het proces moet blijven duren want risico’s, kwetsbaarheden en dreigingen veranderen voortdurend. Je stuurt bij en herhaalt het proces. Zonder deze herhaling wordt cybersecurity een verzameling losse puzzelstukken: een firewall hier, een training daar, zonder dat iemand ooit checkt of het geheel nog standhoudt.
- Plan: waar zitten de risico’s en wat ga je eraan doen?
- Do: voer die maatregelen ook effectief uit.
- Check: houdt het stand onder druk? Test dat.
- Act: wat heb je geleerd en hoe neem je dat mee naar de volgende cyclus?
PDCA-cyclus ook bekend als…
PDCA wordt ook wel de Deming-cirkel of het Deming-wiel genoemd en, verwarrend genoeg, noemde de man wiens naam het vaakst aan de methode wordt gekoppeld, hem zelf helemaal niet zo.
Wie heeft de PDCA-cyclus uitgevonden?
De methode werd oorspronkelijk ontwikkeld door Walter A. Shewhart, een Amerikaanse natuurkundige en kwaliteitspionier die in de jaren dertig bij Bell Labs werkte aan de vraag hoe je telefoononderdelen consistent foutloos kon produceren. Hij noemde zijn model de Shewhart-cyclus en baseerde die op de wetenschappelijke methode: hypothese, experiment, evaluatie. De term PDCA (Plan-Do-Check-Act) bestond op dat moment trouwens nog niet, die kwam er pas later.
Wat is het verschil tussen PDCA en PDSA?
William Edwards Deming, een leerling van Shewhart, nam het concept over in de jaren vijftig en bracht het naar Japan, waar het wereldwijd bekend werd. Vandaar dat de methode ook zijn naam draagt. De term “PDCA” zoals we die nu kennen, ontstond trouwens pas in die periode: Japanse deelnemers aan Demings lezingen herwerkten zijn model tot “Plan-Do-Check-Act”. Deming zelf gebruikte die term echter niet. Hij sprak over Plan-Do-Study-Act (PDSA), omdat hij “Study” een betere term vond. Het ging voor hem niet enkel over controleren, maar om echt te leren van wat er gebeurd is.
Voor de praktijk maakt dat onderscheid weinig verschil… of je nu PDCA of PDSA zegt, het gaat om hetzelfde onderliggende idee van gestructureerd en cyclisch verbeteren.
Is de PDCA-cyclus nog relevant vandaag?
Sinds de update van 2022 wordt PDCA niet langer expliciet vermeld in ISO 27001. Toch verdwijnt de logica niet, je kan ze nog steeds toepassen op de clausules van de norm, ook al gebruikt de normtekst zelf de term niet meer. Het blijft de moeite waard om terug te grijpen naar het kader van PDCA, want de clausules zijn een stuk makkelijker te doorgronden en toe te passen wanneer je ze indeelt in vier herkenbare stappen. PDCA maakt het gemakkelijker om de continue verbetering die elke ISO-norm vereist ook daadwerkelijk te realiseren.
Clausules 1 tot en met 3 (Toepassingsgebied, Normatieve verwijzingen, Termen en definities) komen in dit overzicht niet voor: ze zijn puur informatief en bevatten geen concrete eisen. Pas vanaf clausule 4 begint het echte werk.
Hoe ziet de PDCA-cyclus er in de praktijk uit binnen ISO 27001?
In theorie is het makkelijk maar wie vandaag effectief een ISMS moet opbouwen, heeft meer nodig dan vier abstracte woorden. Elke stap krijgt een concrete invulling: welke risico’s brengt Plan in kaart, welke maatregelen horen bij Do, hoe test je tijdens Check of het werkt en wat betekent bijsturen in de praktijk bij Act?
Concreet ingevuld voor een ISO 27001-traject, zien de vier stappen er zo uit:
1. Plan
- Breng de context van de organisatie in kaart: interne en externe factoren, en wie de belanghebbende partijen zijn
- Bepaal de scope van het ISMS: welke processen, locaties en systemen vallen eronder?
- Zorg voor betrokkenheid van het management: laat hen het informatiebeveiligingsbeleid mee vastleggen en actief uitdragen, niet enkel goedkeuren.
- Ken rollen en verantwoordelijkheden toe
- Voer een risicoanalyse uit: breng kritieke bedrijfsprocessen en de bijhorende risico’s in kaart, en stel de risicocriteria op waarmee je ze beoordeelt
- Bepaal op basis daarvan de risicobehandeling: welke maatregelen krijgen prioriteit?
- Stel meetbare beveiligingsdoelstellingen op
- Voorzie voldoende middelen, competenties, bewustzijn en communicatie om dit alles ook effectief te kunnen uitvoeren
2. Do
- Implementeer technische maatregelen (bv. multi-factor authenticatie, netwerksegmentatie)
- Rol nieuwe procedures uit, zoals een incident response-plan
- Train medewerkers en management op hun rol binnen die procedures
3. Check
- Monitor doorlopend of maatregelen effectief werken
- Verzamel metrics zoals reactietijden of het aantal gemelde incidenten
- Analyseer gemelde incidenten of near-misses
- Evalueer die gegevens: voldoen de resultaten aan de vooropgestelde doelstellingen?
- Voer interne audits uit om formeel te toetsen of het ISMS als geheel nog aan de norm voldoet
- Test de paraatheid via oefeningen (bv. een phishing-simulatie of tabletop-oefening)
4. Act
- Onderzoek bij elke tekortkoming of elk incident niet enkel het symptoom, maar ook de onderliggende oorzaak: root cause analysis
- Werk beleid en procedures bij op basis van die auditresultaten of incidenten
- Escaleer structurele tekortkomingen naar het management
- Koppel de geleerde lessen terug naar de Plan-fase, zodat de volgende cyclus start vanuit een scherper beeld in plaats van dezelfde blinde vlek
Wat zijn veelgemaakte fouten bij PDCA binnen een ISO 27001-traject?
Risicoanalyse afgerond. Klaar?
Je kan een technisch perfecte risicoanalyse hebben, maar als niemand er verantwoordelijkheid voor draagt, niemand de tijd of middelen heeft om er iets mee te doen en het management het niet ondersteunt, blijft het gewoon een document dat ergens opgeslagen staat in de cloud.
Veel organisaties herleiden Plan tot één stap… de risicoanalyse. Terecht belangrijk, maar dat is slechts clausule 6. De volledige Plan-fase omvat ook de context van de organisatie (clausule 4), leiderschap en betrokkenheid van het management (clausule 5), en de nodige middelen en competenties om er iets mee te doen (clausule 7).
Gepubliceerd. Maar uitgevoerd?
Clausule 8 gaat over de uitvoering, maar “uitvoering” betekent hier meer dan een beleidsdocument publiceren op het intranet. Het vraagt een operationeel planningsbord: concrete acties, toegewezen aan mensen met een tijdslijn.
Er is een verschil tussen beleid hebben (een intentieverklaring) en beleid uitvoeren (er ook echt iets mee doen, dag na dag). Zolang een beleid niet terugkomt in hoe mensen daadwerkelijk werken, hoort het nog steeds bij Plan, ook al staat er “beleid” op de kaft.
Eén keer per jaar checken? Dat is geen “Check”.
De interne audit (clausule 9.2) is het bekendste onderdeel van Check, maar niet het enige. Clausule 9.1 vraagt om monitoring en measurement: doorlopend nagaan of maatregelen effectief werken, niet alleen op het moment dat de auditor langskomt. Een organisatie die enkel jaarlijks checkt, mist alles wat daartussen verandert. Naast monitoring, measurement en interne audit, hoort ook de management review (clausule 9.3) bij Check. Daar beoordeelt het management of het ISMS nog relevant en effectief is, en welke veranderingen nodig zijn.
Check is dus een doorlopend proces van meten en opvolgen, met de jaarlijkse interne audit en de management review als formele controlemomenten daarbovenop. Zonder die doorlopende monitoring merk je pas bij de volgende audit, soms maanden later, dat iets allang fout liep.
Het lek is gedicht. Het probleem niet.
Wanneer er iets misloopt (een audit vindt een tekortkoming, of er gebeurt een echt incident), denken de meeste bedrijven dat Act simpelweg betekent: dat ene probleem oplossen. Er is bijvoorbeeld een kwetsbaarheid gevonden? Patch uitrollen, klaar, vinkje gezet.
Clausule 10 vraagt meer. Onderzoek ook de root cause, de onderliggende oorzaak van het probleem. Pas wanneer die root cause teruggekoppeld wordt naar Plan, is de cirkel ook echt rond en voorkom je dat dezelfde kwetsbaarheid een paar maanden later in een andere vorm opnieuw opduikt.
