IT Support for Insurance Brokers

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

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

What general insurance brokers actually run

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

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

Cluster and network group requirements

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

AFSL, ASIC and the obligations behind the IT

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

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

Client financial and personal data under the Privacy Act

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

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

Business email compromise: the threat aimed straight at brokers

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

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

The defences are unglamorous and they work:

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

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

Cyber insurance underwriting expectations — yes, for brokers too

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

The questions you can expect:

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

Document management and the renewals workflow

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

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

A Melbourne example

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

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

Frequently asked questions

Does the Privacy Act apply to a small insurance broker?

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

What is the biggest IT risk for a broking firm?

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

Will better IT lower our cyber insurance premium?

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

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

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

Getting it right without overspending

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

Financial planning firms sit on a pile of sensitive client data — tax file numbers, super balances, estate details, bank accounts — under an AFSL, the Privacy Act and ASIC’s watch. Good financial planning IT support keeps Xplan and your platforms running, locks down email against payment fraud, and gives you a defensible security position when a licensee audit or a breach lands.

The risk profile is specific. Advisers move money on client instruction, hold years of sensitive records they are legally required to retain, and increasingly run their whole practice through cloud financial-planning software and CRM. That combination — money, sensitive data and email — is exactly what attackers target. Getting the IT right is not a nice-to-have for a planning firm; it is part of meeting your obligations as a licensee.

What sits behind an AFSL

If you provide personal financial advice you operate under an Australian Financial Services Licence, either your own or as an authorised representative of a dealer group. ASIC’s licensing obligations under the Corporations Act require you to have adequate resources and risk-management systems, and ASIC has been explicit that this includes cyber resilience. The RI Advice case made the point clearly — a licensee was found to have breached its obligations by failing to have adequate cyber-security risk management across its authorised representatives. Cyber is not treated as separate from your licence conditions; it is part of them.

For most planning firms that means you need to be able to show, not just assert, that you have controls in place: access management, multi-factor authentication, patching, backups, an incident response plan and oversight of the third parties handling client data. The Australian Cyber Security Centre (ACSC) Essential Eight is the sensible framework to anchor that against, and it maps cleanly onto what ASIC expects a well-run licensee to do. We cover the practical rollout in our guide to Essential Eight compliance in 90 days.

The Privacy Act and sensitive financial data

Planning firms hold some of the most sensitive personal information there is. The Privacy Act 1988 and the Australian Privacy Principles apply to most advice businesses, and the data you hold — tax file numbers, financial position, health information gathered for insurance advice — attracts a high level of protection. TFNs carry their own handling rules on top of the APPs.

Under the Notifiable Data Breaches scheme, a breach involving client financial records that is likely to cause serious harm must be assessed and, where required, reported to the Office of the Australian Information Commissioner (OAIC) and to affected clients. A compromised adviser mailbox full of statements of advice and identity documents is precisely the scenario that scheme exists for. The practical defence is unglamorous: encrypt devices, control access, keep a record of who can see what, and back everything up. We walk through breach obligations in more detail in our overview of our cybersecurity services.

The software stack: Xplan, CRM and platform integrations

Most Melbourne planning practices run on a financial-planning platform plus a CRM plus a stack of integrations into investment platforms. The common tools are Xplan (Iress), AdviserLogic and Midwinter for advice generation, modelling and statements of advice, sitting alongside CRM and document management. Those connect outward to platforms such as HUB24, Netwealth, BT Panorama and the major fund administrators, and inward to your Microsoft 365 environment.

Because the core tools are SaaS, the vendor secures the application. Your obligations do not disappear. You still own the accounts, the devices, the network, the data feeds and the backup of anything outside the platform. The recurring weak spots we find in advice firms:

• Shared or generic logins to Xplan or the CRM, instead of an individual account per adviser and support staff member.
• No multi-factor authentication on the practice-management platform or on Microsoft 365, so a single phished password gives an attacker the lot.
• Platform data feeds and document integrations configured once and never reviewed, with credentials that outlast the staff who set them up.
• Statements of advice, fact-finds and scanned ID documents sitting in a Downloads folder or a personal OneDrive rather than the managed system.

The IT job is making each of those integrations authenticated, monitored and owned, and making sure access is tied to individuals so it can be revoked the day someone leaves.

Email security and business email compromise

This is the single biggest financial risk a planning firm carries, and it deserves its own section. Business email compromise is where an attacker gets into — or convincingly impersonates — a mailbox and uses it to redirect money. For an advice firm the danger is payment and rollover instructions: a client emails asking to redeem an investment or change their nominated bank account, the adviser actions it, and the instruction was never really from the client. Or the attacker is inside the adviser’s mailbox, watching, and inserts fraudulent account details at the moment a genuine payment is due.

The controls that actually reduce this risk are layered:

• MFA on every mailbox, enforced through conditional access, so a stolen password alone is not enough. Our piece on conditional access policies in Microsoft 365 covers how to do this without making sign-in painful.
• Mailbox monitoring and alerting on the inbox rules attackers create to hide their tracks — auto-forwarding and “move to RSS feeds” rules are classic tells.
• A hard process rule: any change to client bank details or any payment instruction received by email is verified by a phone call to a known number, never to the number in the email.
• SPF, DKIM and DMARC configured so attackers cannot easily spoof your domain to your clients.

The technology stops most of it. The verbal-verification process catches what gets through. We go deeper on this in our article on business email security, phishing and BEC.

MFA, conditional access and identity

Identity is the perimeter for a cloud-based advice firm. Multi-factor authentication on every account that touches client data is the non-negotiable baseline — Microsoft 365, the planning platform, the CRM and the investment platforms. Conditional access then lets you go further: block sign-ins from outside Australia, require a managed and compliant device, and step up verification for risky logins. For a firm where a single mailbox compromise can move client money, this is the control that earns its keep. It also aligns with the zero-trust thinking we explain in our zero-trust security model overview.

Data retention and client portals

Advice firms have to keep records, and keep them a long time. Under the Corporations Act and ASIC’s rules, advice documents — including statements of advice and records of the advice given — must generally be retained for at least seven years, and fee disclosure and ongoing-service records carry their own retention requirements. That is a long time to keep sensitive data safe, searchable and recoverable.

The IT implications are straightforward but easy to neglect. Retained records need to live in managed, backed-up systems, not on a departed adviser’s laptop. Microsoft 365 retention is not a backup — it protects against some accidental deletion but will not save you from a compromised account wiping data or a malicious deletion. A dedicated backup of email, OneDrive and SharePoint is essential, and our data backup and recovery service is built around exactly this. Knowing your recovery targets — how long you could operate without systems (RTO) and how much data you could lose (RPO) — turns “we have backups” into something you can actually rely on.

Client portals are increasingly how firms share statements of advice, fact-finds and annual reviews securely instead of by email attachment. A properly configured portal — whether built into your platform or layered on Microsoft 365 — reduces the BEC risk and gives clients a defined place to upload identity documents. The catch is that a portal is only as secure as the identity controls behind it, which brings us back to MFA.

Where APRA CPS 234 flows down to you

