IT Support for NDIS and Disability Service Providers

NDIS IT support means keeping participant records, claiming systems and a distributed support workforce running securely — to the standard the NDIS Quality and Safeguards Commission and the NDIS Practice Standards now expect. Get it wrong and you risk a reportable breach, a failed audit, or support workers locked out of care plans.

Disability service providers sit on some of the most sensitive personal data in the country and run it across phones, tablets and vehicles spread over the whole of Melbourne. That combination — concentrated risk and a mobile workforce — is what makes the IT demanding. Here’s what providers actually need, and where most are exposed.

Registered, unregistered, and the range of services

“NDIS provider” covers a wide spread of organisations, and the IT requirements shift depending on where you sit. A registered provider has been audited against the NDIS Practice Standards and carries explicit obligations around governance, incident management and the handling of participant information. An unregistered provider working with plan-managed or self-managed participants has fewer audit obligations but holds the same sensitive data and the same duty under the Privacy Act — so “we’re not registered” is no reason to run loose IT.

The service types pull in different directions too. A support coordination business is mostly office and laptop work: managing plans, liaising with participants, writing reports. Supported Independent Living (SIL) and community-access services run more like a 24/7 operation across multiple houses, with workers on shift, rosters that change daily, and behaviour-support information needed at the point of care. The software looks similar from outside; the network, device and access design underneath is genuinely different.

The compliance layer: the Commission and the Practice Standards

The NDIS Quality and Safeguards Commission regulates registered providers, and a meaningful slice of its expectations land on IT. The NDIS Practice Standards include governance and operational management requirements, and the Privacy and Information Management requirements expect providers to keep participant information confidential, accurate and secure, and to control who can access it. That is an identity and data-security problem as much as a policy one.

Two points catch providers out. Accountability stays with you — “we outsourced it to an IT company” is not an answer the Commission accepts. And you have to be able to show it: if a verification or certification audit asks how participant records are protected and who can see them, you need documented access controls, an offboarding process, and evidence your backups work. Most providers can describe their intentions; far fewer can produce the evidence.

PRODA and the NDIS portals

Almost every NDIS provider lives in the government portals, and access is an identity issue with real consequences. PRODA (Provider Digital Access) is the Commonwealth identity gateway that gets staff into the myplace provider portal, the NDIS Commission systems, and the claiming and payment functions. Each PRODA account is tied to an individual, secured with two-factor sign-in, and linked to your organisation.

The risk sits in lifecycle management. When a payments officer leaves and their PRODA access isn’t revoked, you have an orphaned door into participant payment data. We treat PRODA and portal access with the same identity discipline as everything else: documented who-has-what, removed the same day someone leaves, and never shared. Shared logins remain the most common control failure we find in this sector.

Participant management and claiming software

The system at the centre of an NDIS provider’s day is its participant management platform — handling records, plans, shift notes, invoicing and the claim file that goes to the agency. That usually means Lumary, ShiftCare, Brevity, SupportAbility or Carelink, often with finance and payroll alongside.

Whether these run in the cloud or on a server in the comms room, the IT job is the same: they must be available, fast, backed up, and reachable wherever support happens. We treat them as the priority for monitoring, patching and uptime.

A SIL provider in Dandenong we work with runs records, rostering and claiming on one cloud platform. The risk was never the software — it was everything underneath: a single shared login, a flat network where one compromised PC could reach everything, unmanaged personal phones, and backups nobody had tested. None of that is the vendor’s responsibility. It’s the MSP’s, and it’s where the real exposure sits.

Protecting highly sensitive participant data

NDIS providers hold a concentration of sensitive information that makes them a deliberate target: disability and health records, behaviour-support plans, medication details, NDIS numbers, bank and plan-management details, guardianship and next-of-kin information, and often data about minors. Under the Privacy Act and the Australian Privacy Principles, much of this is “sensitive information” attracting the highest protection, and a breach likely to cause serious harm is reportable to the Office of the Australian Information Commissioner (OAIC) under the Notifiable Data Breaches scheme.

Attackers know care providers often run lean IT and a workforce that’s easy to phish, and the data is high-value — the cyber insurance market has noticed too, with premiums and required controls reflecting the risk.

The defensive baseline we hold NDIS clients to is the Australian Cyber Security Centre’s (ACSC) Essential Eight: application control, fast patching of applications and operating systems, Microsoft Office macro settings, user application hardening, restricted administrative privileges, multi-factor authentication, and regular tested backups. Most breaches we’re called in after would have been stopped or contained by getting it genuinely in place rather than half-done. If you want the staged version, we’ve written up how to reach Essential Eight maturity in 90 days.

A mobile workforce: devices, rostering and remote access

Rostering and field devices

SIL and community-access providers run on rosters that change constantly, and support workers need to see shifts, log visit notes and read care plans on a phone or tablet wherever they are. Those devices carry participant data out into the world, so they have to be managed centrally. If a tablet is lost between a shift in Footscray and the next in Sunshine, you need to remotely wipe it within minutes — not discover it’s been sitting unencrypted in a glovebox. Mobile device management through Microsoft Intune, enforced encryption, and conditional access tied to a managed device are what make field devices defensible.

Secure remote access for support workers

Workers reaching rosters and care plans from homes, group residences and their cars need access that’s both easy and locked down — not VPNs into a flat network, but identity-based access where each worker signs in as themselves, MFA is enforced, and what they reach is scoped to their role. A support worker should see their participants and shifts, not the organisation’s whole record set. We run conditional access in Microsoft 365 and build around least privilege, so one compromised account can’t expose every participant.

Identity for a high-turnover workforce

Disability services have significant staff churn — casuals, agency workers, people moving between providers. Every starter needs the right access on day one and every leaver needs it gone the same day, including PRODA. Orphaned accounts are how breaches happen months after someone’s left. We run it properly: standardised onboarding and offboarding, role-based access, and MFA everywhere.

Backups and incident readiness

A tested, isolated backup is the difference between a ransomware incident being a bad week and an existential event for a provider that can’t access medication or behaviour-support records. We cover this in our guide to backup and disaster recovery for Melbourne businesses, and it applies double when records relate to vulnerable people. Incident readiness goes further: logging, a rehearsed response plan, and the ability to retrieve records quickly when the Commission, an insurer or a family asks.

What good NDIS IT support actually covers

TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers — no offshore helpdesk touching participant data. We price per user on a fixed monthly basis with no hourly billing for in-scope work, which matters in a sector budgeting against plan-funded revenue. Our cybersecurity services and broader managed IT services carry this regulated, always-on workload, and our 24/7 network operations centre in Tecoma means support doesn’t stop when a SIL house needs help overnight.

Frequently asked questions

Do the NDIS Practice Standards require specific IT controls?

They don’t prescribe particular products, but the Privacy and Information Management and governance requirements mean providers must be able to show participant information is kept secure, accurate and access-controlled. In practice that points straight at Essential Eight controls, MFA, managed identity and tested backups — and the accountability stays with the registered provider, not the IT vendor.

We’re an unregistered provider — do these IT requirements still apply?

The audit obligations differ, but the data doesn’t. You hold the same sensitive participant information and the same duty under the Privacy Act, and a breach likely to cause serious harm is still reportable to the OAIC. Running lean IT because you’re unregistered is a risk, not a saving.

How should we handle PRODA access when a staff member leaves?

Revoke it the same day, alongside their email, portal and system access, as part of a standard offboarding process. PRODA accounts are tied to individuals and must never be shared. Orphaned access is a live door into participant payment data and a common audit finding.

Where to start

If you’re unsure whether your IT would stand up to a Practice Standards audit or a breach, the honest first step is an assessment: where participant data lives, how access and PRODA are controlled, whether your backups actually restore, and where the Essential Eight gaps are. Most providers we assess have two or three serious exposures they didn’t know about — usually shared logins, unmanaged devices, or untested backups. Get in touch with TechAssist and we’ll give you a straight read on what to fix first.

Registered Training Organisations live or die on their data. RTO IT support means keeping your Student Management System, AVETMISS reporting, USI checks and online delivery running and secure — because if your records are wrong or breached, ASQA and your students both notice fast.

We work with vocational training providers across Melbourne, and the pattern is consistent: the compliance burden is enormous, the margins are thin, and the IT is usually held together by one overworked admin and a pile of spreadsheets. This post covers what actually matters for an RTO’s IT — the systems, the obligations, and where things break.

Why RTOs are a different beast to most SMEs

A 30-person consultancy in Hawthorn loses email for a morning and it’s annoying. An RTO loses its Student Management System during a reporting deadline and it’s a regulatory problem. The difference is that almost everything an RTO does — enrolments, results, certificates, funding claims — is data that ASQA, NCVER and state training authorities can audit, and that students are legally entitled to.

That changes how you have to think about IT. It’s not just “keep the laptops working”. It’s records integrity, retention, access control and uptime around fixed reporting windows. Get those wrong and you risk funding clawbacks, audit non-compliance, or a notifiable data breach. Our professional services IT support grew out of exactly this kind of compliance-heavy work, and RTOs sit right in that bracket.

The Student Management System is the heart of everything

Your Student Management System (SMS) is where the real risk lives. Whether you run aXcelerate, VETtrak, Wisenet or JobReady, this is the single system that holds enrolments, competencies, results, certificates and the data that feeds your AVETMISS exports. If it’s down, you can’t enrol. If it’s corrupted, you can’t report. If it’s breached, you’ve got a privacy incident.

Most of these are cloud-hosted (aXcelerate and Wisenet in particular), which removes some infrastructure headaches but introduces others. You’re now dependent on identity, internet reliability and integration plumbing instead of a local server. The IT job shifts from “patch the box in the cupboard” to “make sure the right people can get in, the wrong people can’t, and the integrations don’t silently fail”.

What we actually manage around an SMS

• Access control — who can see and edit student records, and removing access the day a trainer leaves, not three months later.
• Integrations — the SMS talking to your LMS, your USI checks, your CRM and your accounting system. These break quietly; nobody notices until a sync has been failing for a fortnight.
• Browser and device health — cloud SMS platforms are only as reliable as the machines and connections your staff use to reach them.
• Export integrity — making sure AVETMISS files generate cleanly and aren’t being mangled by stale data or duplicate records.

AVETMISS, NCVER and ASQA: the reporting you can’t get wrong

Every RTO has to report training activity in the AVETMISS format — the national standard for VET data, collected by the National Centre for Vocational Education Research (NCVER) and used by ASQA and state authorities. For most providers that means AVETMISS submissions through NCVER’s collection system, with strict validation rules and fixed annual deadlines.

IT’s role here is unglamorous but critical: the export only works if the underlying data is clean. We’ve seen AVETMISS submissions bounce repeatedly because of duplicate student records, mismatched USI data, or a half-finished migration that left two versions of the truth. None of that is a “training” problem — it’s a data hygiene and systems problem, which is squarely IT’s job.

Practical reality: your SMS does most of the AVETMISS heavy lifting, but it can only export what’s in it correctly. The work is keeping the inputs clean — consistent course codes, deduplicated learners, validated USIs — so the file passes NCVER validation the first time instead of eating a week of your compliance manager’s life.

USI integration — small system, big consequences

Every student needs a verified Unique Student Identifier (USI), and you can’t issue a nationally recognised qualification without one. Most SMS platforms integrate directly with the USI Registry to verify identifiers at enrolment. When that integration is configured correctly it’s invisible. When it isn’t, you get a backlog of unverified students and certificates you legally can’t issue.

The integration relies on credentials and certificates that expire. A training provider in Box Hill we work with had USI verification silently stop working for a fortnight because an integration certificate lapsed and nobody owned the renewal. The fix was trivial; the cause was that no one was watching it. That’s the gap managed IT closes — owning the boring renewals and monitoring so they don’t become a crisis.

LMS and online delivery: Moodle, Canvas and uptime that matters

If you deliver online or blended training, your Learning Management System (LMS) is student-facing infrastructure, and outages are immediately visible. Moodle (including hosted Moodle and MoodleCloud) and Canvas are the two we see most. The reliability question depends on how it’s hosted:

Self-hosted Moodle is where most of the avoidable pain lives. It’s cheap to stand up and expensive to neglect — an unpatched Moodle is a genuine security liability, and a slow one during assessment week generates a flood of student complaints. If you run your own Moodle, it needs the same patching and monitoring discipline as any production server. Our managed IT services cover that so it isn’t left to whoever set it up two years ago.

Protecting student PII and the Privacy Act

RTOs hold a lot of sensitive personal information: full names, dates of birth, USIs, government identity documents used for verification, language and disability data, sometimes payment details. Under the Privacy Act 1988 and the Australian Privacy Principles, you’re responsible for protecting it, and a serious breach is notifiable to the Office of the Australian Information Commissioner (OAIC) and to affected students.

The threats are ordinary, not exotic. Phishing that harvests a trainer’s Microsoft 365 password. A shared admin login that never gets rotated. Student records emailed around as unprotected spreadsheets. The controls that stop most of this are well established and align with the Australian Cyber Security Centre’s (ACSC) Essential Eight:

• Multi-factor authentication on every account that touches student data — non-negotiable, and the single highest-value control.
• Conditional access so logins from unexpected locations or unmanaged devices are challenged or blocked. We cover the detail in conditional access policies for Microsoft 365.
• Least-privilege roles in the SMS and LMS so a marketing coordinator can’t export the entire learner database.
• Email security and phishing defence, because that’s still how most breaches start.

If you want a structured path through this, our cybersecurity services are built around the Essential Eight and the kind of identity controls that genuinely reduce breach risk for an RTO.

The Standards for RTOs 2025

The revised Standards for RTOs took effect from 1 July 2025, replacing the 2015 standards. The headline change is a shift toward outcomes and quality, with clearer expectations around governance, the integrity of records and the experience of learners. They don’t prescribe a particular IT stack, but several obligations land directly on your systems.

Specifically, the standards reinforce that you must keep accurate, secure and accessible records of training and assessment, manage learner information responsibly, and be able to produce evidence on request during an ASQA audit. In practice that means: records that are backed up and retrievable, access that’s controlled and logged, and an SMS you can actually report from. If your IT can’t demonstrate those things, you’ve got a compliance exposure regardless of how good your training is.

Backup and records retention

Records retention is one of the most concrete IT obligations an RTO has. You’re required to retain certain student and assessment records for set periods — AVETMISS and learner records for years, and assessment evidence under your standards obligations — and you must be able to produce them years after a student has left.

That’s a retention problem as much as a backup problem. A 30-day backup cycle protects you from accidental deletion last week; it does nothing for a record you need to produce from four years ago. RTOs need a deliberate retention strategy: where long-term records live, how they’re protected, and how they’re retrieved on demand. We design backup with both recovery and retention in mind — see our approach to data backup and recovery.

The other half is recovery speed. If your SMS or self-hosted LMS goes down mid-semester, how long until students and trainers are working again? That’s the RTO and RPO question — how much data you can afford to lose and how long you can be down — which we unpack in RTO vs RPO explained. (Yes, “RTO” means two different things in this world; the recovery one matters here too.)

Identity and access for trainers and students

RTOs have unusually messy identity needs. Trainers come and go, often part-time or contract. Students arrive in cohorts and leave in cohorts. Both groups need access to different systems, and both create risk when access isn’t cleaned up.

The pattern we put in place for training providers is simple to describe and a discipline to maintain:

1. Single sign-on through Microsoft 365 where the SMS and LMS support it, so there’s one identity to manage and revoke, not five.
2. Joiner-mover-leaver processes so a trainer who finishes a contract loses access that day across every system — SMS, LMS, email, shared drives.
3. Separate student and staff identity boundaries so a student LMS account can never reach administrative or AVETMISS data.
4. MFA everywhere on staff accounts, with sensible enrolment for students on systems that hold their PII.

Getting Microsoft 365 configured properly underpins most of this. If your tenancy is the typical “set up once, never reviewed” arrangement, our Microsoft 365 support is usually the first thing we tighten.

Reliable delivery infrastructure

None of the above matters if the basics aren’t reliable. A training room in Dandenong full of students who can’t reach the LMS because the internet dropped is a real cost — wasted trainer time, frustrated learners, and complaints that find their way into your quality data.

Reliable delivery infrastructure for an RTO means business-grade internet with sensible failover, classroom Wi-Fi that actually copes with a full cohort connecting at once, and devices that are patched and managed rather than a random fleet of whatever was on sale. It’s not glamorous, but it’s what keeps delivery running. As a Melbourne MSP founded in 2014 with 13 Australian-employed engineers and same-business-day on-site across the metro, this is the part we do quietly in the background so you never have to think about it.

Frequently asked questions

Does our Student Management System provider handle our IT?

No. aXcelerate, VETtrak, Wisenet and JobReady support their own platform — the software, hosting and platform-level issues. They don’t manage your Microsoft 365, your identity and access, your LMS, your devices, your network, or the integrations between systems. Those are your responsibility and are where most RTO IT problems actually occur.

How long do we have to keep student records?

Retention periods vary by record type and funding arrangement — AVETMISS and learner records run to years, and assessment evidence is governed by your standards obligations. The safe position is a deliberate, documented retention strategy with long-term records backed up and retrievable, rather than relying on a short backup window. Check current ASQA and NCVER guidance for the specific periods that apply to you.

Is MFA really mandatory for an RTO?

It’s not written into the Standards for RTOs as a named requirement, but it’s the single most effective control against the account compromise that causes most breaches of student PII. Given your Privacy Act obligations and the sensitivity of the data you hold, treating MFA as mandatory across all staff accounts is the only defensible position.

What happens to our data if we switch SMS providers?

This is where a clean migration matters. Done badly, you end up with duplicate records, broken USI links and AVETMISS exports that fail validation. Done well, your data is mapped, deduplicated and validated before cutover. We treat SMS migrations as a data integrity project, not a copy-paste exercise.

Where TechAssist fits

RTOs need an IT partner who understands that the compliance and the technology are the same conversation. We support training providers and other compliance-heavy organisations across Melbourne with fixed per-user pricing, sub-15-minute response on critical issues, and engineers who actually understand AVETMISS reporting, USI integration and the privacy obligations that come with holding student data.

If your SMS, LMS or Microsoft 365 setup is held together with goodwill and you’d rather it was held together with proper monitoring, backups and access control, get in touch. We’ll start with an honest look at where your real risks are — usually identity, retention and the integrations nobody’s watching — and tell you straight what needs fixing first.

Community pharmacies run on systems that have to be available the moment a customer hands over a script, store sensitive health data the Privacy Act takes seriously, and connect to half a dozen government and supplier networks at once. Good pharmacy IT support keeps the dispensary, the retail front and the claiming all running together, securely.

If you own or manage a retail pharmacy, your IT is not a back-office convenience. A dispensing terminal that freezes, a SafeScript lookup that times out, or a server that goes down on a Saturday morning translates directly into a queue of patients you cannot serve and prescriptions you cannot legally fill. This is operational, clinical and regulatory all at once, and most generic “computer guys” do not understand the stack.

What actually runs in a community pharmacy

A typical suburban pharmacy is running more integrated software than most small businesses twice its size. The dispensing system is the heart of it. Depending on the banner group and the pharmacist’s history, that is usually one of:

• FRED Dispense or the newer cloud-capable FRED NXT
• Z Software (ZDispense)
• Minfos
• Aquarius
• Simple Retail or another integrated retail POS platform

That dispensing system does not sit on its own. It has to talk to electronic prescription services, the real-time prescription monitoring database, My Health Record, your wholesaler ordering, your retail point of sale, your label printers and your dose-administration-aid packing. When the underlying network, server or workstation has problems, all of that wobbles at once. The pharmacist usually notices first, at the worst possible moment.

A pharmacy in Box Hill we work with runs FRED NXT in the dispensary and an integrated retail POS at the front counter, with a single on-premise server tying them together and a secondary internet service on standby. That setup is normal now, not gold-plated. The dependencies are real, so the infrastructure underneath them has to be treated as critical, not as something you replace when it finally dies.

Electronic prescriptions, SafeScript and My Health Record

Three external systems sit close to the centre of day-to-day dispensing, and all three depend on a stable internet connection and correctly configured workstations.

Electronic prescriptions (eRx and the token / Active Script List)

Paper scripts have largely given way to electronic prescriptions delivered through the eRx Script Exchange (and, where still in play, MediSecure). A patient presents an SMS or email token, or you pull their Active Script List, and the script flows straight into the dispensing software. When the connection to the prescription exchange drops, dispensing slows to a crawl and staff fall back to manual workarounds that introduce errors. Reliable connectivity and a tested failover path are not optional here.

Real-time prescription monitoring (SafeScript Victoria)

In Victoria, SafeScript is mandatory for supplying monitored medicines. Pharmacists are required to check it, and a slow or broken connection to SafeScript is not just an inconvenience, it sits in the middle of a legal obligation. The integration runs through the dispensing software and a browser, so DNS, certificates and browser configuration all matter. We have seen “it’s just the internet” turn out to be an expired certificate or a security setting blocking the lookup.

My Health Record

Uploading dispense records to My Health Record relies on your NASH PKI certificate, correct HPI-O configuration and a healthy connection to the Healthcare Identifiers service. Certificates expire. When they do, uploads silently fail and nobody notices until there is a problem. Part of competent pharmacy IT is tracking those expiry dates and renewing them before they bite.

Claiming through the Pharmacy Programs Administrator

Beyond dispensing revenue, pharmacies claim for programs administered by the Pharmacy Programs Administrator (PPA) through its portal — MedsCheck, Dose Administration Aids, staged supply, and the various professional programs that come and go. Claiming depends on accurate records out of your dispensing and patient management systems, and on PRODA access for the staff who lodge claims.

