IT Support for Insurance Brokers

Insurance brokers hold client money, financial records and personal data, and operate under an AFSL with real ASIC obligations. Good insurance broker IT support keeps your broking platform running, protects the trust account from email fraud, and gets the security controls in place that your own cyber insurer now expects.

General insurance brokers sit in an awkward spot. You are a small business by headcount but you carry the data risk of a financial institution and the payment-fraud exposure of a conveyancer. You handle premium funds in trust, you hold years of client financial and personal information, and you answer to ASIC for how the business is run. The IT underneath all of that is usually a couple of cloud platforms, Microsoft 365 and whatever the last broker set up. That gap is where the trouble starts.

What general insurance brokers actually run

Most Australian broking offices run on a dedicated broking platform rather than a generic CRM. The common ones are WinBEAT, Sunrise (and the SCTP transaction platform behind it), Insight, and the broader ebix stack that several of these sit within. These handle policy administration, quoting, the insurer transaction interface, client records, claims and the all-important trust-account and premium-funding reconciliation.

Some platforms are cloud-hosted; others still run as on-premises or hybrid installs with a database server in the office. Either way, the vendor secures the application, but you own the devices, the accounts, the network, the integrations and the backup of everything outside the platform. The recurring weak spots we find in broking offices: shared logins on reception machines, no multi-factor authentication on Microsoft 365, the broking database backed up to a USB drive that has not been tested in two years, and bank details for premium payments sitting in email threads anyone can read.

Cluster and network group requirements

Most independent brokers belong to a cluster or network group — Steadfast, AUB, Insurance Advisernet and similar. Membership is not just buying power; it increasingly comes with technology and security expectations. Network groups push standardised platforms, single sign-on into their portals, data feeds back to head office, and in some cases minimum cyber-security requirements you have to attest to. If you join or change groups, the IT migration — platform data, mailbox records, document history — needs to be planned, not improvised over a weekend. We treat that as a project with a rollback plan, because losing seven years of client correspondence mid-migration is not recoverable.

AFSL, ASIC and the obligations behind the IT

Holding an Australian Financial Services Licence (AFSL) brings general conduct obligations under the Corporations Act, and ASIC expects licensees to have adequate technological resources and risk-management systems. That is deliberately broad, but the practical reading is clear: you need systems that keep accurate records, protect client data, and let the business keep operating when something fails. ASIC’s own guidance on cyber resilience and outsourcing makes the point that you cannot contract away responsibility — if your IT or your software vendor has a problem, the obligation to your clients is still yours.

Record-keeping is the concrete part most brokers underestimate. You are expected to retain client files, advice records, policy documentation and trust-account records for years, and to be able to produce them. That makes backup and retention a compliance matter, not just an IT nicety. A broking database you cannot restore is a record-keeping failure waiting to be discovered at the worst time.

Client financial and personal data under the Privacy Act

Brokers hold a dense file on every client: names, addresses, dates of birth, financial details, claims history, sometimes health information for certain covers, and bank account details for premium payments. That is exactly the kind of personal and sensitive information the Privacy Act 1988 and the Australian Privacy Principles are built around.

If your business turns over more than $3 million you are squarely covered, and even smaller brokers are caught where they trade in personal information or provide certain services. Under the Notifiable Data Breaches scheme, a breach involving client data that is likely to cause serious harm must be assessed and reported to the Office of the Australian Information Commissioner (OAIC) and the affected clients. A compromised mailbox full of client financial records is precisely the scenario that scheme exists for — and for a broker, it is also a conversation with your AFSL obligations and your network group.

Business email compromise: the threat aimed straight at brokers

Of every risk on this page, this is the one that takes brokers down. Business email compromise (BEC) is where an attacker gets into a mailbox — usually through a phished password with no MFA — watches the email flow, and then redirects money. For a broker, the targets are obvious: premium payments from clients, refunds, and movements in and out of the trust account.

