Alt om GRC

Governance, risk & compliance – tre områder som sammen avgjør hvordan en organisasjon styres. Men hva innebærer det i praksis, og hva kreves for å få dem til å fungere sammen? Det går vi nærmere inn på her.

Hva er GRC?

GRC er et samlebegrep for tre arbeidsområder som sammen avgjør hvor godt en organisasjon styres og holder seg på rett side av lover, risiko og egne mål. På norsk brukes også "styring, risikohåndtering og regeletterlevelse".

GRC deles vanligvis inn i tre områder:

Governance: Hvordan virksomheten faktisk styres i det daglige – roller, ansvar, beslutningsveier og oppfølging. Eies typisk av administrerende direktør, styret og ledergruppen.
Risk management: Å identifisere, vurdere, håndtere og følge opp risiko som kan påvirke organisasjonens mål. Eies typisk av risikoansvarlig, CRO eller en risikokomité.
Compliance: Å sikre etterlevelse av lover, bransjeregler og interne retningslinjer. Eies typisk av compliance officer, Head of Legal eller internkontroll.

Slik ser inndelingen ut. Men i praksis flyter områdene sammen. Et NIS2-spørsmål er samtidig en risiko, et compliance-spørsmål og et styringsspørsmål. En leverandørvurdering berører både informasjonssikkerhet, personvern og internkontroll.

Det er nettopp i disse overgangene problemene oppstår. Derfor er det mer nyttig å tenke på GRC som et sammenhengende system for virksomhetsstyring enn som tre separate funksjoner.

Hvordan skiller governance, risk management og compliance seg fra hverandre?

Den enkleste måten å skille dem på er gjennom hvilket spørsmål hver av dem stiller..

Governance stiller spørsmålet "hvem tar beslutningene, og ut fra hva?".
Risk management stiller spørsmålet "hva kan gå galt, og hvor sannsynlig er det?".
Compliance stiller spørsmålet "følger vi det vi må følge?". I praksis er svarene ofte vevd sammen, men spørsmålene må fortsatt stilles hver for seg for ikke å bli glemt.

Fire vanlige utfordringer i GRC-arbeid

De fleste organisasjoner jobber allerede med GRC. Spørsmålet er bare hvordan. Vi ser fire mønstre gå igjen hos organisasjonene vi snakker med – uansett bransje og uansett modenhet.

Fragmentert arbeid

Risiko håndteres i ett verktøy, informasjonssikkerhet i et annet, internkontroll i et tredje. Compliance lever i Excel. Hver av delene fungerer - isolert sett. Men ingen ser det store bildet, og i overgangene mellom dem oppstår det både dobbeltarbeid og blindsoner. Et tydelig eksempel er hvordan IKT-risikoer ofte håndteres isolert fra annen risikostyring, noe vi tar for oss i vår artikkel om hvordan man integrerer IKT-risikoer med organisatorisk risikostyring.

Mangelfull oversikt

Ledelsen mår rapporter, men de kommer fra ulike systemer, på ulike tidspunkter og med ulike definisjoner av hva som er "rødt" eller "grønt". Beslutninger tas uten et samlet bilde av risikosituasjonen, og oppfølgingen blir reaktiv snarare enn styrende.

Uklart eierskap

Ansvaret er spredt over flere funksjoner - juridisk, IT, sikkerhet, drift, kvalitet - og når alle eier en del, er det ingen som eier helheten. Kritiske spørsmål faller mellom stolene eller håndteres for sent.

Reaktivt arbeid

Når det ikke finnes noen struktur, blir GRC-arbeidet en rekke brannutrykninger. Tid og ressurser brukes på å løse problemer i etterkant i stedet for å forebygge dem. Når et nytt regelverk trer i kraft - cybersikkerhetsloven, NIS2, DORA, CSRD - starter arbeidet fra scratch i stedet for å bli håndtert innenfor en eksisterende struktur. Dette er ikke et problem som kan løses med flere verktøy eller flere mennesker. Det er et strukturelt problem. Og så lenge strukturen mangler, vokser kompleksiteten raskere enn kontrollen.

