ISO 27001 risikovurdering: Fra identificerede risici til dokumenterede sikkerhedsforanstaltninger

En ISO 27001-risikovurdering er en systematisk vurdering af, hvilke risici der kan påvirke organisationens informationer, systemer og forretningskritiske processer.

Formålet er at skabe et dokumenteret grundlag for at beslutte, hvilke sikkerhedsforanstaltninger organisationen skal indføre, forbedre eller acceptere. Det handler ikke om at fjerne alle risici. Det handler om at forstå dem, prioritere dem og behandle dem på en måde, der passer til organisationens drift, forpligtelser og risikovillighed.

I praksis vurderer organisationen typisk:

• Hvilke informationer og systemer der er kritiske
• Hvilke trusler der kan påvirke dem
• Hvilke sårbarheder der findes
• Hvad konsekvensen kan være
• Hvor sandsynligt det er, at risikoen realiseres
• Hvilke sikkerhedsforanstaltninger der reducerer risikoen

En ISO 27001-risikovurdering er derfor ikke kun et compliance-dokument. Den er et styringsværktøj, der hjælper ledelsen og organisationen med at træffe bedre beslutninger om informationssikkerhed.

Har jeres organisation brug for rådgivning inden for ISO 27001 og begynde arbejdet med bl.a. risikovurderinger, tilbyder vi både skræddersyede forløb og timebaseret rådgivning (læs mere om vores rådgivning her).

ISO 27001 bygger på en risikobaseret tilgang til informationssikkerhed. Det betyder, at organisationens sikkerhedsarbejde skal tage udgangspunkt i de risici, der faktisk er relevante for organisationen.

En virksomhed med følsomme kundedata, cloudbaserede systemer og mange eksterne leverandører har andre risici end en produktionsvirksomhed med kritiske driftssystemer og OT-miljøer. En kommune har andre hensyn end en SaaS-virksomhed, fordi nedbrud kan påvirke borgerbetjening, omsorgsopgaver og samfundsvigtige services.

Risikovurderingen skaber sammenhæng mellem:

• Organisationens forretningsmål
• De informationer og systemer, der skal beskyttes
• De trusler og sårbarheder, der kan skabe skade
• De sikkerhedsforanstaltninger, der skal implementeres
• Den dokumentation, der skal kunne fremvises ved audit, kundekrav eller regulatorisk kontrol

Hvis risikovurderingen er svag, bliver resten af ISO 27001-arbejdet ofte upræcist. Organisationen risikerer at implementere kontroller, der ikke adresserer de vigtigste risici, eller at bruge ressourcer på sikkerhedstiltag, der ikke har tilstrækkelig forretningsmæssig betydning.

Hvad skal organisationen vurdere?

En god risikovurdering starter med at afgrænse, hvad der skal beskyttes.

Det kan være informationsaktiver, systemer, processer, lokationer, leverandører eller organisatoriske funktioner. Det vigtigste er, at vurderingen afspejler den måde, organisationen faktisk fungerer på.

Eksempler på aktiver og områder i en ISO 27001-risikovurdering:

Område	Eksempler	Mulige konsekvenser ved svigt
Kundedata	Kontaktoplysninger, kontrakter, supportdata	Databrud, tab af tillid, regulatoriske krav
Driftssystemer	ERP, produktionssystemer, planlægningsværktøjer	Produktionsstop, forsinkede leverancer, økonomisk tab
Cloud-platforme	Microsoft 365, AWS, Azure, Google Cloud	Utilgængelige services, tab af data, afhængighed af leverandør
Medarbejderadgange	Administratorrettigheder, VPN, e-mailkonti	Misbrug af adgang, lateral bevægelse, datalæk
Leverandører	IT-drift, hosting, softwareleverandører	Forsyningskæderisici, nedbrud, manglende kontrol
Dokumentation	Politikker, procedurer, risikovurderinger	Manglende auditspor, uklar styring, svag compliance

