Field Notes_004_Pragmatic risk management for SMEs: three techniques, one architecture, and the AI that finally makes it cheap

Key takeaway — Most SME risk registers protect nothing because they are designed as compliance artefacts, not as decision instruments. Real protection comes from three named techniques run as three sessions a year — a pre-mortem, a decision matrix, a quarterly drill — and from a CEO who treats risk as a decision problem rather than a documentation problem. AI tools like Claude turn what used to be a €30–50k consulting project into an afternoon. The architecture stays the operator's; the leverage is finally in reach.

Risk management at most SMEs is an Excel column nobody reads. A heatmap. A binder for the auditor. A register no operator has ever touched.

Then the warehouse floods. A key supplier goes silent. A line manager retires and twenty-two years of know-how walks out the door. The risk register, in each case, contained the right row. What it did not contain was a decision.

This is the fourth entry in the Field notes series. Field notes 003 looked at supply chain resilience at the strategic level - at the perimeter of the company. This one moves inside the building. It is for the CEO who already knows the supply chain story is partially broken and who now wants to know what to do about the rest of the operational risk surface - the people, the permits, the machines, the customers, the systems - without hiring a Chief Risk Officer the company does not need.

The audience is the same as the previous three pieces. Founders, owner-managers, CEOs, division heads, operating board members. People whose week is judged by what the company actually moved, not by what was added to a register.

Why most SME risk registers protect nothing

Every mid-market company I have worked inside has a risk file. It lives in finance. It is updated once a year, the week before the auditor arrives. It has thirty rows, traffic-light colour coding, and a mitigation column written in the conditional tense. It is opened in February and again in September and at no other moment in the year.

The deck succeeds at exactly one thing. It allows the board to record that risk was "considered". It does not produce a company that is harder to break.

The reason is not effort or intelligence. The reason is design. A risk register, as practised in most SMEs, is a compliance artefact - a document built to satisfy an external observer that the topic has been touched. A risk architecture is a decision instrument - a system built to change what the company actually does when a defined signal arrives. The two look superficially similar on the page. They behave completely differently in a crisis.

A risk that is not priced is not managed. A risk that is not paired with a pre-decided action is not even a risk: it is anxiety in PowerPoint form. And a company that confuses the artefact for the instrument has built itself a placebo - a thing that produces the feeling of risk management without producing the behaviour of risk management.

The SME problem is sharper than the listed-company problem. A listed company can afford a head of risk, a second line of defence, an internal audit function, and the apparatus around them. An SME with €5M to €50M of revenue cannot. The standard ERM playbook, applied at SME scale, produces either an unread document or a part-time job for the finance director that the finance director resents. Neither outcome protects the company.

The architecture below is built for the constraint. Three named techniques. Three sessions a year. Operator-led. No second line, no consulting team, no €40k engagement to maintain the framework. Designed to survive on the bandwidth the CEO of a mid-market company actually has.

Risk is a decision problem

Strip the apparatus away, and the operational principle is one line: risk management in a physical SME is not about documenting risk; it is about pre-deciding what happens when a defined signal arrives.

The signal is the volume in the wrong place - the supplier that does not respond by Tuesday, the inventory below the trigger level, the resignation that names a single point of failure, the cyber alert that crosses a defined threshold. The decision is the named action - the second supplier called, the production line paused, the cross-training programme accelerated, the response team convened. The architecture is the relationship between the two - pre-decided, written down, owned by a name, rehearsed often enough that the muscle holds under pressure.

What documents do not produce, and what architectures do, is speed of decision under stress. A risk register opened at the board meeting cannot move a supplier order. A decision rule, sitting in the operations file, with a named owner and a tested escalation path, can. The performance gap between the two, in a real shock, is not 20%. It is the difference between losing a quarter and losing the company.

The companies that survive cycles are not the ones with prettier spreadsheets. They are the ones who already knew who decides - before the phone rang.

The method: three techniques, three sessions, one architecture

What follows is the operational expression of the principle, refined from research into how high-performing scale-ups and SREs run their operational resilience, and from eighteen months in the operator chair of a Belgian industrial business. None of the three techniques is invented. Each is borrowed from a discipline that has tested it under conditions much harder than an SME faces.

01 - The pre-mortem

