Incident Response for a Team of Four

Incident response frameworks assume a security team, a war room and a communications function. Most Australian businesses have none of those, and the person who notices something odd is the person who has to deal with it, between jobs.

This is that version. One page, four people or fewer, and it assumes you find out about the problem the way most businesses do — a customer mentions something strange.

The first hour

1. Write down the time and what was reported.

Before anything else. The date, the time, who said what.

This sounds like bureaucracy and it is the single most valuable thing you will do, because Australia’s notification scheme starts its clock when you become aware of grounds to suspect a breach — not when you confirm one. That timestamp is the only evidence of when the clock started, and reconstructing it later from memory is both unpleasant and unconvincing.

2. Do not start deleting or “cleaning up”.

The instinct is to remove the suspicious thing. Resist it. Whatever it is may be the only record of what happened, and you will need to establish scope before you can tell anyone anything useful.

3. Change the password on the account involved, and turn on multi-factor authentication if it is not on.

This is the one immediate action worth taking. It stops continuation without destroying evidence.

4. Decide whether you are in this alone.

One name, decided in advance. Your IT provider, your insurer’s hotline, or a specialist. The failure mode here is three hours spent deciding whether it is serious enough to escalate — hours that come out of a window measured in days.

What you are actually trying to establish

Not “what happened” in a forensic sense. Three specific things:

Which information was involved. Not which system — which information about which people. This is what determines whether the breach is notifiable and what you would have to tell affected individuals.

Whether it is still happening. An account still compromised is a different situation from one closed off an hour ago.

When it started. Which usually means looking at sign-in logs, and those have a retention period that depends on your licence tier — frequently shorter than the 30 days you have to assess within.

That third point is worth acting on before anything goes wrong. Find out today how long your platform keeps sign-in and file-access history. If the answer is 30 days on your current plan, a breach suspected on day 25 is one you may not be able to scope.

★ Insight ───────────────────────────────────── The binding constraint for a small business is almost never technical skill. It is that the evidence needed to answer “what was accessed” either exists or does not, and that was decided months ago by a licensing choice nobody framed as a security decision. Log retention is bought, not configured, and it is the cheapest thing on any incident-response list. ─────────────────────────────────────────────────

The decision with a deadline

If personal information was involved and you are covered by the Privacy Act, you have 30 calendar days from becoming aware of grounds to suspect, to assess whether this is an eligible breach — one likely to result in serious harm.

Three things about that window are commonly misunderstood:

It is an assessment window, not a response window. The output is a decision, not a resolution.
The Commissioner expects 30 days to be a maximum, not a target. Taking 29 days over something assessable in four is itself a fact about your handling.
Once you conclude it is notifiable, there is no second window. Notification is “as soon as practicable”.

And a change many businesses have missed: from 1 July 2026, the Privacy Act applies to entities that became reporting entities under the second tranche of the anti-money-laundering regime, regardless of turnover. That brings in real estate agents, conveyancers, accountants and lawyers who previously sat under the small-business exemption.

What the first day usually looks like

Worth describing honestly, because the plans never do and the gap between them is where the time goes.

It rarely begins with certainty. It begins with something ambiguous — a customer forwarding an odd email, a login notification from a place nobody has been, an invoice that does not match. Somebody mentions it in passing. It is not obviously an incident, which is precisely why the clock starts unnoticed.

The next few hours are typically spent establishing whether there is anything to establish, by the person who found it, between other work. That is the most expensive phase and the least visible, and it is the one a written page compresses — not by making anyone faster, but by removing the question of whether this is worth escalating.

The one page to write now

Not a plan. A page, printed, somewhere other than your email:

Who starts the clock. One name. Their only job on day one is to record the time.
Who we ring. Name, number, and what they cover.
Where personal information lives. A list of systems, and roughly what each holds.
Who can reach each one. Including anyone who has left.
Our log retention period. Per platform.
Our insurer and policy number, if we have cyber cover.

That page takes about forty minutes to write and it is the difference between a controlled fortnight and an improvised one.

The three things worth arranging before anything happens

None of these can be done during an incident, and all three determine how the week goes.

Know your log retention, per platform. Sign-in history, file access, mailbox activity. This is a licensing question with a security consequence, and the number is usually 30, 90 or 180 days depending on tier. If it is 30, a breach suspected late is a breach you may not be able to scope, and upgrading one tier is frequently cheaper than one hour of forensic work.

Have one account that is not part of your normal sign-in. If your email is compromised, every password reset route runs through the compromised thing. A separate administrative account, with its own recovery method, is the difference between locking an attacker out in ten minutes and negotiating with your own provider for two days.

Agree who talks to customers. Not what they say — who. In a four-person business the instinct is that everybody answers the questions they get, which produces four slightly different accounts within a day, and the differences become the story.

What not to do

Do not notify before you know the scope. A notification that says “some customer information may have been affected, we are not sure which” creates alarm you then cannot resolve, and it does not satisfy the obligation, which requires you to tell people what steps to take.

Do not promise a timeline you cannot meet. “We will have answers by Friday” during an investigation whose length you do not control is a second failure on top of the first.

Do not let it end without a written conclusion. Whatever you decide, record it and the reasoning — including for incidents assessed as not notifiable. That record is what demonstrates a reasonable and expeditious assessment actually happened, and it is the only artefact that survives the week.

Cloud Geeks provides cybersecurity and managed IT for Australian small businesses, including incident support. Websites come from Cosmos Web Tech, apps from Awesome Apps, and the group is Ganda Tech Services. General information, not legal advice.