En informationssikkerhedspolitik fastlægger, hvilke oplysninger og systemer organisationen beskytter, hvem der træffer beslutninger, og hvilke regler medarbejdere og leverandører skal følge. Den skal kunne bruges, når en leder bestiller et nyt system, en administrator tildeler adgang, eller et kritisk system går ned. Dokumentet bliver først nyttigt, når reglerne hænger sammen med konkrete procedurer og faktisk drift.
Denne guide viser, hvordan en dansk virksomhed kan udarbejde politikken i syv trin. Det gennemgående eksempel er en fiktiv servicevirksomhed med 85 medarbejdere, et kundesystem, et lønsystem og teknikere på farten. Eksemplets frister og ansvarsfordeling er interne valg, som illustrerer metoden.
Hvilken pligt skal politikken understøtte?
GDPR kræver passende tekniske og organisatoriske foranstaltninger, og artikel 24 omfatter passende databeskyttelsespolitikker, når det står i rimeligt forhold til behandlingsaktiviteterne. Artikel 32 handler om sikkerhed tilpasset risikoen. Politikkens opbygning skal passe til virksomhedens behandlinger og risici. Databeskyttelsesforordningen.
Datatilsynets vejledning om risikovurdering beskriver den risikobaserede tilgang og skelner mellem sikkerhedsrisici, konsekvensanalyse og vurdering efter et brud. En politik skal derfor bygge på virksomhedens behandlinger og de mulige konsekvenser for mennesker. Risiko for omsætningen er relevant for virksomheden, men erstatter ikke vurderingen af skade på kunder og ansatte.
Særlige pligter kan følge af virksomhedens område. Brug den eksisterende gennemgang af NIS2 i Danmark eller DORA for finansielle virksomheder, hvis de regelsæt er relevante. Registrer den konkrete hjemmel og dens anvendelsesområde i kravoversigten, frem for at stemple hele politikken med alle tre regelsæt.
1. Afgræns systemer, oplysninger og arbejdssteder
Begynd med de aktiviteter, politikken skal dække. I servicevirksomheden omfatter den kundebesøg, tilbud, fakturering, personaleadministration og den interne it-drift. Den omfatter også de telefoner, teknikere bruger hos kunderne, og leverandørens fjernadgang til kundesystemet. Et dokument, der kun nævner kontorets computere, ville efterlade to centrale adgangsveje uden for den praktiske styring.
Skriv afgrænsningen konkret: Alle medarbejdere og eksterne brugere, som behandler virksomhedens oplysninger, følger reglerne for de systemer og tjenester, de får adgang til. Systemejeren afklarer leverandørens pligter i kontrakten. Politikken giver ikke automatisk virksomheden kontrol over leverandørens interne organisation.
Forbind omfanget med kortlægningen af it-systemer. Fortegnelsen viser, hvorfor personoplysninger behandles; systemkortet viser, hvor behandlingen foregår. Begge skal kunne pege på samme kundesystem, selv om de beskriver det fra forskellige vinkler.
2. Vælg de risici, reglerne skal håndtere
Lav en kort liste over hændelser, der kan få væsentlig betydning. I eksemplet er det en stjålet teknikertelefon, en tidligere medarbejders fortsatte adgang, et forkert kundebilag og utilgængelige serviceaftaler. For hver hændelse beskrives både årsag og konsekvens. Et lækket adgangskortnummer kan eksempelvis gøre det muligt at komme ind hos kunden; skaden er mere konkret end formuleringen tab af fortrolighed.
Vurder derefter eksisterende beskyttelse. Telefonen kan være administreret og låst, mens kundebilag stadig kan eksporteres til privat mail. De to forhold bør ikke få samme status, blot fordi begge står under overskriften mobil sikkerhed. Hvis en kontrol kun er planlagt, markeres den som en åben opgave.
En konsekvensanalyse efter artikel 35 har sit eget formål og sin egen tærskel. Politikarbejdet kan identificere, at en bestemt behandling kræver den analyse. En generel sikkerhedspolitik kan ikke erstatte vurderingen af netop den behandling.
3. Fordel beslutninger og praktiske opgaver
En systemejer skal kunne forklare behovet for adgang, mens it-funktionen gennemfører det godkendte valg. Direktionen afgør større ressourceprioriteringer. Den sikkerhedsansvarlige samler risikovurderinger og følger op på undtagelser. DPO’en rådgiver og fører de relevante tilsynsopgaver uden dermed at overtage den dataansvarliges ansvar.
Afklar også, om den udpegede DPO har de nødvendige kompetencer til organisationens behandlinger. Valg af DPO-uddannelse kan knyttes til konkrete rådgivningsopgaver, frem for at et kursusbevis alene bruges som dokumentation for kompetence.
| Opgave i eksemplet | Beslutning | Udførelse og dokumentation |
|---|---|---|
| Ny adgang til kundesager | Servicelederen godkender kundekreds og rolle | It opretter personlig konto og gemmer godkendelsen |
| Fratrædelse | HR meddeler sluttidspunkt og nærmeste leder | It lukker konti; systemejer kontrollerer lokale adgange |
| Undtagelse for ældre program | Driftsdirektøren godkender den konkrete rest-risiko | It begrænser adgang og registrerer udløbsdato |
| Mistanke om læk | Hændelsesansvarlig starter undersøgelsen | It sikrer spor; juridisk funktion vurderer anmeldelse |
Udpeg også en stedfortræder for de opgaver, der ikke kan vente på ferie eller sygdom. Det er en del af organiseringen, ikke et argument for at give alle permanent administratoradgang.
4. Skriv regler, der kan omsættes til handling
En regel bør have et objekt, en ansvarlig og en henvisning til fremgangsmåden. Alle systemer skal være sikre fortæller ingen, hvad der skal ske. En brugbar regel kan i stedet sige, at fjernadgang til kundesystemet skal gå gennem den godkendte identitetsløsning, og at lokale undtagelseskonti registreres særskilt.
Knyt adgangsreglen til adgangskodepolitikken og MFA. Angiv, hvem der kan godkende rettigheder, hvordan en mistet faktor håndteres, og hvordan rettigheder fjernes. Detaljerede tekniske parametre hører til i den vedligeholdte procedure, så en ændring af et program ikke kræver en ny overordnet politik.
For sporbarhed henvises til sikkerhedslogning. Politikken kan kræve sporbarhed for relevante adgange og ændringer, men logbilaget skal angive hændelser, beskyttelse, ansvar og opbevaring. En formulering om at registrere alt er hverken præcis eller nødvendigvis proportional.
5. Forbind politikken med hændelser og kontinuitet
En medarbejder skal vide, hvor en mistanke meldes, også når den normale mail ikke virker. Politikken fastlægger kontakten og mandatet til at begrænse hændelsen. Den detaljerede procedure og brudlog holder styr på observationer, beslutninger og vurdering af anmeldelsespligten.
Servicevirksomheden beslutter i eksemplet, at teknikere ved utilgængeligt kundesystem alene registrerer tidspunkt, kundenummer og en kort status i den godkendte nødformular. De må ikke begynde at fotografere kundedokumenter med private telefoner. Nødarbejdsgangen skal også kunne afsluttes: oplysninger overføres kontrolleret og fjernes fra det midlertidige sted.
Den forretningsmæssige beredskabsplan afgør, hvilke opgaver der fortsætter, og hvilke der må sættes på pause. Politikken fastlægger ansvaret for den prioritering, mens planen beskriver det konkrete scenarie.
6. Et udfyldt politikudsnit til servicevirksomheden
Følgende tekst illustrerer et sammenhængende beslutningsniveau. Den er fiktiv og skal vurderes imod den virkelige organisations systemer og krav:
Servicelederen er ejer af kundesystemets adgangsroller. Teknikere får adgang til de kunder, der indgår i deres opgaver. Masseeksport kræver særskilt godkendelse fra servicelederen med angivet formål og modtager. It-funktionen gennemfører rettighedsændringer og fører spor over administrationen. HR meddeler fratrædelser til it og systemejer. It lukker brugerens adgang på det aftalte fratrædelsestidspunkt, hvorefter systemejeren kontrollerer eventuelle særkonti hos leverandøren. Mistanke om fortsat adgang behandles gennem hændelsesproceduren.
Udsnittet kan afprøves på en konkret person: Hvem godkendte rollen, hvilke kundedata kan kontoen åbne, og findes der leverandørkonti ved siden af? Hvis svaret kun findes i en administrators hukommelse, mangler der et led i processen.
En anden passage kan regulere undtagelser. I eksemplet får et ældre planlægningsprogram en tidsbegrænset undtagelse, fordi det endnu ikke understøtter central login. Undtagelsen gælder kun to navngivne driftsroller, kræver begrænset netværksadgang og udløber ved næste planlagte versionsskift. Den beslutningsansvarlige får en konkret dato for genvurdering. Dokumentet kalder ikke den manglende funktion gennemført.
7. Godkend, indfør og kontroller anvendelsen
Ved godkendelsen skal ledelsen se både politikken og de væsentlige åbne punkter. En underskrift uden indsigt i manglende kontroller giver et misvisende billede af driften. I eksemplet godkendes adgangsreglerne, men den lokale konto i planlægningsprogrammet står fortsat som en tidsbegrænset undtagelse med ansvar og opfølgning.
Medarbejdere behøver ikke læse samtlige tekniske bilag. Teknikerne får instruktion i telefon, kundebilag og hændelsesmelding. Lederne får adgangsgodkendelse og fratrædelse. Administratorerne får de tekniske procedurer. Gem information om den udleverede version og den relevante oplæring, og sørg for at nye medarbejdere får samme aktuelle materiale.
Kontrollen bør følge enkelte virkelige arbejdsgange. Vælg eksempelvis en nyansættelse og en fratrædelse, og sammenhold godkendelse med aktive konti. Gennemgå et tilfælde af leverandøradgang. Resultaterne kan vise, om reglerne virker på tværs af HR, ledelse og it. Dokumenter afvigelsen og den efterfølgende rettelse, frem for blot at tælle udførte gennemgange.
Revider politikken ved relevante ændringer: et nyt kundesystem, en overtagelse, en ny leverandør eller en hændelse, der viser en forkert antagelse. En intern årlig gennemgang kan være et nyttigt holdepunkt, men fritager ikke for at reagere tidligere. Hold versionshistorikken kort: hvad ændrede sig, hvorfor, hvem godkendte det, og hvilke procedurer blev berørt?
Hvad skal være klar ved aflevering?
Den ansvarlige bør kunne fremvise en dateret politik, dens systemafgrænsning, de tilknyttede procedurer og de åbne undtagelser. Desuden skal mindst én gennemført arbejdsgang vise, at de beskrevne roller faktisk fungerer sammen. Det er den kombination, der gør dokumentet anvendeligt i indkøb, daglig drift og en undersøgelse efter en hændelse.
Kildernes anvendelsesområde og henvisninger er kontrolleret 8. september 2026. Eksemplerne illustrerer valg i en tænkt virksomhed og udgør ikke dokumentation for en bestemt virksomheds efterlevelse.