The first session is the pre-mortem. The technique was formalised by Gary Klein in a 2007 Harvard Business Review article, building on earlier research by Mitchell, Russo and Pennington (1989) showing that prospective hindsight - imagining an outcome has already occurred - improves the correct identification of failure causes by approximately thirty per cent.

The session is two hours. The leadership team is in a room. The CEO sets the frame in a single sentence: "It is eighteen months from now. The company has just lost €500k to a single failure. What happened?" The team then writes - individually, on paper, for fifteen minutes - every plausible cause they can think of. Only after the writing do the answers go on the wall.

The discipline matters. Asking "what could go wrong" produces a polite list. Asking "what already did go wrong, in the world we are imagining" produces a candid one. The difference is the psychological permission that prospective hindsight gives the room - to name the supplier the CEO has been protecting, the manager who is the single point of failure, the maintenance shortcut everyone has been pretending is fine.

The output of the session is a bow-tie diagram of the top three failure modes. The bow-tie is the industrial-process-safety standard - threats on the left, the top event in the centre, consequences on the right, with named preventive and mitigative barriers on each side. It is more useful than a heatmap because it shows, for each failure mode, what currently stops it and what currently absorbs it - and therefore where the company has thin or missing barriers. A heatmap tells you you have a problem. A bow-tie tells you which barrier to build.

02 - The decision matrix

The second session is the decision matrix. It takes the top failure modes from the pre-mortem and converts each one into a pre-decided protocol.

The structure borrows from RAPID (the Bain framework: Recommend, Agree, Perform, Input, Decide) or from RACI-VS, depending on the company's prior exposure. The granularity that matters at SME scale is not the framework label; it is the four questions answered for each top failure mode: Who decides? What threshold triggers the decision? What is the response window? Who executes?

The matrix fits on one page. It lives where the work happens - operations, not finance. It names individuals, not departments. It defines triggers numerically wherever a number is honest - "inventory below 14 days of cover for SKU group A", not "inventory low". And it specifies a response window in hours, not in "as soon as possible".

The reason the matrix is the operational core of the architecture is that it converts a risk register from a document into a behaviour. A risk register tells the CEO that a supplier failure would be material. A decision matrix tells the operations manager that, if supplier X stops responding by close of business Tuesday, he or she has authority to issue a backup order to supplier Y by close of business Wednesday - without escalating to the CEO, without waiting for a meeting, without the loss of forty-eight hours that almost always converts a manageable disruption into an unmanageable one.

A risk register documents the risk. A decision matrix decides what happens next.

03 - The quarterly drill

The third session is the drill. It is the only one that recurs.

The drill is borrowed from the chaos-engineering and Site Reliability Engineering practice that companies like Shopify, Stripe and AWS use to keep their operational resilience honest. In its full software form - a "game day" - the engineering team intentionally injects failure into the production system and observes how the human and machine response actually performs. Most of what those teams discover is that the runbook is wrong, the dashboards lie, and the person nominally on call is on holiday.

Scaled to an SME, the drill is two hours per quarter. One scenario at a time, drawn from the bow-tie. Real phone calls. The CEO or COO acts as the scenario referee. The named owners on the decision matrix actually execute their roles - call the backup supplier, walk to the floor, issue the standdown order. The session ends with a retrospective in which two questions are answered honestly: what did the matrix get wrong, and what does it need to change?

The drill is the discipline that keeps the architecture alive. A pre-mortem held once is interesting. A pre-mortem held once and never tested is forgotten by the second year. A decision matrix that has never been used in a drill is a document. A decision matrix that has been used in four drills a year for two years is muscle memory - and muscle memory is what produces correct behaviour under stress, when the analytical part of the brain has already left the building.

The AI leverage: what changes when an SME has Claude

For most of the last twenty years, the three-technique architecture above was available, in principle, to any company. In practice, it was available to large companies. The reason was cost. A facilitated pre-mortem, a bow-tie workshop, a decision matrix build, and four quarterly drills cost a mid-market company somewhere between €30,000 and €60,000 a year in external consulting fees - once the consultant's time, the materials, the reporting and the follow-up were honestly priced.

