Tag: Risicobeheer

  • 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.

  • DORA uitgelegd: wanneer raakt digitale weerbaarheid jouw organisatie?

    DORA uitgelegd: wanneer raakt digitale weerbaarheid jouw organisatie?

    Misschien ben je geen bank, verzekeraar of financiële instelling. Toch kan DORA ineens op je bord belanden.

    Niet omdat je organisatie rechtstreeks onder de verordening valt, maar omdat een klant in de financiële sector wil weten hoe jij omgaat met ICT-risico’s, incidenten, continuïteit en leveranciers. Zeker wanneer je ICT-diensten levert, SaaS aanbiedt, gevoelige informatie verwerkt of onderdeel bent van een digitale keten, kan DORA indirect heel relevant worden.

    Veel organisaties zoeken dan niet naar een juridische uitleg van Europese regelgeving. Ze willen vooral weten: moeten wij hier iets mee? En zo ja, wat moeten we praktisch kunnen aantonen?

    In deze blog leggen we uit wat DORA is, voor wie de verordening rechtstreeks geldt, wanneer je als leverancier indirect geraakt kunt worden en hoe je je organisatie voorbereidt op DORA-vragen van klanten.

    Wat is DORA in gewone taal?

    DORA staat voor de Digital Operational Resilience Act. Het is een Europese verordening die financiële organisaties verplicht om digitaal weerbaar te zijn.

    Dat gaat verder dan alleen cybersecurity. Natuurlijk speelt beveiliging een belangrijke rol, maar DORA kijkt breder. Een organisatie moet niet alleen proberen incidenten te voorkomen, maar ook kunnen aantonen dat zij verstoringen tijdig herkent, schade beperkt en herstel organiseert.

    In gewone taal draait DORA om de vraag: kan een financiële organisatie blijven functioneren als digitale processen onder druk komen te staan?

    Denk aan situaties zoals een cyberaanval, langdurige systeemuitval, een storing bij een cloudleverancier, problemen bij een softwarepartner of een incident waardoor klantdata of financiële processen geraakt worden. DORA verplicht financiële organisaties om ICT-risico’s structureel te beheersen, passende maatregelen te nemen, incidenten zorgvuldig af te handelen en afhankelijkheden van ICT-leveranciers inzichtelijk te houden.

    Belangrijk daarbij: DORA is geen algemene cybersecuritywet voor elk bedrijf. De verordening is primair gericht op de financiële sector. Omdat financiële organisaties sterk afhankelijk zijn van ICT-leveranciers, SaaS-platformen, cloudomgevingen en andere ketenpartners, werkt DORA in de praktijk wel breder door.

    Voor wie geldt DORA rechtstreeks?

    DORA geldt rechtstreeks voor veel financiële entiteiten. Denk aan banken, verzekeraars, beleggingsondernemingen, betaalinstellingen, aanbieders van cryptoactivadiensten en andere gereguleerde financiële partijen.

    Daarnaast introduceert DORA een Europees oversight framework voor ICT-dienstverleners die als kritiek voor de financiële sector worden aangemerkt. Dat betekent niet dat iedere softwareleverancier of ICT-dienstverlener automatisch onder volledig DORA-toezicht valt. Het gaat om specifieke aanbieders die als kritisch worden aangemerkt.

    Voor de meeste leveranciers en dienstverleners zal de impact vooral via klanten en contracten lopen. Als je zelf niet onder de financiële sector valt, betekent dat dus niet automatisch dat DORA irrelevant is. Zodra je levert aan financiële organisaties, kan je klant verplicht zijn om jouw rol in de keten beter te beoordelen en vast te leggen.

    Wanneer raakt DORA jouw organisatie indirect?

    Voor leveranciers zit de relevantie vaak in ketenwerking. Je klant moet aantonen dat digitale risico’s en afhankelijkheden beheerst worden. Daardoor kunnen vragen bij jou terechtkomen.

    Je levert ICT of SaaS aan een financiële klant

    Lever je software, hosting, beheer, support of andere ICT-diensten aan een bank, verzekeraar, pensioenpartij, fintech of administratieve dienstverlener in de financiële keten? Dan kan jouw dienstverlening relevant zijn voor hun digitale weerbaarheid.

    Zeker wanneer jouw dienst belangrijk is voor operationele processen, klantbediening, financiële transacties, rapportages of informatieverwerking, zal je klant willen weten hoe betrouwbaar jouw organisatie is ingericht.

    Dat kan leiden tot vragen over beveiliging, beschikbaarheid, incidentafhandeling, back-ups, herstelafspraken en onderaannemers.

    Je verwerkt of beheert gevoelige informatie

    Ook wanneer je geen kernsysteem levert, kun je relevant zijn. Bijvoorbeeld wanneer je toegang hebt tot klantdata, financiële data, gebruikersaccounts, rapportages of operationele informatie.

    Voor een financiële organisatie is het niet alleen belangrijk of een leverancier technisch kritisch is. Ook de gevoeligheid van de informatie en de mogelijke impact van een incident tellen mee.

    Ook een leverancier met een beperkte rol kan daardoor onderdeel zijn van een groter risicobeeld.

    Je klant vraagt om aantoonbaarheid

    DORA zorgt ervoor dat financiële organisaties meer aandacht moeten geven aan bewijs. Niet alleen: “we hebben beveiliging geregeld”, maar: “waar blijkt dat uit?”

    Dat werkt door naar leveranciers. Klanten kunnen vragen stellen over je ICT-risico’s, incidentproces, continuïteitsafspraken, leveranciersbeheer en opvolging van verbetermaatregelen.

    Dit zijn geen vreemde vragen. Ze passen bij een volwassen manier van kijken naar digitale weerbaarheid.

    Je bent onderdeel van een leveranciersketen

    Veel organisaties leveren niet alleen zelf een dienst, maar zijn ook afhankelijk van anderen. Denk aan cloudproviders, hostingpartijen, externe beheerders, softwarecomponenten, supportpartners of datacenters.

    Als jouw klant onder DORA valt, wil die klant niet alleen weten wat jij zelf doet. De klant wil ook begrijpen waar jij weer afhankelijk van bent. Daarmee verschuift de aandacht van losse leverancier naar ketenrisico.

    Dat vraagt niet om perfectie. Het vraagt wel dat je kunt uitleggen hoe je afhankelijkheden kent, beoordeelt en opvolgt.

    Welke onderwerpen komen bij DORA steeds terug?

    DORA kent meerdere onderdelen, maar in klantvragen zie je vaak dezelfde thema’s terugkomen. Het helpt om die praktisch te vertalen naar je eigen organisatie.

    ICT-risicomanagement

    De basisvraag is eenvoudig: welke digitale risico’s kunnen jouw dienstverlening verstoren?

    Denk aan uitval van systemen, ransomware, datalekken, ongeautoriseerde toegang, afhankelijkheid van één cloudleverancier, kwetsbaarheden in software of onvoldoende beheer van gebruikersrechten.

    Daarvoor heb je niet meteen een omvangrijk risicoprogramma nodig. Maar je moet wel kunnen laten zien dat je de belangrijkste risico’s kent, beoordeelt en koppelt aan maatregelen.

    Een risico-overzicht zonder opvolging is daarbij niet genoeg. Het gaat er juist om dat duidelijk is welke risico’s prioriteit hebben, wie eigenaar is en wat er gebeurt om ze te beperken.

    Incidentbeheer

    Incidenten zijn onvermijdelijk. De vraag is vooral hoe je ermee omgaat.

    Kun je incidenten centraal registreren? Kun je beoordelen wat de impact is? Is duidelijk wie actie moet nemen? Worden oorzaken onderzocht? En worden verbetermaatregelen vastgelegd?

    Als leverancier krijg je meestal niet dezelfde meldplicht als je financiële klant. Maar je klant kan wel van jou verwachten dat je incidenten tijdig herkent, vastlegt en informatie kunt aanleveren wanneer jouw dienstverlening impact heeft op hun processen.

    Incidentbeheer gaat dus niet alleen over oplossen. Het gaat ook over aantonen wat er is gebeurd, welke keuzes zijn gemaakt en wat je hebt geleerd.

    Continuïteit en herstel

    Digitale weerbaarheid betekent dat je nadenkt over verstoringen voordat ze plaatsvinden.

    Denk aan de beschikbaarheid van je applicatie, kritieke systemen, herstelafspraken, besluitvorming bij verstoringen en het testen van back-ups. Voor veel organisaties bestaat continuïteit vooral impliciet. Iedereen weet ongeveer wat er moet gebeuren als iets misgaat.

    Dat werkt zolang de verstoring klein blijft. Zodra de druk toeneemt, wil je niet afhankelijk zijn van geheugen en improvisatie.

    Een beknopt continuïteitsplan, duidelijke herstelafspraken en periodieke tests geven veel meer rust.

    Testen van weerbaarheid

    Een plan is pas waardevol als je weet dat het werkt.

    DORA legt bij financiële organisaties nadruk op het testen van digitale operationele weerbaarheid. Voor leveranciers betekent dit niet automatisch dat zij dezelfde zware testverplichtingen hebben. Klanten kunnen wel vragen hoe jij controleert of maatregelen effectief zijn.

    Dat kan praktisch blijven. Denk aan hersteltests, scenario-oefeningen, technische controles, periodieke evaluaties of interne audits. Het belangrijkste is dat maatregelen niet alleen beschreven zijn, maar ook aantoonbaar worden gecontroleerd.

    Leveranciersbeheer

    Leveranciersbeheer is een belangrijk onderdeel van digitale weerbaarheid. Zeker bij ICT-diensten is vrijwel niemand volledig zelfstandig.

    Gebruik je externe hosting? Draait je applicatie op een cloudplatform? Maak je gebruik van externe ontwikkelaars, supportpartijen of softwarecomponenten? Dan moet je kunnen uitleggen hoe je die afhankelijkheden beheerst.

    Dat betekent niet dat je iedere leverancier volledig moet auditen. Wel wil je weten welke leveranciers kritisch zijn, welke afspraken zijn gemaakt, welke risico’s bestaan en wanneer je opnieuw beoordeelt of de samenwerking nog passend is.

    Wat betekent dit praktisch voor jouw organisatie?

    Voor veel organisaties is de belangrijkste conclusie: begin niet bij een zwaar programma, maar bij structuur.

    Als je niet rechtstreeks onder DORA valt, hoef je meestal geen volledige DORA-implementatie op te tuigen. Wat je wél nodig hebt, is een praktische basis waarmee je klantvragen goed kunt beantwoorden.

    Die basis begint bij inzicht in je belangrijkste ICT-risico’s. Welke diensten zijn kritisch voor klanten? Welke systemen, leveranciers of toegangsrechten spelen daarin een rol? Welke maatregelen zijn genomen? Wie is verantwoordelijk voor opvolging? En kun je bij een klantvraag snel laten zien hoe dit is georganiseerd?

    Daar zit de kern.

    DORA raakt veel leveranciers niet als directe wettelijke verplichting, maar als volwassenheidsvraag vanuit de keten. Klanten willen niet alleen vertrouwen op goede bedoelingen. Ze willen kunnen zien dat risico’s, incidenten, continuïteit en leveranciers serieus worden beheerd.

    Dat hoeft niet zwaar te zijn. Maar het moet wel uitlegbaar zijn.

    Hoe verhoudt DORA zich tot ISO 27001 en NIS2?

    DORA wordt vaak in één adem genoemd met ISO 27001 en NIS2. Dat is begrijpelijk, want alle drie raken aan informatiebeveiliging, risicobeheer en continuïteit. Toch zijn het verschillende dingen.

    ISO 27001 is een internationale norm voor het opzetten en onderhouden van een managementsysteem voor informatiebeveiliging. De norm helpt je om risico’s te beoordelen, maatregelen te kiezen, interne audits uit te voeren en continu te verbeteren.

    Heb je ISO 27001 goed ingericht, dan heb je een sterke basis voor veel DORA-gerelateerde klantvragen. Je kunt dan vaak al laten zien hoe je informatiebeveiligingsrisico’s beheerst, hoe je maatregelen opvolgt en hoe je verbetering borgt.

    Maar ISO 27001 is niet hetzelfde als DORA. DORA is specifieker gericht op digitale operationele weerbaarheid in de financiële sector. Thema’s zoals incidentrapportage, testen van weerbaarheid en ICT-risico’s bij derde partijen krijgen binnen DORA een specifieke context.

    NIS2 is Europese cybersecuritywetgeving die zich richt op essentiële en belangrijke entiteiten in meerdere sectoren. De richtlijn is breder dan de financiële sector en raakt onder meer sectoren zoals energie, zorg, digitale infrastructuur, transport en bepaalde digitale diensten.

    Praktisch gezegd: ISO 27001 helpt je informatiebeveiliging structureel te organiseren. NIS2 legt cybersecurityverplichtingen op aan bepaalde sectoren. DORA kijkt specifiek naar digitale weerbaarheid in en rond de financiële sector.

    Voor leveranciers aan financiële klanten is vooral de combinatie relevant. Een klant kan vragen stellen die voortkomen uit DORA, terwijl jouw antwoord deels gebaseerd is op ISO 27001, je ISMS, je incidentproces, je continuïteitsafspraken en je leveranciersbeheer.

    Waar begin je als je DORA-vragen van klanten verwacht?

    De beste voorbereiding is niet om meteen een juridische analyse te starten. Begin met je positie in de keten.

    Maak eerst inzichtelijk welke klanten actief zijn in de financiële sector. Kijk daarna welke diensten je aan hen levert en hoe belangrijk die diensten zijn voor hun processen.

    Lever je een kritisch systeem, verwerk je gevoelige informatie of ondersteun je operationele processen? Dan zal een financiële klant sneller willen begrijpen hoe jouw dienstverlening is ingericht en hoe afhankelijkheden worden beheerst.

    Daarna breng je ICT-risico’s en afhankelijkheden in kaart. Kijk niet alleen naar je eigen software of systemen, maar ook naar hosting, cloud, support, onderaannemers, toegangsbeheer en beheerprocessen. Het doel is niet om elk denkbaar risico te beschrijven. Het doel is om de belangrijkste risico’s zichtbaar te maken en te bepalen welke maatregelen daarbij horen.

    Richt vervolgens incidentbeheer aantoonbaar in. Leg vast hoe incidenten worden gemeld, geregistreerd, beoordeeld en opgevolgd. Zorg dat duidelijk is wie verantwoordelijk is en hoe je leert van terugkerende incidenten.

    Ook continuïteit verdient aandacht. Bepaal welke diensten kritisch zijn, welke verstoringen grote impact kunnen hebben en hoe herstel georganiseerd is. Denk aan back-ups, hersteldoelen, verantwoordelijkheden, communicatie en testmomenten.

    Tot slot: voorkom dat bewijsvoering een aparte papierberg wordt. Veel organisaties schieten door zodra klanten om bewijs vragen. Er ontstaan mappen vol documenten, losse screenshots, exports, Excelbestanden en beleidsstukken. Dat lijkt volledig, maar maakt het vaak juist lastiger om snel antwoord te geven.

    Beter is een centrale structuur waarin risico’s, maatregelen, incidenten, leveranciers en verbeteracties logisch samenkomen. Dan ontstaat bewijs als onderdeel van je normale manier van werken, in plaats van als stressvolle verzameling achteraf.

    Wanneer is tooling zinvol?

    Tooling wordt zinvol wanneer je merkt dat de informatie die nodig is voor digitale weerbaarheid te verspreid raakt.

    Risico’s staan in losse Excelbestanden. Incidenten worden via e-mail opgevolgd. Leveranciersinformatie staat verspreid over mappen. Verbeteracties blijven liggen. Klantvragen kosten telkens opnieuw veel handwerk. Audits of assurancevragen zorgen voor onrust omdat bewijs achteraf bij elkaar gezocht moet worden.

    Dat zijn signalen dat structuur nodig is.

    Belangrijk is wel om tooling niet te overschatten. Een systeem maakt je niet automatisch DORA-proof. Tooling vervangt geen keuzes, geen eigenaarschap en geen goed gesprek over risico’s.

    Wat goede tooling wél doet, is helpen om informatie gestructureerd vast te leggen, op te volgen en uit te leggen. Juist voor organisaties waar compliance naast de dagelijkse operatie wordt opgepakt, is dat waardevol. Niet omdat je een zwaar enterprise-platform nodig hebt, maar omdat je voldoende structuur wilt om aantoonbaar grip te houden.

    Met CompliTrack kun je risico’s, incidenten, maatregelen, leveranciers en verbeteracties samenbrengen in één praktisch systeem. Daardoor wordt het eenvoudiger om klantvragen te beantwoorden, audits voor te bereiden en continuïteit aantoonbaar te organiseren.

    Conclusie

    DORA geldt niet voor iedere organisatie rechtstreeks. Maar wie levert aan financiële organisaties, ICT-diensten ondersteunt of onderdeel is van een digitale keten, kan wel degelijk met DORA-vragen te maken krijgen.

    De kern is niet dat je meteen een groot complianceprogramma moet starten. De kern is dat je moet kunnen uitleggen hoe je digitale risico’s, incidenten, continuïteit en leveranciers beheerst.

    Voor veel organisaties begint dat niet bij juridische complexiteit, maar bij praktische structuur. Weet wat je levert, welke risico’s daarbij horen, welke maatregelen zijn genomen en hoe je opvolging aantoonbaar maakt.

    Juist dan wordt DORA geen paniekdossier, maar een logische aanleiding om digitale weerbaarheid beter te organiseren.

    Verder lezen

    Wil je dieper ingaan op de thema’s uit deze blog? Deze artikelen sluiten goed aan:

    ISO 27001 Continuïteitsplan: Zo blijft jouw bedrijf draaien
    Over continuïteit, herstelmaatregelen en het voorbereiden van je organisatie op verstoringen.

    ISO 27001 en NIS2: Hoe risicobeheer helpt bij cyberweerbaarheid
    Over risicobeheer, incidentrespons, leveranciersrisico’s en de samenhang tussen informatiebeveiliging en compliance.

    Van incident naar verbetering: Hoe organisaties incidentbeheer optimaliseren met GRC-software
    Over het registreren, opvolgen en structureel verbeteren naar aanleiding van incidenten.

    De risicoanalyse: Een onmisbaar instrument voor elke ondernemer
    Over het praktisch in kaart brengen, beoordelen en opvolgen van risico’s zonder onnodige complexiteit.

    Ontdek hoe CompliTrack helpt bij digitale weerbaarheid

    Krijg je steeds vaker vragen over digitale weerbaarheid, continuïteit of leveranciersbeheer?

    Met CompliTrack breng je risico’s, incidenten, maatregelen en leveranciers samen in één praktisch systeem. Geen zware enterpriseoplossing, maar voldoende structuur om aantoonbaar grip te houden.

  • 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

  • Wanneer risico’s blijven liggen zonder eigenaar

    Wanneer risico’s blijven liggen zonder eigenaar

    Het begint vaak met een risico dat niemand betwist.

    Een leverancier voldoet nog niet aan alle gemaakte afspraken. Een beveiligingsmaatregel werkt in de praktijk minder goed dan op papier. Een klantvraag legt bloot dat een proces afhankelijk is van één persoon. Het risico wordt herkend, besproken en genoteerd. Iedereen begrijpt dat er iets mee moet gebeuren.

    En toch blijft het liggen.

    Niet omdat mensen het onbelangrijk vinden. Ook niet omdat het risico onbekend is. Het blijft liggen omdat nergens echt duidelijk is wie de keuze moet maken. De compliance-verantwoordelijke heeft het risico vastgelegd. IT ziet de technische kant. Degene die over prioriteit en capaciteit gaat, begrijpt de mogelijke impact. En de collega met klantcontact voelt de druk vanuit de klant.

    Iedereen ziet een deel van het probleem. Niemand is eigenaar van de afweging.

    Dat is een kwetsbaar moment in risicobeheer. Zolang een risico alleen wordt beschreven, lijkt er grip te zijn. Het staat in een overzicht, heeft een score en misschien zelfs een toelichting. Maar daarmee is nog niet bepaald wat de organisatie ermee doet.

    Wordt het risico geaccepteerd? Moet er direct capaciteit vrijgemaakt worden? Is uitstel verdedigbaar? Moet de klant iets worden verteld? Of is het risico eigenlijk groter geworden doordat er al maanden niets verandert?

    Zonder eigenaar blijven die vragen hangen.

    Waarom dit probleem ontstaat

    In organisaties waar mensen meerdere rollen combineren, lopen signaleren, beoordelen en besluiten vaak door elkaar. Dat is praktisch en meestal ook begrijpelijk. De lijnen zijn kort, veel kennis zit dicht op het werk en problemen worden vaak snel informeel opgelost.

    Maar juist daardoor ontstaat een kwetsbaarheid. Degene die een risico ziet, is niet automatisch degene die mag kiezen wat ermee gebeurt.

    Iemand kan signaleren dat een leverancier kwetsbaar is, maar niet besluiten dat het contract wordt aangepast. Iemand kan zien dat een proces afhankelijk is van één medewerker, maar niet bepalen dat er tijd wordt vrijgemaakt voor overdracht. Iemand kan een beveiligingsrisico benoemen, maar niet zelfstandig besluiten dat een klantbelofte wordt vertraagd.

    Daar ontstaat het gat tussen inzicht en eigenaarschap.

    Het overzicht laat dan wel zien dát er een risico is, maar niet waar de afweging thuishoort. Daardoor wordt uitstel makkelijk verward met acceptatie. “We pakken dit later op” klinkt dan als een besluit, terwijl het vaak vooral betekent dat niemand de knoop heeft doorgehakt.

    Waarom gangbare oplossingen tekortschieten

    De eerste reflex is vaak om het risico-overzicht verder aan te vullen. Er komt een extra kolom voor status, een toelichting, een kleurcode of een prioriteit. Dat kan nuttig zijn, maar het lost het kernprobleem niet op.

    Meer informatie maakt nog geen eigenaar.

    Een andere reflex is om alvast een maatregel te formuleren. Ook dat voelt concreet. Maar een maatregel zonder besluit blijft kwetsbaar. Wie bepaalt of deze maatregel voldoende is? Wie bewaakt of zij wordt uitgevoerd? Wie mag bepalen dat het risico voorlopig aanvaardbaar is?

    Zolang die vragen onbeantwoord blijven, ontstaat vooral schijnrust. Het risico lijkt behandeld, omdat er iets bij staat. In werkelijkheid is alleen de administratie bijgewerkt.

    Ook periodiek overleg helpt niet vanzelf. Een risico kan meerdere keren terugkomen op de agenda zonder dat er iets verandert. Dan wordt het onderwerp wel besproken, maar niet echt gekozen. Het gesprek houdt het risico levend, maar geeft het nog geen eigenaar.

    Structuur en uitlegbaarheid als denkkader

    Goede structuur begint niet bij meer velden of zwaardere procedures. Ze begint bij een eenvoudig onderscheid: wie ziet het risico, wie beoordeelt het risico en wie mag kiezen wat ermee gebeurt?

    Dat hoeft geen formeel comité te zijn. Zeker niet in organisaties waar mensen meerdere rollen combineren. Het gaat erom dat zichtbaar is waar de afweging ligt. Als een risico klantimpact heeft, moet duidelijk zijn wie die klantimpact mag accepteren. Als een risico budget vraagt, moet duidelijk zijn wie daarover beslist. Als een risico operationele gevolgen heeft, moet duidelijk zijn wie de uitvoering kan dragen.

    Uitlegbaarheid ontstaat wanneer die keuze wordt vastgehouden. Niet alleen de uitkomst, maar ook de reden. Waarom is dit risico nu acceptabel? Waarom krijgt een ander risico voorrang? Waarom wachten we met een maatregel? En wanneer kijken we opnieuw?

    Dat is geen bureaucratie. Het is organisatorisch geheugen.

    Juist dat geheugen maakt het verschil tussen een risico dat bewust wordt beheerst en een risico dat langzaam uit beeld verdwijnt. Niet omdat het onbelangrijk is geworden, maar omdat niemand meer precies weet welke afweging is gemaakt.

    Tot slot

    Risico’s blijven zelden liggen omdat niemand ze ziet. Ze blijven liggen omdat eigenaarschap onduidelijk is op het moment dat er gekozen moet worden.

    Dat maakt risicobeheer minder een kwestie van analyseren en meer een kwestie van verantwoordelijkheid organiseren. Niet zwaar, niet formeel, maar wel expliciet genoeg om verschil te maken tussen bewust uitstellen en ongemerkt laten liggen.

    Wie naar zijn eigen risico-overzicht kijkt, kan daarom beter niet alleen vragen welke risico’s hoog scoren. De scherpere vraag is: bij welke risico’s weten we eigenlijk niet wie de keuze moet maken?

    Daar begint vaak het echte inzicht.

    Verder lezen

  • Waarom kennis in hoofden een risico wordt bij groei

    Waarom kennis in hoofden een risico wordt bij groei

    Het lijkt een simpele vraag.

    Waarom hebben jullie dit risico zo beoordeeld?

    Er valt een korte stilte. Iemand herinnert zich nog globaal het gesprek waarin dit is besloten. Een ander weet dat het op dat moment logisch voelde. Maar niemand kan precies uitleggen welke afweging toen doorslaggevend was.

    Niet omdat die afweging er niet was, maar omdat die nooit expliciet is vastgelegd.

    Zolang dezelfde mensen betrokken blijven, is dat geen probleem. Maar zodra iets verandert, wordt zichtbaar hoe afhankelijk beslissingen waren van geheugen.

    Wat er verandert bij groei

    In kleine teams werkt impliciete kennis vaak prima. Mensen weten hoe dingen lopen, herkennen signalen en stemmen onderling af zonder alles vast te leggen. Dat houdt het werk snel en werkbaar.

    Groei legt de kwetsbaarheid daarvan bloot.

    Er komen nieuwe mensen bij. Rollen verschuiven. Verantwoordelijkheden worden verdeeld. Wat eerst gedeelde context was, wordt minder vanzelfsprekend. Wat eerder duidelijk was, moet ineens worden uitgelegd.

    Dat kantelpunt komt ook terug in Groei maakt impliciete afspraken onbetrouwbaar. Wat impliciet werkte, verliest zijn betrouwbaarheid zodra de context niet meer gedeeld is.

    De uitkomst van een besluit blijft meestal zichtbaar. De reden erachter raakt sneller uit beeld.

    Waar het in de praktijk misgaat

    Het probleem ontstaat zelden in één keer. Het wordt zichtbaar in situaties die op zichzelf logisch zijn.

    Een collega neemt tijdelijk werk over en merkt dat niet duidelijk is waarom iets zo is ingericht.
    Een audit vraagt hoe een keuze tot stand is gekomen, en het antwoord blijft algemeen.
    Een incident wordt geëvalueerd, maar eerdere afwegingen zijn niet meer goed te reconstrueren.

    In al die gevallen ontbreekt niet de beslissing, maar het verhaal erachter.

    Dat maakt organisaties kwetsbaar. Niet omdat er verkeerde keuzes worden gemaakt, maar omdat niet meer duidelijk is waarom ze logisch waren.

    Waarom meer vastleggen niet helpt

    De reflex is vaak om meer vast te leggen. Extra toelichting, uitgebreidere documenten, meer detail.

    Dat geeft het gevoel van grip, maar lost het probleem zelden op.

    Meer informatie betekent niet automatisch meer duidelijkheid. Zonder duidelijke structuur blijft betekenis afhankelijk van interpretatie. Wat voor de één helder is, roept bij een ander juist vragen op.

    Hetzelfde geldt voor systemen. Die kunnen helpen om informatie consistenter vast te leggen, maar zorgen er niet vanzelf voor dat iedereen dezelfde betekenis geeft aan wat er staat.

    De kern verandert daarmee niet. Informatie is beschikbaar, maar de onderliggende afweging blijft impliciet.

    Waar het risico echt zit

    Het risico zit niet in kennis die in hoofden zit. Dat is vaak juist wat organisaties wendbaar maakt.

    Het risico ontstaat wanneer die kennis nodig is buiten de context waarin ze is ontstaan.

    Wanneer iemand anders het werk overneemt en moet begrijpen waarom keuzes zo zijn gemaakt.
    Wanneer een beslissing moet worden toegelicht aan een klant of auditor.
    Wanneer wordt teruggekeken op een keuze die eerder logisch leek.

    Op dat moment blijkt of een organisatie afhankelijk is van individueel geheugen, of dat keuzes herkenbaar zijn vastgehouden.

    Daar raakt dit onderwerp direct aan risico. Niet als abstract begrip, maar als praktisch gevolg. Beslissingen die niet meer te volgen zijn, worden moeilijker te beoordelen, te herhalen en waar nodig bij te stellen.

    Structuur als geheugen

    De oplossing zit meestal niet in méér vastleggen, maar in gerichter vastleggen.

    Niet alles hoeft beschreven te worden. Maar de momenten die ertoe doen, moeten herkenbaar zijn.

    Wanneer noemen we iets een risico en wat bedoelen we daar precies mee?
    Wanneer vinden we een maatregel voldoende en waarom?
    Wanneer accepteren we een afwijking bewust?

    Dat zijn geen administratieve vragen, maar momenten waarop keuzes worden gemaakt.

    Structuur helpt om die keuzes vast te houden. Niet om alles te documenteren, maar om te voorkomen dat dezelfde discussie telkens opnieuw gevoerd moet worden.

    Zoals ook terugkomt in Waarom ‘we weten hoe het werkt’ niet overdraagbaar is: wat niet expliciet wordt gemaakt, blijft afhankelijk van degene die erbij was.

    Van impliciete kennis naar gedeelde betekenis

    Naarmate organisaties groeien, verandert de rol van kennis.

    Wat eerst impliciet kon blijven, moet explicieter worden om overdraagbaar te zijn. Niet door alles dicht te schrijven, maar door duidelijk te maken wat iets betekent en hoe keuzes tot stand komen.

    Wanneer begrippen, afwegingen en verantwoordelijkheden herkenbaar zijn, ontstaat rust. Overdrachten worden eenvoudiger. Discussies concreter.

    Ondersteuning kan daarbij helpen, maar volgt pas wanneer duidelijk is wat er eigenlijk vastgehouden moet worden. Niet als vervanging van kennis, maar als manier om te voorkomen dat betekenis onderweg vervaagt.

    Reflectie

    Kennis in hoofden is geen probleem. Het is vaak wat organisaties wendbaar maakt.

    Het wordt pas een risico wanneer die kennis nodig is zonder de context waarin ze is ontstaan.

    De relevante vraag is daarom niet wat je allemaal moet vastleggen, maar welke keuzes later nog te begrijpen moeten zijn. En of iemand die er niet bij was, die logica kan volgen.

    Wie merkt dat uitleg vaker nodig is, maar moeilijker wordt, ziet hetzelfde signaal terugkomen.

    Niet dat er te weinig kennis is, maar dat die nog niet voldoende gedeeld is om mee te groeien.

    Verder lezen

  • Scope snijden zonder gaten: zo kies je wat je wél en níet borgt

    Scope snijden zonder gaten: zo kies je wat je wél en níet borgt

    Of je werkt aan ISO 27001, ISO 9001 of je voorbereidt op nieuwe regelgeving zoals NIS2: alles begint met één fundamentele beslissing.

    De scope.

    Een te brede scope maakt compliance onnodig duur en complex. Een te smalle scope creëert blinde vlekken. De kunst is niet alles meenemen, maar bewust kiezen en die keuze bestuurlijk kunnen uitleggen.

    Compliance begint niet bij maatregelen, maar bij afbakening.

    Scope bepaalt welke risico’s je analyseert, welke processen je borgt en welke systemen onder je verantwoordelijkheid vallen. Wat buiten scope blijft, accepteer je impliciet als restrisico. Dat is een bewuste keuze, en dus ook een bestuurlijke verantwoordelijkheid.

    Hieronder vind je een praktisch besliskader in vijf stappen.

    Wat scope in de praktijk betekent

    Scope is geen technisch lijstje met systemen.

    Scope is een formele afbakening van activiteiten, processen, systemen, data, locaties en eventueel juridische entiteiten die onder je managementsysteem vallen. Die afbakening bepaalt waar je aantoonbaar grip op moet hebben.

    Alles wat je buiten scope laat, leg je bewust naast je neer. Dat is toegestaan, zolang het uitlegbaar en proportioneel is.

    Stap 1: begin bij impact

    Veel organisaties starten vanuit structuur. Een afdeling. Een locatie. Alleen IT.

    Dat lijkt overzichtelijk, maar zegt niets over risico.

    Begin bij impact. Stel jezelf vier vragen:

    • Wat raakt direct klantbelang of contractuele verplichtingen?
    • Wat raakt kritische informatie?
    • Wat kan de organisatie stilleggen?
    • Wat is wettelijk verplicht?

    Scope volgt uit risico, niet uit het organogram.

    Wie deze stap overslaat, loopt het risico dat de afbakening vooral praktisch voelt, maar inhoudelijk zwak is. Voor verdieping over het werken vanuit risico’s zie ook De risicoanalyse: een onmisbaar instrument voor elke ondernemer.

    Stap 2: knip logisch en uitlegbaar

    Beperken mag. Willekeurig knippen niet.

    Een scope is logisch wanneer zij inhoudelijk samenhangend is. Denk aan één duidelijk afgebakend product, één samenhangend proces of één aparte juridische entiteit.

    Wat meestal niet werkt, is alleen IT meenemen terwijl processen organisatiebreed lopen, of één afdeling certificeren terwijl verantwoordelijkheden gedeeld zijn.

    De toets is eenvoudig: kun je de gekozen scope in één samenhangend verhaal uitleggen aan een auditor of een opdrachtgever?

    In het kader van certificering wordt die vraag expliciet gesteld. Zie ook De initiële ISO-audit: Stapsgewijze gids naar ISO-certificering.

    Stap 3: expliciteer wat je niet meeneemt

    Hier zit het echte onderscheid.

    Niet-opgenomen onderdelen horen expliciet benoemd te worden, voorzien van een korte motivatie en periodiek heroverwogen te worden.

    Niet meenemen is toegestaan. Niet onderbouwen niet.

    Door uitzonderingen vast te leggen voorkom je dat scope ongemerkt verschuift. Bovendien voorkom je dat discussies bij audits telkens opnieuw gevoerd moeten worden.

    Dit raakt direct aan bestuurlijke volwassenheid. Wie keuzes maakt, moet ze ook kunnen toelichten.

    Stap 4: werk proportioneel

    Niet elk onderdeel hoeft volledig binnen het managementsysteem te vallen.

    Soms volstaat een lichtere maatregel, zoals contractuele borging bij leveranciers of een periodieke steekproef in plaats van realtime monitoring.

    De kern is proportionaliteit. De maatregel moet in verhouding staan tot het risico. Zolang je kunt uitleggen waarom de gekozen aanpak passend is, is zij verdedigbaar.

    Stap 5: maak scope een levend besluit

    Scope is geen eenmalige actie.

    Nieuwe diensten, systeemwijzigingen, gewijzigde wetgeving of organisatorische veranderingen kunnen de oorspronkelijke afbakening onder druk zetten.

    Herijk daarom bewust. Wat je wilt voorkomen, is impliciete uitbreiding zonder formeel besluit. Dat leidt vrijwel altijd tot onduidelijkheid, oplopende kosten en discussies achteraf.

    Vier terugkerende valkuilen

    Ook bij goedbedoelde implementaties zie je vaak dezelfde fouten terug:

    • Scope kiezen op basis van gemak
    • Scope beperken om certificering sneller te halen
    • Geen periodieke herbeoordeling uitvoeren
    • Uitzonderingen niet expliciet vastleggen

    Deze fouten lijken klein, maar ondermijnen op termijn de samenhang van het hele systeem.

    Grip is kiezen

    Grip ontstaat niet door meer maatregelen, maar door scherpere afbakening.

    Wie bewust kiest, houdt kosten beheersbaar, behoudt overzicht en kan uitleggen waarom iets wél of niet is meegenomen.

    Uiteindelijk draait het om één eenvoudige vraag:

    Kun je in één alinea uitleggen waarom jouw huidige scope logisch en proportioneel is?

    Als dat niet lukt, ligt daar waarschijnlijk de grootste optimalisatie.

    Verder lezen

    Deze artikelen verdiepen respectievelijk het risicoperspectief, de auditcontext en de bestuurlijke opvolging van keuzes.

  • Wanneer vastleggen rust oplevert in plaats van extra werk

    Wanneer vastleggen rust oplevert in plaats van extra werk

    Het begint vaak klein.
    Een besluit in overleg. Iedereen begrijpt waarom dit logisch is. Er is ervaring, er is context en er is vertrouwen dat dit later nog wel duidelijk is. Vastleggen voelt op dat moment overbodig. Misschien zelfs als extra ballast.

    Tot iemand een vraag stelt die niet direct te beantwoorden is. Omdat degene die erbij was er niet is. Omdat de context is veranderd. Of omdat iemand van buiten meekijkt en vraagt waarom dit zo is ingericht. Dan blijkt dat het antwoord vooral in hoofden zit. En dat niet iedereen hetzelfde verhaal vertelt.

    Niet omdat er iets fout ging, maar omdat het nooit expliciet is gemaakt.

    Waarom dit probleem zo vaak ontstaat

    In organisaties waar veel tegelijk gebeurt, wordt veel geregeld op basis van impliciete afspraken. Mensen combineren rollen, kennen elkaars werk en stemmen voortdurend informeel af. Dat werkt efficiënt zolang dezelfde mensen betrokken zijn en context gedeeld wordt.

    Het wordt kwetsbaar zodra die context niet meer vanzelfsprekend is. Wanneer verantwoordelijkheden verschuiven, iemand tijdelijk wegvalt of besluiten later moeten worden uitgelegd. Dan blijkt hoeveel kennis nooit is vastgelegd, simpelweg omdat dat op het moment zelf niet nodig leek.

    Het probleem zit zelden in onduidelijkheid op het moment van beslissen. Het probleem ontstaat pas later, wanneer dat besluit losraakt van de situatie waarin het is genomen.

    Waarom gangbare oplossingen tekortschieten

    Als dit zichtbaar wordt, volgt vaak een herkenbare reflex. Meer documentatie. Extra overzichten. Strakkere afspraken over wie wat bijhoudt. Dat lijkt logisch, maar pakt het kernprobleem zelden aan.

    Het gaat meestal niet om een gebrek aan informatie. Het gaat om een gebrek aan betekenis. Vastleggen wat is besloten zonder vast te leggen waarom, zorgt ervoor dat dezelfde discussie later opnieuw gevoerd moet worden. Niet omdat mensen niet opletten, maar omdat het besluit zijn context heeft verloren.

    Ook het verzamelen van losse documenten helpt niet. Ze registreren dat er iets is gebeurd, maar maken geen samenhang zichtbaar. Ze worden archief, geen geheugen.

    Structuur en uitlegbaarheid als denkkader

    Structuur wordt vaak gezien als synoniem voor bureaucratie. Extra stappen, extra formulieren, extra controle. In de praktijk gaat structuur juist over het wegnemen van ruis.

    Structuur betekent dat beslissingen herleidbaar blijven. Dat zichtbaar is welke afweging is gemaakt en door wie. Niet om alles te verwoorden, maar om te voorkomen dat betekenis verdwijnt zodra de aandacht verschuift.

    Uitlegbaarheid ontstaat niet achteraf. Wie pas bij een evaluatie, audit of incident probeert te reconstrueren waarom iets zo is ingericht, is eigenlijk al te laat. Dan blijkt dat keuzes wel zijn gemaakt, maar niet zijn vastgehouden.

    Wanneer vastleggen daadwerkelijk rust geeft

    Vastleggen wordt vaak gezien als extra werk, terwijl het in de praktijk juist werk kan wegnemen. Wanneer afspraken expliciet zijn vastgelegd, hoeven ze niet steeds opnieuw te worden uitgelegd. Interpretatieverschillen nemen af. Gesprekken worden concreter, omdat duidelijker is wat het vertrekpunt is.

    Dat betekent niet dat alles dichtgetimmerd moet worden. Het betekent dat de kern zichtbaar blijft. Mensen kunnen daarop voortbouwen, in plaats van steeds opnieuw context te moeten ophalen. Op dat moment krijgt vastleggen een andere functie: het ondersteunt het geheugen van de organisatie, in plaats van dat het alleen administratie toevoegt.

    Tooling als logisch gevolg, niet als startpunt

    Wanneer dit besef ontstaat, komt vaak ook de vraag op hoe je dit praktisch organiseert. Niet omdat een systeem het probleem oplost, maar omdat consistentie niet langer afhankelijk mag zijn van individueel geheugen.

    Tooling is op dat punt geen oplossing, maar een gevolg. Zonder helder denkkader legt een systeem vooral vast dat er iets is, niet wat het betekent. Dan verplaatst het probleem zich, zonder dat het verdwijnt.

    Pas wanneer duidelijk is welke structuur nodig is om uitlegbaar te blijven, kan ondersteuning echt bijdragen aan rust en overzicht.

    Reflectie

    Vastleggen hoeft geen extra laag te zijn bovenop het werk. Het kan onderdeel worden van hoe rust ontstaat. Niet door alles vast te leggen, maar door de juiste afspraken expliciet te maken.

    De vraag is niet of je meer moet vastleggen. De vraag is welke afspraken zo belangrijk zijn dat ze niet afhankelijk mogen zijn van geheugen of toeval.

    Wie die vraag serieus neemt, merkt vaak dat vastleggen minder werk kost dan steeds opnieuw uitleggen. En dat daar ruimte ontstaat. Niet doordat alles vastligt, maar doordat duidelijk is wat telt.

    Verder lezen

  • Wanneer je risico’s buiten je organisatie beginnen: leveranciersbeheer als basis voor grip

    Wanneer je risico’s buiten je organisatie beginnen: leveranciersbeheer als basis voor grip

    Veel organisaties hebben hun interne zaken redelijk op orde. Rollen zijn verdeeld, verantwoordelijkheden benoemd en risico’s besproken. Er is nagedacht over wat er binnen de organisatie kan misgaan en hoe daarop wordt gestuurd. Tot het moment dat er iets gebeurt bij een leverancier. Dan wordt zichtbaar hoe relatief die interne grip eigenlijk is.

    Steeds vaker ontstaan de grootste risico’s niet binnen de eigen organisatie, maar daarbuiten. Bij partijen waar dagelijks op wordt vertrouwd, maar waar zelden structureel bij wordt stilgestaan. Leveranciersbeheer is daarmee geen administratief onderwerp meer, maar een essentieel onderdeel van goed bestuur en beheersing.

    De verschuiving van risico’s naar buiten

    De afgelopen jaren is het werk van organisaties fundamenteel veranderd. Taken worden uitbesteed, systemen draaien extern en specialistische kennis ligt steeds vaker bij derden. Dat is geen bewuste strategie om risico’s te verplaatsen, maar een logisch gevolg van schaal, digitalisering en specialisatie.

    IT wordt geleverd als dienst. Applicaties draaien in de cloud. Externe partijen beheren data, ondersteunen klantprocessen of leveren cruciale functionaliteiten waarop de organisatie zelf nauwelijks nog invloed heeft. Tegelijkertijd blijft de verwachting bestaan dat dienstverlening beschikbaar, betrouwbaar en uitlegbaar blijft.

    Die afhankelijkheden ontstaan meestal geleidelijk. Ze worden zelden expliciet ontworpen, maar groeien mee met keuzes die op zichzelf logisch zijn. Een leverancier die ooit ondersteunend was, wordt ongemerkt kritisch. Een tijdelijke oplossing wordt structureel. En een externe partij wordt de enige die een bepaald proces echt begrijpt.

    Zolang alles werkt, voelt dat comfortabel. Er is weinig aanleiding om vragen te stellen. Pas wanneer een klant zekerheid vraagt, een incident zich voordoet of een audit scherper doorvraagt, blijkt hoe weinig overzicht er eigenlijk is op al die afhankelijkheden.

    Leverancierbeheer als governancevraagstuk

    Leveranciersbeheer wordt vaak gezien als iets operationeels. Contracten, afspraken, prestaties en evaluaties. In de kern gaat het echter over vertrouwen en verantwoordelijkheid.

    De relevante vraag is niet of een leverancier “goed” presteert, maar of je kunt uitleggen waarom deze partij wordt vertrouwd. En of helder is welke risico’s daarbij horen. Keuzes die buiten de organisatie worden gemaakt, hebben vaak directe impact op betrouwbaarheid, continuïteit en reputatie. De verantwoordelijkheid daarvoor blijft intern liggen.

    Zonder structureel leveranciersbeheer ontbreekt dat overzicht. Dan worden keuzes wel gemaakt, maar zijn ze achteraf moeilijk te verklaren. Niet omdat ze per se verkeerd waren, maar omdat niemand expliciet heeft vastgelegd waarom ze logisch leken op dat moment.

    De valkuil van eenmalig beoordelen

    In veel organisaties bestaat leveranciersbeoordeling wel degelijk. Vaak bij aanvang van de samenwerking of bij contractverlenging. De beoordeling wordt vastgelegd, besproken en daarna opgeborgen.

    Het probleem zit niet in het beoordelen zelf, maar in het idee dat één moment voldoende is. Risico’s veranderen. Leveranciers breiden hun dienstverlening uit, nemen andere partijen in de keten op, of wijzigen hun manier van werken. Tegelijkertijd verandert ook de organisatie zelf, waardoor afhankelijkheden verschuiven.

    Een beoordeling die geen vervolg kent, geeft vooral een gevoel van zekerheid. Op papier is alles geregeld, maar niemand kan aangeven of aannames nog kloppen. Wanneer niet zichtbaar is hoe actueel een beoordeling is, ontstaat schijncontrole. Er is documentatie, maar weinig grip.

    Niet elke leverancier is even kritisch

    Een veelgemaakte fout is dat alle leveranciers gelijk worden behandeld. Dat leidt tot twee ongewenste effecten. Ofwel er ontstaat onnodige administratieve last voor partijen die weinig risico vormen. Ofwel de aandacht voor echt kritische leveranciers verwatert.

    Effectief leveranciersbeheer begint bij onderscheid maken. Welke leveranciers raken kernprocessen? Welke hebben toegang tot gevoelige informatie? Welke zijn lastig te vervangen zonder directe impact op dienstverlening?

    Zodra dat onderscheid helder is, verschuift het gesprek. Dan gaat het minder over formulieren en meer over afhankelijkheid en impact. Dat gesprek is soms ongemakkelijker, maar ook veel waardevoller dan een uniforme beoordeling die niets zegt over prioriteit.

    Waarom eenvoud beter werkt dan perfectie

    Er bestaat een hardnekkig idee dat leveranciersbeheer complex moet zijn om serieus genomen te worden. Dat leidt tot uitgebreide modellen, uitgebreide vragenlijsten en theoretisch perfecte beoordelingskaders die in de praktijk nauwelijks worden gebruikt.

    Wat daadwerkelijk werkt, is eenvoud en herhaalbaarheid. Dat dezelfde vragen periodiek worden gesteld. Dat keuzes worden vastgelegd, ook als ze niet ideaal zijn. En dat zichtbaar is wanneer een beoordeling is gedaan en wanneer niet.

    Een eenvoudige structuur die consequent wordt gebruikt, levert meer grip op dan een perfect model dat alleen tijdens audits wordt geraadpleegd. Juist in organisaties waar compliance geen aparte discipline is, maar onderdeel van het dagelijkse werk, is dat verschil bepalend.

    Van individuele leverancier naar ketenbewustzijn

    Wie leveranciersbeheer structureel oppakt, merkt al snel dat het onderwerp breder wordt. Het gaat niet alleen meer over afzonderlijke partijen, maar over de keten als geheel.

    Leveranciers zijn zelf ook afhankelijk van andere partijen. Meerdere leveranciers kunnen dezelfde onderliggende dienst gebruiken. Een verstoring op één plek kan daardoor onverwacht veel impact hebben. Dat maakt risico’s cumulatief in plaats van geïsoleerd.

    Ketenbewustzijn betekent dat deze samenhang zichtbaar wordt. Niet door alles te analyseren, maar door te begrijpen waar afhankelijkheden elkaar raken. Dat vraagt geen ingewikkelde modellen, maar wel aandacht en periodieke reflectie op de vraag waar kwetsbaarheden samenkomen.

    Vertrouwen vraagt onderbouwing

    Leveranciersbeheer draait uiteindelijk om vertrouwen. Niet het naïeve vertrouwen dat alles wel goed geregeld is, maar het onderbouwde vertrouwen dat gebaseerd is op inzicht en bewuste keuzes.

    Organisaties die dit op orde hebben, hoeven minder uit te leggen wanneer er iets misgaat. Ze weten waar hun kwetsbaarheden zitten en kunnen laten zien waarom bepaalde keuzes zijn gemaakt. Dat maakt het verschil tussen reactief handelen en regie houden.

    Juist daarom past leveranciersbeheer binnen compliance. Niet als verplicht nummer, maar als manier om grip te houden op wat je zelf niet volledig beheerst.

    Afronding

    Risico’s stoppen niet bij de grenzen van de eigen organisatie. Ze lopen door in de keten van leveranciers, partners en externe partijen waarop dagelijks wordt vertrouwd. Leveranciersbeheer is de manier om die risico’s zichtbaar en bespreekbaar te maken.

    Niet door alles dicht te regelen, maar door bewust om te gaan met afhankelijkheden. Organisaties die dat doen, bouwen niet alleen aan compliance, maar ook aan betrouwbaarheid.

    Verder lezen

  • Toen het misging deed iedereen z’n best maar niemand volgde het proces

    Toen het misging deed iedereen z’n best maar niemand volgde het proces

    Het begon op een dinsdagochtend die nergens bijzonder in leek. De agenda stond vol, het team was net opgestart en iedereen was bezig om de dag rustig in te glijden. De eerste melding kwam om 09:03 uur. Een klant kon niet meer inloggen. Het gebeurt vaker, dus niemand raakte direct in paniek. Vijf minuten later volgde de tweede melding. Binnen een kwartier stond de teller op drie. De lichte onrust veranderde in gespannen alertheid. Iedereen keek elkaar aan. Dit was geen toeval meer.

    In een reflex stond het hele team paraat. De een dook in systemen, een ander pakte de telefoon, een derde probeerde alvast een workaround voor de klant te regelen. Het was pure betrokkenheid. Niemand wachtte af, niemand wilde dat de klant langer in onzekerheid bleef. En toch speelde precies dat moment het zwakke punt van de organisatie bloot. Iedereen deed zijn uiterste best, maar niemand volgde het incidentproces.

    Wanneer betrokkenheid de structuur verdringt

    Naarmate de minuten verstreken, groeide de druk. De meldingen bleven binnenkomen, vragen stapelden zich op en klanten wilden weten wat er aan de hand was. Het overzicht verdween razendsnel. Wat bedoeld was als een gecoördineerde aanpak, veranderde in parallelle pogingen om het probleem op te lossen. Er werd gemaild, geappt en tegelijk in meerdere systemen gezocht. Een collega noteerde iets in een privé notitieboek, een ander in een Excel-bestand, een derde in een chatsysteem.

    Het was geen chaos door gebrek aan kunde. Het was chaos omdat niemand dezelfde eerste stap nam. Dat is precies wat er gebeurt wanneer een proces wél bestaat, maar niet leeft. Een document kan netjes zijn opgesteld, maar als het geen onderdeel is van het dagelijkse werk, verdwijnt het op het moment dat de druk het hoogst is.

    Later die dag, toen de storing onder controle was en de adrenaline gedaald, was er ruimte voor reflectie. De vraag die terugkwam was simpel. Hoe kan het dat we een incidentproces hebben, en toch volledig terugvallen op improvisatie zodra het spannend wordt.

    De eerlijkste conclusie was ook de meest confronterende. Het proces was geen routine. Het was informatie. Geen gedrag.

    Een proces op papier is nog geen proces in de praktijk

    In veel organisaties blijft een incidentproces hangen in theoretische bekendheid. Mensen hebben het ooit gezien, weten dat het er is, maar hebben het nooit echt hoeven toepassen. En als het dan zover is, grijpen ze naar wat het meest natuurlijk voelt: direct handelen. Dat is begrijpelijk, maar ook gevaarlijk.

    Een proces werkt alleen als medewerkers het herkennen als houvast, niet als verplichting. Het moet intuïtief zijn. Het moet een routine worden. En routines ontstaan niet door een presentatie, een folder of een pagina in het handboek. Ze ontstaat doordat je een proces regelmatig toepast, bespreekt, herhaalt en controleert. Pas dan beklijft het.

    Het team besefte achteraf dat niemand nog precies wist waar het proces stond, laat staan hoe het begon. Sommigen dachten dat de storing zo uitzonderlijk was dat het proces waarschijnlijk niet volledig zou passen. Anderen begonnen uit gewoonte aan hun favoriete oplossingsrichting. Iedereen handelde met de beste intenties, maar het ontbrak aan een gedeeld startpunt. Dat is een van de meest voorkomende oorzaken van falend incidentbeheer: het proces voelt niet logisch of dichtbij genoeg.

    Onze eerdere blogs over continuïteit en ISMS laten hetzelfde zien. Een procedure die niet is ingeslepen, blijft niet overeind wanneer de druk toeneemt. Onder stress volgt iedereen zijn eigen instinct. Daarom moet een proces dat je in crisistijd wilt gebruiken, vooral heel simpel zijn.

    Waarom incidentprocessen zo vaak instorten onder druk

    Incidentbeheer heeft twee natuurlijke tegenpolen. Aan de ene kant wil een organisatie snel handelen. Aan de andere kant wil ze gestructureerd werken. Wanneer de druk toeneemt, wint snelheid het bijna altijd van structuur. Zeker in kleinere teams, waar iedereen meerdere rollen heeft en niemand fulltime met compliance bezig is.

    Dat leidt tot herkenbare patronen. Stappen worden overgeslagen omdat ze “later wel” worden ingevuld. Incidentregistratie gebeurt achteraf, selectief of versnipperd. Wat in e-mails staat, staat niet in het registratiesysteem. Wat in persoonlijke notities staat, bereikt het team niet. Bewijslast ontbreekt. Analyse wordt moeilijk. En tijdens een audit blijkt dat de opvolging niet aantoonbaar is, ook al heeft iedereen heel hard gewerkt.

    Dit patroon zagen we eerder ook in onze blog over risico’s, incidenten en audits. Een proces dat niet verbonden is met het dagelijks werk, kan ook niet functioneren als het erop aankomt. Het verschil tussen theoretische naleving en praktische beheersing komt altijd bovendrijven op momenten waarop je het het minst kunt gebruiken.

    Hoe we het proces weer klein en logisch maakten

    Het inzicht was helder. Het proces was niet te ingewikkeld op papier, maar voelde wel ingewikkeld op het moment zelf. Dat moest anders. Daarom besloten we het proces terug te brengen naar drie basisvragen die iedereen, ongeacht rol of ervaring, direct moet kunnen beantwoorden.

    • Wat is er precies gebeurd?
    • Wat is de impact op klant en operatie?
    • Wie pakt de eerste actie op?

    Door het proces te versimpelen, werd het niet minder compleet. Het werd toegankelijk. Herkenbaar. Toepasbaar in stresssituaties. Het gaf medewerkers duidelijkheid in plaats van keuzestress. En dat zorgde voor een interessant effect.

    Het proces werd vaker gevolgd omdat het eenvoudiger werd. Incidenten werden vaker geregistreerd omdat de drempel lager werd. Niet alleen grote, maar ook kleine afwijkingen kwamen boven water. Die signalen zijn goud waard. Kleine incidenten laten zien waar routines afwijken, waar communicatie schuurt of waar processen onnodig kwetsbaar zijn. Dat is precies het niveau waarop organisaties leren en verbeteren.

    Incidenten oplossen is niet hetzelfde als incidenten beheersen

    In de evaluatie ontdekten we dat we incidenten goed konden oplossen, maar onvoldoende beheersten. Oplossen gebeurt in de operatie. Beheersen gebeurt in het proces. Het eerste draait om actie, het tweede om structuur, analyse en verbetering.

    Wanneer incidenten niet worden beheerst, ontstaan steeds dezelfde patronen. Werk verdwijnt in mailboxen. Gegevens worden niet eenduidig geregistreerd. Incidenten worden als losse gebeurtenissen gezien, niet als onderdeel van een trend. Het gevolg is dat de organisatie stabiliteit mist. En tijdens audits ontstaat onzekerheid, omdat er geen helder verhaal is over wat er is gebeurd en wat ermee is gedaan.

    Een audit later dat jaar maakte dat pijnlijk duidelijk. De auditor vroeg niet alleen naar incidentregisters, maar vooral naar de manier waarop we opvolging borgden. Welke informatie vastgelegd werd op het moment zelf. Hoe het team wist wie de eerste stap moest zetten. En hoe we zeker wisten dat niets tussen wal en schip viel. Het nieuwe, eenvoudige proces gaf ineens een helder antwoord. Het was aantoonbaar. Begrijpelijk. Praktisch.

    De vraag die elk team zichzelf zou moeten stellen

    Wat doen wij als eerste wanneer er morgen een incident is?

    Dat is de vraag die je team in één zin moet kunnen beantwoorden. Als de antwoorden uiteenlopen, leeft het proces niet. Als iedereen dezelfde startstap kent, staat het fundament. Incidentbeheer begint niet bij tooling of procedures, maar bij gedrag. Bij mensen die weten waar de eerste stap ligt. En pas daarna bij het systeem dat die stap ondersteunt, documenteert en opvolging afdwingt.

    Goede incidentbeheersing is geen hogere wiskunde. Het is voorspelbaar samenwerken. Het is helderheid creëren op het moment dat alles onduidelijk lijkt. Het is het verschil tussen paniek en overzicht. En vooral: het geeft klanten vertrouwen dat je organisatie grip heeft op wat er gebeurt, ook wanneer er iets misgaat.

    Een proces is pas waardevol wanneer het in de praktijk werkt. Niet wanneer het op papier perfect staat, maar wanneer het team het instinctief volgt. Dat is de stap van document naar gewoonte. Van papier naar gedrag. Van losse incidenten naar structurele verbetering.

    Verder lezen

    Deze blogs sluiten goed aan op het thema van incidentgedrag, opvolging en aantoonbaarheid:

  • Ketenrisico’s in kleine organisaties: waarom het verder gaat dan leveranciersbeheer

    Ketenrisico’s in kleine organisaties: waarom het verder gaat dan leveranciersbeheer

    Veel organisaties richten hun aandacht vooral op de leveranciers waar zij formele afspraken mee hebben. Er zijn contracten, SLA’s en terugkerende evaluaties die moeten aantonen dat alles onder controle is. Toch ontstaan de grootste verstoringen zelden bij deze partijen. Problemen komen juist van een heel andere hoek: de externe ontwikkelaar die een cruciale module onderhoudt, het bureau dat klantgegevens bewaart zonder dat dit expliciet is afgesproken of de partner die wijzigingen doorvoert zonder vooraf overleg.

    Dit zijn geen uitzonderlijke situaties. Ze laten zien dat ketenrisico’s veel verder reiken dan traditionele leveranciersrelaties. Ze raken aan kennis, toegang, continuïteit en zelfs cultuur. En juist omdat deze risico’s buiten de formele processen vallen, blijven ze vaak onzichtbaar tot het misgaat.

    In eerdere blogs hebben we al verkend hoe je leveranciers beoordeelt en risico’s beheerst. In deze blog kijken we verder. Wat gebeurt er wanneer je de hele keten in beeld brengt, en hoe krijg je daar grip op zonder het zwaar te maken.

    1. De keten is groter dan je leverancierslijst

    Wanneer mensen over ketenbeheer praten, denken ze vaak aan leveranciers waar facturen vandaan komen. De praktijk is anders. Veel organisaties werken met tijdelijke experts, nichepartners en freelancers die onderdeel zijn van de dienstverlening, maar niet worden gezien als formele leverancier.

    Denk aan een externe ontwikkelaar die toegang heeft tot productiedata. Een adviseur die inlogt op interne omgevingen. Of een creatief bureau dat klantinformatie ontvangt om een campagne te bouwen. Hoewel deze partijen een directe rol spelen in processen, staan ze meestal niet in een risicomatrix of leveranciersregister.

    Dat maakt de keten kwetsbaar. Wanneer een externe specialist uitvalt, vertrek aankondigt of simpelweg tijdelijk niet beschikbaar is, kan een proces volledig stilvallen. Niet omdat het systeem faalt, maar omdat er afhankelijkheden bestaan die nooit zijn vastgelegd.

    2. Afhankelijkheden moeten eerst zichtbaar zijn

    Ketenrisico’s kun je pas beoordelen wanneer je weet wie invloed heeft op je processen. Dat vraagt niet om uitgebreide documentatie, maar om een helder beeld van de externe partijen die in jouw organisatie meedraaien.

    Een goede inventarisatie begint bij drie eenvoudige vragen:

    • Welke externe partijen raken processen, systemen of informatie.
    • Wat gebeurt er wanneer hun werk wegvalt.
    • Welke afspraken bestaan er al en welke worden alleen in de praktijk gemaakt.

    Zodra je deze vragen beantwoordt, ontstaat er een duidelijk beeld van waar de echte kwetsbaarheden zitten. Je ziet welke werkzaamheden door één persoon worden uitgevoerd, waar kennis niet is gedeeld en welke processen afhankelijk zijn van informele afspraken. Dat inzicht maakt het mogelijk om risico’s te beheersen voordat ze zich voordoen.

    3. Risico’s in de keten zijn vaak menselijk

    Veel ketenrisico’s ontstaan niet door techniek, maar door gedrag. Een externe specialist die meerdere projecten combineert, een partner die wijzigingen doorvoert zonder melding of een dienstverlener die blijft vertrouwen op verouderde middelen. Het zijn kleine beslissingen die grote gevolgen kunnen hebben.

    In een eerdere blog beschreven we hoe gedrag bepalend is voor de effectiviteit van compliance. Dat geldt ook in de keten. Contracten zijn belangrijk, maar ze bepalen niet of iemand zorgvuldig werkt, kennis overdraagt of wijzigingen actief communiceert. Dat hangt af van gewoonten, verwachtingen en samenwerking.

    Daarom is het bij ketenrisico’s belangrijk om niet uitsluitend naar afspraken te kijken, maar ook naar de manier waarop externen hun werk uitvoeren. Hoeveel kennis ligt bij één persoon. Is het werk goed gedocumenteerd. Kan iemand anders het proces overnemen. Deze vragen bepalen hoe robuust de keten in werkelijkheid is.

    4. Een eenvoudige risicoanalyse voor je keten

    Grip krijgen op ketenrisico’s hoeft niet complex te zijn. Een lichte risicoanalyse kan al voldoende inzicht geven om structurele risico’s te verkleinen. Daarbij helpt het om vijf elementen te beoordelen:

    1. Externe partijen
      Breng alle partijen in kaart die invloed hebben op jouw processen, systemen of informatie.
    2. Geraakte onderdelen
      Noteer welke activiteiten of applicaties afhankelijk zijn van deze partijen.
    3. Impact bij uitval
      Onderzoek wat er stagneert wanneer een externe partij tijdelijk wegvalt.
    4. Toegang en beveiliging
      Bepaal welke accounts, systemen en data toegankelijk zijn voor deze partij.
    5. Vervangbaarheid
      Bekijk hoe snel iemand anders het werk kan overnemen.

    Dit overzicht geeft een realistisch beeld van waar de keten kwetsbaar is. De kracht zit in eenvoud: hoe duidelijker het beeld, hoe gemakkelijker het wordt om maatregelen te nemen zonder een zware beheersstructuur op te tuigen.

    5. Toegang door externen: het meest onderschatte risico

    Wanneer externe partijen toegang hebben tot systemen of data, ontstaat een risico dat vaak pas wordt opgemerkt wanneer iets misgaat. Accounts blijven bestaan nadat een project is afgerond. Toegang wordt niet herzien wanneer rollen veranderen. Of een partij werkt met gedeelde wachtwoorden omdat dat in de praktijk eenvoudiger is.

    Dit is geen technisch probleem, maar een organisatorische keuze. Wie toegang heeft, bepaalt in grote mate de beveiliging van je keten. In eerdere blogs over informatiebeveiliging beschreven we hoe derde partijen expliciet risico’s introduceren, vooral wanneer zij toegang hebben tot gevoelige informatie of kritische systemen.

    Daarom is het belangrijk om te weten welke toegang externen hebben, waarom zij die toegang nodig hebben en hoe lang die toegang relevant blijft. Door dit periodiek te controleren, verklein je een van de meest voorkomende kwetsbaarheden binnen de keten.

    6. NIS2 maakt ketenverantwoordelijkheid concreet

    Niet elke organisatie valt onder NIS2. Voor bedrijven die wel binnen de richtlijn vallen, geldt een duidelijke verplichting: zij moeten kunnen aantonen dat zij risico’s in de keten herkennen, beoordelen en monitoren.

    Dat betekent in de praktijk dat organisaties:

    • Externe partijen moeten opnemen in hun risicoanalyse;
    • Beveiligingsmaatregelen moeten afstemmen op de rol en toegang van deze partijen;
    • Incidenten moeten onderzoeken wanneer die impact hebben op de dienstverlening;
    • Continuïteit binnen de keten moeten borgen.

    NIS2 maakt hiermee zichtbaar wat in de praktijk allang relevant is: organisaties zijn verantwoordelijk voor de risico’s die ontstaan door partijen waarmee zij samenwerken. Voor bedrijven die niet formeel onder de richtlijn vallen, blijft dit een waardevol kader om grip te krijgen op hun keten en risico’s beheersbaar te houden.

    7. In vijf stappen naar meer grip op je keten

    Een praktisch ketenbeheerproces hoeft niet zwaar of tijdrovend te zijn. De volgende vijf stappen werken in vrijwel elke organisatie:

    1. Breng alle externe partijen in kaart, inclusief freelancers, nichepartijen en tijdelijke specialisaten.
    2. Koppel elke partij aan processen, systemen of informatie die zij raken.
    3. Bepaal wat er gebeurt wanneer een partij tijdelijk wegvalt.
    4. Controleer welke toegang externen hebben en stel vast waarom die toegang nodig is.
    5. Herhaal de beoordeling jaarlijks of wanneer een rol, project of samenwerking verandert.

    In deze stappen ontstaat structuur zonder dat het proces complex wordt. Door klein te beginnen en de beoordeling consequent te herhalen, krijgt de keten een steviger fundament.

    Conclusie

    Ketenrisico’s gaan verder dan leveranciers. Ze raken je dienstverlening, beveiliging, continuïteit en reputatie. De kwetsbaarheden zitten vaak in partijen die niet in formele processen zijn opgenomen, maar wél een directe rol spelen in jouw operatie. Door inzicht te krijgen in deze afhankelijkheden, toegang van externen te beheersen en risico’s periodiek te beoordelen, bouw je een keten die minder gevoelig is voor verstoringen.

    Het gaat er niet om elke situatie volledig te beheersen. Het belangrijkste is dat je weet waar de risico’s zitten en dat je deze stap voor stap verkleint. Daarmee ontstaat een keten die wendbaar, transparant en beter voorbereid is op de toekomst.

    Verder lezen

    Effectieve leveranciersbeoordeling met CompliTrack
    Hoe je leveranciers koppelt aan bedrijfsmiddelen en risico’s binnen ISO 9001 en ISO 27001.

    Wat is NIS2 en hoe beïnvloedt het jouw ISMS?
    Waarom NIS2 organisaties dwingt om risico’s in de toeleveringsketen serieus te nemen.

    Van incident naar verbetering
    Hoe organisaties incidenten gebruiken om risico’s in de keten structureel te verkleinen.

    Van spreadsheets naar gestructureerd risicobeheer
    Waarom Excel tekortschiet voor leveranciers- en ketenbeoordelingen.

    Leveranciers beoordelen zonder Excel: zo krijg je grip op risico’s
    Praktische verdieping op leveranciers- en ketenafhankelijkheden