AI Acceptable Use Policy for Melbourne SMEs: What to Include and How to Roll It Out

An AI acceptable use policy tells your staff which AI tools they can use, what they can paste in, and what happens when somebody pastes the wrong thing. For a Melbourne SME it is now a baseline governance document, sitting next to your password policy and breach response plan. Write it before something goes wrong.

We have spent the last eighteen months helping clients across construction, accounting, law, and healthcare write and roll these out. The pattern is consistent: people are already using ChatGPT and Copilot on company data, leadership has no visibility, and nobody can articulate the rules because there are no rules. This post is the practical guide to fixing that.

Why every Melbourne SME needs an AI acceptable use policy by 2026

The regulatory ground has shifted under Australian businesses in the last twelve months. The Privacy and Other Legislation Amendment Act 2024 introduced a statutory tort for serious invasions of privacy, expanded the Australian Information Commissioner’s enforcement powers, and brought in tiered civil penalties. The reforms are being rolled out in tranches through 2025 and 2026, and the OAIC has explicitly signalled AI-related privacy practices as a focus area.

The OAIC’s guidance on generative AI, published in October 2024, is unambiguous on three points. Personal information entered as a prompt triggers Australian Privacy Principle obligations. Organisations should not enter personal or sensitive information into publicly available generative AI tools by default. Organisations need policies and staff training, not just technical controls. If your business hits the $3 million annual turnover threshold and you do not have a documented position on AI tool usage, you are exposed.

Then there is the insurance side, which is the conversation that usually focuses minds. Most professional indemnity and cyber insurers renewing policies in 2025 and 2026 are asking specific questions about AI usage and whether the insured has an acceptable use policy in place. Answering “no” is not yet a coverage exclusion, but it is increasingly a premium loading factor and, in the event of a claim involving AI-assisted error, a question your broker would rather not have to answer for you.

A Hawthorn accounting firm we onboarded earlier this year discovered, during the initial security review, that two of their senior accountants had been pasting client trial balances into ChatGPT to draft management reports. The data was technically anonymised, but client revenue figures, GST positions, and director loan accounts were sitting in OpenAI’s training-eligible consumer tier. There was no malice and no policy. The partners had not realised what their staff were doing because nobody had told the staff what they could or could not do. The remediation took a fortnight. The conversation with their PI insurer took considerably longer.

What an AI acceptable use policy should actually contain

A workable AI AUP for a Melbourne SME runs to about eight to twelve pages. Anything shorter is a marketing document; anything longer will not be read. We structure ours around nine sections, and the framing matters — the document should read as a set of practical rules with reasons attached, not as a legal artefact that requires a lawyer to interpret.

Sample wording: Acceptable uses

This is the section that tells staff what AI is for. Get this right and the rest of the policy reads as enabling rather than restrictive. Sample wording:

Staff are encouraged to use approved AI tools to: draft and refine internal communications; summarise long documents that the staff member has the right to access; generate first-draft code, scripts, and spreadsheet formulas; brainstorm options and structure arguments; translate text where no client-confidential content is involved; transcribe and summarise meetings where all participants have consented and the meeting platform’s AI features have been approved. The expectation is that AI accelerates work; the staff member remains accountable for the output.

Sample wording: Prohibited inputs

This is the section that does the heaviest lifting. Be specific. Vague prohibitions (“do not enter sensitive data”) are unenforceable because nobody agrees on what sensitive means. Sample wording:

The following must never be entered into any AI tool, regardless of tier, unless the tool is explicitly listed as approved for that data type in the tools register: full names combined with any other identifier of clients, patients, students, or staff; financial account numbers, credit card numbers, or tax file numbers; health information of any kind; legal advice received from the firm’s solicitors; commercially sensitive information about live tenders, M&A activity, or unannounced pricing changes; passwords, API keys, certificates, or any other authentication material; source code that the company does not own or that is covered by a non-disclosure agreement; CCTV footage, voice recordings, or biometric data.

Sample wording: Data handling for client information

This is where most policies fall over because the authors try to write a single rule that covers all client data. It does not work. The cleaner approach is to define tiers and map tools to tiers. Sample wording:

