Writing a Useful SLA: Severity Levels, Consequences and Project-Specific Targets

POLISH regards two things as the core of an SLA (service level agreement): how problems are graded by severity, and what happens when an agreed target is missed. Response and repair time limits are set per project, according to the system, its users and the budget, and are written into the contract, so this article gives no time limits. What follows covers the items worth writing into an SLA and the reason for each.

The difference between an SLA and an SLO is whether missing the target has a consequence

In its chapter on service level objectives, Google's Site Reliability Engineering distinguishes indicators (SLIs), objectives (SLOs) and agreements (SLAs). An SLA is an explicit or implicit contract with users that includes the consequences of meeting or missing the SLO, and the most recognizable consequence is a refund or a penalty (Jones et al., 2017). The test is to ask what happens when the SLO is missed. A target with no defined consequence is almost certainly an SLO.

If a contract lists only target values and says nothing about what happens when a target is missed, the clause is just an expectation on both sides, with nothing enforceable in it. The same chapter also advises against setting targets from current performance, keeping the wording simple, and avoiding absolute statements such as "always available."

The same page also notes that SRE teams generally do not take part in drafting SLAs, because an SLA is closely tied to business and product decisions. In public-sector procurement, the consequences and scope need to be decided jointly by the business unit and the procurement unit, and the development team's role is to explain what is feasible and where the limits lie.

Problems are graded by scope of impact, which sets the order of handling

When a report comes in, POLISH first determines the scope of impact and then sets the order of handling. The table below is a severity structure that can be adopted in a contract. The response and repair time limits for each level are filled in per project, and this article gives none.

Severity levels are also used to judge the nature of a notification. After a website redesign, old links saved by users are still visited, and search engine webmaster tools therefore send notices about pages not found. Such notices mostly come from legacy links, and a mistyped address is expected to return not found, so no immediate action is needed. Notices about page redirects are likewise left alone for now. When the project team forwards a query through the regular communication channel, POLISH writes the severity judgment and its reasons in the same reply, and the project team accepts it and takes no action for now.

When a system problem occurs, POLISH will assign staff to handle it immediately. The notification, grading, repair and reporting steps that follow are covered in Handling process when a system malfunctions.

Defect fixes and new requests are separated into two columns on the quotation

POLISH recommends that the quotation divide the work into two columns before signing. A defect fix means a function within the contract that does not work properly. A new requirement means an item beyond the contract scope, quoted separately. The definition of each column is checked against the contract scope and the acceptance items, and both parties confirm it before signing. Other pre-signing checks are covered in Evaluating a Software Vendor: A Scorecard and Pre-Contract Checklist.

With the two columns in place, every incoming report can be classified first. A defect fix enters the severity levels described in the previous section, and a new requirement is quoted first, with the agency deciding whether to include it. Opportunities beyond the agreed scope are explained to the project team by POLISH as proactive proposals and POCs, and the agency then decides; the approach is described in POC work beyond the agreed scope.

Why maintenance notices, backups and data ownership belong in the agreement

The items below are not part of responding to and repairing problems, yet these items decide whether the agency can arrange staff, restore data and change vendors. POLISH recommends spelling out each one in the contract, with frequencies and time limits set per project.

• Advance notice of scheduled maintenance: state who is notified and through which channel. Maintenance suspends or changes the service, so the agency needs to notify users beforehand and avoid event periods.
• Time limit for notifying security incidents: state the deadline by which the vendor notifies the agency, and what the notice contains. The agency has its own statutory reporting deadline, explained in the next section.
• Fixed backup frequency: state the frequency and the range of data covered. Only with a frequency can the worst-case data loss be known.
• Data export after termination: state that the data belongs to the agency and can be exported in full on termination. When the vendor changes, the successor can then obtain complete data.

Data export is tied to handover: a successor needs complete data and system documentation to continue the existing functions. Continuity of system knowledge between the design tender and the engineering tender is covered in System knowledge continuity from design tender to engineering tender. The day-to-day practice of maintenance notices and periodic checks is covered in Routine maintenance after launch. All of these are items worth writing into an SLA, and whether to include these items, and in how much detail, is set per project.