Most standalone advice firms are not APRA-regulated. But the moment you serve, or sit inside the supply chain of, an APRA-regulated entity — a super fund, an insurer, an RSE licensee — their obligations under APRA CPS 234 start to flow down to you. CPS 234 requires regulated entities to manage the information-security capability of third parties that handle their data, which means they will push contractual security requirements onto their advice partners and service providers. In practice that shows up as security questionnaires, evidence requests and clauses requiring you to maintain defined controls and notify them of incidents. If you receive feeds from or share data with a regulated platform, expect this. We unpack the standard in our explainer on information security and CPS 234, and being Essential Eight aligned puts you in a strong position to answer those questionnaires honestly.

A Melbourne example

A boutique financial planning firm in Hawthorn we work with — four advisers and a handful of support staff running Xplan and Microsoft 365 — came to us after a close call. A client emailed asking to redirect a six-figure redemption to a new bank account. The email was genuine-looking and came from the client’s real address, but the client’s own mailbox had been compromised, and the account details were the attacker’s. The adviser nearly actioned it; a junior staff member happened to phone the client about something unrelated and the fraud unravelled by luck.

We rebuilt the foundations: MFA enforced through conditional access on every account, geographic sign-in restrictions, mailbox-rule alerting, SPF, DKIM and DMARC on their domain, and a documented process that every bank-detail change or payment instruction is verbally verified on a known number. We added a real Microsoft 365 backup covering their seven-year retention obligations and moved client documents out of personal OneDrives into a managed, access-controlled portal. The firm now relies on process and controls rather than luck.

Frequently asked questions

Does ASIC require financial planning firms to have cyber security?

Effectively, yes. ASIC’s licensing obligations require an AFSL holder to have adequate risk-management systems and resources, and ASIC has made clear — including through the RI Advice case — that this covers cyber-security risk management. A planning firm that cannot demonstrate basic controls across its advisers is exposed on its licence obligations, not just its data.

How long do we have to keep client advice records?

Advice documents such as statements of advice generally must be kept for at least seven years under the Corporations Act and ASIC’s rules, and fee disclosure and ongoing-service records carry their own retention requirements. Those records need to live in managed, backed-up systems for the full period, not on individual devices.

What is the biggest IT risk for an advice practice?

Business email compromise on payment and rollover instructions. Because advisers move money on client instruction, a compromised or spoofed mailbox can redirect funds before anyone notices. MFA, mailbox monitoring and a strict verbal-verification rule for any bank-detail change are the controls that matter most.

Does APRA CPS 234 apply to us if we are not APRA-regulated?

Not directly, but it flows down. If you handle data for, or sit in the supply chain of, an APRA-regulated entity such as a super fund or insurer, CPS 234 requires them to manage your information security. Expect security questionnaires and contractual control requirements as a condition of working with them.

Getting it right without overspending

A planning firm does not need an enterprise security budget — it needs the right controls done properly and kept that way: MFA and conditional access everywhere, hardened email with a verbal-verification process for payments, individual logins across Xplan and your CRM, a real backup that meets your retention obligations, and the discipline to be able to answer a licensee or CPS 234 questionnaire honestly. TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma — no offshore helpdesk. We support professional services firms across Melbourne metro on per-user fixed monthly pricing, with sub-15-minute response on critical issues and same-business-day on-site when you need hands on the ground. If your practice is running on saved passwords and goodwill, get in touch and we will tell you plainly what to fix first.

Allied health clinics carry the same privacy and security obligations as a GP practice, usually with a fraction of the budget and no in-house support. Good allied health IT support keeps your clinical software running, your telehealth stable, and your patient records protected to the standard the Privacy Act and AHPRA expect.

Physiotherapy, psychology, occupational therapy, dietetics, podiatry and speech pathology clinics all sit in the same regulatory bucket. They handle health information, so they are covered by the Privacy Act regardless of turnover — the usual $3 million small-business exemption does not apply to health service providers. A two-room psychology practice in Camberwell has the same baseline obligations as a 40-clinician group. That trips a lot of owners up, so it is worth getting the IT side right from the start.

What allied health clinics actually run

Most allied health practices in Melbourne run on cloud-based practice-management software, not a server in the back room. The common platforms — Cliniko, Halaxy, Nookal, Power Diary and Coreplus — handle appointments, clinical notes, invoicing, Medicare and DVA claiming, and increasingly NDIS billing.

Because these are SaaS products, the vendor secures the application and database. Your obligations do not disappear, though. You still own the devices, accounts, clinic network, integrations and the backup of anything outside the platform — and that half is where most incidents happen. The recurring weak spots we find: unpatched, unencrypted laptops with a saved Cliniko login; shared reception accounts with no multi-factor authentication; booking widgets, payment terminals and SMS reminders that touch patient data without being configured properly; and assessment reports or scanned referrals sitting in a Downloads folder or on a USB stick. That last one is the data that gets lost.

Telehealth that actually holds up

Telehealth went from optional to core during the pandemic and has not gone back. Psychology and speech pathology run a large share of sessions over video, and the problem is almost never the platform — it is the clinic’s internet and the practitioner’s setup.

Reliable telehealth comes down to a few unglamorous things: a business-grade connection with enough upload bandwidth, a 4G or 5G failover so a session does not drop when the NBN has a wobble, Quality of Service on the router so video is prioritised over a background 2 GB update, and a decent headset and webcam. We have seen practitioners blame Coreplus or Halaxy for dropouts when the real fault was a consumer router and a single connection carrying four concurrent sessions. Upload speed is the number that matters and the one most retail plans bury — if you run more than two or three sessions at once, size it deliberately.

My Health Record and secure messaging

My Health Record connectivity

Eligible allied health providers can connect to My Health Record to view shared health summaries, discharge summaries, pathology and imaging. Connecting requires conformant software (most major platforms support it), an HPI-O for the organisation, HPI-I numbers for practitioners, and a NASH PKI certificate to authenticate the connection. The NASH certificate has to be installed and renewed correctly or the connection silently stops working — a task for someone who has done it before, not a practice manager guessing at midnight.

Secure messaging with Argus and Medical-Objects

Secure messaging through Argus or Medical-Objects is how allied health clinics exchange referrals, assessment reports and correspondence with GPs and specialists in an encrypted, point-to-point way. If you accept referrals from GP clinics, they will often expect you to be reachable on one of these networks. Getting the directory listing, software integration and message routing right is a setup job that removes a privacy risk fax and ordinary email both carry.

Privacy, AHPRA and your legal obligations

Two regimes matter here, and they overlap. The Privacy Act 1988 and the Australian Privacy Principles apply to every health service provider, with no turnover threshold. Health information is sensitive information and attracts the highest level of protection. Under the Notifiable Data Breaches scheme, an eligible breach involving patient records must be assessed and, where it is likely to cause serious harm, reported to the Office of the Australian Information Commissioner (OAIC) and affected individuals. A lost laptop full of psychology case notes is exactly what that scheme exists for.

Separately, AHPRA and the National Boards set professional obligations on registered practitioners — physiotherapists, psychologists, occupational therapists, podiatrists and speech pathologists — including keeping accurate clinical records and protecting confidentiality. The controls that satisfy the Privacy Act are the same ones that meet those obligations: access control, encryption, retention and a record of who accessed what.

None of this requires gold-plating. The Australian Cyber Security Centre (ACSC) Essential Eight is a sensible baseline, and most clinics can implement the meaningful parts — multi-factor authentication, patching, application control and backups — without a large spend. We cover the practical version in our guide to healthcare IT support, the OAIC and My Health Record, and the broader picture in our cybersecurity services.

Multi-practitioner access control

Most allied health clinics grow by adding practitioners, and access control is usually what gets left behind. The principle is simple: each person has their own login, sees only what their role requires, and loses access the day they leave. In practice:

• Individual accounts in Cliniko, Nookal or whichever platform you run — never a shared “reception” login that three people use.
• Multi-factor authentication on every account that touches patient data, including the practice-management platform and Microsoft 365 mailboxes.
• Role-based permissions so a casual admin cannot export the entire client database.
• A leaver process that disables accounts immediately. Locum and contractor physios who rotate through clinics are a particular risk if access is never revoked.

If your clinic runs on Microsoft 365, conditional access policies let you enforce MFA and block sign-ins from unexpected locations without making life painful for staff. We walk through that in our piece on conditional access policies in Microsoft 365.

NDIS and Medicare billing

Billing is where allied health gets operationally messy, because a single clinic might invoice Medicare, DVA, private health funds, NDIS plan managers, self-managed participants and the agency itself. Cliniko, Halaxy, Nookal, Power Diary and Coreplus all handle Medicare and DVA claiming through integrated channels, and most now support NDIS invoicing. The IT job is making sure those integrations are configured and authenticated correctly, and that the financial data — which is also personal information — is backed up and access-controlled like everything else. Incorrect NDIS claiming is not just an accounting problem; it can become a compliance issue.

Backup of patient data

“It’s in the cloud, so it’s backed up” is the most dangerous assumption in allied health IT. SaaS platforms protect against their own infrastructure failing. They do not protect you from a staff member deleting a client record, a compromised account wiping data, or a billing dispute cutting off your access. A proper backup position covers three things:

1. Practice-management data. Where the platform allows export or third-party backup, take it. Know how to get your patient and clinical data out if you ever need to.
2. Microsoft 365. Email, OneDrive and SharePoint need a dedicated backup — Microsoft’s retention is not a backup, and referrals live in mailboxes.
3. Local files and devices. Anything on the reception PC or a practitioner’s laptop needs to be backed up and, ideally, not stored there at all.

Knowing your recovery targets matters too — how long you could operate if the system went down (RTO) and how much data you could lose (RPO). Our backup and disaster recovery overview covers how to set those.

A Melbourne example

A multidisciplinary allied health clinic in Box Hill we work with — physio, podiatry, dietetics and psychology under one roof — came to us after a near-miss. A practitioner’s laptop was stolen from a car. It had a saved login to their practice-management system and a folder of exported assessment reports on the desktop — none of it encrypted, no MFA on the account. They had no clear way to know what was on the device or whether the OAIC needed notifying.

We rebuilt the basics: full-disk encryption on every device, MFA across the practice-management platform and Microsoft 365, conditional access to block unexpected sign-ins, a real Microsoft 365 backup, and a policy of not storing patient files locally. Their My Health Record and Argus connections were configured and documented so renewals do not get missed. The clinic now has a defensible position if a device goes missing again.

Frequently asked questions

Does the Privacy Act apply to my small allied health clinic?

Yes. Health service providers are covered by the Privacy Act and the Australian Privacy Principles regardless of turnover. The $3 million small-business exemption does not apply to organisations that provide a health service and hold health information, so even a solo psychology or physiotherapy practice is covered.

What does My Health Record connection require?

Conformant practice-management software, an HPI-O for the organisation, HPI-I numbers for practitioners, and a NASH PKI certificate. The NASH certificate must be installed correctly and renewed on time, or the connection stops working without an obvious error.

Do I really need to replace fax for referrals?

Secure messaging through Argus or Medical-Objects is the appropriate way to exchange referrals and reports with GPs and specialists. It is encrypted point-to-point, it is what referring clinics increasingly expect, and it removes the privacy risk fax and ordinary email both carry.

Getting it right without overspending

None of this is exotic. Allied health clinics do not need an enterprise security budget — they need the basics done properly and kept that way: encrypted devices, MFA everywhere, a real backup, sound access control, and the My Health Record and secure messaging connections maintained by someone who has done it before. TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma. We support healthcare practices across Melbourne metro on per-user fixed monthly pricing, with same-business-day on-site when a clinic needs hands on the ground. If yours is running on goodwill and a consumer router, get in touch and we will tell you plainly what to fix first.

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.

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.

If your business stores, processes or transmits card payment data, PCI DSS compliance applies to you. It’s the security standard the card brands enforce on every merchant that touches cardholder data. The good news for most Australian SMEs: with the right payment setup, your obligations are smaller than you’d think.

What PCI DSS actually is

PCI DSS stands for the Payment Card Industry Data Security Standard. It’s not Australian law or a government regulation. It’s a contractual standard maintained by the PCI Security Standards Council, owned by the major card brands: Visa, Mastercard, American Express, Discover and JCB. When you signed your merchant agreement, you agreed to comply with it.

The current version is PCI DSS 4.0.1, a minor revision of version 4.0. The old v3.2.1 standard was retired in March 2024, and the future-dated v4 requirements that were optional during the transition became mandatory from 31 March 2025. So if you ticked “best practice, not yet required” against those controls at your last assessment, that grace period is over. The v4 requirements push harder on multi-factor authentication for all access into the cardholder environment, tighter password rules, anti-phishing controls and scripts on payment pages.

Who has to comply

The rule is blunt: any business that stores, processes or transmits cardholder data must comply, whether you take ten transactions a year or ten thousand. A florist in Camberwell on an EFTPOS terminal is in scope, just as a national retailer is. The standard scales, but never switches off.

Cardholder data means the primary account number (the long number on the front of the card) plus cardholder name and expiry date. A stricter category, sensitive authentication data, covers the full magnetic stripe, the CVV/CVC code and the PIN. That must never be stored after a transaction is authorised, full stop. A surprising number of Australian SMEs breach this by keeping card details in an email, spreadsheet or CRM note.

The four merchant levels

Merchants are sorted into four levels by annual card transaction volume. The level decides how you validate, from a heavyweight external audit at the top to a self-assessment at the bottom. The Visa and Mastercard tiers below are the ones almost everyone uses.

The overwhelming majority of Melbourne SMEs are Level 4: no auditor turns up at your door. You validate by completing the correct Self-Assessment Questionnaire and, depending on your setup, running quarterly external vulnerability scans through an Approved Scanning Vendor.

Self-Assessment Questionnaires in plain English

The SAQ is a checklist you fill in to attest that you meet the relevant controls. There are several types, and using the wrong one means answering hundreds of irrelevant questions or, worse, under-scoping your risk.

• SAQ A — for merchants who have fully outsourced all cardholder data handling to a compliant third party and never see the card number: the e-commerce shop that redirects customers to Stripe, Square or a hosted payment page. The shortest questionnaire, and where you want to be.
• SAQ A-EP — for e-commerce merchants whose site doesn’t receive card data directly but controls how the payment page is delivered, for example loading the payment fields via JavaScript from a provider. Your site can affect transaction security, so you carry more responsibility.
• SAQ B — for merchants using standalone dial-out or IP EFTPOS terminals, or imprint machines, with no electronic card data storage. Common for cafes, trades and small retail.
• SAQ C — for merchants with an internet-connected payment application, where card data is processed through your own network but not stored. More controls apply because your environment is exposed.
• SAQ D — the full questionnaire, for everyone who doesn’t fit the simpler categories, including any merchant that stores cardholder data. It covers all applicable requirements and is the most demanding.

