Supply Chain Cybersecurity in Australia: How to Manage Third-Party Vendor Risk

Your cybersecurity is only as strong as the weakest link in your supply chain. That is not a cliché — it is the documented lesson from some of the most consequential cyberattacks of the past five years. The organisations that got hit were not always negligent. Many had reasonable defences in place. What they lacked was visibility into the security posture of the vendors, software providers, and managed service partners they trusted with access to their systems and data.

The Australian Cyber Security Centre (ACSC) has specifically identified supply chain cyber risk as one of the primary threats facing Australian organisations. The incidents driving that warning are not theoretical. They have affected real Australian businesses, government agencies, and the service providers those businesses depend on. This article explains what supply chain cyber risk is, why Australian SMBs are exposed, how to assess the vendors you already trust, and what an ongoing approach to third-party risk management looks like in practice.

What Is a Supply Chain Cyber Attack?

A supply chain cyber attack does not target your business directly. Instead, it targets a vendor, supplier, or service provider that already has trusted access to your systems or your data. Once the attacker compromises that vendor, they use that trusted access to reach you — without ever having to break through your own defences.

The reason these attacks are so effective is simple: trusted access bypasses the front door entirely. Your firewall, your email filters, your endpoint security — none of those controls are designed to catch malicious activity coming from a vendor your systems already recognise and trust.

Three incidents illustrate this clearly.

MOVEit (2023). MOVEit Transfer is a widely used managed file transfer product from Progress Software. In May 2023, the Cl0p ransomware group exploited a critical zero-day vulnerability (CVE-2023-34362) in MOVEit before a patch was available. Because MOVEit was used by hundreds of organisations worldwide to transfer sensitive files, the attackers were able to steal data from a vast number of victims in a short time without needing to individually breach each one. Multiple Australian government agencies and private sector organisations were among those affected. The organisations that suffered data exposure had done nothing wrong — they had purchased and deployed a legitimate, reputable product. The vulnerability was in the product itself.

SolarWinds (2020). The SolarWinds attack is perhaps the most studied supply chain compromise in history. Attackers — later attributed to a Russian state-sponsored group — inserted malicious code into a software update for SolarWinds' Orion platform, a widely used network monitoring product. When organisations applied what looked like a routine update, they unknowingly installed a backdoor that gave the attackers persistent access. The attack affected thousands of organisations worldwide, including US government agencies and major enterprises. The update was digitally signed by SolarWinds, meaning it passed integrity checks that would normally catch unauthorised software.

Kaseya VSA (2021). Kaseya VSA is a remote monitoring and management tool used extensively by managed service providers (MSPs) to administer their clients' systems. In July 2021, the REvil ransomware group exploited vulnerabilities in VSA to push ransomware to the downstream clients of MSPs using the tool. Because MSPs use VSA to manage hundreds of client environments simultaneously, a single compromise gave the attackers access to a large number of businesses at once. Estimates suggest up to 1,500 businesses were affected through their MSPs. This attack was specifically designed to weaponise the trust relationship between MSPs and their clients.

The common thread in all three incidents is trusted access. The attacks worked because victims trusted the vendor and had no independent means of verifying that what the vendor was delivering or accessing on their behalf was safe.

Why Australian Businesses Are Exposed

Supply chain risk is not a problem exclusive to large enterprises. Australian SMBs face it in everyday operations, often without realising the extent of their exposure.

Most Australian businesses rely on between five and fifteen third-party software vendors and cloud services at any given time — accounting platforms, CRMs, HR systems, cloud storage, communication tools, and often a managed IT provider overseeing all of it. Each of those vendors holds some level of access to your data or your systems, making each a potential entry point for an attacker.

This exposure is compounded by a common assumption: that paying for a reputable service means the vendor is secure. It does not. Reputable vendors get breached. MOVEit was a well-regarded enterprise product. SolarWinds was trusted by US government agencies. Security does not correlate reliably with reputation or price.

MSPs represent a particular concentration of risk. A managed IT provider has privileged access — often administrator-level — to every client they manage, frequently through a single set of management tools spanning dozens of environments. An MSP that lacks robust internal security is not just a risk for itself; it is a multiplied risk for every business that has trusted it with access. This is precisely what the Kaseya attack exploited.

