How to create a process map
How to create a process map: set the boundaries, name the roles, map the steps and decisions into lanes, then record the systems and evidence each step touches. With a live worked example.
A process map records what happens, who does it and what each step produces: a flowchart with owners, systems and records attached, so it answers questions a bare sequence cannot.
The short version
- Scope is two events: a trigger and an end state. Not a subject area.
- A step is one hand-off-able unit of work: if explaining it takes a paragraph, split it.
- Lanes are accountable roles, and external parties count.
- Record the system and the evidence for each step, not just the action.
- The map is finished when the people in every lane agree it is what they do.
What a map adds to a flowchart
A flowchart tells you the order things happen in. A process map tells you the order things happen in, who is accountable for each one, which system it happens in, and what record it leaves behind. That extra layer is what makes a map useful to people who were not in the room: an auditor asking where the evidence is, a new joiner asking who to chase, an improvement team asking where the time goes.
The mapping work is mostly a sequence of decisions about scope. Where does this process start and stop, as events, not as a subject area. Which roles are lanes, and which are details inside a lane. How granular a step should be, which is settled by a single test: could it be handed to somebody else without further explanation? Get those three right and the drawing is the easy part.
The example below is a security incident response process across five roles. It is a good map to study because the steps carry obligations beyond the activity itself: an evidence-preservation step that exists for legal reasons, a notification decision with a regulatory deadline behind it, and a review step whose output is the input to the next version of the process.
A process map across five roles
Security incident response, from detection to lessons learned. Watch what each stage adds beyond sequence.
Trigger, and the record it creates
Detected, reported through a named channel, logged with a timeline started. The third step is a document shape because it produces evidence: a map records what each step leaves behind, not only what it does.
Classify before you act
A verification decision that can close a false positive, then severity, then whether an incident commander is appointed. Two of these steps exist purely to route the work, and mapping them is how you find out that severity is being decided by whoever answers first.
The steps that exist for a reason outside the process
Isolate, preserve evidence, then apply long-term containment. Evidence preservation slows recovery down and is non-negotiable, which is exactly the kind of constraint a map has to make visible or people will optimise it away.
Verify, and loop if it is not clean
Analyse scope, eradicate, then a verification decision that returns to containment when systems are not clean. A map that runs straight through eradication to recovery is describing a best case, not a process.
Close the loop into the next incident
A notification decision with a regulatory consequence, a post-incident review, and lessons recorded. The last step of a good process map is often an input to a different process: say so, and link them.
How it works
Write the scope as two events
"Starts when suspicious activity is detected; ends when lessons are recorded and the incident is closed." Agree that sentence before anything else. Most process maps that sprawl were never scoped, and every interview quietly extended them at one end or the other.
Name the lanes
List the roles that perform steps, merge to four or six, and include external parties whose action the process waits on. Roles, not people and not departments: a map that names individuals is out of date at the next reorganisation.
Draft the steps at a consistent grain
Use one test throughout: a step is something you could hand to somebody without a covering explanation. Consistency matters more than the level you pick: a map with three-word steps next to paragraph-long ones is unreadable regardless of how accurate it is.
Add the decisions and their exits
Every fork gets a question and labelled routes. Then check that the exits cover every case: the branch nobody drew is usually the branch people actually take when things go wrong.
Record system, owner and evidence per step
Use the step's comment for the system it happens in and the record it produces. This is what makes a map answer an auditor's question without a follow-up, and it is what makes an automation project cheap to scope later.
Validate lane by lane, then approve it
Walk the map with each lane owner separately, fix what they disagree with, then put it through approval so there is one current version with a date and a name against it. An unapproved map is one person's account of what happens.
Mistakes to avoid
Inconsistent granularity
Three steps for the part the author knows well and one for everything else. The detail follows the author's knowledge rather than the reader's need.
No systems or records
A map that shows only activity cannot answer where the evidence is, which is the first question anyone from outside the team will ask.
Mapping the policy
The policy is the intent. The map should be the practice, and the gap between them is the most valuable thing the exercise produces.
Finishing at the drawing
A map nobody has validated is a draft. The signature of the people in each lane is what turns it into a shared reference.
Create your own process map
Open the incident response example as your own chart, or start blank and map your own process into the rows.
Related guides
Frequently asked questions
What is the difference between a process map and a flowchart?
A flowchart shows sequence and logic. A process map keeps that and adds context: who owns each step, which system it happens in, what record it produces, and often how long it takes. The practical marker is lanes: once the flow is split by owner it is a map, and that is the version worth having for anything crossing a team boundary. For a procedure that stays inside one team, a flowchart is usually enough.
What should a process map include?
A stated trigger and end state, the steps in order, the decisions with labelled exits and stated criteria, a lane per accountable role, and for each step the system it happens in and the record it leaves. Everything beyond that (timings, volumes, control references) is worth adding when somebody has a use for it, and worth leaving out when nobody does.
How detailed should a process map be?
Consistent grain beats fine grain. Use one test for every step: could this be handed to someone else without further explanation? For most operational processes that lands somewhere between fifteen and thirty steps. If a step needs a paragraph to explain, it is a sub-process and deserves its own map with a link from the parent.
Who should be involved in creating a process map?
One person to draft it, and one practitioner per lane to correct it. Draft from interviews rather than from the policy, and validate with each lane owner separately before any group session: people correct their own lane candidly one-to-one and defend it in a room. The process owner then approves the result, which is what makes it a reference rather than an opinion.
