SLA vs OLA vs UC: How the Three Agreements Fit Together in Outsourced IT

The short version: An SLA is the promise a provider makes to its customer. An OLA (operational-level agreement) is the internal promise between the provider's own teams that makes the SLA achievable. A UC (underpinning contract) is the contract with an outside supplier that does the same job. Each target in the SLA should be backed by an OLA or UC that is at least as fast.

If you buy IT support from a provider, you sign one of these three agreements: the SLA. The other two sit behind it, out of sight, and they decide whether the SLA's numbers are realistic. This guide explains what each one is, who the parties are, how they stack up, and what the picture means when your IT support is outsourced.

We read the outside definitions on 28 October 2026: the Wikipedia article on service-level agreements, the Wikipedia article on operational-level agreements and the Wikipedia article on service-level objectives (all checked 2026-10-28). The term "underpinning contract" is ITIL vocabulary. We did not retrieve the ITIL glossary text on that date, so the explanation of UC below is our own plain-language reading, not a quotation. Brocent figures come from our published SLA page.

What is the difference between an SLA, an OLA and a UC?

The simplest way to separate them is to ask who signs each one.

• SLA (service level agreement): between the service provider and its customer. It states what the customer can expect, in terms the customer cares about: response, resolution, hours, availability, reporting.
• OLA (operational-level agreement): between teams inside the same provider, for example the service desk and the network engineering team. It states what one team commits to do for another, and how fast, so that the provider can keep the SLA.
• UC (underpinning contract): between the provider and an outside supplier, such as a carrier, a software vendor or a hardware maintenance firm. It states what the supplier commits to do for the provider, and how fast, for the same reason.

The three are not alternatives. They are layers of one chain, and the customer only sees the top layer.

What is an SLA, and who is it for?

The Wikipedia article on SLAs (checked 2026-10-28) describes an SLA as an agreement, typically a binding contract, between a service provider and a customer that defines particular aspects of the service, such as quality of service, availability and responsibilities. It adds that SLAs commonly contain service-level objectives, which are measurable targets, for defined indicators such as uptime and first-call resolution.

An SLA is written for the customer. It answers questions like "how soon will someone answer?", "when will it be fixed?" and "what do I get if it is not?". Our guide to what an SLA is in IT support goes through the contents in detail, and the P1 to P4 priority guide explains how priority levels set the targets.

The same Wikipedia article notes that large organisations also keep SLAs internally, where one department is the customer and another is the provider. That is a legitimate use of the word, but it is easy to confuse with an OLA, so the rest of this article uses SLA for the customer-facing agreement and OLA for the provider's internal one.

What is an OLA?

The Wikipedia article on OLAs (checked 2026-10-28) describes an operational-level agreement as defining the interdependent relationships that support an SLA. It sets out the responsibilities of each internal support group towards the others, including the process and the timeframe for delivering their services. The same article says an OLA is not a substitute for an SLA, and that its purpose is to make sure the underpinning activities done by several support teams line up to deliver the SLA.

In practice an OLA answers questions the customer never asks but always feels:

• Handoffs: when the service desk cannot fix a ticket, how quickly must the next team accept it?
• Information: what must be in a ticket before it is passed on, so the next engineer does not start from scratch?
• Hours: which team covers which hours, and who is on call overnight?
• Escalation: who is paged when a deadline is about to be missed?

Without those answers, an SLA target is a hope. The Wikipedia article makes a related point: if the underpinning OLA is not in place, it is often very difficult to go back and engineer agreements between the support teams afterwards. Our articles on L1, L2 and L3 support levels and on the escalation matrix describe the handoffs and the contacts that an OLA usually formalises.

A few variants of the name appear: organisational-level, operating-level and operations-level agreement. The Wikipedia article says they all mean the same thing.

What is an underpinning contract (UC)?

In ITIL terminology, an underpinning contract is a contract between the service provider and an external supplier, made so that the supplier's performance supports a commitment the provider has made to its customer. (This is our reading; see the note on sources above.) The supplier might be:

• an internet or leased-line carrier,
• a software vendor that provides a licence and support,
• a hardware maintenance company that supplies spare parts,
• a data centre or cloud platform operator.

