Et nedbrud bliver opdaget på få minutter. En fastfrosset adgangsmodel bliver først opdaget ved en audit.

Her er, hvad du bør gøre inden den 3. november.

Hvad gjorde memberOf egentlig?

Preview-funktionen gjorde det muligt for en dynamisk gruppe at hente medlemmerne fra andre grupper:

user.memberOf -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>'])

Det var det tætteste, Entra ID kom på indlejrede grupper, som downstream-tjenester kunne læse. Organisationer brugte funktionen til at flade et gruppehierarki ud til en struktur, som SharePoint, Teams, Conditional Access og gruppebaseret licensering kunne bruge, fordi indlejrede grupper aldrig har fungeret problemfrit med disse tjenester.

Microsofts angivne årsag til at udfase funktionen er skala. Under previewen blev det observeret, at memberOf kunne forsinke behandlingen af dynamisk medlemskab i en hel tenant – ikke kun for de grupper, der brugte funktionen.

Der kan være en alternativ løsning under udvikling, men der er endnu ikke noget nyt på vej ud.

Hvad går i stykker, og hvor mærker du det først?

Det fastfrosne medlemskab forplanter sig til alt det, der afhænger af gruppen:

• Adgang til SharePoint og Teams. Medarbejdere, der forlader organisationen, beholder adgangen til sites og kanaler. Nye medarbejdere får den aldrig.
• Targeting i Conditional Access. Nye medarbejdere falder uden for en politik, som de burde være omfattet af. Din MFA- eller enhedsoverholdelsespolitik holder dermed stille og roligt op med at dække dem.
• Gruppebaseret licensering. Nye medarbejdere får ikke tildelt licenser. Medarbejdere, der forlader organisationen, fortsætter med at optage licenser, som du betaler for.
• Access packages. Automatiske tildelingspolitikker holder op med både at tildele og fjerne adgange, så en tidsbegrænset adgang i stilhed bliver permanent.
• Dynamiske administrative enheder. Det delegerede administrationsscope begynder at afvige fra organisationsstrukturen.

For regulerede organisationer er der et yderligere problem. Hvis jeres procedure for adgangskontrol siger, at medlemskab vedligeholdes automatisk af en attributbaseret regel, og den regel i stilhed er holdt op med at blive evalueret, er der ikke længere overensstemmelse mellem den dokumenterede proces og systemets faktiske tilstand.

Det er en audit finding, og den kan være svær at afgrænse bagefter. I skal kunne dokumentere, hvem der havde adgang til hvad – og hvor længe.

Hvilke dele af din tenant glemmer folk at kontrollere?

Næsten alle kontrollerer dynamiske grupper. Der er to andre steder, hvor memberOf-regler kan gemme sig, og som næsten ingen kontrollerer:

• Dynamiske administrative enheder. De bliver konfigureret én gang af en person på identity-teamet og derefter aldrig rørt igen. De er heller ikke synlige under et almindeligt adgangseftersyn. Når en sådan enhed fryser fast, holder det delegerede administrationsscope op med at følge organisationsstrukturen.
• Automatiske tildelingspolitikker i Entitlement Management. Reglen ligger i politikkens konfiguration af tilladte mål i stedet for på selve gruppeobjektet. Derfor vil en eksport, der kun fokuserer på grupper, overse den fuldstændigt.

Begge dele kræver Microsoft Graph for at kunne enumereres korrekt. Ingen af dem dukker op, hvis du kun søger under Groups i administrationscenteret.

Den detalje, næsten alle overser: Nogle af dine medlemskaber er allerede frosset fast

Her er den opdagelse, der ændrer, hvordan du bør prioritere arbejdet – og den kommer direkte fra de dokumenterede begrænsninger ved preview-funktionen.

memberOf fjernede aldrig medlemmer, når en kildegruppe blev slettet, eller når et medlem blev fjernet fra en kildegruppe. Dokumentationen siger det direkte: Berørte brugere forbliver medlemmer af memberOf-gruppen, indtil reglen ændres.

