Informationssikkerhed fejler sjældent, fordi nogen mangler slides. Den fejler, fordi planen ikke er praktisk, fordi milepæle ikke kan måles, fordi ansvar er uklart, og fordi dokumentation enten mangler eller bliver et mål i sig selv. I denne artikel får du en konkret, anvendelig model til at planlægge og gennemføre sikkerhedsarbejde, der kan holde til revision, hændelser og hverdagsdrift.
Du får også værktøjer til at undgå “powerpoint-sikkerhed”: den pæne fortælling om kontrol og modenhed, som ikke matcher virkeligheden i systemer, processer og adfærd. Målet er, at du kan gå fra overblik til handling med tydelige leverancer, realistisk tidsplan og dokumentation, der faktisk hjælper.
Hvad er en praktisk sikkerhedsplan, og hvorfor betyder den noget?
En praktisk sikkerhedsplan er en handlingsorienteret plan, der beskriver hvilke sikkerhedstiltag der skal implementeres, hvornår de skal være på plads, hvem der ejer dem, og hvordan de dokumenteres og kontrolleres i drift. Den betyder noget, fordi den forbinder risici og krav med konkrete ændringer i teknologi og arbejdsgange, så sikkerhed ikke forbliver en ambition.
Typiske spørgsmål er: Hvad skal vi gøre først? Hvorfor netop det? Hvordan ved vi, at det virker? Og hvad koster det? En god plan svarer ved at prioritere efter risiko og forretning, ikke efter hvad der lyder bedst i en præsentation. Den gør det også lettere at koordinere mellem IT, forretning, ledelse og leverandører.
Mini-konklusion: Hvis du ikke kan pege på konkrete leverancer og ejere, har du ikke en plan, men en hensigt.
Start med overblik: risici, krav og minimumsniveau
Overblik handler ikke om at kortlægge alt til mindste detalje. Det handler om at identificere de vigtigste aktiver, trusler og afhængigheder, så du kan sætte et minimumsniveau for sikkerhed, som giver mening. Begynd med at beskrive dine mest kritiske forretningsprocesser og de systemer, der understøtter dem, inklusive cloud-tjenester og eksterne driftsleverandører.
Lav en hurtig, brugbar risikovurdering
En risikovurdering behøver ikke være tung. Den skal være tydelig nok til at kunne forklare, hvorfor en indsats er prioriteret, og hvad konsekvensen er ved at vente. Brug et simpelt skema med sandsynlighed, konsekvens og nuværende kontrolniveau. Det vigtigste er at få fælles sprog og beslutninger, ikke at perfektionere scoring.
Oversæt krav til lokale leverancer
Krav fra standarder, kontrakter eller regulering bliver ofte abstrakte. Oversæt dem til lokale leverancer: “MFA på alle admin-konti”, “gendannelsestest hvert kvartal”, “leverandørkrav i indkøbsskabelon”. Når du kan se leverancen, kan du planlægge den. Når du kan teste den, kan du dokumentere den.
Mini-konklusion: Overblik er godt, men værdien opstår først, når du kan omsætte risiko og krav til konkrete ændringer.
Fra hensigt til plan: milepæle, leverancer og afhængigheder
Milepæle gør planen styrbar. En milepæl er et tydeligt punkt, hvor du kan sige “færdig” eller “ikke færdig” ud fra objektive kriterier. Undgå milepæle som “forbedre awareness” eller “styrke governance” uden målbare leverancer. Arbejd i stedet med leverancer, der kan gennemføres, testes og overdrages til drift.
En praktisk opdeling er: fundering, implementering, stabilisering og drift. Fundering dækker politikker, inventar og roller. Implementering dækker tekniske kontroller og procesændringer. Stabilisering dækker test, målinger og oprydning. Drift dækker løbende kontrol, træning og forbedringer.
- Definér scope og kritiske systemer
- Lav prioriteret backlog af tiltag
- Fastlæg milepæle med acceptkriterier
- Planlæg afhængigheder og ressourcer
- Gennemfør implementering og test
- Overdrag til drift med målinger
Mini-konklusion: Milepæle uden acceptkriterier skaber falsk fremdrift; milepæle med testbare leverancer skaber reel sikkerhed.
Ansvar der virker: ejerskab, RACI og beslutningsveje
Uklart ansvar er en af de dyreste fejl i sikkerhedsarbejde. Du kan have de bedste kontroller på papiret, men hvis ingen ejer dem, bliver de ikke vedligeholdt, og de fungerer ikke, når det gælder. Et enkelt RACI-setup kan afklare hvem der er Responsible, Accountable, Consulted og Informed for hver leverance og for hver tilbagevendende driftstest.
Gør kontrol-ejerskab konkret
For hver kontrol skal der være en navngiven ejer, ikke bare “IT”. Eksempler: “Identity Manager” som ejer af adgangsstyring, “Platform Lead” som ejer af patching, “Data Owner” som ejer af klassifikation og retention. Ejerskab betyder også budgetdialog og prioritering, ikke kun opgaver.
Skab korte beslutningsveje
Hvis alle ændringer kræver lange styregrupper, opstår der sikkerhedsgæld. Definér derfor, hvilke beslutninger kan tages i teamet, hvilke kræver ledelsesaccept, og hvilke kræver risikogodkendelse. Brug faste tidspunkter til risikodiskussioner, så undtagelser ikke bliver til uendelige “midlertidige” løsninger.
Mini-konklusion: Når ansvar er tydeligt, bliver sikkerhed en del af driften frem for et projekt, der forsvinder efter deadline.
Dokumentation, der hjælper: beviser, sporbarhed og drift
Dokumentation skal være et middel til kontrol og læring, ikke et mål i sig selv. God dokumentation gør det muligt at forstå, hvad der er besluttet, hvad der er implementeret, og hvordan det kontrolleres løbende. Tænk i “beviser”: konfigurationer, logs, screenshots, tickets, testresultater og træningsdata. Hvis du ikke kan bevise det, har du ikke gjort det.
Hold dokumentationen tæt på arbejdet. Brug samme værktøjer som teams allerede bruger: ticket-system, kode-repos, CMDB eller assetliste, og en enkel wiki. En kort, vedligeholdt kontrolbeskrivelse er ofte mere værd end en lang policy, ingen læser.
- Politikker og standarder: korte, handlingsnære
- Kontrolkatalog: hvad kontrolleres, og hvordan
- Procedurer: trin-for-trin for kritiske opgaver
- Bevispakker: artefakter fra test og drift
- Undtagelser: begrundelse, kompensation, udløb
Mini-konklusion: Den bedste dokumentation er den, der kan genbruges som tjekliste, beslutningshistorik og bevis ved revision.
Undgå “powerpoint-sikkerhed”: sådan lukker du gap’et mellem ord og virkelighed
“Powerpoint-sikkerhed” opstår, når organisationen beskriver kontroller, der ikke er implementeret, eller når processen ser god ud på papir, men ikke fungerer i praksis. Kurens kerne er at flytte fokus fra fortælling til test, fra intention til drift. Brug derfor “show me”-princippet: vis konfigurationen, vis rapporten, vis hændelsen, vis at I kan gendanne.
En nyttig øvelse er at vælge tre kritiske scenarier: kompromitteret konto, ransomware, og leverandørnedbrud. For hvert scenarie gennemgår I, hvad der sker første time, første dag og første uge. Mangler bliver straks konkrete: manglende MFA, uklare kontaktlister, ingen segmentering, ingen offline-backup, eller utestet restore.
Midt i mange programmer dukker kravet om NIS2 compliance op, men uanset rammeværk gælder samme princip: kontroller skal være implementeret, ejet, målt og forbedret. Det er her, du undgår at ende med flotte formuleringer uden operativ effekt.
Mini-konklusion: Når du kan teste dine vigtigste scenarier uden at improvisere, er du på vej væk fra powerpoint og hen mod robusthed.
Bedste praksis for milepæle: acceptkriterier, test og målinger
For at milepæle kan styre et sikkerhedsprogram, skal de have acceptkriterier. Acceptkriterier beskriver, hvad der skal være sandt, før noget kan kaldes færdigt. De skal være realistiske og knyttet til evidens. Eksempel: “MFA er på alle privilegerede konti” er ikke nok; du vil også have “rapport viser 100% dækning” og “undtagelser har udløbsdato”.
Byg tests ind fra starten
Planlæg test som en del af leverancen, ikke som en eftertanke. For backup er testen restore. For patching er testen rapport og stikprøve. For awareness er testen adfærdsmåling, ikke deltagelse. Målinger behøver ikke være perfekte, men de skal være stabile nok til at vise forbedring eller forringelse.
Brug få, stærke KPI’er
For mange KPI’er skaber støj. Vælg 5–7, der dækker de største risici: patch compliance på kritiske systemer, MFA-dækning, sårbarheder over SLA, backup-restore succesrate, tid til deaktivering af brugere, phishing-klikrate, og tid til at lukke højrisiko-hændelser. Kombinér dem med en kort månedlig kommentar, der forklarer afvigelser og næste skridt.
Mini-konklusion: Milepæle bliver værdifulde, når de ender i gentagelige tests og få målinger, som ledelsen faktisk kan handle på.
Hvad koster det, og hvordan planlægger du ressourcer realistisk?
Omkostninger afhænger af udgangspunkt, kompleksitet og modenhed. De største poster er typisk tid fra nøglepersoner, licenser til identitet og endpoint-sikkerhed, logning og overvågning, samt konsulentbistand til design og implementering. Mange undervurderer prisen på oprydning: at få styr på rettigheder, enhedsinventar og gamle systemer.
Planlæg med en kombination af “quick wins” og investeringer. Quick wins kan være at stramme admin-rettigheder, slå MFA til, og etablere en enkel patch- og backup-rytme. Investeringer kan være segmentering, central logning, bedre IAM-processer og leverandørstyring. Realistisk ressourceplan betyder, at du allokerer tid til drift samtidig med projektarbejde, ellers falder kontrollerne hurtigt tilbage.
Mini-konklusion: Den billigste plan er sjældent den med færrest tiltag, men den der reducerer de største risici tidligt og gør drift enklere.
Typiske fejl og faldgruber, og sådan undgår du dem
Mange organisationer gentager de samme fejl: de starter for bredt, de dokumenterer før de implementerer, de glemmer leverandører, og de mangler en rytme for opfølgning. En anden klassiker er at acceptere undtagelser uden udløb, så midlertidige huller bliver permanente. Endelig ser man ofte, at sikkerhedsarbejde bliver isoleret i et team, mens resten af organisationen ikke ved, hvad der forventes.
Brug denne korte tjekliste til at undgå de mest almindelige faldgruber:
- Uklart scope: afgræns til kritiske processer og systemer først
- Ingen ejere: navngiv ansvarlige for hver kontrol og rapport
- Ingen evidens: definér beviser for hver milepæl
- Utestede kontroller: planlæg restore-, adgangs- og hændelsestests
- Leverandørblindhed: kræv rapporter, SLA’er og kontaktveje
- Undtagelser uden udløb: giv dato og kompensationskontrol
Mini-konklusion: Når du gør scope, ejerskab, evidens og test til standard, forsvinder de fleste “overraskelser” i sikkerhedsarbejdet.
Sådan kommer du i gang på 30 dage: en enkel handlingsplan
Hvis du vil fra analyse til handling uden at miste kvalitet, så kør en 30-dages opstart med tydelige leverancer. Første uge: scope, kritiske aktiver, og top-10 risici. Anden uge: backlog og milepæle med acceptkriterier. Tredje uge: implementér de vigtigste quick wins, især på identitet, admin-adgang og backup. Fjerde uge: etabler rapportering, ejerskab og en fast driftsrytme.
Hold det småt, men fuldt. Det er bedre at få tre kontroller helt i drift end at beskrive tredive, der aldrig bliver testet. Fremdrift er ikke antallet af dokumenter, men antallet af kontroller, der kan bevises og gentages i hverdagen.
Mini-konklusion: En god start er at skabe en rytme, hvor plan, milepæle, ansvar og dokumentation hænger sammen, og hvor “powerpoint-sikkerhed” bliver erstattet af målbar praksis.
