Step 1 i en sikkerhedsindsats er ikke at købe nye værktøjer, men at forstå jeres nuværende niveau: hvad I har, hvad der virker, og hvor risikoen reelt ligger. Denne guide viser, hvordan I gennemfører en kortlægning og analyse, der kan bruges som beslutningsgrundlag for konkrete forbedringer.
Du får en praktisk opskrift på hvilke artefakter der skal indsamles, hvilke interviewspørgsmål der passer til forskellige roller, og hvordan du scorer sikkerhed på tværs af centrale domæner. Til sidst får du et outputformat, der gør det let at omsætte observationer til prioriterede anbefalinger med tydelig effort.
Kortlægning/analyse betyder her en struktureret gennemgang af dokumentation, konfigurationer og arbejdsgange for at identificere sikkerhedsgab, vurdere risiko og definere næste skridt. Det betyder noget, fordi uden et fælles faktagrundlag bliver prioritering ofte styret af mavefornemmelser, enkeltsager eller leverandørinput frem for virksomhedens faktiske trusselsbillede.
1) Afgrænsning: hvad er scope, og hvad vil I have ud af step 1?
Start med at fastlægge, om analysen dækker hele organisationen eller et afgrænset miljø (fx kerneinfrastruktur, fælles platforme, eller en kritisk forretningsproces). Definér også tidshorisont og ambitionsniveau: er målet et hurtigt risikobillede på 2–3 uger, eller en dybdegående baseline over 6–10 uger?
Definér “kritiske aktiver” før du kigger på kontroller
En typisk fejl er at starte i tekniske detaljer uden at vide, hvad der er mest forretningskritisk. Lav derfor en kort liste over de systemer og data, hvor nedetid, datatab eller brud på fortrolighed gør mest ondt. Brug gerne tre kategorier: kritisk, vigtig, øvrig.
Aftal succeskriterier og leverancer
Gør det klart, at output ikke bare er en rapport, men et prioriteret backlog: findings med risiko, anbefaling, effort og prioritet. Aftal desuden, hvem der godkender faktagrundlaget, og hvem der ejer opfølgningen.
Mini-konklusion: Når scope, kritikalitet og succeskriterier er aftalt, bliver resten af kortlægningen markant hurtigere og mere objektiv.
2) Artefakter: hvad skal indsamles for at skabe et troværdigt faktagrundlag?
Artefakter er de dokumenter og tekniske udtræk, der viser, hvordan sikkerheden faktisk er tænkt og udført. Saml dem tidligt, så interviews kan handle om afvigelser og ikke hukommelse.
- Politikker: informationssikkerhedspolitik, adgangspolitik, logningspolitik, backup-politik, change management, acceptabel brug.
- Hændelseslog: incident tickets, SIEM/EDR-alarmhistorik, helpdesk-kategorier, sagsforløb fra de sidste 6–12 måneder.
- Systemoversigt: CMDB eller systemkatalog, dataflows, integrationsliste, klassifikation, ejerskab, miljøer (prod/test).
- Adgangsmodel: roller, AD/Azure AD-struktur, MFA-krav, privileged access, joiner/mover/leaver-proces.
- Leverandørkontrakter: driftsaftaler, databehandleraftaler, SLA’er, revisionsrapporter (ISAE 3000/3402), underleverandører.
- Beredskabsdokumenter: incident response plan, kommunikationsplan, BCP/DR, restore-procedurer, kontaktlister og eskalationsveje.
Et praktisk tip er at oprette en delt mappe med fast navnestandard og versionskontrol, så du kan citere konkrete kilder i dine findings. Husk at notere “sidst opdateret”, fordi forældede dokumenter ofte er et finding i sig selv.
Mini-konklusion: Jo mere du kan basere analysen på faktiske artefakter og udtræk, desto mindre bliver analysen farvet af antagelser og personafhængig viden.
3) Interviewpakker pr. rolle: få de rigtige svar uden at spilde tid
Interviews er der, hvor du validerer praksis, finder “workarounds” og får kontekst til, hvorfor noget er som det er. Lav faste interviewpakker, så svar kan sammenlignes på tværs af enheder og teams.
IT drift: driftssikkerhed, ændringer og teknisk gæld
Fokusér på driftens faktiske processer og evidens. Spørg fx: hvordan patches planlægges, hvad der er undtagelser, og hvordan I opdager afvigelser. Bed om konkrete eksempler: seneste kritiske patchrunde, seneste restore, seneste større incident.
Forvaltnings-ejere: forretningskrav, kritikalitet og afhængigheder
Forvaltnings-ejere kan forklare, hvilke funktioner der ikke må gå ned, og hvilke data der er mest følsomme. Spørg til acceptabel nedetid, manuelle nødprocedurer, og om der findes kendte “single points of failure” i processerne.
DPO/jura, indkøb og ledelse: compliance, kontrakter og risikovillighed
DPO/jura hjælper med behandlingsgrundlag, sikkerhedskrav og brudshåndtering. Indkøb bidrager med leverandørkrav, SLA’er og sanktioner. Ledelsen skal tydeliggøre risikovillighed og prioriteringskriterier: hvad er værst, datalæk, nedetid eller økonomisk tab?
Midt i interviewplanlægningen kan det være nyttigt at sammenholde metode og forventninger til kortlægning og analyse for at sikre, at både dokumentation og samtaler dækker de samme risikoområder.
Mini-konklusion: Standardiserede interviewpakker reducerer “støj”, gør det lettere at spotte uoverensstemmelser og giver hurtigere, mere handlingsrettede findings.
4) Scoremodel pr. domæne: sådan gør I sikkerhed målbar uden at overkomplicere
En scoremodel skaber fælles sprog. Den behøver ikke være perfekt; den skal være konsekvent. Brug fx en skala fra 0–5 pr. domæne, hvor 0 er fraværende kontrol, 3 er etableret men ikke konsekvent, og 5 er dokumenteret, monitoreret og forbedres løbende.
Vurder hvert domæne ud fra tre typer evidens: dokumentation (politik/proces), implementering (konfiguration/teknik) og efterlevelse (logs, stikprøver, tickets). Brug en enkel regel: laveste evidensniveau trækker scoren ned.
- Identitet/adgang: MFA, privilegerede konti, livscyklus, adskillelse af roller, adgangsrecertificering.
- Patching: patchvinduer, sårbarhedshåndtering, undtagelser, EOL-systemer.
- Logging: logkilder, retention, alarmer, ansvar for triage, kvalitet af hændelsesdata.
- Backup/restore: dækning, immutability, restore-test, RPO/RTO, adskilt adgang.
- Netværk: segmentering, firewall-regler, remote access, overvågning, “east-west” trafik.
- Leverandørstyring: due diligence, kontraktkrav, revisionsrapporter, exit-planer.
- Awareness: træning, phishing-simuleringer, målgruppeopdeling, måling af effekt.
- Hændelseshåndtering: playbooks, eskalation, roller, kommunikation, læring efter hændelser.
Mini-konklusion: Når I scorer pr. domæne med samme evidenskriterier, kan I prioritere ud fra helhedsbilledet frem for enkeltsymptomer.
5) Outputformat: fra observation til prioriteret handling
Det vigtigste i step 1 er at gøre resultaterne operationelle. Brug et ens format, så ledelse og drift kan læse det hurtigt. Standardisér som: finding → risiko → anbefaling → effort → prioritet.
Sådan skriver du et godt “finding”
Et finding skal være specifikt og efterprøvbart: hvad er observeret, hvor, og hvilken evidens ligger bag. Undgå vage formuleringer som “bør forbedres”. Brug i stedet “ingen dokumenteret restore-test for system X i de sidste 12 måneder”.
Effort og prioritet uden Excel-krig
Effort kan beskrives groft som S/M/L baseret på timer, tværgående afhængigheder og ændringsrisiko. Prioritet kan være P1–P3 ud fra kombinationen af sandsynlighed og konsekvens. Det gør det muligt at handle hurtigt, selv når I ikke har perfekte data.
Mini-konklusion: Et konsekvent outputformat skaber fælles forståelse og gør det muligt at eksekvere, selv når der er mange interessenter.
6) Mini-eksempler på findings: sådan ser det ud i praksis
Eksempel 1: Finding: Restore-procedurer findes for flere kritiske servere, men der er ikke dokumenteret restore-test for de seneste 12 måneder, og der findes ingen samlet oversigt over RTO/RPO pr. system. Risiko: I kan tage backup, men ikke sikkert gendanne i tide ved ransomware eller driftsfejl; det kan forlænge nedetid og øge datatab. Anbefaling: Etabler kvartalsvise restore-tests for de mest kritiske systemer, log resultat og afvigelser, og definér RTO/RPO sammen med forretningen. Effort: M. Prioritet: P1.
Eksempel 2: Finding: Incident-escalation er uklart; drift, forretning og leverandør har forskellige opfattelser af, hvornår en hændelse bliver “kritisk”, og hvem der kontakter DPO/ledelse. Risiko: Forsinket eskalation kan forværre skade, forsinke kommunikation og øge risiko for brud på tidsfrister ved persondatasikkerhed. Anbefaling: Definér severity-niveauer, roller og kontaktpunkter i en one-page eskalationsguide, og gennemfør en bordøvelse. Effort: S. Prioritet: P1.
Mini-konklusion: Når findings beskrives med evidens, risiko og effort, bliver de lette at prioritere og svære at ignorere.
7) Hvad koster step 1, og hvor lang tid tager det?
Omkostningen afhænger af scope, modenhed og hvor let data kan trækkes. Som tommelfingerregel tager en basal kortlægning 2–4 uger med en kombination af interviews og artefaktgennemgang, mens en dybere analyse med stikprøver, tekniske udtræk og flere enheder typisk tager 6–10 uger.
Hvis du skal estimere internt, så regn med 6–12 interviews á 45–60 minutter, plus tid til at samle dokumentation, gennemgå konfigurationer og skrive findings. Hvis der er mange leverandører, så sæt ekstra tid af til kontrakter, SLA’er og afgrænsning af ansvar, fordi det ofte skaber de største uklarheder.
Mini-konklusion: Step 1 behøver ikke være tungt, men det kræver kalenderdisciplin og klare ejere af artefakter, ellers løber det ud i sandet.
8) Typiske fejl og bedste praksis: sådan undgår I en analyse, der ikke kan bruges
De mest almindelige faldgruber handler ikke om teknik, men om metode og forankring. Undgå især at gøre analysen til en “compliance-øvelse”, hvor man kun tjekker om dokumenter findes, uden at teste om de virker i praksis.
- Fejl: For bredt scope fra start. Modtræk: Afgræns til kritiske aktiver og udvid iterativt.
- Fejl: Interviews uden evidens. Modtræk: Bed altid om konkrete tickets, logs eller konfigurationer.
- Fejl: Ingen fælles scoringskriterier. Modtræk: Brug samme skala og samme evidenskrav pr. domæne.
- Fejl: Findings uden ansvar. Modtræk: Tilføj ejer og næste skridt allerede i udkastet.
- Fejl: Fokus på værktøjer frem for processer. Modtræk: Start med arbejdsgange, og se derefter om værktøjer understøtter dem.
- Fejl: Ingen hurtige forbedringer. Modtræk: Markér 3–5 “quick wins” med lav effort og høj risikoreduktion.
Som bedste praksis er det værd at bruge stikprøver: tjek 10 brugere for MFA, 10 servere for patchstatus, og 5 incidents for eskalationskæde. Det giver et mere realistisk billede end et enkelt “ja/nej”.
Mini-konklusion: En god step 1 balancerer dokumentation, tekniske facts og organisatorisk virkelighed, så resultaterne kan omsættes til handling.
