What is an application maintenance SLA actually for?

The SLA makes service quality observable and governable after go-live. It prevents neither bugs nor outages. It organises how they are detected, assessed, communicated and resolved. Above all, it reduces the grey area between “the hosting works”, “the application responds” and “the business process is usable”.

An application rarely depends on a single party. The code may be maintained by an agency, the infrastructure by a hosting provider, identity by Microsoft Entra, payments by a service provider and data by an ERP. An incident visible in the browser may therefore originate from a third-party API, a certificate, a database migration, a quota, a network rule or a functional error. The SLA must specify who coordinates the investigation even when the cause is not yet known.

Four access and management models with Microsoft Intune

Before setting response times: map what needs to be maintained

You cannot promise a credible timeframe without understanding the architecture, dependencies and impact of an outage. Start with an inventory: code repositories, environments, domains, certificates, secrets, databases, scheduled tasks, storage, identity providers, email services, payment gateways, APIs, libraries and owners.

Then map the important user journeys. A slow marketing page does not have the same impact as an inaccessible regulatory form, a blocked booking portal or an application that assigns interventions. For each journey, record the hours of use, affected user groups, peak periods, data created and fallback options.

The page Purchase, logistics and personal use policy needed. Purchase, logistics and personal use policy needed.

Also check maintainability before accepting commitments. A product without documentation, a test environment, access to the code or a deployment procedure may require a handover and stabilisation phase. Immediately promising a firm resolution time on an unknown basis creates risk for both parties.

The 12 clauses that make an SLA usable

The best clauses answer twelve simple questions: what, when, how severe, what timeframe, who monitors, who secures, who deploys, who restores, who protects the data, who tests quality, who reports and how to exit.

4. Company-owned device

4. Company-owned device

2. Maintenance categories

Separate corrective maintenance, which fixes an anomaly; preventive maintenance, which reduces a risk; adaptive maintenance, which follows a change in a browser, API or platform; and evolutionary maintenance, which adds or modifies a feature. An incident package must not become an unlimited backlog of new features. Define how a request changes category after analysis.

3. Service hours and on-call support

Specify the time zone, Belgian working days, public holidays, channels and exceptions. “24/7” support may mean automated monitoring, on-call support for critical incidents or a full helpdesk: these are not the same services. Also specify who can trigger on-call support and how to prevent a non-critical request from activating the service.

4. Priority matrix

Define each level by impact and urgency: number of users, critical journey, data loss, security exposure, available workaround and external deadline. A feature that is completely unavailable to two people may be less urgent than a silent error affecting all invoices. Provide an arbitration rule when the client and maintainer assign different priorities.

5. Clocks and service targets

Distinguish acknowledgement, start of analysis, update frequency, workaround, restoration and permanent resolution. Explain when the clock starts, what may suspend it — for example, awaiting essential information — and what evidence stops it. A permanent resolution may sometimes depend on a third-party supplier; in that case, a restoration or workaround target is more controllable.

6. Monitoring and detection

List the checks: availability, application errors, latency, scheduled tasks, certificates, capacity, queues, integrations and synthetic transactions. Define thresholds, measurement retention, alert channel and owner. An HTTP test receiving a 200 status code does not prove that the connection or payment works; critical journeys deserve checks closer to the real user experience.

7. Vulnerabilities and security patches

Write policy and notice. Explain visibility, responsibilities, support, loss, removal, departure and updates.OWASP ASVS 5.0 provides an open framework for specifying and verifying application security controls, including in contracts. However, the SLA should avoid turning an automated scanner into absolute proof of security.

8. Deployments, changes and rollback

Describe the request, review, testing, approval, production deployment window, monitoring and rollback. Specify who approves an urgent change and how it is documented afterwards. Measure separately the incidents caused by a change and the success of rollbacks.

9. Backups and restoration

Purchase, logistics and personal use policy needed.

10. Personal data and operational security

When the maintainer processes data on behalf of the data controller, Article 28 of the GDPR requires a contract or legal act defining, in particular, the subject matter, duration, nature, purpose, types of data and obligations. Article 32 requires measures appropriate to the risk. The SLA must link these responsibilities to access, logs, incidents, subcontractors, deletion and notification, without replacing the data processing agreement.

11. Performance, compatibility and accessibility

Purchase, logistics and personal use policy needed. W3C Web Content Accessibility Guidelines 2.2 Mobile Application Management applies rules to work applications and business data without placing the whole endpoint under device management. Microsoft describes MAM for unenrolled devices as a way to combine application configuration and protection. On supported apps, policies can require an app PIN, restrict copying to personal apps, limit local storage and selectively remove organisational data.