The classic version: a client emails about paying their premium, the attacker (sitting silently in your mailbox or theirs) replies with “updated” bank details, and the money lands in a mule account. By the time anyone notices, it is gone. The variant aimed at the trust account is worse, because the sums are larger and the reconciliation is monthly, so the theft can sit hidden for weeks.

The defences are unglamorous and they work:

• MFA on every mailbox, enforced, with no exceptions for the principal who finds it annoying. Most BEC starts with a password that worked because nothing else was in the way.
• Conditional access in Microsoft 365 to block sign-ins from unexpected countries and flag impossible-travel logins.
• A verbal verification rule for any change to payment details — phone the client on a known number, never the number in the email. This is policy, not technology, but it is the single most effective control.
• Email security that catches lookalike domains and external-sender warnings, plus mailbox-rule auditing so an attacker quietly forwarding your mail gets caught.

We go deeper on this in our guide to business email security, phishing and BEC. For a broker handling trust money, it is the first thing to fix.

Cyber insurance underwriting expectations — yes, for brokers too

There is a particular irony in brokers being underprepared for their own cyber-insurance application. The same underwriting questions you help clients answer now land on your desk, and they have hardened considerably. Insurers will not write a policy — or will price it punitively — without evidence of baseline controls.

The questions you can expect:

These map almost exactly onto the Australian Cyber Security Centre (ACSC) Essential Eight. If you implement the meaningful parts of the Essential Eight, you answer most of the underwriting questionnaire honestly and in the affirmative — which both gets you covered and lowers the premium. We cover this overlap for SMEs in our cyber insurance guide for Australian SMEs, and the controls themselves in our Essential Eight compliance work. Answering “yes” to a control you do not actually have is a fast way to have a claim declined, so it pays to make the answers true.

Document management and the renewals workflow

Broking runs on documents — schedules, certificates of currency, closings, endorsements, claims correspondence — and on a renewals cycle that never stops. The renewals workflow is where document management, email and the broking platform all have to work together, and where things fall through when the IT is loose.

A sound setup keeps client documents in the broking platform or a structured SharePoint library, not scattered across personal mailboxes and a Downloads folder. It means a broker who leaves does not take the only copy of a client’s history with them, and a renewal does not get missed because the reminder lived in one person’s inbox. If you run on Microsoft 365, getting Microsoft 365 configured properly — shared mailboxes, sensible SharePoint structure, retention policies — is what turns a pile of email into a system the next person can pick up. It also makes the record-keeping side of your AFSL obligations far easier to satisfy.

A Melbourne example

A general insurance broking firm in Hawthorn we work with — eight staff, member of a national cluster group, running WinBEAT and Microsoft 365 — came to us after a close call. A client emailed about paying a commercial property premium. What none of them knew was that the client’s mailbox had been compromised; the attacker replied from the real address with new bank details. The broker’s accounts person nearly paid it. What stopped her was an old habit of phoning to confirm anything over a few thousand dollars — and the new account did not match.

It rattled them, because the firm had no MFA on Microsoft 365, no conditional access, and a broking database backed up to a single drive plugged into the server. We rolled out MFA across every mailbox, conditional access to block overseas sign-ins, advanced email filtering with external-sender warnings, and proper monitored backups of both Microsoft 365 and the WinBEAT data with an isolated copy. We documented a payment-verification policy so the “phone to confirm” habit became a rule rather than one person’s caution. When their cyber-insurance renewal came round, they could answer the questionnaire truthfully for the first time, and the premium reflected it.

Frequently asked questions

Does the Privacy Act apply to a small insurance broker?

If you turn over more than $3 million a year, yes, directly. Smaller brokers can still be covered depending on what they do with personal information. Given the volume of client financial and personal data a broker holds, and the AFSL and ASIC obligations sitting alongside it, the sensible approach is to operate as though the Australian Privacy Principles apply regardless — the controls are the same ones your cyber insurer and network group already expect.