The IT angle is unglamorous but real: PRODA accounts tied to individuals who have since left, multi-factor authentication that nobody can reset, and software that has not been updated to the current program rules. When claiming breaks at month-end, it is real money sitting unclaimed. Keeping access, identity and software current is part of the job.

Protecting health and payment data under the Privacy Act

This is where pharmacies are exposed in a way most retailers are not. You hold two categories of data that attract serious obligations: health information and payment card data.

Health information is sensitive information under the Privacy Act 1988, and the usual small-business turnover exemption does not apply to it. A pharmacy that turns over well under the $3 million threshold is still an APP entity because it provides a health service and holds health records. In plain terms: there is no turnover threshold that lets a pharmacy off the hook. You are covered by the Australian Privacy Principles and the Notifiable Data Breaches scheme regardless of size, and the Office of the Australian Information Commissioner (OAIC) is the regulator if something goes wrong.

That means a stolen laptop, a ransomware hit that exposes patient records, or a misconfigured backup sitting in a public cloud bucket can each be a notifiable breach. The practical controls are not exotic: encrypted devices, properly segmented networks so the public-facing retail Wi-Fi cannot reach the dispensary server, tight access control, multi-factor authentication on email and remote access, and patched systems. Most of this maps cleanly onto the Essential Eight, which is the framework we use as the baseline for healthcare clients. If you want the wider clinical-records picture, our guide to healthcare IT support, the OAIC and My Health Record goes deeper on the obligations.

On the payment side, taking card payments brings PCI DSS obligations through your bank and payment provider. Integrated EFTPOS and properly maintained terminals do most of the heavy lifting, but the surrounding network still has to be kept clean.

Where the retail POS and the dispensary have to meet

The thing that makes pharmacy IT distinct from a standard shopfront is that the retail and clinical sides are genuinely fused. A customer collecting a prescription often buys front-of-shop items in the same transaction. Stock, pricing, promotions, loyalty and scheduled-medicine handling all flow between the POS and the dispensing system.

When that integration is healthy, the counter is fast and the pharmacist is not retyping anything. When it is not — mismatched product files, a POS that has lost its link to the dispensing database, a pricing update that did not sync — staff start working around the system, and that is where errors and lost margin creep in. Getting this right is a mix of vendor coordination and solid local infrastructure, and it is exactly the kind of thing a generic break-fix provider tends to shrug at.

Uptime, backups and ransomware resilience

A pharmacy cannot trade when its core systems are down. That makes three things non-negotiable: reliable uptime, recoverable backups, and a genuine plan for ransomware.

Uptime

Uptime is about removing single points of failure. A pharmacy that depends on one ageing server, one internet connection and one power outlet is one bad morning away from closing the dispensary. Sensible measures — a properly specified and monitored server, a UPS, a secondary internet service that fails over automatically, and proactive monitoring that flags a failing disk before it dies — keep the doors open. Our managed IT services are built around catching these problems before they become outages, with same-business-day on-site cover across Melbourne metro when something does need hands on it.

Backups

Your dispensing database is the record of every supply you have made. It has to be backed up, the backups have to be tested, and at least one copy has to be off-site and out of reach of anything that compromises the main system. An untested backup is a hope, not a plan. We work to clear recovery objectives so you know how much data you could lose and how long you would be down — the detail is in our piece on RTO versus RPO.

Ransomware resilience

Healthcare is a favourite target for ransomware crews precisely because the data is sensitive and the pressure to pay is high. Resilience means layered defences — email security to stop the phishing that usually starts it, endpoint protection, network segmentation, multi-factor authentication everywhere, and immutable off-site backups so that even if the main systems are encrypted, you can rebuild. Our cybersecurity services and 24/7 NOC at Tecoma are geared to exactly this: catch the intrusion early, contain it, and have a recovery path that does not involve paying criminals.

What good pharmacy IT support looks like in practice

The difference between a provider who understands pharmacies and one who does not shows up in the small things: knowing that a SafeScript timeout might be a certificate, not the NBN; knowing that a failed My Health Record upload usually traces back to NASH PKI; understanding that the dispensing vendor and the IT provider have to coordinate rather than blame each other.

TechAssist is a Melbourne-based MSP founded in 2014, with 13 Australian-employed engineers — no offshore helpdesk — and a sub-15-minute response on critical issues. For a pharmacy, that response time is the difference between a brief hiccup and a closed dispensary. We work with healthcare clients across the metro on per-user fixed monthly pricing, so a busy month does not turn into a surprise IT bill.

Frequently asked questions

Does the Privacy Act apply to a small pharmacy?

Yes. Because a pharmacy provides a health service and holds health records, it is an APP entity under the Privacy Act regardless of turnover. The small-business exemption that applies to many businesses under $3 million does not cover the handling of health information, so the Australian Privacy Principles and the Notifiable Data Breaches scheme apply to you.

Can you support FRED, Minfos, Z Software and Aquarius?

We support the infrastructure, network, workstations, servers and security those systems run on, and we coordinate directly with the dispensing vendor for application-level issues. Most “the dispensing system is slow” calls turn out to be infrastructure or connectivity problems, which is squarely our remit.

What happens to dispensing if our internet goes down?

Electronic prescriptions, SafeScript and My Health Record all need connectivity, so an outage hits dispensing hard. We design pharmacies with a secondary internet service that fails over automatically, so a single ISP fault does not stop you trading. It is one of the first things we check on a new pharmacy site.

How quickly can you get someone on-site?

We offer same-business-day on-site support across Melbourne metro, backed by a sub-15-minute response on critical issues from our Tecoma NOC and CBD office. For a pharmacy with a down dispensary, getting hands on it the same day matters.

Talk to a Melbourne MSP that knows pharmacies

If your current provider treats your dispensary like an ordinary office network, you are carrying more risk than you should — clinically, financially and under the Privacy Act. We build pharmacy IT around the systems you actually run, the regulators you actually answer to, and the uptime your patients depend on. Get in touch and we will walk through your dispensing, claiming, security and backup setup, and tell you straight where the gaps are.

Good childcare IT support keeps your sign-in kiosks running, your Child Care Subsidy claims flowing, your CCTV recording, and families’ data locked down — without a centre director becoming the accidental IT person. For long daycare, kindergarten and OSHC providers, the technology now sits at the heart of compliance, funding and safety.

Early learning is one of the most technology-dependent industries that rarely thinks of itself that way. A single morning touches a sign-in kiosk, a management platform, a funding system, room Wi-Fi and a bank of cameras — and when any of it breaks, parents can’t sign children in, subsidy claims stall, and educators are pulled off the floor.

What makes childcare IT different from a normal office

A childcare centre has shifting staff, children who must be accounted for at all times, sensitive records on every family, funding tied to accurate attendance data, and physical-safety systems that can’t fail quietly. The stakes are also regulatory: the Australian Children’s Education and Care Quality Authority (ACECQA) administers the National Quality Framework (NQF), and your technology has to support — not undermine — your obligations around record-keeping, supervision and child safety. Get the IT wrong and you create gaps that show up at assessment and rating.

Whatever your brand of childcare management software — the common platforms in Australian centres include Xplor, Storypark, QikKids, Kidsoft, OWNA and Hubworks — it is the spine of the operation, handling enrolments, attendance, billing, educator observations and the documentation that feeds your Quality Improvement Plan. Most are cloud-based now, which makes your internet connection and Wi-Fi non-negotiable.

Child Care Subsidy and the CCSS gateway

The single most expensive thing that can go wrong is a break in your funding data. The Child Care Subsidy (CCS) subsidises fees for most Australian families, and it flows through the Child Care Subsidy System (CCSS). Your management software connects to the CCSS gateway to submit session reports, confirm enrolments and reconcile payments — a connection that runs over your internet link. When it drops — because the internet went down, a certificate expired, or someone changed a setting — session reports don’t submit on time, which means delayed payments, families chasing why their gap fee jumped, and an administrator manually reconciling weeks of attendance.

The protections that matter here are a business-grade internet service with automatic 4G/5G failover so kiosks and CCSS submissions keep working when the primary line drops, monitoring so we know the line is down before the office does, and documented certificate renewals so nothing silently expires.

Sign-in kiosks and iPads on the floor

Most centres now run sign-in/sign-out on a wall-mounted iPad at the entrance. Parents tap in, the attendance record updates, and that record is what your CCS session reports are built on — so if the kiosk is frozen or on a dead battery at 8:15am, you have a queue of parents and a hole in your attendance data.

iPads on the floor — used for observations and documentation in apps like Storypark and OWNA — are a fleet that needs managing, not a pile of personal devices. Without management, they end up on random iOS versions, signed into someone’s personal Apple ID, with no way to wipe one that goes missing with a child’s photos on it. Proper device management means enrolling every iPad in a mobile device management (MDM) platform so you can push apps, lock devices to kiosk mode, and remotely wipe anything lost or stolen.

Wi-Fi that actually reaches every room

Childcare buildings are hostile to Wi-Fi: thick walls, separate rooms for different age groups, outdoor play areas, and a single modem never designed to cover the whole centre. The result is a strong signal at reception and dead spots in the toddler room where the iPad won’t sync. Because so much now runs over the network, that’s the difference between attendance syncing in real time and an educator writing it on paper to enter later — which is how data gets lost.

The fix is a proper site survey and access points placed for coverage, with separate networks for staff devices, kiosks and families, so a parent’s phone can never reach your management system or cameras. A centre in Box Hill we work with had constant complaints about iPads dropping out in two of their five rooms; the cause was a single consumer router trying to cover the whole building. Three access points and a segmented network later, the dead spots and the paper backups disappeared.

CCTV and physical-IT security

Cameras are now standard at most centres, both for child safety and as a record if an incident is disputed. But CCTV is where physical security and IT security collide, and it is frequently the weakest link. Cheap systems often ship with default passwords, are exposed directly to the internet so staff can “check the cameras from home”, and never receive a firmware update — a combination that has put thousands of cameras worldwide onto the open internet. For a childcare centre, an exposed camera feed is a child-safety incident and a privacy breach at the same time.

Doing it properly means cameras on their own isolated network segment, no direct internet exposure, remote viewing only through a secured connection, default credentials changed, and firmware kept current — part of broader cybersecurity hygiene.

Protecting children’s and families’ sensitive data

A childcare centre holds some of the most sensitive personal information of any small business: children’s names, dates of birth, photos, medical conditions, allergies, custody arrangements, and parents’ financial details. Under the Privacy Act 1988 and the Australian Privacy Principles overseen by the Office of the Australian Information Commissioner (OAIC), you are responsible for protecting it, and a serious breach can trigger obligations under the Notifiable Data Breaches scheme.

