SLO vs SLA vs SLI Explained: Service Level Targets for CySA+

A service level objective is the internal target you hold a service to. It sits between two terms it is constantly confused with, and the exam tests the distinction more often than the definition.

SLI, SLO, SLA

Term	What it is	Who it is for
SLI — service level indicator	The measurement itself	Engineering
SLO — service level objective	The target for that measurement	Internal
SLA — service level agreement	The contractual promise, with penalties	Customer, legal

Worked through: the SLI is "percentage of requests returning successfully in under 300 ms". The SLO is "99.9% of requests, measured monthly". The SLA is "99.5% availability, or the customer receives a service credit".

Note the deliberate gap. The SLO is stricter than the SLA, so the team is alerted and correcting well before the contract is breached. If your internal target equals your contractual obligation, you find out you have a problem at the same moment your customer does. A question asking why an SLO should be tighter than the SLA is testing exactly this.

An OLA, operational level agreement, is the internal commitment between teams that makes the SLA achievable — the storage team's promise to the application team. A UC, underpinning contract, is the equivalent with an external supplier. You cannot promise a customer more availability than your own suppliers promise you.

Availability and the nines

Availability targets get quoted in nines, and the downtime figures are testable.

Availability	Downtime per year	Per month
99%	3.65 days	7.2 hours
99.9% (three nines)	8.76 hours	43.8 minutes
99.99% (four nines)	52.6 minutes	4.38 minutes
99.999% (five nines)	5.26 minutes	26 seconds

Each additional nine costs far more than the last, because it demands redundancy at every layer and removes the option of any manual step during recovery. Five nines leaves no time for a human to read an alert. The exam likes the point that higher availability is a cost decision, not a purely technical one.

Error budgets

The neat consequence of an SLO. If the target is 99.9% over a month, the remaining 0.1% — about 43 minutes — is the error budget: the failure you are permitted.

That reframes reliability as something to spend. Budget intact means you can ship changes aggressively. Budget exhausted means you freeze risky deployments and spend the effort on stability instead. It converts an argument about whether to release into a question with a measurable answer.

Where security metrics fit

CySA+ links service levels to incident response, because the same discipline applies.

MTTD, mean time to detect, is how long between compromise and discovery. MTTR can mean respond, repair, recover or remediate depending on context — read the stem carefully. MTBF, mean time between failures, measures reliability of repairable systems. MTTF applies to things that are replaced rather than repaired.

Vulnerability management SLAs are the common case: critical findings remediated within 7 days, high within 30, and so on. Those are service level targets applied to security work, and compliance regimes often set the numbers.

Making an SLO useful

Measure what the user experiences, not what is convenient. A server that responds to pings while the application returns errors is up by the wrong measure.

Set the target where the user stops noticing improvement, not at the highest number you can justify. Define the measurement window — 99.9% over a year permits a single eight-hour outage that 99.9% measured monthly would not. And decide what counts as an exclusion: scheduled maintenance usually sits outside the calculation, and that definition belongs in the agreement, not in an argument afterwards.

What to remember

SLI measures, SLO targets, SLA contracts with penalties. The SLO should be stricter than the SLA so you correct before breaching. OLAs and underpinning contracts make the SLA deliverable internally and from suppliers. Three nines is about 8.8 hours a year, four nines under an hour, five nines about five minutes. The error budget is the permitted failure, and it governs how aggressively you can change things.

Related reading: Mean time to detect · Mean time to remediate · CMDB