Platform Health Check

Who it is for

The Platform Health Check fits when you are responsible for a platform in production and nobody can tell you, with evidence, what condition it is in.

• You have inherited a platform and the team that built it has moved on.
• An application built years ago is still in production and still holds customer records, and nobody has opened the codebase since the developer left.
• A build stalled and someone needs to establish what actually exists before deciding what to do with it.
• You are acquiring a business and its software is part of what you are buying.
• A supplier is proposing a support contract or a rebuild and you want an independent view first.

If you already know what you want built and need a price for it, the Product Development Plan produces one. If we built the platform and you want it looked after, Product Support starts without a health check.

Still running, no longer owned

The most common platform we are asked to look at was built years ago, works, and has had no budget since, because nothing on the screen looked wrong. Software does not hold still while it is left alone. The frameworks and packages underneath it keep moving, so it misses the security patches published for code it already runs, and it stays frozen at the practice of the year it was written for authorisation, secrets and file uploads. The application ends up too far behind to upgrade casually and too embedded to switch off, while still holding customer records. The health check establishes what that position costs before something forces the question.

Health check or roadmap?

The Platform Health Check reads one platform in depth: its code, infrastructure, security and documentation. The Technology Roadmap maps several systems and the manual work between them, scores the options and never reads code. If one platform is the worry, start here. If the estate and the order of work is the worry, start with the roadmap; it often names a health check on one platform as the first initiative, and the roadmap fee is credited against it.

What you get

A written report about a week after the review begins, and an hour of playback to go through it.

• The code: what the platform is made of, how it is put together, which dependencies are no longer maintained and how much of it is covered by tests.
• The infrastructure: where it runs, what it costs to run, how it is deployed and what would happen if the account holding it were lost.
• The security posture: whether every route requires a login and every record check runs, which dependencies carry published advisories, how secrets are held, and who can reach the server directly.
• The documentation, judged by whether an engineer who has never seen the platform could operate it from what exists.
• Findings ranked by exposure, in the order we would fix them, so the decision to patch, support or replace is made with evidence in hand.
• One recommendation with the reasoning written down: support it as it stands, rebuild it in stages, or leave it with whoever runs it today.

The report describes the platform as it runs rather than as its documentation says it runs. It is yours, and it is written so that another engineering team could work from it.

How it runs

1. A 30-minute call. We confirm which platform the review covers and the access we will need. Nothing is invoiced before this call.
2. Kickoff and access. An hour with whoever knows the system best, and read access to the repositories, the cloud account and any monitoring.
3. The review. A few days of reading once access is granted, across the code, the infrastructure and the security posture.
4. The report, about a week in. Findings for each area, what would have to change for the platform to be safely supported, and the recommendation.
5. Playback. An hour on the findings and what to do next.

What the security review looks at

These are the checks that most often change the picture on an application nobody has opened for a while. An application does not have to be badly built to fail several of them after a few years without an owner. Each is a question about your application, and the report answers it from the code rather than from memory.

• Does every endpoint require a login? Routes added beside a protected group rather than inside it read as protected while being open to the internet, so the report lists every route and its authentication state.
• Does the authorisation layer run at all? Knowing who is calling is not the same as checking the record is theirs, and permission logic can sit in a codebase for years disabled or written so that it always passes.
• How does user input reach the database? Whether request values are bound as parameters or assembled into a query as text, and what predates the framework default or went around it.
• What decides a user’s level of access? Registration and invitation paths hand out authority, and anything that lets the person asking influence that decision is a finding.
• Are identifiers doing the work of permissions? Sequential or predictable references carried in links, standing in for a permission check.
• What does the application trust the browser to tell it? Forms that accept and store fields the application should have decided for itself, which is how an ordinary bug becomes a financial one.
• What happens on repeated failed logins? Whether credential endpoints are rate limited per account as well as per source, and whether an application behind a content delivery network can still see the real client address.
• Are uploads and generated documents private? Which file types are accepted, judged from contents rather than name, and whether stored documents can be retrieved by anyone holding the link.
• What are the dependencies and the runtime running? Which packages carry published advisories, and whether the framework and language versions still receive security fixes.
• Where do the credentials and secrets live? Whether any appear in documentation, seed data, the repository, or a file readable by more processes than need it.
• Who and what can reach the server? Whether the origin answers requests directly around whatever sits in front of it, and how many people still hold administrator access from projects that finished years ago.

Where the review leads to remediation, that runs as one change per issue with a test proving the issue is closed, so the same finding cannot come back quietly.

Responsibility for the data has become explicit

The Privacy and Other Legislation Amendment Act 2024 clarified that taking reasonable steps to protect personal information includes implementing appropriate technical and organisational measures. Application security is now named in the obligation. Since 10 June 2025 a statutory tort for serious invasions of privacy has also been available, so an individual can bring an action directly rather than waiting for a regulator to act.

Further change is in draft. On 31 August 2026 the Attorney-General’s Department released the exposure draft of the Privacy Amendment (Personal Data Protection) Bill 2026, with submissions closing on 18 September 2026. The drafting may change, but the proposals include a statement to the Information Commissioner within 72 hours of becoming aware of an eligible data breach. Seventy-two hours leaves little room to establish what happened inside an application nobody has opened in three years.

None of this is legal advice. Decisions about your obligations, and about whether an incident needs notifying, need a lawyer. How National Digital handles information security on its own engagements is set out in our information security and privacy statement.

What happens after

Most platforms move onto Product Support, where the report becomes the first roadmap. Some justify a staged rebuild, which is scoped and quoted through a Product Development Plan, and the health check fee is credited in full against that rebuild if it proceeds within 90 days. A few are in good enough condition to hand back to whoever runs them, with the report as the record. We say in writing which one yours is.

A rebuild is the recommendation we make least often. Replacing a platform that works is expensive and risky, so the report has to establish why the current system cannot be improved in place before it recommends replacing it.