Compliance › Governance

GRC-implementering: sådan undgår du de udfordringer, der får den til at gå i stå

De fleste GRC-implementeringer går i stå af organisatoriske grunde, ikke på grund af softwaren. Guiden viser, hvordan klart ejerskab, enklere processer og dokumentation, der kan vedligeholdes, holder jeres i gang, med RACI, køreplan og nøgletal koblet til NIS2, DORA, GDPR og ISO 27001.

GRC-implementering som tre forbundne platforme: to kolleger, der giver et opgavekort videre, en trappe med fire trin og et årshjul med opgavekort i fire kvartaler

De fleste GRC-implementeringer går ikke ned på lanceringsdagen. De går stille i stå, måneder senere. Platformen kører, frameworks er lagt ind, og kickoff-mødet gik godt. Så holder kontrolejerne op med at opdatere deres opgaver, det gamle regneark bliver stadig vedligeholdt ved siden af, og den første interne gennemgang finder dokumentation, som ingen har rørt siden go-live.

Årsagerne er sjældent tekniske. De er organisatoriske. Ingen ved, hvem der ejer hvad, første fase forsøgte at dække alle frameworks på én gang, og dokumentationen har hverken ejer eller revisionsdato. Det er det mønster, vi ser hos de 400+ organisationer, der bruger .legal, og det svarer til det, både fagfolk og danske revisionsrapporter beskriver.

Denne guide viser, hvordan du undgår det. Den forklarer, hvad en GRC-implementering egentlig indebærer, hvilke udfordringer der får den til at gå i stå, og de tre greb der løser dem: klart ejerskab, enklere processer og dokumentation, der kan vedligeholdes. Hvert greb er koblet til de EU-regler, der allerede kræver det, med artikelnumre. Til sidst får du en køreplan for de første 12 måneder og de nøgletal, der viser, om det virker.

Det korte svar: hvorfor GRC-implementeringer går i stå

En GRC-implementering går i stå, når organisationen behandler den som en softwareinstallation i stedet for en ændring af, hvordan ansvar, processer og dokumentation fungerer. Tre ting forhindrer det.

Klart ejerskab. Ledelsen har ansvaret og godkender. Hver kontrol, risiko og registrering har én navngiven ejer, der gør arbejdet.
Enklere processer. Start med det framework, I er lovmæssigt forpligtet til, kør det helt igennem i ét område, og udvid så ved at genbruge kontroller.
Dokumentation, der kan vedligeholdes. Hvert dokument har en ejer, en revisionsdato og en plads i årshjulet, så det stadig er aktuelt et år efter den første audit.

Der findes ingen pålidelig, offentliggjort fejlrate for GRC-projekter, så vær skeptisk, når nogen nævner én. Det, der derimod er veldokumenteret, er at mennesker og forandringsledelse afgør resultatet. I Prosci’s forskning i forandringsledelse nåede eller overgik 88 % af projekterne med fremragende forandringsledelse deres mål, mod 13 % af projekterne, hvor forandringsledelsen var dårlig.

Hvad indebærer en GRC-implementering?

GRC står for governance, risk og compliance, altså ledelse, risiko og regelefterlevelse. OCEG, organisationen bag den formelle definition, beskriver GRC som den samlede evne til pålideligt at nå sine mål, håndtere usikkerhed og handle med integritet. Deres GRC Capability Model deler arbejdet op i fire komponenter: Learn (forstå kontekst, kultur og interessenter), Align (sæt strategi og mål), Perform (forebyg, opdag og afhjælp) og Review (tjek at design og drift virker).

En GRC-implementering er processen, hvor den evne bliver til daglig drift. Den forveksles ofte med tre beslægtede begreber, og det er typisk her, scope-problemerne starter.

Begreb	Hvad det er	Eksempel
GRC-framework	Den struktur af krav og kontroller, I arbejder efter	ISO/IEC 27001, NIS2 artikel 21, OCEG-modellen
GRC-program	Den faste organisering, de roller og det tilbagevendende arbejde, der holder jer compliant	Navngivne ejere, et årshjul, kvartalsvis ledelsesrapportering
Køreplan for implementering	En tidsbestemt plan for at få programmet i drift	En 90-dages pilot og derefter en 12-måneders udvidelse
GRC-system	Værktøjet, der understøtter programmet	En platform med frameworks, opgaver, risikoregister og rapportering

