Can You Meet the Essential Eight on Google Workspace?

Yes, mostly, and the honest answer is that six of the eight have almost nothing to do with which email platform you chose. The Essential Eight is a set of controls for endpoints and networks, not for productivity suites. Choosing Google over Microsoft changes how you satisfy two or three of the strategies and changes nothing at all about the rest.

Where it does bite is real, though, and it is not where most people expect. Read on before you answer that cyber insurance questionnaire.

The eight strategies, named exactly

The Australian Signals Directorate publishes the Essential Eight as part of its Strategies to Mitigate Cyber Security Incidents. The eight mitigation strategies are: patch applications, patch operating systems, multi-factor authentication, restrict administrative privileges, application control, restrict Microsoft Office macros, user application hardening and regular backups.

Four maturity levels are defined, Maturity Level Zero through to Maturity Level Three. Maturity Level Zero signifies weaknesses in an organisation’s cyber security posture. ASD’s guidance is that Maturity Level One may generally be suitable for small to medium enterprises, Maturity Level Two for large enterprises, and Maturity Level Three for critical infrastructure providers and organisations in high threat environments. The current version of the Essential Eight Maturity Model is the November 2023 release, with a supporting FAQ last updated in October 2024.

Two rules matter more than any individual control. First, organisations should achieve the same maturity level across all eight strategies before moving to a higher level. There is no partial credit for being excellent at backups and absent on application control. Second, ASD states that seeking to use risk acceptance without compensating controls, or risk transference such as buying cyber insurance, as justification for not implementing an entire mitigation strategy means the organisation “will be considered to have not protected themselves against a specific class of cyber threat” and will be assessed as Maturity Level Zero for that strategy and for their overall implementation. You cannot insure your way past a control.

If the model itself is new to you, start with what the Essential Eight actually asks for.

Why the model reads as Microsoft-shaped

It reads that way because it largely is. The maturity model names Internet Explorer 11, Microsoft Office macros, Microsoft’s recommended application blocklist, Microsoft’s vulnerable driver blocklist, Windows PowerShell 2.0, Constrained Language Mode, Credential Guard, Local Security Authority protection and memory integrity. ASD’s own definition of a workstation is “any device that uses a desktop operating system, such as Microsoft Windows or a Linux distribution”, and the FAQ’s answers on hardening, privileged access management and passwordless deployment all point at Microsoft documentation.

That is not bias so much as history. It also means a Google-centric business has to do more explaining, not necessarily more work.

One point in Google’s favour is worth quoting. ASD’s FAQ says that where an organisation cannot rapidly scan and patch its own online services, it “encourages all organisations to consider moving their online services to mature and trustworthy cloud service providers”, noting this can deliver significant security benefits such as rapid identification and patching of vulnerabilities. Running Gmail instead of an on-premises mail server is the outcome ASD is asking for.

Working through the eight

Patch applications

Google Workspace itself is patched by Google, and ASD’s definition of an online service explicitly includes cloud services. That part is genuinely easier than running your own.

What is not easier is the rest of the requirement. Maturity Level One asks for an automated method of asset discovery at least fortnightly, a vulnerability scanner with an up-to-date database, daily scanning for vulnerabilities in online services, and weekly scanning for office productivity suites, web browsers and their extensions, email clients, PDF software and security products. Critical or actively exploited vulnerabilities in online services get 48 hours. That whole category gets two weeks otherwise.

Note the phrase “web browsers and their extensions”. This is where Google-centric businesses fail assessments. Chrome updates itself, so people assume they are covered. Chrome extensions do not manage themselves, and in most Workspace tenancies staff install whatever they like. Force-install an approved extension list and block the rest through Chrome Enterprise policy, and keep an inventory of what is installed. Without that you have no asset discovery and no scanning across a category ASD names explicitly.

Verdict: achievable, but only if you manage the browser as a managed application rather than as something that came with the laptop.

Patch operating systems

Nothing about this control changes because you use Google. If your staff run Windows laptops, this is a Windows patching control. If they run Macs, it is a macOS patching control, and the same mapping problem on macOS applies. Maturity Level One requires unsupported operating systems to be replaced, patching within one month for workstations and non-internet-facing servers, and 48 hours for critical vulnerabilities in internet-facing servers and network devices.

ChromeOS devices are the interesting case. They update automatically, and update policy is enforceable from the admin console. The evidence problem is that an assessor wants to see the scanning and reporting, not a claim that the platform handles it. Chrome Enterprise reporting gives you version data. Use it.

Verdict: unaffected by Google. Judge yourself on your endpoint fleet, not your email.

Multi-factor authentication

This is where Google is strong and where most Workspace tenancies are still weak.

Maturity Level One requires multi-factor authentication for users of your organisation’s online services that handle sensitive data, for third-party online services holding your sensitive data, and, where available, for third-party services holding non-sensitive data. The November 2023 update removed a common shortcut: biometrics alone, security questions and “Trusted Signals” are not recognised as valid factors. ASD accepts two combinations: something users have together with something users know, or something users have that is itself activated by something users know or are, such as a PIN or a fingerprint releasing a credential held on a device.

Google Workspace supports all of this through 2-Step Verification, and Google’s own admin guidance names security keys as the most secure method and recommends them for super admins. Maturity Level Two raises the bar to phishing-resistant multi-factor authentication for online services and for users of systems, and ASD’s FAQ points at FIDO2 certification. Security keys and passkeys in Workspace meet that.

There is even an argument that a Google-first business has an easier path to Maturity Level Two here than a Windows shop, because on a ChromeOS device the workstation sign-in is the Google account sign-in, so a phishing-resistant factor covers both at once. On Windows the equivalent is Windows Hello for Business or smart cards, which is a separate project.

What fails audits: enforcement gaps. Optional 2-Step Verification is not multi-factor authentication. Neither is 2-Step Verification with SMS left enabled as a fallback for the executives who complained. See phishing-resistant multi-factor authentication for the practical rollout.

Verdict: the strongest of the eight on Google. Fully achievable to Maturity Level Two.

Restrict administrative privileges

Google’s admin role model maps well. Maturity Level One wants privileged access requests validated when first requested, dedicated privileged accounts used solely for privileged duties, separate privileged and unprivileged operating environments, and unprivileged accounts unable to sign in to privileged environments.

Google’s published administrator security best practices ask for exactly this pattern: more than one super admin, each managed by a separate individual, and each super admin holding two accounts, one for admin work and one for daily activity. That is the ASD requirement stated in Google’s own words.

The requirement that used to break on cloud platforms is the one preventing privileged accounts from accessing the internet, email and web services. The November 2023 update amended this specifically to support cloud management: accounts explicitly authorised to access online services are permitted, but must be explicitly identified and strictly limited to what is required. A Workspace super admin account is exactly that case. Identify it, document the authorisation, restrict it.

Two things to actually check. Delegated admin roles accumulate silently, so review them. And domain-wide delegation is a privileged access path most businesses have never audited: Google’s own documentation warns that with domain-wide delegation “the app has access to the data belonging to all of your users” and recommends a regular review of service accounts, deleting any no longer in use. An assessor who knows Google will ask about this. Most do not, which is not a reason to skip it.

Verdict: achievable, and the November 2023 wording change made it cleaner than it used to be.

Application control

This is the hardest of the eight for a Google-centric business, and anyone telling you otherwise has not read the requirements.

Maturity Level One requires application control implemented on workstations, applied to user profiles and temporary folders used by operating systems, web browsers and email clients, restricting the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set.

If your staff use Windows laptops with Google Workspace, nothing here is different: you need Windows Defender Application Control or AppLocker, and Google is irrelevant to the control.

If your fleet is ChromeOS, the position is genuinely ambiguous. ASD defines a workstation as any device using a desktop operating system, giving Windows and Linux as examples rather than an exhaustive list. ChromeOS arguably qualifies. It also has no application control mechanism in the sense the model describes, because it does not execute those file types in that way. What it has instead is verified boot, per-process sandboxing and policy-enforced allowlisting of apps and extensions.

That is a compensating controls argument, and ASD permits compensating controls. The FAQ is clear on the terms: system owners must demonstrate that compensating controls provide an equivalent level of protection, and if an assessor judges them unsuitable, the strategy is assessed at the next lowest maturity level it qualifies for, or Maturity Level Zero. Write the argument down before the assessment, not during it.

Verdict: the control most likely to hold you at Maturity Level Zero. Get the scope and the compensating control position agreed in writing early.

Restrict Microsoft Office macros

The strategy is named after a Microsoft product. If Microsoft Office is not deployed anywhere in your organisation, the Maturity Level One requirements (macros disabled for users without a demonstrated business requirement, macros in files from the internet blocked, macro antivirus scanning enabled, macro settings not changeable by users) have nothing to attach to.

Two warnings.

First, “we do not use Microsoft Office” is almost never true. Someone in finance has Excel. Someone received a .docm from a client. The requirement bites on any Windows device where Office is installed, whatever your email platform is. Check before you claim it.

Second, and more importantly, the risk the control exists to mitigate does not disappear. Google Apps Script is embedded executable code in Sheets, Docs and Forms, triggered by the document, capable of calling out to the internet and touching Drive and Gmail through the user’s own authorisation. It is the same class of threat. The Essential Eight does not mention it, so satisfying the control literally does not protect you from it. Restrict Apps Script through the admin console, control which third-party apps can access Workspace data via API controls, and document that you have done so. It will not earn you a tick, but it is the right answer, and a competent assessor or insurer will be more impressed by it than by the tick.

Verdict: likely out of scope, but get the scoping decision agreed with your assessor in writing rather than assuming it. And treat Apps Script as the equivalent risk it is.

User application hardening

Maturity Level One requires Internet Explorer 11 disabled or removed, web browsers not processing Java from the internet, web browsers not processing web advertisements from the internet, and browser security settings that users cannot change.

All four are achievable in Chrome through Chrome Enterprise policy, and the ad-blocking requirement is the one people forget. Note that ASD’s FAQ clarifies this requirement does not extend to JavaScript, only Java.

Where the mapping genuinely breaks is Maturity Level Two and above, which requires web browsers and office productivity suites to be “hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur”. ASD publishes hardening guidance for Microsoft 365 and Office. It does not publish an equivalent Google Workspace hardening guide. There is nothing to comply with, which sounds convenient and is actually a problem: you cannot evidence compliance with guidance that does not exist.

The workable position is to apply vendor guidance from Google, apply ASD’s browser hardening guidance to Chrome, document the absence, and be ready to explain it. See hardening the Workspace tenancy itself for the configuration.

Verdict: Maturity Level One is achievable. Maturity Level Two requires a documented argument rather than a checklist.

Regular backups

Google Workspace is not a backup, and this is the control where Google-centric businesses are most often quietly non-compliant.

Maturity Level One requires backups of data, applications and settings performed and retained in accordance with business criticality and business continuity requirements, synchronised to enable restoration to a common point in time, retained in a secure and resilient manner, with restoration tested as part of disaster recovery exercises. Unprivileged accounts must not be able to access other users’ backups, or to modify and delete backups.

Google Vault is retention and eDiscovery. It holds data against deletion and it supports legal hold. It does not restore a Drive folder structure to a point in time, and it will not help you after a ransomware event that encrypts files synced from an endpoint. The requirement to test restoration as part of a disaster recovery exercise is the one nobody does.

This needs a third-party Workspace backup product with independent retention and its own access control. Google is not backing up your Workspace data covers the options and the Australian data residency question.

Verdict: fully achievable, and the most common real gap.

What an assessor or insurer will actually say

Three things, in our experience.

They will ask for evidence, not assertions. ASD notes there is no requirement to have an Essential Eight implementation certified by an independent party, but that assessment may be required by a government directive or policy, by a regulatory authority, or under contractual arrangements. Cyber insurers increasingly require it contractually. Screenshots of admin console settings, exported policy configurations and dated restoration test results are what gets accepted.

They will run a questionnaire written for Microsoft environments. Answering “not applicable” three times looks like evasion even when it is correct. Answer with the compensating control and the reasoning, not with a blank.

And they will treat application control and backups as the two that decide the outcome. Everything else tends to be tidy-up.

If your fleet is genuinely mixed, which most Australian businesses of this size are, the assessment scope is the fleet and not the productivity suite. A mixed Windows, Mac and Google fleet is assessable, it just needs the mapping written down once, properly.

We do Essential Eight uplift and assessment work for businesses running Google, Microsoft, Apple or all three, and we will tell you where you actually sit before you sign anything. Call 1300 028 324 or book a review at https://techassist.au/contact/.

The Essential Eight is ASD’s set of eight prioritised mitigation strategies for protecting internet-connected IT networks, assessed across four maturity levels from Maturity Level Zero to Maturity Level Three. It was written with Windows environments in mind, and several of its requirements name Microsoft products directly. That does not exempt your Macs, and an assessor will not accept “it is a Mac” as an answer.

This post maps each of the eight onto macOS honestly, including the three places where the mapping is genuinely imperfect and you will need compensating controls to survive an assessment. If you need the framework itself first, start with what the Essential Eight actually requires.

Get the names right, because assessors do

ASD’s eight mitigation strategies are: patch applications, patch operating systems, multi-factor authentication, restrict administrative privileges, application control, restrict Microsoft Office macros, user application hardening, and regular backups.

Maturity is assessed per strategy across four levels: Maturity Level Zero, One, Two and Three. ASD’s guidance is that organisations “should plan their implementation to achieve the same maturity level across all eight mitigation strategies before moving onto higher maturity levels”. There is no requirement to have an implementation certified by an independent party, though a government directive, a regulator or a contract may require an independent assessment.

Two things people get wrong in tender responses. First, “Maturity Level Two” is a target across all eight, not a badge you earn on your best control. Second, ASD’s FAQ states that risk acceptance without compensating controls, or transferring risk by buying cyber insurance, results in an assessment of Maturity Level Zero for that strategy and for the overall Essential Eight implementation. You cannot insure your way out of application control.

Why the mapping is awkward on Apple hardware

Read ASD’s own scoping language and the problem is visible. The Essential Eight “has been designed to protect organisations’ internet-connected information technology networks”, and the Maturity Model FAQ defines a workstation as “any device that uses a desktop operating system, such as Microsoft Windows or a Linux distribution”. macOS is not named. The application control file type list in the same FAQ is entirely Windows: .exe, .dll, .ps1, .msi, .chm, .hta, .cpl.

This is not an argument that the Essential Eight does not apply to Macs. It is an argument that you must translate intent into macOS controls and document the translation. ASD explicitly allows this. The FAQ states that compensating controls are acceptable where “system owners will need to demonstrate that their compensating controls provide an equivalent level of protection to the specific Essential Eight requirements they are compensating for”. Write that demonstration down before the assessor asks for it.

The mapping, strategy by strategy

Patch applications: mostly a tooling problem

The requirements are platform neutral. You need automated asset discovery at least fortnightly, a vulnerability scanner with a current database, weekly scanning of office productivity suites, browsers and their extensions, email clients, PDF software and security products, patching of those within two weeks, and removal of unsupported software.

Nothing here is Windows specific. The failure is practical: most Australian SMB fleets have no vulnerability scanner pointed at their Macs at all, and no automated way to push a third-party application update. Intune in particular has no macOS equivalent of its Windows Enterprise App Catalog, which is the detail covered in what Intune can and cannot enforce on a Mac. Fixing this usually means either an Apple-first MDM with a patch feed or a scripted packaging pipeline.

Verdict: clean mapping, common failure.

Patch operating systems: clean, with one open question

macOS updates are enforceable through Apple’s declarative device management, which lets you nominate a target OS or build version and an enforced deadline. Maturity Level One requires workstation operating system patches within one month of release, which is comfortably achievable.

The open question is the last requirement: “Operating systems that are no longer supported by vendors are replaced.” Apple does not publish a formal end-of-support date for a macOS release the way Microsoft publishes a Windows lifecycle date. You will need to state your own supported-version policy, defend it, and evidence that no Mac in the fleet is outside it. Expect an assessor to probe this.

Verdict: clean mapping, one documentation gap.

Multi-factor authentication: the strongest macOS story

This strategy is mostly about identity, not endpoints, so the platform is largely irrelevant. Maturity Level One requires that MFA “uses either: something users have and something users know, or something users have that is unlocked by something users know or are”.

macOS has a good answer. Platform SSO with the Secure Enclave authentication method binds a credential to the hardware and is described by Microsoft as passwordless and phishing resistant, conceptually similar to Windows Hello for Business. ASD’s FAQ explicitly accepts Windows Hello for Business as satisfying the MFA requirement. ASD has not published an equivalent answer for Platform SSO, so if you are being formally assessed, raise it with the assessor rather than assuming. Our reading is that it satisfies the construction, but that is our reading and not an ASD ruling.

Broader guidance on rollout sits in our multi-factor authentication for business guide.

Verdict: strong mapping, one unresolved question worth raising early.

Restrict administrative privileges: partly identity, partly a Mac habit

Maturity Level One requires separate dedicated privileged accounts, privileged accounts blocked from internet, email and web services, separate privileged and unprivileged operating environments, and unprivileged accounts unable to log on to privileged environments. Maturity Level Three adds Secure Admin Workstations.

Most of that lives in Microsoft Entra ID or Google Workspace and is platform neutral. The macOS-specific problem is cultural: on Macs, the day-to-day user account is very often a local administrator, because that is how the machine was set up out of the box and because some applications ask for it. Fixing that means standard user accounts by default, a managed local administrator account with a rotating password, and a controlled elevation mechanism for the handful of tasks that genuinely need it.

Verdict: clean mapping, uncomfortable remediation.

Application control: this is the real gap

ASD requires that application control “restricts the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set”, applied to user profiles and temporary folders at Maturity Level One and to all locations by Maturity Level Two, with rulesets validated at least annually.

macOS does not ship an allowlisting engine. What it ships is Gatekeeper, notarisation and XProtect. Apple’s own security documentation describes this stack accurately: Gatekeeper verifies that software “is from an identified developer, is notarised by Apple to be free of known malicious content and hasn’t been altered”, and XProtect is “built-in antivirus technology” using YARA signatures for “signature-based detection and removal of malware”.

That is a strong reputation and integrity model. It is not an organisation-approved allowlist. Apple decides what is trusted, not you. A determined user can also override Gatekeeper unless restricted by a device management service.

Your realistic options are: restrict installation to the App Store only through managed Gatekeeper policy, which is genuinely an allowlist but usually kills business applications; deploy a third-party application control product built on Apple’s Endpoint Security API; or document a compensating control set and argue it. The third option is what most Australian SMBs will do, and it must be written up properly, because ASD’s compensating-control test is equivalence of protection, not good intentions.

One useful detail for the write-up: from macOS 15 onwards, third-party security software can receive Endpoint Security API events when a user bypasses Gatekeeper, which gives you the central logging of untrusted execution that an assessor will want to see.

Verdict: genuinely imperfect. Expect to argue compensating controls.

Restrict Microsoft Office macros: half maps, half does not

Macros are not a Windows-only problem. Microsoft Office for Mac runs VBA, and Microsoft publishes managed preference keys for it. Setting the com.microsoft.office key VisualBasicMacroExecutionState to DisabledWithoutWarnings via a configuration profile disables macros and, per Microsoft, disables the user interface for changing it. Related keys let you force VBAObjectModelIsTrusted and AllowVisualBasicToBindToSystem to false and DisableVisualBasicExternalDylibs to true.

That covers Maturity Level One’s core intent: macros disabled for users without a demonstrated business requirement, and macro security settings that users cannot change.

What does not map: “Microsoft Office macros in files originating from the internet are blocked” relies on Mark of the Web, a Windows construct. “Microsoft Office macros are blocked from making Win32 API calls” is meaningless on macOS. At Maturity Level Three, Trusted Locations, the Message Bar, Backstage View and V3 signatures are all Windows concepts.

The honest position is that a Mac with macros hard-disabled by policy is more restricted than a Windows machine at Maturity Level One, and you should say so in exactly those terms.

Verdict: partial mapping. Argue over-compliance, not equivalence.

User application hardening: the most Windows-specific of the eight

Maturity Level One is easy on a Mac and slightly absurd. “Internet Explorer 11 is disabled or removed” is satisfied by the operating system not having it. The browser requirements (no Java from the internet, no web advertisements from the internet, browser security settings that users cannot change) are achievable through managed browser preferences delivered by configuration profile.

Maturity Level Two and Three are where it falls apart. Blocking Microsoft Office from creating child processes, blocking executable content, blocking code injection and preventing OLE package activation are Windows attack surface reduction rules. .NET Framework 3.5, Windows PowerShell 2.0 and PowerShell Constrained Language Mode do not exist on macOS.

Two requirements do translate and matter: “PowerShell module logging, script block logging and transcription events are centrally logged” and “Command line process creation events are centrally logged”. On macOS the equivalent is shipping shell and process execution telemetry from the unified log or from your EDR into a central log store, protected from modification and deletion. If you can show that, you have a defensible compensating control. If your Macs log nowhere, you do not.

Verdict: imperfect above Maturity Level One. Central logging is the control that saves you.

Regular backups: platform neutral, commonly failed

The requirements are about retention aligned to business criticality, synchronisation to a common point in time, secure and resilient retention, tested restoration as part of disaster recovery exercises, and unprivileged accounts being unable to access, modify or delete backups.

Nothing Apple specific. The Mac-specific failure is Time Machine to a local external drive, which fails the last two requirements outright: the user can delete it, and it is not resilient. The other common failure in a Mac-heavy business is assuming iCloud or a sync service is a backup. It is not, and neither is the Microsoft 365 or Google Workspace tenancy that your Mac users store everything in. That belongs in a backup regime that survives an incident.

Verdict: clean mapping, frequently failed in practice.

What an assessor will actually ask you

• Show me the device inventory, including every Mac, and how it is generated automatically.
• Show me the last vulnerability scan that included macOS endpoints.
• Show me the policy that sets the macOS update deadline, and the report proving devices met it.
• Show me your documented compensating controls for application control on macOS, and your evidence that they provide equivalent protection.
• Show me a Mac with a standard user account and no local administrator rights.
• Show me the central log store receiving process execution events from a Mac.
• Show me a restore test from the last twelve months that included data created on a Mac.

None of those require an Apple-specific product. All of them require the Macs to be genuinely managed rather than merely enrolled, which is why get the Macs properly enrolled and managed first is the correct order of operations, and why choosing between Jamf and Intune is a decision to make before the uplift work rather than during it.

One thing to watch

In June 2026 ASD opened consultation on evolving the Essential Eight into a broader Essentials series, with a first chapter covering enterprise IT. Nothing has changed for you yet. The Essential Eight, the Maturity Model and the assessment process guide are all still published and still the reference for contracts, insurance questionnaires and government supply chain requirements. Keep scoring against the current model, and fund controls rather than a framework name.

If you have a cyber insurance questionnaire, a client security review or a tender asking for an Essential Eight maturity level and your Macs are the part you cannot answer, call 1300 028 324 or use https://techassist.au/contact/. We will do an honest gap assessment against the current Maturity Model, including the compensating controls you will need to document for application control.

If your IT provider walked away tomorrow, could a competent replacement pick up your environment and run it without guessing? For most Australian businesses of 10 to 200 staff the honest answer is no. An IT documentation set is the written record of every system, device, account, licence, supplier relationship and recovery procedure your business depends on, kept accurate enough that someone who has never seen your environment can take it over without reverse engineering it.

Undocumented IT is a business risk, not an IT inconvenience

The bill for missing documentation never arrives on a quiet Tuesday. It arrives at five specific moments, and all five are already bad days.

An outage, where the question is not “can we fix it” but “what exactly is running on that box, and who do we ring at the vendor”. A staff departure, where the one person who knew how the ERP integration was configured has just served notice. A provider change, where the incoming team spends its early months discovering your environment instead of improving it, and bills you for the privilege. An insurance renewal or client security questionnaire, where you are asked to list systems holding personal information and you cannot. And a due diligence process during a sale, where an inability to produce an asset register and access records turns into a price adjustment.

The regulatory side is blunter than most owners expect. Australian Privacy Principle 11 requires an APP entity to take reasonable steps to protect the personal information it holds from misuse, interference and loss, and from unauthorised access, modification or disclosure, and to destroy or de-identify it in certain circumstances (OAIC, Australian Privacy Principles quick reference). Reasonable steps is an evidentiary standard. You demonstrate it with records, not with recollection.

The Notifiable Data Breaches scheme sharpens it further. Where you have grounds to suspect an eligible data breach, section 26WH(2) of the Privacy Act 1988 requires a reasonable and expeditious assessment, and you must take all reasonable steps to complete that assessment within 30 calendar days of becoming aware of the grounds. The OAIC’s stated expectation is that 30 days is treated as a maximum, not a target. Assessment means scoping: which systems were touched, whose data sat in them, what left the building. You cannot scope an environment nobody has mapped, and the clock does not pause while you work out what you own.

Worth naming the trade-off honestly: if your business turns over $3 million or less a year, the small business operator exemption may mean the Privacy Act does not apply to you at all. The exceptions are broad, though, and they catch a lot of Melbourne SMBs: health service providers holding health information, businesses trading in personal information, contracted service providers under a Commonwealth contract, and reporting entities under anti-money laundering legislation (OAIC, Small business). Check which side of that line you sit on before deciding it does not concern you. Your clients’ security questionnaires will not care either way.

What a complete set contains

Nine things. If your provider has given you fewer, you have a partial set.

1. Asset register. Every device, physical and virtual: make, model, serial, purchase date, warranty expiry, assigned user, location, operating system and current patch state. This is also where the security frameworks start. The ASD Essential Eight maturity model requires an automated method of asset discovery at least fortnightly under Patch applications, specifically to support subsequent vulnerability scanning. You cannot patch what you have not discovered, and you cannot report on what you have not recorded. If you are still tracking this in a spreadsheet, read our piece on asset management for a growing business before you buy anything else.

2. Network diagram and IP addressing. The ASD Information Security Manual’s Guidelines for networking call for network documentation to be developed, implemented and maintained, including high-level diagrams showing all connections into the network and logical diagrams covering critical servers, network devices and network security appliances, along with their settings. In practice that means a current diagram, an IP address plan, VLAN allocations, firewall rules with a stated purpose for each, VPN configuration and internet service details with account numbers. Add rack elevations and patch schedules for the physical layer, which is where comms room design and documentation meet.

3. Identity and access records. Every user account, service account, shared mailbox and group, with what each one can reach and who approved it. Service accounts are the ones that get missed, and they are the ones that outlive their creators.

