ICT risk management framework integrated with ERM

Context

Organisation

A medium-sized retail and SME bank in a rapid growth phase, running several digital programmes concurrently — among them a cloud migration and changes to core IT systems.

Growth of this kind has a characteristic effect on process. Arrangements that worked acceptably while the organisation was smaller, held together by the judgement of the people running them, begin to require formalisation as headcount rises and interactions between departments become more complex — methodologically and politically. The formalisation already in place had been built for a smaller organisation, and in several areas obstructed the work more than it provided a baseline for it.

Environment

A heavily regulated and competitive banking market with strong emphasis on the digital side of the business. The applicable requirements came from at least seven sources of differing legal status: the supervisor’s IT risk recommendation, issued years earlier and never revised; a cloud-specific supervisory communiqué published the previous year, which developed and detailed that recommendation rather than replacing it; the outsourcing regime in banking law; the European banking authority’s outsourcing guidelines; data protection law; the national transposition of the NIS Directive; and a comparable number of ISO standards and market practices.

Together these formed an unevenly defined amalgam. Some requirements, if interpreted literally, compounded into a shape that practically paralysed the bank’s operations. Others contradicted one another. None specified how an ICT risk operating model should look, or how it should sit inside a holistic enterprise risk management framework. The regulation that would eventually answer that question directly had been published as a Commission proposal the previous September. It carried no deadline, no certainty as to final shape, and would not apply for another four years. Nothing in the applicable stack required designing towards it.

Competitive landscape

ICT risk management affects a bank’s competitive position indirectly, but the effect is substantial, given the weight placed on systems resilience, data integrity and strong authorisation requirements. It remains invisible and apparently insignificant until an incident occurs, at which point the sector is reminded of it at once.

For an institution pursuing rapid growth, the cost is visible long before any incident, in the conduct of project and change management: prolonged time to market readiness, inconclusive risk committee discussions, unclear division of responsibility between compliance and security functions, and commercially attractive initiatives rejected by an approach more risk-averse than the risk warranted. For a large institution with an established position, this is troublesome and expensive. For a smaller one that needs to sustain tempo, it is existential.

Problem

Situation

A large cloud migration was scheduled to begin five months out. A risk management and control framework had to exist before it started, to be used for the migration itself. Ahead of that, the bank intended to use projects then reaching completion as an acid test of the new approach — to verify both the spectrum of risk visibility it produced and its pragmatism, meaning whether it could actually be operated by the people who would have to operate it.

Boundaries

Compliance with the full applicable regulatory stack, including the outsourcing regime — which matters more than it appears, since where banking secrecy is involved, cloud arrangements generally fall under outsourcing rules. The migration and the outsourcing regime were one problem, not two adjacent ones. COBIT 5, ISO 27001, ISO 27005 and ISO 31000 served as reference frameworks. The framework had to be usable in departments with high personnel turnover, which set a hard ceiling on how much of its operation could depend on accumulated familiarity.

Constraints

The control layer had to remain effective without depending on the goodwill of the people it constrained. Risk decisions in project work sit with individuals whose performance is measured on delivery, and any control that can be quietly set aside under schedule pressure will be. The design also had to be introduced without taking operational functions offline. Several elements the framework required — reclassification of existing contracts in particular — represented weeks of work if approached as a single exercise, in an organisation that could not spare the capacity.

Objective

As commissioned: update the project risk management process and the risk assessment questionnaire supporting it.

Solution

My role

Security architect and management consultant, working as the sole consultant on the engagement. Three months for assessment and design, approximately six weeks for testing and handover.

Reasoning

External parties cannot be instructed, but their decisions can be constrained at the points where the relationship is defined. That places the external layer inside procurement, contracting, third-party management and outsourcing oversight rather than inside a separate vendor risk process, and it is why those existing processes had to be hardened rather than supplemented.

A framework whose observance depends on goodwill is a set of recommendations. In an organisation with high turnover and rising headcount, goodwill does not scale and cannot be audited. The framework therefore needed rules that hold when the people applying them would prefer they did not — enforceable without relying on anyone’s account of their own conduct.

Quantification was used wherever an analyst could reasonably produce it. Where they could not, the alternative was structured judgement: standards and detailed questionnaires covering a defined spectrum of threats and compliance gaps, so that the qualitative path produced comparable output rather than personal opinion.

Reframe

The commissioned scope assumed that ICT risk enters the organisation at one point, and that a better process and a better questionnaire at that point would be sufficient.

Early assessment did not support that assumption. ICT risk emerges at several distinct points: project and IT change management, which expand the existing exposure landscape with every initiative; everyday operational work, where incidents accumulate and entropy grows if left without deliberate control; the strategic level, where risk functions as a compass for the board in assessing which directions are available; and an external layer of suppliers, vendors and partners, whose activities cannot be directed as internal actors can.