Risiko som nav: slik henger GRC-arbeidet sammen

Risiko er ikke enda et domene ved siden av compliance og informasjonssikkerhet. Det er logikken som binder dem sammen. Hvorfor? Fordi risiko er det eneste perspektivet som tvinger frem prioriteringer. Compliance kan i verste fall bli en uendelig liste med krav som skal krysses av.

Informasjonssikkerhet kan reduseres til et sett med tekniske kontroller. Internkontroll kan stivne i et årshjul. Men når dere tar utgangspunkt i risiko - hva kan gå galt, hvor sannsynlig er det, og hva blir konsekvensene? - da får hver aktivitet en kobling til virksomhetens faktiske situasjon.

For den vil dykke dypere i dette perspektivet, har vi skrevet mer om
hvordan risikomodenhet ser ut i praksis. Det er ofte der forskjellen mellom en organisasjon som lykkes og en som setter seg fast, blir synlig.

Konkret betyr det at

Et compliance-spørsmål blir interessant først når det er koblet til en risiko. Hva er det vi vil beskytte oss mot? Hvilke kontroller håndterer den risikoen? Da blir etterlevelse et resultat av god styring, ikke et mål i seg selv.
Et informasjonssikkerhetstiltak prioriteres ut fra hvilke informasjonsverdier som er mest kritiske og hvilke trusler de står overfor - ikke ut fra hva som tilfeldigvis er lettest å implementere.
Internkontroll blir et system for å verifisere at de viktigste risikoene er under kontroll, ikke en separat årshjul på siden av virksomheten.

Når dere gjør risiko til nav, får dere også en felles målestokk. Risiko er språket som CISO, Risk Manager, Head of Legal, Controller og CEO kan forstå sammen. Det er der samtalen om GRC kan skifte fra "hva skal vi gjøre for å slippe bøter" til "hva skal vi gjøre for at virksomheten skal fungere også når det blåser".

Spesialister er ikke nok - GRC må fungere på tvers av hele organisasjonen

Dette er punktet der de fleste GRC-initiativ mister fart, og det er verdt å stoppe opp ved. Vi ser det samme mønsteret gang på gang: organisasjoner satser på en dyktig CISO, en kompetent risikoansvarlig, en erfaren Head of Legal. Hver av dem bygger et strukturert bilde av sitt område. Og så stopper arbeidet der.

Rammeverk skrives som ingen utenfor spesialistfunksjonen leser. Risikovurderinger gjøres i parallelle verktøy som ledere ute i virksomheten aldri ser. Compliance-ansvar dokumenteres i retningslinjer som ikke påvirker hvordan arbeidet faktisk utføres.

Dette er ikke et kunnskapsproblem - spesialistene kan faget sitt. Det er et problem med adopsjon, og det er noe vi går dypere inn på i artikkelen vår om styring av informasjonssikkerhet.

GRC blir først virkelig verdifullt når

Linjeledere vet hvilke risikoer de har ansvar for, og kan se status uten å måtte ringe CISO.
Prosesseierne forstår hvilke kontroller de skal gjennomføre, og kan signere dem der arbeidet skjer.
Ledelsen får et samlet bilde av risikosituasjonen uten at noen må klippe sammen tre ulike rapporter manuelt.
Revisoren kan følge kjeden fra risiko til kontroll til tiltak til oppfølging uten å måtte eksportere data.

Dette er ikke detaljer i et verktøy - det er forskjellen mellom GRC-arbeid som lever i hodet på spesialisten, og et som faktisk blir en del av hvordan virksomheten styres.

En del av dette handler om verktøy og flyt, men en like viktig del handler om å bygge kunnskap og sikkerhetsbevissthet fortløpende i organisasjonen, slik at spesialistens rammeverk faktisk lander hos dem som skal handle på den.

Hvilke rammeverk brukes innen GRC?

