Project risk management interview questions and answers
Prepare answers that connect uncertainty to an actionable decision. The set covers risk statements, ownership, response triggers and the combined exposure that may be invisible when projects are reviewed separately.
Actionable analysis: state the uncertain cause, potential event and effect on an objective.
Ownership and response: identify someone able to act, resources for the response and a trigger.
Proportionate governance: adapt escalation and control to exposure rather than using identical paperwork for every project.
How to approach your answer
Describe the uncertainty and the outcome at risk; distinguish an event that might happen from an issue that already exists.
Explain assessment, response options, ownership and residual exposure. Avoid pretending that every estimate is precise.
Show when the response would activate, who could accept the remaining risk and how you checked that exposure changed.
A migration risk has an owner but no funding for its response.
Illustrative approach: I would check whether the assigned owner can actually implement the response. If additional testing or a fallback environment is needed, I would quantify the decision sufficiently to request funding or a different response. Until the response is feasible, I would retain the exposure in reporting and escalate it through the agreed threshold. Acceptance would require an authorised decision with the consequences understood. Assigning a name to the register does not make the risk controlled.
Mistakes to avoid
Treating a populated RAID log as evidence of managed exposure.
Giving probability scores without explaining assumptions or consequences.
Ignoring correlated risks, response funding or the authority to accept residual risk.
Questions and answer guidance
Start with the level closest to your experience. Each question links to its exact practice exercise; the answer is also available here without opening the app.
Foundations
Start with the concepts and explain them using a small example.
Technical · Fresher
1. How would you turn supplier uncertainty into a risk statement that supports action?
Read the answer guide
I would write it in three parts, the cause, the uncertain event and the effect on an objective. For example, because the only qualified supplier has a long lead time on a key component, supply may be late, which could defer commissioning by several weeks. That wording tells the team what to watch, who to talk to and what is at stake. A label such as supplier risk does not do that, since it names a category and not a situation. I would also check that the statement describes something uncertain, and not something already happening, which would be an issue.
What the interviewer is assessing
Whether you can write a specific cause, event and effect statement that points to monitoring and response instead of a vague category label.
Common mistakes
They write supplier risk as the whole statement, which names a category but no event, cause or affected objective.
They describe something already happening, such as a late delivery, as if it were an uncertain future risk.
Practise a follow-up
How would you decide who should own the supplier delay risk?
How would you rewrite a statement that mixes two separate events into one risk?
2. What is a RAID log and how do you keep it useful?
Read the answer guide
RAID stands for Risks, Assumptions, Issues and Dependencies. Each entry needs an owner, a date, an impact, a rating and an action. It stays useful only if it is reviewed on a fixed rhythm, closed items are cleared out, assumptions are tested and anything beyond the team's control is escalated. A RAID log that is filled in once at kickoff and never opened again is not managing anything.
What the interviewer is assessing
Practical familiarity with basic project control.
Common mistakes
Treating it as a one-time list
Entries with no owner or date
Confusing a risk (might happen) with an issue (already happening)
Practise a follow-up
Give me an example of an assumption that later became a risk.
Show how you would apply the idea to a constraint, disagreement or failure.
Technical · Mid-level
3. How do you distinguish a risk from an issue?
Read the answer guide
A risk is something that might happen and would affect objectives; an issue is already happening and needs action now. The distinction matters because they are managed differently: a risk gets an owner, an estimate of probability and impact, a response and a trigger to watch, while an issue needs an owner, a fix date and escalation if it is outside tolerance. A supplier delay that could happen is a risk; when it has happened, it is an issue. Risks that materialise move to the issue log. Review both regularly and escalate what exceeds your authority.
What the interviewer is assessing
Whether you separate uncertain future exposure from a present problem and manage each with owners, responses and escalation.
Common mistakes
They use the words interchangeably and keep one combined list with no owners or response dates.
They log risks once at kickoff and never review them, so they become issues by surprise.
Practise a follow-up
What is a risk trigger and how would you use it?
When would you escalate a risk instead of managing it within the project?
4. How do you decide when to escalate an issue and to whom?
Read the answer guide
Escalate when an issue threatens a commitment that you cannot fix within your own authority and time, for example a cost, date or quality target, or when a decision is needed from someone more senior. Try first to resolve it at the lowest sensible level, but do not wait until it is a crisis. When you escalate, be brief and factual: what the issue is, its impact, what you have already tried, and the specific decision or help you need. Escalate to the person who can actually decide, and keep your own manager informed.
What the interviewer is assessing
Judgement about timing and the ability to escalate constructively, not as blame.
Common mistakes
Escalating everything immediately
Holding on to problems too long out of pride
Escalating without a clear ask
Practise a follow-up
Have you ever escalated too early?
How do you escalate without damaging a relationship?
5. A data migration risk has an owner but no response funding. Is it adequately managed?
Read the answer guide
No, ownership alone does not make a risk managed. A named owner with no funding means the response may be impossible to carry out. I would estimate the effort for both the mitigation and the fallback, say rehearsing the migration and keeping a rollback option, identify where funding comes from, and define the trigger and who can authorise the action. If funding is refused, that is a legitimate decision, but it should be documented with the residual exposure, and accepted by the accountable risk owner at the right level, not silently ignored.
What the interviewer is assessing
Whether you understand that a risk needs a funded, triggered and authorised response, and that refusal of funding must become a documented decision by the right authority.
Common mistakes
They say the risk is managed because someone is named, without checking whether the response is funded or feasible.
They quietly absorb the response cost into the team's time instead of getting an explicit decision on funding.
Practise a follow-up
How would you cost a mitigation plan for a data migration risk?
Who should accept the residual risk if the sponsor declines to fund it?
6. What is the difference between a risk response trigger and a weekly risk-review date?
Read the answer guide
A trigger is an observable condition that tells us a risk response should start now, for example an approval still missing at a cutoff date. A weekly review date is when we reassess exposure and update the register. They serve different purposes, and I use both, so that the team can act immediately when a trigger occurs rather than waiting for the next meeting. In practice, each important risk gets a trigger, a named person to watch it and a pre-agreed response, which saves precious days.
What the interviewer is assessing
Whether you can distinguish a specific activation condition for a response from a scheduled review, and use triggers to act without waiting for a meeting.
Common mistakes
They rely only on the weekly review, so a risk that has already occurred waits days for any response.
They define triggers vaguely, such as if things get worse, so nobody knows when to act.
Practise a follow-up
Can you give an example of a good trigger for a schedule risk?
Who should be authorised to activate a response when the trigger occurs?
7. Why can ten moderate project risks collectively justify a serious escalation?
Read the answer guide
Individually moderate risks can still be a serious problem when they share a cause or hit the same constrained milestone, for example several risks all depending on one overloaded team. Adding ordinal scores gives a false total, so I look at common causes, correlation and cumulative exposure, and describe the plausible combined scenario in plain terms: what happens to the date or budget if three of them occur together. Then I present that scenario with the specific action or decision needed to reduce it, so escalation leads somewhere.
What the interviewer is assessing
Whether you can assess correlated risks together, avoid adding ordinal scores, and present a combined scenario with the decision needed.
Common mistakes
They add the individual risk scores together and quote the total as if the scale were numerical.
They keep each moderate risk in its own row and never look for shared causes or a combined effect.
Practise a follow-up
How would you spot a common cause behind several risks in a register?
How would you quantify the combined exposure if the sponsor asks for a figure?
8. What makes a program-level risk different from a project risk escalated for visibility?
Read the answer guide
A program risk threatens shared outcomes or several components, or the coordinated transition, and cannot be handled well inside one project. It needs its systemic consequence defined and a program-level owner who can act across the projects. A project risk escalated for visibility is still a local risk, and sending it up for awareness alone does not transfer accountability. For instance, a data quality problem in one system is a project risk, while a shared supplier failing across four projects is a program risk.
What the interviewer is assessing
Whether you can tell a genuinely cross-component risk needing program ownership from a local risk merely escalated for awareness.
Common mistakes
They treat every escalated project risk as a program risk, so the program register fills with local issues.
They keep a cross-project risk with one project manager who lacks authority over the other components.
Practise a follow-up
How would you assign an owner to a risk that spans four projects?
How would you stop the program register from becoming a copy of project registers?
Explain trade-offs, wider consequences and the evidence behind your decision.
Technical · Mid-level / Senior
9. How do you identify, assess and manage risks on a programme?
Read the answer guide
Identify risks early with the team, the customer and past project lessons, and write each one clearly as cause, event and impact. Score each by likelihood and impact so effort goes to the biggest ones. Choose a response for each: avoid, reduce, transfer or accept, and assign an owner and a date. Review the risk log regularly in a meeting rather than leaving it as a static document, and watch for risks that have become issues. Keep senior stakeholders aware of the top few risks and the help you need.
What the interviewer is assessing
A working process, not a one-time list.
Common mistakes
Creating a log that nobody reviews
Listing risks without owners or actions
Confusing risks with issues that have already happened
Practise a follow-up
Give an example of a risk you avoided.
What is the difference between a risk and an issue?
10. Tell me about a time you spotted a serious risk early and prevented a problem.
Read the answer guide
Choose an example where your early warning made a real difference. Explain how you noticed the risk, for instance a small pattern in status data, a comment in a meeting or a dependency that did not add up, and why others had missed it. Describe what you did: assessing the impact, choosing a response, and raising it with the right people. Give the result, ideally something concrete that did not happen because of you, and what habit helped you see it.
What the interviewer is assessing
Alertness, judgement and the habit of raising concerns before they become crises.
11. How is an aggregate program risk different from a project risk?
Read the answer guide
A project risk threatens one project's objectives and is managed by its team. An aggregate program risk arises from the combination of exposures, for example several projects depending on the same scarce team, the same vendor or the same release window, so that a single event hits many at once, or from interfaces that no single project owns. It can be larger than the sum of the parts. I would identify the systemic drivers, assess the combined effect, assign a program-level owner and response, and report it to the board along with project risks, without simply adding up the scores.
What the interviewer is assessing
Whether you understand correlated and interface-driven exposure at program level, and give it ownership rather than summing project risks.
Common mistakes
They add project risk scores together and call the total the program risk.
They leave shared-vendor or shared-team risks with individual projects, so nobody owns the combined exposure.
Practise a follow-up
How would you spot a correlated risk across projects?
What response would you consider for a risk that affects several projects at once?
12. How would you demonstrate that a smaller project needs lighter governance than a high-risk transformation?
Read the answer guide
I would assess the exposure, complexity, reversibility and external obligations of each initiative, not just its size. Then I propose proportionate approvals, evidence and reporting, such as a monthly one-page report for the small project against detailed stage gates for the transformation, while keeping essential accountability intact. I would also review whether the lighter controls catch material exceptions, for instance by defining triggers that move the project to heavier governance. Size alone is a poor guide, since a small project can carry a large regulatory risk.
What the interviewer is assessing
Whether you tailor governance by risk, complexity and reversibility rather than size, keep essential accountability, and check that lighter controls still catch material problems.
Common mistakes
They apply the same heavy governance to every project, wasting effort on small low-risk work.
They judge governance need purely by budget size, missing a small project with high regulatory exposure.
Practise a follow-up
What triggers would move a light-governance project to heavier control?
How would you explain proportionate governance to an auditor?