Cyber Action Year 2026: What ASD’s Five Actions Actually Mean in an Accounting Firm

8min read | Practice Management | Cyber Security | Compliance | Access Control

ASD has named five critical actions for Australian organisations this year. Most of the guidance behind them is written for a very different kind of organisation to an accounting, bookkeeping or financial planning practice. This is the translation — what each action means in a firm, which ones can wait, and who actually ends up doing the work.

Why ASD’s list doesn’t feel like it was written for firms operating in the accounting space

On the Cyber Action Year 2026 page, the Australian Signals Directorate lists five critical actions for organisations: replace or mitigate the risks of legacy technologies, implement best practice event logging, choose secure by design products and services, prepare for post-quantum cryptography, and prepare for AI-enabled cyber threats.

Read that list from inside an accounting practice — one running on Xero, Microsoft 365, a practice management system and a handful of connected applications — and at least two of those read as somebody else’s problem. ASD’s guidance covers organisations from critical infrastructure operators down, and the distance between the two ends of that range is enormous.

What the list doesn’t come with is a translation. ASD’s framing for the year is that awareness alone is not enough, and it has deliberately built a year-round program rather than a single campaign month. So it’s worth asking the practical question: what do these five actions actually mean in a practice, which can a firm reasonably set aside, and who does the ones that are left?

Three actions that matter for accounting firms — and two that don’t

Start with the two to set aside. Post-quantum cryptography is an action for organisations that own cryptographic infrastructure; a practice inherits that work from its software providers. Legacy technology, in a firm with no server room, rarely means ageing equipment — it usually means dormant application connections nobody has reviewed. Those are worth a look, and there’s a question for exactly that at the end of this article, but looking is not the same as taking on a project this year.

The other three translate directly

So, who’s supposed to do all this?

That’s the question a list like this always raises in a small firm, and ASD has published something close to an answer.

On 15 October 2026 it published the ASD Essentials, an evolution of the Essential Eight. One chapter in it is written for organisations whose technology runs entirely on software-as-a-service and platform-as-a-service — a fair description of most accounting practices, and the first time ASD guidance has described an environment with no server in it.

The chapter is aimed at larger organisations, and the language reflects that. But one idea in it travels well to a firm of any size. Every recommended action is marked according to who delivers it.

• Provider means the vendor does it and the firm verifies.
• Customer means the firm does it outright.
• And a large number fall into a third category: Supplied, meaning the provider offers the capability, but somebody at the firm has to switch it on, configure it, and keep it running.

That third category is where most practices quietly lose ground, and it’s worth being precise about why. A lot of what a firm needs is already available inside Microsoft 365, the practice management system and the applications it pays for monthly. But supplied is not the same as running. MFA has to be enforced, not merely available. Logging has to be switched on, and someone has to know where to find it. Access has to be removed when a staff member leaves — in every application, not the three anyone remembers.

And each of those capabilities lives inside its own application. Xero has its own controls, Microsoft 365 has its own, the document system has its own. Nothing joins them up. There is no single record of who reached which client file, no single action that removes a departing employee everywhere at once, and no application that produces the documentation a regulator or insurer asks to see. Configuring ten applications individually, then keeping them configured as each one changes, is ten jobs that never finish.

ASD puts the underlying principle plainly: outsourcing a service does not transfer accountability for the outcome that service is meant to achieve. Xero and Microsoft secure their own infrastructure. Your firm owns user access, credentials, permissions, and the evidence that the right people reached the right things.

Who actually runs this inside an accounting firm?

So, the question becomes a practical one. In your practice, who is that somebody?

There are broadly three answers, and firms sit in all of them.

No one in particular. It falls to whoever is most comfortable with technology — often a partner, sometimes the practice manager — fitted around client work. Things get done when there’s time, which during a lodgement period usually means later.

Someone, informally. A capable person internally, or a contractor called when something breaks. That works well for fixing. It’s less suited to the parts of this that need to run continuously and be evidenced afterwards.

An established security provider. Infrastructure, devices and helpdesk handled properly, often by someone the firm has worked with for years and trusts. The gap here isn’t competence. It’s that the accounting-specific layer sits outside what a generalist provider is set up to carry: which applications hold client data, what the TPB expects a practice to demonstrate, what evidence looks like when a client or an insurer asks. It’s a division of labour question — the provider runs the infrastructure, and something still has to run the application layer and produce the record.

