There’s a particular kind of panic that sets in when a business first realises something’s wrong. A strange login alert, a customer asking why they received an odd email from your address, or a system that simply stops responding. In that moment, the decisions made in the next few hours often matter more than anything done in the weeks that follow.
We work with small and medium businesses across web design, infrastructure, and security, and the businesses that come through a breach in the best shape are rarely the ones with the most expensive tools. They’re the ones who knew, even roughly, what to do first. This isn’t about having a perfect plan. It’s about not wasting the first 24 hours figuring out where to start.
Recognising That Something Has Actually Happened
Breaches rarely announce themselves clearly. There’s no alarm bell, just a collection of small signals that, looked at individually, might mean nothing.
An email that bounces back unexpectedly. A colleague mentioning they received a strange message “from you.” A login notification for a time you weren’t using that system. Files that have moved, renamed themselves, or won’t open. A website that’s behaving oddly, redirecting somewhere it shouldn’t, or showing content that wasn’t there yesterday.
Any one of these on its own might be nothing. But the first hour of a breach response isn’t about being certain. It’s about taking these signals seriously enough to check, rather than assuming everything’s fine and moving on. The cost of investigating something that turns out to be harmless is minutes. The cost of ignoring something that turns out to be real compounds by the hour.
Containing the Situation Without Making It Worse
Once something looks genuinely wrong, the instinct is often to start shutting things down immediately. That instinct is half right. Containment matters, but how it’s done matters too.
The priority is stopping further damage without destroying evidence of what happened, since understanding the breach later depends on what’s still intact now.
A few things tend to help in this first stretch:
Disconnect affected devices from the network rather than shutting them down completely, since some evidence can be lost on shutdown
Change passwords for accounts that may be compromised, starting with email, since email access often unlocks everything else
Revoke active sessions or tokens on affected accounts, which logs out anyone currently using stolen credentials
Avoid deleting anything, even files that look suspicious, until someone with more context has had a chance to look
This is also the point where having multi-factor authentication already in place pays off. An attacker with a stolen password but no access to the second factor is often stopped here, turning what could have been a full breach into a contained, much smaller incident.
Working Out What Actually Happened
With the immediate bleeding stopped, the next few hours are about understanding scope. What was accessed, when, and how. This step is less about technical forensics and more about asking the right questions and writing down the answers as they come in.
Useful questions at this stage include which systems showed unusual activity, what time the activity started, whether any data was downloaded, modified, or sent somewhere, and whether the access point can be identified, a phishing email, a compromised password, an outdated piece of software.
It’s worth being honest that this picture often stays incomplete in the first 24 hours, and that’s normal. The goal isn’t a finished investigation. It’s enough understanding to make informed decisions about who needs to be told and what needs to happen next.
If the breach traces back to a compromised website or hosting environment, this is also where having a clear record of what plugins, themes, or third-party tools were running becomes valuable, since outdated or vulnerable components are a common starting point for these incidents.
Deciding Who Needs to Know, and When
Communication during a breach is a balancing act. Move too slowly and people find out from somewhere other than you, which damages trust further. Move too fast with incomplete information and you risk causing unnecessary alarm or having to walk back details later.
A rough order of priority tends to work well. Internally, the people who need to act, anyone with system access relevant to containment, should know immediately, even before the full picture is clear. Externally, customers or partners whose data might be affected come next, though the message at this stage can be honest about what’s known and not known, rather than waiting for complete certainty.
If the business has cyber insurance, this is also the point to make that call. Many policies have specific requirements about how quickly an incident needs to be reported, and insurers often have resources or contacts that can help with the response itself.
There’s also a regulatory dimension worth being aware of. Depending on the nature and scale of the breach, there may be formal notification obligations, particularly where ransomware or significant data exposure is involved. Even businesses that fall outside strict thresholds often find that being upfront with affected customers, rather than staying quiet and hoping it doesn’t surface, tends to preserve far more trust in the long run.
Getting the Right People Involved
Few small businesses have the in-house expertise to fully investigate and remediate a breach alone, and that’s not a failing, it’s just realistic. Knowing who to call before an incident happens saves precious time during one.
This might include an external IT or security provider who understands the business’s systems, a legal advisor if data exposure or notification obligations are involved, and in more serious cases, reporting the incident to the Australian Cyber Security Centre, which tracks incidents nationally and can sometimes offer guidance based on patterns seen across other businesses.
The value of bringing in outside help early isn’t just technical. It’s also about having someone who’s seen this situation before, who can help separate what’s urgent from what can wait, and who isn’t operating on adrenaline and three hours of sleep.
Documenting Everything as You Go
It’s tempting, in the middle of a stressful day, to focus entirely on fixing things and figure out the paperwork later. Resist that instinct. Documentation done in real time is dramatically more accurate than documentation reconstructed afterward from memory.
A simple running log works fine. Time, what was observed, what action was taken, and by whom. This serves several purposes at once. It helps whoever’s coordinating the response keep track of what’s been done and what hasn’t. It becomes essential if the business needs to report the incident, to insurers, regulators, or affected customers. And it’s invaluable afterward, when reviewing what happened and what could be improved.
This log doesn’t need to be polished. A shared document or even handwritten notes are fine in the moment. The goal is capturing information before it’s lost, not producing something presentable.
The Hours That Shape Everything After
The first 24 hours of a data breach rarely feel calm, and they’re not supposed to. But having even a rough sense of the order of operations, recognise, contain, understand, communicate, escalate, document, turns chaos into something manageable. Businesses that have thought through this in advance, even briefly, consistently handle the real thing better than those encountering these decisions for the first time under pressure.
As a digital agency working across web design, infrastructure, and security for Australian small and medium businesses, we’ve seen how much of a difference those first few hours make to how everything else unfolds, not just technically, but in terms of cost, recovery time, and how much trust survives the experience. Once the immediate response is handled, the conversation usually turns to what an incident like this actually costs a business in real terms, and understanding that fuller picture is worth looking at before an incident happens, not after.
