Planning to achieve service management objectives

ISO/IEC 20000-1:2018 Clause 6.2.2 requires you to convert each service management objective into an executable plan that states the work to be done, the resources needed, named owners, target completion timing, and how results will be evaluated. To operationalize it, create an objective-by-objective “delivery plan” with governance, evidence, and recurring review built in. ¹

Key takeaways:

• Every service management objective needs a written plan with actions, resources, accountability, timing, and evaluation criteria. ¹
• Auditors will look for traceability from objectives to work items, owners, budgets/capacity, milestones, and measurable acceptance criteria.
• Your best evidence is a consistent planning template, approval workflow, and periodic status/effectiveness reviews tied to management review inputs.

“Planning to achieve service management objectives” is a control over execution. You can have solid objectives, but if you cannot show who is doing what, with which capacity, by when, and how you will judge success, the Service Management System (SMS) becomes aspirational rather than auditable.

Clause 6.2.2 sits in the planning layer of ISO/IEC 20000-1:2018. It forces discipline around turning objectives into delivery. For a Compliance Officer, CCO, or GRC lead, the practical task is to standardize a planning method that works across service owners, IT operations, and enabling functions (security, procurement, HR, finance). You are building repeatable governance: one planning template, one approval path, one evidence set.

This page gives requirement-level implementation guidance you can put into operation quickly: scope, step-by-step process, evidence to retain, common audit questions, typical failure modes, and a practical execution plan. Everything ties back to the requirement language in ISO/IEC 20000-1:2018 Clause 6.2.2. ¹

Regulatory text

ISO/IEC 20000-1:2018 Clause 6.2.2 states: “The organization shall determine what will be done, what resources will be required, who will be responsible, when it will be completed, and how the results will be evaluated when planning how to achieve service management objectives.” ¹

Operator meaning: for each service management objective, you must produce a plan that answers five questions, in writing, in a way that is actionable and reviewable:

1. What work will be done
2. What resources are required
3. Who is responsible
4. When it will be completed
5. How results will be evaluated
   ¹

Plain-English interpretation (what the requirement demands)

This requirement is a “no-handwaving” rule. If your objective is “reduce incident recurrence” or “improve change success,” you must show the implementation plan, not just the intent.

A compliant plan is more than a project name in a roadmap. It has:

• Action definition: concrete activities and deliverables (procedures, tooling changes, training, new reports).
• Resourcing: people capacity, skills, tools, and any dependencies needed to deliver.
• Accountability: a single accountable owner with contributing roles.
• Timing: milestones or completion triggers.
• Evaluation: how you will determine whether the objective was achieved (metrics, thresholds, acceptance criteria, review cadence). All five elements are explicitly required by Clause 6.2.2. ¹

Who it applies to (entity and operational context)

Applies to: any organization operating an SMS aligned to ISO/IEC 20000-1:2018, including internal IT service organizations and external service providers. ¹

Operational contexts where this becomes “exam critical”:

• You publish SMS objectives (often in Clause 6.2.1) but execution happens in many teams.
• You depend on third parties for key service components (cloud hosting, managed SOC, SaaS platforms). Your plan must account for third-party constraints and responsibilities because they affect resources, timelines, and evaluation.
• Objectives cut across functions (e.g., service desk + problem management + change enablement). Without a single plan, accountability fragments.

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

Use the steps below as your implementation checklist. The goal is a consistent planning workflow that produces auditable artifacts.

Step 1: Create a standard “Objective Delivery Plan” template

Build a one-page template (form, ticket type, or document) with required fields that map directly to Clause 6.2.2:

• Objective statement (link to SMS objectives register)
• Planned activities / deliverables (“what will be done”)
• Resource plan (“what resources will be required”): roles, estimated capacity categories (no need for precise hours), tooling, budget approvals if relevant, third-party inputs
• RACI or named owner (“who will be responsible”): accountable owner plus contributors
• Schedule (“when it will be completed”): milestones, dependencies, target completion criteria
• Evaluation plan (“how results will be evaluated”): KPIs, data source, reporting frequency, success criteria, and who reviews
• Approvals: service owner + SMS governance (or equivalent) This template is your primary compliance control because it forces completeness. ¹

