Guest Wi-Fi Done Right: Convenience Without the Risk

Guest wifi done right means giving visitors internet access on a network that is completely walled off from your servers, point-of-sale, staff devices and cameras. The fix is segmentation: a separate guest SSID on its own VLAN, with client isolation, bandwidth limits and content filtering. The convenience stays; the risk does not.

The problem is not that you offer Wi-Fi to visitors. It is how most small businesses offer it. A single flat network, one Wi-Fi password shared with everyone, the till and the file server and the receptionist’s PC and the customer in the waiting room all sitting on the same network. That setup is convenient to stand up and a genuine liability to run, and it is the most common network design mistake we see across Melbourne SMEs.

Why one flat network is a real risk

When everything shares a single network, every device can, in principle, see every other device. A guest’s phone, a contractor’s laptop, a visitor’s tablet riddled with malware — all of them are placed on the same logical network as your accounting PC, your server, your network-attached storage and your payment terminal. Network segmentation exists precisely to stop that.

The risk is not theoretical. An infected guest device can scan the local network and attempt to reach anything reachable: an unpatched server, a printer with a known vulnerability, a file share with weak permissions. Ransomware spreads laterally — it lands on one machine and moves sideways looking for more. A flat network is a clear corridor for that movement. You have also handed every guest the same pre-shared key, which means it leaks, gets written on a whiteboard, and is never rotated, so anyone who has ever connected can reconnect indefinitely.

There is a performance angle too. On a flat network, a guest streaming video or running a large backup competes directly with your card processing and your line-of-business apps for bandwidth. The till slows at exactly the wrong moment because someone in the waiting room is downloading a film.

Segmentation: the actual fix

The right design separates your network into distinct segments, each on its own VLAN (virtual LAN), with firewall rules controlling what can talk to what. A VLAN lets one physical network behave as several isolated ones, so traffic in one segment cannot reach another unless you explicitly allow it. For a typical business the segments look like this:

The guest segment is the simplest to reason about: it gets internet and nothing else. No path to the server, no path to the POS, no path to the cameras. If a guest device is compromised, the blast radius is the guest network and the open internet — not your business. This is the baseline our cybersecurity services apply to any network that carries both staff and visitor traffic.

Client isolation on the guest SSID

Segmentation keeps guests away from your internal systems. Client isolation keeps guests away from each other. With it enabled on the guest SSID, every connected device can reach the gateway and the internet but cannot see any other device on the same Wi-Fi. That matters in a public-facing setting — a cafe, a clinic waiting room, a retail floor — where you have no idea what is on the strangers’ phones sharing your guest network. Without isolation, one guest can probe another guest’s laptop. With it, they are each in their own bubble. It is a single setting on business-grade gear and it should always be on for guest access.

Bandwidth limits and content filtering

Guest Wi-Fi is a courtesy, not an entitlement to your whole connection. Per-client or per-SSID bandwidth limits stop one visitor saturating the link and protect your trading traffic. Content filtering on the guest network blocks the categories you do not want associated with your business — illegal content, malware-hosting domains, the obviously inappropriate — which is both a duty-of-care matter and a way to keep your IP address out of trouble. A clinic or a venue offering open Wi-Fi to the public has a reasonable interest in not having that connection used for something it will later have to explain.

Captive portals, terms and privacy

A captive portal is the splash page a guest hits before they get online — the one asking them to accept terms, sometimes enter an email or a name. Used well, it does two useful things: it presents an acceptable-use policy so a user has agreed to terms before they connect, and it gives you a clean point to set session limits and expiry.

The privacy angle deserves care. The moment your portal collects an email address or a phone number, you are collecting personal information, and under the Privacy Act and the Australian Privacy Principles you need a reason to hold it, a privacy notice explaining what you do with it, and a sensible retention period. Collecting marketing emails through a Wi-Fi portal and bolting them onto a mailing list without consent is the kind of thing the Office of the Australian Information Commissioner (OAIC) takes a dim view of. Our honest advice to most SMEs: unless you have a real, stated use for the data, do not collect it. A simple click-to-accept portal with an acceptable-use policy gives you the protection without the privacy liability.

Data retention and acceptable use

If you do log guest activity — and there are legitimate reasons to keep basic connection logs — decide how long you keep it and stick to that. Logs are useful for troubleshooting and for the rare occasion you need to demonstrate what happened on your network, but indefinitely hoarding records of who connected and when is a liability, not an asset. A short, defined retention window is the right answer. The acceptable-use policy on the portal should state, in plain language, that the network is monitored, what is not permitted, and that access can be withdrawn. None of this needs to be a legal epic — a few clear sentences does the job.

Why IoT, cameras and printers belong on their own segment

The devices that quietly create the most risk are the ones nobody thinks of as computers. IP cameras, smart TVs, network printers, building sensors, the smart thermostat — collectively the Internet of Things (IoT). They are cheap, rarely patched, frequently shipped with default passwords, and they sit on your network for years. Internet-exposed cameras and recorders with factory credentials are a well-documented soft target, routinely scanned and hijacked.

You cannot reliably secure these devices the way you secure a managed PC, so the strategy is containment. Put them on their own isolated segment with tightly restricted outbound access — a camera needs to reach its recording system and maybe a vendor cloud, and nothing else. If a compromised smart TV cannot reach your file server, the compromise is contained. Keeping IoT and CCTV off both the staff network and the guest network is not over-engineering; it is the single highest-value piece of segmentation for most businesses, because that is where the unpatched, forgotten devices accumulate. It is closely related to the work in our managed IT services, where keeping an accurate inventory of every device on the network is half the battle.

The kit that makes this practical

You cannot do proper segmentation on the consumer router your internet provider shipped you. That box gives you one network and one Wi-Fi, and that is the whole problem. Business-grade equipment — the UniFi, Meraki and Aruba class of gear — is built around exactly this: multiple SSIDs mapped to separate VLANs, client isolation as a tick-box, per-SSID bandwidth and content controls, a built-in captive portal, and central management so you can see and control the whole network from one place.

Which platform suits you depends on size and how you want it managed. UniFi is excellent value and very common in Melbourne SMEs; Meraki and Aruba bring cloud management and licensing models that suit larger or multi-site setups. The brand matters far less than the design — a well-configured network on any of these beats a default-everything deployment on the most expensive one. The value is in the configuration and the ongoing management, which is the part an MSP actually does.

Where the MSP earns its keep

Designing segmentation is not difficult once you have done it a few hundred times; doing it correctly the first time, on a live business, without breaking the things that already work, is where experience shows. The MSP role is mapping your actual devices to the right segments, writing firewall rules that are tight but do not block legitimate traffic, configuring the guest portal and its terms, setting sensible bandwidth and filtering, and then monitoring it so a new device that appears in the wrong place gets noticed. TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers — not an offshore call centre — and we treat network segmentation as a baseline, not a premium add-on.

A Melbourne example

A physiotherapy clinic in Hawthorn we work with had the textbook flat network: a single consumer router, one Wi-Fi password printed on a card at reception, and on that one network sat the practice-management PC holding patient records, two staff laptops, the EFTPOS terminal, three IP cameras and the waiting-room Wi-Fi every patient connected to. A patient’s phone could, in principle, see the machine holding their health record. We replaced the router with business-grade gear and rebuilt it properly: a staff segment for the PCs and practice-management system, an isolated payments segment for the terminal, a guest network with client isolation and a click-to-accept portal that collects nothing, and a separate locked-down segment for the cameras with their default passwords gone. The waiting-room Wi-Fi works exactly as before; it simply can no longer reach anything that matters. Given the patient data involved, that separation is not just good hygiene — it is a defensible position if the practice is ever asked how it protects records.

Frequently asked questions

Is it really a problem to put guests on my normal Wi-Fi?

Yes. On a shared network, a guest device — which you have no control over and cannot trust — sits alongside your servers, payment devices and staff PCs, and can attempt to reach them. An infected visitor phone or a contractor’s laptop becomes a path onto your business systems. Separating guests onto their own isolated network removes that path entirely while keeping the convenience.

Do I need expensive equipment to set up guest Wi-Fi properly?

No. Business-grade gear in the UniFi class is affordable and does everything required — multiple SSIDs, VLANs, client isolation, bandwidth limits and content filtering. The cost is modest compared with the consumer router it replaces. The real work, and the real value, is in configuring and managing it correctly rather than the hardware price.

Should my guest Wi-Fi captive portal collect email addresses?

Only if you have a genuine, stated use for them and a privacy notice covering it — collecting personal information triggers obligations under the Australian Privacy Principles. For most businesses a simple click-to-accept portal with an acceptable-use policy is the better choice: it gives you the legal protection without creating a pile of personal data you then have to safeguard and justify holding.

Where do cameras and smart devices fit in?

On their own isolated segment, separate from both staff and guest networks. IoT devices like cameras, smart TVs and printers are rarely patched and often ship with default passwords, so the strategy is containment: restrict what they can reach so a compromised device cannot move onto anything important.

Getting guest Wi-Fi right

Guest Wi-Fi is meant to be the easy, friendly bit — and it can be, without putting your business one infected phone away from a serious incident. The recipe is consistent: business-grade gear, segmentation into staff, POS, guest, IoT and BYOD, client isolation on the guest SSID, sensible bandwidth and filtering, a portal that protects you without hoarding data, and someone keeping an eye on it. TechAssist runs a 24/7 NOC in Tecoma and offers same-business-day on-site across Melbourne metro on per-user fixed monthly pricing. If your business is still running one flat network with the Wi-Fi password on the wall, get in touch and we will tell you plainly what to fix first.

Mobile device management is how you keep company email and data secure when staff read it on phones, tablets and personal laptops you don’t own. The real problem with bring-your-own-device (BYOD) is the privacy trade-off, and the fix is usually app-protection policies that secure the company data inside an app without taking control of someone’s entire personal phone.

The problem MDM and MAM actually solve

The moment a staff member adds their work Microsoft 365 account to the Mail app on their own iPhone, your company data is sitting on a device you have no control over. No screen lock policy, no encryption guarantee, no way to remove the data if the phone is lost or the person leaves. Multiply that across a 40-person business and you have email, OneDrive files and Teams chats scattered across dozens of unmanaged personal devices.

This is the gap two related technologies close. Mobile device management (MDM) manages the whole device — it enrols the phone or laptop and enforces a passcode, encryption and OS version, and gives you the ability to wipe it. Mobile application management (MAM), or app-protection policy, manages only the company apps and the data inside them. It can require a PIN on the work app, block copy-paste out to personal apps, and wipe just the company data, while never touching the photos, messages or personal accounts on the device.

The distinction matters because most BYOD failures aren’t technical — they’re about trust. Staff don’t want their employer controlling their personal phone, and they’re right to be cautious. MAM answers that objection, and getting the choice right is the difference between a policy people accept and one they quietly work around.

The BYOD privacy tension, and why it kills full enrolment