Organisationen bør undgå at gøre vurderingen for teoretisk. Risici skal beskrives, så ledelsen og de ansvarlige kan forstå, hvad der kan ske i praksis.

Eksempelvis er “manglende adgangsstyring” en sårbarhed. Risikoen kan være, at tidligere medarbejdere eller brugere med for brede rettigheder får adgang til fortrolige oplysninger eller kritiske systemer.

Trussel, sårbarhed og risiko

Mange risikovurderinger bliver uklare, fordi begreberne blandes sammen.

En trussel er noget, der kan udnytte en svaghed. Det kan være cyberkriminelle, fejl, systemnedbrud, interne handlinger eller leverandørsvigt.

En sårbarhed er en svaghed i organisationen, teknologien eller processen. Det kan være manglende MFA, utilstrækkelig backup, for brede administratorrettigheder eller manglende test af beredskab.

En risiko opstår, når en trussel kan udnytte en sårbarhed og skabe en konsekvens for organisationen.

Eksempel:

Element	Eksempel
Trussel	Phishingangreb mod medarbejdere
Sårbarhed	Manglende MFA og begrænset awareness-træning
Risiko	Uautoriseret adgang til e-mail og kundedata
Konsekvens	Databrud, driftsforstyrrelser og tab af tillid
Mulig behandling	MFA, awareness-træning, overvågning og hændelsesprocedure

Denne opdeling gør risikovurderingen mere konkret og lettere at omsætte til handling.

Hvordan vurderes sandsynlighed og konsekvens?

En risikovurdering skal give organisationen et prioriteringsgrundlag. Derfor vurderes risiko typisk ud fra sandsynlighed og konsekvens.

Sandsynlighed beskriver, hvor realistisk det er, at risikoen kan indtræffe. Konsekvens beskriver, hvor alvorlig påvirkningen vil være, hvis den gør.

Konsekvens bør ikke kun vurderes teknisk. Den bør også vurderes ud fra drift, kunder, økonomi, lovgivning, omdømme og ledelsesansvar.

Eksempel:

Risiko	Sandsynlighed	Konsekvens	Samlet prioritet
Kompromittering af administratoradgang	Høj	Høj	Kritisk
Nedbrud i marketingplatform	Middel	Lav	Lav
Manglende backup-test af ERP-system	Middel	Høj	Høj
Leverandør uden dokumenterede sikkerhedskrav	Middel	Middel	Middel

Organisationen bør definere sin skala tydeligt. Hvis “høj konsekvens” betyder noget forskelligt for IT, økonomi og ledelse, bliver risikovurderingen svær at bruge.

Et praktisk udgangspunkt kan være at beskrive konsekvens ud fra spørgsmål som:

• Kan risikoen stoppe kritiske forretningsprocesser?
• Kan risikoen påvirke kunder, borgere eller samarbejdspartnere?
• Kan risikoen medføre brud på lovgivning eller kontrakter?
• Kan risikoen medføre væsentlige økonomiske tab?
• Kan risikoen skade organisationens tillid eller markedsposition?

Fra risikovurdering til risikobehandling

Når risici er vurderet, skal organisationen beslutte, hvordan de skal behandles.

I ISO 27001-sammenhæng handler risikobehandling om at vælge en passende håndtering af hver væsentlig risiko.

Der er typisk fire muligheder:

Behandling	Betydning	Eksempel
Reducere risiko	Indføre eller forbedre sikkerhedsforanstaltninger	MFA, backup-test, adgangsgennemgang
Acceptere risiko	Acceptere risikoen inden for organisationens risikovillighed	Lav risiko med begrænset konsekvens
Undgå risiko	Stoppe eller ændre aktiviteten	Fravælge usikker leverandør eller teknologi
Overføre risiko	Flytte dele af konsekvensen til en anden part	Forsikring eller kontraktuelle krav

