When the IT Desk Is a Duo: A Resilience Playbook for Leave and Sick Cover
Photo: Tofs2025, CC0, via Wikimedia Commons
An IT team of two is not unusual in a UK SME. It can be effective, close to the business and quick to respond. It is also exposed. When one person takes annual leave, attends a funeral or is off sick, the remaining colleague may inherit every system, supplier relationship and half-finished project. The risk is not that staff take leave; it is that the organisation has no agreed way to cover it.
A leave-and-sick-cover playbook is a short, controlled document. It does not replace good documentation or a managed service contract. It sets out who does what when the usual person is unavailable, where the critical information sits and how the firm will escalate when something goes wrong. The aim is calm continuity, not a bureaucratic binder.
Begin with the services that matter
Start by listing the technology services that keep the business trading. For most SMEs this includes identity and email, the finance or practice-management system, any line-of-business application, the local network and Wi-Fi, internet lines, telephony, backup and security alerting. Add the suppliers behind each service.
For each item, record the service owner, a nominated deputy, the business impact of an outage and the route to support. Use a simple criticality scale: high if an outage stops revenue, statutory reporting or customer safety; medium if it causes significant delay; low if work can continue for a day. This prevents the playbook from treating a printer queue with the same urgency as the finance system.
Write a minimum viable runbook
The runbook should be practical rather than exhaustive. One page per high-criticality system is usually enough. It should explain what the system does, who relies on it, how to check whether it is healthy, the first three diagnostic steps, the supplier escalation route and any known quirks. Record where credentials are held, but never place passwords or recovery codes in the document itself. Use the firm's password manager with a break-glass process that is approved and audited.
For UK firms, keep data protection in mind. A cover document may contain personal data about staff or customers, so store it where access is role-based and reviewed. Do not email copies around as attachments. Link to the current version in a controlled location.
Name deputies and decision rights
A deputy is not simply the other IT person. It may be an operations manager, a finance lead or a trusted managed service provider. What matters is that the deputy has been briefed, can access the runbook and knows when to stop and escalate.
Define decision rights in advance. Who can approve a supplier callout? Who can authorise emergency spend up to a stated limit? Who can request a password reset for a senior manager? Who contacts the insurer, legal adviser or data protection officer if a security incident occurs? A short RACI-style table is enough: primary, deputy, escalation and informed.
Build a supplier escalation matrix
Most incidents are resolved through suppliers, so the playbook must contain a current contact matrix. List each supplier, the service it provides, the account number, the support portal, the telephone number, the escalation contact, the service level and the support hours. Include out-of-hours routes for internet, telephony and any SaaS platform that handles payments or payroll. Test the numbers before you need them. A matrix that relies on one person's inbox is not a matrix.
Test during a low-risk absence
A plan that has never been used is a hypothesis. Choose a low-risk period, such as a quiet half-day or a normal day outside payroll and month-end, and ask the deputy to cover the primary's leave. The deputy should run the morning checks, raise a test ticket with a supplier if appropriate and record every point of confusion. Afterwards, hold a short debrief and update the playbook.
The test does not need to be dramatic. Its purpose is to prove that the deputy can find the runbook, reach the right supplier and make a routine decision without ringing the absent colleague. If the primary must be contacted, that is a finding, not a failure.
One-afternoon checklist
- List all technology services and suppliers.
- Mark each service high, medium or low criticality.
- Confirm the owner and a named deputy for every high-criticality service.
- Write a one-page runbook for each high-criticality system.
- Store credentials in the approved password manager and document the break-glass route.
- Record decision rights for spend, resets, supplier callout and incident escalation.
- Build and test the supplier escalation matrix.
- Schedule a low-risk absence test and a post-test review.
- Set a review date, at least every six months or after any major change.
Simple cover card template
| Field | Entry |
|---|---|
| Primary IT contact | Name, role, phone |
| Deputy for this absence | Name, role, phone |
| Second escalation | Name, role, phone |
| High-criticality systems | List with runbook links |
| Key supplier hotlines | Internet, telephony, SaaS, hardware |
| Emergency spend authority | Name and limit |
| Security incident route | Contact and reporting channel |
| Review date | Date and owner |
The playbook should be reviewed when staff change, when a major system moves, or when a supplier contract is renewed. It should also be part of onboarding for any new IT recruit. A two-person team can remain lean, but it should not be fragile. A short playbook, tested once, is a modest investment that protects the business when ordinary life intervenes.
