SLAs for small companies: what to actually require

A service level agreement is the part of a supplier’s terms that says what “the service works” means and what happens when it does not. Small companies rarely negotiate one and seldom read the one they got — until the e-mail provider is down for a morning, nobody knows which address to write to, and the contract turns out to promise a 5 % credit if you claim it within ten days. This guide is what to actually require in an SLA, what the numbers mean, and why the terms belong in your supplier register beside the contacts.

Why an SLA matters more than it looks

For most SMEs no law prescribes SLA contents. Two things make them matter anyway. First, your own customers’ commitments: whatever you promise them rests on what your suppliers promise you, and the gap between the two is your risk. Second, regulation on the customer side. NIS2 Article 21(2)(c) requires entities in scope to have business continuity, backup and crisis management, and Article 21(2)(d) makes their suppliers’ arrangements part of that. DORA goes further for financial entities: Article 30(2) of Regulation (EU) 2022/2554 lists what their contracts with ICT providers must contain — descriptions of functions, locations, availability and integrity provisions, service level descriptions, termination rights — and Article 30(3) adds, for critical or important functions, precise quantitative and qualitative performance targets, notice periods, contingency plans and exit strategies. Sell to a bank or an insurer and those are the questions you will get about your suppliers as well as yourself.

Availability: what the number means

“99.9 % uptime” is a monthly allowance of downtime. Convert it before you sign:

• 99 % — about 7 hours 18 minutes a month
• 99.5 % — about 3 hours 39 minutes
• 99.9 % — about 44 minutes
• 99.95 % — about 22 minutes
• 99.99 % — about 4 minutes

Then read the definitions, because the number is only as good as they are. Measurement window: monthly is standard; a yearly window lets a supplier be down for almost nine hours in one go and stay within 99.9 %. What counts as downtime: the whole service or only the API, degraded performance or only a full outage, measured by the supplier’s monitoring or by an agreed external check. Exclusions: scheduled maintenance, force majeure, “factors outside our reasonable control”, customer-caused problems, third-party outages. Every exclusion is downtime that does not count, and a supplier whose cloud provider is excluded has excluded most of its own outages.

Service credits

Credits are the standard remedy: a percentage of the monthly fee for each availability band missed. Check four things. The size — 10 % for a missed 99.9 % is common; 5 % is thin. The cap — usually 25 to 50 % of a month’s fee, meaning a week-long outage costs the supplier at most half a month. The procedure — most SLAs require you to claim in writing within a fixed period, often 30 days, with your own evidence of the outage; a credit you must claim is a credit most customers never receive. And exclusivity — “credits are the sole and exclusive remedy” means no damages beyond them. For a service you depend on, require the right to terminate without penalty after repeated misses, for example three months out of six. Credits compensate a bad month; only a termination right protects you from a bad supplier.

Maintenance windows

Require advance notice — 48 hours to 7 days — through a channel that reaches you, not only a status page. Require a window in your off-hours, stated in a named time zone: “Sunday 02:00–06:00 UTC” is a window, “outside business hours” is not. Require a cap on maintenance hours per month, and a statement of whether maintenance inside the window counts toward availability. Emergency maintenance should be defined narrowly, with a report afterwards.

Support tiers and response times

Support terms are where “SLA” usually means the least. Require, in writing: severity definitions — what counts as priority one (service down for all users), two (major function impaired), three (minor), four (question); vague definitions let every incident be a P3. Response and resolution targets per severity — acknowledgement within 30 minutes for P1 is realistic for a supplier with on-call staff, “we aim to respond promptly” is not a target; distinguish response, workaround and resolution. Hours — 24/7 for P1 at least, business hours in a named time zone for the rest. And the plan you are on — many suppliers give those targets only on the top tier. Know which tier your plan buys.

Contact routes

An SLA without a contact route is a promise you cannot invoke. Require the incident route — a phone number or an escalation address for P1, not only a web form — the support route for everything else, a status page with subscription, and the security contact for reporting a vulnerability or a breach affecting you. Record them beside the SLA in your own register, with the date, because a support address is the term that changes most often and is announced least.

Data return and exit

The SLA’s last clause is what happens when you leave. The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025 to data processing services such as cloud and SaaS: Article 25(2) requires the contract to set a maximum notice period for switching of no more than two months and a transitional period of no more than 30 days, and Article 29 removes switching charges entirely from 12 January 2027. Check that the SLA and the terms say so, and that export is self-serve and in an open format.

Why the SLA belongs in your register

The day something is down, you need in one place: whom to call, what they promised, where that promise is written, and what your own customers were promised for the service that depends on it. Those facts come from three documents and one person’s notes, and they change independently. A register row per supplier holding the availability commitment, the credit terms, the maintenance window, the support tiers and the contact routes — each with the document and date it came from — is what turns an outage from a search into a phone call. It is also what your customer in NIS2 or DORA scope asks to see, and part of the register NIS2 expects.

The questions to put to the supplier

1. Which document is the current SLA for our plan, and where is its change history?
2. How is availability measured, over what window, and what is excluded?
3. What credits apply per band, what is the cap, how do we claim, and after how many misses may we terminate?
4. What are the maintenance windows, in which time zone, and how are we notified?
5. What are the response and resolution targets per severity on our plan, and the hours?
6. Which phone number or address reaches a person for a priority-one incident?
7. What are the notice and transition periods for switching, and what does export cost?

How Maditon does this

Maditon reads a supplier’s SLA and terms like any other document, and the SLA and contacts view shows one row per supplier: the availability commitment, service credits, maintenance windows, support channels and tiers as read from the documents, beside the contacts your own people recorded. Every value names its origin — the document and the date it was read, or that it was recorded by hand — and when the document and your note disagree, you see both. Per system, your own promise to your customers sits first, then the rows for the suppliers under it, and the whole view is included in the PDF package for the day you have no access to Maditon at all. A value read from a document is a fact with a quote; whether the SLA is good enough is your decision.

See What does the SLA and contacts view show? and What are systems and services in Maditon?, or record your first supplier’s contacts in the app.