What should a managed IT SLA actually guarantee?

A real SLA states response time (how fast someone acknowledges an issue) separately from resolution time (how fast it's fixed), by severity level, with a stated consequence if the provider misses it. If the document only promises to "respond promptly," that's not an SLA. It's a sentence.

Who owns my backups if I switch providers?

You should. Ask in writing whether backup data is stored in an account you control and whether you get an export on exit. If the answer is "we'll work something out," treat that as a red flag before you sign, not after you leave.

Is per-seat pricing better than a flat retainer?

Neither is inherently better: the risk is in what counts as a "seat" and what gets billed as an add-on. Get the exact definition and a list of what triggers an extra charge before comparing two providers' per-seat quotes.

What counts as an emergency under a managed IT contract?

Ask the provider to define it in the contract, not describe it in the sales call. "Emergency" should list specific triggers (server down, ransomware, network outage) with a stated after-hours response path, or you'll find out the real definition during your first outage.

Blog July 10, 2026 4 min read

What to Ask Before You Sign a Managed IT Contract

By Gabriel Lopez-Seco

The short answer

Five questions separate a real managed IT provider from a rebadged break-fix shop wearing a monthly-retainer label: what exactly gets monitored, what the SLA actually commits them to, who owns your backups, what happens if something breaks at 2am, and how the pricing model can quietly grow. Ask them before you sign, because a contract is much easier to negotiate before your data is already on their platform.

What does “monitored” actually cover?

“We monitor your systems” is marketing copy until you get specifics. Ask which devices are covered: every server and workstation, or just the servers? Ask what’s actually being watched: disk health, backup job success, failed login attempts, memory and CPU thresholds, or just whether the machine responds to a ping. Ask how often alerts are checked and by whom, not just whether an alert fires.

A provider that can name the specific signals they track (a backup job that silently failed, a disk showing early SMART errors, a server that’s been swapping memory for three days) is doing the proactive work managed IT is supposed to sell. A provider that answers with “everything” hasn’t told you anything.

What does the SLA actually commit them to?

A service-level agreement is a contract term, not a marketing claim, and the two numbers that matter are response time and resolution time. Response time is how fast someone acknowledges the issue exists. Resolution time is how fast it’s actually fixed. They are not the same thing, and a vague SLA blurs them on purpose.

Ask for both numbers, broken out by severity (a down server should have a tighter commitment than a printer driver issue), and ask what happens if the provider misses the SLA. A contract with no consequence for a missed commitment isn’t really a commitment; it’s a hope.

Who owns the backups?

Backups fail silently more often than people expect, which is exactly why “we back up your data” isn’t the question. Ask whether restores are actually tested on a schedule, not just whether the backup job runs. A backup nobody has restored from is a hypothesis, not a safety net.

Then ask who owns the data. If you leave the provider, do you get your backups in a portable format, or are they locked inside a platform you no longer have access to? Get this in writing before you sign, not when you’re trying to switch providers under pressure.

What happens at 2am?

Outages don’t wait for business hours. Ask directly: if a server goes down at 2am, who gets paged, how fast, and what’s the actual response: a live person working the issue, or a ticket that gets picked up at 9am? “24/7 monitoring” can mean an automated system that emails a ticket queue overnight with no one reading it until morning.

Ask for the after-hours escalation path in writing: who’s on call, what triggers a page versus a next-business-day ticket, and whether emergency response costs extra. A provider that’s vague here is telling you what your first real outage will look like.

How does per-seat pricing go wrong?

Per-seat and flat-retainer pricing are both normal; the problem is in what counts as a “seat” and what quietly becomes a billable add-on. Get the exact seat definition: does a shared conference-room PC count as one seat, or does everyone who logs into it count separately? Ask for the full list of what’s included versus billed separately: after-hours emergency work, new-employee onboarding, hardware procurement, security incident response.

A quote that looks cheaper per seat can end up more expensive once the add-on list runs long. Compare providers on total expected monthly cost for your actual environment, not the headline per-seat number.

A short checklist before you sign

Get the monitored-systems list in writing, not a verbal “everything.”
Get response time and resolution time as separate numbers, by severity.
Confirm backups are tested on a schedule and that you own the data on exit.
Get the after-hours escalation path and what triggers extra charges.
Get the full seat definition and the add-on list before comparing price.

Vetting a provider this way takes an extra conversation, but it’s a much shorter conversation than the one you’ll have during an outage with a contract that doesn’t answer these questions. iServU’s managed IT services in Tampa Bay are built around one accountable senior operator with a documented infrastructure track record, not a rotating helpdesk. It’s the kind of provider these questions are designed to find.

Not sure how your current setup stacks up against this checklist? Get a free IT assessment and find out before your next contract renewal.