The True Cost of Downtime: What an Hour Offline Really Costs

The honest answer to “what does an hour offline cost us?” is: more than you think, and you can work it out in ten minutes. Take the staff who can’t work, multiply by their loaded hourly cost and the hours lost, then add the revenue you didn’t earn and the cost of putting things right. That number is usually a nasty surprise.

Most owners have never run that sum. They have a vague sense that downtime is bad, but no figure to weigh against the cost of preventing it. That gap is exactly why “we’ll fix it when it breaks” feels cheaper than it is. Here’s how to calculate the real cost of downtime for your business, what people leave out, and why a proactive approach almost always wins on the numbers.

The simple formula

You don’t need a consultant or a spreadsheet model to get a defensible figure. Four buckets cover most of it.

• Lost productivity = staff affected x loaded hourly cost x hours down. The people who are sitting idle, or working at half pace, while the system they need is unavailable.
• Lost revenue = sales, billable hours or transactions you couldn’t process during the outage and won’t recover later. Not every business has this; a retailer with the till down clearly does.
• Recovery costs = the after-hours engineering, overtime, expedited hardware, and the catch-up work once you’re back. This is the bit that keeps running after the lights come back on.
• Intangibles = reputation damage, missed deadlines, SLA penalties you owe your own clients, and the goodwill you spend apologising. Hard to price exactly, real all the same.

Add the four together and you have your cost per hour of downtime. The first bucket is the one everyone can calculate, so start there.

Getting “loaded hourly cost” right

A common mistake is to use the raw wage. The figure you want is the loaded cost — salary plus superannuation, payroll tax, leave loading, and overheads like the desk, the laptop and the software licence that person needs to do their job. As a rough rule, loaded cost runs about 1.25 to 1.4 times base salary. Someone on $90,000 isn’t costing you $43 an hour when they’re idle; they’re closer to $55 to $60 once you load it properly. Use the loaded figure or you’ll undercount every time.

A worked example

Let me put real numbers to it. This is a deliberately hypothetical scenario, not a real client and not a statistic — but the assumptions are the kind we see in Melbourne SMEs every week. You should swap in your own figures.

Picture a 30-person professional services firm in Camberwell. Their line-of-business application and shared files go down for half a day — four working hours — because a server failed and there was no quick failover. Assumptions:

• 25 of the 30 staff are completely blocked; the other five can do offline admin.
• Average loaded hourly cost across the affected staff: $60.
• The firm bills time, and roughly $8,000 of billable work for that morning simply can’t be done and largely can’t be clawed back.
• Recovery: an after-hours engineer, a replacement part couriered in, and overtime to catch up — call it $3,500.

That’s $17,500 for half a day, before you count the intangibles. Spread the same event across a few times a year and you’re well into five figures of avoidable loss. Run those four lines for your own business with your own headcount and rates — the exercise takes ten minutes and the result tends to change how people think about their IT budget.

The hidden costs people forget

The formula above captures the obvious losses. The ones that quietly inflate the real figure are easy to miss.

• The ramp-back-up tax. Productivity doesn’t snap back to 100% the moment systems return. People spend the next hour re-doing lost work, re-establishing context and clearing the backlog. Add 25 to 50 per cent to your productivity figure for this.
• Cascading effects. If your phone system, payment terminal or booking platform depends on the same internet link or server, one failure takes out several functions at once. The blast radius is usually wider than the thing that broke.
• SLA penalties you owe. If you have your own service-level commitments to clients, an outage can trigger credits or penalties. A logistics firm that misses a delivery window doesn’t just lose that job’s margin.
• Morale and overtime. Staff who lose half a day’s work then stay back to catch up don’t forget it. Chronic instability is a genuine factor in people leaving.
• Reputation. A retailer whose card terminal is down on a Saturday, or a clinic that can’t access patient records, loses trust as well as revenue. You can’t invoice for that, but you pay for it.

Why “fix it when it breaks” is a false economy

Break-fix — paying an hourly rate to fix things only once they fail — looks cheaper on a quiet month because you’re not paying for anything. The problem is what it does to both the frequency and the duration of downtime, which are the two levers that actually drive your cost.

Under break-fix, nobody is watching your systems. A failing disk, a backup that quietly stopped running three weeks ago, a firewall firmware bug — these get discovered when they cause an outage, not before. And when something does break, you’re at the back of the queue: the provider has to be called, has to understand an environment they don’t monitor, has to source parts cold. Your four-hour outage in the example above could easily have been an eight-hour one if the first two hours were spent just working out what failed.

The false economy is comparing the monthly fee of managed IT against zero, when the honest comparison is against the downtime you’ll eat without it. One avoided half-day outage a year often covers the difference.

How proactive managed IT cuts the bill

Good managed IT attacks downtime on two fronts: it makes outages less frequent, and it makes the ones that do happen shorter. Both reduce the hours in your formula.

Monitoring catches problems before they’re outages

Continuous monitoring means a failing drive, a service that’s stopped, or a backup job that didn’t complete raises an alert while it’s still a maintenance task, not an emergency. Most of the outages we prevent are ones the client never knew were coming. That’s the whole point — the cheapest downtime is the kind that never happens.

Redundancy removes single points of failure

A second internet service, a failover server, a clustered firewall — redundancy means one component failing doesn’t stop the business. It costs money, so you apply it where the downtime cost justifies it, which is exactly the calculation above. A business that knows an hour offline costs $4,000 can make a rational call on a $200/month redundant link.

Backups and a tested DR plan shorten recovery

When something does take systems down, the difference between a two-hour recovery and a two-day one is whether your backups work and whether you’ve ever actually tested restoring from them. An untested backup is a guess. We restore from backups on a schedule precisely so the day we need them isn’t the day we find out they were corrupt. A real backup and disaster recovery setup — with a documented, rehearsed DR plan — is what turns a catastrophe into an inconvenience. We go deeper on this in our guide to backup and disaster recovery for Melbourne businesses.

Tying downtime tolerance to RTO and RPO

Once you know what an hour costs, two numbers turn that into a design target. Your recovery time objective (RTO) is how long you can be down before the damage is unacceptable. Your recovery point objective (RPO) is how much data — measured in time — you can afford to lose. A business losing $4,000 an hour can’t tolerate a 24-hour RTO; the maths makes that obvious.

These aren’t abstract IT acronyms — they’re the bridge between your downtime cost and the money you should spend preventing it. Tight RTO and RPO targets cost more to deliver because they need redundancy and faster backups; loose ones are cheaper but expose you to bigger losses. The right answer falls out of the numbers you just calculated. Our explainer on RTO versus RPO walks through how to set them sensibly for each system.

TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers and no offshore helpdesk. We run per-user fixed monthly pricing with no hourly billing for in-scope work, and we target sub-15-minute response on critical issues from our 24/7 NOC in Tecoma — because on a P1, every minute is a line in the downtime sum above. If you’d like help working out what an hour offline genuinely costs your business and designing around it, get in touch and we’ll run the numbers with you.

Frequently asked questions

How do I calculate the cost of downtime for my business?

Add four buckets: lost productivity (staff affected x loaded hourly cost x hours down), lost revenue you can’t recover, recovery costs like after-hours engineering and overtime, and intangibles such as reputation and SLA penalties. Sum them for a cost per hour, then multiply by a realistic outage length. Use loaded staff cost — salary plus on-costs and overheads — not the raw wage.

What is loaded hourly cost?

It’s the true cost of an employee per hour, including superannuation, payroll tax, leave entitlements and overheads like their equipment and software, not just their base wage. It usually works out to roughly 1.25 to 1.4 times base salary. Using the loaded figure stops you undercounting your productivity losses.

Is managed IT actually cheaper than break-fix?

Over a realistic period, usually yes — because break-fix ignores the cost of downtime it fails to prevent. Managed IT reduces both how often outages happen and how long they last through monitoring, redundancy and tested backups. One avoided half-day outage a year commonly covers the difference in fees.

How do RTO and RPO relate to downtime cost?

Your downtime cost tells you how much an outage hurts; RTO and RPO turn that into design targets. RTO is how long you can be down, RPO is how much data you can lose. A high hourly cost demands tighter targets, which justify spending on redundancy and faster backups. The numbers should drive the design, not the other way round.

What are the hidden costs of downtime?

The ones people miss include the ramp-back-up time after systems return, cascading effects when one failure takes out several functions, penalties under your own client SLAs, staff morale and overtime, and reputation damage with customers. These often add as much again to the obvious productivity and revenue losses.

There’s no single right answer to cloud vs colocation vs on-premises — the right home depends on the workload. Cloud suits variable, web-facing and rapidly scaling systems. Colocation suits steady, hardware-heavy workloads you want to own. On-prem still earns its place where latency, data volume or predictable cost rule. Most Melbourne SMEs end up running a mix.

“Cloud-first” became the default advice somewhere around 2018, and a lot of businesses moved everything to Azure or AWS on that logic alone. Some of those migrations were right. Plenty quietly cost more than the server they replaced, ran slower for the people using them, and locked the business into a bill that never stops. The honest version of this decision is workload-by-workload, not a blanket policy. Here’s how the three models actually compare.

The three models, in plain terms

On-premises

