Contract TemplateClickwrap Agreements

Service Level Agreement (SLA)
Template — South Africa

An attorney-drafted Service Level Agreement (SLA) template designed specifically for South African businesses. This comprehensive, legally compliant document defines measurable performance standards, uptime guarantees, support response and resolution times, service credit remedies, escalation procedures, and maintenance windows — transforming vague service promises into enforceable contractual obligations under South African common law of contract, the Consumer Protection Act 68 of 2008, the Electronic Communications and Transactions Act 25 of 2002, and the Protection of Personal Information Act 4 of 2013. Built for cloud and SaaS providers, managed IT service companies, facilities management firms, outsourced service providers, and any business that commits to measurable service delivery standards.

Drafted by qualified South African attorneys

Reviewed for compliance with current legislation · Last updated April 2026

Why It Matters

Why Your Business Needs This Agreement

No Measurable Service Standards — Subjective "Best Efforts" Commitments

Service agreements that promise "best efforts" or "reasonable" service quality without measurable targets create inevitable disputes. The provider believes they are delivering good service; the customer disagrees. Without objective metrics, there is no way to determine who is right. Litigation over subjective service standards is expensive, unpredictable, and rarely satisfactory for either party. An SLA replaces subjective promises with measurable commitments — uptime percentages, response times, resolution targets — that can be objectively assessed against monitoring data.

Service Credit Provisions Structured as Unenforceable Penalties

Service credits that are disproportionately large relative to the customer's actual loss from underperformance risk being reduced or struck down under the Conventional Penalties Act 15 of 1962. Conversely, credits that are negligibly small relative to the monthly fee (such as a 2% credit for a major outage) provide no meaningful accountability. The credit structure must be calibrated to represent a genuine pre-estimate of the customer's loss — proportionate enough to incentivise the provider, defensible enough to survive a legal challenge, and commercially meaningful enough to provide the customer with a real remedy.

Excessively Broad Exclusions That Gut the SLA

Providers who exclude too many events from SLA calculations — load shedding, upstream ISP failures, "third-party" issues, "unforeseen circumstances," and vaguely defined force majeure events — effectively render the SLA meaningless. If the majority of outage events fall within exclusions, the uptime commitment is aspirational rather than enforceable. Exclusions must be narrowly drafted, specifically defined, and genuinely outside the provider's control. The customer should negotiate for exclusions to be limited to events that the provider demonstrably could not have prevented or mitigated through reasonable infrastructure investment.

No Escalation Path for Persistent Underperformance

SLAs that provide service credits as the sole remedy — without any escalation to termination rights for persistent failure — trap the customer in a relationship with an underperforming provider. The customer receives monthly credits but cannot exit the contract without paying early termination fees. This creates a perverse incentive: the provider can repeatedly miss targets, pay credits, and still retain the customer's business. A well-drafted SLA includes a termination trigger for persistent failure — allowing the customer to exit without penalty when the provider has demonstrated a consistent inability to meet committed service levels.

No POPIA Framework for Data Processing Within the Service

Service providers who process personal information on behalf of their customers without a POPIA-compliant operator agreement are exposing both parties to regulatory risk. The customer (as responsible party) is liable to the Information Regulator for the provider's data handling practices — and without a written agreement specifying processing conditions, security measures, breach notification procedures, and data return/destruction obligations, the customer cannot demonstrate POPIA compliance. The SLA must include or reference a POPIA-compliant data processing framework.

Load Shedding Not Addressed — Uniquely South African Risk

SLAs drafted from international templates do not address Eskom load shedding — a uniquely South African operational risk that materially affects service availability. Without explicit load shedding provisions, disputes arise over whether load shedding constitutes force majeure, whether the provider's backup power was adequate, and whether load shedding-related downtime counts against availability targets. South African SLAs must specifically address load shedding, backup power requirements, and the SLA treatment of grid instability.

What is a Service Level Agreement (SLA)?

