Your Product Still Has a Data Store From Its First Version, and It Is on Nobody's List. What the Firm Lacks Is a List Taken From the Code.

An engineer is going through the monthly storage bill, looking for savings. One line is unfamiliar: a storage area with a name from the product’s first version.

Nobody on the team has opened it. The engineer asks around. A colleague thinks it held the files attached in the product’s first two years, before that feature was rebuilt. The product has not written to it since, as far as anyone knows.

It has been paid for every month for six years. It is on no diagram, and it is not in the firm’s own record of the data it holds.

What We Found

For this article we went through the public record on old data held in places a product no longer uses as its main store: one published account of a data exposure, written by a law firm, and one survey of IT professionals on why old systems stay. We should say first what we do not do. IOanyT does not carry out security reviews. We do not close, secure or delete a data store, and we do not look at, copy, move or handle the data in one.

Three findings stand out.

The problem is on record, in general terms. Recently, one published account, written by a law firm, says data of one kind was still held in an older store, which the article says appeared to contradict the firm’s own policy that data of that kind was deleted once it had served its purpose. We do not name the firm or describe the app, and we take one narrow point from the account: data from an earlier time was still held, in a place that was no longer the product’s main store. The account does not say how the store was reached or why it still held the data, and we do not guess.

Old systems are the usual case, not the exception. In one survey of 504 IT professionals in the US, “across industries and company sizes”, run by a firm that sells software services and not about software firms alone, the summary finding was that “62% of organizations still use legacy systems”. Among the top challenges of those systems, 43% named security vulnerabilities.

What keeps old systems in place is that they still work. In the same survey, half said the biggest reason they had not upgraded was that “the current system still works”. A store the product has stopped using raises no error, so it stays.

Our reading is that old stores are rarely hidden. They drop out of sight: the old store is kept “for now”, the people who knew about it move on, and the firm’s list is written from memory. The product’s code, old versions included, still names every store it was told to use.

What Waits While the List Is Written From Memory

A store nobody remembers is a security matter for the firm’s own security people. Our reading is that before it can be anyone’s matter, it has to be on a list.

The first cost is the question the firm cannot answer. A buyer, an investor’s adviser or the board asks whether the firm knows every place its product keeps data. The honest answer is “we believe so”.

The second cost falls on the firm’s own security people. They protect the stores they have been told about. A store on no list is outside everything they do, through no fault of theirs.

The third is that the gap never closes by itself. Engineering knows what the product uses now, finance pays for what exists, and security guards what it was told about. Nobody sets the three side by side.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Find the Old Stores, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Ask each team what it remembers, and read the storage bills	The product is young, and the people who built it are still there	A list made from memory leaves out what was forgotten, and a bill names an account, not what a store was for
Have an outside security or data-protection firm review, of the firm’s own choosing	The firm needs a view on security or on its duties, and can say where to look	The review starts from the stores the firm can name; a store on no list may never reach it
Leave it until the next rebuild	A rebuild is already planned and close	The old stores carry on until then, and a rebuild planned without the list may leave another one behind
Read the code first, then hand the list to the firm’s own people, or to the outside firm it chooses	The product is old and much changed, and nobody holds a full list	It costs money before anything changes, it covers only what the code names, and every decision after it still has to be made

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own product, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Stores named in the code, set beside the stores on the firm’s own list	Never compared; the firm’s list was written from memory	Every store the code names is on the firm’s list, or marked as a difference for the firm’s own people to look into	The store list, set beside the firm’s own record
Stores nothing uses any longer	Not known	Each one listed, with what once wrote to it, and handed to the firm’s own security people	The store list
Kinds of record with a written account of what the code does with them	None	Every kind of record the code handles, with what the code does once its purpose is served	The written account in the specification
Old stores with a line in the traceability matrix and a named person’s decision	None	Every old store a rebuilt part used, carried across or dropped on purpose, with who decided	The traceability matrix

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a software firm.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your product, how long it has run, and what your own people believe it keeps and where. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here it is limited to your product’s own code and the structure of its databases, taken from the code or from a structure-only export your team gives us, never the data in them. It lists every data store the code still writes to or reads from, and of those, the ones nothing uses any longer, for your own security people to act on. It also lists which accounts, domains, licences and keys are held in whose name. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. Where you decide to rebuild a part of the product or replace a store, we rebuild it one module at a time while the old product keeps running, on React, Node.js, Python or Java. We never do a single cutover. The traceability matrix records every old store that part used, carried across or dropped on purpose, and who decided; your own team carries out what was decided. We keep development work apart from your live product, and the separate place we set up for trying changes runs on separate data, never your live customer data. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This approach has limits, and on this issue they matter more than anywhere. We do not carry out a security review, and we are not a data-protection adviser. We do not close, secure, empty, move or delete a store, and we do not look at, copy or handle the data in one; your own team does whatever is decided. We cannot tell you whether anyone else has reached a store. The list covers what the code names: a copy somebody made by hand, or a store whose code was thrown away, will not be on it. We say nothing about what any data protection rule requires. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a software firm.

What changes for the business:

Role	What they gain
CEO	The firm knows every store its product’s code names, and stops answering “is there anything else?” with hope.
CTO or CIO	A list of every store the code writes to or reads from, with what uses each, and which ones nothing uses any longer.
CISO	The firm’s own security work starts from a list of every store the product’s code names, and not from the ones people remember.
Head of risk and compliance	The firm’s record of what personal data it holds can be set beside what the product’s code actually uses.
Head of product	Product knows which old features left data behind, and can decide what the product should still be keeping.

None of these means that anyone’s records are safe, or that a store has not been reached by someone else.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
A published account, written by a law firm, says data of one kind was still held in an older store, which it says appeared to contradict the firm’s own policy that data of that kind was deleted. We do not name the firm.	Our part is far narrower, and it is not security work. We read a product’s own code and list every store it still uses or once used, so that the firm’s own security people know where to look. We do not review, close or delete a store, handle the data, or say whether a store was reached. We do not say we would have changed anything in that case.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Here we start with a list read from your product’s code, and everything that is decided about each store stays with your own people.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →