📚 ISO Kennisbank / ISO 27001 Clausule 8: Uitvoering van de Operationele Planning

ISO 27001 Clausule 8: Uitvoering van de Operationele Planning

🔒 ISO 27001 ⏱ 8 min lezen 📅 3 juni 2026

Clausule 8 van ISO 27001 gaat over de daadwerkelijke uitvoering van wat u in de planningsfase heeft vastgesteld. Leer hoe u operationele planning, risicobeoordeling, risicobehandeling en Annex A-controls in de praktijk brengt.

Wat is ISO 27001 Clausule 8?

ISO 27001 Clausule 8 is de uitvoerende kern van uw ISMS: hier zet u alles wat u heeft gepland daadwerkelijk om in actie. Waar clausules 4 tot en met 7 de basis leggen en clausule 6 het plan opstelt, draait clausule 8 om de operationele realisatie van informatiebeveiliging in de dagelijkse praktijk.

Wat zegt de norm?

Clausule 8 bestaat uit drie sub-clausules:

  • 8.1 Operationele planning en beheersing – De organisatie moet de processen die nodig zijn om aan de eisen te voldoen plannen, implementeren, beheersen, onderhouden en evalueren.
  • 8.2 Risicobeoordeling informatiebeveiliging – De risicobeoordeling moet op geplande tijdstippen, of wanneer significante wijzigingen zich voordoen, worden uitgevoerd.
  • 8.3 Risicobehandeling informatiebeveiliging – Het plan voor risicobehandeling moet worden geïmplementeerd en gedocumenteerd bewaard.

8.1 Operationele planning en beheersing: het verschil met clausule 6

Een veelgestelde vraag is: wat is nu precies het verschil tussen de planning in clausule 6 en de uitvoering in clausule 8.1? Het antwoord is simpel maar cruciaal. Clausule 6 gaat over wat u gaat doen en waarom: u stelt risicos vast, bepaalt doelstellingen en legt een plan neer. Clausule 8.1 gaat over hoe u het doet: u voert de processen daadwerkelijk uit, beheert ze en houdt er toezicht op.

Concreet betekent dit dat u in clausule 8.1 operationele procedures schrijft, verantwoordelijkheden belegt en ervoor zorgt dat uitbestede processen aantoonbaar voldoen aan de gestelde beveiligingseisen. De norm vereist ook dat u geplande wijzigingen beheerst doorvoert en de gevolgen van onbedoelde wijzigingen beoordeelt en zo nodig corrigeert.

Operationele procedures en werkinstructies

Voor elk kritisch informatiebeveiligingsproces heeft u gedocumenteerde procedures nodig. Denk aan:

  • Toegangsbeheer (wie krijgt toegang tot welke systemen en onder welke voorwaarden)
  • Patchmanagement (hoe en hoe snel worden beveiligingsupdates doorgevoerd)
  • Back-up en herstelprocessen (frequentie, bewaarperiode, testprocedure)
  • Fysieke beveiliging (toegang tot serverruimtes, clean-desk beleid)
  • Cryptografiebeleid (welke versleuteling, welke sleutelbeheerprocessen)

Procedures hoeven niet altijd ellenlange documenten te zijn. Een helder stroomdiagram of een eenpagetje met stappen kan volstaan, mits het aantoonbaar gevolgd en bijgehouden wordt.

8.2 Risicobeoordeling herhalen: wanneer en hoe?

ISO 27001 vereist dat u de risicobeoordeling niet eenmalig uitvoert, maar herhaalt op geplande momenten en bij significante wijzigingen. In de praktijk kiezen de meeste organisaties voor een jaarlijkse grondige herbeoordeling, aangevuld met ad-hoc beoordelingen bij:

  • Grote IT-wijzigingen (nieuwe systemen, migratie naar de cloud)
  • Organisatiewijzigingen (fusies, overnames, reorganisaties)
  • Significante incidenten of bijna-incidenten
  • Wijzigingen in wet- en regelgeving (zoals nieuwe AVG-vereisten)
  • Nieuwe dreigingen of kwetsbaarheden die bekend worden in de sector

De output van de risicobeoordeling moet gedocumenteerd worden bewaard als bewijs. Dit is een essentieel auditbewijsstuk. Gebruik hiervoor een risicoregister dat de volgende elementen bevat: informatieasset, dreiging, kwetsbaarheid, kans, impact, risiconiveau voor behandeling, geselecteerde maatregel en risiconiveau na behandeling.

8.3 Risicobehandeling uitvoeren: van plan naar actie

Het risicobehandelingsplan dat u in clausule 6 heeft opgesteld, voert u hier daadwerkelijk uit. De vier behandelstrategien zijn:

  • Mitigeren – Het risico verkleinen door technische of organisatorische maatregelen
  • Accepteren – Het risico bewust aanvaarden omdat de kosten van behandeling hoger zijn dan het risico zelf
  • Overdragen – Het risico verlegen via verzekering of contractuele afspraken met leveranciers
  • Vermijden – De activiteit die het risico veroorzaakt staken