Hold det op mod udfasningen. Det betyder, at fastfrysningen den 3. november ikke er starten på jeres drift. Hvis en kildegruppe, der refereres til i en af jeres regler, er blevet slettet eller har fået fjernet medlemmer, er noget af jeres adgang allerede forældet i dag – og har været det, lige så længe kildegruppen har været væk eller medlemmet har været fjernet.

Det er derfor, en memberOf-gennemgang bør identificere hvert eneste kildegruppe-ID i hver regel og kontrollere, om gruppen stadig findes.

Et kildegruppe-ID, der ikke kan opløses, er ikke bare et irriterende datakvalitetsproblem. Det er et tegn på adgang, der på et tidspunkt er holdt op med at afspejle virkeligheden.

Og det er præcis den slags, du helst selv vil opdage, frem for at få det påpeget under en audit.

Hvordan beslutter du, hvad du skal gøre med hver regel?

Der er tre ærlige udfald – og et fjerde, som folk helst undgår at sætte navn på.

Omskriv reglen ved hjælp af understøttede operatorer. Hvis kildegrupperne svarer til en reel attribut, såsom afdeling, stillingsbetegnelse, virksomhedsnavn eller en extension attribute, kan du udtrykke reglen direkte ud fra denne attribut.

Det kan være det bedste udfald, og det tvinger ofte organisationen til endelig at tage den samtale om kvaliteten af HR-data, som burde have været taget for længe siden.

Konverter til tildelt medlemskab. Fastfrys medlemskabet bevidst, og administrer det gennem jeres joiner/mover/leaver-proces. Det er kedeligt, auditerbart og ærligt omkring, hvem der ejer listen.

Slet reglen. En betydelig del af grupperne fra preview-perioden viser sig ikke at blive brugt til noget.

Accepter, at nogle grupper har brug for et dynamisk medlemskab. Det er den løsning, folk ofte springer over. Hvis en gruppes medlemskab udelukkende består af alle medlemmerne fra andre grupper, findes der ingen attribut, der kan udtrykke det. Hvis medlemskabet samtidig skal holdes løbende opdateret, er tildelt medlemskab ikke en migration.

Hvordan tester du en omskrivning, før du implementerer den?

Du ønsker både coverage og precision på 100 %, men de fleste migrationsplaner holder kun øje med coverage.

Coverage er andelen af de nuværende medlemmer, som den foreslåede regel stadig inkluderer. Coverage under 100 % betyder, at nogle personer mister adgang, når ændringen implementeres. Det hører du om samme morgen.

Precision er andelen af den population, som den foreslåede regel inkluderer, og som faktisk er medlem i dag. Precision under 100 % betyder, at nogle personer får adgang, når ændringen implementeres.

Ingen rapporterer om det. Og det er præcis derfor, det er den farlige af de to.

En regel med 100 % coverage og 80 % precision ser ud som en problemfri migration på dagen – men bliver til en stille over-tildeling af adgang, som fortsætter for altid.

Da vi udviklede vores eget analyseværktøj, gjorde vi precision til den blokerende tærskel i stedet for coverage. Værktøjet vil ikke foreslå en omskrivning, der udvider adgangen, men det foreslår gerne en, der efterlader dig med en navngiven liste på otte personer, som manuelt skal tilføjes igen.

En kort manuel opgave er bedre end en usynlig udvidelse af rettigheder.

Uanset hvordan du beregner værdierne, bør du validere den foreslåede regel i Entra-portalen, før du implementerer den, og sammenligne medlemskabet før og efter.

En tilgang i 3 trin

Trin 1: Find alle anvendelser.

Eksportér dynamiske grupper, og søg efter memberOf i reglerne. Gør det samme for dynamiske administrative enheder og automatiske tildelingspolitikker i Entitlement Management via Graph.

For hvert fund skal du registrere, hvad der bruger gruppen: sites, teams, Conditional Access-politikker, licenstildelinger, access packages osv.

Migrationsrisikoen ligger i de systemer og funktioner, der bruger gruppen – ikke i selve gruppeobjektet.