Ask any team to enrol their personal phones in full MDM and you’ll hear the same fear: “Can the company read my texts? Can they wipe my photos?” With full device enrolment, the honest answer is that the company can see device-level inventory, push configuration, and yes, issue a full wipe that takes the personal data with it. Even when an MSP would never do that, the perception alone pushes people to refuse, use a second unmanaged device, or forward work email to a personal account — far worse for security than the problem you started with.

App-protection policy removes the objection. The company gets a security boundary around its own data — the work account, its files, its email — and the staff member keeps full ownership of everything else. When they leave, you wipe the company container and their holiday photos are untouched. For BYOD this is almost always the right model; you reserve full device management for hardware the business actually owns.

Microsoft Intune: the tool most Melbourne SMEs already have

If you’re on Microsoft 365 Business Premium or any E3/E5 licence, you already own Microsoft Intune — it’s bundled, which is why it’s the default MDM/MAM platform for businesses in our patch. Intune does both jobs from one console and ties into the rest of the Microsoft security stack. Four pieces do the heavy lifting.

Device compliance policies

A compliance policy defines what “healthy” means for a device: minimum OS version, disk encryption on, a passcode of a set length, not jailbroken or rooted. Intune continuously checks enrolled devices and marks each one compliant or non-compliant. On its own this is just a status flag — its power comes from what you connect it to.

App protection policies

This is the MAM layer. An app-protection policy applies to the Microsoft apps (Outlook, Teams, OneDrive, the Office apps) and governs the data inside them. You can require a separate PIN or biometric to open the work app, block cut/copy/paste into personal apps, stop “Save As” to personal storage, encrypt company data, and force a selective wipe of only the in-app company data on command. Critically, this works whether or not the device is enrolled in MDM at all.

Conditional access

Conditional access is the enforcement engine, and it lives in Microsoft Entra ID rather than Intune itself. It evaluates each sign-in and applies rules — for example, only grant access to Exchange Online if the device is marked compliant, or only allow Outlook if an approved app-protection policy is applied. That turns a compliance flag into a real control: a non-compliant or unmanaged device simply doesn’t get the data. We go deeper in our guide to conditional access policies in Microsoft 365.

Selective wipe at offboarding

When someone leaves, you don’t chase their personal phone. From the Intune console you issue a wipe of company data — on a MAM-protected BYOD device that removes the work account and its cached files and leaves the rest alone; on a company-owned enrolled device you can do a full wipe and reset. Combined with disabling the account, this is how secure offboarding actually happens — the step most businesses skip until a former employee still has live access three weeks later.

MDM full enrolment vs MAM app-protection

The single most useful decision in any BYOD rollout is which of these two models a given device gets. Here’s how they compare.

In practice a typical setup uses both: full MDM on the laptops and phones the business bought and owns, and MAM-only app-protection on staff personal devices, with conditional access requiring one or the other before any company data is released.

Company-owned vs BYOD enrolment paths

The enrolment path follows ownership. For company-owned devices, you enrol into full MDM — on iOS usually through Apple Business Manager so the device is supervised and locked to your tenant from first boot; on Windows it’s Autopilot, which ships a laptop that configures itself at first sign-in. These get the full set of compliance and configuration policies because the business owns the hardware.

For BYOD, you avoid full enrolment wherever you can. The staff member installs the standard Microsoft apps, signs in with their work account, and the app-protection policy applies automatically — no enrolment, no agent on the device, nothing that touches their personal data. Where a BYOD device genuinely needs full management you use a model that ring-fences the work side, such as a work profile on Android, but for most SMEs MAM-only covers it without the friction.

How this maps to the Essential Eight and secure offboarding

Mobile device management isn’t a standalone exercise — it’s how several Essential Eight controls reach the devices outside your office walls. The Australian Cyber Security Centre (ACSC) Essential Eight expects multi-factor authentication, patched operating systems and applications, and restricted admin privileges. Intune enforces those on a phone or laptop you can’t physically touch: compliance policies hold devices to a current, patched OS; conditional access pairs with MFA so a stolen password alone doesn’t open the mailbox; and app-protection keeps company data inside sanctioned apps.

Offboarding is where the absence of MDM gets expensive. We worked with a construction firm in Box Hill that had no device management at all — staff used personal phones for site photos, email and the project app. When a site supervisor left for a competitor, the business had no way to remove its data from his phone and no record of what he could still reach. With Intune in place, offboarding is a five-minute job: disable the account, issue a selective wipe of company data, done. That firm now runs MAM on every personal device and full MDM on the company-issued tablets on site.

A sensible BYOD plus MDM policy outline

We have a separate post on writing the BYOD policy itself; here the focus is the technical controls it should mandate. A workable policy ties the rules to enforceable Intune settings rather than good intentions:

• Eligibility. Define which roles may use BYOD and which must use company-owned devices — sensitive client or health data often warrants company hardware.
• Minimum device standard. Require a supported, currently-patched OS and a device passcode or biometric, blocked by conditional access if not met.
• App-protection mandatory. Company data is accessed only through the approved Microsoft apps with app-protection applied — no native mail clients, no forwarding to personal accounts.
• Access conditions. Conditional access requires a compliant or app-protected device before email, files or Teams are released.
• Separation of data. Block copy, paste and “Save As” from work apps into personal storage so company data can’t leak sideways.
• Offboarding and loss. State in writing that the business will selectively wipe company data on exit or device loss — never personal data on a BYOD device — with a single point of contact who actions it the same day.

The policy and the platform have to match. “Devices must be encrypted” means nothing if no system checks; a compliance policy that enforces it does. That pairing — written rules backed by enforced technical controls — is the whole point, and the part most businesses get half-right.

Frequently asked questions

Can my employer read my personal texts or photos if I enrol in MDM?

On a personal BYOD device set up with app-protection (MAM) only, no — the business sees nothing outside the work apps and cannot read your messages, photos or personal accounts. On a company-owned device in full MDM, the business can see device inventory and configuration and can issue a full wipe, which is exactly why we keep full enrolment for company-owned hardware and use app-protection for personal devices.

What’s the difference between MDM and MAM?

MDM (mobile device management) manages the whole device — passcode, encryption, OS, all apps — and is right for company-owned hardware. MAM (mobile application management, or app-protection policy) manages only the company apps and the data inside them, leaving the rest of a personal device alone. For BYOD, MAM is almost always the better fit.

Do I need extra licences for Microsoft Intune?

Usually not. Intune is bundled with Microsoft 365 Business Premium and the E3 and E5 plans, so most SMEs on those licences already own it and aren’t using it. On a lower plan it’s available as an add-on, but for most Melbourne businesses the capability is already paid for.

What happens to company data when someone leaves?

You issue a selective wipe from the Intune console, removing the company account and its cached files. On a BYOD device that’s all it touches — personal data stays put. Pair it with disabling the user’s account so access is revoked immediately. That’s the secure offboarding step businesses without device management can’t perform.

Getting it set up properly

Intune is powerful, but a misconfigured rollout either locks staff out of email or quietly enforces nothing. The work is in the detail: scoping which devices get MDM versus MAM, writing conditional access that doesn’t break legitimate access, and tying offboarding into a repeatable process. As a Melbourne MSP founded in 2014 with 13 Australian-employed engineers, we set up and run Intune across the metro as part of our cybersecurity services and managed IT services, on per-user fixed monthly pricing so it isn’t a surprise line item. If staff devices are reaching your company data with no controls in place, get in touch and we’ll map out what BYOD security should look like for your business.

Data classification is the act of sorting your information by how sensitive it is, so you can apply the right protection to each tier. It is the step most security programs skip, and the reason so many of them are expensive and still leaky: you cannot protect what you have never bothered to identify.

Most SMEs treat every file the same. A lunch-order spreadsheet gets the same controls as a folder of client Tax File Numbers. That is how money gets spent in the wrong places and the genuinely sensitive material slips out the side door.

Why classification comes first

Every other security control assumes you already know what matters. Data Loss Prevention needs to know which data to stop leaving. Encryption needs to know which files are worth encrypting. Retention rules need to know which records have legal minimums. Even your cyber insurer’s questionnaire assumes you can describe where your sensitive data lives. Skip classification and all of these become guesswork — you end up either locking down everything (and the business grinds), or locking down nothing meaningful (and the breach finds you).

The point is not bureaucracy. It is focus. A small business has finite attention and budget. Classification tells you where to spend both. Once you know that 90 per cent of your files are mundane and 10 per cent would hurt if they leaked, you can put real controls on the 10 per cent instead of spreading effort thinly across everything.

A scheme an SME will actually use

Government departments run five- and six-tier classification schemes with handling caveats, dissemination markings and clearance requirements. Do not copy them. They are built for an environment you do not operate in, and if you impose that complexity on a 30-person business in Camberwell, staff will quietly ignore the lot and your scheme dies in a fortnight.

Four tiers is the sweet spot for almost every SME:

• Public — material you would happily put on your website. Brochures, published case studies, job ads. No restrictions.
• Internal — the default for ordinary business content. Project notes, internal emails, draft documents. Not secret, but not for outsiders. This is where most of your data lives.
• Confidential — information that would cause real harm if it leaked. Client records, contracts, financials, personal information, employee files. Encrypt it, control who can share it.
• Restricted — the small set of crown-jewel data: Tax File Numbers, Medicare numbers, health records, banking details, anything under a strict regulatory or contractual obligation. Tightest controls, smallest audience, full audit trail.

If four feels like too many, run three (Public, Internal, Confidential) and fold Restricted into Confidential with stricter handling. The exact labels matter far less than picking a set, defining each one in a sentence a non-technical person understands, and sticking to it.

Classification is useless without handling rules

A label that does not change behaviour is just decoration. The value comes from mapping each tier to concrete handling rules — where it can be stored, how it can be shared, whether it is encrypted, how long it is kept, and how it is destroyed. Write these down once, in plain language, and they become the operating manual for your whole data estate.

This is the part most people forget. Disposal and retention are as much a part of classification as protection. Holding a decade of old client files you no longer need is not caution — it is liability. The records exist to be stolen, subpoenaed or breached, and they serve no business purpose. Classification tells you what to keep, for how long, and what to destroy.

Making it real with Microsoft Purview

For the Melbourne SMEs we work with — almost all on Microsoft 365 — classification stops being a paper exercise the moment you turn it into sensitivity labels in Microsoft Purview. A sensitivity label is a tag that travels with the file or email wherever it goes, and it can enforce the handling rules above rather than just suggest them.

Map your four tiers straight onto four labels. A Confidential label can apply encryption automatically, so a file forwarded to the wrong address is unreadable to whoever receives it. A Restricted label can lock access to a named group and block external sharing outright. The classification scheme and the technical control become the same thing — which is exactly what you want.

Auto-labelling