Rækkefølgen er vigtig. Et GRC-system understøtter et program, det erstatter det ikke. Køber I værktøjet, før I har besluttet, hvem der ejer hvad, ender I med at sætte det op efter det gamle regneark og arve alle dets problemer. Læs mere om selve begrebet i vores introduktion til governance, risiko og compliance og om værktøjerne i vores guide til GRC-software.

Typiske udfordringer ved GRC-implementering

Det er de udfordringer, vi oftest møder, holdt op mod fagfolks egne undersøgelser. Hver af dem viser et genkendeligt symptom længe før projektet officielt går i stå, og det er nyttigt, for så kan du fange det tidligt.

Udfordring	Tidligt symptom	Grundårsag	Løses under
Ingen navngivne ejere	Opgaver tildelt "Compliance" eller en fælles indbakke	Ansvaret forlader aldrig compliance-funktionen	Greb 1
Intet ledelsesmandat	Styregruppemøder aflyses, beslutninger eskaleres og går i stå	Ledelsen ser GRC som et compliance-projekt, ikke en lovpligt	Greb 1
For bredt scope	Fire-fem frameworks i første fase, intet er færdigt efter seks måneder	Ønsket om at "gøre det ordentligt" fra dag ét	Greb 2
Siloer	Privacy, sikkerhed og risiko dokumenterer det samme system hver for sig	Hvert framework køres som sit eget projekt	Greb 2
Overtilpasning	Måneder går med at få værktøjet til at ligne de gamle regneark	Værktøjet bøjes efter en gammel proces	Greb 2
Regneark ved siden af	Det gamle Excel-ark opdateres stadig "for en sikkerheds skyld"	Der blev aldrig sat en slutdato	Greb 3
Dokumentation forælder	Dokumentation ældre end revisionsintervallet, forældet fortegnelse	Ingen ejer eller revisionsdato pr. dokument	Greb 3
Svag forandringsledelse	Ejerne logger aldrig ind, træning springes over	Udrulningen blev behandlet som et it-projekt	Køreplanen

Forskningen peger samme vej. Et indlæg på ISACA’s blog fra december 2025 nævner tre sejlivede årsager til, at GRC fejler: at arbejdet foregår i siloer, at det er reaktivt, og at procedurerne er manuelle. Undersøgelser viser omfanget af det manuelle arbejde. I Dratas State of GRC 2025, en undersøgelse blandt amerikanske virksomheder, svarede 48 % af GRC-fagfolkene, at de har svært ved at følge med i opdateringer af eksisterende frameworks. Hyperproofs benchmark for 2025 fandt, at 52 % bruger 30-50 % af deres tid på administrative opgaver som manuel indtastning. Og i den uafhængige praktikerundersøgelse State of GRC 2026 med 795 besvarelser var regneark stadig det mest udbredte primære GRC-værktøj, nævnt af 93, foran ServiceNow med 86.

Findes der en fejlrate for GRC-projekter? Ikke en pålidelig. Du kan finde tal som "58 % af alle GRC-implementeringer fejler" på leverandørsider, men vi har ikke kunnet spore nogen af dem til en primærkilde, så vi bruger dem ikke. Dokumentationen for forandringsledelse er langt stærkere, og den siger det samme: Det er mennesker og processer, ikke værktøjet, der afgør resultatet.

Infografik med otte typiske udfordringer ved GRC-implementering, deres tidlige advarselstegn og det greb, der løser hver af dem

Greb 1: klart ejerskab

Ejerskab afgør, om de to andre greb virker. Den gode nyhed er, at EU-retten allerede har afgjort halvdelen af spørgsmålet for jer.

Ansvaret ligger hos ledelsen, ifølge loven

På tværs af fire regelsæt placerer lovgiver ansvaret hos ledelsesorganet, ikke hos compliance-medarbejderen.

