Bestyrelsens spørgsmål til digital suverænitet

Kort fortalt

Digital suverænitet er et bestyrelsesanliggende, når digitale afhængigheder kan påvirke strategi, drift, compliance, økonomi eller organisationens handlefrihed. Bestyrelsen skal ikke overtage IT-arkitektur, indkøb eller jura. Den skal sikre, at ledelsen kan dokumentere de afhængigheder, der kan blive strategiske.

Den nyttige bestyrelsesdiskussion er derfor ikke: “Er vi digitalt suveræne?”

Det bedre spørgsmål er:

Hvilke digitale afhængigheder har vi bevidst accepteret, hvilke har vi reduceret, og hvilke kan vi faktisk komme ud af, hvis forudsætningerne ændrer sig?

Artiklen giver et praktisk brief med syv kategorier: strategi, risiko, compliance, leverandørstyring, data, beredskab og exit-planer.

Beslutningen artiklen hjælper med

Artiklen hjælper bestyrelse, direktion, offentlige ledelser, risikoudvalg og revisionsudvalg med at beslutte, om digital suverænitet skal behandles som:

• et emne, der kun rapporteres ved større IT-projekter
• et fast punkt i risikostyring og indkøb for kritiske systemer
• et bestyrelsesforankret tilsyn med organisationens digitale handlefrihed

Anbefalingen er den tredje model for organisationer, hvor digitale systemer understøtter kritiske processer, følsomme data, myndighedsopgaver, kundekontakt, økonomi, produktion, sikkerhed eller lovpligtig dokumentation.

Det betyder ikke, at bestyrelsen skal godkende alle tekniske valg. Det betyder, at bestyrelsen bør kræve et beslutningsgrundlag, når en digital afhængighed kan blive så stærk, at den begrænser organisationens fremtidige valg.

Hvad bestyrelsen bør eje - og ikke eje

Bestyrelsen bør eje tre ting:

1. Risikotolerance: Hvor meget afhængighed kan organisationen acceptere på kritiske systemer?
2. Tilsyn: Får bestyrelsen et ærligt billede af de afhængigheder, der kan påvirke drift, compliance, økonomi og strategi?
3. Beslutningskriterier: Skal nye kritiske indkøb have krav til dataeksport, dokumentation, leverandørkæde, beredskab og exit?

Bestyrelsen bør ikke eje leverandørvalg i detaljer, teknisk implementering, daglig sikkerhedsdrift eller migrationens projektplan. De opgaver ligger hos direktion, IT, sikkerhed, indkøb, jura og forretning.

En god bestyrelsesrolle er at stille spørgsmål, der gør skjulte afhængigheder synlige, før organisationen står i en presset situation: kontraktfornyelse, sikkerhedshændelse, leverandørsvigt, prisændring, tilsynssag, opkøb, geopolitisk ændring eller strategisk omlægning.

Den faktiske ramme: governance, ikke slogan

Digital suverænitet er ikke i sig selv et generelt juridisk krav for alle organisationer. Men flere regelsæt gør de underliggende spørgsmål bestyrelsesrelevante.

GDPR kræver blandt andet, at den dataansvarlige kan gennemføre og dokumentere passende tekniske og organisatoriske foranstaltninger, og at sikkerhedsniveauet passer til risikoen. Det gør leverandørvalg, databehandlerstyring, adgang, backup, dokumentation og hændelseshåndtering relevante for ledelsens tilsyn. GDPR artikel 24 og 32

NIS2 er mere direkte om ledelsesorganer for de omfattede væsentlige og vigtige enheder: ledelsesorganer skal godkende cybersikkerhedsrisikostyring og føre tilsyn med implementeringen. Direktivet nævner også blandt andet forsyningskædesikkerhed, sikkerhed ved anskaffelse, adgangskontrol, aktivstyring og beredskab som dele af risikostyringen. NIS2 artikel 20 og 21

Data Act er relevant for cloud og andre databehandlingstjenester, fordi den indeholder regler om skift mellem tjenester, portering, tekniske begrænsninger og udfasning af visse switching charges. Reglerne fjerner ikke det praktiske arbejde med migration, men de gør exit til et konkret kontrakt- og indkøbsspørgsmål. Data Act kapitel VI

Konklusionen er ikke, at bestyrelsen skal blive compliance-afdeling. Konklusionen er, at digital suverænitet bør behandles som almindelig governance: ansvar, dokumentation, risikotolerance, kontrolpunkter og opfølgning.

Bestyrelsesbrief: syv spørgsmålskategorier

Brug denne model som en fast side i bestyrelsesmaterialet. Den kan anvendes årligt, ved større platformsskift, før kritiske kontraktfornyelser eller som del af et risikoudvalgs arbejde.

Bestyrelsen bør ikke acceptere et “ja” uden dokumentation. Et godt svar indeholder systemnavn, ejer, datatyper, kontraktudløb, afhængigheder, kendte svagheder og næste handling.