Client information is classified into three tiers. Tier 1 is publicly available information about the client (their published address, their listed directors, their ABN); this may be used with any approved AI tool. Tier 2 is non-public but non-sensitive client information (meeting notes, project plans, draft scopes of work); this may only be used with AI tools running in the company’s Microsoft 365 tenancy or other approved enterprise tenancies, and only where the client engagement letter does not prohibit it. Tier 3 is confidential or regulated client information (financial records, legal matters, health records, personally identifying details of the client’s customers or staff); this must not be entered into any AI tool without written authorisation from the engagement partner and, where required, the client.

Tool-by-tool guidance: where the data actually goes

The single most useful section of an AI AUP, in our experience, is the per-tool guidance. Staff do not care about abstractions; they care about whether they can use the specific tool that is open on their screen. The honest answer for each major tool depends on which tier you are on, and most staff have no idea what tier their employer is paying for.

ChatGPT

The free and ChatGPT Plus consumer tiers train on user inputs by default unless the user opts out, and they sit outside any contractual arrangement your business has with OpenAI. These tiers should be in the prohibited column for anything beyond Tier 1 client information. ChatGPT Team and ChatGPT Enterprise do not train on business data and offer SAML SSO, audit logs, and data residency commitments. If your business has a Team or Enterprise subscription, ChatGPT can be used for Tier 1 and Tier 2 client data. The policy should state which tier the business holds and forbid use of personal ChatGPT accounts for work purposes.

Microsoft Copilot

This is where most policies get muddled because Microsoft uses the word “Copilot” for at least four different products. Microsoft 365 Copilot, included as a per-user licence on top of a Business Standard or Premium subscription, runs against your Microsoft 365 tenancy, respects your existing SharePoint and OneDrive permissions, and does not train on your data. It is generally safe for Tier 1 and Tier 2 data, with the important caveat that Copilot will surface anything a user has permission to access — so an oversharing problem in SharePoint becomes a Copilot problem the day you turn it on. Copilot Chat (the free tier formerly known as Bing Chat Enterprise) offers commercial data protection but does not access tenancy data. GitHub Copilot is a separate product with its own data handling. Copilot in Windows is a Bing-backed consumer experience and should be treated like consumer ChatGPT.

Claude

Anthropic’s consumer Claude.ai free and Pro tiers do not train on user conversations by default, which puts Claude in a better starting position than consumer ChatGPT, but the consumer terms still apply and the data sits outside any business agreement. Claude for Work (Team and Enterprise) provides the contractual framework, SSO, and admin controls that make it viable for Tier 2 client data. Claude is also available via Amazon Bedrock and Google Cloud, which is the route most regulated Australian businesses take because it keeps data within a known cloud tenancy.

Gemini

Gemini in a personal Google account trains on user data and should be treated as prohibited for anything beyond Tier 1. Gemini for Google Workspace, included with Business and Enterprise Workspace plans, does not train on customer data and respects Workspace permissions in the same way Microsoft 365 Copilot respects SharePoint permissions. Gemini in Google AI Studio with a paid API key has its own data handling terms that need to be read separately. The policy should be explicit that the consumer Gemini at gemini.google.com is a different product from Gemini inside Gmail and Docs at a business domain.

Industry-specific clauses you will need

The base policy works for most professional services businesses. Specific industries need extra clauses, and we add these as numbered addenda rather than rewriting the body of the policy.

Law firms

Solicitors have legal professional privilege obligations that are not negotiable. The addendum should prohibit entering any communication with a client, any document prepared in contemplation of litigation, and any matter file content into any AI tool that is not covered by an enterprise agreement with explicit confidentiality provisions. It should require that any AI-assisted drafting is reviewed by the responsible practitioner before it leaves the firm, and that any use of AI in advice given to the client is disclosed in accordance with the firm’s cost agreement. The Victorian Legal Services Board has not yet mandated AI disclosure, but it has signalled that practitioners remain wholly responsible for AI-assisted work, and firms should not wait for prescriptive guidance before tightening their own rules.

Accountants and bookkeepers

The APES 110 Code of Ethics covers confidentiality of client information without any AI-specific carve-out, which means client financial data going into a consumer AI tool is a Code breach regardless of intent. The addendum should prohibit entering client financial records, BAS data, payroll data, or trust account information into any tool not in the approved enterprise tier. It should also address the AI-generated advice question directly: AI output that materially informs advice given to a client must be reviewed and signed off by a qualified accountant, and the firm’s engagement letters should be updated to disclose the use of AI tools in the engagement.

Healthcare providers

