RiskOps

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.

For risk managers, chief information security officers (CISOs), engineering and product leaders asked to “accept the risk”, and continuity and operational-risk teams.

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.”^[3] The problem is four habits:

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).^[4]

• Not a fraud platform or team (FinCrimeOps); such teams use the method on this page.
• Not compliance. 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”.^[5]
• Not the security operations centre (SOC Ops). NetWitness uses “RiskOps” for continuous cyber-risk monitoring;^[6] 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;^[5][7] avoiding every risk is itself a costly decision.

The label is recent and contested; the discipline behind it is not.

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.”^[1]

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”.^[15] A KRI watches the tolerance; the owner decides inside it; anything outside goes up.

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

Neighbours produce risks or act on decisions; this page owns the decision rules (an editorial split, not a standard).

%%{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

No official RiskOps charter exists; this one is this Atlas’s proposal (one-page version in the 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.^[19] 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.”^[20] ISO/IEC 27001 has named risk owners approve the treatment plan and accept the residual risk.^[21] Outside such regimes, this Atlas proposes authority banded by exposure (the delegation policy).
3. Every acceptance expires, because “the validity and usefulness of any risk assessment is bounded in time” (SP 800-30).^[22]
4. Measure what you accept. Accepted risks “need to be measured to ensure that they remain within established risk tolerance parameters” (IR 8286r1).^[15]
5. Matrices to talk, money and ranges to allocate (methods).
6. Transfer is partial (treatment options).
7. Responses have side effects: “Risk responses themselves may introduce new risks.”^[15]

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.

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”).^[19] 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).^[23]

NIST SP 800-39’s four components (frame, assess, respond, monitor)^[24] 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).^[15]

Delegation-of-authority policy (Atlas proposal), on residual exposure scored with written 1–5 scales (the score only sorts; see methods):

For quantified risks, define the bands in money too (for example on the 99th-percentile annual cost, P99 in Lab 2), 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.

A process architecture, not a technology stack: the register is the system of record; everything else feeds or reads it.

%%{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

Trust boundary. The register lists unpatched systems and weak suppliers, an attacker’s shopping list: restrict access and keep its history immutable.

The most common transaction is a request to accept a risk, often a vulnerability exception from 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 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”.^[25] The acceptance is suspended and the runbook starts.

%%{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

NIST describes risk as typically a function of an event’s adverse impact and its likelihood.^[22] 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”.^[26]

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.

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.^[27][28] 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.^[29] 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”.^[15]

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;^[30] pyfair automates FAIR simulations^[31]): 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; 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.

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.^[15][24] The UK Orange Book (which references ISO 31000:2018) adds taking more risk for an opportunity and retaining risk “by informed decision”.^[34]

Transfer has further limits: customer trust cannot be transferred (IR 8286r1);^[15] “the caps on the insurance may be too low to act as a mitigation” (SSVC);^[25] and public-sector bodies generally cannot buy insurance to transfer risk because law or policy sets their liability (SP 800-39).^[24] An acceptance can come with a risk reserve, money or hours set aside in case the risk is triggered.^[15]

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.^[35]

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.^[35] 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).^[17] 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; 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”.^[35] 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 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.^[35]

CSF 2.0 expects that “Suppliers are known and prioritized by criticality” (GV.SC-04).^[7] 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.^[36] 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”.^[37] DORA requires in-scope EU financial entities to keep a register of their ICT third-party contracts (Article 28(3)).^[23]

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).^[38] 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, contract clauses to LegalOps.

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.^[39]

Exercise results feed the register. Technical recovery (RTO, RPO, failover, restores) belongs to DisasterRecoveryOps and BackupOps; cyber incidents to ResponseOps.

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.

Automate the bookkeeping, not the decision: KRI collection, authority and expiry checks, chasing overdue treatments, reports (as in the 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;^[46] model validation belongs to ModelOps, where three US banking agencies revised their model risk guidance on 17 April 2026.^[47] 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.^[8]

The core artefact is a register that checks itself against its own policy: the delegation bands 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).

{
  "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.

"""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 <register.json>")
    sys.exit(main(sys.argv[1]))

$ 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.

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 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.

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;^[16] 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.

"""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))

$ 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). 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.

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; 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.

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”.^[4] 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.

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.^[38] Lesson: a “low” supplier risk repeated across every critical service is a high concentration risk (metrics).

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.^[48] 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).

A UK payment institution, one of the firm types PS21/3 covers, must set an impact tolerance for each important business service;^[41] 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).^[49] 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.

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 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.