The realistic threats aren’t sophisticated: a phished staff email, a lost iPad, a shared password on a sticky note, or a former educator who still has access. The controls that make the difference are multi-factor authentication on every email and management-software login (this alone stops most account takeovers), individual logins for staff rather than a shared “office” account, encrypted devices, and email security to catch the phishing and invoice fraud that targets centre administrators. Much of this aligns with the Essential Eight, the Australian Cyber Security Centre (ACSC) baseline — and you don’t need to be a bank to apply it.

Staff turnover and access

Early learning has high turnover and a lot of casual and relief educators, so every starter and leaver is an access event. The risk isn’t usually malice — it’s accounts that never get switched off. We regularly find centres where three or four former staff still have live logins months after they left. The fix is a documented onboarding and offboarding process: a new educator gets exactly the access they need on day one, and on their last day every login is disabled and any device is collected or remotely wiped. With per-user fixed pricing and no hourly billing for in-scope work, that becomes a quick, repeatable task.

Backups — for the data you can’t recreate

Cloud management platforms are resilient, but “it’s in the cloud” is not a backup strategy. If a staff member deletes a year of observations, an account is compromised, or a vendor has an outage, you need your own line of recovery — and the same applies to email, since Microsoft 365 doesn’t keep your data forever. A proper approach to backup and recovery covers your Microsoft 365 environment, your critical local data, and how your software vendor protects and restores data. The test isn’t whether backups are running — it’s whether you’ve confirmed you can actually restore from them.

What good childcare IT support looks like in practice

Centre directors and educators are not IT people, and shouldn’t have to be. The point of managed IT is that the kiosk works at drop-off, CCSS submissions go through, the Wi-Fi reaches every room, the cameras record, and there’s someone to call when something breaks.

TechAssist is a Melbourne-based MSP founded in 2014 with 13 Australian-employed engineers — no offshore helpdesk — and a 24/7 NOC in Tecoma. With same-business-day on-site support across the metro area, that matters when a kiosk goes down during the morning rush and you need someone, not a queued ticket.

Frequently asked questions

What happens to our Child Care Subsidy claims if the internet goes down?

Your software can’t reach the CCSS gateway, so session reports don’t submit until the connection is restored, which delays subsidy payments. The fix is a business internet connection with automatic 4G or 5G failover so the line — and your claims — keep running when the primary service drops.

Do you support our specific childcare management software?

We support the IT your platform runs on — internet, Wi-Fi, devices, accounts and security — across Xplor, Storypark, QikKids, Kidsoft, OWNA, Hubworks and others, working alongside your vendor’s support for in-app issues.

How do we keep children’s photos and records secure?

Multi-factor authentication on every login, individual staff accounts rather than shared ones, encrypted devices, managed iPads that can be wiped if lost, and email security to stop phishing. These align with the Australian Cyber Security Centre’s Essential Eight and your obligations under the Privacy Act.

Getting your centre sorted

If you run a long daycare, kindergarten or OSHC service across Melbourne and the technology has become one more thing to worry about, it doesn’t have to be. The right setup quietly does its job and protects the families who trust you with their children. Get in touch for a straight conversation about what your centre needs.

Aged care IT support means keeping clinical systems, resident records and connectivity running across facilities and homes — to a standard the strengthened Aged Care Quality Standards now expect. Get it wrong and you risk a data breach, a downgraded Star Rating, and care staff locked out at handover. Get it right and the technology becomes invisible.

Since 1 July 2025, residential and home care providers have operated under the new Aged Care Act and a strengthened set of Quality Standards. The compliance bar moved, and a lot of it now lands squarely on IT. This is a practical look at what aged care providers in Melbourne actually need from their technology, and where most of them are exposed.

Why aged care is a harder IT problem than it looks

On paper an aged care provider looks like any other mid-sized organisation: staff, devices, email, a few line-of-business systems. In practice it is one of the more demanding environments we support. You have a 24/7 operation where downtime affects vulnerable people, a workforce with high turnover and patchy device literacy, some of the most sensitive personal data in the country, and a regulator that can publish your performance as a Star Rating for families to read.

Residential and home care providers also run differently from each other. A residential facility is a fixed site — nurses’ stations, medication rooms, Wi-Fi that has to reach every wing including the ones with thick brick walls built in 1975. Home care is a distributed workforce: support workers driving between clients across the suburbs, logging visits on a phone or tablet, needing reliable mobile access to care plans without carrying paper. The IT looks similar from the outside and is genuinely different underneath.

The compliance layer: Quality Standards, Star Ratings and the portals

The strengthened Aged Care Quality Standards put more explicit weight on governance, information management and the security of personal information. Standard 2 (the organisation) and the governance expectations around it mean a provider’s board and management are now accountable for how information is handled and protected — and “we outsourced it to an IT company” is not an answer the Aged Care Quality and Safety Commission accepts. The accountability stays with the provider.

Practically, that means your IT arrangements need to be documented, your access controls need to be defensible, and you need to be able to show how resident information is kept secure. If you can’t produce that on request, you have a governance gap, not just a technical one.

Star Ratings raise the stakes again. Compliance, quality measures, staffing and residents’ experience feed into a public rating on My Aged Care. Systems that don’t capture data accurately — or go down during a quality audit period — can quietly drag the numbers that families use to choose a provider. The link between “our IT is reliable” and “our rating holds up” is more direct than most boards realise.

Then there are the portals. My Aged Care, the provider portals, the Government Provider Management System and the data submissions that flow through them all depend on the right people having the right access, secure sign-in, and accurate records at the source. When a staff member leaves and their access isn’t revoked, or when the wrong person can see the wrong client’s record, that is an IT and identity problem with a compliance consequence.

Clinical and care management systems

The system at the centre of an aged care provider’s day is its clinical or care management platform. In the Australian market that usually means one of AlayaCare, Leecare, Manad Plus or Telstra Health’s iCareHealth — plus medication management, rostering and finance systems hanging off the side.

Whether these are cloud-hosted or run on a server in the comms room, the IT job is the same: they must be available, fast, backed up, and reachable from wherever care happens. A nurse at a medication round or a support worker in a client’s lounge room cannot wait for a system to load. We treat these platforms as the priority for monitoring, patching and uptime, and we build the network and connectivity around keeping them responsive.

A residential provider in Box Hill we work with runs its clinical records in the cloud and its rostering separately. The risk wasn’t the software — both vendors run solid platforms — it was everything underneath: a single internet service with no failover, a flat network where a compromised reception PC could reach the medication system, and backups nobody had ever tested. None of that is the clinical vendor’s responsibility. It’s the MSP’s, and it’s where the real exposure sits.

Protecting highly sensitive resident data

Aged care providers hold a concentration of sensitive information that makes them a deliberate target: health records, medication histories, cognitive assessments, next-of-kin details, financial and Centrelink information, and increasingly the data of family members too. Under the Privacy Act and the Australian Privacy Principles, much of this is “sensitive information” attracting the highest level of protection, and a breach is reportable to the Office of the Australian Information Commissioner (OAIC) under the Notifiable Data Breaches scheme.

The sector’s risk profile has worsened. Healthcare and aged care are consistently among the most-breached sectors in OAIC reporting, and attackers know these organisations often run lean IT with older systems and a workforce that’s easy to phish. The cyber insurance market has noticed too — premiums and the controls insurers demand both reflect the elevated risk.

The defensive baseline we hold aged care clients to is the Australian Cyber Security Centre’s (ACSC) Essential Eight: application control, patching applications and operating systems quickly, configuring Microsoft Office macro settings, hardening user applications, restricting administrative privileges, multi-factor authentication, and regular tested backups. None of this is exotic. Most of the breaches we’re called in after would have been stopped or contained by getting the Essential Eight genuinely in place rather than half-done. If you want the staged version, we’ve written up how to reach Essential Eight maturity in 90 days.

Backups deserve their own mention. A tested, isolated backup is the difference between a ransomware incident being a bad week and being an existential event for a provider that can’t access medication records. We cover the discipline behind this in our guide to backup and disaster recovery for Melbourne businesses, and it applies double in aged care.

Connectivity, devices and a 24/7 operation

Connectivity that doesn’t drop at handover

A residential facility needs Wi-Fi that actually reaches every resident room, nurses’ station and medication room, and an internet connection that doesn’t take the clinical system offline when the single NBN service has a wobble. Redundant connectivity — a second link that fails over automatically — is not a luxury in a 24/7 care setting. We design facility networks with coverage and failover as the starting point, not an afterthought, and we segment the network so that resident, staff, clinical and guest traffic are properly separated.

Devices for mobile care staff

Home care support workers and roaming clinical staff need phones and tablets that are secured, enrolled and managed centrally. If a device is lost between a client visit in Ringwood and the next in Croydon, you need to remotely wipe the resident data on it within minutes — not discover it’s been sitting in someone’s glovebox unencrypted. Mobile device management through Microsoft Intune, enforced encryption, and conditional access tying sign-in to a managed device are the controls that make a fleet of field devices defensible.

Identity for a high-turnover workforce

Aged care has significant staff churn — agency staff, casuals, people moving between providers. Every starter needs the right access on day one and every leaver needs it gone the same day. Manual, ad-hoc account management is where access creep and orphaned accounts come from, and orphaned accounts are how breaches happen months after someone’s left. We run identity properly: standardised onboarding and offboarding, role-based access so a kitchen hand can’t see clinical notes, and conditional access in Microsoft 365 enforcing MFA and blocking risky sign-ins. Get identity right and a large slice of your risk disappears.

24/7 uptime expectations

Care doesn’t stop at 5pm, so neither can support. A system outage at 2am during a medication round is a clinical problem, not just an IT ticket. TechAssist runs a 24/7 network operations centre from our Tecoma office in Melbourne’s east, with a sub-15-minute response on P1 critical issues and same-business-day on-site across Melbourne metro. For a sector where downtime touches vulnerable people, those response times are the point, not a marketing line.

What good aged care IT support actually covers

TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers — no offshore helpdesk handling resident data. We price per user on a fixed monthly basis with no hourly billing for in-scope work, which matters in a sector that has to budget tightly and can’t absorb surprise IT bills. Our cybersecurity services and broader managed IT services are built to carry this kind of regulated, always-on workload.

Frequently asked questions

Do the strengthened Aged Care Quality Standards require specific IT controls?

They don’t prescribe particular products, but the governance and information-management expectations mean providers must be able to show that resident information is kept secure and access is controlled. In practice that points straight at Essential Eight controls, MFA, managed identity and tested backups — and the accountability stays with the provider, not the IT vendor.

Is our clinical software vendor responsible for security and backups?

Only for their platform. AlayaCare, Leecare, Manad Plus and iCareHealth secure and back up their own service, but everything around it — your network, devices, identity, email, and any data you hold outside their system — is yours to protect. That gap is exactly where most incidents happen and where an MSP earns its keep.

What happens if we have a data breach?

