How to create a process map

A worked example, stage by stage

1. 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.

2. 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.

3. 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.

4. 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.

5. 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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

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.