Health information is sensitive information under the Privacy Act and attracts stricter handling. The addendum should prohibit entering any patient-identifying information, clinical notes, imaging, pathology, or Medicare numbers into any AI tool that is not specifically approved for health data — which, in practice, means almost none of the consumer or general-business AI tools qualify. Practices using AI scribing tools (Heidi, Lyrebird, and similar) need to verify the vendor’s data residency, ensure the tool has been assessed against the practice’s privacy obligations, and obtain patient consent in line with RACGP guidance.

How to roll it out without it becoming shelfware

Writing the policy is the easy part. The hard part is getting it adopted, and the failure mode we see most often is a policy that gets emailed to all staff once, signed in a hurry, and never referenced again. The rollout that actually works follows a sequence.

Stakeholder sign-off comes first, and it should involve more people than you think. The owner or managing director signs as the policy sponsor. The person responsible for IT — whether that is an internal IT manager or your managed service provider — signs as the technical owner. Heads of regulated practice areas sign because they will be enforcing the industry addenda. HR signs because policy breaches feed into the disciplinary process. Send a copy to your external auditor or PI broker before publication, because their later approval is much easier than their retrospective objection.

The training session is non-negotiable. A thirty-minute, in-person or video, all-staff session works better than any e-learning module. The session should cover the three or four scenarios staff will actually encounter — drafting an email, summarising a meeting, writing a report — and walk through what is and is not allowed in each. The session should be recorded for new starters and run again, in a different month, for staff who missed it. Sign-on after the training, not before.

Monitoring is where most SMEs hand-wave, and it is also where insurers are increasingly looking. Microsoft 365 and Google Workspace both expose audit logs that show Copilot and Gemini usage, and Defender for Cloud Apps (or its equivalent) can detect personal AI tool usage on managed devices. Endpoint DLP can flag attempts to paste large blocks of text into browser tabs. None of these are perfect; all of them are better than nothing. A quarterly review of the approved tools register, with input from team leaders on what their staff are actually using, catches the drift that always happens between policy and practice.

Breach consequences should be proportionate and documented. We recommend a three-tier framing: a first-time minor breach (using a non-approved tool for low-sensitivity work) results in a refresher conversation and a documented note. A repeat or moderate breach (entering Tier 2 data into a consumer tool, or ignoring the approved tools register after training) results in a formal warning and remedial training. A serious breach (entering Tier 3 data, or any breach involving client personal information) triggers the data breach response process, an incident review, and the disciplinary procedures set out in the staff handbook. The point of writing this down is so the response to a breach is predictable rather than political.

Aligning the policy with broader security frameworks is the step most SMEs skip and most insurers are starting to ask about. Our policies are Essential Eight aligned because that is the baseline the Australian Cyber Security Centre expects of Australian SMEs, and because the application control and user application hardening strategies map directly to the question of which AI tools staff can run. For clients pursuing ISO 27001 certification, the AI AUP slots into the Annex A control set under information security policies and acceptable use. For clients moving toward zero trust, the per-tool tenancy rules in the AI AUP are an expression of the same conditional access principle.

A worked example: rolling out the policy at a Box Hill professional services firm

A forty-seat professional services firm in Box Hill — a mix of consulting and accounting work — engaged us last spring to write and roll out their AI AUP. The starting position was familiar: the principals knew staff were using ChatGPT, had no idea what data was going into it, and had just received a renewal questionnaire from their PI insurer with an AI governance section.

Week one was discovery. We ran a short survey, anonymous, asking staff which AI tools they used at work and for what tasks. Eighty per cent of staff used ChatGPT; about half used the personal Plus tier; one team had standardised on Claude. Nobody used Copilot, despite the firm holding Microsoft 365 Business Premium licences that included Copilot Chat. The discovery surfaced two specific risks: confidential client correspondence being summarised in consumer ChatGPT, and the firm’s internal financial reports being pasted into Claude for variance commentary.

Week two was the policy draft. We started from our template, customised the tools register for the firm’s environment (Microsoft 365, Xero, a practice management system), and added the accounting industry addendum. A working session with the principals and practice manager surfaced three changes: a carve-out for AI use in business development, a stricter rule on AI-generated client deliverables, and a thirty-day transition clause to move off personal AI accounts.

Week three was the rollout. A forty-five minute all-staff session walked through the policy with three worked scenarios. Microsoft 365 Copilot was enabled for a pilot group, and the firm subscribed to ChatGPT Team for the consultants who needed it. Signed acknowledgements were collected through the firm’s HR system.

