“Residual Risk vs Secondary Risk: What’s the Difference?”

What is residual risk?

residual risk vs secondary risk is a key topic in modern project management and teamwork. Residual risk is the risk that remains after a response has been implemented. In the PMBOK Guide glossary it is defined as the risk remaining after risk responses have been implemented; ISO 31000 uses the same idea under “residual risk” in its vocabulary guidance.

Almost no response removes a risk entirely. Firewalls reduce intrusion risk without eliminating it. A second supplier reduces single-source exposure while leaving you dependent on two vendors instead of one. A contract clause transfers liability while leaving you with the cost of enforcing it.

Residual risk matters for three practical reasons:

1. It is the risk you are actually carrying. Plans, contingencies, and insurance should be sized against residual exposure, not against the original gross exposure.
2. It must be accepted by someone with authority. A risk owner cannot silently absorb a $90,000 tail; that decision belongs to the sponsor or business owner.
3. It justifies the response. If the residual is nearly as large as the original risk, the mitigation is spending money to feel better rather than to change outcomes.

How do you express residual risk in numbers?

The cleanest method is to re-score probability and impact after the response, then compare the expected values.

Example 1: a data migration risk.

• Original risk: migration corrupts customer records during cutover
• Probability: 30%
• Impact: $200,000 (recovery, compensation, regulatory exposure)
• Gross expected value: 0.30 × 200,000 = $60,000

Response: two full rehearsals on a masked copy of production data, plus a validated rollback script. Cost of the response: $18,000. After the response:

• New probability: 8%
• New impact: $150,000 (rollback shortens the outage but does not eliminate recovery work)
• Residual expected value: 0.08 × 150,000 = $12,000

The response spends $18,000 to reduce expected exposure from $60,000 to $12,000 — a $48,000 reduction, roughly 2.7 times the cost. That is a defensible trade. Note that the impact barely moved: rehearsals cut the likelihood, not the severity. Many responses work this way, and saying so is more honest than claiming a blanket “80% reduction”.

How do you decide what residual is acceptable?

Set the threshold before the workshop, not after. Two numbers do most of the work: the risk appetite for the category, and the contingency reserve available to absorb what remains.

The bands are illustrative, and the principle is not: somebody with authority must say “we are carrying this on purpose.” A register where every risk is marked “mitigated” with no residual figure is not a control system; it is a wish.

What is secondary risk?

A secondary risk is a new risk that arises as a direct result of implementing a risk response. The PMBOK Guide defines it in exactly those terms: a risk that arises as a direct result of implementing a risk response.

The distinction is causal. Residual risk is the leftover of the original exposure. Secondary risk is a different exposure, created by the cure.

Classic examples:

• Outsourcing to reduce delivery risk creates vendor dependency, contract risk, and a loss of internal capability.
• Fixed-price contracting to cap cost risk creates adversarial behavior, change-order disputes, and quality shortcuts.
• Automating a manual control to reduce human error creates system dependency, integration failure, and a skills gap in the team that used to do it manually.
• Adding a second supplier to reduce single-source risk creates qualification overhead, split volumes that weaken both relationships, and inconsistency between components.
• Compressing the schedule to protect a launch date creates overtime fatigue, defect leakage, and key-person burnout.
• Requiring additional approvals to reduce fraud risk creates delay, queue buildup, and shadow workarounds that bypass the control entirely.

Every one of those is a real risk in its own right, with its own probability, impact, owner, and response. That is the test: if it can be scored and owned independently, it belongs in the register as a separate entry, cross-referenced to the response that created it.

Why do secondary risks get missed so often?

Because they appear after the decision, not before it. The approval meeting discusses the original risk and the cost of the response. Nobody is assigned to ask what the response introduces, and the people who would notice — the team doing the work — are usually not in that meeting.

There is also an incentive problem. The person proposing the mitigation is often the person who benefits from it being approved. Asking them to enumerate the risks it creates is asking for a self-critique at the worst possible moment.

The fix is procedural rather than moral: make the secondary risk question a required field, not an optional reflection.

How are they different in practice?

The register column is where most organizations go wrong. Residual risk lives inside the existing entry — the row stays open, with its score reduced and a note saying who accepted the remainder. Secondary risk needs a new row. Teams that only update the original entry lose the new risk entirely; teams that create a new row but never update the original lose sight of what they are still carrying.

How do you run the two-question check on every response?

Before a response is marked complete, require two written answers. Not a discussion — two lines in the register.

Question 1: what is left? Restate probability and impact after the response, in the same units as the original scoring. If the answer is “much lower”, the response is not finished being described.

Question 2: what did this create? List any new dependency, new single point of failure, new cost, new compliance obligation, or new behavior the response encourages.

Example 2: outsourcing a support function.

A company outsources tier-1 support to cut internal cost risk.

• Original risk: support costs exceed budget by $150,000 in year one. Probability 40%. Expected value: $60,000.
• Response: three-year managed service contract at a fixed fee.
• Residual risk: costs still overrun by up to $40,000 through change requests; probability 25%; residual expected value $10,000.
• Response cost: $12,000 of transition effort.

On the original risk, the trade looks good: $12,000 spent, expected exposure down by $50,000. But the response creates secondary risks:

• Vendor fails to meet service levels during peak season: probability 20%, impact $70,000 → $14,000
• Loss of internal knowledge makes future insourcing expensive: probability 35%, impact $90,000 → $31,500
• Contract lock-in prevents switching for 36 months: probability 15%, impact $120,000 → $18,000

Secondary expected value: $63,500 — larger than the $50,000 reduction the response achieved. The outsourcing decision may still be right for other reasons: cash flow, headcount limits, access to skills. But it is not the clean win the original business case implied, and the honest total position is worse than doing nothing on a pure expected-value basis.

That is the most useful thing this distinction does: it stops a mitigation from being scored only against the risk it addresses.

When does residual risk become a secondary risk?

Three patterns blur the line, and each needs a deliberate call.

The response becomes permanent. A temporary manual workaround, introduced to survive a peak, becomes the operating model. What started as a residual exposure inside a project risk turns into an operational risk with a new owner, new budget, and no end date.

The residual is bigger than the tolerance. If the leftover exposure exceeds the threshold for acceptance, the correct action is another response — and that response will have its own residual and secondary risks. This is recursion, not failure, and it should stop when the residual is acceptable or the cost of further response exceeds the benefit.

The secondary risk is the same risk, relocated. Transferring a risk through insurance or contract does not remove it; it moves the financial consequence and adds counterparty risk. If the “new” risk has the same cause and the same impact, it is probably residual exposure viewed from a different seat.

> Important note: Risk transfer almost never produces zero residual risk. It produces a different risk profile with a new party in it, and that party can fail.

How do you keep both visible in a risk register?

Four fields and one habit are enough for most projects.

Fields:

1. Residual probability and impact, with the resulting expected value and the name of the person who accepted it.
2. Secondary risk links, so the new entry points back to the response that created it.
3. Response cost, so the trade can be evaluated rather than assumed.
4. Trigger, which for residual risk is often “residual exceeds tolerance” rather than an external event.

Habit: at every review, ask the two questions for any response being closed. It takes ninety seconds per risk and is the only reliable point at which the information still exists in someone’s memory.

Example 3: a portfolio view.

A program has 14 open risks with responses in progress. Total gross expected value: $610,000. Total residual after planned responses: $240,000. Sum of identified secondary risks: $95,000.

The honest exposure is $335,000, not $240,000 — a 40% understatement if secondary risks are ignored. Contingency was set at $250,000, which covers the residual but not the residual plus the consequences of the responses themselves. That single calculation is usually enough to change how a steering committee reads a risk slide.

Common mistakes with residual and secondary risk

• Marking a risk “closed” when the response is complete. The response is complete; the risk is reduced. Closing it removes the monitoring that residual exposure still needs.
• Expressing residual as a percentage. “70% mitigated” invites the question “of what?” Re-score probability and impact instead.
• Forgetting the response cost. A mitigation that cuts exposure by $20,000 and costs $18,000 is not obviously worth doing, and the register should show both numbers.
• Treating transfer as elimination. Insurance, outsourcing, and warranties all move risk and create counterparty exposure.
• Letting the proposer self-assess the secondary risks. Add a reviewer who has to live with the consequences.
• Scoring secondary risks as “low” because they are inconvenient. The scoring scale applies to all risks, including the ones your own decisions created.
• Never revisiting accepted residual risk. Acceptance is a decision with a date and should be re-confirmed when the project context changes.

What are the trade-offs of formalizing this?

Rigor versus speed. Scoring residual and secondary risk adds roughly 10% to the time spent on each response. On a 14-risk program that is a couple of hours, and it changes the contingency number.

Detail versus usability. A register with 40 secondary risks becomes unreadable. Fold minor ones into a single “response-induced dependencies” entry with a combined score, and keep separate rows for anything above the acceptance threshold.

Formalism versus culture. In teams with low psychological safety, a required secondary-risk field becomes a box-ticking exercise. Recording secondary risks can make a preferred option look worse, which is the point — and it only works when the person naming the downside of their own proposal is not punished for it.

For a broader view of how these risks sit alongside the rest of the register, see our guides to technology project risks and vendor and supplier risks.

How does this work in a real register?

The mechanics are simple enough that a spreadsheet handles them. Column for residual probability, column for residual impact, a lookup for the accepting authority, and a text field for the secondary risk link. The failure is rarely the schema; it is that the register lives apart from the work, so nobody updates the residual when the response actually finishes.

Doitify keeps risks and constraints next to tasks, owners, milestones, and project documents, so a response action closes as a task and the residual question appears at the moment it matters rather than in a quarterly cleanup. Doitify is our product, so read that description with the obvious bias in mind. It will not decide your tolerance thresholds or sign off on accepted exposure; that remains a human decision, and it should be.

Whatever tool you use, make the two questions impossible to skip. A required field labeled “residual exposure accepted by” does more for risk culture than a policy document.

Conclusion

Residual risk and secondary risk answer two questions that arrive together and are rarely asked together: what is left, and what did we create. The first belongs to the original entry and needs a number plus a named acceptor. The second belongs in a new row, with its own owner and its own response.

Run the two-question check every time a response closes. Score the residual in probability and impact rather than percentages. Count the cost of the response against the exposure it removes. And when the secondary risks add up to more than the mitigation saves, say so plainly — because the decision may still be right, but it should be made with the whole number in front of the people paying for it.

If this post on residual risk vs secondary risk was helpful, you might also enjoy Project Management Software for Consulting Firms and Project Resource Management: Complete Guide.