Mapping ICT Systems and Integrations

Mapping ICT systems and integrations traces the technology a service runs on: the applications that carry it, the platforms underneath them, and the links that pass data between them. A customer-facing service may look like one thing, but behind it there is usually a chain of systems, each depending on the next. When one link in that chain fails, the map should show what else stops, what keeps running in a degraded form, and what must be restored first. Without that trace, responders may restore a visible system while the hidden dependency that actually broke it remains down, and the service fails again as soon as it restarts.

Start with the systems the service directly uses, then work outward to the systems those systems depend on. Include the customer channel, the core processing application, supporting services such as authentication and messaging, and the infrastructure underneath, such as hosting and network services, where they affect recovery. For each system, record its owner, its role in the service, and the systems it connects to. A simple inventory list is not a map. The value lies in the connections: which system calls which, in what order, and what happens to the service if that connection breaks or slows.

Integrations are where services most often surprise their owners. An integration may be a modern interface, a file transfer, a shared database, or an older link that has survived several rounds of change and is now understood by very few people. Each type fails differently. An interface may return errors, a file may arrive late or incomplete, and a shared store may lock or corrupt under load. The map should record, for each integration, what is exchanged, how often it is expected, and what the service does when it is missing. That last point matters most, because a service that assumes an integration will always be there has no plan for the day it is not.

Technology changes faster than most maps can follow. A system is upgraded, an integration is replaced, a platform is moved, or a supplier changes its interface, and the map quietly falls behind. The discipline is to treat every technology change as a potential map change and to check the map before the change goes live, not after an incident exposes the gap. Change records should therefore ask a direct question: does this change add, remove, or alter a dependency of an important service? If the answer is yes, the map should be updated as part of the same change, with the old dependency removed rather than left alongside the new one to confuse responders.

Legacy systems and shared platforms create a particular mapping challenge. A legacy system may support several services, so its failure spreads further than a map drawn for one service would suggest. A shared platform may look like a single dependency but contain many components with different owners and recovery sequences. The map should make shared use visible, so that a team restoring one service can see which other services are waiting on the same component and can sequence recovery accordingly. It should also be honest about legacy knowledge gaps. If nobody is certain how an old integration behaves under failure, that uncertainty belongs on the map as a gap to investigate, not hidden behind a tidy box.

Test by failing components in rehearsal and following the map to the consequence. Choose a system, a platform, or an integration, declare it unavailable, and ask responders to describe the customer impact, the workaround, and the restoration order using only the map. If they cannot, or if different teams give different answers, the map needs work. Also test restoration, not just failure, because a system that returns in the wrong order may fail again or corrupt data. Under DORA in the EU, ICT risk and third-party ICT risk are treated distinctly, and under FCA and PRA policy in the UK the same mapping discipline supports the wider resilience picture; in both cases the map is evidence only if it survives a rehearsal.