An SLA Agreement Step by Step. How to Write a Contract That Protects Your Business When a System Fails

Black Friday, 10:00 a.m. Your e-commerce payment system goes down. You call the provider , no answer. You check the contract. There is no SLA. Or there is, but all it says is “response time: up to 24 hours”. For the next eight hours, your store makes no sales. How much have you just lost?

If you run a technology company, an e-commerce business or a SaaS company , and use external IT services , an SLA (Service Level Agreement, i.e. an agreement guaranteeing a specified level of service) determines whether, in a crisis, you have a tool that enables you to act or are left with nothing but a phone and hope. A poorly drafted SLA means chaos when the system stops working. A well-drafted one establishes clear responsibilities, gives you control over the provider’s response time and protects you against losses that may exceed the cost of the service many times over.

In this article, I will show you, step by step, how to prepare an SLA that protects your business. I will discuss service metrics, penalties, issue-reporting procedures, data security, IP rights and exit mechanisms , using specific scenarios and the case law of Polish courts.

Key terms to understand before negotiating an SLA

Before we move on to the specifics, let’s clarify the terminology. Many SLA disputes arise because the parties understand the same words differently.

The distinction between response time and resolution time is one of the most common sources of misunderstanding. Customers assume that a “2-hour response time” means the problem will be fixed within 2 hours. Providers understand it as: “we will respond within 2 hours”. If you do not define both metrics separately, you will only discover the difference during an outage.

Scope of services and exclusions , what exactly are you buying?

The first and most important section of an SLA is a precise description of what the provider is expected to do , and what it is not expected to do.

A lack of clarity about the scope leads to a classic dispute: the customer says, “consulting was included in the price”, while the provider replies, “it was not”. Such conflicts escalate quickly and end either in court or with the relationship being terminated.

What the scope description should include

1. List of services covered by the SLA , hosting, monitoring, helpdesk support, application maintenance, backups and security updates.
2. Exclusions , what is not covered by the agreement (e.g. development of new features, user training or integrations with third-party systems).
3. Support hours , whether the provider responds 24/7 or only during business hours (8:00 a.m.-6:00 p.m. on business days).
4. Boundary conditions , e.g. maximum number of users, data volume or number of reports per month.
5. Change management procedure , rules for modifying the scope of services during the term of the agreement, protecting against scope creep (the uncontrolled expansion of the scope).

The provider is not liable for areas that have not been contractually entrusted to it. Therefore, every service you expect must be reflected in the SLA. If something is not included , you have no grounds for making a claim.

Contact us , we will review your agreements with IT providers and identify any missing provisions.

SLA metrics that really matter

99.5% uptime sounds great , until you calculate that it amounts to almost 44 hours of downtime per year. Can your e-commerce business survive 44 hours without sales?

How to interpret availability figures

On the Polish hosting market, the lowest level generally offered is annual availability above 99%. For business services, the standard is 99.9% or higher. Data centres and network infrastructure providers compete at the 99.95-99.99% level.

But the uptime figure alone is not enough. Check how the provider measures availability. If only “business hours” (8:00 a.m.-6:00 p.m.) are measured, overnight outages , when batch processes, synchronisations or data imports are running , are not included in the statistics. The definition of “uptime” must be unambiguous.

Issue priorities and response/resolution times

Not every outage is the same. An SLA should define several priority levels with different response and resolution times.

The values in the table are examples , your metrics should be based on an analysis of which systems are critical to your company and how much their downtime costs. The scale of the risk is different when an e-commerce payment system fails on Black Friday than when an internal reporting tool fails.

Polish case law shows that major service contracts use response times of around 4 hours for critical failures, with a resolution time of 24 hours for critical failures and 48 hours for non-critical failures (case I ACa 1219/15, Court of Appeal in Kraków , service contract worth USD 208,594).

Issue-reporting procedure , when does the clock start?

Even the best SLA metrics are worthless if you do not know when the response time starts running.

Does it start when an email is sent? When receipt of the report is confirmed? When a ticket is opened in the system? If you do not specify this, every minute will become a matter of dispute during a crisis.

What the issue-reporting procedure must cover

1. Reporting channels , which forms of contact are permitted (ticketing system, email, telephone, messenger). Determine which channel is binding , if an email report does not automatically open a ticket, the response clock may not start.
2. Report format , what information a report must contain (description of the problem, priority, environment, screenshots and logs).
3. When the clock starts , e.g. when the system confirms receipt of the ticket, rather than when the customer sends an email.
4. Support hours , whether response time is measured in business hours or calendar hours. With 8/5 support, a report submitted at 5:00 p.m. on Friday will not start “ticking” until 8:00 a.m. on Monday.
5. Escalation , who is responsible for communication on the customer’s and provider’s side, what the lines of support are, the rules for substitution and presumptions of authority.

