Your Policy Says the Record Is Deleted, and Nobody Has Read What the Code Does. Four Ways to Find Out, Weighed.

The head of product is revising the product’s privacy wording. One sentence has been there since the first version: files attached to an account are deleted thirty days after the account is closed.

To be safe, the head of product asks engineering to confirm it. An engineer reads the code for an afternoon and comes back with an answer nobody expected.

After thirty days the files are marked as deleted, and the product stops showing them. The files themselves stay where they are. Nothing in the code the engineer read removes one.

What We Found

For this article we went through the public record on why old systems, and what they do, stay as they are: one survey of IT professionals on the challenges of old systems and the reasons for not replacing them. We say first what this article does not offer. IOanyT does not judge whether a policy, or any data protection rule, is met. We do not carry out security reviews, we do not delete data, and we do not look at or handle the records themselves.

Three findings stand out.

Old systems are common, and much of what they do was decided long ago. 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.

Firms leave old systems alone because they work. In the same survey, half said the biggest reason they had not upgraded was that “the current system still works”. A step in the code that stopped removing a record after a change produces no error.

Money and disruption hold the rest back. In the same survey, 44% named budget limitations among their reasons for not modernising, and 38% fear of disrupting operations.

Our reading is that a firm’s policy is written by people describing what the product was meant to do, and the code is what it does. The two part company for ordinary reasons. “Deleted” has more than one meaning in code: a record can be removed, or marked as removed and hidden. Copies are made along the way, such as an export, a log entry or a smaller version of an image. And when a feature is rebuilt, the step that removed old records may not be carried over, while the sentence in the policy stays the same.

What the Firm Cannot Do While Policy and Code Are Unchecked

While nobody has read the code with the policy in hand, the firm has three things it cannot do.

It cannot check its own policy. Every sentence about a record rests on what someone was told when it was written.

It cannot check its own record of what it holds. The firm’s list of the personal data it keeps, and where, was written from what each team remembered. The copies the code makes along the way are on it only if somebody thought of them.

Its security team cannot protect what it was never told about. Our reading is that this is the sharpest of the three: the people whose job is protection protect the stores and copies on their list, and a copy made by the code and named nowhere is outside it.

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

Four Ways to Find Out What the Code Does, Weighed

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

Option	When it fits	What it risks
The firm’s own team lists the stores and copies from memory and from the bills	The product is young, small and built by people who are still there	People answer with what the product was meant to do; copies made by the code are the first thing missed
An outside security or data-protection firm reviews, of the firm’s own choosing	The firm needs a view on its security or its duties	The review starts from what the firm can describe; what the code does that nobody described may not reach it
Leave it until the next rebuild, and get it right then	A rebuild is close, and the policy is being rewritten for it	The gap stays open until then, and a rebuild planned without the account may carry it into the new product
Read the code first, then hand the written account to the firm’s own people, or to the outside firm it chooses	The product is old and much changed, and the policy has not been checked against it	It costs money before anything changes, the answer may be unwelcome, and what the code shows must still be confirmed by the firm’s own team

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
Kinds of record with a written account of what the code does with them	None; the policy describes the design	Every kind of record the code handles, with what the code does once its purpose is served and what sets it off	The written account in the specification, confirmed by your own people
Copies the code makes on the way	Not listed	Every copy the code makes (exports, logs, smaller versions) named, with where it goes	The written account in the specification
Stores named in the code, set beside the stores on the firm’s own list	Never compared	Every store the code names is on the firm’s list, or marked as a difference for the firm’s own people	The store list
Development kept apart from live data	Not stated	All work done apart from the live product, on separate data, never live customer data	The staged plan, reviewed at every stage

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, the kinds of record it handles and what your policy says about them. 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. For each kind of record, the specification gives a written account of what the code does once the record’s purpose is served, and where it copies the record on the way, so that your own people and lawyers can set it beside your policy. 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, 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. 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. We do not judge whether your policy or any data protection rule is met, and we give no legal view on what a gap means. We do not carry out a security review, and we do not delete, move or handle records; any change to live data is made by your own team. Reading code shows what the code would do: a job that is written but never runs can still mislead, so your own team confirms what really happens. The account covers what the code does, not what staff do by hand. 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	What the firm tells its users and what its product does can be set side by side by the firm’s own people.
CTO or CIO	A written account, taken from the code, of what happens to each kind of record when its purpose is served: deleted, hidden, moved or kept.
CISO	The copies the code makes along the way, such as exports, logs and smaller versions of images, are named, so they can be included in what the firm protects.
Head of risk and compliance	The firm’s own people and lawyers can set each sentence of the policy beside a written account of what the code does, with the code’s evidence in hand.
Head of product	The firm’s own people and lawyers can check its privacy wording against what the product does, and a gap becomes a piece of work on the roadmap and not a surprise.

None of these means that anyone’s records are safe, or that a policy or a rule is met.

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

The case	What IOanyT does
This article names no organisation. Its figures come from a vendor’s survey of IT professionals, which we do not name.	We read a product’s own code and write down what it does with each kind of record once its purpose is served, for the firm’s own people and lawyers to set beside the policy. We do not judge whether a policy or a rule is met, review security, or delete or handle data.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write down what the code does; what your policy should say, and whether it is met, stays with your own people and your lawyers.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →