So, you’ve been hacked - or you’re trying to get ahead of the “what if?”. Either way, you’re not overreacting.
For SMEs, data breaches rarely arrive with dramatic movie music. They show up as a “small” problem that quickly turns into a business-wide one: an invoice that doesn’t get paid, a customer calling about a weird email, a staff member locked out of Microsoft 365, or a supplier saying, “That wasn’t us.”
The reality is that the first few days after a breach are a blur of urgent decisions made while the facts are still moving. And that’s exactly why understanding the sequence of what happens - operationally and legally - matters. In this guide, we’ll walk through what you can expect after a breach, what your obligations might be, and how to respond in a way that reduces harm without making things worse.
What counts as a “data breach” (and what doesn’t)
A “data breach” isn’t just a hacker breaking into a server room. In plain terms, it’s any incident where information is accessed, disclosed, altered, or lost without authorisation - especially personal information about customers, staff, or clients.
For SMEs, the most common breaches are surprisingly ordinary.
One of the biggest is the email compromise. A staff member enters their login details into a convincing-looking sign-in page. The attacker gets into the mailbox. Then they do something you don’t notice straight away: they set up a forwarding rule, or quietly watch email threads, waiting for the right moment to jump in.
That’s when the breach becomes visible. A customer gets “updated bank details” that look legitimate because they come from your real email address. Or a PDF invoice is swapped out mid-thread. The business hasn’t lost every file in its system - but the damage can still be serious, because trust is what’s being exploited.
On the other end of the spectrum are accidental disclosures: a spreadsheet sent to the wrong recipient, a link to a shared folder left open, a laptop left in a taxi. These can still be data breaches, and sometimes they’re more likely to create legal notification issues because the organisation can clearly identify what was exposed.
Not every security incident automatically becomes a notifiable data breach. A virus alert that’s cleaned up quickly, with no evidence that information was accessed or disclosed, might be an incident - but not necessarily a “data breach” in the legal sense. The difference matters because it affects what you need to do next.
The first 24–72 hours: what happens operationally
When a breach hits, the first goal is not “figure out who did it.” The first goal is: stop it continuing.
This is where most SMEs learn, in real time, that a breach response isn’t just an IT task. It’s operations, customer relationships, and decision-making under pressure.
Usually, the first phase looks like this: access gets locked down, passwords are reset, multi-factor authentication is enforced (or urgently switched on), suspicious forwarding rules are removed, and compromised devices are isolated. If the breach involves ransomware, it can also include taking systems offline to prevent spread and working out whether backups are intact and safe to restore.
At the same time, there’s a temptation to “wipe everything and start over.” That can backfire. If you erase logs and records too early, you may lose the ability to confirm what happened - which makes it harder to decide whether notifications are required, harder to reassure customers, and harder to deal with insurers or other third parties.
A practical example: a business discovers a staff mailbox has been compromised. They reset the password and move on. Two days later, the attacker is back - because an app permission was granted, or a session token is still active, or another admin account is compromised. That’s why containment needs to be deliberate, not rushed.
This is also the point where good businesses appoint a single “incident lead.” Not because you need a formal crisis room - but because you need one person coordinating the moving parts: IT, legal, customer comms, and management decisions.
Triage: what data was involved and how serious is it?
Once you’ve stabilised the situation, the next phase is triage. This is where most SMEs feel stuck - because “what happened” is rarely obvious.
Triage is about turning the chaos into an answerable set of questions:
- What systems were affected (email, CRM, file storage, accounting, payroll)?
- What types of data are involved (contact details, invoices, identity documents, payment details, health information)?
- How many people are likely impacted?
- Was the data merely accessible, or does it appear to have been copied or misused?
The “seriousness” usually depends less on the drama of the hack and more on the kind of data involved and what harm is likely.
If only names and emails are exposed, the most common harm is phishing and scams. It’s still disruptive, but it’s a different risk profile than if the breach involves identity documents, bank details, or sensitive information. If payroll files were accessed, the downstream harm to staff can be severe. If health information is involved, you’re usually in a higher-risk, higher-scrutiny category.
This is also the stage where SMEs often need help. Not necessarily a full forensic team - but someone who can interpret logs, confirm whether access was unauthorised, and identify whether the attacker is still present.
Do you have to notify anyone?
This is where the legal context matters - and where a lot of small businesses get caught by assumptions.
There are three “buckets” to think about: privacy law, contracts, and industry rules. Even if the first doesn’t apply, the others still might.
Privacy Act and the Notifiable Data Breaches scheme (when it applies)
Australia’s Notifiable Data Breaches (NDB) scheme applies to organisations covered by the Privacy Act. If you’re covered, you must notify the OAIC and affected individuals when there’s an “eligible data breach” - broadly, when unauthorised access/disclosure/loss of personal information is likely to result in serious harm, and that risk hasn’t been prevented by remedial action.
The remedial action point is important in the real world. Sometimes quick steps actually change the legal analysis.
Imagine a staff member accidentally emails a customer list to the wrong recipient. If the file was password-protected, the password wasn’t shared, and you get written confirmation the email was deleted without being opened, you may be able to say: yes, it was an incident - but the likely harm has been prevented. On the other hand, if the spreadsheet includes identity documents and you can’t confidently contain where it went, you’re in a very different position.
“But we’re a small business - aren’t we exempt?”
Many SMEs aren’t covered by the Privacy Act because of the small business exemption. But that’s not the end of the story. Some small businesses are still brought under the Act depending on what they do - and businesses in areas like health services can be captured even if they’re small.
So the right question isn’t “are we small?” It’s: are we covered by the Privacy Act, and if yes, is this an eligible data breach? If you don’t know, it’s worth checking early - because notification obligations (when they exist) are time-sensitive.
Contracts can require notification even when privacy law doesn’t
Even if you’re not covered by the Privacy Act, your contracts might still require you to notify customers, platforms, or vendors.
This is common where you provide services to larger organisations, where you handle client data, or where your customers have their own compliance obligations. Some contracts include strict notice windows and specific communication requirements, including approval processes before you contact affected individuals.
This is why “we don’t have to notify anyone legally” can be a dangerous conclusion. You may not have to notify a regulator - but you may have to notify a client, an insurer, or a service provider.
Industry-specific rules (only for some businesses)
Some industries have additional reporting regimes beyond privacy law. If you’re regulated (finance, health, critical infrastructure and related supply chains), your obligations can stack - and breach response becomes a multi-regulator exercise. This is a key reason SMEs in regulated supply chains should treat breach planning as a business continuity issue, not just an IT one.
If you do notify: what the notice should include
If you do need to notify - whether under privacy law, contract, or as a risk-management step - the goal is the same: reduce harm and maintain trust, without creating unnecessary liability.
The most effective breach notices aren’t long, legalistic documents. They’re clear, factual, and practical. They typically explain what happened at a high level (without speculation), what information was involved, what you’ve done to contain the issue, and what steps people should take next.
For example, where email compromise is involved, your notice should prepare people for invoice scams and impersonation attempts, not just tell them to “be careful.” Where passwords may be affected, telling people to reset passwords is only half the advice; the other half is to warn against password reuse and encourage MFA.
What you should avoid is overconfidence. Saying “no data was accessed” is tempting, but if you don’t have the evidence, it’s a promise that can collapse later. A better approach is to be honest about what you know, what you’re still investigating, and when you’ll update people.
Managing the business fallout (the part people underestimate)
For SMEs, the technical incident is often shorter than the business fallout.
Even a contained breach can create weeks of disruption: resetting systems, dealing with customer anxiety, responding to complaints, handling refunds or chargebacks, and managing reputational damage in a world where trust is hard to win back.
This is also where SMEs feel the “second wave” of a breach. If customer data was accessed, attackers may not do anything obvious immediately. Instead, they use that information to run targeted scams later - phishing that looks unusually plausible, fake invoices that reference real jobs, phone calls that mention real staff names.
Internally, breaches also expose process gaps. Who can approve customer comms? Who talks to suppliers? Who controls admin accounts? If answers are unclear, the breach response feels chaotic - even if the underlying incident was limited.
The “after” phase: uplift and prevention
Once the immediate crisis is over, the next question becomes: how do we stop this happening again - or at least make it much harder and less damaging?
For most SMEs, the highest-impact improvements are not exotic security tools. They’re fundamentals done properly.
Email and admin access should be locked down with MFA. Admin accounts should be limited. Password reuse should be eliminated with a password manager. Backups should exist - and, critically, be tested for restore. Staff should be trained on invoice scams and phishing, because humans are the easiest route in.
This is also the moment to look at data minimisation. If you don’t need to hold identity documents after onboarding, don’t. If old customer spreadsheets sit in shared drives forever, clean them up. A breach can only expose what exists - and SMEs often keep far more than they realise.
Finally, it’s worth reviewing your public-facing privacy statements and internal policies. After a breach, businesses sometimes discover that their privacy policy promises things they don’t actually do, or that their internal processes don’t match what customers reasonably expect. Fixing that isn’t just “compliance” - it reduces future risk.
A simple breach response checklist (without turning the whole article into a list)
Most SMEs don’t need a 40-page incident response plan. But having a short “what we do first” sequence makes a huge difference when everyone is stressed.
A simple way to frame it is:
Contain → Confirm → Assess → Notify → Support → Improve
Contain access so the incident stops. Confirm what happened with evidence. Assess what data and harm are likely. Notify where required (and where sensible). Support customers and staff with practical steps. Then improve your controls so the next incident is smaller, slower, and easier to stop.
If you want a one-page checklist as a downloadable resource, that can sit alongside this article as a companion - without forcing the main post into dot points.
When to get legal help
Some incidents are manageable without formal advice. Others are the kind where early legal input saves you from compounding the damage.
It’s usually worth getting advice early when:
- identity documents, financial info, health info, or other sensitive data may be involved;
- you’re unsure whether you’re covered by the Privacy Act or whether this is an eligible data breach;
- you have enterprise contracts with strict notification clauses;
- there’s extortion or ransomware;
- you need to notify customers and want to avoid inconsistent or risky statements.
Done properly, legal support here isn’t about making things slower. It’s about getting the sequencing right, checking which regimes apply, and helping you communicate clearly without overcommitting or under-disclosing.
Next Steps
A data breach is rarely just an IT problem. For SMEs, it’s usually an operational and trust problem first - and sometimes a legal one too.
If you’ve had a suspected breach, or you want a simple response plan in place before you need it, we can help you work out what obligations apply, review your contracts, and draft customer communications that are accurate, practical, and consistent with your risks.
If you would like a consultation on data breaches, you can reach us at 1800 730 617 or team@sprintlaw.com.au for a free, no-obligations chat.