Hvis du vil være sikker på, at du får det hele med, og har brug for hjælp, så kontakt os for en gratis vurdering.

Trin 2: Beslut dig for hver gruppe.

Husk den begrænsning, der oprindeligt fik folk til at bruge memberOf: Funktionen kunne ikke kombineres med andre regler eller operatorer.

En omskrivning er derfor sjældent en direkte oversættelse én til én. Det er en mulighed for at udtrykke den oprindelige intention korrekt.

Trin 3: Validér og dokumentér.

Sammenlign medlemskabet før og efter, bekræft, at de downstream-systemer og -funktioner, der bruger grupperne, stadig fungerer korrekt, og dokumentér ændringen.

Under GxP, NIS2 eller DORA er dokumentationen af valideringen selve leverancen.

Læg en buffer ind inden den 3. november. Du ønsker ikke, at den sidste gruppe bliver migreret på den sidste dag.

Arbejder du med memberOf-grupper i et reguleret miljø?

Vi gennemfører en read-only-vurdering af din tenant og giver dig et register, en anbefaling for hver gruppe samt en valideringsplan.

Kontakt os for at høre mere.

Ulrich Bojko
Udviklingschef

The post Udfasningen af memberOf i Entra: Dine grupper går ikke i stykker – de fryser fast appeared first on Strator.

Skiftet består i, at lifecycle, tilladelser og klassificering bliver forudsætningerne for at kunne anvende kunstig intelligens, snarere end valgfri finjusteringer, der kan håndteres senere. For enhver organisation, der planlægger en implementering af Microsoft 365 Copilot i anden halvdel af året, er det vigtigt at vide, at de ændringer, vi vil gennemgå i denne artikel, ikke er underordnede detaljer, men derimod de nye grundregler. Disse ændringer peger alle i samme retning.

At grundlægge Copilot i pålidelige kilder

Den mest iøjnefaldende af de nye funktioner er Authoritative Sites. Den giver en administrator mulighed for at udpege bestemte SharePoint-websteder som pålidelige, så Microsoft 365 Copilot prioriterer indholdet herfra, når det besvarer spørgsmål i Copilot Chat og Copilot Search. Indstillingen gælder for hvert enkelt websted, kræver en Copilot-licens og er som standard deaktiveret.

Intentionen er god. I en stor tenant skal Copilot basere sine svar på noget, og ikke alt indhold fortjener samme vægt. Den politik, der blev offentliggjort i sidste uge, og det forkastede udkast fra for flere år siden bør ikke have samme autoritet, og Authoritative Sites giver en organisation mulighed for at foretrække de kilder, der har opnået tillid.

Det, som denne funktion ikke gør, er at opbygge tillid på dine vegne. At markere et websted som autoritativt er kun en fordel, hvis webstedet rent faktisk er opdateret, præcist og velforvaltet. Hvis du leder Copilot hen til et websted fyldt med forældet, duplikeret eller forkert mærket materiale, vil det, som man kunne forvente, resultere i en assistent, der mangler pålidelige oplysninger. Det er en assistent, der gentager dit dårligste indhold med fornyet selvtillid, nu med dit eget autoritetsstempel. Funktionen forudsætter, at organisationen allerede ved, hvilke af dens websteder der er troværdige. Det gør de fleste ikke, og den antagelse er den røde tråd, der går igennem alt andet.

Ekstern deling bliver som standard underlagt styring

I årevis har deling af indhold med personer uden for organisationen været baseret på en engangskode, der blev sendt via e-mail. Denne mekanisme udfases nu. Fra juli 2026 begynder udfasningen af SharePoints autentificering med engangskoder, og ekstern deling

overgår fuldstændigt til Microsoft Entra B2B, hvilket forventes gennemført inden udgangen af august. Nye eksterne invitationer er allerede tidligere på året overgået til denne model.