On-premises means your server lives in your building — usually a comms room or a cupboard with a UPS, an air conditioner working harder than it should, and a network switch. You own the hardware outright, you control everything, and you’re responsible for everything: power, cooling, physical security, replacement when a disk dies at 2am. For a single-site business with a line-of-business application that doesn’t need to leave the premises, this is often perfectly sensible, despite what the cloud marketing says.

Colocation

Colocation (colo) is the middle path. You still own the server hardware, but instead of sitting in your office it lives in a professional data centre — in Melbourne that means facilities like NEXTDC’s M1 in Port Melbourne, M2 in Tullamarine, M3 in Brunswick, or Equinix’s ME1/ME2 in the CBD. You rent rack space, power and cooling; the data centre provides redundant power feeds, industrial cooling, fire suppression, carrier-neutral connectivity and 24/7 physical security with biometric access. You keep full control of the box and what runs on it. You just stop being responsible for the building it sits in.

Cloud

Cloud — Microsoft Azure, Amazon Web Services, and the rest — means you run on someone else’s hardware and pay for what you consume. No box to buy, no rack to rent, no disk to replace. You spin up a virtual server, a database or a storage account, and the bill scales with usage. The trade is that you give up ownership and physical control in exchange for someone else handling the infrastructure entirely. The point here isn’t which cloud provider to pick, but what cloud as a model gives and costs you against the other two.

The honest trade-offs

Every comparison you’ll read from a cloud vendor frames their model as the obvious winner. The reality is a set of genuine trade-offs where each model wins on some axes and loses on others.

Cost model: capex versus opex

On-prem and colo are mostly capital expenditure — you buy the hardware up front, depreciate it over three to five years, and the running cost after that is power, cooling and maintenance. Cloud is operating expenditure — a monthly bill that scales with use and never ends. Neither is automatically cheaper. For a steady, predictable workload running 24/7, owning the hardware is frequently cheaper over its life than renting equivalent compute in the cloud, because you’re not paying a margin on every CPU hour forever. For bursty or unpredictable workloads, cloud wins because you only pay for what you use. The mistake is assuming “opex good, capex bad” without modelling your actual usage.

Control and security

On-prem gives you total control and total responsibility — including the parts you’d rather someone else handled, like patching the hypervisor and physically securing the room. Colo keeps your control of the software but hands physical security to a data centre that does it far better than your comms-room door lock. Cloud abstracts the hardware away entirely: you control your configuration, the provider controls the infrastructure, and the security model becomes shared responsibility — they secure the platform, you secure what you put on it. That shared-responsibility line is where a lot of breaches happen, because businesses assume the cloud provider is securing things they’re actually responsible for themselves. Whichever model you choose, the controls still need to align with frameworks like the Essential Eight; see our cybersecurity services for how that applies across hosting models.

Latency and data gravity

This is the axis cloud-first advice ignores most often. If you have an application that shifts large volumes of data, or one where staff feel every millisecond of delay — CAD and rendering, video editing, large databases, manufacturing systems talking to floor equipment — running it in a distant cloud region can be noticeably slower than a server in the same building or a nearby data centre. Data has gravity: once you’ve got terabytes sitting somewhere, moving it is slow and, in the cloud, expensive (egress charges). Latency-sensitive and data-heavy workloads are exactly the ones that often belong on-prem or in colo, not cloud.

Reliability, power and cooling

This is where on-prem usually loses badly. Your comms room has one air conditioner and, if you’re lucky, a UPS that buys you fifteen minutes. A data centre has N+1 (or better) redundant power with generator backup, industrial cooling, and uptime guarantees backed by an SLA. Cloud providers run the same industrial-grade infrastructure across multiple availability zones. If continuous uptime matters and your building can’t deliver it, on-prem is the weakest of the three — which is the most common reason businesses move to colo or cloud in the first place.

Scalability

Cloud wins this outright. Need more compute for end-of-month processing? Scale up for a few days and back down. With on-prem or colo, scaling means buying and installing hardware — a lead time of weeks and a cost you can’t easily reverse. If your demand is genuinely variable, that elasticity is the single best reason to be in the cloud.

Data residency

For Australian businesses handling regulated data — patient records under the Privacy Act and OAIC expectations, or data with contractual residency clauses — where the server physically sits matters. On-prem and Melbourne colo keep data unambiguously onshore. Cloud can too: Azure and AWS both run Australian regions. But cloud residency is a configuration discipline, not a default — you must confirm backups, logs and replicas don’t quietly land offshore. With on-prem and colo, the answer is simply “in this building.”

Side-by-side comparison

Why “cloud-first” isn’t automatically right

Cloud is the right answer for a great many workloads — web applications, anything seasonal or spiky, software-as-a-service products, and businesses that genuinely value never touching hardware again. But three situations regularly make cloud the wrong default.

