Plan the services

“Plan the services” is a requirement about operational readiness and control: you should be able to show, for every service you offer, what you committed to deliver, what it takes to deliver it, and how you prove you delivered it. ISO/IEC 20000-1 places this obligation directly on the organization operating the service management system, whether you deliver internal IT services, customer-facing managed services, or shared platform services ¹.

This clause often fails in audits for a simple reason: teams confuse service planning with project planning, or they rely on scattered documents (SOWs, runbooks, monitoring dashboards) that never get reconciled into a controlled, service-level plan. The standard expects minimum content for each service plan: service requirements, delivery resources, and performance measurement methods against SLAs and service management objectives ¹.

This page gives requirement-level implementation guidance you can execute quickly: what “planning” must include, how to build a repeatable service plan, what evidence to retain, and how to prepare for exam questions without creating paperwork that nobody uses.

Regulatory text

ISO/IEC 20000-1:2018 Clause 8.2.2 states: “The organization shall plan each service, including at minimum the service requirements, resources required to deliver the service, and the methods for measuring the performance of the service against service level agreements and service management objectives.” ¹

Operator interpretation (what you must do):

• Plan each service: maintain a defined, controlled plan per service (typically aligned to your service catalog entries).
• Include service requirements: document what the service must do and the conditions under which it must operate (scope, users, hours, criticality, support boundaries, dependencies).
• Include resources required to deliver: identify the people, tools, infrastructure, third parties, and financial/contractual dependencies needed for delivery.
• Define measurement methods: specify metrics, data sources, calculation logic, reporting cadence, and ownership to measure performance against SLAs and service management objectives ¹.

Plain-English meaning (what auditors expect to “see”)

Auditors typically test this clause by sampling a handful of services and asking you to prove three things:

1. You know what you deliver. Your service requirements are explicit and current, not implied or tribal knowledge.
2. You have delivery capability. Your resourcing plan matches the service’s requirements and risk profile (including reliance on third parties).
3. You measure what matters. You can show how SLA results and service management objectives are measured, reported, and acted on, with consistent definitions ¹.

A practical litmus test: if a service owner left tomorrow, could another qualified person pick up the service plan and understand commitments, dependencies, and how performance is evaluated?

Who it applies to

In scope entities

• Any organization operating an ISO/IEC 20000-1 service management system.
• Internal IT, shared services, managed service providers, SaaS/platform operators offering defined services ¹.

Operational contexts where this clause matters most

• High-impact services (customer-facing production services, identity, payments, core ERP).
• Services with strong third-party dependence (cloud hosting, payment processors, outsourced service desk).
• Services with tight SLAs or contractual penalties (even if those penalties sit outside ISO, your measurement must still be defined to manage the SLA).

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

Step 1: Establish your “service plan” standard (one template, many services)

Create a controlled template that every service uses. Keep it short but complete. Minimum sections aligned to the clause:

• Service requirements
• Resources required
• Performance measurement methods ¹

Add the fields auditors repeatedly ask for:

• Service owner and backup owner
• Service boundaries (in/out of scope), hours of support, target users/customers
• Key dependencies (upstream/downstream systems, third parties)
• Applicable SLAs and service management objectives mapped to metrics

Step 2: Inventory services and tie plans to the service catalog

• If you already have a service catalog, treat it as the index. Every catalog entry should point to a service plan.
• If you lack a catalog, start with a simple list of “services we run” and assign owners. Convert the list into a catalog later; don’t block planning on perfect taxonomy.

Audit tip: “Plan each service” is hard to defend if you cannot show what your defined services are.

Step 3: Define service requirements (make them testable)

For each service, document requirements in operational language:

• Functional scope: what the service provides.
• Non-functional requirements: availability expectations, performance expectations, data handling constraints, continuity needs, support model.
• Constraints: maintenance windows, excluded components, customer responsibilities.
• Acceptance criteria for changes/releases (what must be true before you consider a change successful).

Keep a clear link to the SLA and objectives. If a requirement exists, you should either measure it or explicitly justify why it is not measured.

Step 4: Define resources required to deliver (include third parties explicitly)

Build a “resource map” for the service:

• People: roles required (service owner, on-call, operations, security, DBAs), coverage model, escalation.
• Technology: environments, monitoring, CI/CD, ticketing, knowledge base, CMDB relationships.
• Third parties: name the third party, what they provide, what you depend on (availability, response times, contractual support hours), and how you monitor them.
• Financial/contractual: contract owner, renewal dates, licensing constraints (include these if they can affect continuity).

This part is where many teams miss operational reality. A service plan that ignores a critical third party dependency is usually indefensible during an incident review.

Step 5: Define measurement methods (not just “what we measure”)

The clause requires “methods” for measuring performance against SLAs and service management objectives ¹. Methods should answer:

• What is measured (metric name and definition).
• Where data comes from (monitoring tool, ticketing, log system).
• How it is calculated (formula/logic, inclusion/exclusion rules, time zone, service hours).
• Who reviews it and how often.
• What triggers action (thresholds, breach workflow, problem management linkage).

Example (availability):

• Metric definition: service availability during supported hours.
• Source: synthetic monitoring checks + status page events.
• Calculation: total supported minutes minus outage minutes divided by total supported minutes; planned maintenance excluded if communicated.
• Review: service owner reviews monthly report; breaches trigger incident review and problem record.

Step 6: Operationalize governance (approve, review, and keep current)

Set minimum governance rules:

