Last updated: 2026-11-10
Responding to Risk: Strategies, Contingencies and the Risks Responses Create
Analysis tells you which risks matter most. Response planning decides what to do about each of them, who will do it, what it will cost, and what will tell you that a backup plan needs to start. A response that amounts to "keep an eye on it" is a note that the risk exists, not a plan.
This page covers the standard responses to threats and to opportunities, then the engineering practices that work as permanent responses to whole classes of risk, then the contingency and fallback plans that sit behind the main response, the residual and secondary risks that remain or appear afterwards, how reserves are sized, and what goes into a risk management plan.finding risks comes first
Responses to Threats FoundationalKnowledge that endures for decades — core principles
The PMBOK Guide lists five responses to threats1:
| Response | What it does | Software example | When to use it |
|---|---|---|---|
| Avoid | Changes the plan so the risk can't occur | Drop an experimental feature; choose a proven library instead of a new one | High impact, and an alternative exists without major loss |
| Transfer | Moves the impact (not the risk itself) to a third party | A managed database service with an SLA; a fixed-price contract; insurance on equipment | The risk is outside your expertise, and transferring it costs less than the expected loss |
| Mitigate | Reduces the probability, the impact, or both | More frequent testing (probability); redundancy or rollback (impact); an early prototype (uncertainty) | The risk can't be avoided or transferred but can be reduced at a reasonable cost |
| Accept | Acknowledges the risk and acts only if it happens | Passive: deal with it if it comes. Active: set aside a time or budget reserve | Low exposure, or every other response costs more than the expected loss |
| Escalate | Passes the risk to whoever has the authority to deal with it | A regulatory change affecting several projects goes to the programme board | The risk is outside the project's scope or authority |
Transfer deserves a second look. Moving a database to a managed service transfers the operational work, but if the provider has an outage, it's still your users who can't log in. The financial impact may be transferred through a contract; the product impact usually isn't. Treat transfer as a change in who pays, and check what remains.
Choosing between responses is a cost–benefit judgement. Boehm lists risk-reduction leverage analysis among the prioritisation techniques: compare how much a response lowers risk exposure against what the response costs2. A response that costs three days to cut exposure by half a day isn't worth doing; one that costs a day to cut exposure by five is.exposure : impact x probability
authority?"} Q1 -->|no| ES["Escalate"] Q1 -->|yes| Q2{"Can the plan change
to remove it, cheaply?"} Q2 -->|yes| AV["Avoid"] Q2 -->|no| Q3{"Can someone else carry
the impact more cheaply?"} Q3 -->|yes| TR["Transfer
(then check what remains)"] Q3 -->|no| Q4{"Does reducing it cost
less than its exposure?"} Q4 -->|yes| MI["Mitigate"] Q4 -->|no| AC["Accept
(active or passive)"]
Responses to Opportunities FoundationalKnowledge that endures for decades — core principles
The same guide mirrors the threat responses for opportunities1, following the argument that the risk process should manage upside uncertainty as deliberately as downside3:
| Opportunity response | Mirror of | What it does | Software example |
|---|---|---|---|
| Exploit | Avoid | Acts to make sure the opportunity happens | Put the strongest developers on the feature that could win a major client |
| Share | Transfer | Partners with a third party better placed to capture the benefit | Co-develop a shared component with another team; a joint venture into a new market |
| Enhance | Mitigate | Increases the probability or the size of the benefit | Contribute a fix upstream so the framework release we're hoping for lands sooner |
| Accept | Accept | Takes the benefit if it comes, without pursuing it | Note that a library might add a feature; use it if it appears |
| Escalate | Escalate | Passes it to someone with the authority to act | A reusable platform idea goes to the department, not one project |
Good Engineering Practice as Standing Mitigation FoundationalKnowledge that endures for decades — core principles
Many of the practices that make up ordinary good software engineering are risk responses that have been made permanent. They don't wait for a particular risk to be identified: each one reduces the probability or the impact of a whole class of downside outcomes, on every project, all the time. Seeing them that way explains why they're worth their cost, and it gives a vocabulary for deciding how much of each a project needs.
They fall into two groups. Practices in how the work is organised mostly reduce the likelihood that a fault gets made or goes unnoticed. Practices in how the system is structured mostly reduce the impact when a fault, a failure or a change arrives anyway. The pairing of process practice with likelihood and architecture with impact is our framing; it's a tendency rather than a rule, and several practices do both.
(errors, change,
failures, suppliers)"] --> P["Process practices
reduce likelihood"] P --> F["Faults and failures
that get through"] F --> A["Architectural practices
reduce impact"] A --> H["Harm to users,
schedule, business"] style P fill:#FFC857 style A fill:#FFC857
Process and project management practices
| Practice | Risks it reduces | How |
|---|---|---|
| Iterative, incremental delivery | Wrong functions, requirements churn, schedule slip | Short cycles expose misunderstandings while they're cheap to fix; each increment is a checkpoint. Boehm lists incremental development as a response to unrealistic schedules2 |
| Prototypes and spikes | Design and technology uncertainty | Buy information before committing; turn an unknown into a measured risk |
| Version control with a remote | Data loss, unrecoverable mistakes | Every change can be recovered or reverted |
| Automated tests and continuous integration | Defects reaching users; integration failure late in the project | Faults are caught minutes after they're written, while the cause is fresh |
| Code review and pairing | Defects, single points of knowledge | A second reader catches errors; knowledge spreads beyond one person |
| Estimates as ranges, refined by retrospectives | Schedule and cost overrun | Uncertainty is visible in the plan; each cycle calibrates the next estimate |
| A Definition of Done | Hidden incomplete work; quality drift | "Finished" means the same thing to everyone, so progress reports are trustworthy |
| Documentation and cross-training | Personnel turnover | The project survives any one person leaving |
A common objection is that these practices slow a team down, trading speed for safety. Forsgren, Humble and Kim's research on software delivery found the opposite pattern: the organisations that deployed most often were also the ones with the most stable systems, so throughput and stability moved together rather than against each other4. Small, frequent, well-tested changes are lower-risk changes. CI/CD and TDD and BDD cover the practices in detail.
Architectural practices
| Practice | Risks it reduces | How |
|---|---|---|
| Information hiding and modularity | The cost of change; ripple effects | Parnas argued for decomposing a system around the design decisions most likely to change, hiding each behind a module interface5. When a decision changes, the damage stays inside one module |
| Abstraction layers around third parties | Supplier failure, vendor lock-in, API deprecation | Swapping a provider means rewriting one adapter, not the whole system (see Exit Architecture) |
| Timeouts, circuit breakers and bulkheads | Cascading failure | Nygard's stability patterns stop one failing dependency from dragging down everything that calls it6 |
| Redundancy and failover | Component or infrastructure outage | A failure removes capacity rather than service |
| Feature flags and reversible deployments | A bad release | Turning a feature off or rolling back takes minutes |
| Least privilege and defence in depth | Security breach | A compromised component can reach less, and an attacker meets several barriers (see Security Design Principles) |
| Observability: logs, metrics, alerts | Failures going unnoticed | Problems are detected early, which shortens their impact |
The common thread in that table is reversibility. Most architectural risk reduction works by keeping options open: a decision hidden behind an interface can be changed; a deployment behind a flag can be undone; a provider behind an adapter can be replaced. Software Architecture Styles compares how different architectures trade these properties off.reversibility lets you defer hard choices
Contingency and Fallback Plans Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
| Contingency plan | Fallback plan | |
|---|---|---|
| What it is | A pre-planned response that starts when a risk materialises | A second plan for when the primary response fails |
| Needed for | Any risk with an accept-active or mitigate response | High-impact or highly uncertain risks |
| Example | If the vendor is more than two weeks late, switch to in-house development of the component | If the in-house build hasn't reached a working prototype within three weeks, cut the feature and extend the timeline |
Both need a trigger: an observable condition, written in advance, that says the plan starts now. "If the vendor is late" isn't a trigger; "if the vendor misses the 3 March interface delivery" is. Without a trigger, the team keeps hoping for another week, and by the time anyone acts the options have narrowed. Both also need an owner, so somebody is responsible for noticing the trigger.
Residual and Secondary Risks Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
Residual risk is what's left after a response has been applied. Mitigation rarely takes exposure to zero; the remainder is covered by a contingency reserve or accepted explicitly.
Secondary risks are new risks created by the response itself. They're easy to miss because the team's attention is on the risk it has just dealt with.use techniques to find these hidden risks
vendor delay"] --> B["Response:
switch to alternative vendor"] B --> C["Secondary risk:
integration issues
with new vendor's API"] B --> D["Secondary risk:
new contract, new
licence terms"] C --> E["Response:
adapter layer;
integration spike first"] style C fill:#FFC857 style D fill:#FFC857
Every response in the register should have a line for the secondary risks it creates, even if that line says "none identified". Writing the line forces the question.
Reserves Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
| Contingency reserve | Management reserve | |
|---|---|---|
| Covers | Known risks, after their responses | Unknown and unpredictable risks; scope changes |
| Sized from | The exposure of the accepted and residual risks | Organisational experience; a percentage of the budget or schedule |
| Controlled by | The project manager | Senior management or the sponsor |
Summing exposures to size a contingency reserve works when there are many independent risks of similar size. When one large risk dominates, the sum understates what that risk would cost if it happened (see Measuring Risk). In that case, plan for the large risk separately with its own contingency, and size the reserve for the rest.
The Risk Management Plan Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
A risk management plan describes how risk management will be done on this project, rather than listing the risks themselves:
| Section | Contents |
|---|---|
| Methodology | The process, tools, templates and data sources |
| Roles and responsibilities | Who identifies, analyses, plans and monitors; how risk owners are assigned |
| Budget | Effort for risk activities; contingency and management reserves |
| Timing | Review frequency; events that trigger reassessment |
| Categories | The taxonomy used (for example process, product and business) |
| Scales | Definitions of each probability and impact rating |
| Risk attitude | Appetite and tolerances (see Risk Attitude) |
| Reporting | Register format, dashboards, burn-down chart |
The inputs come from three places: the organisation's environment (its risk tolerance, industry standards and regulation), its accumulated process assets (lessons learned, templates, policies), and the project's own baselines for scope, schedule and budget. For a small team or an individual project, the whole plan fits on one page; what matters is that the scales and the review schedule are written down before the first risk is rated.
What Goes Back in the Register Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
For each risk: the chosen response, the owner, the trigger, the contingency and fallback plans, the residual risk, any secondary risks, and the time and cost of the response, added to the schedule and budget. The register template has columns for most of these; add the rest as the project needs them.
Related Topics
- Risk Management & Mitigation: the overview and full cycle.
- Measuring Risk: where the priorities and exposures used here come from.
- Keeping Risk Management Alive: watching triggers and checking that responses work.
- Risk Management: Lessons from Testing Real Systems: avoid, reduce and accept decisions made while building real systems.
- Software Architecture Styles: architectural choices and the risks each one reduces or introduces.
References
-
Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK Guide) (6th ed.). Project Management Institute. Section 11.5: Plan Risk Responses. ↩↩
-
Boehm, B. W. (1991). Software risk management: Principles and practices. IEEE Software, 8(1), 32–41. https://doi.org/10.1109/52.62930 ↩↩↩
-
Hillson, D. (2002). Extending the risk process to manage opportunities. International Journal of Project Management, 20(3), 235–240. https://doi.org/10.1016/S0263-7863(01)00074-6 ↩
-
Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press. ↩
-
Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058. https://doi.org/10.1145/361598.361623 ↩
-
Nygard, M. T. (2018). Release It! Design and Deploy Production-Ready Software (2nd ed.). The Pragmatic Bookshelf. ↩
Graduate Attributes
Directly developed
- Critical Thinker: Readers compare the cost of a risk response against the reduction in exposure to decide whether the action is justified.
- Self-Directed Learner: Readers define specific observable triggers and assign owners for contingency plans to ensure timely action.
Modelled on this page
- Subject Specialist: Standard engineering practices are framed as permanent risk responses that reduce probability or impact across projects.
- Reflective: The requirement to record secondary risks forces consideration of the new problems created by mitigation actions.
University of Reading Graduate Attributes framework.