The first is latency-sensitive or data-heavy work. A workload that moves large files constantly, or one where staff notice every delay, can run worse in a distant region than on local hardware — and the egress charges for shifting that data make it expensive too. The second is predictable, steady cost. A line-of-business server running flat-out 24/7 with no real variation often costs more to rent forever than to own and depreciate; the cloud premium only pays off when elasticity is doing real work. The third is regulatory or contractual constraint that’s simpler to satisfy with hardware you physically control than with a cloud configuration you have to audit continuously.

None of this is anti-cloud. It’s anti-dogma. The question is never “is cloud good?” — it’s “is cloud right for this specific workload?”

The hybrid reality most SMEs land on

In practice, almost no Melbourne SME we work with runs purely one model. The sensible setup is hybrid, decided workload by workload: email, collaboration and identity in Microsoft 365 and Azure where the cloud genuinely shines; a latency-sensitive line-of-business application on a local or colocated server; backups copied to a second location so a single site failure doesn’t take you out. The goal isn’t ideological purity. It’s putting each workload where it runs best for the cost.

This is exactly the kind of architecture decision a virtual CIO should be making with you, rather than defaulting everything to one model because it’s easier to manage or sounds modern.

How to decide, workload by workload

Run each workload through a short set of questions and the right home usually becomes obvious:

• How variable is demand? Spiky or seasonal leans cloud; flat and steady leans owned hardware.
• How latency-sensitive is it? If users or equipment feel every millisecond, keep it close — on-prem or colo.
• How much data does it move? Heavy data gravity makes cloud egress costly and on-prem/colo cheaper.
• What does uptime actually need to be? If your building can’t deliver it, colo or cloud beats on-prem.
• Are there residency or compliance constraints? Onshore-only data is simplest in Melbourne colo or on-prem.
• What’s the real total cost over five years? Model it — don’t assume opex beats capex.

A Dandenong scenario

A manufacturer in Dandenong we work with had been told by a previous provider to “move everything to the cloud.” They did — including the ERP system that talks constantly to machinery on the factory floor and a large file store of engineering drawings. Within weeks, staff were complaining that file opens that used to be instant now lagged, and the monthly Azure bill, padded by data egress every time someone pulled a drawing, had crept well past the cost of the server it replaced.

We didn’t reverse the whole thing — email, Teams and identity belonged in the cloud and stayed there. But the ERP and the drawing store went back onto a server, this time colocated in a Melbourne data centre rather than the old comms room. Latency dropped back to instant, the egress charges disappeared, and the colo facility gave them the redundant power and uptime their factory had never had on-site. The lesson wasn’t “cloud bad.” It was that the workloads had been placed by slogan instead of by fitness.

Frequently asked questions

What’s the difference between colocation and cloud?

With colocation you own the physical server hardware and rent space, power and cooling in a data centre; you keep full control of the box. With cloud, you own no hardware at all — you rent virtual compute and storage from a provider like Azure or AWS and pay for consumption. Colo is “your hardware, their building”; cloud is “their hardware, their building.”

Is on-premises dead?

No. On-prem still makes sense for single-site businesses with latency-sensitive or data-heavy applications, predictable steady workloads where owning hardware is cheaper over its life, and situations where physical control of data simplifies compliance. Its main weakness is reliability — a comms room can’t match a data centre’s redundant power and cooling — which is the usual reason to move to colo or cloud.

Where are Melbourne’s data centres?

The major carrier-neutral facilities include NEXTDC’s M1 in Port Melbourne, M2 in Tullamarine and M3 in Brunswick, plus Equinix’s ME1 and ME2 in the CBD. These offer redundant power, industrial cooling, fire suppression and 24/7 secured physical access, and keep your data unambiguously onshore.

Is cloud always more expensive than owning a server?

No — it depends entirely on the workload. For variable or bursty demand, cloud’s pay-for-what-you-use model is usually cheaper. For a server running flat-out 24/7 with stable demand, owning and depreciating hardware is often cheaper over its life, because you avoid paying a margin on every compute hour indefinitely. Always model your actual usage rather than assuming.

Making the call

The honest answer to where your servers should live is “it depends on the workload” — and that’s not a cop-out, it’s the only correct answer. Cloud, colocation and on-prem each win on different axes, and a well-run SME uses all three where each fits. The failure mode is treating it as a single ideological choice instead of a series of small, costed decisions.

If you’d like a straight assessment of where each of your workloads should live — and the real five-year cost of each option rather than a vendor pitch — explore our cloud services or get in touch with our team. We run Australian-employed engineers out of Tecoma and the Melbourne CBD, and we’ll tell you honestly which workloads belong in the cloud and which don’t.

