The test site that holds your real customers

· · Security

Somebody needed to test a change without breaking the live system. So they stood up a copy: same application, separate address, and, because it was the quickest way to make the test realistic, a copy of the real customer database inside it. It took an afternoon. It was supposed to last a week.

That was eight months ago. It is still running, still reachable from the internet, and it has one shared login or none. It has never appeared on a risk register, a backup policy, or an insurance questionnaire, because as far as the business is concerned it does not exist.

A translation for anyone who does not build software. Alongside the live system customers use, most businesses keep one or more non-production copies for trying changes out first: test, staging, demo, or dev. The point is that you can break them without anybody noticing. The problem is what goes inside them. Made-up data is more work and never quite behaves like the real thing, so copying the live database becomes the quick option. The test copy then holds every customer record you have.

Why these outlive their purpose

Three things go wrong at once. The security is deliberately lighter: nobody decided the test site should be insecure, they decided that multi-factor authentication, meaning a second check beyond the password, would get in the way, and that a shared login was fine for a week. Nothing keeps it patched, because no outage makes anyone look. And nobody owns it, which makes the first two permanent. It was created by one person for one task, the task finished, and no job description contains the sentence "switch that off".

A column in The Register describes exactly this pattern, found during an audit: a staging instance spun up for a short demonstration, still live months later, wired to real customer data, because the developers did not expect unauthorised people to reach it. That is one person's account rather than an investigation, and its only value is how familiar it sounds.

This is a data protection question too

If real customer records sit in that copy, then under UK GDPR it is not a test system. It is a system processing personal data, carrying the same obligations as the live one.

That matters most at the worst moment. If a forgotten test site leaks, the incident is assessed on the personal data actually exposed, not on the label attached to the server. You may be looking at a notifiable breach, which for most organisations means reporting to the ICO within 72 hours of becoming aware, and telling affected individuals if the risk to them is high. None of that is softened by the system having been temporary in intent. The practical problem is worse than the legal one: the first hours of an incident are a poor time to work out whose data was in a system nobody documented.

If you are a director rather than an engineer, you do not need to follow any of that to act on it. Ask whoever builds or runs your systems one question, and get the answer in writing: what non-production systems do we have, what data is in each, who can reach them, and when is each due to be switched off? A good answer is a short list with four columns filled in. A vague answer is the finding, and it is usually the first time anybody has asked.

What to check

  • List every non-production environment. Test, staging, demo, dev, training, the one on a spare virtual machine, the one on someone's cloud account. Include anything built for a migration, a pilot, or a supplier demonstration.
  • Record what data is in each. Real customer records, a partial copy, or genuinely made-up data. Be honest about copies taken just to test with, including database dumps sitting in folders and cloud storage.
  • Check what is reachable from the internet. If it can be opened from outside your network, it needs the same access controls as the live system, or it needs to stop being reachable.
  • Name an owner and an end date for each. A system with no end date will not get one later.
  • Switch off what is finished. Delete the environment and the data copy, not just the link to it, then confirm the address no longer answers.
  • Change the default. Non-production systems use masked or generated data unless there is a written reason not to, and anything built for a short-term task gets a review date on the day it is created.

How Steelwise can help

Working out which non-production systems exist, what customer data is in them, and which are reachable from the internet is a short, specific piece of work that usually finds something on the first pass. Get in touch if you would like a second pair of eyes on yours.

Further reading

← All filings

We use cookies to understand how visitors use this site. More information.