Rickard spanar:
Det tog 250 risker att förstå ISO 27001
28 oktober 2026

När vi bestämde oss för att certifiera Any4m var min förväntan att det mesta skulle handla om policies. Det visade sig vara helt fel.
Varför vi började
Jag hade en förenklad bild av vad som väntade när vi besämde oss för att certifiera Any4m enligt ISO 27001. Jag trodde att det framför allt skulle handla om att skriva dokument, få ordning på policyer och rutiner och till slut visa en revisor att vi hade gjort det som krävdes.
Certifikatet var ändå inte anledningen till att vi började. Vi bygger stora och avancerade system åt våra kunder, och vi har ett stort ansvar för att de är säkra. Vi tror också att AI kommer att förändra förutsättningarna för cybersäkerhet rejält. Samma utveckling som gör det snabbare för oss att bygga programvara gör det också enklare att leta efter och utnyttja svagheter.
Vi tog hjälp av Komply.One för att vägleda oss genom processen, och snart började vår bild av ISO 27001 förändras. Visst finns det mycket som ska dokumenteras. Men det verkliga arbetet handlar om att undersöka sin egen verksamhet och förstå vad som kan gå fel.
Över 250 risker
Det första vi gjorde var därför att fråga alla på bolaget vad de använder under en vanlig arbetsdag. Vilka system loggar du in i? Vilka tjänster använder du? Vilken information arbetar du med? Vilka andra resurser behöver du för att kunna göra ditt jobb?
Frågan var enkel: Vad använder du på dagarna?
Svaren gav oss en bild av verksamheten som den faktiskt är, inte som vi trodde att den var. Utifrån den började vi identifiera risker för varje system och resurs.
När vi var klara hade vi över 250 risker. Det var då vi på riktigt förstod vad vi hade gett oss in på.
Första reaktionen var att det här aldrig skulle fungera. Att förstå, bedöma och besluta om åtgärder för mer än 250 risker skulle ta hur lång tid som helst. Vi började direkt fundera på om AI kunde göra större delen av jobbet åt oss.
En timme i taget
I stället gjorde vi något betydligt mindre avancerat.
Vi samlade en fokusgrupp och bokade 60 minuter. Först tog vi de risker som vi utan diskussion kunde konstatera var de allvarligaste. Då hade vi plötsligt en skala att förhålla oss till och kunde välja ut nästa grupp, som var något mindre allvarlig. Sedan nästa.
När vi fastnade hoppade vi över risken i stället för att låta hela mötet försvinna i en diskussion. Ibland fick någon ta med sig en risk och undersöka den till nästa gång, eftersom den handlade om ett arbetssätt som just den personen kunde bäst.
Efter en timme slutade vi. Till vår förvåning hade vi kommit långt.
Det förändrade hela arbetet. I stället för en lista med 250 risker som skulle bli färdig såg vi ett arbete som gick att flytta framåt steg för steg. Genom att börja med de farligaste riskerna förstod vi också vad som var allvarligt och vad som kunde vänta. Att se att vi kom framåt gav energi.
I dag lägger vi ungefär tre timmar i veckan på ISO-arbetet. Vi går igenom risker, förbättrar rutiner, stänger aktiviteter och dokumenterar bevis inför revisionen. Vi försöker inte göra allt samtidigt. Målet är att verksamheten ska vara lite bättre efter varje vecka.
Det låter självklart i efterhand, men det är en av våra viktigaste lärdomar. När ett projekt känns stort är det lätt att lägga mycket energi på att hitta ett smart sätt att lösa hela problemet på en gång. För oss har det fungerat bättre att acceptera att vi inte kan göra allt, och i stället hela tiden ta nästa steg.
Mer än dokument
Nästa stora pusselbit föll på plats när vi började arbeta med Annex A, den del av standarden som listar de säkerhetskontroller en organisation ska ta ställning till.
Fram till dess hade risker, dokument och rutiner känts som separata delar. När vi gick igenom kontrollerna blev sambanden tydliga. En kontroll pekade tillbaka på hur vi hade bestämt att vi skulle arbeta. Våra rutiner behövde gå att förklara utifrån de risker och krav vi hade identifierat, och vi behövde kunna visa att vi gjorde det vi hade bestämt.
Det var där jag förstod varför ISO 27001 inte går att reducera till ett antal dokument.
En policy kan vara hur välskriven som helst, men den betyder lite om organisationen inte arbetar som det står i den. För oss handlar ISO-arbetet därför allt mindre om att producera dokument, och allt mer om att bestämma vilka krav vi ställer på oss själva och sedan få det dagliga arbetet att leva upp till dem.
Säkert från början
Det har fått konkreta konsekvenser i vår utveckling.
Det är lätt att tänka ”det här är bara ett test, vi gör det ordentligt senare”. En tillfällig hemlighet, till exempel ett lösenord eller en nyckel till en tjänst, skapas och sparas lokalt på någons dator. Tanken är att den ska flyttas till ett valv, en skyddad lagring för just sådana uppgifter, när lösningen blir mer permanent.
Så gör vi inte längre. Hemligheter läggs i valv från början, även när det bara är ett test. Det är ibland mindre smidigt, men vi bygger hellre säkert från början än hoppas att vi kommer ihåg det senare.
Fler perspektiv än våra egna
Samtidigt har vi upptäckt att våra egna riskbedömningar bara är en del av helheten. Vi arbetar med kunder i hårt reglerade verksamheter, inte minst inom bank, där kraven i till exempel NIS2 och DORA kan gå betydligt längre än det vi själva kom fram till.
Ibland blir skillnaden nästan komisk. Vi är i princip helt digitala, men kan ändå behöva hantera krav på något så analogt som en dokumentförstörare.
Poängen är inte dokumentförstöraren. Poängen är att vi behöver hålla ihop flera perspektiv: våra egna risker, kraven i ISO 27001, våra interna rutiner och de krav vi har lovat kunderna att uppfylla. När vi såg de sambanden blev det tydligt varför ett ledningssystem behöver stödja mycket mer än dokument.
Därför gör vi ISO-arbetet i vårt eget ledningssystem, samma ledningssystem som våra kunder använder. Det vi hade underskattat var hur många typer av information som behöver hänga ihop när arbetet görs ordentligt. Risker, resurser, kontroller, rutiner, kundkrav och bevis behöver gå att följa som delar av samma helhet. Det är också ett bra test av vår egen teknik: det vi bygger för kunderna använder vi själva.
Vad AI kan, och inte kan
Naturligtvis använder vi AI i arbetet.
När vi identifierar en resurs låter vi AI hjälpa oss att tänka igenom vilka risker som kan finnas. Vi använder den för att analysera om policyer och rutiner hänger ihop, för att gå igenom kundkrav och för att ställa många frågor om ISO 27001.
Men vi har också upptäckt en viktig begränsning: AI är inte med på våra morgonmöten.
Den vet inte hur mycket som händer samtidigt i ett utvecklingsbolag, och den känner inte människorna som ska följa rutinerna. Vi har personer som är innovativa och gärna rör sig snabbt, och andra som är fantastiska på struktur och på att följa en process. Ett arbetssätt som fungerar hos oss måste fungera för båda.
AI är bra på att hitta risker, se samband och föreslå sådant vi borde tänka på. Men den kan inte avgöra hur informationssäkerheten ska fungera tillsammans med utveckling, kundprojekt, support och allt annat som ska hinnas med under en vecka. Den delen måste vi lösa själva.
Inför revisionen
Nu närmar vi oss vår första internrevision, och känslan inför den är en helt annan än jag hade föreställt mig. Jag trodde att en revision främst skulle kännas som ett prov, där någon kommer för att hitta fel.
I dag ser vi fram emot att någon utifrån går igenom vårt arbete och pekar på det vi själva har missat.
Målet är att bli certifierade i år. Men ju längre vi kommer, desto mindre känns certifikatet som slutmålet. Det viktigaste är att vi arbetar på ett nytt sätt och har hittat en metod för att fortsätta bli bättre.
Det jag skulle göra annorlunda
Om jag fick börja om skulle jag göra en sak annorlunda: reservera fokustiden direkt. Vi drog ut på processen alldeles för länge genom att försöka klämma in ISO-arbetet mellan allt annat.
Några timmar i veckan med rätt personer är värt mycket mer än ambitionen att någon gång hitta tid för ett stort grepp om allt.
Det är det våra 250 risker lärde oss. Vi behöver inte lösa allt på en gång. Men vi måste fortsätta lösa nästa sak.

Funderar ni på hur risker, rutiner och krav kan hänga ihop i er organisation?