The practical goal is to engineer your way down to SAQ A or SAQ B. The further down you sit, the fewer controls you have to build, evidence and maintain.

How compliant providers and tokenisation shrink your scope

“Scope” is the most important word in PCI DSS. It covers every system, person and process that touches cardholder data, or connects to systems that do. So the smartest strategy isn’t building more controls, it’s keeping card data out of your environment entirely.

Two levers do most of the work. The first is a compliant payment provider. If you take payments through a PCI-certified gateway like Stripe, Square, Tyro or Eway, and your systems never see the raw card number, you’ve handed the hardest parts of the standard to a provider built to meet them. That’s the gap between a 20-question SAQ A and a 300-question SAQ D.

The second lever is tokenisation. Instead of storing a customer’s card number for repeat billing, the provider stores it and hands you back a meaningless token. You charge the card by sending the token, never the real number. Because the token is worthless to an attacker, the systems holding it generally fall out of scope. For any business doing subscriptions, retainers or saved-card checkouts, it’s the cleanest way to keep recurring payments running.

Where Australian SMEs trip up

We see the same handful of mistakes again and again across Melbourne, and nearly all are avoidable.

• Storing card details in email, spreadsheets or CRM notes. A customer phones through a card number and a staff member jots it into an Outlook draft “to process later”. That single act pulls your mail platform and CRM into scope and often breaches the rule against storing the CVV.
• Assuming the payment provider’s compliance covers you. Stripe being compliant doesn’t make you compliant; you still complete your own SAQ. Outsourcing reduces your obligations; it doesn’t delete them.
• Treating it as a once-a-year form. PCI DSS 4.0.1 expects controls to operate continuously, not just on assessment day.
• Conflating it with the Privacy Act. Your obligations to the Office of the Australian Information Commissioner (OAIC) under the Notifiable Data Breaches scheme are separate. A card data breach can trigger both; meeting one doesn’t satisfy the other.

A professional services firm in Hawthorn we work with had been emailing client card numbers internally for years to process annual retainer invoices. We moved them to tokenised, saved-card billing through their gateway and wiped the historical card data out of their mail and accounting systems, dropping them from SAQ D to a short SAQ A.

How an MSP handles the technical side

For businesses that can’t fully outsource card handling, real engineering work is involved, and that’s where an MSP earns its keep.

Network segmentation

The fastest way to cut scope where card data does flow is segmentation: isolating the cardholder data environment from the rest of your network with firewalls and VLANs, so a compromise of the office Wi-Fi can’t reach the payment systems. Done correctly, it takes dozens of machines out of scope. Done badly, your entire flat network is in scope. This is core to our cybersecurity services and overlaps with the controls we deploy under our Essential Eight compliance work.

Logging and monitoring

Version 4 is strict about logging. You need to capture access to cardholder systems, retain those logs, and actually review them, not just generate them. For most SMEs that means feeding logs into a SIEM with alerting, which is what our security operations team runs. When a bank or assessor asks for six months of access logs, having them already searchable is the difference between a quick answer and a panic.

The everyday technical controls

The rest is the disciplined IT hygiene that underpins the whole standard: MFA on every account that can reach the cardholder environment, prompt patching, hardened firewall rules, anti-malware, encrypted transmission of card data and tightly controlled access. None of it is glamorous; all of it is the work, and the controls slip the moment no one owns them. As a Melbourne managed IT services provider founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma, TechAssist keeps them running year-round, not just at audit time.

Frequently asked questions

Is PCI DSS a legal requirement in Australia?

Not directly. There’s no Australian statute that says “thou shalt be PCI compliant”. It’s a contractual obligation you accepted in your merchant agreement. Non-compliance can mean fines passed on by your acquirer, higher transaction fees, or in serious cases losing the ability to take card payments. A breach can also trigger separate obligations under the OAIC’s Notifiable Data Breaches scheme.

We only take payments through Square. Are we still in scope?

Yes, but your scope is small. If card data never lands in your own systems, you’ll typically complete the short SAQ A and confirm you don’t store card details anywhere. The risk is staff quietly creating shadow records, a card number in an email or spreadsheet, which drags other systems back into scope.

How often do we have to validate, and what’s the easiest way to stay compliant?

Validation is annual for most merchants: you complete the relevant SAQ each year, plus quarterly external vulnerability scans through an Approved Scanning Vendor if your setup requires them. The underlying controls are expected to operate year-round under PCI DSS 4.0.1. The single biggest thing you can do to make it easier is get card data out of your environment, using a compliant gateway and tokenisation so you never handle the raw card number.

Getting it sorted

For most Melbourne SMEs, PCI DSS compliance is far more achievable than the standard’s bulk suggests, provided you keep card data out of your hands and lock down whatever’s left. If you’re not sure which SAQ applies, or you suspect card numbers are lurking in your email and CRM, that’s worth fixing before an incident forces the issue. Get in touch with our team and we’ll map your scope and the controls you need.

SMB1001 is an Australian-developed cyber security certification standard built specifically for small and medium businesses. It uses five ascending tiers — Bronze, Silver, Gold, Platinum and Diamond — so a business can prove it has sensible controls in place without the cost and overhead of an enterprise framework like ISO 27001.

If you have heard it referred to as “Cyber Certification” or under the Dynamic Standards branding, that is the same lineage. SMB1001 is the named standard that sits behind those schemes. For a Melbourne SME being asked by a larger customer or insurer to “prove your security,” it is increasingly the answer that gets accepted — and it is far more achievable than people assume.

What SMB1001 actually is

SMB1001 is a tiered, multi-level cyber security standard aimed squarely at the businesses that the bigger frameworks were never written for: the 5-person bookkeeping firm, the 30-person fabrication shop, the family logistics operation running three trucks and a back office. These businesses still hold client data, still process payments, still get phished — but they do not have a CISO, a security budget, or the appetite to spend six months and tens of thousands of dollars on an ISO audit.

The standard’s strength is that it is designed to be self-assessed at the lower tiers and independently certified at the higher ones. You do not need to boil the ocean. You pick a tier that matches your size, risk and what your customers are demanding, implement the controls, and certify against it. As your obligations grow, you climb.

It is genuinely useful, and it is genuinely not a silver bullet. A certificate on the wall does not stop a determined attacker, and the lower tiers in particular set a floor, not a ceiling. Treated as a starting point and a discipline rather than a finish line, though, it does real work.

The five tiers, and roughly what each requires

The whole point of the tiered model is that the requirements scale with the business. Bronze is a sensible baseline that almost any micro-business can reach; Diamond approaches the kind of maturity you would expect from an organisation handling sensitive data at scale. Here is the broad shape of it.

The exact control list at each tier is defined by the standard itself and is refreshed periodically, which is part of the “dynamic” idea — the requirements move as the threat picture moves, so a Bronze in 2026 is not the Bronze of several years ago. Treat the table above as the shape, not the letter of the law. When we scope this for a client we work from the current published control set, not memory.