A UC is a real contract with commercial terms, so it often has its own SLA inside it. The difference is who is on each side. An SLA has the end customer on one side. A UC has the provider as the customer and an outside company as the supplier.

How do the three fit together?

Draw the chain from the customer downward:

1. The customer has an SLA with the provider.
2. The provider's service desk has OLAs with its engineering teams.
3. The provider has UCs with outside suppliers.

Each layer must be at least as fast as the promise above it. If the SLA says a critical incident gets a first response in 20 minutes, the OLA for the team that does the first response must be set so that 20 minutes is achievable. If the SLA says a carrier fault is escalated in an hour, the UC with the carrier must give the provider a way to reach the carrier's fault desk at that speed.

A simple way to check this is a time budget. Take one SLA target and list every step inside it. For a first response target the steps are:

• The ticket arrives and is logged by the system.
• The service desk picks it up and classifies the priority.
• The acknowledgement is sent to the customer.

The time allowed for all three steps together must fit inside the SLA figure. As an illustration (the numbers are invented to show the arithmetic and are not Brocent's): if an SLA promises a 20-minute first response and the internal agreement allows the service desk 30 minutes to pick up a critical ticket, the SLA cannot be met, however hard people try. The arithmetic fails before the humans do.

What does this look like when IT support is outsourced?

Outsourcing adds two things to the picture, and both are worth a question before you sign.

Your own people are part of the chain

An outsourced engineer cannot fix a locked-out account without knowing the account is yours to unlock, and cannot add a new starter without an approval from your HR contact. These are dependencies on the customer side. A good agreement lists them as customer responsibilities with time limits, such as who approves access requests and how quickly. Some teams write this as a short internal agreement between IT, HR and facilities, which works like an OLA on your side of the table. If the customer's approvers are slow, the provider's clock should say so, and a well-written pause condition does.

The provider's suppliers matter

The provider's SLA can only be as strong as its UCs for the parts it does not control. Ask how the provider handles a fault in a carrier line, a software vendor's platform or a hardware part on back order. The honest answer is usually "we respond and escalate to the supplier within our SLA, and we keep you updated, but the supplier's repair time is outside our control". That is a fair answer when it is written down, with an update frequency. It is a problem when the SLA promises a resolution time for something the provider cannot repair.

Also ask whether the provider's targets are "back-to-back" with its suppliers' targets. A provider that promises a four-hour fix on a leased line, while its own carrier contract allows 24 hours, is carrying a risk that either shows up in a missed target or in a limit buried in the exclusions.

A worked example: an office internet outage

This is an illustrative scenario, not a real client. A small office loses its internet connection on a weekday morning.

1. The user reports the outage. The SLA between the office and its IT provider says a business-critical outage gets a first response within a stated number of minutes.
2. The service desk logs the ticket, confirms the cause is outside the building, and passes it to the network team under an OLA that sets how quickly the network team must accept it.
3. The network team calls the carrier's fault desk under the UC, which defines the carrier's response and repair times.
4. The provider updates the customer at the agreed interval until the carrier repairs the line, then closes the ticket and records the root cause.

If the customer asks "who is late?", the layered agreements make the answer clear. A slow first reply is an SLA problem for the provider. A slow handoff inside the provider is an OLA problem. A slow repair by the carrier is a UC problem that the provider has to manage on the customer's behalf. Without the layers, the answer is "everyone, and no one".

For incidents that affect the whole business, see our guide to the major incident management process, which covers communication and roles.

How is an SLA different from an SLO, a KPI and a contract?

These terms overlap, so a short comparison helps.

• SLA versus SLO: an SLO is one measurable target inside an SLA. The Wikipedia article on SLOs (checked 2026-10-28) says the SLA is the entire agreement that specifies what service is provided, how it is supported, times, locations, costs, performance and responsibilities, while SLOs are specific measurable characteristics of it.
• SLA versus KPI: a KPI is any measure a team uses to track its own performance. An SLA target is a KPI that the provider has promised to the customer.
• SLA versus contract: the SLA is usually a schedule inside the contract. The contract covers price, term, liability and termination.
• OLA versus SLA: an OLA is internal and supports the SLA. It is not a substitute for it.

If you want the metrics that SLAs and OLAs are usually measured with, see our guide to MTTR, MTBF and MTTA and the article on first call resolution.

What mistakes do buyers and providers make?

• Treating the SLA as the whole picture. An SLA looks complete on its own. The OLAs and UCs behind it decide whether it is reliable.
• Promising resolution times for third-party faults. A provider can commit to response and escalation for a supplier's fault. A repair time it does not control belongs in the exclusions, with an update rule.
• Setting OLAs slower than the SLA. The arithmetic fails, and the people on the desk take the blame.
• No owner for handoffs. When two teams each assume the other has the ticket, the clock runs and nobody works. An OLA should name who accepts the ticket and by when.
• Customer-side delays left out. If the customer's approvers are not part of the picture, the provider's clock runs while it waits for a reply. A fair agreement handles this explicitly.
• Never reviewing. Teams change, suppliers change, and a target agreed two years ago may no longer fit. Review OLAs and UCs whenever the SLA changes.
• Confusing internal SLAs with OLAs. If your company runs internal SLAs between departments, call them what they are, but do not expect them to replace the provider's own OLAs.

What should you ask a provider about OLAs and UCs?

You do not need to see the provider's internal documents. You can ask these questions about the effect:

1. Which targets in the SLA depend on outside suppliers, and how are those faults handled?
2. How does a ticket pass between support levels, and what is the maximum time to accept it?
3. Who is on call outside business hours, and how does a critical ticket reach them?
4. How do you measure the handoff steps, and do they appear in the report you send me?
5. What do you do when a supplier is slow? Is there an escalation path with named contacts?
6. Which customer-side tasks stop the clock, and how do you tell me when it is stopped?
7. How often do you review the internal agreements and supplier contracts that support my SLA?

A provider that can answer these clearly has probably thought about the chain behind the SLA.

How does Brocent present its SLA?

Our SLA and service priority page publishes the customer-facing agreement: five priority levels (P1 to P5), first response, remote support, onsite and resolution targets for each, two service windows (8x5 and 24x7), and an impact-by-urgency matrix. As of 28 October 2026 the table shows a first response of 15 minutes for P1 and P2, and resolution targets of 8 business hours for P1 and 24 business hours for P2. The page also states that the figures depend on the service window and on the contract terms.

That page covers the SLA. Internal agreements between our teams, and our supplier contracts, are not part of what we publish there. What you can ask for, and what any customer should ask for, is evidence that the SLA is measured: a monthly report of actual performance against each target. Our managed IT support plans and the 24/7 help desk service describe how the service is delivered, and our managed IT support plans and per-user pricing shows the published response commitment next to plan prices.

Frequently asked questions

What is the difference between an SLA and an OLA?

An SLA is an agreement between a provider and its customer. An OLA is an agreement between teams inside the provider, written so that the provider can meet the SLA. The customer signs the first and normally never sees the second.

What does UC stand for in ITIL?

UC stands for underpinning contract. It is a contract between a service provider and an outside supplier, made so that the supplier's performance supports what the provider has promised its customer. We describe it in our own words because we did not retrieve the ITIL glossary text on 28 October 2026.

Can an OLA replace an SLA?

No. The Wikipedia article on OLAs (checked 2026-10-28) says an OLA is not a substitute for an SLA. The OLA supports the SLA from inside the provider, and the customer needs the SLA to hold the provider to account.

Do small businesses need to worry about OLAs?

Not directly. A small business signs the SLA and should ask the questions above about how it is supported. If you run your own small IT team that depends on other departments, writing down who approves what and how quickly is a light version of an OLA.

What is the relationship between an SLA and an SLO?

An SLO is a measurable target inside an SLA, such as a response time or an availability percentage. The SLA is the whole agreement around the targets, including scope, hours, reporting and remedies.

Who is responsible when a supplier causes the outage?

The provider is the party you contract with, so the provider is responsible for managing the supplier. What the SLA promises for supplier faults varies: many commit to response, escalation and regular updates, but not to a repair time. Check how your SLA treats third-party faults before you sign.

Where can I see how Brocent's targets are set out?

On the SLA page, which lists the P1 to P5 targets and the two service windows. For help comparing your current agreement with it, contact us.

Want these targets in a contract, not a slide? Brocent's managed IT support plans publish the SLA and the per-user monthly price side by side for Hong Kong, Singapore, mainland China and the United States. See the plans and pricing or talk to a consultant.