The work behind the workflow: auditing the manual controls UK IT services cannot survive

Most IT service reviews begin with the systems estate: the applications, the infrastructure, the support contract and the service credits. That is understandable, but it is rarely where the whole process lives. Ask how a payment run actually completes, how a nightly data transfer is checked, how a customer record is corrected or how an access request reaches the right inbox, and the answer often includes a spreadsheet, a manual handover and one person who knows the sequence.

These are not necessarily failures of governance. They are the practical glue that keeps services running when systems do not quite meet. The risk lies in the fact that they are frequently undocumented, unowned and invisible to the board until the day the file corrupts, the person leaves or the manual step is missed.

Start with the service, not the spreadsheet

An audit of manual controls should not begin with a hunt through shared drives. It should begin with the organisation’s critical services. Work with business owners to identify the processes whose interruption would cause material harm: payroll, supplier payments, customer onboarding, regulatory reporting, incident response or the fulfilment of a statutory obligation.

For each service, trace one complete cycle end to end. Follow the transaction or record through every system, inbox, shared folder and approval step. Ask the people doing the work what they actually do, not only what the procedure says. The gap between the two is usually where the hidden controls sit.

Useful evidence includes runbooks, calendars, recurring email folders, spreadsheet filenames, access lists, handover notes and the questions staff ask when the usual person is away. The aim is not to compile an inventory of every workbook in the organisation. It is to find the small number of manual controls on which critical services genuinely depend.

Four dependency types to record

A simple taxonomy helps keep the register usable. First, the single-file dependency: a workbook, template or macro-enabled file that performs a calculation, holds a mapping table or reconciles two systems. Second, the single-person dependency: knowledge, access or judgement held by one individual, often without a deputy. Third, the manual handover: rekeying data between systems, forwarding approvals by email or checking that an overnight job has completed. Fourth, the informal reconciliation: a monthly total, an exception list or a visual check that provides assurance but leaves little evidence.

Each type carries a different failure mode. A file can be corrupted, overwritten or left with an outdated formula. A person can be absent, resign or forget. A handover can be missed during peak periods. An informal reconciliation can continue for months without anyone noticing that it has stopped.

Test the control, not the document

For each control identified, establish what triggers it, who performs it, what happens if it is missed and where the evidence is kept. Then test it. Select a recent period and ask for the evidence that the control operated. If the answer is that the person remembers doing it, record that as an evidence gap rather than accepting it as assurance.

Rate the consequence of failure in plain terms: service interruption, financial misstatement, regulatory breach, security exposure or avoidable staff overtime. A simple high, medium or low rating is sufficient if the rationale is recorded. The register should not become a second risk register. Its purpose is to show where operational resilience depends on manual work and what the organisation intends to do about it.

Build a register the board can use

A board-level register should be short enough to read and specific enough to prompt decisions. For each material control, record the service it supports, the control description, the accountable owner, the deputy, the evidence location, the frequency, the failure impact, the last test date and the agreed action.

Keep the top section to the controls that matter most. A register of twelve to twenty entries is usually more useful than a comprehensive catalogue that no director will read. Include a clear decision for each: accept and document, assign a deputy, automate, retire or escalate for investment.

The board’s questions should be direct. Which critical controls have no named deputy? Which depend on a file that only one team can access? Which have not been tested in the past twelve months? Which are candidates for automation in the next budget cycle? Which would fail an audit if the evidence were requested tomorrow?

Assign ownership without creating a paper empire

Ownership should sit with the accountable manager for the service, not with the person who maintains the spreadsheet. The owner is responsible for ensuring the control is documented, tested and resourced. The deputy provides continuity. Both should be recorded in the service catalogue and reviewed when roles change.

Avoid over-formalising controls that are low risk. The objective is proportionate assurance, not bureaucracy. For controls that remain manual, set minimum standards: restricted access, version control, backup, input validation and a defined reconciliation check. For controls that are no longer necessary, retire them deliberately rather than allowing them to persist as organisational habit.

Use renewal points to reduce the dependency

Manual controls often survive because systems do not exchange data cleanly or because a supplier’s process stops at the boundary of its contract. When contracts are renewed, ask suppliers to expose data, provide audit trails or automate handovers that currently rely on internal effort. Include data extraction and exit requirements so that the organisation is not left reconstructing a manual process at short notice.

The spreadsheet behind the system is not the problem in itself. The problem is the dependency that nobody has named. A focused audit turns that hidden work into visible decisions, and gives the board a more honest account of how the organisation actually keeps its critical services running.