Vendor access is also frequently over-provisioned. The principle of least privilege is rarely applied rigorously to vendor relationships. Broad access is granted at onboarding and rarely reviewed or reduced as the relationship matures. Over time, vendors accumulate access well beyond what they need — and that access is rarely revoked when the relationship ends or changes scope.

The ACSC has specifically warned Australian businesses — not just critical infrastructure operators — that supply chain risk is a material threat requiring active management, backed by documented incidents involving Australian organisations.

The Three Types of Supply Chain Cyber Risk

Supply chain cyber risk takes different forms depending on the nature of the vendor relationship. Understanding these categories helps you prioritise where to focus your risk management effort.

Software and Product Risk

Software risk arises from vulnerabilities in the products you use — operating systems, business applications, security tools. These vulnerabilities may be exploited before a patch is available, as with MOVEit, or discovered after the fact through vendor disclosure.

The primary mitigation is disciplined patching. Critical vulnerabilities in internet-facing systems should be patched within 48 hours of release. The Essential Eight framework includes application and operating system patching as foundational controls for exactly this reason. Businesses should also subscribe to security advisories from key software vendors — most publish advisories through their own channels and through the National Vulnerability Database.

Service Provider and MSP Risk

Service provider risk arises from the privileged access your IT provider, cloud provider, or outsourced service partner holds over your systems. Your managed IT services provider likely has more access to your systems than any other third party — in some cases more than your own staff. Mitigating this risk requires vendor assessment, contractual obligations, and access controls: understanding what access the MSP holds, how that access is managed and audited, and what security practices they apply internally.

Knowing how to choose a managed IT provider with a strong internal security posture is one of the most consequential security decisions an Australian SMB can make.

Data Handling Risk

Data handling risk arises from vendors who process or store your data — your CRM, HR platform, cloud backup provider, accounting system. If those systems are breached, your customers' personal information may be exposed. Under the Privacy Act 1988 and the notifiable data breaches scheme, the obligation to notify affected individuals and the OAIC may fall on your business even when the breach occurred in a vendor's systems — not the vendor's.

Mitigation includes vendor due diligence before onboarding, data processing agreements that define the vendor's obligations, and data minimisation — sharing with vendors only the data they genuinely need to perform their service.

How to Assess Third-Party Vendor Security

Enterprise organisations have vendor risk management teams and sophisticated assessment frameworks. Australian SMBs need something practical, proportionate, and achievable without a dedicated risk function. The following framework is designed to be exactly that.

Tier Your Vendors by Access Level

Not all vendors pose the same level of risk. Start by categorising your vendors based on the access they hold.

Apply your most rigorous assessment to Critical and High tier vendors. For Medium and Low tier vendors, basic due diligence is sufficient. The goal is proportionality — concentrating your effort where the risk is highest.

Review this tiering annually and whenever you onboard a new vendor or significantly change the scope of an existing vendor relationship.

Questions to Ask Vendors

Once you have tiered your vendors, use a structured set of questions to assess their security posture. For Critical and High tier vendors, these questions should be answered in writing before you grant access.

• Do you hold ISO 27001 certification or a SOC 2 Type II report? Can we see the current certificate or report?
• When was your most recent independent security audit or penetration test?
• How do you manage employee access to client systems and data, and how quickly is access revoked for departed staff?
• What is your process for notifying clients if you experience a breach that could affect their data or systems, and what is your target notification timeframe?
• Have you experienced a security incident in the past two years? If so, what happened and what changed as a result?
• Do you carry cyber liability insurance, and would that cover costs incurred by clients resulting from a breach in your systems?
• How do you deliver software updates — and are updates digitally signed and verified before deployment?

A well-run vendor will have ready answers to all of these. A vendor that cannot or will not answer them is itself a signal worth taking seriously.

Contractual Protections

Vendor assessments establish your current level of confidence. Contracts establish your rights if that confidence turns out to be misplaced.

