Two places a control can live
Ask a department where their four-eyes principle is documented and you will usually be pointed to a policy: a paragraph that says payments above a threshold need a second approval. Ask the same department to show you, in their process, the step where that approval happens, who gives it and what record it leaves, and the room goes quiet for a moment.
That is the difference between a control that lives in a policy and a control that lives in the process. The policy says what should happen. The process shows where it happens, between which steps, by which role, and what the auditor can look at afterwards. An audit asks for the second kind.
A policy proves intent. A control step in the diagram proves a place, a role and a trace.
What an auditor actually asks
Whatever the framework, the questions an auditor brings to a process are remarkably similar. For each control they want to know what it is meant to prevent or ensure, which internal rule or external requirement it refers to, and what evidence shows it was performed. Objective, reference, evidence. If the answer to any of the three is "it depends who you ask", the control is weak, however carefully the policy was written.
We built the compliance analysis in patchley around exactly these three questions. Every step marked as a control carries them, and when you ask patchley what is missing, it points to the question that has no answer yet. We have described how this plays out in three industries in the reports on banking, insurance and manufacturing; the frameworks differ, the three questions do not.
Why the diagram, not the document
There are three practical reasons to put the control into the diagram rather than only into a document.
Position is part of the control
A check before payout and the same check after payout are different controls. In a text, the position is a sentence that may or may not be precise. In a diagram, the position is unambiguous: the control step sits between two other steps, in the lane of the role that performs it. Moving it is visible; skipping it is visible. When the process changes, the question "is the control still in the right place?" can be answered by looking.
The role is in the lane
A four-eyes check performed by the same person who prepared the payment is not a four-eyes check. In the diagram, the preparation sits in one lane and the approval in another, and if they end up in the same lane, something is wrong and it shows. Segregation of duties, which many frameworks ask about in some form, is a property of lanes.
Evidence is attached to the step
The approval leaves a record: a status in the system, a signed form, a note in the file. In the analysis attached to the control step, that evidence is named, and it is named next to the system the step works in. When the auditor asks "show me", the answer is a step, a system and a record, not a search through emails.
Objective, reference, evidence. If a control step cannot answer all three, it is a finding before the auditor arrives.
Capturing controls in the interview
Controls rarely come up on their own in a process interview. People describe what they do, and a check they perform every day feels like part of the step, not a step of its own. We ask for them explicitly, late in the interview, with one question: "Who checks, and what proves it?" The answers mark the control steps, and the follow-ups fill in the objective and the evidence.
Two things we have learned to watch for. First, controls that exist in practice but not in the policy: the experienced colleague who "has a look" at every unusual case. These are real controls, often good ones, and they should be in the diagram so that they survive the colleague's retirement. Second, controls that exist in the policy but not in practice: the second signature that is given in bulk on Friday afternoon. The diagram should show what happens; the gap between it and the policy is the finding.
What this looks like in a model
The example models show the convention: the control step is a task like any other, marked so that it can be found, placed in the lane of the role that performs it, usually just before a gateway that depends on its result. The claims example has a coverage check before the payout decision; the invoice example has a three-way match and an approval before the payment is released. In each case the step, the lane and the position say more about the control than a paragraph would.
The diagram leaves as BPMN 2.0 XML, so the control steps travel with the process into whichever tool the organisation uses next, and the analyses that explain them travel into the deck for the audit committee. What stays behind is the moment of silence when someone asks where the control actually is.