I praksis bliver alle eksterne modtagere nu en administreret Entra B2B-gæst i stedet for indehaver af en midlertidig kode. Dette er en klar forbedring af styringen, da ekstern adgang dermed falder ind under de samme kontrolmekanismer som alt andet: betinget adgang, identitetsbeskyttelse og centraliseret gæstestyring. Det er også en deadline. Eksterne brugere, der har benyttet den gamle metode, kan miste adgangen til tidligere delt indhold, og den administrative indstilling, der tidligere styrede denne adfærd, fjernes.

Implikationen er enkel. Det gæsteområde, som mange organisationer aldrig formelt har revideret, er ved at blive et reguleret område, uanset om de er forberedte på det eller ej. Det er tid, der er godt brugt, at gennemgå, hvem der har ekstern adgang, inden overgangen er afsluttet.

Klassificering bliver en grænse, ikke et forslag

Tilladelser beskriver, hvad en bruger har lov til at åbne. De har aldrig i sig selv beskrevet, hvad et AI-system bør undlade at røre ved. Den skelnen trækkes nu.

Gennem Microsoft Purview kan følsomhedsmærker udelukke indhold fra Copilots grundlag, og håndhævelsen vil være fuldt implementeret inden udgangen af juli. Et dokument, der er klassificeret på et begrænset niveau, kan holdes uden for Copilots rækkevidde, selv for brugere, der har tilladelse til at åbne det direkte. Klassificering er ikke længere blot vejledende metadata, men bliver en håndhævelig grænse, der forhindrer Copilot i at få adgang blot fordi »brugeren havde adgang«, som det var den utilstrækkelige begrundelse før opdateringen.

For regulerede brancher er dette ikke blot en bekvemmelighed; det er forskellen mellem en Copilot-implementering, der kan forsvares, og en, der afslører kontrollerede oplysninger i et genereret svar, fordi tilladelserne tilfældigvis tillod det. Ligesom med autoritative websteder fungerer beskyttelsen kun, hvor mærkningerne allerede findes. En grænse opretholdes kun, hvor nogen har fastlagt den.

Governance bliver en disciplin, man kan se

Det mere underliggende tema bag disse ændringer er, at governance i sig selv behandles som en operationel disciplin snarere end en årlig oprydning. Microsoft samler aktiviteterne i forbindelse med gennemgang af websteder, inaktivitet, ejerskab og attestering i mere overskuelige grænseflader for de ansvarlige, og forbedrer rapporteringen, så administratorer kan identificere overdreven deling og risici ved tilladelser, så man ikke længere behøver at gætte sig frem.

Governance får sine egne arbejdsredskaber, hvilket betyder, at den kan måles, tildeles og håndteres som et løbende arbejde.

Den fælles forudsætning: Styring er adgangsbilletten

Ser man bort fra de enkelte funktioner, er den fælles forudsætning umulig at overse. Hver enkelt funktion læser oplysninger, som forventes allerede at findes på webstedet, og handler

ud fra dem. Autoritative websteder er afhængige af at vide, hvilke websteder der er troværdige. Purviews beskyttelse bygger på, at der er tildelt mærker. Kontrol af ejerskab og attestering forudsætter, at der findes en gyldig ejer, der kan kontaktes. Ingen af disse kontrolmekanismer skaber de underliggende oplysninger; de bruger dem alle sammen.

Hvilket rejser spørgsmålet: hvor kommer disse oplysninger fra?

Den side af livscyklussen, som ingen styrer

Microsoft styrer midten af et websteds levetid og dets afslutning. Registrering af inaktivitet, ejerskabsgennemgange, attestering og arkivering er alle kontroller, der finder sted under normal drift og ved udløb af levetiden. De forudsætter, at et websted allerede eksisterer, allerede har en ejer, allerede har en klassificering og en fornuftig tilladelsesmodel. De bygger på metadata, som nogen på et tidligere tidspunkt forventedes at have indført.