That economic constraint is collapsing. A general-purpose AI tool like Claude does not make the operator-judgement parts of risk management easier - and as I will say in the next section, that is the right outcome. What it does is collapse the cost of every part around the operator judgement: structuring, drafting, facilitating, simulating, documenting, translating.

What Claude actually does, in this architecture:

It facilitates the pre-mortem. The CEO and leadership team brief Claude on the business, the operating environment, and the obvious failure modes. Claude then runs a structured premortem prompt - issuing the "it is eighteen months from now…" frame, asking each member to enumerate causes, clustering the responses, surfacing the under-discussed failure modes the team avoided naming. The session still happens in the room; the facilitation that used to require an external consultant happens through the AI.

It drafts the bow-tie. Given a top event and a description of the operations, Claude can draft a first-pass bow-tie diagram in minutes - threats, barriers, escalation factors, consequences - that the leadership team then corrects rather than constructs from scratch. The correction is the operator's work, and it is faster than the construction. The team finishes a bow-tie in an afternoon that used to take a workshop week.

It builds the decision matrix. Given the bow-tie and the company's org chart, Claude drafts a candidate decision matrix - named owners, candidate thresholds, candidate response windows. The leadership team challenges every line. The challenged version, which is what gets adopted, is far better than what would have been produced from a blank page on a Tuesday afternoon.

It runs the drill as a tabletop opponent. The CEO no longer has to design the scenario or play both sides. Claude takes the role of the failing supplier, the cyber threat, the regulator, the journalist - feeding the team realistic, escalating prompts in real time, recording the responses, flagging the moments where the decision matrix did not give a clear answer. The retrospective writes itself from the session log.

It maintains the artefacts between sessions. The bow-tie, the matrix, the drill log, the retrospective - all of them get updated by the AI as the business changes. The CEO reviews the updates rather than producing them.

What changes economically is the cost structure of running the architecture. The work that used to live with an external consultant - facilitation, documentation, scenario design, follow-up - now lives with an AI tool that costs less per year than one day of consulting. The work that stays with the operator is the judgement: what risks matter, who decides, what threshold is the right one, when to override the matrix. That work is the part that should never have been outsourced in the first place. It is also the only part that compounds.

What AI does not change

The CEO does not delegate the architecture to the model. The model drafts. The CEO decides. That distinction is the single most important sentence in this piece.

A decision matrix that has been drafted by Claude and never challenged by the leadership team is a worse document than the one the company would have written itself. It is plausible, well-structured, comprehensive - and disconnected from the operational reality only the operator can see. Claude does not know that the maintenance manager is the only person who can actually start the backup line. Claude does not know that supplier X is also the brother-in-law of the procurement director. Claude does not know which threshold is the one the union will treat as a provocation. The operator does. The architecture only works when the operator's judgement is the binding input.

This is the same principle that the second Field Note applied to priority setting. The frameworks are not the source of focus; they are the expression of it. The architecture is not the source of resilience; it is the expression of it. The source is the CEO's decision discipline. The AI changes the cost of running the discipline. It does not replace it.

The harder discipline

A risk register tells the auditor that the topic was considered. A decision architecture tells the company what to do on the day the warehouse floods. The two outputs look similar on paper. They produce opposite outcomes in a crisis.

What the architecture above does not promise is that nothing will go wrong. Things will go wrong. The next supply chain shock, the next cyber incident, the next key-person event, the next regulatory inflection - they are coming, on a cadence the operator class cannot predict and should stop trying to predict. What the architecture promises is that, when each one arrives, the company has already decided what it does. The decision is in the matrix. The owner is named. The response window is defined. The team has rehearsed it.

The frameworks always existed. The leverage to run them at SME scale did not. It does now. The companies that will look unreasonably resilient in 2030 are the ones whose CEOs are setting up the architecture in 2026 - three sessions, three techniques, one decision instrument, and an AI that finally makes the economics work.

The next Field Note returns to the inside of the company: how the CEO uses the same three-technique architecture to manage people risk specifically - the single point of failure that almost every Belgian mid-market business is structurally exposed to, and almost none has priced.

Ruben Claessens is CEO of an industrial group in Belgium and founder of LIDI Partners BV. Field Notes is the public archive of his work on operatorship, governance, and Belgian mid-market reality. Published deliberately, on a monthly cadence.