12. Reporting, governance and reversibility

Define a regular dashboard: incidents, achievement of targets, trends, vulnerabilities, backups, releases, capacity, technical debt and actions. Identify meetings, decision-makers and escalations. Exit arrangements should provide for the export of data, code, documentation, transferable secrets, accounts, ticket history, dependencies and handover support. Good reversibility also improves day-to-day maintenance.

Control table: what must be written down and evidenced

Use this table to compare two proposals without reducing the decision to the monthly price or the most impressive timeframe.

Build a criticality matrix that teams will actually use

A usable priority combines impact and urgency, then provides examples specific to your business. Avoid defining P1 as a “blocking incident” without explaining for whom, at what point and with what alternative.

A critical level may cover the unavailability of an essential journey for all users, suspected active exposure, data corruption or the inability to meet an immediate deadline. A high level may concern a large group without an acceptable workaround. A normal level covers a limited or workaround-enabled defect. A planned request is not an incident, even if it is important.

Purchase, logistics and personal use policy needed.

Do not automatically link priority to a promise of permanent resolution. The supplier has greater control over acknowledgement, escalation and restoration efforts than over the correction of an external dependency. You can set a target for regular updates and restoration, followed by an action plan for the root cause.

The incident lifecycle: seven steps and several clocks

A well-managed incident moves from detection to improvement; it does not end when the screen first comes back. The sequence helps place commitments in the right areas.

1. Detection: automatic alert or user report, with time and symptom.
2. Qualification: 4. Company-owned device
3. Acknowledgement: confirmation, initial priority and owner.
4. Containment or workaround: Company device
5. Restoration: return the journey to a usable and verified state.
6. Analysis: identify the cause, contributing factors and missing controls.
7. Corrective action: fix, test, document and monitor effectiveness.

Tickets must retain priority changes, pauses and communications. Measurement is not intended to manufacture a flattering score: it reveals recurring incidents, fragile dependencies and late detection.

Rollout plan

Organisation size alone is not enough: hours, seasonality, data and alternatives determine the SLA.

Accounting firm during filing deadlines

A document portal may be used all year but become critical during tax periods. The SLA can provide enhanced coverage during announced windows, pre-peak testing and a freeze on non-essential changes. The objective is not permanent 24/7 support, but capacity adapted to the actual calendar.

Association or ASBL with a campaign

Purchase, logistics and personal use policy needed.

Multi-site group and operational tool

If the application distributes morning interventions, a short outage at the start of the day has a high impact. Provide monitoring before opening, a manual procedure, emergency access and escalation contacts. Rapid restoration may take priority over the permanent fix, which can then be carried out during a controlled window.

Public administration or healthcare organisation

Data responsibilities, accessibility, history and secondary suppliers may carry as much weight as the timeframe. The DPO, business, security and procurement teams must approve the applicable clauses. Never infer compliance or certification from the SLA alone; require evidence appropriate to the context.

For a strategic application, the page GVISION Power Apps and custom web applications shows how architecture, roles, integrations, documentation and the test environment are designed together. Maintenance becomes more predictable when these elements exist from the outset.

Negotiate a realistic SLA and manage it over time

First ask for a measurable methodology, then adjust coverage and timeframes to the value of the service. A very short commitment costs more or becomes unverifiable if it is not supported by an on-call organisation, ready access and a recoverable architecture.

Four access and management models with Microsoft Intune

Choose a small number of indicators: median time and distribution by priority, adherence to update commitments, restoration time, recurring incidents, deployment failures, success of backups and tests, open vulnerabilities and availability of critical journeys. An average alone can hide a lengthy incident; keep major cases visible.

Service credits may have a contractual function, but they neither restore data nor rebuild trust. Prevention, transparency and learning remain the priority. Have the legal clauses reviewed by a suitably qualified adviser; this guide is an operational framework, not legal advice.

Belgian scenarios

The SLA mainly fails when it uses reassuring words without a measurement method or clear allocation of responsibilities.

• Confusing response with resolution: an automated acknowledgement does not prove that someone is analysing the incident.
• 4. Company-owned device Purchase, logistics and personal use policy needed.
• Leaving “critical” subjective: every request becomes urgent and triage loses its value.
• Forgetting third parties: no one coordinates the hosting provider, software vendor, payment provider or identity service.
• Measuring infrastructure only: the server responds while the business journey fails.
• Counting backups, not restorations: there is no evidence of recoverability.
• Company device maintenance turns into an unpredictable project.
• Ignoring accessibility and browsers: a release degrades the experience for some users without triggering an alert.
• Neglecting exit: code, data, secrets and knowledge remain with the supplier.