Step 2: Build an “Objectives-to-Plans” register for traceability

Maintain a register that shows:

• Each service management objective
• The linked delivery plan(s)
• Current status (draft/approved/in progress/complete)
• Where evidence is stored (links) Auditors ask for traceability. A register prevents the common failure where some objectives have detailed plans and others have none. ¹

Step 3: Assign accountable owners and establish governance

Set one accountable owner per plan (often the process owner or service owner). If delivery spans teams, keep accountability single-threaded and list other teams as contributors.

Define governance rules:

• Who approves plans
• How conflicts are resolved (resource contention, priority disputes)
• How plan changes are controlled (versioning and re-approval triggers) These governance mechanics operationalize the “determine” language in the clause. ¹

Step 4: Translate the plan into executable work

A plan is not execution. Convert plan activities into:

• backlog items / work orders
• change records (if applicable)
• training tasks
• reporting tasks and dashboard updates Then link those work items back to the plan. This creates the audit trail between “what will be done” and what was actually done. ¹

Practical tip: If you already run ITSM in a ticketing platform, model each plan as an “epic” with child tasks. If you run work in a project tool, store the plan in the SMS repository and link to the project plan.

Step 5: Define evaluation criteria that can be evidenced

“We will evaluate” must become “we can prove evaluation occurred.” For each plan:

• Specify metric definitions (what is counted, what is excluded)
• Identify authoritative data sources (ITSM tool reports, monitoring system, customer survey results)
• Document success criteria (thresholds, trend improvement, or acceptance conditions)
• Define who reviews results and where the review is recorded (meeting minutes, management review inputs, service report sign-off) This directly satisfies “how the results will be evaluated.” ¹

Step 6: Run recurring status and effectiveness reviews

Hold a recurring review cadence under SMS governance:

• Status: progress against milestones, issues, resource constraints
• Effectiveness: early indicators, metric behavior, customer impact signals Record decisions and changes (scope change, timeline changes, additional resources). If a plan slips, capture the reason and the corrective action. Auditors care less about perfect delivery and more about controlled delivery. ¹

Step 7: Close the plan with evidence of completion and evaluation

Closure criteria should include:

• deliverables completed
• evaluation performed against the defined criteria
• residual risks/known issues documented
• handover into BAU (ownership, runbooks, monitoring, reporting) This prevents “paper completion” where work is done but evaluation is missing. ¹

Required evidence and artifacts to retain

Keep evidence in a controlled repository (SMS document control or equivalent). Minimum artifacts:

• Service management objectives register (the objective list you are planning against)
• Objective Delivery Plan for each objective, with all five Clause 6.2.2 elements completed ¹
• Approvals (electronic workflow approvals, signed minutes, or equivalent)
• Resource evidence (capacity confirmation, budget approval, role assignments, third-party statements of work or commitments if they are required inputs)
• Work execution traceability (links to backlog, tickets, changes, training completion, updated procedures)
• Evaluation outputs (dashboards, reports, KPI exports, meeting minutes showing review)
• Change history (versions, re-approvals, decision logs)
• Closure record documenting evaluation and acceptance

If you use Daydream to manage compliance work, map each objective to a control task bundle: plan template completion, approvals, evidence capture, and recurring review tasks. That reduces the “lost in tools” problem where the plan lives in one place and evidence in five others.

Common exam/audit questions and hangups

Expect questions like:

• “Show me one service management objective and the plan that meets all Clause 6.2.2 elements.” ¹
• “Where do you document resources required, and who confirms availability?”
• “Who is accountable, and what happens if the accountable owner changes roles?”
• “How do you evaluate results, and where is the evaluation recorded?”
• “How do you ensure every objective has a plan, not just the high-priority ones?”
• “How do third-party dependencies affect timelines and evaluation?”

Hangups auditors commonly probe:

