Ett riskregister för informationssäkerhet är den samlade förteckningen över organisationens identifierade informationsrisker. För varje risk anges hur den har bedömts, vem som äger den, vilka åtgärder som beslutats och hur långt behandlingen har kommit. Registret ska inte vara ett arkiv över gamla riskanalyser. Det är ett styrverktyg som visar ledningen var verksamheten är sårbar och vad som görs åt det. Den här guiden går igenom vad registret ska innehålla, hur du bygger det steg för steg och hur det hänger ihop med cybersäkerhetslagen, GDPR och ISO/IEC 27001.
Kort sagt
- Ett riskregister samlar alla riskanalyser på ett ställe och visar status i riskbehandlingen. Varje risk ska ha en utsedd riskägare i verksamheten.
- Cybersäkerhetslagen, som gäller sedan 15 januari 2026, kräver ett systematiskt och riskbaserat arbete. Ett levande riskregister är det mest konkreta sättet att visa att arbetet faktiskt bedrivs.
- Minimifälten är: risk, informationstillgång, hot och sårbarhet, sannolikhet, konsekvens, riskvärde, behandlingsbeslut, åtgärd, ansvarig, tidplan, restrisk och datum för nästa översyn.
- Det vanligaste misstaget är att se registret som en statisk lista som ägs av IT. Ansvaret ska ligga hos dem som äger verksamheten och informationen.
- Registret blir mer värt när det kopplas till DPIA-resultat, incidenter, leverantörsbedömningar och ledningens uppföljning.
Innehållsförteckning
- Vad ett riskregister är, och vad det inte är
- Vilka regelverk som ställer krav på riskarbetet
- Fälten som ett riskregister bör innehålla
- Så bygger du riskregistret steg för steg
- Exempel: en risk från identifiering till uppföljning
- Koppla registret till incidenter och övningar
- Vanliga misstag i riskregister
- Kalkylark eller compliance-plattform?
- Vårt perspektiv: registret är ett ledningsverktyg
- Samla riskregistret i Trustview
- Vanliga frågor om riskregister
- Källor
Vad ett riskregister är, och vad det inte är
MSB beskriver i sitt metodstöd för riskhantering riskhantering som en central del av det systematiska informationssäkerhetsarbetet. Risker identifieras, analyseras, värderas och behandlas löpande, eftersom förutsättningarna hela tiden förändras. I det arbetet fungerar riskregistret som den sammanställning där resultaten av riskanalyserna och statusen i riskbehandlingen samlas.
I praktiken fyller registret tre funktioner:
- Minne. Det dokumenterar vilka risker som har identifierats, när och av vem, och hur de bedömdes.
- Styrning. Det visar vilka åtgärder som har beslutats, vem som ansvarar och när de ska vara genomförda.
- Underlag för ledningen. Det gör det möjligt att prioritera resurser och att acceptera kvarstående risker på ett medvetet och dokumenterat sätt.
Ett riskregister är däremot inte samma sak som en riskanalys. Analysen är aktiviteten, till exempel en workshop om ett nytt verksamhetssystem. Registret är platsen där analysens resultat lever vidare. Det ersätter inte heller en informationsklassning eller en kontinuitetsplan, men det ska kunna hänvisa till dem.
Vilka regelverk som ställer krav på riskarbetet
Ingen svensk lag använder ordet “riskregister” som ett formellt krav. Flera regelverk kräver dock ett riskbaserat och dokumenterat arbetssätt, och då blir registret det naturliga beviset.
Cybersäkerhetslagen
Den nya cybersäkerhetslagen trädde i kraft den 15 januari 2026 och genomför NIS2-direktivet i Sverige. Verksamhetsutövare inom de utpekade sektorerna ska bedriva ett systematiskt och riskbaserat cybersäkerhetsarbete. Det omfattar bland annat strategier för riskanalys, incidenthantering och säkerhet i leveranskedjan. Ledningen ska också genomgå utbildning om säkerhetsåtgärder, och betydande incidenter ska rapporteras till utsedd myndighet senast 24 timmar efter att verksamheten fått kännedom om dem. En slutrapport ska lämnas senast en månad efter incidentanmälan.
För riskregistret innebär det i korthet att du behöver kunna visa:
- att riskerna för nätverks- och informationssystemen är identifierade och bedömda,
- att åtgärderna står i proportion till riskerna,
- att leverantörsrisker ingår, inte bara den egna IT-miljön,
- att ledningen följer upp och fattar beslut om riskerna.
Leverantörsdelen underskattas ofta. Vi har skrivit mer om varför i guiden om NIS2 och leverantörskedjan.
GDPR
Enligt dataskyddsförordningen ska tekniska och organisatoriska säkerhetsåtgärder vara lämpliga i förhållande till risken. IMY betonar att utgångspunkten är risken för de registrerades fri- och rättigheter, inte bara organisationens egna ekonomiska eller operativa intressen. Ett riskregister som bara mäter konsekvenser i kronor och driftstopp missar alltså halva bilden när personuppgifter berörs. Lägg därför till en konsekvensdimension för enskilda personer.