Manual labelling depends on people choosing the right tag every time, and people are busy. Auto-labelling closes that gap. Purview can scan content against patterns — Tax File Numbers, Medicare numbers, credit card numbers, ABNs — and apply a label automatically, or recommend one to the user. A document with a dozen TFNs in it gets flagged as Confidential whether or not anyone remembered to mark it. Auto-labelling lives in the advanced Purview tier (E5 or the E5 Compliance add-on); manual labelling is included with Business Premium, which is enough to start.

What labels then power

Once data carries labels, the rest of your governance has something to act on. DLP can block a Confidential file from being emailed externally or copied to a USB stick. Retention policies can key off the label. And critically, labels govern what Microsoft 365 Copilot is allowed to surface — Copilot respects the protection on a labelled file, so a document marked Confidential and encrypted will not be casually summarised to someone who should not see it. This is why classification underpins AI governance and is not separate from it. We cover the labelling and DLP setup in depth in our guide to Microsoft Purview data governance, and the AI side in our piece on AI data governance for company data.

The human side: keep it simple or it dies

Here is the truth most vendors will not tell you. The biggest risk to a classification scheme is not the technology — it is asking people to think too hard. If staff have to choose between six labels with overlapping definitions, they will pick the default every time, or whatever is fastest, and your scheme becomes noise.

Four labels. One-sentence definitions. A sensible default (Internal) so the lazy choice is also a safe one. Reserve the friction — the encryption prompts, the sharing blocks — for the top tiers where it earns its keep. A scheme that 80 per cent of staff apply correctly without thinking beats a perfect scheme that everyone routes around. Simplicity is a security control, not a compromise.

Where classification meets Australian compliance

Classification is not just good hygiene — it is how you demonstrate compliance when someone asks. Under the Privacy Act 1988 and the Australian Privacy Principles, you are obliged to take reasonable steps to protect personal information (APP 11) and to not keep it longer than you need (and dispose of it when you do not). A working classification scheme, with labels and retention rules you can show, is exactly the kind of “reasonable steps” the Office of the Australian Information Commissioner (OAIC) expects to see. The privacy reforms moving through Parliament — tighter rules on data minimisation and automated decision-making — only sharpen that expectation.

The same scheme feeds your other obligations. DLP is meaningless without classification to tell it what to watch. Cyber insurers increasingly ask how you identify and protect sensitive data. And, as above, AI governance depends on it entirely. Classification is the foundation layer that makes the rest defensible rather than aspirational.

A Dandenong scenario

A logistics business in Dandenong we work with had grown from a handful of staff to around fifty, and its SharePoint had grown with it — no structure, broad permissions, everything in one bucket. Driver licences, customer contracts, payroll exports and old quotes all sat side by side, equally accessible. They wanted DLP and were about to switch on Copilot, and could not understand why we said classification had to come first.

We ran a discovery pass, agreed a four-tier scheme with their leadership, and built the matching Purview labels. Auto-labelling caught the TFN and licence data that manual marking would have missed. We applied encryption to the Confidential and Restricted tiers, set retention to purge expired quotes and old onboarding documents, then layered DLP on top — which now had a clear target. Only then did Copilot go live, on data that was actually governed. The whole exercise gave them a defensible answer for their insurer and a SharePoint that no longer leaked by default.

TechAssist has run Microsoft 365 for Melbourne SMEs since 2014, with thirteen Australian-employed engineers and a 24/7 NOC in Tecoma. The classification-first review has become one of the more common first steps we run before any DLP or AI rollout.

A phased rollout that works

Do not attempt to classify everything in one weekend. It fails every time. Phase it:

1. Define the scheme. Agree four tiers and one-sentence definitions with leadership. This is a half-day workshop, not a project.
2. Map handling rules. Decide storage, sharing, encryption, retention and disposal for each tier. Write it down.
3. Build the labels. Create the matching Purview sensitivity labels, starting cosmetic (markings only) so people get used to choosing one.
4. Add enforcement to the top tiers. Switch on encryption and sharing controls for Confidential and Restricted once labelling is a habit.
5. Turn on auto-labelling and DLP. Run DLP in audit-only mode for a fortnight, tune out false positives, then move to blocking. Auto-labelling catches what users miss.
6. Then enable AI. With data labelled and protected, Copilot or another sanctioned tool can be turned loose safely.

Each phase delivers value on its own. You are never left with a half-finished mess that protects nothing.

Frequently asked questions

How many classification levels should an SME have?

Four is ideal for most: Public, Internal, Confidential and Restricted. Three works if four feels heavy — fold Restricted into Confidential with stricter handling. Avoid the five- and six-tier government schemes; the extra complexity makes staff disengage, and a scheme people ignore protects nothing.

Do I need an expensive licence to start classifying data?

No. Manual sensitivity labels are included with Microsoft 365 Business Premium, which is enough to define your scheme, apply labels and enforce encryption on the top tiers. Auto-labelling and endpoint DLP sit in the advanced Purview tier (E5 or the E5 Compliance add-on), worth adding once the basics are bedded in.

What is the difference between data classification and a sensitivity label?

Classification is the scheme — the tiers and the rules that decide how each type of data is handled. A sensitivity label is the technical mechanism in Microsoft Purview that puts that scheme into effect, tagging files and enforcing the rules. The classification is the decision; the label is how the decision sticks to the data.

Why does Copilot need data classification first?

Microsoft 365 Copilot surfaces any data the asking user can already access, and respects the protection on labelled files. Without classification, over-permissioned sensitive data — a payroll spreadsheet in a shared site — becomes easy for Copilot to expose. Labelling and protecting that data first is what makes an AI rollout safe rather than a quiet exposure incident.

Where to start

Pick four tiers, write a one-line definition for each, and agree the handling rules. Build the matching Purview labels, start cosmetic, then add encryption to the top two. That alone puts you ahead of most SMEs and gives you the foundation every other control — DLP, retention, AI governance — depends on.

If you would like a hand defining a classification scheme, building the Purview labels and getting your data governed before you switch on DLP or Copilot, talk to our cyber security team, or get in touch with TechAssist. We will tell you plainly what to classify first and what you can safely leave alone.

Supply chain risk management is the discipline of knowing which third parties touch your data, how exposed each one makes you, and what you would do if one was breached. For an SME that means a vendor inventory, a classification of each supplier by risk, and the right questions before you hand over data.

The uncomfortable truth is that your data no longer sits in one place you control. It sits in your accounting platform, your CRM, your payroll provider, your email host and the dozen smaller SaaS apps your team signed up for. A breach at any one of them is your problem — and potentially your reportable obligation under the Privacy Act.

Why third-party risk is now a leading breach vector

For years the security conversation focused on hardening your own perimeter — firewalls, patching, multi-factor authentication. That work still matters, but attackers worked out something obvious: it is far easier to breach one supplier with weak controls and ride that access into hundreds of downstream businesses than to attack each one individually. So the breach rarely happens inside your four walls. It happens at a vendor — a software provider, an outsourced bookkeeper, a marketing platform — and your data is collateral. You did everything right with MFA and backups, and you still end up notifying customers because a supplier you trusted left a database exposed.

The Australian context makes this concrete. The last few years have seen a string of large supplier and service-provider breaches where the headline organisation was big, but the real damage fanned out across thousands of smaller businesses whose data was processed on their behalf. When a payroll outsourcer or a legal-services platform is breached, every business that fed it data is suddenly exposed — and most had no idea how much was sitting there, or how weak that supplier’s controls were. The lesson is blunt: your security posture is only as strong as the weakest supplier holding your data.

Doing vendor risk management without enterprise GRC

Large organisations run formal governance, risk and compliance (GRC) programmes with dedicated teams, risk registers and continuous monitoring. An SME has none of that and does not need it. What you need is a “lite” version that captures most of the value for a fraction of the effort — five habits.

1. Maintain a vendor inventory

You cannot manage risk you cannot see. List every external party that holds, processes or can access your data and systems. Most SMEs are surprised by how long this list is once they write it down — accounting software, CRM, payroll, Microsoft 365, file storage, e-signature tools, the booking system, the marketing platform, the backup provider, and every smaller app a team member signed up for on a credit card. That last category is the dangerous one, and it overlaps with the problem we cover in our piece on auditing SaaS sprawl and hidden apps. The inventory does not need to be sophisticated — a spreadsheet with the vendor name, what data they hold, who owns the relationship, and how critical they are will do. The discipline is keeping it current.

2. Classify by data sensitivity and criticality

Not every vendor deserves the same scrutiny. Sort your inventory along two axes: how sensitive is the data they hold, and how badly would it hurt if they went down or were breached? The handful of suppliers that hold sensitive personal data, payment information or your core operational systems are your tier-one vendors — they get real questions and contract scrutiny. The rest get a lighter touch. Trying to assess every supplier to the same depth is how SMEs give up on vendor risk entirely.

3. Ask key suppliers the right questions

For your tier-one suppliers, a short questionnaire does most of the work. You are not auditing them; you are checking they are not obviously negligent and getting answers on the record. The questions that matter:

• Certifications. Do they hold ISO 27001, SOC 2, IRAP or an equivalent? A current certification is not a guarantee, but it tells you an independent party has looked at their controls.
• MFA and access control. Is multi-factor authentication enforced on their systems and on the admin access to your data?
• Breach notification. Will they notify you, and how quickly, if they suffer an incident affecting your data? Get the timeframe in writing.
• Data location. Where is your data physically stored and processed? Onshore in Australia, or offshore in a jurisdiction with different privacy rules?
• Sub-processors. Who else do they hand your data to? A vendor’s own suppliers become your risk, and the chain is often longer than anyone admits.

If a supplier cannot or will not answer these, that is itself a finding. A vendor that bristles at basic security questions is telling you something about how they treat your data.

4. Bake security clauses into contracts

Verbal assurances are worthless when something goes wrong. Where you have negotiating room, get the important commitments into the contract or data-processing agreement: a defined breach-notification window, a requirement to maintain reasonable security controls, restrictions on where data is stored, limits on sub-processors, and an obligation to return or destroy your data when the relationship ends. For the suppliers you choose and pay, this is where your virtual CIO earns their keep — reading the agreement before you sign it.

5. Review annually

Vendor risk is not set-and-forget. Suppliers change ownership, move data offshore, or quietly degrade their security. Once a year, pull out the inventory, confirm the tier-one suppliers still hold the certifications they claimed, and remove the vendors you no longer use. The annual review is the single habit that keeps the whole exercise honest.

A Box Hill example

A professional services firm in Box Hill we work with came to us after a near-miss. One of their outsourced administrative suppliers had suffered a data incident, and the firm spent a frantic week trying to work out whether any client data was caught up in it — only to discover they had no record of what that supplier held or where it was stored. The answer turned out to be “not much,” but the panic was real.

We built them a vendor inventory from scratch, classified their suppliers, and sent the tier-one ones a short questionnaire. Two could not confirm MFA on their admin access; one was storing data offshore the firm did not know about. None of it was catastrophic, but all of it was the kind of thing you want to know before an incident, not during one.

The flip side: your customers are now assessing you

Here is the part SMEs often miss. While you assess your suppliers, your customers — especially the larger ones — are assessing you. Vendor questionnaires flow in both directions. If you supply a listed company, a government department or any sizeable organisation, expect their procurement team to send you the same questions you should be asking your own vendors: what certifications do you hold, is MFA enforced, where is data stored, how fast will you notify us of a breach.

This is where demonstrating a recognised baseline pays off commercially, not just defensively. Holding Essential Eight alignment, an SMB1001 certification, ISO 27001 or SOC 2 turns a painful back-and-forth into a single document you hand over. We cover the SME-focused option in our guide to Essential Eight compliance for Melbourne businesses, and our cyber insurance guide for Australian SMEs shows how these credentials connect. The business that can answer the questionnaire quickly wins the work over the one that cannot.

Offboarding vendors properly

The riskiest vendors are often the ones you stopped using but never properly disconnected. A trial app that still has an active OAuth grant into your Microsoft 365, a former bookkeeper whose login was never disabled, a marketing tool with a standing API token reading your customer list — these are live doors into your environment nobody is watching.

Offboarding a vendor means more than cancelling the subscription. Revoke their OAuth app permissions in Microsoft 365 or Google Workspace, disable any service accounts or API keys, confirm they have returned or destroyed your data per the contract, and remove any standing access your staff held to their platform. Reviewing those OAuth grants routinely surfaces forgotten third-party access no one remembers approving — our cyber security services include exactly this kind of access hygiene.

Frequently asked questions

What is the difference between supply chain risk and third-party risk?

Third-party risk is the risk introduced by any external party you deal with directly. Supply-chain risk is broader and includes the parties behind those parties — your vendor’s vendors, the sub-processors handling your data further down the chain. For a small business the practical work is the same: know who holds your data, and how exposed each link makes you.

Do we need expensive GRC software to do this?

No. For an SME a maintained spreadsheet, a sensible classification of suppliers by risk, a short questionnaire for the important ones and an annual review will deliver almost all the benefit. Dedicated third-party risk platforms are built for enterprises managing hundreds of vendors under regulatory mandate. Start with the discipline, not the tooling.

What do we do if a key supplier is breached?

Check your inventory to confirm what data the supplier held, contact them for confirmation of what was affected, and assess whether the incident triggers your obligations under the OAIC’s Notifiable Data Breaches scheme. If personal information you are responsible for was likely accessed and serious harm is likely, you may need to notify the OAIC and affected individuals — far easier when you already know what the supplier held.

Where to start

TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC at Tecoma — no offshore helpdesk. We help SMEs get a grip on third-party risk without enterprise overhead: building the vendor inventory, classifying suppliers, drafting the questions, cleaning up forgotten OAuth access, and getting you ready to answer your own customers’ security questionnaires. If you do not have a vendor inventory, that is the place to start. Get in touch and we will scope it with you.

A cyber tabletop exercise is a facilitated, discussion-based walkthrough of a realistic cyber incident — your team talks through how they’d respond, step by step, while a facilitator throws in complications. No real systems are touched, no production data is at risk. For the price of a couple of hours in a room, it’s the cheapest, highest-value security exercise an SME can run.

Most businesses buy controls and assume they’d cope on the day. A tabletop tests the assumption before an actual attacker does. It exposes the awkward gaps — who decides whether to pay a ransom, where the offline contacts list lives, whether anyone has actually read the cyber insurance policy — while the cost of finding out is a meeting, not a disaster.

What a tabletop exercise actually is

The format is deliberately low-tech. You gather the right people in a room, present a plausible incident, and walk through the response as a guided conversation. The facilitator describes the scenario, reveals new information at intervals (“injects”), and asks decision questions at each turn: What do we do now? Who makes that call? Who do we have to notify, and by when?

Nothing is simulated technically. You’re not unplugging servers or launching a fake phishing campaign — that’s a live or red-team exercise, a different and more expensive thing. A tabletop tests your decisions, your roles, your communications and your documentation. It answers the question that controls alone never do: when something goes wrong at 4:45pm on a Friday, does this team actually know what to do?

That’s why it sits at the top of the value-for-money list. A penetration test tells you whether attackers can get in. A tabletop tells you whether you can respond once they have. We cover the testing side in our piece on penetration testing; this is the other half of the picture.

Why it’s the best-value exercise you can run

Three reasons. First, cost: the only real input is people’s time, usually 90 minutes once or twice a year. No tooling, no consultants required for a first pass. Second, breadth: in one session you stress-test your incident plan, your decision-making, your notification obligations and your backups all at once. Third, it surfaces the failures that genuinely sink SMEs — not technical zero-days, but the human and process gaps. Nobody knew who could authorise a payment hold. The disaster recovery plan referenced a staff member who left in 2022. The “current” backup hadn’t been test-restored in eighteen months.

Those are the things that turn a manageable incident into a week of chaos, and a tabletop finds them in an afternoon.

Who should be in the room

The single biggest mistake is treating a cyber incident as an IT problem and inviting only IT. A real incident is a business event with legal, financial, operational and reputational consequences. The people who’ll actually make the decisions on the day need to be the people in the exercise.

• Owner or managing director — the person who ultimately decides whether to pay, to go public, to pull systems offline. Their absence is the most common reason a tabletop is toothless.
• Operations — they understand what the business can and can’t run without, and what “down for a day” actually costs.
• Finance — for ransom and fraud scenarios especially. They hold the payment controls and know the bank relationships.
• IT or your MSP — to speak to containment, recovery, what’s logged and what can realistically be restored, and how fast.
• Communications or whoever fronts customers — staff, clients, suppliers and possibly media all need handling, and silence is its own decision.

For a small business these might be five people wearing seven hats, and that’s fine. The point is to have every function represented, not to fill seats.

How to run one

1. Pick a realistic scenario

Choose something that could plausibly happen to your business, not a Hollywood cyber-war. The four that matter most for Australian SMEs:

• Ransomware — files encrypted, a ransom note, operations halted.
• Business email compromise (BEC) payment fraud — a supplier’s “updated bank details” email that diverts a real payment.
• A stolen or lost laptop — a device with mailbox and file access gone from a cafe or car.
• Microsoft 365 account takeover — a phished login giving an attacker access to mail, files and Teams.

Rotate the scenario each time. Don’t run ransomware every year and call it covered.

2. Inject complications

The scenario shouldn’t unfold cleanly. Part-way through, the facilitator reveals a twist: the backups are also encrypted; the one person who knows the firewall is on a plane; a journalist has already called. Injects are where comfortable plans fall apart and the real learning happens.

3. Ask decision questions and capture gaps

At each stage, push for specifics. Who makes this call? Who do we legally have to notify, and within what window? Where’s our offline list of contacts if email and Teams are down? The facilitator’s job is to record every “we’re not sure” and “we’d have to check” — those uncertainties are the output. A scribe writing down each gap and unanswered question is what turns the session into something actionable.

A sample 90-minute agenda

A sample scenario you can run

Here’s one a real Melbourne SME could use verbatim. A manufacturing business in Dandenong arrives Monday to find production-planning files won’t open and a ransom note demanding payment in cryptocurrency sits on the shared drive. Staff can’t process orders.

Work through it: Who’s leading the response? Do we shut down the network to contain it? Inject one — IT reports the most recent backup ran successfully but has never been test-restored, so nobody can confirm it works. Inject two — a production supervisor mentions they reused their work password on a personal site that was breached last year. Inject three — a key customer rings asking why their order is late, and a second emails asking if their data is safe.

Now the hard questions. Do we engage our cyber insurer before doing anything, given the policy may require it? Does this trigger the Notifiable Data Breaches scheme, and who assesses that? Who tells staff what they can and can’t say? You’ll likely find at least three things nobody had a confident answer for — which is exactly the point.

Turning findings into actions

A tabletop that ends with a nice discussion and no follow-up was a waste of an afternoon. Before everyone leaves, every gap on the list needs an owner and a date. “Build an offline contact sheet — Ops, two weeks.” “Test-restore the backups quarterly — MSP, ongoing.” “Add a verbal-confirmation rule for any bank-detail change over $5,000 — Finance, this week.” We feed these straight into a remediation plan, and the most valuable ones usually point at controls: multi-factor authentication everywhere, conditional access, tested backups. Those tie into the work we describe in our guides on conditional access in Microsoft 365 and recovery time and recovery point objectives.

The second run, six to twelve months later, should open by checking off the previous list. That closed loop — find, fix, verify — is what separates a business that’s genuinely ready from one that merely owns an incident response plan.

How often to run one

Annually as a baseline, and again after any major change: a new core system, a merger or acquisition, a shift to a new cloud platform, or significant staff turnover in the key roles. A plan written around last year’s team and last year’s systems quietly goes stale. An annual rhythm keeps it current and keeps the muscle memory warm.

How it satisfies insurers and Essential Eight expectations

This isn’t only good practice — it increasingly maps to what insurers and frameworks expect. Cyber insurance applications and renewals now routinely ask whether you have an incident response plan and whether you test it. “Yes, and we run a tabletop annually” is a materially stronger answer than a dusty document, and it can shape both whether you’re covered and what you pay. We unpack this in our cyber insurance guide for Australian SMEs.

On the framework side, the Australian Cyber Security Centre (ACSC) builds the Essential Eight around technical mitigations, but the higher maturity levels and the broader ACSC guidance assume you can actually respond to and recover from an incident — tested backups, a workable plan, and people who know their roles. A tabletop is how you prove the human side of that holds together, not just the technical controls. It’s the rehearsal that makes the documentation real.

Frequently asked questions

How long should a tabletop exercise take?

90 minutes to two hours is the sweet spot for an SME. Long enough to work through a scenario and a few injects properly, short enough that busy decision-makers will actually commit the time. Anything under an hour rarely gets past the obvious; anything over half a day usually means too many people or too broad a scope.

Do we need an external facilitator?

Not for your first one. A capable internal lead or your MSP can run it from a prepared scenario. An independent facilitator earns their keep later, because they ask the uncomfortable questions an internal person might smooth over, and they can play injects without the group seeing them coming.

What’s the difference between a tabletop and a real simulation?

A tabletop is a discussion — you talk through decisions, nothing technical happens. A live simulation or red-team exercise actually executes attacks or recovery steps against real systems. Tabletops are cheaper, lower-risk and where every business should start; simulations come later, once the basics are solid.

Who should facilitate if the MD needs to be a participant?

Whoever facilitates should stay neutral and not be a decision-maker in the scenario, so the MD participates rather than runs the session. That’s a common reason businesses bring in their MSP or an external facilitator — it frees the leadership team to actually make the calls.

Where to start

You don’t need a budget or a consultant to begin. Pick one scenario from this post, block 90 minutes, get the right five people in a room, and walk it through. Capture every gap and assign an owner before you leave. That single session will tell you more about your real readiness than any amount of policy documentation.