Regelsæt	Bestemmelse	Hvad den kræver
NIS2	Artikel 20, stk. 1	Ledelsesorganet godkender foranstaltningerne til styring af cybersikkerhedsrisici efter artikel 21, fører tilsyn med gennemførelsen og kan holdes ansvarligt for overtrædelser
NIS2	Artikel 20, stk. 2	Medlemmer af ledelsesorganet skal deltage i undervisning
DORA	Artikel 5, stk. 2	Ledelsesorganet fastlægger, godkender, fører tilsyn med og er ansvarligt for rammen for IKT-risikostyring og bærer det endelige ansvar for IKT-risici
DORA	Artikel 5, stk. 4	Ledelsesorganets medlemmer skal have tilstrækkelig viden og færdigheder til at forstå og vurdere IKT-risici
GDPR	Artikel 5, stk. 2, og artikel 24, stk. 1	Den dataansvarlige er ansvarlig for og skal kunne påvise overholdelse. Foranstaltningerne skal gennemgås og ajourføres efter behov
ISO/IEC 27001:2022	Punkt 5.1 og 5.3	Topledelsen sikrer, at ansvar og beføjelser for informationssikkerhedsroller er tildelt og kommunikeret

I Danmark har NIS2-loven (lov nr. 434 af 6. maj 2025) været i kraft siden 1. juli 2025 og viderefører ledelsesansvaret i dansk ret. Vores NIS2-vejledning gennemgår trinene.

To niveauer: ansvarlig og udførende

Implementeringer, der går i stå, samler som regel ejerskabet på ét niveau. Enten "ejer" bestyrelsen det hele, og intet sker, eller også ejer DPO'en eller CISO'en det hele og bliver flaskehalsen. Løsningen er to niveauer. Ledelsesorganet har ansvaret: det godkender, fører tilsyn og modtager rapporter. Navngivne personer i forretningen er udførende: de ejer et system, en proces, en leverandør eller en kontrol og gør det daglige arbejde.

En enkel RACI-matrix gør det konkret. R = udfører arbejdet, A = har ansvaret og godkender, C = konsulteres, I = informeres.

Aktivitet	Ledelsesorgan	Compliance- / risikoansvarlig	CISO	DPO	System-, proces- eller kontrolejer	Intern audit
Godkend risikoappetit og centrale politikker	A	R	C	C	I	I
Godkend NIS2- / DORA-foranstaltninger	A	R	R	I	C	I
Hold fortegnelsen efter GDPR art. 30 opdateret	I	A	C	C	R	I
Drift en kontrol og dens dokumentation	I	C	A	–	R	I
Vurder og håndter en risiko	I	A	C	C	R	I
Klassificer og indberet en væsentlig hændelse	I	C	A/R	C	C	–
Intern audit og årlig gennemgang	I	C	C	C	C	A/R

I en mindre organisation kan én person have flere af rollerne. Det er fint, så længe hver aktivitet stadig har én navngiven ejer, og ingen både udfører arbejdet og selv kontrollerer det uafhængigt.

Ansvar på to niveauer: tre medlemmer af ledelsesorganet gennemgår et dokument øverst, forbundet til fem ejere nedenunder, der arbejder med en server, et procesforløb, en leverandørpakke, en kontrolliste og en kontorbygning

Kobl rollerne til Three Lines-modellen

IIA's Three Lines Model fra 2020 giver RACI'en en anerkendt struktur. Det øverste ledelsesorgan står til ansvar over for interessenterne og fører tilsyn. Ledelsen leverer organisationens mål og ejer risikoen som første linje. Roller i anden linje, fx compliance, risiko, informationssikkerhed og DPO, bidrager med ekspertise, overvågning og udfordring. Intern audit er den uafhængige tredje linje. Mellemstore organisationer uden intern audit bruger ofte en ekstern revisor eller en ISAE 3402-erklæring til det uafhængige blik.

Gør ikke DPO'en til ejer af det hele

Efter GDPR artikel 39 skal DPO'en informere, rådgive og overvåge overholdelsen, og artikel 38, stk. 6, kræver, at andre opgaver ikke skaber en interessekonflikt. Fortegnelsen er den dataansvarliges pligt, ikke DPO'ens. Hvis DPO'en vedligeholder fortegnelsen alene, har I gjort en rådgiver til en driftsperson og skabt et single point of failure. Lad procesejerne holde deres del af fortegnelsen opdateret, og lad DPO'en kontrollere den.

Greb 2: enklere processer, der starter småt og modnes over tid

Den mest almindelige fejl i scope er at implementere alle frameworks i alle forretningsenheder i første fase. Det føles grundigt. I praksis betyder det, at intet bliver færdigt, ingen ser fremskridt, og projektet mister sin sponsor.

Brug en modenhedsmodel til at sætte målet

Modenhedsmodeller inspireret af OCEG og CMMI beskriver, hvordan GRC udvikler sig fra ad hoc til optimeret. De er ikke en certificering, men de hjælper jer med at aftale et realistisk mål med ledelsen. Statslige myndigheder kender princippet fra Digitaliseringsstyrelsens ISO 27001-modenhedsmåling.

