Skip to content

Building a Simple Risk Register: Fields, Scales and Upkeep

A step-by-step way to build a risk register a small team will actually maintain, drawing on ISO 31000 and NIST guidance on recording and ranking risks.

Strategy Chaos · Last reviewed October 23, 2026 · 6 min read

Most organizations already track risks somewhere: in meeting notes, in a manager's head, in a spreadsheet that was last opened during an audit. A risk register pulls that into one place so people can see the biggest threats, who owns them and what is being done.

The idea is simple, but registers often fail in predictable ways. Descriptions are vague, every risk is rated "medium," nobody owns anything, and the file goes stale within a quarter. This guide shows how to build a lean register that avoids those traps, using concepts from ISO 31000 and from NIST's guidance on integrating risk registers into enterprise risk management.

You do not need special software. A shared spreadsheet is enough to start.

What a risk register is

NIST IR 8286r1, published in December 2025, quotes two short definitions. OMB Circular A-11 describes a risk register as "a repository of risk information including the data understood about risks over time." ISO defines it as a "record of information about identified risks."

The register is not the risk management process itself. ISO describes its ISO 31000 standard as providing principles, a framework and a process for managing risk, covering identifying, analyzing, evaluating, treating, monitoring and communicating risks. The register is where the results of that work are written down, so they can be compared, prioritized and reviewed. ISO also notes that ISO 31000 is guidance and cannot be used for certification.

Start from objectives, not a list of fears

NIST's online glossary, drawing on ISO's risk vocabulary and OMB Circular A-11, defines risk as the "effect of uncertainty on objectives." That is a helpful starting point. Before listing risks, write down the three to five objectives that matter most this year: revenue, a product launch, keeping a key customer, staying compliant. Then ask what could get in the way of each.

Write each risk as a short scenario rather than a single word. NIST IR 8286r1 says a complete risk scenario "describes the source of uncertainty, any predisposing conditions, the resources affected, and the anticipated result." Its example: "Construction activity severs a critical fiber optic cable that was not protected in conduit, interrupting communications to the data center and resulting in the loss of availability of enterprise financial systems."

For example, imagine a hypothetical commercial bakery. "Ovens" is not a risk. "Our single deck oven fails during the November holiday rush, and because the repair technician is two hours away and parts take days, we miss wholesale deliveries and lose a café account" is a risk someone can act on.

The fields worth tracking

NIST IR 8286r1 includes a notional register template. Its fields make a sensible default:

  • ID: a sequential number for referring to the risk.
  • Priority: a relative ranking, as a number or a level such as high, moderate or low.
  • Risk description: the scenario, written with consistent phrasing.
  • Risk category: a theme that lets you group and compare related entries.
  • Likelihood: an estimate of how probable the scenario is before any further response.
  • Impact: the potential consequences if nothing more is done.
  • Exposure rating: the combination of likelihood and impact.
  • Risk response type: how you plan to handle it.
  • Risk response cost: the estimated cost of that response.
  • Risk response description: a brief description of what will be done.
  • Risk owner: the person accountable for the risk.
  • Status: where things stand now.

NIST notes that a register may contain more or fewer fields depending on the organization. Two worth adding for a small team are "date last reviewed" and "next review date." NIST suggests keeping the register itself a summary and putting supporting detail, such as assumptions, people involved and schedules, in a separate risk detail record.

Choose scales you can defend

Likelihood and impact need scales, and scale design is where many registers quietly go wrong. NIST SP 800-30 Rev. 1, the Guide for Conducting Risk Assessments (September 2012), compares three approaches.

Qualitative scales use categories such as very low, low, moderate, high and very high. NIST says these support communicating results to decision makers, but the small range of values makes it hard to prioritize within the set. It also warns that unless each value is clearly defined or illustrated with examples, different experts "could produce significantly different assessment results." Its fix: annotate each rating with the reasons behind it.

Semi-quantitative scales use bins or scores, such as 1 to 10 or ranges like 0 to 15 and 16 to 35, that translate easily into qualitative labels while allowing finer comparisons. Quantitative assessments use numbers that keep their meaning outside the assessment, which best supports cost-benefit comparisons, but NIST cautions that rigor is "significantly lessened" when subjective judgments are buried inside the numbers.

For most small teams, a five-level scale with written definitions is a practical middle ground. A hypothetical impact scale might read: 1 means an inconvenience absorbed within a week; 3 means losing a month of profit or a significant customer; 5 means a threat to the business continuing. Whatever you choose, write the definitions at the top of the register and add a one-line "because" note to every rating.

Decide how to respond

NIST IR 8286r1 lists four response types for negative risks:

  • Accept: the risk is within tolerance, so you monitor it without additional action.
  • Mitigate: take actions that reduce likelihood, impact or both to an acceptable level.
  • Transfer: share part of the consequences with another party, such as an insurer. NIST notes that some consequences, like lost customer trust, often cannot be transferred.
  • Avoid: change plans so the risk does not occur, considering the cost of the lost opportunity.

Registers can also track opportunities. For positive risks, NIST lists realize, share, enhance and accept.

To decide which risks need action, you need a sense of risk tolerance. NIST describes it as the readiness to bear the remaining risk after responding to it. A small business owner can state this plainly, for example, "We will not accept any single risk that could cost more than two months of cash."

Keep it alive

A register captures a single point in time. NIST notes that once agreed responses are in place, the result becomes the current state "and the cycle begins anew." In practice, that means a rhythm:

  1. Review the top-priority risks at a regular leadership meeting, such as once a month.
  2. Revisit the whole register on a set schedule, such as quarterly, and after any major change or incident.
  3. Ask owners for a one-line status update rather than a fresh analysis each time.
  4. Close or merge risks that no longer apply, so the list stays short enough to read.

FEMA's Ready Business guidance on risk assessment adds a useful prompt for each review: look for vulnerabilities that would make a hazard more damaging. Its example is a building without a fire sprinkler system, which could burn to the ground, compared with a protected building that would suffer limited damage.

Common mistakes to avoid

  • Listing categories ("cyber," "people") instead of scenarios.
  • Rating everything moderate, which hides the real priorities.
  • Assigning risks to a department instead of a named person.
  • Recording mitigations that have no due date or budget.
  • Treating the register as a compliance document instead of a decision tool.

Key takeaways

  • A risk register is a running record of identified risks, their ratings, responses and owners.
  • Start from your objectives and write each risk as a specific scenario.
  • Use a small set of fields: description, likelihood, impact, exposure, response, owner, status and review dates.
  • Define every rating level in writing and note the reason behind each score.
  • Choose a response for each significant risk: accept, mitigate, transfer or avoid.
  • Review on a fixed rhythm so the register reflects reality, not last year's worries.

Sources

Spotted something out of date? Let us know.

More in Uncertainty & Risk