If you’d rather have it facilitated properly — a tailored scenario, sharp injects, and a remediation plan you can actually action — that’s part of what we do. TechAssist is a Melbourne-based MSP founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma, and we run tabletop exercises as part of our cybersecurity services. Get in touch and we’ll help you rehearse the bad day before it arrives.

A good incident response plan answers the questions you won’t be able to think clearly about at 2am: who’s in charge, who they call, what they do in the first half hour, and who’s allowed to pull a server offline. If your plan doesn’t fit on one page, nobody will read it when it matters.

That’s the gap most SMEs have. They’ve got a document — usually written to pass an audit — and it’s useless under pressure. Here’s how to build an incident response plan your team can actually follow when something goes wrong.

Why most SME incident response plans fail

The plans we’re handed when we take on a new client usually fail for one of three reasons, and often all three.

They’re too long. A 35-page document with a glossary, a RACI matrix and four appendices is not a plan — it’s a compliance artefact. When a finance manager in Hawthorn notices their mailbox sending invoices they didn’t write, they won’t page through a PDF. They need to know who to ring and what to touch, in seconds.

They’ve never been tested. A plan that has only ever been read is a guess. You don’t find out that the listed “incident lead” left eight months ago, or that nobody knows the after-hours number for your IT provider, until you’re already in a live event.

They were written for auditors, not for 2am. A document that satisfies an ISO 27001 control reads very differently from one a stressed staff member can act on. The first describes a process in the passive voice; the second tells a named human to do a specific thing right now. You need both, but if you only have time for one, write the one for 2am.

The six phases, in plain English

Every credible incident response framework — the ACSC’s guidance and the international NIST model both land in the same place — breaks a response into six phases. You don’t need to memorise the jargon, but you do need to understand what each phase is for.

• Prepare. Everything you do before an incident: the plan, the contact list, logging, backups, and training so people recognise an incident when they see one. This phase decides how the other five go.
• Detect. Noticing something is wrong and confirming it’s real. The faster you detect, the less damage gets done. Detection that relies on a customer phoning to say their data is on a forum isn’t detection — it’s notification.
• Contain. Stopping the spread: isolating the affected machine, disabling the compromised account, blocking the malicious sender. Stop the bleeding before you worry about the cure.
• Eradicate. Removing the cause — the malware, the foothold, the dodgy mail rule the attacker created. Containment buys time; eradication makes it safe to come back.
• Recover. Bringing systems back in a controlled way, restoring from clean backups, and watching closely in case the attacker is still around.
• Lessons learned. The bit everyone skips. A short, blameless review of what happened and what you’d change. Skip it and you’ll relive the same incident next quarter.

The mistake is treating these as neat, sequential stages. In a real event you’ll be detecting, containing and notifying at once. The phases are a checklist of what must happen, not a timeline.

What a usable one-page plan contains

The plan people actually follow is short, specific and pinned somewhere everyone can reach. Here’s what earns a place on the single page.

Roles and a call tree

Name an incident lead — one person who owns the response and can make decisions — and a deputy for when they’re on a plane. Then a call tree: who rings whom, in what order. The staff member who spots the problem rings the lead, who decides whether to escalate and who else gets pulled in. Names and mobile numbers, not job titles. “Notify the CISO” is no use to a business that doesn’t have one.

Severity levels

Three is plenty. A simple severity scale stops people either panicking over spam or shrugging at ransomware. Something like:

First-30-minutes actions

The single most valuable part of the page. A short, ordered checklist for before anyone has worked out exactly what’s happening: don’t turn the machine off (you’ll lose evidence in memory), disconnect it from the network instead, change the affected user’s password, ring the incident lead, and start a timestamped log of who did what and when. That log matters later — for your insurer, for the OAIC, and for the lessons-learned review.

Who can authorise disconnecting systems

Spell out, by name, who has the authority to pull production systems offline. In the heat of an incident, the worst outcome is a staff member who can see the problem but is too afraid to act because they’re not sure they’re allowed to take the line-of-business server down. Pre-authorise it. The incident lead, or a named director, can make that call without waiting for a meeting.

Communications

Decide in advance who says what to whom. Internally: how you tell staff without tipping off an attacker who may be reading the same mailboxes (use a phone tree or an out-of-band channel, not the compromised email). Externally, you may have legal duties:

• The OAIC. If personal information is breached and serious harm is likely, the notifiable data breaches scheme requires you to notify the Office of the Australian Information Commissioner and affected individuals. We’ve covered the timing and thresholds in our piece on the OAIC obligations for Melbourne businesses. Build the assessment trigger straight into your plan.
• ReportCyber and the ACSC. Cybercrime should be reported to the Australian Cyber Security Centre (ACSC) through ReportCyber. It doesn’t replace your other obligations, but it’s the right channel.
• Customers. A pre-agreed holding statement saves you drafting one while the phones are ringing. Honest, brief, no speculation.

Recovery priorities tied to RTO and RPO

Not everything comes back at once, so the plan should rank what comes back first. That ranking comes straight from your recovery time objective (how long you can be down) and recovery point objective (how much data you can afford to lose). If you haven’t set those, our guide on RTO versus RPO walks through how. The short version: the systems with the tightest RTO get restored first, and your backup design has to actually meet the RPO you’ve promised — tested, not assumed.

An IR plan is not a BCP or DR plan

People use these terms interchangeably, then wonder why the documents contradict each other. They answer different questions.

They overlap. A ransomware event might trigger all three: the IR plan handles containment and eradication, the DR plan handles restoring systems from backup, and the BCP keeps invoices going out and staff paid while it happens. Keep them as separate, linked documents rather than one giant file, and make sure the recovery steps in your IR plan point at the same RTO/RPO targets your DR plan uses.

Test it before it’s real

An untested plan is a hypothesis. The cheapest, most effective test is a tabletop exercise: get the people named in the plan around a table for 90 minutes and walk through a realistic scenario. “It’s 7am Monday, finance can’t open any files and there’s a ransom note on the desktop. Go.” Then watch what breaks.

Every tabletop we run surfaces the same gaps: the after-hours number is wrong, two people both think they’re the lead, nobody knows where the offline backups are, or the plan assumes a tool the business doesn’t have. None of those are failures — finding them in a meeting room beats finding them in a real breach. Run one at least annually, and again whenever something significant changes. It’s a core part of being Essential Eight aligned, not a nice-to-have.

Decide who you’re calling before you need them

When a P1 hits, you do not want to be googling “incident response Melbourne” at 2am. The contact list — current numbers, on the page — should include the people you’ll genuinely need:

• Your MSP. The team that knows your environment and can contain the incident technically. Response time is the whole game here.
• Your cyber insurer. Most cyber policies require you to notify them early, often within hours, and many provide a breach-response hotline and panel of specialists. Notify late and you risk the claim.
• Your lawyer. For anything involving personal data, regulatory notification or potential liability, get legal advice early. It also helps protect privilege over the investigation.

A manufacturing business in Dandenong we work with learned this the practical way. A staff member clicked a convincing invoice link, credentials were phished, and within an hour the attacker was setting up forwarding rules to skim payment redirections. Because their plan named us as first call and pre-authorised us to disable accounts, we killed the session, reset the credentials and locked the mailbox down before money moved. The plan didn’t prevent the click — nothing does entirely — but it turned a potential six-figure fraud into a contained, two-hour incident.

TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers and no offshore helpdesk. We target sub-15-minute response on critical incidents from our 24/7 NOC in Tecoma — which is exactly when an incident response plan stops being a document and starts being a clock. If you want a plan that holds up under pressure, our security and SOC services and broader cybersecurity services are built around detection and response, not just policy. Happy to pressure-test your current plan with a tabletop before something forces the issue.

Frequently asked questions

How long should an incident response plan be?

The part people act on should fit on one page: roles, call tree, severity levels, first-30-minutes actions and the key contacts. You can keep longer supporting detail — runbooks, notification templates, the OAIC assessment process — in a separate document, but the action page has to be short enough to use under pressure.

What’s the difference between an incident response plan and a disaster recovery plan?

The incident response plan covers how you detect, contain and clean up a security incident. The disaster recovery plan covers how you get IT systems back online after any outage, including non-security ones like hardware failure. A serious cyber attack usually triggers both, plus your business continuity plan, so keep them linked but separate.

How often should we test our incident response plan?

At least once a year with a tabletop exercise, and again after any significant change — a new core system, a major staffing change, or a merger. Testing is where you find the broken phone numbers and unclear roles before a real incident does.

Who do we have to notify after a breach in Australia?

If personal information is involved and serious harm is likely, you must notify the OAIC and affected individuals under the notifiable data breaches scheme. Cybercrime should also be reported to the ACSC through ReportCyber. Notify your cyber insurer early too — most policies require prompt notification.

Can our staff disconnect a server during an incident?

Only if your plan says so, by name. Pre-authorise specific people to take systems offline, because the worst outcome is a staff member who can see the problem but hesitates because they’re not sure they’re allowed to act. Spell out who has that authority before you need it.

Penetration testing vs vulnerability scanning is not an either/or decision. Vulnerability scanning is automated, broad and frequent — it finds known weaknesses across your environment. Penetration testing is manual, human-led and deep — it proves what an attacker could actually exploit. Most Melbourne SMEs need both, used for different jobs.

The confusion costs money. Businesses pay for an expensive pen test when a cheap recurring scan was what they needed, or they tick a “we scan monthly” box and assume that covers a client review demanding a real test. Here’s how to tell which one a situation actually calls for.

The quick comparison

Read that table as roles, not rivals. Scanning keeps you honest week to week. A pen test tells you whether your defences hold up when a skilled human is actively trying to get past them. You want the cheap, frequent thing running constantly and the deep thing done deliberately at the right moments.

What vulnerability scanning actually does

A vulnerability scanner connects to your network, servers, endpoints and public-facing systems and compares what it finds against a constantly updated database of known weaknesses. Missing Windows patches, an outdated firewall firmware, a database listening on a port it shouldn’t, TLS misconfigurations, default credentials still in place — the scanner catalogues all of it and ranks each finding by severity, usually with a CVSS score.

Its great strength is coverage and repeatability. You can scan a whole environment overnight, then again next week, and watch the numbers trend down as you patch. That’s exactly the discipline you want, because the overwhelming majority of breaches exploit known vulnerabilities that already had a fix available. Scanning catches those before someone else does.

Its limitation is judgement. A scanner reports that a flaw exists; it doesn’t tell you whether that flaw is reachable, chains into anything worse, or is already neutralised by another control. It produces false positives, and has no business context — it can’t tell you the “medium” on your billing server matters far more than the “high” on a test box nobody uses.

What penetration testing actually does

A penetration test puts a skilled human in the attacker’s seat. Rather than listing what might be wrong, the tester sets out to prove what an attacker could actually achieve — getting onto the network, escalating privileges, moving laterally, and reaching data or systems that should be off-limits. They chain small weaknesses together the way a real intruder does: a forgotten account here, a misconfigured share there, a reused password, and suddenly they’re domain admin.

