Hvad betyder digital suverænitet for danske virksomheder?

Kort fortalt

Digital suverænitet handler om organisationens evne til at forstå, styre og ændre sine digitale afhængigheder. For danske virksomheder er det især et spørgsmål om data, leverandører, kontrakter, kompetencer, beredskab og realistiske alternativer.

Kort over organisatoriske afhængigheder

Kort fortalt

Digital suverænitet betyder ikke, at danske virksomheder skal bygge al teknologi selv eller fravælge globale leverandører. Det betyder, at virksomheden skal kende de digitale afhængigheder, der kan begrænse drift, sikkerhed, compliance, forhandlingsstyrke og strategisk handlefrihed.

En praktisk definition er:

Digital suverænitet er virksomhedens evne til at forstå, styre og om nødvendigt ændre sine digitale afhængigheder uden uacceptabelt tab af data, drift, sikkerhed, compliance, økonomi eller handlefrihed.

Det er et ledelsesspørgsmål, fordi afhængigheder sjældent kun opstår i teknikken. De opstår også i kontrakter, datamodeller, arbejdsgange, identitetssystemer, leverandørkæder og intern kompetence.

Beslutningen artiklen hjælper med

Denne artikel hjælper ledelse, bestyrelse, IT, indkøb og compliance med at beslutte, om digital suverænitet skal behandles som:

et generelt princip uden faste krav
et teknisk arkitekturhensyn i IT-afdelingen
et konkret ledelses- og indkøbskriterium for kritiske systemer

Anbefalingen er den tredje tilgang. Ikke fordi alle afhængigheder er dårlige, men fordi kritiske afhængigheder bør være kendte, dokumenterede og bevidst accepterede.

Hvad digital suverænitet ikke er

Begrebet bliver let uklart, fordi det bruges i både politiske, tekniske og kommercielle diskussioner. For en dansk virksomhed er det nyttigt at afgrænse begrebet nøgternt.

Digital suverænitet er ikke det samme som national isolation. En virksomhed kan godt bruge internationale leverandører og stadig have god styring af data, kontrakter, exit, sikkerhed og beredskab.

Det er heller ikke det samme som selv-hosting. Egen drift kan give mere kontrol, men den kan også skabe sårbarhed, hvis organisationen mangler kompetencer, overvågning, patching, dokumentation og redundans.

Det er ikke automatisk det samme som open source. Open source kan give gennemsigtighed, fleksibilitet og flere leverandørmuligheder, men kun hvis projektet er sundt, kompetencerne findes, og driftsmodellen er realistisk.

Og det er ikke et argument for at vælge den mindste leverandør. En mindre eller lokal leverandør kan også skabe stærk binding, hvis dataeksport, dokumentation, økonomi, support og exit-vilkår er svage.

Den nyttige diskussion handler derfor ikke om ideologisk renhed. Den handler om kontrolpunkter.

Hvor afhængighederne typisk opstår

En virksomhed bør især kortlægge fem typer afhængighed.

1. Data

Dataafhængighed handler ikke kun om, hvor data ligger. Den handler om, hvorvidt virksomheden kan få alle relevante data ud igen i en form, der kan forstås, kontrolleres og bruges i et andet system.

Spørgsmålene er blandt andet:

Kan data eksporteres fuldstændigt, inklusive metadata, historik, relationer, bilag og rettigheder?
Er eksportformatet åbent, almindeligt brugt eller veldokumenteret?
Kan eksporten valideres, så virksomheden ved, hvad der mangler?
Findes der en realistisk importvej til en anden løsning?

GDPR giver registrerede personer en ret til dataportabilitet i bestemte situationer, men den ret løser ikke automatisk en virksomheds samlede migrationsbehov. GDPR artikel 20 er derfor relevant, men ikke nok som exit-strategi.

2. Identitet og adgang

Identitetssystemer er ofte mere kritiske end de enkelte fagsystemer. Hvis login, MFA, grupper, enhedsstyring, betinget adgang og audit logs er bundet tæt til én platform, kan et platformsvalg påvirke næsten alle andre systemer.

Det er ikke nødvendigvis forkert. Central identitet kan give bedre sikkerhed og enklere administration. Men ledelsen bør vide, om identitetslaget er et neutralt fundament eller en låsemekanisme.

3. Integrationer og arbejdsgange

Et system bliver svært at forlade, når andre processer er bygget omkring det. Det kan være API’er, rapporter, automatiseringer, dokumentflows, kundekommunikation, dashboards, regneark, formularer eller manuelle rutiner.