If the breach is likely to cause serious harm, it’s notifiable to the OAIC and to affected individuals under the Notifiable Data Breaches scheme, usually within 30 days of becoming aware. Having tested backups, logging and an incident response plan ready is what turns a breach from a crisis into a managed event.

Can you support providers with both residential facilities and home care?

Yes. The two models need different network and device designs but the same underlying disciplines — identity, data protection and uptime. We build for both, including the mobile-device and connectivity needs of a distributed home care workforce.

Where to start

If you’re an aged care provider unsure whether your IT would stand up to a Quality audit or a breach, the honest first step is an assessment: where your sensitive data lives, how access is controlled, whether your backups actually restore, and where the Essential Eight gaps are. Most providers we assess have two or three serious exposures they didn’t know about. Get in touch with TechAssist and we’ll give you a straight read on where you stand and what to fix first.

The right to disconnect lets employees refuse to monitor, read or respond to work contact outside their working hours unless that refusal is unreasonable. It is Fair Work law, not an IT rule. But the email, Teams and mobile settings your MSP controls are what turn a policy on paper into something that actually holds.

What the right to disconnect actually says

The right to disconnect was added to the Fair Work Act and took effect on 26 August 2024 for medium and larger employers. For small business employers (fewer than 15 employees), it commenced a year later, on 26 August 2025. So as of now, it applies across the board.

The substance is narrow but important. An employee may refuse to monitor, read or respond to contact (or attempted contact) from their employer outside their working hours, unless the refusal is unreasonable. The same applies to contact from a third party — a client, a supplier — if it relates to their work. Whether a refusal is unreasonable depends on factors the legislation spells out: the reason for the contact, how it is made and how disruptive it is, whether the employee is compensated for being available, the employee’s role and level of responsibility, and their personal circumstances including family or caring responsibilities.

Note what it does not say. It is not a ban on after-hours contact. An employer can still send a message at 9pm. What changes is that the employee is generally entitled not to engage with it until they are back on the clock, and they cannot be punished for that. Disputes are meant to be worked out at the workplace first, and if that fails, the Fair Work Commission can deal with them.

This is workplace-relations law, and the genuinely hard questions — what counts as “working hours” for a salaried manager, how an on-call allowance is structured, what your enterprise agreement or award says — are HR and legal questions. Get advice on those. What we deal with as a Melbourne MSP is the layer underneath: the systems that decide whether a notification lands on someone’s phone at all, and whether your roster and monitoring arrangements line up with what you have told staff.

The IT controls that make a policy real

A right to disconnect policy that says “please don’t email after hours” and changes nothing in Microsoft 365 is theatre. Staff still hear the buzz, still feel the pull, and the more conscientious ones still answer. The controls below are the ones that actually shift behaviour, and most of them are already sitting in your tenant waiting to be turned on.

Quiet hours and scheduled send in Outlook and Teams

Microsoft Teams has a built-in quiet hours and quiet days feature in the mobile app, so notifications are silenced outside the hours a user sets. The catch is that it is per-user and opt-in by default — most people never find it. The fix is to make it part of standard onboarding and to actually show people where the setting lives, rather than burying it in a policy PDF.

On the sending side, Outlook’s scheduled send (Delay Delivery) lets a manager who genuinely does their thinking at 10pm queue the email to land at 8am. That one habit removes most of the after-hours pressure without anyone having to ignore anything. We usually pair it with a short signature line on out-of-hours senders — something like “I work flexible hours; I don’t expect a reply outside yours” — which the Fair Work Ombudsman’s own guidance points to as good practice.

If you want notifications properly switched off rather than left to each person, that is configurable through Microsoft 365 administration and device policy. This is part of the day-to-day work in any managed Microsoft 365 environment, and it is the kind of thing worth getting right once across the whole organisation rather than user by user.

Mobile device management and conditional access

The real after-hours leak is the phone. Work email and Teams on a personal mobile means contact follows people into the lounge room. Mobile device management (through Microsoft Intune) and conditional access policies give you proper levers here.

You can enforce app protection so work data stays inside managed apps, and you can use conditional access to shape when and how people connect. For specific roles — not everyone — you can even restrict access to corporate apps to particular hours or locations, so that someone who is genuinely off the roster is not technically able to be pulled back in. Used carefully, this turns a written rule into an enforced boundary. Used clumsily, it locks out the on-call engineer at 2am, so it has to be designed around your actual roster rather than applied with a blunt instrument.

A professional services firm in Hawthorn we work with had the opposite problem to most: their junior staff were answering partner emails at all hours because the Teams app pinged their personal phones and nobody had told them they didn’t have to. The remedy was not a stern memo. It was switching most of the team to managed app access with notifications off outside business hours, leaving a small after-hours group properly resourced, and writing the policy to match what the systems now did.

On-call rosters and the compensation question

The right to disconnect bites hardest where there is no clear on-call arrangement. If you expect certain people to be reachable after hours, that should be a defined roster with an allowance or overtime attached — not a vague cultural expectation that everyone is always on. The legislation explicitly weighs whether the employee is compensated for being available when judging if a refusal is unreasonable.

From the IT side, that means your access controls and notification rules should mirror the roster. The on-call person this week gets the alerts and the access; everyone else doesn’t. We run our own 24/7 NOC out of Tecoma on exactly this model, with a defined roster and the tooling configured so the engineers who are off are genuinely off. The technology and the employment arrangement have to agree with each other, or one of them is lying.

Monitoring, alerts and overtime creep

System monitoring is where this gets subtle. Automated alerts from a server, a backup job or a security tool are not “the employer contacting you” in the Fair Work sense — they are machines. But if a human is expected to act on those alerts after hours, that expectation is exactly what the right to disconnect is about, and it should be rostered and paid like any other on-call duty.

The practical move is to route after-hours monitoring to whoever is actually on call, not to a whole team’s inboxes. Alert fatigue and silent unpaid overtime usually come from the same root cause: everyone gets every alert, so everyone feels vaguely responsible at all hours. Tightening alert routing is both better security operations and a cleaner employment boundary. This is core to how a managed security operations capability should be run regardless of the legislation.

Writing a policy your systems can back up

The order of operations matters. Plenty of businesses write the policy first, then discover their systems don’t support it. Do it the other way around: decide what the systems will enforce, then write a policy that describes that reality.

A workable right to disconnect policy generally covers:

• Working hours by role — what they are, and who, if anyone, is on a defined after-hours roster.
• Contact expectations — that staff are not expected to respond outside their hours, and won’t be penalised for not doing so.
• The genuine exceptions — emergencies, the on-call roster, and how those people are compensated.
• The tools — quiet hours, scheduled send, managed notifications — and that the business has configured them, not just recommended them.
• How to raise a concern — the internal process before anything goes near the Fair Work Commission.

The wording and the workplace-relations judgement calls belong with your HR adviser or employment lawyer. The Fair Work Ombudsman publishes plain-English guidance on the right to disconnect that is a sensible starting point for that conversation. Our job is the other half: making sure the tenant settings, device policies and alerting genuinely do what the document claims. When we take on a new client we treat this as part of the broader managed IT baseline, alongside the security and identity controls that touch the same systems.

Frequently asked questions

Does the right to disconnect ban after-hours emails?

No. Employers can still send messages outside working hours. What the law changes is that employees are generally entitled not to monitor or respond to them until they are back at work, and they can’t be disadvantaged for that — unless their refusal is unreasonable in the circumstances. Scheduled send is the easy way to avoid the issue entirely.

Does it apply to my small business?

Yes. The right to disconnect commenced on 26 August 2024 for employers with 15 or more employees and on 26 August 2025 for small business employers under 15 staff. Both dates have now passed, so it applies regardless of size.

Can IT settings actually enforce this?

To a large degree, yes. Quiet hours in Teams, managed-app notifications through Intune, and conditional access policies can stop most after-hours pings reaching staff who aren’t on call. They can’t make legal judgements about what’s reasonable, but they remove the temptation and the pressure that cause the problem in the first place.

What about our on-call engineers and after-hours support?

Genuine on-call work is fine — it just needs to be a defined roster with proper compensation, and your access and alert routing should match it so only the on-call person is pinged. The law specifically considers whether someone is paid for being available when deciding if declining contact is reasonable.

Is this a security or a compliance issue?

It is primarily a workplace-relations issue, so the policy and any disputes are HR and legal territory. But the controls that make it work — identity, device management, conditional access, alert routing — are the same ones that underpin your security posture, which is why it tends to land on the IT plate.

Where TechAssist fits

We’re a Melbourne MSP, founded in 2014, with 13 Australian-employed engineers — no offshore call centre — and we run this kind of configuration work across professional services, construction, manufacturing and healthcare clients every week. The right to disconnect is one of those rules where the legal text is short but the implementation lives entirely in settings most businesses have never opened.

If you want your Microsoft 365 tenant, mobile device policies and after-hours alerting set up so they actually back the policy you’re putting in writing, get in touch. We’ll handle the IT half; pair it with your HR adviser for the rest.

SOC 2 is an independent attestation report, produced under American Institute of Certified Public Accountants (AICPA) standards, that tells your customers an external auditor has examined your security controls. It is not a certification you pass. For Australian SaaS firms selling into the US or to enterprise buyers, it has become the price of entry.

If you build software in Melbourne and your sales pipeline runs through US accounts or large Australian enterprises, you have probably hit a security questionnaire that asks one blunt question: “Do you have a SOC 2 report?” The honest answer for most early-stage Australian SaaS companies is no, and that “no” stalls deals. This post explains what SOC 2 actually is, how it differs from ISO 27001, what the audit involves, and what it realistically costs in time and money.

What SOC 2 actually is

SOC 2 (System and Organization Controls 2) is a reporting framework owned by the AICPA. A licensed CPA firm examines how you manage customer data and issues a report describing your controls and whether they were designed, and in some cases operating, effectively. The deliverable is a report, not a logo or a certificate. You cannot self-certify, and there is no central registry to check against — your customers read the report under NDA.

The report is built around the Trust Services Criteria. There are five of them, and you choose which apply to your business:

• Security — the only mandatory criterion (often called the “common criteria”). Covers access control, change management, risk assessment, monitoring and incident response.
• Availability — uptime, performance monitoring, disaster recovery. Relevant if you make uptime commitments in SLAs.
• Processing Integrity — data is processed completely, accurately and on time. Matters for payments, payroll or anything that transforms data.
• Confidentiality — protection of information designated as confidential, including encryption and retention controls.
• Privacy — collection, use, retention and disposal of personal information in line with your privacy notice.

Most SaaS companies scope their first report to Security alone, then add Availability and Confidentiality once customers ask. Privacy is the least commonly included because, for Australian companies, the Privacy Act 1988 and the Australian Privacy Principles already govern that ground — and bolting it onto SOC 2 adds work for limited buyer benefit.

Type I versus Type II

This distinction trips people up, so be clear on it before you commission anything.