What is the biggest IT risk for a broking firm?

Business email compromise aimed at premium payments and the trust account. An attacker in a mailbox with no MFA can quietly redirect client money before anyone notices. MFA on every account, conditional access, and a strict phone-to-verify rule for any change of bank details are the controls that stop it.

Will better IT lower our cyber insurance premium?

Usually, yes. Insurers price on the controls you can evidence — MFA, tested backups, email filtering, endpoint protection and patching. Implementing the Essential Eight lets you answer the underwriting questionnaire honestly and in the affirmative, which improves both your ability to get covered and the price.

We’re switching cluster groups — what about the IT?

Treat it as a planned migration, not a weekend job. Platform data, mailbox records, document history and any single sign-on into the group’s portals all need to move cleanly, with a rollback position if something goes wrong. Losing years of client correspondence mid-migration is not recoverable, so it is worth doing methodically.

Getting it right without overspending

None of this is exotic. A broking firm does not need a bank’s security budget — it needs the basics done properly and kept that way: MFA on every account, conditional access, tested and isolated backups of both the broking platform and Microsoft 365, advanced email filtering, and a payment-verification rule that everyone actually follows. TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma. We support professional services firms across Melbourne metro on per-user fixed monthly pricing, with same-business-day on-site when you need hands on the ground. Our IT support for professional services and cybersecurity services are built for exactly this kind of business. If your broking office is running on goodwill and no MFA, get in touch and we will tell you plainly what to fix first.

Most SME IT is unconsciously designed for the median 35 to 45-year-old user. That median user does not exist alone in the modern workplace, where four generations work alongside each other with very different expectations of technology. This is a Sunday read about designing IT that serves all your staff, not just the comfortable middle.

The four-generation reality

Walk into a typical Melbourne SME today and you will find a 22-year-old graduate, a 38-year-old manager, a 52-year-old senior operator, and a 64-year-old founder or long-tenured staff member all working in the same office. They use the same Microsoft 365 tenant, the same Wi-Fi, and the same helpdesk. They have completely different mental models of how technology is supposed to work, and most SME IT environments accidentally privilege one of those mental models over the others.

Since founding TechAssist in 2014, we have onboarded hundreds of SMEs and watched the generational mix shift through every one of them. The pattern in 2026 looks like this:

For a 60-staff Brunswick design agency we manage, the split is roughly 28% Gen Z, 52% Millennial, 16% Gen X, and 4% Boomer (the founder and one long-tenured operations director). For a 90-staff manufacturing business in Bayswater, the same split is 8% Gen Z, 31% Millennial, 44% Gen X, and 17% Boomer. Same Microsoft 365 tenant, completely different IT delivery requirements.

What each generation actually expects

These are generalisations, and individuals vary wildly within every group. They are still useful generalisations because the average matters when you are designing a helpdesk channel mix or a default permission set.

Gen Z

Gen Z grew up with iPads, Discord, TikTok, and friction-free consumer tech. Their reference point for ‘good software’ is whatever app they used last on their phone. Their expectations:

• Chat-first communication; phone calls feel intrusive
• Self-service everything; if there is a form, they will not fill it in
• Search-driven discovery rather than menu navigation
• Zero tolerance for slow interfaces or multi-step authentication friction
• Limited muscle memory for keyboard shortcuts or file system organisation
• Strong assumption that anything they need will be Googleable or YouTube-able

What this means in practice: Gen Z staff bounce off old-fashioned ticket portals, do not read documentation, and will quietly use a personal Notion or a personal ChatGPT account rather than ask IT for help. The risk is shadow IT and data leakage, not refusal to use tools.

Millennial

The bulk of most SME workforces. Grew up with the internet as it commercialised, formed their work habits with email and Slack, and have generally adapted to whatever tech their workplace put in front of them. Their expectations:

• Self-serve when possible, but happy to raise a ticket when needed
• Comfortable with both chat and email; tolerant of phone if the situation calls for it
• Strong adoption of new tools when the value is clear
• Reasonable security hygiene if it has been trained
• Power users of collaboration tools (Teams, SharePoint, project management)

Most SME IT is implicitly designed for this group. They are easy. They are also the group most likely to get over-prioritised because they make up the largest share of the helpdesk inbound.

Gen X

Gen X formed their work habits in the late 1990s and early 2000s, in the transition from paper to digital. They are often the most productive group with established workflows, and they are often the silent shadow IT contributors because they have been carrying habits from old systems forward for two decades. Their expectations:

• Get the job done; do not care about new shiny tools unless they obviously help
• Email-first, with chat as a tolerated overlay
• Strong file system mental model; may struggle with SharePoint’s metadata-first approach
• Quietly use personal Dropbox, Evernote, or other tools they brought with them from a previous job
• Will phone the helpdesk if email is taking too long

The shadow IT pattern in this generation is the biggest hidden risk in most SMEs. It is rarely malicious. It is almost always ‘I have been doing it this way since 2008 and nobody told me to stop’.

Boomer

Often the founder, often a director, often the most experienced person in the room with the strongest informal authority. Their expectations:

• Phone or in-person support, preferably from someone they know by name
• Email as the dominant communication channel
• Reluctance to adopt new tools without strong evidence of value
• Trust-based rather than process-based interaction with IT
• Will phone the helpdesk for a captcha that has stumped them, and will be frustrated if the helpdesk does not pick up immediately

The Boomer cohort is often the smallest by headcount and the largest by IT influence per person. A board member who cannot get into Teams before a meeting will create more helpdesk pressure in five minutes than 20 Millennials in a week.

Helpdesk channel design for a four-generation workplace

The default modern helpdesk is a ticket portal plus a chat channel, optimised for self-service. This works for Gen Z (chat) and Millennials (either) but actively fails Gen X and Boomers, who often prefer phone or walk-up. The solution is not to abandon chat; it is to offer all four channels with deliberate routing.

Running all four channels properly is expensive if you do it yourself with a small internal team. It is one of the practical reasons SMEs move to an MSP arrangement. Our 13 Australian engineers cover all four channels from our 24/7 NOC in Tecoma and our 575 Bourke Street CBD office, with a contractual sub-15-minute P1 response and same-business-day on-site response across Melbourne metro. That coverage model is hard to replicate with internal staff under about 8 IT FTEs, which is well beyond most SMEs.

Training that does not condescend

The single fastest way to lose generational goodwill in IT training is to pitch every session at the lowest common denominator. A 24-year-old Gen Z staff member sitting through ‘how to attach a file to an email’ becomes a future shadow IT user because they have learned that IT is not where help comes from. A 64-year-old Boomer thrown into a fast-paced ‘we will assume you know Slack’ onboarding becomes a future helpdesk regular because they did not catch up.

Tiered training

The model that works in SMEs is tiered training with self-selection. Offer three tiers of every major training session: foundational (assumes no prior knowledge), standard (assumes baseline comfort with the tool category), and advanced (assumes daily use, focuses on power features). Let staff self-select.

Almost everyone correctly self-assesses. The exception is a small subset of Gen X and Boomer staff who under-select out of pride and then struggle. The fix is a gentle 1:1 follow-up two weeks later: “How is the new system going? Is there anything you would like a walkthrough on?”

Avoid the metaphor trap

Training that leans on ‘this is like an old filing cabinet’ or ‘this is like sending a letter’ lands badly with Gen Z, who have never used either. Training that uses TikTok metaphors lands badly with Boomers, who have never used TikTok. The safest training language is concrete and operational: “Click here, then here, this is what happens, this is how to undo it.” Skip the metaphors entirely.

Documentation that respects time

Documentation needs to exist in two forms: searchable short-form (Notion pages, SharePoint articles, KB entries) for Gen Z and Millennials, and printable PDF or single-page reference sheets for Gen X and Boomers who learn by reading offline. The same content, different formats. The cost of producing both is modest. The cost of having only one is a generation that does not engage with documentation.

