Reading Between the Uptime: A Board Routine for Testing Supplier SLA Evidence

Most UK organisations do not lack service level agreement data. They lack a habit of testing it. The monthly report arrives on time, carries a familiar logo and presents a reassuring set of percentages. Directors see green, the supplier relationship manager files it, and the board pack moves on. Yet a service report is a claim before it is evidence. The useful question is not whether the supplier has produced a dashboard, but whether the underlying incidents, timestamps and credit calculations support what the dashboard says.

A dashboard is a claim before it is evidence

Service level agreements are contractual instruments, not management summaries. They define how performance is measured, what counts as an incident, when the clock starts and stops, which events are excluded, and what remedy follows a miss. A polished report can be entirely consistent with the contract and still obscure the operational reality. Assurance therefore requires a modest, repeatable audit trail: a sample of incidents, the raw records behind them, and a short note explaining what was tested and what was found.

This is not a invitation to re-run the supplier’s service desk. It is a way for the customer organisation to satisfy itself that the reported position is credible. For many mid-market UK firms and public sector bodies, a quarterly sample of ten to fifteen incidents is enough to expose whether the reporting regime is sound—or whether the green dashboard is doing more work than the evidence beneath it.

Start with the incident population, not the percentage

Ask the supplier for the full incident population for the period, not just the summary table. The extract should include ticket references, priority, detection time, response time, restoration time, resolution time, status and any exclusion applied. Where the supplier reports against several service levels, ask for the population relevant to each one.

Then select a stratified sample. Include at least one major incident, several routine incidents, any incident that came close to breaching its target, any repeat failure, and any incident that the supplier excluded from measurement. If the report shows a perfect month, sample more rather than less. Perfection is not suspicious in itself, but it should be easier to test than a mixed month because the population is smaller.

Record why each incident was chosen. A board or audit committee does not need the full ticket history, but it does need to know that the sample was deliberate rather than convenient. The sampling rationale is part of the assurance evidence.

Timestamps are where stories slip

Most SLA disputes turn on time. When was the incident detected? When did the supplier acknowledge it? When did work begin? When was service restored? When was the ticket closed? These are different moments, and contracts often treat them differently.

Check the clock-start rule. Some agreements start the clock at ticket creation; others start at alert generation, user report or supplier acknowledgement. If the supplier’s monitoring detected an issue at 02:14 but the ticket was created at 08:30, the reported response time may be contractually correct and operationally misleading. That distinction belongs in the assurance note.

Look for pause states. Tickets can be placed on hold pending customer information, third-party action or change approval. Each pause should be documented and consistent with the contract. A pattern of long pauses immediately before a breach is a finding, even if each individual pause has a plausible explanation. Check time zones and daylight saving changes where services span the UK and overseas. Check whether ‘resolved’ and ‘closed’ are being used interchangeably when the contract defines them separately.

Exclusions deserve a paper trail

Every SLA contains exclusions: planned maintenance, customer-side faults, third-party dependencies, force majeure and agreed changes. The existence of an exclusion is not the issue. The issue is whether it was applied correctly and consistently.

For each excluded incident in the sample, ask for the evidence: the change record, the third-party incident reference, the customer communication or the formal agreement that the event fell outside the service level. If exclusions are being applied retrospectively, or if the same category is used repeatedly without corroboration, the measurement regime is weaker than the report suggests. Keep an exclusion register and review it quarterly. A rising exclusion rate is an early warning about service design, dependency management or contract fit, not merely an administrative nuisance.

Service credits: test the arithmetic and the cause

Service credits are often treated as the point of the SLA. In practice they are a narrow remedy, frequently capped and rarely equal to the business disruption caused. That makes them worth checking, but not worth over-reading.

Recalculate any credits from the raw incident data rather than accepting the supplier’s figure. Confirm that the credit was actually applied to an invoice or account, not merely proposed. Where no credit was triggered despite apparent misses, test the severity mapping and the exclusion logic. Where a credit was triggered, ask what caused the underlying failure and whether the same cause has appeared before. A credit that recurs for the same reason is a sign that the remedy is working as a price signal but not as an improvement mechanism.

The board note should distinguish between contractual performance and operational performance. A supplier can meet its service levels while the business still experiences unacceptable disruption. Both statements can be true, and directors need to see them side by side.

A one-page assurance note for the board

Turn the sampling work into a short note with five sections: scope and sample; what was tested; findings and exceptions; contractual position; and actions. State clearly whether the review provides limited assurance, no assurance or identifies material exceptions. Avoid audit jargon where plain English will do.

Separate what the supplier reported from what the customer observed. Include a small table of sampled incidents with the reported outcome and the tested outcome. Note any exclusions that could not be substantiated, any timestamp discrepancies and any credits that were due but not applied. End with named actions and dates, not general commitments to ‘work with the supplier’. The note should be capable of being minuted without further editing.

Make the test a routine, not a rescue

A quarterly sample is usually sufficient if it is consistent. Rotate across services and suppliers, retain the extracts and working papers, and let the contract manager own the routine with oversight from finance or internal audit. Use the findings before renewal negotiations, not after. If a supplier is slow to provide raw records, that resistance is itself a finding worth recording.

The aim is not to catch the supplier out. It is to give directors a defensible basis for saying that the service report has been tested, that the contractual position is understood and that the organisation knows what it is relying on. In 2026, with IT estates more dependent on third parties than ever, that modest discipline is a better board comfort than another clean dashboard.