A Type I says “on 30 June, these controls were in place and well designed.” A Type II says “across the six months to 30 June, these controls ran and here is the audit evidence.” Serious buyers want Type II. Many Australian SaaS firms do a Type I first to demonstrate progress to a waiting prospect, then run a Type II over the following six to twelve months. That is a sensible path, but do not expect a Type I alone to clear an enterprise security review.

Why Australian SaaS companies pursue it

The driver is almost always commercial, not regulatory. SOC 2 is not law anywhere — it is a market expectation that crystallised in US procurement and has spread to large Australian buyers running mature vendor risk programmes.

If your product touches a customer’s data and you want to sell to a US fintech, a healthcare platform, or any ASX-listed enterprise, their security team will ask for a SOC 2 Type II report early in the process. Without one you get stuck in a back-and-forth of bespoke questionnaires, and procurement treats you as a higher-risk vendor. The report short-circuits all of that: it answers most of the questionnaire in one document and signals that you take security seriously enough to pay an auditor to check.

A logistics-tech startup in Cremorne we work with hit exactly this wall — a US enterprise prospect wouldn’t progress past security review without a Type II, and the deal was large enough that the audit cost was a rounding error against the contract value. That is the usual shape of it: SOC 2 pays for itself the moment it unlocks one enterprise account.

SOC 2 versus ISO 27001

This is the question every founder asks, and the honest answer is that they overlap heavily but serve different audiences.

The control sets behind them are largely the same — access management, change control, risk assessment, vendor management, incident response. The difference is the wrapper. SOC 2 is an auditor describing and testing your controls; ISO 27001 certifies that you run a documented Information Security Management System that continuously improves.

Do you need both?

If your buyers are overwhelmingly North American, SOC 2 alone is usually enough. If you sell into Europe, the UK and Australia, ISO 27001 carries more weight and is the more recognised brand. Plenty of Australian SaaS companies end up doing both because their customer base spans regions — and the marginal effort is smaller than it looks, since one set of controls and one evidence library can support both audits. Build the controls once, attest and certify twice. If you are weighing the options, our cybersecurity services team can map your buyer base to the right framework before you spend a cent on auditors.

The audit process and the role of a security partner

A SOC 2 engagement has two distinct phases, and conflating them is where budgets blow out.

Readiness

Readiness is everything you do before the auditor arrives. You define scope, write or tidy policies, implement the controls, and stand up the tooling that proves they work — multi-factor authentication everywhere, centralised logging, formal access reviews, change management tied to your code pipeline, vendor risk records and an incident response plan you have actually tested. For most Australian SaaS companies this is the real work, and it is where an MSP or security partner earns its fee. The auditor will not help you fix gaps; their job is to observe, not advise.

This is what a security partner does in readiness: run the gap assessment against the Trust Services Criteria, prioritise the controls that matter, deploy the technical guardrails, and set up evidence collection so you are not scrambling at audit time. Much of the Security criterion overlaps with hardening work we already do for clients — the Essential Eight mitigation strategies map cleanly onto SOC 2’s access control, patching and application hardening expectations, so if you are already Essential Eight aligned you are further down the road than you think.

Evidence collection and continuous controls

Type II is won or lost on evidence. The auditor samples across the monitoring period and asks for proof that each control operated every time it should have — access reviews completed each quarter, every code change approved, every alert triaged, every offboarding done within policy. If those records do not exist, the control fails for the period regardless of how good your intentions were.

This is why continuous controls monitoring matters. Compliance automation platforms such as Vanta, Drata or Secureframe connect to your cloud, identity provider and code repositories and collect evidence automatically, flagging drift the moment a control slips. They do not make you compliant — they make the evidence trail survivable. A partner who already runs your SIEM and managed detection stack is well placed to wire these tools into your environment and keep the controls green between audit windows. TechAssist runs a 24/7 NOC out of Tecoma and our engineers are Australian-employed, so the monitoring that underpins your evidence is staffed locally, not handed to an offshore queue.

Realistic timeline and cost

Be wary of anyone promising SOC 2 in a few weeks. Here is the honest shape of it for an Australian SaaS company starting from a reasonable baseline.

• Readiness: two to four months for an early-stage company with decent foundations; longer if your access controls and logging are immature.
• Type I report: issued shortly after readiness, reflecting a point in time.
• Type II monitoring window: three months at minimum, but six to twelve months is what enterprise buyers expect to see.
• Annual reissue: SOC 2 is not one-and-done. A Type II report covers a stated period, so you run a fresh audit each year to keep a current report on hand.

On cost, the auditor’s fee for a Type II from a reputable CPA firm typically runs into the tens of thousands of dollars (AUD), and that is before tooling and the internal or partner effort to get ready. Compliance automation platforms add an annual subscription. The readiness work — the controls, the policies, the engineering — is usually the larger line item, especially the first time through. Budget for the whole programme, not just the audit invoice, and treat year one as the expensive one.

Frequently asked questions

Is SOC 2 a certification?

No. It is an attestation report issued by a CPA firm under AICPA standards. There is no certificate and no public registry — you receive a report describing your controls and the auditor’s opinion, which you share with customers under NDA. Calling it a “certification” is common shorthand, but technically wrong.

Should an Australian company do SOC 2 or ISO 27001?

It depends on who buys from you. North American buyers expect SOC 2; European, UK and Australian buyers lean on ISO 27001. If your customer base spans both, doing both is common and the underlying controls are largely shared, so the second framework costs far less effort than the first.

Does SOC 2 satisfy Australian privacy law?

Not on its own. The Privacy Act 1988 and the Australian Privacy Principles still apply to your handling of personal information regardless of any SOC 2 report. SOC 2 can include a Privacy criterion, but it is a US framework — it is not a substitute for meeting your obligations under Australian law.

Can an MSP get us SOC 2 ready?

A security partner can run the gap assessment, implement and harden the controls, stand up evidence collection and keep controls monitored continuously between audits. The CPA auditor must remain independent, so the same firm cannot both prepare you and issue the report — but the readiness work is exactly where an MSP adds value.

Where TechAssist fits

We are a Melbourne MSP, founded in 2014, with thirteen Australian-employed engineers. We do not issue SOC 2 reports — that is the auditor’s job, and it has to stay independent — but we do the readiness and the continuous controls work that gets you there and keeps you there. That means hardening your Microsoft 365 and cloud environment, standing up logging and detection, wiring in compliance automation, and making sure the evidence trail your auditor samples actually exists every time. If a SOC 2 report is gating your next enterprise deal, get in touch and we will map the gap before you commit to an audit timeline.

An IRAP assessment is an independent security evaluation of a system against the Australian Government’s Information Security Manual. It does not certify or pass a system. It produces a report that a government entity uses to make its own risk-based decision about whether to let your product handle its data.

That distinction trips up a lot of Melbourne SMEs chasing their first government contract. They hear “you need IRAP” and assume it works like an ISO certificate you hang on the wall. It doesn’t. If you’re selling cloud, SaaS or managed services into a Commonwealth or state agency, understanding what IRAP actually is — and what it isn’t — saves you a lot of wasted money and a few uncomfortable conversations with a procurement officer.

What IRAP actually is

IRAP stands for the Infosec Registered Assessors Program. It’s run by the Australian Signals Directorate (ASD) through the Australian Cyber Security Centre (ACSC). ASD endorses a pool of independent assessors — IRAP assessors — who are trained and authorised to evaluate the security of ICT systems against Commonwealth requirements.

The benchmark those assessors measure against is the ASD Information Security Manual (ISM). The ISM is a large, regularly updated document of security controls covering everything from cryptography and access control to physical security and personnel vetting. When an IRAP assessor reviews your system, they’re checking how it implements the relevant ISM controls for the classification of data it will handle.

The critical thing to grasp: an IRAP assessor produces a security assessment report. They document what controls are in place, what’s missing, what the residual risks are, and how well the system aligns to the ISM. They do not issue an “IRAP certified” stamp. There is no pass mark. The assessor’s job is to give a clear, evidence-based picture of the system’s security posture so that someone else can make a decision.

The classification levels you’ll hear about

Australian Government data is classified by the damage its compromise would cause. For most SMEs selling into government, three levels matter:

• OFFICIAL — routine government information, the bulk of day-to-day public sector data. Low sensitivity.
• OFFICIAL:Sensitive — information that needs limited dissemination because its compromise could cause limited damage (personal information, commercially sensitive material, some law enforcement data).
• PROTECTED — information whose compromise could cause damage to the national interest, organisations or individuals. This is the first of the security-classified tiers and the threshold where IRAP work gets serious.

Above PROTECTED sit SECRET and TOP SECRET, but if your business is operating at those levels you’re not reading a blog post to work out what to do next. For the overwhelming majority of Melbourne SMEs, the conversation is about OFFICIAL, OFFICIAL:Sensitive or PROTECTED. The higher the classification, the more ISM controls apply and the more rigorous the assessment.

Assessment, not certification — why it matters

This is the single most misunderstood part of the whole process, so it’s worth being blunt about it.

IRAP gives the agency an assessment. The agency itself — specifically its authorising officer — then makes the authorisation decision: do we accept the residual risk of using this system for our data, or don’t we? That decision is theirs, based on their risk appetite, their other controls, and the criticality of the data involved.

Two agencies can read the same IRAP report and reach different decisions. One might authorise your platform for OFFICIAL:Sensitive data; another might decline pending remediation of a control you didn’t think mattered. The report is the input. The risk-based authorisation is the output, and it doesn’t belong to you or your assessor.

So when a salesperson tells you their product is “IRAP certified”, they’re using shorthand that doesn’t really exist. What they usually mean is that the product has been through an IRAP assessment at a particular classification level. Whether that’s enough for your target agency is a separate question.

The gap between “we use a PROTECTED cloud” and “our system is assessed”

Here’s where we see Melbourne businesses come unstuck. A construction-tech firm in Cremorne we work with had built a project management SaaS product on Microsoft Azure. They’d seen that Azure has Australian regions assessed at PROTECTED, and they went to a government tender assuming that covered them. It didn’t.

Running on a PROTECTED-assessed cloud platform means the underlying infrastructure has been assessed. It says nothing about your application sitting on top of it — your code, your access controls, your data flows, your administrative practices, your logging, your backup arrangements. The cloud provider’s assessment covers their layer of the stack. Yours is still unassessed.

This is the shared responsibility model, and IRAP follows it precisely. Microsoft, AWS and others publish their IRAP assessment reports for their platforms. That’s genuinely useful — it means the infrastructure layer is a known quantity and you inherit a set of controls. But the agency buying your SaaS wants to know that the whole system, including your part of it, meets the ISM at the required classification. Inheriting controls from your provider is the start of the work, not the end of it.

A useful way to frame it internally: the cloud provider’s IRAP report answers “is this platform secure enough to build on?” Your IRAP report answers “is the thing we built actually secure?” You need the second one to win the contract.

When does a Melbourne SME actually need IRAP?