A Data Processing Agreement (DPA) defines how a vendor may process data on your behalf — purpose of processing, data types, required security measures, and breach obligations. Under the Privacy Act, a DPA is particularly important where a vendor processes personal information collected by your business.

Right to audit clauses give you the right to request evidence of the vendor's security posture at reasonable intervals. Not all vendors will agree to this, but for Critical tier vendors it is worth negotiating.

Breach notification obligations require the vendor to notify you — typically within 24 to 72 hours — of any suspected compromise affecting your data or systems. This is your operational right to respond promptly, distinct from the vendor's own regulatory obligations.

Liability provisions determine what happens financially if a vendor-caused breach results in costs to your business. In standard contracts these provisions are often written heavily in the vendor's favour. Review them carefully, especially the liability caps.

Managing MSP Risk Specifically

Given the Kaseya VSA incident and the broader pattern of MSP-targeting attacks, the relationship between an Australian business and its managed IT provider deserves specific attention. When your MSP connects to your environment to perform maintenance, deploy updates, or respond to an incident, they do so with credentials that can reach your servers, workstations, file shares, and cloud services. If an attacker compromises your MSP's remote management tooling — as happened with Kaseya VSA — they inherit that access across every client the MSP manages.

This is not a reason to avoid using a managed IT provider. A good MSP significantly improves your security posture. It is a reason to hold your MSP to a high standard of their own internal security.

When evaluating your current or prospective MSP, ask the following.

• Do they have a dedicated internal security function or undergo regular external security review, including penetration testing?
• Do all staff with access to client systems use multi-factor authentication — not just on client-facing tooling, but on internal systems too?
• How is privileged access to client environments managed and audited? Is admin access time-limited and session-based, or are standing admin credentials in use?
• What happens to client access credentials when an MSP employee departs?
• What remote monitoring and management (RMM) tools do they use, and have any of those tools had known security incidents?
• Do they carry cyber liability insurance, and does that coverage extend to client impacts from a breach of their own systems?
• What is their commitment to notifying clients in the event of a compromise to their own environment?

A reputable MSP will welcome these questions. They reflect the same standard of due diligence the MSP itself should be applying to its own supply chain. If an MSP is reluctant to answer, that reluctance is meaningful.

Ongoing Monitoring — Vendor Risk Is Not a One-Time Assessment

Completing a vendor assessment at onboarding is a starting point, not a finished product. A vendor that had a clean SOC 2 report eighteen months ago may have experienced staff turnover in their security team, deployed unreviewed infrastructure, or suffered an undisclosed compromise. Your assessment needs to remain current.

Minimum ongoing practices.

Subscribe to vendor security advisories. Most major software vendors publish advisories when they identify vulnerabilities in their products. Subscribe to these notifications for your Critical and High tier vendors and ensure that patches are applied within the timeframes specified in your patching policy.

Monitor for credential exposure. Services such as Have I Been Pwned (haveibeenpwned.com) allow you to monitor whether email addresses from your domain have appeared in known data breaches. This is a low-effort early warning signal. Configure domain monitoring for your business domain so you are notified when your credentials appear in breach datasets.

Review vendor access annually. Conduct a formal review of all active vendor access at least once per year. Remove access for vendors that are no longer actively engaged. Verify that the access scope for continuing vendors remains appropriate. This review often uncovers access grants that were created during a project and never revoked — a common source of unnecessary exposure.

Monitor security news for products you use. When a significant incident affects a software product or service provider in your environment, you need to know promptly. Follow reputable security news sources and treat any major incident involving a product you use as a trigger for reassessment — do not wait for the annual review cycle if a vendor is acquired, undergoes significant leadership change, or experiences a known compromise.

The ACSC's Guidance on Supply Chain Risk

The Australian Cyber Security Centre has published specific guidance on supply chain cyber risk management at https://www.cyber.gov.au/business-government/supplier-cyber-risk-management. The ACSC defines supply chain cyber risk as risks arising from products and services provided by third parties that can introduce vulnerabilities into an organisation's environment.

The ACSC's recommended approach covers four stages: identify your supply chain and the access each vendor holds; assess the security posture of your vendors, prioritising those with the most significant access; establish contractual requirements that formalise vendor security obligations; and maintain ongoing visibility by monitoring continuously rather than treating the initial assessment as complete.

