Helix Precision Components: Building a DR Programme Without Authority
Helix Precision Components operates six plants in three countries and generates €1.4 billion in revenue. Its DR capability consists of nightly backups and a 90-page plan owned by the infrastructure team lead, who also runs the service desk. There is no DR budget line: costs are absorbed into the IT operating budget when incidents occur. After ransomware encrypted two production servers at Plant 3, the CEO told the CIO to 'get ISO 22301 certified within six months' and asked for a programme plan.
The CIO has appointed you as DR programme manager with a part-time analyst and no authority over plant managers. Plant managers say DR is 'an IT problem'; the CFO wants a costed business case before releasing funds; internal audit has flagged the absence of management review three times. You have six months and limited credibility.
1. Define the governance structure you would establish in the first 60 days, including sponsorship, decision rights, roles and policy. Justify each choice.
Read the worked answer
The first task is to move DR from an infrastructure side activity to a governed business programme.
- Executive sponsor: the COO, not the CIO. Plant managers will not accept priorities from IT, and the COO controls operational trade-offs. The sponsor should issue a charter that defines scope, authority, budget and escalation path.
- Steering committee: COO as chair, plus CIO, plant directors, CFO, risk, HR, facilities and the DR programme manager. It approves RTO/RPO tiers, funding and residual risk.
- Accountable owner: a named DR programme manager with a written mandate and direct access to the sponsor. A part-time analyst is insufficient for six plants; request at least one full-time planner and plant-level coordinators.
- Decision rights: business process owners own MTPD, RTO and RPO. IT owns recovery capability and evidence. This prevents IT from inventing recovery targets and prevents plants from declaring everything critical.
- Policy: a one- or two-page DR policy approved by the board risk committee, covering scope, objectives, roles, testing, maintenance and reporting.
- Reporting: monthly dashboard to the steering committee and quarterly report to the board risk committee, covering plan status, test results, open corrective actions and budget.
The structure directly addresses the audit finding: management review becomes a scheduled governance event with recorded decisions, not an occasional IT briefing.
2. Assess the CEO's goal of ISO 22301 certification within six months. What would you propose instead, and how would you manage the CEO's expectation?
Read the worked answer
Certification is a conformity assessment of a management system; it is not proof of recovery capability. Six months is possible for a narrowly scoped management system where processes already exist and leadership is engaged. It is not realistic to certify six plants across three countries when there is no budget line, no business ownership, no exercise programme and no management review history.
The risk of accepting the goal uncritically is a paper certification: documents written for an auditor, no tested recovery, and a false sense of assurance that collapses in the next incident. That would also damage credibility with the CFO and internal audit.
A defensible proposal:
- Months 1-2: gap assessment, charter, policy, scope statement and business-led BIA for one pilot plant and one critical product.
- Months 3-4: recovery strategies, plans and a first exercise for the pilot scope.
- Months 5-6: internal audit, management review and certification audit for the pilot scope only.
- Months 6-18: extend to the remaining plants in waves, with enterprise-wide certification as a later goal.
When communicating with the CEO, separate the two outcomes explicitly: certification can be achieved for a defined scope, while enterprise resilience will take longer. Ask the CEO to approve the scope and to state publicly that certification is a milestone, not the objective.
3. How would you build the business case and secure recurrent funding, given that the CFO wants costs before releasing funds and there is currently no DR budget line?
Read the worked answer
The business case should speak in the CFO's language: exposure, options and risk reduction, not technology preferences.
- Quantify current exposure. Use the ransomware incident and any prior outages to estimate downtime cost per plant per hour: idle labour, lost output, scrap, overtime, contractual penalties and customer churn. Add insurance deductibles and regulatory or customer audit consequences.
- Show the gap. Compare current recovery times with the MTPD and RTO implied by customer contracts and production dependencies. The nine-hour or multi-day restore from nightly backups is the baseline.
- Present options. A minimum option that addresses audit and contractual exposure; a risk-reduction option for the highest-impact plants; and an optimisation option. For each, give capital cost, recurring cost, expected recovery improvement and residual risk.
- Fund maintenance, not just build. Include testing, plan maintenance, training and exercise facilitation, typically a recurring percentage of the build cost. A DR programme with no maintenance budget will decay within a year.
- Stage the release. Ask for funding for the gap assessment and pilot first, with later tranches tied to evidence such as completed BIA, tested recovery and closed audit findings.
- Link to governance. The steering committee approves the business case, and the board risk committee records the accepted residual risk. This gives the CFO assurance that spending is governed and that unresolved risk is visible.