Niveau	Sådan ser det ud	Typisk dokumentation	Næste skridt
1. Ad hoc	Compliance afhænger af enkeltpersoner og personlige mapper	Spredte filer og mails	Navngiv ejere og vælg det første framework
2. Fragmenteret	Hvert framework køres separat af sit eget team	Ét regneark pr. team	Saml ét framework i et fælles system
3. Standardiseret	Én metode, definerede roller og et årshjul for mindst ét framework	Log over gennemførte opgaver, risikoregister	Tilføj næste framework ved at genbruge kontroller
4. Integreret	Et fælles kontrolkatalog på tværs af frameworks og fast ledelsesrapportering	Én dokumentation koblet til flere krav	Mål effekten med nøgletal
5. Optimeret	Løbende forbedring drevet af nøgletal og auditresultater	Trendrapporter, erfaringsopsamling	Bliv ved med at justere

For de fleste mellemstore organisationer er niveau 3 i første år og niveau 4 i andet år et fornuftigt mål. Niveau 5 er et valg, ikke en pligt.

GRC-modenhedsmodel som fem stigende platforme, fra spredte ark over sorterede stakke og samlede klodser til en færdig struktur, med et flag på tredje niveau som målet for første år

Vælg det første framework ud fra pligt, ikke ambition

Start der, hvor loven allerede kræver, at I er. Det giver projektet en deadline, en sponsor og en begrundelse, ingen kan diskutere.

Omfattet af NIS2: Start med foranstaltningerne i artikel 21 og brug ISO/IEC 27001 som kontrolsæt.
Finansiel enhed under DORA: Start med rammen for IKT-risikostyring i artikel 5-16.
Alle, der behandler personoplysninger: Start med fortegnelsen efter artikel 30 og risikovurderingen efter artikel 32.
Drevet af kundekrav: Start med ISO 27001, som de fleste kunder og udbud efterspørger ved navn.

Gå derefter smalt og dybt. Tag ét framework gennem én forretningsenhed eller en håndfuld kritiske systemer, helt fra kortlægning til første gennemgang. En færdig pilot lærer organisationen mere end et halvfærdigt program, der dækker det hele.

Genbrug kontroller, men tjek hullerne

Frameworks overlapper meget, og overlappet er officielt dokumenteret. I juni 2025 udgav ENISA teknisk implementeringsvejledning til gennemførelsesforordning (EU) 2024/2690, hvor hvert krav er mappet til ISO/IEC 27001:2022, NIST CSF 2.0 og andre standarder. ENISA skriver samtidig udtrykkeligt, at mappingen ikke skal læses som ækvivalens. Genbrug dokumentationen, og tjek så hullerne.

Emne	ISO/IEC 27001:2022	NIS2	DORA	GDPR
Risikovurdering	Punkt 6.1.2, 8.2	Art. 21, stk. 2, litra a	Art. 6, 8	Art. 32, 35
Hændelseshåndtering	A.5.24-A.5.28	Art. 21, stk. 2, litra b, og art. 23	Art. 17-19	Art. 33-34
Driftskontinuitet	A.5.29-A.5.30	Art. 21, stk. 2, litra c	Art. 11	Art. 32, stk. 1, litra c
Leverandørsikkerhed	A.5.19-A.5.23	Art. 21, stk. 2, litra d	Art. 28-30	Art. 28
Træning og awareness	Punkt 7.3, A.6.3	Art. 20, stk. 2, og art. 21, stk. 2, litra g	Art. 5, stk. 4, og art. 13, stk. 6	Art. 39, stk. 1, litra b
Adgangsstyring	A.5.15-A.5.18, A.8.5	Art. 21, stk. 2, litra i-j	Art. 9, stk. 4, litra c	Art. 32

Det, der ikke kan genbruges: NIS2-registrering og indberetningsfrister, ledelsens undervisningspligt, DORA's informationsregister over IKT-tredjepartsleverandører og det specifikke indhold i GDPR-fortegnelsen. Planlæg dem som selvstændige opgaver. Vores guide til risikostyring viser, hvordan ét dokumenteret risikoscenarie kan dække flere frameworks på én gang.

Tilpas værktøjet til processen, ikke omvendt

Overtilpasning er en langsom måde at gå i stå på. Teams bruger måneder på at genopbygge det gamle regneark i det nye værktøj, kolonne for kolonne, og genskaber de samme problemer et dyrere sted. Aftal processen først: hvem ejer hvad, hvor ofte gennemgås det, og hvad tæller som dokumentation. Brug så platformens standardskabeloner, og tilpas kun dér, hvor jeres lovkrav eller forretning reelt er anderledes.

Greb 3: dokumentation, der kan vedligeholdes

Det meste GRC-dokumentation er i god stand på dagen for den første audit. Problemet er året efter.

Det, der forælder først: erfaringer fra den offentlige sektor

Statslige myndigheder har skullet følge ISO 27001 siden 2014, og standarden skulle være fuldt implementeret i begyndelsen af 2016. Alligevel viste Digitaliseringsstyrelsens måling, at kun 16 af 109 myndigheder havde fuldt implementeret standarden i 2018, og 39 af 113 i september 2019. Det svageste område var måling, audit og evaluering, altså præcis den del, der holder et ISMS aktuelt, efter det er bygget.

I januar 2022 konstaterede Rigsrevisionen, at ingen af fem kritiske statslige myndigheder levede op til alle 20 tekniske minimumskrav til it-sikkerhed, og at fire af de fem havde handlingsplaner, de ikke havde fulgt. I 2021 rapporterede Københavns Kommunes databeskyttelsesrådgiver, at ingen af kommunens forvaltninger havde en proces, der sikrede, at GDPR-fortegnelsen løbende blev opdateret. Og efter tilsyn med fortegnelserne i tre kommuner i 2020 præciserede Datatilsynet sin vejledning om fortegnelser.

Ingen af disse organisationer manglede politikker. De manglede en mekanisme, med navngivne personer og datoer, der holdt arbejdet i gang efter det første skub.

Minimumsdokumentationen

Hold dokumentationen så lille, som reglerne tillader, og sørg for, at hvert element har en ejer og en revisionscyklus. Revisionsintervallerne nedenfor er almindelig praksis, medmindre reglen selv fastsætter dem.

Framework	Kernedokumentation	Retsgrundlag	Typisk gennemgang
GDPR	Fortegnelse, risikovurderinger og konsekvensanalyser, databehandleraftaler, log over brud	Art. 30, 32, 35, 28, 33, stk. 5	Årligt og ved væsentlige ændringer
ISO/IEC 27001:2022	Scope, politik, risikovurdering og risikohåndteringsplan, SoA, intern audit, ledelsens evaluering	Punkt 4.3, 5.2, 6.1.2, 6.1.3, 9.2, 9.3	Med planlagte intervaller
NIS2	Ledelsens godkendelse af foranstaltninger, dokumentation for undervisning, hændelsesprocedure, leverandørvurderinger	Art. 20, 21, 23	Årligt og ved væsentlige ændringer
DORA	Ramme for IKT-risikostyring, informationsregister over IKT-tredjepartsleverandører, klassificering af hændelser	Art. 6, 28, stk. 3, art. 17-18	Rammen gennemgås mindst én gang om året (art. 6, stk. 5)

Fire regler, der holder dokumentationen levende

Én navngiven ejer for hvert dokument, hver kontrol, risiko og registrering. Et team er ikke en ejer.
En revisionsdato, der sættes ved oprettelsen. Ved ingen, hvornår et dokument skal gennemgås, bliver det ikke gennemgået.
Versionsstyring og ændringslog. ISO/IEC 27001 punkt 7.5.3 kræver styring af distribution, adgang, opbevaring, versioner og opbevaringstid. Det er god praksis alle andre steder også.
Dokumentation gemt ved den kontrol, den beviser, ikke i en mailtråd eller på et personligt drev.

Kør arbejdet gennem et årshjul

Et årshjul gør statiske dokumenter til tilbagevendende arbejde med ejere og frister. En enkel version ser sådan ud.

Kvartal	Tilbagevendende opgaver	Ejer	Dokumentation
K1	Gennemgå fortegnelsen, opdater leverandørlisten og klassificeringen	Proces- og leverandørejere	Opdateret fortegnelse, leverandørregister
K2	Opdater risikovurderinger, gennemfør en awareness-kampagne	Risikoejere, compliance-ansvarlig	Risikoregister, gennemførelse af træning
K3	Intern audit, test af hændelseshåndtering og beredskab	Intern audit eller ISMS-ansvarlig, CISO	Auditrapport, testrapport
K4	Ledelsens evaluering, godkendelse af foranstaltninger, politikker og næste års plan, ledelsesundervisning	Ledelsesorganet	Referater, godkendelser, dokumentation for undervisning

Brug vores compliance-årshjul til at sætte det op, og vores guide til awareness-træning til kampagnen i K2.

Udfas til sidst regnearket på en fast dato. At køre begge dele "for en sikkerheds skyld" fordobler arbejdet og sikrer, at de to versioner glider fra hinanden. Vores artikel om GDPR i Excel eller software gennemgår fordele og ulemper.

GRC-årshjul i fire kvartaler, hvor hvert kvartal har opgavekort med en ejer og et flueben, mens fire kolleger sætter opgaver ind og afslutter dem

Eksempel: sådan kom en GRC-implementering i gang igen

Nordvig Forsyning A/S og Line Bech er fiktive. Vi har opfundet dem til denne artikel, men mønsteret er almindeligt.

Nordvig Forsyning er et forsyningsselskab med 180 ansatte, der er omfattet af NIS2. I januar købte selskabet et GRC-system og lagde GDPR, NIS2 og ISO 27001 ind på én gang. Line Bech, der er compliance-ansvarlig, tildelte de fleste opgaver til sig selv og resten til it-afdelingens fælles postkasse. I juni havde 12 % af kontrollerne aktuel dokumentation, det gamle regneark var stadig i brug, og bestyrelsen havde drøftet NIS2 to gange.

Genstarten krævede fem beslutninger.

Ledelsesorganet godkendte et mandat på én side med økonomidirektøren som sponsor, Line som programleder og kvartalsvis rapportering.
Scope blev skåret ned til NIS2-foranstaltningerne for tre kritiske systemer, med ISO 27001 som kontrolsæt.
De 41 kontroller i scope blev fordelt på ni navngivne ejere i it, drift og indkøb.
De tilbagevendende opgaver kom ind i årshjulet, hver med en ejer, en frist og den dokumentation, opgaven skal give.
Regnearket blev udfaset 1. september.

Halvfems dage senere havde alle kontroller en navngiven ejer, og 85 % havde aktuel dokumentation. I første kvartal året efter tilføjede Nordvig GDPR og genbrugte sine leverandørvurderinger og dokumentationen for adgangsstyring i stedet for at starte forfra.

Trin i en GRC-implementering: køreplan for de første 12 måneder

De ti trin sætter de tre greb i rækkefølge. De virker både til en første implementering og til en genstart.

Afklar forpligtelser og scope. List de love og standarder, der gælder, og hvilke enheder, systemer og processer de dækker.
Sikr et ledelsesmandat og en sponsor. Få ledelsesorganet til at godkende programmet, scope og rapporteringsrytme.
Mål jeres modenhed. Placer hvert framework på modenhedsskalaen, og aftal et mål for første år.
Navngiv ejere. Byg RACI'en, og giv hver kontrol, risiko og registrering til en person, ikke et team.
Vælg første framework og et pilotområde. Vælg ud fra lovpligt, og hold piloten smal.
Byg minimumsdokumentation og kontrolsæt. Kun det, reglerne kræver og forretningen har brug for, hvert element med ejer og revisionsdato.
Tilpas værktøjet til processen. Brug standardskabeloner, og tilpas kun dér, hvor I reelt er anderledes.
Træn, migrer og udfas regnearket. Træn ejerne i deres opgaver, flyt data, og sæt en fast slutdato.
Gennemfør den første gennemgang. En intern audit eller gennemgang af piloten, rapporteret til ledelsen.
Udvid ved at genbruge kontroller, og gennemgå årligt. Tilføj næste framework eller forretningsenhed via det fælles kontrolsæt.

Fase	Tidspunkt	Milepæle
Fundament	Dag 0-30	Mandat godkendt, forpligtelser kortlagt, ejere navngivet
Pilot	Dag 31-60	Første framework sat op for pilotområdet, dokumentationen er i gang
Drift	Dag 61-90	Regnearket udfaset, de første opgaver i årshjulet gennemført, første ledelsesrapport
Udvidelse	Måned 4-9	Andet framework tilføjet via genbrugte kontroller, flere forretningsenheder med
Gennemgang	Måned 10-12	Intern audit, ledelsens evaluering, plan for år to