När en behandling sannolikt leder till hög risk krävs en konsekvensbedömning (DPIA). IMY skriver att en konsekvensbedömning ska vara en pågående process som följs upp och vid behov uppdateras. De risker som identifieras i en DPIA hör därför hemma i samma register, med samma krav på ägare och uppföljning. Läs mer i vår guide om GDPR-riskbedömning och DPIA.
ISO/IEC 27001 och 27005
I ett ledningssystem för informationssäkerhet (LIS/ISMS) enligt ISO/IEC 27001 är riskbedömning och riskbehandling kärnan. ISO:s egen revisionsvägledning om Annex A understryker att Annex A är en referenslista att jämföra mot, inte en komplett checklista att utgå från. Riskerna ska komma ur verksamhetens sammanhang, och de valda kontrollerna ska kunna härledas till dem i uttalandet om tillämplighet (SoA). För metodiken kring själva riskanalysen, se vår guide om riskanalys enligt ISO 27005.
Fälten som ett riskregister bör innehålla
Tabellen nedan visar en struktur som fungerar för de flesta organisationer, oavsett om utgångspunkten är cybersäkerhetslagen, GDPR eller ISO 27001. Börja hellre med färre fält som alltid fylls i än med många som står tomma.
| Fält | Vad det beskriver | Exempel |
|---|---|---|
| Risk-ID | Unik identitet för spårbarhet | R-2026-014 |
| Riskbeskrivning | Händelse, orsak och effekt i en mening | Obehörig åtkomst till HR-systemet via delade inloggningar leder till röjda personuppgifter |
| Informationstillgång | Vilken information eller vilket system som berörs | HR-system, löneuppgifter |
| Hot och sårbarhet | Vad som kan hända och varför det är möjligt | Kontokapning; saknad flerfaktorsautentisering |
| Sannolikhet | Bedömning på fastställd skala | 3 av 4 |
| Konsekvens | För verksamheten och för de registrerade | 4 av 4 (känsliga personuppgifter) |
| Riskvärde | Sannolikhet × konsekvens, eller matrisnivå | 12, hög |
| Behandlingsbeslut | Reducera, undvika, överföra eller acceptera | Reducera |
| Åtgärd | Konkret säkerhetsåtgärd, gärna kopplad till kontroll | Införa MFA och personliga konton |
| Riskägare | Person i verksamheten som äger risken | HR-chef |
| Åtgärdsansvarig och tidplan | Vem som genomför och när | IT-förvaltare, 30 november |
| Restrisk | Bedömt riskvärde efter åtgärd | 4, låg |
| Status | Öppen, pågående, genomförd, accepterad | Pågående |
| Nästa översyn | Datum för omprövning | Mars 2027 |
| Källa | Var risken identifierades | Riskworkshop, DPIA, incident, leverantörsbedömning |
Fältet Källa är lätt att hoppa över men gör stor skillnad. Det visar att risker hämtas från flera håll, inte bara från en årlig workshop. Det är också precis det som ISO-vägledningen efterfrågar när den varnar för att luta sig enbart mot Annex A.
Så bygger du riskregistret steg för steg
MSB:s metodstöd beskriver det systematiska arbetet som en cyklisk process i fyra delar: identifiera och analysera, utforma, använda samt följa upp och förbättra. Stegen nedan följer den logiken.
- Fastställ riskkriterier. Bestäm skalor för sannolikhet och konsekvens, vad som räknas som låg, medel och hög risk, och vem som får acceptera vilken risknivå. Utan kriterier blir bedömningarna personberoende och svåra att jämföra.
- Utgå från informationen, inte från tekniken. Identifiera verksamhetens viktigaste informationstillgångar och beroenden. Cybersäkerhetskollen 2025 beskriver identifiering av information, it-system, ot-system och beroenden som ett grundläggande steg i allt systematiskt cybersäkerhetsarbete.
- Identifiera risker från flera källor. Kombinera workshops med verksamheten, resultat från DPIA och TIA, incidentrapporter, leverantörsbedömningar, revisionsiakttagelser och aktuell hotbild. Om ni behöver inspiration kan en genomgång av exempel på vanliga cyberrisker som nätfiske, ransomware och dataläckor fungera som startpunkt för diskussionen.
- Analysera och värdera. Bedöm sannolikhet och konsekvens enligt kriterierna. Bedöm konsekvensen för de registrerade separat när personuppgifter berörs.
- Fatta behandlingsbeslut. Välj mellan att reducera, undvika, överföra eller acceptera risken. Dokumentera motiveringen, särskilt när en hög risk accepteras.
- Utse riskägare och åtgärdsansvariga. Riskägaren sitter i verksamheten och har mandat att prioritera. Åtgärdsansvarig kan vara någon annan, till exempel en IT-förvaltare eller en leverantör.
- Följ upp med fast rytm. Gå igenom höga risker varje månad eller kvartal och hela registret minst årligen. Gör även en översyn vid större förändringar, efter allvarliga incidenter och vid byte av kritisk leverantör.
- Rapportera till ledningen. Sammanfatta riskbilden, avvikelser från tidplaner och de risker som kräver ledningsbeslut.
Vill du förstå hur ett riskbaserat arbetssätt hjälper dig att prioritera mellan regelverk? Läs mer om riskbaserat tänkande för compliance.
Exempel: en risk från identifiering till uppföljning
Scenario. En medelstor kommunal verksamhet byter till ett molnbaserat ärendehanteringssystem som innehåller uppgifter om enskilda, däribland känsliga personuppgifter.
- Identifiering. I DPIA:n framkommer att leverantören använder en underleverantör utanför EU/EES för support. Risken förs in i registret med källan “DPIA” och kopplas till informationstillgången “ärendehantering”.
- Bedömning. Sannolikheten för obehörig åtkomst bedöms som medel och konsekvensen för de registrerade som hög. Risken hamnar därmed på hög nivå.
- Behandling. Beslutet blir att reducera risken. Åtgärderna är en överföringsbedömning (TIA), avtalsvillkor om åtkomstloggning och kryptering där verksamheten själv förvaltar nycklarna.
- Ansvar. Förvaltningschefen blir riskägare. Upphandlingsansvarig och IT-arkitekt är åtgärdsansvariga med datum i registret.
- Uppföljning. Efter genomförda åtgärder bedöms restrisken som låg. Riskägaren accepterar den formellt, och nästa översyn sätts till sex månader eller till nästa avtalsförändring, beroende på vad som inträffar först.
En och samma risk berör här GDPR, leverantörskedjan och informationssäkerheten. Ligger de i tre olika kalkylark tappar ledningen helheten.
Koppla registret till incidenter och övningar
Ett riskregister som aldrig prövas mot verkligheten blir lätt teoretiskt. Incidenter är det tydligaste beviset på att en risk var underskattad eller att en åtgärd inte fungerade. Varje allvarligare incident bör därför leda till en kontroll i registret: fanns risken där, var bedömningen rimlig och genomfördes åtgärderna?
CERT-SE framhåller att incidenthantering kräver regelbundna övningar, till exempel diskussionsövningar kring ransomware eller nätfiske. Sådana övningar avslöjar luckor i processer och ansvarsfördelning innan en verklig incident inträffar. Resultaten passar bra som riskkälla i registret. Den som vill bredda perspektivet kan också ta del av en åtgärdsplan för cyberresiliens som strukturerar beredskapen i konkreta steg.
Med 24-timmarsgränsen för incidentrapportering enligt cybersäkerhetslagen behöver det dessutom vara tydligt i förväg vem som gör vad. Vår guide om hanteringsprocess för dataintrång beskriver hur processen kan se ut.
Vanliga misstag i riskregister
- Registret ägs av IT. När registret ligger hos en säkerhetsspecialist blir riskerna tekniska, och verksamheten slutar känna ansvar. Riskägarskapet ska ligga där besluten fattas.
- Statisk lista. Ett register som uppdateras en gång om året inför revisionen speglar inte den faktiska riskbilden.
- Vaga riskbeskrivningar. “Cyberattack” är ingen risk. Beskriv händelse, orsak och effekt så att åtgärden blir självklar.
- Inga riskkriterier. Utan fastställda skalor blir riskvärdena inte jämförbara mellan enheter.
- Åtgärder utan datum och ägare. En åtgärd utan namn och tidplan blir sällan genomförd.
- Acceptans utan beslut. Att låta en risk ligga kvar är också ett beslut, och det ska fattas av någon med mandat.
- Ledningen saknas. MSB:s stöd om ledningens roll inom informations- och cybersäkerhet lyfter ledningens engagemang som avgörande. Cybersäkerhet ska integreras i den ordinarie verksamhetsstyrningen och inte hanteras som en isolerad IT-fråga.
Resurserna är en del av problemet. Enligt Cybersäkerhetskollen 2025 saknar 65 procent av organisationerna i offentlig förvaltning den personal som krävs för ett systematiskt cybersäkerhetsarbete. Det talar för att registret ska vara enkelt att underhålla, så att den tid som finns läggs på bedömningar och åtgärder och inte på administration.
Kalkylark eller compliance-plattform?
Många börjar med ett kalkylark, och för en liten organisation med ett fåtal risker kan det räcka. När antalet risker, riskägare och regelverk växer blir begränsningarna tydliga.
| Kriterium | Kalkylark | Generellt ärende- eller GRC-verktyg | Compliance-plattform med juridiskt innehåll |
|---|---|---|---|
| Kom igång | Direkt | Kräver konfiguration | Färdiga mallar och ramverk |
| Spårbarhet och historik | Svag, versionsfiler | God | God, med logg per risk |
| Påminnelser och uppföljning | Manuell | Ofta inbyggd | Inbyggd, kopplad till ansvar |
| Koppling till DPIA, incidenter och leverantörer | Manuella hänvisningar | Beror på uppsättning | Samlat i samma miljö |
| Stöd för svenska och europeiska regelverk | Inget | Ofta generellt | Anpassat för till exempel GDPR och NIS2 |
| Rapportering till ledningen | Manuell sammanställning | Rapporter efter konfiguration | Automatiska rapporter och realtidsöversikt |
Avgörande är inte verktyget i sig. Det viktiga är att registret används, att ansvaret syns och att ledningen får en rättvisande bild utan manuellt sammanställningsarbete.
Vårt perspektiv: registret är ett ledningsverktyg
Vi som har byggt Trustview är jurister med erfarenhet av svensk och europeisk lagstiftning. Vi ser samma mönster om och om igen. Organisationer har ofta gjort bra riskanalyser, men resultaten ligger utspridda i workshopanteckningar, DPIA-dokument och mejltrådar. När revisorn eller tillsynsmyndigheten frågar hur riskerna följs upp tar det veckor att sammanställa svaret.