Who SMB1001 suits

The honest answer is most Australian SMEs that have never certified against anything. If you have been muddling along with decent-enough IT, an MSP keeping the lights on, and a vague sense that you “should do something about cyber,” SMB1001 gives you a structured, affordable way to start — and a credential at the end that means something to the people asking.

It fits particularly well for businesses in supply chains. A construction subcontractor in Box Hill bidding for work with a tier-one builder, a manufacturer supplying a listed company, a professional services firm acting for larger corporate clients — all of these are increasingly being asked, in tender documents and vendor onboarding forms, to demonstrate a baseline of security. SMB1001 is built to answer that question proportionately. We see it most across the construction, manufacturing and professional services clients we work with.

How it differs from — and complements — the Essential Eight and ISO 27001

This is where a lot of business owners get confused, so it is worth being precise. The Essential Eight, ISO 27001 and SMB1001 are three different things that overlap rather than compete.

The Essential Eight is a set of eight technical mitigation strategies published by the Australian Cyber Security Centre (ACSC). It is a controls framework, not a certification scheme — there is no certificate you receive at the end, only maturity levels you self-assess or have assessed against. It is excellent at telling you what to harden (application control, patching, MFA, restricting macros and so on) but it does not, by itself, give you a credential to wave at a customer. We cover this in detail in our guide to Essential Eight compliance for Melbourne businesses.

ISO 27001 sits at the other end. It is an international standard for a full information security management system (ISMS) — risk-driven, documentation-heavy, externally audited annually, and respected globally. It is the right answer for businesses that need international credibility or are contractually required to hold it. It is also a serious undertaking in time and cost, which is exactly why it is overkill for a 15-person business that simply needs to prove it is not negligent.

SMB1001 lands in the gap between them. It borrows the practical, control-based spirit of the Essential Eight, packages it into a certifiable, tiered credential like ISO 27001 offers, and scales it down to SME reality. The tiers map sensibly onto the others: the lower tiers cover much of the same ground as the Essential Eight’s foundational maturity, while the upper tiers start to resemble a lightweight ISMS. None of them cancels the others out.

In practice we often run them together. We will harden a client against the Essential Eight because the controls are sound, then certify the business under SMB1001 because that is the thing a customer or insurer actually recognises. The work overlaps heavily, so doing both is far less than twice the effort.

Why customers and primes are asking for it

Three forces are driving the demand. First, supply-chain security has become a procurement issue — larger organisations have woken up to the fact that their weakest link is often a small supplier with the keys to their data, so they are pushing security requirements down the chain. Second, cyber insurers have tightened underwriting and want evidence of basic controls before they will quote, let alone pay a claim. Third, regulators expect more: under the Privacy Act and the OAIC’s Notifiable Data Breaches scheme, a business that suffers a breach has to be able to show it took reasonable steps, and “we had nothing in place” is not a defensible position.

SMB1001 gives an SME a clean, recognised way to satisfy all three at once. It is a credential a prime contractor’s procurement team will accept, a data point an insurer’s underwriter understands, and evidence of diligence if the worst happens. That is why it is showing up in tender packs and vendor questionnaires far more often than it did two years ago. If cyber insurance is part of your thinking, our cyber insurance guide for Australian SMEs covers how these pieces fit together.

The certification path, effort and cost

The route through SMB1001 is deliberately straightforward. You scope which tier you need — driven by your size, your risk and, frankly, whatever your biggest customer is demanding. You implement the controls for that tier. At Bronze and Silver you self-assess and attest; at Gold and above you engage an authorised assessor for independent certification. Certification is then maintained and renewed periodically rather than being a one-off.

On effort: for a business with reasonable IT already in place, Bronze or Silver can be a matter of tidying up MFA, backups, patching and staff awareness, then documenting it — weeks, not months. Gold and above take longer because the governance and evidence requirements are real, and because independent assessment means you actually have to demonstrate the controls, not just claim them. Where there is groundwork to do — and there usually is — the gap is the controls, not the paperwork.

On cost: SMB1001 is markedly cheaper than ISO 27001, which is the whole point. The certification fees scale with the tier, and the larger expense for most businesses is the remediation work to actually meet the controls rather than the certification itself. As a rough guide, the lower tiers are a modest annual outlay; the upper tiers cost more but remain a fraction of an ISO programme. Figures move, so we scope it per-business rather than quoting a number that ages badly.

A heads-up worth giving plainly: the certificate is the easy bit. The controls are what protect you, and they only protect you if they are maintained — MFA stays enforced, backups keep being tested, patches keep landing, leavers keep getting offboarded. A business that certifies and then lets it all drift has a piece of paper and a false sense of security. That ongoing discipline is exactly what a managed arrangement is for.

How TechAssist approaches it

We are a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers — no offshore helpdesk. We are Essential Eight aligned and ISO 27001 capable, which means the controls underneath SMB1001 are bread and butter for us. When a client comes to us holding a tender that demands certification, we scope the right tier, close the control gaps, and get them through assessment — then keep the controls live afterwards under fixed per-user monthly pricing so they do not quietly rot.

A recent example of the pattern: a transport and logistics operator in Dandenong we work with was told by a national client that ongoing work depended on demonstrating a baseline of cyber controls. They had no certification and a tender deadline. We mapped their environment, lifted the gaps — MFA across Microsoft 365, tested backups, patching discipline, basic staff training — and put them in a position to certify at a sensible tier without blowing the budget. The work doubled as genuine risk reduction, not box-ticking. Our cyber security services are built around exactly this kind of proportionate, evidence-backed uplift.

Frequently asked questions

Is SMB1001 mandatory in Australia?

No. SMB1001 is a voluntary certification standard. There is no law requiring you to hold it. The pressure to certify is commercial — customers, primes and insurers asking for proof of security — rather than legal. That said, demonstrating reasonable security steps does help your position under the Privacy Act and the OAIC’s breach-notification obligations.

Which SMB1001 tier should we aim for?

Start from what is driving the decision. If a specific customer or tender names a tier, that is your target. If you are certifying proactively, Bronze or Silver is a sensible entry point for most small businesses, with Gold and above reserved for those handling sensitive data or facing stronger contractual demands. We scope this per-business rather than guessing.

Does SMB1001 replace the Essential Eight or ISO 27001?

No — they complement each other. The Essential Eight tells you which technical controls to harden, SMB1001 gives you a recognised certificate proving you have a sensible baseline, and ISO 27001 is the heavyweight option for businesses needing international-grade assurance. Many SMEs run the Essential Eight controls underneath an SMB1001 certification.

How long does it take to get certified?

For a business with reasonable IT already in place, the lower tiers can be achieved in weeks once the remediation is done. Higher tiers take longer because of the governance and independent assessment involved. The timeline is driven mostly by how much control gap there is to close, not by the certification paperwork.

Where to start

If a customer, prime contractor or insurer has put SMB1001 in front of you — or you simply want a structured, affordable way to prove your business takes security seriously — the first step is an honest look at where your controls actually stand. We will tell you which tier is realistic, what it takes to get there, and whether the bigger frameworks are worth it for you. Get in touch and we will scope it properly.

