A recent proposal in the UK to consider making software manufacturers more accountable for cyber breaches caught my attention. For me, it raised a question that I think deserves more discussion here in Australia: when something goes wrong, who should actually be held responsible?
At first glance, the argument for holding software vendors accountable seems pretty straightforward. If a vulnerability exists in a product they've developed and sold, shouldn't they bear some responsibility when that vulnerability is exploited?
With a simplistic lens, I think there could be a strong argument for that. Too often, businesses are left dealing with the financial and operational fallout from security weaknesses they had little ability to identify or prevent themselves.
But having spent years working with enterprise technology, customers and managed IT services, I think there's another side to this discussion.
Where does the vendor's responsibility end, and where does the responsibility of the organisation deploying and managing that technology begin? It's not always an easy question to answer.
We rightly expect software vendors to take security seriously. Products should be designed with security in mind, vulnerabilities should be addressed promptly, and customers should be given clear information about risks, updates and ongoing support.
Security Doesn't End With the Software
But even a well-designed product can be rendered vulnerable by how it's implemented or managed.
Configuration matters. Access controls matter. So does keeping systems up to date, applying security patches and making sure someone is actually monitoring what's happening.
These aren't new challenges for anyone working in IT, but they really complicate the question of liability when things go wrong.
Security Doesn't End With the Software
Imagine a vendor releases a product with a serious vulnerability. A patch eventually becomes available, but it isn't applied. Perhaps the customer is concerned about disrupting a critical business application. Perhaps the managed service provider is waiting for approval to make the change from the customer. Or perhaps nobody has clearly established who is responsible for identifying the vulnerability and ensuring it gets addressed. You can see where this starts getting confusing from a liability standpoint.
If an attacker exploits that vulnerability, who should carry the can?
The software vendor might argue that a patch was available. The service provider might point to the customer's failure to approve the change. The customer might reasonably ask why the risk wasn't identified and escalated earlier.
Depending on the circumstances, each party could have a legitimate point.
That's what makes this issue more complicated than simply deciding whether software manufacturers should be liable for security breaches.
Where Do Managed Service Providers Fit In?
What about the people responsible for managing the technology? This is where I think the discussion becomes particularly relevant to managed service providers and managed security service providers.
Organisations increasingly rely on external partners to manage their IT environments, monitor threats, maintain systems and help keep their businesses secure. In many cases, these providers are responsible for a significant part of the day-to-day work required to maintain a secure environment. But what does that responsibility actually mean?
If an MSSP is contracted to manage patching and fails to act on a critical vulnerability within the agreed scope of its services, it's reasonable to ask whether the provider has failed in its obligations.
On the other hand, if the provider has identified the risk, recommended remediation and clearly explained the consequences of delaying a patch, but the customer decides not to proceed, the situation looks quite different.
And what if the vulnerability was the result of a fundamental flaw in the software itself – something the customer and its service provider could not reasonably have anticipated or prevented? These scenarios shouldn't necessarily be treated the same way.
From my perspective, can the need for responsibility be shared and reflect what each party was actually responsible for, what they knew, what they could reasonably have done about it, and whether they had the authority to act?
That might sound obvious, but it isn't always reflected in the way organisations think about cybersecurity risk or the contracts that underpin their technology arrangements.
What Does This Mean for Australia?
Being born in England (and reading British/European news keeps me connected), but I’ve lived in Sydney for over a decade and therefore I’ve done some initial research to help me correlate and understand how the Australian Government might already approach this. I’m not a legal expert but I understand that Australia already has legal protections and obligations relevant to this issue, including provisions under Australian Consumer Law, general principles of negligence and contractual obligations.
The Australian Consumer Law can apply to computer software in relevant circumstances, including through consumer guarantees and provisions dealing with goods that have safety defects. However, that doesn't mean every software vulnerability automatically makes a manufacturer liable for a resulting cyber breach, particularly where a business is seeking to recover commercial losses.
Australia has also introduced mandatory security standards for certain internet-connected consumer products under the Cyber Security Act 2024 and associated rules. These are positive steps towards improving product security. But they don't establish a universal rule that software manufacturers are responsible for every breach involving their products.
Should Australia Go Further?
With the UK Government’s proposed policy consideration, that still leaves me with some important questions.
• Should and could Australia go further in establishing minimum expectations for software security, vulnerability disclosure and the provision of security updates?
• Should vendors have clearer obligations around how long products will be supported and how critical vulnerabilities will be addressed?
• And if stronger obligations are introduced, how should they interact with the responsibilities of the businesses and service providers deploying and managing those products?
I don't think these questions have simple answers. But the UK's proposed consideration of software liability could give Australia a good reason to examine whether our existing approach adequately reflects how technology is actually used and managed today. Only in June this year did Albanese give notice of the OpenAI research agent that bypassed security controls while conducting online research into medical spending.
With enterprise software and AI guardrails, is the answer simply a shared responsibility, but with clearer boundaries? I’m not so sure. The phrase ‘shared responsibility’ is used frequently in cybersecurity. The problem is that it can sometimes become a convenient way for everyone to acknowledge a problem without anyone being clearly accountable for fixing it.
Software vendors should take responsibility for the security of the products they develop and the vulnerabilities they can reasonably prevent or address. Service providers should take responsibility for the services they've agreed to deliver, including appropriate configuration, monitoring, maintenance and escalation. Customers also have a role to play. They need to make informed decisions; understand the risks they're accepting and ensure that the people managing their technology have the authority and information they need to do their jobs properly.
I don’t think the boundaries will ever be clear-cut. A single incident might involve a product vulnerability, a configuration weakness and a delayed patch. More than one party may have contributed to the outcome.
That's precisely why clear contracts, documented decisions and well-defined responsibilities matter. When a serious incident occurs, there should be a reasonable way to establish what happened, what each party knew and whether the appropriate actions were taken.
Shared Responsibility Needs Clear Accountability
The objective shouldn't be to find a convenient party to blame after the event. It should be to make sure everyone involved has a genuine incentive to prevent the incident in the first place. For me, it's a conversation worth having in Australia.
I can understand why there's growing interest in making software manufacturers more accountable. Businesses shouldn't have to carry the full cost of security weaknesses that they had little ability to prevent. But I also think we need to be careful not to oversimplify the issue. A vulnerability in a product, an insecure implementation and a failure to apply a critical patch are all different problems. They may, and do, overlap, but they don't necessarily have the same cause or warrant the same allocation of responsibility.
With some of the conversations I have with our customers, who operate complex IT environments, security depends on more than the quality of the software they buy. It also depends on how that software is configured, integrated, maintained and supported throughout its life.
As an industry, we should be asking whether our legal frameworks, commercial arrangements and operating practices adequately reflect that reality. If we're going to hold software vendors more accountable for cyber breaches, we also need to be clear about where the responsibilities of customers and service providers begin, and how we determine who was genuinely in a position to prevent the failure.
Where I feel it’s a collective responsibility, that's the part of this debate I think deserves much closer attention.
