Service availability management

ISO/IEC 20000-1:2018 Clause 8.7.1 requires you to manage service availability so it meets agreed requirements, then monitor and report availability against defined targets. To operationalize it quickly, define availability targets per service, instrument measurement end-to-end, review results on a set cadence, and drive corrective actions when targets are missed. ¹

Key takeaways:

• Availability management starts with clear, measurable availability requirements tied to each service and its dependencies. ¹
• You must measure availability consistently, report results against targets, and keep evidence that the process runs. ¹
• Auditors look for defined targets, trustworthy monitoring, and proof you act on breaches, not just dashboards. ¹

Service availability management is one of those requirements that looks simple in the standard and gets messy in operations. The clause is short, but it forces discipline across service design, monitoring, incident/problem/change, third-party management, and customer reporting. If you cannot explain “what availability means for this service,” “how we measure it,” and “what we do when we miss,” you will struggle in an ISO/IEC 20000-1 audit.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat availability as a governed metric with a single owner per service, a defined measurement method, and a reporting package that can be produced on demand. You also need a boundary: what is included in the service measurement (service hours, maintenance windows, excluded events), what dependencies are critical (cloud hosting, network carriers, SaaS sub-processors), and what happens operationally when availability degrades.

This page translates the requirement into an implementation playbook: scope, roles, steps, artifacts, audit questions, common failure modes, and a practical execution plan. All requirement statements and interpretations are grounded in ISO/IEC 20000-1:2018 Clause 8.7.1. ¹

Regulatory text

Requirement (verbatim): “The organization shall manage the availability of services to meet agreed availability requirements. Availability shall be monitored and reported against targets.” ¹

Operator interpretation (what you must do):

1. “Manage the availability of services” means you have an operating process, not an ad hoc reaction. It includes setting expectations, engineering to those expectations, and running controls to sustain them. ¹
2. “Agreed availability requirements” means availability expectations are explicitly agreed with the customer or service consumer (often via SLAs/OLAs/UCs, service catalogs, or contracts). “Agreed” also implies you can produce the agreement during an audit. ¹
3. “Monitored and reported against targets” means you define targets and then produce monitoring outputs and reports that compare actual performance to those targets. A dashboard alone is not enough unless it is retained and reviewed as evidence. ¹

Plain-English requirement

You need to (a) define what “available” means for each in-scope service and the target you commit to, (b) measure actual availability using a consistent method, and (c) regularly report results against the target and act when performance falls short. ¹

Who it applies to

Entity types: Any organization delivering or operating services, including internal IT service providers and external service providers. ¹

Operational context where it matters most:

• Customer-facing technology services with explicit SLAs (helpdesk, business applications, platforms, APIs).
• Shared internal services where business units depend on uptime (identity, email, network, core infrastructure).
• Services with third-party dependencies (cloud, telecom, managed service providers) where you still own the service outcome.

Scoping decision you must make: define which “services” are in scope for ISO/IEC 20000-1 and ensure each has a named owner and availability target. If your organization runs many components, do not confuse “component uptime” with “service availability.” Auditors will ask you to connect component telemetry to service-level reporting. ¹

What you actually need to do (step-by-step)

1) Create a service availability register

Build (or extend) a service catalog view that includes, per service:

• Service name and owner
• Service consumers (customer(s) or internal business units)
• Availability target statement (see next step)
• Service hours (e.g., business hours vs 24x7) and time zone
• Included/excluded downtime rules (planned maintenance, customer-caused outages, force majeure rules if contractually defined)
• Key dependencies (infrastructure, platforms, third parties, key internal teams)

This register is your audit map: it proves you manage availability as a service construct rather than scattered system metrics. ¹

2) Define “agreed availability requirements” and convert them to targets

For each service, document the agreed requirement and the target metric you will report:

• Requirement source: SLA, contract, service charter, service catalog commitment, or internal OLA.
• Target format: keep it measurable and comparable period over period (for example: “availability measured monthly during service hours,” plus the threshold).

