De ISO 27001 scope is de eerste echte beslissing in een certificeringstraject: welk deel van je organisatie valt onder het managementsysteem en welk deel niet. Die beslissing wordt vaak in tien minuten genomen en bepaalt daarna twee jaar aan werk, kosten en geloofwaardigheid. Begin bij de dienst die je klant afneemt, niet bij je organogram.
In het kort
- De scope legt vast welke processen, locaties, systemen en mensen onder je managementsysteem vallen.
- Hij staat letterlijk op je certificaat, dus je klant kan nalezen wat je hebt laten toetsen.
- Begin bij de dienst die je aan klanten levert, niet bij je afdelingen of je serverlijst.
- De scope is iets anders dan de Verklaring van Toepasselijkheid: de een bakent de organisatie af, de ander de maatregelen.
- In de praktijk wordt een te krappe scope vaker verruimd dan een te ruime ingeperkt.
Wat is de ISO 27001 scope precies?
De scope is de afbakening van je managementsysteem voor informatiebeveiliging. Hij beschrijft welke informatie je beschermt, in welke processen die informatie omgaat, op welke locaties dat gebeurt en welke systemen en mensen daarbij betrokken zijn.
De scope is geen intern document dat in een la verdwijnt. Hij staat op het certificaat zelf. Een klant die jouw certificaat opvraagt, leest daar precies wat er wel en niet is getoetst. Een certificaat met de scope “de financiële administratie op de hoofdvestiging” zegt niets over de softwaredienst die je diezelfde klant levert.
Waarom is de ISO 27001 scope zo bepalend?
Op drie manieren tegelijk.
- Werklast. Elk proces binnen de scope moet je beschrijven, van risico’s en maatregelen voorzien en aantoonbaar maken. Een extra locatie of afdeling is geen kleine toevoeging.
- Auditkosten. Certificerende instellingen bepalen hun audittijd mede op het aantal medewerkers en locaties. Met drie locaties in scope duurt de externe audit al snel meerdere dagen, waar de interne audit soms in één dag past.
- Geloofwaardigheid. Inkopers kijken of de dienst die zij afnemen daadwerkelijk binnen de scope valt. Een certificaat dat formeel klopt maar de geleverde dienst niet dekt, roept meer vragen op dan geen certificaat.
Wat neem je wel en niet mee?
Processen
Begin hier, en niet bij je afdelingen. Welke diensten lever je, en welke processen zijn nodig om die te leveren? Ondersteunende processen als HR en inkoop horen erbij zodra ze de beveiliging raken, en dat doen ze bijna altijd: HR regelt in- en uitdiensttreding, inkoop selecteert leveranciers.
Locaties
Kantoren, datacenters, thuiswerkplekken. Thuiswerken wordt regelmatig vergeten omdat het geen adres heeft, terwijl het voor de meeste organisaties de plek is waar het meeste werk gebeurt. Zit je in een gedeeld bedrijfsgebouw, dan heb je de fysieke beveiliging maar deels zelf in handen. Leg dan vast wat de gebouwbeheerder regelt, bijvoorbeeld via diens servicevoorwaarden.
Systemen en data
Welke systemen ondersteunen de processen binnen de scope, en welke gegevens staan daarin? Cloudplatforms horen erbij, ook al beheer je ze niet zelf. Niet beheren is niet hetzelfde als niet verantwoordelijk zijn.
Mensen en leveranciers
Vaste medewerkers, maar ook inhuur, stagiairs en beheerders van je IT-partij. Leveranciers vallen niet ín je scope, maar de manier waarop je ze beheerst wel.
Wat zien we in de praktijk?
In de GAP-analyses en implementaties die we begeleiden, komen een paar patronen steeds terug.
De ISO 27001 scope groeit tijdens het traject. Organisaties beginnen vaak met één product of één dienst, omdat dat het kleinst en dus het makkelijkst lijkt. Halverwege blijkt dat processen, mensen en systemen gedeeld worden met de rest. In een van de trajecten ging de scope daarom van één product naar alle softwareontwikkeling: één organisatiebrede afbakening bleek eenvoudiger te certificeren dan een grens die dwars door het team liep.
De scope en de Verklaring van Toepasselijkheid worden door elkaar gehaald. Niet elk thema uit de norm hoort bij elke organisatie. Ontwikkelt een organisatie zelf geen software, dan sluit je die maatregelen uit in de Verklaring van Toepasselijkheid. Dat is iets anders dan de scope verkleinen, en de verwarring kost in de eerste sessies vaak onnodig tijd.
De rechtspersoon bepaalt meer dan verwacht. Bij groepen is de eerste vraag welke bv eronder valt. Soms verschuift daardoor zelfs de norm: in een van de gesprekken bleek de activiteit waarvoor een sectornorm bedoeld is in een andere rechtspersoon te zitten, en werd de scope ISO 27001 in plaats van die sectornorm.
De scope wordt bepaald in de eerste sessie, niet in de laatste. Bij ons komt de afbakening aan bod in de GAP-analyse en in de eerste implementatiesessie, samen met de context en de belanghebbenden. Wie hem pas vlak voor de audit scherp stelt, moet werk overdoen.
Hoe bepaal je de scope stap voor stap?
- Benoem de dienst. Waar wil je een certificaat voor kunnen laten zien? Dat is meestal een klantvraag, dus begin bij die vraag.
- Volg de informatie. Waar komt die binnen, waar wordt hij verwerkt en opgeslagen, waar verlaat hij de organisatie?
- Teken de grens. Alles wat je bij stap twee tegenkwam, hoort binnen de scope.
- Toets de raakvlakken. Kan iets van buiten de scope de beveiliging binnen de scope aantasten? Zo ja, haal het erbij.
- Formuleer hem in één alinea. Lukt dat niet, dan is de afbakening nog niet scherp.
- Leg hem voor aan je certificerende instelling. Doe dat vóór de implementatie, niet erna.
Weet je nog niet waar je staat, dan is een GAP-analyse een goede eerste stap. Die maakt meteen zichtbaar welke processen en systemen er echt toe doen.
Welke fouten maken organisaties bij het afbakenen?
- De scope op de organisatiestructuur baseren. Afdelingen veranderen, processen blijven.
- Ontwikkeling eruit laten. Bij softwarebedrijven is dat precies het proces waar de klant naar vraagt.
- Een uitsluiting nemen zonder onderbouwing. Elk deel dat je eruit laat, moet aantoonbaar geen invloed hebben op wat erbinnen valt.
- Alles meenemen “voor de zekerheid”. Dat verdubbelt de werklast zonder dat een klant er iets aan heeft.
De laatste twee zijn twee kanten van dezelfde medaille: onzekerheid over wat er echt toe doet. Daarom schreven we eerder dat compliance geen beveiliging is. De scope is de plek waar dat verschil ontstaat.
Kun je de ISO 27001 scope later uitbreiden?
Ja, en vaak is dat de verstandigste route. Je begint met de dienst waar de meeste klantvraag op zit, bouwt daar een werkend managementsysteem omheen en breidt daarna uit. Een uitbreiding wordt beoordeeld tijdens een controleaudit of een aparte uitbreidingsaudit. Dat kost minder dan een eerste implementatie, omdat het systeem er dan al staat.
Hoe zo’n traject in de praktijk loopt, staat bij ISO 27001-implementatie. Wat er in de norm staat en hoe certificering werkt, lees je op onze pagina over ISO 27001.
Veelgestelde vragen
Mag ik één afdeling certificeren en de rest niet?
Ja, dat mag. De voorwaarde is dat de rest van de organisatie geen invloed heeft op de beveiliging binnen de scope, en dat je dat kunt onderbouwen. In de praktijk blijkt die scheiding lastiger dan gedacht, vooral bij gedeelde ICT.
Moet mijn cloudleverancier binnen de ISO 27001 scope vallen?
Nee, een leverancier valt niet binnen jouw scope. Wel valt de manier waarop jij die leverancier beheerst eronder: contractafspraken, toegangsbeheer en het toetsen of hij zijn afspraken nakomt.
Wat is het verschil tussen de scope en de Verklaring van Toepasselijkheid?
De scope bepaalt welk deel van de organisatie onder het managementsysteem valt. De Verklaring van Toepasselijkheid bepaalt welke beheersmaatregelen binnen die scope van toepassing zijn. Ontwikkel je zelf geen software, dan sluit je die maatregelen uit in de verklaring; je scope wordt daar niet kleiner van.
Wat kost een bredere scope?
Vooral interne tijd. De audittijd stijgt met het aantal medewerkers en locaties, maar de grootste kostenpost is het beschrijven, invoeren en aantoonbaar maken van meer processen.
Kan een auditor mijn scope afwijzen?
Een certificerende instelling kan concluderen dat een afbakening niet houdbaar is, bijvoorbeeld als een uitgesloten deel duidelijk invloed heeft op de beveiliging binnen de scope. Leg je scope daarom vroeg voor, niet vlak voor de audit.
