Risikoaccept
Også kendt som: accept af risiko
En bevidst og dokumenteret beslutning om at leve med en risiko i stedet for at bruge flere ressourcer på at mindske den.
Kladde - dette opslag er endnu ikke gennemgået.
Formelt
Den håndteringsmulighed, hvor organisationen bevidst beholder en risiko, fordi den ligger inden for risikoappetitten, eller fordi flere kontroller ville koste mere end skaden; beslutningen træffes og underskrives af en person med ret til at eje risikoen.
Forklaret enkelt
Som at køre videre med et lille stenslag i kanten af forruden - man noterer det, beslutter, at en ny rude ikke er pengene værd endnu, og ser på det igen efter vinteren.
I praksis
I et færgeselskab skriver IT-chefen ned, at testserveren ikke har backup, direktøren skriver under på, at det er acceptabelt i et år, og punktet sættes på listen til ny gennemgang.
Hvorfor det betyder noget
At acceptere en risiko er i orden; at ignorere den er ikke - den skriftlige beslutning viser, hvem der ejer den, og forhindrer, at risici bliver accepteret, uden at nogen har besluttet det.
Teknisk uddybning
ISO 31000:2018 kalder denne mulighed at bibeholde risikoen ved en informeret beslutning, og ordet "informeret" er hele pointen. ISO/IEC 27001:2022 bygger accept ind to steder: Punkt 6.1.2 a) 1) kræver, at kriterier for risikoaccept fastlægges, før der vurderes, og punkt 6.1.3 f) kræver, at risikoejerne godkender håndteringsplanen og accepterer de residuale risici. En accept, der ikke kan føres tilbage til de kriterier, eller som er underskrevet af en person uden myndighed over den berørte forretningsaktivitet, er en hyppig afvigelse ved audit. I NIST Risk Management Framework (SP 800-37 Rev. 2) svarer det til trinnet Authorize, hvor en ledende authorizing official udtrykkeligt accepterer den residuale risiko ved at drive et system.
En accept, der kan forsvares, indeholder risikobeskrivelsen, den aktuelle residuale vurdering, begrundelsen for ikke at håndtere yderligere (omkostning, teknisk umulighed, planlagt udfasning), eventuelle kompenserende kontroller, den navngivne ejer, godkenderens niveau og en udløbs- eller revurderingsdato. Modne organisationer knytter godkendelseskompetencen til vurderingen: En teamleder kan acceptere lave risici, en direktør middel, og kun direktionen eller bestyrelsen noget, der ligger uden for den dokumenterede appetit. Tidsbegrænsning er vigtig, fordi forudsætningerne ændrer sig; et styresystem uden support, der blev accepteret det ene år, kan det næste blive indgangen for en bredt udnyttet sårbarhed.
Accept har faste grænser. Den kan ikke fritage for lovkrav: En dataansvarlig kan ikke acceptere sig ud af pligten til at anmelde brud på persondatasikkerheden efter databeskyttelsesforordningens art. 33, og viser en konsekvensanalyse vedrørende databeskyttelse en høj residual risiko for de registrerede, kræver art. 36, stk. 1, forudgående høring af tilsynsmyndigheden, i Danmark Datatilsynet, frem for intern accept. Kontraktlige standarder fungerer på samme måde; i PCI DSS håndteres et krav, der ikke kan opfyldes, med dokumenterede kompenserende kontroller, ikke ved at acceptere hullet. Og risici, som primært bæres af andre, fx kunder eller registrerede, bør ikke accepteres alene ud fra organisationens egen cost-benefit-betragtning.
Anti-mønstret er den tavse accept: risici, der er kendte, aldrig håndteres og aldrig besluttes, ofte synlige som gamle fund i sårbarhedsscanninger eller revisionsrapporter. I praksis er de accepteret, men uden ejer, begrundelse eller revurderingsdato. Forskellen til undgåelse er, at accept beholder både aktiviteten og risikoen; forskellen til reduktion er, at der ikke tilføjes flere kontroller.
Hvad du bør lære først
Alt det, dette bygger på - grundlaget først.
Relationer
- En slags
- Risikohåndtering
- Forudsætter
- RisikoappetitResidual risiko
- Forveksl ikke med
- Risikoundgåelse
Kilder og videre læsning
Standarder og officielle tekster
- ISO/IEC 27005:2022 (8.2 - Risk treatment options)
Kursusmateriale
- Cyber Security Fast Track - Kursuskompendium, Modul 5 og Ordliste (Risikohåndtering)
Hvor dataene kommer fra
Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.
Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON
Test dig selv
Indlæser…