Data og risikostyring

Dataklassifikation i en app: beskyt det vigtigste først

En app kan indeholde kundedata, priser, dokumenter, driftsopsætning og offentligt indhold, men de kræver ikke nødvendigvis samme beskyttelse. Dataklassifikation gør det synligt, hvad der kan ske, hvis oplysninger bliver læst, ændret eller utilgængelige, så adgang, backup, test og overvågning kan følge den faktiske risiko.

Udgivet 22. oktober 2026 · Ca. 11 minutters læsetid

Det korte svar

Lav en oversigt over appens meningsfulde datatyper og vurder konsekvensen af tab af fortrolighed, integritet og tilgængelighed hver for sig. Knyt derefter en ejer og konkrete regler til hver type: hvem må se og ændre den, hvor må den kopieres hen, hvor hurtigt skal den kunne gendannes, og hvordan opdages en fejl. Kontrollér til sidst, at reglerne faktisk håndhæves i database, API, filer, logs, backup og browser.

Klassifikation er en beslutningshjælp, ikke et mærkatarkiv. Hvis “fortroligt” ikke ændrer adgang, deling, test eller recovery, giver mærket ingen reel beskyttelse.

Se på tre forskellige former for tab

NIST beskriver en model, hvor information vurderes efter mulig konsekvens ved tab af fortrolighed, integritet og tilgængelighed. Modellen er udviklet til amerikanske myndigheder; en dansk virksomhed kan bruge tankegangen som arbejdsmodel uden at gøre NIST's kategorier til et lovkrav.

Fortrolighed: Hvad sker der, hvis en uvedkommende ser data? Tænk på persondata, priser, tilbud, adgangsnøgler og interne noter.
Integritet: Hvad sker der, hvis data er forkerte, ufuldstændige eller ændret uden ret? En offentlig pris kan være frit læsbar og stadig kræve stærk beskyttelse mod ændring.
Tilgængelighed: Hvad sker der, hvis autoriserede brugere ikke kan få data eller funktionen frem? Vurdér både varighed, tidspunkt og muligheden for en manuel nødprocedure.

GDPR artikel 32 bruger også fortrolighed, integritet og tilgængelighed ved sikkerhed omkring personoplysninger. Dataklassifikation erstatter dog hverken en GDPR- risikovurdering eller en DPIA: de vurderer konsekvenser for mennesker, mens den interne klassifikation også kan omfatte drift, økonomi, kontrakter og forretningshemmeligheder.

Klassificér datatyper, ikke hvert databasefelt

En liste med tusind kolonner bliver ikke vedligeholdt. Saml felter, filer og hændelser i datatyper, som medarbejdere og udviklere kan genkende: kundegrunddata, bookinger, fakturagrundlag, supportnoter, vedhæftede dokumenter, revisionslog og systemadgange. Notér samtidig hvor typen findes og bevæger sig hen.

Datatype	Hvis den lækkes	Hvis den ændres	Hvis den mangler
Offentlige åbningstider	Begrænset skade	Kunder møder forgæves	Henvendelser og salg kan stoppe
Kundekontakt og noter	Privatliv og tillid rammes	Forkert kunde kontaktes	Sagen kan ikke behandles
Ordre, pris og status	Aftaler kan afsløres	Forkert beløb eller levering	Driften kan stå stille
API-nøgler og systemadgang	Andre kan handle som appen	Integrationer kan omdirigeres	Appen kan miste forbindelser

Eksemplerne er spørgsmål, ikke færdige niveauer. Den samme datatype kan have en helt anden betydning i en medlemsportal, et bookingsystem eller en sundhedsløsning.

Brug få niveauer med tydelige regler

Tre eller fire niveauer er ofte lettere at bruge end en detaljeret skala. Navnene er mindre vigtige end reglerne. En enkel virksomhedsmodel kan for eksempel være offentlig, intern, fortrolig og særligt beskyttet. Beskriv hvert niveau med konkrete handlinger frem for brede ord.

Adgang: Hvilke roller må læse, ændre, eksportere eller slette data?
Placering: Må data være i udvikling, supportværktøjer, browserlagring, analyseværktøjer eller AI-tjenester?
Deling: Må data sendes som mail, downloades, deles via link eller gives til en leverandør?
Beskyttelse: Kræves kryptering, revisionslog, ekstra godkendelse eller en bestemt backup- og gendannelsestest?
Levetid: Hvornår arkiveres eller slettes data, og gælder reglen også kopier og eksporter?

