Welke informatie moet ik vastleggen voor de scope van ISO 27001?

Voor de scope van ISO 27001 moet je vastleggen welke onderdelen van de organisatie, welke informatiesystemen, welke processen en welke locaties onder het Information Security Management System (ISMS) vallen. Dit heet het toepassingsgebied of scopedocument. Een goed afgebakende scope is de basis van een succesvolle certificering: te breed maakt het onbeheersbaar, te smal maakt het ongeloofwaardig. In dit artikel beantwoorden we de meest gestelde vragen over het vastleggen van de ISO 27001-scope.

Wat valt er precies binnen de scope van ISO 27001?

De scope van ISO 27001 omvat alle organisatieonderdelen, processen, informatiesystemen en locaties waarop het ISMS van toepassing is. Je bepaalt zelf welke grenzen je trekt, maar die keuze moet aantoonbaar onderbouwd zijn en consistent zijn met de context en risico’s van je organisatie. De scope is vastgelegd in een scopedocument dat beschikbaar moet zijn voor auditors.

Concreet betekent dit dat je antwoord geeft op de volgende vragen:

• Welke organisatieonderdelen of afdelingen zijn inbegrepen?
• Welke locaties of vestigingen vallen binnen het toepassingsgebied?
• Welke producten of diensten worden gedekt door het ISMS?
• Welke interfaces en afhankelijkheden bestaan er met partijen buiten de scope?

De norm eist niet dat je de hele organisatie opneemt. Een zorginstelling kan er bijvoorbeeld voor kiezen om alleen de afdeling die patiëntgegevens verwerkt binnen scope te brengen. Wel moet je dan expliciet maken waarom andere onderdelen buiten scope vallen en hoe de grenzen worden bewaakt. Kijk je naar de ISO 27001-norm zelf, dan zie je dat clausule 4.3 precies beschrijft wat er van je wordt verwacht bij het bepalen van het toepassingsgebied.

Welke informatie over de organisatiecontext is verplicht?

ISO 27001 vereist dat je de organisatiecontext analyseert voordat je de scope definitief vaststelt. Dit betekent dat je zowel interne als externe factoren in kaart brengt die van invloed zijn op informatiebeveiliging, en dat je de relevante eisen van belanghebbenden (zoals klanten, toezichthouders en partners) documenteert.

Verplicht vast te leggen zijn:

• Interne context: organisatiestructuur, bedrijfsdoelstellingen, cultuur, bestaande systemen en processen
• Externe context: wet- en regelgeving (zoals de AVG), marktomgeving, ketenpartners, branchespecifieke normen
• Belanghebbenden: wie zijn de relevante partijen en wat zijn hun eisen ten aanzien van informatiebeveiliging?
• Grenzen van het ISMS: welke onderdelen zijn expliciet buiten scope gelaten en waarom?

Deze contextanalyse is geen formaliteit. Ze vormt de inhoudelijke onderbouwing van je scopekeuze. Auditors toetsen of de scope logisch volgt uit de beschreven context. Als je organisatie sterk afhankelijk is van cloudleveranciers of externe verwerkers, moet dat zichtbaar zijn in de contextbeschrijving en de scope.

Hoe bepaal je welke systemen en processen je opneemt?

Je bepaalt welke systemen en processen je opneemt door te kijken naar welke informatie wordt verwerkt, hoe gevoelig die informatie is en welke risico’s daarmee samenhangen. Systemen en processen die gevoelige of kritieke informatie verwerken, horen in principe binnen de scope. Systemen die volledig losstaan van die informatiestromen kunnen buiten scope blijven, mits je dat kunt onderbouwen.

Een praktische aanpak is om te starten met een informatie-inventarisatie: breng in kaart welke informatiestromen er zijn, waar die informatie wordt opgeslagen, wie er toegang toe heeft en welke systemen daarbij betrokken zijn. Vanuit die inventarisatie kun je redeneren welke systemen en processen je niet kunt weglaten zonder de betrouwbaarheid van je ISMS te ondermijnen.

Denk daarbij ook aan:

• Systemen van derde partijen die namens jou informatie verwerken (verwerkers)
• Cloudoplossingen en SaaS-applicaties die bedrijfskritische data bevatten
• Processen die raken aan klantgegevens, financiële informatie of persoonsgegevens
• Interfaces tussen interne systemen en externe partijen

Bij de implementatie van een ISMS is dit de fase waarin de meeste organisaties baat hebben bij externe begeleiding, omdat het overzicht van systemen en processen in de praktijk complexer is dan het op papier lijkt.

Wat moet er in het scopedocument zelf staan?

Het scopedocument is een formeel document dat beschrijft wat binnen het ISMS valt. Het moet voldoende detail bevatten om voor een auditor duidelijk te maken wat wel en niet gecertificeerd wordt. ISO 27001 stelt dat de scope beschikbaar moet zijn als gedocumenteerde informatie.

Een volledig scopedocument bevat minimaal:

1. Een beschrijving van de organisatie en haar activiteiten in relatie tot informatiebeveiliging
2. Het toepassingsgebied: welke afdelingen, locaties, processen en diensten zijn inbegrepen
3. Expliciete uitsluitingen: wat valt buiten scope en waarom
4. Relevante interfaces en afhankelijkheden met partijen buiten de scope
5. Een verwijzing naar de contextanalyse en de eisen van belanghebbenden

Het document hoeft niet lang te zijn, maar moet wel precies zijn. Vage omschrijvingen als “alle IT-systemen” of “de gehele organisatie” zijn onvoldoende als er ook onderdelen zijn die buiten scope vallen. Wees specifiek en gebruik waar mogelijk concrete namen van systemen, afdelingen of locaties.

Welke veelgemaakte fouten leiden tot een afkeurende audit?

De meest voorkomende fouten bij het vastleggen van de ISO 27001-scope zijn een te vage afbakening, inconsistentie tussen de scope en de rest van het ISMS, en het weglaten van onderdelen die feitelijk wel binnen de bedrijfsvoering vallen maar bewust buiten scope zijn gehouden zonder onderbouwing.

Specifieke fouten die auditors regelmatig tegenkomen:

• Scope en praktijk komen niet overeen: de scope beschrijft iets anders dan wat er in de organisatie daadwerkelijk wordt gedaan
• Uitsluitingen zijn niet onderbouwd: onderdelen zijn buiten scope gelaten zonder dat duidelijk is waarom dat verantwoord is
• Interfaces met externe partijen ontbreken: leveranciers of verwerkers die toegang hebben tot gevoelige informatie worden niet benoemd
• De scope is niet afgestemd op de contextanalyse: de beschreven risico’s en belangen rechtvaardigen de gekozen scope niet
• Het document is niet actueel: de scope is vastgesteld bij de start maar nooit bijgewerkt na organisatiewijzigingen

Een interne audit is een effectief middel om dit soort fouten op te sporen voordat de externe certificeerder langskomt. Via een interne audit kun je toetsen of het scopedocument aansluit op de werkelijkheid en of de rest van het ISMS consistent is met de gekozen afbakening. Zo voorkom je verrassingen tijdens de certificeringsaudit.

Hoe Kwinzo helpt bij het vastleggen van je ISO 27001-scope

Een goed doordachte en correct gedocumenteerde scope is de fundering van je hele ISMS. Wij helpen organisaties in zorg, ICT en onderwijs om die fundering stevig neer te zetten, zonder dat het proces onnodig complex of tijdrovend wordt.

Wat wij concreet voor je doen:

• We voeren een nulmeting uit om de huidige situatie, systemen en informatiestromen in kaart te brengen
• We begeleiden de contextanalyse en helpen je de juiste keuzes te maken over wat wel en niet binnen scope valt
• We stellen het scopedocument op dat voldoet aan de eisen van ISO 27001 en stand houdt bij een externe audit
• We toetsen de scope via een interne audit voordat de certificeerder langskomt
• We zorgen dat de norm aansluit op jouw bedrijfsvoering, niet andersom

Wil je weten hoe wij jouw organisatie kunnen begeleiden bij het ISO 27001-certificeringstraject? Neem dan contact met ons op via kwinzo.nl/contact voor een vrijblijvend adviesgesprek.