The first quarterly review, ninety days in, found that two staff had requested additional tools (one approved, one not), one minor breach had occurred and been handled through a refresher conversation, and Copilot adoption had reached seventy per cent of licensed users. The renewal questionnaire was answered honestly, and the broker confirmed the policy met the insurer’s expectations. The principals would tell you the value was less in the document itself and more in the conversation the rollout forced — shadow IT became part of the supported environment, and they got visibility into how the firm was actually working.

What to do this week if you do not have a policy yet

If your business is in the Melbourne CBD, Camberwell, Dandenong, Richmond, or anywhere else in greater Melbourne, and you do not have an AI acceptable use policy, the practical next steps are straightforward. Run an anonymous staff survey to find out what AI tools are actually being used. Audit your existing Microsoft 365 or Google Workspace licences to find out what AI features you are already paying for. Identify the three to five regulated obligations specific to your industry (privacy, professional standards, sector-specific rules) that the policy needs to address. Draft the policy or have it drafted, run a training session, and put a quarterly review in your calendar.

TechAssist has been doing this work for Melbourne SMEs since we started the firm in 2014. We run a thirteen-engineer team out of our offices in Tecoma and the Melbourne CBD at 575 Bourke Street, with our 24/7 network operations centre in Tecoma. Our cybersecurity services include AI governance work as a defined engagement, and our broader managed IT services sit underneath it for clients who want the policy enforcement to be technically backed by their managed environment. We work with construction firms, law practices, accounting partnerships, healthcare clinics, schools, manufacturers, and logistics businesses across Melbourne, and the AI AUP looks different in each of those industries — which is part of the work.

If you want a starting point, the Privacy Act guidance for Australian SMBs is a useful companion read because the AI AUP sits on top of the Privacy Act compliance posture. If you have an internal IT lead and want help on the governance side without handing over the day-to-day, our co-managed IT support arrangement is the right shape. If you want a conversation about where to start, get in touch and we will book a thirty-minute call with one of our senior engineers.

Frequently Asked Questions

Is an AI acceptable use policy legally required in Australia?

There is no specific Australian law that mandates an AI AUP by name. However, the Privacy Act, the OAIC’s generative AI guidance, professional standards in regulated industries (legal, accounting, medical), and increasingly the terms of professional indemnity and cyber insurance policies all create a practical requirement. If you handle personal information and you do not have a documented position on AI tool usage, you are exposed under the existing legal framework.

How long should an AI acceptable use policy be?

Eight to twelve pages is the sweet spot for an SME. Shorter than that and you cannot cover the per-tool guidance and industry addenda that make the policy useful. Longer than that and staff stop reading. The approved tools register and industry addenda are the sections that should grow over time; the body of the policy should stay stable.

Can we just use a generic AI AUP template from the internet?

You can start with one, but you will need to do real customisation work. Generic templates do not know which AI licences you actually hold, which industry you are in, what your data classification scheme looks like, or how your disciplinary process works. The cost of poor customisation is a policy that does not match your environment, which makes enforcement impossible and gives staff a reason to ignore it.

How often should the policy be reviewed?

The body of the policy should be reviewed annually. The approved tools register should be reviewed quarterly, because the AI tool landscape moves fast enough that a six-month-old tools register is already out of date. We bake the quarterly review into our managed services engagements so it does not get forgotten.

What if a staff member breaches the policy?

The policy itself should set out a tiered response: a documented conversation and refresher training for a first-time minor breach, a formal warning for a repeat or moderate breach, and the data breach response process plus disciplinary procedures for a serious breach involving client or personal information. The point is to make the response predictable and proportionate, so that the first breach does not become a political event.

Does the policy cover AI features built into tools we already use?

It should. AI features built into Microsoft 365, Google Workspace, Adobe products, Zoom, Teams, Atlassian tools, and any other SaaS your business uses are all in scope. The approved tools register should list them explicitly, including which features are enabled and which are turned off at the tenancy level. The default position should be that an AI feature is prohibited until it has been assessed and added to the register.

Should we tell our clients we use AI in our work?

For most professional services engagements, yes. The cleanest approach is to update your engagement letters with a short clause disclosing that the firm uses approved AI tools to assist with work, that human review remains with the qualified practitioner, and that no client confidential information is entered into any AI tool that does not meet the firm’s data handling standards. Several professional standards bodies are moving toward this disclosure as an expectation, and it is easier to lead than to be caught out.

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.