De fleste organisasjoner som jobber strukturert med GRC, støtter seg på etablerte rammeverk. Her er noen av de vanligste:

ISO 27001/ISO 27002 - internasjonal standard for ledelsesystem for informasjonssikkerhet.Bygger på risiko som utgangspunkt og krever dokumentert styring, risikovurdering og kontinuerlig forbedring. Er ofte det første rammeverket en organisasjon sertifiserer seg mot.

NIS2 og Cybersecurity Act - henholdsvis EU-direktiv og svensk lov som stiller krav til cybersikkerhet og risikohåndtering for en bred gruppe organisasjoner. Lagen gjelder fra 15. januar 2026.

DORA - EU-forordning for digital operasjonell motstandsdyktighet i finanssektoren, med fokus på IKT-risiko og tredjepartshåndtering..

GDPR - den grunnleggende personvernforordningen som stiller krav til hvordan personopplysninger håndteres, dokumenteres og beskyttes.

I tillegg til disse finnes det rammeverk som NIST Cybersecurity Framework og ISO 31000 (prinsipper for risikostyring) som supplement, avhengig av bransje og behov.

Hvordan kommer dere i gang med GRC? Fire steg som faktisk fungerer

En struktur som fungerer, er ikke et imponerende organisasjonskart i en PowerPoint. Det er en måte å jobbe på som kan skaleres opp uten at man mister kontrollen.

1. Forstå - kartlegg det som skal styres

Dere kan ikke styre det dere ikke ser. Første steg er derfor å skape et felles bilde av hvilke prosesser og verdier som er kritiske for virksomheten, hvilke regelverk og interne styringsdokumenter som påvirker dem, og hvilke roller og ansvar som er knyttet til dem.
Dette skal ikke være en engangsøvelse. Det skal være et levende grunnlag som oppdateres når virksomheten endrer seg. Det er fundamentet alt annet hviler på.

2. Vurder - sett risiko i sentrum

Når grunnlaget er på plass, er neste steg å vurdere risikoen knyttet til det. Hva kan gå galt? Hvor sannsynlig er det? Hva blir konsekvensen? Hvilke kontroller har vi allerede på plass?

Dette er essensen av en risikodrevet tilnærming. En gjennomtenkt risikovurdering gir to ting: et grunnlag for prioritering (hvor skal vi sette inn ressurser?) og et felles språk (hva mener vi når vi sier at noe er "høyt prioritert"?).

3. Handle - håndter risikoer der den finnes

Strukturert styring betyr at tiltak havner hos rett person, til rett tid, med rett mandat. Det er her de fleste organisasjoner mister fremdriften: En risiko identifiseres, en tiltaksplan utarbeides - og så renner den ut i sanden.

For den som ønsker å se hvordan dette fungerer i en spesifikk sammenheng, har vi oppsummert 7 suksessfaktorer i håndteringen av IKT-risikoer, der de samme prinsippene gjelder.

En bærekraftig struktur gjør det enkelt å fordele eierskap, sette tidsfrister og se status. Ikke i parallelle systemer, men i den samme flyten der risikoen ble vurdert.

4. Følg opp - gjør det til en levende prosess

Det siste steget er å lukke loopen. Tiltak som iverksettes, bør følges opp, kontroller testes og status rapporteres - ikke én gang i året, men kontinuerlig. Når det gjelder scenarier som driftsforstyrrelser, er kontinuitetsplanlegging et tydelig eksempel på at struktur og forberedelser gjør en forskjell i stundens hete.

Når de fire stegene kobles sammen - forstå, vurdere, handle, følge opp - blir GRC en kontinuerlig syklus i stedet for en serie prosjekter. Og det er da strukturen holder selv når nye forskrifter kommer til eller virksomheten vokser.

Hva er et GRC-system, og hva gjør det?

Et GRC-system er en programvarestøtte som binder sammen arbeidet med virksomhetsstyring, risikostyring og compliance i samme struktur.

