Thinking — Outside The Box Consulting

DORA isn't your problem. Your operating model is.

2026-06-15T00:00:00Z

Walk into most DORA programmes and you'll find the same artefact: a spreadsheet with several hundred rows, one per regulatory requirement, each mapped to a policy, a control, an owner and a RAG status. Months of work. Mostly green. And almost entirely beside the point.

That spreadsheet answers one question: can we show a supervisor that a document exists for each thing the regulation mentions? DORA asks a different question: when something critical breaks, does your firm keep operating? Those are not the same question, and the gap between them is where firms are quietly failing right now — with fully green trackers.

The 2am test

Here is the scenario the regulation is actually about. It's 2am. Your payments processor — or your cloud platform, or the SaaS product your operations team lives in — has gone down, and their status page is lying to you. Their account manager isn't answering. Your service desk is fielding calls.

Now the questions that matter. Who in your firm has the authority to invoke the contingency? Not "who is accountable on the RACI" — who will actually make the call, at 2am, without convening a committee? Do they know they have that authority? Have they ever used it? What triggers the decision to fail over, and what triggers the harder one — to tell customers, to tell the regulator, to start counting the hours against your impact tolerance?

If the honest answer is "it depends who's on call", your operating model has already failed the test. No register entry fixes that. The register can be immaculate and the firm can still stand in the corridor at 2am arguing about who's allowed to spend money.

DORA is not a documentation standard. It is a behavioural test, administered at the worst possible moment, with no opportunity to resit.

This is what the regulation means by resilience, underneath the articles and the technical standards. Can the firm absorb the failure of things it depends on but doesn't control? That is an operating-model property. It lives in decision rights, escalation paths, rehearsed muscle memory and contracts you've actually read. It does not live in a spreadsheet.

The register is a symptom, not the disease

The information register gets the attention because it's tangible and auditable, and because filling it in feels like progress. Fine — you need one, and a sloppy one will earn you awkward supervisory letters. But watch what happens when a firm treats the register as the deliverable.

The register says the vendor is "critical". Nobody has decided what the firm does in the first hour of that vendor failing. The register records an exit strategy. The exit strategy is a paragraph, written by someone who left last year, describing a migration that would in reality take nine months and has never been priced. The register lists a substitute provider. Nobody has ever run so much as a tabletop of the substitution, so nobody knows the substitute needs six weeks of onboarding and a data format you don't produce.

Paper resilience. It maps beautifully. It survives contact with an auditor and dies on contact with an outage. Supervisors have started noticing the difference, and the firms getting uncomfortable follow-up questions are not the ones with gaps in their registers — they're the ones whose registers are perfect and whose people can't describe what happens next.

What good actually looks like

Good is smaller and harder than the programme plan suggests. It looks like this.

For each genuinely critical third party — the handful, not the hundreds — there is a severance decision that has been tested, not filed. Someone senior has sat in a room and made the call under exercise conditions: we are leaving this provider, now, and here is the sequence. The exercise found the gaps a document never would: the licence that doesn't transfer, the person who is single-handedly load-bearing, the backup that restores in twelve hours rather than two.

The playbooks are written in plain English, short enough to use at 2am, and the people named in them know they're named. A playbook nobody can follow under stress is a compliance artefact wearing a hard hat.

And every arrangement passes the one-sentence test we apply to everything: the person living with it can say what it's for, in one sentence, without mentioning the regulator. "If Provider X dies, I switch to Y, it takes four hours, and I'm allowed to do it on my own authority." That sentence is resilience. Forty pages of mapped controls are not.

The irony is that firms which build this way find the compliance falls out of the bottom almost for free. The register describes reality instead of aspiration. The testing evidence exists because the tests actually happened. The board reporting writes itself, because there is something real to report.

DORA didn't create the weakness in your operating model. It just scheduled the exam.

Fix how your firm decides under stress, and DORA becomes paperwork; fix only the paperwork, and DORA becomes prophecy.

The 40-page control document is a confession.

2026-05-14T00:00:00Z

Pick up any forty-page control standard and read it as a detective would. Not for what it says — for what it's covering up.

The tell is always the same. Page 3 states the control plainly enough. Then come the exceptions. The carve-out for legacy systems that risk insisted on. The alternative process for the trading floor, negotiated after they escalated. The "risk-based approach" paragraph that means the second line and engineering never agreed on scope, so someone wrote a sentence vague enough for both to sign. Three appendices of edge cases, each one the fossil of an argument that ended in a workshop instead of a decision.

That's what the forty pages are. Not rigour — sediment. Every unresolved disagreement in the organisation, laminated and given a version number. The document is long precisely because nobody with authority ever said what the control was for and made it stick. Length is the confession.

Nobody works around a control they understand

Here's why this matters beyond tidiness. Controls don't fail in audits. They fail on a Tuesday afternoon, when someone with a deadline meets a requirement they can't see the point of.

A person who understands what a control protects will usually cooperate with it, even when it's inconvenient — people are not stupid, and nobody wants to be the cause of the breach. A person facing forty pages of qualified, contradictory prose doesn't get the chance to understand it. They ask a colleague, the colleague shrugs, and together they find the path of least resistance. The workaround isn't rebellion. It's the only rational response to an instruction nobody can parse.

A control your people can't explain isn't a control. It's a queue of workarounds that haven't happened yet.

So the forty-page document doesn't just record the organisation's confusion. It manufactures more of it, daily, at the exact moments the control was supposed to work.

