Compliance › Software

Compliance software: byg selv eller køb en GRC-platform?

Skal I bygge jeres egen compliance software eller købe en GRC-platform? Se hvad systemet skal kunne på tværs af GDPR, NIS2, DORA og AI-forordningen, hvad de to veje koster over fem år, og hvornår det faktisk giver mening at bygge.

En vej, der deler sig i et byg-spor med en kran og et køb-spor med en færdig platform, som mødes igen i én fælles platform

For få år siden handlede spørgsmålet om at bygge eller købe compliance software næsten kun om GDPR. En fortegnelse, nogle databehandleraftaler og en hændelseslog kunne godt ligge i et regneark eller et lille internt system. Sådan ser det ikke ud længere. Den danske NIS2-lov har været i kraft siden 1. juli 2025, DORA har gældt for den finansielle sektor siden 17. januar 2025, AI-forordningens frister er netop blevet flyttet, og Cyber Resilience Act har krævet rapportering fra producenter siden 11. september 2026.

Samtidig er det blevet fristende at bygge selv. Med AI-kodeværktøjer og lavkodeplatforme kan en udvikler have en fungerende prototype klar på en uge. Spørgsmålet er, hvad der sker i de næste fem år.

Denne artikel giver dig et beslutningsgrundlag. Vi rydder op i de veje, I reelt kan vælge imellem, viser hvilke krav et system skal kunne dokumentere på tværs af regelsæt, regner på et fiktivt eksempel over fem år og er ærlige om, hvornår det giver bedst mening at bygge. Vi er selv leverandør af en GRC-platform. Derfor bygger tallene på offentlige kilder, og vi skriver hvilke.

Det korte svar: skal I bygge eller købe compliance software?

For langt de fleste organisationer med 50 til 1.000 ansatte er det billigere og mindre risikabelt at købe en GRC-platform og bygge integrationer ved siden af. Den store udgift ved egenudvikling er ikke første version. Det er drift, sikkerhed og den løbende tilpasning til nye regler, som I står alene med i hele systemets levetid. Byg selv, hvis compliance er en del af jeres kerneprodukt, hvis I har krav, ingen leverandør kan opfylde, eller hvis I allerede har et platformsteam og en udviklingsproces under jeres ISMS. Uanset valget gør et system jer ikke compliant. Det gør jeres kontroller, jeres ledelse og jeres dokumentation.

Tre veje, ikke to

Debatten bliver ofte stillet op som byg mod køb. I praksis vælger organisationer mellem tre veje, og mange ender med en blanding. Det er nyttigt at skille dem ad, før I sammenligner priser, fordi de fejler på forskellige måder.

Vej	Hvad det er	Hvem ejer vedligeholdelsen	Typisk faldgrube
Regneark og dokumenter	Excel, SharePoint eller Teams med skabeloner, mapper og en årsplan	Den compliance-ansvarlige	Ingen sporbarhed, dobbeltregistrering på tværs af regelsæt og afhængighed af én person
Egenudviklet system	Et internt system bygget fra bunden, på en lavkodeplatform eller med AI-genereret kode	Jeres it-afdeling eller en ekstern udviklingspartner	Drift, sikkerhed og regelændringer bliver en permanent intern opgave
Købt GRC-platform	Standardsoftware til governance, risiko og compliance, som konfigureres til jeres organisation	Leverandøren (platformen) og jer (indholdet)	Funktioner, I ikke bruger, og afhængighed af en leverandør
Hybrid	Købt platform som kerne, egne integrationer og rapporter via API eller BI-værktøj	Delt	Integrationerne skal også vedligeholdes, men de er små og afgrænsede

Regnearket er ikke per definition forkert. For en organisation med få behandlingsaktiviteter og ingen NIS2-forpligtelser kan det række langt. Vi har skrevet en særskilt sammenligning af GDPR i Excel eller i software. Denne artikel handler om det næste skridt: når regnearket ikke længere slår til, og valget står mellem at udvikle et system selv og at købe et.

Fire kolonner sammenligner regneark, egenudviklet system, købt GRC-platform og hybrid på ejerskab af vedligeholdelse og typisk faldgrube

Hvad compliance software skal kunne i 2026