Denne afhængighed er ofte usynlig i kontrakten. Den ligger i måden organisationen arbejder på.

4. Kontrakter og økonomi

Kontrakter kan skabe afhængighed gennem opsigelsesvarsler, minimumskøb, prisregulering, supportmodeller, databehandleraftaler, underleverandører, auditrettigheder, egress-omkostninger og betingelser for assistance ved ophør.

EU’s Data Act er relevant, fordi den blandt andet indeholder regler, der skal lette skift mellem databehandlingstjenester og kræver information om blandt andet eksportformater, tekniske begrænsninger og switching-processer. Data Act kapitel VI bør derfor indgå i vurderingen af cloud- og databehandlingstjenester, men organisationen skal stadig selv stille konkrete krav før kontraktindgåelse.

5. Kompetencer og leverandørmarked

En løsning kan være teknisk åben og alligevel svær at forlade, hvis kun én leverandør, én konsulent eller én intern nøgleperson forstår opsætningen. Digital suverænitet kræver derfor også dokumentation, kompetenceplaner og et realistisk marked af alternative partnere.

Den første ledelsesmodel: kendt, reduceret eller testet

Digital suverænitet bliver praktisk, når virksomheden holder op med at spørge “er vi suveræne?” og i stedet klassificerer afhængigheder.

Tilstand	Betydning	Ledelsens handling
Ukendt afhængighed	Ingen har overblik over data, exit, integrationer eller kontraktbindinger	Kortlæg før næste fornyelse eller større ændring
Kendt og accepteret	Afhængigheden er bevidst valgt, fordi fordelene er større end risikoen	Dokumentér beslutningen og review den fast
Kendt og reducerbar	Afhængigheden er for stærk, men kan mindskes med krav eller arkitekturændringer	Kræv eksport, dokumentation, standarder, alternativer eller kontraktændringer
Kendt og testet	Exit, backup, restore eller leverandørskifte er afprøvet i praksis	Brug testen som beslutningsgrundlag og opdatér beredskab
Uacceptabel	Afhængigheden kan true drift, compliance eller strategi	Lav en prioriteret plan for reduktion eller udskiftning

Modellen er bevidst enkel. Den skal ikke erstatte risikostyring. Den skal gøre det muligt for ledelsen at skelne mellem en afhængighed, der er rationel, og en afhængighed, der bare ikke er blevet opdaget.

Hvorfor regulering gør emnet mere konkret

Digital suverænitet er ikke et selvstændigt juridisk krav for alle virksomheder. Men flere regler peger i samme retning: bedre styring af data, leverandører, sikkerhed og portabilitet.

GDPR kræver blandt andet dokumenterbar ansvarlighed, passende tekniske og organisatoriske foranstaltninger og klare roller mellem dataansvarlige og databehandlere. Det gør leverandørvalg, databehandleraftaler, adgangsstyring og dokumentation til ledelsesrelevante spørgsmål. GDPR

NIS2 stiller for omfattede væsentlige og vigtige enheder krav om cybersikkerhedsrisikostyring, herunder blandt andet forsyningskædesikkerhed, sikkerhed ved anskaffelse, adgangskontrol, asset management og beredskab. Det er ikke en generel regel for alle virksomheder, men det viser en reguleringsmæssig forventning om, at leverandør- og afhængighedsrisici skal styres systematisk. NIS2 artikel 21

Data Act er særlig relevant for cloud, hosting og andre databehandlingstjenester, fordi den adresserer switching, portering, tekniske begrænsninger, åbne grænseflader og gradvis afvikling af visse switching charges. Den fjerner ikke alle praktiske migrationsproblemer, men den gør exit til et mere konkret kontrakt- og indkøbsspørgsmål. Data Act kapitel VI

For virksomheder betyder det: digital suverænitet bør ikke behandles som et løst princip. Det bør omsættes til krav, dokumentation og faste reviewpunkter.

Minimumskrav ved nye kritiske systemer

Når virksomheden køber eller fornyer et kritisk system, bør disse krav vurderes før kontrakt:

Område	Minimumsspørgsmål
Data	Hvilke data kan eksporteres, i hvilke formater, med hvilke metadata og med hvilken dokumentation?
Exit	Hvad sker der ved opsigelse, konkurs, prisændring, opkøb eller leverandørskifte?
Integration	Hvilke API’er, webhooks, filudvekslinger og automatiseringer bliver kritiske?
Identitet	Kan login, rettigheder og logs fungere uden at binde hele porteføljen til samme platform?
Underleverandører	Hvilke datacentre, supportfunktioner, underdatabehandlere og tredjepartstjenester indgår?
Sikkerhed	Kan virksomheden få relevante logs, rapporter, hændelsesinformation og auditgrundlag?
Kompetence	Findes der alternative leverandører, dokumentation og intern viden nok til at skifte retning?
Økonomi	Er exit, dataudtræk, egress, migration, parallel drift og intern tid med i business casen?