• Plans that exist but were not approved.
• “Evaluation” described vaguely with no metric definitions or review records.
• Milestones missing or continuously shifting without controlled change records.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Objectives with no delivery plan.
   Fix: enforce a register that flags objectives without linked plans, and make plan completion a gate for objective approval. ¹

2. Mistake: Plans that list tasks but ignore resources.
   Fix: require a resource section with named roles and explicit third-party inputs; add an approver who can commit capacity.

3. Mistake: Shared accountability across multiple owners.
   Fix: appoint one accountable owner and document contributors; use a RACI only as support, not as a substitute for accountability.

4. Mistake: “Evaluation” means “we’ll look at it later.”
   Fix: define metrics, data sources, review forum, and evidence artifacts at plan creation. ¹

5. Mistake: Plans don’t survive change.
   Fix: version control with re-approval triggers (scope changes, timeline changes, material resource changes).

Risk implications (why operators should care)

This clause is a control against predictable SMS failures:

• Operational risk: objectives fail due to unassigned ownership, hidden dependencies, or insufficient capacity.
• Assurance risk: you cannot demonstrate controlled planning and evaluation, which undermines ISO/IEC 20000-1 audit outcomes.
• Third-party risk: outsourced components become silent blockers if third-party responsibilities and deliverables are not in the resource and timeline sections of the plan.

Practical 30/60/90-day execution plan

This requirement needs speed, but you can phase it without guessing exact effort.

First 30 days (establish the mechanism)

• Publish the Objective Delivery Plan template with mandatory fields mapped to Clause 6.2.2. ¹
• Build the objectives-to-plans register and populate it with current objectives.
• Pick one or two objectives and run the full workflow end to end (plan, approval, work linkage, evaluation definition).
• Define where evidence lives and who owns document control.

By 60 days (make it the default)

• Require a completed plan for every objective in the register.
• Train service owners and process owners on how to write evaluation criteria that can be evidenced.
• Add governance: recurring review agenda, status reporting format, and change control rules for plan updates.
• Add third-party dependency check prompts into the template (inputs, constraints, acceptance evidence).

By 90 days (prove it runs and is auditable)

• Complete at least one objective plan cycle through closure, including documented evaluation results. ¹
• Run an internal spot check: select a sample of objectives and confirm each has the five required planning elements plus evidence.
• Fix weak points: missing approvals, weak evaluation definitions, or poor traceability links.
• Prepare an audit-ready “objective pack” export: objective statement, plan, approvals, work links, evaluation report, closure record.

Frequently Asked Questions

Do I need a separate plan for every objective, or can one program plan cover multiple objectives?

You can group objectives under one program plan if the plan still clearly addresses what will be done, resources, responsibility, timing, and evaluation for each objective. Auditors will still expect traceability from each objective to specific actions and evaluation criteria. ¹

What counts as “resources” under Clause 6.2.2?

Treat resources broadly: people capacity and skills, tooling, budget approvals where applicable, and third-party deliverables that your plan depends on. Document the constraint and who commits it. ¹

Can “when it will be completed” be a milestone rather than a calendar date?

Yes, if the completion trigger is clear and you can show progress against it. The point is controlled timing and an auditable basis for determining completion. ¹

How detailed does the evaluation method need to be?

Detailed enough that an independent reviewer can repeat the evaluation from defined data sources and reach the same conclusion. Record metric definitions, data source, reviewer, and where the review evidence is stored. ¹

We rely heavily on third parties. Do their tasks need to be inside our plan?

If achieving the objective depends on third-party work or service levels, include those dependencies in the “resources” and “what will be done” sections, and define what evidence you will accept as completion. Keep your internal accountable owner responsible for driving third-party follow-through. ¹

What’s the minimum evidence auditors want to see for this clause?

A plan per objective (or a clearly mapped program plan) showing actions, resources, owner, timing, and evaluation method, plus proof you executed and reviewed outcomes. Missing evaluation evidence is a common failure point. ¹

Footnotes

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