Wat zegt clausule 4?
Clausule 4 van ISO 27001:2022 legt het fundament van elk Information Security Management System (ISMS). Zonder een heldere context weet een organisatie niet welke risico’s relevant zijn, wie er belang heeft bij informatiebeveiliging en welk deel van de organisatie onder het ISMS valt. Clausule 4 bestaat uit vier sub-clausules die samen de basis vormen voor alles wat daarna komt.
4.1 — Inzicht in de organisatie en haar context
Sub-clausule 4.1 verplicht de organisatie om zowel interne als externe factoren te bepalen die relevant zijn voor haar doelstellingen en die van invloed zijn op het ISMS. Interne factoren zijn zaken als organisatiestructuur, bedrijfscultuur, IT-architectuur, bestaande beleidsregels en de volwassenheid van processen. Externe factoren omvatten wet- en regelgeving (AVG, NIS2, sector-specifieke normen), technologische ontwikkelingen, marktvereisten, dreigingen uit de omgeving en de bredere maatschappelijke context.
De norm schrijft niet voor hoe je dit vastlegt — een SWOT-analyse, een PESTLE-analyse of een simpele gestructureerde lijst zijn allemaal geaccepteerde methoden. Wat telt is dat de uitkomst aantoonbaar wordt gebruikt als input voor het ISMS.
4.2 — Begrijpen van de behoeften en verwachtingen van belanghebbenden
Sub-clausule 4.2 vraagt om een inventarisatie van alle relevante belanghebbenden (interested parties) en hun eisen ten aanzien van informatiebeveiliging. Denk aan klanten die contractuele beveiligingseisen stellen, toezichthouders die specifieke rapportages verwachten, aandeelhouders die risicobeheer willen zien, medewerkers die verwachten dat persoonsgegevens beschermd zijn, en leveranciers die inzicht willen in beveiligingsprocessen.
Per belanghebbende documenteer je: wie zijn ze, wat zijn hun eisen of verwachtingen, en welke van die eisen worden omgezet in verplichtingen voor het ISMS. Niet alle eisen worden automatisch verplichtingen — dit is een bewuste keuze van de organisatie.
4.3 — Bepalen van de scope van het ISMS
Sub-clausule 4.3 bepaalt de grenzen van het ISMS. De scope beschrijft welke organisatieonderdelen, locaties, processen, systemen en diensten onder het ISMS vallen. Een scope kan breed zijn (de gehele organisatie) of smal (alleen de clouddienst die klantdata verwerkt). Bij het bepalen van de scope moet rekening worden gehouden met de interne en externe context (4.1) en de eisen van belanghebbenden (4.2). De scope moet worden vastgelegd als gedocumenteerde informatie.
Let op: een bewust smalle scope is toegestaan, maar uitsluitingen moeten kunnen worden verantwoord. Een auditor zal kritisch kijken of uitgesloten onderdelen invloed hebben op de informatiebeveiliging van de scope-onderdelen.
4.4 — Informatiebeveiliging managementsysteem
Sub-clausule 4.4 is kort maar krachtig: de organisatie moet een ISMS opzetten, implementeren, onderhouden en continu verbeteren in overeenstemming met de eisen van de norm. Dit is de overkoepelende verplichting die de rest van de clausules invult. Het ISMS is geen project met een eindpunt — het is een doorlopend systeem.
Wat betekent dit in de praktijk?
Voor veel organisaties is clausule 4 de meest abstracte clausule om te beginnen. Hieronder vertalen we elke sub-clausule naar concrete praktijkvoorbeelden.
Praktijkvoorbeeld 4.1: interne en externe context
Een middelgrote accountantskantoor met 80 medewerkers stelt vast dat intern de volgende factoren relevant zijn: gebruik van cloudgebaseerde boekhoudsoftware, drie externe vestigingen, een mix van vaste medewerkers en zzp’ers met toegang tot klantdata, en geen dedicated IT-afdeling. Externe factoren zijn: de AVG, de Wet toezicht accountantsorganisaties (Wta), verwachtingen van grote accountantsnetwerken en de toenemende dreiging van gerichte phishing op financiële dienstverleners. Al deze factoren worden in een contextdocument vastgelegd en jaarlijks herzien.
Praktijkvoorbeeld 4.2: belanghebbenden
Dezelfde accountant identificeert de volgende belanghebbenden: zakelijke klanten (verwachten vertrouwelijke behandeling van financiële data), de Autoriteit Persoonsgegevens (verwacht AVG-compliance), medewerkers (verwachten bescherming van hun personeelsdossiers), de NBA (beroepsorganisatie met gedragscodes), en softwareleveranciers (verwachten veilige koppeling via API). Voor elke partij wordt genoteerd welke eisen relevant zijn voor het ISMS.
Praktijkvoorbeeld 4.3: scope
De scope wordt gedefinieerd als: “Het ISMS omvat alle processen en systemen die worden gebruikt voor de verwerking van klantgerelateerde financiële en fiscale informatie, inclusief de kantoorlocaties in Amsterdam, Rotterdam en Utrecht, en de cloudinfrastructuur van leverancier X.” De payrolladministratie die via een externe salarisverwerker loopt valt bewust buiten scope, omdat die partij een eigen certificering heeft.
Praktijkvoorbeeld 4.4: ISMS opzetten
Het ISMS wordt geoperationaliseerd door een jaarplanning op te stellen met risicobeoordelingen, interne audits, managementreviews en bewustwordingstrainingen. Een ISMS-coördinator is aangewezen en rapporteert maandelijks aan de directie.
Veelgemaakte fouten bij clausule 4
- Context invullen als eenmalige oefening. Veel organisaties stellen een contextdocument op voor de certificering en updaten het daarna nooit meer. De norm vereist dat de context actueel blijft — bij organisatorische veranderingen, nieuwe regelgeving of nieuwe dreigingen moet het document worden herzien. Een jaarlijkse herbeoordeling is minimaal vereist.
- Te brede of te vage scope. Een scope als “de gehele ICT-omgeving” zegt niets. Een goede scope beschrijft specifieke processen, systemen en locaties. Te breed gedefinieerde scopes leiden tot een ISMS dat onbeheersbaar wordt; te smalle scopes leiden tot auditbevindingen omdat kritieke onderdelen ontbreken.
- Belanghebbenden beperken tot klanten en management. Organisaties vergeten regelmatig toezichthouders, leveranciers, samenwerkingspartners en zelfs medewerkers als belanghebbenden te vermelden. Ook vergeten ze de eisen van deze partijen concreet te maken — “klanten willen veiligheid” is geen bruikbare eis.
- 4.1 en 4.2 niet koppelen aan risicoanalyse. De context en de eisen van belanghebbenden zijn de input voor de risicoanalyse in clausule 6. Organisaties die deze koppeling niet leggen, voeren een risicoanalyse uit in een vacuüm en missen relevante dreigingen en kwetsbaarheden.
- Scope niet als gedocumenteerde informatie bewaren. De norm eist expliciet dat de scope gedocumenteerd is. Een mondelinge afspraak of een slide in een presentatie volstaat niet — er moet een versiebeheerstuk zijn dat door de juiste persoon is goedgekeurd.
Hoe pak je clausule 4 aan? (stap-voor-stap)
- Stap 1 — Contextworkshop organiseren. Plan een sessie van 2 tot 4 uur met directie, IT-verantwoordelijke en eventueel een compliance-functionaris. Gebruik een PESTLE-template voor externe factoren en een SWOT voor interne factoren. Documenteer alle uitkomsten direct.
- Stap 2 — Stakeholderanalyse uitvoeren. Maak een tabel met kolommen: belanghebbende, hun eisen/verwachtingen, relevant voor ISMS (ja/nee), vertaald in ISMS-verplichting. Loop alle interne en externe partijen langs — minimaal 8 tot 12 partijen is gebruikelijk voor een middelgrote organisatie.
- Stap 3 — Scopedocument opstellen. Schrijf een scope die de volgende elementen bevat: welke organisatieonderdelen, welke locaties, welke systemen en diensten, en een expliciete vermelding van wat er buiten valt en waarom. Laat dit document goedkeuren door directie.
- Stap 4 — Koppeling leggen naar clausule 6. Zorg dat de geïdentificeerde factoren en stakeholder-eisen als input worden opgenomen in het risicobeoordelingsproces. Documenteer deze koppeling expliciet.
- Stap 5 — Jaarlijkse herzieningscyclus inplannen. Agendeer een jaarlijkse herbeoordeling van het contextdocument, bij voorkeur als onderdeel van de managementreview (clausule 9.3).
Relatie met andere clausules
Clausule 4 is niet op zichzelf staand — het is de voedingsbodem voor het gehele ISMS:
- Clausule 6 (Planning en risicobeoordeling): De interne en externe context (4.1) en de eisen van belanghebbenden (4.2) zijn directe input voor de risicoanalyse. Zonder een goede context mis je risico’s die voor jouw organisatie specifiek relevant zijn.
- Clausule 8 (Uitvoering): De scope (4.3) bepaalt op welke processen en systemen de operationele beheersmaatregelen van clausule 8 van toepassing zijn. Wat buiten scope valt, hoeft niet te worden beheerst — maar dit moet wel bewust zijn besloten.
- Clausule 9 (Prestatiebeoordeling): De managementreview (9.3) kijkt terug op veranderingen in de context en de eisen van belanghebbenden. De input voor die review is rechtstreeks afkomstig van clausule 4.
Veelgestelde vragen over clausule 4
Wat is de context van de organisatie bij ISO 27001?
De context van de organisatie omvat alle interne factoren (organisatiestructuur, cultuur, IT-landschap, bestaande processen) en externe factoren (wet- en regelgeving, marktomstandigheden, dreigingen, verwachtingen van klanten en toezichthouders) die van invloed zijn op de manier waarop de organisatie informatiebeveiliging inricht. Het is de startpositie van het ISMS: zonder deze context weet je niet welke risico’s en maatregelen relevant zijn voor jouw specifieke situatie.
Hoe bepaal je de scope van het ISMS?
De scope bepaal je door te kijken naar welke processen, systemen, locaties en organisatieonderdelen omgaan met informatie die beschermd moet worden. Houd daarbij rekening met de context (4.1) en de eisen van belanghebbenden (4.2). Een praktische aanpak is: begin met de informatie die het meest gevoelig is of waarover de grootste contractuele of wettelijke verplichtingen bestaan, en trek van daaruit de grens. Leg vervolgens expliciet vast wat er buiten scope valt en waarom — een auditor zal daar altijd naar vragen.
Wie zijn de belanghebbenden bij ISO 27001?
Belanghebbenden zijn alle partijen die een belang hebben bij de informatiebeveiliging van de organisatie of wier eisen invloed hebben op het ISMS. Typische belanghebbenden zijn: klanten (contractuele eisen), toezichthouders (wettelijke eisen zoals de AVG), medewerkers (bescherming van persoonsgegevens), aandeelhouders (risicobeheer en reputatie), leveranciers en verwerkers (ketensamenwerking), brancheorganisaties (gedragscodes) en samenwerkingspartners (gedeelde systemen).
Hoe documenteer je clausule 4?
De ISO 27001-norm vereist expliciet dat de scope (4.3) als gedocumenteerde informatie wordt vastgelegd. Voor 4.1 en 4.2 is documentatie niet expliciet verplicht, maar in de praktijk onmisbaar: zonder vastgelegd bewijs kun je aan een auditor niet aantonen dat je de oefening hebt gedaan. Gebruikelijke documenten zijn een contextanalyse (PESTLE/SWOT-format), een stakeholderregister en een scopeDocument met versienummer en goedkeuringshandtekening.
Wat is het verschil tussen interne en externe context?
Interne context zijn factoren binnen de organisatie zelf: de structuur, cultuur, strategie, processen, IT-systemen, financiële middelen en bestaande beleidsregels. Externe context zijn factoren buiten de organisatie: wet- en regelgeving, technologische ontwikkelingen, concurrenten, klantenverwachtingen, dreigingen vanuit het internet en maatschappelijke trends zoals thuiswerken of cloudadoptie. Het onderscheid is belangrijk omdat je op externe factoren weinig invloed hebt — je kunt er alleen op reageren — terwijl je interne factoren actief kunt aansturen.
Hoe lang duurt het invullen van clausule 4?
Voor een middelgrote organisatie (50 tot 250 medewerkers) kost het correct invullen van clausule 4 gemiddeld 2 tot 4 werkdagen, inclusief voorbereiding, workshops en documentatie. De contextworkshop zelf duurt doorgaans 2 tot 4 uur. De stakeholderanalyse kost 1 tot 2 uur. Het opstellen en reviewen van het scopedocument kost een halve tot een volledige dag. Bij grotere of complexere organisaties — met meerdere vestigingen, juridische entiteiten of internationale activiteiten — kan dit oplopen tot 2 tot 3 weken.
