Every serious initiative carries risk and rests on dependencies you do not fully control. A strong business case does not try to hide this. Instead, it shows that you have a disciplined view of what could go wrong, who and what you depend on, and how you will manage both. This chapter gives you a practical framework to build that view: a risk taxonomy anchored in your organization’s appetite, a way to map dependencies and critical path, guidance on mitigations and residual risk, a step-by-step guide to building the risk register, and a checklist you can use before sending your case to any risk-sensitive audience (CFO, CRO, CIO, Board, or regulator).
13.1 Risk Taxonomy and Appetite
You cannot manage “generic risk.” You manage specific categories, with a shared language. A risk taxonomy and a clear sense of risk appetite are the foundation.
Simple risk taxonomy for business cases
You do not need an enterprise-risk textbook. For business cases, you usually need these categories:
- Strategic risk
Whether the initiative is the wrong bet, or becomes misaligned with strategy or market reality (e.g., technology obsolescence, demand shift, regulatory change). - Financial risk
Funding availability, cost overruns, weaker-than-expected benefits, FX exposure, working capital strain, impact on covenants or ratings. - Operational risk
Process failures, execution issues, quality problems, business disruption during transition, key person risk, vendor execution failures. - Technology & cyber risk
System instability, integration failures, data migration errors, security vulnerabilities, outages, performance issues. - Regulatory & compliance risk
Breaches of laws, regulations, standards, or internal policies (e.g., data privacy, prudential rules, conduct, safety, environmental). - People & change risk
Low adoption, resistance to change, talent shortages, labor relations issues, cultural misfit. - Reputational & stakeholder risk
Negative media, customer backlash, NGO scrutiny, community impact, political sensitivity.
For each risk you identify, tag it with one or more categories. This makes review and ownership easier: the CISO will look hard at Technology & cyber; Compliance at Regulatory; HR at People & change, and so on.
Risk appetite: how much is acceptable
Your organization has (or should have) a risk appetite: the level and type of risk it is willing to accept in pursuit of its objectives.
In a business case, you should show:
- Which risk categories this initiative materially affects (up or down).
- Where the current risk level is vs. appetite (e.g., already high operational risk in a given process).
- How the initiative will move the needle (e.g., reduce cyber risk but increase vendor dependency).
Avoid suggesting that zero risk is possible. Instead:
- Indicate when residual risk is within appetite (“after mitigations, outage risk is within our stated tolerance”).
- Flag when it may be at or above appetite and needs explicit sign-off or additional controls.
If your organization has formal ratings (e.g., Low/Medium/High appetite in specific categories), use that language. It reassures risk and audit that you’re playing by house rules.
13.2 Dependency Mapping and Critical Path
Dependencies are everything you do not directly control but that must go right for the initiative to succeed. Many “surprise failures” are actually unmanaged dependencies.
Types of dependencies
Common dependency types:
- Upstream initiatives
Other programs that must deliver capabilities before (or as) your case can succeed (e.g., data platform, new CRM, regulatory remediation). - Downstream initiatives
Programs that rely on your initiative’s output (e.g., analytics use cases relying on your data platform). - External parties
Vendors, partners, regulators, landlords, external IT providers, joint-venture partners. - Internal functions
Shared services such as IT, data, finance operations, HR, legal, procurement, facilities, call centers. - Approvals and decisions
Regulatory approvals, security certifications, architectural sign-offs, union agreements, privacy assessments.
Each dependency should answer: “If they do not deliver what we expect, what happens to our cost, timing, risk, or benefits?”
Critical path vs. “nice to have”
Not all dependencies are equal. Focus on the critical path:
- Activities or dependencies where delay or failure will delay or block benefits.
- Single points of failure (e.g., only one team can perform a specialist task; only one vendor can supply a critical component).
A simple way to identify critical path for the case:
- Start from the go-live / benefit-realization date and work backward: what milestones must be met?
- For each milestone, list pre-conditions (e.g., design sign-off, procurement complete, data migration).
- Ask: “If this slip by a month, does the overall case slip?” If yes, it is on your critical path.
Your business case should:
- Name the top few dependencies explicitly in the main body.
- Show how they relate to the roadmap (e.g., a visual with dependencies annotated).
- Assign an owner for managing each dependency.
Do not hide critical dependencies in an appendix; that’s how they become “unknown knowns” that surprise executives later.
13.3 Mitigations, Contingencies, and Residual Risk
Once you have risks and dependencies, the point is not to create a long list—it is to design how you will manage them.
Mitigations
Mitigations are actions that reduce the likelihood or impact of a risk.
Good mitigations:
- Are specific actions, not aspirations (“run performance tests before go-live,” not “be careful with performance”).
- Have owners and dates.
- Are proportionate to risk: bigger risk → stronger, earlier mitigation.
Examples:
- Operational: “Introduce phased rollout by region to limit impact of defects.”
- Technology: “Run full production-like load tests before cutover; add auto-scaling thresholds.”
- Regulatory: “Obtain data protection impact assessment and legal sign-off before collecting new customer data.”
- People: “Identify and train super-users in each site; incentivize adoption in performance goals.”
Mitigations often become tasks in the roadmap and controls in governance. Make sure they show up there, not just in the risk register.
Contingencies
Contingencies are pre-planned responses if a risk does materialize:
- Alternative suppliers or backup vendors.
- Manual work-around processes if systems fail.
- Additional budget that is only released under specified conditions.
- Rollback plans if pilot or rollout fails.
For major risks, having a written contingency (“If X happens, we will do Y”) gives boards and risk committees much more comfort.
Residual risk
Residual risk is what remains after mitigations. This is the risk decision-makers actually need to sign off on.
For each top risk:
- Estimate likelihood and impact after planned mitigations.
- Explain briefly why residual risk is acceptable (e.g., within appetite, outweighed by value, further reduction would be uneconomic).
- If residual risk is still high, say so and invite explicit sign-off.
Avoid implying mitigations and remove risk entirely. “Reduced to low likelihood / medium impact” is credible; “eliminated” almost never is.
13.4 Step-by-Step Risk Register Build Guide
You already saw the template earlier in the playbook. Here’s how to build and use it, step by step.
Step 1 – Set scope and time horizon
Clarify:
- The initiative scope (systems, processes, geographies, products).
- The time horizon for risk assessment (typically the case horizon plus at least 12–24 months of steady state).
This ensures you look beyond go-live to operational risk in BAU.
Step 2 – Initial risk identification workshop
Convene a short session (60–90 minutes) with:
- Sponsor and case lead.
- Finance partner.
- Technology/architecture lead where relevant.
- Risk/compliance, security/privacy, data, operations, and change leads.
In the session:
- Walk through the end-to-end flow: current state → change activities → future state.
- Use the risk taxonomy categories as prompts.
- Capture risks in simple form first: “What could go badly wrong here?”
At this stage, do not be a wordsmith; just get the universe of concerns out.
Step 3 – Clean up and classify
After the workshop:
- Remove duplicates and merge similar risks.
- Classify each risk:
- Category (strategic, operational, tech, etc.).
- Owner (who is best placed to manage it).
- Distinguish issues (already happening) from risks (may happen). Issues belong in your baseline and plan, not as future risk.
Aim to get to a manageable list (e.g., 15–25 risks total, of which 5–10 are top-tier).
Step 4 – Rate inherent likelihood and impact
For each risk, before mitigation:
- Rate likelihood: Low / Medium / High (or 1–5).
- Rate impact on cost, schedule, quality, customers, or compliance: Low / Medium / High.
- Use simple guidance (e.g., “High impact = could move NPV by more than X or cause regulatory breach”).
You can use the enterprise risk scoring method if one exists; otherwise, keep it simple and intuitive.
This gives you an inherent risk rating—your honest view if you did nothing beyond business as usual.
Step 5 – Define and assign mitigations
For the more material risks (e.g., Medium/High or anything that worries the sponsor):
- Identify mitigating actions: what will you do, by when, to reduce likelihood or impact?
- Assign an owner for each mitigation (not always the same as risk owner).
- Link key mitigations into your roadmap (e.g., “complete penetration test before Pilot gate”).
Document mitigations inside the risk register and also reflect them in your implementation plan so they are not forgotten
Step 6 – Re-rate residual risk
Once mitigations are in place:
- Re-assess likelihood and impact after you assume mitigations are executed.
- Record residual risk rating for each item.
- Compare residual ratings to risk appetite (e.g., any High residual risk in a category where appetite is Low must be explicit to decision-makers).
At this point, identify the top 5–10 residual risks that could move the decision or require special attention.
Step 7 – Map dependencies and link to risks
Now build or refine your dependency map:
- List major dependencies (upstream, downstream, internal, external, approvals).
- For each dependency, ask “If this fails or is delayed, what risk does that create?”
- Either link dependencies directly to existing risks (e.g., “Regulator approval delay” → schedule and regulatory risk) or add new risks as needed.
In your register, you can either:
- Include dependencies as separate risk entries, or
- Have a separate dependency column that links risks to dependencies.
The key is traceability from “who/what we depend on” to “what risk that creates.”
Step 8 – Define contingencies for top risks
For each of the top residual risks:
- Write a short contingency plan: “If risk R occurs, we will do X, led by Y, with Z resources.”
- Estimate rough cost/impact of the contingency if used.
- Where appropriate, treat contingencies as options (e.g., “if adoption lags in Q2, we will invest additional $X in targeted training and incentives”).
Include brief reference to these contingencies in the case narrative, especially for risks boards worry about (cyber, outages, regulatory breaches).
Step 9 – Integrate into governance and stage gates
Your risk register is not a static appendix; it is a living tool:
- Use it to define gate criteria (e.g., Gate 1 occurs only once specific risks are reduced or mitigations complete).
- Attach it to steering committee packs, updating ratings and statuses regularly.
- Tag which risks are escalation candidates if they deteriorate (early warning metrics).
This makes risk management part of the initiative’s DNA, not a one-time compliance exercise.
Step 10 – Distill for the main business case
Finally, from the full register:
- Select the 5–10 most material risks and 3–5 most critical dependencies.
- Present them succinctly in the main body of the case:
- Risk description.
- Category.
- Residual rating.
- Key mitigations.
- Contingency (if significant).
- Keep the full register in the appendix, referenced from the risk section.
Decision-makers should see enough to be confident the team has done the work, without being overwhelmed by tables.
13.5 Risk & Dependency Checklist
Use this checklist right before you submit your case.
Risk coverage and taxonomy
- Risks from all major categories (strategic, financial, operational, technology/cyber, regulatory/compliance, people/change, reputation) have been considered.
- At least the top 5–10 risks are clearly described in the main case; the full list is in an appendix.
- Each risk has a clear, specific description (event + cause + consequence), not vague labels (“IT risk,” “change risk”).
Risk appetite and residual risk
- For key risks, inherent (pre-mitigation) and residual (post-mitigation) levels are distinguished.
- Residual risk is compared against risk appetite (explicitly or implicitly) and any areas at or above appetite are called out.
- The case explains why residual risks are acceptable (or what further actions are planned).
Dependencies and critical path
- Major upstream and downstream initiatives are identified, with owners and timing.
- Key external dependencies (vendors, regulators, partners) are named.
- The critical path is clear, and dependencies that could delay benefits are highlighted.
- The link between dependencies and specific risks is visible (e.g., dependence on Vendor X → risk of delay or cost overrun).
Mitigations and contingencies
- Each top risk has at least one concrete mitigation with an owner and target date.
- Mitigation actions appear in the implementation roadmap, not just in the risk register.
- For the most material risks, contingency plans exist and are briefly described.
- Costs or impacts of contingencies, where significant, are understood and, if needed, reflected in downside scenarios.
Integration with economics and plan
- Major risks that could significantly shift economics (costs, benefits, timing) are reflected in scenarios and sensitivities.
- Risks with strong timing implications (e.g., approvals, vendor lead times) are tied to the calendar in the roadmap.
- Any risks that drive additional costs (e.g., extra controls, insurance, remediation) are included in the cost model where appropriate.
Ownership and governance
- Each risk has a named owner accountable for managing it.
- Risk and dependency topics are built into the governance cadence (steering, design authority, risk reviews).
- Thresholds for escalation (e.g., if certain KRIs or milestones slip) are defined.
Quality and credibility
- The risk section avoids hand-waving (“we will manage this carefully”) and uses specific, testable statements.
- There is no attempt to suggest risk can be reduced to zero; residual risk is acknowledged.
- Risk language and categories align with your organization’s enterprise risk framework, where one exists.
- Risk partners (Risk, Compliance, Security, Data Privacy, Internal Audit as appropriate) have reviewed or been consulted.
If you can walk through this checklist and honestly tick the items, your “Risks, Dependencies & Mitigations” section will give decision-makers what they need: confidence that the team has looked around corners, is candid about uncertainties, and has a practical, proportionate plan to manage them—rather than pretending they don’t exist.