• Service plans are approved by the service owner and the service management function.
• Changes to SLAs, objectives, or dependencies require plan updates.
• Plans are reviewed on a defined cadence or upon major change (new third party, architecture shift, new SLA).

If you use a GRC platform like Daydream, treat the service plan as a controlled artifact with ownership, review workflows, and linked evidence (dashboards, SLA reports, contracts). That reduces the “document sprawl” problem during audits.

Required evidence and artifacts to retain

Keep evidence at two levels: (1) the plan and (2) proof the plan is real.

Core artifacts

• Service plan for each in-scope service (version controlled, owner identified).
• SLA documents and service management objectives mapped to metrics ¹.
• Monitoring/measurement definitions (metric dictionary, SLI/SLO specs, reporting logic).
• Resource documentation: RACI, on-call rota model, key tool dependencies, third-party dependency list.
• Performance reports and review notes (monthly/quarterly service reviews, corrective actions).
• Evidence of updates: change records showing plan updates after material changes.

Evidence auditors like

• A sample SLA report that matches the measurement method described in the plan.
• Incident postmortems or problem records tied back to the service objectives and metrics.
• Third-party service reports or tickets that show you monitor and manage dependencies.

Common exam/audit questions and hangups

Expect questions like:

• “Show me the plan for Service A. Where are the requirements, resources, and measurement methods?” ¹
• “How do you ensure service plans stay current when architecture changes?”
• “Where are service management objectives defined, and how do they relate to SLAs?”
• “How do you calculate SLA attainment? What do you exclude, and why?”
• “Which third parties are critical to delivery, and how do you manage their performance?”

Common hangups:

• Undefined service management objectives. Teams have SLAs but no internal objectives (or they are vague).
• Metrics without methods. Dashboards exist, but nobody can explain definitions consistently.
• Resource planning missing third parties. The plan lists internal teams only.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: One master plan for “IT services” instead of per-service planning.
   Fix: Create a standard template and apply it to each service catalog entry ¹.

2. Mistake: Requirements copied from a contract without operational detail.
   Fix: Add support boundaries, dependencies, and measurable non-functional requirements.

3. Mistake: SLAs measured inconsistently across tools and teams.
   Fix: Maintain a metric dictionary and embed definitions in the service plan’s measurement section.

4. Mistake: Service plans written once for certification, then ignored.
   Fix: Tie service plan review to change management triggers (new third party, major release, SLA change) and to service review meetings.

Risk implications (why this clause matters operationally)

Poor service planning creates predictable failure modes:

• SLA disputes because measurement logic is unclear or changes over time.
• Incident response delays because ownership, escalation paths, or dependencies are undocumented.
• Third-party outages cascading into your service without clear monitoring, escalation, or contract accountability.
• Audit findings for “paper controls,” where monitoring exists but cannot be traced to defined objectives and requirements ¹.

Practical execution plan (30/60/90-day)

Use phases rather than date promises; the right pace depends on service count and maturity.

First 30 days (Immediate stabilization)

• Stand up the service plan template aligned to Clause 8.2.2 minimums ¹.
• Create or confirm your service inventory and assign owners.
• Select a pilot set of high-impact services and draft plans end-to-end.
• Define a metric dictionary format (even a spreadsheet) and require every pilot service to document measurement methods.

By 60 days (Broaden coverage and harden evidence)

• Expand service plans to the remaining in-scope services, prioritizing those with SLAs and critical third parties.
• Implement a lightweight approval workflow and version control.
• Produce repeatable SLA/objective reporting for each planned service and store the outputs as audit evidence.
• Run one service review meeting per pilot service and capture actions and decisions.

By 90 days (Institutionalize and make it durable)

• Integrate service plan updates with change management (plan update required for material service changes).
• Standardize third-party dependency documentation inside service plans, including escalation and monitoring.
• Perform an internal audit-style sampling: pick services, trace requirements → resources → measurement → reports → actions.
• If you use Daydream, map each service plan to owners, linked evidence, and review tasks so you can answer audits from a single control record without chasing screenshots.

Frequently Asked Questions

Do we need a separate plan document for every service?

ISO requires you to “plan each service” and include minimum elements per service ¹. You can meet this with one template per service or a structured system record, as long as each service’s requirements, resources, and measurement methods are clearly documented.

Can a contract or SOW count as the “service plan”?

Only if it contains the minimum planning content, including resourcing and measurement methods tied to SLAs and service management objectives ¹. In practice, most contracts lack metric calculation rules and internal resourcing details, so you still need a service plan.

What are “service management objectives” and how are they different from SLAs?

SLAs are the agreed service level commitments, while service management objectives are the organization’s objectives for managing and improving services ¹. Your plan should show how you measure against both, even if the objectives are internal targets.

How detailed do “resources required” need to be?

Detailed enough that delivery is credible: key roles, tooling, infrastructure dependencies, and critical third parties should be explicit. If losing a named dependency would break the service, it belongs in the resource section.

We have dashboards. Do we still need to document “methods” for measuring performance?

Yes. The clause calls for the methods, not just the existence of metrics ¹. Document definitions, data sources, calculation rules, reporting, and ownership so results are consistent and auditable.

How do we keep service plans current without creating admin overhead?

Tie updates to operational triggers: major changes, new third parties, SLA changes, and post-incident corrective actions. A workflow tool (including Daydream) helps by assigning owners, review cycles, and evidence links so plans do not decay.

Footnotes

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