For most Australian SMEs in 2026 the honest answer to laptops vs desktops comes down to one question: does the person need to work in more than one place? If yes, buy a business-grade laptop and a dock. If they sit at the same desk every day and never move, a desktop gives you more performance per dollar and a longer life. The nuance is in the edge cases.

The old reasons to buy desktops — far cheaper, far faster, easier to fix — have softened. Laptops have closed the gap on performance, and hybrid work has made portability a default expectation rather than a perk. But desktops haven’t disappeared, and for some roles they’re still the right call. Below is a plain comparison and a role-by-role view, with the Windows 11 and Copilot+ angle that’s now part of every refresh conversation.

The quick comparison

Prices and configurations shift constantly, so treat that as a framework, not a quote. The hardware sticker is rarely the deciding number anyway — total cost of ownership over four years, including support, downtime and the value of flexibility, is what actually matters.

Mobility and hybrid work

This is the factor that’s reshaped the decision. A few years ago most Melbourne SMEs ran desktops in the office and that was that. Now hybrid is the default for professional services, and a person who can’t pick up their machine and work from home, a client site or the train is a productivity gap waiting to happen. For sales, field and management roles, a laptop isn’t a luxury — it’s the job.

The catch is that buying laptops “because everyone’s hybrid now” without thinking it through wastes money on people who never actually leave their desk. Be honest about who moves and who doesn’t. A reception or warehouse terminal that lives in one spot for five years doesn’t need a portable battery you’ll be replacing in year three.

Performance per dollar and the power users

For the same spend, a desktop still gives you more — more cores, faster GPU, more RAM, and the thermal headroom to sustain it under load. That matters enormously for a narrow band of roles: CAD and 3D work, engineering simulation, video editing, large data sets, anything that pegs a processor for hours. Cram that workload into a thin laptop and it throttles, runs hot and ages fast.

An engineering or architecture practice in Hawthorn running AutoCAD and Revit is a clear desktop case — or at minimum a mobile workstation, which is a different (and pricier) animal to a standard ultrabook. For the bulk of office work, though — Microsoft 365, browsers, video calls, line-of-business apps — a mid-range business laptop has more than enough grunt, and the performance gap is invisible day to day. Don’t pay for desktop horsepower a spreadsheet user will never touch.

Repairability, upgradeability and lifespan

Desktops win cleanly here, and it’s a real cost lever over time. A desktop is a serviceable box: when the storage fills up or the RAM gets tight, you open it and add more. A failed power supply is a cheap, quick swap. That’s why a well-specced desktop comfortably runs four to six years, and you can stretch it further with a single part.

Laptops are tighter. Better business models still let you upgrade RAM and SSD, but many consumer machines solder the RAM, and a cracked screen, worn battery or failed keyboard is a genuine repair bill — sometimes close to the cost of replacement. Plan on three to four years for laptops as a working assumption, and build that shorter cycle into your budgeting rather than being surprised by it.

Docking and dual monitors

The classic objection to laptops — “but my team needs two big screens” — stopped being valid years ago. A decent USB-C or Thunderbolt dock turns a laptop into a full desktop setup in one cable: dual monitors, keyboard, mouse, wired network and power. Staff get the desktop experience at their desk and full portability when they walk away.

Two practical notes. First, standardise on one or two dock models across the fleet — mismatched docks are a quiet, recurring source of support tickets. Second, check the laptop actually drives the displays you want at the resolution and refresh you want; not every USB-C port carries enough bandwidth for two 4K screens. Get that right at purchase and dual-monitor laptop setups are genuinely seamless.

Security: laptops get lost

This is the factor people underrate. A desktop bolted under a desk in your office is, physically, fairly safe. A laptop rides in cars, sits in cafes and gets left on trains. Every portable device is a data-loss event waiting to happen if it isn’t protected, and under the OAIC’s Notifiable Data Breaches scheme, a lost laptop holding client data can be a reportable breach.

The non-negotiable is full-disk encryption — BitLocker on Windows, managed centrally so recovery keys are escrowed and you can prove the device was encrypted if it goes missing. Pair that with a business-grade machine that has a TPM 2.0 chip (which Windows 11 requires anyway), conditional access so a stolen device can’t simply sign in, and remote wipe through Intune. We cover the access side in our guide to conditional access policies in Microsoft 365, and encryption is a baseline control under the Essential Eight. A lost encrypted laptop is an annoyance; a lost unencrypted one is a notifiable breach and a very bad week.

The Windows 11 baseline and Copilot+ PCs

Windows 10 reached end of support in October 2025, so every machine you buy now should be Windows 11 and meet its hardware floor: a supported 64-bit CPU, 4GB+ RAM (realistically 16GB for business use), UEFI with Secure Boot, and TPM 2.0. Any business-grade device from the last few years clears that bar; the trap is cheap consumer stock that quietly doesn’t.

