---
name: enterprise-risk
description: Identifies, assesses, and tracks organizational risk — building and maintaining a risk register, scoring exposure, assigning owners and treatments, and preparing for audit. Use this to stand up a risk program, assess the risk in a decision or initiative, prepare for a certification or audit, decide whether a risk should be accepted, mitigated, transferred, or avoided, or report risk posture to leadership.
---

# Enterprise risk

## The register is the artifact

A risk that is not written down with an owner is not managed. Each entry carries:

- **The risk stated as a cause and consequence** — "if X happens, then Y." "Cybersecurity" is a
  category, not a risk. "If an employee's credentials are phished, an attacker reaches customer
  records" is a risk you can do something about.
- **Likelihood and impact**, on a stated scale, with the reasoning. The reasoning matters more than
  the score.
- **Current controls** and an honest view of whether they work.
- **Residual risk** after those controls — the number that actually matters and the one most often
  omitted.
- **A named owner.** A person, not a department.
- **Treatment and a date.**

## Treatment is a decision with four options

**Mitigate** (reduce it), **transfer** (insure or contract it away), **avoid** (do not do the
thing), or **accept**. Accepting is legitimate and often correct — but acceptance must be explicit,
at the right level of authority, and recorded. Risk accepted by silence is risk nobody owns.

Anything above the threshold that only the chief executive can accept goes to them. Never let an
unacceptable risk be quietly downgraded to fit an existing authority.

## Scoring honestly

Two failure modes, both common:

- **Everything is high.** The register stops discriminating and gets ignored.
- **Scores drift downward** as items age without the underlying exposure changing.

Re-assess on a schedule and require evidence for any reduction. A control's existence is not
evidence it works; a test of the control is.

## Audit readiness

Continuous, not a project. What auditors need: documented policies, evidence they are followed,
records of exceptions and approvals, and a clear line from the framework's requirement to your
control to the evidence.

Collect evidence as work happens. Assembling a year of it retrospectively is expensive, and gaps
found then cannot be fixed retroactively.

## Reporting

Leadership needs the few risks whose residual exposure is above appetite, what is being done, and
what needs a decision. Not the whole register. A risk report that requires reading forty rows to
find the three that matter will not be read.

## Sources

`references/sources.md` in this skill lists the outside authorities that settle the questions
here — what each one is authoritative for, and what you may do with it. Check them before
answering on anything they cover, and cite what you used. Most are free to read and not free
to reproduce; the use note on each is binding.

## Tooling

A risk register is a table, and for most organizations a spreadsheet or a database in
Notion, Airtable, or Confluence is the honest answer. Dedicated platforms — LogicGate,
AuditBoard, Riskonnect, ServiceNow IRM, and similar — earn their place when the register
has to reconcile with audit findings and control testing in one system.

Compliance automation tools cover control evidence, not enterprise risk. Do not let one
stand in for the other.

## Never

- Score residual risk on controls that are planned rather than operating.
- Accept a risk without naming who accepted it and when it is reviewed again.
- Keep a register with no review cadence. That is documentation, not risk management.
- Close a risk because the project that raised it ended.