Allt om GRC

Governance, risk & compliance – tre områden som tillsammans avgör hur en organisation styrs. Men vad innebär det i praktiken och vad krävs för att få dem att fungera tillsammans? Det går vi in djupare på här.

Vad är GRC?

GRC är ett samlingsbegrepp för tre arbetsområden som tillsammans avgör hur väl en organisation styrs och håller sig på rätt sida av både lagar, risker och egna mål. På svenska används också "styrning, riskhantering och regelefterlevnad".

GRC delas vanligen in i tre delområden:

Governance: Hur verksamheten faktiskt styrs i vardagen – roller, ansvar, beslutsvägar och uppföljning. Ägs typiskt av VD, styrelse och ledningsgrupp.
Risk management: Att identifiera, bedöma, hantera och följa upp risker som kan påverka organisationens mål. Ägs typiskt av riskansvarig, CRO eller en riskkommitté.
Compliance: Att säkerställa efterlevnad av lagar, branschregler och interna policyer. Ägs typiskt av compliance officer, Head of Legal eller internkontroll.

Så ser indelningen ut. Men i praktiken flyter områdena ihop. En NIS2-fråga är samtidigt en risk, en compliance-fråga och en styrningsfråga. En leverantörsbedömning rör både informationssäkerhet, dataskydd och internkontroll.

Det är just i de skarvarna som problemen uppstår. Därför är det mer användbart att tänka på GRC som ett sammanhängande system för verksamhetsstyrning än som tre separata funktioner.

Hur skiljer sig governance, risk management och compliance åt?

Den enklaste sättet att skilja dem åt är genom vilken fråga var och en ställer.

Governance ställer frågan "vem fattar besluten, och utifrån vad?".
Risk management ställer frågan "vad kan gå fel, och hur sannolikt är det?".
Compliance ställer frågan "följer vi det vi måste följa?". I praktiken är svaren ofta sammanflätade – men frågorna behöver fortfarande ställas separat för att inte tappas bort.

Fyra vanliga utmaningar i GRC-arbete

De flesta organisationer arbetar redan med GRC. Frågan är bara hur. Vi ser fyra mönster återkomma hos de organisationer vi pratar med – oavsett bransch och oavsett mognad.

Fragmenterat arbete

Risk hanteras i ett verktyg, informationssäkerhet i ett annat, internkontroll i ett tredje. Compliance lever i Excel. Var och en av delarna fungerar – isolerat. Men ingen ser helheten, och i skarvarna mellan dem uppstår både dubbelarbete och blinda fläckar. Ett tydligt exempel är hur IKT-risker ofta hanteras helt separat från övrig riskhantering, vilket vi går igenom i vår artikel om hur ni integrerar IKT-risker med organisationens riskhantering.

Bristande överblick

Ledningen får rapporter, men de kommer från olika system, vid olika tidpunkter, med olika definitioner av vad som är "rött" eller "grönt". Beslut fattas utan en samlad bild av riskläget, och uppföljning blir reaktiv snarare än styrande.

Otydligt ägarskap

Ansvaret är spritt över flera funktioner – juridik, IT, säkerhet, verksamhet, kvalitet – och när alla äger en bit äger ingen helheten. Kritiska frågor faller mellan stolarna eller hanteras för sent.

Reaktivt arbete

När struktur saknas blir GRC-arbetet en serie brandkårsutryckningar. Tid och resurser går till att åtgärda problem i efterhand i stället för att förebygga dem. När ett nytt regelverk träder i kraft – cybersäkerhetslagen, NIS2, DORA, CSRD – startar arbetet om från noll istället för att hanteras inom en befintlig struktur. Det här är inte ett problem som löser sig med fler verktyg eller fler personer. Det är ett strukturproblem. Och så länge strukturen saknas växer komplexiteten snabbare än kontrollen.

För NIS2 specifikt har vi sammanställt smarta prioriteringar för att lyckas när resurserna är begränsade.

Risk som nav: så hänger GRC-arbetet ihop

Risk är inte ytterligare en domän bredvid compliance och informationssäkerhet – det är den logik som binder ihop dem. Varför? För att risk är det enda perspektiv som tvingar fram en prioritering. Compliance kan i värsta fall bli en oändlig lista med krav att bocka av.

Informationssäkerhet kan reduceras till en uppsättning tekniska kontroller. Internkontroll kan stelna i årshjul. Men när ni utgår från risk – vad kan gå fel, hur sannolikt är det, och vad blir konsekvenserna? – då får varje aktivitet en koppling till verksamhetens faktiska situation.

För den som vill djupdyka i det här perspektivet har vi skrivit mer om
hur riskmognad ser ut i praktiken – det är ofta där skillnaden mellan en organisation som lyckas och en som fastnar blir synlig.

