TL;DR: These 20 risk assessment ai prompts cover the real arc: naming risks people are reluctant to say out loud, scoring likelihood and impact without letting the model invent numbers, running Gary Klein's 2007 pre-mortem exercise correctly, building an actual mitigation plan, and the recurring review that keeps a register alive past its first month.
Most risk registers get built once, at kickoff, in a burst of good intentions, and then never opened again. That is not a tooling problem. It is an incentive problem: naming a risk out loud can read as pessimism, scoring it honestly takes longer than scoring it politely, and revisiting it later means admitting which of your assumptions were wrong. None of that goes away because AI is in the loop. What it can do is lower the friction on the mechanical parts: drafting the first list, structuring a scoring table, running a facilitation script, so the actual judgment calls get more of your attention instead of less. The twenty prompts below are grounded in that division of labor on purpose — every prompt that asks for a number also tells the model where that number has to come from, because a plausible-sounding score with no real evidence behind it is worse than no score at all.
Why does a risk register usually die within a month of being built?
A risk register dies when it becomes a one-time deliverable instead of a living document someone is accountable for reopening. Most teams write one during planning, attach it to the kickoff deck, and never touch it again until something has already gone wrong, at which point it gets reopened as an autopsy instead of a warning. Nobody schedules the reopening, because nobody wants to be the person who books a meeting to talk about what might still go wrong on a project that is, on paper, going fine.
The prompts below are grouped around the five things that actually need to happen for a register to stay useful: identifying risks honestly, scoring them without guessing, running a proper pre-mortem before the plan is locked, turning scores into an owned mitigation plan, and reviewing it on a schedule that survives contact with a busy quarter. Skip any one of the five and the other four don't hold up on their own — a beautifully scored register with no owner assigned is just a longer spreadsheet, and a pre-mortem that never gets converted into register rows is a good meeting with no lasting output.
1. Initial risk sweep from a project brief
Here is my project brief: [paste your brief, scope, timeline, and team].
List every risk you can identify across these categories: technical, schedule, budget,
external/market, and people/team. For each risk, write one sentence stating what could go
wrong and one sentence stating why, given what's actually in my brief above.
Do not invent details about my project that aren't in the brief — if a category has no
obvious risk from what I gave you, say so instead of manufacturing one.
2. Category-by-category deep sweep
Focus only on [pick one: technical / schedule / budget / external / people] risk for this
project: [paste brief].
List 5-8 risks specific to this category, ranked from most to least likely given what you know
about projects of this type and size.
For each, name the earliest point in the project where this risk would first become visible,
so I know what to watch for and when.
3. The devil's-advocate stress test
Here is my project plan: [paste plan].
Act as a skeptical reviewer whose job is to find the plan's weakest assumption, not to be
encouraging. Identify the three assumptions this plan depends on that would be most damaging
if they turned out to be wrong.
For each, state what evidence I actually have for the assumption today, versus what I am
simply hoping is true.
4. Stakeholder-specific risk elicitation
Here is my project plan: [paste plan].
Answer as a skeptical [finance lead / legal counsel / operations manager] reviewing this plan
for the first time. What are the three risks a person in that specific role would flag that a
project manager might not think to look for?
Stay strictly inside that role's usual concerns — don't produce generic risks a non-specialist
would already list.
5. Dependency and single-point-of-failure scan
Here is my project's list of dependencies: [paste vendors, tools, team members, or other
projects this one depends on].
For each dependency, state what happens to my timeline if it fails, is delayed, or becomes
unavailable, using only the information I gave you above.
Flag any dependency that has no backup or workaround mentioned in my list — that is the
single point of failure, not the ones I already have a plan B for.
What should AI actually do in a likelihood/impact score, and what should it refuse to invent?
An AI model can organize, normalize, and compare scores you give it reasoning for. It cannot generate a real probability out of nothing, because it has no access to your project's actual base rates, so a fluent-sounding "70% likely" from a model is a guess dressed as a measurement, and it will look identical to a real one until something goes wrong. The fix is the same one that works for any AI-assisted numeric task: you supply the judgment, the model supplies the structure.
This matters more here than in most scoring exercises because the two biases that already distort human risk scoring — optimism about your own plan, and reluctance to rank a colleague's pet initiative as high-risk — don't disappear just because a model is doing the arithmetic. A model asked to "score this risk" with no evidence supplied will happily produce a number anyway, and that number will carry the same false confidence a human's unexamined gut estimate does, just with better formatting. The rubric below exists to force the evidence question before the number gets written down, not after.
| Score | Likelihood means | Impact means |
|---|---|---|
| 1 | Very unlikely — no precedent on this or similar projects | Negligible — absorbed without anyone noticing |
| 2 | Unlikely — would need an unusual chain of events | Minor — a short delay or small budget line |
| 3 | Possible — has happened before on similar work | Moderate — visible schedule or scope impact |
| 4 | Likely — a known weak point in this specific plan | Major — threatens a deadline, budget, or deliverable |
| 5 | Near-certain absent a specific change | Severe — threatens the project's viability |
6. Grounded likelihood/impact scoring
Here is my raw risk list: [paste risks from the identification prompts above].
Score each on a 1-5 likelihood scale and a 1-5 impact scale, using this rubric: [paste the
table above, or your own version of it].
For every score, state the one piece of evidence from my project that justifies it. If you
have no specific evidence for a score, assign a 3 (possible/moderate) as the default and say
so explicitly rather than picking a more dramatic number.
7. Scored list to prioritized top 10
Here is my scored risk list (risk, likelihood, impact): [paste table].
Multiply likelihood by impact for each and rank them highest to lowest.
Output the top 10 only, as a table, and add one column stating why each risk ranked where it
did relative to the one above and below it.
8. Calibration and consistency check
Here is my scored risk list: [paste table with reasoning per score].
Check this list for internal consistency: flag any two risks that received similar scores but
have very different-looking reasoning behind them, and any risk whose stated reasoning
doesn't actually support the number given to it.
Do not re-score anything yourself — only flag the mismatches for me to review.
9. Plain-English narrative for a non-technical stakeholder
Here is my prioritized risk table: [paste top 10 with scores].
Write a 150-word plain-English summary for a stakeholder who has never seen a likelihood/
impact matrix. State the top 3 risks by name, what would trigger them, and what we are doing
about each, in one sentence per risk.
No jargon, no scoring methodology — assume they only care what could go wrong and what we're
doing about it.
What is a pre-mortem, and where did it actually come from?
The pre-mortem is not an unattributed piece of project-management folklore. Cognitive psychologist Gary Klein published it as "Performing a Project Premortem" in the September 2007 issue of Harvard Business Review, building on 1989 research by Deborah J. Mitchell, of the Wharton School; Jay Russo, of Cornell; and Nancy Pennington, of the University of Colorado, on a phenomenon Klein calls "prospective hindsight—imagining that an event has already occurred", which the researchers found increases the ability to correctly identify reasons for future outcomes.
The two mechanics worth keeping intact when you translate this into an AI prompt: everyone writes their own list independently before anyone speaks, so no one's answer anchors anyone else's, and the framing is "this has failed" rather than "this might fail," a settled fact people are explaining, not a hypothetical they have to defend raising. Lose either mechanic and you get a regular risk-review meeting with extra steps — the independence stops the loudest voice in the room from setting everyone else's answer, and the past-tense framing is what actually gives the reluctant reason permission to be said out loud in the first place.
10. Full pre-mortem facilitator prompt
Act as a facilitator running a project pre-mortem, based on Gary Klein's method (Harvard
Business Review, September 2007).
Here is our project plan: [paste plan].
Assume this project has already failed, one year from now. Generate 10-15 plausible, specific
reasons it failed — not generic risks, but reasons a real team member might have been
reluctant to say out loud during planning (a political dependency, an unstated assumption
about scope, a skill gap no one named).
Write each reason as a settled fact ("The project failed because...") not a hedge
("The project might fail if...").
11. Round-robin capture and consolidation
Here are independent pre-mortem lists from each team member: [paste each person's list
separately].
Consolidate these into one list, removing exact duplicates but keeping every distinct reason,
in the order Klein's method calls for: read one reason at a time from each list, cycling
through people, until everything is captured.
Flag any reason that appears on only one person's list — those are often the ones people were
most reluctant to say, and the ones a facilitator should double-check got a fair hearing.
12. Solo pre-mortem for a one-person team
I'm running this project without a team to pre-mortem it with. Here is my plan: [paste plan].
First, generate my own list: assume the project failed, and list every reason I can think of,
in first person, as if I'm explaining what went wrong to someone.
Second, take the opposite side: act as a colleague who wasn't in the planning and has no
stake in the plan looking good. What did my list miss, and what assumption in my plan would
you personally be most reluctant to challenge if you worked for me?
13. Surfacing the reason nobody wants to say
Here is our project plan and team context: [paste plan and any relevant org context — reporting
lines, recent history, politically sensitive dependencies].
Assuming this project fails, what is the single most likely reason that would be uncomfortable
for someone on this team to say out loud in a meeting — a dependency on a person who's
overcommitted, a decision nobody wants to revisit, a deadline everyone privately doubts?
State it plainly, as something a facilitator should ask about directly rather than wait for
someone to volunteer.
14. Pre-mortem findings into new register rows
Here is our consolidated pre-mortem list: [paste the reasons from the group exercise].
Convert each into a proper risk register row: risk name, category, likelihood (1-5, with your
reasoning), impact (1-5, with your reasoning), and a suggested owner role (not a named person —
just the function, e.g. "engineering lead").
Flag any pre-mortem reason that doesn't map cleanly to a single risk — some may need splitting
into two.
How do you turn a scored risk list into an actual mitigation plan?
A score without an owner and a trigger is a paragraph, not a plan. The step teams skip most often is deciding, in advance, what specific event would tell you a risk is starting to materialize; without that, "monitor it" means nobody notices until the risk has already become the problem. An owner with no trigger tends to check in only when something visibly breaks, which is the same failure mode as having no owner at all, just with someone to blame for it afterward.
15. Owner, mitigation, and trigger per risk
Here is my top-10 scored risk list: [paste table].
For each risk, add three columns: a suggested owner role, one concrete mitigation action, and
a specific trigger — an observable event or metric that would tell us this risk is starting to
happen, not just a vague "if things go wrong."
Keep each mitigation action specific enough that someone could start it this week.
16. Contingency plan for high-severity risks
Here are our top 3 highest-scored risks: [paste risks, scores, and mitigation actions].
For each, write a short contingency plan answering: if the mitigation fails and this risk
fires anyway, what is our first move in the next 48 hours, and who makes that call?
Assume the mitigation didn't work — don't restate the mitigation plan itself.
17. Cost/effort-weighted mitigation prioritization
Here is my mitigation list with rough effort estimates: [paste risk, mitigation action,
estimated effort/cost to implement].
Rank these by the ratio of risk-reduction value to effort, and separate them into three
groups: do now, monitor and revisit next review, and accept as-is with no action.
Justify the "accept as-is" group specifically — that's the one worth double-checking.
18. Mitigation stress test
Here is our mitigation plan for this risk: [paste risk and its planned mitigation].
Act as a skeptic whose job is to find out how this specific mitigation could itself fail —
not new risks to the project, just ways this particular fix might not work as intended.
List the top 3 failure modes of the mitigation itself, and what would need to be true for each
one to happen.
How often should a risk register actually get reviewed, and what changes at each check-in?
The honest answer is a fixed cadence tied to your project's own rhythm rather than a universal rule: weekly for a fast-moving sprint, monthly for most other work, and always again immediately before a major milestone or launch, since that is exactly when a stale register does the most damage by giving false confidence. A register nobody has opened in six weeks is worse than no register at all in one specific way: it lets a team point at a document and believe the risks are handled, when the document is simply old.
19. Recurring review: diff against last time
Here is our risk register from the last review: [paste previous version].
Here is the current state of the project: [paste current status, recent events, and anything
that's changed].
Identify: which risks have grown more or less likely since last time and why, which appear
resolved and can be closed, and which new risks should be added given what's happened since
the last review.
Do not just re-list everything unchanged — flag only what's actually different.
20. Pre-decision gate check
We're about to [launch / ship to production / present to the board / sign the contract] on
[date]. Here is our current risk register: [paste register].
Do a quick pulse check: which of our top 5 risks has a trigger condition that's actually
present right now, based on what I've told you about current status: [paste current status]?
Flag only risks that are live right now, not the full list — this is a go/no-go check, not a
re-scoring exercise.
Should you trust an AI's risk score more than your own judgment?
No, and the twenty prompts above are built around that answer rather than around it. Every prompt that touches a number is written to ask the model for structure and reasoning, not for a probability it has no way to actually know. The same caution applies to the underlying model's tendency to fill a gap with a plausible-sounding answer rather than an honest "I don't know." Our explainer on why ChatGPT makes things up covers the mechanism in more depth, and the practical takeaway carries over directly here: a model will produce a confident-sounding likelihood score exactly as readily as a correct one, so every number that reaches your actual register needs to trace back to evidence you can name.
The pre-mortem is the one prompt in this set worth running even if you skip everything else. It costs one meeting, it is built on a named, dated, verifiable method rather than a folk technique, and it is specifically designed to surface the risk everyone already half-suspected but nobody had said out loud yet. If your team already runs a PM workflow built around AI, the risk register slots in as one more artifact fed by the same persistent product context rather than a one-off document you paste a plan into once — the fewer times you retype the same project background before a prompt, the more likely the register actually gets kept current. Before you trust any output here past a first draft, it's worth running your own plan through the same kind of adversarial check our guide to red-teaming your own prompts walks through, and if part of your review cadence includes reporting risk status upward, the same no-spin discipline from our investor update prompts applies just as directly to a risk section as it does to a metrics section: state the risk plainly, before the reassurance, not after it.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 4.8★ on the Chrome Web Store.
Create An AccountSave the pre-mortem prompt and the recurring-review prompt above: those two are the ones that actually determine whether this register is still alive in three months. The rest draft faster with a model in the loop. Whether every score and every "accepted risk" is actually true is still the judgment call that belongs to your team, not the model that helped you write it down. A register is only as honest as the meeting that built it, and the meeting is still yours to run.
By Nafiul Hasan — Founder of Prompt Architects.