Corrigerende maatregelen bij ISO 27001: van bevinding naar bewijs

U heeft een bevinding op tafel liggen: een auditor heeft een afwijking vastgesteld, of uw eigen interne audit heeft een non-conformiteit blootgelegd. De vraag is dan niet meer wát het precies is — lees anders eerst wat een non-conformiteit precies is — maar wat er nu concreet van u wordt verwacht. Dit artikel behandelt het corrigerende-maatregelenproces (in de praktijk vaak CAPA genoemd, naar het Engelse corrective and preventive action) zoals clausule 10.2 van ISO 27001 dat voorschrijft: van de eerste reactie op de bevinding tot het daadwerkelijk aantonen dat de oorzaak is weggenomen — niet alleen dat er iets over is opgeschreven.

Van bevinding naar corrigerende maatregel: het proces in het kort

Clausule 10.2 beschrijft een vaste volgorde, en die volgorde is niet vrijblijvend. Bij elke bevinding reageert u eerst op het probleem zelf: de directe correctie, waarmee u de situatie onder controle krijgt. Pas daarna beoordeelt u of er een structurele corrigerende maatregel nodig is — moet de onderliggende oorzaak worden weggenomen, of was dit een eenmalige uitschieter die verder geen actie vraagt? Is een corrigerende maatregel nodig, dan voert u die uit, beoordeelt u vervolgens of ze daadwerkelijk effectief was, en werkt u — als de bevinding een breder risico blootlegt — de risicobeoordeling van het ISMS bij. Elke stap wordt onderweg gedocumenteerd, niet achteraf gereconstrueerd.

Deze twee begrippen worden vaak door elkaar gebruikt, maar clausule 10.2 maakt bewust onderscheid. Een correctie lost het concrete incident op — het foutieve toegangsrecht wordt ingetrokken, het lek wordt gedicht, het verkeerd verzonden document wordt teruggehaald. Een corrigerende maatregel gaat een stap verder en pakt aan waaróm dat kon gebeuren, zodat hetzelfde probleem zich niet in een andere vorm herhaalt. Niet elke bevinding heeft per se een corrigerende maatregel nodig — soms is een correctie voldoende, bijvoorbeeld bij een aantoonbaar eenmalige menselijke vergissing zonder onderliggende procesfout. Die afweging hoort u wel expliciet te maken en vast te leggen, niet stilzwijgend over te slaan.

De meest onderschatte stap in die cyclus is de vierde: beoordelen of de maatregel wérkte. In de praktijk wordt een corrigerende maatregel te vaak behandeld als een administratieve handeling — een zin genoteerd, een actie afgevinkt, het dossier gesloten. Dat is niet wat de norm vraagt. 'Afgesloten' is niet hetzelfde als 'effectief'. Effectiviteit moet op een later moment aantoonbaar zijn, niet beweerd worden op het moment dat de actie wordt doorgevoerd. Dit verschil — tussen een taak afvinken en een oorzaak daadwerkelijk wegnemen — is precies waar herhaalbevindingen bij een volgende audit doorgaans uit voortkomen.

Root cause analyse: de oorzaak, niet alleen het symptoom

De meest voorkomende misstap bij corrigerende maatregelen is het repareren van het symptoom in plaats van de oorzaak. Een bekend voorbeeld: een medewerker maakt een fout bij het toekennen van toegangsrechten, en de corrigerende maatregel bestaat uit... die ene medewerker nogmaals trainen. Dat lost mogelijk het individuele incident op, maar niet de onderliggende vraag: waarom liet het proces deze fout überhaupt toe? Ontbrak een vier-ogen-controle? Was de procedure onduidelijk of niet vindbaar? Was de verantwoordelijkheid niet eenduidig belegd? Zonder die vraag te beantwoorden, is de kans reëel dat dezelfde soort fout — bij deze of een andere medewerker — zich op termijn herhaalt.

Een root cause analyse hoeft niet complex te zijn. Eenvoudige methodes zoals de '5x waarom' (herhaaldelijk doorvragen naar de onderliggende reden) of een basale oorzaak-gevolganalyse volstaan voor de meeste bevindingen binnen een ISMS. Het doel blijft steeds hetzelfde: onderscheid maken tussen wat er is misgegaan (het symptoom) en waarom het proces dat toeliet (de oorzaak). Alleen die laatste vraagt om een structurele corrigerende maatregel — een herhaalde instructie of een eenmalige correctie is dat per definitie niet.

In de praktijk is de oorzaak zelden één enkel feit. Vaak is het een combinatie: een proces dat niet duidelijk beschreven stond, een systeem dat een risicovolle actie niet technisch blokkeerde, én een medewerker die niet wist bij wie te melden dat iets niet klopte. Een corrigerende maatregel die alleen het meest zichtbare van de drie aanpakt — meestal de mens, omdat dat de makkelijkste knop lijkt om aan te draaien — laat de andere twee onaangeroerd. Neem daarom de tijd om door te vragen tot minstens het niveau van proces en systeem, niet alleen tot het niveau van individueel gedrag.

Corrigerende maatregel uitvoeren en vastleggen

