The Unlisted Interfaces: A Five-Day Review of Ad Hoc Exports in UK Firms

Every UK mid-market firm has interfaces that never appear on an architecture diagram. They are the exports that leave the finance system on a Friday afternoon, the customer list that arrives by email before a sales meeting, the stock report that appears in a chat channel each Monday. The organisation may call them ad hoc extracts, manual workarounds or simply 'the spreadsheet'. In practice they are unlisted interfaces, and they carry real business decisions.

Security and data loss prevention teams often see these files first, and rightly so. But an export is not only a leakage risk. It is a signal. A repeated export usually means someone has a reporting need that the official estate does not meet, or meets too slowly. An export with a hidden owner is often an undeclared data product. A one-week review can turn a vague concern about shadow data into a practical register of demand, risk and ownership.

Monday: Draw the boundary and collect the evidence

Start with a defined scope. Pick the core systems that matter to the business: finance, CRM, ERP, HR, service management. Include the common export routes: email attachments, collaboration platforms, shared drives and any self-service reporting tool that permits download. The aim is not to inspect content. It is to build a metadata picture.

Ask IT and security for the logs they already hold. Email gateway records can show attachment names, sizes and recipients. Collaboration platforms can show file uploads and sharing events. Shared drives can show recent file creation in known export folders. Business intelligence tools often log scheduled and ad hoc downloads. Where logs are incomplete, use a short request to service desk and departmental leads rather than a forensic exercise.

Create a simple register with columns for date, requester, source system, fields requested, approximate row count, frequency, destination, stated purpose and whether the export appears in the reporting catalogue. Keep the register to metadata. Under UK GDPR, avoid opening files that may contain personal data unless there is a clear lawful basis and a defined need.

Tuesday: Follow the request trail

Most exports begin as a request. Someone asks for a list, a file or a 'quick extract'. Those requests often sit in service desk tickets, team inboxes or chat messages. Search for common phrases: 'can you send me', 'export', 'list of customers', 'monthly numbers'. Do not aim for completeness on day one. Aim for patterns.

Classify each request as recurring, one-off or unknown. Recurring requests are the most valuable because they point to a repeatable need. One-off requests may still matter, especially around board papers, regulatory returns or month-end. Unknown requests are those where the trail goes cold. Note them, but do not chase every one in the first week.

Compare the request list with the official reporting catalogue. The gap between the two is the interesting part. If a request is easy to satisfy from an existing dashboard, the issue may be discoverability or training. If it cannot be satisfied at all, the export is standing in for a product that has not been commissioned.

Wednesday: Find the repeat exports and their hidden owners

Repeat exports are the heart of the review. A file that leaves the same system, with the same fields, to the same team every week is not really ad hoc. It is an informal feed. The person who requests it may not be the person who maintains it. The hidden owner is often the analyst who built the spreadsheet, the manager who checks it before circulation, or the administrator who knows which formula breaks at month-end.

Interview a small number of these owners. Ask three questions: what decision does this file support, what would happen if it stopped tomorrow, and what is missing from the official report? The answers will tell you whether the export is a genuine operational need, a habit, or a workaround for a known data quality problem.

Record the hidden owner in the register. This is not about assigning blame. It is about making the informal arrangement visible so that it can be supported, replaced or retired.

Thursday: Triage into three routes

Not every export needs to become a governed feed. Use four criteria: frequency, sensitivity, decision criticality and maintenance cost. A weekly export containing customer personal data that feeds a pricing decision is a strong candidate for a governed feed. A monthly extract that duplicates an existing report and sits unopened is a candidate for retirement. A file that contains excessive fields, or leaves the organisation without a clear purpose, may need to be blocked.

The three routes are governed feed, block and retire. For governed feeds, define the contract: fields, refresh schedule, access controls, data quality checks and an owner. For blocked exports, offer an alternative before removing the route, otherwise people will find another one. For retired exports, confirm that no live process depends on the file, then decommission it openly.

Some needs can be met with a lighter intervention. A saved view, a scheduled report or a read-only dashboard may be enough. The review should not assume that every signal requires a new data product.

Friday: Publish the register and keep it alive

End the week with a register that lists each export, its route, its owner, its review date and the action agreed. Share it with data governance, IT, security and the business leads who sponsored the review. Keep the language factual. The register is a management tool, not an audit finding.

Then make the review repeatable. Add an export request category to the service desk. Review repeat exports quarterly. Link the register to the data catalogue so that governed feeds become visible and informal ones do not quietly return. The point is not to eliminate every spreadsheet. It is to know which ones matter, who depends on them and what unmet need they represent.

Shadow exports are often described as a culture problem. More often they are a product problem. The organisation has not yet built the report, feed or view that the work requires. A five-day review will not solve that on its own, but it will produce a reliable list of where to start.