Forskjellen fra punktverktøy (som et risiko-Excel, en separat policy-database eller et system for hendelseshåndtering) er at informasjon kan flyte mellom domenene - en risiko er knyttet til en kontroll, kontrollen er knyttet til en retningslinje, og retningslinjen kobles tilbake til regelverket som krever den.

I praksis betyr dette vanligvis fem grunnleggende funksjoner:

Risikoregister med eierskap. Alle risikoer dokumentert, prioritert og tildelt.
Kontroller knyttet til risikoer. Sporbar kobling fra risiko til kontroll til tiltak - ikke separate lister.
Retningslinjer og styrende dokumenter. Versjonsstyrte og koblet til regelverkene og kontrollene de oppfyller.
Dashbord og rapportering. Et samlet bilde for ledelse, styre og revisjon - uten manuell sammenstilling.
Distribuert eierskap. At linjeledere, prosesseiere og systemeiere kan arbeide i systemet, ikke bare spesialister.

Markedet deles i dag grovt inn i tre kategorier. Automasjonsfokuserte verktøy som først og fremst automatiserer tekniske kontroller for SaaS-selskaper. Tunge enterprise-systemer bygget for store globale konsern med mangefasetterte regulatoriske behov. Og midt imellom: governance-plattformer bygget for mellomstore og større organisasjoner i offentlig sektor, helse, finans og industri – der behovet er strukturert styring som hele organisasjonen kan delta i, snarere enn automasjon av et smalt utvalg compliance-rammeverk.

Hvordan vet man at det er på tide å skaffe et GRC-system?

Det finnes ikke noe eksakt modenhetsnivå der behovet oppstår, men det er noen tegn som går igjen:

Excel-ark har vokst ut av kostymene sine - flere personer redigerer samme fil, og versjonshåndteringen er sporløst tapt.
Dere har minst to GRC-relaterte roller (risikoleder, CISO, compliance, internkontroll) som i dag ikke jobber i samme system.
Et nytt regelverk har gjort at ad hoc-arbeid ikke lenger er tilstrekkelig - ofte NIS2, DORA eller CSRD.
Ledelsen eller styret har etterspurt samlet rapportering som ingen idag kan produsere uten manuelt arbeid.
Dere har hatt en hendelse eller revisjon der spørsmålet "hvem eier dette?" var vanskeligere å svare på enn det burde være.

Hvis to eller flere av punktene over stemmer, er dere sannsynligvis klare til å begynne. Den vanligste inngangen er risikostyring eller informasjonssikkerhet - deretter vokser arbeidet ut over andre områder etter hvert som strukturen er på plass.

Fra spesialistarbeid i siloer til styring i hele organisasjonen

Hovedforskjellen mellom organisasjoner som ser på GRC som en byrde, og de som ser på det som en løftestang, ligger ikke i hvor mye de jobber med det. Den ligger i hvem som faktisk jobber med det.

I den første kategorien er GRC et spesialistspørsmål. Risiko håndteres av risikofunksjonen, sikkerhet av CISO, compliance av juridisk avdeling. Alle produserer sine egne dokumenter. Men ledelsen får ikke et helhetsbilde, linjelederne kjenner ikke til kontrollene sine, og helheten er aldri samlet på ett sted.

I den andre kategorien er GRC en måte å jobbe på der hele organisasjonen er involvert. Spesialistene setter strukturen, men arbeidet gjøres der det hører hjemme - av prosesseiere, linjeledere og systemansvarlige. Eierskapet er distribuert, og det er nettopp derfor det fungerer i det lange løp.

Det er slik Stratsys GRC-plattform er bygget for. Ikke for spesialistene alene, men for hele organisasjonen.

Oppdag Stratsys GRC-løsning

Ofte stilte spørsmål om GRC

Hva er forskjellen mellom governance, risk management og compliance?