That’s the part automation can’t replicate. A scanner sees issues in isolation; a good tester sees the path. They’ll also find logic flaws a scanner is blind to — an ordering process that lets you change someone else’s invoice, an API that leaks records if you increment an ID in the URL. The deliverable isn’t a list of maybes; it’s evidence of a specific, demonstrated way in.

The main types of pen test

• External — testing your internet-facing systems (website, VPN, mail, remote access) the way an attacker on the open internet would see them. The most common starting point.
• Internal — simulating an attacker who already has a foothold: a compromised laptop, a malicious insider, or a contractor on your network. This tests how far someone gets once they’re past the perimeter.
• Web application — deep testing of a specific app or portal for flaws like injection, broken access control and authentication weaknesses. Essential before launching anything that handles customer data or payments.
• Phishing and social engineering — testing your people, not just your tech. A controlled campaign that measures who clicks, who hands over credentials, and whether your controls catch it. Often the most uncomfortable and most useful result.

When an SME needs which

For day-to-day security hygiene, run vulnerability scanning continuously. It belongs in your ongoing operations alongside patching, monitoring and backups — the routine work that keeps your attack surface small. We fold scanning into our managed cybersecurity and SOC monitoring so findings get triaged and fixed, not just emailed to someone who’s already flat out.

Reach for a penetration test at specific moments:

• Compliance demands it. Some frameworks, certifications and contracts explicitly require an independent test at a set interval.
• Before a big launch. A new customer portal, payment flow or public API deserves a real test before it goes live, not after a breach.
• Cyber insurance or a renewal. Insurers increasingly want evidence your controls actually work, not just a policy document.
• A client security review. When you’re bidding for enterprise or government work, their procurement team often asks for a recent pen test report. No report, no contract.
• Annually as a baseline. Even with none of the above, a yearly external test is sensible practice for a business holding meaningful data.

A professional services firm in Camberwell we work with learned this the hard way. They’d scanned diligently for two years and assumed that covered them. Then a major client’s security team demanded a current penetration test report before renewing a six-figure contract — a scan summary wasn’t acceptable. We arranged an external and web app test, the report surfaced two genuinely exploitable issues the scans had only flagged as “informational”, and the remediated report kept the contract. Scanning had done its job; it just wasn’t the job being asked for.

What a good report looks like

This is where pen tests earn or waste their money. A weak report is a raw tool dump with hundreds of low-priority noise items and no narrative. A good one is written for two audiences at once.

The executive summary tells a non-technical director what was tested, what the tester achieved, and how much risk it represents in plain terms — “we reached your full client database from the public internet within a day” lands differently than a CVSS table. The technical body then walks each finding through: what it is, proof it’s real, the business impact, severity, and clear remediation steps. A good tester ranks by genuine exploitable risk in your context, not just raw severity.

The report is the start, not the end. Remediation is where the value is realised — fixing the issues, then ideally a retest to confirm the fixes actually hold. A pen test report sitting unread in a folder has bought you nothing but a false sense of security.

How this maps to Essential Eight and cyber insurance

The two practices line up neatly with the Essential Eight. The Australian Cyber Security Centre (ACSC) builds the framework around controls like patching applications and operating systems, restricting admin privileges and configuring Microsoft Office macros. Vulnerability scanning is how you continuously check those controls are in place — that patches landed, that no exposed service crept back in. A penetration test validates that the whole stack holds together against a real adversary, including gaps no single control owns.

Cyber insurers have moved the same way. Renewals now routinely ask whether you run regular vulnerability scanning, enforce multi-factor authentication, and conduct penetration testing — and increasingly they want evidence, not assertions. A current test report and a remediation trail make the underwriting conversation far easier, and can move your premium. We cover the broader picture in our guides to reaching Essential Eight maturity and the cyber insurance landscape for Australian SMEs.

Cost and the MSP role

Vulnerability scanning is inexpensive — it’s a tool running on a schedule, and for most of our clients it’s bundled into a managed security plan rather than a separate line item. Penetration testing costs more because you’re paying for a skilled human’s time. A focused external test sits at the lower end; a comprehensive engagement covering external, internal, web app and social runs into five figures depending on scope. Beware quotes that look suspiciously cheap — that’s usually an automated scan dressed up and sold as a pen test, which is exactly the confusion this whole post is about.

TechAssist is a Melbourne-based MSP founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma. We run the ongoing scanning, patching and monitoring in-house as part of managed IT, and we coordinate penetration testing through vetted specialists when a deeper, independent test is warranted — then we’re the ones who actually fix what the report finds. That last part matters: a test you can’t act on is an expensive PDF.

Frequently asked questions

Is a vulnerability scan the same as a penetration test?

No, and treating them as the same is the most common and costly mistake. A scan is automated and lists known weaknesses across a broad surface. A pen test is a human deliberately exploiting weaknesses to prove what an attacker could reach. If someone offers a “pen test” for a few hundred dollars with same-day turnaround, you’re almost certainly buying a scan with a fancier label.

How often should we run each?

Scan continuously or at least monthly — it’s hygiene, and the more often you run it the faster you catch new exposures. Pen test at least annually, plus before any major launch, after significant infrastructure change, or when a contract, insurer or certification requires it.

Do we still need a pen test if we already scan regularly?

Yes, if you hold meaningful data or face compliance and client-review obligations. Scanning tells you which doors might be unlocked; a pen test tells you whether someone can actually walk through them and what they reach once inside. They answer different questions.

Will a penetration test disrupt our business?

A well-run test is scoped to avoid disruption — destructive techniques are agreed in advance, and aggressive testing can be scheduled out of hours. Reputable testers work from a signed scope and rules of engagement precisely so your systems stay up while the testing happens.

Getting it right for your business

Run scanning as the cheap, constant background discipline. Use penetration testing as the deliberate, deeper check at the moments that matter — compliance, launches, insurance, client reviews and an annual baseline. They’re complementary, and a business that does both well is in genuinely good shape rather than just feeling like it is.

If you’re not sure which you need, or you’ve been asked for a pen test report and don’t know where to start, get in touch. We’ll look at your environment, your obligations and what you’re actually being asked to prove, then recommend the right test — not the most expensive one.

Deepfake scams use AI-generated voice clones and video to impersonate a real person — usually your CEO, CFO or a supplier — and trick staff into approving a payment or handing over credentials. They are already hitting Australian businesses, and they work because they exploit trust in a familiar voice or face rather than a dodgy link.

What changed: the technology caught up

For years, the weak link in business fraud was the writing. A scam email asking the accounts team to urgently pay a new supplier account often gave itself away — odd phrasing, a misspelt name, a tone the real boss would never use. Staff learned to spot it.

That tell has gone. Modern voice-cloning tools need only a few seconds of clean audio to produce a convincing copy of someone’s voice, saying anything you type. A LinkedIn video, a conference talk on YouTube, a podcast appearance, a voicemail greeting, even a recorded webinar — that is more than enough source material. The output is good enough to fool a colleague who speaks to that person every day, especially over a phone line or a slightly glitchy Teams call where audio quality is already degraded.

Video deepfakes have followed. The widely reported 2024 case in Hong Kong, where a finance worker paid out roughly AUD $39 million after joining a video call with what he believed were several senior colleagues — every one of them a deepfake — is the example everyone cites because it proves the technique scales to live, multi-person video. You no longer need to be a nation-state to run it. The tools are commodity, cheap, and getting easier to use by the month.

How the attack actually plays out

This is not theoretical, and it is not science fiction. It is a refinement of business email compromise (BEC), the fraud that the Australian Cyber Security Centre (ACSC) and ReportCyber already rank among the most costly facing Australian businesses. We wrote about the email side of this in our guide to business email security and BEC. Voice and video are the new front end on the same con.

The pattern is consistent. The attacker has done their homework — they know the names of your finance staff, who reports to whom, and often that a director is travelling or otherwise hard to reach. Then they apply pressure through a channel that feels personal:

• A phone call or voicemail from “the managing director”, voice cloned, instructing accounts to release a payment before close of business because a deal is about to fall over.
• A Teams or WhatsApp voice note from “the CFO” that sounds exactly right, authorising a transfer to a new account and asking the recipient to keep it quiet until it is done.
• A short video call where the face and voice of a senior leader appear on screen, lending authority to an instruction that would normally need paperwork.
• A “supplier” calling to confirm that their bank details have changed, following up an email you were already half-expecting.

Every version leans on the same three levers: authority (it is the boss), urgency (it has to happen now) and secrecy (don’t loop anyone else in). Those three together should be a red flag regardless of how convincing the voice is. Genuine executives almost never combine all three.

Why this supercharges BEC

Classic BEC relied on a spoofed or compromised email account and the victim not picking up the phone to check. The standard advice — “if in doubt, call the person directly” — was the defence. Voice cloning attacks that defence head-on. Now the phone call itself can be the fraud. When the verification channel and the attack channel are the same, the old safety net is gone, and you need a new one.

A Melbourne scenario

Picture a construction firm in Box Hill, mid-afternoon on a Friday. The accounts manager gets a voicemail that sounds unmistakably like the director, who everyone knows is on site at a job in Geelong and notoriously hard to reach. He says a subcontractor needs to be paid today to keep a pour on schedule, the bank details are in a follow-up email, and he is heading into a meeting so just get it done — he will sign off properly Monday. The email arrives moments later from what looks like his address. The voice was right. The story was plausible. The pressure was real.

The only thing that saves that firm is a process that does not depend on recognising the voice — because the voice was perfect. A business we work with in the eastern suburbs had a near-miss almost exactly like this. What stopped it was a boring rule: any change to payment details, or any new payee over a set dollar threshold, gets verified by calling the requester back on the number already in the contact system, never a number supplied in the request. The accounts manager rang the director’s real mobile, got no urgent payment story at all, and the fraud collapsed.

Defences that actually work

You cannot reliably train staff to detect a good deepfake by ear or eye any more — that race is lost, and pretending otherwise sets people up to fail. The defences that hold up are about process and verification, not detection. Technology helps at the edges; controls do the heavy lifting.

Out-of-band verification and callback procedures

This is the single most effective control. Any instruction to move money, change bank details or release sensitive data must be confirmed through a different channel than the one it arrived on — and a channel the attacker does not control. If the request came by call or voice note, verify by a different route: call back on the known number stored in your system, message them on an established internal channel, or confirm in person. Never use contact details supplied in the request itself. The whole point is that a cloned voice cannot also intercept the verification.

Payment controls and dual approval

No single person should be able to release a significant payment or change a payee unilaterally. Dual authorisation — a second, independent person who approves transfers over a threshold — means one fooled employee is not enough to lose the money. Set sensible thresholds, enforce them in your accounting and banking platforms, and make exceptions impossible rather than merely discouraged. Most banks support transaction limits and multi-signatory approval; use them.

