Scope bepalen voor ISO 27001
De scope van je ISMS beschrijft waarvoor ISO 27001 van toepassing is: welke onderdelen van je organisatie, welke locaties, diensten en systemen. De scope is het eerste wat de auditor beoordeelt en de basis voor alles wat daarna komt. Een te brede scope maakt het traject onnodig complex; een te smalle scope levert een certificaat op dat klanten niet overtuigt. De norm is verkrijgbaar via NEN en behandelt de scope in hoofdstuk 4.3.
Een goede scope is logisch, verdedigbaar en afgestemd op wat je klanten van je verwachten. In dit artikel lees je hoe je de scope bepaalt, welke fouten je moet vermijden en hoe een scopestatement eruitziet.
Wat is de scope van een ISMS?
De scope is het officieel vastgelegde toepassingsgebied van je managementsysteem. Wat valt eronder, en wat niet? ISO 27001 eist dat je de scope documenteert en dat die beschikbaar is voor de auditor en voor belanghebbenden.
Je bepaalt de scope op basis van drie vragen uit hoofdstuk 4 van de norm:
- In welke context opereert de organisatie? (interne en externe factoren)
- Wat verwachten de belanghebbenden, met name klanten?
- Welke grenzen zijn logisch gegeven de activiteiten en interfaces?
De scope moet grenzen bevatten. Benoem wat erin zit én wat erbuiten valt. “Het ISMS is van toepassing op alle activiteiten” is geen bruikbare scope; “Het ISMS is van toepassing op de ontwikkeling en levering van ons SaaS-platform, inclusief de bijbehorende infrastructuur en ondersteuningsprocessen” wel.
Hoe baken je de scope af?
Je kunt een scope definiëren langs vier assen: locaties, diensten of producten, processen en systemen. Combineer ze zoals het bij jouw organisatie past.
| As | Voorbeeld: klein IT-bedrijf | Voorbeeld: logistiek bedrijf |
|---|---|---|
| Locaties | Kantoor Amsterdam, remote werkomgeving | Distributiecentrum Utrecht, vestiging Rotterdam |
| Diensten/producten | SaaS-platform voor HR-software | Transport- en opslaan van goederen voor derden |
| Processen | Softwareontwikkeling, klantondersteuning | Orderverwerking, magazijnbeheer |
| Systemen | Productie-omgeving in AWS, ticketing-systeem | Warehouse management system, transportplanningssoftware |
Scope voor een heel bedrijf versus een afdeling
Je kunt kiezen voor een smalle scope (één product of afdeling) of een brede scope (de hele organisatie). Beide zijn geldig, mits consistent en verdedigbaar.
Smalle scope is verstandig als:
- Je snel wilt certificeren voor een specifieke klantvraag
- Je organisatie grote, complexe onderdelen heeft die nog niet klaar zijn
- Je wilt leren van een eerste certificering voordat je uitbreidt
Brede scope is logisch als:
- Klanten verwachten dat de hele organisatie gecertificeerd is
- Je informatiestromen niet goed te splitsen zijn tussen afdelingen
- Je al een goed beveiligingsniveau hebt in de hele organisatie
Wat mag je uitsluiten?
Je mag onderdelen uitsluiten, maar alleen als ze geen invloed hebben op de informatiebeveiliging van wat wel in scope is. Als je de klantenservice buiten scope laat terwijl die medewerkers toegang hebben tot gevoelige klantgegevens die wél in scope zijn, is dat niet verdedigbaar. De auditor toetst dit kritisch.
Voorbeelden van scope-statements
De tabel geeft scope-statements voor verschillende typen organisaties. Gebruik ze als inspiratie, niet als template.
| Type organisatie | Voorbeeld scopestatement |
|---|---|
| SaaS-bedrijf (15 fte) | “De scope omvat de ontwikkeling, het testen en de levering van het cloudplatform, inclusief de ondersteunende infrastructure in AWS eu-west-1 en de bijbehorende ondersteuningsprocessen.” |
| IT-dienstverlener (60 fte) | “De scope omvat alle managed services die worden geleverd vanuit het kantoor in Amsterdam en de productie-omgeving in Azure, exclusief de interne HR- en financiële administratie.” |
| Accountantskantoor (30 fte) | “De scope omvat de verwerking en opslag van cliëntgegevens voor audit- en adviesdiensten, inclusief de bijbehorende digitale werkplekken en cloudopslag.” |
| Productiebedrijf (200 fte) | “De scope omvat de IT-infrastructuur van de afdeling Operations en de hierop aangesloten productiesystemen op de locatie Tilburg, exclusief de kantoorlocatie Den Haag.” |
Veelgemaakte fouten bij de scope
Te breed beginnen
Een scope die “de hele organisatie” omvat terwijl je net begint, is ambitieus maar risicovol. Elke afdeling, elk systeem, elke locatie komt dan in scope. Dit verhoogt de complexiteit en de kosten drastisch.
Logische grenzen negeren
De scope moet logisch zijn. Als je klantenservicemedewerkers klantdata verwerken, maar de klantenservice “niet in scope” is, vraagt de auditor hoe je de beveiliging van die data dan waarborgt. Je kunt dan niet verwijzen naar je ISMS, want dat is niet van toepassing op die afdeling.
Geen aandacht voor interfaces
Systemen en processen raken aan systemen en processen buiten de scope. Hoe beveilig je die grens? Als je cloudplatform in scope is maar de VPN-verbinding ermee niet, hoe bescherm je de toegang dan? Beschrijf deze interfaces in je scopedocument.
De scope niet bijhouden
Je start met een scope voor een specifiek platform. Twee jaar later heb je een nieuw product gelanceerd en een overname gedaan. De scope beschrijft nog steeds de situatie van twee jaar geleden. De auditor constateert dat de scope niet meer aansluit bij de werkelijkheid.
Herzie je scope bij elke significante verandering in de organisatie. Een overname, een nieuw product of een verhuizing kunnen reden zijn om de scope bij te werken.
Interfaces en uitsluitingen documenteren
ISO 27001 vraagt dat je interfaces (grenzen met de buitenwereld) en uitsluitingen beschrijft in het scopedocument. Dit zijn de plekken waar informatie de scope inkomt of verlaat.
Typische interfaces:
- Leveranciers die toegang hebben tot systemen in scope
- Klanten die data aanleveren aan systemen in scope
- Systemen buiten scope die data uitwisselen met systemen in scope
Voor elke interface beschrijf je kort hoe je de beveiliging borgt. Gebruik hierbij de maatregen uit je risicoanalyse en verwijs naar het relevante beleid of de procedure.
Scope bepalen en het stappenplan
De scope stel je vast in fase 1 van het implementatietraject, voordat je aan de nulmeting en gap-analyse begint. Zonder vastgestelde scope weet je niet welke processen, systemen en risico’s in scope vallen, en dus ook niet welke kloof er is met de norm.
Pas de scope niet te lichtvaardig aan als het traject al loopt. Scope-uitbreidingen halverwege verhogen de werkdruk en kunnen leiden tot een herstart van de gap-analyse.
Meer informatie
- Eisen van de norm — Hoofdstuk 4.3 over de scope
- Nulmeting en gap-analyse — Volgt direct na de scope
- Stappenplan — De scope in het totale traject
- Risicoanalyse — Risico’s bepaal je binnen de scope
- Het ISMS — De scope als startpunt van het ISMS
- ISO/IEC 27001:2022 — Clausule 4.3 (ISO.org)