SLA for a Business System: What the Contract Should Cover

Why a Business System Needs an SLA#

A business information system doesn't stop needing attention once it goes live. Users eventually run into errors, load on the system shifts with the season or with business growth, and integrations with other systems get updated independently of the client. The question is never whether a disruption will happen, but how quickly and by what agreed process the organization responds. An SLA — a service level agreement — is the contractual framework that settles this question in advance, before any disruption occurs.

Without an SLA, response is negotiated case by case. The client often doesn't know who to call, the provider doesn't know which issue takes priority, and downtime can stretch out simply because it isn't clear who has to act next. This kind of uncertainty is most costly when the system supports a core business process and every hour of downtime directly affects the users, customers, or employees who depend on it.

An SLA contract sets out error classes, how issues are reported, responsibilities on both sides, and the escalation process if an agreed deadline isn't met. This applies equally to public-sector systems, which often require a documented support process, and to private companies maintaining their own business applications, portals, or SaaS platforms. The content of an SLA varies by industry, but the underlying structure of the contract stays largely the same.

Error Classes and Priority Handling#

The first step in drafting an SLA is agreeing on error classes. Not every disruption carries the same urgency, so the contract needs to state clearly which situation belongs to which class and what that means for how it's handled. Without this split, every report gets treated the same way — a minor cosmetic issue waits in the same queue as a full system outage, which slows down response exactly where speed actually matters.

• Class 1 – outage: the system or a key part of it is down; handled with top priority, with a response time agreed in the support contract.
• Class 2 – disruption: the system works, but a specific function doesn't; handled by priority as set out in the contract.
• Class 3 – minor error: no impact on business operations; scheduled into the next regular release.
• Class 4 – request: a change or enhancement to the system; scope is assessed and the timeline agreed with the client.

#

Splitting issues into four classes lets limited support capacity go where it has the most impact. An outage of a core system is handled immediately, while a request for a new feature is folded into the regular development flow. The client gains predictability, knowing what to expect for each type of report, while the provider gets a clear basis for allocating the team's time between fixes and development work.

We don't publish universal response times in hours upfront, because they depend on the system's criticality, the industry, and what's agreed with the client. The response time for each class is set when the SLA is signed and becomes part of the contract, not a general promise. That way, every system gets response times matched to its own complexity, instead of one formula that ignores the gap between a simple and a critical system.

What the Contract Needs to Spell Out#

Beyond error classes, an SLA contract needs to cover several other elements, and these need to be settled before signing, not during the first outage. They can look purely administrative until they actually matter, at which point they decide whether support runs smoothly or adds friction. The points below are worth checking in every SLA contract, regardless of the system's size or the client's industry.

• How errors are reported and the contact point the client uses to report a disruption.
• The escalation process if a response time or commitment in the contract isn't met.
• Responsibilities on the client's side and the provider's side for each stage of handling an issue.
• Separation of development, test, and production environments, and the rules for moving changes between them.
• How resolved issues and the status of open reports are communicated.
• The scope of regular maintenance: technical and security updates, not just error fixes.

#

Each of these elements shapes how smoothly and transparently day-to-day work runs after the contract is signed. If the reporting channel isn't clear, a disruption often gets reported through the wrong channel and handling gets delayed, even when the underlying issue could have been fixed in minutes. If responsibilities aren't split out, a report can sit unanswered because no one on the provider's side is sure they're the one who should act.

For the client, this means it's worth insisting on concrete SLA content rather than general phrasing like “regular support” or “fast response”. A specific agreement on reporting, escalation, and status updates is what separates an SLA from an ordinary service contract — and what actually determines how support behaves in the first week after a real outage.

Separate Environments and the Change Process#

One part of an SLA that often gets overlooked is how development, test, and production environments are set up. The development environment is for ongoing code work, the test environment is for checking changes before release, and production is where the client's users actually work with the system. Keeping these three separate reduces the risk of an unverified change reaching end users before anyone has confirmed it works as intended.

Real personal data is never used in the test environment. This matters most for systems processing user, customer, or employee data, since testing with real data introduces unnecessary privacy risk regardless of how carefully the environment is otherwise secured. The contract should state this rule explicitly rather than leave it as an unwritten practice that every new team member only learns about later.

Every change, whether an error fix or a new feature, goes through review and testing before it's released to production. This applies to small fixes too, since minor, seemingly harmless changes are often exactly what causes unexpected errors. An SLA contract should describe this process, making clear who reviews a change and who approves it for release into production.

Taking Over an Existing System for Maintenance#

An SLA contract doesn't always start alongside a brand-new system — it's often set up when a client wants formal support for a system that already exists and has, until now, had no formal maintenance agreement. In that case, taking over maintenance starts with a review of the source code, architecture, infrastructure, and data, since without that review it isn't possible to realistically judge how much work the system needs or which response classes apply.

The same applies to a system left unfinished — perhaps built by a different team on a project that stalled before completion. Taking over maintenance of such a system starts with reviewing its actual state, not assuming the documentation is complete or that the code matches expectations. Only after that review can a realistic SLA scope and matching error classes be set.

For the client, this means taking over an existing system isn't a simple administrative step — it's the opening phase of the project. Time spent on review pays off later through a more realistic SLA classification and fewer surprises after signing. A system properly reviewed before takeover is also easier to maintain in the long run, since the risks are already known from day one.

Ownership of Code, Data, and Documentation#