The ACSC's Critical Infrastructure Protection programme applies more prescriptive requirements under the Security of Critical Infrastructure (SOCI) Act for operators in energy, water, communications, and financial services. The ACSC is explicit, however, that the underlying principles apply to all Australian businesses. For SMBs, the ACSC's guidance aligns closely with the Essential Eight framework — particularly application patching, restricting administrative privileges, and multi-factor authentication, all of which directly reduce supply chain attack surface.

How Pickle Manages Supply Chain Risk for Its Clients

As a managed IT and cybersecurity provider, Pickle occupies the highest-risk position in our clients' vendor ecosystems — and we take that responsibility seriously.

Vetted technology partners. We select tools used in client environments from vendors with strong security track records, reviewing security posture, patch history, and incident history before deployment.

MFA on all management tools. Every Pickle staff member uses multi-factor authentication on all accounts with access to client systems — on internal systems as well as client-facing management tooling. This is a requirement, not a recommendation.

Documented access management. We maintain documented records of staff access to each client environment, at what privilege level, and for what purpose. Access is reviewed when roles change and revoked promptly when staff depart.

Cyber liability insurance. Pickle carries cyber liability insurance covering security incidents that could affect client environments. Coverage details are available to clients and prospective clients on request.

Transparent incident notification. If we become aware of a compromise of our own systems or tooling that could affect a client's environment, we notify affected clients promptly — we do not wait for an investigation to conclude before making that call.

If you would like to understand more about how Pickle manages access and security in your environment, we welcome that conversation.

Call us on 1300 688 588 or email [email protected].

FAQ

Q: Is my business responsible if a vendor's breach exposes my customers' data?

A: Potentially, yes. Under Australia's Privacy Act 1988 and the Notifiable Data Breaches scheme, the obligation to notify affected individuals and the OAIC typically rests with the entity that collected the personal information — your business, not your vendor. Even if the breach originated in a vendor's systems, your business may be required to notify if the data involved was information you collected and shared with the vendor. This is why data processing agreements and breach notification clauses in vendor contracts matter: they ensure you receive prompt notice so you can meet your own obligations in time.

Q: How do I know if my software vendor has been compromised?

A: In many cases, you will not know immediately — and that is part of what makes supply chain attacks dangerous. A layered approach is most effective: subscribe to the vendor's security advisory channels; monitor security news; configure domain monitoring on Have I Been Pwned; and ensure your endpoint detection tools alert on unusual behaviour from installed software. No single measure provides complete visibility, but the combination significantly improves your chances of early detection.

Q: Should I ask my MSP for their SOC 2 report or ISO 27001 certificate?

A: Yes, and a well-run MSP should be willing to provide one. SOC 2 Type II is a third-party audit report covering security, availability, and confidentiality controls over a defined period — more meaningful than a point-in-time Type I. ISO 27001 certification indicates an independently audited information security management system. Either provides a reasonable level of assurance. If your MSP has neither and cannot explain how they validate their own security posture, that gap is worth discussing before granting privileged access.

Q: What is a Data Processing Agreement and do I need one?

A: A Data Processing Agreement (DPA) is a formal contract specifying how a vendor may process personal information on your behalf — including the purpose of processing, security measures required, sub-processor obligations, and breach response obligations. Australia's Privacy Act does not mandate DPAs in the same form as the GDPR, but having one is strong practice for any vendor handling personal information of your customers or employees, and may be required under contracts with international partners operating under GDPR or similar frameworks.

Q: Can supply chain attacks be covered by cyber insurance?

A: Most cyber liability policies cover data breach, business interruption, and third-party liability — all of which supply chain attacks can trigger. However, coverage depends on policy wording. Some policies exclude attacks exploiting unpatched vulnerabilities, which is relevant given that incidents like MOVEit involved exploited software flaws. Ask your insurer explicitly how coverage applies to third-party vendor incidents and whether exclusions could limit a claim originating in a vendor's environment. Maintaining good security hygiene — timely patching, vendor due diligence — generally strengthens both your insurability and your claim position.