The SOCI Act directly captures owners and operators of designated critical infrastructure assets across 11 sectors. Most small and mid-sized Melbourne businesses are not caught. But if you supply, manage IT for, or sit in the supply chain of one of these entities, its obligations can land on your desk regardless.

That gap — between “the law doesn’t name me” and “I’m still on the hook” — is where most of the confusion sits. Here is who is actually captured, what they have to do, and how to tell whether any of it touches your business.

What the SOCI Act actually is

The Security of Critical Infrastructure Act 2018 (Cth) is Commonwealth legislation administered by the Department of Home Affairs through the Cyber and Infrastructure Security Centre (CISC). When it first passed it covered four sectors and did little more than require an asset register for electricity, gas, water and ports.

Two rounds of amendments changed that dramatically. The Security Legislation Amendment (Critical Infrastructure) Act 2021 expanded the sectors and introduced mandatory cyber incident reporting and government assistance powers. The 2022 Act, shortened to SLACIP, added the Risk Management Program obligation and enhanced duties for “systems of national significance”.

So the SOCI Act today means the 2018 Act as amended by those packages — the expanded version that now reaches businesses that never thought of themselves as critical infrastructure.

The 11 critical infrastructure sectors

The amended Act defines 11 sectors. If your organisation owns or operates an asset inside one of these, you are potentially in scope.

• Communications
• Financial services and markets
• Data storage or processing
• Defence industry
• Higher education and research
• Energy
• Food and grocery
• Health care and medical
• Space technology
• Transport
• Water and sewerage

Being in a sector is not the same as being captured. The Act bites on specific critical infrastructure assets defined by rules and thresholds within each sector. A small clinic in Camberwell sits within “health care and medical”, but the obligations attach to large hospitals and designated systems, not every GP practice. The sector tells you to keep reading; the asset thresholds tell you whether you are actually in.

The three core obligations

For captured entities, the Act imposes a tiered set of duties. Three are worth understanding in plain terms.

The asset register

Responsible entities must provide ownership and operational information about their assets to the Register of Critical Infrastructure Assets, held by the CISC: who controls the asset, who has access, and where interest or control sits offshore. The register is not public. It exists so government has visibility of who runs the country’s important infrastructure.

The Risk Management Program

This is the heart of the SLACIP amendments. Captured entities must adopt, maintain and comply with a Critical Infrastructure Risk Management Program (CIRMP) that identifies and manages hazards across four domains: cyber and information security, personnel, supply chain, and physical and natural hazards. Boards must approve it, and entities submit an annual report confirming the program is current and signed off at board level.

For the cyber domain, the rules point entities towards a recognised framework such as the Essential Eight maturity model or an equivalent standard like ISO 27001. This is where security posture stops being a nice-to-have and becomes a documented, board-signed legal obligation.

Mandatory cyber incident reporting

Captured entities must report cyber security incidents to the Australian Signals Directorate (ASD), in practice through the Australian Cyber Security Centre and coordinated with the CISC. There are two clocks, and the difference matters:

Twelve hours is a brutal window if you have not planned for it. A captured entity needs an incident response process that can detect, triage and report inside half a day — overnight, on a weekend, during a holiday. That is operational maturity, not a policy in a drawer, which is why our managed detection and response work exists.

Be honest: most Melbourne SMEs are not directly captured

This gets glossed over by anyone trying to sell you compliance product. The vast majority of small and mid-sized businesses in Melbourne are not responsible entities under the SOCI Act. A 25-person law firm in the CBD, a manufacturer in Dandenong, a logistics operator in Footscray — these are not critical infrastructure assets, and the asset register, CIRMP and 12-hour reporting clock do not apply to them directly.

The obligations are deliberately aimed at scale and national consequence: major energy networks, large hospitals, designated data centres, financial market operators, telecommunications carriers, significant ports and rail. If a cyber attack on you would disrupt an essential service for a meaningful slice of the population, you are the target of this law. If it would mostly hurt you and your customers, you almost certainly are not directly captured. Anyone telling a 30-person SME it must file a Risk Management Program because of the SOCI Act is either confused or selling something.

Why it still matters to SMEs: the supply chain flow-down

Direct capture is not the only way SOCI obligations reach you. The Risk Management Program explicitly requires captured entities to manage supply chain hazards — a legal duty to assess and control the security risk posed by their vendors, contractors and IT providers.

So the obligation flows downhill through contracts. A captured hospital cannot meet its CIRMP duty unless it can demonstrate its suppliers are secure, so it pushes security requirements into procurement and supplier agreements. If you sell software, provide IT support, host data, supply equipment or deliver professional services to a captured entity, you will increasingly be asked to prove your security posture as a condition of doing business.

We see this constantly. A professional services firm in Hawthorn that works for a captured energy operator suddenly receives a security questionnaire demanding evidence of multi-factor authentication, patching cadence, access controls and an incident response plan — Essential Eight territory. The firm is not captured by the SOCI Act, but its client is, and the client’s obligation has become the firm’s commercial reality.

This is the honest reason SMEs should care. Not because the regulator is coming for you, but because your captured customers are. Losing a contract because you cannot answer a supplier security assessment is a far more immediate risk than any enforcement action. Aligning to the Essential Eight is the most efficient way to be ready, and it is the same framework the captured entities are pointed to.

How do I know if any of this applies to me?

A practical test, in order:

1. Are you in one of the 11 sectors? If not, the SOCI Act does not directly apply, though you may still face flow-down obligations if you supply someone who is.
2. Do you own or operate a defined critical infrastructure asset? Each sector has thresholds — capacity, customer numbers, designation by the Minister. Most SMEs fall well under them. The CISC publishes the authoritative guidance on which assets are caught.
3. Have you been notified? Responsible entities are generally aware they are captured; the framework is not a hidden trap. If no regulator or rule has identified you as one, you very likely are not.
4. Do your contracts impose security obligations? This is the one that catches SMEs. Read your supplier agreements and any new security schedules from larger clients — that is where SOCI reaches you in practice.

If you are genuinely unsure whether you are captured, that is a legal question worth getting right. Where we add value is the technical side: building the controls and evidence that either satisfy a direct CIRMP obligation or answer the supplier assessments flowing down from your captured clients. Our virtual CIO engagements often start here — turning a vague “our client wants us to be secure” into a concrete, costed plan.

What TechAssist does about it

We are a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma. That on-shore, around-the-clock capability matters here, because the 12-hour reporting clock does not respect business hours. For captured entities, we build the cyber domain of a Risk Management Program: Essential Eight uplift, documented controls, monitoring, and an incident response process that can actually meet a 12-hour deadline. For the far larger group of SMEs facing flow-down pressure, we get your posture to where supplier questionnaires become a formality rather than a fire drill. Either way it is real engineering, not a compliance binder, and it sits inside our standard cybersecurity services.

Frequently asked questions

Does the SOCI Act apply to small businesses?

Almost never directly. The Act captures owners and operators of defined critical infrastructure assets, which are large-scale and nationally significant. A typical Melbourne SME is not a responsible entity. The real exposure is indirect — security obligations flowing down through contracts from captured customers.

What are the SOCI Act reporting timeframes?