An SLA contract needs to be unambiguous about ownership of the source code and data. The source code and data belong to the client, not the support provider. This principle has to be written explicitly, not assumed, since ownership is exactly the kind of question that turns contentious if a maintenance contract ends or the provider changes and the client is left without access to their own system.

• Source code remains the client's property throughout the engagement.
• Data processed by the system remains the client's property.
• System documentation is part of the handover, not a separate service to request later.
• Access credentials and passwords are handed over to the client, not retained by the provider.
• The client retains access to their own system at all times, regardless of who currently provides support.

#

These rules matter most when a client is considering switching support providers or bringing maintenance back in-house. If documentation, access, and credentials are set up properly from the start, the transition is fast and free of unnecessary complications. If they aren't, switching providers becomes a slow, risky process, since the new provider first has to reverse-engineer the system without proper information, which extends downtime exactly when the client needs support the most.

Written rules on ownership and handover aren't a formality — they protect the client. They keep the SLA a tool for orderly collaboration, rather than something that locks the client into one provider through lack of documentation or access to their own system. The client can check the system's state or change providers at any time, without needing the current provider's consent.

Testing and QA Within the SLA#

Maintaining a system isn't just about fixing reported errors — it's also about verifying that a fix doesn't introduce new ones. An SLA contract should define what testing process accompanies every change before it reaches the production environment, and who is responsible for making sure that testing actually happens before each release.

Testing includes prepared test scenarios, manual and automated testing — including tools such as Playwright and Cypress — plus API testing and regression testing to confirm a change hasn't broken existing functionality. Automated tests can run as part of a CI/CD process, executing with every code change rather than only before major releases, which catches issues quickly before they ever reach production.

Before releasing significant changes, acceptance testing against criteria agreed in advance makes sense, with the client confirming a change works as intended. For systems where reliability is critical, QA can be handled by a team separate from development, reducing the risk that a developer overlooks their own mistake by reviewing it from the same perspective it was written in.

For the client, this means an SLA isn't just a promise of a fast response — it's also a commitment to the quality of fixes. A system maintained without regular testing might get fixed faster on paper, but carries a higher risk of new errors, which costs more and disrupts more over time than a consistent testing process before every release.

Who Provides the Support#

An SLA contract is only as good as the team behind it. For maintaining and supporting business systems, Epix assembles project teams from its own specialists and its specialist partner network, depending on which roles a given system requires — from simple upkeep to more demanding security and infrastructure work.

• senior engineers and solution architects for systems with more demanding architecture
• backend and frontend developers for ongoing fixes and enhancements
• DevOps and cloud engineers for the infrastructure the system runs on
• cybersecurity specialists for security updates and incident response
• QA and test automation engineers to verify changes before release
• project managers who coordinate SLA obligations and client reporting

#

Within Epix and its specialist partner network, certified profiles are also available for cloud, security, and infrastructure work — including AWS, Microsoft Azure, Google Cloud, Kubernetes, and cybersecurity — alongside a delivery structure aligned with ISO 9001, ISO 20000/20001, ISO 27001, and ISO 27701 standards. These certifications and standards apply to Epix and its partner network as a whole, not to any individual team member or to Epix Group d.o.o. on its own.

For larger projects, Epix assigns a project manager, defines each team's responsibilities, and sets deadlines along with communication and reporting practices, so the client knows who is responsible for each part of maintenance. Smaller systems may have a smaller team, but the structure of responsibility stays the same: it's clear who picks up a report, who resolves it, and who confirms it as closed.

How SLA Scope and Pricing Are Determined#

We don't list SLA pricing here, because it always depends on the scope a given system actually requires — a flat number would be misleading both for a system that barely needs basic monitoring and for one connecting several internal applications. Rather than a single figure, it's more useful to understand which factors shape that scope, since the same factors apply to pricing any SLA contract, regardless of industry or client size.

• the scope of system functionality and the number of user roles
• how many existing systems need to be connected and what their APIs look like
• whether it's a new system or taking over and upgrading an existing one
• security, audit trail, and compliance requirements, for example in the public sector
• the scope of testing and whether independent QA is needed
• the level of post-launch support and the agreed response times per error class

#

Together, these factors determine how many support hours, which roles, and what infrastructure a given SLA actually needs. A system with one simple integration and low criticality needs a much smaller support scope than a system connecting several internal applications and required to meet the demands of a regulated environment, where any disruption can carry business or compliance risk.

Pricing is set only after reviewing the requirements, scope, and technical complexity of the project. Before that, a short analysis that breaks the scope into workstreams makes sense, so each workstream can be estimated and delivered separately — whether for a new system or for taking over an existing one into maintenance, where the analysis also includes a review of the code, architecture, and data.

How to Start the Engagement#

At Epix, preparing an SLA contract starts with reviewing the system that needs maintaining — whether it's a new system about to go live or an existing system that has, until now, run without a formal support agreement. That review is the starting point for every step that follows.

Based on a review of the architecture, infrastructure, and data, Epix proposes error classes, appropriate response times, and a maintenance scope matched to the specific system. The client retains ownership of the code, data, and access credentials throughout the engagement, and documentation is part of the handover from day one, not an extra service to request later.

The result is an SLA contract that clearly defines what happens in the event of an outage, a disruption, a minor error, or an upgrade request — and who is responsible for each step. That's the foundation a business system needs to run predictably, whatever situations day-to-day operation brings.