The register is sensitive (see the trust boundary), and incident details can contain personal data (PrivacyOps). Regulation fixes parts of the method, by jurisdiction (dated, not legal advice):

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.”^[5] 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.^[15] 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.^[42]

• 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.^[23]
• 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.

An illustrative scenario using R-002 from the reference register: 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.

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

Applied to R-002: verify that the three incidents are the processor’s; suspend the acceptance (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.

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.

%%{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

When options are close, quantify (Lab 2) and decide on two numbers: expected annual cost and the probability of breaching tolerance. Record the inputs, their owners and the date.

These levels are this Atlas’s model; no official RiskOps maturity model exists.

Most organisations should aim for Level 2 everywhere and Level 3 for their top scenarios.

• 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 and visible to the risk committee.

• 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.

• Appetite, tolerances and delegation bands re-approved.
• Calibration and surprise rate reviewed; concentration scenarios, continuity exercise and archive review done.

APPETITE AND TOLERANCE - <objective>                Approved by: <board/committee>
Date: <YYYY-MM-DD>   Review: yearly or on strategy change
Appetite (broad):   We accept <type> risk in pursuit of <objective> when <condition>.
                    We do not accept <type> risk that could <unacceptable outcome>.
Tolerances (measurable):
  T1: <metric> shall not exceed <limit> over <period>.          KRI: <name, source>
  T2: <metric> shall not exceed <limit> over <period>.          KRI: <name, source>
Capacity note:      A loss above <amount> in one year would breach <constraint>.
Escalation:         Any breach of T1 or T2 goes to <role> within <time>.

RISK ACCEPTANCE - <risk ID>                                  Policy version: <v>
Scenario: <cause> could <event> affecting <asset/service>, leading to <consequence>
Residual score: L<1-5> x I<1-5> = <score>  Band: <low|medium|high>
Quantified (if done): mean <amount>/yr; P(year > threshold) <x>% vs tolerance <y>%
Why not treat now: <reason>             Compensating control: <description>
Condition re-verified by: <who>, every <period>
KRI: <name> limit <value> source <system>
Approved by: <name, role>  Authority for band? <Y/N>
Approved on: <date>  Expires on: <date>  (max <days> for this band)
Law, contract or directive forbids acceptance? <N / reference>

KRI - <name>                                   Linked tolerance: <T-id>
What it signals early: <risk exposure that rises before the loss>
Formula: <numerator / denominator, unit>   Source: <system>   Data owner: <name>
Limit: <value> (from the tolerance, not from today's value)
Amber at: <value>   Frequency: <daily|weekly|monthly>
On breach: <who acts, within what time, which runbook>

DELEGATION OF RISK ACCEPTANCE                        Approved by: <committee>
Scales: likelihood and impact 1-5 as defined in <document>; score = L x I
Low 1-4:      risk owner          max 365 days   review yearly
Medium 5-9:   director            max 180 days   review every 6 months
High 10-16:   risk committee      max 90 days    review quarterly
Critical 20+: no one may accept; treat or avoid, the board decides which
Never acceptable internally: <list of legal, contractual, directive cases>
  e.g. US federal directive actions (BOD 26-04); UK impact-tolerance breaches (SYSC 15A)
Every acceptance: conditions, KRI, expiry, record in the register

RISK COMMITTEE - <quarter>                       Attendees: <names>
1. Movement: top risks against appetite (new, up, down, closed)
2. Breaches: KRIs over limit, expired acceptances, overdue treatments
3. Decisions requested: high-band acceptances, escalations
4. Quantified scenarios: mean, tail, response options
5. Concentration and continuity: supplier map, exercise results
6. Method health: acceptance validity, calibration, surprise rate
Decisions and owners: <list>

An editorial comparison (this Atlas’s synthesis, not a standard). In every model the three lines stay: owners decide, the risk function challenges, internal audit assures.^[19]

ERM names the enterprise-wide discipline (COSO); GRC usually names the programme and tooling that join governance, risk and compliance work. The practice on this page fits inside either.

Is RiskOps a new name for GRC? Partly. GRC tools hold registers and controls; RiskOps here is the decision discipline they serve. Auditive says its RiskOps is “not a rebrand of GRC”;^[12] the test is whether decisions change.

We bought a “RiskOps platform” for fraud. Is this the right page? For fraud and AML operations, no: see FinCrimeOps. In Feedzai’s 2021 definition, RiskOps “helps risk management teams stop fraud and money laundering” and adds compliance tooling;^[2] the international AML baseline is the FATF Recommendations (as amended June 2026; further reading).^[51] The method here still applies to your fraud appetite.

Should the CISO accept security risks? Usually the business or system owner accepts within the bands; the CISO advises and may veto specific cases. ISO/IEC 27001 gives residual-risk acceptance to risk owners;^[21] in the US federal RMF the authorizing official accepts and cannot delegate it.^[20]

Do we need FAIR? Not to start. Written scales and ranges come first; FAIR helps compare responses in money for the largest scenarios.^[27][28]

Is an exception the same as a risk acceptance? An exception is a deviation from a policy or control; accepting the risk it leaves is the decision. ComplianceOps records the exception; this page decides who may accept it.

How often should risks be reassessed? On expiry, KRI breach, material change or incident, and at least on the band’s cycle.

• Portfolio aggregation. Summing scenarios as if independent understates correlated losses; shared drivers (one supplier, one region) need joint simulation.
• AI risk. NIST is revising AI RMF 1.0 and in April 2026 released a concept note for a critical-infrastructure profile;^[46] treat claims of autonomous risk management as unproven until independently evaluated.
• Regulatory movement (as of October 2026). US third-party guidance under revision,^[37] a new IIA Three Lines statement (July 2026),^[19] ISO 31000 under review.^[32]

• Beginner: read to the decision framework; do Lab 1; read the Orange Book.^[34]
• Practitioner: Lab 2 on a real scenario; NIST IR 8286r1 and the COSO KRI paper;^[15][18] run the 30-day plan.
• Leader or architect: the judgement call; Lab 3 with your executives; then ComplianceOps and DisasterRecoveryOps.

Situation (illustrative). Lab 2’s order platform. The finance director proposes the control alone, the option with the lowest expected annual cost. The board’s tolerance allows at most a 1% chance of a year costing more than 2 million.

Why the attractive choice can be wrong. Minimising the average treats a 6-million year as no worse than six 1-million years, but one large loss can exceed what the organisation can absorb (its risk capacity, in the FSB’s terms).^[16] The combination costs 84,800 a year more than the control alone.

Recommendation. If the 1% tolerance is real, choose both and revisit at renewal; if the board will not pay 84,800 a year for that tail, rewrite the tolerance, not the analysis. Uncertainty: a weaker control (Lab 2, step 4) makes insurance the cheaper single option, but in both variants only the combination stays inside 1%; the inputs need owners and back-testing.

After this page you can explain why “RiskOps” is ambiguous, distinguish appetite, tolerance and capacity, design a delegation policy with expiry, quantify a scenario on mean and tail, and evaluate a register. Self-check:

1. An engineer marks a vulnerability ticket “risk accepted” and closes it. What is missing?

2. Two risks both score 5 on a 5×5 matrix. Can you fund the one that “looks worse” from the colour?

3. “We bought cyber insurance, so the ransomware risk is transferred.” What do you say?

4. The board’s appetite says “customers can always pay online”. Turn it into a tolerance and a KRI.

5. Your 20 past “90% ranges” contained the actual outcome 13 times. What does that tell you?

6. A US federal agency cannot patch a known-exploited vulnerability in time. Can its CISO accept the risk for 30 days?

The practice behind the label is old and well documented: decide how much risk you will take, make that measurable, let the accountable owner decide inside it, measure what was accepted, and let every decision expire. What is new is the expectation that this runs continuously, with indicators fed by systems and money where money matters.

The test of a RiskOps function is simple: pick any accepted risk and ask who decided, under which authority, on what evidence, until when, and what would tell you it had changed. If the register answers all five, the label does not matter.

Every source was opened on 2026-10-17; dates are the source’s own. Claim-level support, blocked pages (iso.org; bis.org and fatf-gafi.org, read through Internet Archive copies) and executed artefacts are in research/riskops-ledger.md.

Further reading. NIST IR 8286Ar1 (December 2025) and IR 8286B-upd1 (February 2025) continue the register series; the COSO ERM framework page (https://www.coso.org/enterprise-risk-management).

Changelog. 2026-10-17, r0: first edition (term status confirmed as ambiguous; executed register checker and Monte Carlo lab). 2026-10-17, r1: answered review r1 (reviews/riskops-r1-response.md): current CRR3 operational-risk definition; Case 4 rewritten as an impact-tolerance breach; checker blocks acceptances with no record (sixth risk added, outputs re-run); loss-event data, RCSA and ISO/IEC 27001/27005 added; tolerance wording, decision tree, sources and acronyms corrected; operating-model comparison added. 2026-10-18, post-score polish (reviews/riskops-polish.md): CRR waiver, critical band, money band edges, acronyms, Figure 1 label, AI RMF status; repeats cut.