Dansk hosting til intranet: Hvad skal organisationer være opmærksomme på?

En kommunal IT-chef sidder med tre intranetleverandører foran sig. Alle tilbyder cloud. Flere skriver dansk eller europæisk hosting. Men hvor ligger organisationens data egentlig? Hvem har adgang til dem? Hvordan gendannes platformen efter en hændelse – og hvad sker der, hvis organisationen senere vil skifte leverandør?

For kommuner, forsyninger, sundhedsorganisationer og andre organisationer med høje krav til drift og datasikkerhed er hosting derfor ikke bare et teknisk valg. Når intranettet samler intern kommunikation, procedurer, dokumenter og adgang til arbejdsredskaber, bliver hosting en del af organisationens governance, datasuverænitet og beredskab.

Når datacenteret flytter med dig hjem

En IT-chef i en mellemstor kommune får ofte det samme spørgsmål fra både økonomi og ledelse. Kan løsningen placeres i Danmark, og kan den samtidig holde til en reel driftskrise? Det er et rimeligt spørgsmål, men det er også et spørgsmål, der afslører, om organisationen tænker i placering eller i beredskab.

Et dansk datacenter er ikke automatisk et sikkert datacenter. Hvis leverandøren ikke kan vise klar segmentering, dokumenteret backup og en plan for adgang efter en hændelse, er det lokale postnummer mest et salgsargument. Kommuner, regioner og forsyninger har ikke råd til at købe en flot lokation og en svag driftsmodel.

Praktisk regel: Spørg altid, hvem der stadig kan komme ind i data, hvis leverandøren får et driftsnedbrud, en sikkerhedshændelse eller et revisionskrav. Hvis svaret er uklart, er løsningen ikke klar til offentlig drift.

Det er også her, mange organisationer forveksler hosting i Danmark med sikker hosting i Danmark. Den første siger kun noget om geografi. Den anden må kunne dokumentere adgangsstyring, gendannelse, auditspor og ansvar i praksis.

For en kommune handler det om sagsbehandling, intranet, driftsinformation og adgang til interne arbejdsgange. For et hospital handler det om pålidelig adgang til kommunikation og udveksling af information uden unødigt stop. For en forsyning eller anden kritisk aktør handler det om, at data og drift ikke bliver afhængige af en enkelt leverandørs gode vilje.

Hvad cloud hosting egentlig betyder

Cloud hosting bliver ofte blandet sammen med almindelig hosting, men det er ikke det samme. Klassisk hosting er som en lejlighed, hvor man bor i en fast ramme og flytter rundt med begrænsede muligheder. Managed cloud minder mere om et lejet kontor, hvor driften er fælles, men opsætningen er mere fleksibel. Privat cloud er som et helt kontorhus, man selv indretter og styrer.

Tre begreber, som beslutningstagere bør kende

Cloud hosting betyder i praksis adgang til it-ressourcer over netværk, hvor kapacitet kan skaleres efter behov, og hvor brugeren selv eller via en leverandør kan ændre på ressourcerne uden at starte forfra. Det er en anden logik end et ældre webhotel, hvor der ofte er meget fastlåste rammer. Colocation er heller ikke det samme, fordi man i colocation typisk ejer hardwaren og blot placerer den hos en driftspartner.

I leverandørmateriale dukker tre modeller ofte op:

• Infrastructure as a Service, hvor organisationen får servere, lagring og netværk som en platform.

• Platform as a Service, hvor leverandøren også tager mere af den underliggende platformdrift.

• Software as a Service, hvor selve applikationen leveres som en tjeneste, og kunden primært bruger den.

Det afgørende er ikke navnet. Det afgørende er, hvem der bærer drift, sikkerhed, backup og genopretning, når noget går galt.

Hvad managed cloud tilfører i praksis

Managed cloud giver mest værdi, når organisationen ikke selv har et fuldt driftsteam. Så flytter ansvaret ikke bare til “skyen”, men til en leverandør, der skal overvåge drift, håndtere patching, tage backup og stille support til rådighed. Det er især relevant for offentlige og halvoffentlige organisationer, hvor it-afdelingen skal levere stabilitet uden at være bemandet som et stort hostinghus.

