Scope är oftast det första riktiga stoppet när ett företag börjar jobba med ISO 27001. Ledningen har fattat beslutet, någon har fått ansvaret, och sedan händer det. Frågan om vad som egentligen ska ingå i ledningssystemet lägger sig som en våt filt över hela projektet.
Det händer nästan alltid av samma anledning. Man tror att scope är en gräns man ska rita upp innan man vet vad man ritar runt. Så sätter man sig i ett konferensrum, tittar på ett organisationsschema och försöker peka ut avdelningar. Det brukar inte gå särskilt bra.
Jon Solheim, informationssäkerhetskonsult och revisor som jobbat med ledningssystem sedan 2014, brukar säga det ganska rakt:
”Man bygger inte ett scope, utan man definierar ett scope man redan har. Att bygga ett ledningssystem för informationssäkerhet handlar om att fundera på vad det är vi vill skydda. Vad ska vara fokus för våra ansträngningar?”
Skillnaden låter kanske hårfin, men den förändrar hela hur man ska angripa problemet.
Vad är scope i ISO 27001, egentligen?
Scope, eller tillämpningsområde som det heter på svenska i standarden, är den avgränsning som beskriver vad ditt ledningssystem för informationssäkerhet faktiskt omfattar. Det handlar om vilken information, vilka system, vilka processer och vilka delar av organisationen som är med.
Det låter enkelt på pappret. I praktiken är det den fråga flest organisationer fastnar på, för att den kräver att man svarar på något djupare först: vad är det egentligen vi håller på med, och vad av det behöver skyddas?
Om du inte kan svara på den frågan tydligt kommer scopet aldrig kännas riktigt rätt.
Så hittar du ditt scope i praktiken
Börja med det du faktiskt vill skydda
Första steget är inte att rita en gräns. Det är att ställa en enkel fråga och faktiskt svara ärligt på den: vad är det vi vill skydda?
Svaret varierar väldigt mycket beroende på vilken typ av verksamhet du driver. Ett vårdbolag kanske svarar patientdata. Ett mjukvarubolag svarar ofta källkod eller kunddata i sin plattform. Ett tillverkningsbolag kan landa i ritningar, avtal med leverantörer eller information kopplad till en särskild produktionslinje. Är ni en samhällsviktig verksamhet kan svaret handla om en specifik kritisk tjänst snarare än ett visst dataslag.
Poängen är att det inte finns ett rätt svar som passar alla. Det finns bara ert svar, och det måste komma från er egen verksamhet.
Följ informationen ett steg till, sedan ett till
Här är det många som stannar för tidigt. Att säga ”vi vill skydda personuppgifter” räcker inte. Nästa fråga är var de lagras. Sedan vem som har tillgång till dem. Sedan vilka leverantörer som tar del av dem, och i vilka system den informationen passerar på vägen.
Ganska snabbt växer det fram en kedja. System A pratar med system B via en integration som sköts av en extern leverantör. Den leverantören har i sin tur en underleverantör som hostar servrarna. Informationen finns kanske också i ett CRM som marknadsavdelningen använder, och i en Excel-fil någon säljare sparat lokalt (vilket förresten också säger något om var ni behöver jobba, men det är en annan artikel).
Det är den här kedjan, systemen, leverantörerna, platserna och processerna som informationen faktiskt rör sig genom, som blir ert scope. Inte de avdelningar ni tänkte er i förväg. Ofta blir resultatet en annan avgränsning än den ni hade i huvudet när ni började, och det är helt normalt.
”Man följer informationen vidare, ett eller flera steg ner, och helt plötsligt börjar man plita ner: den här informationen delar vi med den leverantören, den finns i det systemet, den lagras på den servern. Plötsligt får man en kedja med lite olika entiteter, leverantörer, mjukvaror och olika fysiska platser.”
Låt inte lagen ensam bestämma vad som ska in
En sak som förvånar många: allt behöver inte in i scopet bara för att lagen kräver skydd för det. Personuppgifter är det tydligaste exemplet. Ni är skyldiga enligt GDPR att skydda dem, men det måste inte ske genom just ert ISO 27001-ledningssystem. Det går utmärkt att hantera dataskyddsfrågor separat, om ni av någon anledning vill göra det.
Det här är värt att komma ihåg innan ni per automatik drar in varje system som rör personuppgifter i scopet, bara för att någon läst att GDPR kräver det. Standarden och lagen är två olika saker som kan, men inte måste, hänga ihop i just er organisation.
Scope när ni är en koncern med flera bolag
Det här är frågan som gör att många fastnar helt, och den kommer alltid upp förr eller senare i lite större organisationer. Ska hela koncernen in i scopet? Bara ett bolag? Ett urval?
Ett vanligt och fungerande sätt att börja, särskilt om ni är nya på ledningssystem, är att avgränsa scopet till den centrala organisationen. Ofta är det där kundinformationen faktiskt ägs och hanteras. Dotterbolag på andra platser i världen kan då i stället behandlas som intressenter, ungefär som samarbetspartners som behöver leva upp till vissa regler för att få jobba tillsammans med moderbolaget.
Fördelen är rent praktisk. En revisor behöver inte flyga runt till varje dotterbolag i varje land för att certifiera hela härligheten.
”Dotterbolagen blir som samarbetspartners, och då behöver inte en revisor åka ut till alla de här platserna. Man måste i stället visa att man har hanterat de risker som det innebär att samarbeta med sina dotterbolag, vilka risker det nu än kan vara.”
I stället visar ni att ni har identifierat och hanterat de risker som uppstår i just det samarbetet, till exempel genom avtal, riktlinjer eller tekniska kontroller mot dotterbolagen.
Ett sätt att tänka på det är hur en franchisekedja fungerar.
”Man kan jämföra det med McDonald’s. Det finns en central organisation som bestämmer till punkt och pricka i minsta detalj hur alla restauranger ska se ut, hur lång tid det ska ta att laga en hamburgare, hur hög disken ska vara, vilken musik som ska spelas. Vill du driva en McDonald’s-restaurang så gäller det att du följer de här reglerna.”
Samma princip går att applicera på hur en koncern styr sina bolag, oavsett om det handlar om informationssäkerhet eller något annat.
Att ta hela koncernen i ett enda scope går också, rent tekniskt. Men det blir sällan smidigt. Fler länder, fler system, fler människor att prata med, fler lokala lagar att ta hänsyn till. De flesta organisationer vinner på att börja med ett mindre, hanterbart scope och sedan låta det växa i takt med att ledningssystemet mognar och organisationen blir bekväm med arbetssättet.
Påverkar ny lagstiftning som NIS2 hur ni ska sätta scope?
Kort svar: ja, men inte på det sätt många tror.
Om ni bedriver samhällsviktig verksamhet går det faktiskt att bygga ett ledningssystem som helt utesluter den kritiska tjänsten från scopet. Ni kan certifiera er ändå, standarden hindrar er inte. Men en tillsynsmyndighet enligt exempelvis NIS2 kommer knappast bli imponerad, eftersom ni då inte har styrt informationssäkerheten kring det som faktiskt gör er samhällsviktiga. Ni får ett certifikat, men missar hela nyttan med övningen.
Lagstiftningen säger med andra ord aldrig att ni måste certifiera er enligt ISO 27001. Den säger att ni ska förstå vad som är skyddsvärt och hantera riskerna kring det, på ett sätt ni kan visa upp. ISO 27001 råkar vara ett väldigt bra verktyg för just det, men det är fortfarande bara ett verktyg bland flera möjliga.
Scope handlar om att prioritera bort, inte bara prioritera in
Här kommer den poäng som förmodligen är viktigast av allt, och den som lätt går förlorad när man är mitt i arbetet: ISO 27001 är i grunden ett verktyg för att prioritera. Lika mycket ett verktyg för att välja bort, som för att välja in.
Att försöka skydda allt är varken möjligt eller ens önskvärt för de flesta organisationer. Det finns inte resurser till det, och ärligt talat behövs det oftast inte heller. Ett bra scope tvingar er att göra skillnad på vad som är viktigt och vad som inte är det, och den skillnaden måste kännas rimlig för resten av organisationen. Om ledningsgruppen eller de som faktiskt jobbar med informationen inte litar på hur ni har dragit gränserna, spelar det ingen roll hur snyggt scopet är formulerat på pappret. Riskbedömningarna och åtgärderna som byggs ovanpå det blir aldrig träffsäkra, eftersom hela grunden saknar förankring.
Dokumentera scopet så det håller för en revision
När ni väl har landat i ett scope behöver det skrivas ner, kort och konkret. Standarden kräver att ni har ett dokumenterat tillämpningsområde, och det brukar hänga ihop nära med er Statement of Applicability, listan över vilka av standardens kontroller som är relevanta för just ert scope.
Håll det korta dokumentet just kort. Ett par sidor räcker gott. Beskriv vilken information, vilka system, vilka platser och vilka delar av organisationen som ingår, och lika viktigt, vad som medvetet inte ingår och varför. Den sista delen glöms lätt bort, men den är minst lika viktig för en revisor som vill förstå era resonemang.
Vanliga frågor om scope i ISO 27001
Vad är scope i ISO 27001?
Scope är avgränsningen av vilken information, vilka system, leverantörer och delar av organisationen som ert ledningssystem för informationssäkerhet omfattar. Det bestäms utifrån vad som faktiskt behöver skyddas i er verksamhet, inte utifrån en godtycklig gräns på ett organisationsschema.
Måste hela företaget ingå i scopet?
Nej. Ni kan avgränsa scopet till en del av organisationen, till exempel en central enhet i en koncern, och hantera resten av bolagen som intressenter eller samarbetspartners som behöver följa vissa regler.
Kan man ändra scope i efterhand?
Ja, och de flesta gör det. Scope är inget ni sätter en gång för alla vid start. Vanligast är att börja med ett mindre scope och utöka det efter hand som ledningssystemet mognar och organisationen känner sig mer bekväm med arbetssättet.
Hur lång tid tar det att sätta scope?
Det varierar kraftigt beroende på hur komplex organisationen är, men räkna med att det tar längre tid än ni tror första gången ni gör det. Att faktiskt följa informationskedjan genom system och leverantörer tar tid, och det är tid väl spenderad jämfört med att gissa sig fram.
Nästa gång ni sätter er för att diskutera scope, lämna organisationsschemat därhemma. Börja i stället med informationen ni faktiskt hanterar varje dag och följ den dit den leder, genom systemen, leverantörerna och platserna. Gör ni det ordentligt kommer scopet i ert ISO 27001-arbete i princip visa sig självt, i stället för att bli en punkt ni bråkar om i tre möten innan någon till slut ger upp och sätter en gräns bara för att komma vidare.
