Scope bepalen voor je ISMS: wat hoort erin en wat niet

De scope van je ISMS is geen sjabloon dat je invult maar een uitkomst van hoofdstuk 4 van ISO 27001. Je bepaalt eerst de context van je organisatie (4.1) en wie er eisen aan je stelt (4.2), en pas daaruit volgt het toepassingsgebied (4.3), inclusief de raakvlakken en afhankelijkheden met wat je niet zelf doet. Die scope is een verplicht document en meestal het eerste dat een auditor opvraagt. Hij hoeft niet groot te zijn, maar wel verdedigbaar: uitsluiten wat je niet kunt afschermen is de fout die het vaakst tot een bevinding leidt.

Waarom een sjabloon hier niet werkt

Twee organisaties met evenveel medewerkers in dezelfde sector kunnen een totaal andere scope nodig hebben. De ene draait alles zelf op eigen hardware, de andere heeft het primaire proces bij drie leveranciers ondergebracht. De ene verwerkt medische gegevens, de andere niet. Een scope die je uit een voorbeelddocument overneemt beschrijft de organisatie van iemand anders, en dat merk je in de audit binnen tien minuten.

De norm erkent dat expliciet. Hoofdstuk 4.1 vraagt je om de externe en interne onderwerpen te bepalen die van invloed zijn op wat je met informatiebeveiliging wilt bereiken. Hoofdstuk 4.2 vraagt wie de belanghebbenden zijn en welke eisen zij stellen: klanten, toezichthouders, verzekeraars en medewerkers. Reken daar in de praktijk ook je leveranciers bij, want hun eisen en hun tekortkomingen landen allebei bij jou. Pas in 4.3 bepaal je de grenzen van het managementsysteem, en daarbij moet je expliciet rekening houden met de uitkomsten van 4.1 en 4.2 en met de raakvlakken en afhankelijkheden tussen wat jij doet en wat andere organisaties voor jou doen.

Ook het NCSC redeneert zo. In zijn artikel Beginnen met een ISMS staat het onomwonden: elk ISMS is uniek en moet passen bij de aard, omvang en cultuur van je organisatie, en je begint met de vraag welke processen, systemen of onderdelen het belangrijkst zijn om te beschermen en waarom.

Vier vragen die je scope bepalen

Voordat je een grens trekt, beantwoord je vier vragen. Ze komen uit dezelfde NCSC-aanpak en ze werken omdat ze over je organisatie gaan en niet over de norm.

1. Waar verdien je je geld mee? Kijk naar het primaire proces. Wie doet het werk en welke middelen en informatiestromen gebruiken zij daarvoor.
2. Wie verwacht betrouwbaarheid van jou? Welke klanten zijn van je afhankelijk, welke leveranciers ben jij afhankelijk van, en wat staat er in contracten over beveiliging. Vaak staat daar minder in dan je denkt, en dat is zelf een bevinding waard.
3. Wat mag nooit uitvallen? De systemen, data en processen waarvan de beschikbaarheid, integriteit of vertrouwelijkheid bepalend is voor je bedrijfsvoering.
4. Waar zit je grootste kwetsbaarheid? Kijk naar je aanvalsoppervlak en naar incidenten uit het verleden. Die leggen doorgaans precies de afhankelijkheden bloot die in geen enkel schema stonden.

De antwoorden geven je een kern. Rond die kern trek je de grens, en die grens leg je vast in termen die een buitenstaander kan controleren: welke diensten, welke organisatieonderdelen, welke locaties, welke systemen en welke processen.

Klein beginnen mag, vaag blijven niet

Een smalle scope is geen zwaktebod. Het NCSC adviseert de eerste ronde bewust klein en beheersbaar te houden en waarschuwt voor scope creep: neem je meteen alle afhankelijkheden in de hele organisatie mee, dan is je aanpak binnen de kortste keren niet meer beheersbaar. Kwetsbaarheden die je in de eerste cyclus niet meeneemt zet je in een register, zodat ze niet uit beeld verdwijnen.

Er zit ook een rekensom aan vast. Certificerende instellingen leiden het aantal auditdagen af uit het aantal medewerkers binnen de scope, gecorrigeerd voor complexiteit, locaties en risico. Elke afdeling die je erbij trekt betaal je drie jaar lang terug in audittijd. Wat je scope kost aan geld en uren staat in onze gids over ISO 27001.

Wat niet mag, is een scope die zo geformuleerd is dat niemand kan vaststellen wat erin zit. "De informatievoorziening van de organisatie" is geen scope. "De ontwikkeling, het beheer en de ondersteuning van dienst X vanuit de vestiging in Utrecht, inclusief de daarvoor gebruikte kantoorautomatisering en cloudomgevingen" wel.

Raakvlakken en afhankelijkheden: waar het misgaat

Uitsluiten is toegestaan. Doen alsof er geen verbinding bestaat met wat je uitsluit, is dat niet. De norm vraagt om de raakvlakken en afhankelijkheden expliciet mee te wegen, en juist daar stelt een auditor zijn vragen.