A Service Level Agreement transforms the inherently subjective concept of "good service" into objective, measurable, and enforceable contractual commitments. Without an SLA, service delivery disputes are resolved by reference to vague standards — what is "reasonable," what constitutes "acceptable" performance, and what the customer's "expectations" were. These subjective standards are expensive to litigate and produce unpredictable outcomes. An SLA eliminates this uncertainty by defining precisely what the service provider commits to deliver, how performance is measured, what happens when targets are missed, and how disputes about service quality are resolved.

Under South African common law of contract, an SLA is a legally binding agreement that creates enforceable obligations on both parties. The service provider commits to meeting specified performance targets, and the customer commits to paying the agreed fees and fulfilling any customer-side obligations (such as providing access, infrastructure, or information). If the service provider fails to meet the agreed performance levels, the SLA specifies the remedies — typically service credits (a reduction in the monthly fee proportional to the shortfall), which serve as agreed pre-determined damages rather than penalties. This distinction is critical under South African law because penalty clauses — provisions that impose a punishment disproportionate to the actual loss suffered — are unenforceable under the Conventional Penalties Act 15 of 1962 unless the creditor can prove actual loss. Service credits structured as genuine pre-estimates of the customer's loss for underperformance are enforceable as liquidated damages.

The Consumer Protection Act 68 of 2008 (CPA) applies where the customer qualifies as a "consumer" under the Act. Section 54 requires that services be performed in a manner and quality that persons are generally entitled to expect — the SLA defines what this "expected" quality is in measurable terms. Section 54(2)(a) requires performance with reasonable care and skill, Section 54(2)(b) requires that services be fit for the purpose communicated to the supplier, and Section 54(2)(c) requires performance of a quality generally expected. The SLA provides the specific, agreed standards against which CPA compliance is measured. Where the customer is not a consumer under the CPA (for example, a large enterprise), the SLA is governed by common law principles of contract and breach.

For technology service providers, the Electronic Communications and Transactions Act 25 of 2002 (ECTA) is relevant in several ways. ECTA's safe harbour provisions (Sections 46-49) may provide limited liability protection for service providers in specific circumstances — but only if the provider meets certain conditions, which the SLA can codify. ECTA also provides the legal framework for electronic service delivery, electronic communications between the parties, and automated monitoring and reporting systems used to measure SLA performance.

The Protection of Personal Information Act 4 of 2013 (POPIA) intersects with SLAs wherever the service provider processes personal information on behalf of the customer. Under POPIA Sections 20-21, the customer (as "responsible party") must have a written agreement with the service provider (as "operator") that addresses processing conditions, security measures, breach notification, and data return/destruction. The SLA should either include these POPIA provisions or reference a separate data processing agreement.

This attorney-drafted template is compliant with South African common law of contract, the Conventional Penalties Act 15 of 1962, the Consumer Protection Act 68 of 2008, the Electronic Communications and Transactions Act 25 of 2002, and the Protection of Personal Information Act 4 of 2013. It is designed to be used as a schedule or addendum to a master service agreement, providing the measurable performance framework that the commercial agreement references.

Who Needs This

Cloud hosting providers, data centre operators, and infrastructure-as-a-service (IaaS) providers committing to uptime, performance, and availability guarantees
SaaS companies defining service availability, response times, data backup, and disaster recovery commitments for their customers
Managed IT service providers (MSPs) with ongoing support contracts covering helpdesk, network management, and systems administration
Telecommunications providers committing to network availability, latency, bandwidth, and fault resolution targets
Facilities management and maintenance companies defining response times, preventive maintenance schedules, and service quality standards
Outsourced customer service and call centre operators committing to answer rates, wait times, resolution rates, and customer satisfaction targets
Professional services firms defining project delivery timelines, milestone commitments, and quality standards for consulting engagements
Any service provider wanting to formalise performance commitments, create accountability mechanisms, and differentiate through measurable service quality

Want early access to the Service Level Agreement (SLA) template?

We'll email you the moment early access opens

Under the Conventional Penalties Act 15 of 1962, SLA service credits structured as penalties (disproportionate to actual loss) can be reduced by a court — credits must represent genuine pre-estimates of the customer's loss

