Guiding a multi-year risk mitigation program across the finish line
The Situation
A global bank had a number of risk and audit findings around technology change management, which collectively created the impression to regulators, investors and clients of an uncontrolled environment where things could and would go wrong. This impression was amplified by real-life incidents including a change-related outage that took ATMs in the bank’s home market out of action.
The technology division was given funding to run a large program including organisational changes, new processes and migration from multiple change and incident management tools to a single unified platform. Six months away from the deadline, it became apparent that the delivery teams had no idea how to prove that what they were delivering was adequate to address the specific risk and audit findings.
The Task
As a technologist who had recently moved into the risk function I was asked to provide assurance to get the program over the line. As the technology risk function was itself new and still forming, I was given no guidane and expected to figure it out myself.
The Action / Approach
It was clear to me that this was fundamentally a translation problem, or a matter of mapping requirements that were expressed in the language of risk and audit to deliveries phrased in the language of technology, tools and processes.
I reviewed the details of each specific risk and audit issue, as well as the “umbrella” issue that was being used to track them, discussed with SMEs and captured the specific deliverables that would be required to demonstrate that the issue had been addressed – not just forward-looking statements of intent but evidence that a) what had been delivered resolved the issue, and b) it was operating in a sustainable way such that the issue would not recur.
I identified gaps in the existing delivery plans – some of these would have led to issues remaining unresolved, while others would have resolved them but without providing auditable evidence of this, which was equally important. I reviewed these gaps with the delivery leads for the three key areas (change approval, testing and production support operating model) and obtained agreement to update the plans where necessary. For instance, to address the issue of “segregation of duties” between development and production support staff, it was not enough to create dedicated teams with some developers who had previously done support tasks moving into the support team – it was also necessary to ensure that no support staff had access to development environments where they could modify code that would be released to production, and conversely no development staff had access to support tools where they could deploy code to production or otherwise modify production environments. Similarly, it was not enough to create a testing standard to be followed for all changes, but it was necesary to capture evidence that this had actually been followed prior to a change being approved.
As the deadline drew closer, I instituted regular review calls and performed quality review on all evidfence of completion as it became available. I stayed in close contact with the managing director in charge of the overall program, with his complete support for everything I asked the teams to do.
The Result
The program was a complete success, finishing on time passing formal review by the risk and audit functions and being signed off by the Group Executive Board. It created a foundation of operating practices and quality standards that are still in place.
