Risk registers: naming risks, owners and likelihood

By the end, you can

• Define a risk and a risk register, and explain why a risk entry needs a stated probability, impact and owner before it's usable (PM-2).
• Use AI to draft a first-pass risk register from a project brief or task breakdown, and explain why a named owner must confirm each entry before it's treated as real (PM-2).
• Classify a sample list of risks by owner, probability and impact, and identify one an AI-only pass is likely to miss (PM-2).

Before you start

This is Module 3, Lesson 1 of the AI-Powered Project Management course, opening the module's work on risks and decisions. It assumes you have completed Modules 1 and 2 — you should be comfortable with a bounded project brief and a reviewed task breakdown — and have used at least one AI chat assistant for drafting text. It does not require project-management certification, software or a specific risk tool.

A risk is a potential; a risk register makes it usable

Every plan this course has built so far assumes things go roughly as expected. They don't always. APM's project management glossary defines a risk as "the potential of a situation or event to impact on the achievement of specific objectives." That definition is worth reading slowly: a risk is not something that has already happened, and it is not automatically bad — it is the chance that something, positive or negative, could affect whether the project reaches its goal.

A single sentence naming a risk isn't yet useful on its own. "The venue might cancel" tells a reader almost nothing about what to do with that information. APM's glossary defines a risk register as "a document listing identified risk events and their corresponding planned responses," used "interchangeably with risk log or risk repository." A risk register turns a vague worry into something a project can actually manage: each entry names the risk and states a planned response if it occurs, not just that the risk exists.

What makes a risk entry usable: owner, probability, impact

A risk register entry with only a description is still not enough to act on. Three more things turn a named risk into something a project can genuinely track. APM's glossary defines a risk owner as "the individual or group best placed to assess and manage a risk" — a named person, not "the team" or "someone." It defines probability as "the likelihood of a risk occurring," and impact as "the assessment of the effect on an objective of a risk occurring." Without a named owner, a listed risk belongs to nobody, and nobody notices when it starts to happen. Without a probability and impact, every risk looks equally urgent, which in practice means none of them get the attention that actually matters.

Why an AI-drafted risk register still needs an owner's check

Given a project brief or a task breakdown, an AI assistant can propose a plausible first-pass risk register: read "book venue," "recruit volunteers," "order equipment" from a task list, and it can generate genuinely reasonable entries — "venue unavailable," "insufficient volunteer turnout," "equipment delivery delayed." That is real, useful drafting work; naming risks from a blank page is one of the harder parts of risk work to do well.

It is not the same as knowing which risks are real for your specific project, or who should own each one. The US National Institute of Standards and Technology's (NIST) AI Risk Management Framework describes an AI system as something that "can, for a given set of objectives, generate outputs such as predictions, recommendations, or decisions" — a generator of plausible candidate risks, not a party with access to your actual suppliers, your team's actual availability, or your organisation's actual history of what tends to go wrong. A probability or impact rating in an AI-drafted register is worth a second look for exactly this reason: the draft has no real basis to rate one risk higher than another from a task list alone — only the named owner, who knows the venue's actual cancellation history or the supplier's actual track record, can rate that honestly.

Assigning a named owner to a risk, and confirming the response the project will take if it occurs, is itself the kind of call the Open Worldwide Application Security Project's (OWASP) guidance on excessive agency has in mind when it recommends that a human "approve high-impact actions before they are taken." Deciding who is accountable for watching a risk, and what the project will do if it materialises, commits a real person's time and attention before anything has gone wrong yet — exactly the kind of high-impact call that belongs with a named person, not with the draft that first named the risk.

A worked example: a brewery's new taproom opening

A small independent brewery is opening a new taproom in a converted warehouse, six weeks out from a planned launch night. The owner asks an AI assistant to draft a risk register from her project brief and task breakdown.

The assistant proposes four risks, each with a plausible-sounding one-line response: "building inspection fails — schedule inspection early," "equipment delivery delayed — order early," "bar staff shortage — start hiring now," "poor launch night turnout — promote on social media." It rates all four as "medium probability, medium impact."

The owner reviews the draft against what she actually knows. She rates the building inspection risk high impact — a failed inspection could delay opening past the launch date entirely, not just cause a scramble — and assigns herself as owner, since only she can push the inspection date with the council. She rates the equipment delivery risk lower probability than the draft suggested: she has used this supplier twice before and they have never missed a date, though she keeps it on the register because the impact would still be severe if it did happen this time. She reassigns the bar-staff risk to her assistant manager, who actually handles hiring, rather than herself. She adds a risk the AI draft missed entirely: the warehouse's existing electrical supply may not support the number of taps and fridges planned — something only she knows because she toured the building herself, with no equivalent line in the task names for an AI assistant to have picked up on.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Project management glossary — APM (Association for Project Management). Defines a risk as the potential of a situation or event to impact on the achievement of specific objectives, and a risk register as a document listing identified risk events and their corresponding planned responses.
2. Project management glossary — APM (Association for Project Management). Defines a risk owner as the individual or group best placed to assess and manage a risk, probability as the likelihood of a risk occurring, and impact as the assessment of the effect on an objective of a risk occurring.
3. AI Risk Management Framework 1.0 — NIST AI Resource Center. Frames an AI system as an engineered system that generates outputs such as predictions, recommendations or decisions — not a self-directing decision-maker.
4. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Recommends human-in-the-loop control requiring a person to approve high-impact actions before an LLM-connected system takes them.