Zodra de oorzaak helder is, krijgt de corrigerende maatregel een concrete eigenaar en een deadline — niet 'het team' of 'de afdeling', maar één met naam aanwijsbare verantwoordelijke. Zonder eigenaarschap verdwijnt een actie stilzwijgend van de lijst zodra de aandacht verslapt, en juist dát is wat een volgende audit blootlegt.

Minstens zo belangrijk: bouw het bewijsdossier op terwíjl u de maatregel uitvoert, niet achteraf. Dat betekent de root cause analyse zelf vastleggen — niet alleen de conclusie — de genomen actie documenteren met datum en betrokkenen, en wijzigingen in procedures, systemen of trainingen archiveren op het moment dat ze plaatsvinden. Een auditor die maanden later vraagt wát er is gedaan en wannéér, moet dat bewijs kunnen terugvinden. Reconstructie achteraf oogt zelden overtuigend en is in de praktijk vaak onvolledig — juist de details die het verschil maken tussen aannemelijk en aantoonbaar raken dan zoek.

Concreet betekent dit bijvoorbeeld: een bijgewerkte procedure met versiedatum en wijzigingslog, een aanwezigheidsregistratie van een aanvullende training, een export of screenshot waaruit blijkt dat een systeeminstelling daadwerkelijk is aangepast, of een aantekening in het risicoregister die naar de bevinding verwijst. Een losse mondelinge toezegging dat "dat inmiddels is opgelost" is geen bewijs — het is een bewering die bij de volgende audit alsnog moet worden onderbouwd.

Effectiviteit aantonen: wat een auditor hier daadwerkelijk checkt

Bij een vervolgbezoek van de certificerende instelling — zie wat de certificerende instelling hier vervolgens van controleert — draait het niet primair om het dossier zelf, maar om wat er ná de actie is gebeurd. De vraag die een ervaren auditor stelt, is niet 'staat het opgeschreven', maar 'is er bewijs dat de onderliggende oorzaak daadwerkelijk is weggenomen, gecontroleerd op een moment dat daar genoeg tijd voor is verstreken'. Een actie die net is doorgevoerd, kan nog niet als effectief worden bestempeld: er moet minstens één gelegenheid zijn geweest waarop het proces onder normale omstandigheden opnieuw is gedraaid, zonder dat de fout zich herhaalde.

Wat hier niet volstaat, is een subjectieve inschatting van de proceseigenaar dat 'het nu goed voelt'. Effectiviteit moet objectief waarneembaar zijn: een meting, een steekproef, een herhaalde controle met een concreet resultaat — iets dat een buitenstaander zonder voorkennis zou kunnen navolgen en tot dezelfde conclusie zou komen.

Een veelgemaakte fout is dat er geen concrete hercontroledatum wordt vastgelegd. Een corrigerende maatregel zonder gepland evaluatiemoment blijft hangen in een vaag 'we houden het in de gaten' — en dat is precies wat bij een volgend bezoek als onvoldoende aantoonbaar wordt beoordeeld. Plan de hercontrole bij voorkeur op een concreet, herkenbaar moment: de eerstvolgende keer dat het proces normaal gesproken draait — de volgende toegangsreview, de volgende releasecyclus, het volgende kwartaalcontrolemoment — in plaats van een willekeurige kalenderdatum die los staat van de praktijk.

Terugkoppelen naar risicobeoordeling en SoA

Niet elke bevinding is een geïsoleerd incident. Als een corrigerende maatregel een structurele zwakte blootlegt — bijvoorbeeld een beheersmaatregel die in de Statement of Applicability als 'geïmplementeerd' stond, maar in de praktijk niet aantoonbaar functioneerde — dan stopt het werk niet bij het oplossen van dát ene geval. De risicobeoordeling en de SoA moeten worden bijgewerkt om die bredere zwakte te reflecteren. Gebeurt dat niet, dan duikt dezelfde categorie bevinding bij uw volgende interne audit opnieuw op — mogelijk op een andere plek, maar met dezelfde onderliggende oorzaak.

Het verschil is vaak te herkennen aan de vraag: is dit de eerste keer dat dit specifieke geval misging, bij deze ene medewerker, op dit ene moment? Dan is de kans groter dat het bij een geïsoleerde correctie kan blijven. Speelt de onderliggende zwakte mogelijk op meerdere plekken in de organisatie, of raakt ze een beheersmaatregel die u eerder als afdoende had beoordeeld? Dan hoort de risicobeoordeling zelf te worden herzien, niet alleen het individuele geval te worden hersteld.

Dit is ook waar de cyclus zich daadwerkelijk sluit: de uitkomst van een corrigerende maatregel is verplichte input voor de eerstvolgende management review, en de effectiviteit ervan wordt op zijn beurt weer getoetst bij de volgende interne audit. Zo blijft het geen eenmalige actie na een onprettige bevinding, maar een terugkerend onderdeel van hoe het ISMS wordt onderhouden en verbeterd.

Wilt u dit proces structureel borgen in plaats van ad hoc bijhouden? Onze interne-auditchecklist en management review-checklist geven een praktisch overzicht van wat u per stap moet vastleggen — van eigenaarschap en hercontroledatum tot de verplichte inputs voor de eerstvolgende management review.

ISO/IEC 27001 — officiële normpagina (officiële bron).