You need to engage with IRAP when you’re selling a system that will store, process or transmit government data — typically a cloud or SaaS product, but also managed services where your staff touch the agency’s information. The trigger is usually written into the tender or contract: the agency requires an IRAP assessment at OFFICIAL:Sensitive or PROTECTED before they’ll let your system handle their data.

You probably don’t need it if:

• You’re selling a one-off product or hardware with no ongoing access to government data.
• The agency is consuming your service entirely within their own assessed environment.
• You’re a sub-supplier and the prime contractor carries the assessment obligation (check this carefully — sometimes it flows down to you).

For a lot of SMEs, the honest answer is “not yet, but soon”. If government is on your roadmap, building to the ISM early is far cheaper than retrofitting later. Much of the groundwork — proper identity and access management, hardened Microsoft 365, comprehensive logging, documented backup and recovery — overlaps heavily with the Essential Eight and with general security maturity you should be pursuing regardless. We cover the foundations in our guide on getting Essential Eight aligned in 90 days, and a lot of that work is directly reusable as IRAP evidence.

How the process works

An IRAP assessment isn’t a single audit you book and pass. It runs in stages.

1. Scoping. You define the system boundary — exactly what’s being assessed — and the target classification. Get this wrong and you’ll either over-spend assessing things that don’t need it, or under-scope and fail to cover what the agency cares about.
2. Documentation and control implementation. You build the security documentation set: a System Security Plan, risk assessment, incident response plan, and so on. Crucially, you actually implement the ISM controls. This is where most of the cost and calendar time lives.
3. Stage 1 assessment. The IRAP assessor reviews your design and documentation against the ISM and identifies gaps before you’ve gone too far.
4. Stage 2 assessment. The assessor tests and verifies that controls are genuinely implemented and effective — not just written down. They produce the security assessment report.
5. Authorisation. You hand the report to the agency. Their authorising officer makes the risk-based decision and, if satisfied, grants authority to operate for the relevant data.

It doesn’t end there. Authorisations are time-bound and the ISM changes. You’ll need to maintain your controls, monitor continuously, and re-assess periodically. IRAP is an ongoing commitment, not a one-time hurdle.

Be honest about the cost and effort

This is not a cheap or quick exercise, and anyone telling you otherwise hasn’t done one. The assessor’s fee alone for a PROTECTED assessment of a non-trivial system commonly runs well into five figures and can reach into six. But the assessor’s invoice is the small part.

The real cost is the remediation and documentation work to get your system ISM-ready before the assessor arrives. For most SMEs that’s months of engineering and governance effort: implementing controls, writing the security plan, building the logging and monitoring, hardening identity, formalising change management. If you go into the assessment unprepared, you’ll pay the assessor to tell you what you already should have known, then pay again for the re-assessment after you fix it.

Where TechAssist fits

We’re a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma. We’re not an IRAP assessor — and you should be wary of anyone who both prepares your system and assesses it, because that’s a conflict of interest the ISM frowns on. What we do is the readiness work: getting your environment to the standard where an independent IRAP assessment goes smoothly rather than turning into an expensive list of findings.

That means hardening your Microsoft 365 tenant, implementing the access controls and logging the ISM expects, building the backup and recovery posture, and documenting it all so the assessor has evidence rather than promises. Because we run fixed monthly managed IT with Australian engineers, the same team that maintains your environment is the team that prepares it for assessment — there’s no offshore handoff and no hourly meter running while you scope the work.

Frequently asked questions

Is there such a thing as “IRAP certification”?

No. IRAP produces a security assessment report against the ISM. The government entity makes the authorisation decision. “IRAP certified” is common shorthand, but technically there’s no certificate — there’s an assessment and an agency’s risk-based authority to operate.

Does running on Azure or AWS PROTECTED regions cover my SaaS?

No. The cloud provider’s IRAP assessment covers their infrastructure. Your application, configuration, access controls and processes sitting on top still need their own assessment. You inherit some controls, but the system you built is your responsibility under the shared responsibility model.

How long does an IRAP assessment take?

The assessment activity itself can be weeks, but realistic preparation — implementing ISM controls and producing the documentation — typically runs several months for an SME doing it properly the first time. The clock is dominated by readiness work, not the assessor’s review.

Do small businesses ever really need this?

Yes, if you’re selling cloud, SaaS or services that touch government data at OFFICIAL:Sensitive or PROTECTED. The requirement is usually in the tender. If government is on your roadmap, building to the ISM and the Essential Eight early makes the eventual assessment dramatically cheaper.

Can an MSP do the IRAP assessment for us?

Only an ASD-endorsed IRAP assessor can perform the assessment, and they should be independent from whoever prepared your system. An MSP like us does the readiness and remediation; a separate IRAP assessor does the evaluation. Keeping those roles separate protects the integrity of the report.

If government work is on your horizon and you’re not sure how far your current environment is from ISM expectations, get in touch. We’ll give you an honest read on the gap before you spend a cent on an assessor.

If your business gets hit by a data breach that’s likely to seriously harm the people whose data you hold, the law gives you a tight window: assess it fast, then notify the regulator and the affected individuals as soon as practicable. Get the timing wrong and the penalties now run into the millions.

That’s the short version of the notifiable data breaches scheme, and it catches far more Melbourne SMEs than most directors realise. Here’s what it actually requires, who it covers, and the incident-handling steps you should have ready before anything goes wrong.

What the NDB scheme actually is

The notifiable data breaches scheme sits under Part IIIC of the Privacy Act 1988 (Cth) and has been in force since February 2018. It’s administered by the Office of the Australian Information Commissioner (OAIC). The core obligation is simple to state and harder to live by: if you experience an eligible data breach, you must notify both the OAIC and every affected individual.

It isn’t a “tell us if you feel like it” arrangement. Notification is mandatory once the threshold is met, and the clock starts the moment you have reason to suspect something has gone wrong. The scheme exists so people can take protective steps — change passwords, watch their bank accounts, put a credit ban in place — before stolen data is used against them.

Who the Privacy Act covers

The Act applies to “APP entities” — organisations bound by the Australian Privacy Principles. The headline test is annual turnover. If your business turns over more than $3 million a year, you’re almost certainly covered. Plenty of directors stop reading there and assume they’re exempt. That’s a mistake, because the exceptions sweep in a lot of smaller operators.

You’re covered regardless of turnover if you:

• Are a health service provider that holds health information — this includes GPs, allied health, dentists, physios, psychologists and pharmacies, no matter how small the practice.
• Trade in personal information (buying or selling it).
• Are a credit reporting body or provide credit.
• Are a contractor delivering services under a Commonwealth contract.
• Are a tax file number recipient (most employers handle TFNs).

A three-chair dental practice in Camberwell with $1.2 million turnover is covered because it holds health information. A logistics broker handling TFNs and credit checks gets pulled in through those activities. The $3 million line is a floor for ordinary businesses, not a free pass for everyone under it. If you handle health data specifically, our write-up on healthcare IT support and OAIC obligations goes deeper on the sector rules.

What counts as an “eligible data breach”

Not every lost laptop or misdirected email triggers notification. An eligible data breach has three ingredients:

1. There’s unauthorised access to, or unauthorised disclosure of, personal information you hold — or that information is lost in circumstances where unauthorised access or disclosure is likely.
2. A reasonable person would conclude the breach is likely to result in serious harm to one or more affected individuals.
3. You haven’t been able to prevent that likely serious harm through remedial action.

That third point matters. If you act quickly enough that serious harm is no longer likely — say, you remotely wipe a stolen, encrypted laptop before anyone could read it — the breach may not be notifiable at all. Remediation is a genuine off-ramp, but only if it’s fast and effective.

The “serious harm” test

“Likely to result in serious harm” is the pivot the whole scheme turns on, and there’s no fixed checklist. The OAIC asks you to weigh factors including the kind of information involved (health records and financial details rank high; a publicly listed business name does not), its sensitivity, whether it was encrypted or otherwise protected, who is now likely to have it, and what they could do with it.

Serious harm can be physical, psychological, emotional, financial or reputational. A breach exposing identity documents and bank details is far more likely to clear the bar than one exposing a marketing mailing list. The judgement is yours to make, but you have to be able to defend it — the OAIC can and does ask to see your reasoning.

The timeframes you have to hit

This is where SMEs get caught out, so be precise about the two clocks.

The assessment clock. If you only suspect an eligible data breach has occurred — you’re not yet sure it clears the serious-harm threshold — you must carry out a reasonable and expeditious assessment. The word “expeditious” means you start straight away, not when it’s convenient. The Act sets an outer limit of 30 calendar days from when you became aware of the grounds for suspicion. Thirty days is a ceiling, not a target. If you can resolve it in three, do it in three.

The notification clock. Once you’ve decided you have an eligible data breach, you must notify the OAIC and affected individuals as soon as practicable. There’s no fixed day count here — “as soon as practicable” is judged on your circumstances — but it is not weeks of internal deliberation. You prepare a statement, lodge it with the Commissioner through the OAIC’s online form, and notify individuals by whatever method you normally use to contact them.

People often talk about a “72-hour rule” for data breaches. That figure comes from the EU’s GDPR, not the Australian Privacy Act. Australia’s standard is the “as soon as practicable” test, with the 30-day assessment ceiling sitting behind it. Treating 72 hours as your internal working deadline is sensible discipline — just don’t mistake it for the letter of Australian law.

The 2024 reforms and the new penalty regime

The penalties for getting this wrong are no longer trivial. Reforms that began with the Privacy Legislation Amendment (Enforcement and Other Measures) Act 2022 and continued through the Privacy and Other Legislation Amendment Act 2024 sharpened the OAIC’s teeth considerably.

For serious or repeated interferences with privacy, the maximum penalty for a body corporate is now the greater of $50 million, three times the value of any benefit obtained from the misuse of information, or 30 per cent of the entity’s adjusted turnover for the relevant period. That’s a dramatic jump from the old cap and it’s aimed squarely at organisations that treat privacy as optional.

The 2024 reforms also introduced a statutory tort for serious invasions of privacy, gave the Commissioner new mid-tier and low-tier civil penalty powers for less severe contraventions, and added powers to issue infringement notices. The practical effect for an SME: there is now a graduated enforcement ladder, so even a moderate compliance failure can attract a penalty rather than just a stern letter. Australia’s privacy framework is being progressively tightened, and the direction of travel is more obligations, not fewer.

What an SME should have ready before a breach

The businesses that handle a breach well aren’t the ones that read the Privacy Act after the fact — they’re the ones who decided in advance who does what. A data breach response plan doesn’t need to be a 40-page document. It needs to answer a handful of questions before the pressure is on.

A construction firm in Box Hill we work with discovered a compromised mailbox after a finance staffer’s credentials were phished. Because the logging was already in place, we could see exactly which messages and attachments the attacker had opened, scope the affected individuals within a day, and confirm that the exposed data did clear the serious-harm threshold. The notification went out fast and clean — not because they panicked well, but because the plan already existed. That kind of visibility is exactly what our cybersecurity services and managed detection and response are built to deliver.