What all three positions share isn’t a capability problem. It’s a context problem. Whoever handles this has to already know what Xero, Karbon and Dext are, what a BAS lodgement period does to a firm’s week, what the TPB asks a practice to show, and why a breach in an accounting firm is a professional problem before it’s a technical one. A generalist starts that conversation from scratch every time. Someone working with accounting and bookkeeping firms every day starts it already knowing.

And when it goes wrong

That context question stops being abstract the moment something actually happens, because an incident in an accounting, bookkeeping or financial planning firm runs on a clock and involves parties a generalist provider has probably never dealt with.

Under the Notifiable Data Breaches scheme, the clock starts when the firm has reasonable grounds to suspect a qualifying breach — not when it has worked out what happened. Notification to the OAIC and to affected clients is due within 30 days, and failure to notify inside that window is itself a civil penalty event under the amended Privacy Act. Thirty days sounds generous until you are three days in and still establishing which applications were reached.

The accounting-specific part is what sits behind those applications. The ATO has formally identified tax agent credentials as high-value targets, and for good reason: compromised agent credentials can enable fraudulent lodgements, access to client tax file numbers, and refund redirection across an entire client portfolio — with the registered agent carrying the liability. A breach in a practice isn’t only a privacy incident. It’s a professional standing incident, a client trust incident, and potentially a fraud incident, all at once.

Which is why the first hour matters more than the first week. Knowing which applications to lock first, how to work out what was accessible, how to preserve the evidence, and how to structure a notification the OAIC will accept is a different skill from restoring a mailbox. It’s also the part most firms discover they don’t have a plan for at the worst possible moment — their provider has never run a breach in a practice, and their insurer is on hold.

Which raises two questions most firms haven’t been asked. Does your firm have a written incident response plan? And has anyone tested it?

In February 2026 the Federal Court ordered a financial services firm to pay $2.5 million in penalties, plus $500,000 in costs, for cyber security failures — the first time civil penalties have been imposed for cyber security failures of this kind in Australia. Among the shortcomings the Court identified: no multi-factor authentication for remote access, credentials stored in plain text, and no cyber incident response plan tested at least annually, setting out how an incident would be detected, confirmed and responded to.

The Court was reading what reasonable steps look like in practice, and it treated an untested plan as no plan. The Privacy Act asks firms for reasonable steps too, and the TPB expects policies and procedures that are documented and enforced. A plan written once and filed is the version that fails when it’s needed — and the version that looks worse afterwards.

Trust, security and compliance are one conversation

Read across those five actions and they stop looking like five separate jobs. Clients hand an accounting firm highly sensitive financial information on trust. Security is how that trust is protected. Compliance is how the firm demonstrates the measures it has put in place. Treated as three separate programs, a firm ends up with controls it can’t evidence, or documentation describing controls nobody follows.

That’s why event logging sits at the centre rather than at the edge of the list. It’s the action that turns the other two into something a firm can show — to a client asking a reasonable question, to an insurer at renewal, to a regulator, or simply to a partner who wants to know what happened when a staff member left in March. The firms that find this straightforward aren’t the ones with the most tools. They’re the ones where the capability was switched on, configured, and left running.

Where to start: three checks for your firm

The national list reduces to three checks for a practice. None of them requires a project, a budget or a consultant to answer. If you’d rather work through a longer version, the Firm Owner’s Security Checklist covers 24 questions across devices, email, cloud storage and browser access.

Against legacy technology. Which applications still hold an active connection to your client data that nobody has opened this year — and could a former staff member still reach any of them?

Against event logging. If you were asked today to show who accessed a particular client’s information and when, what could you produce, and how long would it take?

Against AI-enabled threats. Which AI tools is your team using right now, in which accounts, with what client data in them? Shadow AI is only a problem for as long as it stays invisible.

A firm that struggles to answer these doesn’t have a tools problem. It has a visibility problem, and that’s a far easier thing to fix.

Taking action across the year

Cyber Action Year runs across the whole of 2026, and the value in it for a practice isn’t the list itself. It’s the hour spent on those three checks and finding out which ones are hard to answer.

The firms that move quickest from a national recommendation to an actual change are the ones who don’t have to explain their application stack from scratch first.

If you’d like to see what your firm’s access, applications and documentation look like today, book a complimentary security consultation. Under 60 minutes, with a specialist who works with accounting and bookkeeping firms every day.

More on the threats and regulations shaping Australian accounting firms on the Practice Protect blog, and in our live webinars.

Disclaimer: This article does not constitute legal advice. For obligations specific to your firm, consult your legal or compliance adviser.