APO09: Managed Service Level Agreements

The apo09: managed service level agreements requirement expects you to define, agree, monitor, and enforce service levels for IT services and third-party services, with clear ownership and measurable targets. To operationalize it fast, inventory services, set SLA/OLA/UC templates, implement measurement and reporting, and run a recurring review cycle with documented exceptions and remediation. ¹

Key takeaways:

• Treat SLAs as an operating control: defined metrics, owners, monitoring, reporting, and corrective action.
• Cover the full chain: business-facing SLAs, internal OLAs, and third-party underpinning contracts so targets are achievable.
• Evidence wins exams: signed agreements, dashboards, breach logs, and meeting minutes that show active management.

APO09 in COBIT 2019 is where “we expect good service” becomes a measurable, enforceable agreement that you can manage and audit. Most SLA programs fail for one of three reasons: the service catalog is incomplete, the targets are not measurable (or not measured), or third-party commitments don’t match what the business was promised. APO09 closes those gaps by requiring a disciplined lifecycle: define services, agree on service levels, monitor performance, and take action when service levels are missed. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to focus on operational proof. Auditors and internal stakeholders will ask: What services are in scope, what are the agreed metrics, who owns each metric, where is performance reported, and what happens after a breach? If you can answer those with artifacts and a consistent cadence, APO09 is “implemented” in the only way that matters: it runs without heroics and it leaves a trail. ²

This page gives requirement-level implementation guidance you can hand to IT, SRE/Operations, Procurement, and Vendor Management, then verify through evidence. It is written to help you operationalize the apo09: managed service level agreements requirement quickly, not debate theory. ²

What APO09 requires (plain-English)

APO09 expects your organization to manage service level agreements as a controlled process: you define the services you provide, set measurable service level targets with the business, ensure internal teams and third parties can meet those targets, continuously monitor performance, and drive corrective actions when targets are missed. ¹

Operationally, that translates into three linked agreement layers:

• SLA (Service Level Agreement): Business-facing commitments for a service (availability, support response, recovery objectives, security obligations, reporting frequency).
• OLA (Operational Level Agreement): Internal commitments between IT teams that enable the SLA (e.g., Network and App Support).
• Underpinning Contract / Third-Party SLA: Contractual commitments from third parties that support delivery (cloud provider uptime, SOC response, managed service coverage).

Your goal is alignment. If the business SLA promises outcomes that internal OLAs or third-party contracts cannot support, APO09 fails in practice even if you have “documents.” ²

Who it applies to

APO09 applies to any enterprise IT organization (including regulated entities) that:

• Provides internal IT services (identity, endpoint management, ERP, networks, data platforms).
• Delivers customer-facing digital services (online banking, e-commerce, healthcare portals).
• Relies on third parties for critical components (cloud, MSP/MSSP, payment processors, payroll, customer support platforms). ¹

It matters most in these operational contexts:

• High availability services where downtime is a reportable incident or drives customer harm.
• Outsourced IT / managed services where performance depends on third parties.
• Shared services where multiple business units consume the same platform and disputes arise without clear targets.
• Material change environments (migrations, new platforms) where “expected performance” shifts and needs re-baselining. ²

Regulatory text

Provided excerpt: “COBIT 2019 objective APO09 implementation expectation.” ¹

Operator interpretation: COBIT is a framework, so this “text” is an implementation expectation rather than a statute. For operators, treat it as a requirement to:

1. establish documented service levels for in-scope services,
2. confirm mutual agreement with stakeholders,
3. measure actual performance against targets,
4. review results on a defined cadence,
5. remediate breaches and track exceptions with approvals and timelines. ²

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

Step 1: Set scope using a service catalog

Create or refresh a service catalog that answers:

• Service name and description
• Service owner (accountable) and operations owner (responsible)
• Customers (business units / external users)
• Support model (hours, channels)
• Dependencies (internal platforms, third parties)
• Data classification / criticality tier (drives minimum SLA rigor)

Practical shortcut: start with “critical services” first (those tied to revenue, safety, regulated operations, or customer commitments), then expand. ²

Step 2: Define standard SLA metrics and a template

Build an SLA template with a controlled set of metrics so reporting is consistent. Common SLA sections:

• Availability definition (what counts as outage, exclusions, maintenance windows)
• Incident response (acknowledgement time, restoration targets, escalation)
• Service request fulfillment (turnaround targets)
• Performance (latency, throughput) if relevant
• Backup/restore and recovery commitments (tie to DR program)
• Security obligations (logging, vulnerability handling, access controls, notification paths)
• Reporting (what reports, cadence, recipients)
• Breach handling (root cause analysis expectations, corrective actions, credits if applicable)

Do not accept “best effort” language for critical services. If a metric cannot be measured, rewrite it until it can. ²

Step 3: Align SLAs with OLAs and third-party commitments

For each critical SLA metric, map:

• The internal team(s) that must perform actions to achieve it (OLAs).
• Any third-party dependency that affects the metric (underpinning contract clauses).

Create a simple “SLA traceability matrix”:

• SLA metric → internal OLA metric(s) → third-party clause(s) → measurement source.

This is where most programs break: business SLAs get approved, but Procurement contracts and internal runbooks never change. APO09 expects the chain to hold. ¹

Step 4: Implement measurement, monitoring, and a single source of truth

Decide, per metric:

• Data source (monitoring tool, ticketing system, call center platform, cloud status logs)
• Calculation method (definitions for numerator/denominator, sampling, exclusions)
• Owner for producing the report
• Storage location for reports (GRC repository or controlled drive with retention)

Day-to-day, this is an operations job. Your compliance job is to confirm the measurement exists, is repeatable, and cannot be quietly redefined after a miss. ²

Step 5: Establish breach management and corrective action

Define a consistent breach workflow:

• Identify and record breach
• Classify severity and customer impact
• Notify stakeholders (business owner, risk, vendor manager if third-party involved)
• Document root cause and corrective action
• Track remediation to closure
• Approve exceptions with expiry dates when remediation is not immediate

If you allow “permanent exceptions,” you are accepting unmanaged risk. Require time-bounded exceptions with a plan. ²

Step 6: Run a recurring SLA governance cadence

Create a standing agenda for SLA reviews:

• Performance results vs targets
• Trend analysis and recurring issues
• Breach reviews and remediation status
• Upcoming changes that may affect targets (migrations, vendor changes)
• Decisions: keep targets, revise targets, or invest to meet targets

Include the service owner, operations lead, and third-party owner as needed. Publish minutes and action items. ²

Required evidence and artifacts to retain

Use this as your audit-ready checklist:

• Service catalog with owners, tiers, and dependencies
• Approved SLA templates and current SLAs (version-controlled)
• OLAs for internal support functions linked to SLAs
• Third-party contracts / statements of work with service level clauses (or cross-references)
• SLA traceability matrix (SLA → OLA → third-party)
• Monitoring definitions and metric calculation documentation
• Periodic SLA performance reports/dashboards
• Breach log with tickets, root cause summaries, and corrective actions
• Exception register with approvals and expiry dates
• SLA review meeting minutes and action-item tracking
• Evidence of stakeholder sign-off for new/changed SLAs ²

Practical note: Daydream (or your GRC system) should store the mapping between each SLA control point and its evidence location so you can produce a complete packet without a scavenger hunt.

Common exam/audit questions and hangups

Auditors commonly press on:

• “Show me your complete list of in-scope services and how you decide which ones require SLAs.”
• “Who approves SLAs and changes to SLA targets?”
• “How do you know the numbers are correct? Show metric definitions and data sources.”
• “Show breaches for a recent period and the corrective actions. Did you close them?”
• “Where do third-party service levels appear in contracts, and how do you enforce them?”
• “How do you handle maintenance windows, exclusions, and force majeure so reporting is consistent?” ²

Hangups that slow reviews:

• Multiple dashboards with conflicting numbers.
• SLAs that exist but have no reporting recipients.
• Contract SLAs that don’t match what IT reports internally.

Frequent implementation mistakes (and how to avoid them)

1. Writing aspirational SLAs
   Fix: require measurability tests during drafting: “What system produces the metric, and who owns it?”

2. No end-to-end mapping (SLA doesn’t match OLA or third-party contract)
   Fix: make the traceability matrix a gate for SLA approval and renewal. Procurement cannot sign without it.

3. Ignoring “support hours” reality
   Fix: define hours, escalation paths, and after-hours coverage explicitly. Many “breaches” are really ambiguity.

4. Treating SLA reviews as a reporting exercise
   Fix: require decisions. Each review should produce actions: invest, change targets, or accept time-bounded risk.

5. Evidence scattered across teams
   Fix: centralize evidence pointers in Daydream (or equivalent) with owners and a consistent naming convention. ²

Risk implications (why APO09 gets attention)

Weak SLA management increases:

• Operational risk: outages and prolonged incidents with unclear escalation.
• Third-party risk: you cannot enforce performance without contractual hooks and measurement.
• Compliance risk: inability to demonstrate control operation, even if teams “do the work.”
• Business friction: disputes over whether IT met expectations, which often leads to shadow IT.

COBIT positions APO09 as an objective because service performance is a governance outcome: it requires agreement, measurement, and accountability, not informal promises. ¹

Practical 30/60/90-day execution plan

First 30 days: establish the backbone

• Appoint SLA process owner and define RACI for service owners, operations, vendor managers, and Procurement.
• Build the initial service catalog focused on critical services.
• Publish SLA template, metric definitions, and approval workflow.
• Stand up an evidence repository structure (or Daydream workspace) with folders/records for SLAs, reports, breaches, and exceptions. ²

By 60 days: get to measurable reporting for critical services

• Execute SLA drafting and sign-off for critical services.
• Create OLAs for internal dependencies that are required to meet the SLA.
• Validate third-party contracts for underpinning service levels; log gaps and start contract addenda where needed.
• Produce the first recurring performance report from authoritative data sources. ²

By 90 days: run governance and prove corrective action

• Hold recurring SLA reviews with minutes and tracked actions.
• Implement breach workflow with root cause and corrective action tracking.
• Create an exception register with time-bounded approvals and ownership.
• Perform an internal “APO09 evidence drill”: pick one critical service and produce the full evidence packet in one sitting. Fix gaps immediately. ²

Frequently Asked Questions

Do we need SLAs for every IT service to satisfy APO09?

You need a defined approach for which services get SLAs and why, plus SLAs for services where performance materially affects the business. Start with critical services and expand based on tiering in your service catalog. ²

What’s the difference between an SLA and an OLA, and do we need both?

An SLA is the commitment to the business; an OLA is the internal commitment between teams required to meet the SLA. If a service depends on multiple internal teams, OLAs prevent “handoff gaps” that cause SLA misses. ²

How do we handle third-party services where the provider refuses custom SLAs?

Document the provider’s standard commitments, map them to your business SLA targets, and either adjust your business commitment or add compensating controls (redundancy, enhanced monitoring, incident playbooks). Track the gap as a risk acceptance with an expiry and owner. ²

What evidence is most persuasive to auditors for SLA management?

Signed/approved SLAs, consistent performance reports, and a breach log with corrective actions closed. Meeting minutes that show decisions and follow-through usually matter more than polished templates. ²

Can we use SLOs/SLIs instead of SLAs?

Yes if they function as enforceable commitments: defined metrics, owners, reporting recipients, and a corrective-action process. If they are internal-only and not agreed with stakeholders, they don’t meet the intent of managed service level agreements. ²

Where does Daydream fit in operationalizing APO09?

Daydream helps you keep SLAs, third-party mappings, and evidence pointers in one place so you can show design and operation without assembling artifacts manually each review cycle. Use it to link each service to its SLA, reports, breaches, and exceptions. ²

Footnotes

1. ISACA COBIT overview; OSA COBIT 2019 objective mapping

2. ISACA COBIT overview