4. Licence and subscription register. What you hold, per tenant and per user, with renewal dates, term commitments and the billing owner. This is the single most common source of a nasty surprise at renewal, and the second most common source of an audit exposure.

5. Supplier and account ownership. Every vendor, the account number, the support contract level, the escalation path, the phone number that actually reaches a human, and critically the name of the person at your business who owns the relationship. Domain registrar and DNS belong here, and they are usually the worst documented item in the whole environment.

6. Backup and recovery runbooks. Not “we back up to the cloud”. What is backed up, to where, how often, how long it is retained, when it was last restore-tested, and the step by step procedure to bring each system back. A backup you have never restored is a hypothesis.

7. Standard build and configuration baselines. The known-good state for a workstation, a server, a firewall and a mobile device. Baselines are what let you say “this machine is compliant” without opening it. The ISM’s Guidelines for system management also expect software registers covering workstations, servers and network devices, maintained with versions and patch history and verified regularly.

8. Change history. What changed, when, why, who approved it and how to reverse it. Without this, every incident investigation starts from zero.

9. The credential store. Which is its own conversation.

Credentials do not belong in the documentation system

This is where a lot of otherwise decent documentation goes wrong. Passwords, API keys, certificates, recovery codes and PINs should live in a dedicated secret store, not in a wiki page, not in a spreadsheet called Passwords_FINAL.xlsx, and not in a shared mailbox.

The separation matters for a practical reason. Documentation needs to be widely readable inside your business so it is actually used. Secrets need to be narrowly readable, individually attributable and revocable in seconds. Those two requirements pull in opposite directions, so you satisfy them with two systems and a link between them: the documentation record names the credential, the secret store holds it, and access to the store is granted by role rather than by person.

A business-grade password manager gives you role-based vaults, per-user identity, multi-factor authentication on the vault itself, an audit log of who viewed which secret and when, and the ability to revoke one person’s access without a mass reset. A spreadsheet gives you none of that, and it also gives you no way to answer the only question that matters after a departure: what did they have access to. Our guide to business password management covers the selection criteria in detail.

Two rules that are worth stating plainly. Break-glass credentials for your global admin and firewall accounts should be printed, sealed and stored physically, with a documented procedure for opening the envelope, because a secret store you cannot log into is not much use during an identity outage. And every credential in the store should have a named owner and a rotation trigger tied to your onboarding and offboarding checklist, not to a calendar reminder nobody honours.

The sharp question: if you leave, do you get it?

Here is the part your current provider would rather you did not read.

If you gave notice tomorrow, what would you receive? Not “would they help”, but specifically: which documents, in what format, within how many days, and is any of that written into your agreement? Most SMB managed services contracts are silent on it. Silence favours the incumbent.

The pattern we see repeatedly with new clients is a partial handover: a PDF export missing the credential store, an asset list months out of date, no network diagram at all, and a domain registrar account still sitting under the outgoing provider’s login. That last one is not a documentation failure, it is a control failure, and it is remarkably effective at making a client stay. Anyone who has taken over an undocumented cloud tenancy knows the shape of this: our post on inheriting a tenancy nobody documented walks through the recovery work involved.

Four things to check in your agreement this week.

Ownership. Does it state that documentation, asset records and configuration data relating to your environment are your property, not work product owned by the provider? If it is not stated, assume it is contested.

Format and portability. A handover in a proprietary format you cannot open is not a handover. Ask for machine-readable exports: CSV or JSON for registers, PDF or image for diagrams, and a documented export path from the secret store.

Registrant and tenant control. Your domain registrar, DNS zone, Microsoft 365 or Google Workspace tenancy and your certificate authority accounts should be registered to your business, with a director or nominated staff member holding a global administrator account. Your provider should have delegated access, not sole possession.

Exit and handover. Termination is usually the thinnest clause in an SMB managed services agreement, and it is the one that decides how your last month goes. Look for four specifics by name: a transition assistance clause that lists the deliverables, a timeframe expressed in business days from notice, a stated format for each deliverable, and whether that transition work is included in your fee or billed hourly. Check as well that the intellectual property clause does not quietly claim configuration data and documentation as the provider’s work product, and that there is an obligation to return or destroy your data rather than simply stop using it. If any of those are missing, that is the amendment to raise at renewal, because it is a far easier conversation to have while you are happy than while you are leaving.

Documentation rots, so tie it to change rather than to a review

An annual documentation review is a promise everyone makes and nobody keeps. The moment it slips once, the set is stale, and a stale set is arguably worse than none because people trust it.

The fix is structural. Documentation updates become an exit condition of the change, not a task that follows it. A change is not closed until the record is updated. That means:

• New device deployed? Asset register updated as part of provisioning, ideally automatically from the management platform rather than by hand.
• Staff member starts or leaves? Identity records and credential access updated as part of the onboarding or offboarding run, same day.
• Firewall rule added? Diagram and rule register updated before the change ticket closes.
• Licence purchased or cancelled? Subscription register updated at the point of purchase, by whoever raised the order.
• System restored from backup? Runbook updated with what actually happened, because that is when you discover the runbook was wrong.

Automate the parts that can be automated. Device inventory, software versions, patch state and licence assignment can all be pulled from your management and identity platforms on a schedule, which removes the largest and most tedious category of manual updates. The parts that cannot be automated, meaning the diagrams, the runbooks and the supplier relationships, are the parts a human has to own, and they should be reviewed on a fixed cadence with a named person accountable for each.

The trade-off is real: tying updates to change makes every change slightly slower. That is the cost, and it is worth paying. A change process that produces accurate documentation as a by-product is the only one that stays accurate.

Audit your provider this week

Send one email. Ask for these six items, and give a deadline.

1. A current asset register export, in CSV, with serial numbers and warranty dates.
2. The network diagram, dated within the last six months, plus the IP addressing plan.
3. A licence and subscription register with renewal dates and the billing owner.
4. Confirmation of who holds the registrant details for your domain and who holds global administrator on your cloud tenancy.
5. The date of the last successful restore test, and which system was tested.
6. The clause in your agreement that covers documentation handover on termination.

What comes back tells you most of what you need to know. Items arriving within a couple of days means the documentation exists and is maintained. A request for time to compile means it is being assembled for the first time. Silence, or a phone call asking why you are asking, means the answer is no. If you want a broader sweep of your environment while you are at it, our annual IT audit checklist covers the other governance items worth reviewing in the same pass.

If those six requests come back thin, we will do the documentation build for you and hand it over in a format you own, whether or not you move your managed services across. Call TechAssist on 1300 028 324 or get in touch at https://techassist.au/contact/ and we will scope it against your actual environment.

Network segmentation gets explained as a zero-trust enterprise project with microsegmentation and identity-aware proxies. That framing scares SMEs off, which is a shame. A 30-person Melbourne business can segment its network usefully in a weekend with a UniFi stack and four VLANs. The hard part is sequencing the work so each step reduces real risk.

This guide is the practical version. We will walk through the minimum-viable segmentation that actually reduces lateral movement risk for an Australian SME, the priority order (guest Wi-Fi first, because it is the cheapest win and stops half the dumb risks), where SMEs over-engineer and waste budget, a sample VLAN and firewall rule pack you can adapt, and the trap of segmenting your network without doing the identity work alongside it.

TechAssist has been deploying these stacks for Melbourne SMEs since we were founded in 2014. Our cybersecurity services Melbourne team treats segmentation as one of the highest-leverage controls available to a small business. It is not the most exciting work, but it is the work that means a phished receptionist credential does not become a domain-wide ransomware incident.

What Network Segmentation Actually Is

Segmentation is the practice of dividing your network into separate zones so that a device or user in one zone cannot freely communicate with devices in another zone. Each zone is governed by firewall rules that say what traffic is permitted between it and other zones.

The simplest example: your guest Wi-Fi should not be able to talk to your office laptops. Your office laptops should not be able to talk to your CCTV cameras. Your CCTV cameras should not be able to talk to your phone system. Your phone system should not be able to talk to anything except the SIP provider. If you implement those four rules, you have already done most of the segmentation work that meaningfully reduces risk.

The reason segmentation matters is lateral movement. Modern ransomware does not just encrypt the machine it lands on. It enumerates the local network, finds open shares, weak credentials, and unpatched services on other devices, and spreads. A flat network gives the attacker the entire estate. A segmented network gives them one VLAN.

This is not zero trust, despite what some vendors will tell you. It is the perimeter approach with internal perimeters added. Zero trust is the next step beyond segmentation, where every connection is authenticated and authorised regardless of zone. Read our zero trust security model explained guide for that broader picture. For most SMEs, getting segmentation right is the prerequisite, and the right place to stop for now.

The Minimum Four VLANs for a Melbourne SME

If you run a 15-to-100-person business and you want a segmentation design that actually reduces risk without becoming a multi-month project, run four VLANs. We deploy this exact pattern several times a quarter across our client base.

Four VLANs sound trivial. The reason it is enough for most SMEs is that each one represents a meaningfully different risk profile. Guest devices are unmanaged and untrusted. IoT devices are notoriously badly patched and run weird firmware. Voice devices have their own QoS needs and should not be exposed to general office traffic. Corporate is the only zone where managed, patched, and authenticated devices live.

If you have a meaningfully different workload, like a manufacturing floor with PLCs, an OT environment, or a clinical environment with medical devices, add a fifth VLAN for that. Do not collapse it into the IoT VLAN. The blast radius if it gets compromised is too different.

Priority Order: Guest WiFi First

The single highest-leverage step you can take is splitting guest Wi-Fi from corporate Wi-Fi. It is cheap, it is fast, and it removes the most common dumb risk: a visitor’s compromised phone or a contractor’s malware-laden laptop pivoting onto your file server because they got the office Wi-Fi password.

The order we deploy in for a typical Melbourne SME segmentation engagement is as follows.

Week one. Guest Wi-Fi on its own VLAN with a captive portal, time-limited credentials, and a firewall rule that permits internet egress only. No access to internal subnets. This alone removes about 40 percent of the lateral movement risk for a typical SME.

Week two. Voice VLAN. Move the SIP phones onto their own VLAN, lock egress to your SIP provider’s IP range only, and prioritise QoS. This stops a compromised phone from talking to anything except the SIP provider and improves call quality at the same time.

Week three. IoT and AV VLAN. Move printers, cameras, smart TVs, AV gear, and any other unmanaged device onto its own VLAN. Permit only the management traffic the corporate VLAN needs (Bonjour and mDNS reflection for AirPrint, print server traffic, RTSP for camera viewing). Block everything else.

Week four. Corporate VLAN cleanup. Remove anything that should not be on the corporate VLAN, audit static IPs, document the segmentation in a network diagram, and set up monitoring alerts for inter-VLAN traffic that violates the rule set.

That is a four-week project for a typical 30-person Melbourne SME. Most of the cost is engineering time, not hardware. If you are already on UniFi, the hardware is essentially free, and the labour is roughly fifteen to twenty engineer-hours including documentation.

Where SMEs Over-Engineer

Segmentation has a way of attracting over-engineering. Here is what to skip if you are a 30-to-100-person business.

Microsegmentation. This is the practice of giving each workload or application its own segment with policies down to the application port level. It is the right answer for large enterprises with data centres and dozens of regulated workloads. It is not the right answer for a 40-person Melbourne law firm with one practice management system. Microsegmentation tooling costs more than the entire SME’s segmentation budget and adds operational complexity that the IT team cannot maintain.

Per-application firewalls. The pattern where each application has its own next-generation firewall with deep packet inspection rules. Same logic as above. It belongs to the enterprise data centre, not the SME network. For SMEs, a single perimeter firewall with sensible inter-VLAN rules covers the same risk at a fraction of the cost.

Identity-aware proxies for every internal application. Good idea in theory. In practice, deploying ZTNA across every internal app for a 30-person business takes three to six months of integration work, costs tens of thousands in licensing, and leaves the team frustrated. Start with corporate, guest, IoT, and voice segmentation. Then layer identity-aware access onto the two or three highest-value internal applications. Do not try to do all of it at once.

Dedicated SIEM and SOAR. SMEs that try to deploy a SIEM and incident orchestration platform alongside segmentation usually end up with both half-deployed. Use Microsoft Defender for Business or your MSP’s monitoring stack until you genuinely outgrow it. Our managed IT services Melbourne programme includes 24/7 NOC monitoring out of our Tecoma office, which covers what a small SIEM does for a fraction of the cost.

Sample VLAN and Firewall Rule Pack

Here is a sample rule pack that we deploy as a starting point on UniFi, pfSense, or Meraki gear. Adapt the IP ranges to your environment. The rules are written as “from-to: permit/deny.”

The thing to notice about this rule pack is how restrictive it is by default. Most SMEs run flat networks where everything can talk to everything. That is the disease. The cure is “deny by default” between VLANs and explicit permits only for the traffic you actually need. If you do not know whether a traffic flow is needed, it is not needed. Add it back if something breaks.

One detail that catches people out: print discovery. Modern printers use mDNS and Bonjour for discovery, which is broadcast-based and does not cross VLAN boundaries by default. You need either an mDNS reflector (UniFi calls it mDNS, Meraki calls it Bonjour Forwarding) configured between corporate and IoT VLANs, or you fix the printers in DNS with static A records and add them as IP-based printers. Both work. We usually prefer the static DNS approach because it is more deterministic.

The Trap: Segmenting Without Identity