Hvad et godt svar ser ud som

Et godt svar fra ledelsen er sjældent perfekt. Det er konkret.

Svagt svar:

“Vi har styr på det hos IT, og leverandøren er markedsledende.”

Stærkere svar:

“Vores identitetsplatform, økonomisystem og dokumenthåndtering er de tre afhængigheder med størst strategisk betydning. Identitetsplatformen er accepteret som strategisk standard, men vi har ikke testet nødadgang uden leverandørens primære kontrolplan. Økonomisystemet fornyes om seks måneder; dataeksport og exit-bistand er ikke tydeligt nok beskrevet. Dokumenthåndteringen har god eksport af filer, men svag eksport af metadata og rettigheder. Direktionen foreslår tre handlinger før næste møde.”

Forskellen er ikke, at det stærke svar lover fuld uafhængighed. Forskellen er, at bestyrelsen kan se, hvad der er kendt, hvad der er accepteret, og hvad der kræver beslutning.

De 21 spørgsmål bestyrelsen kan stille

1. Strategi

1. Hvilke digitale platforme er så centrale, at de påvirker vores mulighed for at ændre strategi, forretningsmodel, servicekanaler eller myndighedsopgaver?
2. Hvilke afhængigheder har vi valgt bevidst, fordi standardisering, sikkerhed eller hastighed vejer tungere end fleksibilitet?
3. Hvilke afhængigheder er opstået gradvist uden en egentlig ledelsesbeslutning?

2. Risiko

1. Hvilke fem systemer ville skade os mest ved 1, 7 og 30 dages utilgængelighed?
2. Hvilke systemer er dyrest eller sværest at forlade, selv om de ikke nødvendigvis har den højeste licenspris?
3. Hvilke afhængigheder har både høj forretningskritikalitet og lav teknisk flytbarhed?

3. Compliance

1. Kan vi dokumentere dataansvar, databehandlerroller, underdatabehandlere, dataflow og sikkerhedsforanstaltninger for kritiske systemer?
2. Hvor afhænger compliance af leverandørens dokumentation, og hvor har vi selv kontrolleret eller testet?
3. Hvilke nye eller kommende krav kan gøre eksisterende leverandørafhængigheder mere risikable?

4. Leverandørstyring

1. Hvilke leverandører er strategiske, fordi de kontrollerer data, identitet, drift, sikkerhed eller kritiske integrationer?
2. Hvilke kontrakter fornyes inden for 12 til 18 måneder, hvor exit, dataudtræk og underleverandører bør vurderes før fornyelse?
3. Hvad sker der ved prisændring, opkøb, supportændring, konkurs, sanktioner, kontospærring eller væsentligt ændrede vilkår?

5. Data

1. Hvilke kritiske data kan eksporteres komplet, inklusive metadata, historik, relationer, bilag, rettigheder og logs?
2. Kan eksporten valideres, og findes der en realistisk importvej til en anden løsning?
3. Hvilke data er teknisk tilgængelige, men praktisk svære at bruge uden leverandørens værktøjer?

6. Beredskab

1. Har vi testet restore, nødadgang, alternativ kommunikation og nøddrift for de mest kritiske digitale afhængigheder?
2. Hvem træffer beslutninger ved leverandørsvigt eller tab af adgang, og hvilke manuelle processer kan holde organisationen kørende?
3. Kan vi få relevante logs, hændelsesdata og supportinformation hurtigt nok under en alvorlig hændelse?

7. Exit-planer

1. Hvilke platforme har en reel exit-plan med ejer, tidslinje, omkostningsoverslag og udløsere?
2. Hvilke systemer har kun en kontraktuel ret til data, men ingen testet migrationsvej?
3. Hvilke afhængigheder bør reduceres nu, fordi en senere exit vil blive dyrere for hvert år?

Dokumentationspakken bestyrelsen bør bede om

Et bestyrelsesbrief behøver ikke være langt. Det bør være præcist. For de mest kritiske systemer bør materialet mindst vise:

Hvis ledelsen ikke kan levere hele pakken første gang, er det ikke nødvendigvis et problem. Det er derimod et problem, hvis ingen ejer at få hullerne lukket.

En enkel risikotolerance-model

Bestyrelsen kan bede ledelsen klassificere kritiske afhængigheder i fire kategorier:

Modellen er bevidst enkel. Den skal ikke erstatte enterprise risk management, men gøre digitale afhængigheder sammenlignelige med andre strategiske risici.

Røde flag i bestyrelsesmaterialet

Følgende svar bør udløse opfølgende spørgsmål:

• “Leverandøren kan hjælpe med eksport, hvis det bliver relevant.”
• “Vi har backup, men restore er ikke testet uden samme platform.”
• “Systemet er ikke kritisk, men næsten alle rapporter eller arbejdsgange afhænger af det.”
• “Kontrakten fornyes automatisk, og exit-vilkår er ikke prioriteret.”
• “Data kan eksporteres, men metadata, rettigheder, historik eller bilag er uklare.”
• “Kun én leverandør eller én intern nøgleperson forstår opsætningen.”
• “Vi har ikke et samlet overblik over underleverandører og supportadgang.”
• “Business casen viser implementering og licenspris, men ikke exit, parallel drift, validering og intern tid.”
• “Identitet, enheder, mail, dokumenter, sikkerhed og logs er samlet i én platform uden scenarie for tab af adgang.”
• “Vi håndterer det ved næste udbud”, selv om næste fornyelse allerede nærmer sig.

Røde flag betyder ikke automatisk, at løsningen er forkert. De betyder, at bestyrelsen ikke bør acceptere risikoen uden et bedre beslutningsgrundlag.

Tradeoffs: uafhængighed er ikke gratis

Bestyrelsen bør undgå to fejl: at ignorere afhængigheder og at gøre uafhængighed til et mål uden proportioner.

Stærke standardplatforme kan give lavere kompleksitet, bedre brugeroplevelse, hurtigere implementering, høj tilgængelighed og moden sikkerhed. En samlet identitetsplatform kan være mere sikker end mange lokale brugerdatabaser. En stor SaaS-løsning kan være bedre dokumenteret end en specialbygget løsning, som kun få personer kan vedligeholde.

Mere kontrol kan til gengæld koste penge, tid og kompetence. Flere leverandører kan skabe integrationsarbejde. Selv-hosting kan give mere kontrol, men også mere driftsansvar. Open source kan give gennemsigtighed og flere leverandørmuligheder, men kræver vurdering af projektets sundhed, support, sikkerhedsopdateringer og intern evne til at tage ansvar.

Den modne bestyrelsesbeslutning er derfor ikke at kræve mindst mulig afhængighed. Den modne beslutning er at kræve synlig, dokumenteret og proportionel afhængighed.

Når rådet ikke passer

En tung bestyrelsesproces passer ikke til alle digitale værktøjer.

Hvis et værktøj er billigt, ikke-kritisk, let at opsige, uden følsomme data og uden integrationer, kan en enkel operationel vurdering være nok. Bestyrelsens tid bør bruges på afhængigheder, der kan påvirke strategi, drift, compliance, sikkerhed, økonomi eller omdømme.

Rådet passer heller ikke som en automatisk afvisning af globale leverandører. En global leverandør kan være et fornuftigt valg, hvis organisationen har krav, dokumentation, sikkerhed, exit, dataadgang og kompetence på plads. Omvendt kan en lokal eller europæisk leverandør skabe stærk binding, hvis data, integrationer, kontrakt og dokumentation er svage.

Første 90 dage: en realistisk dagsorden

Bestyrelsen kan bede direktionen komme tilbage med et første overblik på 90 dage.

Dag 1 til 30: Find de kritiske afhængigheder

Ledelsen udpeger 10 til 15 systemer, der er mest kritiske for drift, data, compliance, økonomi, kommunikation, identitet eller sikkerhed. For hvert system angives ejer, kontraktudløb, vigtigste data, vigtigste integrationer og kendt exit-status.

Dag 31 til 60: Klassificér og dokumentér

Systemerne klassificeres som accepteret, reducerbar, testkrævende eller uacceptabel. De største dokumentationshuller beskrives åbent: dataeksport, underleverandører, restore, adgang, kontraktvilkår, integrationer eller kompetence.

Dag 61 til 90: Beslut handlinger

Bestyrelsen får en beslutningsside med de vigtigste afhængigheder, anbefalet handling, ejer, frist og budgetmæssig konsekvens. Handlingerne kan være en kontraktændring, krav til kommende indkøb, eksporttest, restore-test, dokumentationsløft, alternativanalyse eller en egentlig exit-plan.

Det vigtigste resultat efter 90 dage er ikke et fuldt modenhedsprogram. Det vigtigste er, at organisationen går fra antagelser til kendte beslutninger.

Kildenoter og afgrænsning

Kilderne i denne artikel er brugt til at understøtte afgrænsede governance- og compliancepointer. Artiklen vurderer ikke, om en konkret organisation er omfattet af NIS2, om en konkret behandling opfylder GDPR, eller om en konkret cloudkontrakt opfylder Data Act. Det kræver en konkret juridisk og teknisk vurdering.

Artiklens bestyrelsesbrief, spørgsmål, risikokategorier og 90-dages model er original beslutningsstøtte udarbejdet til denne artikel. Visualet er ikke gengivet fra en ekstern kilde.

Kilder

• Europa-Parlamentets og Rådets forordning (EU) 2016/679, GDPR
• Europa-Parlamentets og Rådets direktiv (EU) 2022/2555, NIS2
• Europa-Parlamentets og Rådets forordning (EU) 2023/2854, Data Act

Dette er generel information og ikke juridisk rådgivning.