The Near-Miss Debrief: Your Cheapest IT Procurement Tool Is a 30-Minute Meeting

Here is an uncomfortable truth about IT procurement in UK SMEs: most security spending is triggered by a scare, a renewal date or a persuasive salesperson. Very little is triggered by evidence from your own business. That is why the near miss is such a useful thing — and why it is such a wasted one.

A near miss is not an incident. It is the blocked phishing email, the laptop left on a train and handed in, the unexpected MFA prompt that someone denied, the invoice that was questioned before the money moved. Nobody got hurt. That is exactly why it is valuable. You have the lesson without the loss, and you have it while the details are still fresh.

Why near misses get ignored

Near misses are awkward. They do not fit the incident process because nothing broke. They do not fit the good-news story because something nearly did. So they get mentioned in passing, someone says 'lucky', and everyone moves on. The same weakness stays in place until a real incident forces a purchase.

From a procurement point of view, that is backwards. A near miss gives you a free specification. It tells you which control was missing, which team was exposed, and whether the fix is a process change or a product. That is far better than a vendor telling you the market is full of threats and you need the top tier of everything.

The 30-minute debrief

Book it within a week. Keep it to 30 minutes. Invite the person closest to the event, the person who owns the relevant system, and whoever signs off IT spend. No slides. One notes-taker. The agenda is four questions and one decision.

0–3 minutes: set the ground rules

Say clearly: this is not a blame meeting. We are here to find the control gap, not the person who nearly clicked. If someone is worried about getting into trouble, they will edit the story, and the story is the useful part.

3–10 minutes: what happened?

Build a short timeline. When did the email arrive, who saw it, what did they do, what stopped it? Keep it factual. 'The invoice looked like it came from our regular supplier, but the bank details had changed' is enough. You do not need a forensic report for a near miss.

10–16 minutes: what almost happened?

This is the question most teams skip. If the email had been actioned, what would the loss have been? A payment? A mailbox takeover? A customer data exposure? A day of downtime? Put a rough shape on it: money, data, time, reputation. This is what turns a near miss into a procurement argument.

16–23 minutes: who needs to know?

Not everyone. But usually more people than hear about it now. Consider the finance team, the affected supplier or client, your IT support provider, your insurer, and anyone who needs to change a process. If personal data was almost exposed, take advice on whether it needs to go further. The point is not to create a paper trail for its own sake; it is to stop the same near miss happening in a different team.

23–28 minutes: what is the single control to fix first?

Pick one. Not five. The most common useful controls are boring: mandatory MFA on email and finance systems, a call-back rule for bank-detail changes, auto-forwarding disabled for external addresses, a proper leaver checklist, laptop encryption, or a simple asset register. Choose the one that would have stopped this near miss, or made it much less likely.

28–30 minutes: assign one owner and one date

A control without an owner is a wish. Write down who is doing it, by when, and how you will know it is done. If it needs money, put it in the next IT review with the near-miss facts attached.

The reusable template

Copy this into a shared document and fill it in after every near miss:

• Date and time of near miss:
• Reported by:
• What happened (short timeline):
• What almost happened (money, data, time, reputation):
• Who needs to know:
• Single control chosen:
• Owner:
• Due date:
• How we will know it worked:
• Procurement note (buy, configure, change process, or train):

That last line matters. It forces the meeting to end with a practical question: are we buying something, changing something, or teaching something? Those are different answers, and they have different costs.

The procurement payoff

A near-miss debrief will not make you immune. It will make your spending less random. When a supplier asks for a meeting, you can point to a real event and ask whether their product would have stopped it. When a renewal comes up, you can check whether the control you agreed is actually in place. And when nothing happens for months, you have a record of the small saves that kept it that way.

That is a better basis for IT procurement than fear. It is also cheaper than waiting for the real thing.