Default-deny vs default-allow assumptions

Modern security thinking, and the zero trust security model in particular, is default-deny. Nothing works unless it has been explicitly allowed. This is the right approach from a security perspective. It is also the approach that generates the most generational friction.

Gen Z and Millennials, raised on consumer apps that just work, find default-deny baffling: “Why can I not just install this thing? It is free.” Gen X and Boomers, raised on workplaces where IT controlled everything, find default-deny familiar but resent the friction when they are trying to do their actual job.

The path through this is not to compromise on default-deny. It is to invest in the user experience around it.

• Make exception requests easy. A two-click ‘request this app’ button beats a five-field ticket form every time.
• Publish a list of pre-approved tools clearly visible to staff. Most exception requests are for tools that would have been approved if the staff member had known.
• Communicate decisions back. “Your request for Tool X was approved/denied because Y” closes the loop and trains future requests.
• Treat the catalogue of approved tools as living. Add to it monthly. Staff who see the catalogue growing will treat exception requests as legitimate, not as a fight.

This is the practical application layer of application control, which is the hardest Essential Eight strategy to implement well. It is also the area where generational expectations matter most, because Gen Z will go around the control if the friction is too high.

The ‘tech buddy’ pairing model

One of the highest-leverage interventions we have seen in SMEs is the formal tech buddy model. Every new starter is paired with a tenured staff member from a different generation as their day-to-day go-to for small tech questions. The tech buddy is not IT; they are someone who already knows how the business uses the tools.

Why it works

• Reduces helpdesk inbound for small questions (estimated 12-25% reduction in our deployments)
• Creates cross-generational relationships in a way that other onboarding rarely does
• Surfaces shadow IT habits early, before they become entrenched
• Distributes IT literacy across the workforce instead of concentrating it

How to set it up

Pair new Gen Z starters with a Millennial or Gen X buddy who can model how the business actually uses tools. Pair new Boomer or Gen X starters with a Millennial buddy who can explain the modern collaboration patterns. The asymmetry is deliberate. The cross-generational pairing is where the learning happens.

For a Richmond marketing agency we manage, the introduction of the tech buddy model coincided with a 19% reduction in ‘how do I do X’ helpdesk tickets in the following quarter. The remaining tickets were genuinely harder problems that needed an engineer rather than a peer.

Specific design choices that help

Authentication friction

MFA is non-negotiable for any modern SME. The friction of MFA falls most heavily on Boomers, who are most likely to forget to bring their phone, lose their authenticator, or be confused by a passwordless prompt. Mitigations:

• Use Microsoft Authenticator passwordless or Windows Hello for Business as the default, not SMS codes
• Set up FIDO2 security keys (Yubikey) for users who repeatedly struggle with mobile MFA
• Conditional access policies that reduce MFA prompts on managed devices within the trusted network
• A clear and well-staffed account recovery process for the inevitable ‘I have lost my phone’ moment

Communication channels

Do not collapse all internal communication to Slack or Teams chat. The over-collapse of channels privileges Gen Z and disadvantages everyone else. Keep email viable for substantive communication, keep Teams or Slack for quick coordination, and keep phone open for urgent or sensitive conversations. Generational comfort follows the channel.

Device choice

Gen Z and many Millennials prefer Apple hardware for personal use and increasingly for work. Gen X and Boomers are typically Windows-fluent and find macOS unfamiliar. Standardising on Windows for cost and management reasons is the right call for most SMEs (and aligns with our endpoint policy recommendations), but be explicit about it and explain why. Treating Mac requests as unreasonable rather than as a legitimate preference creates a generational rift.

The Boomer founder problem

