MA and SLA contracts: what to check before you sign

A maintenance agreement (MA) often arrives with a one-page SLA promising "response within one hour". Months later the system fails at 2 a.m. on a holiday weekend: the vendor acknowledges on time, service returns mid-morning, and a request to fix a wrong report comes back as a quotation because it is "a change request". Neither side may have breached the contract; the contract was simply unclear. This guide covers the clauses to check before signing. The examples are hypothetical, not customer results or legal advice.

What does an MA cover, and what does it not?

An MA typically should cover fixing defects in delivered software, with new capability quoted separately. SWEBOK V3 (2014; the IEEE Computer Society has since published SWEBOK V4), citing IEEE 14764, defines four categories: corrective (reactive fixes for discovered problems), adaptive (keeping software usable in a changed environment; our example: an operating system upgrade), perfective (enhancements, documentation and performance or maintainability improvements) and preventive (fixing latent faults before they cause failures). Emergency maintenance, a subset of corrective, is an unscheduled change that keeps the system running until a permanent fix.

Write the contract in three zones: included in the MA fee, change request, and out of scope. SWEBOK notes that maintainers may route requests above a certain size, effort or complexity to development, so agree a size threshold, such as estimated hours per request or any database structure change.

Why "system support" may not include backup

The term software maintenance in ISO/IEC/IEEE 14764:2022 does not include operational functions such as backup, recovery and system administration (scope summary in the EVS standards catalogue). If the contract does not list them, each side may read "support" differently, so name backup, restore and server duties separately. To compare managed and in-house operating models, see managed services vs in-house IT.

How to define severity

Base severity on business impact and urgency, with examples from your own system and a named tie-breaker. The UK Cabinet Office incident guidance uses an impact by urgency matrix and sets separate response and resolution targets per priority for internal services during business hours, for example 20 minutes and one hour for a critical outage. Those are one organisation's internal targets, not a benchmark; copy the structure, not the numbers.

Response, restoration and resolution

Response means a responsible person has acknowledged and started work. Restoration means service is usable again, perhaps through a workaround. Resolution means the permanent fix is in production. The Cabinet Office treats an incident as resolved when the incident lead agrees service is restored, and some guides, including our guide to IT support after go-live, also count restoring service as resolution. That is why the contract must state which event stops each clock.

When the SLA clock starts, pauses and stops

Ticketing tools such as Jira Service Management use start, pause and stop conditions, with pausing while waiting for a customer to respond as a typical example, and SLA calendars set time zone, working hours and holidays, defaulting to 09:00–17:00. State the time zone (Asia/Bangkok), the holiday calendar, which severities run 24x7, a closed list of pause conditions and the channels that start the clock.

A hypothetical incident timeline

The figures below are hypothetical. The outage starts at 02:10 on a Sunday, P1 runs 24x7, and waiting for the client's approval pauses the clock.

1. 02:10 monitoring alert; clock starts.
2. 02:25 on-call engineer acknowledges: response in 15 minutes.
3. 02:50–03:20 waiting for the client to approve a failover; clock paused.
4. 03:40 service restored by workaround: 90 minutes elapsed, 60 minutes on the SLA clock.
5. Next business day, 14:00 permanent fix deployed: resolution, followed by a post-incident review.

With only a response target, the vendor met the SLA at 02:25 while the system was still down.

Reporting, patching and backups

Monthly reports should list each ticket with its response, restoration and resolution times and any pauses, not just an overall percentage. The Cabinet Office requires a post-incident review for every P1 and P2 incident; the contract should also say how often progress updates are sent during an incident at each level.

NIST SP 800-40 Rev. 4 defines patch management as identifying, prioritizing, acquiring, installing and verifying patches, and calls patching preventive maintenance and a cost of doing business. Assign each step for operating system, middleware, libraries and application code, and name who approves maintenance windows.

Control CP-9(1) in NIST SP 800-53 Rev. 5 requires testing backups at an organisation-defined frequency. Write that frequency, the evidence and who restores into the contract.

Dependencies and service credits

Each PHP branch gets two years of active support and two of security fixes before end of life; PHP 8.2 security support ends on 31 December 2026. Decide whether such upgrades are adaptive work in the fee or change requests. Cloud SLAs cover only the provider's service: the Amazon Compute SLA excludes failures caused by customer software or equipment.

The same SLA shows how limited credits can be: credits are a share of the monthly bill (10%, 30% or 100%), capped at 100%, must be claimed by the end of the second billing cycle, and are the customer's "sole and exclusive remedies". A credit is not compensation for business loss; check the base, cap, claim process, exclusions and any limit on other remedies.

Change requests, renewal, exit and personal data

SWEBOK refers to these requests as modification requests or problem reports. Require logging, impact analysis, a quote and written approval before work starts. Check auto-renewal, notice periods, price adjustment, termination for repeated SLA misses and handover at exit; see the software vendor handover checklist.

A vendor with production access usually processes personal data, so attach a data processing agreement. A draft DPA that Thailand's Office of the National Digital Economy and Society Commission (ONDE) uses with its own service providers includes processing only on written instructions, appropriate security, written consent for sub-processors, breach notice to the client (24 hours in that draft) and deletion or return of data at contract end (7 days given as an example). These are figures from one draft agreement, not legal requirements.

Before you sign

• Scope by maintenance category, plus a change request size threshold
• Operations duties: backup, restore, system administration
• Severity definitions with real examples
• Separate response, restoration and resolution targets
• Clock calendar, time zone, holidays and pause conditions
• Reports, patching, restore tests and end-of-life
• Service credit base, cap, claim window and remedies
• Renewal, exit handover and a data processing agreement

UNIXDEV runs systems after go-live through DevOps, SRE and managed operations, and maintains existing applications through legacy application maintenance, agreeing severity, scope and clock rules up front.

Continue reading

All engineering articlesExplore related servicesDiscuss a project