Whose Name Is on the Account
A study of retail systems held by someone else, from the public record: a small start-up stopped through the account of someone who had left, a large grocer moving off systems it had shared with a former owner, what the government's summary of India's data protection rules says, the options, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study · From the public record. Neither organisation described here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record, reported as the record gives it and without judgement.
| Organisation type | A small grocery delivery start-up whose systems were reached through the account of someone who had left; and a large grocer moving off systems it had shared with a former owner |
| Size band | The start-up: a small team. The grocer: very large. Our reader: a mid-size retailer, brand or online seller |
| Region | India (the start-up) and the UK (the grocer) |
| The decision at stake | What a firm should do when the accounts, the code or the systems it runs on are held by someone else: a former employee, an agency, a former owner |
| The public outcome | In mid-2025 the start-up lost its app code and its servers, and its app stayed up but could not take orders. The grocer’s work moving off thousands of older systems it had shared with a former owner cost more than £1 billion by the end of 2025, and its leadership said the work delayed its recovery |
| Why it matters to a mid-size retailer | Few firms can say whose name is on each account, code repository and domain they depend on. The question is whether they find out on a plan, or on the day something stops or someone else sets a date |
2. The Business Problem, in the Buyer’s Words
“Our shop went down on a Saturday and we could not get into the hosting account. It turned out the agency opened it years ago in its own name, and the agency has since been sold. The domain is in the name of someone who left in 2021. A second agency would happily quote to look after the shop, but it wants the code, and our agency will release it only when we leave. And a customer has just asked us what we hold about her. I own this business. I am not sure what I actually hold.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The firm is caught between systems it pays for and cannot get into, and a supplier it cannot compare or leave because nobody else can describe what it runs.
3. What We Found
Method. We went through the public record on retailers whose systems, code or accounts were held by someone other than the firm: news reporting of an attack on a small Indian grocery start-up in 2025, reporting of a large UK grocer moving off systems it had shared with a former owner, to the end of 2025, and the government’s summary of India’s data protection rules, notified in November 2025.
An account outside the firm’s control.
| What | Public record |
|---|---|
| The firm | A small Indian grocery delivery start-up with a small team |
| When | In mid-2025 |
| The way in | According to the company, through the account of someone who had left |
| What was lost | Its app code and its servers |
| Scale | Tens of thousands of customers |
| Effect | Its app stayed up but could not take orders |
This is a failure of access control at a start-up, not an old system. The record does not say who did the wiping, and this study does not either.
A separation from a former owner’s systems.
| What | Public record |
|---|---|
| The firm | A large UK grocer |
| Scale | Thousands of older systems it had shared with a former owner, moved to a packaged ERP product on a public cloud |
| Cost | More than £1 billion by the end of 2025 |
| Effect on trading | Sales in the second half of 2025 were hit by disruption to what was on the shelves and to shopping online |
| What its leadership said | The work delayed its recovery |
India’s data protection rules, in the government’s summary. The government’s summary of the Digital Personal Data Protection Rules, 2025 says they were notified “on 14 November 2025” and “introduce an eighteen-month period for phased compliance”. It says that “Every Data Fiduciary must issue a separate consent notice that is clear and easy to understand”, and that Data Fiduciaries “are required to address all requests related to access, correction, updating or erasure within a maximum of ninety days”.
Our reading of why firms end up here. These four are our reasoning from the record above. None is a finding of any source.
- Nobody keeps a list of who holds what. Accounts were opened by whoever was helping, in their own names, and the names were never updated as people and firms moved on.
- The firm holds no record of its own systems. The builder has the code and the knowledge, so no one else can quote, and leaving looks like starting again.
- A firm that leaves one holder can simply acquire another, unless what is built runs in accounts in the firm’s own name.
- Leaving is planned as one switch on someone else’s date, because everything is tied together and nobody on the firm’s side knows how.
Our reading, and only that: where customer records sit in systems another party built and runs, a request to see, correct or erase personal data waits on that party too.
What this record does not show. The two cases sit at opposite ends of size, and neither is a close fit. The start-up is a small firm, and its case is about access, not old technology; the record does not say who did the wiping. The grocer is very large, its move was to a packaged ERP product, which is not IOanyT’s kind of work, and we did not examine why that project cost what it did or what caused the disruption; we draw no cause from it. We found no public case of an agency or a freelancer withholding code or accounts from a retailer, and we do not suggest it is common. We found no figure for how many retailers hold their systems in other people’s names, and no named mid-size case. The data protection rules are taken from the government’s summary, not the rules’ text; a later change to their timeline was reported and not read; no source ties them to any retailer’s systems. The law on who owns code, a domain or an account was not researched, and nothing here is legal advice.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Keep paying the current holder and change nothing | The relationship works, prices are fair, no move is planned | Every question and quote still goes to one party; the firm learns its position on a bad day | Right only while the firm also makes its list |
| Rebuild everything new from what the systems show on screen, and switch on one weekend | The old systems are few, small and plain | What happens behind the screens is missed and found by customers after the switch, with no old system to go back to | We would advise against this for systems that trading depends on |
| Ask each holder for a handover of the accounts and the code | The holders are known and willing | It is the firm’s own step, sometimes with a lawyer; without a list, accounts are missed, and code on its own describes nothing in plain words | Right, and necessary, as the firm’s own step |
| List who holds what, arrange read-only access to the code, have an assessment write the specification, then rebuild one module at a time in accounts in the firm’s own name | The systems matter to trading, and there is time before any date | You pay the old holder and the new work at once; it takes more months than a single switch, so it must start early | Our recommendation |
What we would have advised against: for a firm in this position, waiting for the day something stops to ask whose name is on an account, and planning a separation as one weekend on a date the other party set, with requirements written from what staff see on their screens.
5. Our Recommendation, and the Decision It Asks of the Board
For the systems a retailer runs on (the shop’s own code, order handling, the links to stock, the till and the accounts), write down first every system, where it runs and whose name holds its account, its code and its domain. The firm’s own people act on that list: they ask each holder for the access and copies the firm wants, and change names and access. The firm then arranges read-only access to the code with whoever holds it. The assessment reads the code and writes a specification of what the systems do, which the firm holds whatever happens next. If the firm is leaving, it starts now: each module is rebuilt in accounts in the firm’s own name and takes over only when it is accepted, with the old system still running. The firm pays the old holder and the new work at the same time, and a staged move begun too late will not finish by a date.
The decision it asks of the board: commission the list now, as the firm’s own work, and approve a fixed-price assessment once code access is arranged. Then approve each stage on its own evidence, with the freedom to pause after any accepted module. The board stops learning what it holds on the worst day, and starts approving a plan it can follow.
6. Benchmark: Where You Are Now, and Where You Should Be
These are targets, not results. In an engagement the starting points are replaced by the retailer’s own figures, taken in the first review.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Systems, with whose name holds each account, code repository and domain | Not recorded; known to whoever set them up | Every system listed, a list for the firm to act on | The list beside the map of the system |
| Read-only access to the code | With the holder; not asked for | Arranged by the firm for every system to be assessed | Confirmed before the assessment begins |
| A written record of what the systems do | None; in the holder’s heads | A specification the firm holds | The specification |
| Where customer details are kept | Known only to the holder | Written down, system by system | The specification |
| Modules rebuilt in accounts in the firm’s own name | None | Rising at every stage, each accepted before it takes over | Reported at every review, with the traceability matrix |
| The cost of leaving | One sum, committed at the start | The old holder’s fee and the new work both in the plan, stage by stage | The cost comparison beside the staged plan |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about the systems the business runs on, who holds them, and the questions it cannot answer without asking. 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.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This study is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is the applications your business built or had built, wherever they are held. 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.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the firm’s own applications, rebuilt module by module in accounts the firm opens in its own name. We never do a single cutover. A traceability matrix links every old function to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
- 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.
8. What the Client Would Own
- The map and the specification: what the firm’s own applications do, in writing, held by the firm whoever runs them.
- The risk register: what the assessment found, including what would stop trading if one account were lost, listed before any price is set.
- The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
- The code: the rebuilt modules are the client’s, in accounts the client opens. No runtime or platform fee.
- The filled-in benchmark: each measure, where it started and where it stands.
9. What This Approach Does Not Cover
- IOanyT does not recover accounts, domains or code from anyone. Getting the code, or read-only access to it, from an agency or a former owner is the firm’s own step.
- IOanyT does not negotiate with an agency, a freelancer or a former owner, and gives no legal advice on ownership, contracts or transitional agreements.
- IOanyT does not manage passwords, review who has access or remove a leaver’s access. The firm’s own people do, using the list.
- IOanyT does not restore systems that have been wiped, and does not secure, scan or monitor systems. Nothing here is a promise that an attack will not happen.
- IOanyT does not host, and does not install, move or choose a packaged shop platform or a packaged ERP product, which is what the larger public case involved.
- PHP is a language IOanyT reads, not one it builds in. The older technologies it reads include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP.
- IOanyT does not offer a compliance, audit or legal service, and says nothing about what card-payment or data protection rules require of a particular firm. Meeting the data protection rules is the firm’s own work.
- A staged move does not make a date that is too close achievable. Begun too late, it will not finish by the date.
- This study does not say IOanyT would have prevented the events described, or that IOanyT has done this work for a retailer. IOanyT has no published case of this work for a retailer.
About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.
10. Sources
| Source | Used for |
|---|---|
| News report, 2025 | A small Indian grocery delivery start-up |
| Trade press, 2026 | A large UK grocer moving off systems it had shared with a former owner |
| PIB backgrounder, 17 November 2025 | The government’s summary of India’s data protection rules |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. This issue starts with a conversation: what your business runs on, and whose name is on each part of it.
Read the research notes on this issue
Accounts and systems held by someone else
Research note 1
Many Firms Cannot Say Whose Name Is on Their Own Systems. They Find Out on the Worst Day.
Many retailers cannot say whose name is on their own systems until the worst day. What the public record shows, four ways to respond and a benchmark.
Research note 2
A Firm That Does Not Hold Its Own Systems Cannot Plan a Move.
A retailer whose agency or former owner holds the code cannot get a second quote or plan a move unaided. What waits, four ways forward and a benchmark.
Research note 3
Leaving Someone Else's Systems Is Not a Weekend. It Is a List, Then One Module at a Time.
Leaving systems held by someone else is not a weekend job. The benchmark we would set: list who holds what, then move one module at a time.