Den mest undervurderede del af et byggeprojekt er kravspecifikationen. Et system til compliance er ikke et dokumentarkiv. Det skal kunne vise over for en tilsynsmyndighed eller en revisor, at I har gjort det, reglerne kræver, og hvornår. Tabellen viser de regelsæt, en typisk dansk organisation med 50+ ansatte skal forholde sig til, og hvad systemet konkret skal kunne dokumentere.

Regelsæt	Hvad systemet skal kunne dokumentere	Retskilde	Gælder fra
GDPR	Fortegnelse over behandlingsaktiviteter, databehandlere og aftaler, risikovurderinger, sikkerhedsbrud og at I kan påvise overholdelse	Art. 5, stk. 2, art. 24, art. 28, stk. 3, art. 30, art. 32 og art. 33, stk. 5	25. maj 2018
NIS2	Ledelsens godkendelse af risikostyringsforanstaltninger, de ti minimumsforanstaltninger, leverandørsikkerhed og hændelsesrapportering (24 timer, 72 timer, 1 måned)	NIS2-direktivet art. 20, art. 21, stk. 2, og art. 23, gennemført ved lov nr. 434 af 6. maj 2025	1. juli 2025 (dansk lov)
DORA	Register over aftaler med ikt-tredjepartsleverandører, klassificering og rapportering af ikt-hændelser og exitstrategier	Forordning (EU) 2022/2554, art. 17-19 og art. 28-30	17. januar 2025 (finansielle enheder)
AI-forordningen	AI-færdigheder, oversigt over AI-systemer, forpligtelser for idriftsættere og konsekvensanalyse af grundlæggende rettigheder	Forordning (EU) 2024/1689, art. 4, art. 26 og art. 27, ændret ved forordning (EU) 2026/1744	Art. 4 fra 2. februar 2025. Højrisiko efter bilag III fra 2. december 2027
Cyber Resilience Act	Rapportering af aktivt udnyttede sårbarheder og alvorlige hændelser for producenter af produkter med digitale elementer	Forordning (EU) 2024/2847, art. 14	11. september 2026 (rapportering). Øvrige krav 11. december 2027
ISO/IEC 27001:2022	Risikovurdering og -håndtering, Statement of Applicability, dokumenteret information, intern audit og ledelsens evaluering	Kl. 6.1.2, 6.1.3, 7.5, 9.2 og 9.3 samt 93 kontroller i Annex A	Frivillig standard. 2013-certifikater udløb 31. oktober 2025

To ting springer i øjnene. Den første er, at kravene overlapper. En årlig gennemgang af en it-leverandør kan på én gang opfylde tilsynet med en databehandler efter GDPR art. 28, forsyningskædesikkerheden i NIS2 art. 21, stk. 2, litra d, registeret i DORA art. 28 og ISO 27001-kontrollerne A.5.19 til A.5.22. Det er kernen i GRC: én kontrol, mange krav. Et hjemmebygget system skal derfor ikke bare gemme opgaver. Det skal kunne koble hver opgave til flere krav i flere regelsæt og vise status for hvert regelsæt for sig. Den datamodel er sværere at bygge rigtigt, end den ser ud.

Den anden er, at listen ikke står stille. Vi forklarer mere om overlappet i vores artikel om risikostyring på tværs af GDPR, NIS2, DORA og ISO 27001.

Reglerne ændrer sig, mens I bygger

Se på de sidste 14 måneder alene. Den danske NIS2-lov trådte i kraft 1. juli 2025. Data Act begyndte at gælde 12. september 2025 med nye regler om skift mellem cloudtjenester. EU-Domstolen afsagde 4. september 2025 dom i sag C-413/23 P (EDPS mod SRB), som nuancerer, hvornår pseudonymiserede data er personoplysninger for en modtager. Kommissionen fremsatte 19. november 2025 sit forslag til en digital omnibus, der vil ændre GDPR og samle indrapportering af hændelser. Forordning (EU) 2026/1744 trådte i kraft 27. juli 2026 og flyttede AI-forordningens højrisikofrister. Og 11. september 2026 blev CRA-rapporteringen obligatorisk.

Hver af de ændringer betyder nyt indhold, nye felter eller nye frister i et compliance-system. Hos en leverandør deles det arbejde mellem alle kunder. I et hjemmebygget system lander det hos jer. Det er ikke kun private virksomheder, der mærker det. I Statens It-råds statusrapport for første halvår 2025, offentliggjort 3. februar 2026, stod projekter, der er sat i gang for at implementere dansk eller EU-lovgivning, for cirka 65 % af de samlede udgifter i statens store it-projekter.

