What "IT support" actually means (and what it shouldn't)

25 August 2026

Ask ten people what "IT support" covers and you'll get ten different answers. For some it means someone picks up the phone when a laptop won't start. For others it's the invisible layer underneath everything, quietly making sure systems are backed up, patched, monitored, and defensible if a regulator ever asks how they're protected. Both answers are technically right. That's exactly the problem.

For most businesses, that ambiguity is a minor irritation. Contracts get renegotiated, expectations get reset, everyone moves on. For a hedge fund, family office or insurer, the same ambiguity is a genuine risk, because IT support sits underneath almost everything you'll eventually be asked to account for: operational resilience, third party oversight, incident response, due diligence.

We think it's worth being specific about what "IT support" should actually include, because the gap between what firms assume they're getting and what they're actually getting is usually invisible until something goes wrong.

What most people picture

Ask most people to describe IT support and they'll describe the helpdesk: someone answers the phone or the ticket, fixes the immediate problem, and moves on to the next one. Response time gets quoted in the contract. That's the visible part, and it's the part most providers compete on.

It's also, on its own, closer to a symptom-management service than IT support.

What good IT support actually includes

The helpdesk is real and it matters, nobody wants a provider who's slow to answer. But a proper support arrangement includes a set of things that never generate a ticket, because their whole purpose is making sure nothing does:

Proactive monitoring, so a failing disk or an odd login pattern gets picked up before it becomes an outage or a breach, not after.

A real patching cadence, applied consistently, not "we do updates sometimes."

Backups that are actually tested, not just running. A backup that's never been restored is a hope, not a safeguard.

Documented, tested incident response, so if something does go wrong, there's a known process rather than everyone improvising at 2am.

Reporting that's actually useful to the people who need it. A ticket-volume dashboard tells you how busy the helpdesk was. It doesn't tell a board, an investor or a regulator whether your systems are actually resilient.

None of this shows up when you ask "how fast do you answer the phone." All of it shows up when something goes wrong, or when someone starts asking harder questions about how your IT is actually run.

The single point of failure most firms don't think about

There's a quieter risk worth naming too: tribal knowledge. A support setup that runs fine because one engineer happens to remember how everything's configured isn't a resilient setup, it's a lucky one. Proper IT support means the knowledge lives in documentation, not in one person's head, so a holiday, a sick day or a resignation doesn't become an operational risk of its own.

It's not just about outages

Good IT support also isn't purely reactive. It includes regular reviews of what's actually needed, not just what's currently running: is the setup still right for the size of the business, is anything being paid for and not used, is there a sensible plan for the next twelve months rather than a scramble every time something breaks. A provider who only shows up when something's wrong is running a fire brigade, not a support service.

Why this shows up in due diligence too

It's not only regulators asking these questions. Investors carrying out due diligence, insurers pricing cyber cover and auditors reviewing operational resilience are all increasingly specific about IT arrangements, not just "do you have an IT provider" but "can you show us how it's actually run." A provider who can produce a tested incident response plan and a real patching record turns that conversation into a five-minute box tick. A provider who can only offer a service level agreement and a smile turns it into weeks of follow-up questions.

That difference compounds. The firms that handle due diligence quickly and confidently aren't the ones with the fanciest IT, they're the ones who can actually answer the specific questions being asked, because their provider was set up to produce those answers before anyone asked for them.

Why this matters more than it used to for regulated firms

Two things have shifted the ground under this conversation in the past few months, and both make the gap between "someone answers the phone" and "IT support" harder to ignore.

From 13 July 2026, HM Treasury designated four global cloud providers, Amazon Web Services, Google Cloud, Microsoft and Oracle, as Critical Third Parties to the UK financial system. The Bank of England, the PRA and the FCA now oversee those providers directly, because a serious outage at any one of them could ripple across a large share of the sector at once.

That sounds like good news, and in one sense it is. But designation is not the same as authorisation, and it doesn't transfer your firm's own responsibility for third party risk anywhere. Your regulator will still expect you personally, not your cloud provider, to be able to answer for how your IT is managed and what happens if it fails.

Separately, the FCA's PS26/2 policy statement, published in March 2026 with rules coming into force in March 2027, will require firms to report significant operational incidents and to maintain and submit an annual register of material third party arrangements. That's a new, formal expectation that your IT support setup needs to be able to produce clean answers to two questions on demand: what happened, and who do we rely on.

Neither of these changes is about your provider's cloud platform. Both are about whether your own IT support arrangement, whoever runs it, is actually built to produce the answers you'll be asked for.

What to actually ask your provider

If you outsource your IT, whether to us or to someone else, these are worth asking directly rather than assuming:

• What's our patching schedule, in writing, not "regularly"?
• When was our last backup actually restored, not just backed up?
• What does your incident response process look like, and has it been tested in the last twelve months?
• Can you produce a written incident report we could put in front of a board or a regulator, not a support ticket summary?
• Do you maintain a record of the third party services we rely on, and could you produce it if asked?

A provider who answers these plainly and specifically is telling you something useful about how they operate. A provider who reaches for a brochure is telling you something too.

Where we land

We built Maple's own support model around the assumption that "someone answers the phone" was always the minimum, not the whole job. Monitoring, patching, tested backups, documented incident response and proper reporting aren't add-ons we sell separately, they're what we think "IT support" is supposed to mean in the first place.

If you're not sure whether your current setup covers all of this, that's a genuinely useful conversation to have now, while it's a planning exercise rather than a gap someone finds during an incident, an audit, or a due diligence review.