Als iemand mij vraagt of een organisatie “klaar is voor ISO 27001”, kijk ik niet als eerste naar het aantal documenten.
Ik wil weten of de organisatie kan uitleggen hoe zij informatiebeveiliging bestuurt, welke risico's belangrijk zijn, welke maatregelen daarbij horen en welk bewijs laat zien dat die maatregelen ook werkelijk worden uitgevoerd.
Dat is voor mij de kern van deze checklist.
Gebruik hem niet als vervanging van de norm. Gebruik hem om te zien of de belangrijkste bouwstenen van een werkend ISMS aanwezig zijn.
1. Is de scope helder?
Begin met een duidelijke afbakening.
Kun je uitleggen:
- welke organisatieonderdelen binnen scope vallen;
- welke diensten en processen erbij horen;
- welke locaties onderdeel zijn;
- welke systemen en leveranciers relevant zijn;
- welke grenzen bewust zijn gekozen.
Een te vage scope maakt vrijwel alles daarna lastiger.
Mijn controlevraag
Kan iemand buiten het project in een paar zinnen uitleggen wat precies wordt gecertificeerd?
Als dat niet lukt, zou ik eerst de scope aanscherpen.
2. Zijn context en belanghebbenden in beeld?
ISO 27001 vraagt dat de organisatie begrijpt in welke context zij werkt.
Praktisch betekent dit dat je weet:
- welke klanten of opdrachtgevers eisen stellen;
- welke wet- en regelgeving relevant is;
- welke contractuele verplichtingen bestaan;
- welke ketenafhankelijkheden belangrijk zijn;
- welke interne verwachtingen gelden.
Dit hoeft geen omvangrijk theoretisch document te zijn.
Het moet vooral bruikbaar zijn bij het bepalen van risico's, scope en prioriteiten.
3. Is eigenaarschap geregeld?
Een ISMS werkt alleen wanneer duidelijk is wie waarvoor verantwoordelijk is.
Controleer:
- wie bestuurlijk verantwoordelijk is;
- wie het ISMS beheert;
- wie risico-eigenaren zijn;
- wie controls uitvoert;
- wie afwijkingen opvolgt;
- wie besluiten over restrisico neemt.
Ik zie liever een eenvoudige verantwoordelijkheidsstructuur die mensen kennen dan een uitgebreide matrix waar niemand mee werkt.
4. Is er een actuele risicoanalyse?
De risicoanalyse is geen bijlage om de auditor tevreden te stellen.
Hier hoort zichtbaar te worden:
- wat voor de organisatie belangrijk is;
- welke dreigingen en kwetsbaarheden relevant zijn;
- wat de mogelijke impact is;
- welke risico's prioriteit krijgen;
- welke risico's worden behandeld;
- welke risico's bewust worden geaccepteerd.
Vraag voor bestuur/directie
Welke informatiebeveiligingsrisico's vragen op dit moment aantoonbaar bestuurlijke aandacht?
Als de risicoanalyse daar geen antwoord op geeft, mist zij waarschijnlijk bestuurlijke waarde.
5. Is de risicobehandeling concreet?
Een risico zonder eigenaar en maatregel blijft vooral een constatering.
Controleer daarom of per relevant risico duidelijk is:
- welke maatregel wordt genomen;
- wie eigenaar is;
- welke termijn geldt;
- welk restrisico overblijft;
- wie dat restrisico accepteert.
Daarmee wordt het risicoregister een stuurinstrument.
6. Is de Statement of Applicability logisch opgebouwd?
De Statement of Applicability, vaak afgekort tot SoA, laat zien welke beheersmaatregelen relevant zijn en waarom.
Mijn voorkeur is om de SoA te behandelen als een inhoudelijke brug tussen risico's en controls.
Dus niet alleen:
“Control van toepassing: ja.”
Maar ook kunnen uitleggen waarom die control relevant is en hoe de organisatie hem heeft ingericht.
7. Zijn beleid en procedures werkbaar?
Je hebt beleid nodig.
Het doel is alleen niet zoveel mogelijk documenten produceren.
Controleer of beleid:
- aansluit op de organisatie;
- verantwoordelijkheden duidelijk maakt;
- uitvoerbaar is;
- bekend is bij de juiste mensen;
- periodiek wordt beoordeeld;
- overeenkomt met de werkelijke praktijk.
Een procedure die niemand volgt helpt het ISMS weinig.
8. Werken de belangrijkste technische controls?
Afhankelijk van risico en omgeving verwacht ik inzicht in onderwerpen als:
- identiteits- en toegangsbeheer;
- multi-factor authenticatie;
- beheeraccounts;
- endpointbeveiliging;
- patchmanagement;
- kwetsbaarhedenbeheer;
- logging;
- monitoring;
- back-up;
- herstel;
- netwerkbeveiliging;
- cloudconfiguratie.
De precieze inrichting verschilt per organisatie.
De auditvraag blijft hetzelfde:
kun je laten zien dat de maatregel passend is en structureel werkt?
9. Zijn leveranciers aantoonbaar beheerst?
Voor veel organisaties zit een groot deel van de feitelijke IT bij externe partijen.
Controleer daarom:
- welke leveranciers kritisch zijn;
- welke beveiligingseisen gelden;
- welke toegang zij hebben;
- welke incidentafspraken bestaan;
- welke assurance beschikbaar is;
- hoe leveranciers periodiek worden beoordeeld;
- wat gebeurt bij uitval of beëindiging.
Uitbesteden van IT betekent niet dat je het risico uitbesteedt.
10. Is incidentmanagement ingericht en geoefend?
Een incidentprocedure is belangrijk.
Ik wil daarnaast weten:
- wie incidenten coördineert;
- wanneer bestuur/directie betrokken wordt;
- welke leveranciers moeten worden gebeld;
- hoe communicatie verloopt;
- hoe bewijs wordt veiliggesteld;
- hoe herstel wordt aangestuurd;
- wanneer voor het laatst is geoefend.
Een oefening maakt snel zichtbaar wat op papier nog logisch leek.
11. Is awareness meer dan een jaarlijkse e-learning?
Awareness hoort aan te sluiten op risico en gedrag.
Kijk daarom naar:
- relevante doelgroepen;
- terugkerende aandacht;
- phishing en meldgedrag;
- verhoogde risico's per functie;
- onboarding;
- managementbetrokkenheid;
- meetbare verbetering.
Het bewijs zit uiteindelijk niet in het aantal verstuurde modules, maar in wat de organisatie ermee bereikt.
12. Worden controls aantoonbaar uitgevoerd?
Bij iedere belangrijke maatregel stel ik graag drie vragen:
Opzet
Is de maatregel logisch ingericht?
Bestaan
Is hij daadwerkelijk ingevoerd?
Werking
Functioneert hij gedurende de tijd zoals bedoeld?
Dit voorkomt een veelvoorkomend probleem: de organisatie heeft alles beschreven, maar kan nauwelijks laten zien wat er daadwerkelijk is gebeurd.
13. Is een interne audit uitgevoerd?
De interne audit hoort onafhankelijk te beoordelen of het ISMS passend werkt.
Controleer:
- is er een auditprogramma;
- is relevante scope afgedekt;
- zijn bevindingen gedocumenteerd;
- zijn oorzaken onderzocht;
- zijn acties opgevolgd.
Een interne audit is geen vinkje vóór de certificatie-audit.
Het is een instrument om zelf zwakke plekken te vinden.
14. Heeft de directie het ISMS echt beoordeeld?
De directiebeoordeling hoort bestuurlijke sturing zichtbaar te maken.
Daar wil ik onderwerpen terugzien zoals:
- prestaties;
- risico's;
- incidenten;
- auditbevindingen;
- middelen;
- leveranciers;
- trends;
- verbeteringen;
- besluiten.
Als de directiebeoordeling alleen bestaat omdat “ISO het vraagt”, mis je de kans om informatiebeveiliging onderdeel te maken van normale besturing.
15. Zijn afwijkingen en verbeteringen aantoonbaar opgevolgd?
Een volwassen ISMS mag problemen vinden.
Sterker nog: als er nooit iets wordt gevonden, zou ik juist nieuwsgierig worden.
Controleer of:
- afwijkingen worden geregistreerd;
- oorzaken worden onderzocht;
- acties eigenaars hebben;
- deadlines worden gevolgd;
- effectiviteit wordt beoordeeld.
Daarmee laat je zien dat het systeem leert.
Een compacte bestuurderscheck
Als bestuurder zou ik vóór certificering deze zes vragen willen kunnen beantwoorden:
- Wat is precies onze scope?
- Welke digitale risico's hebben de hoogste prioriteit?
- Wie is eigenaar van die risico's?
- Welke maatregelen werken aantoonbaar?
- Welke belangrijke afwijkingen staan nog open?
- Waar stuurt de directie aantoonbaar op bij?
Als daar duidelijke antwoorden op zijn, staat er meestal meer dan alleen documentatie.
En voor de IT-manager?
Voor de IT-manager zou ik aanvullend kijken naar:
- bewijs uit beheerprocessen;
- accountreviews;
- patchrapportages;
- kwetsbaarheden;
- logging;
- back-up;
- restore-tests;
- wijzigingen;
- leveranciers;
- incidenten.
Mijn advies is om bewijs zoveel mogelijk uit normale beheerprocessen te laten ontstaan.
Dan hoeft vlak voor de audit geen aparte bewijsfabriek te worden opgetuigd.
Wanneer is deze checklist onvoldoende?
Wanneer je wilt weten of je werkelijk klaar bent voor certificering, is een eigen checklist meestal niet genoeg.
Dan wil je onafhankelijk laten beoordelen:
- welke normonderdelen nog ontbreken;
- waar bewijs onvoldoende is;
- waar beleid en praktijk uit elkaar lopen;
- welke punten waarschijnlijk tijdens certificatie aandacht krijgen.
Daar is een ISO 27001 GAP-analyse voor bedoeld.
Wil je eerst begrijpen hoe de certificatie-audit zelf verloopt? Lees dan ook:
ISO 27001 audit: wat gebeurt er tijdens de audit?
Passende vervolgstap
Van inzicht naar gerichte verbetering
Wil je onafhankelijk vaststellen waar de belangrijkste risico’s en verbeterpunten liggen? Kynexis helpt om de vraag scherp te formuleren en de uitkomst bestuurlijk en praktisch bruikbaar te maken.
Bekijk ISO 27001 GAP-analyse →