Rather than propose a framework as a predetermined answer, target components were put to the client one at a time as the review of the operating structure surfaced the need for each. The scope grew by agreement, component by component. What accumulated was a full ICT risk framework integrated with enterprise risk management — a shape the engagement had not started with and did not assume.

Solution architecture

Reference material included COBIT 5, ISO 27001, ISO 27005 and ISO 31000 as mandated, together with elements of FAIR, PMBOK and ITIL and material from the CISM body of knowledge. FAIR was not required by anything in the applicable stack; it was used as a model of good practice for decomposing exposure.

The target architecture introduced three new processes — project risk management, IT change risk management, and information security risk management — hardened five existing ones — procurement, contracting, third-party management, audit and governance — updated a broad set of internal standards, and introduced three assessment questionnaires covering compliance, technical and organisational risk.

Decision layer

ERM integration. ICT risk taxonomy was mapped into the bank’s existing risk categories rather than given a parallel branch of its own. Reporting ran on two tracks: individual risks whose impact exceeded what an initiative leader could reasonably carry escalated to the risk committee, alongside periodic aggregate reporting and standing disclosure of residual exposure that could not be worked down further.

Assessment and decision rights. Severity was expressed as a financial range wherever an analyst could estimate one, and on a four-level scale where they could not. The top level obliged verification by the initiative sponsor, which in practice meant board level. Every assessment carried three separated roles: an identifying role accountable for completeness of the picture, a managing role accountable for selecting mitigations, and a verifying role looking at the plan and its subsequent implementation as a whole — embedded in the iteration for severe cases, and conducted periodically otherwise.

The register rule. A business owner could not remove a risk from the register. Removal was possible only where the underlying threat had been disproven, and required formal approval, recorded. The rule was designed to be enforceable by audit through cross-interviews, so that a risk quietly dropped by agreement between two parties would surface when a third was asked about it independently.

New initiative risk assessment. The assessment was split in two. An initial pass at initiation and partly at design fed scope and budget estimation, making risk an input to the feasibility study rather than a review of a decision already taken. A detailed pass between solution architecture and implementation resolved the register to its final form, and carried the authority to return an initiative to redesign of its assumptions where the two passes diverged materially. In practice that authority was exercised only in the most serious cases, given the cost of rework — but its existence changed what the second pass was for.

Gating. Control points ran at initiation, design and architecture, then iteratively through implementation. Completion of testing was conditional on evidence that every planned mitigation had been implemented, which closed the distance between the register and the system.

Scope and interfaces

Cloud path. Where a questionnaire detected a cloud component, it expanded — additional questions, and a mandatory control by the compliance function.

Classification and the supplier register. IT components, processes, suppliers and data were classified. The framework specified a supplier register and its necessary elements, but deliberately did not produce it as a one-off asset. Reclassifying the existing contract base as a single exercise would have taken the commercial function out of operation for weeks. Instead the register was designed to accrete: mandatory classification of every new contract, plus periodic review of existing ones, sequenced so that the cost fell in increments the organisation could absorb.

Interfaces. Risks with the potential to affect operational continuity were identified as such and routed to the business continuity management process. Designing that area was outside scope; the framework was aligned to its reference model. Incident classification attached to the existing incident management process rather than introducing a parallel taxonomy.

Implementation

Delivery ran in small batches, with the client’s team participating throughout — different department leaders according to the stage in hand — so that the people who would own the framework afterwards had built parts of it.

Once complete, the framework was used to reassess initiatives already in flight. At that stage the consulting role was deliberately reduced to shadowing the key stakeholders and updating assessment templates in line with what surfaced.

That sequence was a design decision rather than a delivery convenience. A specification’s meaning is underdetermined until someone other than its author operates it: passages that read as unambiguous to the person who wrote them turn out to admit several readings in practice. Handing over a finished design, then staying quiet and watching it being used, surfaces a class of error that no amount of review by the author will find.

Result

Outcome

Partial deliverables were accepted progressively by the CISO; the completed framework then passed through the compliance and IT directors.

The testing stage did more than confirm applicability. Applying the framework to live initiatives surfaced gaps in cloud contract scopes, gaps in audit evidence, and unassigned responsibilities — and moved forward several initiatives that had been stalled in review. Those findings fed back into the design before handover.

Representatives of the IT, audit and compliance teams who took part in the build acquired a working understanding of the architecture and the reasoning behind it, which was the condition of the incremental improvement the framework assumed would follow.

Business impact

Three years later the client returned with a new engagement, scoped as a review of the existing design against the requirements of the regulation that had by then been adopted, and requesting the original author rather than a delegate. A scope framed that way rests on the design still being in force.