NIS2 gap-analyse: sådan kortlægger du nuværende niveau og laver en realistisk roadmap
Kortlægning og analyse er det praktiske fundament for enhver seriøs cybersikkerheds- og compliance-indsats: Du skaber overblik over, hvordan sikkerhed faktisk fungerer i dag, hvor hullerne er, og hvad der er vigtigst at lukke først. I denne metodeguide får du en gennemprøvet tilgang til step 1, så du kan gå fra mavefornemmelser til beslutninger baseret på data.
Du får konkrete inputs til datagrundlag, interviewspørgsmål pr. team, en enkel scoremodel på tværs af kontrolområder, og en måde at omsætte resultater til et roadmap i 30/60/90 dage samt 6/12 måneder. Undervejs får du typiske faldgruber, estimering af indsats, og et mini-eksempel på et finding med en praktisk anbefaling.
Hvad “kortlægning og analyse” er, og hvorfor det betyder noget
Kortlægning og analyse er en struktureret proces, hvor du indsamler evidens, interviewer nøglefunktioner og vurderer modenhed og risici på tværs af organisationens sikkerhedskontroller. Det betyder noget, fordi du ellers risikerer at bruge tid på de forkerte forbedringer, overse kritiske afhængigheder og undervurdere leverandør- og hændelsesrisiko.
Mini-konklusion: En god kortlægning reducerer både teknisk gæld og compliance-gæld, fordi du kan prioritere efter risiko og forretningskritikalitet.
Datagrundlag: hvad du skal indsamle før interviews
Start med et klart scope: hvilke forretningsenheder, systemer og lokationer indgår, og hvilke kravrammer arbejder I efter. Datagrundlaget skal være konkret og sporbar dokumentation, så vurderingen ikke ender som “holdninger”. Saml materialet i et fælles workspace med versionsstyring og en ansvarlig pr. dokumenttype.
Politikker
Indsaml alle gældende sikkerhedsrelaterede politikker og retningslinjer, også dem der ligger i HR eller indkøb. Kig efter dato, ejer, godkendelse og seneste review. Typiske politikker er informationssikkerhed, adgangsstyring, password, remote work, dataklassifikation, backup, change management og leverandørstyring.
Processer, systemoversigt, leverandørliste og hændelser
Her er et praktisk minimum for en effektiv baseline:
- Procesbeskrivelser for incident management, sårbarhedshåndtering, patching, onboarding/offboarding og change.
- Systemoversigt: applikationer, infrastruktur, dataflows, ejere, kritikalitet og driftsmodel.
- Leverandørliste: SaaS, drift, konsulenter, underdatabehandlere, hosting og kritiske tredjeparts-API’er.
- Hændelser sidste 12 mdr.: incidents, nærved-hændelser, phishing, driftsnedbrud, datalæk og root cause.
- Logging- og overvågningskilder: SIEM, EDR, MDM, firewall, cloud audit logs.
- Træning: gennemførsel, indhold, målgrupper og testresultater.
Mini-konklusion: Hvis du kan knytte hvert system til en ejer, en kritikalitet og en leverandør, bliver resten af analysen markant mere præcis.
Interviewsetup: sådan får du sandheden frem
Interviews er ikke en eksamen, men en måde at afdække praksis, undtagelser og “shadow IT”. Planlæg 45–60 minutter pr. team, og send 6–10 spørgsmål på forhånd. Bed om eksempler: “Vis mig den sidste change”, “Vis mig en incident ticket”, “Hvem godkender adgang?”. Det gør samtalen evidensbaseret.
Faldgruber i interviewfasen
De mest almindelige fejl er at spørge for bredt, ikke få konkrete artefakter, og at lade ledelsen “oversætte” virkeligheden. Undgå også at interviewe for få: drift og udvikling kan have helt forskellige billeder af samme kontrol.
Mini-konklusion: Spørg efter fakta og eksempler, og accepter at uoverensstemmelser er data, ikke modstand.
Interviewspørgsmål pr. team: IT drift, udvikling, HR, ledelse, indkøb
Brug nedenstående som skabelon og tilpas efter jeres teknologi og branche. Målet er at forstå ansvar, kontrolpraksis og dokumentation, ikke at “finde fejl”.
IT drift
- Hvordan håndterer I patching og prioritering af kritiske sårbarheder, og hvor hurtigt?
- Hvilke logkilder har I, hvor længe gemmes logs, og hvem reagerer på alarmer?
- Hvordan styres privilegerede konti, og hvordan gennemføres access reviews?
- Hvordan testes backup-restore, og hvad er RTO/RPO for kritiske systemer?
- Hvordan håndterer I ændringer: godkendelse, dokumentation, rollback og nødchanges?
Udvikling
- Hvilke sikkerhedstjek indgår i CI/CD: SAST, dependency scanning, secret scanning, IaC scanning?
- Hvordan håndteres miljøadskillelse, og hvem har adgang til produktion?
- Hvordan håndterer I tredjepartsbiblioteker og SBOM, og hvordan reagerer I på CVE’er?
- Hvordan dokumenterer I trusselsmodellering eller sikkerhedskrav ved nye features?
- Hvordan håndteres incident response for applikationsfejl og databrud?
HR
- Hvordan ser onboarding/offboarding ud i praksis, og hvor hurtigt fjernes adgange?
- Hvilken sikkerhedstræning gives, hvor ofte, og hvordan måles effekt?
- Hvordan håndteres baggrundstjek, roller med særlige rettigheder og interne politikbrud?
- Hvordan kommunikeres sikkerhedsprocedurer til medarbejdere og konsulenter?
Ledelse
- Hvad er jeres vigtigste forretningsprocesser og tolerancer for nedetid og datatab?
- Hvordan prioriteres sikkerhedsinitiativer, og hvem accepterer residual risiko?
- Hvilke KPI’er/risikorapporter får I, og hvordan følges der op på afvigelser?
- Hvordan håndteres krisestyring og beslutningskompetence ved større hændelser?
Indkøb
- Hvordan vurderes leverandørers sikkerhed før kontrakt, og hvilke krav er standard?
- Hvordan håndteres databehandleraftaler, underleverandører og ændringer i scope?
- Har I en cadence for review af kritiske leverandører og deres audits/attestationer?
- Hvordan dokumenteres exit-plan og dataudlevering ved leverandørskifte?
Midt i arbejdet kan det være nyttigt at sammenholde jeres nuværende praksis med en målestok som en NIS2 gap analyse, så interviewfund og evidens kobles til konkrete kontrolkrav og forventet modenhed.
Scoremodel (0–5) på tværs af kontrolområder
En enkel scoremodel gør det muligt at sammenligne teams, systemer og kontrolområder uden at drukne i detaljer. Vælg én skala og brug den konsekvent. Her bruger vi 0–5, hvor 0 er ikke-eksisterende, og 5 er optimeret og målt.
Definition af 0–5
0: Ingen kontrol. 1: Ad hoc og personafhængigt. 2: Delvist dokumenteret, uens praksis. 3: Defineret og implementeret, men begrænset måling. 4: Styret, målt, regelmæssige reviews. 5: Optimeret, automatiseret hvor relevant, læring fra hændelser.
Kontrolområder og hvad du scorer på
- Governance: roller, ansvar, politikker, ledelsesrapportering, risikoejer.
- Risiko: metode, opdateringsfrekvens, sammenhæng med forretning, risikoregister.
- Hændelser: detektion, triage, eskalation, post-mortems, læring.
- Leverandører: due diligence, kontraktkrav, løbende review, exit.
- Træning: målgrupper, hyppighed, øvelser, phishing-simulering, effektmåling.
- Beredskab: BCP/DR, test, roller, kommunikation, afhængigheder.
- Logging: logdækning, retention, alarmer, korrelation, adgangskontrol til logs.
Mini-konklusion: Scoring skaber fælles sprog, men virker kun, hvis den understøttes af evidens og korte noter om hvorfor scoren er sat.
Fra data til “findings → anbefaling → effort → risiko”
Når evidens og interviews er samlet, omsætter du det til findings, der er handlingsorienterede. Et finding er en observerbar mangel eller svaghed, ikke en holdning. Hver post bør være kort, entydig og koblet til en konsekvens, så ledelse og teams kan prioritere.
Skabelon til output
Brug et ensartet format:
- Finding: Hvad mangler eller fungerer ikke konsekvent?
- Anbefaling: Hvad skal etableres eller ændres, konkret og testbart?
- Effort: Lav/medium/høj eller timer/sprints, inkl. afhængigheder.
- Risiko: Forretningspåvirkning og sandsynlighed, gerne i 1–2 linjer.
Mini-eksempel på et finding
Finding: Mangler formel leverandørstyring for kritiske SaaS-leverandører; vurderinger sker uensartet og uden fast cadence.
Anbefaling: Etabler en standard kravpakke (sikkerhed, underleverandører, logning, hændelsesnotifikation, exit) + review cadence kvartalsvis for kritiske leverandører og årligt for øvrige, inkl. dokumenteret godkendelse.
Effort: Medium (2–6 uger) afhængigt af kontraktfornyelser og dataindsamling.
Risiko: Forhøjet risiko for databrud og driftsforstyrrelser, fordi tredjepartsændringer ikke fanges tidligt.
Mini-konklusion: Et godt finding peger på et systemisk greb, ikke en engangsoprydning.
Hvad koster kortlægning og analyse, og hvordan estimerer du effort?
Omkostningen afhænger primært af kompleksitet: antal systemer, leverandører, lokationer og modenhed. For en mellemstor organisation kan kortlægning og analyse ofte gennemføres på 2–6 uger med 1–3 nøglepersoner i koordinering og 5–15 interviewdeltagere. Hvis systemoversigt og leverandørliste mangler, stiger effort typisk markant.
Praktisk estimering: Opdel arbejdet i dataindsamling, interviews, evidensreview, scoring og rapport. Læg buffer på 20–30% til manglende dokumentation og kalenderkonflikter. Vær eksplicit om afhængigheder, fx at du ikke kan score logging uden adgang til logplatform eller eksempler på alerts.
Mini-konklusion: Den dyreste fejl er at undervurdere tiden til at indsamle “små” lister som leverandører og integrationspunkter.
Roadmap: 30/60/90 dage + 6/12 måneder med afhængigheder
Roadmappet er broen fra analyse til handling. Det skal være realistisk, have ejerskab og tage højde for driftens kapacitet. Start med quick wins, men lås dem til risikoreduktion, ikke kosmetik.
30 dage: stabiliser og få styr på basen
- Etabler risikoregister med ejere og beslutningsforum.
- Færdiggør systemoversigt med kritikalitet og dataflows.
- Definér minimumskrav til logging og retention for kritiske systemer.
- Indfør standard for incident-klassifikation og eskalation, inkl. kontaktliste.
60 dage: standardiser og luk de største huller
- Implementér leverandørkravpakke og review cadence for kritiske leverandører.
- Indfør access review-proces for privilegerede konti og kritiske systemer.
- Plan for sårbarhedshåndtering med SLA’er og rapportering.
- Gennemfør målrettet træning til roller med høj risiko, fx support og finance.
90 dage: test, mål og automatisér de vigtigste kontroller
- Kør tabletop-øvelse for incident response og dokumentér læring.
- Test backup-restore på mindst to kritiske systemer og mål RTO/RPO.
- Opsæt basisalarmer i SIEM/EDR og definer respons-playbooks.
- Indfør change-krav til sikkerhedstjek ved højrisikoændringer.
6 måneder: løft modenhed og skab gentagelig drift
Prioritér initiativer med tværgående effekt: central logplatform for flere kilder, formaliseret governance, samt sikkerhedskrav ind i udviklingsprocessen. Afhængigheder inkluderer licenser, dataadgang, og at roller som systemejere er navngivet og accepterer ansvar.
12 måneder: optimer og dokumentér kontinuerlig forbedring
Her handler det om måling, intern audit-lignende reviews og løbende forbedring baseret på hændelser. Afhængigheder er ofte organisatoriske: budget, kompetencer og at risikostyring er forankret i ledelsesrapportering.
Mini-konklusion: Et stærkt roadmap er ikke en ønskeliste; det er en prioriteret plan med ejere, milepæle og klare afhængigheder.
Bedste praksis og typiske fejl du kan undgå fra starten
Bedste praksis er at kombinere dokumentation, interviews og tekniske stikprøver, så du undgår at overvurdere modenhed. Sørg for at adskille “findings” fra “observationer”, og hold fokus på de kontroller, der faktisk reducerer risiko. Brug minimum viable governance: få roller og enkle beslutningsveje, der virker i hverdagen.
Typiske faldgruber inkluderer at lave for mange parallelle spor, at glemme leverandør- og integrationslandskabet, og at undervurdere betydningen af logging og beredskab. En anden klassiker er at skrive anbefalinger uden at angive effort og afhængigheder, hvilket gør dem svære at omsætte til sprints og budget.
Mini-konklusion: Når du tydeligt kobler kontrol, evidens, score og roadmap, får du en metode, der kan gentages hvert år og løbende forbedres.