Ikke alle krav skal være lige tunge i alle indkøb. Et lille, ikke-kritisk værktøj bør ikke behandles som et kernebank-system. Men fravalg af krav bør være bevidst.

Eksempel: når et tilsyneladende simpelt system bliver strategisk

Forestil dig en mellemstor virksomhed, der vælger et nyt CRM-system. Beslutningen begynder som et salgs- og kundeserviceprojekt. Efter to år ligger der kundedata, samtykker, supporthistorik, marketingflows, rapporter, integration til økonomisystem, automatiske mails, identitetsstyring, dokumenttemplates og ledelsesdashboards i eller omkring systemet.

Hvis virksomheden på det tidspunkt vil skifte leverandør, er spørgsmålet ikke kun, om kundelisten kan eksporteres. Spørgsmålet er:

Kan relationer, historik, samtykker og dokumenter eksporteres korrekt?
Kan rapporter og automatiseringer genskabes uden uforholdsmæssig manuel indsats?
Er integrationerne dokumenteret?
Kan salgs- og supportarbejdet fortsætte under migration?
Er der kontraktuel ret til hjælp ved exit?
Er økonomien for parallel drift og datavalidering medregnet?

Det er her digital suverænitet bliver konkret. Det er evnen til at opdage, at et forretningssystem er blevet en kritisk digital afhængighed, før virksomheden står i en presset forhandling.

Tradeoffs: afhængighed kan være rationel

En vigtig pointe er, at leverandørafhængighed ikke altid er et problem, der skal fjernes.

En stor cloud- eller SaaS-leverandør kan give høj tilgængelighed, moden sikkerhed, stærke administrationsværktøjer og lavere intern kompleksitet. Et standardsystem kan være bedre end en specialbygget løsning, som kun én person forstår. Central identitet kan være mere sikker end mange lokale brugerdatabaser.

Mere uafhængighed kan omvendt koste penge, tid og kompetence. Flere leverandører kan skabe integrationsarbejde. Selv-hosting kan flytte risikoen fra kontrakt til drift. Open source kan give frihed, men også ansvar for vedligehold, sikkerhedsopdateringer og governance.

Den modne beslutning er derfor ikke at minimere alle afhængigheder. Den modne beslutning er at vælge, hvilke afhængigheder virksomheden vil acceptere, og hvilke den vil reducere eller teste.

En modenhedstrappe for virksomheden

Brug denne trappe som første selvvurdering:

Niveau	Kendetegn
1. Reaktiv	Afhængigheder opdages først ved prisstigning, nedbrud, audit, fornyelse eller ønsket leverandørskifte
2. Dokumenteret	Kritiske systemer, data, integrationer, kontrakter og ejere er kortlagt
3. Styret	Nye indkøb har krav til data, exit, sikkerhed, underleverandører og dokumentation
4. Testet	Backup, restore, dataeksport eller exit-scenarier afprøves for udvalgte kritiske systemer
5. Strategisk	Ledelsen får fast rapportering om kritiske digitale afhængigheder og prioriterer reduktion, accept eller investering

De fleste virksomheder behøver ikke starte på niveau 5. Et godt første mål er niveau 2 for de mest kritiske systemer og niveau 3 for nye indkøb.

Første møde: syv spørgsmål ledelsen kan stille

Start med en times møde mellem ledelse, IT, indkøb, jura/compliance og sikkerhed. Brug disse spørgsmål:

Hvilke fem digitale systemer ville skade os mest, hvis vi mistede adgang til dem i 30 dage?
Hvilke fem systemer ville være dyrest eller sværest at forlade?
Hvor er vores identitet, data, dokumenter, logs og backup bundet til samme leverandør eller platform?
Hvilke kritiske data kan vi eksportere og validere i dag?
Hvilke kontrakter fornyes inden for 12 måneder, hvor exit og dataudtræk bør vurderes før fornyelse?
Hvilke afhængigheder accepterer vi bevidst, fordi fordelene er større end risikoen?
Hvilke afhængigheder accepterer vi kun, fordi de ikke er blevet gjort synlige?

Det sidste spørgsmål er ofte det mest værdifulde.

Kilder

Dette er generel information og ikke juridisk rådgivning.