DORA Lead Manager study materials
DORA Lead Manager study resources

Four inventories, no business impact analysis, and an accountability conflict

DORA Lead Manager · Put your knowledge to work in context.

All case studies

Four inventories, no business impact analysis, and an accountability conflict

Corvus Bank is a cooperative bank with EUR 9 billion in assets and 1,700 ICT assets recorded across four inventories: a CMDB maintained by infrastructure, a vendor list held by procurement, a spreadsheet of internally developed applications, and an application register owned by the business. A reconciliation found 214 assets appearing in only one source and 38 applications with no named owner. The ICT risk register holds 90 risks scored on a 1-5 likelihood scale that three teams interpret differently; 12 risks have been marked as mitigated for more than two years without supporting evidence. There is no business impact analysis; recovery time objectives were inherited from a 2017 disaster recovery plan and have never been validated. Critical business functions are defined as departments rather than processes. DORA implementation is being run by the head of IT operations, who reports to the CIO - the same person accountable for delivering the systems being assessed. The supervisory authority has asked in writing for the bank's approach to ICT risk management.

1. Diagnose the framework weaknesses and map them to what the regulation requires.

Read the worked answer

Every symptom here maps to a specific framework requirement.

  • Four inventories (Art. 8, identification). The regulation requires identification of ICT-supported business functions, the assets supporting them and their dependencies. Four unreconciled sources means no single source of truth and no reliable dependency map. Fix: one register keyed to business functions, with defined data ownership and quarterly reconciliation, retiring the others rather than adding a fifth.
  • 38 unowned applications (governance). Every asset needs an accountable owner and a risk owner. Unowned systems cannot be risk-assessed, patched on schedule or included in testing.
  • Risk register calibration (Art. 6). A 1-5 scale interpreted differently by three teams cannot be aggregated, compared or reported. Write definitions with worked examples for each point on the scale, and recalibrate the existing 90 risks in one exercise.
  • Twelve risks mitigated for two years without evidence. The defect is closure criteria. A risk closes only against documented evidence, is revalidated on a schedule, and reverts if the control lapses.
  • No BIA, 2017 RTOs (Art. 11 and 12). Recovery objectives must derive from business tolerance for disruption, not from what IT found achievable in 2017. The unvalidated RTOs are the most dangerous item in the list because everyone downstream plans against them.
  • Critical functions defined as departments. The regulation works on business functions and their dependencies. Redefine as processes with owners, then map assets and providers downward.
  • Missing annual review (Art. 6). The framework must be documented and reviewed at least annually and after significant incidents.

Framing for the response: these are not documentation gaps, they are the reason the bank cannot currently demonstrate that its resilience posture matches its risk appetite. That is the sentence the supervisor is testing for.

2. The head of IT operations runs DORA implementation and reports to the CIO, who owns delivery of the systems being assessed. What are the options and their trade-offs?

Read the worked answer

This is a structural conflict. The person accountable for the controls under assessment also benefits from a favourable assessment. Practical consequences: risk acceptance will not be escalated honestly, testing findings will be softened at the drafting stage, and the supervisor will conclude the second line is not independent.

Options:

  • (a) Move ICT risk management into the second line, reporting to the CRO or a dedicated head of operational resilience, with a dotted line to the CIO. Cleanest structurally, but requires hiring or promoting a credible owner; three FTE is thin and the bank must fund the gap.
  • (b) Split implementation from assessment. Put the programme PMO under the COO with the CIO as one workstream owner, and place ownership of the ICT risk framework in risk. Delivers independence without a large hire, but only works if the risk function has enough ICT literacy to challenge rather than transcribe.
  • (c) Interim measures. An independent chair for the ICT risk committee plus co-sourced internal audit coverage for the first year, with a dated commitment to a permanent structure.

Non-negotiables whichever option is chosen: the management body formally approves the framework and the risk appetite and remains accountable; the reporting line to the board does not run through the CIO; the three lines are documented - IT operations first, risk and compliance second, internal audit third with genuine ICT capability. Co-sourcing audit is a reasonable stopgap, but the board must not treat a co-sourced report as permanent independent assurance.

3. Draft the substance of the written response to the supervisory authority: what to admit, what to commit to, and in what order.

Read the worked answer

Structure it as diagnosis, commitments with dates, and governance evidence - not reassurance.

1. Current state, stated plainly. Four inventories, 214 single-source assets, 38 unowned applications, no BIA, RTOs inherited from 2017 and never validated, risk scales not calibrated, 12 risks closed without evidence. Do not present the 2017 disaster recovery plan as an ICT recovery plan; the supervisor will find out and the credibility loss is worse than the admission.

2. Remediation plan with owners and dates.

  • Single asset and dependency register, reconciled and owned, with a completion date.
  • BIA covering the functions behind payments, deposits and lending first, with recovery objectives derived from it.
  • Recalibrated risk taxonomy and revalidation of the 12 closed risks.
  • Defined critical business functions as processes with owners, mapped to assets and providers.

3. Governance change. Independent ownership of the ICT risk management function, management body approval of framework and risk appetite, documented three-lines model, and credible audit capability.

4. Proportionality rationale. Explain why the sequence matches the bank's size and risk profile, and why the BIA is top-down rather than covering all 1,700 assets at once.

5. Evidence trail. Dated documents, decision logs, and a first progress report at 90 days.

What supervisors read for: whether the management body understands the gap, whether commitments have real dates and named people, and whether the bank is being straight. A bank that admits no BIA exists and commits to one by a date is in a stronger position than one that re-describes a DR plan. Expect follow-up testing of the inventory and the BIA outputs, so the plan must produce verifiable artefacts, not narrative.