Statutory reporting deadlines in the public sector are the agency's responsibility

After a government agency becomes aware of a cybersecurity incident, it must report within the deadline set by regulation, through the system platform designated by the competent authority. The Cyber Security Management Act FAQ of the Administration for Cyber Security, Ministry of Digital Affairs, cites this requirement (Administration for Cyber Security, Ministry of Digital Affairs, 2026). The duty to report rests with the agency. The purpose of a vendor's incident notification deadline in an SLA is to give the agency enough information within the statutory deadline. Details of the provisions and incident levels follow the current rules in the regulations database.

An agency's own required actions depend on its responsibility level. Under the Regulations on Classification of Cyber Security Responsibility Levels, agencies are classified into levels A to E. Where several levels apply, the highest governs, and each level carries out the required actions in the appendices to the regulations. Before signing, the agency's level should be confirmed, and the required actions that call for vendor cooperation should then be listed in the SLA.

Routine checks arranged by the supervising agency are another source of deadlines: the supervising agency sets the deadline, and the vendor cooperates by making corrections and keeping records. Take a monthly routine host scan as an example. The supervising agency sets the deadline, POLISH makes corrections within it and replies with an explanation of the handling, and the project team then reports to the supervising agency.

SLA clauses related to such deadlines cover the vendor's handling process and the way of replying after a report is received, while the deadline itself follows the supervising agency's rules. Prioritizing fixes and retesting after a report arrives is covered in What happens after a vulnerability scan report arrives. How replies and records are kept as delivery evidence is covered in Delivery and maintenance evidence in public-sector projects.

Contract terms and the working relationship complement each other

A questionnaire study of South Korean IT executives by Goo et al. supports the view that formal contracts and relational governance complement each other. A well-structured SLA has a significant positive effect on relational norms, harmonious conflict resolution and mutual dependence, and besides measuring supplier performance, an SLA also helps the partnership between the two parties develop (Goo et al., 2009). The same study also found that the "change" characteristic of an SLA can weaken trust and commitment, and acts more like a substitute for relational governance.

Change is therefore an item in an SLA that needs careful drafting. POLISH recommends spelling out how changes are proposed and how changes are quoted, which is the two-column quotation described in the previous section. How contract terms and relational governance divide the work is covered in Two tracks in long-term outsourcing: contract terms and relational governance.

POLISH supports the Ministry of Education project, carrying the work from the design tender through to the engineering tender, and the long-term maintenance collaboration can be seen in the case of the Outdoor Education Resource Platform.

Situations where figures should not be applied directly

In the situations below, citing figures from other systems or from the industry easily produces clauses that do not fit.

• Systems not yet live: there is no usage record to refer to, so the clauses first set out severity levels and the handling process, and target values are agreed after launch based on actual use.
• Low-traffic services: ratio-based metrics are easily swayed by a handful of incidents, so target values need to be set separately according to actual usage.
• Event sites that run for a limited period: the clauses are written phase by phase. During the event the focus is the order of handling and staffing, and data retention and export are placed after the event ends.

SLA target values are agreed according to the usage context and user needs of a single system. Targets are not worked back from current performance, and numbers from other systems are not borrowed.

What to prepare before starting

For SLA discussions, POLISH's long-term maintenance and platform building service recommends preparing the following first, and the time limits and consequences in the clauses are then set per project.

1. The functions users depend on most, and the scope of impact when those functions stop working.
2. The functional scope and acceptance items in the contract, as the basis for separating defect fixes from new requirements.
3. The agency's cybersecurity responsibility level, and the required actions that call for vendor cooperation.
4. The inspection items the supervising agency has already set, and the source of the correction deadlines.
5. Data ownership, the export format on termination, and the successor to receive the data.
6. The likely time windows for scheduled maintenance, and who notifies users.

With these prepared, the current system and contract conditions can be described, and POLISH will propose SLA items that suit the project, without applying preset time limits.