Det betyder konkret att:

En compliance-fråga blir intressant först när den är kopplad till en risk. Vad är det vi vill skydda oss mot? Vilka kontroller hanterar den risken? Då blir efterlevnad ett resultat av god styrning – inte ett mål i sig.
En informationssäkerhetsåtgärd prioriteras utifrån vilka informationstillgångar som är mest kritiska och vilka hot de står inför – inte utifrån vad som råkar vara enklast att implementera.
Internkontroll blir ett system för att verifiera att de mest betydande riskerna är under kontroll, inte ett separat årshjul vid sidan om verksamheten.

När ni gör risk till nav får ni också en gemensam måttstock. Risk är det språk som CISO, riskansvarig, Head of Legal, controller och VD kan förstå tillsammans. Det är där samtalet om GRC kan flyttas från "vad ska vi göra för att slippa böter" till "vad ska vi göra för att verksamheten ska fungera även när det blåser".

Specialisterna räcker inte – GRC måste fungera över hela organisationen

Det här är den punkt där de flesta GRC-initiativ tappar fart, och det är värt att stanna upp vid. Vi ser samma mönster gång på gång: organisationer satsar på en duktig CISO, en kompetent riskansvarig, en erfaren Head of Legal. Var och en bygger en strukturerad bild av sitt område. Och sedan stannar arbetet där.

Ramverk skrivs som ingen utanför specialistfunktionen läser. Riskbedömningar görs i parallella verktyg som chefer i verksamheten aldrig ser. Compliance-ansvar dokumenteras i policyer som inte påverkar hur arbetet faktiskt utförs.

Det här är inte ett kunskapsproblem – specialisterna kan sin sak. Det är ett adoptionsproblem, och det är något vi går djupare in på i vår artikel om styrning av informationssäkerhet.

GRC blir verkligt värde först när:

Linjecheferna vet vilka risker som är deras ansvar, och kan se status utan att behöva ringa CISO.
Processägarna förstår vilka kontroller de ska genomföra, och kan signera dem där arbetet sker.
Ledningen får en samlad bild av riskläget utan att någon behöver klippa ihop tre olika rapporter manuellt.
Revisorn kan följa kedjan från risk till kontroll till åtgärd till uppföljning utan att behöva exportera data.

Det här är inte detaljer i ett verktyg – det är skillnaden mellan ett GRC-arbete som lever i specialistens huvud och ett som faktiskt blir en del av hur verksamheten styrs.

En del av det handlar om verktyg och flöden; en lika viktig del handlar om att bygga upp kunskap och säkerhetsmedvetenhet löpande i organisationen, så att specialistens struktur faktiskt landar hos dem som ska agera på den.

Vilka ramverk används inom GRC?

De flesta organisationer som arbetar strukturerat med GRC stödjer sig på etablerade ramverk. Här är några av de vanligaste:

ISO 27001 / ISO 27002 – internationell standard för ledningssystem för informationssäkerhet. Bygger på risk som utgångspunkt och kräver dokumenterad styrning, riskbedömning och kontinuerlig förbättring. Är ofta det första ramverket en organisation certifierar sig mot.

NIS2 och cybersäkerhetslagen – EU-direktiv respektive svensk lag som ställer krav på cybersäkerhet och riskhantering för en bred grupp organisationer. Cybersäkerhetslagen gäller från 15 januari 2026.

DORA – EU-förordning för digital operativ motståndskraft i finansiell sektor, med fokus på IKT-risker och tredjepartshantering.

GDPR – grundläggande dataskyddsförordning som ställer krav på hur personuppgifter hanteras, dokumenteras och skyddas.

Utöver dessa förekommer ramverk som NIST Cybersecurity Framework (cybersäkerhet) och ISO 31000 (riskhanteringsprinciper) som komplement, beroende på bransch och behov.

Hur kommer ni igång med GRC? Fyra steg som faktiskt fungerar

En struktur som håller är inte en imponerande organisationskarta i en PowerPoint. Den är ett arbetssätt som klarar av att skalas upp utan att tappa kontrollen.

1. Förstå – kartlägg det som ska styras

Ni kan inte styra det ni inte ser. Första steget är därför att skapa en gemensam bild av vilka processer och tillgångar som är kritiska för verksamheten, vilka regelverk och interna styrdokument som påverkar dem, och vilka roller och ansvar som finns kopplade till dem.

Det här ska inte vara en engångsövning. Det ska vara ett levande underlag som uppdateras när verksamheten förändras. Det är fundamentet som allt annat vilar på.

2. Bedöm – sätt risk i centrum

