05 · Resilience

Incident Response for Non-Technical Businesses: Something Broke — Now What

The Ops Manual · Updated 2026-07-18

The word “incident” sounds corporate, but the thing itself is familiar: the website is down, the booking system is spitting errors, a supplier delivered the wrong stock to the wrong site, an email went to the entire customer list that absolutely should not have. Incident response is just the discipline of handling those moments in a sequence, instead of in a panic.

First, size it honestly

SeverityWhat it looks likeResponse
MinorAnnoying, work continues — one printer down, one report wrongLog it, fix in normal hours
MajorMoney or customers affected — payments failing, site down, wrong order shippedDrop other work, run the sequence below
CriticalSafety, legal exposure or the whole business stoppedAll hands, phone the professionals, consider notification duties

Most heat-of-the-moment arguments are really disagreements about severity. Thirty seconds of “what is this, honestly?” prevents both over-reaction and the more expensive under-reaction.

The four-stage sequence

  1. Stabilise. Stop the bleeding before diagnosing the wound. Switch to the manual workaround, pause the campaign that is sending the broken link, take the payment terminal offline — whatever stops the situation getting worse. You are not fixing yet; you are containing.
  2. Communicate. One nominated spokesperson tells the people affected what is known, what still works and when the next update comes. Short, honest and early beats polished and late, every time. Silence is what customers punish.
  3. Fix. Now diagnose and repair, one change at a time, writing down what you try as you go. Two people changing things simultaneously without telling each other is how a two-hour outage becomes a two-day one.
  4. Learn. Within a week, run a blameless postmortem: what happened, what the timeline was, what made it worse, what made it better, and the one or two changes that would stop a repeat. Blameless is not softness — people hide facts from investigations that hunt for a culprit, and hidden facts guarantee a rerun.
In practice: print the four stages and the severity table on one page and stick it where the team can see it. In the moment, nobody reads documents — they read walls.

Keep an incident log as you go

During a major incident, nominate someone to keep a running note: the time each thing was noticed, decided and changed, in plain language. It feels bureaucratic in the moment and proves invaluable afterwards — for the postmortem, for the insurer if there is a claim, for the supplier dispute if the root cause turns out to be theirs, and for your own memory, which will compress a chaotic four hours into a misleading highlight reel by the following morning. The log also calms the room: writing “14:20 — payments confirmed working again” is a visible sign of progress when everyone is tired. A phone note or a piece of paper is fine; the habit is the point, not the tool. Half a dozen timestamped lines is usually all a small-business incident needs.

When the incident is a cyber one

If the incident involves compromised accounts, ransomware or fraud, the Australian Cyber Security Centre (cyber.gov.au) operates ReportCyber and publishes step-by-step response guidance for small business. If personal information you hold may have been exposed, the OAIC sets out when the Notifiable Data Breaches scheme requires you to notify affected people and the regulator — build “check our notification duties” into the critical-severity row of your one-pager rather than researching it mid-crisis.

Do not promise a fix time you have invented to calm people down. A missed promise converts a technical problem into a trust problem, and trust problems outlive outages by years.

FAQ

Who should be the spokesperson?

Whoever can stay calm and write a clear sentence under pressure — not necessarily the most senior person, and never the person doing the fixing. Splitting fixing from communicating is the single biggest upgrade most small teams can make.

Do minor incidents really need logging?

A one-line log entry, yes. Patterns live in minor incidents: the “printer plays up every few weeks” log is how you discover the failing switch before it takes the EFTPOS down on a Saturday.