Tilbage til bloggen
GRC

Hvad er GRC? Governance, risiko og compliance forklaret

GRC står for Governance, Risk og Compliance. Betydningen af GRC rækker ud over selve akronymet: Det beskriver, hvordan organisationer strukturerer deres interne regler, håndterer usikkerhed og opfylder eksterne lovgivningsmæssige krav – ikke som tre separate arbejdsområder, men som én sammenhængende tilgang.

31.07.2026
14'
Professional reviewing a GRC dashboard showing governance, risk, and compliance metrics.
Maurice Müller

Maurice Müller

Senior Content Manager

Maurice Müller er journalist og content strategist med erfaring inden for trykte og digitale medier. Hos Formalize formidler han komplekse emner inden for compliance og regulering til klart og praktisk indhold for fagfolk inden for compliance, risiko og sikkerhed i hele Europa.

De vigtigste pointer

  • GRC samler governance, risikostyring og compliance i én samlet driftsmodel.

  • Uden en fælles struktur er der en tendens til, at disse tre funktioner udfører overlappende arbejde og skaber blinde vinkler.

  • En GRC-platform hjælper teams med at styre kontrolforanstaltninger, dokumentation og rapportering på tværs af flere frameworks.

Hvad er GRC?

GRC er en struktureret måde for organisationer at skabe sammenhæng mellem beslutningstagning, risikobevidsthed og lovmæssige forpligtelser. Konceptet blev udviklet af Open Compliance and Ethics Group (OCEG) i begyndelsen af 2000’erne og formelt defineret i 2007, men den underliggende udfordring er ældre: I takt med at organisationer vokser, har governance-, risiko- og compliance-funktionerne en tendens til at udvikle sig hver for sig, med forskellige værktøjer, forskellige ansvarlige og begrænset overblik på tværs af teams.

Resultatet er dobbeltarbejde, inkonsekvent dokumentation og mangler, der først kommer til syne under en audit.

GRC løser dette ved at behandle governance, risiko og compliance som en fælles driftsmodel frem for separate, isolerede afdelinger.

De tre søjler i GRC

Governance

Governance indebærer, hvordan en organisation træffer beslutninger og placerer ansvar. Dette omfatter interne politikker, bestyrelsestilsyn, godkendelsesstrukturer og fordelingen af ansvarsområder på tværs af teams. God governance betyder, at det altid står klart, hvem der har ansvaret for en beslutning, og hvem der kan holdes ansvarlig, når noget går galt.

Risiko

Risikostyring er processen med at identificere, hvad der kan gå galt, vurdere, hvor sandsynligt og hvor alvorligt det ville være, og beslutte, hvad der skal gøres ved det. I en GRC-sammenhæng er risiko ikke blot et juridisk eller finansielt begreb. Det omfatter operationelle risici, leverandørrisici, datarisici og de compliance-risici, der opstår ved manglende overholdelse af lovgivningsmæssige krav.

Compliance

Compliance betyder at opfylde de krav, der gælder for jeres organisation: regulativer, love, branchestandarder og interne politikker. For de fleste europæiske virksomheder i dag betyder det at håndtere flere overlappende frameworks på én gang, herunder NIS2, DORA, ISO 27001 og GDPR. Udfordringen består i at gøre dette uden at skulle genopbygge de samme kontrolforanstaltninger og dokumentation fra bunden for hvert enkelt framework.

Hvad betyder GRC inden for cybersikkerhed?

I en cybersikkerhedssammenhæng anvender GRC den samme tredelte struktur – governance, risiko og compliance – specifikt i forhold til, hvordan en organisation beskytter sine systemer, sine data og sin infrastruktur.

Governance definerer, hvem der har ansvaret for sikkerhedsbeslutninger: hvem der godkender sikkerhedspolitikken, hvem der godkender risikoundtagelser, og hvem der rapporterer til bestyrelsen, når noget går galt. Risikostyring identificerer og prioriterer sikkerhedsspecifikke trusler: sårbarheder, tredjepartsadgang, fejlkonfigurationer og de operationelle konsekvenser af et sikkerhedsbrud. Compliance handler om at påvise, at sikkerhedskontrollerne overholder de gældende regler, hvilket for europæiske organisationer i stigende grad betyder specifikt NIS2 og DORA, sideløbende med bredere frameworks som ISO 27001.

Det, der adskiller dette fra generelt compliance-arbejde, er tempoet. Sikkerhedsrisici ændrer sig hurtigere end de fleste lovgivningsmæssige cyklusser: En ny sårbarhed eller hændelse kan dukke op mellem planlagte gennemgange, ikke kun mellem audits. En GRC-tilgang udviklet til cybersikkerhed, skal understøtte løbende risikovurdering og indsamling af dokumentation – ikke blot et periodisk øjebliksbillede – så governance og compliance kan følge med den hastighed, som risikobilledet udvikler sig med.

Særligt for sikkerhedsteams er det her, GRC holder op med at være en compliance-øvelse, som varetages af andre, og i stedet bliver en del af den daglige sikkerhedsdrift: Dokumentation for hændelser, kontrolstatus og audit-parathed samles i det system, som sikkerhedsteams allerede anvender til at styre risici.

Hvorfor er GRC vigtigt?

Compliance-landskabet har ændret sig. For ti år siden håndterede mange organisationer compliance som et årligt projekt: forbered jer til auditten, bestå den, og så videre. Den model fungerer ikke længere.

Lovgivningen kræver nu løbende dokumentation, tydelig ansvarsfordeling og audit-parat dokumentation på ethvert tidspunkt. NIS2 og DORA kræver for eksempel begge, at organisationer udviser vedvarende operationel modstandsdygtighed – ikke blot et årligt øjebliksbillede.

Det er her, en GRC-tilgang bliver praktisk frem for teoretisk. Når governance, risikostyring og compliance deler det samme framework, de samme kontroller og den samme dokumentation, holder organisationer op med at udføre det samme arbejde tre gange og begynder i stedet at opbygge noget, de reelt kan stole på.

  • Mindre dobbeltarbejde: Kontroller og dokumentation kan understøtte flere krav på samme tid

  • Tydeligere ansvarsfordeling: Risici, politikker og kontroller har navngivne ansvarlige

  • Bedre gennemsigtighed: Ledelsen kan se risici, forfaldne opgaver og kontrolstatus

  • Mere effektive audits: Dokumentation er koblet direkte til de relevante kontroller og krav

  • Nemmere tilpasning til nye krav: Nye krav kan kortlægges i forhold til eksisterende kontroller og processer

Hovedelementerne i et GRC-program

Et velfungerende GRC-program dækker typisk fire områder:

  • Styring af politikker og kontroller: Et centralt sted til at dokumentere politikker, tildele ansvarlige og holde styr på, om kontrollerne er aktive og opdaterede.

  • Risikovurdering: En struktureret proces til at identificere risici, vurdere dem ud fra sandsynlighed og konsekvens samt beslutte, hvordan de skal håndteres.

  • Styring af audits og dokumentation: En metode til løbende at indsamle dokumentation – ikke kun op til en audit – og vise, at dokumentationen er aktuel, godkendt og knyttet til det rette krav.

  • Rapportering og dashboards: Et overblik, der giver ledelsen et klart billede af compliance-status, aktuelle risici, forfaldne opgaver og kommende forpligtelser.

Hvad er et GRC-værktøj?

Regneark er ofte udgangspunktet. De er fleksible, velkendte og tilstrækkelige, når et enkelt team håndterer ét framework med et begrænset antal kontroller. De begynder dog at svigte, når compliance bliver til en løbende proces.

Udfordringen er ikke, hvad et regneark kan registrere. Det er, hvad det ikke pålideligt kan styre: ejerskab, versionshistorik, dokumentationsspor, kortlægning på tværs af frameworks og audit-parat rapportering. Når et team forbereder sig på en DORA-evaluering, og den relevante dokumentation er spredt ud over delte mapper, e-mailtråde og individuelle indbakker, bliver det reelle arbejde at bevise, at alt er opdateret, tildelt og knyttet til det rette krav.

En GRC-platform løser dette ved at give teams ét samlet sted til at styre kontroller, dokumentation, risici og rapportering på tværs af adskillige frameworks. Når man evaluerer en GRC-løsning, bør teams kigge efter automatisering af arbejdsgange, kontrolkortlægning på tværs af frameworks, løbende indsamling af dokumentation og audit-parat rapportering.

Tegn på, at en organisation er klar til at gå fra regneark til et GRC-værktøj:

  • Den samme kontrol eller politik optræder i flere frameworks, men vedligeholdes separat i hvert enkelt.

  • Forberedelse til audits tager ugevis, fordi dokumentationen er spredt på tværs af værktøjer og indbakker.

  • Ledelsen har ikke noget pålideligt overblik over compliance-status mellem audits.

  • Ansvaret for kontrollerne er uklart, og opgaver spores af enkelte personer i stedet for at være tildelt i et system.

Se, hvordan Formalize hjælper teams med at erstatte fragmenterede processer med strukturerede GRC-arbejdsgange.

GRC vs. ERM: Hvad er forskellen?

Enterprise Risk Management (ERM) fokuserer specifikt på at identificere og håndtere risici i hele organisationen. GRC er bredere: det omfatter risiko, men dækker også governance-strukturer og compliance-forpligtelser.

I praksis har de fleste organisationer brug for begge dele. ERM leverer risikometodikken, mens GRC leverer det driftsmæssige rammeværk, der forbinder risikostyring med governance-beslutninger og compliance-krav. Mange GRC-platforme indeholder funktioner til risikostyring som en del af en bredere compliance-infrastruktur.

GRC i praksis: et eksempel

Her kan I se, hvordan GRC anvendes i et typisk compliance-scenarie: styring af brugeradgang på tværs af en organisation.

Område

Eksempel

Governance

Ledelsen fastlægger, hvem der kan godkende adgang, og hvor ofte der skal foretages kontroller

Risiko

Organisationen vurderer risikoen for omfattende eller forældede adgangsrettigheder

Compliance

Adgangskontroller og godkendelser dokumenterer overholdelsen af relevante sikkerhedskrav

Kontroller

User access is reviewed quarterly and removed when no longer required

Dokumentation

Logfiler over gennemgange, godkendelser og afhjælpningsforanstaltninger opbevares centralt

Rapportering

Forfaldne gennemgange og uafklarede adgangsproblemer er synlige for kontrolansvarlige og ledelsen

Sådan kommer I i gang med GRC

De fleste organisationer behøver ikke omstrukturere hele deres compliance-program for at se resultater. Den mere praktiske tilgang er at starte med ét højt prioriteret område (NIS2-parathed, DORA-rapportering eller indsamling af dokumentation til ISO 27001) og bygge videre derfra.

Det første skridt er som regel at kortlægge det eksisterende: Hvilke politikker er på plads, hvilke kontroller er aktive, hvem har ansvaret for dem, og hvilke regelsæt skal de understøtte. Derfra bliver manglerne synlige, ansvaret kan placeres, og indsamlingen af dokumentation kan begynde.

Et bibliotek over compliance-frameworks kan hjælpe teams med at koble eksisterende kontroller til adskillige lovkrav uden at skulle opbygge det hele fra bunden.

Ofte stillede spørgsmål

Book en demo