Build a project risk register with Claude

A risk register is useful when it changes what the team does. That means a short list of specific risks, each with an owner and an action, reviewed regularly. Claude helps turn a team brainstorm into that list in about 45 minutes: it structures each risk as cause, event and consequence, adds typical risks you may have missed, and sorts by score. The team's knowledge and the prioritization stay in human hands.

Brainstorm first

Describe the project in a few lines: deadlines, budget, key suppliers, dependencies on other teams. Then run a 20-minute risk brainstorm with the team on a whiteboard. People who do the work know the risks that matter: the vendor who is always late, the approver who goes on leave in the critical month, the data migration nobody has tested. This list is the core of the register; the model's additions are a supplement.

The prompt

Role: you are a project risk manager. Context: project: {{description}}. Deadline: {{deadline}}. Budget: {{budget}}. Dependencies: {{suppliers, other teams}}. Risks from the team: {{list}}. Task: add risks typical for this kind of project. For each risk state the cause, the event and the consequence, suggest probability and impact from 1 to 5 and a mitigation action. Format: a table "risk, cause, consequence, probability, impact, action, owner role", sorted by score. No long dashes.

Cause, event, consequence is the structure that makes a risk actionable. "Delays" is too vague to act on. "The vendor's integration team is shared with another client (cause), so the API delivery slips (event), and user testing moves past the go-live date (consequence)" tells you exactly where to act.

Trim and rate

Remove generic risks you cannot influence, such as force majeure or a general economic downturn. They make the register longer and change nothing. Then rate each remaining risk with the team, probability and impact from 1 to 5. The model's suggested scores are a starting point; the team knows whether the vendor has been late before.

Multiply probability by impact. Every risk scoring 12 or more gets a named owner and a concrete action with a date. The top 5 by score go to management.

Owners and actions that mean something

An owner is the person who watches the risk and triggers the action, which is not always the person who would suffer the consequence. For the vendor delay above, the owner might be the project manager who holds the vendor relationship. The action should reduce probability or impact and have a date: "agree a named integration engineer with the vendor by the end of the month" is an action; "monitor the vendor" is not. If you cannot name an action for a high-scoring risk, say so in the register and raise it with management. That is exactly the kind of risk they need to hear about.

Keep it alive

Review the register at every status meeting. Update scores, close risks that passed, add new ones. A register written at kickoff and never opened again is a document for the audit trail, not a management tool.

What to do

1. Describe the project, deadlines, budget, key suppliers and dependencies.
2. Run a 20-minute risk brainstorm with the team.
3. Ask Claude to add typical risks and structure each as cause, event and consequence.
4. Remove generic risks you cannot influence.
5. Rate each risk for probability and impact from 1 to 5 with the team.
6. Assign an owner and an action to risks scoring 12 or more, and report the top 5 to management.
7. Review the register at every status meeting.

A working register

Every risk has a probability, impact, owner and action, and management knows the top 5.

Plans

A risk register fits the free plan. Pro at 20 USD per month (17 with annual billing) adds Projects, where the project description and register can stay together for each review; Team at 25 USD per seat with annual billing keeps team data out of training by default. See Claude pricing, the project manager's version of this task and Claude vs Miro AI if you run the brainstorm on a whiteboard.