Der er næsten ingen styring af begyndelsen, og det er netop i begyndelsen, at resultatet afgøres. Et websted, der oprettes uden en klar ejer, efterlader attesteringspolitikken uden nogen at underrette. Et websted, der oprettes uden en følsomhedsmærkning, giver Purview-grænsen intet at håndhæve. Et websted, der oprettes med brede, arvede tilladelser, bliver præcis det, som rapporten om overdreven deling senere vil omtale. Den kostbare afhjælpning, der udgør hovedparten af de fleste styringsprogrammer, er næsten udelukkende den akkumulerede pris for websteder, der aldrig blev oprettet korrekt fra starten.Det er netop dette hul, som Strators eksperter er trænet til at lukke.

Microsofts værktøjer er kun så pålidelige som de oplysninger, der allerede er registreret på webstedet. Arbejdet med at sikre, at disse oplysninger findes fra første øjeblik, og at reparere dem, hvor de mangler, er en separat disciplin i forhold til de kontroller, der senere afhænger af dem.

To halvdele af den samme livscyklus

Strators tilgang og Microsofts indbyggede livscyklusstyring er ikke alternativer til hinanden. De regulerer forskellige halvdele af den samme livscyklus, og den del, der omhandler klargøring, er en forudsætning for, at den del, der omhandler stabil drift, kan fungere.

Forholdet er direkte på alle punkter. »Authoritative Sites« bliver troværdigt, når webstederne allerede er klassificeret efter niveau, fordi denne klassificering udgør den naturlige udvælgelse af kilder, der har opnået Copilot-prioritet. Purviews klassificeringsgrænse bliver legitim, når mærkater tildeles ved oprettelsen i stedet for at blive eftermonteret under pres.

Ejerskabs- og attestationsgennemgange bliver meningsfulde, når der fra starten findes gyldige ejere, så der ikke er nogen forsømte websteder, der kan forsinke gennemgangen. Og rapporter om overdreven deling har mindre at finde, når webstederne som standard tildeles adgang med mindst mulig privilegier. I alle fald arver den indbyggede kontrol et fundament, som den ikke selv har skullet opbygge.

Hvor en Copilot-implementering egentlig begynder

Erfaringerne fra sommerens ændringer viser, at en Copilot-implementering ikke starter med en licens. Den starter i det underliggende indholdsmiljø, i den ikke særlig glamourøse disciplin omkring ejerskab, livscyklus og klassificering, som hver eneste af disse nye funktioner i al stilhed er afhængig af. De organisationer, der vil indføre Copilot med tillid, er dem, der først har udført dette arbejde og betragtet det som et fundament snarere end en oprydning.

Microsoft styrer midten og slutningen af et websteds levetid. Strator styrer begyndelsen. Og det er begyndelsen, der afgør, om man kan stole på alt det, der følger efter.

The post Først styring, så aktiverer man AI’en appeared first on Strator.

Denne skelnen er vigtigere nu end nogensinde før, fordi de strategiske indsatser er reelle, og markedsføringen omkring dem er højlydt. To nylige og omfattende undersøgelser hjælper med at skære igennem støjen: Digitaliseringsstyrelsens rapport fra december 2025 om open source i den offentlige sektor og en international undersøgelse af seksten digitalt modne lande, som Digitaliseringsstyrelsen bestilte året før. Læst i sammenhæng peger de på den samme ubehagelige men nyttige konklusion. Digital suverænitet er en formåen, og formåen skal opbygges. 

Suverænitet er ikke et produkt du kan købe 

Det er fristende at tro, at en bestemt type platform afgør spørgsmålet. Det gør den ikke. Man kan være reelt uafhængig på en proprietær platform, hvis man har en god styring, og fuldstændig fanget i open source, hvis man ikke har det. Mærket på emballagen betyder meget lidt. Organisationen bag den afgør næsten alt. 

De store udbydere er selv et godt eksempel på dette. I løbet af det seneste år har Microsoft færdiggjort sin EU Data Boundary og indført suverænitetsløsninger såsom krypteringsnøgler, der opbevares hos kunden, adgangskontrol baseret i Europa og lokal implementering af centrale arbejdsbelastninger – alt sammen med direkte fokus på suverænitetshensyn. Det er betydelige investeringer, og de gør det muligt at opnå digital suverænitet på en hyperscale-kommerciel cloud på en måde, der ikke var mulig for blot få år siden. Samtidig er der stadig uafklarede spørgsmål, såsom udenlandsk lovgivnings rækkevidde over data, der fysisk er lagret i Europa, hvilket ingen indkøbsbeslutning i sig selv fuldt ud kan fjerne. Læren er ikke, at én udbyder er sikker, og en anden ikke er det. Læren er, at uanset hvad man vælger, overgår ansvaret for at forstå, hvad man besidder, hvor det befinder sig, og hvordan man ville afhænde det, hvis det blev nødvendigt, ikke til leverandøren. Det forbliver hos dig. 

Så det egentlige spørgsmål er aldrig »hvilken platform giver os digital suverænitet«. Det er »forstår vi vores konfiguration, ejer vi vores data, kender vi vores kontrakter, og har vi en økonomisk bæredygtig måde at skifte kurs på«. Det er organisatoriske egenskaber, ikke produktegenskaber. 

Kontrol og ansvar er én og samme beslutning 

Digitaliseringsstyrelsens rapport fra 2025 taler klart om den handel, som ingen bryder sig om at nævne. Når du får større kontrol over din teknologi, påtager du dig også et større ansvar: licensbetingelser, sikkerhedsopdateringer, support, maintenance og ganske enkelt at vide, hvad du arbejder med. Kontrol er ikke en præmie, man modtager. Det er en arbejdsbyrde, man påtager sig. Rapporten undgår omhyggeligt at hævde, at mere åbenhed altid er bedre; den siger tværtimod det modsatte. Træf valg ud fra den værdi, de tilfører, og vær ærlig om, hvorvidt du kan gennemføre det, du har valgt. 

Danmark oprettede et særligt open source-kontor til sundhedssektoren. Selvom det var teknisk højt anset, gik det alligevel i opløsning. Ikke på grund af kodens kvalitet, men på grund af manglende organisatorisk og økonomisk opbakning. Teknisk ekspertise er ikke i sig selv nok til at sikre vedvarende operationel opbakning. Det gør finansiering, ejerskab og lederskab derimod. Især lederskab. Det samme mønster viser sig omvendt, hvor suverænitet lykkes. Den opretholdes af en organisation med et lederskab, der har besluttet at afsætte ressourcer til den, ikke af en licens, der tilfældigvis tillod det. 

Derfor kæmper de mindste organisationer mest, og hvorfor svaret sjældent er en heroisk genopbygning internt. Duelighed er krævende netop fordi det er rigtigt arbejde, og at lade som om en platform fjerner det arbejde er hvordan afhængighed stille og roligt hober sig op. 

Forudsætningerne er det sted, hvor suveræniteten egentlig opbygges 

Hvis digital suverænitet er en duelighed, bliver det praktiske spørgsmål, hvad denne duelighed består af. Digitaliseringsstyrelsens rapport, der bygger på erfaringer fra offentlige myndigheder i Danmark og i udlandet, opstiller en klar og fordelsagtigt neutral leverandørliste over forudsætninger. Disse forudsætninger gælder i lige så høj grad for proprietær software som for open source. 

Den første forudsætning er organisation og ledelse. Nogen skal stå bag beslutningen, formulere begrundelsen for den og investere i den kompetence, der skal til for at gennemføre den, uanset om denne kompetence opbygges internt eller købes. Den anden er en bevidst beslutning om support og maintenance. Der er behov for det, uanset om softwaren er open source eller ej. Al software har brug for support og maintenance, og det ville være en fejl at lade den stå uden ejerskab. Den tredje forudsætning er evnen til at vurdere sikkerhed og modenhed, til at bedømme, om der står et aktivt fællesskab eller en kompetent leverandør bag en komponent, i stedet for at antage, at en licens garanterer det. Den fjerde forudsætning er et reelt overblik over licenser, kontrakter og data; at vide, hvilke vilkår der binder dig, hvor dine oplysninger befinder sig, og hvad dine aftaler rent faktisk siger. Det femte punkt er open standards og integration, så systemerne kan kommunikere med hinanden, og – hvad der er afgørende – så man senere kan skifte leverandør uden at skulle afmontere det hele. Det sidste punkt er en honest lifetime economics, hvor man sammenligner en løsnings samlede omkostninger i stedet for den angivne pris, fordi værdien af at kunne skifte aldrig fremgår af en faktura. 

Ingen af disse forudsætninger er tekniske kneb. De er alle discipliner. Tilsammen udgør de det, som digital suverænitet reelt består af, og det opmuntrende er, at de kan udvikles bevidst. 

Organisationer behøver ikke at stå alene  

Organisationer behøver ikke at erhverve evnen til at udøve digital suverænitet på selvstændig vis, og de mest udviklede lande har indset dette. Det gennemgående mønster i den internationale undersøgelse er fremkomsten af fælles forvaltning: neutrale organisationer, der har denne formåen på vegne af mange. I Danmark giver OS2-fællesskabet kommunerne mulighed for at samle midler og kompetencer med fælles løsninger, ud fra princippet om, at de, der er afhængige af noget, bidrager til at opretholde det og bevarer muligheden for at skifte leverandør. Estland og Finland gik så langt som til at oprette en fælles institution med personale og et budget, udelukkende med det formål at forvalte den software, de deler. Italien har oprettet et statsligt kontor til at vejlede og støtte indførelsen af open source, Tyskland har etableret både et offentligt organ til at udvikle fælles løsninger og et agentur til at finansiere vedligeholdelsen af kritisk open source, og Den Europæiske Union er i færd med at sammensætte fælles byggesten, som flere lande kan trække på. 

Det afgørende er ikke, hvilken model der vinder, men, at hver enkelt af dem betragter duelighed som noget, der skal finansieres, bemandes og deles, snarere end noget, der tages for givet. Digital suverænitet i stor skala er lige så meget en kollektiv disciplin som en individuel. 

Digital suverænitet er en ledelsesmæssig holdning 

Alt dette fører tilbage til ét enkelt punkt, og det er et punkt, som CTO’en og CIO’en skal tage ansvaret for. Ledelsen, nærmere bestemt CIO’en og/eller CTO’en, er dem, der skal træffe beslutninger om digital suverænitet. Det er vigtigt, at de gør dette allerede under selve indkøbsprocessen. Datalokalisering, mulighed for at skifte leverandør, open standards og klarhed omkring kontrakter bør ikke være eftertanker, der først kommer frem, når en platform allerede er valgt. De hører som standard til kravene, der gælder for alle leverandører, uanset hvem de er. Behandlet på den måde bliver digital suverænitet beslutningen om at tage ansvar for sin egen infrastruktur, at vide, hvad man kører og hvorfor, samt bevidst at holde sine muligheder åbne. 

De mest holdbare eksempler er governed, ikke improviseret. Aarhus blev for eksempel ikke mere digitalt uafhængigt ved blot at skifte til et andet produkt. Byen fastlagde en retning over mange år – fra et krav om at overveje alternativer, over en handlingsplan og en digital strategi, til afsatte budgetmidler med henblik på at udvide udvalget af leverandører. Den røde tråd er ikke en teknologi. Det er vedvarende, værdidrevet governance og en afvisning af at lade andre bestemme tempoet som udgangspunkt. Det langvarige princip bag det er værd at huske: Vælg den bedste og mest økonomiske løsning uanset softwaretype. Disse løsninger skal vælges af en organisation, der forstår, hvad den vælger. 

Det er netop denne formåen, vi opbygger hos Strator. Platformen er jeres uanset om den er kommerciel eller open source, i skyen eller on-premises. Det egentlige spørgsmål er, om I kan styre den, og om I kan forlade den, hvis I nogensinde bliver nødt til det. Digital suverænitet er ikke blot en sætning i kontrakten; det er bevidstheden om, at organisationen kender sin situation og har evnen til at migrere, hvis den vælger det.  

The post Digital suverænitet er ikke en licens. Det er en formåen. appeared first on Strator.