Voor elk behandeld risico moet u kunnen aantonen dat de geplande maatregel daadwerkelijk is geimplementeerd. Bewaar implementatiebewijzen zoals configuratieschermen, testresultaten, trainingsregistraties en audit logs.

Annex A-controls implementeren in de praktijk

ISO 27001:2022 bevat in Annex A 93 controls verdeeld over vier themas: organisatorisch (37), personeel (8), fysiek (14) en technologisch (34). U selecteert de relevante controls op basis van uw risicobehandeling en legt deze vast in de Verklaring van Toepasselijkheid (Statement of Applicability, SoA).

Organisatorische controls

  • Stel een informatiebeveiligingsbeleid op en laat het door de directie ondertekenen
  • Definieer rollen en verantwoordelijkheden in een RACI-matrix
  • Implementeer een procedure voor het classificeren van informatie
  • Zorg voor een leveranciersbeleid met security-eisen in contracten

Personele controls

  • Screening van nieuwe medewerkers (VOG, referentiecheck)
  • Security awareness training (minimaal jaarlijks, bij voorkeur doorlopend)
  • Disciplinaire procedure bij schendingen van het informatiebeveiligingsbeleid
  • Exit-procedure (intrekken toegangsrechten, retourneren apparatuur)

Fysieke controls

  • Toegangscontrole tot gebouwen en serverruimtes (badgesysteem, logregistratie)
  • Clean-desk en clear-screen beleid
  • Beveiligde verwijdering van media en apparatuur
  • Cameratoezicht en bezoekersregistratie

Technologische controls

  • Multi-factor authenticatie voor alle kritische systemen
  • Geautomatiseerd patchmanagement
  • Encryptie van data in transit en at rest
  • SIEM-systeem voor monitoring en detectie van beveiligingsincidenten
  • Vulnerability management (regelmatige scans en penetratietests)

Leveranciers- en uitbestedingsbeheersing

Clausule 8.1 vereist dat u ook uitbestede processen beheerst. Voor elke kritische leverancier dient u een risicoanalyse uit te voeren voordat u de samenwerking aangaat, contractuele beveiligingseisen vast te leggen, periodiek de naleving te controleren en een exit-strategie achter de hand te hebben.

Leveranciersincidenten zijn een van de grootste risicos voor informatiebeveiliging. Zorg dat uw leveranciersbeheersproces ook incidentmeldplichten bevat: de leverancier moet beveiligingsincidenten die uw data betreffen direct aan u melden.

Incidentbeheer en bedrijfscontinuiteit

Hoewel incidentbeheer en bedrijfscontinuiteit ook als Annex A-controls zijn opgenomen, worden ze in clausule 8 geoperationaliseerd. Een goed incidentbeheerproces omvat vijf fasen:

  • Detectie en rapportage – Hoe melden medewerkers een incident? Via een ticketsysteem, e-mail of telefonisch?
  • Triage en classificatie – Hoe ernstig is het incident? Wat is de prioriteit?
  • Respons en insluiting – Welke directe maatregelen worden genomen om schade te beperken?
  • Herstel – Hoe wordt de normale situatie hersteld?
  • Lessons learned – Wat leren we van dit incident ter voorkoming in de toekomst?

Alle incidenten, ook bijna-incidenten, moeten worden gedocumenteerd in een incidentregister. Dit register is een waardevol auditbewijsstuk en een bron voor continue verbetering.

Veelgemaakte fouten bij clausule 8

  • Papieren procedures zonder praktische uitvoering – Procedures zijn aanwezig maar worden in de dagelijkse praktijk niet gevolgd of zijn niet bekend bij medewerkers.
  • Risicobeoordeling als eenmalige exercitie – De risicobeoordeling wordt eenmalig uitgevoerd voor de certificering en daarna niet meer herhaald.
  • Onvolledige SoA – Controls worden geselecteerd zonder duidelijke koppeling aan de risicobehandeling, of controls worden uitgesloten zonder adequate motivatie.
  • Leveranciers buiten scope laten – Kritische IT-leveranciers worden niet opgenomen in het ISMS terwijl zij wel vertrouwelijke data verwerken.
  • Geen bewijs van implementatie – Er wordt geen documentatie bijgehouden die aantoont dat controls daadwerkelijk werken.
  • Incidenten niet vastleggen – Incidenten worden opgelost maar niet gedocumenteerd, waardoor trends niet zichtbaar zijn en verbeteringen uitblijven.