Det vigtigste er, at beslutningen er dokumenteret og begrundet.

Hvis organisationen vælger at acceptere en risiko, bør det ikke ske passivt. Det bør fremgå, hvem der har accepteret risikoen, hvorfor den accepteres, og hvornår beslutningen skal revurderes.

Hvad er Statement of Applicability?

Statement of Applicability, ofte forkortet SoA, er et centralt dokument i ISO 27001.

SoA’en viser, hvilke sikkerhedsforanstaltninger fra ISO 27001 Annex A organisationen har valgt at anvende, hvilke der ikke er relevante, og hvorfor.

Det gør SoA’en til forbindelsen mellem risikovurderingen og de konkrete kontroller.

En god SoA bør kunne svare på:

• Hvilke kontroller er relevante for organisationen?
• Hvorfor er de valgt?
• Hvordan er de implementeret?
• Hvilke kontroller er fravalgt?
• Hvorfor er de fravalgt?
• Hvordan hænger valgene sammen med risikovurderingen?

SoA’en skal ikke bare være en liste over kontroller. Den skal dokumentere organisationens beslutninger.

Eksempel:

Annex A-område	Relevans	Begrundelse	Implementering
Adgangsstyring	Relevant	Risiko for uautoriseret adgang til kritiske systemer	MFA, rollebaseret adgang og kvartalsvis adgangsgennemgang
Backup	Relevant	Risiko for datatab og driftsafbrydelse	Daglig backup og halvårlig gendannelsestest
Leverandørstyring	Relevant	Kritiske IT-services leveres af tredjeparter	Sikkerhedskrav i kontrakter og årlig leverandørvurdering
Fysisk sikring	Delvist relevant	Begrænset lokal infrastruktur	Adgangskontrol til kontor og aflåst netværksudstyr

Ved audit vil SoA’en ofte være et vigtigt dokument, fordi den viser, om organisationens kontroller er valgt ud fra en dokumenteret og risikobaseret metode.

Eksempel: Risikovurdering af adgangsstyring

Adgangsstyring er et godt eksempel på, hvordan en risiko kan beskrives konkret.

En organisation bruger Microsoft 365, et ERP-system og flere cloudbaserede fagsystemer. Flere medarbejdere har administratorrettigheder, men der gennemføres ikke regelmæssig adgangsgennemgang. (Læs mere om relationen mellem ERP-systemer og ISO 27001, NIS2 og CRA her).

Risikoen kan beskrives sådan:

“Brugere med for brede eller forældede adgangsrettigheder kan få adgang til fortrolige oplysninger eller kritiske systemfunktioner, hvilket kan medføre databrud, fejlændringer eller misbrug af privilegerede konti.”

Mulige sikkerhedsforanstaltninger:

• MFA på alle brugere
• Særskilt håndtering af administratoradgange
• Rollebaseret adgangsstyring
• Kvartalsvis adgangsgennemgang
• Hurtig deaktivering ved fratrædelse
• Logning og overvågning af privilegerede handlinger

Denne type risikobeskrivelse er bedre end en generel formulering som “adgangsstyring er utilstrækkelig”, fordi den tydeliggør konsekvensen og gør det lettere at vælge de rigtige handlinger.

Eksempel: Risikovurdering af leverandører

Leverandørstyring er et område, hvor mange organisationer undervurderer risikoen.

Hvis en ekstern leverandør driver kritiske systemer, hoster data eller har administratoradgang, kan leverandørens sikkerhedsniveau direkte påvirke organisationens egen risiko.

En relevant risiko kan være:

“Kritisk IT-leverandør har utilstrækkelig dokumentation for adgangsstyring, backup og hændelseshåndtering, hvilket kan medføre driftsafbrydelser, datatab eller manglende indsigt ved sikkerhedshændelser.”

Mulige sikkerhedsforanstaltninger:

• Sikkerhedskrav i kontrakter
• Krav om dokumentation for backup og beredskab
• Databehandleraftale, hvor relevant
• Vurdering af leverandørens certificeringer eller erklæringer
• Krav om varsling ved sikkerhedshændelser
• Periodisk leverandøropfølgning

Her viser risikovurderingen, at leverandørstyring er en central del af informationssikkerheden.

Typiske fejl i ISO 27001-risikovurderinger

Mange organisationer laver risikovurderinger, der formelt set er korrekte, men som er svære at bruge i praksis.

De mest almindelige fejl er:

• Risikoen beskrives for abstrakt

Formuleringer som “cyberangreb”, “databrud” eller “manglende compliance” er for brede alene. De skal omsættes til konkrete scenarier, så organisationen kan vurdere årsag, konsekvens og behandling.

• Der er for lidt sammenhæng til forretningen

Hvis risikovurderingen kun vurderer tekniske systemer, overser organisationen ofte de reelle konsekvenser for drift, kunder, medarbejdere og leverancer.

• Sandsynlighed og konsekvens er uklart defineret

Hvis skalaen ikke er tydelig, bliver vurderingen subjektiv. Det gør det svært at sammenligne risici og prioritere indsatser.

• SoA’en bliver en tjekliste

Annex A-kontroller skal vælges ud fra risikovurderingen. Hvis SoA’en blot udfyldes som en generisk kontrolliste, mister den sin værdi som dokumenteret beslutningsgrundlag.

• Risikovurderingen opdateres ikke

Risikovurderingen skal holdes ajour, når organisationen ændrer systemer, leverandører, processer eller risikobillede. Den bør også opdateres efter væsentlige hændelser, auditfund eller ændringer i lovgivning og kundekrav.

Hvor ofte bør risikovurderingen opdateres?

En ISO 27001-risikovurdering bør gennemgås regelmæssigt og ved væsentlige ændringer.

Det kan for eksempel være ved:

• Nye kritiske systemer
• Nye cloud-leverandører
• Outsourcing af IT-drift
• Større organisatoriske ændringer
• Nye regulatoriske krav
• Sikkerhedshændelser
• Auditfund
• Ændringer i trusselsbilledet
• Nye kundekrav eller udbudskrav

Mange organisationer vælger en årlig fuld gennemgang og løbende opdateringer ved større ændringer. Det vigtigste er, at risikovurderingen afspejler den aktuelle virkelighed.

En forældet risikovurdering kan give falsk tryghed. Den kan også skabe problemer ved audit, fordi dokumentationen ikke længere viser den faktiske risikoeksponering.

Risikovurderingen som ledelsesværktøj

En moden ISO 27001-risikovurdering er ikke kun relevant for informationssikkerhedsansvarlige.

Den bør også give ledelsen et klart billede af:

• Hvor organisationens væsentligste informationssikkerhedsrisici ligger
• Hvilke risici der kræver investeringer
• Hvilke risici der accepteres
• Hvilke sikkerhedsforanstaltninger der er prioriteret
• Hvor der er behov for ledelsesbeslutninger

Når risikovurderingen bruges rigtigt, bliver den en del af organisationens styring. Den hjælper med at prioritere mellem tekniske forbedringer, leverandørkrav, awareness-træning, beredskab og dokumentation.

Det gør også dialogen med bestyrelse, direktion og kunder mere konkret. I stedet for at tale generelt om “cybersikkerhed” kan organisationen forklare, hvilke risici der er identificeret, hvordan de behandles, og hvilke beslutninger der er truffet.

Praktisk tjekliste til ISO 27001-risikovurdering

En organisation bør som minimum kunne svare ja til følgende:

Spørgsmål	Ja/nej
Har vi defineret scope for risikovurderingen?
Har vi identificeret kritiske informationsaktiver, systemer og processer?
Har vi beskrevet relevante trusler og sårbarheder?
Har vi vurderet sandsynlighed og konsekvens ud fra en tydelig metode?
Har vi prioriteret risici ud fra forretningsmæssig betydning?
Har vi besluttet risikobehandling for væsentlige risici?
Har vi koblet risici til konkrete sikkerhedsforanstaltninger?
Har vi dokumenteret relevante Annex A-kontroller i SoA’en?
Har ledelsen taget stilling til væsentlige og accepterede risici?
Har vi fastlagt, hvornår risikovurderingen skal opdateres?

 

ISO 27001 bygger på en risikobaseret tilgang til informationssikkerhed. Det betyder, at organisationens sikkerhedsarbejde skal tage udgangspunkt i de risici, der faktisk er relevante for organisationen.

En virksomhed med følsomme kundedata, cloudbaserede systemer og mange eksterne leverandører har andre risici end en produktionsvirksomhed med kritiske driftssystemer og OT-miljøer. En kommune har andre hensyn end en SaaS-virksomhed, fordi nedbrud kan påvirke borgerbetjening, omsorgsopgaver og samfundsvigtige services.

Risikovurderingen skaber sammenhæng mellem:

• Organisationens forretningsmål
• De informationer og systemer, der skal beskyttes
• De trusler og sårbarheder, der kan skabe skade
• De sikkerhedsforanstaltninger, der skal implementeres
• Den dokumentation, der skal kunne fremvises ved audit, kundekrav eller regulatorisk kontrol

Hvis risikovurderingen er svag, bliver resten af ISO 27001-arbejdet ofte upræcist. Organisationen risikerer at implementere kontroller, der ikke adresserer de vigtigste risici, eller at bruge ressourcer på sikkerhedstiltag, der ikke har tilstrækkelig forretningsmæssig betydning.

Hvad skal organisationen vurdere?

En god risikovurdering starter med at afgrænse, hvad der skal beskyttes.

Det kan være informationsaktiver, systemer, processer, lokationer, leverandører eller organisatoriske funktioner. Det vigtigste er, at vurderingen afspejler den måde, organisationen faktisk fungerer på.

Eksempler på aktiver og områder i en ISO 27001-risikovurdering:

Område	Eksempler	Mulige konsekvenser ved svigt
Kundedata	Kontaktoplysninger, kontrakter, supportdata	Databrud, tab af tillid, regulatoriske krav
Driftssystemer	ERP, produktionssystemer, planlægningsværktøjer	Produktionsstop, forsinkede leverancer, økonomisk tab
Cloud-platforme	Microsoft 365, AWS, Azure, Google Cloud	Utilgængelige services, tab af data, afhængighed af leverandør
Medarbejderadgange	Administratorrettigheder, VPN, e-mailkonti	Misbrug af adgang, lateral bevægelse, datalæk
Leverandører	IT-drift, hosting, softwareleverandører	Forsyningskæderisici, nedbrud, manglende kontrol
Dokumentation	Politikker, procedurer, risikovurderinger	Manglende auditspor, uklar styring, svag compliance

Organisationen bør undgå at gøre vurderingen for teoretisk. Risici skal beskrives, så ledelsen og de ansvarlige kan forstå, hvad der kan ske i praksis.

Eksempelvis er “manglende adgangsstyring” en sårbarhed. Risikoen kan være, at tidligere medarbejdere eller brugere med for brede rettigheder får adgang til fortrolige oplysninger eller kritiske systemer.

Trussel, sårbarhed og risiko

Mange risikovurderinger bliver uklare, fordi begreberne blandes sammen.

En trussel er noget, der kan udnytte en svaghed. Det kan være cyberkriminelle, fejl, systemnedbrud, interne handlinger eller leverandørsvigt.

En sårbarhed er en svaghed i organisationen, teknologien eller processen. Det kan være manglende MFA, utilstrækkelig backup, for brede administratorrettigheder eller manglende test af beredskab.