Also record the measurement method:

• What constitutes “down” (synthetic checks failing, error rate threshold, inability to complete a transaction, etc.)
• Minimum data sources (monitoring tool, logs, incident records)
• How you treat partial degradation (decide whether you will measure “availability only” or include “performance/latency” in a broader reliability metric; if you only measure availability, say so)

If targets are unrealistic, availability management becomes a reporting exercise that forces constant exceptions. Renegotiate targets or invest in resilience, but avoid informal “everyone knows we don’t really meet that.” ¹

3) Instrument monitoring end-to-end (service-level, not just device-level)

Set up monitoring that can support a service-level availability calculation:

• Synthetic monitoring for user journeys (login, checkout, ticket submission)
• Health checks at key service endpoints (APIs, web, DNS)
• Dependency monitoring for critical upstream systems (database, message bus, identity provider)
• Alerting rules aligned to “down” definitions

Tie monitoring events to incident records. The audit question is predictable: “Show me a month where you missed availability and what you did.” Without linkage, you cannot prove management, only observation. ¹

4) Establish an availability reporting pack and review cadence

Create a standard report template per service (or per service tier) with:

• Target vs actual availability for the reporting period
• Number and duration of availability-impacting incidents (derived from incident records and monitoring)
• Root cause themes (from problem management where available)
• Corrective actions and owners (from problem/change/action logs)
• Risks or upcoming changes that may affect availability (maintenance, migrations)

Ensure the report is reviewed (not just generated). Capture review evidence: meeting minutes, sign-off in a ticketing system, or a GRC control attestation. ¹

5) Define breach handling: triggers, communications, and corrective action

Write a simple runbook for availability target breaches:

• Trigger: what constitutes a breach (target not met, repeated major incidents, chronic instability)
• Escalation: who gets notified (service owner, SRE/ops lead, account owner, compliance if customer commitments are involved)
• Customer/internal communications: when and how you report missed targets
• Corrective action: when you open a problem record, when you require a change, and how you track to closure
• Exception handling: when a breach is excluded due to agreed terms, and how you document that determination

Auditors generally accept missed targets if you can show controlled response and continual improvement discipline. They do not accept missing targets with no governance trail. ¹

6) Cover third-party dependencies explicitly

If a third party underpins your service, your availability management should include:

• Dependency mapping in the service availability register
• Contract/SLA clauses that support your target (or an internal OLA that compensates)
• Monitoring of the third party’s status where feasible (status pages, API checks, provider metrics)
• An operational plan for third-party outages (failover, manual procedures, customer comms)

You may not control the third party, but you still need to manage the service outcome and report availability against targets. ¹

Required evidence and artifacts to retain

Keep artifacts that prove agreement, measurement, reporting, and action:

Agreement and target definition

• Service catalog entries or service charters with availability commitments
• SLAs/OLAs/underpinning agreements referencing availability requirements
• Availability target definitions, including service hours and exclusions

Monitoring and measurement

• Monitoring configuration exports or screenshots (checks, alert rules)
• Availability calculation logic (how downtime is counted)
• Raw source data references (monitoring logs, incident timelines) sufficient to support reported numbers

Reporting and governance

• Monthly/periodic availability reports per service (target vs actual)
• Evidence of review (meeting minutes, email sign-off, ticket comments, control attestations)
• Breach records with corrective actions and owners

Operational follow-through

• Incident records linked to downtime
• Problem records and post-incident reviews for material outages
• Change records implementing corrective actions

If you use a platform like Daydream to manage service evidence and control execution, map each artifact to a control task so the reporting and sign-offs are captured as part of the workflow rather than reconstructed before an audit. ¹

Common exam/audit questions and hangups

Expect these questions (and prepare the evidence package in advance):

