To map business dependencies, you list the handful of processes your business genuinely runs on, write down what each one needs in order to work, mark which processes feed each other, and then stop. The result should be short enough that someone unfamiliar with your operation can read it in one sitting. A dependency map that runs to forty pages is a document nobody opens on the day it matters.
This article is general information about documentation and planning. It is not legal, compliance or security advice. Recovery targets and technical configuration are decisions for your organization to make with qualified professionals and to record in your own documents, and which obligations apply to you varies by organization, industry and jurisdiction.
What it means to map business dependencies
A dependency map records the processes your business performs and the things each process needs to function. It is not a network diagram, an asset inventory or an org chart. Those are separate documents and usually live somewhere else.
The unit of the map is a process, described the way a customer or a staff member would describe it. “Taking payment.” “Paying staff.” “Answering the support line.” “Getting an order out the door.” Ten to fifteen of those is a normal count for a small or mid-sized business. If your list runs well past twenty, you have started listing individual tasks rather than processes, and the map will collapse under its own weight.
Underneath each process sits a short block listing what that process depends on: the people who can do it, the systems and data it touches, the premises or equipment involved, the outside parties it relies on, and the records that have to be at hand. That is the whole shape of the document.
How to map business dependencies in six steps
Work in this order. A first pass is an afternoon of work with the right people in the room, not a quarter-long project.
- List the processes, not the departments. Ask what the business does for its customers and what it has to do to keep operating. Write each one as a verb phrase. Resist the urge to group them under headings at this stage, because the headings become the map and the detail disappears.
- Put them in a rough order of priority. Sort the list by which processes you would want back first if several were interrupted at once. You are establishing an order, not setting a recovery target. The targets themselves are a decision for your organization to make with qualified professionals and to record in your own documents.
- Write what each process depends on. Go process by process and ask the person who performs it what they need in front of them to do the work. Capture their answer in their words. People describe their own dependencies accurately when you ask them concretely and badly when you ask them in the abstract.
- Name a person for each process. One named person who knows how the process runs and can speak to it. Not a department and not a job title that currently has nobody in it.
- Mark the links between processes. Note where one process cannot start until another has finished, and where two processes share a dependency. This is the part that turns a list into a map.
- Date it and name the author. Put the date and the author at the top. An undated map cannot be trusted, because a reader has no way to judge how much of it is still true.
Writing a dependency line that holds up
A good dependency line names the thing and says why the process needs it. “Order dispatch needs the shipping records and at least one person with warehouse access.” A weak line names a category: “IT systems.”
Write the line so it still makes sense when read by someone who joined last week. Avoid internal nicknames for systems unless you also write the plain description beside them. Avoid writing the dependency as a solution, because “we would use the spare laptop” belongs in a runbook, not in a map of what the process needs.
The dependency categories most maps miss
Most first drafts cover systems and buildings, then stop. These are the categories that get left out and then turn out to matter.
| Category | What to record |
|---|---|
| People | Who can perform the process, and who else has ever done it |
| Systems and data | The systems touched and the records that must be readable |
| Premises and equipment | Where the work happens and what physical items it needs |
| Outside parties | Suppliers, service providers and anyone whose absence stops you |
| Records and documents | Contracts, licenses, forms and reference material in use |
| Money movement | What is needed to pay out and to take payment in |
| Communication | How you reach staff and customers, and who holds that list |
Single points of knowledge sit near the top of the list of things to catch. The person who is the only one who knows how a month-end process runs is a dependency, and writing that down is not an accusation. It is the only way the gap gets closed before it is tested.
Access is another. A process that depends on one person’s access to a system has a dependency on that person, not on the system, and the map should say so plainly.
Mapping which processes depend on each other
Once each process has its own block, look across the list for three patterns.
The first is sequence. One process cannot start until another finishes, so an interruption early in the chain is felt everywhere downstream. Write the chain out in order, because people consistently underestimate how long these chains are inside their own business.
The second is shared dependency. Several processes rely on the same person, the same records or the same outside party. A shared dependency concentrates consequence, and that is worth knowing before you choose where to spend effort.
The third is circularity, where two processes each need something the other produces. These are rare and worth flagging clearly when you find one, because they are the hardest to work around manually.
You do not need diagramming software for this. A simple notation works: under each process, a line reading “depends on” and a line reading “depended on by.” Many businesses find that two lines per process carries everything a diagram would have conveyed.
Where people go wrong when they map business dependencies
Mapping the org chart. Departments are not processes. A map organized by team tells you who is unavailable, not what has stopped.
Listing assets instead of needs. An inventory of equipment is a different document with a different purpose. The map answers what a process needs, which is often a person or a record rather than a device.
Writing it alone. A map written by one person from memory is a map of that person’s assumptions. The value comes from asking the people who do the work.
Letting it grow. Every addition makes the document less likely to be read. Length is a cost, not a sign of thoroughness.
Leaving it undated and unowned. Both are free to add, and without them the map ages invisibly.
Keeping the map short enough to use
Set a page limit before you start writing and hold to it. One page for the process list with its priority order, and a short block per process, is enough for most businesses. If something will not fit, it probably belongs in a runbook or a records list instead.
Review the map on a cadence your organization chooses and writes down, and trigger an off-cycle review when a process changes materially, a key person leaves, or an outside party is replaced. Log the review date and what changed, even when nothing did. Keep superseded versions rather than overwriting them, because the version history is what shows the document is in use.
The map is also the source material for everything downstream. Restore testing, recovery runbooks and continuity exercises all start from the same list of processes and needs, so building it once removes work later rather than adding it. For worksheets and checklists you can start from, see the Free Resources page on this site.