This is the trap that costs SMEs more than any other in segmentation projects. You spend a weekend deploying four VLANs, you write a clean rule pack, you feel great, and then a phished user credential turns out to be a domain admin because identity hygiene was never done. The attacker authenticates as a privileged user, traverses your VLAN rules using legitimate credentials, and segmentation buys you nothing.

Segmentation is necessary but not sufficient. You also need identity hygiene. The minimum identity work to do alongside segmentation is as follows.

One. No standing domain admin. Domain admin rights are granted just-in-time, ideally through Privileged Identity Management in Entra ID, or at minimum through a separate dedicated admin account that requires MFA and is not used for email or browsing.

Two. MFA on everything. Not just email. RDP gateways, VPN, the firewall admin interface, the switch management interface, the wireless controller, the file server admin. If a credential gives access to something, that access requires MFA.

Three. Conditional access policies on Entra ID. At a minimum, require MFA for all users, block legacy authentication protocols, and require a compliant device for access to admin roles and high-value applications. This is included in Microsoft 365 Business Premium and is one of the highest-leverage controls available.

Four. Local admin password randomisation. Every Windows endpoint should have a unique, randomised local administrator password managed via LAPS or its modern equivalent in Intune. A consistent local admin password is one of the fastest paths to lateral movement, and most SMEs still have it.

Five. Application control allowlisting on at least the corporate VLAN endpoints. This is the hardest of the Essential Eight to deploy well, but it is also one of the most effective. See our deep dive on application control for the practical playbook.

Without those identity controls, segmentation is theatre. With them, segmentation becomes a meaningful second line of defence.

A Melbourne Example: 38-Person Architecture Practice in Richmond

A 38-person architecture practice in Richmond engaged us in early 2025 after a near-miss incident. A user clicked a phishing link, entered credentials into a fake Microsoft login page, and an attacker logged into their mailbox. The mailbox had access to a shared SharePoint library with five years of client documents, and the attacker started downloading files before MFA challenges (delayed by a policy gap) interrupted them.

The post-incident review showed three problems. First, no conditional access policy requiring MFA on every sign-in. Second, no device compliance check, so the attacker authenticated from an unmanaged device with no resistance. Third, flat network with no segmentation, so if the attacker had pivoted from email to internal systems, nothing would have stopped them.

We deployed in three phases. Phase one was identity hardening: conditional access, device compliance, MFA enforcement, LAPS on the Windows fleet. Phase two was segmentation, exactly the four-VLAN pattern above, with the addition of a fifth VLAN for the Revit project file server because it is high-value and warrants its own zone. Phase three was monitoring: alerting on inter-VLAN traffic that violated rules, alerts on impossible-travel sign-ins, and alerts on download volume anomalies in SharePoint.

Total project cost: just under $34,000 across three months. Total engineer time: 58 hours. Hardware: $4,800 of UniFi gear that replaced a single flat-network router and a consumer-grade access point. They have had zero security incidents in the eighteen months since.

The most important detail: the segmentation work would have been worthless without the identity work that came first. We do not deploy VLANs as a standalone project anymore. Segmentation comes packaged with identity hardening, or it does not come at all.

Hardware Choices: UniFi, Meraki Go, or Meraki Proper

Three tiers cover almost all Melbourne SME deployments. Each has trade-offs.

UniFi from Ubiquiti is the SME favourite for good reason. Hardware is one-time-cost, no recurring licences, the controller is good, and the gear is genuinely capable of handling four-to-six VLANs and the rule pack above. The trade-off is that you (or your MSP) own the operational lift. If the controller falls over, no vendor support phone number rescues you. We deploy UniFi for clients with an MSP relationship in place, because the MSP carries the operational responsibility.

Meraki Go is the entry-level cloud-managed option from Cisco. It is easy to set up, has a clean phone app, and is a good fit for businesses under 20 staff who want minimal operational complexity. The trade-off is feature ceiling. Once you want VLAN-aware DHCP scopes, more than basic firewall rules, or advanced visibility, you hit the ceiling. We tend to deploy Meraki Go for businesses we do not co-manage.

Meraki proper (the full Cisco Meraki dashboard) is the right answer for SMEs with serious compliance ambitions or with multi-site setups. The licensing cost is real (typically $80-$200 per device per year), but the cloud management, deep visibility, and reliability are excellent. We deploy this for clients in regulated sectors and for clients with three or more sites where central management saves enough engineer time to pay for itself.

None of these is the wrong answer. The right answer depends on whether you have an MSP, your compliance trajectory, and how much operational lift you want to carry yourself. Our MSP Melbourne team scopes the hardware decision as part of the segmentation engagement so the gear matches the operating model.

Monitoring: How You Know Segmentation Is Working

Deploying segmentation and not monitoring it is half the job. You need to know when a rule is being violated, when a device is in the wrong VLAN, and when traffic patterns indicate something abnormal.

The minimum monitoring set for an SME deployment:

Alert on denied inter-VLAN traffic above a threshold. A few denied packets are normal background noise. A sustained pattern of denied traffic from one IoT device trying to talk to a corporate file share is a signal worth investigating.

Alert on new devices in any VLAN. Especially the corporate VLAN. If an unknown MAC address suddenly appears, you want to know.

Alert on devices moving between VLANs. This should almost never happen during normal operations. If a device hops from IoT to corporate, something is misconfigured or, worse, someone is poking at the network.

Alert on rule changes. The firewall rule pack is now a security control. Changes to it should be logged, ideally reviewed, and definitely not made silently.

Our 24/7 NOC out of Tecoma handles this monitoring for our managed clients. We respond to P1 incidents in under 15 minutes and are on-site across Melbourne metro within the same business day when something needs hands on gear. For clients running their own ops with our co-managed IT support model, we share the monitoring with the internal team and escalate when thresholds are crossed.

How This Fits With Essential Eight and ISO 27001

Segmentation is not explicitly an Essential Eight strategy, but it is referenced under several of them and is foundational to a Maturity Level Two posture. Restricting administrative privileges, restricting Microsoft Office macros, and application control all become more enforceable when segmentation has limited the blast radius of any single compromised endpoint.

For ISO 27001, segmentation falls under Annex A.13 (Communications Security) and contributes evidence for several other controls. We do not certify clients (we are ISO 27001 capable, not a certifying body), but we have helped a number of Melbourne SMEs pass certification audits, and segmentation always shows up positively in the auditor’s review.

For Privacy Act obligations, segmentation reduces the population of data potentially affected in a breach, which can change the calculus on notifiable data breach decisions. See our Privacy Act for SMBs guide for the data handling context.

What This Costs for a Typical Melbourne SME

The all-in cost for a 30-to-50-person SME segmentation engagement, including identity hardening and ongoing monitoring, breaks down roughly as follows.

Total project cost typically lands between 20 and 30 thousand dollars depending on existing hardware, site complexity, and how much identity work is needed alongside the segmentation. The ongoing monitoring sits inside our per-user fixed monthly managed service pricing, so there is no surprise on the operational side.

Compared to the cost of a single ransomware incident (we covered this in another article and the realistic number for an SME is between $150,000 and $400,000 including downtime and customer churn), the segmentation project pays for itself if it prevents one incident. The maths is usually obvious in the boardroom.

Frequently Asked Questions

Can I do segmentation myself with a consumer router?

No. Consumer routers do not support meaningful VLAN tagging, and the firewall capabilities are not granular enough to write the kind of rule pack that makes segmentation worth doing. You need at minimum a small-business gateway like a UniFi Cloud Gateway, a Meraki Go GX, or an equivalent. The hardware costs less than a couple of staff laptops, so the price is not the obstacle.

Will segmentation slow down my network?

On modern gear, no. The gateway processes inter-VLAN routing at line rate, and the firewall rules add microseconds of latency, not milliseconds. The only place we see performance issues is when an SME tries to deploy deep packet inspection and TLS interception on undersized hardware. If you size the gateway correctly for your throughput, segmentation is invisible to users.

Do I need separate physical switches for each VLAN?

No. VLANs are logical, not physical. One managed switch handles all four VLANs at once, tagging traffic on the uplink to the gateway. The only reason to use physically separate switches is for an OT or industrial environment with very strict isolation requirements, and that is not most SMEs.

What about working from home: do segmentation rules apply on the VPN?

This is the part that gets missed. If your remote workers VPN in and land in the corporate VLAN by default, your segmentation has a hole. The fix is either a separate VPN VLAN with its own rule set, or, better, moving away from VPN entirely and using Entra ID conditional access with device compliance checks for application access. The latter is the modern approach and avoids the VPN-as-trust-domain problem entirely.

How often should the rule pack be reviewed?

Quarterly at minimum, and after any significant change to the application stack. We review rule packs as part of our managed client quarterly business reviews, and we use those reviews to remove rules that are no longer needed (which is more common than adding new ones).

What if a vendor needs access to one of my internal systems?

Vendor access should land in a dedicated vendor-access zone with explicit rules to the specific systems they need. Do not give vendors guest Wi-Fi credentials and ask them to VPN. Do not give them corporate Wi-Fi access. A dedicated zone with explicit permissions, ideally with MFA and time-bound credentials, is the right pattern.

How do I get started?

The honest first step is an assessment. We will look at your existing network, your endpoint fleet, your identity setup, and your compliance trajectory, and we will give you a sequenced plan. We do this for Melbourne clients regularly out of both our Tecoma office and our 575 Bourke St CBD office. Reach the team via the contact page and we will sort out a discovery session.

Phishing-Resistant MFA: Why It’s Time to Move Past SMS Codes

SMS-based MFA is now treated as a failed control by ASD’s Essential Eight guidance and by every major cyber insurer. If your Melbourne business still relies on text-message codes for accounts that matter, you are running a security control your insurer will dispute on claim day. Here is the practical fix.

What “phishing-resistant” actually means

The term gets thrown around loosely. The technical definition is sharper than people realise. A phishing-resistant authenticator is one where the secret used to prove identity cannot be replayed, phished or intercepted between the user and the legitimate service, and where the authentication is cryptographically bound to the actual domain being authenticated to.

In practice that means the authenticator checks the relying party — the actual domain the browser is connecting to — and refuses to release credentials to an attacker’s lookalike site. SMS does not do this. TOTP authenticator apps that spit out six-digit codes do not do this. Push notifications that show “approve or deny” without binding to a domain do not do this either, which is why attackers spent 2022-2024 perfecting MFA fatigue attacks.

The three things that actually qualify as phishing-resistant in 2026:

• FIDO2 security keys — physical hardware tokens like YubiKey 5, Google Titan, or Feitian devices that perform cryptographic challenge-response against the verified origin.
• Platform passkeys — credentials stored in Windows Hello, Touch ID, Face ID or Android’s keystore, syncing through iCloud Keychain or Google Password Manager, using the same FIDO2 protocol.
• Microsoft Authenticator with number matching and Authenticator-based passkeys — the modern Microsoft Authenticator experience now supports both number-matching push (a meaningful improvement) and full FIDO2 passkeys (the actual fix).

Notice what is missing. SMS, voice calls, email codes, TOTP apps like Google Authenticator or Authy, and old-school push notifications without number matching. All of those are second-factor controls, but none of them is phishing-resistant in the technical sense. Your insurer’s renewal questionnaire is going to ask very specifically.

Why SMS failed

SMS as a second factor has four structural problems that no configuration can fix.

SIM swapping. An attacker convinces your telco to port your number to their SIM. We have seen this happen to a director at a Camberwell professional services firm in 2024 — the entire attack ran from “ported number” to “Microsoft 365 inbox compromised” in under ninety minutes, on a Sunday afternoon, with no malware involved. The MFA code went straight to the attacker.

SS7 interception. The signalling protocol that routes SMS messages between carriers has known weaknesses that allow message interception without touching the victim’s phone. Less common than SIM swapping, but documented in the wild against high-value targets.

Phishing kits with relay. Modern phishing kits (Evilginx, Modlishka, EvilProxy and their successors) act as transparent proxies between the user and the real Microsoft login page. The user types their password and SMS code into the attacker’s lookalike, the attacker relays both to Microsoft in real time, and walks away with a valid session cookie. SMS does not stop this attack at all. The user is genuinely authenticating; the attacker is just sitting in the middle.

User behaviour. SMS codes get forwarded, screenshotted, read out loud in open-plan offices, and pasted into chat windows. They are six-digit numbers transmitted in plain text. They were never designed to be a hard security control.

The ASD’s Essential Eight maturity model now explicitly requires phishing-resistant MFA at Maturity Level 2 for privileged users and Maturity Level 3 for all users. If you are aiming for ML2 or higher, SMS does not count. Essential Eight alignment is becoming a procurement prerequisite for state government work and an increasing number of private contracts, so this is not just a security debate.

YubiKey 5 vs platform passkeys: the cost comparison

Once you accept that SMS has to go, the next question is which phishing-resistant option to standardise on. The honest answer is “both, for different purposes”. Here is the comparison we walk Melbourne clients through.

For most Melbourne SMEs, the right answer is platform passkeys or Authenticator passkeys for the general staff population, plus YubiKey 5 (in pairs — primary and backup) for the privileged admin accounts and the break-glass emergency account. Total hardware spend for a 50-person business is usually in the $800-$1,500 range, not the eye-watering number people imagine.

TechAssist’s rollout order: privileged first, then finance/exec, then all staff

Doing this in the wrong order is how rollouts get stuck. We have run dozens of these and the sequencing matters more than the technology choice. Here is the order that actually works.

Phase 1: privileged accounts (week 1-2)

