When the only IT manager is off sick: building a succession plan the board will actually minute
Photo: Loominade, CC0, via Wikimedia Commons
Consider a professional services firm of four hundred people in the Midlands. It has one IT manager, fourteen years in post, who holds the firewall rule set in his head, owns the Microsoft tenant as global administrator, knows which of the two backup jobs actually completes, and is on first-name terms with every supplier account manager the firm pays. In February he is admitted to hospital on a Tuesday morning. By Thursday the firm has discovered that the person who renews the domain registration is the person who is not answering his phone.
This is not an unusual story. It is the default state of technology continuity across a great deal of the UK mid-market, and it survives because nothing has yet tested it. The instinct when the risk is raised is to commission a documentation exercise. That instinct is the problem. A lever-arch file describing a system nobody can operate is not continuity; it is reassurance with a spine. What follows is an argument for treating solo IT as a succession question, with named owners, a rehearsal, and a decision recorded in the minutes.
The dependency is rarely where the organogram puts it
Boards tend to assume the exposure sits with the person. It sits with the intersections: the individual who is simultaneously the administrator, the contract holder, the approver and the only person who knows why a particular workaround exists. Mapping headcount tells you nothing about that. Mapping what stops, and when, tells you everything.
A useful key-person review examines three horizons. What fails within four hours — authentication, email, the line-of-business application that finance cannot open. What degrades within four days — patching, ticket queues, the joiner-mover-leaver process that payroll depends on. What quietly rots within four weeks — certificate renewals, licence true-ups, backup verification, the access review that no one has run since the incumbent's last holiday. Each item on that list should carry the name of a second person who has demonstrably performed it. Not attended a briefing on it. Performed it.
Turning the audit into evidence rather than adjectives
The difference between a risk register entry reading "key-person dependency: high" and a finding that survives scrutiny is a test. Choose eight or ten routine but consequential tasks — restoring a mailbox, raising a support ticket against the finance system, approving a software renewal, adding a starter to the directory — and ask a nominated colleague to complete each one using only the written material available. Where they succeed, the material is validated. Where they stall, the dependency has been located precisely, and the gap can be closed with a short procedure and a second run at the task.
Record the date, the person tested, and the outcome. A dependency map with test results attached is a document a finance director, an insurer or an acquiring party can interrogate. A dependency map without them is an opinion.
Custody: credentials, contracts and the supplier address book
Two failures recur with such regularity that they deserve naming. The first is ownership of the tenancy. Domain registrations, cloud billing accounts, certificate authorities and software licences registered to an individual's work address, or worse a personal one, create a transfer problem that surfaces at the worst possible moment. The test is simple: if that person were unreachable tomorrow, could the company prove it owns its own estate? Everything should sit under a role-based account controlled by the organisation, with a documented break-glass route held by two named officers under seal, rotated whenever a holder changes, and logged.
The supplier side is a relationship, not a spreadsheet
The second failure is institutional memory held in a single head. A supplier register that lists company name, contract reference and renewal date is a start, but the operational knowledge — who answers when the escalation line is engaged, which account manager can approve an emergency uplift, which maintenance window has been informally agreed — usually lives nowhere. Capture it, and attach each entry to a second named contact within the firm who has spoken to that supplier at least once in the past twelve months.
The handover pack, and who owns it
The pack itself should be short enough to be read in an afternoon and structured so that it can be updated in an hour each quarter. An architecture one-pager. A supplier register with escalation routes. A custody map showing who holds which credentials and who holds the seal. Restore procedures annotated with the date of their last successful test. A calendar of recurring obligations — patch cycle, access review, backup verification, statutory renewals. A decision log explaining the significant choices and their reasons, which is the part most often omitted and most often needed.
Crucially, the pack needs an executive sponsor at director level, not because they will maintain it, but because ownership without seniority does not survive a busy quarter. Version control and a storage location reachable by at least two people complete the minimum.
The decision the board should be minuting
Continuity for a sole IT function resolves into a small number of options, and every one of them has a cost and a lead time. A retained managed service provider can supply interim cover, but only if the retainer is in place before it is needed; assembling one during a crisis adds weeks. Internal cross-training of a capable operations or finance colleague buys days, not months. A fully outsourced service desk with a named escalation tier changes the shape of the role rather than removing it.
The board's job is to choose, and to minute the choice alongside its trigger, its budget and the officer accountable for activating it. An unminuted preference is not a contingency. It is a conversation someone remembers having.
Rehearse it, then put the result in the board pack
An annual exercise is sufficient and need not be elaborate. A colleague performs a restore from the documented procedure. A renewal is actioned by someone other than the incumbent. An invoice query is resolved using only the pack. The outcomes are recorded as evidence, in the same way that a business continuity test under ISO 22301 would be, and reported to the audit committee or equivalent with the date and the exceptions named.
That is the whole proposition. Not a document filed against a risk, but a named second person for each critical task, a custody arrangement the company can prove, a decision in the minutes, and a test result with a date on it. The phone will still go unanswered one day. The question is only whether the firm spends that week recovering or discovering.