Mapping the Invisible Wiring: Why Every UK SME Needs an Integration Audit

Ask a leadership team at a typical UK SME how many software systems the business runs on and, within a minute, someone will produce a number. Ask which of those systems exchange data with each other, in which direction, how often, and what happens when the exchange fails, and the room usually falls quiet.

That silence is expensive. The subscription list is a procurement question. The dependency map is an operational one, and it is the map that determines whether a Tuesday morning invoice run completes, whether a customer record is accurate, and whether anyone can answer a data subject access request inside the statutory month.

An integration audit is the exercise of drawing that map deliberately, before an outage or an ICO enquiry draws it for you.

An app inventory is not an architecture diagram

Most businesses hold two very different documents in their heads and treat them as one. The first is a list of tools: the accounts package, the CRM, the e-commerce platform, the payroll service, the helpdesk, the warehouse system. The second is a description of how information moves between them.

The first is easy to produce because it appears on a bank statement. The second is hard because it accreted quietly, usually in response to a specific frustration, and frequently without anyone recording the decision. A finance manager connects a payment provider to the ledger. A operations lead sets up a scheduled export to a spreadsheet because the reporting module will not do what the board wants. An agency, during a website build two years ago, adds a webhook that has worked silently ever since.

None of these choices was unreasonable. Collectively, they form a structure that nobody owns and nobody can describe.

Start with the data, not the tools

A tool-led audit produces a list. A data-led audit produces an understanding. The practical method is to choose four or five core entities the business genuinely depends on, and trace each one through every system it touches.

For most organisations the shortlist looks something like this:

• The customer record, including contact details and consent status
• The order or engagement, from enquiry to fulfilment or delivery
• The invoice and payment
• The employee record, including payroll and access rights
• The product, price or service catalogue

The second step is a worksheet, dull but decisive. For every flow, capture the source system, the destination system, the transport method (API, webhook, scheduled export, manual re-keying), the frequency, the fields transferred, the named owner, and what the receiving system does if the payload is missing or malformed.

That last column is where the interesting answers live. A surprising number of integrations have no failure path at all: the job either runs or it does not, and nobody is alerted either way.

The quiet dependencies that carry real weight

Integration audits consistently surface the same cast of characters. There is the nightly CSV that lands in a shared drive at 02:00 and is picked up by a scheduled task. There is the spreadsheet macro maintained by one person in finance. There is the low-cost automation tool connecting two systems, configured by a former employee, billed to a company card nobody has reconciled. There is the folder that holds the only copy of a document set because the system of record never quite took.

Individually these look like housekeeping. In aggregate they are the load-bearing walls of the business, and they are usually undocumented, untested and unmonitored.

Three kinds of single point of failure

Once the map exists, the risk review becomes almost mechanical. Failures tend to fall into three categories.

Technical. A single API credential shared across several jobs, with no rotation policy and no owner. An unmonitored scheduled task. An integration that depends on a middleware service with no fallback. These fail loudly when they fail, but they fail silently far more often, producing partial data that nobody notices for weeks.

Contractual. A connector that depends on a licence tier which is due for renewal or downgrade. A vendor whose product roadmap no longer includes the endpoint you rely on. An acquisition that puts a critical supplier in the hands of a competitor. Integration risk is frequently commercial risk wearing a technical costume.

Human. The person who knows why the export runs at 02:00 rather than 23:00, and what to do when it does not. When they hand in their notice, the integration does not break immediately, but its supportability does.

The data-protection dimension

For UK organisations, an integration audit is also, unavoidably, a data-protection exercise. Every flow that carries personal data is a processing activity, and each one needs a lawful basis, a documented purpose, a retention position and a contract that satisfies UK GDPR requirements.

In practice, the audit should capture, for each integration: whether a data processing agreement is in place and current; whether the supplier publishes a sub-processor list and whether that list has been reviewed; whether any data leaves the UK or the EEA and on what transfer mechanism; and what happens to the data at the end of the contract.

The uncomfortable finding is common. A marketing tool receiving customer records under a click-through terms of service, with no negotiated processing terms, is an exposure that will not appear on any risk register unless someone looks for it.

There is a useful side effect here. A completed integration map is most of the way to a record of processing activities, and it makes subject access requests far quicker to service, because the team knows where the data lives rather than guessing.

Document, replace or retire

Every integration on the map should leave the audit with a verdict and an owner. Four verdicts are usually sufficient.

Keep and document covers flows that are sound but undocumented. The action is a short written record: purpose, owner, failure behaviour and support contact.

Consolidate covers flows that duplicate a capability the business already pays for. Two systems syncing contacts in opposite directions is rarely a design decision; it is usually history.

Replace applies where the current route is fragile or unsupported. Replacing a manual export with a supported API connection is often cheaper than the incident it prevents.

Retire is the most neglected option and frequently the most valuable. A meaningful proportion of integrations exist to serve a report or process that no longer matters.

Make it a rhythm, not a project

An audit conducted once becomes stale within a year. The practical approach for a small team is a light cadence: a full review every twelve to eighteen months, plus a targeted review triggered by any of four events, namely a leaver, a contract renewal above a defined threshold, a significant system change, and any incident affecting data integrity.

Store the map where people will actually find it, not in one person's notes. A single shared document with a named owner, reviewed at the same meeting where you discuss business continuity, is sufficient. The objective is not a beautiful diagram. It is the ability to answer, without hesitation, the question of what holds the business together and what happens when a piece of it stops.