A code word for fund transfers

Agree a verbal pass-phrase, known only to the people who authorise payments, that must be stated to confirm any urgent or unusual transfer. A deepfake can clone a voice but it does not know the secret word that was never written down or spoken online. It is low-tech, it costs nothing, and it works precisely because the attacker has no way to obtain it from public footage.

Staff awareness, framed correctly

Train people on the pattern, not the polish. Staff should treat any combination of authority, urgency and secrecy as a trigger to verify, full stop — regardless of how genuine the voice or face seems. Make it explicitly safe, even expected, for a junior staff member to slow down and check an instruction that appears to come from the CEO. The culture has to make verification normal, not insubordinate.

Limit your public voice and video footprint

Cloning needs source audio and video. The more of your executives’ voices and faces sit publicly online, the easier the job. You will never eliminate this — and senior people often need a public profile — but it is worth being deliberate about what gets posted, and aware that anyone with a prominent media presence is a higher-value target who warrants tighter payment controls.

Email security underneath it all

Most of these attacks still pair the voice or video with a supporting email, so the email layer matters. Properly configured SPF, DKIM and DMARC to stop domain spoofing, anti-impersonation rules that flag display-name lookalikes, and conditional access to lock down accounts all reduce the surface. This is core to our cybersecurity services, and we cover the email-specific side in detail in the BEC guide. Strong authentication matters too — if attackers cannot get into the real mailbox, they cannot send the convincing follow-up from the genuine address.

What to do if you have been hit

Speed matters enormously with payment fraud, because the money moves fast and recovery odds fall by the hour. If you suspect a deepfake or voice-clone scam has succeeded, or nearly has:

1. Call your bank immediately. Ask them to attempt a recall or freeze on the transfer. The first hour or two is when funds are most likely to be recoverable.
2. Report to ReportCyber (cyber.gov.au) and, for the scam itself, to Scamwatch (run by the National Anti-Scam Centre). These reports feed the national picture and can assist tracing.
3. Lock down internally. Reset credentials on any account that may have been compromised, check mailbox rules for malicious forwarding, and review what else the attacker may have accessed.
4. Tell your people. Warn staff that an attack is in progress so a second or third attempt does not land. These campaigns often target several employees.
5. Check your obligations. If personal information was exposed, the Notifiable Data Breaches scheme under the Office of the Australian Information Commissioner (OAIC) may require notification. Get advice quickly.
6. Preserve evidence. Keep the voicemail, the call records, the emails and any video. Do not delete anything — it matters for the bank, the police and your insurer.

If you carry cyber insurance, notify your insurer early; social-engineering and fund-transfer fraud cover varies widely between policies and many have strict notification windows.

Frequently asked questions

How little audio is really needed to clone a voice?

A few seconds of clear speech is enough for current consumer tools to produce a usable clone, and a minute or two yields something genuinely convincing. Given that most business leaders have video, podcast or webinar audio publicly available, attackers rarely struggle for source material. Assume any voice with a public footprint can be cloned.

Can we just train staff to spot deepfakes?

No, and relying on that is dangerous. Good deepfakes already fool people who know the real person well, and the quality keeps improving. Train staff to follow verification processes regardless of how authentic something seems. The defence is procedural — callback verification, dual approval, a code word — not human lie-detection.

Is this just a problem for big companies?

No. Small and mid-sized businesses are arguably easier targets because they often lack formal payment controls and have flatter structures where one person can authorise a transfer. Attackers go where the friction is lowest. A 15-person firm with no dual-approval rule is a softer target than a large enterprise with locked-down finance controls.

Does multi-factor authentication stop these scams?

It helps but does not solve it. Strong authentication stops attackers logging into your real accounts to send convincing emails, which is valuable. But a voice-clone scam can work entirely outside your systems — a phone call to your accounts team referencing a legitimate-looking email. You still need the payment-verification controls on top of good authentication.

The short version

Deepfake and voice-clone fraud is BEC with a far more convincing front end, and it is landing on Australian businesses now. You cannot train your way to spotting a perfect clone, so the answer is process: out-of-band callback verification on a known number, dual approval over a threshold, a code word for transfers, and email security underneath. Those controls do not care how good the fake is. As a Melbourne-based MSP founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma, we set these controls up so a convincing voice on the phone is not enough to move your money. If you want a straight assessment of where your payment and email controls stand, get in touch.

AI data governance is how you stop staff pasting confidential, customer or regulated information into public AI tools where it can be retained and reused. The fix is not banning AI. It is steering people onto sanctioned, commercially protected tools and putting technical controls around the data itself.

Every Melbourne SME we work with has the same quiet problem: people are already using ChatGPT, Gemini and Copilot, whether or not anyone approved it. The data has already started moving. Governance is about catching up to that reality before it bites.

The actual risk: your data ends up in someone else’s model

When a staff member pastes a slab of text into a free, consumer AI tool, that text leaves your control. Depending on the product and the account tier, it may be stored on the provider’s servers, reviewed by humans for quality, and used to train future versions of the model. That is the part that catches people out — not a dramatic breach, just an employee trying to work faster.

The realistic scenarios are mundane and that is what makes them common:

• A bookkeeper pastes a payroll export into a free chatbot to “summarise the anomalies” — names, salaries and Tax File Numbers go with it.
• A lawyer drops a draft settlement deed in to “tighten the language” — privileged client material, now sitting on an external service.
• A sales rep uploads the full customer list to “write a follow-up campaign” — personal information of hundreds of people, handed to a third party with no agreement in place.
• A clinic manager pastes patient correspondence in to “make it sound friendlier” — health information, the most sensitive category there is.

None of these people are reckless. They are using a tool that is genuinely useful, on data they handle every day, without realising the back end works differently to Office or their line-of-business app. That is the gap governance closes.

Consumer AI vs commercial AI: the difference that matters

Not all AI tools treat your data the same way, and the difference is entirely about which account you are signed into. This is the single most important thing to get staff to understand.

Consumer tiers — a free ChatGPT account, a personal Gmail’s Gemini, a chatbot someone signed up for with their own email — generally reserve the right to retain prompts and use them to improve the model. The provider’s consumer terms, not a commercial contract, govern what happens to your data.

Enterprise and business tiers — the paid, commercially licensed versions tied to your organisation — come with explicit data-protection commitments. Prompts are not used to train the underlying models, data stays within a contractual boundary, and you get administrative controls. The same brand can sit on either side of that line depending on the plan.

The practical instruction for staff is short: if AI work involves anything that is not already public, it goes through the sanctioned, organisation-signed-in tool — never a personal or free account. Microsoft 365 Copilot in particular sits inside the same service boundary as your existing Microsoft 365 data, which is why it is the natural starting point for most Melbourne SMEs already on Business Premium. Our guide to what is included with Microsoft 365 support in Melbourne covers where Copilot fits.

The Australian regulatory angle

This is not just a tidiness issue. Feeding personal information into an uncontrolled AND offshore service can put you on the wrong side of the Privacy Act 1988.

Under the Australian Privacy Principles (APPs), you must take reasonable steps to protect personal information (APP 11) and you carry obligations when personal information crosses borders to an overseas recipient (APP 8). Most consumer AI services process data offshore, which means an employee pasting customer data into a free tool can quietly trigger a cross-border disclosure you never assessed or agreed to.

The privacy reforms passed in late 2024 sharpened the picture. They introduced a statutory tort for serious invasions of privacy, strengthened enforcement powers for the Office of the Australian Information Commissioner (OAIC), and signalled tighter expectations around automated decision-making and transparency. The direction of travel is clear: regulators expect organisations to know where personal information goes and to be able to show they controlled it.

Sensitive information — health, biometric, and similar categories — attracts a higher bar again. A health service that lets staff paste patient details into a consumer chatbot has a genuine problem, not a theoretical one. If you operate in that space, our note on healthcare IT support and OAIC obligations is worth a read. The point for everyone else: regulated and customer data needs governance before it goes anywhere near a model.

The technical controls that actually work

A policy document on its own changes nothing. The control that holds is the one that does not depend on every employee remembering a rule at the moment they are busy. Here is the stack we put in place, roughly in order.

An AU-aligned AI acceptable use policy

You still need the policy — it sets the expectation, names the sanctioned tools, and gives you something to point to. The key is that it must be specific to your tools and your obligations, not a generic template. We have written separately about building an acceptable use policy that staff actually follow; the short version is that it should name which tools are approved, what data must never go into any AI tool, and who to ask when unsure. Treat the policy as the starting line, not the finish.

Sanctioned tools, properly licensed

Give people a good, approved option and most of the problem evaporates. Staff reach for free tools because nothing better was offered. Roll out Microsoft 365 Copilot or Gemini for Workspace on the right licence, sign them in under the organisation account, and the data stays inside the commercial boundary by default. Sanctioning a tool is cheaper than cleaning up after an uncontrolled one.

Microsoft Purview sensitivity labels and DLP

This is where governance gets teeth. Sensitivity labels tag and can encrypt your most sensitive files, and Data Loss Prevention (DLP) inspects content and acts on it. A DLP policy can warn or block when someone tries to send a document full of Tax File Numbers or Medicare numbers to an external destination — including, increasingly, paste actions into a browser-based AI tool via endpoint DLP. Labelling and DLP are also what govern what Copilot itself is allowed to surface internally. We cover the full setup in our piece on Microsoft 365 data governance, but the headline is that labels plus DLP are the data-layer control that does not rely on goodwill.

Conditional access

Identity controls decide who can reach the sanctioned tools and from where. Conditional access policies let you require a managed, compliant device and an MFA-verified identity before someone touches the corporate AI tools, and let you block access from unmanaged personal devices where you have no visibility. This is the difference between “we hope people use the right account” and “the wrong account simply cannot reach our data”.

Staff training

Controls reduce the blast radius; training reduces how often the trigger gets pulled. People need to understand, in plain terms, why a free chatbot is different from the signed-in corporate one, and what counts as data they must not paste. A fifteen-minute briefing that shows the consumer-versus-commercial difference does more than a fifty-page policy nobody reads.

Govern before you adopt

The mistake we see most is enthusiasm-first: a business rolls AI out across the company, then thinks about data governance when something goes wrong. Reverse it. Decide what data is sensitive, label and protect it, set DLP rules, pick and license your sanctioned tools, lock access with conditional access, then turn AI loose. Governance first is not slower — it is the only version that does not generate a clean-up project six months later.

A Box Hill scenario

An accounting firm in Box Hill we work with came to us after a partner noticed staff using personal ChatGPT accounts to draft client letters — pasting in figures, names and TFNs as they went. Nobody had done anything malicious; the firm had simply never offered an approved tool or said where the line was. We rolled out Microsoft 365 Copilot under their existing Business Premium licences, applied Confidential sensitivity labels with encryption to their client folders, set DLP rules on TFNs and Medicare numbers, and used conditional access so the corporate tools only worked from managed devices. We paired it with a short staff session on the consumer-versus-commercial difference. The firm now has a faster, sanctioned tool and a defensible answer if the OAIC or their professional indemnity insurer ever asks how client data is controlled.

