The Governance-by-Design Primer

Why controls bolted on afterwards fail

A control added after a process is live has to fight the process. It sits outside the flow of work, so it depends on someone remembering to apply it, and it is measured by a report written days or weeks later. By the time a breach is visible, the work has already gone out of the door.

Governance by design reverses the order. The control is specified at the same moment as the step it governs: who may perform it, what evidence it must produce, how quickly it must complete, and what happens when it does not.

• Late controls rely on memory and goodwill; designed controls rely on the process itself.
• If a control cannot be measured from the event log, it is a statement of intent, not a control.
• Every control should name an owner, a threshold, and a consequence.

The four design questions

Before a process is signed off, four questions should have written answers. They take an hour to answer and save quarters of remediation.

• What must always be true? These become your invariants — required steps, approval limits, segregation of duties.
• What must never happen? These become your prohibitions — the same person raising and approving, a payment without a match, a change without a test.
• How will we know? Name the recorded event that proves each answer. No event, no control.
• Who acts when it breaks? A breach with no named owner is a notification, not governance.

From policy to measurable rule

Policy language is deliberately broad; a rule has to be narrow enough to evaluate. The translation step is where most governance programmes stall, and it is mechanical once you have the pattern.

Take the policy sentence, isolate the measurable noun, attach a threshold, and bind it to an activity in the process. 'Invoices should be approved promptly' becomes 'the Approve activity must occur within 48 hours of Invoice received, measured per case, owned by the Finance Operations lead'.

• Cycle-time limits: a step, or a whole case, must complete inside a stated window.
• Required steps: a named activity must appear in every case of this type.
• Segregation of duties: two named activities must be performed by different people.
• Thresholds: value, volume, or rework count above which a second pair of eyes is required.

Evidence that survives an audit

An auditor is not asking whether you believe the control worked. They are asking for the record. Designed controls produce that record automatically: the case, the activity, the timestamp, the actor, the rule that was evaluated, and the outcome.

Store the evidence with the breach rather than reconstructing it later. A breach record that carries its own evidence can be exported, reviewed, and closed without a hunt through inboxes.

A ninety-day starting path

You do not need a programme. You need one process, one set of rules, and one month of history.

• Weeks 1–2: pick a process with real volume and real pain. Pull an event log with case, activity, and timestamp.
• Weeks 3–6: discover the actual map, agree the four design questions, and write between five and ten rules.
• Weeks 7–10: run the rules over history. Expect surprises; tune thresholds rather than arguing with the data.
• Weeks 11–13: assign owners to exceptions, agree the review cadence, and publish the first evidence pack.