What a Real IT AMC SLA Should Include (and the Clauses That Hide the Gaps)

Most IT annual maintenance contracts in Dubai are sold on two numbers: a monthly price and a response time. Both are close to meaningless on their own.

Response time without a definition of what counts as a response tells you nothing. Monthly price without knowing what falls outside the scope tells you less. The contracts that cause problems are rarely the ones that are obviously bad — they are the ones that look reasonable until the day you need something the exclusions quietly removed.

Here is how to read one properly.

Response time is not resolution time

This is the most common misunderstanding, and vendors are not always motivated to correct it.

Response time is how long until someone acknowledges your ticket. In a poorly written contract, an automated email saying “we have received your request” satisfies a four-hour response SLA. Nothing has been fixed. Nothing has even been looked at.

Resolution time is how long until the problem is actually solved. Many AMC contracts do not commit to one at all.

A contract with a one-hour response time and no resolution commitment is weaker than one with a four-hour response and a defined resolution target. If the contract you are reviewing only quotes response times, that is the first question to ask.

What good looks like: severity-tiered targets for both, with resolution measured to service restoration.

A workable structure separates severity by business impact rather than by technical category:

• Severity 1 — business stopped. Server down, no internet, no access to core systems for everyone.
• Severity 2 — significant impairment. A department blocked, a critical application degraded.
• Severity 3 — individual user affected, workaround available.
• Severity 4 — requests, changes, questions.

Ask who assigns severity. If the vendor classifies unilaterally, expect your Severity 1 to arrive as their Severity 3. The contract should either define severity by objective criteria or give you the initial classification with a defined escalation route if you disagree.

The clauses that quietly limit coverage

Business hours definition

“8×5 support” needs a definition of which eight and which five. In the UAE this genuinely varies — some providers work Monday to Friday, some Monday to Saturday, and public holiday treatment differs.

Check specifically: – Which days constitute the working week – Start and end times – How UAE public holidays are treated – Whether Ramadan hours change the coverage window – What out-of-hours support costs, and whether it is even available

An AMC that is unavailable from Friday afternoon until Monday morning is a different product from one that covers weekends, whatever the headline hours suggest.

Ticket volume caps

Some contracts cap included tickets or support hours per month, with overage billed separately. This is not inherently unreasonable, but it needs to be visible.

Check: is there a cap? What is the overage rate? Does an unused allowance carry forward? Does a single incident requiring six hours count as one ticket or six hours?

The exclusions list

This is where the real scope lives, and it is usually the section people skim. Read it before the inclusions

Commonly excluded, sometimes reasonably and sometimes not: – Hardware replacement parts – Software licence costs – Anything the vendor classifies as “consultancy” or “project work” rather than support – Third-party vendor liaison – Equipment past a certain age – Equipment not supplied by the vendor – Issues caused by user error – Anything arising from unauthorised changes

That last pair deserves scrutiny. “User error” and “unauthorised change” are elastic categories. A contract that excludes both without definition gives the vendor a defensible reason to bill separately for a substantial share of real-world incidents, because a large share of real-world incidents do trace back to someone changing something.

Age and supportability limits

Many contracts exclude equipment beyond a certain age, or beyond manufacturer end-of-support. Fair enough in principle — nobody can guarantee resolution on hardware with no available parts.

But check what happens when your equipment crosses that line mid-term. Does coverage lapse silently? Are you notified? Does the price adjust? Discovering that half your estate fell out of scope eight months ago is not a conversation you want during an outage.

Response time exclusions

Look for clauses excluding response time obligations during specified conditions — vendor holidays, force majeure, situations dependent on third parties. Third-party dependency is the one worth attention: if your internet fails and the ISP is the actual fix, does the SLA clock pause? Reasonable answer is yes for the ISP’s portion, but the vendor should still own managing that relationship rather than handing you the ISP’s number.

What should be included that often is not

Preventive maintenance, not just reactive support

An AMC that only responds to failures is an insurance policy, not a maintenance contract. The value is in the failures that do not happen

Look for defined, scheduled activity: – Patch management with a stated cadence – Backup verification — and specifically restore testing, not just confirmation that backups ran – Disk and hardware health monitoring – Firmware currency across network and security devices – Log and capacity review – Antivirus and endpoint protection status verification

That backup point is worth dwelling on. A backup job reporting success proves a job ran. It does not prove the data is restorable. The gap between those two things is where organisations discover, at the worst possible moment, that their backups have been silently useless for months. A contract that includes periodic test restores is materially more valuable than one that only monitors backup completion.