TechAssist has run Microsoft 365 for Melbourne SMEs since 2014, with thirteen Australian-employed engineers and a 24/7 NOC in Tecoma. The govern-then-adopt review has quietly become one of the more common pieces of work we do as AI tools spread through workplaces.

Frequently asked questions

Is it safe to use ChatGPT for work?

It depends entirely on the account. A free or personal ChatGPT account may retain your prompts and use them to improve the model, so it is not appropriate for confidential, customer or regulated data. ChatGPT Team or Enterprise, signed in under your organisation, does not use your prompts for training and is a reasonable sanctioned tool. The rule of thumb: anything not already public goes only through the approved, organisation-licensed tool.

Does Microsoft 365 Copilot use our data to train its models?

No. Microsoft 365 Copilot operates under commercial data-protection commitments. Your prompts, responses and organisational data are not used to train the underlying foundation models and stay within the Microsoft 365 service boundary. That is precisely why it is a safer default than a personal AI account for business data.

Can staff pasting data into AI tools breach the Privacy Act?

It can. Pasting personal information into a consumer AI service that processes data offshore can amount to a cross-border disclosure under APP 8 and a failure to take reasonable security steps under APP 11. Sensitive information such as health data raises the bar further. Sanctioned tools, sensitivity labels and DLP are how you keep that data inside controls you can demonstrate to the OAIC.

How do we stop people using free AI tools without banning AI entirely?

You give them a good sanctioned alternative and put controls around the data. License a commercial tool such as Microsoft 365 Copilot or Gemini for Workspace, apply Purview sensitivity labels and DLP, enforce conditional access so the corporate tools only work from managed devices, and back it with a short, specific acceptable use policy and training. Most uncontrolled use stops once a better, approved option exists.

Where to start

You do not need to solve everything at once. Decide which data is genuinely sensitive, license one sanctioned AI tool, switch on a couple of DLP rules in audit mode, and run a fifteen-minute staff briefing. That alone moves you from “people are doing whatever” to a defensible, governed position.

If you would like a hand scoping an AI data governance rollout — sanctioned tools, Purview labels and DLP, conditional access and a policy that fits your obligations — talk to our cyber security team, or get in touch with TechAssist. We will tell you plainly what to lock down first and what you can safely leave alone.

Shadow AI is the unapproved use of artificial intelligence tools by your staff — pasting company data into ChatGPT, running client calls through a free transcription app, installing a browser AI extension — without IT knowing or approving it. It is happening in your business right now, whether you have a policy or not.

The instinct is to ban it. That fails. This post covers what shadow AI actually looks like, the real risks, how to find what is already in use, and how to give staff a safe option instead of a locked door.

What shadow AI actually is

Shadow AI is the AI cousin of shadow IT — staff using software the business never sanctioned. The difference is that AI tools are free, browser-based, genuinely useful, and they ingest whatever you feed them. That makes adoption fast and the data exposure quiet. In a typical Melbourne SME it shows up as:

• Public chatbots — staff pasting contracts, client emails, financials or source code into the free tiers of ChatGPT, Google Gemini or Claude to summarise, rewrite or debug.
• Free transcription tools — meeting bots that join Teams or Zoom calls and quietly record and transcribe board meetings, HR discussions and client briefings to a third-party server.
• Browser AI extensions — Chrome and Edge add-ons that promise to “summarise this page” while reading everything on screen, including data inside your line-of-business apps.
• AI features bolted onto consumer apps — note-takers, design tools and PDF readers that have added an AI feature most users never think twice about.

None of this is malicious. It is a marketing manager hitting a deadline, an accounts clerk speeding up a reconciliation, a salesperson who wants their call notes written for them. The intent is fine. The data trail is the problem.

The real risks

The risks are concrete, and several carry legal weight in Australia.

Confidential and customer data leaving the business

When someone pastes a client list, a draft contract or a spreadsheet of personal details into a public AI tool, that data has left your control. On free and consumer tiers you generally have no contractual data-handling guarantees, no Australian data residency, and limited ability to demand deletion. Once it is out, it is out.

Your data becoming training data

Several consumer AI services reserve the right to use submitted content to improve their models unless you are on a paid plan that explicitly opts out. A confidential prompt today could influence an answer given to a stranger tomorrow. For a law firm, an accountant or anyone handling commercial-in-confidence material, that is a genuine professional problem.

Intellectual property and privacy breaches

Feeding proprietary code, product designs or unpublished strategy into an external tool can weaken your claim over that IP. More seriously, if the data includes personal information — names, contact details, health or financial records — you are likely engaging the Privacy Act 1988 and the Australian Privacy Principles, which require reasonable steps to protect personal information and to control offshore disclosures. A staff member uploading a customer database to a US-hosted chatbot can put you on the wrong side of those obligations, and a serious breach is reportable to the Office of the Australian Information Commissioner (OAIC) under the Notifiable Data Breaches scheme.

Inaccurate output, trusted blindly

The risk that gets least attention is the most common in practice. AI tools produce confident, fluent answers that are sometimes wrong — fabricated case citations, invented figures, misremembered policy. When staff paste that output straight into client advice, a board paper or a compliance document without checking it, the error is now yours. The tool does not sign off on the work; your business does.

Why banning it outright fails

The first reaction from a nervous business owner is “block all of it”. It does not work, for three reasons.

First, the tools are too accessible. You can block a domain on the corporate network, but staff will use their phone, home laptop or personal browser profile. You have not removed the risk; you have just lost sight of it.

Second, AI genuinely makes people faster and your competitors are using it. A blanket ban tells your best people the business is behind, and they will route around it.

Third, a ban with no sanctioned alternative guarantees the worst outcome: people still use AI, but only the unmonitored consumer versions, because you gave them nothing else. The goal is not zero AI. It is governed AI — the same logic that underpins sensible cyber security everywhere else.

How to discover what is already in use

You cannot govern what you cannot see, and most businesses have no idea how deep shadow AI already runs. Three practical ways to find out:

• SaaS and cloud app discovery (CASB) — a Cloud Access Security Broker, or the app-discovery capability in Microsoft Defender for Cloud Apps, inventories which cloud services staff sign into and ranks them by risk. The fastest way to see that thirty people are logging into AI tools you never approved.
• Network and DNS logs — your firewall and DNS resolver already record outbound connections. Filtering for known AI domains shows traffic volume and which devices generate it, even before you have a CASB in place.
• Conversations — the most underrated method. Ask teams, without blame, what AI tools they use and why. People are usually happy to tell you, because they do not see it as a security issue. That honesty tells you where to provide a safe option.

A construction firm in Box Hill we work with ran exactly this exercise. A discovery scan plus a few honest conversations turned up four AI transcription tools quietly joining site-coordination meetings, and two project managers pasting subcontractor agreements into a public chatbot to summarise variations. Nobody was acting in bad faith. They simply had no sanctioned tool and no rule telling them where the line sat.

Building a sane AI position

The fix is a short, clear acceptable-use position backed by a real alternative — not a 40-page policy nobody reads.

A short acceptable-use position

Write a one-page AI acceptable-use statement that answers the questions staff actually have: which tools are approved, what data must never go into a public tool (client personal information, financials, contracts, anything under NDA), and that AI output must be checked by a human before it is used in client work. A policy people understand is worth ten they ignore.

Provide a sanctioned, safe option

This is the part most businesses skip, and the part that makes the policy stick. Give staff an enterprise-grade AI tool with proper data protections — most commonly Microsoft 365 Copilot, which operates inside your tenant, respects existing permissions, and does not use your prompts to train public models. When people have a fast, sanctioned tool that works, the pull towards consumer apps drops sharply.

The catch is that Copilot surfaces anything the asking user can already reach, so loose permissions become a liability the moment you switch it on. That is why governance comes first, and why conditional access policies matter for controlling which devices and users can reach these tools at all. The data-governance groundwork sits alongside the rest of your Microsoft 365 setup.

The governance and DLP layer

A policy tells people what to do; technical controls back it up when they forget. This is the AI data governance layer, and for Microsoft 365 businesses it largely lives in Microsoft Purview.

Two Purview capabilities do most of the work:

• Sensitivity labels — tagging documents as Confidential or Highly Confidential, with encryption on the top tier, so the most sensitive data is marked and protected before any AI tool can touch it.
• Data Loss Prevention (DLP) — rules that detect sensitive content (Tax File Numbers, Medicare numbers, credit card numbers, client records) and warn or block when someone pastes or uploads it to an unsanctioned destination. Endpoint DLP extends that to the browser and clipboard, which is precisely where shadow AI lives.

Start DLP rules in audit-only mode for a fortnight, tune out the false positives, then move the high-risk ones to block. Turn everything to block on day one and you will have the finance team locked out of legitimate work by Tuesday.

Staff training closes the loop

Tools and policies fail without the why. A thirty-minute session showing real examples — what happens to a contract pasted into a free chatbot, why the transcription bot in the board meeting is a problem, how to use the sanctioned tool instead — changes behaviour far more than a signed policy ever will. The message is not “AI is dangerous, stop”. It is “AI is useful, here is how we use it safely”. Train people to treat AI output as a draft to verify, never a finished answer.

Frequently asked questions

Is using ChatGPT at work illegal in Australia?

Using it is not illegal. The risk is what you put into it. If staff feed personal information into a public AI tool, you may breach the Australian Privacy Principles, particularly the rules on protecting personal information and disclosing it overseas. A serious breach can trigger reporting obligations to the OAIC. The tool is fine; uncontrolled data going into it is the problem.

Does Microsoft 365 Copilot solve the shadow AI problem?

It removes most of the pull towards consumer tools by giving staff a fast, sanctioned alternative that keeps data inside your tenant. It does not replace governance. You still need sensitivity labels, sensible permissions and DLP, because Copilot surfaces whatever the user can already access. Provide the safe tool and govern the data underneath it.

What is the first thing we should do about shadow AI?

Find out what is actually in use. Run a SaaS discovery scan or check your DNS logs, and have a few honest conversations with staff. You cannot write a sensible policy or pick the right sanctioned tool until you know what problem people are solving and which tools they have reached for.

Where to start

Shadow AI is not a reason to panic, and certainly not a reason to ban a technology your staff find useful. It is a reason to look. Find out what is in use, write a one-page position people will follow, give them a safe enterprise tool, and back it with Purview labelling and DLP. That sequence — discover, sanction, govern, train — turns an invisible risk into a managed one.

TechAssist has run Microsoft 365 and security for Melbourne SMEs since 2014, with thirteen Australian-employed engineers and a 24/7 NOC in Tecoma. If you would like a hand finding what is in use and putting a sane AI position in place, get in touch with TechAssist. We will tell you plainly what is happening, what to allow, and what to lock down.