Interim Chief Information Officer — Technology Controls

Dependency is a risk, not just a cost

Every bank depends on something it cannot easily replace: a core banking platform, a vendor's proprietary integration layer, a handful of engineers who understand a critical batch process, a cloud service configured in ways nobody has written down. Dependency of that kind is usually discussed as a cost problem. It is more usefully seen as a control problem, because it determines what the bank can change, how quickly it can recover and what it can prove to a supervisor about its own resilience.

Architecture choices that do not freeze the roadmap

The hard part is that dependency cannot be reduced by stopping delivery. Customers, product teams and regulators expect change to continue. The Interim Chief Information Officer's task is to loosen the most dangerous dependencies while the delivery commitments already made are still met. That is a sequencing problem: choosing which dependency to tackle first, which new delivery to route through new patterns and which to leave on old ones for now, and being explicit about the risk carried in the meantime.

What an interim chief information officer can decide

The appointment carries executive authority, and its first use is structural: you will set how technology decisions are allocated and what local teams may decide for themselves, and fix the measures by which technology spending, capacity and controls are governed. Which technology commitments continue is yours to decide; you will block proposals that move cost or risk while leaving no one accountable, and decline investment where adoption, operating dependency or the downside is missing. You will approve the technology leadership structure and the way incidents and exceptions climb to you.

Dependencies mapped, loosened, owned

In the first ninety days, critical technology dependencies should be mapped, architecture principles agreed and someone accountable for controls on each core platform. Around month nine, architecture changes aimed at the highest-risk dependencies should be under way, and the delivery commitments that existed when you arrived should still be on track. By month 24, a less dependent architecture should be operating, with technology controls tested and owned within the CIO's leadership team rather than held by you personally.

Someone who has changed the plumbing while the water ran

You have run technology for businesses with at least $835 million in revenue, 1,600 or more staff and a presence in five countries, and during a cost transformation you reset who held authority, how technology was funded and how often delivery was reviewed. Your judgement has been tried on platforms that had to keep running while ownership moved. The bank will weigh your record in cost transformation, digital transformation and restructuring. Risk judgement is wanted at level 4; at level 3 it wants architecture at scale, AI and data governance, and product delivery. What is unresolved you report as unresolved, without letting it slow the work. You accept that an early win may be a stopped commitment, you will act ahead of unanimous country-leader consent, and you expect accountability for the full term.

Four stages to appointment

Stage one, in the first week, is a confidential conversation by video with the Group Chief Executive Officer. The Risk Committee Chair follows in week three, working through with you how architecture risk should be reported. Week five gathers, in person, executive leaders from each function whose delivery depends on your choices; in week 7 you meet the board's directors. Allow up to four working days after each stage for our response, which will come in writing.