När underlaget finns på plats är nästa steg att bedöma riskerna kopplade till det. Vad kan gå fel? Hur sannolikt är det? Vad blir konsekvensen? Vilka kontroller har vi redan på plats? Läs våra artikel om hur ni arbetar med riskbedömning - och om ni vill ha hjälp att visualisera prioriteringen är riskmatrisen ett beprövat verktyg som gör jobbet.

Det här är kärnan i ett risk-drivet arbetssätt. En genomtänkt riskbedömning ger två saker: ett underlag för prioritering (var ska vi lägga resurser?) och ett gemensamt språk (vad menar vi när vi säger att något är "högt prioriterat"?).

3. Agera – hantera risker där de finns

Strukturerad styrning betyder att åtgärder hamnar hos rätt person, vid rätt tidpunkt, med rätt mandat. Det är här de flesta organisationer tappar fart: en risk identifieras, en åtgärdsplan tas fram – och sedan rinner den ut i sanden.

För den som vill se hur det här fungerar i en specifik kontext har vi sammanfattat sju framgångsfaktorer i arbetet med IKT-risker, där samma principer återkommer. För compliance-delen, där åtgärder ofta tar formen av kontroller, har vi också skrivit om fem steg till effektivare internkontroll.

En hållbar struktur gör det enkelt att fördela ägarskap, sätta deadlines och se status. Inte i parallella system, utan i samma flöde där risken bedömdes.

4. Följ upp – gör det till en levande process

Sista steget är att stänga loopen. Genomförda åtgärder ska följas upp, kontroller testas, status rapporteras. Inte en gång om året, utan löpande. När det gäller scenarier som verksamhetsstörningar är kontinuitetsplanering ett tydligt exempel på var struktur och förberedelse gör skillnad i skarpt läge.

När de fyra stegen kopplas ihop – förstå, bedöm, agera, följ upp – blir GRC en kontinuerlig cykel snarare än en serie projekt. Och det är då strukturen håller även när nya regelverk tillkommer eller verksamheten växer.

Vad är ett GRC-system, och vad gör det?

Ett GRC-system är ett mjukvarustöd som binder samman arbetet med styrning, riskhantering och regelefterlevnad i samma struktur.

Skillnaden mot punktverktyg (som ett risk-Excel, en separat policy-databas eller ett incidentsystem) är att information kan flöda mellan domänerna – en risk länkas till en kontroll, kontrollen länkas till en policy, policyn länkas tillbaka till regelverket som kräver den.

I praktiken brukar det innebära fem grundläggande förmågor:

Riskregister med ägarskap. Alla risker dokumenterade, prioriterade och tilldelade.
Kontroller länkade till risker. Spårbar koppling från risk till kontroll till åtgärd – inte separata listor.
Policyer och styrdokument. Versionshanterade och kopplade till de regelverk och kontroller de uppfyller.
Dashboards och rapportering. En samlad bild för ledning, styrelse och revision – utan manuell sammanställning.
Distribuerat ägarskap. Att linjechefer, processägare och systemägare kan arbeta i systemet, inte bara specialister.

Marknaden delas idag grovt i tre kategorier. Automation-fokuserade verktyg som primärt automatiserar tekniska kontroller för SaaS-bolag. Tunga enterprise-system byggda för stora globala koncerner med mångfacetterade regulatoriska behov. Och däremellan: governance-plattformar byggda för medelstora och större organisationer i offentlig sektor, vård, finans och industri – där behovet är strukturerad styrning som hela organisationen kan delta i, snarare än automation av ett smalt antal compliance-ramverk.

Hur vet man att det är dags att skaffa ett GRC-system?

Det finns ingen exakt mognadsnivå där behovet uppstår, men det finns några tecken som återkommer:

Excel-arken har växt ur sina kostymer – flera personer redigerar samma fil, versionshanteringen är spårlöst förlorad.
Ni har minst två GRC-relaterade roller (riskansvarig, CISO, compliance, internkontroll) som idag inte arbetar i samma system.
Ett nytt regelverk har gjort att ad-hoc-arbete inte längre räcker – ofta NIS2, DORA eller CSRD.
Ledningen eller styrelsen har efterfrågat samlad rapportering som ingen idag kan producera utan manuellt arbete.
Ni har haft en incident eller revision där frågan "vem äger det här?" var svårare att besvara än den borde vara.

Om två eller fler av punkterna ovan stämmer är ni troligen redo att börja. Den vanligaste ingången är riskhantering eller informationssäkerhet – sedan växer arbetet ut över andra områden allt eftersom strukturen är på plats.

Från specialistarbete i silos till styrning i hela organisationen

Den största skillnaden mellan organisationer som upplever GRC som en börda och de som upplever det som en hävstång ligger inte i hur mycket de jobbar med det. Den ligger i vilka som faktiskt jobbar med det.

