En risikovurdering efter ISO 27001 gennemføres i fem faser: I fastlægger scope og kriterier, kortlægger jeres informationslandskab (aktiver), identificerer relevante trusler, analyserer sandsynlighed og konsekvens for hver kombination, og evaluerer resultatet mod jeres risikoappetit.
NorthGRC understøtter hele processen i ét sammenhængende risikomodul, hvor aktiver, trusselskatalog og risikoberegning hænger sammen – så I ikke skal holde styr på det i separate Excel-ark.
En risikovurdering er den systematiske proces, hvor I identificerer, hvilke risici jeres organisation er udsat for, og hvor store de er. I ISO 27001-sammenhæng er risikovurderingen ikke en formalitet – den er selve begrundelsen for, hvilke sikkerhedskontroller I vælger i jeres Statement of Applicability (SoA). Uden en dokumenteret risikovurdering kan I ikke argumentere for, hvorfor I har valgt (eller udeladt) bestemte kontroller fra Annex A, og det er typisk det første, en auditor beder om at se.
Standarden, der ligger til grund for metodikken, er ISO 31000 (den generelle risikostyringsstandard), mens ISO 27005 giver den informationssikkerhedsspecifikke vejledning. Begge beskriver samme grundproces: kontekst → risikoidentifikation → risikoanalyse → risikoevaluering → risikobehandling → overvågning og rapportering.
En vigtig detalje, mange overser: risikovurdering er ikke et projekt, I laver én gang og lægger i en skuffe. Det er en tilbagevendende proces, der skal genbesøges, når jeres it-landskab, leverandører eller trusselsbillede ændrer sig – ikke kun når revisor kommer på besøg.
NorthGRC's risikomodul er bygget til netop dette: jeres tidligere vurderinger, kommentarer og begrundelser gemmes og kan genbruges, næste gang I reviderer et aktiv, så risikovurderingen bliver en levende del af driften i stedet for et engangsdokument.
Herunder er de fem faser, som både ISO 31000 og ISO 27005 bygger på, oversat til konkrete handlinger.
Beslut, hvad risikovurderingen skal omfatte (hele organisationen, en specifik afdeling, en bestemt systemtype), og fastlæg jeres risikokriterier – altså hvornår en risiko er acceptabel, og hvornår den skal behandles. Dette er også her, I beslutter, hvilken analysemetode I vil bruge (se afsnittet om metodevalg nedenfor).
I skal vide, hvad I har, før I kan vurdere risikoen ved det. Registrer systemer, processer, datasæt og leverandører, der understøtter forretningen, og kortlæg afhængighederne mellem dem – det er afgørende for at forstå, hvordan en hændelse i ét system kan sprede sig til andre. Hvis det er første gang, I laver en risikovurdering, er det en klassisk faldgrube at forsøge at kortlægge "alle aktiver" fra dag ét – start i stedet med de 10-15 mest kritiske aktiver.
Brug et trusselskatalog som udgangspunkt – en liste over generiske trusler med en indledende vurdering af sandsynlighed og konsekvens. Hvilke trusler der er relevante for et givet aktiv, afhænger typisk af aktivets kategori (en server har andre relevante trusler end en leverandøraftale).
For hvert aktiv vurderer I sandsynligheden for, at en trussel udløses, og konsekvensen, hvis det sker. Her er flere metoder at vælge imellem – de er beskrevet i tabellen længere nede. Uanset metode bør hver vurdering ledsages af en kort begrundelse, så jeres ræsonnement er dokumenteret for både ledelsen og revisoren – ikke kun selve tallet.
Eksempel: Sig, at I vurderer jeres kundedatabase med en kombineret CIA-vurdering. I sætter sandsynligheden for et uautoriseret adgangsforsøg til "mellem" og konsekvensen for fortrolighed til "høj" (fordi databasen indeholder persondata), mens konsekvensen for tilgængelighed sættes til "lav" (systemet har en fungerende backup). Den vægtede gennemsnitsberegning giver jer én samlet risikoscore for aktivet – men fordi I har vurderet fortrolighed, integritet og tilgængelighed separat, kan I stadig se, at det er fortroligheden, der driver risikoen, og målrette jeres behandlingstiltag derefter (fx kryptering og adgangsstyring, snarere end mere redundans).
Sammenlign de beregnede risikoniveauer med jeres risikoappetit for at afgøre, hvilke risici der skal behandles, og hvilke der kan accepteres. Herefter vælger I, hvordan hver risiko skal håndteres – I har fire grundlæggende muligheder: acceptere, reducere, overføre eller undgå risikoen. Til sidst dokumenterer og rapporterer I resultatet, og processen genoptages ved næste review.
NorthGRC's risikomodul følger denne rækkefølge direkte i platformen: I starter med trusselskataloget, kortlægger aktiver, gennemfører analysen på det enkelte aktiv og sender vurderingen videre til evaluering med et enkelt klik – med automatisk besked til de ansvarlige for hvert aktiv.
Der findes ikke én "rigtig" metode foreskrevet af ISO 27001 – standarden kræver blot, at I har en dokumenteret og konsistent metodologi. Valget handler om, hvor dybt I har brug for at gå, afhængigt af aktivets kritikalitet.
| Metode | Hvad den måler | Bedst til |
|---|---|---|
| Simpel vurdering | Én samlet risikoscore pr. aktiv | Hurtigt førstegangsoverblik, lav-kritiske aktiver |
|
Kombineret CIA-vurdering |
Separat score for fortrolighed, integritet og tilgængelighed pr. aktiv |
Standardvalget til de fleste ISO 27001- og GDPR-vurderinger |
| Trusselsbaseret analyse | Sandsynlighed og konsekvens vurderet pr. trussel pr. aktiv, ud fra trusselskataloget | Kritiske systemer og data med høj risiko for de registrerede |
Den kombinerede CIA-vurdering er i praksis det mest almindelige valg, fordi den matcher, hvordan både ISO 27001 og myndigheder som Datatilsynet tænker konsekvens – nemlig som en kombination af fortrolighed, integritet og tilgængelighed, snarere end én samlet konsekvenstal.
I NorthGRC kan I vælge dybden pr. aktiv. Det betyder, at jeres mest kritiske leverandør kan få en fuld trusselsbaseret analyse, mens et lav-kritisk internt værktøj klares med en simpel vurdering, uden at I skal skifte system eller metode midt i processen.
Tre mønstre går igen hos virksomheder, der laver deres første risikovurdering under tidspres:
Fordi risici kan forplante sig mellem afhængige aktiver – sandsynligheden opad og konsekvensen nedad i afhængighedskæden – kan en mangelfuld kortlægning af afhængigheder føre til, at I undervurderer den reelle eksponering for jeres mest kritiske systemer.
NorthGRCs risikoarv (risk inheritance) synliggør automatisk disse sammenhænge. Når I kortlægger afhængigheder mellem aktiver, beregner platformen, hvordan risikoen på ét aktiv påvirker de aktiver, det er forbundet med. Dermed slipper I for at holde styr på sammenhængene manuelt i et regneark.
Risikovurdering har altid været et krav under GDPR's artikel 32, men Datatilsynet stiller ingen konkrete krav til metode – hvilket i praksis lægger ansvaret for en forsvarlig metodologi hos jer selv. Det samme billede tegner sig nu for NIS2: loven trådte i kraft i Danmark i 2025 og udvider antallet af omfattede virksomheder markant, og risikostyring er ét af de områder, myndighederne konkret spørger ind til, når NIS2-tilsynet begynder at rulle ud i 2026.
Det er dog langt fra alle, der er i mål. Blandt de omfattede godt 6.000 danske virksomheder er kun omkring 16 procent fuldt forberedte på NIS2 på nuværende tidspunkt – og en dokumenteret risikovurdering er typisk det første, der efterspørges, når tilsynet kommer. Har I allerede en dokumenteret risikovurdering efter ISO 27001, er I dog sjældent langt fra målet – de fleste af NIS2's krav kan dækkes med samme grundlag og få tilføjelser, snarere end en ny proces fra bunden.
Det er netop denne sammenhæng, en fælles platform omsætter til praksis. NorthGRC anvender det samme aktivgrundlag og trusselskatalog på tværs af informationssikkerhed, databeskyttelse og OT. Derfor kan en risikovurdering af ét aktiv understøtte både jeres arbejde med ISO 27001, jeres NIS2-indsats og jeres GDPR-dokumentation – uden at I skal vurdere det samme aktiv tre gange i forskellige systemer.
De fem trin er enkle at liste, men det, der afgør, om jeres risikovurdering reelt holder til en audit, er dokumentationen undervejs: hvorfor I vurderede, som I gjorde, hvilke aktiver der hænger sammen, og hvordan I endte med den valgte behandling. Det er den dokumentation, en revisor beder om at se – ikke bare den endelige score.
Er I i gang med jeres ISO 27001-implementering og skal have styr på metoden fra bunden, eller vil I se, hvordan de fem trin kan understøttes af én sammenhængende platform i stedet for et regneark og et Word-dokument? Vi har samlet en mere detaljeret gennemgang, inklusive praktiske eksempler på behandlingstiltag, i en gratis guide: Vejledning i risikostyring med ISO 27005.
Risikovurderingen bør revideres, når der sker væsentlige ændringer i jeres systemlandskab, leverandører eller trusselsbillede – ikke kun på et fast tidspunkt i kalenderen. ISO 27001 foreskriver ikke et fast interval, men de fleste organisationer sætter en årlig gennemgang som bundgrænse, så aktiver og vurderinger, der ikke er rørt af andre årsager, stadig bliver genbesøgt mindst én gang om året.
Nej. I kan med fordel bruge en simpel vurdering til lav-kritiske aktiver og en mere dybdegående, trusselsbaseret analyse til jeres kritiske systemer og data – så længe metoden er konsistent og dokumenteret for det enkelte aktiv.
Risikovurdering handler om at identificere og score jeres risici. Risikohåndtering (også kaldet risikobehandling) er det efterfølgende trin, hvor I beslutter, hvordan hver risiko skal håndteres – accepteres, reduceres, overføres eller undgås.
Delvist. Begge tager udgangspunkt i sandsynlighed og konsekvens, men GDPR-risikovurderingen (konsekvensanalysen) har fokus på risiko for de registrerede, mens ISO 27001 også ser på forretningsmæssig konsekvens. Med en fælles metode og et fælles aktivgrundlag kan meget af arbejdet dog genbruges mellem de to.
Hvis I aldrig har lavet en risikovurdering før, er det almindelig praksis at starte med de 10-15 mest kritiske aktiver – typisk jeres vigtigste systemer og leverandører – frem for at forsøge at kortlægge alt på én gang.