The newer wrinkle is Copilot+ PCs — machines with a neural processing unit (NPU) rated at 40+ TOPS that run certain AI features locally rather than in the cloud. They’re genuinely more efficient and have excellent battery life, but for most SMEs in 2026 the on-device AI features are a nice-to-have, not a reason to pay a premium or rush a refresh. Buy one if it fits the budget and the role; don’t let the marketing drive the whole fleet decision. If you’re weighing the AI productivity case more broadly, our Microsoft 365 support team can give you a straight read on what’s worth paying for.

Business-grade vs consumer kit

This matters more than the laptop-versus-desktop question for most buyers. Consumer machines from a retail shelf look like a bargain until you account for what’s missing: shorter warranties, no next-business-day on-site option, no fleet manageability, weaker build quality, and bundled junkware. Business lines — think the commercial ranges from the major vendors — give you longer warranties, TPM and firmware-level security features, driver stability, and machines you can enrol and manage centrally.

For a managed fleet, manageability is the quiet killer feature. Business devices support zero-touch provisioning through Windows Autopilot, so a new starter’s machine ships, gets unboxed, connects to wifi and configures itself with the right apps and policies — no engineer building it by hand. Consumer kit fights that process every step. The slightly higher upfront cost pays for itself the first time you onboard someone without a site visit.

Buy, lease or Device-as-a-Service

Buying outright is simplest: you own the asset, depreciate it, and there’s no contract. The downside is a lumpy capital cost every refresh cycle and the temptation to run machines years past their use-by date to avoid spending again. That’s how you end up with a fleet of slow, out-of-warranty laptops dragging productivity down.

Leasing or Device-as-a-Service (DaaS) spreads the cost into a predictable monthly figure and usually bundles refresh, warranty and sometimes provisioning into one line. For a growing business that values predictable opex and an automatic refresh cycle, that’s attractive — it forces the hardware discipline that buyers often skip. The trade-off is you’ll pay a little more over the full term, and you don’t own anything at the end. There’s no universally right answer; it depends on your cash flow and how disciplined you are about refreshes on your own.

Standardise the fleet

Whatever you buy, buy few models, not many. A fleet of three standard configurations — say a standard laptop, a power-user laptop and a desktop workstation — is dramatically cheaper to support than fifteen one-off machines bought ad hoc over the years. Standardisation means one set of drivers to test, spare parts that interchange, predictable imaging, and a swap-out that takes minutes instead of a half-day rebuild.

A professional services firm in Camberwell we work with had exactly that problem: every staff member had picked their own machine over five years, so no two were alike and every fault was a fresh investigation. We moved them to two laptop SKUs and one desktop for their finance team, all enrolled through Autopilot and encrypted with BitLocker. Support time dropped, onboarding went from a day to an hour, and their refresh budgeting finally became predictable. The cost saving wasn’t in the hardware — it was in everything around it. That fleet-management discipline is core to how our managed IT services work.

Frequently asked questions

Are desktops still worth buying in 2026?

Yes, for the right roles. Fixed workstations that never move, finance teams on multiple large monitors, and power users running CAD, video or heavy compute all get more performance per dollar and a longer, cheaper-to-maintain life from a desktop. For mobile or hybrid roles, a laptop with a dock is the better call.

How long should a business laptop last?

Plan on three to four years. The battery, hinges and keyboard wear with use, and after four years repair costs and slowdowns usually outweigh keeping the machine. Desktops stretch to four to six years and can be extended with a cheap RAM or SSD upgrade. Build those cycles into your budget rather than running kit until it dies.

Do we really need business-grade machines instead of cheaper consumer ones?

For a managed business fleet, yes. Business lines give you longer warranties, next-business-day on-site options, TPM and firmware security, driver stability, and central manageability through tools like Intune and Autopilot. Consumer machines look cheaper upfront but cost more in support, downtime and shorter usable life.

What’s the most important security control for laptops?

Full-disk encryption — BitLocker, managed centrally so recovery keys are stored safely. A lost or stolen laptop with client data can be a notifiable breach under the OAIC scheme; if it’s encrypted and you can prove it, the exposure is far lower. Pair encryption with conditional access and remote wipe.

Should we lease or buy our hardware?

Buying suits businesses with the capital and the discipline to refresh on schedule. Leasing or Device-as-a-Service suits those who prefer predictable monthly opex and want refresh, warranty and provisioning bundled in. You pay slightly more over the term but avoid lumpy costs and the temptation to run machines too long.

Getting the decision right

The 2026 rule is simple: match the machine to the role, not to a blanket policy. Map who actually moves, who needs raw compute, and who sits in one place all day, then standardise on a small set of business-grade configurations and manage them properly — encrypted, enrolled and on a sensible refresh cycle. That’s where the real savings live, well beyond the sticker price.