The responsibility matrix should cover: reporting an issue, assigning a category, approving the fix, as well as allocating project roles and support lines with a clear division of responsibilities. Supplementing these provisions with the consequences of non-performance (e.g. automatic escalation to a higher priority once the time limit has expired) creates a complete operational procedure.

Contractual penalties and service credits , how to motivate the provider without derailing negotiations

This section generates the most tension during negotiations. The provider does not want to sign an SLA containing penalties. The customer does not want an SLA without penalties. How can you strike the right balance?

Model 1: traditional contractual penalties (Articles 483-484 of the Civil Code)

Contractual penalties in SLAs are most commonly defined as a percentage of the provider’s fee for each commenced hour or day during which a defect remains unresolved. The penalty for higher-category defects is usually higher.

Polish case law provides specific ranges:

What to avoid:

1. Penalties for monetary obligations , Article 483 § 1 of the Civil Code permits penalties only for non-monetary obligations. Case XIII GC 1553/15: a provision allowing the provider to retain its right to payment despite suspending services following a payment delay was deemed an impermissible penalty for a monetary obligation.
2. Combining penalties for delay and withdrawal , case XIV C 1579/21: the court held that after withdrawing from the agreement, the creditor may claim only the withdrawal penalty and may not combine it with a penalty for delay relating to the same obligation.
3. Lack of precision , case VIII Ga 92/19: the penalty was deemed ineffective because the agreement did not specify the particular breaches for which it was payable.

Reduction by the court: under Article 484 § 2 of the Civil Code, the court may reduce a penalty if the obligation has been substantially performed or the penalty is grossly excessive. Penalties exceeding the value of the provider’s fee are regarded as grossly excessive in case law. However, the court cannot cancel the penalty entirely , it may only reduce it.

Model 2: service credits (fee reductions)

An alternative to traditional penalties , a structure in which the provider reduces the fee for a given billing period in proportion to system unavailability. This model is used by global cloud providers (AWS, Azure, GCP).

Recommendation: consider a hybrid model , service credits for routine breaches of service metrics (e.g. uptime below the threshold) and contractual penalties for serious breaches (e.g. data loss, breach of confidentiality or failure to respond to a security incident).

Once a specified cap on penalties has been reached (e.g. 30% of the annual fee), the customer should have the right to terminate the agreement , an accumulation of problems at this level means that the provider is unable to fulfil its obligations.

Data security and the GDPR in an SLA , what must be included and what should not be duplicated

Relationship between the SLA and the Data Processing Agreement (DPA)

Article 28 of the GDPR requires you to enter into a separate Data Processing Agreement with every IT provider that processes personal data on your behalf. The question is: must the SLA duplicate the DPA provisions?

No. The GDPR does not require the content of the DPA to be duplicated in the SLA. Duplicating provisions is actually counterproductive , it increases the risk of conflicts, makes change management more difficult and may lead to discrepancies in interpretation.

Recommended model:

1. Main agreement , general terms and conditions of the relationship.
2. DPA , a separate appendix containing the full set of elements required by Article 28(3) of the GDPR.
3. SLA , a separate technical appendix that operationalises the security requirements set out in the DPA.
4. Precedence clause , in the event of a conflict between the DPA and the SLA concerning data protection, the provisions of the DPA take precedence.

What an SLA should specify in the context of security

1. RPO and RTO metrics , how much data you can lose and how quickly the service must be restored after a failure.
2. Incident notification procedure , the provider must inform you of a security breach within 24 hours of detecting it. Why? Because Article 33 of the GDPR gives you, as the controller, 72 hours to report the breach to the Polish Data Protection Authority. If the provider informs you after 5 days , you will miss the deadline.
3. Cryptographic standards , requirements concerning the encryption of data at rest and in transit.
4. Frequency of security testing , e.g. penetration tests once per quarter and backup restoration tests once per month.
5. Duty to cooperate in an investigation , the provider must make logs and diagnostic data available and provide technical support in the event of an incident.

The Polish Data Protection Authority’s decision concerning the Sułkowice Cultural Centre shows that even a fine of PLN 2,500 may be imposed for entrusting data processing without a written Data Processing Agreement and without verifying the processor’s guarantees. The Polish Data Protection Authority also emphasises that the controller must verify the processor not only before entering into the agreement but throughout the entire relationship , which means that the SLA should provide for a right to audit.

The impact of NIS2 and the AI Act on SLA requirements

Two new EU regulations are changing the function of an SLA , from a technical and operational document into an instrument for complying with public-law obligations.

NIS2 , supply chain security

The NIS2 Directive (2022/2555), implemented in Poland through an amendment to the Act on the National Cybersecurity System (KSC), covers entities in sectors such as energy, transport, banking, healthcare, digital infrastructure and digital service providers. As a rule, it applies to medium-sized and large enterprises (≥50 employees, annual turnover >EUR 10 million).

NIS2 expressly requires risk-management measures to cover supply chain security , including relationships with ICT service providers. For an SLA, this means that the following must be added:

1. The provider’s obligation to maintain a specified level of security , with reference to ISO/IEC 27001 standards or KSC requirements.
2. The obligation to report incidents without delay , compatible with the 24/72-hour reporting regime (24h for an early warning to the CSIRT, 72h for a full report).
3. Rules governing the use of subcontractors , the obligation to obtain the customer’s consent to subcontractors and extend security requirements to the entire chain.
4. The customer’s right to conduct security audits of the provider.
5. RPO and RTO metrics, restoration testing and log retention.
6. Exit mechanisms in the event of serious security breaches.

Responsibility for reporting incidents rests with the entity subject to NIS2 , regardless of whether the incident concerns its own infrastructure or infrastructure managed by an external provider. The amendment to the KSC also introduces direct personal liability of the entity’s management for compliance with cybersecurity obligations.

AI Act , obligations concerning high-risk systems

If you use an AI system for recruitment, employee performance assessment, work scheduling or employee monitoring , that system is expressly classified as high-risk (Annex III to the AI Act). An SLA with the provider of such a system must cover:

1. The obligation to provide complete technical documentation and instructions for use.
2. Notification of updates that may affect compliance with the regulation.
3. Provision of the information necessary to conduct a DPIA (Data Protection Impact Assessment).
4. Metrics concerning human oversight of the system’s decisions.

Fines for breaches of the AI Act may reach up to EUR 35 million or 7% of annual turnover for prohibited practices and up to EUR 15 million or 3% of turnover for breaches of the requirements applicable to high-risk systems.

Intellectual property rights in an SLA , who owns the code?

As part of the support service, the provider’s developer writes a custom script that solves your problem. After the agreement ends, the provider says: “this code belongs to us”. You are left with a gap in your system.

The absence of an IP clause in an SLA creates a risk of losing access to technology assets that were created with your involvement and at your request.

What to agree in an SLA concerning IP rights

1. Assignment of copyright or a licence , decide whether you want a full assignment of the economic copyright in the code, documentation and configurations created under the SLA, or whether a licence is sufficient. An assignment gives you full control. A licence is cheaper but limits your options.
2. Fields of exploitation , if it is a licence, specify the permitted fields: use, modification, sublicensing and distribution.
3. Time of assignment , whether the rights are transferred when the work is created, when payment is made or when the work is accepted.
4. Source code , whether the provider makes the source code available or only the compiled version. Without the source code, you will not be able to maintain or develop the solution independently after the relationship ends.
5. Pre-existing materials , the provider contributes its own libraries, frameworks and tools to the project. Establish what remains the provider’s property (and on what terms you may use it) and what becomes your property.

Exit and transition clauses , how to change providers safely

An SLA was signed 3 years ago for 50 users. The company has grown to 500. The metrics remain the same. The provider cannot keep up, but formally complies with the provisions. You want to change providers , but you do not know how to migrate without losing continuity.

Elements of an exit clause that your SLA must include

Sector-specific regulations increasingly require these provisions. DORA (Digital Operational Resilience Act) requires financial-sector agreements with ICT providers to contain detailed exit clauses (Articles 28-30, applicable from 17 January 2025). The Data Act (Article 25) introduces a ban on charging fees for data migration after 12 January 2027.

Even if your company is not subject to DORA or the Data Act , these regulations indicate the direction in which the market is moving. Providers that obstruct migration lose customers.

Checklist before signing an SLA

Before signing an SLA, check the following points:

Customer’s perspective:

1. The scope of services matches the business requirements , nothing has been omitted.
2. The SLA metrics (uptime, response times and resolution times) are measurable and verifiable.
3. The issue-reporting procedure is clear , you know when the response clock starts.
4. Contractual penalties or service credits are properly calibrated , they motivate the provider without derailing negotiations.
5. Liability caps are proportionate to the risk , not too low (offering no protection) and not too high (the provider will not sign).
6. IP rights to the code and documentation are regulated , you know what belongs to you after the relationship ends.
7. The DPA is a separate document, consistent with the SLA and containing a precedence clause.
8. The security incident notification procedure is compatible with the GDPR’s 72-hour deadline.
9. The exit clause provides for a transition period, a duty to cooperate and data exports in open formats.
10. The review clause ensures that the metrics are reviewed every 6-12 months.