En risiko opstår, når en trussel kan udnytte en sårbarhed og skabe en konsekvens for organisationen.

Eksempel:

Element	Eksempel
Trussel	Phishingangreb mod medarbejdere
Sårbarhed	Manglende MFA og begrænset awareness-træning
Risiko	Uautoriseret adgang til e-mail og kundedata
Konsekvens	Databrud, driftsforstyrrelser og tab af tillid
Mulig behandling	MFA, awareness-træning, overvågning og hændelsesprocedure

Denne opdeling gør risikovurderingen mere konkret og lettere at omsætte til handling.

Hvordan vurderes sandsynlighed og konsekvens?

En risikovurdering skal give organisationen et prioriteringsgrundlag. Derfor vurderes risiko typisk ud fra sandsynlighed og konsekvens.

Sandsynlighed beskriver, hvor realistisk det er, at risikoen kan indtræffe. Konsekvens beskriver, hvor alvorlig påvirkningen vil være, hvis den gør.

Konsekvens bør ikke kun vurderes teknisk. Den bør også vurderes ud fra drift, kunder, økonomi, lovgivning, omdømme og ledelsesansvar.

Eksempel:

Risiko	Sandsynlighed	Konsekvens	Samlet prioritet
Kompromittering af administratoradgang	Høj	Høj	Kritisk
Nedbrud i marketingplatform	Middel	Lav	Lav
Manglende backup-test af ERP-system	Middel	Høj	Høj
Leverandør uden dokumenterede sikkerhedskrav	Middel	Middel	Middel

Organisationen bør definere sin skala tydeligt. Hvis “høj konsekvens” betyder noget forskelligt for IT, økonomi og ledelse, bliver risikovurderingen svær at bruge.

Et praktisk udgangspunkt kan være at beskrive konsekvens ud fra spørgsmål som:

• Kan risikoen stoppe kritiske forretningsprocesser?
• Kan risikoen påvirke kunder, borgere eller samarbejdspartnere?
• Kan risikoen medføre brud på lovgivning eller kontrakter?
• Kan risikoen medføre væsentlige økonomiske tab?
• Kan risikoen skade organisationens tillid eller markedsposition?

Fra risikovurdering til risikobehandling

Når risici er vurderet, skal organisationen beslutte, hvordan de skal behandles.

I ISO 27001-sammenhæng handler risikobehandling om at vælge en passende håndtering af hver væsentlig risiko.

Der er typisk fire muligheder:

Behandling	Betydning	Eksempel
Reducere risiko	Indføre eller forbedre sikkerhedsforanstaltninger	MFA, backup-test, adgangsgennemgang
Acceptere risiko	Acceptere risikoen inden for organisationens risikovillighed	Lav risiko med begrænset konsekvens
Undgå risiko	Stoppe eller ændre aktiviteten	Fravælge usikker leverandør eller teknologi
Overføre risiko	Flytte dele af konsekvensen til en anden part	Forsikring eller kontraktuelle krav

Det vigtigste er, at beslutningen er dokumenteret og begrundet.

Hvis organisationen vælger at acceptere en risiko, bør det ikke ske passivt. Det bør fremgå, hvem der har accepteret risikoen, hvorfor den accepteres, og hvornår beslutningen skal revurderes.

Hvad er Statement of Applicability?

Statement of Applicability, ofte forkortet SoA, er et centralt dokument i ISO 27001.

SoA’en viser, hvilke sikkerhedsforanstaltninger fra ISO 27001 Annex A organisationen har valgt at anvende, hvilke der ikke er relevante, og hvorfor.

Det gør SoA’en til forbindelsen mellem risikovurderingen og de konkrete kontroller.

En god SoA bør kunne svare på:

• Hvilke kontroller er relevante for organisationen?
• Hvorfor er de valgt?
• Hvordan er de implementeret?
• Hvilke kontroller er fravalgt?
• Hvorfor er de fravalgt?
• Hvordan hænger valgene sammen med risikovurderingen?

