A note before you read: the scenarios below are illustrative, not legal advice.
Somewhere in your firm, someone has assumed your external IT provider is handling your Privacy Act (ADM) updates.
It is a logical assumption. For years, you have paid a Managed Service Provider (MSP) to handle your firm’s “IT compliance”. They run your server migrations, manage your cybersecurity, and send you monthly reports showing that your data is secure.
When you hear that new legislation is coming into effect on 10 December 2026, it is easy to assume it falls under their remit.
It doesn’t.
From 10 December 2026, the Privacy Act changes regarding Automated Decision Making (ADM) come into effect. Your IT provider is neither equipped nor responsible for handling them.
The two different types of compliance
When your MSP talks about compliance, they mean infrastructure security. They audit your firm against technical frameworks like the ASD Essential Eight or ISO 27001. They make sure your data is encrypted, staff are using multi-factor authentication, and your backups will hold in the event of a ransomware attack.
The December ADM rules cover different ground. The computer program doesn’t have to make the whole decision on its own. If it does something substantially related to making the decision, scoring, ranking, or flagging something in a way that shapes what a person decides next, that’s enough to bring it into scope. If your firm arranges for a computer program to do that, in a way that could significantly affect someone’s rights or interests, your privacy policy needs to say so: what kind of personal information is involved, and what kind of decision the program is making or shaping.
Your MSP secures the software. Whether what’s running inside it counts as an automated decision, and what your privacy policy needs to say about that, isn’t something they’re set up to assess.
The tools your MSP doesn’t evaluate
This distinction matters because of the tools your firm uses every day.
HR and Recruitment Software
Your firm likely uses an Applicant Tracking System (ATS) to filter job applicants. It doesn’t need to reject anyone outright to be in scope. If it ranks or scores candidates so a recruiter only ever sees the names that made the cut, it has substantially shaped who gets considered, even though a person makes the final call. Your MSP keeps the login secure. What the scoring model ranks on isn’t something they look at.
Legal Conflict-Checking Systems
Many mid-market firms use SaaS tools to automate conflict-of-interest checks during client intake. If the system flags a potential conflict and the matter gets declined on that basis, an automated decision has shaped the outcome, whether the system declined it outright or a partner signed off on the flag.
Client Engagement and Risk-Rating Tools
Accounting and advisory practices increasingly use software to score new client engagements for risk before work begins, sometimes as part of anti-money laundering checks, sometimes as general practice risk management. The system doesn’t need to decline the engagement itself. If it flags an account as higher-risk and that flag is what sends it to a partner for review, it has shaped a decision about someone’s access to your services. Your MSP makes sure that client database is encrypted and access-controlled. The criteria the model uses to decide who gets flagged isn’t something they’re involved in.
Underwriting and Claims Triage
If you’re an insurance broker, you likely use software that aggregates client data to recommend a premium, or triages claims for fast-track approval versus manual assessment. Your MSP makes sure that data is hosted locally in Australia. Where the line sits between an automatic approval and one that goes to a human isn’t a question they’re answering.
The response most Practice Managers will have, and why it doesn’t hold
“Our MSP says they handle full regulatory compliance for us.”
Here’s the problem with that.
MSPs operate on efficiency, managing infrastructure at scale. Digging into the bespoke workflows of your HR department, interviewing your risk officers about how engagements or claims are assessed, and drafting disclosure wording for your public privacy policy sits outside what an infrastructure contract is built to do.
It’s also squarely the kind of judgement call a regulator would expect a named person inside your firm to own; not an external vendor managing your servers. If you ask your IT account manager to draft the ADM disclosure for your privacy policy, they’ll politely decline, and they’d be right to.
What needs to change before December
Three things, at minimum.
You need to decouple “IT security” from “privacy transparency” in your operational planning.
Someone in your firm, not an external IT helpdesk, needs to map the actual business workflows across your departments to identify where automated logic is making or shaping decisions.
And your public-facing privacy policy needs updating to reflect what that mapping finds.
Your MSP will happily implement any technical changes that come out of this. They won’t define the policy for you.
The question worth sitting with
Do you know which of your firm’s software platforms make, or substantially shape, decisions about individuals? And have you confirmed, in writing, who in your firm is responsible for getting that into your privacy policy before December?
If the answer to either is uncertain, that’s the gap December is coming for.
I can run the full assessment for you if you’d like.