Provider’s perspective:

1. The scope of obligations reflects your actual capabilities , you are not promising more than you can deliver.
2. The financial risk is quantifiable , penalties do not exceed the value of the fee.
3. The schedule and budget are consistent with the scope of services.
4. Exclusions of liability cover force majeure, zero-day vulnerabilities and the customer’s failure to cooperate.

We can help you with this

Preparing an SLA that genuinely protects your business requires combining legal expertise with an understanding of how a technology company operates. Copying a template from the internet is not enough , every SLA must reflect the specific nature of your service, the scale of your operations and your risk profile.

At Sawaryn & Partners, we combine contract law with expertise in IT, AI and data protection. We work with founders, CTOs and product leaders , we understand how technology teams operate and what a system outage at 10:00 a.m. on Black Friday means.

Our support includes:

1. Auditing existing agreements with IT providers , identifying gaps in SLAs, missing metrics and ineffective penalty clauses.
2. Preparing or renegotiating SLAs , from defining the scope of services, metrics and penalties to security, IP and exit clauses.
3. Ensuring consistency between the SLA, DPA and regulations , verifying compliance with the GDPR, NIS2, the AI Act and sector-specific regulations.
4. Support in negotiations with providers , we deliver ready-to-use negotiation options instead of theoretical analyses.

When an SLA determines whether a company survives

A well-drafted SLA is not a document “for the filing cabinet”. It is a tool you activate in a crisis , when the system goes down, data is leaked or the provider stops answering the phone. Every element of an SLA , from the definition of uptime and the issue-reporting procedure to the exit clause , answers one question: what do you do when something goes wrong?

If your current agreements with IT providers do not contain measurable metrics, clear penalties and outage procedures , now is the time to change that. The cost of preparing a good SLA is a fraction of the losses caused by a single serious outage.

Do you need support with an audit of your IT agreements, preparing an SLA or negotiating with providers? Contact us.

Frequently asked questions

How does an SLA differ from the main agreement , is it a separate document?
An SLA may be either a separate document or an appendix to the main agreement. The recommended model consists of three separate documents: the main agreement (general terms and conditions of the relationship), the DPA (Data Processing Agreement) and the SLA (technical service metrics). This structure makes change management easier , you can update the SLA metrics without renegotiating the entire agreement.

How can you set realistic contractual penalties that motivate the provider without derailing negotiations?
Polish case law shows that penalties ranging from 0.1-0.5% of the fee for each day of delay are accepted. Penalties exceeding the value of the provider’s fee may be reduced by the court as grossly excessive (Article 484 § 2 of the Civil Code). Consider a hybrid model: service credits for routine breaches of service metrics and contractual penalties for serious breaches (data loss or breach of confidentiality). Also set an aggregate cap on penalties , once it is exceeded, you have the right to terminate the agreement.

What should you do when the provider says, “we will not sign an SLA with penalties”?
Propose a service credit model instead of traditional contractual penalties. Under this model, the provider reduces its fee for the period of unavailability , this is not a contractual penalty within the meaning of Article 483 of the Civil Code, so it is not subject to reduction by the court. Providers accept this model more readily because the financial risk is limited to the value of the subscription fee. If the provider refuses to accept any form of liability for service metrics , consider changing providers.

Does the SLA have to cover the GDPR if I have a separate Data Processing Agreement (DPA)?
The SLA should not duplicate the DPA provisions , this increases the risk of conflicts. However, the SLA should operationalise the security requirements set out in the DPA: it should define RPO and RTO metrics, the incident notification procedure (no more than 24h from detection, so that you can report it to the Polish Data Protection Authority within 72h), encryption standards and the frequency of security testing. In the event of a conflict between the SLA and the DPA , the provisions of the DPA take precedence.

How can I measure whether the provider is genuinely meeting the SLA , should I have my own monitoring?
Yes , relying solely on the provider’s reports is risky. Implement independent monitoring of service availability and performance. A monthly SLA report should automatically compare the provider’s data with your measurements and flag discrepancies. Link the SLA report to the payment process , if the metrics are not met, the service credit or escalation procedure is triggered.

Can I terminate the SLA unilaterally if the provider repeatedly fails to meet the metrics?
That depends on the provisions of the agreement. Recommendation: include a clause giving you the right to terminate once a specified aggregate penalty cap has been reached or after a specified number of metric breaches within a given period (e.g. 3 P1 breaches in a quarter). Without such a clause, you must rely on the general provisions of the Civil Code concerning termination of a contract for services or termination by mutual agreement , which is slower and less predictable.