Every global admin, every Exchange admin, every SharePoint admin, every Azure subscription owner. Two YubiKeys each (one carried, one in a safe). FIDO2 enforced via Conditional Access. Old MFA methods removed for those accounts entirely. This is the population an attacker actually wants, and it is small enough to do in a fortnight.

For a 45-person construction firm in Port Melbourne we onboarded recently, this phase covered seven accounts — four IT-admin, the CEO, the CFO, and the office manager who had been a global admin since 2017 for reasons nobody remembered. Three of those seven had their admin rights stripped during the phase, because they did not need them.

Phase 2: finance and executive (week 3-4)

Anyone who can authorise a payment, anyone who can sign a contract, anyone whose inbox compromise would lead to a business email compromise wire fraud incident. Platform passkeys or Authenticator passkeys are usually the right tool here, with YubiKeys offered for users who travel internationally or work across multiple devices.

This phase is the one the CEO cares about, because it is also the population most likely to be socially engineered. BEC against the CFO’s inbox is the single most common direct-loss incident we see in Melbourne SMEs. The phishing-resistant control is the actual fix.

Phase 3: all remaining staff (week 5-8)

Roll passkeys out by department, in waves of fifteen to twenty users. Set a hard date by which SMS-based MFA is removed as an option in Conditional Access. Provide hands-on registration in the office for anyone who needs it. We typically allocate one engineer-hour for every five users for the registration push.

By week eight, your Conditional Access policies should be enforcing phishing-resistant MFA for all user sign-ins, with SMS removed from the available authentication methods list. That is the point you can tell the insurer the work is done.

The three traps that derail most rollouts

Even with the right order, three things consistently trip up MFA migration projects. We have learned to address these up front, not as afterthoughts.

Trap 1: shared mailboxes

Shared mailboxes in Microsoft 365 do not have their own sign-in credentials. They cannot have MFA in the traditional sense. The trap is that people forget about the user accounts behind them — the “reception”, “accounts”, “support” mailboxes that started life as full licensed users and got converted to shared at some point, but where the underlying user object is still active and signable-in.

We did a sweep at a Box Hill manufacturer last quarter and found four accounts converted to shared mailboxes years earlier where the user object still had a password, no MFA, and was a member of the global admin group. That is a real incident waiting to happen, and Conditional Access alone will not catch it unless the accounts are properly disabled.

Trap 2: service accounts

Service accounts — for the scan-to-email function on the photocopier, for the integration with the line-of-business app, for the legacy reporting tool that runs at 2am — were typically created without MFA because “you can’t put MFA on a service account”. This is partially true and entirely solvable.

The fix is a combination of: moving to certificate-based auth or app registrations with managed identities where possible, applying conditional access policies that restrict service accounts to specific source IPs or compliant device states, and putting compensating controls (privileged access workstations, vaulted credentials) around the genuinely legacy ones that cannot be modernised. Our managed IT services team treats this as a separate workstream because it always takes longer than the human user migration.

Trap 3: break-glass admin accounts

You need at least one global admin account that is excluded from your Conditional Access policies, so that if your tenant configuration somehow locks everyone out you can still log in and fix it. This account is by definition not protected by your normal controls, which makes it the single highest-value target in the tenant.

The correct setup is two break-glass accounts, each with a long random password stored in two separate physical safes, each requiring a FIDO2 security key (also stored separately), with sign-in alerts configured to notify multiple senior people if either account is ever used. The accounts should be tested quarterly to make sure they still work, and the test should be logged. Most Melbourne SMEs we audit have either no break-glass account, a break-glass account that is also a daily-driver, or a break-glass account whose password is in a sticky note in the IT manager’s desk. All three are wrong.

Conditional Access: the policy that makes it real

You can buy all the YubiKeys you like, but if your Conditional Access policies still allow SMS as a fallback, users will fall back to SMS. The policy work is what turns the rollout from “available” to “enforced”.

The minimum viable policy set for a Melbourne SME running Entra ID (formerly Azure AD) looks like this:

• All users (excluding break-glass) require phishing-resistant MFA for all cloud apps.
• Privileged role activations require FIDO2 security key specifically, not just any MFA method.
• Legacy authentication protocols (POP, IMAP, SMTP AUTH, legacy ActiveSync) are blocked entirely.
• Sign-ins from outside Australia require either compliant device state or additional verification.
• Risky sign-ins (per Microsoft Entra ID Protection signals) require password reset.

This policy stack costs nothing extra if you already have Microsoft 365 Business Premium, which includes the relevant Entra ID P1 features. If you are on Business Standard, the gap is about $9 per user per month for the Entra ID P1 add-on. For a 30-person business that is roughly $3,200 a year — cheaper than a single business email compromise incident excess on most cyber policies.

Cyber insurance: the elephant in the room

Every Australian cyber insurance renewal questionnaire we have seen in the last twelve months asks the phishing-resistant MFA question directly, in some form. The wording varies, but the intent is identical: “Do all privileged accounts use phishing-resistant MFA? Yes/No.” A “No” answer either triggers a steep premium increase, a coverage exclusion for BEC-related losses, or in some cases a refusal to quote.

We had a Hawthorn law firm client whose 2025 renewal came back with a 60% premium increase plus a $50,000 BEC sub-limit, specifically because they were still on SMS MFA for the partners. We did the rollout in three weeks, got the underwriter the updated configuration evidence, and the renewal was repriced to the previous year’s level with the sub-limit removed. The phishing-resistant MFA work paid for itself in one premium cycle.

This is now the most cost-effective security investment a Melbourne SME can make on an ROI basis, full stop. The technology cost is modest, the configuration time is measurable in days not weeks, and the insurance saving is direct and immediate. There is no better-value security project on the table in 2026.

What this looks like at TechAssist

We have been running phishing-resistant MFA rollouts as a structured project type since early 2024. A typical engagement runs four to eight weeks elapsed, depending on the size of the user base and the state of the existing Conditional Access policies. We do the discovery, the policy design, the YubiKey procurement and shipping, the user registration sessions (on-site for Melbourne metro clients with same-business-day response if anything goes wrong), and the cutover.

Because we are Essential Eight aligned and ISO 27001 capable, our documentation pack is structured to give your insurer or auditor exactly what they ask for. That matters more than it sounds — we have had clients try to do MFA rollouts internally and then struggle to produce the evidence the underwriter wanted at renewal. The rollout was fine; the paperwork was the problem.

Our Tecoma cybersecurity practice has done this for construction firms, manufacturers, law firms, healthcare providers and a couple of schools. The technical work is similar across industries; the change management is what varies. A law firm partnership is a different conversation from a warehouse-floor manufacturer, and the rollout plan has to reflect that.

Frequently Asked Questions

Will my staff actually use FIDO2 keys or will they revolt?

Genuine objections drop fast once people use the keys for a week. The sign-in experience with a YubiKey is faster than typing a six-digit SMS code — touch the key, done. Platform passkeys are even faster because they use the biometric the user is already using to unlock the laptop. The main grumbling tends to come from executives who travel and need to use multiple devices, which is a real concern that pairs of YubiKeys solve.

What happens if a user loses their YubiKey?

This is why we issue two per privileged user. The user uses the primary, the backup is in a safe (often a home safe for senior staff who travel, or a locked drawer in the office). If both are lost simultaneously, the admin can reset the user’s authentication methods via a separate verified process. The point is to design the recovery path before it is needed, not after.

Can we just use Microsoft Authenticator and skip the hardware keys?

For general staff, yes. Microsoft Authenticator with passkey support is genuinely phishing-resistant and meets the bar. For privileged admin accounts and break-glass accounts, we still recommend hardware keys because they are not tied to a phone that can be lost, stolen, broken or compromised. The privileged accounts justify the extra cost.

Do we need to upgrade our Microsoft 365 licences for this?

If you are on Microsoft 365 Business Premium, no — you already have the Entra ID P1 features needed for Conditional Access. If you are on Business Standard or Business Basic, you need either to upgrade to Premium or add Entra ID P1 as an add-on. The cost is usually in the order of $5-$10 per user per month depending on the path.

How does this interact with our existing TOTP authenticator app?

TOTP (the six-digit code apps like Google Authenticator) is not phishing-resistant and should be retired alongside SMS. The migration usually runs in parallel — users register their passkey or YubiKey, verify it works, then remove TOTP as a registered method. Conditional Access policies should explicitly require phishing-resistant authentication strength, which excludes TOTP from being a valid method.

How long does the whole project take?

For a typical 40-person Melbourne SME on Microsoft 365, four to six weeks from kickoff to fully enforced. The first fortnight covers discovery, policy design and privileged accounts. Weeks three and four cover finance and executive. Weeks five and six cover the broader staff base. Faster is possible but rarely advisable — the change management is what determines whether the rollout sticks.

What to do this week

If you take nothing else from this article, do three things this week. First, find out what authentication methods your Microsoft 365 tenant currently allows — the “Authentication methods” blade in the Entra admin centre tells you. Second, identify how many of your global admin accounts could be compromised by an SMS-based phishing attack today. Third, get a quote for FIDO2 security keys in pairs for that admin population.

That is a half-day of work that gives you the starting position. From there, the rollout is a structured project with measurable milestones. The Melbourne SMEs that have done this in 2025 are now paying lower insurance premiums, sleeping better, and not having the awkward “yes we still use SMS” conversation with their auditors.

If you would like a hand running this for your business — discovery through cutover — talk to us. We have done enough of these to know where the traps are.

Half the vendor pitches landing this quarter promise that some flavour of frontier AI will rewrite your cybersecurity stack. The federal government just told its own agencies, on the record, not to buy it. If that’s the call for a department with a nine-figure security budget, it’s an even sharper call for a 40-staff Melbourne SME.

The document driving this is the Department of Home Affairs’ Protective Security Policy Framework (PSPF) advisory 001-2026, published late May. Its headline finding: “Australian government entities do not need access to the most advanced frontier AI models to stay protected.” The advisory points agencies at the Australian Signals Directorate’s Essential Eight and the Information Security Manual instead, and sets out a six-step maturity model where AI for cyber defence only enters the picture after the basics are locked down.

This post unpacks what the advisory actually says, why it lands harder for SMEs than for Canberra, and what a Melbourne business should do about it this quarter. The short version is in the next paragraph if that’s all you have time for.

The short version

The federal government has just put its name to an argument many of us in the Australian managed services industry have been making for two years. Frontier AI — the GPT-5-tier and Anthropic Claude Mythos-tier models the consumer press calls “AI” — is not the binding constraint on your security posture. Patching, MFA on every account, application control, and EDR are. If you spend the next twelve months building out an AI security capability while your patching backlog grows and a third of your users still don’t have MFA on their privileged accounts, you will be less secure, not more. The PSPF advisory is the same argument with the Commonwealth coat of arms attached.

What PSPF Advisory 001-2026 actually says

The advisory is short, plain-language, and binding on Commonwealth entities. The core findings are worth quoting because the original is being filtered through vendor marketing and consultant commentary that often softens the edges.

First, frontier AI is collapsing the window between vulnerability discovery and active exploitation from days to hours. The advisory uses the phrase “vulnerability storm” to describe what’s coming — a sustained pace of new vulnerability discovery, accelerated by AI-assisted bug-hunting on both the attacker and researcher sides, that patching teams in their current shape cannot keep up with.

Second, the answer is not “buy a more advanced AI”. The answer is “fix the fundamentals so the storm doesn’t break the roof”. The advisory points entities to Essential Eight Maturity Level Two for user application hardening and patching, and to the broader ISM controls for the rest of the environment.

Third, AI is not banned. The Australian Cyber Security Centre’s companion guidance treats AI as a medium-term lever for reducing analyst workload, sharpening threat prioritisation, and accelerating detection and response — once the configuration baselines, attack surface reduction, and legacy system debt are dealt with. There’s a six-step maturity model that puts “AI used for cyber defence in a secure, controllable, human-supervised, ethical and accountable manner” at the top, not the start.

Fourth, and this is the line most vendors are quietly skipping in their summaries, the ACSC warns that poorly implemented AI can introduce more risk than it removes. A model with broad data access, weak authentication, and inadequate logging is a new attack surface — not a security capability.

The Australian National Audit Office has previously found that federal agencies are not yet meeting the Essential Eight obligations they already have. So the advisory is, in effect, telling agencies: finish the work you’ve already been asked to do before chasing the next thing.

Why this hits SMEs harder than Canberra

The Commonwealth has security teams, dedicated identity engineers, and panels of cleared SOC providers on retainer. A Melbourne SME with 25 staff has, in our experience, an outsourced helpdesk, one part-time internal champion, and a Microsoft 365 Business Premium tenant somebody set up in 2019 and hasn’t touched since.

If the federal government, with that depth of security capability, is being told that frontier AI is not the answer right now, the implication for an SME is sharper still. The marginal dollar spent on an AI security agent for a 25-person firm in Box Hill is a worse investment than the same dollar spent on closing the long tail of unpatched line-of-business applications, deploying conditional access policies that actually block legacy authentication, or moving the firm off the local-admin-for-all model that’s been sitting unaddressed since the original device rollout.

Three things make the SME case sharper.

One, blast radius. A federal agency with mature segmentation, monitored gateways, and a SOC on watch may be able to contain the consequences of an experimental AI tool with broad data access. A 25-staff Melbourne firm where the same person who answers the phone also has SharePoint admin cannot. A poorly configured AI agent on that tenant has the keys to the whole organisation.

