--- title: "RiskOps" slug: riskops category: security term_status: ambiguous evidence_status: verified summary: "RiskOps, as this Atlas uses it, is the day-to-day operation of risk decisions: appetite and tolerances, a live risk register, quantification where it pays, and acceptance, treatment or transfer by the owner with the authority, with an expiry. The label has no standard meaning." audience: [Risk managers and chief risk officers, CISOs and security leaders, Engineering and product leaders who accept risk, Operational-risk and continuity teams, Beginners] last_verified: 2026-10-18 key_takeaways: - "\"RiskOps\" has no standard meaning: fraud platforms, cyber-risk vendors and healthcare and third-party risk tools use it for different, overlapping things. This page teaches operational and technology risk decisions; fraud operations are on FinCrimeOps." - "The core job is a decision: who may accept how much of which risk, until when. Appetite is set at the top, tolerances make it measurable, key risk indicators (KRIs) warn early, and the risk owner decides, not the analyst." - "Likelihood × impact on 1–5 scales is a communication device, not a measurement. Cox (2008) showed that risk matrices can rate quantitatively smaller risks higher; NIST IR 8286r1 (December 2025) prefers quantitative methods where data allow." - "Every acceptance needs an approver with authority for its rating, conditions, a KRI and an expiry. In the US federal Risk Management Framework, explicit risk acceptance by the authorizing official cannot be delegated." - "Transfer is partial. Insurance moves some money, not likelihood, customer trust or accountability; DORA keeps the ultimate responsibility for ICT risk with the management body." - "Compare responses on the tail as well as the average: in this page's simulation the cheapest option on average still broke the tolerance of at most a 1% yearly chance of a 2-million loss year." - "Supplier concentration and large change programmes are programme-level risks, as the CrowdStrike update (July 2024) and the TSB fine (December 2022) show." related: [complianceops, fincrimeops, vulnerabilityops, disasterrecoveryops, privacyops, modelops, procurementops, secops] --- ## What RiskOps is ### In 30 seconds **RiskOps** ("risk operations") is used in this Atlas for the **day-to-day operation of risk decisions**: leadership sets how much risk the organisation will take; that appetite becomes measurable tolerances; a live register records each risk with an owner; risks are analysed in money where feasible; and each is accepted, treated, transferred or avoided **by someone with the authority to do so**, with conditions, an indicator and an expiry date. **In one line: RiskOps turns "we accept the risk" from a sentence into a record with a name, a limit and a date.** ::: caution The label is ambiguous No standards body defines "RiskOps". Prominent uses are fraud and financial-crime products: SEON published a "Complete Guide to RiskOps" in January 2021, and in October 2021 Feedzai announced what it called the "World’s First RiskOps Platform".[^seon][^feedzai2021] **For fraud and anti-money-laundering (AML) operations, read [FinCrimeOps](../fincrimeops/)**; the [FAQ](#faq) summarises that meaning. This page's scope (operational and technology risk decisions) is an **editorial distinction** of this Atlas. ::: **For** risk managers, chief information security officers (CISOs), engineering and product leaders asked to "accept the risk", and continuity and operational-risk teams. ### At a glance | Item | Summary | |---|---| | Term status | **Ambiguous.** At least five different, overlapping published meanings; no standard, body or certification. The practice underneath is established risk management. | | In scope | Registers; appetite, tolerance and capacity; inherent and residual risk; treatment options; acceptance authority and expiry; KRIs; quantification; third-party and concentration risk; continuity at programme level. | | Out of scope | Fraud and AML → [FinCrimeOps](../fincrimeops/); control evidence → [ComplianceOps](../complianceops/); vulnerability scoring → [VulnerabilityOps](../vulnerabilityops/); ICT (information and communication technology) recovery → [DisasterRecoveryOps](../disasterrecoveryops/); model validation → [ModelOps](../modelops/). | | Prerequisites | None; basic statistics helps for Lab 2. | | Key outputs | Appetite and tolerance statements; a register with owners; a delegation policy; acceptance records with expiry; KRIs; quantified scenarios. | ### The problem RiskOps solves Every organisation already accepts risk, mostly silently. NIST's patching guide says so plainly: "By default, an organization accepts the risk posed by using its software."[^sp80040] The problem is four habits: | Without it | What happens | With it | |---|---|---| | Implicit acceptance | An engineer, not the accountable owner, decides by not acting | A named owner signs a recorded decision | | Permanent "temporary" exceptions | Compensating controls drift unchecked | Every acceptance expires and is re-tested | | Heat-map ranking | Different risks share one colour; budgets follow colours | Money and ranges where decisions matter | | Annual review | The register describes last year | KRIs and events trigger reassessment | The cost is documented: in December 2022 UK regulators fined TSB £48,650,000 for "operational risk management and governance failures, including management of outsourcing risks" in a 2018 IT migration ([use cases](#use-cases-and-scenarios)).[^tsb2022] ### What RiskOps is not - **Not a fraud platform or team** ([FinCrimeOps](../fincrimeops/)); such teams use the method on this page. - **Not compliance.** [ComplianceOps](../complianceops/) proves that controls operate; RiskOps decides which risks matter and how much to accept. **Editorial distinction:** no standard draws this line; both often share one governance, risk and compliance (GRC) tool. - **Not a department or a list.** The Committee of Sponsoring Organizations of the Treadway Commission (COSO) summarises its 2017 enterprise risk management (ERM) framework: "Enterprise risk management is not a function or department", "is more than a risk listing" and "is not a checklist".[^coso2017] - **Not the security operations centre** ([SOC Ops](../soc-ops/)). NetWitness uses "RiskOps" for continuous cyber-risk monitoring;[^netwitness] here monitoring is one input (KRIs), not the whole job. - **Not only negative.** COSO and the NIST Cybersecurity Framework (CSF) 2.0 (outcome GV.RM-07) count opportunities as risks;[^coso2017][^csf2] avoiding every risk is itself a costly decision. ## Where it comes from and where it sits ### Origins of the label The label is recent and contested; the discipline behind it is not. | Meaning | Who uses it (dated) | What "RiskOps" means there | |---|---|---| | Fraud and financial crime | SEON guide, January 2021; Feedzai platform, October 2021 and current[^seon][^feedzai2021][^feedzai] | Fraud, AML and compliance tooling | | Healthcare enterprise and third-party risk | Censinet, March 2021: "the first and only cloud-based integrated platform that consolidates enterprise risk management and operations capabilities", built on its third-party risk product[^censinet] | A vendor-risk and ERM product | | Cyber and IT risk | NetWitness glossary (2026); Netenrich glossary (undated); Qualys, October 2024: "Industry’s First Risk Operations Center (ROC)"[^netwitness][^netenrich][^qualys] | Continuous cyber-risk monitoring; exposures prioritised for remediation ([VulnerabilityOps](../vulnerabilityops/)) | | Third-party risk | Auditive blog (2025): "It's not a rebrand of GRC."[^auditive] | Risk checks inside procurement and onboarding | | Insurance underwriting, among others | Opsio knowledge base (2025), a general guide applying the label to underwriting, healthcare and cyber risk[^opsio] | Underwriting decisions in a portfolio view | Censinet and Feedzai in 2021 and Qualys in 2024 each claimed a "first", and SEON wrote about RiskOps before any of them: a marketing term without a founding text. SEON itself notes that "everyone’s idea of risk may be different – even within the same organization."[^seon] ### Glossary and mental model | Term | Meaning on this page | |---|---| | **Risk** | The "effect of uncertainty on objectives" (ISO's vocabulary, as reproduced by NIST);[^glossrisk] in practice a scenario, its likelihood and its consequences. | | **Exposure** | IR 8286r1's term for likelihood combined with impact, the "level of risk" of ISO 31000 and SP 800-30.[^ir8286] | | **Inherent, current, residual** | Inherent: "risk conditions that would exist without any organizational interventions"; current: partly addressed by management; residual: what remains after a response.[^ir8286] | | **Appetite** | "the amount and type of risk that an organization is willing to take in meeting its objectives", set by the most senior leadership.[^ir8286] | | **Tolerance** | "the organization or stakeholders’ readiness to bear the remaining risk after responding to or considering the risk to achieve its objectives"; narrower and measurable. SP 800-39 uses "risk tolerance" for both terms.[^ir8286] | | **Capacity, limits** | Financial Stability Board (FSB, 2013): capacity is the most risk an institution can assume before breaching constraints; limits allocate appetite to business lines.[^fsb2013] | | **Operational risk** | "the risk of loss resulting from inadequate or failed internal processes, people and systems or from external events, including, but not limited to, legal risk, model risk or information and communication technology (ICT) risk, but excluding strategic and reputational risk" (EU Capital Requirements Regulation as amended by Regulation (EU) 2024/1623, applicable from 1 January 2025).[^crr] | | **KRI** | "metrics used by organizations to provide an early signal of increasing risk exposures" (COSO); KPIs mostly report results that have already occurred.[^cosokri] | | **Risk owner** | "The designated party responsible and accountable for ensuring that the risk is maintained in accordance with enterprise requirements."[^ir8286] | **Mental model: appetite flows down, evidence flows up.** IR 8286r1's example turns the appetite "Email service shall be available during the large majority of a 24-hour period" into the tolerance "Email services shall not be interrupted for more than five minutes during core hours".[^ir8286] A KRI watches the tolerance; the owner decides inside it; anything outside goes up. ::: figure From appetite to a recorded decision ```mermaid flowchart TB CAP["Capacity: the most risk the organisation can bear"] --> APP["Appetite: board, broad"] APP --> TOL["Tolerance: measurable limit per objective"] TOL --> KRI["KRIs: warn before a limit is crossed"] REG["Register: scenario, owner, current exposure"] -- "each risk" --> DEC{"Inside tolerance?"} KRI --> DEC DEC -- "Yes" --> ACC["Accept: authorised owner, conditions, expiry"] DEC -- "No" --> TRT["Mitigate, transfer or avoid"] TRT --> REG ACC --> MON["Monitor KRIs and conditions"] MON --> REG classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 class CAP,APP,TOL neutral class KRI,REG,ACC,TRT,MON core class DEC decision ``` Text equivalent: Capacity bounds appetite; the board's broad appetite becomes measurable tolerances, which KRIs watch. Each registered risk is compared with tolerance: inside, an authorised owner accepts it with conditions and an expiry, and monitoring feeds the register; outside, it is mitigated, transferred or avoided and reassessed. ::: ### How RiskOps relates to other Ops Neighbours produce risks or act on decisions; this page owns the decision rules (an editorial split, not a standard). | Neighbour | Shared scope | Its focus | Handoff | |---|---|---|---| | [ComplianceOps](../complianceops/) | GRC tools, exceptions | Controls, evidence, audits | RiskOps sets who may accept what; ComplianceOps records exception and expiry | | [FinCrimeOps](../fincrimeops/) | The word "RiskOps" | Fraud, AML, sanctions | Name collision; link both ways | | [VulnerabilityOps](../vulnerabilityops/) | Remediation exceptions | Scoring, remediation flow | Exception requests in; approval rules out | | [SecOps](../secops/) | Owners, baseline exceptions | Running security controls | Acceptance stays with the owner | | [DisasterRecoveryOps](../disasterrecoveryops/) | Impact analysis, tolerances | ICT recovery; recovery time and point objectives (RTO, RPO) | Continuity programme here; recovery there | | [ProcurementOps](../procurementops/) | Supplier due diligence | Buying, contracts | Supplier risk method here | | [ModelOps](../modelops/) | Model risk | Validation, monitoring | Model risk appetite here | | [PrivacyOps](../privacyops/) | Impact assessments | Personal-data obligations | Privacy risks join the register | ::: figure Where RiskOps sits among its neighbours ```mermaid %%{init: {"flowchart": {"wrappingWidth": 150, "nodeSpacing": 20, "rankSpacing": 50}}}%% flowchart LR V["VulnerabilityOps: exceptions"] --> R["RiskOps: appetite, register, decisions"] P["ProcurementOps: suppliers"] --> R M["ModelOps: model risk"] --> R PV["PrivacyOps: assessments"] --> R F["FinCrimeOps: fraud, AML"] -. same name only .- R R --> C["ComplianceOps: exception register"] R --> DR["Recovery goals: DisasterRecoveryOps"] R --> S["SecOps: owners, windows"] classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 class R core class V,P,M,PV,C,DR,S neutral class F risk ``` Text equivalent: VulnerabilityOps, ProcurementOps, ModelOps and PrivacyOps feed risks into RiskOps (appetite, register, decisions); its decisions go to ComplianceOps, DisasterRecoveryOps and SecOps. FinCrimeOps shares only the name (dotted line). ::: ## Principles and operating model ### A proposed charter and principles No official RiskOps charter exists; this one is **this Atlas's proposal** (one-page version in the [templates](#templates)). **Mission:** make every material risk decision explicit, owned, informed and time-boxed. 1. **The owner decides; the analyst informs.** In the Three Lines Model of the Institute of Internal Auditors (IIA; Statement of Position, July 2026), management, the first line, "owns and manages risks"; second-line roles such as the risk function provide "specialized expertise, support, monitoring, and challenge"; internal audit, the third line, gives independent assurance.[^iia2026] Security and risk staff analyse and challenge; they do not accept. 2. **Authority is explicit.** The US federal Risk Management Framework concentrates it: "The explicit acceptance of risk is the responsibility of the authorizing official and cannot be delegated to other officials within the organization."[^sp80037] ISO/IEC 27001 has named risk owners approve the treatment plan and accept the residual risk.[^iso27001] Outside such regimes, this Atlas proposes authority banded by exposure (the [delegation policy](#operating-model-and-governance)). 3. **Every acceptance expires,** because "the validity and usefulness of any risk assessment is bounded in time" (SP 800-30).[^sp80030] 4. **Measure what you accept.** Accepted risks "need to be measured to ensure that they remain within established risk tolerance parameters" (IR 8286r1).[^ir8286] 5. **Matrices to talk, money and ranges to allocate** ([methods](#likelihood-impact-and-its-limits)). 6. **Transfer is partial** ([treatment options](#treatment-options)). 7. **Responses have side effects:** "Risk responses themselves may introduce new risks."[^ir8286] **Non-goals:** zero risk; one score for everything; a tool that replaces judgement. **Accepted trade-off:** slower, documented decisions for the few risks that matter, fast delegated ones for the rest. ### Building blocks | Block | What it contains | Typical owner | |---|---|---| | Appetite and tolerance statements | Broad appetite per objective; measurable tolerances | Board; risk committee | | Method and taxonomy | Written scales or quantification rules; scenarios naming threat, asset, method and impact, as NIST recommends[^ir8286] | Risk function | | Register | Owner, exposure, response, status, KRIs, acceptance per risk | Risk function (system); owners (content) | | Delegation of authority | Who may accept which band, for how long | Risk committee | | KRIs and treatment plans | Indicators with data owners; actions with cost and due date | Risk and control owners | | Supplier map and continuity programme | Suppliers by criticality; impact analysis, plans, crisis team | Procurement; continuity manager | ### Roles, ownership and RACI | Activity | Board or committee | Risk owner and line management | Risk function (2nd line) | Control owner | Internal audit | |---|---|---|---|---|---| | Set appetite and capacity | **A** (board) | C | C | I | I | | Set tolerances and delegation bands | **A** (committee) | C | R | I | I | | Maintain method and register | I | C | **A**/R | C | I | | Assess a risk | I | **A** | R | C | I | | Accept a low or medium risk | I | **A** (owner; director for medium) | C | I | I | | Accept a high risk | **A** (committee) | R | C | I | I | | Implement a treatment; watch KRIs | I | **A** | R (KRIs) | R (treatment) | I | | Independent assurance | I | I | C | I | **A**/R | R = responsible, A = accountable, C = consulted, I = informed; an Atlas proposal. Outsourcing does not move accountability (the IIA statement has a section titled "Outsourcing Does Not Change Accountability").[^iia2026] Regulation can fix the top: the EU Digital Operational Resilience Act (DORA) requires the management body of an in-scope EU financial entity to "bear the ultimate responsibility for managing the financial entity’s ICT risk" and to set its ICT risk tolerance (not legal advice).[^dora] ### Lifecycle NIST SP 800-39's four components (frame, assess, respond, monitor)[^sp80039] map onto days: - **Day 0, frame:** appetite and tolerances; taxonomy; scales or quantification rules; delegation bands; register design. - **Day 1, populate:** the top 20–30 risks with owners and current exposure; first decisions; KRIs for every accepted risk. - **Day 2, operate:** intake from changes, incidents, loss events, suppliers and exception requests; sweeps; quarterly committee; an "annual review of risks to archive risks" (IR 8286r1).[^ir8286] ### Operating model and governance **Delegation-of-authority policy (Atlas proposal),** on residual exposure scored with written 1–5 scales (the score only sorts; see [methods](#likelihood-impact-and-its-limits)): | Band | Residual score | Who may accept | Longest acceptance | Review at least | |---|---|---|---|---| | Low | 1–4 | Risk owner | 365 days | Yearly | | Medium | 5–9 | Director of the owning area | 180 days | Every 6 months | | High | 10–16 | Risk committee | 90 days | Quarterly | | Critical | 20–25 | No one: treat or avoid; the board decides which | – | Monthly | For quantified risks, define the bands in money too (for example on the 99th-percentile annual cost, P99 in [Lab 2](#lab-2-intermediate-compare-responses-with-a-monte-carlo-simulation)), so top-band decisions do not rest on ordinal scores. **Cadence (Atlas proposal):** automated weekly sweep of expiries, overdue treatments and KRI breaches; monthly owner review; quarterly committee with a portfolio view; yearly appetite review. **Escalate on** a KRI breach, an expired acceptance, a treatment 30 days late, a loss above tolerance, or a new regulation or major supplier change. ## Architecture and workflow ### Reference architecture A process architecture, not a technology stack: the register is the system of record; everything else feeds or reads it. ::: figure Process architecture of a RiskOps function ```mermaid %%{init: {"flowchart": {"wrappingWidth": 110, "nodeSpacing": 18, "rankSpacing": 36}}}%% flowchart TB B["Board: appetite, capacity"] --> RC["Risk committee: tolerances, high-band decisions"] I["Intake: change, incident, supplier, exception"] --> A["Assess: ranges, money where feasible"] A --> REG["Risk register: system of record"] RC --> D{"Decision by an authorised owner"} REG --> D D --> T["Treatment plan and due date"] T --> REG K["KRI feeds and expiry sweep"] --> REG REG -- "portfolio report" --> RC AUD["Internal audit: independent assurance"] -.-> REG classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 class B,RC,AUD neutral class I,A,REG,T,K core class D decision ``` Text equivalent: The board sets appetite; the risk committee sets tolerances and takes high-band decisions. Intake feeds assessment, which feeds the register; an authorised owner decides; treatments, KRI feeds and the expiry sweep update the register, which reports to the committee. Internal audit gives independent assurance (dotted line). ::: | Component | Design choice and trade-off | |---|---| | Intake | One door avoids shadow registers but needs triage capacity | | Register | Spreadsheet (cheap, fragile), GRC suite (workflow, lock-in) or register as code (reviewable, needs engineers) | | Decision | Automate the authority and expiry check, never the judgement | | KRI feeds and reporting | Values pulled from systems, each with a data owner; report movement and breaches | **Trust boundary.** The register lists unpatched systems and weak suppliers, an attacker's shopping list: restrict access and keep its history immutable. ### End-to-end workflow The most common transaction is a request to accept a risk, often a vulnerability exception from [VulnerabilityOps](../vulnerabilityops/). **Happy path:** a legacy billing host cannot take a vendor patch; it is isolated behind a proxy; the residual score is 8 (medium); a director signs for 90 days with a KRI ("days since the isolation rule was verified", limit 7); [ComplianceOps](../complianceops/) logs it. **Exception path:** a firewall change removes the rule and the KRI breaches. CERT/CC's Stakeholder-Specific Vulnerability Categorization (SSVC) guidance warns that such a mitigation "is only valid until someone changes the rule".[^ssvc] The acceptance is suspended and the [runbook](#worked-runbook-an-accepted-risk-breaches-its-tolerance) starts. ::: figure Risk acceptance with authority, conditions and expiry ```mermaid %%{init: {"flowchart": {"wrappingWidth": 130, "nodeSpacing": 24, "rankSpacing": 36}}}%% flowchart TB RQ["Acceptance request"] --> SC["Score residual risk; find band"] SC --> Q1{"Critical band?"} Q1 -- "Yes" --> NO["Treat, avoid or go to the board"] Q1 -- "No" --> Q2{"Approver has authority?"} Q2 -- "No" --> UP["Route to the right approver"] UP --> Q2 Q2 -- "Yes" --> Q3{"Conditions, KRI, expiry in policy?"} Q3 -- "No" --> FIX["Revise the request"] FIX --> SC Q3 -- "Yes" --> REC["Record; ComplianceOps logs it"] REC --> MON["Monitor KRI and conditions"] MON --> Q4{"Breach or expiry?"} Q4 -- "Yes" --> SC Q4 -- "No" --> MON MON -- "Risk retired" --> ARC["Close and archive"] classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 class RQ,SC,UP,FIX,REC,MON,ARC core class Q1,Q2,Q3,Q4 decision class NO risk ``` Text equivalent: A critical-band request cannot be accepted and goes to treatment, avoidance or the board. Otherwise it needs an approver with authority for its band and conditions, KRI and expiry within policy, or it is revised. An approved acceptance is recorded (ComplianceOps logs it) and monitored: a breach or expiry sends it back to scoring; otherwise monitoring continues until the risk is retired and archived. ::: ## Methods, frameworks and treatment ### Likelihood × impact and its limits NIST describes risk as typically a function of an event's adverse impact and its likelihood.[^sp80030] Many organisations turn that into a 5×5 matrix: score each from 1 to 5, multiply, colour the cell. The matrix is good at **getting people to discuss the same scenario** and bad at **allocating money**. Louis Anthony Cox Jr. showed in 2008 that typical risk matrices "can correctly and unambiguously compare only a small fraction (e.g., less than 10%) of randomly selected pairs of hazards", "can mistakenly assign higher qualitative ratings to quantitatively smaller risks", and, when frequency and severity are negatively correlated, can be "worse than useless".[^cox2008] ::: example Illustrative scenario: two risks, one colour Scales: likelihood 5 = several times a year, 1 = less than once in 20 years; impact 1 = under 10,000, 5 = over 5 million (currency units). **Risk A**, stolen laptops: about 12 a year at 3,000 each (L5 × I1 = **5**), an expected 36,000 a year. **Risk B**, fire in the single data centre: about once in 50 years at 40 million (L1 × I5 = **5**), an expected 800,000 a year, and one event could exceed what the organisation can survive. Same score; a 22-fold difference in expected loss and a different tail. ::: **Rules that keep a matrix honest:** define every score with numbers; never treat ordinal scores as money; score the worst *credible* consequence and the likelihood of *that* consequence, not of the event; record the range behind each score; triage with it, do not budget with it. ### Quantifying risk in money **Open FAIR** (Factor Analysis of Information Risk; The Open Group's Risk Taxonomy O-RT 3.1 and Risk Analysis O-RA 2.1, both updated in May 2025) is an open standard for analysing information risk in money.[^ort][^ora] In FAIR, risk is "the probable frequency and magnitude of future loss", and "Loss Event Frequency = Threat Event Frequency x Vulnerability", vulnerability (or susceptibility) being estimated as the fraction of threat events that become loss events.[^fair2021] NIST IR 8286r1 states: "Quantitative methods are preferred, given the wide variety of data available; however, quantitative methods may not always be possible in certain contexts." Its example loss exceedance curve shows an "approximately 38% chance of losing $5 million or more each year".[^ir8286] **A working method** (this Atlas's simplified version of the calibrated-estimate Monte Carlo approach in Hubbard and Seiersen's *How to Measure Anything in Cybersecurity Risk*, whose companion files include a Monte Carlo model and calibration tests;[^htma] pyfair automates FAIR simulations[^pyfair]): estimate 90% ranges for how often a scenario happens and for the loss per event; simulate many years; read off the mean annual loss and the exceedance probabilities; rerun the same years for each response ([Lab 2](#lab-2-intermediate-compare-responses-with-a-monte-carlo-simulation); the lognormal shape is this page's assumption). **Do not quantify** when no decision depends on the answer, when law prescribes the response, for long tails of small risks, or when nobody will own the estimates. A number without ranges and sources is a matrix in disguise. ### Frameworks compared | Framework | What it is | Status | Use it for | |---|---|---|---| | ISO 31000:2018 | "Risk management — Guidelines"; "Current, Under Review" as of October 2026[^iso31000] | Voluntary | Shared vocabulary | | ISO/IEC 27001:2022, 27005:2022 | Security management system: risk acceptance criteria and a named owner per risk (6.1.2); owners approve treatment and accept residual risk (6.1.3); 27005 is the guidance[^iso27001][^iso27005] | Certifiable (27001); guidance (27005) | Acceptance authority outside US federal systems | | COSO ERM (June 2017) | Five components, twenty principles linking risk to strategy[^coso2017] | Voluntary | Board-level ERM | | NIST SP 800-39, 800-30, 800-37, IR 8286r1 | Programme, assessment, the seven-step RMF, registers rolled up to ERM[^sp80039][^sp80030][^sp80037][^ir8286] | SP 800-37, 800-39, 800-30: US federal systems; IR 8286r1: federal and non-federal | Method, acceptance authority, registers | | NIST CSF 2.0, GOVERN | Outcomes such as GV.RM-02, "Risk appetite and risk tolerance statements are established, communicated, and maintained"[^csf2] | Voluntary | Completeness check | | Open FAIR (O-RT 3.1, O-RA 2.1) | Taxonomy and analysis of loss in money[^ort][^ora] | Voluntary standard | Quantification | | FSB principles (2013) | Appetite, capacity, limits for financial institutions[^fsb2013] | Supervisory | Appetite vocabulary | | DORA, (EU) 2022/2554 | ICT risk framework, tolerance, third-party register, continuity[^dora] | Binding on in-scope EU financial entities since 17 January 2025 | ICT risk governance (not legal advice) | ### Treatment options NIST IR 8286r1 names four responses (accept, transfer, mitigate, avoid), noting "some variance among the terms used by risk management frameworks"; SP 800-39 separates transfer, which shifts "the entire risk responsibility or liability", from **sharing**, which shifts "a portion", and allows combinations.[^ir8286][^sp80039] The UK Orange Book (which references ISO 31000:2018) adds taking more risk for an opportunity and retaining risk "by informed decision".[^orange] | Response | What it does | The catch | |---|---|---| | **Accept** | Bear the risk within tolerance; monitor | Only valid with authority, a KRI and an expiry | | **Mitigate** | Controls reduce likelihood or consequence | Controls cost money and can create new risks[^ir8286] | | **Transfer or share** | Insurance, contracts, outsourcing move part of the consequence | IR 8286r1: only "some of the financial consequences may be transferrable";[^ir8286] SP 800-39: transfer changes neither the likelihood nor the harm to operations, assets and people[^sp80039] | | **Avoid** | Stop or redesign the activity | "The cost of the lost opportunity associated with such a decision should be considered as well"[^ir8286] | Transfer has further limits: customer trust cannot be transferred (IR 8286r1);[^ir8286] "the caps on the insurance may be too low to act as a mitigation" (SSVC);[^ssvc] and public-sector bodies generally cannot buy insurance to transfer risk because law or policy sets their liability (SP 800-39).[^sp80039] An acceptance can come with a **risk reserve**, money or hours set aside in case the risk is triggered.[^ir8286] ## Practices, programmes and tools ### Core practices and playbooks | Practice | Trigger | Owner | Output | Verification | |---|---|---|---|---| | Appetite and tolerances | Yearly; strategy change | Board, committee | One page per objective | Each tolerance has a KRI | | Intake and triage | New system, change, supplier, incident, exception | Risk function | Register entry or "not material" note | Triage within 5 working days | | Scenario assessment | Entry above the triage line | Owner with analyst | Scenario, ranges, exposure | Second-line challenge recorded | | Acceptance with expiry | Residual risk inside tolerance | Authorised approver | Record, KRI, expiry | Automated authority and expiry check | | Treatment tracking | Residual risk outside tolerance | Control owner | Plan, cost, due date | Closed with evidence | | KRI design | Accepted or high risks | Risk owner | Indicator, limit, source | Feed tested; yearly breach drill | ### Operational-risk toolkit: loss events and self-assessment The Basel Committee's operational-risk principles (revised March 2021) name example tools: event management, event data, self-assessments, control monitoring, metrics, scenario analysis and benchmarking.[^bcbs2021] **Loss-event data.** Record material operational events, not only losses: the dataset "typically includes internal loss data, near misses, and, when feasible, external operational loss event data", classified by one taxonomy, with the dates of occurrence, discovery and accounting.[^bcbs2021] EU banks with a business indicator of EUR 750 million or more must keep such a loss data set and count net losses of EUR 20,000 or more in their annual operational-risk loss; supervisors may waive both for banks with an indicator of up to EUR 1 billion where they would be unduly burdensome (CRR Articles 316–319 as amended; as of October 2026, not legal advice).[^crr] For other organisations, an Atlas default: a threshold low enough that teams log near misses, a data owner, the register risk each event belongs to, and a monthly reconciliation with incident tickets and finance write-offs. Events without a register risk feed the [surprise rate](#metrics-and-kpis); repeated near misses reopen the risk's assessment. **Risk and control self-assessment (RCSA).** Line managers rate inherent risk, control effectiveness and residual risk for their own processes, in enough detail "to enable an independent reviewer to determine how the bank reached its ratings".[^bcbs2021] An RCSA is the owner's judgement, challenged by the risk function; it is not a control test. Testing whether a control operated, with evidence, is [ComplianceOps](../complianceops/) work, and a failed test should overrule an optimistic self-rating. Comparing actual losses with self-assessments shows whether the RCSA works, a use the Basel text names.[^bcbs2021] ### Third-party and concentration risk CSF 2.0 expects that "Suppliers are known and prioritized by criticality" (GV.SC-04).[^csf2] The US banking agencies' 2023 guidance organises third-party risk around a life cycle: planning, due diligence and selection, contract negotiation, ongoing monitoring and termination.[^tprm2023] **As of October 2026** the agencies have proposed to rescind and replace it (comments due 16 November 2026), saying it "frequently has been interpreted in an overly broad manner" while remaining "a relevant tool".[^tprm2026] DORA requires in-scope EU financial entities to keep a register of their ICT third-party contracts (Article 28(3)).[^dora] **Concentration is the part registers miss.** Supplier risks are scored one supplier at a time, as if failures were independent; the CrowdStrike update of July 2024 showed the opposite ([Case 2](#case-2-concentration-on-one-software-supplier-sourced)).[^crowdstrike] Add **concentration scenarios** (one supplier, region or identity provider failing everywhere at once) and track the share of critical services that depend on each. Onboarding mechanics belong to [ProcurementOps](../procurementops/), contract clauses to [LegalOps](../legalops/). ### Business continuity and crisis management Continuity is a programme-level response: deciding how much disruption each service can bear and preparing to stay within it. NIST SP 800-34 describes the business continuity plan as focusing "on sustaining an organization’s mission/business processes during and after a disruption", distinct from disaster recovery.[^sp80034] | Element | What RiskOps owns | Reference | |---|---|---| | Business impact analysis | Which services matter, how fast losses grow | DORA Art. 11(5); NIST IR 8286D extends it to any loss[^dora][^ir8286d] | | Impact tolerances | Maximum tolerable disruption per important service | UK Financial Conduct Authority (FCA) PS21/3: set by 31 March 2022, met by 31 March 2025[^fcaps213] | | Management system | Policy, objectives, review | ISO 22301:2019 with Amendment 1:2024[^iso22301] | | Crisis management | Crisis team, decision rules, communications | ISO 22361:2022;[^iso22361] DORA Art. 11(7) crisis function[^dora] | Exercise results feed the register. Technical recovery (RTO, RPO, failover, restores) belongs to [DisasterRecoveryOps](../disasterrecoveryops/) and [BackupOps](../backupops/); cyber incidents to [ResponseOps](../responseops/). ### Tooling landscape | Category | Jobs | Verified examples (as of October 2026) | Watch-outs | |---|---|---|---| | Spreadsheet register | Early stage | Any spreadsheet | No workflow or history | | GRC or integrated risk suites | Register, workflow, controls, vendor reviews | Named in [ComplianceOps](../complianceops/) | Lock-in; risk becomes a checklist | | Open-source GRC | Same, self-hosted | SimpleRisk;[^simplerisk] CISO Assistant community edition (risk, third-party risk, business impact analysis)[^cisoassistant] | You operate it; check licences | | Quantification | Monte Carlo, FAIR models | pyfair (MIT licence, 0.1a13, alpha);[^pyfair] notebooks; [Lab 2](#hands-on-labs) | Inputs dominate outputs | | Fraud "RiskOps platforms" | Fraud and AML decisions | Feedzai[^feedzai] | Different discipline: [FinCrimeOps](../fincrimeops/) | Select on: full export with history; configurable authority and expiry rules; KRI integration by API; access control on sensitive entries; five-year cost of ownership. ### Automation and AI **Automate the bookkeeping, not the decision:** KRI collection, authority and expiry checks, chasing overdue treatments, reports (as in the [reference implementation](#reference-implementation)). **AI as a risk source:** NIST's AI RMF 1.0 (January 2023, voluntary) and its generative-AI profile (July 2024) help identify AI risks;[^airmf] model validation belongs to [ModelOps](../modelops/), where three US banking agencies revised their model risk guidance on 17 April 2026.[^mrm2026] **AI as a risk tool:** language models may draft scenarios, never frequency or loss estimates, and a person signs every decision; Feedzai's "agentic AI-powered platform" is a marketing claim until independently tested.[^feedzai] ## RiskOps in practice ### Reference implementation The core artefact is a **register that checks itself against its own policy**: the [delegation bands](#operating-model-and-governance) as data, and a checker for wrong approvers, acceptances with no record, expired or over-long acceptances, "accepted" critical risks, overdue treatments, missing owners and KRI breaches. **Assumptions (illustrative):** six risks; the date fixed in the file so output is repeatable. A spreadsheet or GRC tool can hold the same fields; what matters is that the rules are explicit and testable. _Example status: JSON syntax-checked; verified by execution together with the script below (Python 3.8.10, 2026-10-17)._ ```json { "as_of": "2026-10-17", "policy": { "bands": [ {"band": "low", "max_score": 4, "approver": "risk-owner", "max_days": 365}, {"band": "medium", "max_score": 9, "approver": "director", "max_days": 180}, {"band": "high", "max_score": 16, "approver": "risk-committee", "max_days": 90}, {"band": "critical", "max_score": 25, "approver": "none", "max_days": 0} ], "review_days": {"low": 365, "medium": 180, "high": 90, "critical": 30} }, "people": { "lena.ortiz": ["risk-owner"], "sam.reed": ["risk-owner", "director"], "risk-committee": ["risk-owner", "director", "risk-committee"] }, "risks": [ { "id": "R-001", "title": "Legacy billing host cannot take the vendor patch", "owner": "lena.ortiz", "inherent": [4, 4], "residual": [2, 4], "response": "accept", "last_review": "2026-09-01", "acceptance": {"approved_by": "lena.ortiz", "approved_on": "2026-09-01", "expires_on": "2026-12-01", "condition": "host isolated behind proxy; rule re-checked weekly"}, "kris": [{"name": "days since isolation rule verified", "value": 4, "limit": 7}] }, { "id": "R-002", "title": "Single payment processor for card checkout", "owner": "sam.reed", "inherent": [3, 5], "residual": [3, 3], "response": "accept", "last_review": "2026-04-20", "acceptance": {"approved_by": "sam.reed", "approved_on": "2026-04-20", "expires_on": "2026-10-01", "condition": "second processor contract signed by Q4"}, "kris": [{"name": "processor incidents in 90 days", "value": 3, "limit": 2}] }, { "id": "R-003", "title": "Ransomware on the order platform", "owner": "sam.reed", "inherent": [3, 5], "residual": [2, 5], "response": "mitigate", "last_review": "2026-08-15", "treatment_due": "2026-11-30", "kris": [{"name": "servers without EDR agent (%)", "value": 1.5, "limit": 2}] }, { "id": "R-004", "title": "Cloud region outage stops all customer services", "owner": "", "inherent": [2, 5], "residual": [2, 5], "response": "accept", "last_review": "2025-11-02", "acceptance": {"approved_by": "lena.ortiz", "approved_on": "2025-11-02", "expires_on": "2026-11-02", "condition": "none recorded"}, "kris": [] }, { "id": "R-005", "title": "Customer data exposed through a misconfigured bucket", "owner": "lena.ortiz", "inherent": [4, 5], "residual": [4, 5], "response": "accept", "last_review": "2026-10-10", "acceptance": {"approved_by": "risk-committee", "approved_on": "2026-10-10", "expires_on": "2027-01-08", "condition": "manual review monthly"}, "kris": [] }, { "id": "R-006", "title": "Partner API still accepts TLS 1.0", "owner": "lena.ortiz", "inherent": [3, 3], "residual": [3, 3], "response": "accept", "last_review": "2026-07-14", "kris": [] } ] } ``` _Example status: verified by execution (Python 3.8.10, 2026-10-17); standard library only; the output below is the actual output._ ```python """Check a risk register against its own acceptance policy (an Atlas example). Usage: python3 check_register.py risk-register.json Standard library only. For each risk: residual score (likelihood x impact on 1-5 scales), band, and findings. BLOCK findings make the exit code 1. """ import json import sys from datetime import date ACCEPTED_SOON_DAYS = 30 RECORD_FIELDS = ("approved_by", "approved_on", "expires_on") def day(text): return date.fromisoformat(text) def band_for(score, bands): for b in bands: if score <= b["max_score"]: return b raise ValueError(f"score {score} above every band") def check_acceptance(acc, band, people, as_of): out = [] missing = [f for f in RECORD_FIELDS if not acc.get(f)] if band["approver"] == "none": out.append(("BLOCK", f"{band['band']} risk cannot be accepted: " "treat, avoid or escalate to the board")) elif missing: out.append(("BLOCK", "accepted without a record: " f"missing {', '.join(missing)}")) else: if band["approver"] not in people.get(acc["approved_by"], []): out.append(("BLOCK", f"approved by {acc['approved_by']} but a " f"{band['band']} risk needs {band['approver']}")) length = (day(acc["expires_on"]) - day(acc["approved_on"])).days if length < 0: out.append(("BLOCK", "acceptance expires before its approval date")) elif length > band["max_days"]: out.append(("BLOCK", f"acceptance runs {length} days; " f"policy maximum is {band['max_days']}")) if acc.get("expires_on"): left = (day(acc["expires_on"]) - as_of).days if left < 0: out.append(("BLOCK", f"acceptance expired {-left} days ago")) elif left <= ACCEPTED_SOON_DAYS: out.append(("WARN", f"acceptance expires in {left} days")) return out def check(risk, policy, people, as_of): out = [] l_res, i_res = risk["residual"] l_inh, i_inh = risk["inherent"] band = band_for(l_res * i_res, policy["bands"]) if not risk.get("owner"): out.append(("BLOCK", "no named owner")) if l_res > l_inh or i_res > i_inh: out.append(("WARN", "residual above inherent: check the data")) if risk["response"] == "accept": acc = risk.get("acceptance") or {} out += check_acceptance(acc, band, people, as_of) if not risk.get("kris"): out.append(("WARN", "accepted without a KRI to show it stays in tolerance")) elif risk["response"] == "mitigate": due = risk.get("treatment_due") late = (as_of - day(due)).days if due else 0 if not due: out.append(("BLOCK", "mitigation without a treatment due date")) elif late > 0: out.append(("BLOCK", f"treatment overdue by {late} days")) age = (as_of - day(risk["last_review"])).days if age > policy["review_days"][band["band"]]: out.append(("WARN", f"last review {age} days ago")) for k in risk.get("kris", []): if k["value"] > k["limit"]: out.append(("BLOCK", f"KRI breach: {k['name']} = {k['value']}" f" (limit {k['limit']})")) return band["band"], l_res * i_res, out def main(path): with open(path, encoding="utf-8") as fh: reg = json.load(fh) as_of = day(reg["as_of"]) blocks = 0 print(f"Risk register check as of {as_of}") for risk in reg["risks"]: band, score, findings = check(risk, reg["policy"], reg["people"], as_of) print(f"{risk['id']} {band:<8} residual {score:>2} {risk['response']:<8}" f" {risk['title']}") for level, text in findings: print(f" {level:<5} {text}") blocks += sum(1 for level, _ in findings if level == "BLOCK") print(f"{len(reg['risks'])} risks, {blocks} blocking findings") return 1 if blocks else 0 if __name__ == "__main__": if len(sys.argv) != 2: sys.exit("usage: python3 check_register.py ") sys.exit(main(sys.argv[1])) ``` ```text $ python3 check_register.py risk-register.json; echo "exit=$?" Risk register check as of 2026-10-17 R-001 medium residual 8 accept Legacy billing host cannot take the vendor patch BLOCK approved by lena.ortiz but a medium risk needs director R-002 medium residual 9 accept Single payment processor for card checkout BLOCK acceptance expired 16 days ago BLOCK KRI breach: processor incidents in 90 days = 3 (limit 2) R-003 high residual 10 mitigate Ransomware on the order platform R-004 high residual 10 accept Cloud region outage stops all customer services BLOCK no named owner BLOCK approved by lena.ortiz but a high risk needs risk-committee BLOCK acceptance runs 365 days; policy maximum is 90 WARN acceptance expires in 16 days WARN accepted without a KRI to show it stays in tolerance WARN last review 349 days ago R-005 critical residual 20 accept Customer data exposed through a misconfigured bucket BLOCK critical risk cannot be accepted: treat, avoid or escalate to the board WARN accepted without a KRI to show it stays in tolerance R-006 medium residual 9 accept Partner API still accepts TLS 1.0 BLOCK accepted without a record: missing approved_by, approved_on, expires_on WARN accepted without a KRI to show it stays in tolerance 6 risks, 8 blocking findings exit=1 ``` **How to read it.** R-003 is clean. R-001 has a sound control but the wrong signature. R-002 is the classic silent failure: the acceptance expired *and* its KRI shows the condition behind it no longer holds. R-004 is an undocumented "we accept cloud-region risk" a year later. R-005 is critical: no one may accept it, so the board chooses treatment (recorded with a due date, as in Lab 1 step 5) or avoidance. R-006 is the most common entry in real registers: "accepted" with no record at all. Whether the scores are right is for second-line challenge, not the script. ### Hands-on labs #### Lab 1 (beginner): run and repair the register **Objective:** read a register as a set of decisions and repair it. **Prerequisites:** Python 3.7 or later (for `date.fromisoformat`); no account, cost or risk; about 45 minutes. 1. Save the [reference](#reference-implementation) register as `risk-register.json` and the checker as `check_register.py`. 2. Run `python3 check_register.py risk-register.json; echo $?`. 3. R-001: change `approved_by` to `sam.reed` (a director) and run again. 4. R-004: set `owner` to `sam.reed` and `last_review` to `2026-10-17`; set the acceptance to `approved_by` `risk-committee`, `approved_on` `2026-10-17`, `expires_on` `2027-01-15`; add the KRI `{"name": "months since last region failover test", "value": 2, "limit": 6}`. Run again. 5. R-005: change `response` to `mitigate`, delete its `acceptance` block and add `"treatment_due": "2026-10-31"`. Run again. 6. R-006: add an `acceptance` block approved by `sam.reed` on `2026-10-17`, expiring `2027-04-15` (180 days, the medium maximum), with a condition of your choice, and the KRI `{"name": "partner calls on TLS 1.0 (%)", "value": 3, "limit": 5}`. Run again. 7. Decide R-002 yourself: renew (who signs, with which new condition?) or treat (what, by when?). **Expected output** (checked by execution). Step 2: the reference output, exit code 1, 8 blocking findings. Step 3: R-001 has no findings; 7 blocking. Step 4: R-004 has no findings; 4 blocking. Step 5: 3 blocking. Step 6: only R-002's two findings remain; exit code still 1. **Validation:** every remaining finding is a decision for a person, not a data error. **Troubleshooting:** `JSONDecodeError`: usually a trailing comma; `Invalid isoformat string`: a date not written as `YYYY-MM-DD`; `KeyError`: a missing required field such as `residual`. **Teardown:** delete the files, or keep them as your first register. #### Lab 2 (intermediate): compare responses with a Monte Carlo simulation **Objective:** compare accept, mitigate, transfer and both on the average **and** the tail. **Prerequisites:** Python 3.6 or later; no cost or risk; about an hour. **Inputs (illustrative, not benchmarks):** ransomware halts an order platform 0.05–0.4 times a year, costing 0.3–6 million per event (90% ranges); a control costs 180,000 a year, stops 40% of events and halves the loss of the rest; insurance costs 140,000 a year with a 500,000 deductible per event and a 3 million annual limit. Tolerance (a loss-exceedance limit): at most a 1% chance of a year costing more than 2 million. Banks often state appetite itself in such numbers, as the FSB's principles expect;[^fsb2013] this page keeps "appetite" for the board's broad statement. _Example status: verified by execution (Python 3.8.10, 2026-10-17); standard library only; fixed seed, so the output below is reproducible on that version._ ```python """Monte Carlo comparison of risk responses for one scenario (illustrative inputs). Usage: python3 quantify.py [years] Standard library only. Frequency and loss per event come from 90% confidence ranges (lognormal). All options share the same simulated years. """ import math import random import sys Z90 = 1.6449 # a 90% interval spans +/- 1.6449 standard deviations SEED = 20261017 SCENARIO = "Ransomware halts the order platform" EVENTS_PER_YEAR = (0.05, 0.40) # 90% range for the annual rate LOSS_PER_EVENT = (300_000, 6_000_000) # 90% range, currency units CONTROL = {"cost": 180_000, "keeps_events": 0.6, "loss_factor": 0.5} POLICY = {"premium": 140_000, "deductible": 500_000, "limit": 3_000_000} THRESHOLD = 2_000_000 # tolerance: a year costing more may occur in at most 1% of years def lognormal(rng, low, high): mu = (math.log(low) + math.log(high)) / 2 sigma = (math.log(high) - math.log(low)) / (2 * Z90) return rng.lognormvariate(mu, sigma) def poisson(rng, lam): limit, k, p = math.exp(-lam), 0, 1.0 while True: p *= rng.random() if p <= limit: return k k += 1 def simulate_year(rng): """Return a list of (base loss, survives the control?) for one year.""" lam = lognormal(rng, *EVENTS_PER_YEAR) return [(lognormal(rng, *LOSS_PER_EVENT), rng.random() < CONTROL["keeps_events"]) for _ in range(poisson(rng, lam))] def year_cost(events, control, insured): spend, retained, paid = 0.0, 0.0, 0.0 if control: spend += CONTROL["cost"] events = [(loss * CONTROL["loss_factor"], True) for loss, keep in events if keep] if insured: spend += POLICY["premium"] for loss, _ in events: claim = max(0.0, loss - POLICY["deductible"]) if insured else 0.0 claim = min(claim, POLICY["limit"] - paid) paid += claim retained += loss - claim return spend + retained def pct(sorted_values, q): return sorted_values[min(len(sorted_values) - 1, int(q * len(sorted_values)))] def main(years): rng = random.Random(SEED) sims = [simulate_year(rng) for _ in range(years)] print(f"{SCENARIO}: {years} simulated years, seed {SEED}") print(f"{'option':<20}{'mean/yr':>11}{'P(>2M)':>8}{'P95':>12}{'P99':>12}") options = [("accept (baseline)", False, False), ("mitigate (control)", True, False), ("transfer (insure)", False, True), ("control + insure", True, True)] for name, control, insured in options: costs = sorted(year_cost(ev, control, insured) for ev in sims) mean = sum(costs) / years breach = sum(1 for c in costs if c > THRESHOLD) / years print(f"{name:<20}{mean:>11,.0f}{breach:>8.1%}" f"{pct(costs, 0.95):>12,.0f}{pct(costs, 0.99):>12,.0f}") no_event = sum(1 for ev in sims if not ev) / years print(f"years with no event: {no_event:.1%}") return 0 if __name__ == "__main__": sys.exit(main(int(sys.argv[1]) if len(sys.argv) > 1 else 50_000)) ``` ```text $ python3 quantify.py Ransomware halts the order platform: 50000 simulated years, seed 20261017 option mean/yr P(>2M) P95 P99 accept (baseline) 355,373 5.9% 2,307,851 6,292,319 mitigate (control) 287,239 1.6% 864,702 2,492,012 transfer (insure) 302,104 1.6% 640,000 3,432,319 control + insure 372,039 0.2% 820,000 883,364 years with no event: 84.6% ``` 1. Save the script as `quantify.py` and run `python3 quantify.py`. 2. Run `python3 quantify.py 200000` to check that 50,000 years are enough. 3. Change the upper loss bound to `12_000_000` and run again. 4. Restore it, then change `"keeps_events": 0.6` to `0.9` (a weaker control) and run again. 5. Write one paragraph: which option meets the tolerance at the lowest cost, and which input would change your answer? **Expected output** (checked by execution). Step 1: the table above. Step 2: means within about 1% (baseline 352,821), same probabilities. Step 3: baseline 627,124 and 8.0%; the combination 0.9%, still inside 1%. Step 4: insurance alone becomes cheapest (302,104 against 338,222); the combination 0.4%. **Validation:** in step 1 the control is cheapest on average, but only the combination meets the 1% tolerance ([judgement call](#a-judgement-call-invest-insure-or-both)). **Troubleshooting:** other Python versions may differ in the last digits; compare trends. The insurance P95 of exactly 640,000 is premium plus one deductible. **Teardown:** none. #### Lab 3 (advanced): appetite-to-decision tabletop **Objective:** test whether your appetite statements decide real cases. **Prerequisites:** two hours with the risk owner, a director, finance, security and the risk function; the [appetite template](#templates); no production changes. 1. Draft appetite and tolerances for one objective, such as "customers can pay online", each tolerance with a KRI. 2. Decide four cases using only the statements: (a) a payment library cannot be patched for 60 days; (b) the second processor's contract slips a quarter; (c) a launch needs a new third-party script on the checkout page; (d) the insurer doubles the deductible. 3. Record response, approver, conditions and expiry for each, and whether the statements sufficed. **Expected output:** four decision records and a gap list. **Validation:** two people reading the statements reach the same decision in at least three cases. **Troubleshooting:** if every case escalates, tolerances are missing or bands too low. **Teardown:** none; schedule the statement fixes. ### Use cases and scenarios #### Case 1: a migration that carried operational and outsourcing risk (sourced) TSB moved its customer data to a new IT platform in April 2018; the data migrated, but "the platform immediately experienced technical failures". All branches and a significant proportion of its 5.2 million customers were affected by the initial failures; some issues persisted until TSB returned to business as usual in December 2018. TSB paid £32.7m in redress. In December 2022 the FCA (£29,750,000) and the Prudential Regulation Authority (PRA, £18,900,000) fined it £48,650,000 after a 30% settlement discount; the FCA's Mark Steward said: "The firm failed to plan for the IT migration properly, the governance of the project was insufficiently robust".[^tsb2022] **Lesson:** a go-live decision is a risk acceptance and needs the same discipline: an explicit tolerance, readiness KRIs and the supplier's risk in the same register. #### Case 2: concentration on one software supplier (sourced) The July 2024 CrowdStrike update affected an estimated 8.5 million Windows devices, under 1% of the total, with outsized effects because many critical services used the same product.[^crowdstrike] **Lesson:** a "low" supplier risk repeated across every critical service is a high concentration risk ([metrics](#metrics-and-kpis)). #### Case 3: an exception that cannot be granted (sourced rule, illustrative case) Under Binding Operational Directive (BOD) 26-04 of the US Cybersecurity and Infrastructure Security Agency (CISA), "CISA does not issue waivers or exceptions for actions required in cyber directives"; an agency that cannot act in time must "remove the asset from the agency network", and its plans should "document explicit, transparent risk decisions" for high value assets.[^bod2604] A private company with the same vulnerability may accept it inside its own policy, with isolation as the condition, a director's signature and a 30-day expiry. **Lesson:** the delegation policy must list the risks no internal approver may accept, because law, contract or directive has already decided ([VulnerabilityOps](../vulnerabilityops/)). #### Case 4: an impact tolerance that cannot be met (sourced rule, illustrative case) A UK payment institution, one of the firm types PS21/3 covers, must set an impact tolerance for each important business service;[^fcaps213] for "customers can pay online" it chooses four hours (an illustrative value). Mapping and testing show that a failure of its single card processor cannot be recovered within four hours. Since 31 March 2025 that is not a risk to accept: a firm "must ensure it can remain within its impact tolerance for each important business service" in a severe but plausible disruption (SYSC 15A.2.9R), and the FCA "expects to be notified of any failure by a firm to meet an impact tolerance" (SYSC 15A.2.11G).[^sysc15a] RiskOps records a breach to remediate (a funded second processor with a date), interim measures as an open issue (manual fallback, closer monitoring) and a decision on notifying the FCA, taken with compliance and legal (as of October 2026; not legal advice). **Lesson:** impact-tolerance breaches of in-scope UK firms belong on the never-acceptable list. **Success measure:** a severe-but-plausible exercise that stays within four hours. ## Measure, govern, pay ### Metrics and KPIs | KPI | Formula | Source | Pitfall | Cadence | |---|---|---|---|---| | Acceptance validity | Accepted risks with an authorised approver, unexpired and within the allowed term ÷ accepted risks | Register check | Counting signatures, not authority | Weekly | | Treatment on time | Treatments closed with evidence by their due date ÷ treatments due | Register | Moving due dates silently | Monthly | | Time in breach | KRI-days above limit ÷ KRI-days observed | KRI feeds | Stale feeds never breach | Monthly | | Owner coverage | Risks owned by a named person ÷ all risks | Register | A team is not an owner | Monthly | | Supplier concentration | Maximum over suppliers of critical services it can stop ÷ critical services | Dependency map | Direct suppliers only | Quarterly | | Calibration | Known outcomes inside their stated 90% range ÷ known outcomes (target about 90%)[^htma] | Estimates, actuals | Too few outcomes | Twice a year | | Surprise rate | Material losses from unregistered risks ÷ material losses | Loss-event data | "Material" defined afterwards | Yearly | | Tail against tolerance | Modelled P(annual cost > threshold), per scenario | Quantified scenarios | Unowned inputs | Per decision | **Worked calculation (illustrative quarter).** Of 44 accepted risks, 3 expired, 2 were signed below the required band and 1 ran too long: acceptance validity = 38 ÷ 44 = **86.4%**. Of 23 treatments due, 17 closed on time: **73.9%**. Twelve KRIs over 92 days give 1,104 KRI-days, 46 above limit: time in breach = **4.2%**. Of 20 ranges with known outcomes, 13 contained the actual value: calibration = **65%**, so estimators are overconfident. Seven of 12 critical services depend on one identity provider: concentration = **58%**. In the [reference register](#reference-implementation) acceptance validity starts at 0 of 5 and reaches 3 of 4 (**75%**) after Lab 1. KRIs and acceptance validity lead; losses and the surprise rate lag. **Vanity traps:** the number of risks registered, the share of green cells, assessments completed. ### Quality, security, privacy and compliance **The register is sensitive** (see the [trust boundary](#reference-architecture)), and incident details can contain personal data ([PrivacyOps](../privacyops/)). **Regulation fixes parts of the method, by jurisdiction** (dated, not legal advice): | Regime | Who it binds | What it fixes | |---|---|---| | DORA, Regulation (EU) 2022/2554 | In-scope EU financial entities, from 17 January 2025 | Management-body accountability, ICT risk tolerance, third-party register, continuity, crisis function, internal audit[^dora] | | UK FCA PS21/3 | Banks, insurers, payment and e-money firms and others in scope | Important business services and impact tolerances[^fcaps213] | | US SEC, Regulation S-K Item 106 (adopted 26 July 2023; check for later amendments) | US public companies | Disclose processes for managing material cybersecurity risks and board oversight[^sec2023] | ### Cost, capacity and sustainability COSO records that "A frequent concern expressed by many business executives is the cost of risk management, compliance processes, and control activities in comparison to the value gained."[^coso2017] Keep the function proportional: quantify the ten scenarios that drive budget or appetite and triage the rest with scales. Compare responses on money and tail: net benefit = reduction in expected annual loss − annual cost. In Lab 2 the control saves 355,373 − 287,239 = **68,134** a year net. Budget a **risk reserve** where a triggered risk would need outside help.[^ir8286] Publish a triage time so teams do not bypass the function. Climate events belong in the continuity programme; ISO 22301 gained a climate-action amendment in 2024.[^iso22301] ### Assurance of the operating model - **Third line:** internal audit samples decisions (authorised approver, live KRI, expiry respected). DORA requires regular internal audit of the ICT risk management framework for in-scope entities other than microenterprises.[^dora] - **Back-testing:** calibration twice a year, surprise rate yearly. - **Process KRIs (Atlas thresholds):** any critical risk recorded as accepted; acceptance validity below 95%; more than 5% of entries untouched for 12 months; a stale KRI feed. ## When things go wrong ### Common failures and troubleshooting | Symptom | Likely cause and diagnosis | Remediation and prevention | |---|---|---| | A loss from a risk "accepted" years ago | No expiry; find the record and its conditions | Reassess now; expiry on every acceptance | | Every risk is amber | Undefined scales, negotiated scores; check the distribution | Numeric scale definitions; quantify the top 10 | | The board receives 200 rows | No aggregation | Portfolio view: top risks, movement, breaches | | Security "accepts" risk for the business | Unclear ownership; compare approvers with roles | Re-sign by the authorised owner; automated check | | KRIs never breach | Limits copied from current values, or stale feeds | Limits from tolerances; a data owner per KRI | | Insurance pays less than expected | Deductibles, limits, exclusions not modelled | Model policy terms per scenario (Lab 2) | | One supplier outage hits many services | Concentration untracked | Concentration scenarios and metric | #### Worked runbook: an accepted risk breaches its tolerance An **illustrative scenario** using R-002 from the [reference register](#reference-implementation): checkout depends on one processor; the acceptance expired 16 days ago and the KRI shows three processor incidents in 90 days against a limit of two. ::: figure Runbook for a tolerance breach on an accepted risk ```mermaid flowchart TB K["KRI over limit, or an accepted risk materialises"] --> V["Verify data, threshold and scope: same day"] V --> Q1{"Real breach?"} Q1 -- "No" --> FD["Fix the feed; record a false alarm"] Q1 -- "Yes" --> S["Suspend the acceptance; tell owner and approver"] S --> C["Contain: compensating action within 72 hours"] C --> RA["Reassess with the new evidence"] RA --> Q2{"Back inside tolerance?"} Q2 -- "Yes" --> RN["Renew: new conditions, shorter expiry"] Q2 -- "No" --> ES["Escalate: treat, avoid or higher band"] RN --> L["Learn: method, KRI, sweep"] ES --> L classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 class V,FD,C,RA,RN,L core class Q1,Q2 decision class K,S,ES risk ``` Text equivalent: A KRI breach or a materialised accepted risk is verified the same day; a data error is fixed and recorded as a false alarm. A real breach suspends the acceptance and notifies owner and approver; containment within 72 hours and reassessment follow. Back inside tolerance, the acceptance is renewed with new conditions and a shorter expiry; otherwise the risk is escalated. Both paths end with lessons for the method, KRI and sweep. ::: Applied to R-002: **verify** that the three incidents are the processor's; **suspend** the acceptance ([ComplianceOps](../complianceops/) updates its exception register); **contain** within 72 hours (an Atlas default), for example with the manual-payment fallback; **reassess** within 10 working days; **decide**: renew only with a new condition, a shorter expiry and the signature the *new* score requires, or treat (sign the second processor), or escalate; **learn** why the expiry passed unnoticed and add the check to the weekly sweep. ### Anti-patterns and myths | Anti-pattern or myth | Why it fails | Warning signal | Do instead | |---|---|---|---| | "Accepted" by whoever closes the ticket | The owner never decided | Approver is an engineer | Delegation bands, automated checks | | Budgeting by heat-map colour | Matrices misrank risks[^cox2008] | Spend spread over many ambers | Quantify decisions that move money | | The register as the programme | ERM "is more than a risk listing"[^coso2017] | Rows added, never decided | A decision and a date per row | | Perpetual exceptions | Assessments are "bounded in time"[^sp80030] | Renewal without reassessment | Expiry, KRI, re-tested condition | | "We transferred it" | Transfer is partial; accountability stays[^ir8286][^iia2026] | No residual risk recorded | Record what remains | | Precision theatre | Numbers without sources or ranges | Single-point estimates | Ranges, named estimators, back-testing | | Risk means security risk | Operational risk covers processes, people, systems and external events; EU banking law names legal, model and ICT risk within it[^crr] | No supplier or change risks | A taxonomy covering all four | | Safety through avoidance | "Public Sector organisations cannot be risk averse and be successful" (Orange Book); the point generalises[^orange] | Every initiative escalates | Appetite that says yes as well as no | ## Deciding and adopting ### When to use and when not to use **Build an explicit practice when** people other than the accountable owner are effectively accepting risk; exceptions pile up without expiry; a regulator or customer asks how risk decisions are made (DORA, PS21/3, SEC Item 106); large changes, supplier dependencies or continuity obligations are growing; or control budgets are argued from colours. **Keep it light when** the owners meet weekly anyway: a one-page appetite statement, a 20-row register and an expiry on every exception are enough. Or when an existing ERM function works and only needs technology risks fed in. **Do not** create a team that "owns" all risks: ownership stays with management, and such a team becomes where decisions wait. ### Decision framework ::: figure Choosing a response for an assessed risk ```mermaid %%{init: {"flowchart": {"wrappingWidth": 130, "nodeSpacing": 24, "rankSpacing": 36}}}%% flowchart TB S["Assessed risk with owner and exposure"] --> Q1{"Inside tolerance?"} Q1 -- "Yes" --> ACC["Accept: authorised approver, KRI, expiry; still take any cheap control"] Q1 -- "No" --> Q2{"Can the activity stop and the objective survive?"} Q2 -- "Yes" --> AV["Avoid"] Q2 -- "No" --> Q3{"Cost-effective control available?"} Q3 -- "Yes" --> MIT["Mitigate"] Q3 -- "No" --> Q4{"Loss insurable or contractable?"} Q4 -- "Yes" --> TRF["Transfer the money part"] Q4 -- "No" --> ESC["Escalate: board decides or objective changes"] MIT --> Q5{"Residual inside tolerance?"} TRF --> Q5 Q5 -- "Yes" --> ACC Q5 -- "No, after mitigation" --> Q4 Q5 -- "No, after transfer" --> ESC classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 class S,ACC,AV,MIT,TRF core class Q1,Q2,Q3,Q4,Q5 decision class ESC risk ``` Text equivalent: A risk inside tolerance is accepted (authorised approver, KRI, expiry), and a cheap control that lowers it further is still worth taking. Outside tolerance: avoid it if the activity can stop without losing the objective; else mitigate if a cost-effective control exists, or transfer the money part if the loss is insurable. A residual inside tolerance is accepted. Still outside after mitigation, the money part of what remains can also be transferred (the combination); still outside after transfer, or if nothing works, the board decides or the objective changes. ::: **When options are close, quantify** ([Lab 2](#lab-2-intermediate-compare-responses-with-a-monte-carlo-simulation)) and decide on two numbers: expected annual cost and the probability of breaching tolerance. Record the inputs, their owners and the date. ### Maturity model These levels are **this Atlas's model**; no official RiskOps maturity model exists. | Level | Observable behaviour | Exit criteria | |---|---|---| | 0. Implicit | Risk is accepted by default; exceptions live in e-mail | A register with the top 20 risks and named owners | | 1. Registered | Register and matrix; reviews are yearly | Appetite and tolerance statements approved; delegation bands in force | | 2. Governed | Every acceptance has an authorised approver, KRI and expiry | Acceptance validity ≥ 95% for two quarters | | 3. Measured | KRIs from systems; top scenarios quantified; concentration tracked | Calibration reported; surprise rate known | | 4. Decision-integrated | Risk analysis built into change, launch, procurement and budget decisions; continuity exercised | Sustain; external review every few years | Most organisations should aim for Level 2 everywhere and Level 3 for their top scenarios. ### Adoption roadmap: 30/60/90 days | Window | Goals | Activities | Metrics at the end | |---|---|---|---| | Days 1–30: see | Know what is accepted today | Collect exceptions and implicit acceptances; draft the register (Lab 1); name owners | Owner coverage; count of unexpired acceptances | | Days 31–60: govern | Decisions by the right people | Approve delegation bands; draft appetite and tolerances (Lab 3); re-sign or expire every acceptance; start the weekly sweep | Acceptance validity | | Days 61–90: measure | Evidence for the top risks | KRIs for accepted and high risks; quantify two scenarios (Lab 2); concentration map; first quarterly committee | Time in breach; tail against tolerance for two scenarios | ## Toolkit ### Checklists #### Before accepting a risk - [ ] The scenario names the asset, threat or cause, and consequence; the score uses the written scales. - [ ] The approver holds authority for the residual band; no law, contract or directive forbids acceptance. - [ ] Conditions are verifiable, a KRI with a limit and data source exists, and the expiry is within policy. - [ ] The record is logged for [ComplianceOps](../complianceops/) and visible to the risk committee. #### Monthly register hygiene - [ ] No expired acceptances, no unowned risks, no overdue treatments without a new decision. - [ ] KRI feeds fresh; every breach has an action. - [ ] New suppliers, changes and incidents from the month triaged. #### Yearly programme review - [ ] Appetite, tolerances and delegation bands re-approved. - [ ] Calibration and surprise rate reviewed; concentration scenarios, continuity exercise and archive review done. ### Templates #### Appetite and tolerance statement ```text APPETITE AND TOLERANCE - Approved by: Date: Review: yearly or on strategy change Appetite (broad): We accept risk in pursuit of when . We do not accept risk that could . Tolerances (measurable): T1: shall not exceed over . KRI: T2: shall not exceed over . KRI: Capacity note: A loss above in one year would breach . Escalation: Any breach of T1 or T2 goes to within