Legacy ICT Systems and Risk

Legacy ICT systems are systems that remain in use beyond the period for which they were designed, supported, or documented, and that carry risk because of that age. The risk is not age itself. It is what age brings: limited supplier support, difficulty in patching, scarce knowledge among staff, fragile integrations, and recovery arrangements that no longer match the system as it runs. Under DORA, legacy risk is managed as part of the single ICT risk management framework, in relation to the services those systems support.

A legacy system that supports a critical service deserves attention proportionate to that service, not to its age alone. Some legacy systems are stable, well understood, and adequately protected. Others are fragile, poorly documented, and central to a service whose disruption would harm many customers. Distinguishing those cases, service by service, is the core of legacy risk management.

Legacy risk arises gradually. A system built for an earlier operating environment continues to run as the surrounding estate changes. Suppliers withdraw support or limit patching. Staff who understood the system leave, and their knowledge is not fully captured. Integrations built for the system become undocumented as other systems change around it. Documentation drifts from reality as small changes accumulate without a full refresh. None of those developments is dramatic on its own, but together they leave a system that is harder to protect, harder to detect problems in, and harder to recover.

Legacy risk also arises from dependence that grows unnoticed. A system intended as a temporary solution may become embedded in several services. A reporting tool may become a source of data for processing. A legacy platform may hold the only copy of certain historical records. By the time that dependence is recognised, replacing the system has become a programme in itself, which can delay action and allow the risk to grow further while replacement is planned.

Assessment starts with the service, not with the system age. For each legacy system, the assessment asks which services depend on it, what harm would follow from its failure or compromise, how supportable it is, how well its behaviour and dependencies are understood, and how recoverable it is. A legacy system supporting a peripheral service and a legacy system supporting a core payment service are assessed differently, even when their technology age is similar, because the service consequence differs.

Assessment also examines support and knowledge. Support covers patching, supplier assistance, and the availability of parts or specialist knowledge. Knowledge covers documentation, staff understanding, and the ability to diagnose and fix faults. Recovery covers whether the system can be rebuilt, whether its data can be restored, and whether the recovery plan has been tested against the system as it currently runs. A gap in any of those areas increases the risk, and the assessment records the gap rather than assuming it away.

Protection for legacy systems often relies on containment as much as on hardening the system itself. Where a system cannot be patched, protection may involve isolating it, restricting access to it, monitoring its traffic closely, and limiting the data it holds or exchanges. Those compensating protections reduce exposure, but they do not remove the underlying risk, and they need to be recorded as compensating measures with their own limits, rather than presented as equivalent to a supported, patched system.

Recovery for legacy systems is often the weakest part of their resilience. A system that cannot be rebuilt from current media, whose configuration is known only to a small number of staff, or whose data cannot be restored cleanly presents a recovery problem that a plan written for a modern system does not solve. Recovery planning for legacy systems therefore needs to be tested against the system as it is, including its documentation gaps and its knowledge dependencies, rather than assumed from a generic recovery template.

Replacement decisions are made by weighing service risk against the cost, disruption, and risk of replacement itself. Replacing a legacy system is a change programme that carries its own risk, and a rushed replacement can disrupt the service it is meant to protect. Decisions therefore consider the service consequence of continued operation, the trajectory of support and knowledge, the feasibility of containment in the meantime, and the availability of a replacement that genuinely reduces risk rather than merely modernising technology.