Two, talent. AI security tooling does not deploy itself. It needs people who understand the threat model, who can write the playbooks, who can tune false positives, and who can read the model’s reasoning when it flags something. SMEs do not have those people. Buying the tool without the people is buying an expensive logging product that nobody reads.

Three, sequencing. The Essential Eight controls compound. MFA reduces the attack rate, which reduces the volume of incidents the EDR has to respond to, which reduces the noise the SOC has to wade through, which reduces the need for AI triage. Skip the MFA layer and the AI tool inherits an unfiltered firehose of alerts it cannot meaningfully reason about. The advisory is essentially saying: do the upstream work first, because everything downstream becomes cheaper and more effective afterwards.

The Essential Eight, translated for an SME

Most SMEs we onboard have heard of the Essential Eight, can name two or three of the strategies, and have implemented somewhere between zero and three of them properly. The framework is from the Australian Signals Directorate and applies to any organisation, not just Commonwealth entities. Maturity Level One is the floor; Maturity Level Two is where insurers, larger clients, and now the PSPF want most organisations to sit. We’ve covered the framework in depth in our plain-English Essential Eight guide and our Essential Eight compliance guide; the short translation for an SME owner reading the PSPF advisory is below.

Working through this table is uncomfortable because most SMEs find they have one or two strategies covered, one or two half-done, and the rest left as “we’ll get to it”. The PSPF advisory is the most senior endorsement Australia has yet produced of the position that no AI-flavoured purchase fixes that gap. Only the work fixes it.

What the “vulnerability storm” looks like at SME scale

The advisory’s framing of a “vulnerability storm” is not abstract. The pattern we’ve watched accelerate since 2024 looks like this. A vulnerability lands in a widely deployed product — a Fortinet appliance, an Exchange server, a content management plugin, a remote access tool. Within hours, AI-assisted reverse engineering produces a working exploit. Within a day, scanning campaigns hit every IP that exposes the product. Within two days, opportunistic ransomware operators are inside the businesses that didn’t patch.

For SMEs the pattern is brutal because the patching pipeline has not shortened. A typical Melbourne SME without managed IT discovers a Fortinet patch when their MSP newsletter arrives, schedules a maintenance window for the weekend, and applies it on Saturday night. The vulnerability has been actively exploited since Tuesday morning. That gap is what the PSPF advisory is trying to close at the Commonwealth level.

The control that defends against this is not AI. It is having someone, somewhere, whose job it is to watch the vendor advisories for the products you actually run and to ship the patches within the timeframes the Essential Eight specifies. For a 25-staff firm in Hawthorn, that someone is almost always a managed service provider with a NOC. For us, that NOC runs 24/7 from Tecoma and covers the patching pipeline as a baseline part of the managed agreement, not as a premium add-on.

“But the vendor said their AI tool reduces our risk”

It might. Read the PSPF advisory’s companion guidance carefully — the ACSC is explicit that AI can meaningfully reduce manual workload, sharpen threat prioritisation, and accelerate detection and response. The objection is not that AI is useless. The objection is that it sits at the top of a maturity ladder, not the bottom.

There are three honest tests for any AI security pitch landing in your inbox right now.

One, does it require capabilities you don’t yet have to be useful? An AI triage tool fed by a SIEM you don’t have, watching logs you don’t collect, against a baseline you haven’t built, will not produce signal. It will produce noise that costs money. If the answer to “what does this AI tool need to work?” includes “your existing telemetry”, and you don’t have existing telemetry, the prerequisite is the telemetry, not the AI.

Two, does it have the access it claims to need, and have you understood what that means? AI agents that read your mailboxes, your file shares, and your SaaS apps to “find risk” need credentials to do so. Those credentials become a target. The advisory’s warning about poorly implemented AI introducing risk is exactly this concern. Before approving the access, ask what happens if the model itself is compromised.

Three, does it replace a control or add a layer? An AI tool that replaces your existing EDR is a forklift. An AI tool that augments your existing EDR with better triage is a layer. For SMEs, layers are easier to roll back than forklifts. Forklifts during a vulnerability storm are how a firm ends up running two products at half-capacity through the period when the storm hits.

None of this means saying no to AI. It means saying “after” to AI for most SMEs in 2026, and meaning it.

What an SME should actually do this quarter

Take the advisory at face value and treat it as cover for postponing the AI pitch until next year. Spend the budget on the four moves below instead.

Move one: do an honest Essential Eight self-assessment. Not a vendor questionnaire. The ASD publishes the assessment guide; we publish a plain-English version in our Essential Eight guide. Walk through each of the eight strategies and grade your current state at Maturity Level Zero, One, Two, or Three. Be honest. Most SMEs land somewhere between Zero and One overall, with one or two strategies at Two.

Move two: pick the worst score and close it within 90 days. If MFA coverage is incomplete, finish it. If patching for line-of-business apps is ad-hoc, build the pipeline. If admin privileges are scattered across the user base, separate them. Closing the worst gap does more than closing three middle gaps because attackers find the worst gap first.

Move three: make sure your backup story holds. The PSPF advisory’s framing of accelerated attack timelines means the time from compromise to ransomware execution is shrinking. If your backups are reachable from the production domain, they will be encrypted alongside production. Immutable copies, offline copies, and quarterly restore tests are the difference between a bad week and a fatal one. The fundamentals are the same as we set out in our Essential Eight guide’s backup section.

Move four: write an AI acceptable use policy so staff don’t bring frontier AI through the back door. While the advisory is telling agencies not to chase frontier AI for security, staff are pasting client data into ChatGPT to summarise emails. The risk is the inverse of the one the advisory addresses, and SMEs need both sides covered. Our AI acceptable use policy template walks through the structure.

None of these four moves require buying frontier AI. All of them reduce the probability and impact of the next incident. That is what the PSPF advisory is asking Commonwealth entities to do; it is what SMEs should be doing too.

Where AI does belong in an SME security stack — eventually

The honest position is not “never AI”. It is “AI when the upstream work is done”. For an SME at Essential Eight Maturity Level Two, with EDR deployed, telemetry centralised, a working SOC relationship, and an identity platform that can reason about access, AI-augmented tooling starts to earn its keep. The places it earns it first are alert triage on a working SIEM, phishing analysis on email that already has DMARC at p=reject, and identity risk scoring on a tenant where conditional access already exists.

The pattern is the same as automation generally. AI amplifies whatever it sits on top of. On a mature stack, it amplifies signal. On an immature stack, it amplifies noise — and noise during a vulnerability storm is how incidents go undetected.

The PSPF advisory’s six-step maturity model puts AI at step six for a reason. The steps below it are the controls that make step six work. There is no shortcut.

How TechAssist is thinking about this with clients

We’ve been running managed IT for Melbourne SMEs since 2008. Thirteen Australian engineers, two offices — Tecoma and Melbourne CBD at 575 Bourke Street — and a 24/7 NOC at Tecoma covering response under fifteen minutes on P1 issues. Our delivery is Essential Eight aligned and ISO 27001 capable, which is the table-stakes posture the PSPF advisory is asking everyone to reach.

The PSPF advisory has not changed our roadmap with clients. It has, helpfully, given us a Commonwealth-level reference for the conversation we were already having when a director forwards a frontier-AI vendor pitch and asks whether to take the meeting. Our standing answer has been: take the meeting next year. Read the advisory, run the gap assessment, close the worst gap. The advisory is now the citation at the bottom of the email.

The broader picture of how we approach security for SMEs is in our Melbourne cybersecurity services page; the operational layer underneath is in our managed IT services page. If you want help reading the PSPF advisory against your own environment, get in touch via our contact page or call 1300 028 324. Mention the advisory; we’ll structure the conversation around your Essential Eight position rather than running a generic discovery.

Frequently asked questions

Is the PSPF advisory binding on private businesses?

No. The PSPF is binding on Commonwealth non-corporate entities only. Private businesses, including SMEs, are not legally required to follow it. The reason it matters anyway is that the underlying control set — Essential Eight and the ISM — is what insurers, larger clients, and most state-government procurement processes now expect, and the PSPF advisory is the most authoritative recent statement of what good looks like. Treat it as the strongest available reference, not a regulation.

We already use Microsoft Copilot. Does the advisory say we should stop?

No. The advisory is about frontier AI for security operations — large language models used to detect and respond to threats in a security operations centre. Copilot for productivity is a separate question with separate controls. The controls that matter for Copilot are data classification, sensitivity labels, conditional access, and an AI acceptable use policy that staff have read. Our AI acceptable use policy guide covers the SME side.

How quickly can a 25-staff Melbourne SME reach Essential Eight Maturity Level Two?

For a firm starting at Maturity Level Zero across most strategies, a realistic timeline is 90 to 180 days with a managed service provider doing the work. The fast wins are MFA rollout (two to four weeks), patching pipeline (four to six weeks), and admin privilege separation (four to eight weeks). The slower ones are application control and application hardening, both of which require workflow testing to avoid breaking staff productivity. We’ve described the staged approach in our 90-day Essential Eight compliance roadmap for Melbourne.

What’s the difference between Essential Eight and the ISM?

The Essential Eight is a small set of high-impact mitigation strategies — eight of them — designed as a baseline. The Information Security Manual is the comprehensive ASD control catalogue covering everything else: cryptography, gateways, system administration, personnel security, supply chain, physical controls, and the rest. The Essential Eight is the prioritised starting set; the ISM is the full reference. For most SMEs, getting to Essential Eight Maturity Level Two is the goal; the ISM becomes relevant if you’re tendering for Commonwealth or large-enterprise work.

Will my cyber insurance cover this?

Cyber insurance does not pay for Essential Eight implementation; it pays out after an incident, and only if you can demonstrate the controls you said you had at the time the policy was written. The trend in 2025 and 2026 has been steeper questionnaires, lower limits where controls are weak, and tighter exclusions on ransomware where backups are not immutable. The PSPF advisory accelerates this — underwriters cite ASD frameworks in their underwriting and will price your renewal accordingly. Closing your Essential Eight gaps reduces both the probability of a claim and the cost of the premium that covers it.

If frontier AI is bad for cyber, why are vendors selling so much of it?

The advisory does not say frontier AI is bad. It says it is not the binding constraint on most defenders’ security posture right now, and that buying it before fixing fundamentals creates more risk than it removes. The vendor incentive to sell AI is unrelated to whether you should be buying it this quarter. Read the pitch, ask the three honest tests we set out above, and put the answer in writing for the file.

Where can I read the PSPF advisory myself?

The advisory is published on the Department of Home Affairs Protective Security Policy Framework website, listed as advisory 001-2026. The companion guidance from the Australian Cyber Security Centre is published on the cyber.gov.au site. Both are public documents. Read them in that order — the PSPF advisory sets the obligation, the ACSC guidance sets the technical detail.

Your Professional Indemnity insurer wants proof, not promises. At 2026 renewal they expect documented evidence of MFA on every account, EDR on every endpoint, immutable backups, a tested incident response plan, vendor risk records, and current security awareness training logs. If you can’t produce these on demand, expect higher premiums, tighter sub-limits, or a declinature.

That’s the short answer. The longer answer is that law firm cybersecurity australia conversations have changed shape since 2023. PI underwriters in the Australian legal market — Lawcover, LMI, Marsh-placed syndicates, and the London market behind most boutique brokers — used to ask a single tick-box question about “having antivirus”. Renewal questionnaires in 2025 and 2026 run twenty to forty technical questions deep, and a “yes” with no evidence is functionally a “no” at claim time.

This post is the practical brief for partners, principals, and practice managers at Melbourne firms with five to a hundred staff. It’s written from the engineering side: what underwriters now demand, what that actually looks like in a working firm, where Melbourne practices keep getting caught, and what to have ready before your broker rings.

Why PI underwriting changed

The Optus breach in September 2022 and Medibank a month later reframed cyber risk in the Australian insurance market. Reinsurers based in London and Munich repriced Australian cyber and PI cover almost immediately. By the 2024 renewal cycle, every Australian PI insurer touching the legal sector had rebuilt their underwriting questionnaires around the same control set — the one the Australian Cyber Security Centre had been publishing as the Essential Eight since 2017.

Three things shifted at once. First, the Notifiable Data Breaches scheme — administered by the OAIC under the Privacy Act 1988 — generated enough public data that underwriters could finally model breach frequency by sector. Legal services consistently sit in the top five by notifications per thousand businesses. Second, the Legal Profession Uniform Law’s professional conduct rules around client confidentiality were tested in several disciplinary matters where the underlying cause was a cyber incident, not deliberate disclosure. The VLSB+C (Victorian Legal Services Board and Commissioner) takes a dim view of practitioners who lose privileged material through preventable controls failures. Third, business email compromise losses on conveyancing and family law settlements stopped being rare. They became the most common notification type from the legal sector.

The combined effect: insurers stopped treating cyber as an adjacent line and started treating it as a core PI risk. A breach that exposes client trust account details, leaks privileged advice, or redirects settlement funds is now a PI loss, not just a cyber loss. That’s why the questionnaires got longer.

The controls underwriters now require evidence of

Below is the control set we see consistently across renewal questionnaires for Melbourne legal practices in 2025 and 2026. The exact wording varies between insurers in the Australian legal market, but the substance is consistent. “Evidence” in the right column means what we hand to the broker — not a verbal assurance.

