Tag: compliance

  • Wanneer audits juist rust kunnen geven

    Wanneer audits juist rust kunnen geven

    De audit is afgerond. De auditor heeft vragen gesteld, aandachtspunten benoemd en zichtbaar gemaakt waar extra aandacht nodig is.

    Toch voelt de compliance-verantwoordelijke vooral opluchting.

    Niet alleen omdat het gesprek goed verliep. Ook omdat eindelijk duidelijk is waar de organisatie werkelijk staat. Onderwerpen die al maanden op de achtergrond meespeelden, zijn uitgesproken. Verschillende interpretaties zijn naast elkaar gelegd. Van enkele acties is vastgesteld dat ze minder ver waren dan gedacht.

    Er is werk te doen, maar de onduidelijkheid is kleiner geworden.

    Dat is het moment waarop een audit juist rust kan geven.

    Waarom onzekerheid meer druk geeft dan een bevinding

    Auditstress wordt vaak gekoppeld aan de mogelijkheid dat een auditor iets vindt. In de praktijk ontstaat veel spanning door onzekerheid.

    Is het overzicht nog actueel? Is een maatregel werkelijk uitgevoerd? Kan iemand uitleggen waarom een risico is geaccepteerd? En vertellen betrokkenen daar hetzelfde verhaal over?

    Wanneer compliance naast andere verantwoordelijkheden wordt opgepakt, komt veel context gemakkelijk bij één persoon terecht. Diegene onthoudt welke acties nog openstaan, waar informatie is opgeslagen en welke afspraken vooral mondeling zijn gemaakt.

    Een goede audit kan dat patroon onderbreken. Er wordt doorgevraagd, informatie wordt bij elkaar gebracht en aannames worden expliciet gemaakt. Dat kan ongemakkelijk zijn, maar het haalt onderwerpen ook uit de sfeer van vermoedens.

    Een concreet verbeterpunt geeft vaak meer rust dan een vaag gevoel dat iets mogelijk niet klopt.

    Waarom extra voorbereiding maar tijdelijk helpt

    Wanneer een audit nadert, proberen organisaties onzekerheid vaak te verkleinen door intensiever voor te bereiden. Informatie wordt verzameld, documenten worden gecontroleerd en collega’s nemen mogelijke vragen door.

    Dat maakt het auditmoment overzichtelijker, maar de rust houdt niet vanzelf aan. Na de audit verschuift de aandacht terug naar het dagelijkse werk. Nieuwe besluiten worden opnieuw verspreid vastgelegd en bij een volgende audit begint dezelfde reconstructie.

    Ook één medewerker die alle verbanden kent, biedt beperkt houvast. De audit kan dan soepel verlopen, terwijl de organisatie afhankelijk blijft van individueel geheugen.

    Duurzamere rust ontstaat wanneer antwoorden niet volledig afhankelijk zijn van één persoon.

    Structuur maakt openstaande punten beheersbaar

    Structuur betekent niet dat iedere handeling uitgebreid moet worden beschreven. Het betekent dat de belangrijkste keuzes herkenbaar blijven.

    Daarvoor moet zichtbaar zijn waarom een risico prioriteit kreeg, wie verantwoordelijk is voor de opvolging, wat daadwerkelijk is uitgevoerd en wanneer de gekozen aanpak opnieuw wordt beoordeeld.

    Wanneer die samenhang tijdens het gewone werk behouden blijft, verandert de functie van een audit. De auditor kan beoordelen of het vastgelegde beeld overeenkomt met de praktijk, terwijl de organisatie haar keuzes kan toelichten.

    Ook openstaande punten worden dan minder bedreigend. Ze hoeven niet allemaal op hetzelfde moment te worden opgelost, zolang de aard en urgentie bewust zijn gewogen, een verantwoordelijke is aangewezen en de opvolging is afgesproken.

    Een gedeelde werkwijze kan daarbij helpen. Niet als auditmachine of vervanging van het gesprek, maar als gezamenlijk geheugen waarin besluiten, verantwoordelijkheden en opvolging bij elkaar blijven.

    De audit als periodiek rustpunt

    Een audit kan zo een moment worden waarop de organisatie stopt met aannemen en opnieuw kijkt naar wat werkelijk zichtbaar is.

    Werkt de praktijk nog zoals bedoeld? Zijn verantwoordelijkheden nog logisch verdeeld? Welke afspraken zijn veranderd? En welke actie staat al langere tijd open zonder dat daar bewust over is besloten?

    De rust zit niet in het vermijden van bevindingen. Ze zit in het verkleinen van het verschil tussen wat de organisatie denkt dat er gebeurt en wat aantoonbaar gebeurt.

    Wie na een audit alleen opgelucht is omdat het gesprek voorbij is, weet dat de spanning waarschijnlijk terugkomt. Wie opgelucht is omdat keuzes, verantwoordelijkheden en openstaande punten weer helder zijn, gebruikt de audit anders.

    Dan is de audit geen onderbreking van het werk, maar een moment waarop de organisatie zichzelf opnieuw begrijpelijk maakt. De belangrijkste vraag na afloop is daarom niet alleen of de auditor voldoende antwoorden heeft gekregen, maar vooral of de organisatie haar eigen situatie beter begrijpt.

    Verder lezen

  • Waarom auditvragen al snel als controle voelen

    Waarom auditvragen al snel als controle voelen

    De auditor stelt een eenvoudige vraag: “Wie bepaalt of dit risico acceptabel is?”

    Het blijft even stil. Niet omdat niemand het antwoord weet, maar omdat meerdere antwoorden mogelijk zijn. De compliance-verantwoordelijke verwijst naar een eerder overleg. Een collega denkt dat de directie het besluit nam. In het risico-overzicht staat alleen dat het risico is geaccepteerd.

    Dan volgt de vraag waarom dat op dat moment een verdedigbare keuze was. Vanaf dat moment voelt het gesprek niet meer als een toetsing van de organisatie, maar als een beoordeling van de mensen aan tafel.

    Toch probeert de auditor vooral vast te stellen of afspraken, gemaakte keuzes en de dagelijkse praktijk met elkaar samenhangen.

    Waarom een audit persoonlijk kan voelen

    Een audit doorbreekt de vanzelfsprekendheid van het dagelijkse werk. In organisaties met korte lijnen is veel context gedeeld. Mensen weten wie ergens over gaat, waarom een uitzondering bestaat en welke afspraken informeel zijn gemaakt. Dat werkt vaak goed.

    Een auditor kan er alleen niet van uitgaan dat die gedeelde context voldoende is. Daarom worden vragen gesteld die intern nauwelijks nodig lijken: wie besloot dit, waarop was dat gebaseerd en wat gebeurde er daarna?

    De organisatie moet daardoor woorden geven aan werkwijzen die normaal op ervaring en onderling begrip draaien. Het ongemak wordt vervolgens gemakkelijk toegeschreven aan de auditor. De vraag voelt kritisch, terwijl vooral zichtbaar wordt dat het antwoord afhankelijk is van geheugen en interpretatie.

    De reflex om het juiste antwoord te geven

    Wanneer een audit als persoonlijke controle voelt, worden mensen voorzichtig. Ze geven het antwoord waarvan zij denken dat het verwacht wordt. Twijfels, uitzonderingen en informele werkwijzen blijven buiten beeld.

    Vooraf worden documenten aangevuld, formuleringen aangescherpt en collega’s voorbereid op mogelijke vragen. Dat geeft tijdelijk houvast, maar versterkt ook het idee dat een audit een test is waarvoor de organisatie moet slagen.

    De houding van de leiding speelt hierin een belangrijke rol. Wanneer een audit wordt gepresenteerd als een moment waarop geen bevindingen mogen ontstaan, ligt defensief gedrag voor de hand.

    Een zorgvuldig geschreven procedure lost dat niet op. Op papier kan een verantwoordelijkheid helder lijken, terwijl in de praktijk meerdere mensen ervan uitgaan dat iemand anders het besluit neemt. Een maatregel kan als afgerond geregistreerd staan, terwijl niemand nog kan uitleggen wat de uitvoering heeft opgeleverd.

    Waar een auditor daadwerkelijk naar kijkt

    Een audit is een vorm van toetsing. De auditor verzamelt informatie en auditbewijs om te beoordelen in hoeverre de organisatie aan de geldende auditcriteria voldoet en of afgesproken werkwijzen aantoonbaar en consistent worden toegepast.

    Daarbij gaat het niet alleen om de vraag of iets is vastgelegd. De auditor kijkt ook naar de samenhang tussen afspraken, keuzes en gedrag.

    Hoe wordt een signaal een risico? Wie maakt de afweging? Wanneer is een maatregel voldoende?

    Dat zijn geen strikvragen. Ze maken zichtbaar of keuzes bewust en herhaalbaar ontstaan, of vooral afhankelijk zijn van degee die op dat moment aanwezig is.

    Een bevinding betekent daarom niet automatisch dat het werk slecht is uitgevoerd. Ze kan ook laten zien dat een logische werkwijze onvoldoende overdraagbaar of uitlegbaar is.

    Structuur verandert het auditgesprek

    Structuur helpt niet door ieder detail dicht te regelen. Ze helpt door de belangrijkste afwegingen vast te houden. Wie nam het besluit? Welke informatie speelde mee? Welke opvolging is afgesproken?

    Wanneer die lijn zichtbaar blijft, hoeft een auditgesprek minder op geheugen te steunen. Antwoorden hoeven niet ter plekke te worden gereconstrueerd. Ook uitzonderingen en openstaande punten kunnen dan worden besproken zonder dat zij direct voelen als bewijs dat de organisatie tekortschiet.

    Een vaste, centrale werkwijze kan dit ondersteunen, zolang die aansluit op het dagelijkse werk. Het doel is niet om een aparte administratieve werkelijkheid te bouwen, maar om te voorkomen dat de betekenis achter keuzes verdwijnt.

    Reflectie

    Dat een audit als controle voelt, zegt niet alleen iets over de audit of de auditor. Het kan vooral laten zien hoeveel van de organisatie nog rust op mondelinge afspraken, gedeelde context en individueel geheugen.

    De relevante vraag is daarom niet alleen of je klaar bent voor de volgende audit. Belangrijker is of je ook zonder audit kunt uitleggen hoe keuzes tot stand komen, wie verantwoordelijkheid draagt en waarom de gekozen aanpak passend is.

    Waar die uitleg tijdens het werk ontstaat, verliest de audit haar dreiging. Niet omdat er niets meer gevonden kan worden, maar omdat doorvragen niet langer voelt als betrapt worden.

    Dan wordt zichtbaar of de organisatie daadwerkelijk handelt zoals zij denkt dat zij handelt.

    Verder lezen

  • Wat audits blootleggen dat al langer speelde

    Wat audits blootleggen dat al langer speelde

    Een week voor de audit wordt het risicooverzicht nog eens doorgelopen. Een maatregel staat op ‘afgerond’, maar niemand kan uitleggen wat precies is uitgevoerd en waarom dat voldoende werd gevonden. Bij een ander risico ontbreekt een eigenaar. Een incident van enkele maanden geleden is geregistreerd, terwijl de opvolging alleen terug te vinden is in de mailbox van een afwezige collega.

    Tot dat moment leek er weinig aan de hand. Het werk ging door en problemen werden opgelost. Pas wanneer iemand van buiten de dagelijkse praktijk doorvraagt, blijken eenvoudige vragen lastig te beantwoorden.

    De audit veroorzaakt die onduidelijkheid niet. Ze maakt zichtbaar wat al langer speelde.

    Waarom onduidelijkheden lang verborgen blijven

    Waar mensen meerdere rollen combineren, wordt veel opgelost op basis van ervaring en onderling overleg. Dat werkt vaak efficiënt. De lijnen zijn kort en betrokkenen kennen de context achter een beslissing.

    Juist daardoor voelt het niet altijd nodig om die context vast te houden. Een risico krijgt tijdelijk minder prioriteit. Een afwijkende werkwijze blijft langer bestaan dan bedoeld. Een controle wordt uitgesteld omdat iets anders urgenter is.

    Dat kunnen verdedigbare keuzes zijn. Het probleem ontstaat wanneer later niet meer zichtbaar is dat er daadwerkelijk een keuze is gemaakt. Dan blijft onduidelijk of een risico bewust is geaccepteerd, tijdelijk is uitgesteld of eenvoudigweg is blijven liggen.

    Zoals beschreven in Auditstress is zelden een auditprobleem, ontstaat auditdruk meestal al ruim vóór het auditmoment.

    Een audit brengt losse signalen bij elkaar

    Een risico zonder eigenaar, een maatregel zonder evaluatie en een procedure die niet meer aansluit op de praktijk lijken afzonderlijke tekortkomingen. Samen vertellen ze een ander verhaal.

    Ze laten zien dat signalen wel bekend waren, maar niet steeds tot een herkenbaar besluit en aantoonbare opvolging hebben geleid. Het probleem zit dan niet alleen in de registratie. Het kan ook betekenen dat verantwoordelijkheden onvoldoende duidelijk waren, keuzes zijn uitgesteld of niemand het mandaat voelde om een besluit te nemen.

    Daarom kan een audit onverwacht zwaar voelen. Verschillende kleine onduidelijkheden worden op hetzelfde moment zichtbaar en blijken met elkaar samen te hangen.

    Waarom snel repareren weinig verandert

    De gebruikelijke reactie is praktisch. Documenten worden aangevuld, overzichten opgeschoond en ontbrekende toelichtingen alsnog geschreven.

    Dat kan nodig zijn, maar het verandert weinig wanneer de onderliggende werkwijze hetzelfde blijft. Na de audit ontstaan dan opnieuw mondelinge besluiten, losse notities en acties zonder duidelijke eigenaar. Het beeld is tijdelijk hersteld, maar de oorzaak blijft bestaan.

    Meer documentatie is daarom niet automatisch de oplossing. Een status ‘afgerond’ heeft pas betekenis wanneer duidelijk is wat is gedaan, wie dat heeft beoordeeld en op basis waarvan de uitkomst aanvaardbaar werd gevonden.

    Structuur begint bij uitlegbaarheid

    Een werkbare structuur hoeft niet zwaar te zijn. Bij belangrijke risico’s, afwijkingen en maatregelen moet vooral zichtbaar blijven wat de afweging was, wie verantwoordelijk is en wanneer opnieuw wordt beoordeeld of de gekozen aanpak nog passend is.

    Wanneer die samenhang tijdens het werk behouden blijft, hoeft zij later niet te worden gereconstrueerd. Een centrale werkwijze kan helpen om besluiten, risico’s en opvolging bij elkaar te houden. Niet als vervanging van overleg, maar als geheugen van de organisatie.

    Daarmee verandert ook de voorbereiding op een audit. De aandacht verschuift van informatie verzamelen naar controleren of de vastgelegde lijn nog overeenkomt met de praktijk.

    Wat de audit werkelijk laat zien

    Een auditbevinding kan aanleiding zijn om verder te kijken dan het punt dat letterlijk in het rapport staat. Achter een ontbrekende registratie kan onduidelijk eigenaarschap zitten. Achter een verouderd risicooverzicht kan uitgestelde besluitvorming schuilgaan. Achter een afwijkende werkwijze kan een proces zitten dat niet meer past bij de organisatie.

    De belangrijkste vraag na een audit is daarom niet alleen hoe een bevinding wordt gesloten. Interessanter is wat zij zichtbaar maakte over de periode ervoor.

    Wie daar rustig naar kijkt, ziet waar de organisatie al langer vertrouwde op geheugen, aannames of informele afstemming. Precies daar ligt de aanwijzing voor waar meer structuur werkelijk rust kan geven.

    Verder lezen

    Meer achtergrond over het auditproces staat in De initiële ISO-audit: Stapsgewijze gids naar ISO-certificering.

    In Auditvoorbereiding in ritme: altijd aantoonbaar zonder stress lees je hoe een regelmatige werkwijze voorkomt dat voorbereiding een jaarlijkse inhaalslag wordt.

    De gevolgen van verloren besluitcontext worden verder uitgewerkt in Wat er gebeurt als beslissingen niet worden vastgehouden.

  • Auditstress is zelden een auditprobleem

    Auditstress is zelden een auditprobleem

    De audit staat al maanden in de agenda. Toch verandert er iets zodra de datum dichterbij komt.

    Documenten worden opgevraagd. Openstaande acties worden nagelopen. Iemand probeert te achterhalen waarom een risico vorig jaar als acceptabel is beoordeeld. Een collega zoekt naar de meest recente versie van een overzicht. Ondertussen ontstaat discussie over wat daadwerkelijk is uitgevoerd en wat alleen ooit is afgesproken.

    De audit is nog niet begonnen, maar de druk is al voelbaar.

    Die spanning wordt vaak gezien als een logisch gevolg van toetsing. Toch ontstaat terugkerende auditstress meestal niet op het auditmoment zelf. De audit brengt vooral onduidelijkheden bij elkaar die in de maanden daarvoor verspreid zijn geraakt.

    Waarom auditdruk zo snel oploopt

    Compliance wordt vaak gedragen door mensen die ook andere verantwoordelijkheden hebben. Dat werkt zolang de context gedeeld blijft en vragen direct kunnen worden beantwoord.

    De kwetsbaarheid ontstaat wanneer risico’s, besluiten en acties verspreid raken over gesprekken, documenten, e-mails en persoonlijke herinneringen.

    Een risico is ooit besproken, maar de afweging staat nergens helder vast. Een maatregel is uitgevoerd, maar het is niet direct zichtbaar wat er precies is veranderd. Een verbeteractie heeft de status afgerond, terwijl onduidelijk blijft of het beoogde effect ook is bereikt.

    Tijdens een audit moeten deze losse onderdelen ineens één samenhangend beeld vormen. Dan blijkt dat de informatie er vaak wel is, maar dat de relaties ertussen ontbreken.

    Auditstress is daarom vaak een samenhangsprobleem.

    Het risico achter de stress

    De zichtbare druk bestaat uit zoeken, afstemmen en herstellen. Daaronder ligt een fundamenteler risico: de organisatie weet onvoldoende zeker of het eigen risicobeeld nog klopt.

    Meestal ontbreekt informatie niet volledig. Er zijn risico-overzichten, notulen, actielijsten, beleidsdocumenten en bewijsstukken. Alleen is niet altijd zichtbaar waarom een maatregel is gekozen, wie het resterende risico heeft geaccepteerd en wat met eerdere verbeterpunten is gebeurd.

    Wanneer die verbanden ontbreken, wordt uitleg afhankelijk van degene die toevallig de geschiedenis kent. Dat maakt niet alleen de audit kwetsbaar, maar ook de besluitvorming gedurende het jaar.

    Voor de besluitvorming zit het werkelijke risico namelijk niet in een ontbrekend document. Het zit in de vraag of eerdere keuzes nog rusten op actuele en herleidbare informatie. Als die onderbouwing pas rond een audit wordt gereconstrueerd, kan in de tussenliggende periode op een onvolledig beeld zijn gestuurd.

    De audit veroorzaakt dat risico niet. Zij kan wel het moment worden waarop het niet langer buiten beeld blijft.

    Waarom gangbare oplossingen weinig veranderen

    De eerste reactie op auditdruk is vaak meer voorbereiding.

    Er wordt een auditmap gemaakt, een checklist rondgestuurd en collega’s wordt gevraagd ontbrekende stukken aan te leveren. Soms worden gesprekken vooraf doorgenomen, zodat betrokkenen weten welke onderwerpen aan bod kunnen komen.

    Dat kan helpen om de audit ordelijker te laten verlopen. Het verlaagt alleen zelden de structurele druk.

    Een auditmap brengt informatie tijdelijk bij elkaar, maar herstelt niet automatisch de betekenis tussen die informatie. Een checklist helpt om onderwerpen niet te vergeten, maar maakt eerdere afwegingen niet vanzelf opnieuw uitlegbaar.

    Een andere reflex is om één persoon verantwoordelijk te maken voor de volledige voorbereiding. Dat lijkt efficiënt, maar concentreert vooral de afhankelijkheid.

    Die persoon wordt de vertaler tussen verschillende overzichten, herinneringen en interpretaties. De voorbereiding slaagt dan dankzij individuele inspanning, niet dankzij een betrouwbaar gezamenlijk beeld.

    Na afloop neemt de spanning af. De documenten worden opgeborgen en het dagelijkse werk krijgt weer voorrang. Bij een volgende audit kunnen dezelfde vragen terugkeren, zolang het onderliggende probleem niet is veranderd.

    Structuur begint vóór de audit

    Minder auditstress vraagt daarom niet in de eerste plaats om intensievere voorbereiding. Het vraagt om een andere manier van werken tussen audits in.

    Structuur betekent niet dat alles uitgebreid moet worden gedocumenteerd. Het betekent dat de belangrijkste relaties zichtbaar blijven op het moment dat keuzes worden gemaakt.

    Een risico krijgt bestuurlijke betekenis zodra duidelijk wordt welke keuze de organisatie erover maakt. Wordt het verminderd, geaccepteerd, gevolgd of later opnieuw beoordeeld? Een maatregel wordt beter uitlegbaar wanneer zichtbaar is welk risico zij beïnvloedt en wie verantwoordelijk is voor de uitvoering en beoordeling.

    Voor betrouwbare opvolging moet na uitvoering van een actie ook duidelijk zijn wat het resultaat betekent en of verdere aandacht nodig blijft.

    Waar tijd en capaciteit beperkt zijn, werkt een beperkte maar consequente structuur beter dan uitgebreide administratie die alleen rond audits wordt bijgewerkt. Het doel is niet om meer informatie op te slaan, maar om te voorkomen dat betekenis verloren gaat.

    Uitlegbaarheid als vorm van risicobeheersing

    Uitlegbaarheid wordt vaak gezien als iets dat vooral nodig is voor een auditor. In werkelijkheid is zij in de eerste plaats nuttig voor de organisatie zelf.

    Wanneer keuzes uitlegbaar zijn, hoeft minder te worden gereconstrueerd. Zichtbaar eigenaarschap voorkomt discussie over wie aan zet is. De samenhang tussen risico’s, maatregelen en besluiten maakt duidelijker waar de echte onzekerheid zit.

    Dat verbetert niet alleen de auditvoorbereiding, maar ook de kwaliteit van risicobesluiten.

    Een audit hoeft niet te bevestigen dat alles foutloos verloopt. Wel vraagt zij om een samenhangend en navolgbaar beeld van wat de organisatie wist, welke afweging zij maakte en hoe zij daarop heeft gehandeld.

    Ook een onvolledig werkende maatregel of bewust geaccepteerd risico kan uitlegbaar zijn, zolang de keuze zichtbaar blijft en opnieuw beoordeeld kan worden wanneer omstandigheden veranderen.

    Wanneer deze samenhang tijdens het werk beschikbaar blijft, hoeft zij rond de audit niet opnieuw te worden opgebouwd. Daardoor ontstaat ruimte om te bespreken of de gekozen aanpak nog werkt, in plaats van vooral te reconstrueren wat er eerder is gebeurd.

    Tooling kan daarbij ondersteunen, maar pas nadat duidelijk is welke samenhang behouden moet blijven. Zonder dat uitgangspunt ontstaat vooral een andere opslagplaats.

    Verder lezen

    Reflectie

    Auditstress zegt vaak minder over de audit dan over de periode ervoor.

    De relevante vraag is daarom niet alleen waarom een audit spanning oproept. Interessanter is welke onzekerheden door de audit ineens tegelijk zichtbaar worden.

    Moet informatie worden teruggezocht omdat zij verspreid staat? Hangt uitleg af van één persoon? Zijn besluiten wel genomen, maar niet herkenbaar vastgehouden? Wordt pas onder tijdsdruk duidelijk welke acties nog openstaan?

    Dat zijn geen problemen die door de auditor worden veroorzaakt. Het zijn signalen over de manier waarop risico’s, keuzes en opvolging in het dagelijkse werk zijn georganiseerd.

    Wie die signalen serieus neemt, hoeft de audit niet kleiner of eenvoudiger te maken. Die maakt de organisatie minder afhankelijk van het auditmoment.

    De rust ontstaat dan niet doordat er minder vragen worden gesteld, maar doordat de antwoorden al onderdeel zijn van hoe de organisatie werkt.

  • Statement of Applicability uitgelegd: waarom ISO 27001 draait om keuzes kunnen onderbouwen

    Statement of Applicability uitgelegd: waarom ISO 27001 draait om keuzes kunnen onderbouwen

    Veel organisaties die met ISO 27001 starten, kijken al snel naar Annex A. Daar staan de informatiebeveiligingsmaatregelen. De reflex is begrijpelijk: controleren wat al geregeld is, aanvinken wat bekend voorkomt en daarna de openstaande punten oppakken.

    Maar ISO 27001 werkt niet als een simpele afvinklijst. De echte vraag is niet: hebben we deze maatregel? De vraag is: waarom is deze maatregel voor ons relevant, hoe hebben we hem ingericht en kunnen we die keuze uitleggen?

    Daar begint de Statement of Applicability.

    De Statement of Applicability, vaak afgekort als SoA, is een verplicht onderdeel van het ISMS binnen ISO 27001. Niet omdat de norm om extra papierwerk vraagt, maar omdat de SoA zichtbaar maakt hoe je van risico’s naar maatregelen komt.

    Welke maatregelen zijn passend? Welke maatregelen zijn niet van toepassing? Welke risico’s accepteer je bewust? En waar is verbetering nodig?

    Wie de SoA goed gebruikt, maakt informatiebeveiliging bestuurbaar. Wie de SoA alleen invult voor de audit, mist juist de waarde ervan.

    Wat is een Statement of Applicability?

    Een Statement of Applicability is het overzicht waarin je vastlegt welke informatiebeveiligingsmaatregelen je hebt geselecteerd, welke Annex A-maatregelen van toepassing zijn en waarom bepaalde maatregelen eventueel niet van toepassing zijn.

    In de praktijk kijk je daarbij naar Annex A van ISO 27001. Daarin staan de referentiemaatregelen die helpen om breed naar informatiebeveiliging te kijken. Annex A is daarbij het referentiekader, maar niet de grens van je beveiligingsaanpak. Als uit je risicoanalyse aanvullende maatregelen nodig blijken, moeten die ook logisch in je ISMS terugkomen.

    In de SoA leg je vast welke maatregelen je toepast, welke nog aandacht vragen en welke niet van toepassing zijn. Minstens zo belangrijk is dat je vastlegt waarom.

    Daarmee is de SoA meer dan een statusoverzicht. Het is de plek waar je keuzes onderbouwt. Een checklist zegt vooral wat je hebt aangevinkt. Een goede SoA laat zien waarom een maatregel wel of niet past bij jouw risico’s, systemen, processen, leveranciers, klanten en verplichtingen.

    De SoA vormt zo de verbinding tussen risicoanalyse, maatregelen en bewijsvoering. Dat maakt het document belangrijk voor auditors, maar ook voor management en klanten die willen begrijpen hoe informatiebeveiliging is ingericht.

    Annex A is geen afvinklijst

    Een veelgemaakt misverstand is dat Annex A een lijst is die je van boven naar beneden moet afwerken. Dat lijkt overzichtelijk, maar leidt vaak tot verkeerde keuzes.

    Soms worden maatregelen ingevoerd omdat ze in de norm staan, terwijl ze weinig bijdragen aan het beheersen van de werkelijke risico’s. Soms worden maatregelen juist overgeslagen omdat ze niet direct herkenbaar lijken, zonder dat goed is onderbouwd waarom ze niet nodig zijn.

    Annex A is beter te zien als een referentieset. De maatregelen helpen je om niets belangrijks over het hoofd te zien. Denk aan toegangsbeheer, leveranciersrelaties, logging, fysieke beveiliging, incidentmanagement en bewustwording.

    Maar de keuze voor maatregelen blijft afhankelijk van jouw context en risicoanalyse. Een organisatie die volledig remote werkt, heeft andere fysieke beveiligingsrisico’s dan een productiebedrijf met een magazijn, bezoekersstromen en technische installaties. Dat betekent niet dat fysieke beveiliging genegeerd mag worden. Het betekent wel dat je moet uitleggen welke risico’s er zijn en welke maatregelen daarbij passen.

    Annex A helpt je breed te kijken. De SoA helpt je gericht te kiezen.

    Wat moet er in een goede SoA staan?

    Een goede SoA hoeft geen dik verhaal te zijn, maar moet wel per maatregel voldoende duidelijk maken waarom deze wel of niet van toepassing is.

    Een goede SoA maakt per maatregel duidelijk:

    • of de maatregel van toepassing is;
    • waarom die keuze logisch is;
    • wat de implementatiestatus is;
    • welk risico of welke verplichting erbij hoort;
    • wie eigenaar is;
    • welk bewijs beschikbaar is.

    De kern zit vooral in de onderbouwing.

    Een maatregel met de status “geïmplementeerd” zegt weinig als niet duidelijk is waarop dat oordeel is gebaseerd. Is er beleid? Wordt het proces uitgevoerd? Is er bewijs? Is iemand verantwoordelijk? Wordt de werking periodiek beoordeeld?

    Andersom is een maatregel met de status “niet van toepassing” kwetsbaar als de toelichting niet verder komt dan “niet relevant”. Dat roept bij een auditor bijna automatisch vervolgvragen op. Waarom niet relevant? Valt het buiten scope? Bestaat het proces niet? Is het risico op een andere manier beheerst? Of is er simpelweg niet goed genoeg naar gekeken?

    Een goede SoA is daarom precies genoeg. Niet te mager, want dan is hij niet verdedigbaar. Niet te uitgebreid, want dan wordt hij onbruikbaar.

    De koppeling tussen risicoanalyse en SoA

    ISO 27001 draait om een risicogebaseerde aanpak. Dat betekent dat je niet begint met maatregelen, maar met risico’s. Welke informatie wil je beschermen? Welke bedreigingen zijn relevant? Welke kwetsbaarheden bestaan er? Wat is de impact als het misgaat?

    De risicoanalyse brengt in kaart wat er kan gebeuren en hoe ernstig dat is. De SoA laat vervolgens zien welke maatregelen je kiest om daarmee om te gaan.

    Stel dat een organisatie het risico identificeert dat medewerkers slachtoffer worden van phishing. Dat risico raakt niet één maatregel, maar meerdere onderdelen van informatiebeveiliging. Je kunt denken aan bewustwording, toegangsbeheer, multi-factor authenticatie, logging, incidentrespons en e-mailbeveiliging.

    In de risicoanalyse staat dan: dit kan misgaan en dit is de mogelijke impact. In de SoA staat: daarom zijn deze maatregelen relevant, zo hebben we ze ingericht en dit is de status.

    Dat onderscheid is belangrijk. Zonder risicoanalyse wordt de SoA al snel een checklist. Zonder SoA blijven maatregelen losse keuzes zonder duidelijke samenhang.

    Juist de koppeling tussen beide maakt je ISMS uitlegbaar. Je kunt laten zien dat maatregelen niet willekeurig gekozen zijn, maar voortkomen uit risico’s, verplichtingen, klantverwachtingen en de context van je organisatie.

    Waarom uitsluitingen extra aandacht vragen

    Toegepaste maatregelen zijn vaak makkelijker bespreekbaar, omdat er meestal beleid, inrichting of bewijs tegenover staat. Je kunt laten zien wat is geregeld en hoe dat werkt.

    Spannender zijn de maatregelen die je niet toepast.

    Een uitsluiting is geen vrijstelling. Het is een keuze. En die keuze moet je kunnen uitleggen.

    Zwakke onderbouwingen klinken vaak als: “niet relevant voor ons”, “doen wij niet” of “zijn we te klein voor”. Op zichzelf zeggen die zinnen weinig. Ze maken niet duidelijk waarom een maatregel niet past bij de scope, risico’s, processen, assets of technologie van de organisatie.

    Een sterke onderbouwing legt uit waarom het risico niet bestaat, waarom het proces buiten scope valt, waarom de technologie niet wordt gebruikt of waarom het risico op een andere manier wordt beheerst.

    Neem een organisatie die geen eigen software ontwikkelt. Bepaalde secure development-maatregelen kunnen dan beperkt of niet van toepassing zijn. Maar als dezelfde organisatie wel maatwerk laat bouwen door een leverancier, verdwijnt het onderwerp niet. De aandacht verschuift dan naar leveranciersbeheer, contractuele eisen, acceptatietesten en wijzigingsbeheer.

    Dat is precies het soort nuance dat een goede SoA zichtbaar maakt.

    De SoA als gesprek met management

    De SoA wordt vaak gezien als iets van de security- of complianceverantwoordelijke. Dat is begrijpelijk, maar te beperkt. De keuzes in de SoA raken namelijk de hele organisatie.

    Management hoeft niet ieder technisch detail te kennen, maar moet wel begrijpen welke risico’s bewust worden geaccepteerd, welke maatregelen investering vragen en waar afhankelijkheden bestaan.

    Een goede SoA helpt bij vragen als: welke beveiligingsmaatregelen zijn voor ons echt kritisch? Waar accepteren we restrisico? Welke maatregelen zijn nog niet volwassen genoeg? Waar zijn we afhankelijk van leveranciers? Welke verbeteringen zijn nodig voordat certificering realistisch is?

    Daarmee wordt de SoA meer dan een auditdocument. Het wordt een hulpmiddel om informatiebeveiliging bestuurbaar te maken.

    Dat past ook bij wat ISO 27001 vraagt. De norm draait niet alleen om beveiligingsmaatregelen, maar om een managementsysteem. Een manier om informatiebeveiliging structureel te organiseren, te beoordelen en te verbeteren.

    Juist wanneer informatiebeveiliging naast andere verantwoordelijkheden wordt opgepakt, helpt de SoA om te voorkomen dat keuzes alleen in hoofden of losse documenten blijven zitten.

    Veelgemaakte fouten bij de SoA

    De eerste fout is Annex A behandelen als afvinklijst. Dan ontstaat een document dat formeel compleet lijkt, maar weinig zegt over de werkelijke relevantie van maatregelen.

    De tweede fout is het ontbreken van een duidelijke koppeling met risico’s. Maatregelen worden dan losse acties. Je ziet wel wat is ingericht, maar niet welk risico ermee wordt beheerst.

    De derde fout is uitsluitingen onvoldoende onderbouwen. “Niet van toepassing” zonder toelichting leidt bijna altijd tot vragen. Zeker wanneer de maatregel op het eerste gezicht wel relevant lijkt.

    De vierde fout is de SoA niet actueel houden. Nieuwe systemen, leveranciers, klantvragen, incidenten of wijzigingen in processen kunnen allemaal betekenen dat maatregelen opnieuw beoordeeld moeten worden.

    Het onderliggende probleem is vaak hetzelfde: de SoA wordt gezien als document voor de audit, niet als onderdeel van het ISMS. Daardoor ontstaat vlak voor de audit alsnog druk. Keuzes moeten worden gereconstrueerd, bewijs moet worden gezocht en toelichtingen moeten achteraf worden bedacht.

    Een sterke SoA voorkomt dat. Niet door alles zwaarder te maken, maar door keuzes vast te houden op het moment dat ze worden gemaakt.

    Hoe houd je de SoA praktisch en actueel?

    Een SoA hoeft geen zwaar of ingewikkeld document te zijn. Hij moet vooral bruikbaar blijven.

    Begin met een duidelijke scope. Waar geldt het ISMS voor? Welke processen, systemen, locaties, diensten en informatie vallen binnen de afbakening? Zonder heldere scope wordt het lastig om te bepalen of een maatregel wel of niet van toepassing is.

    Zorg daarna voor een actuele risicoanalyse. De SoA moet niet losstaan van de risico’s die je hebt geïdentificeerd. Als maatregelen en risico’s niet met elkaar verbonden zijn, ontstaat precies het soort papieren werkelijkheid waar niemand iets aan heeft.

    Werk vervolgens met eenvoudige statussen. Bijvoorbeeld: van toepassing en ingericht, van toepassing maar verbetering nodig, niet van toepassing met onderbouwing, of gepland en in uitvoering.

    De onderbouwing hoeft niet lang te zijn. Een korte, concrete toelichting is vaak sterker dan een algemene alinea. Niet: “niet relevant”. Wel: “niet van toepassing omdat deze activiteit buiten de ISMS-scope valt” of “risico wordt beheerst via contractuele leverancierseisen en periodieke leveranciersbeoordeling”.

    De SoA moet daarnaast meebewegen met je organisatie. Een herziening is logisch wanneer je nieuwe systemen of applicaties introduceert, wanneer leveranciers of processen veranderen, wanneer zich een beveiligingsincident voordoet of wanneer interne auditbevindingen laten zien dat maatregelen opnieuw beoordeeld moeten worden.

    Ook nieuwe klant- of contracteisen, een gewijzigde scope, een nieuwe risicoanalyse of de voorbereiding op een externe audit kunnen aanleiding zijn om de SoA bij te werken.

    Dat betekent niet dat je de SoA continu volledig opnieuw moet opbouwen. Het betekent wel dat hij betrouwbaar moet blijven. Een SoA die niet wordt bijgewerkt, verliest langzaam zijn waarde. Niet omdat het document direct fout is, maar omdat de context verandert. En juist context bepaalt of keuzes nog logisch zijn.

    Lichtgewicht betekent niet oppervlakkig. Het betekent dat je precies genoeg structuur gebruikt om keuzes te kunnen uitleggen.

    Waar CompliTrack helpt

    De uitdaging bij een Statement of Applicability zit zelden alleen in het invullen van een document. De echte uitdaging is samenhang vasthouden.

    Als informatie over risico’s, maatregelen, acties, eigenaren, auditbevindingen en bewijs verspreid staat over Excelbestanden, losse documenten, e-mails en mappen, wordt de SoA al snel een momentopname. Vlak voor de audit moet dan worden gereconstrueerd wat eigenlijk doorlopend zichtbaar had moeten zijn.

    CompliTrack helpt om die samenhang vast te houden. Maatregelen, risico’s, acties, eigenaren, auditbevindingen en bewijs staan niet los van elkaar, maar worden op één plek verbonden. Daardoor wordt de SoA geen document dat vlak voor de audit wordt bijgewerkt, maar onderdeel van de dagelijkse ISMS-structuur.

    Dat maakt het makkelijker om keuzes te onderbouwen. Niet omdat het systeem de keuzes voor je maakt, maar omdat het helpt om onderbouwing, opvolging en bewijsvoering overzichtelijk te bewaren.

    Verder lezen

    Wil je verder lezen over onderwerpen die direct raken aan de Statement of Applicability?

    Lees dan ook Effectieve risicoanalyse: van risico-inventarisatie tot mitigerende maatregelen, waarin wordt uitgelegd hoe je risico’s vertaalt naar beheersmaatregelen.

    Ook relevant zijn:

    Conclusie: ISO 27001 draait om verdedigbare keuzes

    De Statement of Applicability is geen administratieve bijlage bij ISO 27001. Het is een van de belangrijkste onderdelen van je ISMS, omdat het laat zien hoe je van risico’s naar maatregelen komt.

    Een sterke SoA laat niet alleen zien wat je hebt ingericht, maar vooral waarom. Welke maatregelen zijn relevant? Welke niet? Welke risico’s accepteer je bewust? Waar is verbetering nodig? En hoe weet je dat maatregelen werken?

    ISO 27001 gaat niet om zoveel mogelijk maatregelen aanvinken. Het gaat om informatiebeveiliging beheersbaar maken. Dat lukt alleen wanneer je keuzes kunt onderbouwen.

    Wil je jouw Statement of Applicability niet als los auditdocument beheren, maar als onderdeel van een praktisch ISMS? Met CompliTrack koppel je ISO 27001-maatregelen aan risico’s, acties, eigenaren en bewijs. Zo kun je keuzes onderbouwen zonder zware of dure tooling. Plan een vrijblijvende demo en ontdek hoe je ISO 27001 beheersbaar houdt.

  • Uitlegbaarheid ontstaat niet achteraf

    Uitlegbaarheid ontstaat niet achteraf

    Een klant vraagt waarom een bepaald risico vorig jaar als acceptabel is beoordeeld. Niet kritisch, niet wantrouwend, gewoon als onderdeel van een leveranciersbeoordeling. De vraag lijkt overzichtelijk. Er is vast ergens een risicoanalyse, een actielijst of een notitie waarin dit terug te vinden is.

    Toch duurt het langer dan verwacht.

    Iemand zoekt in een Excelbestand. Iemand anders herinnert zich dat het onderwerp tijdens een overleg is besproken. Er wordt verwezen naar een maatregel die destijds voldoende werd gevonden, maar niemand weet meer precies waarom. Misschien ging het om een leverancier die tijdelijk nog niet aan alle afspraken voldeed, maar wel een verbeterplan had toegezegd. Op dat moment was het logisch om het risico tijdelijk te accepteren. Een jaar later staat alleen de status nog in het overzicht. De reden, de termijn en de gemaakte afspraak zijn minder duidelijk.

    De collega die het besluit heeft voorbereid, werkt inmiddels minder op dit onderwerp. De context is er nog wel, maar verspreid. In hoofden, mails, losse documenten en aannames.

    Uiteindelijk komt er een antwoord. Waarschijnlijk zelfs een redelijk antwoord. Maar het kost tijd, geeft twijfel en voelt onnodig kwetsbaar.

    Dat is precies het moment waarop zichtbaar wordt dat uitlegbaarheid niet achteraf ontstaat.

    Het probleem zit meestal niet in de beslissing zelf

    In organisaties met korte lijnen worden dagelijks verstandige keuzes gemaakt. Niet alles wordt formeel uitgewerkt, en dat hoeft ook niet. Mensen kennen elkaar, verantwoordelijkheden raken elkaar en veel wordt opgelost op basis van ervaring en onderling begrip.

    Dat is vaak juist de kracht van zo’n organisatie. Er is snelheid. Er is korte afstemming. Er is weinig afstand tussen degene die iets signaleert en degene die er iets mee moet doen.

    Het probleem ontstaat niet doordat beslissingen per definitie slecht zijn. Het ontstaat doordat de reden achter die beslissingen niet wordt vastgehouden.

    Op het moment zelf is de context helder. Iedereen weet waarom een risico acceptabel lijkt, waarom een maatregel voorlopig voldoende is of waarom een uitzondering logisch is. Maar die helderheid is tijdelijk. Zodra de vraag later opnieuw op tafel komt, moet het verhaal opnieuw worden opgebouwd.

    En opnieuw opbouwen is iets anders dan uitleggen.

    Uitleg vertrekt vanuit een keuze die eerder herkenbaar is vastgelegd. Reconstructie vertrekt vanuit herinnering, interpretatie en zoeken naar aanwijzingen achteraf. Dat maakt het traag en onzeker, zelfs wanneer de oorspronkelijke keuze goed verdedigbaar was.

    Waarom dit vaak pas laat zichtbaar wordt

    Zolang niemand doorvraagt, lijkt er weinig aan de hand. Het werk loopt door. De risico’s staan ergens geregistreerd. Verbeterpunten worden besproken. Incidenten worden afgehandeld. Afspraken worden gemaakt.

    De kwetsbaarheid wordt pas zichtbaar wanneer uitleg nodig is. Bijvoorbeeld bij een audit, een klantvraag, een incident, een leveranciersbeoordeling of een overdracht naar een nieuwe collega.

    Dan blijkt dat veel informatie wel bestaat, maar niet in samenhang.

    Er is een risico-overzicht, maar niet duidelijk waarom de score is aangepast. Er is een maatregel, maar niet zichtbaar waarom deze passend werd gevonden. Er is een actie afgerond, maar onduidelijk welk probleem daarmee precies is opgelost. Er is een besluit genomen, maar de afweging erachter is niet meer terug te vinden.

    In organisaties waar veel kennis bij een beperkt aantal mensen zit, wordt dit vaak opgevangen met persoonlijke toelichting. Vraag het even aan die collega. Die weet nog hoe het zat. Dat werkt, totdat die collega er niet is, de context vervaagt of meerdere mensen een andere herinnering hebben aan hetzelfde besluit.

    Dan wordt duidelijk dat uitlegbaarheid afhankelijk is geworden van beschikbaarheid. En dat is kwetsbaar.

    Waarom gangbare oplossingen tekortschieten

    De eerste reflex is vaak om meer vast te leggen. Meer documenten, meer velden, meer toelichtingen, meer lijstjes. Dat lijkt logisch. Als uitleg ontbreekt, moeten we blijkbaar meer documenteren.

    Maar meer vastlegging leidt niet automatisch tot meer uitlegbaarheid.

    Een document kan beschrijven wat er is besloten, zonder duidelijk te maken waarom. Een spreadsheet kan een status tonen, zonder de afweging vast te houden. Een actielijst kan aangeven dat iets is afgerond, zonder zichtbaar te maken wat het effect was.

    Dan ontstaat schijnduidelijkheid. Er is informatie, maar geen verhaal. Er is registratie, maar geen houvast.

    Een tweede reflex is om vlak voor een audit of klantvraag alles nog even bij te werken. Dat is begrijpelijk, zeker wanneer compliance één van de vele verantwoordelijkheden is. Maar ook dat lost het probleem niet op. Uitleg wordt dan pas gemaakt wanneer de druk ontstaat.

    Dat voelt efficiënt, omdat je niet voortdurend met documentatie bezig bent. In werkelijkheid verschuif je het werk naar het slechtst mogelijke moment. Juist wanneer iemand meekijkt, de tijd beperkt is en de vraag precies moet worden beantwoord.

    De derde reflex is om direct naar zwaardere ondersteuning te zoeken. Een systeem waarin alles kan worden vastgelegd, gekoppeld en gerapporteerd. Dat kan helpen, maar alleen als duidelijk is welk probleem het systeem moet oplossen. Zonder denkkader ontstaat vooral een nettere plek om dezelfde onduidelijkheid te bewaren.

    Het kernprobleem is zelden dat er geen plek is om informatie op te slaan. Het kernprobleem is dat keuzes hun context verliezen.

    Structuur als manier om keuzes begrijpelijk te houden

    Structuur wordt vaak gezien als iets zwaars. Als extra lagen, extra procedures en extra controle. Maar in deze context betekent structuur iets veel eenvoudigers: zorgen dat belangrijke keuzes later nog te begrijpen zijn.

    Dat vraagt niet dat elke handeling wordt vastgelegd. Het vraagt wel dat beslismomenten herkenbaar blijven.

    Het gaat om vragen als: waarom was dit risico acceptabel, waarom paste deze maatregel bij de situatie en wie droeg de verantwoordelijkheid voor die keuze? Dat zijn geen auditvragen. Het zijn organisatievragen. Ze helpen om afwegingen zichtbaar te houden op het moment dat de context nog beschikbaar is.

    Daar zit de timing. Uitlegbaarheid ontstaat niet wanneer iemand later vraagt om uitleg. Uitlegbaarheid ontstaat op het moment dat de keuze wordt gemaakt. Of niet.

    Wie pas achteraf begint, moet reconstrueren. Wie op het juiste moment kort vastlegt wat relevant is, hoeft later niet opnieuw te zoeken naar het verhaal.

    Uitlegbaarheid vraagt om keuze, niet om volledigheid

    Een veelgemaakte fout is denken dat alles volledig moet zijn om uitlegbaar te worden. Dat maakt structuur onnodig zwaar. Zeker wanneer compliance niet iemands enige taak is, werkt dat averechts. Niemand zit te wachten op uitgebreide verantwoordingsdocumenten voor elke kleine beslissing.

    Uitlegbaarheid vraagt niet om volledigheid. Het vraagt om relevantie.

    Sommige besluiten hebben weinig blijvende betekenis. Andere keuzes bepalen hoe risico’s worden geaccepteerd, hoe verantwoordelijkheden worden verdeeld of hoe incidenten worden opgevolgd. Juist die keuzes verdienen aandacht.

    Het gaat dus om onderscheid maken. Wat moet later nog te begrijpen zijn? Welke keuze wil je kunnen uitleggen als een klant, auditor, collega of bestuurder doorvraagt? Welke afweging mag niet alleen in iemands hoofd blijven zitten?

    Die vragen helpen om structuur licht te houden. Niet alles hoeft een dossier te worden. Maar belangrijke keuzes moeten wel een spoor achterlaten dat meer bevat dan alleen de uitkomst.

    Waarom timing zo bepalend is

    Het verschil tussen vastleggen op het moment zelf en uitleggen achteraf lijkt klein, maar is in de praktijk groot.

    Op het moment van beslissen is de context vers. Mensen weten welke alternatieven zijn besproken, welke beperkingen meespeelden en waarom een keuze verdedigbaar voelde. Een korte vastlegging kan dan genoeg zijn.

    Achteraf is die context verdwenen. Dan moet je terugzoeken in documenten, agenda’s, mails en herinneringen. Vaak lukt dat gedeeltelijk, maar zelden scherp. Het risico is dat je een verhaal maakt dat achteraf logisch klinkt, maar niet precies weergeeft hoe de keuze destijds tot stand kwam.

    Dat hoeft niet eens bewust te gebeuren. Mensen vullen gaten in. Ze herinneren zich vooral de uitkomst. Ze reconstrueren de redenering op basis van wat nu logisch lijkt.

    Voor compliance, governance en risicobeheer is dat kwetsbaar. Niet omdat elke reconstructie fout is, maar omdat ze moeilijker te vertrouwen is dan een keuze die op het juiste moment is vastgehouden.

    Ondersteuning als gevolg van structuur

    Wanneer een organisatie merkt dat keuzes steeds vaker teruggezocht, opnieuw uitgelegd of gereconstrueerd moeten worden, ontstaat vanzelf behoefte aan ondersteuning. Niet omdat een systeem het antwoord is, maar omdat losse documenten en persoonlijke herinneringen hun grens bereiken.

    Op dat moment kan een eenvoudige, consistente manier van vastleggen helpen. Niet als auditmachine en niet als extra verantwoordingslaag, maar als geheugensteun voor de organisatie. Een plek waar risico’s, acties, besluiten en opvolging herkenbaar bij elkaar blijven.

    Maar de volgorde is belangrijk. Ondersteuning werkt pas wanneer helder is wat je wilt vasthouden. Anders ontstaat alleen een netter archief van onduidelijke keuzes.

    De werkelijke stap zit eerder. In het besef dat uitlegbaarheid onderdeel is van het werk zelf. Niet iets dat achteraf wordt toegevoegd wanneer iemand erom vraagt.

    Wat dit zegt over volwassenheid

    Volwassen compliance herken je niet alleen aan dikke documenten of perfecte overzichten. Je herkent het vooral aan de rust waarmee een organisatie kan uitleggen wat zij doet en waarom.

    Niet defensief. Niet zoekend. Niet afhankelijk van één persoon die nog weet hoe het zat.

    Maar vanuit een gedeeld beeld van de keuzes die zijn gemaakt, de redenen daarachter en de opvolging die daarop volgde.

    Dat betekent niet dat alles altijd goed gaat. Het betekent wel dat de organisatie zichzelf kan begrijpen. Ook wanneer mensen wisselen, wanneer de druk toeneemt of wanneer externe vragen worden gesteld.

    In organisaties waar verantwoordelijkheden dicht op elkaar liggen, is dat vaak belangrijker dan uitgebreide formele systemen. Juist omdat mensen meerdere rollen combineren, is het nodig dat betekenis niet alleen in hoofden blijft zitten. Anders wordt elke overdracht, audit of klantvraag onnodig zwaar.

    Reflectieve conclusie

    Uitlegbaarheid ontstaat niet op het moment dat iemand om uitleg vraagt. Dan wordt vooral zichtbaar of de uitleg al bestond.

    De vraag is daarom niet of je achteraf een goed verhaal kunt maken. De vraag is of je organisatie belangrijke keuzes op het juiste moment voldoende vasthoudt om ze later nog te begrijpen.

    De vraag is waar je nu vaak naar moet zoeken, welke besluiten afhankelijk zijn van het geheugen van één persoon en welke risico’s, maatregelen of uitzonderingen je wel kunt aanwijzen, maar niet eenvoudig kunt uitleggen.

    Die vragen zeggen veel over de manier waarop structuur in de organisatie werkt. Niet als administratie, maar als geheugen. Niet als controle, maar als houvast.

    Wie dat herkent, ziet ook waar de echte spanning zit. Niet in het ontbreken van documenten, maar in het ontbreken van vastgehouden context. En precies daar begint uitlegbaarheid: niet achteraf, maar op het moment dat keuzes worden gemaakt.

    Verder lezen

    Deze blogs sluiten inhoudelijk aan op dezelfde spanning tussen structuur, context en uitlegbaarheid:

  • ISO 27701 en AVG: wanneer wordt privacy een managementsysteem?

    ISO 27701 en AVG: wanneer wordt privacy een managementsysteem?

    Veel organisaties hebben privacy op papier geregeld. Er is een privacyverklaring. Er is een verwerkingsregister. Er liggen verwerkersovereenkomsten in een map. Misschien is er ook een datalekprocedure en weet iemand waar de belangrijkste AVG-documenten staan.

    Dat klinkt georganiseerd.

    Toch ontstaat er vaak spanning zodra privacy niet meer alleen een juridisch onderwerp is, maar onderdeel wordt van de dagelijkse bedrijfsvoering. Een klant vraagt hoe privacy aantoonbaar wordt beheerst. Een datalek moet snel worden beoordeeld. Een nieuwe softwareleverancier verwerkt persoonsgegevens. Of een nieuwe verwerking roept de vraag op of een DPIA nodig is.

    Op dat moment merk je dat losse documenten niet altijd genoeg zijn.

    Deze blog legt uit wanneer privacy meer wordt dan een set AVG-documenten, wat ISO 27701 daarin betekent en hoe je pragmatisch kunt starten met privacybeheer zonder onnodige bureaucratie.

    Wat is ISO 27701?

    ISO/IEC 27701 is een internationale norm voor privacy-informatiebeheer. De norm helpt organisaties bij het opzetten, implementeren, onderhouden en verbeteren van een Privacy Information Management System, vaak afgekort als PIMS.

    In gewone taal: ISO 27701 helpt je om privacy niet alleen juridisch, maar ook organisatorisch te beheersen.

    Waar de AVG verplichtingen stelt rond het verwerken van persoonsgegevens, helpt ISO 27701 om privacy structureel te organiseren. Denk aan rollen, verantwoordelijkheden, verwerkingen, privacyrisico’s, leveranciers, datalekken, rechten van betrokkenen, maatregelen en continue verbetering.

    De norm is relevant voor organisaties die persoonsgegevens verwerken. Dat kan zijn als verwerkingsverantwoordelijke, bijvoorbeeld wanneer je zelf bepaalt waarom en hoe persoonsgegevens worden verwerkt. Het kan ook zijn als verwerker, wanneer je namens een klant persoonsgegevens verwerkt.

    Belangrijk is dat ISO 27701 niet alleen gaat over beleid. Het gaat vooral over samenhang. Wie doet wat? Waar liggen risico’s? Hoe wordt opgevolgd wat is afgesproken? En hoe toon je later aan dat privacy niet alleen op papier bestaat?

    Wat is het verschil tussen AVG en ISO 27701?

    Het verschil tussen de AVG en ISO 27701 is eenvoudig, maar belangrijk.

    De AVG is de wet. Die bepaalt welke verplichtingen je hebt wanneer je persoonsgegevens verwerkt. Denk aan rechtmatige grondslagen, transparantie, beveiliging, rechten van betrokkenen, verwerkersafspraken, datalekken en in bepaalde gevallen een DPIA.

    ISO 27701 is geen wet. Het is een managementsysteemnorm. De norm helpt om privacyprocessen structureel in te richten, te beheren, te controleren en te verbeteren.

    De kern is deze:

    De AVG zegt wat je moet naleven. ISO 27701 helpt je organiseren hoe je dat aantoonbaar doet.

    Dat betekent ook dat ISO 27701 de AVG niet vervangt. Een organisatie kan niet zeggen: wij hebben ISO 27701, dus wij voldoen automatisch aan de AVG. De AVG blijft leidend.

    Wat ISO 27701 wel kan doen, is helpen om AVG-verplichtingen beheersbaar te maken. Niet als losse juridische checklist, maar als onderdeel van een werkend managementsysteem.

    Waarom losse AVG-documenten vaak niet genoeg zijn

    Veel organisaties starten logisch en praktisch. Eerst wordt een privacyverklaring opgesteld. Daarna volgt een verwerkingsregister. Vervolgens komen er verwerkersovereenkomsten, een datalekprocedure en misschien een template voor rechtenverzoeken.

    Dat is een prima begin. Het probleem ontstaat wanneer die onderdelen los van elkaar blijven bestaan.

    Een verwerkingsregister wordt bijvoorbeeld één keer gemaakt, maar daarna nauwelijks bijgewerkt. Verwerkersovereenkomsten staan ergens opgeslagen, maar niemand beoordeelt periodiek of de afspraken nog actueel zijn. Datalekken worden via e-mail afgehandeld, maar niet structureel geëvalueerd. Privacyvragen blijven liggen bij één medewerker, omdat die toevallig het meeste weet.

    Dan is privacy op papier geregeld, maar niet bestuurbaar.

    Dat is een belangrijk verschil. Documentatie laat zien dat je ergens over hebt nagedacht. Een managementsysteem laat zien dat je het onderwerp blijft beheersen.

    Een verwerkingsregister laat bijvoorbeeld zien welke verwerkingen er zijn. Maar als niemand weet wanneer een verwerking opnieuw beoordeeld moet worden, wie eigenaar is van de verwerking en welke risico’s erbij horen, blijft het register vooral een momentopname.

    Privacydocumentatie is nuttig, maar documentatie zonder opvolging geeft schijnzekerheid.

    Wanneer wordt privacy een managementsysteem?

    Privacy wordt een managementsysteem zodra het niet meer genoeg is om alleen te weten welke documenten er zijn. Het wordt een managementvraagstuk wanneer privacy terugkomt in keuzes, risico’s, klantvragen, leveranciers, incidenten en audits.

    Dat gebeurt vaak geleidelijk. Niet door één grote verandering, maar door een reeks signalen.

    Het eerste signaal is dat privacy meerdere processen raakt. Zolang privacy alleen gaat over één contactformulier op de website, blijft het overzichtelijk. Maar zodra persoonsgegevens voorkomen in HR, sales, support, finance, klantportalen, marketingtools en leveranciersprocessen, ontstaat behoefte aan samenhang. Dan is privacy niet meer één document of één taak. Het raakt meerdere teams, systemen en verantwoordelijkheden.

    De vraag wordt dan niet alleen of iets is vastgelegd. De vraag wordt of duidelijk is wie waarvoor verantwoordelijk is, welke risico’s erbij horen en wanneer opnieuw beoordeeld moet worden of de inrichting nog klopt.

    Een tweede signaal is afhankelijkheid van meerdere verwerkers. Veel organisaties werken met softwareleveranciers, cloudpartijen, salarisverwerkers, marketingtools en externe dienstverleners. Die partijen verwerken soms persoonsgegevens namens jouw organisatie.

    Een verwerkersovereenkomst is dan noodzakelijk, maar geen eindpunt. Je wilt ook weten welke leveranciers kritisch zijn, welke gegevens zij verwerken, welke afspraken zijn gemaakt en of die afspraken nog passen bij de praktijk.

    Een derde signaal is dat datalekken aantoonbaar beoordeeld moeten worden. Een datalek is geen puur administratief incident. Het vraagt om beoordeling, vastlegging en opvolging.

    Wat is er gebeurd? Welke persoonsgegevens zijn geraakt? Wat is de impact voor betrokkenen? Moet het datalek gemeld worden bij de Autoriteit Persoonsgegevens? Moeten betrokkenen worden geïnformeerd? Welke maatregel voorkomt herhaling?

    Als die vragen steeds opnieuw ad hoc worden beantwoord, is privacy kwetsbaar georganiseerd. Niet omdat elk datalek groot is, maar omdat elke beoordeling uitlegbaar moet zijn.

    Daarom is een datalekregister meer dan een lijst. Het is onderdeel van privacybeheer. Het laat zien wat er is gebeurd, welke afweging is gemaakt en welke opvolging heeft plaatsgevonden.

    Een vierde signaal is dat klanten om bewijs vragen. Grotere klanten, zorginstellingen, financiële partijen en overheden vragen steeds vaker naar privacymaatregelen, beveiliging, verwerkersbeheer en incidentprocedures. Niet alleen omdat zij nieuwsgierig zijn, maar omdat zij zelf ook moeten kunnen aantonen dat hun leveranciers betrouwbaar omgaan met persoonsgegevens.

    Op dat moment is “we hebben een privacyverklaring” niet genoeg.

    Een klant wil weten hoe privacy is georganiseerd. Wie is verantwoordelijk? Hoe worden datalekken opgevolgd? Hoe worden verwerkers beoordeeld? Hoe blijven maatregelen actueel?

    Dat vraagt om meer dan documenten. Het vraagt om aantoonbare structuur.

    Een vijfde signaal is dat privacybesluiten afhankelijk zijn van één persoon. In veel organisaties is privacy afhankelijk van één medewerker. Die weet waar alles staat, welke keuzes eerder zijn gemaakt en welke leveranciers gevoelig liggen.

    Dat lijkt efficiënt, totdat die persoon afwezig is, vertrekt of te veel andere verantwoordelijkheden krijgt.

    Als privacykennis vooral in één hoofd zit, is er geen echte borging. Dan is er wel ervaring, maar geen overdraagbaarheid. En juist overdraagbaarheid is belangrijk wanneer klanten, auditors of toezichthouders vragen hoe iets werkt.

    Welke onderdelen horen bij een praktisch privacy management system?

    Een privacy management system hoeft geen zwaar programma te zijn. Zeker niet wanneer privacybeheer één van de vele verantwoordelijkheden is. Het gaat niet om meer papierwerk, maar om voldoende structuur om grip te houden.

    Een praktisch privacy management system begint met inzicht in verwerkingen. Welke persoonsgegevens verwerk je, met welk doel, op basis van welke grondslag en hoe lang bewaar je ze? Het verwerkingsregister blijft dus belangrijk, maar het is het beginpunt, niet het eindpunt.

    Daarna moet je privacyrisico’s kunnen beoordelen. Sommige verwerkingen zijn relatief eenvoudig. Andere verwerkingen kunnen meer impact hebben op betrokkenen, bijvoorbeeld door gevoelige gegevens, grootschalige verwerking, monitoring of gegevensdeling. Bij verwerkingen die waarschijnlijk een hoog privacyrisico opleveren, is een DPIA verplicht. Wil je daar dieper op ingaan? Lees dan ook Van DPIA tot PIA: Privacybeoordelingen begrijpelijk uitgelegd.

    Ook rollen en verantwoordelijkheden moeten duidelijk zijn. Wie beheert het privacybeleid? Wie beoordeelt datalekken? Wie houdt verwerkers bij? Wie beslist of een DPIA nodig is? Wie zorgt dat verbeteracties worden opgevolgd?

    Daarbij horen ook rechtenverzoeken van betrokkenen. Denk aan inzage, correctie, verwijdering of beperking. Het moet duidelijk zijn hoe zulke verzoeken binnenkomen, wie ze beoordeelt, welke termijn geldt en hoe de afhandeling wordt vastgelegd.

    Daarnaast hoort leveranciers- en verwerkersbeheer erbij. Niet alleen de overeenkomst zelf, maar ook het overzicht van welke partijen persoonsgegevens verwerken en hoe kritisch die verwerking is.

    Incidenten en datalekken vormen een ander belangrijk onderdeel. Een organisatie moet weten hoe incidenten worden gemeld, beoordeeld, geregistreerd en opgevolgd. Daarbij gaat het niet alleen om melden, maar ook om leren.

    Verder zijn maatregelen en bewijsvoering essentieel. Welke organisatorische en technische maatregelen zijn genomen? Wanneer zijn ze beoordeeld? Is zichtbaar dat ze werken? En kun je bij een klantvraag of audit uitleggen waarom deze maatregelen passend zijn?

    Tot slot hoort evaluatie erbij. Privacybeheer is geen eenmalige opruimactie. Verwerkingen veranderen, leveranciers veranderen en risico’s veranderen. Daarom moet privacy periodiek terugkomen in overleg, risicoanalyse, audit of managementreview.

    Hoe verhoudt ISO 27701 zich tot ISO 27001?

    ISO 27001 is voor veel organisaties bekender dan ISO 27701. ISO 27001 richt zich op informatiebeveiliging. Het gaat om het beschermen van informatie op basis van vertrouwelijkheid, integriteit en beschikbaarheid.

    ISO 27701 richt zich op privacy-informatiebeheer. De norm helpt om persoonsgegevens verantwoord te beheren en privacyprocessen structureel in te richten.

    Kort gezegd: ISO 27001 helpt je informatie te beveiligen. ISO 27701 helpt je persoonsgegevens verantwoord te beheren.

    Die twee onderwerpen raken elkaar sterk, maar ze zijn niet hetzelfde.

    Je kunt informatie technisch goed beveiligen en toch privacyprocessen slecht georganiseerd hebben. Een systeem kan bijvoorbeeld goed afgeschermd zijn, terwijl niemand weet of de bewaartermijn klopt. Of een leverancier kan veilig werken, terwijl de verwerkersafspraken verouderd zijn. Of een nieuwe verwerking kan technisch netjes worden ingericht, terwijl niemand heeft beoordeeld of een DPIA nodig was.

    Beveiliging is dus een belangrijk onderdeel van privacy, maar privacy is breder dan beveiliging.

    Voor organisaties die al met ISO 27001 werken, kan ISO 27701 logisch aansluiten. Je hebt dan vaak al structuur voor risico’s, maatregelen, audits, eigenaarschap en continue verbetering. ISO 27701 helpt om privacy explicieter in die structuur te plaatsen.

    Twijfel je vooral over de verhouding tussen privacybeheer en informatiebeveiliging? Lees dan ook PIMS of ISMS? Praktische voorbeelden voor de juiste keuze.

    Wat betekent dit voor organisaties die praktisch willen blijven?

    ISO 27701 is niet alleen relevant voor organisaties met een groot privacyteam of een uitgebreid certificeringsprogramma. De norm is ook waardevol als denkkader voor organisaties die privacy praktisch willen organiseren.

    Niet iedere organisatie hoeft direct een certificeringstraject te starten. Niet iedere organisatie heeft behoefte aan uitgebreide handboeken, complexe governance-structuren en zware juridische trajecten.

    Maar veel organisaties hebben wel behoefte aan overzicht.

    Zeker wanneer klanten vragen gaan stellen, persoonsgegevens in meerdere processen voorkomen of privacy-informatie verspreid raakt over Excel, mailboxen en mappen.

    De praktische vraag is dan niet: hoe bouwen we een groot privacyprogramma?

    De betere vraag is: welke privacyprocessen moeten structureel worden ingericht, zodat we niet afhankelijk blijven van losse documenten en individueel geheugen?

    Begin daarom bij de verwerkingen die het meeste risico of de meeste externe druk opleveren. Denk aan klantgegevens, personeelsgegevens, bijzondere persoonsgegevens, financiële gegevens, klantportalen, monitoring of verwerkingen door belangrijke leveranciers.

    Van daaruit kun je bepalen welke structuur minimaal nodig is. Bijvoorbeeld centrale vastlegging, duidelijke eigenaars, periodieke beoordeling, opvolging van incidenten en aantoonbare maatregelen.

    Dat hoeft niet zwaar te zijn. Het moet vooral werkbaar zijn.

    Waar begin je als privacy nu versnipperd is geregeld?

    Als privacy nu verspreid is over documenten, mappen, mailboxen en losse afspraken, is de verleiding groot om alles tegelijk te willen oplossen. Dat is meestal niet nodig.

    Begin met de belangrijkste verwerkingen. Kies de processen waar veel persoonsgegevens, gevoelige gegevens of klantvragen samenkomen. Breng in beeld wat er wordt verwerkt, waarom dat gebeurt en welke systemen en leveranciers daarbij betrokken zijn.

    Koppel die verwerkingen vervolgens aan risico’s. Welke verwerkingen kunnen schade, klachten, datalekken of complianceproblemen veroorzaken? Welke verwerkingen vragen extra aandacht omdat ze gevoelig, omvangrijk of extern zichtbaar zijn?

    Leg daarna verantwoordelijkheden vast. Privacy werkt niet als iedereen een beetje verantwoordelijk is. Maak duidelijk wie eigenaar is van verwerkingen, incidenten, verwerkers, DPIA’s, rechtenverzoeken en verbeteracties.

    Richt vervolgens datalek- en incidentbeheer in. Zorg dat incidenten niet alleen worden opgelost, maar ook geregistreerd, beoordeeld en gebruikt voor verbetering. Juist daar ontstaat aantoonbaarheid.

    Beheer daarna je verwerkers actief. Een verwerkersovereenkomst is geen eindpunt. Je wilt ook weten welke leveranciers kritisch zijn, welke gegevens zij verwerken en of afspraken nog actueel zijn.

    Maak tot slot bewijsvoering onderdeel van het werk. Niet vlak voor een audit bewijs verzamelen, maar tijdens het werk vastleggen wat is besloten, gedaan en opgevolgd. Dat maakt privacybeheer rustiger en betrouwbaarder.

    Wanneer is tooling zinvol?

    Tooling wordt zinvol wanneer privacy-informatie verspreid raakt over meerdere plekken. Denk aan Excel-bestanden, mailboxen, losse verwerkersovereenkomsten, SharePoint-mappen, incidentmeldingen, auditbevindingen en takenlijstjes.

    Op dat moment zit het probleem niet alleen in opslag. Het probleem zit in samenhang.

    Waar staat welke verwerking? Welke leverancier hoort daarbij? Welke risico’s zijn beoordeeld? Welke incidenten hebben plaatsgevonden? Welke maatregel is genomen? En wie volgt de openstaande acties op?

    Een tool vervangt geen privacybeleid en geen juridische beoordeling. Ook een goede GRC-tool bepaalt niet automatisch of een verwerking rechtmatig is of of een DPIA verplicht is.

    Maar tooling kan wel helpen om privacybeheer structureel te maken.

    Met CompliTrack kun je privacybeheer koppelen aan de onderdelen die in de praktijk belangrijk zijn: verwerkingen, risico’s, incidenten en datalekken, leveranciers en verwerkers, maatregelen, taken, verbeteracties, audits en bewijsvoering.

    Daardoor ontstaat één praktisch systeem waarin zichtbaar wordt wat er speelt, wie verantwoordelijk is en wat nog opvolging vraagt.

    Het doel is niet om een zware compliance-suite neer te zetten. Het doel is een praktische basis waarmee privacybeheer zichtbaar en opvolgbaar wordt.

    Conclusie

    Privacy wordt een managementsysteem zodra het niet meer voldoende is om alleen documenten te hebben.

    Wanneer privacy terugkomt in klantvragen, incidenten, leveranciers, audits, DPIA’s, rechtenverzoeken en strategische keuzes, heb je structuur nodig. Niet om meer papierwerk te creëren, maar om te voorkomen dat privacy afhankelijk blijft van losse bestanden, individueel geheugen en ad hoc opvolging.

    ISO 27701 helpt om die structuur te begrijpen. Niet als vervanging van de AVG, maar als manier om privacy beheersbaar, uitlegbaar en aantoonbaar te organiseren.

    Dat hoeft niet zwaar te zijn. Het begint met overzicht, eigenaarschap, risico’s, opvolging en bewijs dat ontstaat tijdens het werk.

    Wil je privacybeheer minder afhankelijk maken van losse documenten, mailboxen en individueel geheugen?

    Met CompliTrack breng je privacyrisico’s, datalekken, leveranciers, maatregelen en verbeteracties samen in één praktisch systeem. Zo ontstaat overzicht zonder onnodige complexiteit.

    Ontdek hoe CompliTrack helpt bij privacybeheer

    Verder lezen

    Privacybeheer raakt vaak aan informatiebeveiliging, risicoanalyse en bredere compliance. Deze artikelen helpen om de onderwerpen verder te verdiepen:

  • ISO 37301 uitgelegd: wanneer heb je een compliance management system nodig?

    ISO 37301 uitgelegd: wanneer heb je een compliance management system nodig?

    Veel organisaties voldoen aan allerlei regels, afspraken en normen. Privacy staat ergens beschreven. Informatiebeveiliging zit in een ISO-map. Klantafspraken staan in contracten. Leveranciersafspraken zitten in e-mails. Auditacties worden bijgehouden in Excel. En tussendoor weten een paar mensen precies hoe het allemaal bedoeld is.

    Zolang de organisatie overzichtelijk is, lijkt dat werkbaar.

    Totdat een klant vraagt om bewijs. Of een auditor wil weten wie verantwoordelijk is. Of nieuwe wetgeving gevolgen heeft voor meerdere processen tegelijk. Of iemand vertrekt die precies wist waar alles stond.

    Dan blijkt dat compliance niet alleen gaat over regels kennen. Het gaat vooral over grip houden op verplichtingen, risico’s, verantwoordelijkheden en opvolging.

    Daar komt ISO 37301 in beeld.

    Niet omdat iedere organisatie zich direct tegen ISO 37301 moet laten certificeren. Wel omdat de norm helpt om na te denken over een vraag die steeds vaker speelt:

    wanneer is compliance te belangrijk geworden om nog met losse documenten, Excel-lijsten en geheugen te beheren?

    De vraag is dus niet alleen of ISO 37301 nodig is. De betere vraag is of je huidige manier van werken nog uitlegbaar blijft zodra iemand van buitenaf doorvraagt.

    Wat is ISO 37301?

    ISO 37301 is een internationale standaard voor een compliance management system. Formeel is het een certificeerbare managementsysteemnorm met eisen en toelichting voor toepassing. Praktisch gezien helpt de norm organisaties om complianceverplichtingen systematisch te identificeren, beoordelen, beheren, monitoren en verbeteren.

    Dat klinkt misschien formeel, maar de gedachte erachter is vrij eenvoudig.

    Compliance gaat niet alleen over wetgeving. Het kan ook gaan over contractuele klantafspraken, sectorregels, interne beleidsregels, ISO-eisen, privacyverplichtingen, informatiebeveiligingseisen, leveranciersafspraken en governance-afspraken.

    Een organisatie heeft dus zelden met één soort verplichting te maken. In de praktijk lopen verplichtingen door elkaar heen. Een klant vraagt om ISO 27001. De AVG stelt eisen aan persoonsgegevens. Een leverancier moet periodiek beoordeeld worden. Een audit levert verbeterpunten op. Een contract bevat afspraken over beschikbaarheid, beveiliging of rapportage.

    ISO 37301 helpt niet om één regel af te vinken. Het helpt om al die verplichtingen samen beheersbaar te maken.

    Daarmee is het niet alleen een norm, maar ook een praktisch denkkader: hoe zorg je dat compliance geen losse verzameling afspraken blijft, maar onderdeel wordt van hoe je organisatie werkt?

    Wat bedoelen we met een compliance management system?

    Een compliance management system, vaak afgekort als CMS, is geen softwarepakket en ook geen beleidsmap. Het is de manier waarop een organisatie compliance organiseert.

    Een goed CMS maakt duidelijk welke verplichtingen gelden, welke risico’s ontstaan als die verplichtingen niet worden nageleefd, wie verantwoordelijk is, welke maatregelen zijn ingericht en hoe opvolging wordt bewaakt.

    Daarmee is een CMS vooral een werkend systeem van afspraken, controles en opvolging. Niet een verzameling documenten die alleen tijdens een audit wordt geopend.

    Dat verschil is belangrijk.

    Stel dat een klant vraagt welke beveiligingsafspraken uit het contract actief worden bewaakt. Zonder CMS zoek je misschien in contracten, beleidsdocumenten, auditrapporten en losse actielijsten. Met een CMS zie je welke verplichting geldt, welk risico eraan hangt, welke maatregel is ingericht en wie verantwoordelijk is voor opvolging.

    Een organisatie kan veel beleid hebben en toch weinig grip. Als niemand weet welke verplichtingen prioriteit hebben, wie eigenaar is van welke actie of waar bewijs te vinden is, dan is er misschien documentatie, maar nog geen werkend compliance management system.

    Andersom hoeft een CMS niet zwaar te zijn. Het kan klein beginnen, met een overzicht van de belangrijkste verplichtingen, gekoppeld aan risico’s, maatregelen, eigenaarschap en periodieke opvolging.

    De waarde zit niet in de hoeveelheid vastlegging. De waarde zit in samenhang.

    Wanneer wordt een compliance management system nodig?

    Je hebt geen compliance management system nodig omdat je groot bent. Je hebt het nodig zodra je verplichtingen te belangrijk zijn geworden om impliciet te beheren.

    Dat moment komt vaak eerder dan organisaties denken.

    Het eerste signaal is versnippering. Compliance-informatie staat verspreid over documenten, spreadsheets, e-mails, contracten en hoofden. Iedereen heeft een deel van het beeld, maar niemand heeft het geheel. Dat wordt riskant zodra iemand vraagt om uitleg of bewijs.

    Een tweede signaal is terugkerend uitzoekwerk. Bij iedere security questionnaire, leveranciersbeoordeling, klantvraag of audit moet opnieuw worden gezocht naar dezelfde informatie. Welke maatregelen hebben we ook alweer? Waar staat het bewijs? Wie weet of deze afspraak nog actueel is?

    Een derde signaal is onduidelijk eigenaarschap. Compliance werkt niet als iedereen een beetje verantwoordelijk is. Dan blijven acties makkelijk liggen, zeker als ze niet urgent voelen. Een CMS maakt zichtbaar wie waarvoor verantwoordelijk is en wat nog opgevolgd moet worden.

    Ook nieuwe verplichtingen zijn een belangrijk kantelpunt. Nieuwe wetgeving, gewijzigde klantvoorwaarden of normupdates vragen om beoordeling. Raakt dit ons? Welke processen worden geraakt? Wie pakt dit op? Welke maatregelen zijn nodig? Zonder structuur wordt dat al snel ad hoc geregeld.

    Daarnaast wordt een CMS relevant wanneer verbeteracties blijven liggen. Auditbevindingen, incidenten en klantklachten worden misschien wel geregistreerd, maar niet structureel opgevolgd. Dan ontstaat het risico dat dezelfde bevindingen terugkomen. Niet omdat mensen het niet belangrijk vinden, maar omdat opvolging niet goed is ingebed.

    Tot slot speelt samenloop van normen een grote rol. Veel organisaties werken niet meer met één verplichtingenkader. Ze hebben te maken met ISO 27001, ISO 9001, AVG, NIS2, NEN 7510, klantstandaarden of sectorspecifieke eisen. Zonder samenhang leidt dat tot dubbel werk en losse interpretaties.

    Een CMS wordt nodig zodra compliance niet meer afhankelijk mag zijn van geheugen, goede bedoelingen of losse overzichten.

    Moet je dit meteen zwaar optuigen?

    Dat is een logische zorg.

    ISO 37301 klinkt al snel als iets groots. Een norm. Een managementsysteem. Mogelijk zelfs certificering. Voor organisaties waar compliance naast de dagelijkse operatie wordt opgepakt, kan dat voelen als een extra laag werk.

    Toch hoeft dat niet zo te zijn.

    Certificering tegen ISO 37301 zal lang niet altijd de logische eerste stap zijn. De principes achter de norm zijn juist waardevol voor organisaties die geen groot compliance-team hebben, maar wel steeds vaker moeten aantonen dat verplichtingen serieus worden beheerd.

    In veel organisaties zit compliancekennis bij een paar mensen. Dat werkt snel en efficiënt, totdat de druk toeneemt. Een klant stelt strengere eisen. Een audit vraagt om bewijs. Een medewerker vertrekt. Een nieuwe norm komt erbij. Dan wordt zichtbaar hoe kwetsbaar impliciete kennis kan zijn.

    ISO 37301 is daarom vooral nuttig als praktisch denkraam.

    Niet alles hoeft zwaar. Niet alles hoeft tegelijk. Maar wat belangrijk is, moet duidelijk zijn.

    Een CMS is geen extra laag bureaucratie. Het is een manier om belangrijke verplichtingen zichtbaar, overdraagbaar en opvolgbaar te maken.

    Hoe verhoudt ISO 37301 zich tot ISO 27001 en ISO 9001?

    Veel organisaties kennen ISO 27001 of ISO 9001 beter dan ISO 37301.

    ISO 27001 richt zich op informatiebeveiliging. ISO 9001 richt zich op kwaliteitsmanagement. ISO 37301 richt zich op compliance als managementproces.

    Dat betekent dat ISO 37301 deze normen niet vervangt. Het helpt juist om de compliancekant ervan beter te organiseren.

    Neem ISO 27001. Daarin spelen risicoanalyse, beheersmaatregelen, interne audits, managementreviews, incidenten en verbeteracties een belangrijke rol. Dat zijn niet alleen informatiebeveiligingsonderwerpen, maar ook verplichtingen die opgevolgd moeten worden.

    Bij ISO 9001 zie je hetzelfde. Procesbeheersing, klanttevredenheid, afwijkingen, verbeteracties en leveranciersbeoordelingen vragen om structuur en aantoonbare opvolging.

    De AVG vraagt om zorgvuldige omgang met persoonsgegevens. NIS2 vraagt om cyberweerbaarheid, risicobeheer en incidentmelding. Klantcontracten kunnen specifieke eisen stellen aan beveiliging, beschikbaarheid, rapportage of audits.

    In de praktijk worden deze verplichtingen vaak apart beheerd. Een deel in het ISMS. Een deel in het kwaliteitsmanagementsysteem. Een deel in contracten. Een deel in losse actielijsten.

    ISO 37301 helpt om daar een overkoepelende laag boven te leggen. Niet om alles dubbel te doen, maar om verplichtingen, risico’s, maatregelen en opvolging met elkaar te verbinden.

    Dat voorkomt dat compliance per norm wordt georganiseerd, terwijl dezelfde maatregelen, risico’s en verantwoordelijkheden meerdere keren terugkomen.

    Wat levert een compliance management system praktisch op?

    De waarde van een CMS zit niet in het hebben van een net systeem. De waarde zit in wat het dagelijks makkelijker maakt.

    Een eerste voordeel is minder afhankelijkheid van losse kennis. Als verplichtingen, risico’s, maatregelen en verantwoordelijkheden centraal zijn vastgelegd, hoeft niet alles uit het hoofd van één persoon te komen. Dat maakt de organisatie minder kwetsbaar.

    Een tweede voordeel is sneller reageren op klantvragen. Wanneer een klant vraagt naar beveiligingsmaatregelen, privacyafspraken, certificeringen of auditresultaten, hoef je niet opnieuw te zoeken. Je weet welke informatie relevant is en waar die staat.

    Ook auditstress neemt af. Bewijsvoering ontstaat tijdens het werk, niet pas vlak voor de audit. Daardoor wordt een audit minder afhankelijk van last-minute herstelwerk.

    Daarnaast zorgt een CMS voor duidelijker eigenaarschap. Acties blijven minder snel liggen wanneer zichtbaar is wie verantwoordelijk is, wat de status is en wanneer opvolging nodig is.

    Een ander belangrijk voordeel is minder dubbel werk. Verplichtingen uit verschillende normen kunnen vaak aan dezelfde maatregelen worden gekoppeld. Eén interne audit, één leveranciersbeoordeling of één verbeteractie kan relevant zijn voor meerdere verplichtingen.

    Voor het management wordt compliance daarmee minder afhankelijk van losse signalen. Je ziet niet alleen dat er acties openstaan, maar ook welke verplichtingen, risico’s of klanten daardoor geraakt worden. Dat maakt het makkelijker om prioriteiten te stellen en gericht te sturen.

    Dat geeft meer vertrouwen richting klanten, auditors en partners. Niet omdat je kunt zeggen dat alles perfect is, maar omdat je kunt laten zien dat compliance georganiseerd is.

    Hoe begin je zonder groot traject?

    Een compliance management system hoeft niet te beginnen met een groot implementatieproject.

    Begin klein, maar begin wel gestructureerd.

    De eerste stap is het in kaart brengen van de belangrijkste complianceverplichtingen. Niet alles tegelijk. Start met de verplichtingen die commercieel, juridisch of operationeel de meeste impact hebben. Denk aan AVG, ISO 27001, ISO 9001, klantcontracten, leveranciersafspraken of sectorspecifieke eisen.

    Daarna bepaal je per verplichting het risico. Wat gebeurt er als je niet voldoet? Denk aan klantverlies, auditbevindingen, boetes, reputatieschade, datalekken of operationele verstoring.

    Vervolgens wijs je eigenaarschap toe. Iedere belangrijke verplichting heeft iemand nodig die verantwoordelijk is voor opvolging. Niet alleen iemand die inhoudelijk iets weet, maar iemand die bewaakt dat het onderwerp niet blijft liggen.

    Daarna koppel je maatregelen en controles. Welke afspraken, processen of controles zorgen ervoor dat je aan de verplichting voldoet? Dat kan gaan om documentbeheer, interne audits, leveranciersbeoordelingen, toegangscontroles, incidentregistratie, periodieke reviews of training.

    Belangrijk is dat bewijsvoering tijdens het werk ontstaat. Als je bewijs pas vlak voor een audit gaat verzamelen, ben je eigenlijk te laat. Een goed CMS helpt om bewijs vast te houden op het moment dat iets gebeurt.

    Tot slot moet er periodieke evaluatie zijn. Compliance verandert. Wetgeving verandert. Klanten veranderen. Processen veranderen. Een CMS is dus geen eenmalige inrichting, maar een manier om actueel te blijven.

    Waar CompliTrack logisch aansluit

    Een compliance management system hoeft geen zware corporate suite te zijn. Zeker niet voor organisaties die overzicht willen zonder onnodige complexiteit.

    Juist wanneer compliance naast de dagelijkse operatie wordt opgepakt, moet structuur praktisch blijven. Je wilt verplichtingen kunnen beheren, risico’s kunnen koppelen, eigenaarschap zichtbaar maken en acties opvolgen. Maar je wilt niet verdrinken in configuratie, terminologie en processen die niet passen bij hoe je werkt.

    CompliTrack helpt om compliance beheersbaar te organiseren door verplichtingen, risico’s, maatregelen en opvolging op één plek samen te brengen.

    Dat betekent dat je niet langer losse lijsten hoeft bij te houden voor audits, risico’s, incidenten, verbeteracties en klantvragen. Je kunt verbanden leggen. Een verplichting kan gekoppeld worden aan een risico. Een risico aan een maatregel. Een maatregel aan een taak. Een auditbevinding aan een verbeteractie. Een incident aan structurele opvolging.

    De waarde zit niet in méér administratie. De waarde zit in één plek waar zichtbaar wordt wat belangrijk is, wie verantwoordelijk is en wat nog moet gebeuren.

    Daarmee sluit CompliTrack goed aan op de praktische kant van ISO 37301: compliance niet zwaarder maken, maar beter organiseren.

    Verder lezen

    Wil je verder lezen over structuur, audits en opvolging? Deze artikelen sluiten goed aan:

    • Het moment waarop Excel niet meer helpt, maar tegenwerkt
      Over het kantelpunt waarop losse overzichten meer uitleg vragen dan ze opleveren.
    • Een interne audit werkt pas als mensen durven zeggen wat niet klopt
      Over audits als instrument voor inzicht, eigenaarschap en verbetering.
    • Wat de opvolging van verbeterpunten zegt over hoe serieus je compliance neemt
      Over waarom verbeterpunten pas waarde krijgen als ze worden vastgelegd, opgevolgd en geëvalueerd.

    Conclusie

    ISO 37301 is vooral interessant zodra compliance te belangrijk wordt om los te organiseren.

    Dat moment komt niet pas bij grote organisaties. Het komt zodra klanten, auditors, wetgeving of groei vragen om aantoonbare grip. Zodra verplichtingen verspreid raken. Zodra acties blijven liggen. Zodra bewijs telkens opnieuw gezocht moet worden. Of zodra niemand precies kan uitleggen wie waarvoor verantwoordelijk is.

    Voor veel organisaties begint ISO 37301 niet met certificering. Het begint met overzicht.

    Welke verplichtingen gelden?
    Welke risico’s horen daarbij?
    Wie is eigenaar?
    Welke maatregelen zijn genomen?
    En hoe wordt opvolging bewaakt?

    Een compliance management system is geen bewijs dat je groot bent. Het is een manier om te voorkomen dat belangrijke verplichtingen afhankelijk blijven van losse kennis, losse documenten en losse opvolging.

    Merk je dat klantvragen, audits of nieuwe verplichtingen steeds meer uitzoekwerk kosten? Plan een vrijblijvende kennismaking en ontdek hoe CompliTrack helpt om compliance praktisch en betaalbaar te organiseren.

  • Wanneer wordt AI een governance-vraagstuk?

    Wanneer wordt AI een governance-vraagstuk?

    AI is in veel organisaties al onderdeel van het werk. Niet altijd via een officieel project, maar via medewerkers, SaaS-tools en slimme functies die automatisch beschikbaar komen. Teksten worden voorbereid, klantdocumenten samengevat, rapportages versneld en analyses ondersteund.

    Vaak is de vraag niet óf AI wordt gebruikt, maar of je organisatie het gebruik al scherp genoeg ziet.

    Dat is niet per se een probleem. Zolang AI een beperkt hulpmiddel blijft, zonder gevoelige informatie of directe invloed op besluiten, is de governancevraag nog overzichtelijk.

    Maar zodra AI raakt aan klantdata, persoonsgegevens, kwaliteit, compliance of beslissingen, verandert de situatie. Dan gaat het niet meer alleen om gebruiksgemak. Dan moet je kunnen uitleggen waar AI wordt gebruikt, welke risico’s daarbij horen en wie verantwoordelijk is voor de uitkomst.

    Precies daar komt ISO/IEC 42001 in beeld.

    ISO/IEC 42001 is een internationale managementsysteemstandaard voor AI en wordt door ISO gepositioneerd als de eerste wereldwijde standaard voor AI-managementsystemen. De standaard is relevant voor organisaties die AI-systemen ontwikkelen, aanbieden, inkopen of gebruiken. Het gaat daarbij niet alleen om techniek, maar juist ook om beleid, verantwoordelijkheden, processen, risico’s, monitoring en continue verbetering.

    Voor veel organisaties betekent dat niet dat er direct een certificeringstraject nodig is. Maar het betekent wel dat AI-gebruik minder vrijblijvend wordt zodra het invloed krijgt op informatie, besluiten, klanten of bewijsvoering richting opdrachtgevers en auditors.

    Wat is ISO 42001?

    ISO/IEC 42001 helpt organisaties om AI op een gestructureerde manier te beheersen. De norm kijkt niet alleen naar de AI-tool zelf, maar vooral naar de organisatie eromheen.

    Dat maakt de standaard herkenbaar voor organisaties die al werken met managementsystemen zoals ISO 9001 of ISO 27001. De gedachte is vergelijkbaar: je richt processen, verantwoordelijkheden en controles zo in dat je aantoonbaar grip houdt op een belangrijk onderwerp. Bij ISO 42001 is dat onderwerp AI.

    Het gaat dan om vragen als:

    Wie bepaalt waarvoor AI wel en niet wordt gebruikt?
    Welke risico’s horen bij een AI-toepassing?
    Welke data mag worden gebruikt?
    Wanneer is menselijke controle nodig?
    Hoe monitor je of AI verantwoord blijft werken?
    Wie grijpt in als de uitkomst niet klopt?

    Daarmee is ISO 42001 niet hetzelfde als een AI-tool goed instellen. Het gaat niet alleen over prompts, instellingen of modelkeuzes. Het gaat vooral over governance: de afspraken, verantwoordelijkheden en controles rondom AI.

    Of simpeler gezegd: ISO 42001 helpt je om AI niet alleen te gebruiken, maar ook te beheersen.

    Waarom AI governance sneller relevant wordt dan je denkt

    AI governance klinkt groot. Het roept misschien beelden op van grote organisaties, juridische afdelingen, ethische commissies en ingewikkelde modellen. In de praktijk begint het vaak veel kleiner.

    Niet met dikke beleidsdocumenten, maar met duidelijke afspraken. Niet met een groot programma, maar met overzicht. Niet met de vraag of alles perfect is ingericht, maar met de vraag of je weet waar AI wordt gebruikt en welke risico’s daarbij horen.

    Een adviesbureau dat AI gebruikt om klantdocumenten samen te vatten, verwerkt mogelijk vertrouwelijke informatie. Een softwarebedrijf dat AI-functionaliteit toevoegt aan zijn product, krijgt verantwoordelijkheid voor de manier waarop klanten die functionaliteit gebruiken. Een HR-dienstverlener die AI gebruikt om sollicitatiebrieven te analyseren, raakt direct aan eerlijkheid, privacy en uitlegbaarheid. Een administratiekantoor dat AI inzet voor documentclassificatie, moet kunnen beoordelen wat er gebeurt als de uitkomst niet klopt.

    De vraag is of je kunt uitleggen wat je doet, waarom dat verantwoord is en wie erop stuurt.

    Daarom is AI governance niet alleen relevant voor organisaties die zelf AI ontwikkelen. Het wordt relevant zodra AI invloed krijgt op informatie, besluiten, dienstverlening of vertrouwen.

    Wanneer wordt AI een governance-vraagstuk?

    AI wordt een governance-vraagstuk op het moment dat informeel gebruik niet meer past bij de impact van de toepassing.

    Dat kantelpunt ontstaat vaak geleidelijk. Eerst gebruikt één medewerker een AI-tool om een tekstvoorstel te maken. Daarna gebruikt een team AI om klantinformatie samen te vatten. Vervolgens wordt AI onderdeel van een werkproces, rapportage of klantadvies. Voor je het weet, is AI geen los hulpmiddel meer, maar onderdeel van hoe de organisatie werkt.

    Er zijn een paar duidelijke signalen dat AI meer sturing nodig heeft.

    AI werkt met gevoelige informatie

    Zodra medewerkers persoonsgegevens, klantdata, contracten, financiële informatie, broncode of interne beleidsdocumenten invoeren in AI-tools, ontstaat een informatiebeveiligings- en privacyvraagstuk.

    De vraag is dan niet alleen of de tool handig is, maar ook waar de data terechtkomt, wie toegang heeft, of de leverancier informatie gebruikt voor training en of dit past binnen afspraken met klanten, leveranciers en medewerkers.

    AI beïnvloedt beslissingen

    AI wordt risicovoller wanneer de uitkomst wordt gebruikt om keuzes te maken. Denk aan klantacceptatie, prioritering van risico’s, beoordeling van sollicitanten, compliancebeoordelingen, fraudedetectie of advies richting klanten.

    Ook als een mens uiteindelijk de beslissing neemt, kan AI de richting van die beslissing beïnvloeden. Juist daarom moet duidelijk zijn wanneer menselijke controle nodig is en welke waarde aan een AI-advies wordt toegekend.

    Wie dieper wil ingaan op menselijke controle bij geautomatiseerde beslissingen, kan ook lezen: AI in compliance: hoe je menselijke controle houdt over geautomatiseerde beslissingen.

    AI-antwoorden worden als waarheid behandeld

    AI kan overtuigend klinken en toch onjuist zijn. Dat maakt het risico verraderlijk. Niet omdat elke uitkomst fout is, maar omdat mensen geneigd kunnen zijn om een goed geformuleerd antwoord sneller te vertrouwen.

    Het risico zit dus niet alleen in de technologie, maar ook in het gebruik ervan. Als medewerkers AI-antwoorden overnemen zonder controle, ontstaat schijnzekerheid.

    AI wordt onderdeel van je dienstverlening

    Zodra AI-functionaliteit onderdeel wordt van een product, rapportage, analyse of klantproces, verandert je verantwoordelijkheid. Klanten vertrouwen dan niet alleen op jouw dienstverlening, maar indirect ook op de manier waarop jij AI inzet en beheerst.

    Dan moet je kunnen uitleggen wat AI wel doet, wat niet, waar menselijke controle plaatsvindt en waar de grenzen liggen.

    Niemand weet precies wie eigenaar is

    AI raakt vaak meerdere rollen tegelijk. IT kijkt naar tools en beveiliging. Compliance kijkt naar risico’s en verplichtingen. Management kijkt naar strategie en efficiëntie. De operatie kijkt naar toepasbaarheid.

    Als iedereen een stukje verantwoordelijkheid voelt, maar niemand echt eigenaar is, ontstaat governance-risico. Dan blijven beslissingen liggen, worden uitzonderingen informeel gemaakt en is onduidelijk wie mag bepalen of een AI-toepassing verantwoord is.

    Klanten, auditors of opdrachtgevers gaan vragen stellen

    Veel organisaties komen pas in beweging als een externe partij vraagt hoe AI wordt beheerst. Bijvoorbeeld in een security questionnaire, audit, aanbesteding of leveranciersbeoordeling.

    Op dat moment wil je niet voor het eerst moeten uitzoeken waar AI wordt gebruikt. Je wilt kunnen laten zien dat je AI-toepassingen kent, risico’s beoordeelt en passende maatregelen neemt.

    Welke risico’s helpt ISO 42001 zichtbaar maken?

    ISO 42001 helpt om AI-risico’s niet alleen technisch, maar vooral organisatorisch te bekijken.

    Een eerste risico zit bij informatie en privacy. AI-tools kunnen gegevens verwerken op manieren die niet altijd direct zichtbaar zijn. De kernvraag is dus welke informatie je invoert, of dat mag en welke afspraken daarover bestaan.

    Een tweede risico zit bij betrouwbaarheid. AI kan fouten maken, bronnen verzinnen of context verkeerd interpreteren. Als AI wordt gebruikt in klantadvies, compliancebeoordelingen of interne besluitvorming, moet duidelijk zijn wanneer controle verplicht is.

    Een derde risico is uitlegbaarheid. Als een AI-uitkomst leidt tot een beslissing, moet je kunnen uitleggen hoe die beslissing tot stand kwam. Niet altijd tot op technisch detailniveau, maar wel organisatorisch: welke informatie is gebruikt, wie heeft beoordeeld, welke controle is uitgevoerd en wie was verantwoordelijk?

    Een vierde risico zit bij leveranciers. Veel AI-functionaliteit zit inmiddels ingebouwd in bestaande software. Daardoor gebruiken organisaties soms AI zonder dat zij het als aparte AI-toepassing herkennen. Ook dan blijven vragen over data, logging, beveiliging, contractafspraken en afhankelijkheid relevant.

    Een vijfde risico is eigenaarschap. Een AI-risico zonder eigenaar wordt al snel een organisatiebreed probleem waar niemand echt op stuurt. Dat is precies het soort risico dat in audits, klantvragen of incidenten zichtbaar wordt.

    Moet je meteen certificeren voor ISO 42001?

    De eerste stap is meestal geen certificering, maar overzicht.

    Voor veel organisaties is ISO 42001-certificering niet direct de meest logische route. Het is verstandiger om eerst te begrijpen waar AI wordt gebruikt, welke risico’s dat oplevert en welke afspraken nodig zijn.

    Certificering kan later relevant worden. Bijvoorbeeld wanneer klanten er expliciet om vragen, wanneer AI onderdeel is van je product of dienstverlening, of wanneer AI-uitkomsten grote impact hebben op mensen, klanten of kritieke processen.

    Ook kan ISO 42001 interessant worden als je al werkt met ISO 27001, ISO 9001 of een ander managementsysteem. In dat geval kun je AI governance vaak logisch toevoegen aan bestaande processen voor risicoanalyse, leveranciersbeheer, incidentbeheer, interne audits en managementreview.

    ISO 42001 begint dus niet bij certificering, maar bij grip.

    Voor veel organisaties is ISO 42001 nu vooral waardevol als denkkader. Niet om direct te certificeren, maar om te bepalen waar informeel AI-gebruik te risicovol wordt.

    Hoe begin je praktisch met AI governance?

    Een praktische start hoeft niet ingewikkeld te zijn. Het belangrijkste is dat AI-gebruik zichtbaar wordt en dat risico’s niet impliciet blijven.

    Begin met het in kaart brengen van waar AI wordt gebruikt. Kijk daarbij niet alleen naar officiële AI-tools, maar ook naar AI-functionaliteit in bestaande software. Denk aan tekstgeneratie, automatische samenvattingen, classificatie, analysefuncties of slimme assistenten in SaaS-applicaties.

    Daarna beoordeel je welke toepassingen echt risico opleveren. Niet elk AI-gebruik vraagt dezelfde mate van beheersing. Een tekstvoorstel voor een interne nieuwsbrief is iets anders dan AI die klantbeoordelingen ondersteunt of persoonsgegevens verwerkt.

    Vervolgens leg je eigenaarschap vast. Wie is verantwoordelijk voor AI-beleid? Wie beoordeelt risico’s? Wie beslist of een toepassing wel of niet gebruikt mag worden? En wie monitort of afspraken worden nageleefd?

    Daarna maak je duidelijke afspraken over data. Welke informatie mag nooit in publieke AI-tools worden ingevoerd? Welke tools zijn goedgekeurd? Welke uitzonderingen zijn mogelijk? En wat moeten medewerkers doen als ze twijfelen?

    Ook leveranciers verdienen aandacht. Als een leverancier AI-functionaliteit toevoegt aan software die je gebruikt, wil je weten wat dit betekent voor data, beveiliging, logging, transparantie en contractuele afspraken.

    Tot slot koppel je risico’s aan maatregelen. Denk aan menselijke review, toegangsbeheer, logging, leveranciersbeoordeling, training, incidentregistratie en periodieke evaluatie.

    De manier van denken lijkt sterk op reguliere risicobeheersing. Lees eventueel ook: ISO 27001 risicoanalyse: In 5 stappen van dreiging naar beheersing.

    AI governance is geen eenmalig beleid. Het is een manier om te blijven leren van gebruik, vragen, afwijkingen en incidenten.

    De link met bestaande GRC-processen

    Het goede nieuws is dat AI governance meestal geen volledig nieuw traject hoeft te zijn. Veel bouwstenen bestaan al binnen volwassen GRC-processen.

    Denk aan risicoanalyse, maatregelenbeheer, leveranciersbeoordeling, incidentregistratie, verbeteracties, interne audits en managementreviews.

    AI vraagt dan niet per se om meer bureaucratie. Het vraagt vooral om uitbreiding van bestaande governance naar een nieuw risicodomein.

    De vraag is dus niet of je een apart AI-proces nodig hebt.

    De vraag is of je bestaande governance sterk genoeg is om AI mee te nemen.

    Als risico’s al centraal worden vastgelegd, kun je AI-risico’s daaraan toevoegen. Als leveranciers al periodiek worden beoordeeld, kun je AI-functionaliteit meenemen in die beoordeling. Als incidenten al worden geregistreerd, kun je AI-gerelateerde afwijkingen daarin opnemen. En als verbeteracties al worden opgevolgd, kun je AI governance laten meegroeien met de praktijk.

    Daarmee past AI governance goed bij dezelfde structuur waarin je ook risico’s, maatregelen, leveranciers, incidenten en verbeteracties beheert.

    Juist voor organisaties met beperkte tijd en capaciteit is dat belangrijk. AI governance moet werkbaar blijven. Anders wordt het een papieren exercitie waar niemand eigenaar van wordt.

    Conclusie

    AI wordt pas echt spannend wanneer niemand meer precies weet waar het wordt gebruikt, welke risico’s eraan zitten en wie verantwoordelijk is voor de uitkomst.

    ISO 42001 helpt organisaties om die vragen gestructureerd te beantwoorden. Niet door AI onnodig zwaar te maken, maar door duidelijk te maken waar beleid, eigenaarschap, risicoanalyse, controle en verbetering nodig zijn.

    Dat hoeft niet te beginnen met certificering. Het begint met overzicht. Met duidelijke afspraken. Met verantwoordelijkheid. En met het vermogen om uit te leggen waarom AI-gebruik verantwoord is.

    Wie AI wil gebruiken zonder onnodig risico, moet dus niet alleen naar de tool kijken.

    Kijk vooral naar de afspraken eromheen.

    Verder lezen

    Wil je dieper ingaan op de onderwerpen achter AI governance? Lees dan ook:

    Wil je weten waar jouw AI-risico’s zitten?

    Gebruik je al AI in je organisatie en wil je weten waar de risico’s zitten? Plan een vrijblijvende kennismaking en ontdek hoe CompliTrack helpt om AI governance praktisch in te richten.

    Met CompliTrack leg je AI-risico’s, maatregelen, leveranciers, verantwoordelijkheden en verbeteracties op één plek vast. Zo kun je klein beginnen, zonder dat AI governance afhankelijk blijft van losse documenten, spreadsheets of informele afspraken.

  • Waarom prioriteren belangrijker is dan analyseren

    Waarom prioriteren belangrijker is dan analyseren

    Er ligt een risico-overzicht op tafel. Niet voor het eerst.

    De belangrijkste risico’s zijn geïnventariseerd, beoordeeld en voorzien van een score. Er staat bij wat de mogelijke impact is, welke maatregelen denkbaar zijn en waar nog onzekerheid zit. Iedereen ziet dat er aandacht nodig is. Tegelijkertijd is de agenda vol, zijn er klantafspraken die door moeten en vraagt de dagelijkse operatie om dezelfde mensen.

    Dan ontstaat de echte vraag: wat krijgt nu voorrang?

    Niet welk risico het hoogst scoort in de analyse. Niet welke maatregel theoretisch het beste is. Maar welk risico vandaag, deze week of dit kwartaal daadwerkelijk aandacht verdient. En welk risico bewust blijft liggen, omdat iets anders belangrijker is.

    Dat is het moment waarop risicobeheer praktisch wordt.

    Dat kantelpunt stond centraal in Een risico wordt pas relevant wanneer iemand moet kiezen: een risico krijgt pas betekenis wanneer iemand er een afweging aan moet verbinden. Deze blog gaat een stap verder, naar de vraag waarom prioriteren dan vaak belangrijker wordt dan nog verder analyseren.

    Veel organisaties besteden veel energie aan analyseren. Dat is begrijpelijk. Een goede analyse geeft taal aan onzekerheid. Je ziet beter waar afhankelijkheden zitten, welke processen kwetsbaar zijn en waar incidenten of klantvragen op kunnen wijzen. Zonder analyse ontstaat al snel onderbuikgevoel.

    Maar analyse is geen besluit.

    Daar gaat het vaak mis. Een risico wordt verder onderzocht, opnieuw besproken of voorzien van extra nuance. De score wordt aangescherpt, de toelichting uitgebreid en het overzicht verfijnd.

    Dat voelt zorgvuldig. Toch kan het ook een manier worden om kiezen uit te stellen. Er is altijd nog iets dat verder uitgezocht kan worden. Een afhankelijkheid die niet helemaal scherp is. Een maatregel waarvan de effectiviteit nog niet bewezen is. Een risico dat misschien minder groot is dan het lijkt, of juist groter.

    Juist in organisaties waar dezelfde mensen meerdere verantwoordelijkheden dragen, wordt dat snel zichtbaar. De mensen die risico’s beoordelen, zijn vaak ook de mensen die klanten helpen, systemen beheren, processen verbeteren en audits voorbereiden. Capaciteit is beperkt. Niet alles kan tegelijk.

    Juist daarom wordt prioriteren vaak belangrijker dan verder analyseren.

    Niet omdat analyse onbelangrijk is, maar omdat analyse pas waarde krijgt wanneer zij richting geeft aan keuzes. Een risico met een hoge score hoeft niet altijd als eerste te worden aangepakt. Misschien is de maatregel te groot voor dit moment. Misschien is het risico tijdelijk acceptabel omdat er een klantdeadline speelt. Misschien is een lager scorend risico urgenter omdat het direct raakt aan betrouwbaarheid of uitlegbaarheid.

    Dat soort afwegingen passen niet altijd netjes in een matrix. Ze vragen om context.

    Stel dat een klant uitleg vraagt over leveranciersbeheer, een interne bevinding al maanden openstaat en tegelijk een verouderd beleid moet worden herzien. Op papier kunnen alle drie relevant zijn. Toch is de vraag niet alleen wat belangrijk is, maar vooral wat nu het meeste vraagt om een besluit.

    Misschien is de openstaande bevinding het meest urgent, omdat die al eerder is blijven liggen. Misschien vraagt de leveranciersbeoordeling voorrang, omdat daar een concrete klantvraag aan raakt. De analyse helpt om dat gesprek te voeren, maar neemt de keuze niet over.

    Daarom schieten gangbare oplossingen vaak tekort. Een uitgebreider risico-overzicht geeft meer informatie, maar niet automatisch meer richting. Een periodiek overleg houdt risico’s zichtbaar, maar voorkomt niet dat dezelfde punten telkens terugkomen zonder besluit. En een lijst met openstaande maatregelen laat zien dat er werk ligt, maar niet waarom juist dit werk eerst moet gebeuren.

    Structuur helpt pas wanneer zij de keuze zichtbaar maakt.

    Dat hoeft niet zwaar te zijn. Het gaat erom dat bij een risico niet alleen staat wat het is, maar ook wat ermee gebeurt. Wordt het opgepakt? Wordt het geaccepteerd? Wordt het uitgesteld? En als het wordt uitgesteld, is dat dan een bewuste keuze of vooral het gevolg van drukte?

    Die laatste vraag is belangrijk. Veel risico’s blijven niet liggen omdat iemand besloten heeft dat ze acceptabel zijn. Ze blijven liggen omdat niemand expliciet heeft gekozen. Daardoor ontstaat een grijs gebied. Het risico is bekend, maar de prioriteit is onduidelijk. Iedereen weet dat het bestaat, maar niemand kan later goed uitleggen waarom er niets mee is gedaan.

    Uitlegbaar prioriteren vraagt om een herkenbaar risico, een duidelijke afweging en zichtbaar eigenaarschap. Niet als checklist, maar als manier om het gesprek concreet te houden. Wie mag bepalen dat dit risico nu voorgaat? Wie mag besluiten dat een ander risico blijft liggen? En wanneer bekijken we die keuze opnieuw?

    Wanneer die vragen worden vastgehouden, ontstaat rust. Niet omdat alle risico’s verdwijnen, maar omdat duidelijk wordt welke risico’s aandacht krijgen en waarom. Dat maakt risicobeheer minder abstract. Het voorkomt ook dat analyse een doel op zich wordt.

    Een eenvoudige manier van vastleggen kan daarbij helpen, zolang die niet belangrijker wordt dan de afweging zelf. Het gaat niet om meer administratie, maar om het vasthouden van de keuze: wat is besloten, waarom was dat op dat moment verdedigbaar en wanneer moet die keuze opnieuw worden bekeken?

    Uiteindelijk zegt prioritering meer over risicobeheer dan de analyse zelf.

    Een organisatie kan een indrukwekkend overzicht hebben en toch weinig grip ervaren. Andersom kan een eenvoudige risicoaanpak goed werken wanneer duidelijk is welke keuzes worden gemaakt, wie daarvoor verantwoordelijk is en waarom die keuzes op dat moment verdedigbaar zijn.

    De vraag is dus niet of alle risico’s volledig zijn geanalyseerd. De betere vraag is of duidelijk is welke risico’s nu aandacht verdienen, welke bewust blijven liggen en wie die afweging kan uitleggen.

    Wie dat scherp heeft, begrijpt zijn eigen risicobeeld beter. Niet omdat alles zeker is, maar omdat onzekerheid wordt verbonden aan keuzes. En precies daar begint echte grip.

    Verder lezen