Tidslinje fra juli 2025 til september 2026: dansk NIS2-lov, dom C-413/23 P, Data Act, digital omnibus, forordning 2026/1744 og CRA-rapportering

Hvad det reelt koster at bygge

De fleste it-projekter går ikke galt. Det er vigtigt at sige, fordi byg-eller-køb-debatten ofte bliver ført med skræmmetal. Problemet er ikke gennemsnittet, men halen: de få projekter, der løber langt over.

Den største undersøgelse på området er Flyvbjerg, Budzier m.fl., The Empirical Reality of IT Project Cost Overruns, offentliggjort i Journal of Management Information Systems i 2022. Forskerne analyserede 5.392 it-projekter og fandt, at budgetoverskridelser følger en potensfordeling. Medianprojektet ramte sit budget. Gennemsnittet for de 4.677 projekter med både estimat og faktisk pris var en faktisk omkostning på 1,8 gange estimatet, fordi et mindretal af projekter løb voldsomt over. Den største overskridelse i datasættet var ifølge forfatterne et lille projekt om tilpasning af et workflow, budgetteret til 1.500 USD, der endte med at koste 425.000 USD.

Det sidste eksempel er værd at hæfte sig ved, fordi et compliance-system i bund og grund er workflows: opgaver, godkendelser, påmindelser og dokumentation. McKinsey og University of Oxford fandt i 2012, at store it-projekter over 15 mio. USD i gennemsnit overskred budgettet med 45 % og tidsplanen med 7 % og leverede 56 % mindre værdi end forventet, og at 17 % gik så galt, at de kunne true virksomhedens eksistens. De tal gælder store projekter og er fra 2012, så brug dem som illustration af halerisikoen, ikke som forventning til et internt compliance-værktøj.

Et dansk billede giver Statens It-råd. I statusrapporten for første halvår 2025 havde 71 % af statens 49 store it-projekter grønt lys. Men de røde og gule projekter, lidt under 30 % af projekterne, stod for cirka 60 % af de samlede it-projektudgifter. Det er det samme mønster: de fleste projekter går fint, og dem, der ikke gør, bliver dyre.

Omkostningerne begynder, når systemet går i drift

Et egenudviklet system har en række udgifter, der sjældent står i det første estimat. Tabellen viser, hvem der typisk bærer dem.

Omkostningspost	Byg selv	Køb GRC-platform
Første version	Udviklingstimer, kravspecifikation fra compliance-teamet, test	Konfiguration og import af eksisterende dokumentation
Hosting, backup og overvågning	Jer	Leverandøren
Sikkerhedsopdateringer og sårbarhedshåndtering	Jer, løbende og uden slutdato	Leverandøren
Adgangsstyring, logning og ændringshistorik	Skal bygges og vedligeholdes	Standardfunktion, som I konfigurerer
Nyt regelsæt eller ændret regel	Nyt udviklingsprojekt	Ny eller opdateret skabelon, som I tilpasser
Nøglepersonrisiko	Høj, hvis én udvikler kender koden	Lav på platformen, men stadig reel for indholdet
Abonnement	Ingen	Løbende, typisk pr. modul eller pr. bruger
Selve compliance-arbejdet	Jer	Jer

Den sidste række er med for ærlighedens skyld. Ingen compliance software laver risikovurderingen, leverandørtilsynet eller ledelsesrapporteringen for jer. Den strukturerer arbejdet, genbruger det på tværs af regelsæt og gør det sporbart. Det er det, I betaler for, eller det, I bygger.

AI-kodeværktøjer gør prototypen billig, ikke driften

I 2026 er det realistisk, at en dygtig udvikler med et AI-kodeværktøj bygger en brugbar prototype af et opgave- og dokumentationssystem på få dage. Det ændrer regnestykket for første version. Det ændrer ikke regnestykket for de fire år, der følger. Kode, der er genereret hurtigt, skal stadig sikkerhedstestes, dokumenteres og vedligeholdes af nogen, der forstår den. Og indholdet, altså hvilke krav systemet skal dække, og hvordan de hænger sammen, kommer ikke fra kodeværktøjet. Det kommer fra jeres jurister og sikkerhedsfolk.