CPA Section 54 requires services to be performed with reasonable care and skill — the SLA defines what "reasonable" means in measurable terms for consumer relationships

Load shedding is a uniquely South African SLA consideration — international templates do not address grid instability, backup power requirements, or availability calculation treatment

POPIA Sections 20-21 require a written operator agreement wherever the service provider processes personal information on behalf of the customer — the SLA should include or reference this agreement

Each additional "nine" in an uptime commitment significantly increases infrastructure costs: 99.9% (43.8 minutes downtime/month) is standard; 99.99% (4.3 minutes/month) requires fully redundant active-active infrastructure

Template Contents

Key Clauses Included

This Service Level Agreement (SLA) template covers 13 essential sections, each drafted by South African attorneys.

01

Service Definitions, Scope & Boundaries

Precisely defines the services covered by the SLA — distinguishing between core services (fully covered by SLA commitments), ancillary services (best-effort, no SLA commitments), and excluded services (explicitly outside the SLA's scope). This section prevents scope disputes by specifying what is and is not covered, the relationship between the SLA and the underlying master service agreement, and the hierarchy of documents in case of conflict. It also addresses multi-service SLAs where different services have different performance targets, and the treatment of new services added during the agreement term.

02

Performance Metrics, KPIs & Targets

Defines specific, measurable key performance indicators (KPIs) with quantitative targets. Common metrics include: availability/uptime percentage (99.5%, 99.9%, 99.99%), response time (time from incident report to first response — measured in minutes or hours by severity level), resolution time (time from incident report to full resolution — measured in hours by severity level), throughput (transactions per second, API calls per minute), error rates (percentage of failed requests), latency (millisecond response time for API calls or page loads), backup frequency and recovery time objectives (RTO/RPO), and customer satisfaction scores (CSAT, NPS). Each metric has a defined measurement methodology, data source, and calculation formula to eliminate disputes over whether targets were met.

03

Severity Classification & Prioritisation

Establishes a severity classification system that determines the response and resolution time commitments for different types of incidents. Typical classifications include: Severity 1 (Critical — service completely unavailable or major functionality impaired, affecting all users), Severity 2 (Major — significant functionality degraded, workaround may be available, affecting multiple users), Severity 3 (Moderate — minor functionality issue, workaround available, limited impact), and Severity 4 (Low — cosmetic issue, enhancement request, no operational impact). The classification criteria, escalation triggers, and examples for each severity level are defined to prevent disputes over incident categorisation.

04

Measurement, Monitoring & Reporting

Specifies how performance is measured and reported. Addresses: the monitoring tools and systems used (Nagios, Datadog, custom dashboards, third-party monitoring services), the measurement intervals (real-time, hourly, daily), the calculation methodology for each metric (including which events are excluded from calculations — see exclusions), the reporting frequency (monthly reports with additional real-time dashboard access), the report format and content (actual vs target, trend analysis, incident summaries), and the process for the customer to challenge or dispute reported metrics. Transparency in measurement is critical — if the provider controls the measurement tools, the customer should have audit rights or independent verification capability.

05

Service Credits & Remedies

Defines the financial remedies when SLA targets are not met. Service credits are structured as genuine pre-estimates of the customer's loss for underperformance — not penalties, which are unenforceable under the Conventional Penalties Act 15 of 1962 unless actual loss is proved. The section specifies: the credit calculation formula for each metric (typically a percentage of the monthly fee based on the magnitude of the shortfall), the maximum credit cap per billing period (typically 20% to 30% of the monthly fee — the provider is not expected to provide services for free), the credit request process and timeline, how credits are applied (offset against future invoices, not cash refunds unless the agreement terminates), and whether credits are the customer's sole and exclusive remedy for SLA breaches or whether they can claim additional damages.

06

Escalation Procedures & Contact Matrix

Establishes a structured escalation framework for service issues — ensuring that unresolved incidents are escalated to progressively senior levels of management on both sides. The escalation matrix includes: the escalation triggers (elapsed time without resolution, severity level, business impact), the designated contacts at each escalation level (names, titles, phone numbers, email addresses) for both the provider and the customer, the response time requirement at each level, and the process for escalating to executive management. For critical (Severity 1) incidents, the section specifies real-time communication requirements — conference calls, incident war rooms, and continuous status updates until resolution.

07

Scheduled Maintenance Windows

Defines when the service provider may perform scheduled maintenance on its infrastructure, and the impact on SLA calculations. Covers: the standard maintenance window (typically Sunday 02:00-06:00 SAST), the advance notice requirements for scheduled maintenance (48 to 72 hours), the maximum permitted maintenance hours per month, emergency maintenance procedures (shorter notice period with executive approval), and critically — whether downtime during scheduled maintenance windows is excluded from availability calculations. The section also addresses the provider's obligation to minimise the impact of maintenance through rolling upgrades, redundant systems, and non-disruptive deployment practices.

08

SLA Exclusions & Force Majeure

Defines events that do not count against SLA metrics — the circumstances where the provider is excused from meeting performance targets. Common exclusions include: force majeure events (natural disasters, civil unrest, government action — see Section 67 of the CPA for force majeure in consumer agreements), customer-caused incidents (misconfiguration, unauthorised changes, insufficient resources), third-party service failures outside the provider's control (upstream ISP outage, DNS provider failure), pre-approved scheduled maintenance, and periods where the customer was notified of a potential impact but chose not to take recommended action. Exclusions must be narrowly drafted to prevent abuse — a provider who excludes too many events effectively guts the SLA.

09

Data Protection, POPIA & Security

Where the service provider processes personal information on behalf of the customer, this section establishes the POPIA compliance framework required by Sections 20-21. Addresses: the processing purposes and limitations, the security measures the provider must implement (aligned with POPIA Section 19 — encryption, access controls, regular assessments), data breach notification obligations (POPIA Section 22 requires notification "as soon as reasonably possible"), data location and cross-border transfer restrictions, data return and destruction upon termination, and the provider's obligation to assist the customer with data subject requests. This section can reference a separate data processing agreement if the POPIA provisions are extensive.

10

Disaster Recovery & Business Continuity

Defines the service provider's disaster recovery and business continuity commitments — the Recovery Time Objective (RTO, the maximum acceptable time to restore service after a disaster), the Recovery Point Objective (RPO, the maximum acceptable data loss measured in time — e.g., "last 4 hours" means up to 4 hours of data may be lost), backup frequency and testing procedures, geographic redundancy (whether backups are maintained in a separate data centre or region), the disaster recovery testing schedule (typically bi-annually with customer participation), and the communication procedures during a disaster event.

11

Continuous Improvement & SLA Review

Establishes the process for reviewing and evolving the SLA over time. Covers: the review frequency (quarterly operational reviews, annual strategic reviews), performance trending analysis (identifying systemic issues rather than isolated incidents), the process for adjusting KPI targets (both tightening and relaxing, by mutual agreement), the introduction of new metrics as the service matures, benchmarking against industry standards, and the continuous improvement commitments that the provider makes — such as conducting root cause analysis for every Severity 1 incident and implementing preventive measures.

12

Termination Rights & Persistent SLA Failure

Defines the customer's right to terminate the underlying service agreement if the SLA is persistently breached — going beyond the credit remedy for individual failures. Typical triggers include: maximum credits reached in consecutive months (e.g., credits at the cap for 3 consecutive months), a specified number of Severity 1 incidents within a rolling period, or a consistent pattern of underperformance that demonstrates the provider cannot meet the committed service levels. The section specifies the termination notice period, whether termination fees are waived for SLA-driven termination, and the provider's obligations during the transition to a replacement provider.

13

Dispute Resolution & Governing Law

Establishes that the SLA and the underlying service agreement are governed by the laws of the Republic of South Africa. For SLA-specific disputes (measurement methodology, credit calculations, exclusion applicability), the section provides for expedited technical review by designated senior technical representatives from both parties. For broader disputes, the process escalates from negotiation to mediation under AFSA rules to binding arbitration. Arbitration is preferred for technology disputes because arbitrators with technical expertise can be appointed, proceedings are confidential, and resolution is typically faster than litigation.

Legal Compliance

South African Law Compliance

Common Law

South African Common Law of Contract

SLAs are governed by the common law of contract, which establishes the fundamental principles of formation, performance, breach, and remedies. The key principles for SLAs include: pacta sunt servanda (agreements must be honoured), the right to specific performance (the customer can demand the provider deliver the agreed service levels, not merely pay credits), the right to cancel for material breach (persistent SLA failure may constitute a material breach justifying termination under BK Tooling principles), and the rules governing agreed damages clauses (service credits are enforceable as liquidated damages if they represent a genuine pre-estimate of loss, but unenforceable as penalties if they are disproportionate to the actual harm).

Conventional Penalties Act

Conventional Penalties Act 15 of 1962

This Act directly impacts how service credits and SLA remedies must be structured. Under the Act, a "penalty stipulation" — a contractual provision that specifies a pre-determined amount payable upon breach — is enforceable, but the court may reduce the penalty if it is out of proportion to the prejudice suffered. The Act applies to service credit provisions if they are characterised as penalties rather than genuine pre-estimates of loss. To ensure enforceability, service credits should be structured as liquidated damages (reflecting the customer's actual estimated loss from underperformance) rather than punitive penalties. The credit calculation methodology should be transparently linked to the commercial impact of the service shortfall — for example, tying credits to the percentage of availability lost multiplied by the monthly fee.

CPA

Consumer Protection Act 68 of 2008

The CPA applies where the customer qualifies as a "consumer" — generally, any natural person or juristic person with annual turnover below the threshold (currently R2 million for most categories). Section 54 requires services to be performed with reasonable care and skill (54(2)(a)), to be fit for the communicated purpose (54(2)(b)), and to be of a quality generally expected (54(2)(c)). The SLA defines these standards in measurable terms. Section 48 prohibits unfair terms — an SLA that provides inadequate remedies or excessively broad exclusions may be challenged. Section 49 requires limitation of liability provisions to be brought to the consumer's attention conspicuously. Section 14 allows the customer to cancel a fixed-term SLA with 20 business days' notice (subject to a reasonable penalty). These CPA provisions must be reflected in the SLA's remedies, exclusions, and termination sections.

ECTA

Electronic Communications and Transactions Act 25 of 2002

ECTA provides the legal framework for electronic service delivery and communications between the parties. Section 11 establishes the legal validity of data messages (including automated SLA monitoring alerts, incident notifications, and performance reports). ECTA's safe harbour provisions (Sections 46-49) may provide limited liability protection for certain categories of service providers — mere conduits, caching services, hosting services, and information location tools. These safe harbours may modify the provider's liability for specific types of service failures and should be considered when drafting the SLA's exclusions. Section 43 disclosure requirements apply if the SLA is part of an e-commerce transaction.

POPIA

Protection of Personal Information Act 4 of 2013

Where the service provider processes personal information on behalf of the customer, POPIA Sections 20-21 require a written agreement addressing processing conditions, security measures, and data subject rights. Section 19 requires appropriate technical and organisational security measures — which the SLA should specify (encryption standards, access controls, audit frequencies). Section 22 requires data breach notification "as soon as reasonably possible" — the SLA should define what "reasonably possible" means in the service context (typically within specific hours of discovery). Section 72 restricts cross-border data transfers — relevant where the service provider uses international infrastructure or cloud services. The SLA's data protection provisions ensure POPIA compliance for the processing activities within the service scope.

South African businesses are lining up for My-Contracts — be first in when we launch

POPIA CompliantLegally ReviewedDigital Signing Available
Simple Process

Create Your Service Level Agreement (SLA) in Minutes

Our guided wizard walks you through every clause — no legal knowledge required. Attorney-drafted, South African law compliant.

01

Define the services covered and the appropriate metrics

Identify the specific services that the SLA will cover and determine the most meaningful performance metrics for each. For cloud/hosting services, the primary metric is availability (uptime percentage). For support services, response and resolution times by severity level. For transaction processing, throughput and error rates. For data services, backup frequency and recovery objectives (RTO/RPO). Engage both technical and business stakeholders to identify the metrics that matter most to the customer's operations.

02

Set realistic targets based on infrastructure capability

Set performance targets that the provider can realistically achieve with their current infrastructure and staffing levels. Over-committing (promising 99.99% uptime without redundant infrastructure) leads to persistent credits, damaged credibility, and customer termination. Under-committing (offering 99% uptime when 99.9% is achievable) fails to differentiate the provider and leaves the customer inadequately protected. Review historical performance data, benchmark against industry standards, and factor in South African-specific considerations like load shedding and ISP reliability.

03

Design the credit structure and escalation framework

Structure service credits as genuine pre-estimates of the customer's loss — not penalties. Link the credit percentage to the magnitude of the shortfall, cap credits at a commercially reasonable level (25-30% of the monthly fee), and define the credit request and application process. Design an escalation framework for persistent failure — including the termination trigger conditions, the notice period, and the transition assistance obligations.

04

Complete the template with monitoring, reporting, and POPIA provisions

Complete the template with your specific metrics, targets, exclusions, maintenance windows, monitoring tools, reporting frequency, escalation contacts, and POPIA data processing provisions. Ensure the measurement methodology is transparent and the customer has audit or verification rights. Address load shedding explicitly — specifying backup power requirements and the SLA treatment of grid-related downtime.

05

Review, execute, and implement monitoring

Review the completed SLA for internal consistency (do the credits, exclusions, and termination provisions work together coherently?), legal compliance (Conventional Penalties Act for credits, CPA for consumer customers, POPIA for data processing), and commercial fairness. Have both parties sign the SLA as a schedule to the master service agreement. Implement the monitoring infrastructure, configure automated alerting, and schedule the first performance review meeting.

Your Service Level Agreement (SLA) is ready
Common Questions

Frequently Asked Questions

A Service Level Agreement is a formal contractual document that defines the performance standards a service provider commits to meeting — transforming subjective expectations into objective, measurable, and enforceable commitments. It specifies what metrics will be measured (uptime, response time, resolution time), the target levels for each metric (99.9% availability, 15-minute response for critical incidents), how performance is measured (monitoring tools, calculation methodology), what happens when targets are missed (service credits), and the escalation procedures for service issues. Without an SLA, service disputes become arguments about what "good service" means — each party having different expectations with no objective standard to resolve the disagreement. Under South African common law, the SLA creates binding contractual obligations that can be enforced through specific performance or damages claims. For consumer relationships, the SLA also defines the "quality generally expected" under CPA Section 54.

Why This Template

What You Get With This Template

Drafted specifically for South African law — compliant with common law of contract, Conventional Penalties Act, CPA, ECTA, and POPIA

Service credit provisions structured as enforceable liquidated damages — not penalties at risk of reduction under the Conventional Penalties Act 15 of 1962

Severity classification system with differentiated response and resolution targets that reflect genuine business impact prioritisation

Narrowly drafted exclusions that protect the provider from genuinely uncontrollable events without gutting the SLA's accountability framework

Eskom load shedding provisions specifically addressing this uniquely South African risk — backup power requirements and SLA calculation treatment

POPIA-compliant data processing provisions for services involving personal information — security measures, breach notification, and data return/destruction

Persistent failure termination trigger that prevents customers from being trapped with underperforming providers — including transition assistance obligations

Customisable template with clearly marked fields for metrics, targets, credit percentages, maintenance windows, escalation contacts, and POPIA provisions

Be First to Draft Your Service Level Agreement (SLA)

Early access opens soon. Join the waiting list and we'll email you the moment it does.

One launch email — no spamFounding-member pricing