TechAssist is a Melbourne-based MSP founded in 2014, with 13 Australian-employed engineers and same-business-day on-site support across the metro — which means we can hand-deliver, swap or fix a machine fast when hardware does fail. If you want a straight recommendation on what to buy for which roles, or a managed fleet that runs itself, get in touch or take a look at our pricing and SLA. No upsell to gear you don’t need.

An untested disaster recovery plan is a hope, not a plan. Until you’ve actually restored your systems and timed it, you don’t know if your backups work, how long recovery takes, or whether the data you assume is protected even exists. Disaster recovery testing is the only thing that turns a document into a capability.

Most businesses we meet discover this at the worst possible moment — mid-incident, watching a restore fail or a backup turn out to be empty. The plan looked fine on paper. Nobody had ever proven it. This post covers why backups quietly fail, the four kinds of DR testing, how to actually run a test, and how it all ties back to your recovery targets.

Why your backup is probably lying to you

A backup job that reports “completed successfully” every night feels reassuring. The green tick tells you the job ran. It does not tell you the data is complete, readable, or recoverable. Those are different questions, and the gap between them is where businesses get destroyed.

Here are the failure modes we see most often, and they’re rarely dramatic — they’re quiet:

• Incomplete coverage. The backup protects the file server everyone remembers, but not the SQL database behind the line-of-business app, the configuration on a critical appliance, or the new cloud VM someone spun up in March. Coverage drifts as the environment changes, and nobody re-checks it.
• Corrupt or unreadable backups. The job runs, the file lands, but the backup itself is corrupt — a bad block, a half-finished snapshot, an encryption key nobody can find. You only learn this when you try to restore.
• Microsoft 365 assumed safe but not backed up. This is the big one, and it deserves its own section below.
• No recent restore test. The most common failure of all. The backups exist. Nobody has actually pulled data back out of them in months — or ever. A backup you’ve never restored from is an untested assumption, not a safety net.

A manufacturing business in Dandenong we work with came to us after a ransomware scare at a competitor prompted a nervous board to ask a simple question: “If this happened to us, could we get back up?” Their previous provider had been running nightly backups for years. When we ran a test restore, two of the four critical systems wouldn’t come back — one backup set was corrupt, the other had silently stopped including the database six months earlier. Every nightly report had said “success”.

The Microsoft 365 and SaaS backup gap

This catches out more Melbourne SMEs than anything else, so it’s worth being blunt. Microsoft 365 does not back up your data in the way most people assume. Microsoft replicates your data across its own infrastructure for availability — so the service stays up if a data centre has a problem. That is not the same as a backup that protects you from your own mistakes.

Under Microsoft’s shared responsibility model, the data in Exchange Online, SharePoint, OneDrive and Teams is your responsibility to protect. If an employee deletes a mailbox folder, a departing staff member wipes a SharePoint site, or ransomware encrypts files synced through OneDrive, Microsoft’s retention windows are limited and unforgiving. A deleted user’s mailbox is gone after 30 days by default. Versioning and recycle bins help with small accidents, but they are not designed to recover from a deliberate or large-scale data loss.

The same logic applies to other SaaS platforms — Xero, your CRM, your practice management system. Many businesses run their entire operation on cloud apps and have never asked who is responsible for backing the data up. The honest answer is usually: nobody. A proper backup strategy treats Microsoft 365 and key SaaS data as first-class assets to be backed up independently, with their own restore tests. We cover the full backup picture in our guide to backup and disaster recovery for Melbourne businesses.

The four types of DR testing

“Testing your DR” isn’t a single activity. There’s a ladder of tests, from cheap and frequent to involved and occasional. A mature business uses all four for different purposes.

Restore verification

The foundation. You pick data from a backup and actually restore it, confirming it opens and is intact. Done monthly, this catches corrupt backups and coverage gaps long before a real incident. It’s low effort and there is no excuse for skipping it — yet it’s the test most businesses never run.

Tabletop exercise

A tabletop is a structured walkthrough, no live systems touched. You gather the people who’d respond to a disaster, present a realistic scenario — “ransomware has encrypted the file server and the backup NAS at 9am on a Monday” — and talk through exactly who does what, in what order, using what. Tabletops surface the human gaps: nobody knows where the recovery runbook lives, the only person with the backup credentials is on leave, no one’s sure who decides to declare a disaster. Cheap to run, brutally revealing.

Partial and full failover

Failover testing is the real thing — you actually recover systems. A partial failover brings one workload back, often into an isolated environment so it doesn’t disrupt production. A full failover recovers the entire environment and confirms the business could genuinely operate from the recovered state. Full failover is the most demanding test and the most honest one. It’s where you discover that recovery takes eleven hours, not the three you’d promised the board.

