Keeping a Service Map Current

Keeping a service map current means treating the map as a living record that changes whenever the service changes, not as a document that is refreshed on a timetable and forgotten in between. Every new system, supplier, team change, process revision, or data store should prompt a check: does the map still match reality? If the answer is no, the map is updated as part of that change, by the person making the change, with the old information removed rather than left to confuse responders. A map that is updated only when someone remembers to do it will always lag behind the service it describes.

Maps go stale because services are not static. Technology teams replace integrations, operations teams revise processes, suppliers change platforms, and people move roles, often in small steps that individually seem too minor to record. No single change breaks the map, but the accumulation does. After a period of unrecorded change, the map may show a system that has been retired, a supplier that has been replaced, and an owner who has left, all at once. An incident team that trusts that map will waste time on dead ends. Staleness is therefore not a sign of laziness. It is the natural result of a system that treats mapping as a project rather than as part of change.

The most reliable method is to link map updates to existing change processes. When a change request is raised for a service, it should ask whether the service map is affected, and the change should not be considered complete until the map reflects it. That discipline works better than a separate mapping review, because it catches changes at the moment they happen, when the person who knows the detail is still involved. It also spreads ownership. Instead of one team owning a map for many services, each service owner owns the currency of their own map, with a central check that the updates have actually been made.

Currency needs a named owner for each service map, plus a routine check that the owner is keeping it up to date. The check need not be elaborate. It can be a comparison of the map against recent change records, a conversation with the service team about what has changed, or a short rehearsal that exposes outdated links. What matters is that the check happens, that its findings are recorded, and that outdated entries are corrected rather than noted and left. A map owner who is never asked about currency will reasonably assume that nobody is reading the map, and the map will drift accordingly. Ownership without checking is a title, not a control.

When a check reveals that the map is out of date, the gap should be treated like any other resilience finding: named, owned, and given a route to closure. The correction should remove the outdated information, add the current information, and note the source of the correction, so that the next reader can trust it. If the gap is material, for example a missing supplier or a retired workaround, the team should also consider whether an incident occurring before the correction would have been mishandled, and whether any other service shares the same outdated link. That follow-through turns a mapping correction into a genuine improvement, rather than a quiet edit that leaves the underlying lesson unlearned.

Testing is the most honest currency check available. A rehearsal that follows the map will quickly expose a retired system, a moved owner, or a workaround that no longer works, because responders will try to use the map and fail. Schedule rehearsals that deliberately use the map as the only guide, and treat every stall as a currency finding. Between rehearsals, small triggers can help: a supplier change, a team move, or a system migration should each prompt a map review for the affected service. Under DORA in the EU and under FCA and PRA policy in the UK, a firm is expected to show that its understanding of a service remains accurate over time, and a map with a visible update history is far more persuasive than a map with a single creation date.