This is the spine of the Essential Eight in legal-firm clothing. If you’ve already mapped your controls to the ACSC framework, you’ve done most of the work — see our Essential 8 compliance guide for how the maturity levels translate into renewal evidence. The broader operational picture for Melbourne firms is covered in our piece on managed IT for Melbourne law firms, which goes deeper on day-to-day workflows. This post stays focused on what the underwriter wants to see.

How Melbourne law firms actually get caught

The questionnaire controls aren’t theoretical. Each one exists because insurers paid claims on a specific failure mode. Three patterns dominate the legal-sector losses we see across Melbourne.

BEC during property settlement

A boutique conveyancing practice in Hawthorn, eight staff, ran a standard residential settlement through PEXA. Two weeks before settlement, the conveyancer’s email account was compromised through a credential-stuffing attack — the practitioner reused a password that had appeared in a 2021 breach dump. The attacker sat in the mailbox for nine days, set up an Outlook rule to auto-forward and delete anything containing the matter reference, and at the right moment sent the purchaser’s solicitor a “corrected” trust account BSB and account number from a lookalike domain registered three weeks earlier.

The purchaser’s funds — $847,000 — landed in a mule account in Sydney and were withdrawn within ninety minutes. The PI claim covered the loss but the renewal premium tripled, the firm was placed on a remediation programme by the insurer, and the principal had a conversation with the VLSB+C that no principal wants to have.

What would have stopped it: MFA on the email account (would have blocked the credential stuffing); DMARC at p=reject on the firm’s domain (would have made the lookalike-domain trick harder); a dual-approval process for any change to settlement bank details that requires verbal confirmation on a known phone number; an inbox rule audit running weekly. Every one of those is now a tick-box on the renewal questionnaire.

Ransomware on the practice management system

A 22-lawyer commercial firm in William Street ran LEAP on an on-premises Windows server. The server was patched, the firm had antivirus, and they had backups on a Synology NAS that was reachable from the domain. On a Tuesday afternoon a paralegal opened an invoice attachment that wasn’t an invoice. By Wednesday morning the LEAP database was encrypted, the file shares were encrypted, the Synology backups had been encrypted because the backup service account had write access to the NAS, and the only clean restore point was a three-month-old archive on a USB drive in the office manager’s desk drawer.

The firm was offline for nine business days. Court deadlines were missed. The reconstruction of work-in-progress cost more than the ransom demand. PI cover responded but the insurer required, as a condition of renewal, EDR with managed response, immutable backups with offline copies, and segregation of the backup environment from the production domain. They also required documented evidence that the firm had moved off the legacy AV product within sixty days.

What would have stopped it: EDR with behavioural detection (would have killed the ransomware process before encryption started); immutable backups (the Synology was the single point of failure); least-privilege on the backup service account (it had no business being able to write to anything except the backup repository); a tested restore process.

Departing-staff conflict-of-interest exfiltration

A family law boutique in Camberwell, six lawyers, had an associate resign and move to a competing practice down the road. In her last fortnight she synced her firm OneDrive to a personal Dropbox, emailed forty-seven matter files to a Gmail address, and copied the client list to a USB stick. The firm only found out when a former client rang asking why the new practice already knew about her matter.

This isn’t a hacker story. It’s a controls story. The OneDrive sync to personal storage was permitted because nobody had configured a conditional access policy blocking personal Microsoft accounts on managed devices. The email exfiltration ran unnoticed because the firm had no DLP rules on outbound attachments. The USB copy worked because removable storage wasn’t blocked. The PI insurer paid the resulting client claims but the firm now has formal data loss prevention controls in place — because the renewal questionnaire asked, and a “no” wasn’t an option.

Where the LIV, VLSB+C, and Uniform Law sit in this

The Law Institute of Victoria publishes practice guidance on technology use and increasingly references the Essential Eight directly. The VLSB+C, as the regulator, doesn’t run a separate cyber compliance regime — but the Legal Profession Uniform Law’s professional conduct rules around client confidentiality apply to electronic records the same way they apply to paper. If privileged material walks out the door because controls were absent, that’s potentially a conduct matter, not just a cyber incident.

The OAIC sits across this as the regulator for the Notifiable Data Breaches scheme. Any breach involving personal information that’s likely to result in serious harm must be notified within thirty days. For a law firm, almost any breach meets that threshold because the data is, by definition, sensitive. The OAIC’s reasonable steps test under APP 11 looks remarkably similar to the Essential Eight in practice.

None of these bodies mandate a specific technical control set. Together they make absence of one indefensible. PI underwriters know this, which is why their questionnaires read like an APP 11 audit with a managed-services flavour. Our guide to IT compliance for legal practices goes deeper on the regulatory side; this post is focused on the insurance side because that’s the meeting that’s coming up next.

The PI questionnaire decoded

If you’ve been handed a 2026 renewal questionnaire, the questions tend to cluster into seven domains. Here’s how to read them.

What “evidence-ready” actually looks like

The phrase brokers use is “evidence-ready”. Insurers want a folder — usually shared via a secure portal — containing the documents that back each questionnaire answer. For a 30-person Melbourne firm, that folder typically holds:

• An information security policy, signed by the managing partner, dated within the last twelve months.
• The incident response plan, with a tabletop exercise record from the last six months.
• A network diagram showing the firm’s environment, including cloud tenancy boundaries.
• A data flow map showing where client data lives — practice management, document management, email, archives.
• Backup architecture and the most recent restore test report.
• MFA coverage report exported from Entra ID or the equivalent identity platform.
• EDR licence and coverage report.
• Patch compliance report by device.
• Phishing simulation results for the last twelve months.
• Security awareness training completion records for every employee.
• Vendor risk register with current SOC 2 or ISO 27001 reports for material vendors.
• Penetration test report or vulnerability assessment dated within the last twelve months.
• Cyber insurance certificate if held separately from PI.
• IR retainer agreement with a DFIR firm.

This is roughly what we maintain for our legal-sector clients on a rolling basis. The first time a firm builds this folder it takes about six weeks. After that it’s a quarterly review.

The trust account angle

Trust accounts deserve their own paragraph because they’re where the PI conversation gets sharpest. The VLSB+C’s trust account inspection regime focuses on financial controls, not cyber controls — but a compromised email account that authorises a trust withdrawal is a trust account failure with a cyber root cause. The principles are similar to what we’ve written about for the accounting sector in our accounting firm data security and trust account protection piece, but legal practices have additional confidentiality obligations on top.

For trust account-handling firms, the additional controls underwriters look for are:

• Segregation of duties so no single person can authorise a trust payment and change a bank detail.
• Out-of-band verification — a phone call to a known number, not the number in the email — for any change to settlement banking details.
• Logging of every change to bank account details in the practice management system.
• Restrictions on remote access to the trust accounting module.

The IR retainer question

This one trips firms up consistently. A growing number of PI questionnaires ask whether the firm has a “pre-engagement with an incident response provider”. A yes-or-no answer with no documentation isn’t enough; underwriters want to see the agreement, the SLA on response time, and the name of the DFIR firm.

The reason is practical. A breach at 4pm on a Friday in a firm without a retainer means the principal spends Friday night ringing law firms (ironic) for referrals, then ringing IR firms who all quote a five-figure engagement fee before they’ll start work, then waiting until Monday morning for forensics to begin. By then the attacker has been in the environment for sixty-plus additional hours. With a retainer, the call goes to a 24/7 hotline, the engagement is pre-papered, and the analyst is in your environment within an hour.

TechAssist’s NOC at Tecoma runs 24/7 with sub-fifteen-minute P1 response, and we maintain DFIR relationships for clients who need separate forensics capability. The retainer doesn’t replace your MSP’s incident response — it’s the specialist forensics and legal-privilege layer that sits above it.

Cost framing

The question every managing partner asks is what this costs. Rough order of magnitude for a Melbourne firm of 25 staff, looking at what insurers now expect as table stakes:

The savings sit on the other side of the ledger — in PI premium itself, in the avoided cost of a single BEC loss, and in the avoided cost of unwinding a ransomware event. A 25-staff firm seeing premium reductions of 10-20% on a $40,000-$80,000 PI line is paying for most of the control uplift through the insurance line alone.

How TechAssist works with law firms on this

We’ve been running managed IT for Melbourne legal practices since 2008. The team is thirteen Australian engineers, all local, with the 24/7 NOC at Tecoma in Melbourne’s east. Our controls are Essential Eight aligned and our delivery is ISO 27001 capable, which matters because the same questionnaire that asks about your controls also asks about your MSP’s controls — and your MSP either passes that sub-questionnaire or becomes the weak link in your renewal.

For PI-renewal-ready engagements we work to a four-stage pattern: gap assessment against the questionnaire your broker uses; remediation plan with priority order driven by the questions most likely to determine pricing; implementation with evidence captured from day one; and a documentation pack handed to your broker. The full picture of how we handle ongoing operations for legal sector clients is in our broader piece on IT support for Australian law firms, which covers the day-to-day. The cybersecurity layer is detailed at cybersecurity services Melbourne.

P1 response sits under fifteen minutes by SLA. We’ve had to use that response time on legal-sector incidents, including BEC attempts caught mid-attack and one ransomware event isolated before encryption spread off the patient-zero machine. The pre-existing IR retainer made the difference in both cases.

If your renewal is coming up

Pull the questionnaire from your broker now, not when the renewal date arrives. Read it cold and mark each question green, amber, or red. Green is “yes, with evidence in the folder”. Amber is “yes, but the evidence is thin”. Red is “no, or I don’t know”.

Take the reds first. The high-leverage ones are usually MFA-everywhere, EDR with managed response, immutable backups, an IR retainer, and a dual-approval process on settlement banking details. Those five, properly implemented and documented, move the needle on premium more than any other combination.

If the questionnaire mentions specific frameworks — Essential Eight, ISO 27001, NIST CSF — ask the broker which one the underwriter weights most heavily. For the Australian legal market it’s almost always Essential Eight, and the maturity level expected is typically ML2 for firms over twenty staff.

If you’d like a hand with any of this — the gap assessment, the remediation, the evidence pack — get in touch via our contact page or call 1300 028 324. Mention you’re working on a PI renewal and we’ll structure the conversation around the questionnaire rather than running through a generic discovery.

Frequently asked questions

What does Lawcover require for cyber controls at renewal?

We don’t speak for any specific insurer’s underwriting position and you should confirm directly with your broker. What we observe across questionnaires from insurers active in the Australian legal market — including Lawcover-placed risks, LMI, and London-market boutique syndicates — is convergence on the Essential Eight control set, EDR rather than signature AV, immutable backups, documented IR plans, and security awareness training records. Specific wording and thresholds vary; the underlying expectations don’t.

Our PI insurer wants “evidence of MFA”. What does that mean in practice?

They want a report, not a statement. For Microsoft 365 environments that’s typically the Authentication Methods Activity report or a conditional access policy export from Entra ID showing the policy, its assignment to all users, and sign-in logs proving MFA fires on every sign-in. For other identity platforms the equivalent applies. A screenshot of the MFA setup page isn’t evidence; a sign-in log is.

Do we need a separate incident response retainer if we already have a managed service provider?

Most renewal questionnaires ask the question in a way that expects yes. The MSP handles operational response — isolating endpoints, restoring from backup, locking down accounts. A DFIR retainer adds forensics under legal privilege, breach notification advice, and the chain-of-custody work that holds up in a regulator investigation or insurance claim dispute. The two are complementary. For smaller firms we sometimes structure this through the MSP’s partnerships rather than a direct DFIR retainer, which is generally acceptable to underwriters if the arrangement is documented.

How long does it take to get evidence-ready for a renewal?

For a firm starting from “we have antivirus and basic backups”, expect six to twelve weeks to reach evidence-ready, depending on the existing environment. The technical implementations can happen quickly — MFA rollout in two weeks, EDR deployment in a week, backup re-architecture in three to four weeks. The documentation and policy work is what extends the timeline. Most firms underestimate the policy side and overestimate the technical side.

If we fail the questionnaire, will we lose cover?

Outright declinature is rare; what happens more often is higher premium, lower limits, ransomware sub-limits, or specific exclusions written into the policy. Some insurers in the Australian legal market will offer cover conditionally — with a remediation deadline and a follow-up assessment in six months. The worst outcome we see isn’t refusal; it’s a policy that pays out at claim time only to the extent the firm can prove it met the controls it said it had at renewal. Failure-to-disclose claims are a recurring source of disputes.

We’re a five-partner firm with one practice manager and no IT staff. Is this all proportionate?

The control set scales down well. MFA is free with your Microsoft licensing. EDR for ten endpoints is around $600-1200 a year. Immutable backup for a small firm is a few thousand. The documentation is shorter because the environment is simpler. The premium savings are proportional too — small firms see absolute premium reductions that more than cover the spend. The trap small firms fall into is assuming size buys them out of the questionnaire. It doesn’t.

Accounting firms in Melbourne hold a richer concentration of attack-worthy data than most law firms or medical practices: TFNs, bank details, payroll files, BAS lodgement credentials, trust account balances, and SMSF records. The real threats are business email compromise during EOFY, ransomware on practice management servers, and departing staff exporting client lists. None of these are theoretical.

This is a security-focused post. If you want the broader operational picture, see our guide on IT support for Melbourne accounting firms. Here we’re staying in the security lane: the controls that actually matter, the regulators that actually audit, and the insurers that actually pay out.

What accounting firm data security actually means in 2026