Stablede søjler for år 1 til 5 ved egenudvikling: første version er 33 % af femårsomkostningen, drift, sikkerhed og regelopdateringer 61 %

Når systemet selv bliver et compliance-objekt

Her er den vinkel, de fleste byg-eller-køb-artikler overser. Et compliance-system indeholder personoplysninger om medarbejdere, registrerede og leverandørkontakter, beskrivelser af jeres sårbarheder og detaljer om sikkerhedshændelser. Det er et af de mest følsomme systemer, I har. Derfor er det selv omfattet af de regler, det skal hjælpe jer med at overholde, og kravene ser forskellige ud afhængigt af, om I bygger eller køber.

Krav	Hvis I bygger selv	Hvis I køber
GDPR art. 25 og art. 32	I skal selv designe databeskyttelse gennem design og standardindstillinger og passende sikkerhed ind i systemet	I skal vurdere, om leverandørens foranstaltninger er passende
GDPR art. 28	Ikke relevant for jeres eget system (men for hostingleverandøren)	Leverandøren er databehandler. I skal have en databehandleraftale efter art. 28, stk. 3 og føre tilsyn
NIS2 art. 21, stk. 2, litra d og e	Sikkerhed ved udvikling og vedligeholdelse, herunder håndtering af sårbarheder	Sikkerhed i forsyningskæden og vurdering af leverandøren
ISO 27001:2022 Annex A	A.8.25 til A.8.28 om sikker udvikling og kodning skal fungere i praksis	A.5.19 til A.5.23 om leverandører og cloudtjenester
DORA art. 28-30 (finansielle enheder)	Egen drift, men hosting og underliggende ikt-tjenester skal i registeret	Aftalen skal i registeret og indeholde de krævede kontraktvilkår og en exitstrategi
Exit og dataportabilitet	I ejer data og kode, men også al gæld i koden	Sikr eksport i et brugbart format. Data Act art. 23-31 giver kunder af visse cloudtjenester ret til at skifte, og skiftegebyrer bortfalder fra 12. januar 2027

Når I køber, skal leverandøren kunne dokumentere sin sikkerhed. Spørg efter databehandleraftale, en uafhængig erklæring som ISAE 3000 eller ISAE 3402 eller et ISO 27001-certifikat, placering af data og underdatabehandlere, og hvordan I får jeres data ud, hvis I stopper. Datatilsynets vejledning om tilsyn med databehandlere giver en brugbar model for, hvor grundigt tilsynet skal være. Læs også vores gennemgang af databehandleraftalen.

Når I bygger, er udfordringen en anden. Så skal jeres eget udviklingsteam leve op til de samme krav til sikker udvikling, som I stiller til jeres leverandører. Mange organisationer opdager først ved den første interne audit, at compliance-systemet ikke selv er med i ISMS'ets scope.

Regneeksempel: fem år med compliance software

Vestkyst Forsyning A/S og Mette Holm er fiktive. Vi har opfundet dem til denne artikel, og de er hverken kunder eller en case.

Vestkyst Forsyning er et dansk forsyningsselskab med 220 ansatte inden for drikkevand og spildevand. Selskabet er omfattet af NIS2-loven, behandler personoplysninger om kunder og medarbejdere efter GDPR og bruger ISO 27001:2022 som ramme for informationssikkerheden uden at være certificeret. Mette Holm er compliance- og informationssikkerhedsansvarlig. Hun har i dag en fortegnelse i Excel, leverandøraftaler i SharePoint og en årsplan i Outlook. It-afdelingen på seks personer har foreslået at bygge et internt system på virksomhedens lavkodeplatform.

Mette sætter de to veje op over fem år. Timepriserne er vores antagelser for eksemplet, ikke markedsdata: 850 kr. i timen for en intern udvikler og 750 kr. for en compliance-fagperson, begge fuldt belastet. Abonnementet er .legals listepris pr. september 2026 på 1.500 kr. pr. modul pr. måned ekskl. moms.

