Identifying ICT Risk

Identifying ICT risk means building a clear picture of what could go wrong with the technology behind a financial service, and why it matters to that service. It starts with the service itself, traces the systems, data, people and suppliers that support it, and then considers the threats and weaknesses that could interrupt, corrupt, or expose it. The result is a risk picture tied to a named service, not a generic list of technology hazards.

That picture shapes everything that follows in the framework. Protection is aimed at the risks that matter most for the service, detection watches for the signs of those risks materialising, and recovery is planned around the disruptions those risks could cause. Identification done badly leaves the rest of the framework aiming at the wrong targets, however diligently each later part is maintained.

Identification starts with a service and its users, rather than with a technology inventory in isolation. A lending platform, for example, serves applicants, credit decision makers, and funding operations, and each group experiences disruption differently. Mapping the service in those terms keeps the work anchored in harm to customers and to the entity, rather than drifting into a catalogue of devices and software versions.

From the service, the map widens to the chain that delivers it. Channels, applications, databases, networks, identity systems, and third party services are traced in the order they are used. Dependencies that are easy to miss, such as a shared authentication service or a data feed from a group function, often matter most, because a failure there can affect several services at once. The map is valuable precisely where it reveals a dependency nobody had named.

The risks considered span deliberate attack, accidental failure, and the slow accumulation of weakness. A cyber attack can corrupt data or deny access. A software fault can halt processing. A supplier failure can remove a link in the chain. An ageing system can become harder to patch and harder to recover. A change made for a sound business reason can introduce a new vulnerability. Identification treats those sources together, because a service in disruption rarely cares which source caused the interruption.

Context sharpens the picture. The threat landscape for a trading platform differs from that for a retail savings service, and the data at stake differs too. Identification therefore draws on threat information, incident history, vulnerability information, and knowledge of the systems themselves. A risk picture that ignores the threat context, or that treats all systems as equally exposed, will misdirect protection and detection effort.

Assessment asks how a risk could affect the service, how likely that effect is in the current context, and what existing protections already reduce it. The assessment is qualitative in character, even where it uses structured ratings, because it rests on judgement about a service, its dependencies, and the threat environment. Its purpose is prioritisation: deciding which risks deserve protection, closer watching, or a recovery plan first.

Assessment also needs a record of uncertainty. Some risks are well understood, with a clear chain from cause to service effect. Others are plausible but poorly evidenced, or dependent on a supplier whose own resilience is hard to observe. Naming that uncertainty honestly matters, because it points to where more information, testing, or supplier assurance is needed, rather than letting an unexamined assumption stand in for knowledge.

Identification commonly misses the indirect and the shared. A service that looks self contained may rely on a common platform, a common data centre, or a common supplier used by several services. A risk to that shared element is a risk to every service that uses it, yet it can be recorded against only one service, or against none, if each service is mapped separately. Cross service dependencies therefore need a view above the single service map.

Identification can also miss change. A map made at one point in time becomes stale as systems are replaced, suppliers are changed, and channels are added. Without a routine link between change and identification, new risks enter the service unrecorded and old risks linger in the record after the system that carried them has gone. The identification picture is a living record, not a project deliverable that is finished once.

Identification feeds protection by showing where hardening matters most and where the effect of compromise would be widest. It feeds detection by showing which signs would indicate that a particular risk is materialising, rather than generating alerts for every anomaly. It feeds response and recovery by showing which disruptions are plausible for the service and in what order systems would need to return. It feeds review by providing the baseline against which incident and test lessons are judged.