Developing an IT Support Plan for Business Resilience
Most small and mid-sized businesses don't have an IT plan. They have a collection of decisions made under pressure, a server bought in a hurry, software chosen by whoever needed it first, a phone system inherited from the previous office.
That works until it doesn't. An IT support plan is simply the document that turns those accidents into deliberate choices, and it doesn't need to be long.
Step one: write down what the business actually depends on
List your critical systems and, for each, answer two questions:
- How long can we be without it? (Recovery time objective.)
- How much data can we afford to lose? (Recovery point objective.)
Answering honestly is uncomfortable and useful. A practice management system might tolerate two hours; your email probably can't tolerate a morning. Everything else in the plan flows from these numbers, because they tell you where to spend.
Our technology risk assessment does this formally, but a whiteboard session with the leadership team gets you most of the way.
Step two: map what you've got
An accurate inventory: servers, endpoints, network hardware, cloud tenancies, line-of-business applications, licences and renewal dates, and who supports each. Include the awkward items, the machine under a desk running one critical thing, the app someone bought on a card.
Note the age and support status of everything. Anything unsupported is both a security risk and an insurance question.
Step three: decide your support model
Three broad options, each valid:
- Internal. Fast and contextual, but single-person dependency and limited specialist breadth.
- Outsourced. Coverage, breadth and included tooling, with scope boundaries to manage.
- Co-managed. Internal person for business-specific work, provider for infrastructure, security and cover.
Whichever you choose, define the hours, the priority levels and what falls outside. Ours is a Monday-to-Friday helpdesk, 8:30am to 5:30pm, with an out-of-hours retainer available separately for businesses that need it.
Step four: define the preventative routine
This is the part that determines whether the plan actually improves anything. Write down what happens on a schedule and who does it:
- Weekly: patch deployment, backup job review, alert triage.
- Monthly: security patch compliance report, licence review, new starters and leavers reconciled.
- Quarterly: test restore, access review, firmware updates on firewalls and switches.
- Annually: risk assessment refresh, disaster recovery rehearsal, hardware replacement planning.
Proactive maintenance and network monitoring are what make this run without needing to be chased.
Step five: build in the security baseline
Resilience and security are the same conversation. The baseline every plan should include:
- MFA on all accounts, conditional access configured.
- Endpoint protection on every device, with encryption enabled.
- A current, correctly configured firewall.
- Email authentication, SPF, DKIM, DMARC.
- Documented joiners, movers and leavers process.
- Regular staff awareness training on invoice fraud and phishing.
If you want that validated externally, Cyber Essentials is the sensible framework, and cyber security consultancy covers the deeper assessment.
Step six: the recovery plan
Backups first: three copies, two media, one off-site, one immutable. Then the thing most businesses skip, a written recovery runbook. What gets restored first, in what order, by whom, and how long each step takes.
Test it. A restore that has never been performed is an assumption. See backup and disaster recovery, our data recovery guide, and business continuity planning for the wider version covering premises and people.
Keep a printed copy. Plans stored only in the system you're trying to recover are a common and avoidable mistake.
Step seven: plan the road ahead, not just today
A support plan should have a horizon. Two or three years of known changes:
- Hardware replacement cycles, budgeted rather than discovered.
- Windows and server end-of-support dates.
- The PSTN switch-off if you still run analogue lines, alarms or lift lines.
- Whether remaining on-premise servers should move to Azure or wider cloud at their next refresh.
- Headcount growth and what it implies for licensing, connectivity and WiFi.
Our IT strategy and roadmap work exists to make this a costed plan rather than a wish list.
Step eight: agree how you'll know it's working
Pick a handful of measures and review them quarterly: ticket volume and trend, first-response and resolution times against priority, patch compliance percentage, successful restore tests, and repeat issues by root cause.
That last one matters most. If the same problem keeps recurring, the plan isn't working regardless of how good the response times look.
Keep it to a few pages
A plan nobody reads is worthless. Aim for something a new finance director could read in fifteen minutes and understand what happens when things break.
We help businesses across Birmingham, Solihull and the West Midlands put these together, including for companies we don't support. If you'd like a hand, book a call or get in touch.