De tidsrammer, der offentliggøres, varierer meget. Leverandørernes estimater går fra to-fire måneder for en platform i en mellemstor organisation til 12-18 måneder for en fuld udrulning i en koncern, så tag ethvert enkelttal med forbehold. Vores råd er enklere: Sigt efter at have ét framework i drift, med navngivne ejere og aktuel dokumentation, inden for 90 dage.

Køreplan for GRC-implementering over 12 måneder med faserne fundament, pilot, drift, udvidelse og gennemgang og ét framework i drift på dag 90

Nøgletal, der viser, om jeres GRC-implementering virker

Mål programmet, ikke kun projektet. Disse nøgletal er nemme at hente fra en platform og viser tidligt, når noget begynder at glide.

Nøgletal	Hvad det fortæller	Advarselstegn
Andel kontroller med navngiven ejer	Ejerskabet er på plads	Under 100 % efter piloten
Tilbagevendende opgaver løst til tiden	Processen kører	Faldende fra kvartal til kvartal
Forsinkede risikohåndteringstiltag	Risici bliver faktisk reduceret	En voksende pukkel
Dokumentationens aktualitet	Dokumentationen vedligeholdes	Dokumentation ældre end revisionsintervallet
Tid til at besvare en auditors forespørgsel	Dokumentationen kan findes	Dage frem for timer
Ledelsesrapporter leveret til tiden	Governance virker	Udskudte eller aflyste rapporter
Ledelsens undervisning gennemført	NIS2 art. 20, stk. 2, DORA art. 5, stk. 4	Ingen dokumentation for undervisning
Ejere, der er aktive i platformen	Udbredelse	Ejere, der aldrig logger ind

Forsiden af tjeklisten til GRC-implementering fra .legal

Download tjeklisten til GRC-implementering

Otte sektioner på seks sider: forpligtelser og mandat, ejerskab, scope og første framework, dokumentation, de første 90 dage, årshjulet, nøgletal hvert kvartal og en selvtest med advarselstegn. Brug den før I starter, efter 90 dage og ved den årlige gennemgang.

Download tjeklisten (PDF, 6 sider)

Hvad skal et GRC-system kunne understøtte?

Et GRC-system kan ikke løse ejerskab eller scope for jer, men det forkerte værktøj kan gøre begge dele sværere. Når implementeringen er i fokus, betyder fem egenskaber mest.

Navngivet ejerskab og rollebaseret adgang, så hver kontrol og registrering har én ansvarlig, der kun ser det, vedkommende har brug for.
Tilbagevendende opgaver eller et årshjul med påmindelser og statusoverblik.
Mapping af kontroller på tværs af frameworks, så én dokumentation tæller alle de steder, den gælder.
Audit trail og versionshistorik for hvert dokument og hver beslutning.
Modulopbygning, så I kan starte med ét framework og tilføje det næste uden et nyt projekt.

De fulde kriterier finder du i vores guide til GRC-software og i vores guide til at købe compliance-software.

Sådan understøtter .legal en GRC-implementering

.legal er en modulopbygget GRC-platform, bygget til den måde at arbejde på, som denne guide anbefaler. Frameworks-modulet kobler én opgave til de kontroller, den understøtter, på tværs af GDPR, NIS2, ISO 27001, DORA og AI-forordningen, så I kan starte med ét framework og genbruge arbejdet senere. Compliance-årshjulet giver hver tilbagevendende opgave en ejer, en frist og en status, og med Enterprise Risk Management kobler I risikoscenarier direkte på de aktiver og processer, I allerede har kortlagt.

Ejerskab er bygget ind. Hvert aktiv, hver proces og leverandør har én navngiven ansvarlig, adgangen er rollebaseret, og kolleger, der aldrig logger ind, kan stadig modtage og kvittere for politikker. Når I er klar til at forlade regnearket, viser vores migreringsguide, hvordan I flytter data. Platformen er dækket af ISAE 3402- og ISAE 3000-erklæringer, og data hostes i EU.

Vil du se, hvordan en trinvis implementering ser ud med jeres egne frameworks? Book en demo, så viser vi det.

Har du fortsat spørgsmål?

Spørg Johannes direkte, han giver de fleste af vores demoer personligt. Book ham her.

Ofte stillede spørgsmål om GRC-implementering

Hvordan implementerer man et GRC-program?