Where most breaches actually start

In practice, the overwhelming majority of breaches we see trace back to compromised credentials and email — phishing, business email compromise, reused passwords. The single highest-value control for an SME is strong identity protection: multi-factor authentication everywhere, conditional access on Microsoft 365, and monitoring that flags anomalous sign-ins. Tightening identity is cheaper than any post-breach notification exercise, and it’s the foundation the Essential Eight is built on.

How TechAssist helps

TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers — no offshore helpdesk. Our 24/7 NOC operates out of Tecoma in the eastern suburbs, with a second office in the Melbourne CBD at 575 Bourke Street. When a breach is unfolding, response time is everything: we target sub-15-minute response on critical incidents, which is the difference between containing a compromise and explaining it to the OAIC.

The realistic goal isn’t never having an incident — it’s detecting fast, containing faster, and being able to make a defensible serious-harm decision inside your timeframes. If you’re not confident you could do that today, that’s the gap worth closing. Have a look at our broader managed IT services, or get in touch and we’ll pressure-test your breach readiness before something forces the issue.

Frequently asked questions

Does the NDB scheme apply to my business if I turn over under $3 million?

Possibly. The $3 million turnover threshold is the general rule, but exceptions bring in any size of business that provides health services, handles credit information, trades in personal information, or operates under a Commonwealth contract. Most healthcare providers are covered regardless of turnover.

Is there really a 72-hour deadline to report a data breach in Australia?

No — the 72-hour figure is a GDPR (European) rule. Under the Australian Privacy Act you must notify the OAIC and affected individuals “as soon as practicable” after deciding you have an eligible data breach, and you have up to 30 days to assess a suspected breach. Acting within 72 hours is good practice, not the legal test.

What if I fix the breach quickly — do I still have to notify?

Not necessarily. If you take remedial action fast enough that serious harm is no longer likely, the breach may not be “eligible” and notification isn’t required. The catch is that the remediation has to genuinely remove the risk, and you need to document why it did.

Who do I actually notify, and how?

You notify the OAIC by lodging a statement through its online Notifiable Data Breach form, and you notify affected individuals directly using your usual contact method. If you can’t reasonably contact individuals one by one, you publish the statement and take steps to publicise it.

What happens if I don’t comply?

Failing to comply is an interference with privacy and can attract enforcement by the OAIC. Following the 2024 reforms, penalties for serious or repeated breaches reach the greater of $50 million, three times any benefit gained, or 30 per cent of adjusted turnover — alongside new mid- and low-tier penalty powers for lesser failures.

CPS 234 is APRA’s prudential standard on information security. It binds banks, insurers and superannuation funds, and through them their third-party providers. Core duties: maintain real security capability, define who owns what, implement and test controls, and notify APRA within 72 hours of a material incident. If you supply a regulated entity, you are in scope by flow-down.

Who CPS 234 actually applies to

The Australian Prudential Regulation Authority (APRA) regulates the entities that hold the country’s deposits, insurance pools and retirement savings. CPS 234 has applied to all of them since 1 July 2019. The list of APRA-regulated entities covers authorised deposit-taking institutions (banks, building societies, credit unions), general and life insurers, private health insurers, and registrable superannuation entity licensees.

If you run one of those, none of this is news. The part that catches Melbourne SMEs out is the flow-down. CPS 234 explicitly requires a regulated entity to manage the information security of the third parties it relies on. The standard says the board of the regulated entity is ultimately responsible for information security, and that responsibility does not evaporate when data or systems are handed to a vendor. So the obligation lands on the regulated entity, and the regulated entity pushes it down the supply chain in the form of contract clauses, security questionnaires and audit rights.

That is how a 25-person fintech in Cremorne, a claims-processing bureau in Box Hill, or a SaaS company that sells loan-origination software to a credit union ends up answering a 200-line security assessment. You are not directly regulated by APRA. But your customer is, and they cannot meet their own CPS 234 obligations unless you can demonstrate you handle their information security to a comparable standard.

The four obligations that matter

Strip away the prudential language and CPS 234 asks regulated entities (and, by extension, the providers they lean on) to do four things.

1. Maintain information security capability commensurate with the threats

This is not a checkbox. APRA wants the size and maturity of your security capability to match the sensitivity of the information you hold and the threat environment you operate in. A provider holding superannuation member data and bank account details is expected to have stronger controls than one handling a low-risk marketing list. Capability here means people, processes and technology — not a firewall and a hope.

2. Clearly define information security roles and responsibilities

Someone has to own this. The standard requires roles and responsibilities for information security to be clearly defined across the board, senior management, governance bodies and individuals. In practice that means a named accountable person, documented responsibilities, and no “we assumed IT was handling it”. For an SME supplier, this is often the single biggest gap — security is everyone’s job, which means it is nobody’s job, until a regulated customer asks who owns it.

3. Implement controls and test them regularly

You must implement information security controls to protect assets, and — this is the part people skip — systematically test the effectiveness of those controls. Testing has to be proportionate to the rate of change in vulnerabilities and threats, the criticality of the assets, and the consequences of a breach. Controls that have never been tested are assumptions, and APRA does not accept assumptions. This is where penetration testing, control reviews and internal audit come in.

4. Notify APRA within 72 hours of a material incident

A regulated entity must notify APRA no later than 72 hours after becoming aware of an information security incident that materially affected, or had the potential to materially affect, the entity or the interests of depositors, policyholders or members. There is also a 10-business-day window to notify APRA of a material information security control weakness the entity cannot remediate in time. For a third-party provider, the practical effect is that your incident at 2am becomes your customer’s regulatory clock. If you sit on a breach for a week, you have blown their 72-hour notification before they even knew.

CPS 234 and CPS 230: how they fit together

CPS 234 does not exist on its own anymore. APRA’s newer operational risk standard, CPS 230, came into force on 1 July 2025, and it widens the lens considerably. Where CPS 234 is squarely about information security, CPS 230 is about operational resilience across the board — operational risk management, business continuity, and the management of material service providers.

The overlap that matters for suppliers is the service-provider piece. CPS 230 requires regulated entities to maintain a register of material service providers, conduct due diligence, manage the risks those providers introduce, and have contracts that meet a defined set of requirements. If you were already feeling the squeeze from CPS 234 flow-down, CPS 230 tightens it: your regulated customers now have a formal, examinable obligation to assess and monitor you as a material service provider.

Read together, the two standards say the same thing to a supplier: a regulated customer is now contractually and prudentially obliged to know how you protect their data and how you keep running when something goes wrong. Vague answers cost you the contract.

Why a Melbourne professional-services or fintech SME gets pulled in

We see this pattern across our professional-services and fintech clients. The business has no direct line to APRA, has never read a prudential standard, and assumes compliance is the bank’s problem. Then a deal with an APRA-regulated entity reaches procurement, and the security questionnaire arrives. Suddenly the SME is asked to evidence things it has never documented.

A fintech in Richmond we work with builds reporting tools for a superannuation fund. They had solid engineering and genuinely good security instincts, but nothing written down. The fund’s vendor risk team, working to CPS 234 and now CPS 230, wanted documented roles, evidence of control testing, a tested incident response plan with a 72-hour notification commitment baked into the contract, and proof that access to member data followed least privilege. The technology was fine. The governance evidence did not exist, and that nearly killed the deal.

The flow-down is rarely negotiable. The regulated entity cannot waive its own obligation, so it cannot accept “trust us” from a supplier. If you cannot demonstrate the controls, you do not get added to the approved-vendor register, and the contract goes to a competitor who can.

What to do about it

The good news: meeting the substance of a CPS 234 flow-down is the same work that meets the Essential Eight and most cyber-insurance requirements. You are not building a separate program; you are documenting and testing one. A practical order of operations:

1. Assign ownership. Name an accountable person for information security in writing, even if it is the director. This single step answers the most common question on every vendor assessment.
2. Document your controls. Map what you actually do — multi-factor authentication, patching cadence, access management, logging, backups — against a recognised framework. The Australian Cyber Security Centre (ACSC) Essential Eight is the most defensible baseline for an Australian SME, and it maps cleanly onto CPS 234’s control expectations.
3. Test the controls. Run a penetration test and a control review so you can show evidence, not assertions. CPS 234’s testing obligation is the one suppliers most often fail to evidence.
4. Write and rehearse an incident response plan. Include a contractual notification commitment that lets your regulated customer hit their 72-hour APRA deadline. Practise it — a plan nobody has run is the same as no plan.
5. Get the contract language right. Expect audit rights, sub-contractor disclosure, data-handling terms and breach-notification timelines. Have these reviewed before you sign.

For most SMEs in this position, the bottleneck is not the technology — it is having the security capability, the documentation and the testing evidence to put in front of a sharp vendor-risk reviewer. That is the work an MSP does day to day. We run this for clients through our cybersecurity services and, where the governance side needs ownership, our virtual CIO function, both backed by 13 Australian-employed engineers and a 24/7 NOC out of Tecoma. Essential Eight alignment and ISO 27001-capable processes mean the evidence is there when the questionnaire lands, not scrambled together the week it is due.

Frequently asked questions

Does CPS 234 apply directly to my business?

Only if you are an APRA-regulated entity — a bank, insurer, private health insurer or superannuation licensee. If you supply one of those, CPS 234 does not bind you directly, but it reaches you through contract flow-down because your customer must manage your information security to meet its own obligation. The practical effect is the same: you have to evidence your controls.

What counts as a material information security incident?

One that materially affected, or had the potential to materially affect, the regulated entity or the interests of its depositors, policyholders or members — for example a breach exposing customer financial data or a ransomware event taking down a critical system. The regulated entity makes that call, but as their supplier your job is to report any incident to them fast enough that they can meet the 72-hour APRA window.

How is CPS 230 different from CPS 234?

CPS 234 is about information security specifically. CPS 230, in force since 1 July 2025, is broader — operational risk, business continuity and the management of material service providers. For suppliers, CPS 230 adds formal due diligence, a material service provider register and stricter contract requirements on top of the CPS 234 security expectations.

How long does it take to get ready for a vendor security assessment?

If your controls are genuinely sound and only the documentation is missing, a focused program of assigning ownership, documenting controls, running a penetration test and writing an incident response plan typically takes weeks, not months. If the underlying controls have real gaps, plan for longer. Either way, start before the deal reaches procurement, not after.

The short version

CPS 234 makes APRA-regulated entities responsible for their own information security and for the security of everyone they hand data to. That responsibility flows down to suppliers as contract terms, questionnaires and audit rights, and CPS 230 has only tightened the grip. If you are a Melbourne professional-services or fintech SME selling into financial services, the requirements will find you whether or not you have read the standard. The fix is to treat security as documented, tested and owned — not assumed. If you want help getting evidence-ready before the next questionnaire arrives, get in touch and we will map where you stand.