Worth a section of its own because it is so common in Melbourne SMEs. The founder, often Boomer or older Gen X, has built the business over 20 to 40 years. They use technology pragmatically but have not personally driven a tech refresh in five years. They are often the bottleneck for any decision about new tools, and they often have the strongest informal control over IT spend.

Two failure modes:

1. The ‘just make it work like the old one’ instruction. Migrations and modernisations get blocked because the founder cannot accept that new tools will not exactly replicate the old ones. Solution: explicit acknowledgement that the new tool is different, paired with a clear demonstration of what gets better. Avoid ‘training’ the founder; offer to sit with them for an hour and walk through the actual workflows they use.
2. The ‘I do not need that’ veto. Security investments and modernisations get blocked because the founder personally does not feel the pain. Solution: frame the conversation in terms of business risk rather than personal benefit. The Privacy Act compliance work and the Essential Eight investments protect the business; they are not optional convenience features.

For a Mount Waverley accounting firm we work with, the founder (mid-60s) had been blocking a move from a self-hosted file server to OneDrive and SharePoint for three years. The breakthrough came not from another training session but from a one-hour walk-through where one of our senior engineers sat with him and showed him how his existing daily file workflow would work in the new environment. The migration completed within two months. The block had been about uncertainty, not opposition.

What this means for IT strategy

Designing IT for a multi-generational workplace is not about generational stereotyping. It is about acknowledging that the median user does not exist on their own and that a one-size-fits-all approach excludes more people than it includes. The practical implications:

• Run multiple support channels in parallel and route deliberately
• Invest in documentation in multiple formats
• Treat default-deny security as a UX problem to be solved, not a posture to be defended
• Pair new starters with cross-generational tech buddies
• Resist the temptation to over-collapse communication channels
• Make founder onboarding to new tools a personal walk-through, not a training session

This is the kind of operational design work that sits inside a properly run Melbourne MSP relationship. A good MSP brings the channel mix, the documentation discipline, and the engineering depth to make all of this work. A bad MSP gives you a ticket portal and expects everyone to use it.

If you want to talk through what this looks like for your specific generational mix and business model, get in touch. Every SME is a different blend, and the right IT delivery model depends on the actual blend you have.

Frequently Asked Questions

Are these generational patterns really that consistent?

On the average, yes. On the individual, no. We work with 64-year-old Gen X-borderline staff who out-skill 24-year-old Gen Z staff on technical fluency, and vice versa. The point is not to assume; the point is to design for the variance. If your IT delivery model only works for one generational profile, you are excluding the others.

Should we have generation-specific training tracks?

Skill-specific, yes. Generation-specific, no. Self-selecting tiered training is more dignified and more accurate than tracking people by age. Generation matters as a design input, not as a sorting category.

How do we handle Gen Z staff who refuse to use email?

You will lose this battle if you frame it as compliance. You will win it if you frame it as professional necessity. Most clients, vendors, and regulators still operate on email. Gen Z will use email for those interactions if you explain why and accept that internal communication can happen elsewhere. The compromise is appropriate.

Is the tech buddy model just unpaid IT support?

It is informal peer support, not unpaid IT support. The tech buddy answers small questions (where do I find the project template, how do I share this externally) that would otherwise become helpdesk tickets. They do not troubleshoot hardware failures or security incidents. Make the boundary clear and recognise the buddy’s time in their performance review.

How does multi-generational design intersect with security?

It intersects most heavily in the authentication and access control layers. The same MFA policy that is invisible to a Gen Z user creates daily friction for a Boomer who keeps misplacing their phone. The same default-deny posture that protects the business creates shadow IT pressure in Gen Z. Good security design accounts for both, not just one. This is why our cybersecurity practice spends as much time on user experience as on policy.

What is the single highest-leverage change we could make this quarter?

Introduce or strengthen the tech buddy model for new starters. It is cheap, it builds relationships, and it surfaces shadow IT patterns before they entrench. Most SMEs see meaningful reductions in helpdesk inbound within a quarter, and the cultural benefits outlast the operational ones.

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.