Stap-voor-stap aanpak voor clausule 8

  1. Inventariseer uw informatieassets – Maak een volledig overzicht van alle systemen, data en processen die binnen de ISMS-scope vallen.
  2. Voer of herhaal de risicobeoordeling uit – Gebruik een gestandaardiseerde methode en documenteer alle resultaten in het risicoregister.
  3. Stel het risicobehandelingsplan op of actualiseer het – Koppel elk risico aan een behandelstrategie en specifieke Annex A-controls.
  4. Implementeer de geselecteerde controls – Volg een projectmatige aanpak met eigenaren, deadlines en budgetten per control.
  5. Schrijf operationele procedures – Documenteer hoe elk kritisch proces wordt uitgevoerd, door wie en onder welke omstandigheden.
  6. Train uw medewerkers – Zorg dat iedereen weet wat van hen verwacht wordt en hoe zij incidenten melden.
  7. Implementeer monitoring – Stel logging, alerting en periodieke controles in om te detecteren of controls effectief zijn.
  8. Test uw continuiteitsplannen – Voer regelmatig oefeningen uit om te controleren of u kunt herstellen van incidenten.

Relatie met andere clausules

Clausule 8 staat niet op zichzelf maar bouwt voort op en levert input aan andere clausules:

  • Clausule 6 – De plannen en risicobeoordeling uit clausule 6 zijn de basis voor de uitvoering in clausule 8.
  • Clausule 7 – De middelen, competenties en bewustzijn die in clausule 7 worden bepaald, worden in clausule 8 ingezet.
  • Clausule 9 – De uitvoering in clausule 8 wordt gemonitord en beoordeeld via de prestatiebeoordeling in clausule 9.
  • Clausule 10 – Afwijkingen die tijdens de uitvoering worden ontdekt, worden via clausule 10 gecorrigeerd en verbeterd.

FAQ

Moet ik alle 93 Annex A-controls implementeren?

Nee, u hoeft niet alle 93 controls te implementeren. U selecteert de controls die relevant zijn op basis van uw risicobehandeling. Wel moet u in de Verklaring van Toepasselijkheid (SoA) voor elke control motiveren waarom u hem wel of niet opneemt. Het uitsluiten van controls is toegestaan, maar de motivatie moet steekhoudend zijn en gedocumenteerd worden.

Hoe vaak moet ik de risicobeoordeling herhalen?

De norm schrijft geen vaste frequentie voor, maar stelt dat u de beoordeling uitvoert op geplande tijdstippen en bij significante wijzigingen. In de praktijk is een jaarlijkse grondige herbeoordeling de minimumstandaard, aangevuld met ad-hoc beoordelingen bij grote wijzigingen in de organisatie of het dreigingslandschap.

Wat moet ik documenteren in het risicoregister?

Een compleet risicoregister bevat minimaal: de geidentificeerde informatieasset, de relevante dreiging(en) en kwetsbaarheid(en), de geschatte kans en impact, het berekende risiconiveau, de gekozen behandelstrategie, de geselecteerde Annex A-controls en het restrisico na behandeling. Voeg ook toe wie de risico-eigenaar is en wanneer de beoordeling is uitgevoerd.

Hoe bewijs ik dat mijn controls effectief zijn?

Bewijs van effectiviteit kan bestaan uit: logbestanden en monitoringrapportages, testresultaten van penetratietests of vulnerability scans, trainingsregistraties van medewerkers, toegangslogboeken, audittrails van systemen, resultaten van interne audits en management reviews. Zorg dat u voor elke kritische control minimaal een vorm van aantoonbaar bewijs heeft.

Hoe ga ik om met leveranciers die zelf geen ISO 27001 certificaat hebben?

Als een leverancier geen ISO 27001-certificaat heeft, kunt u alsnog bewijs van beveiligingsvolwassenheid verzamelen via een ingevulde vragenlijst (security assessment), contractuele beveiligingseisen met auditrecht, een SOC 2-rapport, of periodieke site visits. Laat het ontbreken van een certificaat niet zonder meer door als voldoende reden om risico te accepteren zonder compenserende maatregelen.

Wat is het verschil tussen een dreigings- en kwetsbaarheidsanalyse en een risicobeoordeling?

Een dreigingsanalyse inventariseert wat er mis kan gaan (hackers, brand, menselijk falen), een kwetsbaarheidsanalyse brengt de zwakke plekken in kaart (verouderde software, gebrekkige procedures). Een risicobeoordeling combineert beide: het bepaalt de kans dat een dreiging misbruik maakt van een kwetsbaarheid en wat de impact daarvan zou zijn. De risicobeoordeling leidt tot een geprioriteerde lijst van risicos waarop u actie moet ondernemen.

Direct aan de slag met ISO?

Vooraf ingevulde templates — 80% klaar, in Word, Office 365, Confluence of Google Docs.

Bekijk templates →