Skip to content

SOP-086 — Risk-register maintenance

Guide

SOP-086 — Risk-register maintenance

SOP · owner: Quality & Risk. Layer: SOP/Runbook (docs/canon.md). Open / update / close a row in the operational risk register (reports/risk-register.md) and recompute posture. Covers the control-gap registry kept in the same file. Operational and process risk only — adjacent risk types are routed, not logged.

Interface Contract

  • Inputs: newly surfaced operational/process risk ← from <any agent/unit or audit> · trigger: review requested
  • Inputs: cross-cutting High/Critical finding ← from COO · trigger: briefing posted
  • Outputs: updated risk register / control-gap registry → to Archivist · trigger: artifact approved
  • Outputs: Critical/High risk notification → to Principal / affected Lead · trigger: review passed
  • Handoff trigger (in): a material operational/process risk is identified (by Q&R, an audit, or routed from the COO log)
  • Handoff trigger (out): the register row is written/updated with likelihood, impact, mitigation, named owner, review date — and posture recomputed
  • Definition of Done before handoff:
    • [ ] Risk named as an event that could occur, not a vague consequence
    • [ ] Scoped as operational/process (else routed to the correct register, not logged here)
    • [ ] Likelihood + Impact (L/M/H) and composite Severity set
    • [ ] A named mitigation and a named owner Lead (owner remediates; Q&R assures)
    • [ ] Overall posture recomputed if a material (High/Critical) risk opened/closed
    • [ ] Principal / affected Lead notified on any new Critical/High or escalation
    • [ ] Register handed to the Archivist (artifact approved); 0 drift

Purpose

Keep a single living inventory of operational and process risk that is honest, owned, and current — so accepted risks (like the live Slack ToS exposure) are tracked in a standing register with an owner and a review date, not buried in a one-off triage log.

When to use

  • A new operational/process risk is identified (by Q&R, an internal audit, a four-test sample, or routed from the COO cross-cutting log).
  • An existing risk’s likelihood / impact / status changes (escalates or is mitigated).
  • A control gap is found in an audit and needs tracking to closure.
  • The recurring review fires (reports/audit-schedule.md) — re-confirm every open row.

Flow

flowchart LR
  A["1. Identify the risk<br/>(an event)"] --> B["2. Scope it<br/>(operational? else route)"]
  B --> C["3. Rate L × I → severity"]
  C --> D["4. Name mitigation<br/>+ owner Lead"]
  D --> E["5. Write/update the row<br/>+ control-gap entry"]
  E --> F["6. Recompute posture<br/>(if material)"]
  F --> G["7. Notify + hand to Archivist"]
  classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
  class A,B,C,D,E,F,G s

Text fallback: identify the risk as an event → scope it (if it is security / strategic / delivery / archive risk, route it to that owner instead of logging here) → rate likelihood × impact into a severity → name a mitigation and a single owner Lead → write or update the register row (and the control-gap row if it came from an audit) → recompute overall posture if a material risk opened or closed → notify the Principal / affected Lead on any Critical/High, and hand the register to the Archivist.

Steps

  1. Identify the risk. Name the event that could occur, specifically — “the SOP for X does not exist yet” is a risk; “things might go wrong” is not.
  2. Scope it correctly — operational/process only. If it is a security/privacy threat (→ Security; Principal until seated), strategic/bet (→ Innovation/CPTO), delivery on a project (→ PMO), or archive integrity (→ Archivist), route it to that owner and record it under “Risks owned elsewhere” — do not log it in the operational table.
  3. Rate likelihood and impact (Low / Medium / High each) and set the composite Severity (Critical / High / Medium / Low).
  4. Assign a mitigation and an owner. Every row has a named mitigation action and a named unit Lead responsible for it. Q&R assures; it does not author the mitigation. If the mitigation is a compensating control Q&R itself runs (e.g. a by-hand interlocking trace), name that too.
  5. Write / update the row. Add or update the row in reports/risk-register.md. If the risk came from an audit control gap, add the matching control-gap registry row (Gap ID, stated control, actual gap, severity, owner, status, source). Closed gaps are kept (status struck), never deleted.
  6. Recompute posture. If a material (High/Critical) risk opened or closed, update the “Risk posture (overall)” line.
  7. Notify + archive. On any new Critical/High or an escalation, notify the Principal / affected Lead (review passed). Hand the register to the Archivist (artifact approved); confirm 0 drift.

Roles / approvers

  • Q&R Director owns and maintains the register (sole writer).
  • Named owner Lead owns the mitigation (remediates).
  • Principal / COO notified on Critical/High; escalation per the JD when a Critical mitigation stalls.

Guardrails

  • Operational/process only. Routing a mis-scoped risk to the right register is part of the job — logging it here anyway is a finding against this SOP.
  • Report, don’t silently edit. A new trigger or a risk routed to Q&R is logged and reported, never quietly absorbed; Q&R does not edit other owners’ artifacts.
  • No mitigation = not done. A row without a named mitigation and a named owner is incomplete (DoD).
  • Owner remediates; Q&R assures. Q&R never closes a risk by doing the first-line fix itself.
  • Links to canon, never restates it (CONTRIBUTING.md).

See also: reports/risk-register.md · docs/units/quality-risk/charter.md · SOP-085 (internal audit) · SOP-087 (four-test sample) · reports/phase0-reviews/coo-cross-cutting-log.md · master plan §11 · docs/handoff-triggers.md.