Asset inventory maintenance

The vendor should maintain a current inventory of what they support — devices, specifications, warranty status, software, licence counts, end-of-life dates.

This has a benefit beyond the contract: it is the document that lets you plan capital replacement, and the document you need if you ever change providers. Ask whether you receive it, in what format, and how often.

Documented escalation path

Named roles, contact routes, and time thresholds. “Escalate to management” is not an escalation path. Who, how, and after how long.

Reporting

Monthly or quarterly reporting on ticket volume, resolution times against SLA, recurring issues, and outstanding risks. Without it you have no way to assess whether the SLA is being met, and no basis for the renewal conversation.

Recurring issues are the most useful item on that report. The same problem appearing monthly means something is not being fixed, only repeatedly patched.

Onboarding and documentation

The first thirty days matter. A vendor who takes over support without documenting the environment is guessing during your next incident. Ask what onboarding includes and what documentation you receive.

Exit provisions

Nobody negotiates this and everybody eventually needs it. What happens at termination? Do you get your documentation, asset inventory, passwords, and configuration? Is there a transition period? Are administrative credentials handed over cleanly?

A vendor who holds your infrastructure knowledge hostage at exit is a risk you take on at signature, not at exit.

Parts, labour, and the ambiguity between them

Establish clearly whether the AMC covers:

• Labour only — they diagnose and fix, you buy parts
• Labour and parts — usually with caps or exclusions
• Labour, parts, and replacement — full coverage, priced accordingly

Most contracts are labour-only, which is legitimate but should be explicit. The failure mode is a contract that is vague enough for both parties to assume different things until a server power supply fails.

Also worth clarifying: does the vendor supply parts at cost, at a markup, or at market rate? And is there a committed procurement lead time for common failure items? A four-hour response is irrelevant if the replacement drive takes nine days to arrive.

Security and access

Increasingly the most consequential section, and often the thinnest.

• What administrative access does the vendor hold, and how is it controlled?
• Is privileged access individually attributable, or does the whole team share one account?
• Are their access credentials subject to multi-factor authentication?
• What are their obligations if they suffer a breach that could affect you?
• Under the UAE’s data protection framework, if the vendor processes personal data on your behalf, the contract should reflect that relationship and its obligations
• What happens to their access on termination, and how quickly?

A support vendor typically holds the most privileged access in your environment. That deserves contractual attention proportionate to the risk.

Tiering: matching the contract to the organisation

Not every business needs the same contract, and paying for coverage you cannot use is as wasteful as buying too little.

A reasonable way to think about it:

• Smaller offices with straightforward setups need reliable business-hours support, patching, backup monitoring, and someone who knows the environment. Extended-hours coverage is often genuinely unnecessary.
• Growing businesses with in-house dependencies — a server, a line-of-business application, staff who cannot work if it stops — need faster severity-1 response, defined resolution targets, and proactive monitoring.
• Businesses where downtime has direct revenue impact need extended or around-the-clock coverage, aggressive severity-1 targets, and often on-site response commitments.
• Multi-site or higher-compliance operations need dedicated account management, formal reporting, and contractual security and data protection provisions.

The point of tiering is that the questions above have different right answers depending on which of these you are. Ask a prospective vendor which tier they think you need and why. A vendor who recommends their most expensive tier without asking about your environment is selling, not advising.

A checklist for reviewing a proposal

Before signing, confirm you can answer all of these from the document itself:

• What are the resolution targets, not just response times, by severity?
• Who assigns severity, and can you escalate a disagreement?
• Exactly which hours and days are covered, including UAE public holidays?
• What is on the exclusions list, and how are “user error” and “unauthorised change” defined?
• Is there a ticket or hours cap, and what is the overage rate?
• Does coverage include parts, or labour only?
• What preventive maintenance is scheduled, and does it include backup restore testing?
• What reporting do you receive, and how often?
• What is the escalation path, by name and threshold?
• What happens at termination — documentation, credentials, transition?
• What administrative access does the vendor hold, and how is it secured?
• What happens when equipment ages out of supportability mid-term?

If a proposal cannot answer these, that is itself the answer.

Reviewing your current AMC?

KNH IT provides IT annual maintenance contracts across Dubai, structured in tiers so the coverage matches the environment rather than the other way round. Our AMC scope, response and resolution targets, and what each tier includes are set out on our AMC page.

If you have an existing contract and want a second opinion on where it leaves gaps, we are happy to review it

See our AMC tiers: Annual Maintenance Contract (AMC). Contact: Click Here

FAQ