Vår uppfattning är att riskregistret ska vara den gemensamma punkten där juridik, informationssäkerhet och verksamhet möts. En risk som upptäcks i en konsekvensbedömning ska inte behöva skrivas in på nytt i ett separat säkerhetsregister. En åtgärd ska ha en ansvarig som får en påminnelse, och ledningen ska se status utan att någon behöver bygga en presentation. Med cybersäkerhetslagen på plats och ledningens utbildningsansvar inskrivet i lag blir det svårare att försvara ett register som bara uppdateras inför revisionen.
Vårt råd är att börja smått: fastställ kriterierna, välj ut de tio viktigaste riskerna, ge varje risk en ägare och boka in den första uppföljningen. Ett register som används är mer värt än ett komplett register som ingen öppnar.
— Jesper
Samla riskregistret i Trustview
I Trustview hanterar du riskregistret tillsammans med registerförteckning, konsekvensbedömningar (DPIA och TIA), incidentlogg, leverantörsbedömningar och åtgärdsuppföljning. Du delegerar ansvar, skapar egna ramverk vid sidan av färdiga mallar för GDPR, NIS2, ISO 27000 och AI-förordningen och får en realtidsöversikt över compliance-status med automatiska rapporter. Plattformen kostar från 2 500 kr per månad. Behöver ni stöd i bedömningarna finns även juridisk rådgivning som tillägg. Är du VD eller ytterst ansvarig? Läs mer på sidan för dig som är ansvarig eller VD.
Vanliga frågor om riskregister
Vad räknas som informationssäkerhet?
Informationssäkerhet handlar om att skydda den information en organisation hanterar, oavsett om den är digital eller på papper. Enligt IMY:s beskrivning av informationssäkerhet för verksamheter handlar det om att hindra att information läcker ut, förvanskas eller förstörs, och om att rätt information finns tillgänglig för rätt personer i rätt tid.
Vilka är de tre viktigaste principerna för informationssäkerhet?
De tre grundprinciperna är konfidentialitet, riktighet och tillgänglighet. Information ska bara nås av behöriga, den ska vara korrekt och den ska kunna användas när den behövs. I riskregistret är det bra att ange vilken av de tre aspekterna en risk främst påverkar.
Vad är skillnaden mellan riskanalys och riskregister?
Riskanalysen är aktiviteten där risker identifieras och bedöms för ett visst område, system eller en viss förändring. Riskregistret är den samlade förteckningen där resultaten från alla analyser hamnar och följs upp över tid. Analysen har ett slut, men registret lever vidare.
Hur ofta ska riskregistret uppdateras?
Höga risker bör följas upp löpande, till exempel månadsvis eller kvartalsvis, och hela registret minst en gång om året. Registret ska dessutom ses över vid större förändringar, nya system, byte av kritiska leverantörer och efter allvarliga incidenter.
Vem ska äga riskerna i registret?
Varje risk ska ha en riskägare i verksamheten, normalt den chef som ansvarar för den berörda informationen eller processen. Informationssäkerhetsansvarig eller CISO samordnar arbetet och metodiken, men äger inte alla risker. Ledningen beslutar om de risker som överskrider fastställd acceptansnivå.
Källor
- MSB: Metodstöd för informationssäkerhet, riskhantering
- Riksdagen: Ett starkt skydd för nätverks- och informationssystem, en ny cybersäkerhetslag
- IMY: Säkerhetsåtgärder
- IMY: Hur ska en konsekvensbedömning genomföras?
- IMY: Informationssäkerhet för verksamheter
- ISO/IEC JTC 1/SC 27/WG 1: Auditing Practices Note, Annex A
- MSB: Cybersäkerhetskollen 2025
- MSB: Ledningens roll inom informations- och cybersäkerhet
- CERT-SE: Övningar
- Exempel på cyberrisker
- Åtgärdsplan för cyberresiliens