Captured entities must report a critical cyber incident with significant impact within 12 hours of becoming aware, and an incident with relevant impact within 72 hours. Reports go to the Australian Signals Directorate via the Australian Cyber Security Centre.

What is a Risk Management Program under the SOCI Act?

The CIRMP, introduced by the 2022 SLACIP amendments, requires captured entities to identify and manage hazards across cyber, personnel, supply chain and physical domains, have the board approve it, and report annually that it is current.

I supply a captured entity. What will they ask me for?

Typically evidence of multi-factor authentication, patching, access controls, backup and recovery, logging, and an incident response plan — broadly the Essential Eight. Getting these in place and documented is the most efficient way to keep those contracts.

The short version

The SOCI Act is real and serious, and mostly not aimed at you if you run a Melbourne SME. What is aimed at you is the security pressure your captured customers are now legally required to push down their supply chains. The smart move is not to panic about direct capture, but to get your security posture to a standard that satisfies both your clients and your own risk. For a straight answer on where you sit, talk to us.

Enterprise vendor risk management assumes you have a four-person governance, risk and compliance team. Most Melbourne SMEs have zero. This is a deliberately stripped ‘lite’ framework for businesses with 20 to 200 staff: three vendor tiers, a one-page questionnaire, the only evidence that matters, and the playbook for when a critical vendor fails the assessment.

Why the enterprise playbook fails for SMEs

Open any vendor risk management framework written for a bank or a listed company and you will find a 130-question security questionnaire, a quarterly review cadence, on-site audits, and a control library mapped to NIST CSF, ISO 27001, SOC 2, PCI DSS and the APRA standards. It works because there is a team paid full-time to run it.

An accounting firm in Hawthorn with 45 staff cannot run that programme. The office manager who ‘owns IT’ has neither the hours nor the technical background to read a SOC 2 Type II report properly, let alone challenge the boundaries it covers. And yet that same firm now uses 60 to 90 SaaS products that touch client data: Xero, a practice management system, an e-signature tool, four AI products, a payroll bureau, a document portal, a cloud archive, a CRM, and so on. The risk surface is the same as a mid-market enterprise. The team to manage it is not.

The lite framework below is what we run with our co-managed clients. It is opinionated, it ignores parts of the textbook on purpose, and it produces a defensible position that holds up in a cyber insurance application or a Privacy Act incident review. We have refined it across 12 years of running managed IT services in Melbourne since founding TechAssist in 2014, and it has now been deployed across professional services, healthcare admin, light manufacturing and not-for-profit clients.

The three-tier vendor categorisation

The single most useful move you can make is to stop treating all vendors the same. About 80% of the SaaS in a typical SME is low-risk; about 5% will hurt badly if it is breached or goes down. Sort the list once, properly, and you can focus your effort on the 5%.

Tier 1: Critical

A vendor is Tier 1 if any one of these is true:

• They process or store regulated personal data at scale (health records, financial accounts, legal matters, identity documents)
• Their outage stops the business from operating within 24 hours (your finance system, your line-of-business platform, your phone system, Microsoft 365)
• They have privileged access into your network, your identity provider, or your endpoints (your MSP, your security tooling, your remote support tools)
• They handle payments or move money

Expect 5 to 12 Tier 1 vendors in a typical SME. These get the full questionnaire, evidence requirements, and an annual review.

Tier 2: Important

A vendor is Tier 2 if they hold business data that you would care about leaking, but their outage is tolerable for a few days, or the data set is limited. Examples: your CRM, your marketing automation tool, your e-signature service, an HR information system that holds employee records, project management tools.

Expect 15 to 30 Tier 2 vendors. They get the short questionnaire and a light evidence check (the security page on their website is acceptable if it lists the right certifications).

Tier 3: Everyone else

Free productivity tools, internal-only utilities, vendors that hold nothing more sensitive than a contact list. The control is the procurement gate (someone signs off before the credit card goes in) and an annual list review. No questionnaire, no evidence, no annual reassessment.

Expect 30 to 60 Tier 3 vendors. The point is to have them on the list, not to spend any meaningful time on them.

The 12-question questionnaire that fits on one page

Long questionnaires (the SIG, the CAIQ, an internal 140-item monster) do not produce better risk decisions for SMEs. The vendor copies their answers from the last questionnaire, you have no way to verify most of it, and you sign anyway because you need the product. Strip it down to 12 questions that you will actually read.

Twelve questions. One page. Most credible vendors can answer it in 30 minutes; if a Tier 1 vendor takes three weeks to respond or sends boilerplate that does not address the question, that is your answer. We have seen serious Australian SaaS vendors fill this out in a working day. We have also seen offshore platforms ignore it entirely. Both outcomes are useful information.

What ‘evidence’ you actually need

The textbook says: review their SOC 2 report, walk through their controls, validate their penetration testing, examine their incident response runbooks. In practice, for an SME, the evidence stack is much simpler. Either the vendor has an independent third-party attestation that you can rely on, or they do not.

Accept (Tier 1 and Tier 2)

• SOC 2 Type II covering at least the last 12 months and covering the product you are using. Type I is a snapshot and is worth far less. The scope matters – if the SOC 2 covers their corporate environment but not the production service you are buying, it is window dressing.
• ISO 27001 certification with a recent certificate (within the three-year cycle) and a scope statement that includes the relevant systems. Insist on the scope statement, not just the certificate number.
• IRAP assessment at PROTECTED or higher, for any vendor handling government-adjacent or sensitive data.

Acceptable with caveats (Tier 2 only)

• A current public security page that lists controls in detail and names specific frameworks they align with.
• A signed letter from their CISO or equivalent stating the controls in place, where no certification exists.

Not acceptable for Tier 1

• ‘We follow industry best practice.’
• ‘We are SOC 2 compliant’ with no report attached.
• ‘Our hosting provider (AWS) is certified.’ AWS being certified does not certify the customer running on AWS.
• A self-assessment questionnaire as the only evidence.

This is where most SME vendor programmes drift. The temptation is to accept a marketing page and move on because the alternative is to delay a project. Hold the line on Tier 1. Be pragmatic on Tier 2.

The playbook for when a key vendor fails

Here is what the textbook gets wrong: it implies that a failed vendor risk assessment means you switch vendors. In SME reality, you almost never do. You have a contract, you have integrations, you have user training, and switching costs are punishing. The realistic outcome of a failed assessment is risk acceptance with compensating mitigations.

The playbook we run with clients has five steps.

Step 1: Identify the specific gap

Not ‘they failed the questionnaire.’ Specifically: they have no SOC 2, their breach notification is 30 days, they do not support SSO on our tier, they will not name their sub-processors. Write down the actual gap.

Step 2: Quantify the exposure

What is the worst credible outcome if this gap is exploited? Loss of which data set, of what volume, with what regulatory and reputational consequences? Document the number of records and the personally identifiable information categories.

Step 3: Design compensating controls

Most gaps can be mitigated on your side. If they do not support SSO on your tier, enforce a strong password manager policy, rotate the shared credentials quarterly, and put an alert on the account. If their breach notification is 30 days, monitor publicly available breach feeds yourself. If they will not name sub-processors, restrict the data set you send them. If they do not have MFA on admin accounts, do not send them your most sensitive data.

Step 4: Document the acceptance

