Beyond the Lines – Issue 31

I hope you had a good Easter weekend and managed to switch off for a bit.

There is always something slightly brutal about the first few days back. The inbox fills up, everything is suddenly “urgent”, and the same old process weaknesses show themselves almost immediately. A delayed sign-off. A rushed override. A review that technically happened, but clearly did not influence much. It is one of the fastest reminders that controls do not operate in theory. They operate in the real world, with all the pressure, shortcuts and competing priorities that come with it.

That is exactly what this issue is about.

Because a lot of control environments look fine on paper and still fail to shape behaviour where it matters most.

Before I go further, this is not an argument against detective, monitoring, or non-key controls. They all have a place. The issue is not control type. It is whether the control is doing the job it is supposed to do, or whether we are giving it credit simply because it exists and gets performed.

Most organisations do not have a shortage of controls.

They have approvals. Reviews. Exception logs. Thresholds. Reconciliations. Attestations. Dashboards. Escalations. Plenty of them.

What they often do not have is enough controls that change a live decision in the moment that matters, or enough detective and monitoring controls that surface problems early enough to change what happens next.

That is the gap.

And once you see that properly, a lot of familiar frustrations start making sense. Teams comply with the process, but the same workarounds keep happening. Evidence is collected, but ownership is still fuzzy. Reviews are signed off, but the quality of judgement does not really move. A control exists, yet people still behave as if the control is optional.

That is not just a process issue. It is usually a design issue.

That sentence is worth sitting with, because it cuts across a lot of the comfort language that tends to sit around controls and governance.

If the risky decision has already happened by the time a control arrives, that control may still have value, but it is no longer shaping the original choice. It may still detect. It may still monitor. It may still create an audit trail. But if the person making the original call does not change course because of it, then it is not the control shaping that behaviour.

This is where a lot of organisations get stuck. They confuse completion with influence.

That is why the first question should not just be, “Is the control being performed?”

It should also be, “What decision, signal, or action is it supposed to create?”

If you cannot answer that cleanly, the rest of the design usually starts to wobble.

People often assume stronger control means more intervention. More approvals, more evidence, more review.

But what actually happens is often the opposite of what was intended.

More approvals can dilute ownership. Once enough people have touched something, it becomes harder to say who was really accountable for the judgement.

More evidence can give everyone a false sense of comfort. If the documentation is strong, people assume the process must be working. Quite often, the organisation has simply become better at proving that the step happened.

More reviews can slow down routine work while doing very little to improve how exceptions are handled, unless the output of those reviews leads to timely action, clearer ownership, or escalation. Without that link, frustration grows, bypass becomes normal, and the same behaviour the control was supposed to prevent quietly survives underneath the process.

This is why I keep coming back to the same point: a control is only as good as the choice it changes, the signal it creates, or the action it triggers.

The cleanest way I know to test a control is this:

Control → Decision / Signal → Behaviour / Action → Outcome

Each part matters.

What is the actual mechanism?

A threshold. A required approval. A mandatory field. A workflow block. A review. An escalation trigger. An exception log.

This is the easiest part to describe, which is why people tend to stop here.

What live choice is that mechanism meant to influence?

Approve or reject.
Release or hold.
Grant or deny.
Override or escalate.
Continue or pause.
Defer or act now.

If the decision is vague, the control is almost always too vague as well.

What should people do differently if the control is working?

Challenge more.
Escalate faster.
Pause when something is unclear.
Move routine work through more quickly.
Treat repeat exceptions differently.
Own decisions more clearly.

This is the bit many frameworks skip too quickly. But it is the bridge between governance language and actual human behaviour.

What improves if the behaviour changes?

Fewer repeat issues.
Cleaner execution.
Less leakage.
Better service resilience.
Better data quality.
Stronger accountability.
More predictable operations.

If you cannot explain the full chain, the control is usually more ceremonial than operational.

Not every control is meant to work in the same way. A preventive control should shape a live decision. A detective control should surface an issue fast enough to trigger meaningful action. A monitoring control should create visibility, ownership, and escalation. The point is not that every control must do the same job. The point is that too many controls are still judged by completion rather than whether they do their intended job well.

Most controls do not fail because someone forgot to write them down.

They fail because something else is stronger at the moment of pressure.

Usually it is one of these.

Urgency. The business wants speed. The control asks for pause and judgement. Speed usually wins if the design is weak.

Hierarchy. A senior person wants movement. The formal control feels awkward to challenge, so it gets complied with lightly or overridden quietly.

Habit. The workaround is familiar. The formal route feels clunky. People default to what gets the job done with the least resistance.

Incentives. Teams are rewarded for output, continuity, or service levels, not for careful challenge. The control becomes something to “get through”, not something that improves the decision.

Diffuse ownership. The control belongs to “finance”, “operations”, or “the business”, which often means nobody really owns the judgement when it matters.

That is why some controls sound perfectly sensible in a design review and then fall apart in practice. They were built for governance language, not for operating pressure.

The easiest way to see this is to look at controls that appear sensible on paper but sit too late, or too weakly, in the real operating flow.

Let’s take something outside classic finance.

A supplier onboarding process might include a retrospective monthly review of higher-risk vendors added during the period. That review may be documented, timely, and well presented. But if the real risk sits in the original decision to onboard without complete diligence, then the monthly review is mostly detecting a decision that has already been made.

