Tag: ISO

  • SOC 2, ISO 27001 of ISAE 3402: wat vraagt je klant nu eigenlijk van je?

    SOC 2, ISO 27001 of ISAE 3402: wat vraagt je klant nu eigenlijk van je?

    Een klant stelt een ogenschijnlijk eenvoudige vraag:

    “Hebben jullie ISO 27001?”
    of
    “Kunnen jullie een SOC 2 rapport delen?”

    Op het eerste gezicht lijkt het duidelijk wat er gevraagd wordt. Toch is dat in de praktijk zelden het geval.

    De vraag gaat namelijk meestal niet over een specifiek certificaat of rapport, maar over vertrouwen. Alleen wordt dat vertrouwen vaak vertaald naar termen die niet precies aansluiten bij wat de klant daadwerkelijk probeert te toetsen. En juist daar ontstaan keuzes die achteraf niet goed blijken te passen.

    De vraag achter de vraag

    Wanneer een klant vraagt om ISO 27001, SOC 2 of ISAE 3402, probeert hij in de meeste gevallen één van drie dingen duidelijk te krijgen: of je zorgvuldig met informatie omgaat, of je interne beheersmaatregelen daadwerkelijk werken, of dat hij jouw processen veilig kan opnemen in zijn eigen keten.

    Dat zijn wezenlijk verschillende vragen. Toch zie je in de praktijk dat organisaties ze vaak op dezelfde manier beantwoorden, namelijk door te kijken welk certificaat of rapport ze nodig hebben. Daarmee verschuift de focus van de onderliggende behoefte naar de vorm waarin die behoefte wordt uitgedrukt.

    Het gevolg is dat trajecten worden gestart die óf zwaarder zijn dan nodig, óf onvoldoende aansluiten op wat de klant eigenlijk wil weten.

    Wat deze vormen van assurance écht betekenen

    Hoewel de termen vaak door elkaar worden gebruikt, verschillen ze inhoudelijk behoorlijk van elkaar.

    ISO 27001 is een certificering van een managementsysteem voor informatiebeveiliging. Het laat zien dat je structureel risico’s identificeert, passende maatregelen neemt en blijft verbeteren. Daarmee zegt het vooral iets over hoe je organisatie als geheel is ingericht en hoe je omgaat met informatiebeveiliging.

    SOC 2 heeft een andere insteek. Dit is geen certificaat, maar een assurance-rapport waarin een auditor beoordeelt hoe interne beheersmaatregelen zijn ingericht en functioneren. Daarbij is het onderscheid tussen Type I en Type II relevant. Een Type I-rapport kijkt naar de opzet van maatregelen op een bepaald moment, terwijl een Type II-rapport ook beoordeelt of die maatregelen over een langere periode aantoonbaar hebben gewerkt. De nadruk ligt daarmee meer op werking dan alleen op inrichting.

    ISAE 3402 richt zich weer op een ander vraagstuk. Deze rapportage is bedoeld voor situaties waarin een organisatie processen uitvoert die onderdeel zijn van de interne beheersing van haar klant. Denk aan uitbestede processen die invloed hebben op bijvoorbeeld financiële verslaggeving of operationele controles. In zo’n geval wil de klant zekerheid over hoe die processen zijn ingericht en functioneren, omdat hij daar zelf op moet kunnen steunen.

    Waarom deze begrippen door elkaar lopen

    In de praktijk zie je dat organisaties een klantvraag vaak direct vertalen naar een oplossing. Er wordt gevraagd om zekerheid, dus er wordt gedacht aan een certificaat of assurance-rapport.

    Die stap is begrijpelijk, maar vaak te snel.

    Een klant die om ISO 27001 vraagt, wil in veel gevallen simpelweg zeker weten dat informatiebeveiliging serieus en structureel wordt aangepakt. Een vraag naar SOC 2 kan voortkomen uit de behoefte om te zien dat maatregelen niet alleen bestaan, maar ook daadwerkelijk werken. En soms ligt de vraag nog een laag dieper, bijvoorbeeld wanneer een klant wil begrijpen wat er precies gebeurt in een proces dat hij aan jou uitbesteedt.

    Als je die onderliggende bedoeling niet scherp hebt, is de kans groot dat je optimaliseert voor de verkeerde uitkomst.

    De stap die vaak wordt overgeslagen

    Wat in dit soort situaties vaak ontbreekt, is een eenvoudige maar cruciale stap: doorvragen naar de bedoeling achter de vraag.

    Niet welk rapport of certificaat gewenst is, maar welk risico de klant probeert af te dekken en waar hij zekerheid over wil krijgen. In veel gevallen blijkt dat de oorspronkelijke vraag slechts een afgeleide is van een bredere zorg.

    Door dat gesprek te voeren, ontstaat vaak meer ruimte. Soms blijkt een lichtere vorm van bewijs voldoende. In andere gevallen wordt juist duidelijk dat een zwaardere vorm van assurance wél nodig is, maar dan met een heldere reden.

    Wanneer kies je wat?

    De keuze voor ISO 27001, SOC 2 of ISAE 3402 ontstaat idealiter pas nadat duidelijk is wat er precies wordt gevraagd.

    ISO 27001 past wanneer je wilt laten zien dat informatiebeveiliging structureel is ingericht en geborgd in je organisatie.

    SOC 2 is logischer wanneer je moet aantonen dat interne beheersmaatregelen niet alleen bestaan, maar ook aantoonbaar werken over een bepaalde periode.

    ISAE 3402 komt in beeld wanneer jouw processen onderdeel zijn van de controleomgeving van je klant en hij daar expliciet zekerheid over nodig heeft.

    De keuze zelf is dus minder ingewikkeld dan hij vaak lijkt. De complexiteit zit vooral in het goed begrijpen van de vraag die eraan voorafgaat.

    De valkuil van “meer is beter”

    Een veelgemaakte aanname is dat meer bewijs automatisch leidt tot meer vertrouwen. In dat denken voelt een combinatie van certificaten en rapportages al snel als de veilige keuze.

    In de praktijk werkt dat vaak anders.

    Zwaardere trajecten brengen meer auditdruk met zich mee, vragen meer onderhoud en maken processen complexer. Als die extra inspanning niet direct aansluit op wat de klant wil weten, levert het weinig op en kan het zelfs averechts werken.

    Vertrouwen ontstaat niet door de hoeveelheid bewijs, maar door de aansluiting ervan op de vraag.

    Structuur vóór certificering

    Veel organisaties beginnen bij de vorm: welk certificaat of welk rapport is nodig?

    Een sterkere aanpak begint eerder, namelijk bij de onderliggende structuur.

    Welke risico’s spelen er? Welke maatregelen zijn getroffen? Wie is waarvoor verantwoordelijk? En hoe wordt zichtbaar dat maatregelen daadwerkelijk werken?

    Wanneer die basis helder is, volgt de keuze voor een passende vorm van assurance bijna vanzelf. Zonder die basis wordt elk traject zwaarder, omdat het moet compenseren voor onduidelijkheid die eerder al aanwezig was.

    Wat klanten uiteindelijk willen zien

    Uiteindelijk zoeken klanten geen norm op zichzelf. Ze zoeken voorspelbaarheid.

    Ze willen begrijpen wat er gebeurt, waar risico’s zitten en hoe daarmee wordt omgegaan. Een certificaat of rapport is een manier om dat inzicht te geven, maar blijft altijd een middel.

    Niet het doel.

    Tot slot

    De vraag is dus niet zozeer of je ISO 27001 nodig hebt of een SOC 2 rapport moet laten opstellen.

    De relevantere vraag is wat je klant eigenlijk probeert zeker te weten.

    Wie dat scherp krijgt, voorkomt dat compliance een doel op zich wordt en maakt keuzes die passen bij de werkelijkheid in plaats van alleen bij de formulering van de vraag.

    Verder lezen

    Wil je dit onderwerp verder verdiepen?

  • SOC 2, ISO 27001 of ISAE 3402: wat vraagt je klant nu eigenlijk van je?

    SOC 2, ISO 27001 of ISAE 3402: wat vraagt je klant nu eigenlijk van je?

    Steeds vaker krijgen organisaties vragen van klanten over security, audits of compliance. Soms heel concreet, bijvoorbeeld:

    “Hebben jullie ISO 27001?”
    “Kunnen jullie een SOC 2 rapport delen?”
    “Hebben jullie een ISAE 3402 verklaring?”

    Voor veel organisaties voelt zo’n vraag als het begin van een zwaar traject. Certificering, audits, rapportages. Maar voordat je zo’n traject start, is het verstandig om eerst een andere vraag te stellen:

    Wat probeert de klant eigenlijk zeker te weten?

    Want in de praktijk blijkt vaak dat de vraag en de bedoeling niet hetzelfde zijn.

    Waarom klanten steeds vaker om assurance vragen

    Organisaties worden steeds afhankelijker van software, platforms en externe dienstverleners. Data wordt gedeeld, systemen worden gekoppeld en processen worden soms zelfs volledig uitbesteed.

    Wanneer een organisatie een deel van haar bedrijfsvoering afhankelijk maakt van een leverancier, ontstaat er een logisch risico. Als die leverancier fouten maakt, onvoldoende beveiligd is of processen niet goed beheerst, kan dat direct gevolgen hebben voor de klant.

    Daarom vragen steeds meer organisaties om bewijs dat processen en beveiliging onder controle zijn.

    Die vragen gaan meestal over drie onderwerpen: informatiebeveiliging, betrouwbaarheid van processen en continuïteit van dienstverlening.

    Opvallend genoeg gaat de vraag van een klant zelden echt over een specifieke norm. In de kern gaat het meestal om iets anders:

    Kunnen we erop vertrouwen dat jullie je zaken aantoonbaar op orde hebben?

    Verschillende vormen van certificering en assurance proberen dat vertrouwen op verschillende manieren zichtbaar te maken.

    ISO 27001: certificering van een managementsysteem

    ISO 27001 is een internationaal erkende norm voor informatiebeveiliging. De norm beschrijft hoe organisaties hun beveiliging structureel organiseren via een Information Security Management System (ISMS).

    Zo’n managementsysteem omvat onder andere een risicoanalyse, gekozen beveiligingsmaatregelen, beleid en procedures, monitoring en continue verbetering.

    Tijdens een certificeringstraject toetsen auditors of deze structuur daadwerkelijk functioneert. Zij kijken bijvoorbeeld naar de manier waarop risico’s worden geïdentificeerd, hoe maatregelen worden gekozen en beheerd, hoe incidenten worden opgevolgd en hoe verbeteringen worden doorgevoerd.

    Een risicoanalyse vormt daarbij een belangrijke basis voor het bepalen van passende beveiligingsmaatregelen.

    Het resultaat van een ISO 27001 traject is een certificaat, met jaarlijkse audits om te controleren of het managementsysteem blijft functioneren.

    ISO 27001 laat daarmee zien dat een organisatie informatiebeveiliging niet incidenteel regelt, maar structureel organiseert.

    Wie meer wil weten over hoe zo’n managementsysteem werkt, kan ook lezen: Wat is een ISMS en waarom is het belangrijk voor jouw bedrijf.

    SOC 2: assurance over interne controles

    SOC 2 is een assurance-raamwerk dat veel wordt gebruikt door technologiebedrijven en dienstverleners, vooral wanneer zij internationale klanten bedienen.

    In tegenstelling tot ISO 27001 is SOC 2 geen certificering, maar een auditrapport dat wordt opgesteld door een onafhankelijke auditor.

    De beoordeling is gebaseerd op de Trust Services Criteria, waaronder security, beschikbaarheid, vertrouwelijkheid, privacy en processing integrity.

    Tijdens een SOC 2 onderzoek beoordeelt een auditor of de interne controles van een organisatie passend zijn ingericht en of zij daadwerkelijk functioneren.

    Er bestaan twee varianten.

    SOC 2 Type I

    Beoordeelt of de controles op een bepaald moment goed zijn ingericht.

    SOC 2 Type II

    Beoordeelt ook of deze controles daadwerkelijk hebben gewerkt over een langere periode, meestal zes tot twaalf maanden.

    Het resultaat is een assurance-rapport dat organisaties kunnen delen met klanten en partners.

    Waar ISO 27001 een managementsysteem certificeert, rapporteert SOC 2 vooral over de opzet en werking van interne controles binnen de gekozen scope.

    ISAE 3402: assurance over uitbestede processen

    ISAE 3402 komt vooral voor bij organisaties die processen uitvoeren namens hun klanten.

    Denk bijvoorbeeld aan payroll-providers, administratieve dienstverleners of platforms die financiële processen ondersteunen.

    Het doel van een ISAE 3402 rapport is om aan te tonen dat de interne controles rond deze dienstverlening betrouwbaar functioneren.

    Dit is vooral relevant wanneer de dienstverlening invloed heeft op de financiële controleomgeving of financiële verslaggeving van de klant.

    Net als bij SOC 2 bestaan er twee varianten.

    Type I

    Een beoordeling van de opzet van het controlesysteem op een bepaald moment.

    Type II

    Een beoordeling van de werking van die controles over een langere periode.

    ISAE 3402 richt zich daarmee minder op informatiebeveiliging als geheel en meer op de betrouwbaarheid van processen die organisaties namens hun klanten uitvoeren.

    Waarom deze vragen vaak door elkaar lopen

    In de praktijk worden deze begrippen regelmatig door elkaar gebruikt.

    Een klant vraagt bijvoorbeeld om SOC 2 terwijl hij eigenlijk zekerheid wil over informatiebeveiliging. Een contract noemt ISAE 3402 terwijl het vooral over IT-security gaat. En soms vraagt een organisatie om ISO 27001 omdat dat de bekendste norm is.

    Dat gebeurt om verschillende redenen. Compliance-eisen worden vaak overgenomen uit bestaande contracten. In andere gevallen worden voorwaarden gekopieerd uit sectoren waar andere assurance-vormen gebruikelijk zijn. En soms weten klanten zelf niet precies welk type bewijs ze eigenlijk nodig hebben.

    Het gevolg is dat organisaties soms een zwaar traject starten voor een vraag die eigenlijk anders bedoeld was.

    Hoe bepaal je wat werkelijk nodig is

    De keuze tussen ISO 27001, SOC 2 of ISA 3402 hangt sterk af van de context waarin een organisatie opereert.

    ISO 27001 past goed wanneer je informatiebeveiliging structureel wilt organiseren en meerdere klanten zekerheid verwachten over security.

    SOC 2 komt vaker voor wanneer je internationale klanten bedient en klanten expliciet vragen om assurance-rapporten over interne controles.

    ISAE 3402 wordt vooral relevant wanneer je processen uitvoert die invloed hebben op de financiële controle van je klanten.

    Het doel is niet om zoveel mogelijk certificeringen of audits te verzamelen.

    Het doel is om het juiste bewijs te leveren voor de vraag die werkelijk wordt gesteld.

    Wat veel organisaties te laat ontdekken

    Veel organisaties starten een traject omdat één klant ernaar vraagt, een tender het noemt of omdat een certificering professioneel klinkt.

    Pas later blijkt dat de vraag eigenlijk anders bedoeld was, dat een lichter traject voldoende was geweest of dat de interne structuur nog niet klaar was voor zo’n audit.

    Daarom is de belangrijkste vraag vooraf niet:

    “Welke norm moeten we halen?”

    Maar:

    “Welk vertrouwen probeert de klant eigenlijk te krijgen?”

    Wanneer je dat helder hebt, kun je gerichter bepalen welke vorm van certificering of assurance daarbij past.

    Structuur vóór certificering

    Organisaties die starten met ISO-, SOC- of assurance-trajecten ontdekken vaak dat dezelfde basis nodig is.

    Risico’s moeten worden geïdentificeerd.
    Beheersmaatregelen moeten worden vastgelegd.
    Audits moeten worden uitgevoerd.
    Verbeteringen moeten worden opgevolgd.

    Wanneer die structuur ontbreekt, verandert compliance al snel in administratief werk.

    In CompliTrack komen risico’s, maatregelen, audits en verbeteracties samen in één overzichtelijke structuur. Daardoor ontstaat het inzicht dat nodig is voor certificeringen en assurance-trajecten, zonder dat organisaties hun processen onnodig hoeven te verzwaren.

    Verder lezen

    Wil je dieper ingaan op onderwerpen uit deze blog, dan zijn deze artikelen ook relevant:

  • Wanneer een auditor vertrouwen krijgt zonder checklist

    Wanneer een auditor vertrouwen krijgt zonder checklist

    Tijdens een audit komt vaak een vraag die op het eerste gezicht eenvoudig lijkt.

    “Hoe bepalen jullie eigenlijk welke risico’s prioriteit krijgen?”

    Er volgt een korte stilte. Niet omdat niemand het antwoord weet, maar omdat het lastig is om precies uit te leggen. Iedereen heeft er wel een beeld bij. De risicoanalyse wordt regelmatig besproken. Acties worden opgepakt. In de praktijk voelt het alsof er grip is.

    Maar zodra het gesprek concreet wordt, blijkt hoe veel van dat proces impliciet is.

    De ene collega kijkt vooral naar impact. Een ander let op waarschijnlijkheid. Soms speelt ervaring mee: “dit ging eerder bijna mis”. In andere gevallen weegt de druk van een klant of audit zwaarder. Het zijn allemaal begrijpelijke afwegingen, alleen staan ze nergens echt vast.

    Voor een auditor is dat een interessant moment.

    Niet omdat er per se iets fout gaat, maar omdat hier zichtbaar wordt hoe beslissingen werkelijk tot stand komen.

    Waarom dit probleem ontstaat

    In veel organisaties groeit risicobeheer geleidelijk. Er komt een overzicht van risico’s, een lijst met maatregelen en een paar afspraken over evaluatiemomenten. Dat werkt vaak prima zolang dezelfde mensen betrokken blijven.

    De context zit in gesprekken en ervaring. Iedereen weet ongeveer waarom iets als belangrijk wordt gezien. Daardoor voelt het systeem logisch, ook al is het niet volledig expliciet.

    Het probleem ontstaat pas wanneer iemand van buitenaf probeert te begrijpen hoe het werkt.

    Dan blijken keuzes moeilijk te reconstrueren. Niet omdat ze willekeurig zijn gemaakt, maar omdat het denkproces erachter nooit echt zichtbaar is geworden.

    In de blog Wat auditors feitelijk testen, ook als ze het niet zo noemen beschrijven we hoe auditors vaak minder kijken naar documenten en meer naar de vraag of een organisatie haar keuzes kan uitleggen en consistent kan onderbouwen.

    Waarom meer documentatie het probleem niet oplost

    Wanneer dit zichtbaar wordt, ontstaat vaak dezelfde reflex: meer vastleggen.

    Meer toelichting bij risico’s. Extra velden in het overzicht. Misschien een uitgebreidere risicomatrix. Dat geeft tijdelijk rust, maar verandert weinig aan het onderliggende probleem.

    Meer informatie betekent namelijk niet automatisch meer begrijpelijkheid.

    Wanneer het onderliggende besluitproces onduidelijk blijft, ontstaat er vooral meer documentatie rondom dezelfde vragen. Waarom staat dit risico hier? Waarom kreeg dit prioriteit? Waarom werd deze maatregel voldoende geacht?

    Daar komt nog iets bij. Mensen kunnen verschillende betekenissen geven aan dezelfde termen. Wat voor de één een risico is, ziet een ander pas als probleem wanneer de impact concreet wordt. In Waarom compliance software pas werkt als iedereen hetzelfde bedoelt wordt beschreven hoe zulke interpretatieverschillen ontstaan en waarom ze vaak pas zichtbaar worden wanneer iemand van buitenaf meekijkt.

    Wat auditors eigenlijk proberen te begrijpen

    Auditors kijken zelden alleen naar het bestaan van documenten of procedures. Ze proberen vooral te begrijpen hoe keuzes tot stand komen.

    Komen vergelijkbare situaties tot vergelijkbare beslissingen?
    Begrijpen mensen waarom een maatregel is gekozen?|
    Is duidelijk wie verantwoordelijk is wanneer omstandigheden veranderen?

    Wanneer die samenhang zichtbaar is, ontstaat vertrouwen. Zelfs wanneer niet elk detail perfect is vastgelegd.

    Het omgekeerde gebeurt ook. Een organisatie kan een uitgebreid risico-overzicht hebben, maar toch onzeker overkomen wanneer niemand precies kan uitleggen hoe prioriteiten ontstaan.

    Structuur als hulpmiddel voor uitlegbaarheid

    Daarom draait risicobeheer uiteindelijk minder om het aantal risico’s in een overzicht en meer om het moment waarop keuzes worden gemaakt.

    Wanneer wordt iets echt een risico?
    Wie bepaalt dat?
    Welke informatie speelt daarbij een rol?

    Zodra die momenten herkenbaar zijn, verandert de dynamiek. Beslissingen worden niet alleen genomen, maar ook herleidbaar. Niet omdat alles uitgebreid wordt gedocumenteerd, maar omdat de logica zichtbaar blijft.

    Dat raakt aan een breder vraagstuk: hoe beslissingen inzichtelijk blijven. In Waarom procesanalyse cruciaal is als je beslissingen wilt kunnen uitleggen wordt beschreven waarom juist die besluitmomenten belangrijk zijn voor governance en compliance.

    Structuur helpt hier als geheugen. Niet om elk detail vast te leggen, maar om betekenis vast te houden. Wanneer duidelijk is waarom een risico prioriteit krijgt en wie daarover beslist, verdwijnen veel interpretatieverschillen vanzelf.

    Discussies worden concreter. Evaluaties minder defensief.

    Wanneer vertrouwen ontstaat zonder checklist

    Opvallend genoeg reageren auditors vaak positief op zo’n situatie.

    Niet omdat ze een perfecte methode zien, maar omdat ze een organisatie zien die begrijpt hoe haar eigen keuzes tot stand komen. Waar beslissingen niet toevallig lijken, maar voortkomen uit een herkenbare manier van werken.

    Op dat moment wordt de checklist minder bepalend.

    De auditor hoeft minder te zoeken naar losse aanwijzingen dat het systeem werkt. De consistentie in het verhaal geeft al veel informatie.

    Reflectie

    Veel organisaties proberen vertrouwen te creëren door meer vast te leggen. Meer documenten, meer detail, meer bewijs.

    In werkelijkheid ontstaat vertrouwen vaak ergens anders.

    Bij het moment waarop iemand eenvoudig kan uitleggen waarom een risico belangrijk werd, waarom een maatregel gekozen is en wie daarvoor verantwoordelijkheid draagt.

    Niet omdat alles perfect is georganiseerd, maar omdat de logica achter beslissingen herkenbaar blijft.

    En juist daar begint de rust die auditors vaak zoeken. Niet in de checklist, maar in het verhaal dat erachter klopt.

    Verder lezen

  • Consistentie als stille auditindicator

    Consistentie als stille auditindicator

    Tijdens een auditgesprek komt vaak een ogenschijnlijk eenvoudige vraag op tafel.

    Een auditor wijst naar een risico in een overzicht en vraagt:
    “Waarom hebben jullie dit risico als acceptabel beoordeeld?”

    Het is geen strikvraag. Toch ontstaat er vaak een korte stilte. Niet omdat de beslissing verkeerd was, maar omdat niemand precies meer kan reconstrueren hoe die keuze destijds tot stand kwam.

    Iemand weet nog dat het in een overleg is besproken.
    Een ander herinnert zich dat er al een maatregel bestond.
    Misschien is er ergens een notitie of mail die de afweging bevat.

    De beslissing zelf was logisch. Maar het verhaal erachter blijkt lastiger terug te vinden.

    Waarom dit zo vaak gebeurt

    In veel organisaties worden beslissingen pragmatisch genomen. Er is context, ervaring en onderling begrip. Daardoor voelt het zelden nodig om uitgebreid vast te leggen waarom een keuze precies zo is gemaakt.

    Dat werkt zolang dezelfde mensen betrokken blijven en dezelfde context delen.

    De uitdaging ontstaat wanneer iemand van buiten meekijkt. Een auditor bijvoorbeeld, of een nieuwe collega. Dan blijkt dat veel beslissingen logisch waren op het moment zelf, maar moeilijker uit te leggen zijn zodra de oorspronkelijke context ontbreekt.

    Dat betekent niet dat de beslissing verkeerd was. Het betekent dat het denkproces erachter niet is vastgehouden.

    Wat auditors feitelijk proberen te begrijpen

    Auditors zoeken meestal niet naar perfecte documentatie of volledig uitgewerkte dossiers. In de praktijk proberen ze iets anders vast te stellen: of een organisatie consistent handelt.

    In gesprekken letten auditors bijvoorbeeld op vragen als:

    • worden vergelijkbare risico’s op een vergelijkbare manier beoordeeld
    • sluiten maatregelen logisch aan op de manier waarop risico’s worden beschreven
    • kunnen medewerkers uitleggen waarom een keuze is gemaakt

    Het gaat dus minder om losse antwoorden en meer om samenhang. Wanneer keuzes herkenbaar zijn en elkaar logisch opvolgen, ontstaat vertrouwen. Wanneer elke beslissing op zichzelf staat, wordt dat lastiger.

    Consistentie fungeert daardoor als een stille auditindicator. Niet omdat het expliciet wordt getest, maar omdat het zichtbaar wordt in vrijwel elk gesprek.

    Waarom gangbare oplossingen vaak tekortschieten

    Wanneer organisaties merken dat uitleg moeilijk wordt, ontstaat vaak een reflex om méér vast te leggen.

    Meer toelichting bij risico’s.
    Meer detail in registraties.
    Meer documenten om beslissingen te onderbouwen.

    Dat lijkt logisch, maar helpt vaak minder dan verwacht.

    Meer informatie maakt een besluit niet automatisch begrijpelijker. Zonder duidelijke structuur ontstaat juist meer ruimte voor interpretatie. Verschillende mensen leggen dezelfde situatie anders vast, waardoor het beeld minder consistent wordt.

    Het probleem is zelden een gebrek aan informatie. Het zit in het ontbreken van een herkenbaar kader waarbinnen beslissingen worden genomen.

    Structuur als drager van consistentie

    Consistentie ontstaat niet doordat organisaties altijd hetzelfde doen. Situaties verschillen en keuzes veranderen.

    Wat wel helpt, is structuur in de manier waarop keuzes worden vastgelegd en besproken.

    Wanneer duidelijk is hoe risico’s worden beoordeeld, wie verantwoordelijk is voor de afweging en hoe maatregelen worden gekoppeld aan die afweging, ontstaat vanzelf meer samenhang. Niet omdat alles strak wordt voorgeschreven, maar omdat het denkproces herkenbaar blijft.

    Die herkenbaarheid maakt het later eenvoudiger om keuzes toe te lichten. Niet alleen voor auditors, maar ook intern. Discussies worden concreter en beslissingen beter te herleiden.

    In eerdere blogs kwam dit mechanisme al terug. Zo beschrijven we in “Waarom procesanalyse cruciaal is als je beslissingen wilt kunnen uitleggen” hoe besluitvorming zichtbaar maken een voorwaarde is voor uitlegbaarheid. Ook “Waarom compliance software pas werkt als iedereen hetzelfde bedoelt” laat zien dat consistentie vooral ontstaat wanneer organisaties gedeelde betekenis vastleggen.

    Consistentie als signaal van volwassenheid

    In audits valt vaak op dat vertrouwen niet ontstaat door één perfect document of één goed antwoord. Het ontstaat doordat verschillende onderdelen van een organisatie hetzelfde verhaal vertellen.

    Een risico-overzicht dat aansluit op maatregelen.
    Beslissingen die passen bij eerdere keuzes.
    Medewerkers die vergelijkbare situaties op een vergelijkbare manier uitleggen.

    Wanneer die samenhang zichtbaar is, hoeft een auditor zelden lang door te vragen. Niet omdat alles foutloos is, maar omdat duidelijk wordt hoe de organisatie denkt en handelt.

    Dat maakt consistentie tot een stille indicator van volwassenheid.

    Reflectie

    Veel organisaties gaan ervan uit dat audits vooral draaien om controle van documenten of naleving van regels. In werkelijkheid proberen auditors vooral te begrijpen hoe een organisatie keuzes maakt.

    Consistentie speelt daarin een grotere rol dan vaak wordt gedacht.

    Niet omdat elke beslissing identiek moet zijn, maar omdat vergelijkbare situaties een herkenbare aanpak hebben. Wanneer die lijn zichtbaar blijft, wordt uitleg nauwelijks nog een probleem.

    Wie dit mechanisme beter wil begrijpen, kan ook kijken naar “Wat auditors feitelijk testen, ook als ze het niet zo noemen”, waarin uitgebreider wordt uitgelegd hoe auditors in de praktijk naar organisaties kijken.

    Verder lezen

  • Wat auditors feitelijk testen, ook als ze het niet zo noemen

    Wat auditors feitelijk testen, ook als ze het niet zo noemen

    Een audit begint zelden met spanning.

    Meestal begint het vrij praktisch.

    Een auditor stelt een paar vragen.
    Hoe registreren jullie incidenten?
    Wie beslist wanneer een risico acceptabel is?
    Hoe worden verbeterpunten opgevolgd?

    De eerste antwoorden zijn vaak duidelijk. Er is een document, een overzicht of een procedure. Alles lijkt logisch.

    Maar dan komt vaak een tweede vraag.

    “Kun je laten zien hoe dat in de praktijk werkt?”

    Op dat moment verandert het gesprek. Niet omdat er iets mis is, maar omdat zichtbaar wordt hoe het dagelijks werk zich verhoudt tot wat er is vastgelegd. Wat eerst vanzelfsprekend leek, moet ineens worden uitgelegd.

    Daar begint de echte audit.

    De herkenbare spanning rond audits

    Voor veel organisaties voelt een audit als controle. Alsof iemand komt toetsen of alles klopt. Daardoor verschuift de aandacht snel naar bewijs: documenten, registraties en rapportages.

    Dat is begrijpelijk. Wanneer een auditor vraagt naar risico’s of incidenten, wil je laten zien dat het onderwerp serieus wordt genomen.

    Toch blijkt in de praktijk dat auditors zelden alleen geïnteresseerd zijn in documenten. Ze proberen iets anders te begrijpen: hoe beslissingen tot stand komen.

    Niet of er een lijst met risico’s bestaat, maar hoe die lijst wordt gebruikt.
    Niet of incidenten worden geregistreerd, maar wat er daarna gebeurt.

    In veel organisaties zit precies daar de spanning.

    Waarom dit probleem ontstaat

    In veel organisaties zijn processen grotendeels impliciet georganiseerd. Mensen weten hoe het werk loopt. Rollen zijn duidelijk omdat teams klein zijn en iedereen elkaar kent. Beslissingen ontstaan in gesprekken en worden snel opgepakt.

    Dat werkt vaak prima.

    Totdat iemand van buiten meekijkt.

    Een auditor kijkt namelijk zonder de context van het dagelijks werk. Wat voor het team logisch voelt, moet ineens worden toegelicht. Waarom een risico prioriteit kreeg. Waarom een maatregel voldoende werd gevonden. Waarom een incident geen vervolg kreeg.

    Op dat moment wordt zichtbaar hoeveel kennis nooit expliciet hoefde te worden gemaakt.

    Niet omdat het werk onzorgvuldig is gedaan, maar omdat de logica altijd vanzelfsprekend was.

    De reflex van meer documentatie

    Wanneer organisaties zich voorbereiden op audits, ontstaat vaak dezelfde reflex: meer vastleggen.

    Er worden extra procedures geschreven. Overzichten uitgebreid. Registraties gedetailleerder gemaakt. Het idee is eenvoudig: als auditors bewijs vragen, moet dat bewijs ergens staan.

    Maar meer documentatie betekent niet automatisch meer duidelijkheid.

    Wanneer documenten losstaan van de praktijk waarin beslissingen worden genomen, blijven ze vooral bestaan voor het moment waarop iemand ernaar vraagt. In het dagelijks werk spelen ze een veel kleinere rol.

    Auditors merken dat snel. Ze stellen dan vragen die niet over het document zelf gaan, maar over wat erachter zit.

    Wie beslist wanneer een risico wordt geaccepteerd?
    Wie bepaalt of een incident wordt opgevolgd?
    Wanneer is een maatregel werkelijk afgerond?

    Het zijn vragen over keuzes, niet over documenten.

    Wat auditors proberen te begrijpen

    In de praktijk proberen auditors vooral te beoordelen of een organisatie haar eigen werkwijze begrijpt.

    Dat wordt zichtbaar in drie signalen.

    Consistentie.
    Vergelijkbare situaties worden op vergelijkbare manier behandeld.

    Herleidbaarheid.
    Beslissingen zijn later nog te reconstrueren.

    Eigenaarschap.
    Het is duidelijk wie verantwoordelijk is voor opvolging.

    Wanneer deze drie elementen aanwezig zijn, ontstaat vertrouwen. Zelfs wanneer processen nog niet perfect zijn uitgewerkt.

    Het verschil tussen vastleggen en begrijpen

    Veel organisaties proberen audits te doorstaan door zo volledig mogelijk te zijn. Alles moet ergens staan.

    Maar volledigheid is zelden het probleem.

    Het echte probleem ontstaat wanneer iets wel geregistreerd is, maar niet meer te begrijpen.

    Een risico staat in een overzicht, maar niemand weet waarom het zo is beoordeeld.
    Een maatregel staat als afgerond, maar het effect is nooit besproken.
    Een incident is geregistreerd, maar de afweging erachter ontbreekt.

    Voor een auditor voelt dat instabiel. Niet omdat het per se fout is, maar omdat de logica achter de keuzes niet meer zichtbaar is.

    Daarom weegt uitleg vaak zwaarder dan volledigheid.

    Structuur als hulpmiddel

    Structuur betekent hier niet meer regels of extra administratie. Het betekent dat beslissingen herkenbaar blijven.

    Waarom is een risico zo beoordeeld?
    Wie besloot dat een maatregel voldoende was?
    Wanneer is bewust gekozen om iets niet te doen?

    Wanneer die vragen later nog beantwoord kunnen worden, ontstaat rust. Niet alleen voor auditors, maar ook binnen de organisatie zelf.

    Discussies worden korter. Overdrachten eenvoudiger. Prioriteiten duidelijker.

    De audit verandert daarmee van een zoektocht naar bewijs in een gesprek over hoe het werk georganiseerd is.

    Reflectie

    Een audit gaat zelden over het vinden van fouten. Het gaat over begrijpen hoe een organisatie werkt.

    Wanneer keuzes zichtbaar blijven, ontstaat vertrouwen. Niet omdat alles perfect is vastgelegd, maar omdat de logica achter beslissingen herkenbaar blijft.

    Daarmee verandert ook de rol van een audit. Het wordt een moment waarop duidelijk wordt of structuur en praktijk nog met elkaar verbonden zijn.

    En precies daar wordt zichtbaar wat auditors feitelijk testen, ook als ze het niet zo noemen.

    Verder lezen