A risk acceptance document that names the gap, the mitigations, the residual risk, the business benefit of continuing, and the executive who signed off. This is what makes the position defensible later. Insurance underwriters and OAIC investigators do not expect perfection; they expect documented, considered decisions.

Step 5: Set a review date

Twelve months from now, are the mitigations still in place? Has the vendor improved their controls? Should the risk acceptance be renewed, withdrawn, or escalated?

A 70-staff law firm in Camberwell we work with ran this playbook recently on a US-based legal AI vendor. The vendor had no SOC 2, no SSO on the relevant tier, and stored data in US-East. The partners wanted the product. The compensating controls: a dedicated tenant configuration that limited what content could be sent to the tool, an enforced data classification policy on the matter management side, quarterly review of the vendor’s audit log exports, and a contractual addendum on breach notification. Risk accepted, documented, signed by the managing partner, reviewed annually. That is a defensible position.

The Australian Privacy Act 1988 angle

The Privacy Act amendments that came through in 2024 and 2025 changed the conversation for SMEs. The small business exemption is being narrowed; the maximum penalty for serious or repeated breaches is now the greater of $50 million, three times the benefit obtained, or 30% of adjusted turnover during the breach period. Vendor risk management is now a Privacy Act obligation in practice if not in name. The OAIC has been clear: if your vendor has a breach involving your customers’ data, you are the entity that has obligations to notify and remediate, not the vendor.

Australian Privacy Principle 8 (cross-border disclosure) is the clause that catches most SMEs. Sending personal information overseas – which you do every time you sign up for a US SaaS – generally requires that you take reasonable steps to ensure the overseas recipient does not breach the APPs. Your vendor risk assessment is the ‘reasonable steps’ evidence. Without it, you are exposed.

For the detail on what this means in practice, see our companion piece on the Australian Privacy Act for SMBs and what your IT team must do. The vendor risk programme described here is one of the four foundational pieces of that broader compliance posture, alongside data minimisation, identity hygiene, and breach response readiness.

The cyber insurance vendor list creep problem

Cyber insurance applications now routinely ask for a vendor list. Some carriers want the top 10 by data sensitivity; some want every vendor with access to your systems; the more thorough underwriters want the questionnaire results for your Tier 1 vendors. Three observations from running these applications for clients over the past two years.

First, the list grows every year and the questions get sharper. A 2023 application that asked ‘do you use any third-party SaaS providers’ became a 2025 application that asks ‘list all third-party providers with access to personal information, the data categories involved, and your last review date for each.’ Expect this trajectory to continue. Your vendor list and tiering work is also insurance application work.

Second, an inaccurate disclosure on the insurance application can void the policy. We have seen clients tick ‘all critical vendors reviewed in the last 12 months’ when the answer was closer to ‘three of them.’ If a breach involves an unreviewed vendor, the carrier may decline. Be honest on the form, even if the answer is uncomfortable.

Third, insurers increasingly want evidence that you have an MSP or internal team running this programme. A client of ours in Box Hill had a cyber renewal in late 2025 where the carrier asked for proof of an MSP relationship covering vendor risk before they would renew on the existing premium. The co-managed IT support arrangement we had in place satisfied the underwriter; without it, the renewal would have been 40% more expensive.

What to run yourself versus what to delegate

The split we recommend for a 30 to 150 staff SME is:

The work the MSP does is the technical assessment and the document handling. The work the business owns is the procurement decision and the risk acceptance. That separation matters. Risk acceptance is a business decision, not an IT decision; the MSP should not be signing it off, but should provide the analysis that informs it.

Our own approach at TechAssist is to maintain a vendor register for each managed client, run the questionnaire cycle from our 24/7 NOC at Tecoma, and bring findings to the client quarterly. When a P1 event involves a vendor (a Microsoft 365 outage, a confirmed third-party breach, a vendor that fails an audit), our sub-15-minute P1 response runs from the same NOC, and our 13 Australian engineers are the team that does the assessment work. No offshore questionnaire mills, no automated tooling that emails the vendor and walks away from the answer.

A realistic first 90 days

If you have nothing in place today and you want to start, here is the shape of the first quarter.

Weeks 1 to 2: List every SaaS, every vendor with a login, every contractor with system access. Pull it from your accounting system (every recurring expense), your password manager, and your single sign-on tenant. Expect to find 30 to 50 more than anyone thought existed.

Weeks 3 to 4: Tier the list. Most vendors will be Tier 3 in five minutes. The Tier 1 conversation is the one that takes time and judgement.

Weeks 5 to 8: Issue the 12-question questionnaire to Tier 1. Chase, read, file. Note the gaps.

Weeks 9 to 12: Risk acceptances or remediations for each Tier 1 gap. Document the position. Schedule the 12-month review. Brief the executive on residual risk.

At the end of 90 days you have a defensible vendor risk position, a paper trail for insurance and Privacy Act purposes, and a list that you can maintain in two to four hours a month rather than rebuilding from scratch every year. That is the goal of the lite programme: defensible, sustainable, and proportionate.

Frequently Asked Questions

Do we need a vendor risk programme if we are under the small business turnover threshold for the Privacy Act?

The small business exemption (under $3 million turnover) is being narrowed by the Privacy Act reforms, and even today the exemption does not apply to health service providers, businesses that buy or sell personal information, contractors to the Commonwealth, and a few other categories. More practically, your customers, your insurers, and your enterprise prospects increasingly require vendor risk evidence regardless of whether the Act technically applies to you. We recommend a lite programme for every SME with more than 20 staff.

Is a SOC 2 Type I report sufficient for Tier 1 vendors?

No. SOC 2 Type I is a point-in-time review and tells you very little about how the vendor actually operates the controls over time. For Tier 1, insist on a SOC 2 Type II covering at least six months and ideally twelve. Type I is acceptable for Tier 2 alongside other evidence.

What do we do about vendors that refuse to respond to the questionnaire?

For Tier 1, non-response is the answer. Either escalate to their account team (often the account manager can move the request through their internal security team) or accept that you cannot use them for Tier 1 workloads. For Tier 2, document the non-response, look at their public security page, and consider whether the gap is acceptable. Some smaller vendors genuinely do not have the team to respond, and that is itself a risk signal.

Should we use an automated vendor risk platform?

Probably not for an SME under 100 staff. The platforms (UpGuard, SecurityScorecard, BitSight, OneTrust) are excellent but priced for an enterprise budget and produce more data than a small team can act on. A spreadsheet, a shared mailbox for evidence collection, and a calendar reminder for annual review will do the job for most SMEs. Revisit the tooling question if you grow past 200 staff or if your customers start asking for vendor risk evidence in a specific format.

Who in the business should own vendor risk?

The accountability should sit with a named executive (CFO, COO or general manager in a typical SME). The day-to-day work can be delegated to an office manager, an internal IT lead, or your MSP. The risk acceptance decisions cannot be delegated below executive level.

How does this fit with our existing cyber security work?

Vendor risk is one pillar of a broader programme that also includes endpoint and identity controls, backup and recovery, and incident response. Our Melbourne cyber security services wrap these pillars together for managed clients, and the vendor risk lite framework is part of the standard offering. If you want to talk through how the pieces fit for your business, our team is reachable through the contact page.