SoA’en skal ikke bare være en liste over kontroller. Den skal dokumentere organisationens beslutninger.

Eksempel:

Annex A-område	Relevans	Begrundelse	Implementering
Adgangsstyring	Relevant	Risiko for uautoriseret adgang til kritiske systemer	MFA, rollebaseret adgang og kvartalsvis adgangsgennemgang
Backup	Relevant	Risiko for datatab og driftsafbrydelse	Daglig backup og halvårlig gendannelsestest
Leverandørstyring	Relevant	Kritiske IT-services leveres af tredjeparter	Sikkerhedskrav i kontrakter og årlig leverandørvurdering
Fysisk sikring	Delvist relevant	Begrænset lokal infrastruktur	Adgangskontrol til kontor og aflåst netværksudstyr

Ved audit vil SoA’en ofte være et vigtigt dokument, fordi den viser, om organisationens kontroller er valgt ud fra en dokumenteret og risikobaseret metode.

Eksempel: Risikovurdering af adgangsstyring

Adgangsstyring er et godt eksempel på, hvordan en risiko kan beskrives konkret.

En organisation bruger Microsoft 365, et ERP-system og flere cloudbaserede fagsystemer. Flere medarbejdere har administratorrettigheder, men der gennemføres ikke regelmæssig adgangsgennemgang. (Læs mere om relationen mellem ERP-systemer og ISO 27001, NIS2 og CRA her).

Risikoen kan beskrives sådan:

“Brugere med for brede eller forældede adgangsrettigheder kan få adgang til fortrolige oplysninger eller kritiske systemfunktioner, hvilket kan medføre databrud, fejlændringer eller misbrug af privilegerede konti.”

Mulige sikkerhedsforanstaltninger:

• MFA på alle brugere
• Særskilt håndtering af administratoradgange
• Rollebaseret adgangsstyring
• Kvartalsvis adgangsgennemgang
• Hurtig deaktivering ved fratrædelse
• Logning og overvågning af privilegerede handlinger

Denne type risikobeskrivelse er bedre end en generel formulering som “adgangsstyring er utilstrækkelig”, fordi den tydeliggør konsekvensen og gør det lettere at vælge de rigtige handlinger.

Eksempel: Risikovurdering af leverandører

Leverandørstyring er et område, hvor mange organisationer undervurderer risikoen.

Hvis en ekstern leverandør driver kritiske systemer, hoster data eller har administratoradgang, kan leverandørens sikkerhedsniveau direkte påvirke organisationens egen risiko.

En relevant risiko kan være:

“Kritisk IT-leverandør har utilstrækkelig dokumentation for adgangsstyring, backup og hændelseshåndtering, hvilket kan medføre driftsafbrydelser, datatab eller manglende indsigt ved sikkerhedshændelser.”

Mulige sikkerhedsforanstaltninger:

• Sikkerhedskrav i kontrakter
• Krav om dokumentation for backup og beredskab
• Databehandleraftale, hvor relevant
• Vurdering af leverandørens certificeringer eller erklæringer
• Krav om varsling ved sikkerhedshændelser
• Periodisk leverandøropfølgning

Her viser risikovurderingen, at leverandørstyring er en central del af informationssikkerheden.

Typiske fejl i ISO 27001-risikovurderinger

Mange organisationer laver risikovurderinger, der formelt set er korrekte, men som er svære at bruge i praksis.

De mest almindelige fejl er:

• Risikoen beskrives for abstrakt

Formuleringer som “cyberangreb”, “databrud” eller “manglende compliance” er for brede alene. De skal omsættes til konkrete scenarier, så organisationen kan vurdere årsag, konsekvens og behandling.

• Der er for lidt sammenhæng til forretningen

Hvis risikovurderingen kun vurderer tekniske systemer, overser organisationen ofte de reelle konsekvenser for drift, kunder, medarbejdere og leverancer.

