The Accidental Production Estate: Auditing UK Pilots That Never Got Switched Off

A proof of concept is meant to be disposable. In practice, many UK organisations are running systems that began as pilots and never received a formal decision. They are absent from the service catalogue but hold live data. They are missing from the architecture repository but have integrations. They are not supported by the service desk, yet people depend on them. This is the accidental production estate.

As 2026 draws to a close, such systems tend to surface. A year-end report fails because a departmental database was never backed up. An leaver retains access to a low-code app that still processes customer records. An invoice appears for a SaaS trial that became a team workflow. The underlying problem is not technology. It is the absence of an explicit transition from experiment to operation.

Why pilots drift into production

Pilots drift for understandable reasons. A team needs a quick answer. A vendor offers a free tier. A low-code platform lets a business analyst build something useful without a development backlog. The pilot is described as temporary, so it bypasses change control. No exit criteria are agreed. No owner is named beyond the original enthusiast. When the enthusiast moves role, the system remains.

UK data protection obligations do not recognise the pilot label. If a system processes personal data, it is live processing. The same applies to systems that feed statutory reporting, finance reconciliations or operational scheduling. The question is not whether a system was intended to be temporary. The question is what it now does, who relies on it and what happens if it fails.

Build a discovery ledger, not a wish list

Do not rely on the configuration management database alone. Pilots often sit outside formal discovery because they were never submitted for registration. Use triangulation instead. Finance records can reveal SaaS subscriptions, purchase-card spend and renewal dates. The identity provider can show single sign-on applications, OAuth grants and guest accounts. Network teams can supply DNS records, certificates and shadow IT reports. Data platform logs can identify connections to warehouses and reporting tools. Business unit interviews can confirm what people actually use.

Create a ledger with consistent fields. Record the system name, business sponsor, business owner, technical custodian, stated purpose, data classes, whether personal data is involved, approximate volume, integrations, access methods, support route, annual cost, last review date and current decision state. Keep the ledger short enough to maintain. A spreadsheet is acceptable for the first pass, provided it is itself governed.

Five tests that separate experiment from operation

First, ownership. A system in production needs a named business owner and a named technical custodian. If either is missing, that is a finding, not an administrative gap. The business owner must be able to describe the operational consequence of outage. The technical custodian must be able to describe how the system is patched, backed up and monitored.

Second, access. Trace every path to the system. Who can reach it through single sign-on? Are there local accounts, shared credentials or API keys? Do external suppliers or contractors have access? Is multi-factor authentication enforced? Are dormant accounts reviewed? A pilot with open access is not a pilot. It is an exposure.

Third, data flow. Identify sources and sinks. What data enters, what is stored, what leaves and where does it go? Are copies made for reporting or export? Is retention defined? Does data cross borders, and if so, under what transfer mechanism? For UK organisations, the data protection impact assessment may be missing even though the processing is real.

Fourth, support. Ask who fixes the system at 2am. Is it in the service desk tool? Is there monitoring? Are there backups, and have restores been tested? Is patching applied? Is there a runbook? If the answer depends on one person remembering a password, the system is not supported. It is tolerated.

Fifth, dependency. Determine what breaks if the system is switched off. Look for reports, integrations, manual workarounds and downstream teams. A small tool can sit upstream of a statutory return or a customer-facing process. Dependency is the strongest signal that a pilot has become production by default.

Promote, contain or close

Use three decision states. Promote means the system meets the organisation's standards for production. That requires formal service transition, architecture review, security assessment, data protection review where relevant, a support model, backup and recovery arrangements, change control and a budget line. Promotion is not a reward for longevity. It is a commitment to operate the system properly.

Contain means the system remains temporarily but under constraint. Set a time-boxed exit date, a named owner, restricted access, data minimisation, monitoring and a documented migration or retirement plan. Containment is not a synonym for keep as is. It is a holding pattern with an end date.

Close means retire the system. Migrate any records that must be retained, revoke access, delete data according to retention policy and notify users. Closing a pilot can be politically difficult, particularly when a team depends on it. That is why the decision needs a forum with business, technology, security and data protection representation. The goal is not to punish innovation. It is to stop accidental production from becoming permanent operational debt.

Make the audit a standing control

One audit will find the current estate. A standing control will prevent the next one. Add a pilot register to digital operations governance. Require exit criteria before a pilot starts. State explicitly that a pilot processing live data must meet minimum access, backup and ownership standards even during the trial. Reconcile the register quarterly against finance, identity and network records. Treat renewal notices and leaver events as triggers to review pilot status.

The accidental production estate is rarely created by malice. It is created by omission. A formal decision is deferred, then forgotten, then replaced by dependency. UK teams can recover control by finding these systems, testing them against operational standards and deciding their fate. The alternative is an estate that no one owns, no one supports and everyone relies on. That is not a pilot. It is unmanaged production.