The provider's monthly report says "SLA compliance: 98%". That same month the ERP was down for half a day, the warehouse shipped orders with handwritten dispatch notes, and nobody from the provider showed up until the afternoon. Both things are true. The contract measured whether someone answered the ticket on time, not whether the problem got fixed.
When you hire managed IT services, the SLA (service level agreement) is what turns a sales promise into an obligation you can measure. Many SLAs, though, are written to look good in the proposal rather than to protect your operation. Below is how to read one and what to ask for before signing: severity levels, response and resolution times, penalties, reporting, IT governance and exit terms.
If you're still deciding whether a managed service makes sense for you, we covered that in Managed IT services: what they include and when they make sense. Here we assume you already have a proposal on the table.
Response is not resolution
The most common trap is a single word. "Response time" usually means someone acknowledged the ticket: an automatic email, a phone call, an assignment in the ticketing tool. "Resolution time" is when the service works again. An SLA that only commits to response can be 100% met while the system is down all day.
When you read the contract, check how each term is defined. For response, whether an automatic message counts or a qualified technician has to be working on the case. For resolution, whether a permanent fix is required or a workaround that restores service is enough; the second is normal, with a separate deadline for the root cause. And for the clock, when it starts: when you open the ticket or when the provider "validates" it, and whether it stops while they wait for information from you.
Pausing the clock while the provider waits on you is reasonable. Open-ended pauses, or pauses at the provider's sole discretion, are not. Ask for every pause to be logged in the ticketing tool where you can see it.
Severity levels: the table that decides everything
Times only mean something if they're tied to a clear severity classification. If the provider sets severity without written criteria, it can downgrade a critical incident to "medium" and meet the SLA on paper.
A useful severity table looks something like this. The times are illustrative: each company sets them based on what an hour of downtime costs it.
| Severity | Criteria | Example | Response | Resolution or workaround |
|---|---|---|---|---|
| Critical (P1) | Operations stopped or active security incident | ERP down, ransomware, invoicing blocked | 30 min | 4 h |
| High (P2) | Important function degraded, workaround exists | A module won't load, intermittent VPN | 1 h | 8 h |
| Medium (P3) | Affects one user or a non-critical process | Report error, printer | 4 h | 2 business days |
| Low (P4) | Question or plannable request | New user, permission change | 1 business day | As agreed |
When you review the table in your proposal, look at the examples first. They should come from your business: "electronic invoices aren't reaching the tax authority (SII)" says far more than "system failure". Then look at who classifies. The healthy setup is that you propose the severity when you open the ticket and any downgrade is justified in writing.
Coverage hours also depend on severity. With 9x5 coverage, a P1 that happens on a Friday at 7 p.m. gets handled on Monday. That may be fine for your company or it may not, but it has to be clear before it happens. A common setup is 9x5 for everything and 24x7 for P1 only.
Availability: reading the percentages
If the service includes infrastructure or cloud, the contract will probably promise an availability percentage. The figures look very similar. The downtime they allow does not:
| Monthly availability | Allowed downtime in a 30-day month |
|---|---|
| 99% | ~7 h 12 min |
| 99.5% | ~3 h 36 min |
| 99.9% | ~43 min |
| 99.95% | ~22 min |
Before you settle on a number, ask what is being measured (the server, the application or the user's actual access), with which tool, and whether maintenance windows are excluded. A 99.9% that excludes "scheduled maintenance" with no cap on hours is worth a lot less than it looks.
Penalties and service credits
An SLA without consequences is a statement of good intentions. The usual approach is service credits: a discount on that month's invoice when a metric is missed.
When you negotiate them, the first thing is that they apply automatically. If you have to claim them in writing within a short window, in practice nobody collects. They should also escalate, because one bad month is not the same as three in a row. A cap, for example a percentage of the monthly invoice, is normal and acceptable as long as repeated breaches let you terminate the contract without a penalty. That termination right is the penalty that really matters.
The opposite extreme exists too. With disproportionate penalties, the provider spends its time arguing over every severity rating instead of fixing the fault. What you want is for both sides to benefit from the same outcome.
Reporting and IT governance
The monthly report is where you see whether the service is improving or just staying afloat. At a minimum it should include:
- Tickets by severity, with response and resolution compliance measured separately.
- Recurring incidents and their root cause. If the same problem shows up four times, someone should be managing the problem and not just closing tickets.
- Measured availability, with every outage detailed.
- Changes made and changes that failed.
- Recommendations with an owner and a date.
A report nobody reads doesn't do much. That's why the contract should set an IT governance model: a monthly operational meeting, a quarterly service review with someone from management on each side, and an escalation matrix with names and phone numbers rather than generic job titles. Also ask for direct access to the ticketing tool. You shouldn't need a PDF to know how your service is doing.
Security, personal data and the exit clause
Two Chilean laws change what a managed services contract should cover.
Law 21,719 amends Law 19,628 on personal data protection and takes effect on December 1, 2026. If the provider accesses systems holding customer or employee data, it acts as a data processor. The new article 15 bis requires a contract setting out the purpose and duration of the engagement, the purpose of processing, the types of data and the categories of data subjects. The processor can't delegate the work without specific written authorization, must apply the security measures and report breaches to you, and must delete or return the data when the engagement ends. That belongs in the service contract, not in an annex nobody reads. We go deeper in GDPR data protection and Chile: what applies to your company.
The other is the Cybersecurity Framework Law (Law 21,663). If your company provides services classified as essential or has been designated an operator of vital importance, its article 9 requires it to send an early warning to the National CSIRT within three hours of becoming aware of an incident that may have significant effects. If your provider is the one who detects the incident, the SLA has to require it to notify you well before that deadline. Even if the law doesn't apply to you, setting a short notification window for security incidents is common sense.
That leaves the exit, which almost nobody negotiates at the start because everyone is happy. Before signing, get these in writing:
- Admin credentials, subscriptions and documentation are in your company's name.
- A handover period with a deadline, deliverables and included hours.
- Delivery of the inventory, knowledge base and ticket history in a format you can use.
- The price of the handover, agreed today and not when you've already decided to leave.
Frequently asked questions
What is the difference between response time and resolution time?
Response is when the provider picks up the ticket and starts working. Resolution is when the service works again, even if through a workaround. The SLA should commit to both and measure them separately.
What penalty is reasonable in a managed IT services SLA?
The usual approach is service credits on the monthly invoice that increase with the severity or repetition of the breach, up to a cap. More than the amount, what matters is that they apply automatically and that repeated breaches let you terminate the contract.
How often should I review the SLA with the provider?
Monthly at the operational level and quarterly with management. Once a year it's worth checking whether the severity levels, hours and metrics still match how your company works today.
Let's review your SLA
At Disrupsoft we provide managed services with an SLA and service catalog, as well as staff augmentation and squads. If you have a managed IT services proposal on the table, or a current contract you're not happy with, we'll review it with you and suggest severity levels, times and reports that fit your operation.