The fix is a decision, not an edit

The tempting response is editorial: hire a technical writer, tighten the prose, get it down to twenty pages. Wrong tool. The problem was never the writing. The problem is that a decision was skipped, and the document grew to fill the space where the decision should have been.

The fix is to make the decision. Ask the control's owner to complete one sentence: this control exists so that ___. No sub-clauses, no "and also", no mention of the regulator — regulations are why you must have a control, never what it's for. If the owner can't produce the sentence, you've found the real finding, and it isn't a documentation gap. If two stakeholders produce different sentences, you've found the argument the forty pages were burying. Have it now, with someone empowered to end it, instead of relitigating it in every review cycle.

Then write down only what the sentence requires. Usually that's two or three pages: the point of the control, who does what, and what to do when it doesn't fit. The exceptions that survive are the ones the purpose justifies — the rest were never exceptions, just appeasements.

We watched this play out at a mid-sized regulated firm — details blurred, pattern intact. Their access-review standard ran to thirty-eight pages and three process variants, and reviews were completed late, by bulk approval, every quarter. Managers were rubber-stamping because the document never told them what a review was for. The rewrite began with one sentence: "this control exists so that when someone changes role, their old access dies." Four pages. The variants collapsed, because once the purpose was stated, two of the three processes were visibly theatre. Completion stopped being the metric; revoked access became the metric. The reviews started catching things.

Nothing about the control got weaker. It got shorter, which meant it finally got done.

That's the pattern, and it generalises. Short documents are not a style preference. They are proof that somebody decided something — and a decision, unlike an appendix, is a thing people can follow at speed, under pressure, without asking permission to understand it.

Next time a forty-page standard crosses your desk, don't ask who should update it. Ask what it's hiding.

The length of a control document measures the distance between your organisation and a decision it hasn't made yet.

Stop showing your board heat maps.

2025-12-09T00:00:00Z

Somewhere in your next board pack there is a five-by-five grid. Likelihood along one axis, impact along the other, a scatter of numbered dots drifting from red towards green. It will take ninety seconds of the meeting. Someone will ask about dot 7. Someone else will note that dot 12 has moved. And then the board will turn the page, having learned almost nothing, feeling almost reassured.

That is the heat map's genius, and its indictment. It was never built to inform. It was built to be finished with.

What the grid actually compresses away

Consider what has to be true for a dot to land on the chart. Someone judged the likelihood of, say, "a material cyber event" — a guess about an adversary's intentions, dressed as a number. Someone judged the impact — another guess, averaging away the difference between a bad week and an extinction event. The two guesses were multiplied, a piece of arithmetic with no defensible meaning, and the product was mapped to a colour chosen mainly for how it would land in the meeting. Amber, usually. Amber is the colour of not having the argument.

Every decision-relevant fact died in that compression. Which service would actually stop. Whether the exposure is growing or shrinking. What we're doing about it, what that costs, and whether it's working. How confident anyone is in any of this. A heat map is what remains of a risk conversation after everything a board could act on has been boiled off.

And it fails in both directions at once. It's too abstract to support a decision, and just concrete-looking enough to create the feeling that oversight has occurred. The NEDs can't interrogate it — there's nothing load-bearing to press on. Dot 9 moved from red to amber because a workshop re-scored it. Nothing in the world changed. The chart improved anyway.

The heat map's real function is to end the conversation — and the conversation is the only thing the board was there to provide.

Regulators have noticed. The supervisory question is no longer "does the board see cyber risk information?" It's "can the board evidence that it challenged anything?" A page of unchallengeable colours is not just unhelpful now. It's a liability with a page number.

Give them something to judge

The board's job is not to absorb assurance. It's judgement: weighing what the executive proposes, pressing where the answers wobble, choosing between costly options under uncertainty. So give them material that judgement can grip. In practice that's a handful of plain-English questions, answered honestly, a page or two at most.

What would hurt us most? Not a risk category — a scenario, in words. "Our claims platform is down for four days and we can't pay customers." Name the two or three that would genuinely wound the firm, and say plainly how exposed we are to each, in the terms the board already thinks in: days of outage, customers affected, money.

Are we getting better or worse? A trend, not a temperature. Time to detect, time to recover, what the last real incident and the last exercise actually showed. Better or worse than a year ago — and if the honest answer is "worse, because the estate grew faster than the controls", say that. Boards forgive bad news. They shouldn't forgive discovering it late.

What did we decide last quarter, and did it work? This is the question almost no board pack answers, and it's the one that turns reporting into governance. We approved £800k for privileged access; here's what changed and what didn't. We accepted the risk on the legacy platform; here's what that acceptance has cost us since. Decisions that are never revisited aren't decisions — they're gestures.

Notice what these three have in common: each one can be wrong. A named scenario can be challenged as the wrong scenario. A trend can be disputed. A decision review can reveal that the money bought nothing. That's the point. Judgement needs a surface with grip, and grip means falsifiable claims in plain English — not a grid that is compatible with every possible state of the world.

Your NEDs will thank you, and not out of politeness. The good ones know the ninety-second heat-map ritual is theatre; they've sat through it at every firm on their portfolio, and they know exactly what it's for. Handing them three answerable questions is handing them their actual job back.

The heat map asks the board to admire your risks. The alternative asks them to govern.

If the board can't be wrong about what you've shown them, you haven't shown them anything.