“Hvor ligger vores data?” lyder som et spørgsmål med ét svar, og mange softwarehuse skriver navnet på et datacenter og går videre. Svaret er næsten altid mere end det. Data ligger i produktionsdatabasen, i backup, i logfiler, hos supportværktøjet, i mailtjenesten, i overvågningen og måske hos en sprogmodel. En kunde med en grundig IT-afdeling kender det og spørger videre. Det brugbare svar er et kort over data, der viser, hvilke oplysninger der ligger hvor, og hvem der kan se dem. Kortet tager få dage at lave første gang og sparer tid ved hvert spørgeskema bagefter.
Fem steder, data gemmer sig
Produktion. Databaser, fillager, søgeindekser og mellemlagre (cache). Skriv region og udbyder for hver. Et søgeindeks eller en cache kan ligge et andet sted end databasen, fordi nogen valgte standardopsætningen en gang.
Backup. Kopier ligger ofte i en anden region, og det er meningen, for de skal overleve, at den første region falder ud. Det gør bare svaret længere. Hvor kopierne ligger, hvor længe de gemmes, og hvem der kan hente dem, skal fremgå. Selve gendannelsen er emnet i kan I faktisk genskabe produktet.
Logning og overvågning. Logfiler indeholder tit brugernavne, mailadresser og dele af forespørgsler. Sender I dem til en ekstern logtjeneste eller et fejlopsamlingsværktøj, ligger de også dér. Det er den post, der oftest overrasker teamet selv.
Support. Skærmbilleder i et supportsystem, udtræk i en delt mappe, en database kopieret til en udviklers maskine for at finde en fejl. Her ligger data, som ingen arkitekturtegning viser.
Underliggende tjenester. Mailudsendelse, betaling, analyse af brugeradfærd, login, oversættelse og AI-funktioner. Hver af dem modtager data, og mange af dem har egne regioner og egne underleverandører. Bruger I en sprogmodel, hører det med, hvor teksten behandles, og om den gemmes, se kundedata i AI-funktionen.
Sådan laver I kortet
Lav en tabel med en række for hvert sted, data befinder sig. Fem kolonner er nok:
- Hvor: tjeneste og udbyder.
- Hvad: hvilke data, fx kundens dokumenter, brugerdata eller tekniske logs.
- Land eller region: hvor de lagres, og hvor de eventuelt behandles.
- Hvor længe: hvor lang tid de bliver liggende.
- Hvem: hvem hos jer og hos udbyderen der kan tilgå dem.
Saml oplysningerne fra tre kilder: opsætningen hos cloududbyderen, listen over betalte tjenester fra bogholderiet og en samtale med udviklerne og supporten. Listen fra bogholderiet er en god kontrol, for en tjeneste, nogen har tilmeldt på et kreditkort, står sjældent i dokumentationen.
Gå derefter de tjenester igennem, hvor I ikke kender svaret, og læs udbyderens egne oplysninger om regioner. Er der noget, I ikke kan få afklaret, skal det frem som et åbent punkt, så I ikke ender med at gætte i et svar til en kunde.
Fjernadgang tæller også
Data kan ligge i Danmark og stadig blive set fra et andet land. Har I udviklere eller en supportpartner uden for EU, eller får en leverandør adgang for at løse en fejl, så er det en del af svaret. Kunden spørger ofte om “lagring og adgang” samlet. Beskriv, hvem der har fast adgang til produktionsdata, hvem der kan få den ved behov, og hvordan adgangen logges.
Et spørgsmål hænger tæt sammen med dette: hvilket lands lov udbyderen selv er underlagt. Fysisk placering og jurisdiktion er to forskellige ting, og svaret afhænger af, hvor udbyderen er hjemmehørende. Den vurdering hører til, når I vælger platform, se cloud og hosting til et SaaS-produkt. Om en konkret overførsel af personoplysninger er i orden, er et spørgsmål til advokat eller jeres rådgiver om databeskyttelse.
Svaret til kunden
Kortet er jeres arbejdsredskab. Kunden skal have et kort svar i tre lag:
- Hovedsvaret. “Produktionsdata og backup ligger hos [udbyder] i [region].” En sætning, som salget kan sige uden at spørge.
- Listen over tjenester. Hvilke andre tjenester der behandler kundens data, og i hvilket land.
- Undtagelserne. Det, der afviger, fx supportadgang fra et andet land eller en tjeneste, der gemmer logs uden for EU.
Skriv undtagelserne med, når de findes. Kunden finder dem som regel selv, og et svar med en undtagelse virker mere pålideligt end et svar uden. Svaret hører hjemme i jeres arkitekturbeskrivelse på tre sider og som fast tekst til kundens spørgeskema. Står der krav om placering i en kontrakt, skal det læses mod kortet før underskrift. Hvordan sådanne krav læses fra ledelsens side, står i sikkerhedskrav i kundekontrakten.
Når kunden kræver noget, I ikke kan i dag
Kræver kunden, at alt bliver i Danmark eller i EU, kan det være en lille ændring eller en stor. Flytning af en logtjeneste er ofte overskuelig. Flytning af en hel platform eller udskiftning af en AI-tjeneste er det sjældent. Vurder, hvad ændringen betyder for alle kunder. Det giver sjældent mening at bygge en særlig løsning til én kunde, medmindre I er klar til at drive den i årevis, se én stor kunde vil bestemme køreplanen.
Hold kortet ajour
Kortet bliver forkert, første gang en udvikler tilføjer en ny tjeneste. Gør det til en fast del af jeres rutine: Ingen ny tjeneste, der modtager kundedata, kommer i produktion, før den står i tabellen. Læg et fast eftersyn ind mindst én gang om året, og giv én person ejerskabet.
Det skal I lade være med
· At svare med navnet på ét datacenter, når data også ligger andre steder.
· At glemme logs, support og udviklernes egne kopier.
· At love dansk placering, før I har gennemgået underleverandørerne.
· At sige “i skyen” til en kunde, der har spurgt om land og region.
Det skal I kræve af den eksterne
- ☐ Et skriftligt kort over data med de fem kolonner.
- ☐ Et standardsvar i tre lag, som salg og support kan bruge.
- ☐ En liste over åbne punkter med en ejer.
- ☐ En enkel regel for nye tjenester, der modtager kundedata.
- ☐ En vurdering af, hvad et krav om placering betyder for alle kunder.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Persondata i produktet · Den store kunde kræver SSO, logning og roller
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