Brug den højeste relevante beskyttelse, når flere datatyper blandes i samme fil, tabel eller eksport. Det betyder ikke, at hele appen ukritisk skal have samme niveau; det er ofte bedre at adskille særligt følsomme eller kritiske data.

Omsæt vurderingen til appens faktiske drift

Klassifikationen skal kunne spores til tekniske og organisatoriske valg. Datatilsynet fremhæver, at adgangsrettigheder skal begrænses efter arbejdsbetinget behov, og at for brede rettigheder kan ramme både fortrolighed, integritet og tilgængelighed.

Adgang og handlinger

Håndhæv bruger, virksomhed, rolle og tilladte felter på serveren. Skeln mellem læse-, skrive-, eksport- og sletteret.

Test og udvikling

Brug syntetiske data som udgangspunkt. Lad ikke et lavere beskyttet miljø blive en ukontrolleret kopi af produktion.

Logs og overvågning

Log hændelser og stabile id'er frem for hemmeligheder og fulde datasæt. Begræns også adgang og levetid for logdata.

Backup og recovery

Lad behovet for tilgængelighed og integritet styre backupfrekvens, gendannelsesmål, kontrol af kopien og øvelser.

En praktisk workshop på 60 minutter

1. Tegn dataflowet. Skriv database, filer, mail, integrationer, logs, browser, backup og eventuelle AI-kald på tavlen.
2. Vælg 5-10 datatyper. Brug forretningsord, som den ansvarlige medarbejder forstår, frem for tekniske tabelnavne.
3. Beskriv konkrete konsekvenser. Spørg hvem der rammes, hvordan og hvor længe ved læk, forkert ændring og utilgængelighed.
4. Aftal niveau og ejer. Registrér den person, der kan godkende brugen og svare på tvivl. Udvikleren bør ikke stå alene med forretningsvurderingen.
5. Find ét hul pr. kritisk type. Kontrollér en reel rettighed, log, eksport, backup eller testkopi. Opret en afgrænset opgave med ansvarlig og bevis for afslutning.

Typiske fejl

Alt kaldes fortroligt: Medarbejdere kan ikke prioritere, og mærket bliver ignoreret.
Kun persondata vurderes: Priser, kontrakter, driftsopsætning og adgangsnøgler kan være kritiske uden at være personoplysninger.
Kun læk tæller: Forkerte priser, mistede bookinger eller en utilgængelig kø kan skade mere end offentliggørelse.
Databasen er hele kortet: De samme data ligger også i logs, downloads, mail, support, browser, backup og leverandører.
Niveauet vælges uden konsekvens: Høj risiko er ikke en mavefornemmelse; skriv et realistisk scenarie og hvem der rammes.
Dokumentet fryser: Nye integrationer, felter og kundegrupper ændrer dataflowet uden at klassifikationen følger med.

Tjekliste til dataklassifikation

☐ Appens vigtigste datatyper er beskrevet med forretningsord og en navngiven ejer.
☐ Placeringer og kopier i database, filer, logs, browser, backup og leverandører er med.
☐ Konsekvensen ved tab af fortrolighed, integritet og tilgængelighed er vurderet hver for sig.
☐ Niveauerne har konkrete regler for adgang, deling, test, logging, backup og sletning.
☐ Blandede datasæt og eksporter beskyttes efter den mest krævende relevante datatype.
☐ Mindst én faktisk rettighed, kopi, log og gendannelse er kontrolleret mod reglerne.
☐ GDPR-risikovurdering og eventuel DPIA håndteres særskilt, når persondata kræver det.
☐ Ændringer i dataflow, leverandører og formål udløser en ny vurdering.

Officielle kilder

Kilderne beskriver principper og krav. Den konkrete klassifikation og de tekniske kontroller skal passe til appens dataflow, brugere og konsekvenser.

Når klassifikationen skal virke i koden

Simply Solutions kan hjælpe med at kortlægge dataflowet og kontrollere, om adgang, testmiljø, logging, backup og integrationer følger de beslutninger, virksomheden har truffet. Startklar er relevant, når appen virker, men skal være sikker og rolig nok til rigtige medarbejdere eller kunder.

Se Startklar til AI-byggede apps