Post	Byg selv (5 år)	Køb GRC-platform (5 år)
Kravspecifikation / implementering	200 timer compliance-tid: 150.000 kr.	150 timer compliance-tid til opsætning og import: 112.500 kr.
Første version	900 udviklertimer inkl. test: 765.000 kr.	Ingen
Integration til HR-system	Indeholdt i første version	80 udviklertimer via API: 68.000 kr.
Drift og videreudvikling	250 timer om året i år 2-5: 850.000 kr.	20 timer om året til integrationen i år 2-5: 68.000 kr.
Hosting, backup og årlig sikkerhedstest	80.000 kr. om året i år 2-5: 320.000 kr.	Indeholdt
Regelopdateringer	80 timer compliance-tid om året i år 2-5 til at specificere ændringer i systemet: 240.000 kr.	Nye og opdaterede skabeloner indgår i abonnementet. Tilpasning af eget indhold er ikke medregnet på nogen af siderne
Abonnement	Ingen	4 moduler plus API i 5 år: 420.000 kr.
Leverandørtilsyn	Kun hostingleverandør (ikke medregnet)	10 timer om året: 37.500 kr.
I alt over 5 år	2.325.000 kr.	706.000 kr.

Mette kører derefter to følsomhedsberegninger. Hvis første version ender på 1,8 gange estimatet, som var gennemsnittet i Flyvbjerg-studiet, stiger byggeløsningen til cirka 2,9 mio. kr. Hvis AI-kodeværktøjer halverer udviklingstiden for første version, falder den til cirka 1,9 mio. kr. I ingen af tilfældene når byggeløsningen ned i nærheden af købsløsningen, fordi drift, hosting og regelopdateringer alene koster 1,41 mio. kr. over årene 2 til 5.

Hun noterer også tiden. Den interne løsning ville tidligst være klar efter tre kvartaler, mens platformen kunne tages i brug med det samme. I den periode skulle NIS2-dokumentationen stadig ligge i regneark.

Pointen er ikke, at køb altid vinder. Havde Vestkyst haft et platformsteam med ledig kapacitet og en eksisterende udviklingsproces under ISMS'et, ville de marginale omkostninger være lavere. Og havde selskabet haft behov for at koble compliance-data direkte ind i driftssystemer til styring af vandværker, ville en hybrid med egen integration være det naturlige valg. Eksemplet viser, at regnestykket afgøres af årene efter første version, ikke af første version.

Kumulerede femårsomkostninger for fiktivt forsyningsselskab: byg selv 2.325.000 kr. med bånd fra 1,9 til 2,9 mio. kr., køb 706.000 kr.

Hvornår giver det mening at bygge?

Der er situationer, hvor egenudvikling er det rigtige valg. Vi ser dem sjældnere, end man skulle tro, men de findes. Sæt kryds ved dem, der passer på jer.

☐ Compliance er en del af jeres produkt. I er en bank med egne risikomodeller eller en RegTech-virksomhed, og compliance-logikken er en konkurrencefordel.
☐ I har krav, ingen leverandør dækker. Et sektorspecifikt regelsæt eller en arbejdsgang, som standardplatforme ikke kan konfigureres til.
☐ Data må ikke forlade jeres miljø. Klassificerede oplysninger eller et krav om drift i eget datacenter, som leverandørerne ikke kan opfylde.
☐ I har et platformsteam i forvejen. Et team med ledig kapacitet og en udviklingsproces, der allerede lever op til ISO 27001 A.8.25 til A.8.28.
☐ I er meget store. En koncern med mange selskaber og en it-portefølje, hvor et compliance-system er én af flere hundrede interne applikationer.

Passer to eller flere, er det værd at lave en grundig analyse af at bygge selv. Passer ingen, er spørgsmålet i praksis, hvilken GRC-platform I skal vælge, og om I skal bygge integrationer ved siden af. Hybriden er ofte det bedste af begge: køb kernen med registre, risikovurderinger, frameworks og opgavestyring, og byg de få integrationer og rapporter, der er unikke for jer.

Sådan træffer I beslutningen i seks trin

