ISO 27001 scope en context bepalen waar je ISMS geldt en welke omgevingsfactoren je risico’s sturen — de basis waar auditors elke andere vraag aan koppelen. Zonder scherpe scope ontstaat scope creep of juist een te smalle grens waardoor productie buiten beheer valt.
Scope is geen administratief randje: het is de contractuele en operationele waarheid over welke diensten, locaties, cloud-tenants en ketenpartners onder je informatiebeveiligingsmanagementsysteem vallen. Context vertaalt marktdruk, wetgeving en interne cultuur naar issues die je risicobeoordeling voeden.
Wat betekent dit?
Scope beschrijft welke processen, locaties, teams en informatiesystemen onder het ISMS vallen, inclusief expliciete uitsluitingen met rationale. Context omvat interne en externe issues: markt, wetgeving, technologie, cultuur en belanghebbenden. ISO 27001 clausule 4.1 en 4.2 vragen dat je beide periodiek herziet — niet als eenmalige workshop.
In audittermen is scope het kader voor steekproeven. Een auditor die ziet dat klantdata in SaaS-omgeving X draait terwijl scope alleen ‘kantoor IT’ noemt, zal vragen stellen over uitsluitingen. Context leg je vast in een contextanalyse of equivalent register: welke trends (AI, cloud, NIS2) veranderen je risicoprofiel en welke belanghebbenden eisen welk bewijs?
Voor SaaS-leveranciers betekent scope vaak: productie-omgeving, CI/CD, support tooling en identity provider — plus expliciete keuze over welke legacy of corporate IT buiten scope valt met gedocumenteerde rationale. Multi-tenant architectuur vraagt extra precisie: welke tenant-isolatie maatregelen horen bij scope en welke datastromen naar subprocessors lopen.
Context koppelt je aan de Statement of Applicability en risicoregister: issues over ketenafhankelijkheid of persoonsgegevens beïnvloeden welke Annex A-controles relevant zijn. Auditors verwachten traceerbaarheid van context-issue naar risico naar maatregel — geen losse PowerPoint over ‘de markt verandert’.
Scope-statements voor certificering zijn kort maar moeten feitelijk kloppen met dataflows en contracten. Veel organisaties formuleren scope als ‘ontwikkeling en levering van software-as-a-service’ — dat is prima mits support, monitoring en identity expliciet zijn meegenomen of beargumenteerd uitgesloten.
Voor wie is dit relevant?
Directie en MT moeten scope begrijpen omdat het budget en prioriteit bepaalt — een ISMS dat alleen HR dekt terwijl omzet in productie draait, is strategisch riskant. CISO’s en security leads gebruiken scope om teams te onboarden zonder eindeloze discussies over ‘valt dit eronder?’.
Product- en engineering leads hebben scope nodig voor secure SDLC-grenzen: welke repositories, pipelines en omgevingen vallen onder change control en logging-eisen. Compliance officers koppelen scope aan contracten en DPIA’s — klanten vragen vaak expliciet welke scope op het certificaat staat.
MKB-organisaties kunnen scope bewust compact houden (bijvoorbeeld kernproduct + één kantoor) mits uitsluitingen verdedigbaar zijn. Scale-ups met snelle acquisities moeten scope herzien bij elke integratie — auditors zien fusies als klassiek moment waar scope-documentatie achterloopt.
Procurement en legal raken scope wanneer leveranciers subprocessors zijn: als je scope zegt ‘alle kritieke SaaS’ maar je register mist identity of backup-provider, ontstaat een gap die auditors snel vinden.
Welke eisen of stappen horen erbij?
Start met een scope-workshop met MT, security, product en operations: inventariseer diensten, locaties, systemen en datastromen. Documenteer uitsluitingen met risico-argument — ‘niet in scope omdat geen klantdata’ werkt alleen als dat feitelijk klopt en monitoring dat bevestigt.
Voer contextanalyse uit: PESTEL of vergelijkbaar lichtgewicht model, plus belanghebbendenmatrix (klanten, toezichthouders, werknemers, leveranciers). Leg vast hoe context wordt herzien — bijvoorbeeld kwartaal in management review of bij major release.
Koppel scope aan juridische entiteiten en contracten: welke BV’s, welke hosting-regio’s, welke data-residency beloftes aan klanten. Maak een scope-statement dat op het certificaat kan landen en intern consistent is met sales decks.
Update risicoregister en SoA wanneer scope wijzigt — nieuwe business unit zonder herziening is een veelvoorkomende minor. Plan steekproef: trek drie willekeurige systemen en check of ze in scope-documentatie staan met eigenaar.
Veelgemaakte fouten
Scope te smal tekenen om audit te versnellen terwijl productie buiten valt — auditors volgen data en klantcontracten, niet alleen je PDF. Tweede fout: geen rationale bij uitsluitingen; ‘administratie’ uitsluiten zonder te checken of daar credentials of klantlijsten staan.
Context als eenmalige slide deck zonder herziening — NIS2, AI-features of nieuwe US-klant veranderen je issue-landschap. Derde fout: inconsistentie tussen scope in ISMS, certificaatscope en privacyverklaring.
Vierde fout: vergeten dat support- en monitoring-tools binnen scope vallen — veel incidenten starten in ticketing of SIEM buiten de ‘productie’ scope. Vijfde fout: geen eigenaar voor scope-wijzigingen; niemand coördineert bij nieuwe cloud-regio.
Zesde patroon bij SaaS: scope noemt productie maar niet staging met productie-data — masking en data-handling moeten dan alsnog gedocumenteerd zijn of staging expliciet buiten scope met harde technische scheiding.
Praktisch stappenplan
Week 1–2: dataflow-diagram en dienstenlijst; week 3: draft scope-statement + uitsluitingen; week 4: contextregister en belanghebbenden; week 5: koppeling naar risico’s en MT-goedkeuring. Publiceer scope intern op één wiki-pagina met versiebeheer.
Gebruik dezelfde definities in onboarding voor nieuwe medewerkers — ‘in scope’ betekent dan concreet: welke tools, welke policies, welke meldroute. Koppel aan ISO 27001 risicoanalyse zodra scope staat.
Voor certificering: align scope met gekozen certificeringsinstantie vóór stage 1 — discussie over scope is normaal, verrassingen tijdens stage 2 niet. Zie ISO 27001-certificering voor het totale traject.
Plan jaarlijkse scope sanity check na grote releases, fusies of nieuwe compliance-eisen. Documenteer wijzigingen in change log die auditors kunnen volgen — datum, beslisser, impact op risico’s.
Relatie met ISO 27001, NIS2, AVG of ISMS
Scope en context zijn clausule 4 — fundament voor alles in ISMS en ISO 27001-certificering. NIS2 voegt geen andere scope-definitie toe maar verwacht wel dat kritieke diensten en keten binnen je governance vallen — overlap met context-issues over leveranciers.
AVG raakt scope waar persoonsgegevens verwerkt worden: verwerkers, doorgifte en bewaartermijnen horen in context en scope te landen, niet alleen in privacybeleid. Lees AVG en ISO 27001 voor gezamenlijke registers.
Keten en hosting: leveranciersbeheer en EU hosting vullen context aan met concrete partijen. NIS2 hub voor bestuurlijke verwachtingen; SoA vertaalt scope naar controls.
Interne lijn: scope is levend — behandel wijzigingen als normale change met impactanalyse, niet als audit-paniek in de week voor stage 2.
Documenteer scope-boundaries visueel: een eenvoudig diagram met systemen, mensen en dataflows helpt auditors sneller dan tien pagina’s tekst — mits het diagram actueel blijft na elke architectuurwijziging.
Leg in scope-documentatie ook vast welke juridische entiteiten en merken onder het certificaat vallen — relevant bij due diligence op moeder-dochter structuren.
Remote en hybride werken verlegt scope-grenzen: thuiswerkplekken, BYOD en persoonlijke cloud-accounts horen expliciet in scope of in uitsluiting met technische en juridische onderbouwing — auditors vragen naar MDM, VPN en acceptable use.
Fusies en re-organisaties triggeren scope-review binnen 30 dagen: welke entiteiten, systemen en contracten overgaan, welke uitsluitingen vervallen, en hoe klantcommunicatie over certificaatscope wordt bijgewerkt.
Contextregister met eigenaar per issue — zonder eigenaar veroudert NIS2 of AI-trend entry stil. Koppel issue aan risico-ID binnen vijf werkdagen na identificatie.
Scope goedgekeurd door MT met datum in ISMS handboek — unsigned drafts falen stage 1 regelmatig.
Dataflow diagram versie gekoppeld aan scope change record — datum diagram = datum scope goedkeuring.