Mapping Data Flows and Data Stores

Mapping data flows and data stores follows information through a service: where it comes from, how it is transformed, where it is stored, and who else reads or writes it. A service can have its systems restored and still fail if its data is missing, out of date, or inconsistent. Responders therefore need to know which store is authoritative for each piece of information, which flows feed it, and which copies exist for recovery. A data map that only lists databases without showing flows, or only shows flows without naming stores, leaves the most important recovery question unanswered: which version of the truth should the service use when it restarts?

A data flow is a journey, not a connection. It begins with a source, passes through one or more systems that may validate, enrich, or transform it, and ends in a store or an output that another process or customer relies on. Mapping the flow means recording the source, each transformation, and the destination, in the order they happen. It also means noting timing: whether the flow is continuous, scheduled, or triggered by an event, and what the service does if a scheduled flow arrives late or not at all. A flow that is assumed to be current may in fact be a snapshot from an earlier cycle, and that difference matters when decisions are made from it.

For each store, the map should record what it holds, which service treats it as authoritative, who can write to it, and how it is backed up and restored. It should also record its dependencies: the platform it runs on, the network path to it, and any other store it replicates to or from. Stores that hold the same information in different forms deserve care, because a recovery that restores one copy but not another can leave the service internally inconsistent. The map should therefore distinguish the authoritative store from reporting copies, caches, and archives, so responders do not restore a convenient copy and mistake it for the truth.

Data is often shared across services, which means a fault in one store can ripple far beyond the service that first reports it. A customer record store, for example, may feed onboarding, servicing, and reporting, so a corruption there affects all three even if only one team notices first. Copies add a second risk. A reporting copy may lag behind the authoritative store, a cache may hold stale values after a failure, and an archive may be complete but slow to restore. The map should make both sharing and copying visible, with a note on how freshness is checked. If nobody can say how stale a copy is allowed to be, that is a gap in the map rather than a detail to leave for later.

Recovery is a data decision as much as a systems decision. When a service restarts, it must decide whether to resume from the last known good state, replay missed flows, or reconcile manually, and each choice has consequences for customers. The map supports that decision by showing which flows were interrupted, which stores were affected, and what reconciliation is needed before the service can be trusted again. It should also show the order of restoration where stores depend on each other, because restoring a dependent store before its source can create errors that are harder to untangle than the original outage. That sequencing belongs on the map, not in the memory of one engineer.

Data landscapes change through new fields, new sources, and new reporting needs, often without a formal project to announce them. A data map stays honest when changes to flows and stores are treated as map changes, and when rehearsals include a data failure rather than only a system failure. Ask the team to declare a store unavailable or a flow corrupt, then follow the map to the impact, the workaround, and the reconciliation. Under DORA in the EU and under FCA and PRA policy in the UK, data and ICT dependencies are part of the same resilience picture, labelled separately in these guides, and a map that can guide a data recovery is far stronger evidence than a diagram that only lists where data lives.