Kortlæg regelsæt og roller. Hvilke regelsæt gælder for jer i dag, og hvilke kommer inden for tre år? Er I dataansvarlig, databehandler, væsentlig eller vigtig enhed efter NIS2, finansiel enhed efter DORA, idriftsætter af AI?
Beskriv kontroller og overlap. List de kontroller, I allerede udfører, og hvilke krav hver kontrol opfylder. Det viser, hvor meget genbrug systemet skal kunne håndtere.
Skriv kravene til systemet. Ændringslog, adgangsstyring, påmindelser, eksport, rapporter til ledelsen og revisor, integrationer og sprog. Skeln mellem skal og bør.
Beregn femårige omkostninger for begge veje. Tag drift, sikkerhed og regelopdateringer med, og lav en følsomhedsberegning, hvor første version koster det dobbelte.
Vurder leverandøren som leverandør. Databehandleraftale, uafhængig erklæring eller certifikat, dataplacering, exit og eksportformat. For finansielle enheder også DORA-kravene til kontrakten.
Test med et afgrænset område. Tag ét regelsæt eller én afdeling og kør det igennem i praksis, før I binder jer. Det gælder både en prototype og en købt platform.

Vil du gå dybere med leverandørvalget, har vi samlet kriterierne i vores guide til at købe compliance software og i artiklen om GRC-software.

Seks trin til beslutningen om at bygge eller købe: regelsæt, kontroller, krav, femårsberegning, leverandørvurdering og afgrænset test

Hvad compliance software ikke løser

Et system løser et strukturproblem. Det løser ikke et ledelsesproblem. Efter NIS2 art. 20 skal ledelsesorganet godkende risikostyringsforanstaltningerne, føre tilsyn med gennemførelsen og kan holdes ansvarlig for overtrædelser. Ingen platform kan gøre det på ledelsens vegne. Det samme gælder GDPR art. 24, hvor den dataansvarlige skal kunne påvise, at behandlingen sker i overensstemmelse med forordningen.

Et system er heller ikke bedre end de data, der ligger i det. En fortegnelse, der ikke er opdateret, er lige så forkert i en platform som i et regneark. Forskellen er, at platformen kan minde den ansvarlige om at opdatere den, vise hvem der ændrede hvad, og genbruge oplysningerne i risikovurderingen og leverandørtilsynet.

Og så er der de organisationer, hvor ingen af delene er nødvendige endnu. Har I under 50 ansatte, få behandlingsaktiviteter og ingen NIS2-forpligtelser, kan et velholdt regneark med en fast årsplan række. Det vigtigste er, at nogen ejer det.

Sådan understøtter .legal både køb og byg

.legal er en GRC-platform bygget til præcis det overlap, denne artikel handler om. I vores Frameworks-modul kobler I én kontrol eller opgave til de krav, den opfylder i flere regelsæt, for eksempel GDPR, NIS2-loven, ISO/IEC 27001:2022, D-mærket, Data Act og CRA, og status opdateres i alle rammeværk, når opgaven er løst. Opgaverne ligger i compliance-årshjulet med ansvarlige, frister og dokumentation.

Leverandører og databehandlere håndteres i leverandørstyring, hvor det samme leverandørtilsyn kan bruges til både GDPR og NIS2, og aktiver og risici ligger i modulet for informations- og cybersikkerhed. Vil I bygge dele selv, giver Public API adgang til juridiske enheder, kontrakter og aktiver, så I kan koble platformen til jeres egne systemer. Rapporter og lister kan eksporteres, så jeres data ikke er låst inde.

Platformen gør jer ikke compliant, og den erstatter ikke jeres jurister og sikkerhedsfolk. Den fjerner dobbeltarbejdet og driften af et system, så de kan bruge tiden på selve arbejdet. Se priserne, start på den gratis plan, eller book en demo og få vist, hvordan jeres egne regelsæt ser ud i platformen.

Ofte stillede spørgsmål om compliance software

Hvad er compliance software?

Compliance software er et system, der samler dokumentationen af, hvordan en organisation overholder love og standarder. Typisk omfatter det registre over behandlingsaktiviteter, aktiver og leverandører, risikovurderinger, politikker, hændelseslog og en årsplan med opgaver og ansvarlige. Formålet er at kunne påvise overholdelse over for tilsynsmyndigheder, revisorer og kunder og at genbruge den samme dokumentation på tværs af regelsæt som GDPR, NIS2 og ISO 27001.

Hvad er forskellen på compliance software og GRC-software?

GRC står for governance, risk og compliance. GRC-software er den bredere kategori, der ud over dokumentation af regeloverholdelse også dækker risikostyring, ledelsesrapportering, politikker og kontroller på tværs af flere rammeværk. Mange bruger ordene i flæng. I praksis er forskellen, om systemet kan koble én kontrol til krav i flere regelsæt, eller om det er bygget til ét regelsæt, for eksempel kun GDPR.

