The legacy app nobody is maintaining is still holding customer data

How applications end up here

Over the past few months our team ran security reviews across a set of older applications built between 2019 and 2022. Hand-coded originally, still in daily use, none of them under an active maintenance contract. What came back was consistent enough to show the problem is not any one build or any one developer. It is a category of risk that a lot of Australian businesses are carrying right now without knowing it.

The path is always the same, and it is not the result of anyone being reckless. An application gets built. It works. Budget moves on to the next thing, because technology costs money and the thing you can see on the screen is working perfectly well. Nobody is asking for new features, so nobody is opening the codebase.

"If it isn't broken, don't fix it" is a defensible position for a piece of machinery. It is a much weaker position for software, because software sits on a foundation of other people's code that keeps moving whether you touch yours or not. The framework goes end of life. The language version stops receiving security patches. The vulnerabilities being published every week are cumulative, and the gap between what your application runs and what is currently supported grows.

There is a second gap that gets discussed far less, and it is the more interesting point. Best practice has moved enormously over the last ten years. How authorisation should be structured, how identifiers in a link should be signed, how secrets should be stored, how uploads should be handled, how dependencies should be watched. The frameworks have moved with it, to the point where the safe way to build something is now usually the default way. But none of that reaches code that nobody opens. An unmaintained repository does not only miss security patches. It misses a decade of the industry getting better at this, and it stays frozen at the standard of the year it was written.

Our own pipelines force dependency updates before code merges, and over the past twelve months that has become an area of real focus. None of it is of any use to an application nobody is maintaining. That is a different problem from modernising the architecture underneath an application, where the question is how the systems are put together. Here the code itself is what nobody has opened.

Eventually business arrives at a genuinely uncomfortable position. The application is too far behind to justify the cost of upgrading, but too embedded to switch off, and there is no business case for a rewrite because from the outside nothing is wrong. Meanwhile the thing is still sitting there holding customer records, addresses, payment details, and in some cases health or children's information.

The legal position has moved

Twelve months ago that could reasonably fly under the radar. It cannot now.

The Privacy and Other Legislation Amendment Act 2024 is in effect, and two parts of it matter for this conversation. First, it clarified that taking "reasonable steps" to protect personal information expressly includes implementing appropriate technical and organisational measures. Application security is no longer just good engineering practice. It is named in the obligation. Second, since 10 June 2025 there is a statutory tort for serious invasions of privacy, which means an individual can now bring an action directly rather than waiting for a regulator to act. That sits alongside a tiered civil penalty regime and expanded powers for the Information Commissioner. The same Act requires a Children's Online Privacy Code to be registered by 10 December 2026, which matters to anyone whose application is likely to be accessed by children.

And it is about to move again

On 31 August 2026 the Attorney-General's Department released the exposure draft of the Privacy Amendment (Personal Data Protection) Bill 2026, the second and much larger tranche of reform. It is not law yet and consultation closed on 18 September, but the direction is clear. It proposes a single "fair and reasonable" test for how personal information is handled, and it would require notification to the Information Commissioner within 72 hours of becoming aware of reasonable grounds to believe an eligible data breach has occurred, a timeframe the consultation paper lines up with the Security of Critical Infrastructure Act 2018 and the Cyber Security Act 2024.

Seventy-two hours is not enough time to work out what happened in an application nobody has opened in three years.

None of this is legal advice. But you do not need to be a lawyer to see that "we inherited it and nobody maintains it" is heading towards not being an answer. The same obligation applies to us, which is why we publish our own information security and privacy posture rather than describing it on request.

What it comes down to

None of this is exotic. There is no sophisticated attack chain in it. It is ordinary work that stopped being done, in applications that looked fine because looking fine is exactly what an unmaintained application does right up until it doesn't.

If you own software that holds other people's information and you cannot name the person responsible for patching it, that is the finding. You do not need a review to tell you that one.

We are happy to talk to anyone sitting on an application in this position. Checking one is a much smaller piece of work than most people expect, and considerably smaller than the alternative. It is the same ground a written review of the code, the infrastructure and the security posture covers, and it is where support for an application somebody else built begins.