How to actually run a test

Testing fails when it’s vague. “We should test our backups sometime” never happens. Here’s the approach that works:

1. Schedule it. Put recurring dates in the calendar — monthly restore verification, a tabletop each half, an annual failover. If it isn’t booked, it won’t happen.
2. Pick a real recovery scenario. Don’t test the easy case. Choose something that would actually hurt: the primary file server lost, the finance database corrupted, the email tenant compromised. Test what you’re afraid of, not what’s convenient.
3. Time it against your targets. Start a clock. How long until the data is back and usable? Measure it against your Recovery Time Objective (RTO) and check the recovered data is recent enough to satisfy your Recovery Point Objective (RPO). A restore that works but takes three days when your RTO is four hours is a failed test.
4. Document the gaps. Write down everything that went wrong or slowly — missing credentials, an out-of-date runbook, a system nobody knew wasn’t covered. The output of a test is a list of fixes, not a pass mark.
5. Fix and re-test. Close the gaps, then test again to confirm. A test that finds problems you never fix is theatre.

The discipline here is the same one that separates a real plan from a hopeful one. If you can’t put a stopwatch on your recovery and read the number out loud to your directors, you don’t have a tested plan.

Tying results back to RTO and RPO

This is the point of the whole exercise. Your RTO is how long the business can tolerate being down before the damage is serious. Your RPO is how much data you can afford to lose, measured in time. These aren’t IT numbers — they’re business decisions about survival, and we walk through setting them in our piece on RTO versus RPO and how long your business can survive without IT.

A DR test exists to prove your recovery meets those targets. You set an RTO of four hours; the test reveals actual recovery takes nine. That’s not a failure of the test — it’s the test doing exactly its job, exposing a dangerous gap before a real incident does. Now you have a choice: invest in faster recovery, or honestly revise the target and tell the business what to expect. Either way you’re working from reality instead of a comforting assumption.

Untested, RTO and RPO are just numbers in a spreadsheet. Tested, they become commitments you can stand behind. That’s the difference between business continuity that exists on paper and business continuity that actually holds when the building floods or the ransomware note appears.

How managed backup with monthly restore verification works

The reason most businesses don’t test is honest: it’s tedious, easy to defer, and the day job always wins. That’s precisely why it belongs with a provider who does it as routine rather than something you’ll get to “next quarter”.

Under our managed backup and disaster recovery service, restore verification is scheduled, not optional. Each month we pull real data back from backups — including Microsoft 365 — and confirm it’s intact, not just that the job reported success. Coverage is reviewed as your environment changes, so the new server or cloud app doesn’t quietly fall outside protection. When something fails, we find out during a test on a quiet Tuesday, not during an incident at 9am on a Monday with the whole business watching.

TechAssist is a Melbourne-based MSP founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma. We run backup as an operated service — monitored, tested and tied to your RTO and RPO — alongside managed IT, because a backup nobody verifies is the most expensive false comfort in IT.

Frequently asked questions

How often should we test our disaster recovery?

Restore verification monthly, a tabletop exercise twice a year, and a failover test annually where the risk warrants it. The cheap, frequent tests catch the most failures, so don’t skip restore verification just because it feels routine — that routine is exactly what protects you.

Isn’t my Microsoft 365 data already backed up by Microsoft?

No. Microsoft keeps your data available across its infrastructure, but protecting it from deletion, ransomware and human error is your responsibility under their shared responsibility model. Default retention is limited and won’t save you from a large or deliberate data loss. Microsoft 365 needs its own independent backup with its own restore testing.

What’s the difference between a tabletop and a real failover test?

A tabletop is a discussion — you walk through a scenario to check your people, roles and decisions, without touching live systems. A failover test actually recovers systems and proves the technology works. You need both: the tabletop finds the human gaps, the failover finds the technical ones.

What does a failed DR test mean?

It means the test worked. Finding a corrupt backup, a missing system or a recovery that blows past your RTO during a controlled test is the entire point — far better there than during a real disaster. A test that surfaces problems has just saved you. The failure is never testing at all.

Stop hoping, start proving

A plan you’ve never tested is a guess about the worst day of your business year. The fix isn’t more documentation — it’s putting a stopwatch on a real restore and reading the number honestly. Verify your backups, close the Microsoft 365 gap, run the tabletop, and prove your recovery actually meets the targets you’ve set.

If you’re not certain your backups would come back — or you’ve never actually tried — get in touch. We’ll run a real restore test, time it against your RTO and RPO, and tell you plainly where you stand. Better to find out now than to find out mid-incident.

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 2008, 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.