• Sandsynlighed og konsekvens er uklart defineret

Hvis skalaen ikke er tydelig, bliver vurderingen subjektiv. Det gør det svært at sammenligne risici og prioritere indsatser.

• SoA’en bliver en tjekliste

Annex A-kontroller skal vælges ud fra risikovurderingen. Hvis SoA’en blot udfyldes som en generisk kontrolliste, mister den sin værdi som dokumenteret beslutningsgrundlag.

• Risikovurderingen opdateres ikke

Risikovurderingen skal holdes ajour, når organisationen ændrer systemer, leverandører, processer eller risikobillede. Den bør også opdateres efter væsentlige hændelser, auditfund eller ændringer i lovgivning og kundekrav.

Hvor ofte bør risikovurderingen opdateres?

En ISO 27001-risikovurdering bør gennemgås regelmæssigt og ved væsentlige ændringer.

Det kan for eksempel være ved:

• Nye kritiske systemer
• Nye cloud-leverandører
• Outsourcing af IT-drift
• Større organisatoriske ændringer
• Nye regulatoriske krav
• Sikkerhedshændelser
• Auditfund
• Ændringer i trusselsbilledet
• Nye kundekrav eller udbudskrav

Mange organisationer vælger en årlig fuld gennemgang og løbende opdateringer ved større ændringer. Det vigtigste er, at risikovurderingen afspejler den aktuelle virkelighed.

En forældet risikovurdering kan give falsk tryghed. Den kan også skabe problemer ved audit, fordi dokumentationen ikke længere viser den faktiske risikoeksponering.

Risikovurderingen som ledelsesværktøj

En moden ISO 27001-risikovurdering er ikke kun relevant for informationssikkerhedsansvarlige.

Den bør også give ledelsen et klart billede af:

• Hvor organisationens væsentligste informationssikkerhedsrisici ligger
• Hvilke risici der kræver investeringer
• Hvilke risici der accepteres
• Hvilke sikkerhedsforanstaltninger der er prioriteret
• Hvor der er behov for ledelsesbeslutninger

Når risikovurderingen bruges rigtigt, bliver den en del af organisationens styring. Den hjælper med at prioritere mellem tekniske forbedringer, leverandørkrav, awareness-træning, beredskab og dokumentation.

Det gør også dialogen med bestyrelse, direktion og kunder mere konkret. I stedet for at tale generelt om “cybersikkerhed” kan organisationen forklare, hvilke risici der er identificeret, hvordan de behandles, og hvilke beslutninger der er truffet.

Praktisk tjekliste til ISO 27001-risikovurdering

En organisation bør som minimum kunne svare ja til følgende:

Spørgsmål	Ja/nej
Har vi defineret scope for risikovurderingen?
Har vi identificeret kritiske informationsaktiver, systemer og processer?
Har vi beskrevet relevante trusler og sårbarheder?
Har vi vurderet sandsynlighed og konsekvens ud fra en tydelig metode?
Har vi prioriteret risici ud fra forretningsmæssig betydning?
Har vi besluttet risikobehandling for væsentlige risici?
Har vi koblet risici til konkrete sikkerhedsforanstaltninger?
Har vi dokumenteret relevante Annex A-kontroller i SoA’en?
Har ledelsen taget stilling til væsentlige og accepterede risici?
Har vi fastlagt, hvornår risikovurderingen skal opdateres?

 

Få en praktisk og dokumenteret tilgang til ISO 27001-risikovurdering

Nesp.ONE hjælper organisationer med at etablere risikovurderinger, risikobehandling, Statement of Applicability og dokumentation, der understøtter ISO 27001, NIS2 og øvrige compliance-krav.

Kontakt Nesp.ONE her, hvis I vil have en struktureret tilgang til informationssikkerhed, hvor risici bliver omsat til konkrete og effektive sikkerhedsforanstaltninger.