Start med at afklare, hvilke love og standarder der gælder, og få derefter ledelsesorganet til at godkende et mandat og udpege en sponsor. Giv hver kontrol, risiko og registrering en navngiven ejer, vælg ét framework som pilot, byg minimumsdokumentationen, tilpas værktøjet til den aftalte proces, og udfas regneark på en fast dato. Efter første gennemgang udvider I ved at genbruge kontroller til næste framework.

Hvor lang tid tager en GRC-implementering?

Det afhænger af scope og størrelse. Et realistisk mål for en mellemstor organisation er ét framework i drift med navngivne ejere og aktuel dokumentation inden for 90 dage og et andet framework inden for det første år. Fulde udrulninger i store koncerner med mange enheder og frameworks tager typisk 12-18 måneder ifølge leverandørernes egne estimater.

Hvorfor går GRC-implementeringer i stå?

Primært af organisatoriske grunde: ingen navngivne ejere, intet ledelsesmandat, en første fase med for mange frameworks, teams der arbejder i siloer, værktøjer der tilpasses til at ligne gamle regneark, og dokumentation uden revisionsdato. Der findes ingen pålidelig fejlrate for GRC-projekter, men forskning i forandringsledelse viser, at mennesker og processer i høj grad afgør resultatet.

Hvad er forskellen på et GRC-framework og et GRC-program?

Et framework er den struktur af krav og kontroller, I arbejder efter, fx ISO 27001 eller NIS2 artikel 21. Et program er den faste organisering, der får det til at virke i praksis: ejere, tilbagevendende opgaver, rapportering og gennemgang. Et framework kan vedtages på en dag, mens et program skal bygges og vedligeholdes.

Hvem skal eje GRC i en organisation?

Ejerskabet fungerer på to niveauer. Ledelsesorganet har ansvaret og godkender foranstaltningerne, som NIS2 artikel 20 og DORA artikel 5 kræver. Det daglige ansvar ligger hos navngivne system-, proces- og kontrolejere i forretningen, støttet af roller i anden linje som compliance, CISO og DPO.

Har bestyrelsen ansvaret for NIS2?

Ja. Efter NIS2 artikel 20 skal ledelsesorganet godkende foranstaltningerne til styring af cybersikkerhedsrisici, føre tilsyn med gennemførelsen og kan holdes ansvarligt for overtrædelser. Medlemmerne skal også deltage i undervisning. Den danske NIS2-lov, der har været i kraft siden 1. juli 2025, viderefører ansvaret i dansk ret.

Hvad er en GRC-modenhedsmodel?

En modenhedsmodel beskriver udviklingstrin, typisk fra ad hoc over fragmenteret, standardiseret og integreret til optimeret. Den er ikke en certificering. Værdien ligger i at aftale et realistisk mål med ledelsen, fx et standardiseret program for ét framework i første år og et integreret program på tværs af frameworks i andet år.

Skal vi implementere flere frameworks på én gang?

Som regel ikke. Start med det framework, I er lovmæssigt forpligtet til, og tag det hele vejen til første gennemgang. Tilføj derefter det næste ved at genbruge kontroller og dokumentation. Frameworks overlapper meget, men ENISA advarer selv om, at en mapping ikke er det samme som ækvivalens, så tjek hullerne hver gang.

Kan man køre GRC i regneark?

Med ét framework og få personer kan det fungere en tid. Det bliver skrøbeligt, når flere frameworks, ejere og audits kommer ind i billedet, fordi regneark mangler en pålidelig audit trail, versionsstyring og påmindelser. Skifter I til et GRC-system, så sæt en fast dato for at udfase regnearket, så de to ikke glider fra hinanden.

Hvilke nøgletal viser, at en GRC-implementering virker?

Nyttige nøgletal er andelen af kontroller med en navngiven ejer, tilbagevendende opgaver løst til tiden, forsinkede risikohåndteringstiltag, dokumentation ældre end revisionsintervallet, tiden det tager at besvare en auditors forespørgsel, og om ledelsesrapporter og ledelsens undervisning gennemføres til tiden.

Har du fortsat spørgsmål?

Spørg Johannes direkte, han giver de fleste af vores demoer personligt

Book ham her

.legal compliance platform

Hold jeres GRC-implementering i gang

Start med ét framework, og byg videre derfra. .legal giver hver kontrol, risiko og registrering en navngiven ejer, kører det tilbagevendende arbejde gennem et årshjul og holder dokumentationen aktuel, også når projektgruppen er gået videre.