En riskanalys för informationssäkerhet identifierar vilka informationstillgångar som behöver skydd och vilka hot som kan påverka deras konfidentialitet, riktighet och tillgänglighet. Om du ansvarar för resultatet: kalla in en workshop innan du skriver ett enda ord i mallen. MSB:s metodstöd och ISO 27001 pekar samstämmigt på att kartläggningen av tillgångar måste komma före hotbedömningen, inte tvärtom. Arbetet ska dokumenteras så att GDPR artikel 32 kan besvaras med konkreta bevis.
Kort sagt:
- En riskanalys bör genomföras innan hotbedömning, kopplat till organisationens syfte, och dokumenteras för att kunna visa efterlevnad av GDPR artikel 32.
- Den bör göras på rätt nivå, från hela organisationen till enskilda IT-system, beroende på projektets eller förändringens karaktär.
- Innan workshopen måste tydliga avgränsningar, deltagare, underlag och skalan för sannolikhet samt konsekvens vara fastställda i förväg.
- Risker värderas med en förutbestämd skala för sannolikhet och konsekvens, och riskvärdet jämförs med organisationens riskaptit för att välja lämpliga åtgärder.
- Dokumentationen ska innehålla tydliga beslut, ansvariga, tidsplaner och versionshantering för att underlätta tillsyn och framtida uppföljning.
Innehållsförteckning
- Vad är en riskanalys för informationssäkerhet?
- När och varför genomföra riskanalys?
- Planering och förberedelser innan workshopen
- Steg-för-steg: rekommenderad metod i sex praktiska steg
- Mall för dokumentation: vilka fält behövs?
- Hur värderar man risker utan att gissa?
- Från risk till åtgärd: prioritering och ansvar
- Dokumentation och uppföljning vid tillsyn
- Evertrusts perspektiv: lärdomar från praktiken
- Vad conventional wisdom missar om riskanalys
- Behöver du hjälp att komma igång?
- Källor
- Vanliga frågor
Vad är en riskanalys för informationssäkerhet?
En riskanalys för informationssäkerhet är en systematisk genomgång av vilka hot och sårbarheter som kan drabba en informationstillgång, och vad det skulle kosta verksamheten om det hände. Målet är alltid kopplat till tre egenskaper: konfidentialitet, riktighet och tillgänglighet, ofta kallade CIA-principerna inom fältet.
Analysen skiljer sig från en konsekvensbedömning för dataskydd (DPIA), som fokuserar smalt på risker för enskildas rättigheter vid personuppgiftsbehandling. En riskanalys för informationssäkerhet är bredare och omfattar alla informationstillgångar, inte bara persondata, och den skiljer sig även från en säkerhetsskyddsanalys enligt säkerhetsskyddslagen, som gäller säkerhetskänslig verksamhet.
Du kan genomföra analysen på fyra nivåer: hela organisationen, en specifik verksamhet, ett enskilt IT-system eller ett avgränsat projekt. Karolinska institutets vägledning rekommenderar att nivån väljs utifrån syftet. En ny molntjänst kräver systemnivå. En omorganisation kräver processnivå.
När och varför genomföra riskanalys?
GDPR artikel 32 kräver att organisationer vidtar tekniska och organisatoriska åtgärder som är proportionella mot risken, och det går inte att visa proportionalitet utan en dokumenterad bedömning. Cybersäkerhetslagen och ISO 27001 ställer liknande krav på riktade organisationer, vilket Draftits genomgång av regelkraven beskriver tydligt.
I praktiken triggas en ny analys av flera händelser: en systemanskaffning, en organisationsförändring, en incident eller ett tillsynsbesök från en myndighet. Utöver dessa triggers bör du granska analysen minst en gång per år, även om inget uppenbart har förändrats. Hot och sårbarheter förändras i sig över tid.
Planering och förberedelser innan workshopen
Resultatet av en riskanalys avgörs ofta redan i förberedelsefasen, inte i själva workshopen. Fyra saker måste vara klara innan du bokar rummet:
- Avgränsa analysobjektet visuellt. Rita upp systemet, processen eller organisationsdelen så att alla deltagare ser samma gräns. MSB:s vägledning om att använda riskanalys pekar ut detta som den vanligaste källan till missförstånd i workshopar.
- Bjud in rätt deltagare. Informationsägaren, systemägaren, en IT-representant, dataskyddsombudet (DPO) och en verksamhetsrepresentant behöver alla sitta i rummet, inte bara läsa protokollet efteråt.
- Samla underlag i förväg. Inventarielistor över tillgångar, dataflödesscheman, incidentloggar och ett aktuellt leverantörsregister sparar timmar under själva mötet.
- Fastställ skalan innan mötet. Bestäm hur sannolikhet och konsekvens ska graderas, och vilken riskaptit organisationen accepterar, innan diskussionen börjar.
Proffstips: Skicka ut skalan och exempel på gradering till deltagarna dagen innan. Annars går de första 30 minuterna av workshopen åt till att uppfinna en värderingsmodell istället för att använda den.
Steg-för-steg: rekommenderad metod i sex praktiska steg
En riskanalys som ska hålla för tillsyn behöver en reproducerbar metod, inte en fri diskussion som råkar landa på några risker. Draftits sexstegsmodell fångar den logik som återkommer i de flesta etablerade ramverk, inklusive ISO 27005 och NIST:s riskhanteringsprocess.
1. Kartlägg informationstillgångar och system. Lista vilken information som hanteras, var den lagras, vem som äger den och vilket värde den har för verksamheten. Utan denna karta blir resten av analysen gissningar.
2. Identifiera hot och sårbarheter. Använd workshop-tekniker som brainstorming mot en hotkatalog eller genomgång av tidigare incidenter. Typiska hot är obehörig åtkomst, systemfel, mänskliga misstag och externa angrepp. Sårbarheten är det som gör hotet möjligt, till exempel bristande åtkomstkontroll eller föråldrad programvara.
3. Värdera sannolikhet och konsekvens. Använd en skala som är fastställd i förväg (se föregående avsnitt) så att olika deltagare bedömer på samma grunder.
4. Beräkna riskvärde och besluta om acceptans. Multiplicera eller kombinera sannolikhet och konsekvens till ett riskvärde, och jämför det mot organisationens riskaptit, det vill säga den nivå av risk ledningen är beredd att leva med utan ytterligare åtgärder.
5. Välj riskbehandling. För varje risk över acceptansnivån väljer du en av fyra strategier:
- Acceptera risken med motivering och beslutsdatum.
- Åtgärda genom att minska sannolikhet eller konsekvens.
- Överföra risken, till exempel via försäkring eller avtal med leverantör.
- Undvika risken genom att sluta använda systemet eller processen.
6. Dokumentera, kommunicera och planera uppföljning. Resultatet ska skrivas ner på ett sätt som en extern granskare kan följa steg för steg, med tydliga beslutsdatum och ansvariga personer. En gapanalys mot befintliga säkerhetsåtgärder i detta steg hjälper dig se vilka kontroller som redan finns och vilka som saknas, vilket gör prioriteringen i nästa avsnitt betydligt enklare.
Mall för dokumentation: vilka fält behövs?
En riskanalys utan strukturerad dokumentation försvinner i ett mötesprotokoll ingen hittar sex månader senare. Mallen bör innehålla följande obligatoriska fält:
- ID – unikt löpnummer för spårbarhet mellan versioner.
- Informationstillgång – vad som riskbedöms (system, process, dataset).
- Hot – vad som kan gå fel.
- Sårbarhet – varför hotet är möjligt just här.
- Befintliga åtgärder – vad som redan skyddar tillgången idag.
- Sannolikhet och konsekvens – enligt den fastställda skalan.
- Riskvärde – den sammanvägda bedömningen.
- Riskbehandling – acceptera, åtgärda, överför eller undvik.
- Åtgärd och ansvarig – vad som ska göras och av vem.
- Tidsplan och datum för granskning – när åtgärden ska vara klar och nästa gång risken ska omvärderas.
- Restrisk – vad som återstår efter att åtgärden är genomförd.
Ett kortfyllt exempel: ID 14, tillgång “kundregister i CRM-system”, hot “obehörig extern åtkomst”, sårbarhet “delade lösenord utan multifaktorautentisering”, befintlig åtgärd “lösenordspolicy”, sannolikhet hög, konsekvens hög, riskvärde högt enligt organisationens skala, behandling “åtgärda”, åtgärd “inför multifaktorautentisering”, ansvarig IT-chef, tidsplan tre månader, granskningsdatum satt sex månader framåt.
Statistikruta: MSB:s metodstöd beskriver riskanalysen som en uppskattning avsedd att ge beslutsunderlag, inte ett exakt vetenskapligt facit. Överdriven kvantifiering gör sällan analysen mer träffsäker, bara mer tidskrävande.
Spara varje version av mallen med datum och ansvarig granskare i filnamnet eller i ett versionshanteringssystem, så att du alltid kan visa en tillsynsmyndighet exakt vilket beslut som gällde vid en given tidpunkt.
Hur värderar man risker utan att gissa?
En vanlig skala för sannolikhet har tre till fem steg: mycket osannolik, osannolik, möjlig, sannolik och mycket sannolik. Konsekvensskalan byggs på samma sätt, men kopplas direkt till CIA-principerna: hur allvarligt drabbas konfidentialiteten, riktigheten och tillgängligheten om hotet realiseras? SKR:s vägledning för informationsklassning bygger just på denna koppling mellan konsekvensnivå och klassning.
Tre fallgropar dyker upp gång på gång i workshopar:
- Överskattning av sannolikhet. Ett sällsynt hot som diskuterades livligt i media bedöms ofta som mer sannolikt än det statistiskt är.
- Överskydd. Utan en gemensam klassningsmodell läggs pengar på åtgärder som skyddar redan lågklassad information, medan verkligt kritiska tillgångar förblir underskyddade.
- Överkvantifiering. Att jaga fram exakta procentsatser för sannolikhet ger en falsk känsla av precision i en bedömning som i grunden är kvalitativ.
Proffstips: Fråga alltid “jämfört med vad?” när någon i workshopen säger att en risk är “hög”. En hög risk för ett sjukhus och en hög risk för en enmansbyrå är sällan samma sak.
Från risk till åtgärd: prioritering och ansvar
Prioritera åtgärder efter en enkel tumregel: högt riskvärde och låg kostnad går först, lågt riskvärde och hög kostnad går sist eller accepteras. Allt däremellan kräver ett medvetet beslut från den som äger risken.
- Sätt en ansvarig person per åtgärd, aldrig en avdelning eller ett “vi”.
- Sätt ett datum, inte en säsong. “Q3” glöms bort snabbare än “30 september”.
- Följ upp status i samma dokument som riskanalysen, inte i ett separat projektverktyg som ingen i ledningsgruppen öppnar.
- Fråga dig om åtgärden är proportionell mot riskvärdet innan du godkänner budgeten. En enhetlig klassningsmodell minskar risken för att pengar går till onödiga kontroller på lågklassad information.
Genomförbarhet väger tyngre än många inser. En teknisk lösning som tar arton månader att implementera är ofta mindre värd än en organisatorisk rutinändring som är på plats inom en vecka, även om den tekniska lösningen ger ett något lägre restriskvärde på pappret.
Dokumentation och uppföljning vid tillsyn
En tillsynsmyndighet frågar sällan bara “har ni gjort en riskanalys?”. Den frågar “kan ni visa beslutet, datumet och vem som fattade det?”. Dokumentationen måste därför innehålla ett tydligt beslutspår: vem som deltog, vilket datum bedömningen gjordes, och en versionshistorik som visar hur riskvärdet har förändrats över tid.
Sätt granskningsintervall i förväg, minst årligen, och lägg in extra granskningar vid varje ny leverantör eller systembyte. Riskanalysens resultat bör dessutom vävas in i upphandlingskrav och leverantörsavtal, så att identifierade risker inte bara stannar i ett internt dokument utan även styr vilka säkerhetskrav som ställs på tredje part.
Evertrusts perspektiv: lärdomar från praktiken
Organisationer som gått igenom en incident har ibland upptäckt att riskanalysen aldrig uppdaterades efter senaste systembytet. Mönstret är återkommande: en teoretiskt korrekt mall som ingen längre matchar mot verkligheten. Läs mer om vad en dataintrång med läckta personuppgifter faktiskt kostar en organisation i förtroende och juridisk exponering.
Vad conventional wisdom missar om riskanalys
Den vanligaste missuppfattningen är att en riskanalys ska vara heltäckande för att vara giltig. Det är fel. En analys som försöker fånga varje tänkbart scenario med decimalprecision blir så tung att ingen orkar uppdatera den, och då är den värdelös redan efter sex månader.
Det som faktiskt fungerar är en analys som är proportionerlig mot verksamhetens komplexitet, återkopplad till en enkel klassningsmodell, och uppdaterad ofta i mindre steg snarare än sällan i stora omtag. En organisation med femtio anställda behöver inte samma detaljnivå som en myndighet med kritisk infrastruktur, men den behöver samma disciplin i att faktiskt boka in nästa granskning.
Det andra som underskattas är workshopens sociala dimension. Den bästa mallen i världen ger dåligt resultat om informationsägaren inte satt i rummet när hotbilden diskuterades. Riskanalys är i grunden ett samtal mellan människor som ser olika delar av samma system, dokumenterat på ett sätt som håller för granskning. Prioritera det samtalet före perfektionen i kalkylarket.
— Jesper
Behöver du hjälp att komma igång?
Att sätta upp en riskanalys från noll tar tid ingen informationssäkerhetsansvarig egentligen har att avsätta mellan andra prioriteringar. Det finns stöd i form av workshopstöd, färdiga mallar och möjligheten att anlita extern hjälp för organisationer som vill få analysen klar utan att bygga metoden själva från grunden.
Fördelen med att ta in extern kompetens är inte bara tidsbesparingen. Det är att beslutspåren, ansvarsfördelningen och dokumentationen blir korrekt strukturerad från start, vilket gör nästa tillsynsbesök till en formalitet snarare än en stressig efterrättelse. Evertrust kopplar riskanalysen till löpande governance genom rollen som dataskyddsombud och stöttar även vid DPIA-processer där dataskyddsombudets roll behöver klargöras juridiskt. Om organisationen samtidigt utvärderar tredjepartsverktyg för databehandling, kan tekniska partners som Exanturs EU-anpassade dataskyddslösningar komplettera det interna arbetet. Boka ett inledande samtal via Evertrusts expertisöversikt för att se vilket stöd som passar just din organisations riskbild.
Källor
MSB:s metodstöd är den mest praktiska källan för workshopupplägg och kopplingen mellan klassning och skyddsnivåer. Karolinska institutets vägledning om riskanalys vid informationshantering förklarar valet av analysnivå tydligt. SKR:s vägledning för informationsklassning ger en konkret klassningsmodell att koppla till riskvärderingen, och Draftits genomgång sammanfattar de rättsliga kraven bakom varför analysen behöver göras.
- Metodstöd för systematiskt informationssäkerhetsarbete (MSB)
- Riskanalys vid informationshantering (KI)
- Riskanalys för informationssäkerhet – Steg för steg guide (Draftit)
- Vägledning för informationsklassning (SKR)
Vanliga frågor
Vad ska finnas med i en riskanalys?
En komplett riskanalys ska innehålla informationstillgång, identifierat hot, sårbarhet, befintliga åtgärder, sannolikhet, konsekvens, riskvärde, vald riskbehandling, ansvarig person, tidsplan och datum för nästa granskning.
Vilka är de tre viktigaste principerna för informationssäkerhet?
De tre principerna är konfidentialitet, riktighet och tillgänglighet, ofta kallade CIA-principerna. All riskvärdering i en informationssäkerhetsanalys utgår från hur ett hot påverkar dessa tre egenskaper.
Vilka är några exempel på riskanalyser?
Vanliga exempel är en systemnivåanalys inför en ny molntjänst, en processanalys vid en organisationsförändring och en incidentdriven analys efter ett dataintrång, som i fallet med en advokatbyrå som drabbades av läckta personuppgifter.
Vad är en informationssäkerhetsklassning?
En informationssäkerhetsklassning värderar information utifrån hur allvarliga konsekvenserna blir för konfidentialitet, riktighet och tillgänglighet om den skadas eller läcker, och resultatet styr vilken skyddsnivå informationen ska ha.
Hur ofta bör en riskanalys uppdateras?
En riskanalys bör granskas minst en gång per år, samt vid varje väsentlig förändring som ny systemanskaffning, organisationsförändring eller inträffad incident.
