Unsupported payment switch and failed restore at a retail bank

Ranking. First, the backup and recovery gap: backups sit on the same array as production, the last restore test failed and the DR runbook cannot meet the 4-hour BIA objective. This is the most serious because it removes the bank's ability to recover card authorization within its own impact tolerance. A failure or ransomware event could cause an extended outage across a critical payment service.

Second, the unsupported operating system with a 14-day patch cycle. This creates a high-likelihood compromise path, especially if the switch is reachable from other networks. DORA expects asset management, vulnerability and patch management, and secure configuration. An unsupported platform is not automatically prohibited, but it requires documented compensating controls and a migration plan.

Third, shared domain administrator accounts. This weakens accountability, enables lateral movement and makes containment harder. DORA's access-control expectations require least privilege, unique identities and monitoring of privileged activity. It ranks third only because it is more containable than the recovery gap and does not by itself create the same outage impact. The CTO is wrong to treat migration and backup testing as alternatives; both are needed, but recovery testing should start immediately because it protects the bank during the migration.

Evaluation. An 18-month acceptance cannot be a verbal or implicit decision. It must be a documented, time-bound residual risk acceptance based on the bank's ICT risk appetite, with an owner, review dates and exit criteria. The board should not accept the risk merely because migration is expensive. It should ask whether the bank can remain within its impact tolerance if the switch is compromised or unavailable.

Compensating controls. Isolate the switch in a segmented network with strict firewall rules; remove shared admin accounts and enforce unique privileged accounts with multi-factor authentication; restrict internet exposure; apply virtual patching or vendor-supported extended security updates if available; add endpoint detection and 24/7 monitoring for the switch; isolate backups from production and test restoration quarterly; update the DR runbook and validate the 4-hour objective. The migration plan should have milestones, a fallback plan and a board-approved deadline.

Board decisions. Approve or reject the residual risk, approve the interim controls budget, require monthly reporting on control effectiveness, and define the trigger for escalation if migration slips. The regulator should see evidence of the risk assessment, the acceptance and the remediation plan, not just a statement that migration is underway.

The BIA should define the criticality of card authorization and the maximum tolerable disruption. The 4-hour BIA objective and the 12-hour DR runbook are inconsistent, and that inconsistency is itself a control gap. Helios should not simply change the BIA to match the runbook, because that would hide the operational risk. It should first validate the BIA with the business, then either engineer recovery to meet 4 hours or document why the business can tolerate 12 hours and obtain approval for the changed impact tolerance.

The ICT risk assessment should record the scenario: unavailability or compromise of the card switch, the affected customers and transactions, the current recovery capability, the gap to the BIA objective and the remediation actions. The assessment should drive the continuity plan and testing schedule. DORA expects the BIA to inform the ICT risk management framework and continuity arrangements, so the conflict should be resolved before the next supervisory submission, with evidence of business sign-off and test results.