Governance handler om hvordan virksomheten styres – roller, ansvar, beslutningsveier og oppfølging. Risk management handler om å identifisere, vurdere og håndtere risiko som kan påvirke målene. Compliance handler om etterlevelse av lover, regelverk og interne retningslinjer. De tre overlapper i praksis: et regeletterlevelsesspørsmål er ofte også en risiko, og en risiko håndteres gjennom styring. Derfor anbefaler vi å jobbe med dem som et sammenhengende system, med risiko som logikken som binder dem sammen.

Hvem har ansvar for GRC i en organisasjon?

Det korte svaret er: flere. Risikoansvarlig eier risikohåndteringsprosessen, CISO har ansvar for informasjonssikkerhet, Head of Legal eller compliance officer for regeletterlevelse, og internkontrollansvarlig for internkontroll. Det lange svaret er at GRC fungerer først når ansvaret er distribuert ut i organisasjonen – linjeledere eier sine risikoer, prosesseiere eier sine kontroller, og ledelsen har et samlet bilde. Det er forskjellen mellom et GRC-arbeid som lever hos spesialistene og et som faktisk styrer virksomheten.

Hva er et GRC-verktøy eller en GRC-plattform?

Et GRC-verktøy er et system som støtter arbeidet med styring, risikohåndtering og regeletterlevelse. En GRC-plattform går et steg lenger – den binder sammen flere domener (risiko, informasjonssikkerhet, personvern, internkontroll, tredjepartsrisiko) i samme struktur, slik at informasjon kan flyte mellom dem. Forskjellen er ikke teknisk, men organisatorisk: et verktøy løser et avgrenset problem, en plattform støtter en måte å jobbe på tvers av hele organisasjonen.

Når trenger man et GRC-system?

De fleste organisasjoner havner i samme situasjon: Excel holder ikke lenger, risiko håndteres parallelt i flere verktøy, ledelsen får rapporter som ikke henger sammen, og nye regelverk som NIS2 eller DORA gjør at arbeidet ikke lenger kan være ad hoc. Det er da et GRC-system blir aktuelt. Den vanligste inngangen er risikohåndtering eller informasjonssikkerhet – deretter vokser arbeidet ut over andre områder etter hvert som strukturen er på plass.

Hvordan kommer man i gang med GRC-arbeid?

Vi anbefaler fire steg: forstå (kartlegg prosesser, regelverk og roller), vurder (identifiser og prioriter risiko), handle (fordel eierskap og gjennomfør tiltak) og følg opp (mål, rapporter, juster). Det viktigste er å ikke prøve å gjøre alt på én gang. Start med ett område der behovet er tydeligst – ofte risiko eller informasjonssikkerhet – og bygg ut derfra. En vanlig fallgruve er å prøve å implementere en fullstendig GRC-struktur som et konsulentprosjekt, noe som sjelden overlever det første året.

Hvordan henger GRC sammen med NIS2, DORA og andre regelverk?

NIS2 (cybersikkerhet), DORA (digital operasjonell motstandsdyktighet i finanssektoren), CSRD (bærekraftsrapportering) og GDPR (personvern) er alle regelverk som krever dokumentert styring, risikovurdering og oppfølging. De er ikke separate problemer – de er ulike innganger til det samme underliggende behovet for strukturert styring. En organisasjon med en fungerende GRC-struktur kan møte nye regelverk innenfor eksisterende arbeidsmåte i stedet for å starte et nytt prosjekt hver gang. Det er hele poenget med å jobbe strukturert.

Hva menes med GRC-modenhet?

GRC-modenhet beskriver hvor strukturert og proaktivt en organisasjons GRC-arbeid er. Lav modenhet innebærer siloer, reaktivt arbeid og uklart eierskap. Høy modenhet innebærer integrert styring, risikodrevet prioritering og kontinuerlig oppfølging.

Hva koster mangelfull GRC?

De direkte kostnadene er de mest synlige: regulatoriske bøter, hendelseskostnader og tapte forretninger. De indirekte kostnadene – tid som brukes på reaktiv brannslukking, forsinkede beslutninger, dobbeltarbeid mellom team – er ofte større, men vanskeligere å måle.