{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/risk-acceptance","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/risk-acceptance/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/risk-acceptance/"},"term":{"en":"Risk acceptance","da":"Risikoaccept"},"aka":{"en":["risk retention"],"da":["accept af risiko"]},"domain":["security"],"cluster":"risk-management","layer":"governance","status":"current","summary":{"en":"A deliberate, recorded decision to live with a risk instead of spending more to reduce it.","da":"En bevidst og dokumenteret beslutning om at leve med en risiko i stedet for at bruge flere ressourcer på at mindske den."},"body":{"formal":{"en":"The risk treatment option in which the organisation knowingly keeps a risk, because it is within the risk appetite or further controls would cost more than the harm; the decision is made and signed by someone with the authority to own the risk.","da":"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."},"plain":{"en":"Like driving on with a small chip at the edge of the windscreen - you note it, decide a new glass is not worth it yet, and look at it again after the winter.","da":"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."},"inPractice":{"en":"At a ferry company, the IT manager writes down that the test server has no backup, the director signs that this is acceptable for one year, and the item is put on the list for review.","da":"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."},"whyItMatters":{"en":"Accepting a risk is fine; ignoring it is not - the written decision shows who owns it and stops risks from being accepted without anyone deciding.","da":"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."}},"deepDive":{"en":"ISO 31000:2018 calls this option retaining the risk by informed decision, and the word \"informed\" is the whole point. ISO/IEC 27001:2022 builds acceptance into two places: clause 6.1.2 a) 1) requires risk acceptance criteria to be established before assessment, and clause 6.1.3 f) requires risk owners to approve the treatment plan and accept the residual risks. An acceptance that cannot be traced to those criteria, or that was signed by someone without authority over the affected business activity, is a common audit nonconformity. In the NIST Risk Management Framework (SP 800-37 Rev. 2) the equivalent is the Authorize step, in which a senior authorizing official explicitly accepts the residual risk of operating a system.\n\nA defensible acceptance record contains the risk statement, the current residual rating, the reason treatment is not pursued (cost, technical impossibility, planned decommissioning), any compensating controls, the named owner, the approver's level, and an expiry or review date. Mature organisations tie approval authority to rating: a team lead may accept low risks, a director medium, and only the executive board or management body anything outside the documented appetite. Time-boxing matters because the conditions behind the decision change; an unsupported operating system accepted in one year can become the entry point of a widely exploited vulnerability the next.\n\nAcceptance has hard limits. It cannot waive legal obligations: a GDPR controller cannot accept away its duty to notify a personal data breach under Art. 33, and where a data protection impact assessment shows a high residual risk to data subjects, Art. 36(1) requires prior consultation of the supervisory authority, in Denmark Datatilsynet, rather than internal acceptance. Contractual standards behave similarly; in PCI DSS a requirement that cannot be met is handled with documented compensating controls, not by accepting the gap. And risks borne mainly by others, such as customers or data subjects, should not be accepted purely on the organisation's own cost-benefit reasoning.\n\nThe anti-pattern is silent acceptance: risks that are known, never treated and never decided on, often visible as ageing findings in vulnerability scans or audit reports. Functionally they are accepted, but without an owner, rationale or review date. The distinction from avoidance is that acceptance keeps both the activity and its risk; the distinction from mitigation is that no further controls are added.","da":"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.\n\nEn 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.\n\nAccept 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.\n\nAnti-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."},"edges":[{"type":"requires","to":"security/risk-appetite","confidence":"high","strength":"normal"},{"type":"requires","to":"security/residual-risk","confidence":"high","strength":"normal"},{"type":"kind-of","to":"security/risk-treatment","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"security/risk-avoidance","why":{"en":"Acceptance keeps the activity and its risk; avoidance stops the activity so the risk disappears.","da":"Accept beholder aktiviteten og dens risiko; undgåelse stopper aktiviteten, så risikoen forsvinder."},"confidence":"high","strength":"primary"}],"depth":6,"sources":[{"title":"Cyber Security Fast Track - Kursuskompendium, Modul 5 og Ordliste (Risikohåndtering)","tier":"course-material"},{"title":"ISO/IEC 27005:2022 (8.2 - Risk treatment options)","tier":"standard"}],"draft":true}