The phrase gets thrown around loosely. For a Melbourne accounting firm with 5 to 50 staff, accounting firm data security is the set of technical and procedural controls that protect three asset categories: client financial records (tax returns, BAS, financial statements), authentication credentials to lodgement and banking platforms (myGovID, ATO Online Services for Agents, Xero, MYOB, bank portals), and trust account ledger data where applicable.

Three regulators care about how you handle this. The OAIC enforces the Privacy Act and the Australian Privacy Principles (APPs), with mandatory data breach notification under the Notifiable Data Breaches scheme. The Tax Practitioners Board (TPB) sets the Code of Professional Conduct, which includes obligations around confidentiality, conflict management, and reasonable care of client records. The ATO sets technical requirements for Online Services for Agents access, including a hard MFA requirement and operational security controls. If you handle SMSF audits or AFSL-adjacent work, ASIC and APRA obligations layer on top. AML/CTF accountants (tax agents providing designated services) sit under AUSTRAC.

The point: data security is not optional and it’s not just “an IT thing”. It’s a partnership-level risk that determines whether the firm keeps its registration, its PI insurance, and its clients.

Trust account protection: separation of duties at the IT level

Where firms hold trust money (commonly auditors, insolvency practitioners, and some tax practitioners with statutory deposits), the IT controls around the trust account need to mirror the financial controls. This is where most firms slip up. The bookkeeper has the trust account password saved in their browser, the principal “needs” override access, and there’s no audit trail when transfers happen out of hours.

What proper IT-level separation of duties looks like:

• Dedicated identities for trust account access. Not a shared “office@” login. Each authorised person has their own credential.
• Hardware-backed MFA on those identities. SMS codes are not sufficient for trust account roles. We deploy authenticator apps or FIDO2 keys.
• Conditional access policies that restrict trust account portals to managed devices on Australian IP ranges. Travelling staff get a documented exception process, not a permanent bypass.
• Privileged Access Management (PAM) so that the principal’s elevated access requires a second approver and is logged. This is an Essential Eight maturity-level-two control and it stops the most common trust account fraud vector: a single compromised principal account.
• Immutable audit logging retained for seven years to align with TPB record-keeping requirements. Logs sitting on the same server as the data are not audit logs; they’re evidence the attacker will delete.

A Hawthorn accounting firm we onboarded last financial year had a single Office 365 account being used by three partners for trust correspondence. There was no MFA on it because “the partners share the phone code anyway”. Within two months of remediation we’d split it into three identities, deployed conditional access, and pushed audit logs into a separate tenant. Three weeks after that, one of the partner accounts had a credential-stuffing attempt from Eastern Europe. It was blocked at the conditional access policy and we had the full sign-in log to give to their cyber insurer.

Client data classification: not all client data is equal

One of the most useful exercises we run with new accounting firm clients is a data classification workshop. Most firms treat everything the same, which means either everything gets expensive top-tier protection (wasteful), or sensitive data gets the same controls as the office lunch roster (negligent).

A workable three-tier model:

Once classification is in place, the security tooling actually has something to enforce. Microsoft Purview Information Protection (or equivalent) can auto-label documents containing TFNs as Tier 1 and block them from being emailed to external addresses. Without classification, DLP rules are guesswork.

Business Email Compromise: the EOFY scenario

BEC is the dominant fraud threat against Melbourne accounting firms. Not ransomware. Not data theft for sale. Plain old “trick the bookkeeper into changing the bank account number on a supplier payment” fraud, weaponised around tax time when everyone is busy and inboxes are flooded.

The classic EOFY scenario: it’s late June, a senior accountant is finalising a client’s return. An email lands purporting to be from the client, sent from a lookalike domain (the legitimate domain is client-co.com.au, the fake is clientco-com.au). The email says “we’ve changed our bank for the refund — here’s the new account”. The accountant updates the ATO refund nomination. The refund — sometimes $40,000, sometimes $400,000 — lands in the fraudster’s account.

The other variant: the firm itself gets compromised. An attacker phishes a junior accountant, sits in their inbox for two weeks reading client conversations, then sends invoices for “outstanding fees” to clients from the legitimate firm address with the firm’s logo and the partner’s email signature. Clients pay. By the time anyone notices, the money is gone and the firm’s reputation is on the line.

Controls that actually stop this:

• DMARC at policy p=reject. Stops your domain being spoofed. Most accounting firms we audit are still on p=none or have no DMARC record at all.
• External email banners with prominent visual warning. Cheap. Works.
• Mailbox audit logging turned on. Default in newer M365 tenants but not always enabled in older ones. Without it you cannot determine breach scope when the OAIC asks.
• Inbox rule monitoring. Attackers create rules to auto-delete or forward security alerts. Alerting on new rule creation catches this within minutes.
• Out-of-band verification for any bank account change. Written policy: bank detail changes require a phone call to a known number, never the number in the email.
• Impossible-travel and risky-sign-in detection. If a Hawthorn-based accountant signs in from Lagos at 3am, the session should be blocked, not just flagged.

For a deeper look at our broader posture, see our cybersecurity services for Melbourne businesses.

Xero, MYOB and QuickBooks integration security

Accounting software is the single most concentrated point of value in the firm. A compromised Xero Practice Manager session gives an attacker access to potentially hundreds of client files, bank feed credentials, and payroll data. Most firms underprotect this.

Two specific issues we see constantly: third-party app sprawl in Xero (every tool a previous staffer integrated still has API access years later), and ATO RAM permissions never being revoked when staff leave. The RAM one is particularly dangerous because a former employee with active RAM authorisation can still lodge BAS or update bank details on behalf of the firm’s clients.

Secure document portals for engagement letters and signed financials

Emailing signed engagement letters and PDF financial statements is still the default at most Melbourne firms. It shouldn’t be. The risks: email-in-transit interception is rare but possible; mailboxes are persistent attack targets, so signed docs sitting in Sent Items for years are loot for any future breach; and there’s no audit trail of who actually opened the document.

A proper secure portal (FuseDocs, Suralink, FYI Docs, Annature for signing, or Microsoft SharePoint with sensitivity labels) provides:

• Encrypted upload and download with per-client access control
• Audit trail showing who opened what and when
• Document expiry — links don’t live forever
• MFA on client access (not always implemented by default, ask)
• Watermarking for sensitive financial statements

The compliance angle: if a client engagement letter is breached via your unsecured email channel, the OAIC will ask why you didn’t use available technical controls. “It’s how we’ve always done it” is not a defensible answer under APP 11.

Backup strategy: 3-2-1-1-0 for accounting data

Backup for accounting firms isn’t about RTO bragging rights. It’s about whether you can restore a client’s 2024 working papers when the ATO audits them in 2028, and whether you can do that after a ransomware event without paying. We won’t repeat the whole rule here — read our detailed breakdown in why the 3-2-1 backup rule is not enough in 2026.

What’s specific to accounting firms:

• Practice management database backups need to capture the full database, not just user documents. APS, CCH iFirm, Xero Practice Manager (where applicable), HandiSoft — each has its own backup procedure and most need scheduled exports beyond what the vendor provides by default.
• Workpaper retention beyond active client period. A client who leaves in 2026 still needs their 2024–25 records retained until at least 2030 for ATO purposes. That data must be on backup, not just on the departed-clients folder of a single fileserver.
• Immutable backups — the “1” in 3-2-1-1-0. Ransomware variants in 2025 routinely targeted backup repositories first. Immutability prevents the attacker from deleting your last lifeline.
• Tested restores — the “0” errors. We test client restores quarterly for accounting clients. The number of firms that discover their backups have been silently failing for six months is depressing.

For backup and recovery specifically, see our data backup and recovery service page.

Insider threat: departing staff with client data

This is the one nobody wants to talk about. The single most common data loss event at an accounting firm isn’t a hacker — it’s an accountant taking client contact details, working papers, or template documents on their way out the door, often to a competing firm or to set up their own practice.

The controls:

• USB and removable media controls via endpoint policy. Disabled by default, with documented exception process.
• Cloud egress controls — blocking personal OneDrive, Dropbox, Google Drive sign-in from work devices. Microsoft Defender for Cloud Apps does this well.
• Email auto-forwarding rules disabled at tenant level and alerted on creation.
• Print logging — yes, this still matters. Accountants print client lists.
• Formal offboarding checklist — credentials revoked same day, RAM permissions removed, Xero access removed, mobile devices wiped, signed declaration that no firm data is retained.
• UEBA (User and Entity Behaviour Analytics) — detecting unusual download volumes by users in their final two weeks. We’ve caught two departing senior accountants this way in the past 18 months.

Essential Eight non-negotiables for accounting firms

The Essential Eight is the ASD/ACSC’s mitigation strategy framework. For accounting firms, we treat Maturity Level One as table stakes and push toward Maturity Level Two for firms with trust account or SMSF audit exposure. Full breakdown on our Essential Eight compliance page.

You can self-assess to Maturity Level One in a workshop. Maturity Level Two requires technical configuration that most firms don’t have in-house. We help firms close the gap as part of our security and compliance service.

Cyber insurance requirements: what your insurer actually checks

Cyber insurance renewal questionnaires in 2026 are not the box-ticking exercise they were in 2021. Insurers now require evidence — not attestation — for the controls that drive their loss ratios. If you sign the questionnaire claiming you have MFA on all admin accounts and you don’t, you’ve given the insurer grounds to decline the claim. We’ve seen it happen.

What every Australian cyber insurance application we’ve seen in the last 12 months requires:

• MFA evidence — screenshots of MFA enforcement policy, list of accounts covered, exception register
• EDR/endpoint security — name of product, coverage percentage, last quarterly review
• Backup proof — last successful restore test date, immutability configuration, offsite copy verification
• Email security — DMARC policy state, anti-phishing platform, user training cadence
• Privileged access — separation of admin accounts, no shared credentials, just-in-time elevation
• Incident response — documented IR plan, named IR provider on retainer, tabletop exercise within last 12 months
• Vulnerability management — patch cadence, vulnerability scanning evidence

Firms that can’t demonstrate these are either declined or quoted with sub-limits that make the policy near-useless for ransomware (e.g., $50,000 sub-limit on a $5m policy). For accounting firms that means ransomware recovery comes out of partnership cash.

How TechAssist works with Melbourne accounting firms

We’re a Melbourne MSP with 13 Australian-employed engineers, a 24/7 NOC, sub-15-minute response on critical-severity tickets, and Essential Eight-aligned standard builds. We’re ISO 27001 capable, which matters when your professional indemnity insurer or your largest audit clients ask about your supply chain. We work with accounting practices from Hawthorn, Camberwell, Box Hill, South Yarra and across metro Melbourne.

For accounting firms specifically, our standard onboarding includes a security baseline assessment against Essential Eight, MFA rollout across every business-critical system (not just M365), backup architecture review against the 3-2-1-1-0 standard, and a documented cyber insurance evidence pack so renewal is straightforward rather than terrifying.

FAQ

Do we need ISO 27001 certification as an accounting firm?

Almost certainly not — and the cost of full certification (typically $40,000 to $80,000 over two years for a firm your size) is rarely justified unless you’re servicing ASX-listed audit clients or government work that mandates it. What you do need is the substance of an Information Security Management System: documented policies, risk register, access reviews, incident response plan, supplier risk assessments. We deliver that without the certification overhead for most accounting clients. If a tender or major client actually requires ISO 27001, we’ll get you there; otherwise, the Essential Eight at Maturity Level Two delivers more practical security per dollar.

Is MFA enough?

No. MFA is necessary, not sufficient. MFA stops the majority of credential-based attacks but does nothing about endpoint compromise, malicious insider activity, phishing-resistant attacker-in-the-middle attacks (which bypass non-phishing-resistant MFA), or ransomware delivered via supply chain. Treat MFA as the foundation and build EDR, application control, backup immutability, and email authentication (DMARC) on top. For high-risk roles like principals and trust account signatories, move to phishing-resistant MFA — FIDO2 hardware keys or platform passkeys.

What does our cyber insurer actually require?

Each insurer differs, but the consistent minimum is: MFA on all remote access and admin accounts, EDR (not just AV) on all endpoints, immutable or air-gapped backups with documented restore tests, DMARC and email filtering, a written incident response plan, and security awareness training at least annually. The insurer will ask for evidence at renewal and after any claim. Firms that produced evidence pre-incident settled claims significantly faster than firms that scrambled to assemble it post-incident — and several firms in the past two years had claims declined because their stated controls didn’t match reality.

How long should we retain client data after the engagement ends?

The minimum is generally five years from the date the relevant transaction or act was completed, per ATO record-keeping rules, but TPB obligations and Limitations of Actions Act considerations often push this to seven years. For SMSF and audit work, retention can be longer. The IT implication is that “departed client” data still needs to be on protected, backed-up storage — not a USB drive in the partner’s bottom drawer.

What’s the single biggest security gap you see at Melbourne accounting firms?

Shared logins. A senior partner’s M365 credentials shared with two other staff “for convenience”. Trust account portal credentials in a shared password manager folder. ATO Online Services accessed via a colleague’s myGovID because their own setup is “still being sorted”. This is the gap that causes the most regulatory pain when a breach occurs, because you cannot prove who did what. Individual identities with MFA, full audit logging, and a real offboarding process fixes it.

Next steps

If you’re a partner or principal at a Melbourne accounting firm and you want a frank assessment of where your security sits against Essential Eight, TPB expectations, and current cyber insurance requirements, get in touch via our contact page. The first conversation is a security posture review — no obligation, no sales pitch dressed as a free audit. We tell you what’s actually exposed and what to fix first.