Det er også derfor, en tilbudsliste skal læses med stor skepsis. Et produkt kan godt være teknisk “cloud”, men stadig være så låst, at organisationen ikke får den fleksibilitet, den tror, den betaler for. Den type fejl ses ofte først, når et integrationsprojekt, en søgning eller et sikkerhedstjek bliver sat i gang.

Hvorfor Danmark skiller sig ud som cloud-marked

Danmark er ikke et spædt marked, der først lige er ved at opdage cloud. OECD og Eurostat viser, at 70 % af danske virksomheder købte mindst én type cloud computing-service over internettet i 2023, mens EU-gennemsnittet var 45 %. OECD fremhæver samtidig en DCCA-undersøgelse, der viste 72 % i 2024. Det placerer Danmark markant over niveauet i EU og peger på et modent marked med høj digital grundaccept. Kildegrundlaget er OECD og Eurostat-dokumentet om cloudbrug i Danmark og EU20/en/pdf).

Modenhed ændrer kravene

Når cloud er udbredt, kan leverandører ikke nøjes med at sælge løfter. De skal kunne dokumentere drift, sikkerhed og adgangsmodeller, der holder i praksis. Det gælder især for kommuner, hospitaler og forsyningsselskaber, hvor det er selve kontinuiteten, der købes, ikke bare compute-kapacitet.

IBISWorld beskriver også, at den danske Data Processing & Hosting & Website Operating-branche havde en markedsstørrelse på €3,4 mia. i 2026, med 1.067 virksomheder, en årlig omsætningsvækst på 9,7 % og en langsigtet virksomhedsvækst på 0,1 % CAGR. Det peger på en konsolideret sektor, hvor skala og driftserfaring betyder mere end at være ny og billig. Samme kilde angiver desuden et dansk cloud-service-marked på USD 2,82 mia. i 2024 og en forventning om USD 6,33 mia. i 2032, svarende til 12,25 % CAGR. Se IBISWorlds markedsbeskrivelse af dansk data processing og hosting.

Når markedet er så modent, bliver spørgsmålet ikke, om cloud kan bruges. Spørgsmålet bliver, hvilke krav der skal være indbygget fra starten, så løsningen også kan bestå en revision og en hændelse.

Det er også grunden til, at danske udbydere typisk tilbyder tydeligt afgrænsede profiler med CPU, RAM og NVMe som salgsparametre. Det signalerer et marked, hvor kapacitet og driftsdesign er blevet standardiseret, men også hvor forskellen mellem almindelig webhosting og egentlig cloud-platform er tydelig. For indkøbere betyder det, at pris sjældent er den rigtige første sammenligningsfaktor.

Public, private og hybrid hosting i praksis

Valget står sjældent mellem “god” og “dårlig” hosting. Det står mellem tre driftsprofiler, som løser forskellige problemer. For danske organisationer er det vigtigt at skelne skarpt, fordi datasuverænitet, drift og integrationer ofte trækker i hver sin retning.

Når public cloud er nok

Public cloud passer typisk til arbejdsbelastninger med lavere følsomhed og høj standardisering. Det kan være standard intranet, filadgang eller mail, hvor skalering og hurtig udrulning vejer tungt. For organisationer med mange brugere og relativt ens behov er det en effektiv model, så længe sikkerhed og adgangsbegrænsning er tydeligt sat op.

Når private cloud giver mening

Private cloud er relevant, når datasuverænitet, segmentering og kontrol over driften er vigtigere end hurtig standardisering. Det gælder ofte hospitaler, kommuner og forsyningsselskaber, hvor der er krav om forudsigelig adgang, logning og klar ansvarsfordeling. Her er en dedikeret instans i Danmark eller hos en dansk udbyder ofte mere passende end en bred delt platform.

Hybrid som den praktiske mellemvej

Hybrid managed cloud er den model, mange ender med, fordi den giver mulighed for at placere følsomme data lokalt og samtidig lade mindre kritiske tjenester køre mere skalerbart andetsteds. Det er også den model, der passer bedst til organisationer, som ikke vil vælge mellem total centralisering og total frihed. Her handler arkitekturen om at styre grænserne, ikke om at samle alt ét sted.