That review may still be useful, but it is not the main control shaping the original onboarding decision.

The live decision sits earlier.

A stronger design would push judgement into the onboarding workflow itself. For example:

Now the control does not just tell you that risk was taken. It changes how that risk is taken, who owns it, and how visible it becomes.

Here is another operational example.

An operations team experiences recurring service incidents, but the formal review process sits at the weekly incident committee. By then, the team has already classified the incident, chosen the workaround, restored service, and moved on. The committee may identify themes, but it is not the point where the original risk decision was made.

The real control point sits earlier, when the incident is first classified and the response path is chosen.

A stronger design might include:

That is a different mindset entirely. It puts control around the choice, not just around the reporting of the choice later.

This one sits somewhere between operations and finance.

A business may have a monthly write-off review that looks robust. Inventory adjustments above a threshold are reviewed, signed, and archived. But if the real risk is recurring local judgement about damage, obsolescence, or shrinkage, then the monthly review is again arriving too late to influence much.

It may still help spot patterns. But if the aim is to shape local behaviour, the stronger design is not necessarily another approval. It might be:

That changes the behaviour people adopt locally. It also gives you a much more useful management signal than one monthly number.

In my experience, effective controls usually have five features.

Not in the pack afterwards. Not in the retrospective review. In the live workflow.

If the compliant route is slower, clunkier, or more confusing than the bypass, people will eventually bypass.

A person, not a department. A named decision-maker, a backup, and a clear escalation if neither acts.

Rejected items come back with a reason. Overrides are logged. Exceptions age visibly. Repeat patterns get reviewed, not ignored.

Not stitched together later as proof that the activity happened. The best evidence comes out of the decision itself.

That is the difference between a control that creates administration and a control that changes behaviour.

If you want something practical, do this with one control that people privately complain about.

Ask:

1. What is the live decision this control is meant to influence?
Get specific. One sentence.

2. What currently makes bypass attractive?
Think speed, ambiguity, weak systems, awkward handoffs, poor incentives.

3. Who actually owns the judgement?
Not the function. The person.

4. What visible consequence exists when the control is ignored?
If the answer is “not much”, that is a design clue.

5. Does the evidence prove thinking, or at least produce a signal that leads to action?
That one question is often brutal, but useful.

Then change one thing.

Not everything. One thing.

Move the control earlier.
Name the owner properly.
Reduce friction for low-risk work.
Make override patterns visible.
Force rationale into the workflow.
Escalate repeated behaviour, not isolated events.

That is where real redesign starts.

Use this when something feels “controlled” but not especially convincing.

If the answers feel uncomfortable, good. That usually means you are finally looking at the real operating mechanic rather than the comforting one.

Preventive, detective, and monitoring controls all have a place. The issue is not type. It is whether the design is doing the job it claims to do.

If this is your kind of problem, there are also a couple of resources waiting for you:

AI Defence Pack
Practical guardrails and working notes for using AI in a way that stays controlled, useful and defensible.

Stakeholder Influence Map + Scripts
A practical tool for helping good insight land with the right people, at the right moment, in the right language.

If this issue resonates, you may also want to join my first BtL live session.

I’m hosting a Beyond the Lines™ Leadership Signals webinar on:

Modernising the Three Lines at scale: how to reduce friction and duplication without creating more bureaucracy.

This one matters because a lot of organisations do not need more governance. They need better flow, clearer ownership, and less duplication between risk, controls, audit, and the business.

We’ll be getting into questions like:

It should be a practical conversation, not a theory-heavy one.

If you work in audit, risk, controls, or governance and want a more joined-up, less bureaucratic model, it should be a useful session.

If this edition was useful, please share it with a colleague or team member who would get value from it too.

Beyond the Lines™ is growing through smart people passing useful work on, not noisy promotion.

And if they want practical tools, sharper thinking, and more honest conversations on audit, risk and controls, they can subscribe here:

Most controls do not fail because they are absent.

They fail because they arrive too late, sit with the wrong person, or make no meaningful difference to the decision that matters.

That is why the future of this profession is not more control for the sake of it.

It is better-designed control.

Control that shapes judgement.
Control that clarifies ownership.
Control that changes behaviour.
Control that improves outcomes.

That is a much better standard to design to.

And it is a far more useful one than simply asking whether the control exists.

Best,

Tim Buckley

Founder Beyond the Lines™ | Integral Assurance

Last month, 48% of visitors to documentation sites across Mintlify were AI agents, not humans.

Claude Code, Cursor, and other coding agents are becoming the actual customers reading your docs. And they read everything.

This changes what good documentation means. Humans skim and forgive gaps. Agents methodically check every endpoint, read every guide, and compare you against alternatives with zero fatigue.

Your docs aren't just helping users anymore. They're your product's first interview with the machines deciding whether to recommend you.

That means: clear schema markup so agents can parse your content, real benchmarks instead of marketing fluff, open endpoints agents can actually test, and honest comparisons that emphasize strengths without hype.

Mintlify powers documentation for over 20,000 companies, reaching 100M+ people every year. We just raised a $45M Series B led by @a16z and @SalesforceVC to build the knowledge layer for the agent era.

Make Your Docs Agent-Ready