Drie voorbeelden. Je sluit de salarisadministratie uit, maar die draait op hetzelfde netwerk en dezelfde identiteitsvoorziening als de dienst in scope. Je sluit een dochteronderneming uit, maar haar beheerders hebben beheerrechten op jouw systemen. Je sluit de kantoorautomatisering uit, maar je ontwikkelaars werken erop. In alle drie de gevallen loopt het risico gewoon door de grens heen. Wat je dan vastlegt is niet de uitsluiting zelf, maar hoe de scheiding technisch en organisatorisch is geregeld en wie daar toezicht op houdt.

Veelvoorkomende scope-uitsluitingen en hoe ze het doorgaans doen in een certificeringsaudit. Dit is praktijkervaring, geen letterlijke norm-uitspraak per regel.

Uitsluiting	Meestal verdedigbaar?	Wat de auditor wil zien
Een tweede vestiging met eigen processen en eigen netwerk	Ja	Aantoonbare scheiding en een beschrijving van het verkeer tussen beide
Een bedrijfsonderdeel dat een andere dienst levert aan andere klanten	Ja	Waarom de belanghebbenden en risico's wezenlijk verschillen
De kantoorautomatisering, terwijl mensen in scope erop werken	Nee	Meestal geen uitsluiting mogelijk: de werkplek raakt de dienst
Een uitbestede dienst, omdat de leverancier zelf gecertificeerd is	Nee	De uitbesteding blijft jouw verantwoordelijkheid: leveranciersbeheer, afspraken en toezicht horen in scope
Een beheersmaatregel uit bijlage A, zonder onderbouwing	Nee	Een uitsluiting in de Verklaring van Toepasselijkheid moet terug te voeren zijn op de risicobeoordeling
Legacy-systemen die "toch worden uitgefaseerd"	Nee	Een uitfaseringsdatum, een eigenaar en beheersmaatregelen tot die datum

Als je onder de Cyberbeveiligingswet valt, kies je je scope niet zelf

Hier zit het grootste verschil tussen de norm en de wet. ISO 27001 laat je de grens zelf trekken. De Cyberbeveiligingswet, de Nederlandse uitwerking van NIS2 en sinds 15 augustus 2026 van kracht, doet dat niet. Artikel 21 legt de zorgplicht op voor de netwerk- en informatiesystemen die de entiteit gebruikt voor haar werkzaamheden of voor het verlenen van haar diensten. Dat is de hele organisatie, niet een zelfgekozen deel ervan. De wettekst staat op wetten.overheid.nl. Of je eronder valt lees je in ons artikel over de reikwijdte van de Cyberbeveiligingswet.

Het Cyberbeveiligingsbesluit verplicht die entiteiten daarnaast tot een managementsystematiek waarmee ze aantoonbaar aan artikel 21 voldoen. Welke systematiek dat is, mag de entiteit zelf bepalen: de toelichting noemt een ISMS volgens de ISO 27000-reeks en een CSMS op basis van IEC 62443 als voorbeelden.

Praktisch betekent dat het volgende. Val je onder de wet, dan is een smalle ISO-scope prima als tussenstap, maar hij dekt je wettelijke plicht niet. Leg dan expliciet vast welk deel van je organisatie binnen het certificaat valt en welk deel wel onder de zorgplicht valt maar buiten de certificering, met een plan om dat verschil te verkleinen. Een auditor keurt dat niet af. Een toezichthouder die alleen het certificaat aantreft en de rest onbeschreven, wel.

De scope vastleggen en herzien

De scope is verplichte gedocumenteerde informatie. Houd hem kort, op één pagina, en zorg dat er zes dingen in staan: de diensten en processen die erin vallen, de organisatieonderdelen en locaties, de systemen en cloudomgevingen, de uitbestede activiteiten met wie ze uitvoert, wat er bewust buiten valt met de reden, en de raakvlakken tussen binnen en buiten.

Herzien doe je bij dezelfde gebeurtenissen die ook je risicobeoordeling opnieuw in gang zetten: een overname, een nieuwe dienst, een migratie naar een andere cloudleverancier, een reorganisatie of een klanteis die verder reikt dan je huidige grens. Hoe die twee op elkaar aansluiten staat in ons artikel over de risicoanalyse voor ISO 27001: de scope bepaalt wat je beoordeelt, en de uitkomst van de beoordeling laat soms zien dat de scope niet klopt.

Waar je vandaag mee begint

Schrijf in een uur op wat je primaire dienst is, wie ervan afhankelijk is en welke systemen ervoor nodig zijn. Trek daar een cirkel omheen en noteer per raakvlak met de buitenwereld wie er aan de andere kant zit. Dat is je concept-scope, en die is al beter dan de meeste sjablonen.

Voor het deel dat publiek zichtbaar is hoef je niets aan te nemen. Onze gratis domeinscan laat per domein zien hoe TLS, security headers, DNSSEC, e-mailbeveiliging en de rest van je buitenkant ervoor staan. Dat vertelt je meteen welke domeinen en diensten je in je scope over het hoofd zag, want een domein dat niemand meer beheert komt daar zichtbaar bovendrijven.