In the inventory of any large organisation there are custom applications nobody remembers commissioning. They solved a real problem eight or ten years ago, they still run, and their supplier changed hands, wound up or stopped answering. Nobody has touched them since because nobody had to, and that is exactly the problem.
It is worth saying without drama. An old application that does its job is not a management failure, it is an investment that worked. What fails is not the program, it is that the relationship keeping it alive ended without anyone formalising it. The day something has to change, integrate with another system or fix a security flaw, it turns out there is no code, no documentation and no contact.
The risk takes three shapes and all three fit in a report. The first is paralysis, when a regulatory change forces a change to the program and there is nobody to make it. The second is security, because every application rests on third party components that age and accumulate known flaws nobody is fixing. The third is traceability towards the client and the regulator, who ask more and more often who maintains the software handling their data.
Custom software does not break. It is orphaned, and that only shows the day it has to change.
What gets signed before commissioning
These clauses do not make a build more expensive, but they are asked for before the first invoice. After that they are not negotiable. They work as a contract review criterion and as a reusable annex for procurement.
- Code ownership and delivery. That the source code belongs to the organisation and is delivered with every version, not only at the end. Without this, the rest is pointless.
- Code escrow. A copy in a repository owned by the organisation from day one, with its own accounts, not the supplier's.
- List of third party components. Which libraries and services it carries and in which version. That is what tells you, years later, whether a published flaw affects you.
- Who patches and how fast. A written commitment to fix security flaws with its own window, separate from the one for improvements.
- For how long. The years of maintenance included and the renewal price, so renewal is not a negotiation from scratch.
- Minimum documentation. How it installs, where it is configured and what it takes to bring it up on a new machine. One good page beats a hundred page manual.
- Orderly exit. What the supplier hands over if the relationship ends and within what window, including the data in a format readable without their program.
- Who to call. A named person and a channel, with a commitment to flag it when that person changes.
Four tests on what is already in production
Legacy applications do not take retroactive clauses, but they do take four tests that fit in one cycle and produce evidence for the report.
- Who built it and whether they still exist. Cross the application inventory against the supplier master. The ones that do not match are your first work list.
- Where the code is. Ask for the repository path and check access with an organisation account. If nobody answers, recovering it later costs far more than asking now.
- What it runs on. Operating system, database and runtime versions. If any is out of support, the application inherits that problem whole and the finding has an owner.
- What happens if it does not start tomorrow. How long the business process holds without it and whether a copy exists to rebuild from, with the date of the last tested restore.
None of those questions is technical underneath. They are all dependency questions, the same kind that order the risk universe behind the annual plan, as seen in what teams are going to audit this cycle.
The next custom build will be commissioned anyway, because often it is the right call. The difference between commissioning it well and badly is not price or deadline, it is eight lines of contract written once. And what stays in the file is the evidence that the application will still belong to the organisation the day the supplier disappears.
