Why Service Level Management Is the Anchor Practice
Service level management defines the performance contract between provider and customer. Every other service management practice exists to deliver against SLA commitments. Without clear, agreed, and achievable SLAs, the entire Service Management System lacks direction and accountability. Weak SLAs—vague in scope, unrealistic in targets, or silent on customer obligations—undermine the entire SMS by creating misalignment between what the customer expects and what the service provider delivers. ISO 20000 requires that the SMS be designed and operated to achieve defined service level targets; this means SLAs are not optional, they are foundational.
What Makes a Good SLA
A good SLA is specific about what service is being provided, measurable in clear terms, achievable given the service provider's capability, agreed by both parties with mutual understanding, and subject to review and amendment as circumstances change. It must define not only the provider's obligations but also the customer's obligations (providing timely access, supplying required information for incident investigation, approving changes in advance). The SLA must include a breach handling mechanism—what happens when targets are not met—and a clear review schedule so that targets can be adjusted if circumstances change or if baseline performance data becomes available.
SLA Structure: Required Sections
An effective SLA includes: a service description defining what is included and what is explicitly excluded; service hours (24×7, business hours, or a specific schedule); an availability target with a precise definition of what "unavailable" means (is an SLA breach when a service is 99% functional or only when it is completely down?); performance targets for response time, resolution time, throughput, or other relevant metrics; a support model with incident priorities and resolution targets for each priority level; a documented process for changing the SLA (amendments must not be unilateral); a review schedule (typically annual or triggered by sustained breach); a penalty or credit regime if applicable (some organizations apply service credits; others track breach as reputational but not financial); and signed approval by authorized representatives of both the provider and the customer.
| KEY CONCEPT | The SLA is a bilateral agreement—both the provider and the customer have obligations. Customer obligations (providing access, timely approvals, information for incident investigation) must be documented alongside provider commitments, not buried in footnotes. |
SLO Versus SLA
The SLA is the agreement document. An SLO (Service Level Objective) is a specific, measurable target within the SLA. A single SLA may contain many SLOs. For example, an SLA for an email service might include an SLO for P1 incident resolution within 4 hours, an SLO for availability of 99.9% measured monthly, and an SLO for service report delivery by the 5th working day of each month. The organization typically has many SLOs per service, tracked in a dashboard, with real-time alerting when performance approaches or breaches the target.
Operational Level Agreements (OLAs): The Internal Layer
If an SLA commits to P1 resolution within 4 hours, the infrastructure team must respond to P1 escalations within 30 minutes to provide adequate headroom for diagnosis and fix. This internal commitment is documented in an OLA. OLAs align the internal teams supporting service delivery with the external SLA commitments. Without properly designed OLAs, SLA targets will be chronically missed because internal teams lack the required commitment. OLA design requires understanding the external SLA target, the typical diagnosis and remediation time for that service, and the time required for escalation and communication between teams.
Underpinning Contracts: Supplier Alignment
If the SLA commits to 99.9% availability but the data center UC (Underpinning Contract) only commits to 99.5%, there is a structural gap. The service can never achieve its SLA target if the underlying supplier does not support it. UC alignment review is a critical part of SLA design and ongoing SLA management. Before signing an SLA with a customer, verify that every external dependency (cloud provider SLA, third-party software vendor support, telecommunications carrier SLA) can support the external commitment.
SLA Target Setting: Common Mistakes
Targets set based on what the customer wants rather than what is achievable lead to chronic breach. No baseline data to inform target setting results in targets that are either unrealistically tight or wastefully loose. Identical targets for all priority levels without considering actual resolution capability creates bottlenecks on the higher-priority queue. Targets copied from previous contracts without reviewing current organizational capability ignores actual performance and creates immediate credibility damage. Sound target setting requires historical incident data (how long do P1s actually take to resolve?), capacity modeling (how many P1s can be resolved in parallel?), and honest assessment of what is achievable with current staffing, tools, and processes.
SLA Monitoring and the SLA Dashboard
Monitoring what to track: availability (percentage of time the service is accessible), incident resolution time (median and 95th percentile), change success rate, problem resolution time, and service request fulfillment time. Monitoring frequency: real-time for availability (automated alerting), daily or weekly for incident and change metrics. The SLA dashboard should show current period performance, trend line over the last 12 months, and projected month-end status. Automated alerting when SLA breach is imminent allows proactive intervention (e.g., emergency change approval, incident response prioritization) to prevent breach.
Monthly SLA Reporting
The monthly service report must contain: SLA performance against each SLO (actual vs. target, pass or fail), incident summary (volume by priority, average resolution time, top incident categories), changes implemented and their outcomes, open problems affecting the service, service improvement activity, and any SLA breaches with explanation and remediation plan. Format should be consistent month to month. Distribution to the customer is required; customer acknowledgment of receipt (not necessarily agreement with content) should be documented. The monthly report is required documented evidence for ISO 20000 audit—auditors will examine 3–6 months of reports to verify that SLA monitoring and reporting are consistent and real.
| IMPORTANT | SLA targets that are regularly breached signal either that targets are unrealistic or that service delivery capability is inadequate. Auditors will probe both. Sustained breach without corrective action is a nonconformity under Clause 5.2. |
SLA Breach Management
A breach occurs when a measured SLO falls short of its target. Breach identification should be automated (the SLA dashboard flags it). Breaches must be communicated to the customer (typically within 2 working days); the communication should explain what happened and what remedial action is planned. Investigation determines root cause (was the target unrealistic? did a system failure occur? was there unusual demand?). Breach response may include service credit (if applicable), prioritized problem investigation, or review and adjustment of the SLA target. Breaches must be reported in the monthly service report, not hidden. The breach-to-problem management linkage ensures that repeated breaches trigger deep investigation and permanent fix.
SLA Review Cadence
Formal SLA review occurs at defined intervals—typically annually or triggered by significant service changes, infrastructure upgrades, or sustained breach patterns. Review participants should include the service owner, the customer, and representatives from operations and support teams. During review, the organization assesses whether current targets are appropriate (achieved every month, rarely achieved, or approaching breach regularly), whether the service scope has changed (new integrations, new users, new usage patterns), and whether the OLAs and UCs still support the external commitment. Amendment outcomes are documented in the updated SLA; all parties re-sign; the effective date is recorded.
| BITLION INSIGHT | Bitlion GRC SLA management module automates SLO tracking, breach alerting, and generates monthly reporting templates with customer-ready formatting. Integration with incident and change management ensures that SLO data is populated in real-time from operational systems. |