ISO 27001 scope bepalen: wat neem je wel en niet mee?

De eerste echte beslissing in een certificeringstraject is de ISO 27001 scope: welk deel van je organisatie valt onder het managementsysteem en welk deel niet. Die beslissing wordt vaak in tien minuten genomen en bepaalt vervolgens twee jaar aan werk, kosten en geloofwaardigheid.

Te ruim afbakenen maakt het traject onnodig zwaar. Te krap afbakenen levert een certificaat op waar je klant niets aan heeft, en dat wordt tegenwoordig ook gecontroleerd. In dit artikel loop ik langs wat de scope precies is, hoe je hem bepaalt en waar het misgaat.

Kort samengevat

• 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 organogram of je serverlijst.
• Uitsluiten mag, maar alleen als de uitgesloten delen geen invloed hebben op de beveiliging binnen de scope.
• Je kunt later uitbreiden; dat is bijna altijd goedkoper dan meteen alles meenemen.

Wat is de scope van ISO 27001 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.

Belangrijk om te beseffen: 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 voorzien, van maatregelen voorzien en aantoonbaar maken. Een extra locatie of afdeling is geen kleine toevoeging.
• Auditkosten. Certificerende instellingen bepalen hun audittijd mede op basis van het aantal medewerkers en locaties binnen de scope.
• Geloofwaardigheid. Dit weegt op termijn het zwaarst. Inkopers zijn scherper geworden en kijken of de dienst die zij afnemen daadwerkelijk binnen de scope valt.

Dat laatste punt zie ik steeds vaker terugkomen in aanbestedingen. 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 grootste deel van het werk gebeurt.

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

Vaste medewerkers, maar ook inhuur, stagiairs en beheerders van je IT-partij. Iedereen met toegang tot informatie binnen de scope valt eronder.

Leveranciers

Leveranciers vallen niet ín je scope, maar de manier waarop je ze beheerst wel. Je moet kunnen laten zien dat je weet welke partijen toegang hebben en welke afspraken daarover zijn gemaakt.

Hoe bepaal je de scope stap voor stap?

1. Benoem de dienst. Waar wil je een certificaat voor kunnen laten zien? Dat is meestal een klantvraag, dus begin bij die vraag.
2. Volg de informatie. Waar komt de informatie binnen, waar wordt hij verwerkt, waar opgeslagen, waar verlaat hij de organisatie?
3. Teken de grens. Alles wat je bij stap twee tegenkwam, hoort binnen de scope. Wat je niet tegenkwam, kan erbuiten.
4. Toets de raakvlakken. Bij elk raakvlak met een uitgesloten deel: kan iets van buiten de scope de beveiliging binnen de scope aantasten? Zo ja, dan haal je het erbij.
5. Formuleer hem in één alinea. Lukt dat niet, dan is de afbakening nog niet scherp.
6. 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 eigenlijk toe doen.

Welke fouten maken organisaties bij het afbakenen?

• De scope op de organisatiestructuur baseren. Afdelingen veranderen, processen blijven. Een scope op afdelingsnamen veroudert binnen een jaar.
• Ontwikkeling eruit laten. Bij softwarebedrijven is dat precies het proces waar de klant naar vraagt.
• Thuiswerkplekken vergeten. Formeel buiten beeld, feitelijk de belangrijkste werkplek.
• 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.

Deze laatste twee zijn twee kanten van dezelfde medaille: onzekerheid over wat er echt toe doet. Dat is ook precies waarom we eerder schreven dat een certificaat geen garantie is dat je echt beveiligd bent. De scope is de plek waar dat verschil ontstaat.

Kun je de scope later uitbreiden?

Ja, en in veel gevallen 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 naar andere processen of locaties.

Een uitbreiding wordt beoordeeld tijdens een controleaudit of via een aparte uitbreidingsaudit. Dat kost tijd, maar aanzienlijk minder dan een eerste implementatie, omdat het systeem er dan al staat. Bovendien leer je van de eerste ronde, en dat maakt de tweede sneller.

Wil je weten hoe zo’n traject in de praktijk loopt, dan hebben we de aanpak van ISO 27001-implementatie apart beschreven.

Veelgestelde vragen over de ISO 27001 scope

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 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.

Waar staat de scope in mijn documentatie?

De norm eist de scope als vastgelegde informatie, meestal in het beleidsdocument of in een apart scopedocument. Hij komt daarnaast letterlijk op het certificaat te staan.

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.