De tekniske profiler, der ses i danske tilbud, viser også springet mellem almindelig hosting og egentlig cloud. Når der arbejdes med VPS-profiler, NVMe og flere worker-processer, er det et tegn på, at platformen er bygget til mere end bare statiske websider. Det er vigtigt for platforme med søgning, feed-opdateringer og integrationer til Microsoft 365 eller Google Workspace.

GDPR, ISO 27001 og ISAE hvad forskellen reelt er

Mange leverandører skriver “GDPR-compliant” i deres materiale, men det er ikke en præmie, man kan købe sig til. GDPR er et lovkrav, der forpligter både dataansvarlige og databehandlere. ISO 27001 og ISAE 3000 er derimod dokumentationstyper, der siger noget om, hvordan sikkerhed og kontroller er styret og revideret.

Tre forskellige discipliner

GDPR handler om behandling af personoplysninger og om, hvem der bærer ansvaret. En dansk organisation kan ikke outsource sit ansvar og tro, at en hostingaftale løser alt. En ordentlig databehandleraftale er derfor ikke en formalitet, men en central del af styringen.

ISO 27001 er et ledelsessystem for informationssikkerhed. Certificeringen viser, at leverandøren arbejder systematisk med risici, kontroller og forbedringer. Det er ikke en garanti for, at intet kan gå galt, men det er et stærkt tegn på modenhed i driften.

ISAE 3000 eller ISAE 3402 er en uafhængig revisionserklæring over kontroller. Det er den type dokumentation, der hjælper en kommune, et hospital eller en forsyning med at vurdere, om leverandørens påstande også holder i den reelle drift. Det er her, man ser, hvad der er testet, i hvilken periode, og med hvilke resultater.

Dokumenter, der bør ligge på bordet

• Databehandleraftale: Den skal beskrive rollefordeling, underdatabehandlere og sikkerhedsforanstaltninger.

• ISO 27001-certifikat: Der bør fremgå udstedende organ og gyldighed.

• ISAE-erklæring: Den skal vise dækningsperiode og præcis hvilke kontroller, der er vurderet.

• Exit- og slettevilkår: Organisationen skal kunne komme ud med data på en kontrolleret måde.

Hvis en leverandør ikke kan fremlægge dette uden tøven, er leverandøren ikke klar til kritiske arbejdsgange. For en nærmere teknisk og organisatorisk rammesætning kan denne ISO-certifikat-side hos Colibo bruges som eksempel på, hvordan certificering og dokumentation typisk præsenteres i praksis.

Latency, redundans og SLA i danske miljøer

Tekniske ord som latency og SLA bliver ofte brugt som pynt. Det er en fejl. For danske organisationer er de ord beslutningskriterier, fordi de afgør, om en platform er egnet til daglig drift, eller om den kun ser god ud på et slidesæt.

Det, der mærkes af brugerne

Når en løsning har lav netværkslatens, føles søgning, indholdsopdatering og login mere stabilt for medarbejderne. DK Cloud Solutions angiver lav-latens-netværk med under 2 ms til København og under 5 ms til nordiske hovedstæder, sammen med Tier III+-design, 99,982 % availability, N+1-redundans, dual-stack IPv6 og DDoS-beskyttelse op til 10 Gbps. Se deres serviceside om drifts- og netværksdesign. For en offentlig organisation er det relevant, fordi lokal dataplacering ikke er nok, hvis netværket er ustabilt eller arkitekturen ikke kan tåle fejl.

Driftsregel: SLA uden redundans er bare tekst. Hvis arkitekturen ikke er bygget til at overleve et node- eller zonesvigt, er oppetidsløftet ikke værd at planlægge efter.

Single-AZ og multi-AZ er ikke bare tekniske ord

I danske miljøer er forskellen mellem single-AZ og multi-AZ afgørende, når et system bruges til intern kommunikation, driftsinformation eller kritiske arbejdsprocesser. Multizone-design er mere pålideligt, fordi en enkelt fejl ikke nødvendigvis vælter hele løsningen. Det er den rigtige model, når organisationen ikke kan acceptere længere driftsstop.