Hvad koster en GRC-platform?

Prisen afhænger af antal moduler, brugere og selskaber. Nogle leverandører tager betaling pr. bruger, andre pr. modul eller som en samlet enterprise-aftale. Hos .legal koster hvert modul 1.500 kr. om måneden ekskl. moms pr. september 2026, uden binding og med ubegrænset antal brugere. Sammenlign altid den femårige omkostning inklusive implementering og interne timer, ikke kun abonnementet.

Kan man bygge sit eget compliance-system i Excel eller SharePoint?

Ja, og for mindre organisationer med få behandlingsaktiviteter og ingen NIS2-forpligtelser kan det være tilstrækkeligt. Begrænsningerne viser sig, når flere regelsæt skal dækkes. Regneark har svag ændringshistorik, ingen automatiske påmindelser og kræver, at samme leverandør eller kontrol registreres flere steder. Afhængigheden af den ene person, der kender strukturen, er ofte den største risiko.

Er leverandøren af en GRC-platform databehandler?

Som regel ja. Platformen indeholder personoplysninger om medarbejdere, kontaktpersoner og registrerede, og leverandøren behandler dem på jeres vegne. Så kræver GDPR art. 28, stk. 3, en databehandleraftale, og I skal føre et passende tilsyn med leverandøren. Er I omfattet af NIS2 eller DORA, skal leverandøren også indgå i jeres vurdering af forsyningskæden og ikt-tredjepartsrisiko.

Hvor lang tid tager det at implementere compliance software?

En købt platform kan tages i brug med det samme, men opsætning og import af eksisterende dokumentation tager typisk nogle uger, afhængigt af hvor meget I har i forvejen. Et egenudviklet system kræver kravspecifikation, udvikling, test og sikkerhedsgennemgang, før det kan bruges til noget, en revisor skal stole på. Regn med måneder frem for uger, også med moderne værktøjer.

Kan vi bygge compliance software med AI-kodeværktøjer?

I kan bygge en prototype hurtigt, og det kan være en god måde at afklare krav på. Men koden skal stadig sikkerhedstestes, dokumenteres og vedligeholdes, og systemet skal leve op til de krav til sikker udvikling, I selv stiller til leverandører. AI-værktøjerne leverer heller ikke indholdet, altså hvilke krav systemet skal dække, og hvordan de hænger sammen på tværs af regelsæt.

Hvad skal en GRC-platform kunne for at understøtte NIS2?

Den skal kunne dokumentere ledelsens godkendelse og tilsyn efter NIS2 art. 20, de ti minimumsforanstaltninger i art. 21, stk. 2, herunder leverandørsikkerhed, og forløbet ved væsentlige hændelser med frister på 24 timer, 72 timer og en måned efter art. 23. Det er en fordel, hvis den samme dokumentation kan genbruges til ISO 27001 og GDPR i stedet for at blive registreret tre gange.

Hvad sker der med vores data, hvis vi skifter leverandør?

Det afhænger af aftalen, så spørg før I køber. Efter GDPR art. 28, stk. 3, litra g, skal databehandleren slette eller tilbagelevere personoplysninger, når tjenesten ophører. Data Act giver kunder af visse cloudtjenester ret til at skifte udbyder, og skiftegebyrer må ikke opkræves fra 12. januar 2027. Sørg for, at registre og rapporter kan eksporteres i et format, I kan bruge videre.

Gør compliance software os compliant med GDPR og NIS2?

Nej. Et system strukturerer og dokumenterer arbejdet, men compliance afhænger af de foranstaltninger, I faktisk har gennemført, og af at ledelsen tager ansvaret. NIS2 art. 20 lægger ansvaret for risikostyringen hos ledelsesorganet, og GDPR art. 24 kræver, at den dataansvarlige kan påvise overholdelse. Software gør det lettere at bevise, hvad I gør, men det gør ikke arbejdet for jer.

Har du fortsat spørgsmål?

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

Book ham her

.legal compliance platform

Spring byggeriet over og start compliance i dag

Hvorfor bruge måneder på at bygge, når dotlegals complianceplatform er klar nu? Vores gennemprøvede platform leverer alt, du har brug for, til en brøkdel af byggeomkostningerne.