Ghost Tenants: The Test Accounts Still Holding Live Data

It usually begins with a demo. Someone in sales or operations needs to show a client how the new booking flow works, so a free trial gets spun up on a Friday afternoon. Six months later that same tenant is processing real orders, and nobody can remember who owns the admin console.

Sandboxes rarely announce their promotion. They just stop being empty. One integration gets pointed at real data because the dummy records weren't realistic enough, then a payment key gets pasted in because test mode was fiddly, and before long you have a system that looks like a toy but behaves like infrastructure.

The awkward part is that these accounts sit outside the usual checks. They don't appear in the procurement spreadsheet. They aren't in the renewal calendar. And because they were never formally approved, nobody feels responsible for reviewing them.

The slow path from demo to dependency

A few routes lead here, and most UK teams will recognise at least one.

The first is the realistic-data shortcut. A tester copies a slice of the live customer table into the sandbox so the demo looks convincing. That slice is personal data, and it now lives in an environment with weaker access controls and a vendor whose trial terms probably say something vague about retention.

The second is the shared login. Trial accounts often get created with a generic address — admin@ or test@ — and the password gets passed around in a chat thread. No audit trail, no offboarding, no idea who has seen what.

The third is credential bleed. Someone grabs the production API key because the sandbox integration kept failing, and now a test tenant can write to real systems. That one tends to surface at the worst possible moment.

What tends to be living in there

Before you go hunting, it helps to know what you're looking for. In our experience the usual residents are:

• Real customer records, often a partial export with names, emails and occasionally free-text notes.
• Production API keys, SMTP credentials or webhook secrets pasted in for convenience.
• Shared logins with no individual attribution.
• Live integrations — a sandbox form that still emails a real distribution list, or a test tenant wired to the live CRM.
• Vendor-side trial terms that nobody read, including data deletion schedules and support entitlements.

Any of these is worth a conversation. A combination of them is worth a proper tidy-up.

A short audit you can finish in an afternoon

You don't need a project plan for this. You need a spreadsheet, a couple of questions and the willingness to annoy a few people.

1. Build the list. Start with three sources: the finance team's card transactions, the SSO app catalogue if you have one, and a trawl through browser bookmarks on shared machines. Trial sign-ups usually leave a paper trail somewhere. Ask each team lead to name every non-production system their people touch.

2. Attach an owner. Every account needs a named human, not a department. If nobody will claim it, that itself is the finding.

3. Classify the data. For each account, ask one blunt question: does this contain real personal data, or synthetic test data? If it's real, you have a UK GDPR question to answer — lawful basis, retention, and whether the vendor's terms actually cover that use. The ICO's guidance on storage limitation is worth a skim before you decide to leave it sitting there indefinitely.

4. Check the credentials. Anything shared gets rotated. Anything that could reach production gets revoked and reissued with narrower scope. If a sandbox needs to call a live service, it should do so through a key you can trace and kill.

5. Look at the integrations. Sandboxes that send email, post to Slack or write to a CRM are the ones that cause embarrassment. Disable outbound connections you can't justify.

6. Decide: keep, rebuild or bin. Some sandboxes are genuinely useful and should be kept — but promoted to a proper environment with an owner, a review date and documented access. Others should be rebuilt cleanly rather than patched. The rest should go.

Killing one cleanly

Deletion is easy to say and surprisingly easy to get wrong. Export the configuration and any templates you actually need, but don't export the data. Ask the vendor for written confirmation of deletion, especially where personal data is involved — trial terms often allow them to retain it for a period you didn't agree to.

Then close the loops: remove the account from SSO or your password manager, delete the shared mailbox, revoke the API keys, and update any documentation that pointed at the old tenant. If the sandbox appeared in a runbook or an onboarding guide, fix that too.

Stopping the next one

A naming convention helps more than it sounds. If every trial tenant is prefixed sbx- and every one of them has an owner field filled in at creation, the next audit takes twenty minutes instead of an afternoon.

It's also worth adding a single question to your procurement checklist: does this tool create a non-production environment, and who owns it? That one line catches most of the problem before it starts.

The aim isn't to ban sandboxes — they're genuinely useful. It's to make sure they don't quietly grow up into production systems without anyone being in the room when it happens.