RPO og RTO skal tænkes ind samtidig. Hvis backup kun tages sjældent, bliver datatabet større. Hvis failover ikke er testet, bliver genopretningen langsom. Det er derfor, beredskabsøvelser skal være lige så konkrete som en driftsaftale.

For en praktisk ramme om kontinuitet og gendannelse kan denne Business Continuity-side hos Colibo bruges som et eksempel på, hvordan organisationer kan tænke driftssikkerhed og gendannelse i sammenhæng.

Migration og driftsovervejelser før du skifter

De fleste problemer opstår ikke, når kontrakten underskrives. De opstår, når data skal flyttes, integrationer skal virke, og brugerne forventer, at alt ser ud som før. Det er her, mange projekter mister momentum, fordi migrationsplanen er for optimistisk.

De typiske faldgruber

Først kommer dataeksporten. Metadata, tilknytninger og historik skal med, ellers mister organisationen søgbarhed og sammenhæng. Derefter kommer integrationerne, især til miljøer som Microsoft 365 eller Google Workspace, hvor adgang, kalender, notifikationer og brugerkonti skal spille sammen med resten af porteføljen.

Derefter skal søgning, notifikationer og eventuelle AI-funktioner testes før go-live. Hvis en platform ikke kan finde det rigtige indhold hurtigt, eller hvis varslinger drukner i støj, bliver brugerne frustrerede fra første dag. En rollback-plan er derfor ikke et ekstra dokument, men en del af selve migreringen.

Når leverandøren rammes af en hændelse

CloudNordic-sagen viste, hvor hurtigt backup, segmentering og adgang kan blive forretningskritiske spørgsmål, når en leverandør rammes af ransomware. En organisation, der ikke har tænkt incident response og datatilgængelighed ind fra begyndelsen, står svagt, når noget går galt. Det samme gælder ved strømsvigt eller brud på compliance.

Hvis løsningens dataadgang ikke kan bevares under en krise, er løsningen ikke pålidelig nok til offentlig eller kritisk drift. Det er derfor, backup-segmentering, test af gendannelse og en klar supportvej er nødvendige krav, ikke bonusser.

For en bredere organisatorisk ramme kan denne databeskyttelsesside hos Colibo bruges som reference for, hvordan datastyring og adgang tænkes ind i løsningen.

Din tjekliste før du vælger cloud hosting i Danmark

En leverandørscreening skal være hård, ikke høflig. Hvis organisationen arbejder med borgere, patienter eller kritisk drift, skal spørgsmålene være præcise fra første møde. Det er ikke prisen alene, der afgør det rigtige valg.

Tjek disse punkter før kontrakt

• Dataplacering: Er data lagret i DK eller EU, og kan det dokumenteres?

• Compliance: Findes der en reel databehandleraftale, og er kravene tilpasset jeres sektor?

• Certificering og revision: Er ISO 27001 og en relevant ISAE-erklæring aktuelle og dækkende?

• Oppetid og gendannelse: Hvilke SLA-, RPO- og RTO-niveauer er der, og er de testet?

• Driftssikkerhed: Er der N+1, multi-AZ, DDoS-beskyttelse og en klar exit-plan?

• Support: Er der dansk support, også når hændelsen rammer uden for normal arbejdstid?

Det afgørende spørgsmål er enkelt. Hvad sker der på dag 1, hvis leverandøren får en alvorlig hændelse, og hvem ejer adgangen til jeres data bagefter? Hvis svaret kræver lange forklaringer, er leverandøren ikke klar til jeres organisation.

Colibo leverer en intranetplatform med dansk/EU-hosting, integreret AI-søgning og mulighed for drift i både cloud og on-premise, så organisationer kan styre dataadgang og intern kommunikation uden at låse sig fast i én model. For kommuner, hospitaler og kritisk infrastruktur er det relevant at se platforme som Colibo som en del af den samlede beredskabs- og governance-løsning. Besøg Colibo og vurder, om jeres krav til pålidelighed, audit og dataadgang er tænkt ind fra starten.