I den första kategorin är GRC en specialistfråga. Risk hanteras av riskfunktionen, säkerhet av CISO, compliance av juridik. Var och en producerar sina dokument. Men ledningen får ingen samlad bild, linjecheferna känner inte till sina kontroller, och helheten finns aldrig på en plats.

I den andra kategorin är GRC ett arbetssätt som hela verksamheten är delaktig i. Specialisterna sätter strukturen, men arbetet sker där det hör hemma – hos processägare, linjechefer, systemansvariga. Ägarskapet är distribuerat och det är just därför det fungerar i längden.

Det är det arbetssättet Stratsys GRC-plattform är byggd för. Inte för specialisterna ensamma, utan för hela organisationen.

Upptäck Stratsys GRC-lösning

Vanliga frågor om GRC

Vad är skillnaden mellan governance, risk management och compliance?

Governance handlar om hur verksamheten styrs – roller, ansvar, beslutsvägar och uppföljning. Risk management handlar om att identifiera, bedöma och hantera risker som kan påverka målen. Compliance handlar om efterlevnad av lagar, regelverk och interna policyer. De tre överlappar i praktiken: en regelefterlevnadsfråga är ofta också en risk, och en risk hanteras genom styrning. Det är därför vi rekommenderar att jobba med dem som ett sammanhängande system, med risk som logiken som binder ihop dem.

Vem ansvarar för GRC i en organisation?

Det korta svaret är: flera. Riskansvarig äger riskhanteringsprocessen, CISO ansvarar för informationssäkerhet, Head of Legal eller compliance officer för regelefterlevnad, och internkontrollansvarig för internkontroll. Det långa svaret är att GRC fungerar först när ansvaret är distribuerat ut i organisationen – linjechefer äger sina risker, processägare äger sina kontroller, och ledningen har en samlad bild. Det är skillnaden mellan ett GRC-arbete som lever hos specialisterna och ett som faktiskt styr verksamheten.

Vad är ett GRC-verktyg eller en GRC-plattform?

Ett GRC-verktyg är ett system som stödjer arbetet med styrning, riskhantering och regelefterlevnad. En GRC-plattform går ett steg längre – den binder samman flera domäner (risk, informationssäkerhet, dataskydd, internkontroll, tredjepartsrisk) i samma struktur, så att information kan flöda mellan dem. Skillnaden är inte teknisk utan organisatorisk: ett verktyg löser ett avgränsat problem, en plattform stödjer ett sätt att jobba över hela organisationen.

När behöver man ett GRC-system?

De flesta organisationer hamnar i samma situation: Excel räcker inte längre, risker hanteras parallellt i flera verktyg, ledningen får rapporter som inte hänger ihop, och nya regelverk som NIS2 eller DORA gör att arbetet inte längre kan vara ad-hoc. Det är då ett GRC-system blir aktuellt. Den vanligaste ingången är riskhantering eller informationssäkerhet – sedan växer arbetet ut över andra områden allt eftersom strukturen är på plats.

Hur kommer man igång med GRC-arbete?

Vi rekommenderar fyra steg: förstå (kartlägg processer, regelverk och roller), bedöm (identifiera och prioritera risker), agera (fördela ägarskap och genomför åtgärder) och följ upp (mät, rapportera, justera). Det viktigaste är att inte försöka göra allt på en gång. Börja med ett område där behovet är tydligast – ofta risk eller informationssäkerhet – och bygg ut därifrån. En vanlig fallgrop är att försöka implementera en fullständig GRC-struktur som ett konsultprojekt, vilket sällan överlever första året.

Hur hänger GRC ihop med NIS2, DORA och andra regelverk?

NIS2 (cybersäkerhet), DORA (digital operativ motståndskraft i finansiell sektor), CSRD (hållbarhetsrapportering) och GDPR (dataskydd) är alla regelverk som kräver dokumenterad styrning, riskbedömning och uppföljning. De är inte separata problem – de är olika ingångar till samma underliggande behov av strukturerad styrning. En organisation med en fungerande GRC-struktur kan möta nya regelverk inom befintligt arbetssätt i stället för att starta ett nytt projekt varje gång. Det är hela poängen med att jobba strukturerat.

Vad menas med GRC-mognad?

GRC-mognad beskriver hur strukturerat och proaktivt en organisations GRC-arbete är. Låg mognad innebär silos, reaktivt arbete och otydligt ägarskap. Hög mognad innebär integrerad styrning, riskdriven prioritering och kontinuerlig uppföljning.

Vad kostar bristande GRC?

De direkta kostnaderna är de mest synliga: regulatoriska böter, incidentkostnader och förlorade affärer. De indirekta kostnaderna – tid som läggs på reaktiv brandsläckning, fördröjda beslut, dubbelarbete mellan team – är ofta större men svårare att mäta.