1. “Show me the agreed availability requirements for Service X.” Auditors want the requirement source, not a verbal statement. ¹
2. “How do you define ‘down’ for Service X?” Weak definitions produce unreliable reporting. ¹
3. “How do you calculate availability, and what data do you use?” Be ready to explain the method and point to tool outputs. ¹
4. “Show reporting against targets and the management review.” A dashboard screenshot without review evidence is a common finding. ¹
5. “Show what happened when targets were missed.” They will sample a bad month. Have a clean chain: incident → review → corrective action. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails audits/operations	Fix
Targets exist only in marketing decks or tribal knowledge	Not “agreed,” not auditable	Put targets in the service catalog and/or SLA repository; link to evidence. 1
Measuring device uptime instead of service availability	Components can be “up” while the service is unusable	Define service transactions and measure user-impacting checks. 1
No rule for maintenance windows/exclusions	Reported results get disputed	Document service hours and exclusion logic per service. 1
Reporting exists but no management review	Fails the “manage” expectation	Add a recurring review and retain sign-off evidence. 1
Breaches are “explained away” without corrective action	Repeats incidents, poor control maturity	Require a problem record or action plan for material breaches; track to closure. 1

Enforcement context and risk implications

ISO/IEC 20000-1 is a certifiable standard, not a regulator. Your practical risk is audit nonconformities that can threaten certification, plus contractual exposure when SLAs are missed and reporting is inconsistent. The control also protects you in disputes: clear definitions, consistent measurement, and retained review evidence reduce argument over whether a service met its commitments. ¹

Practical 30/60/90-day execution plan

No timelines are required by the clause, but audits reward a visible operating cadence. Use this phased approach:

First 30 days (foundation)

• Confirm in-scope services and assign service owners.
• Build the service availability register with targets, service hours, and exclusion rules.
• Identify top dependencies (including third parties) per service.
• Standardize the availability metric definition and reporting template.

By 60 days (measurement and reporting live)

• Implement or tune monitoring for service-level checks and dependency signals.
• Start generating availability reports against targets for each in-scope service.
• Run the first management review and capture sign-offs.
• Define breach handling runbooks and escalation paths.

By 90 days (control maturity)

• Test evidence retrieval: pick a service and produce the full chain (agreement → monitoring outputs → report → review → corrective actions).
• Run a tabletop exercise for a major outage to validate communications and breach governance.
• Tie recurring corrective actions to problem/change management so availability improvements are tracked and completed.
• Operationalize third-party outage handling with documented expectations and monitoring inputs.

If you manage controls in Daydream, set recurring tasks for report generation, review sign-off, and breach follow-up so evidence is created continuously instead of assembled during audit season. ¹

Frequently Asked Questions

Do we need an SLA to meet this requirement?

You need “agreed availability requirements,” which can be an SLA, an internal OLA, or a documented service catalog commitment that service consumers accept. Keep the agreement retrievable and tied to the service and target. ¹

Can we report availability from our monitoring tool without a formal review meeting?

The clause requires monitoring and reporting against targets, and the “manage” expectation is hard to prove without review evidence. If you don’t hold a meeting, capture an equivalent approval trail (ticket sign-off or control attestation). ¹

What if the service depends on a third party and they cause downtime?

Your service availability reporting should still reflect actual service availability as experienced by users, unless your “agreed” terms explicitly exclude that downtime. Document the dependency, the exclusion rule (if any), and the corrective actions you took. ¹

How granular should our availability targets be?

Set targets at the service level first, because that’s what the requirement calls “services.” Component targets can exist as supporting objectives, but your primary reporting should map to the service commitment. ¹

Do we need post-incident reviews for every outage?

The clause does not prescribe post-incident reviews, but you do need evidence you manage availability to meet targets. Set criteria for when an outage triggers a formal review and corrective action plan, then follow it consistently. ¹

What’s the minimum evidence set an auditor will accept?

For a sampled service, be ready to show the agreed target, the monitoring method, a report showing actual vs target, review evidence, and at least one example of corrective action taken after a miss or risk trend. ¹

Footnotes

1. ISO/IEC 20000-1:2018 Information technology — Service management