Plan the service management system

Clause 6.3 is a planning requirement, not a paperwork requirement. As a Compliance Officer, CCO, or GRC lead, your job is to force clarity: what the SMS will achieve, the work needed to make it real, and who is accountable for each piece. ISO/IEC 20000-1 does not prescribe a single template; it requires that your organization plans the SMS across establishment, implementation, maintenance, and continual improvement, including how planned changes to the SMS will be handled. ¹

In practice, this clause fails in two common ways. First, organizations treat “planning” as a one-time project plan for certification, then run the SMS through informal decisions and scattered meeting notes. Second, they produce high-level slideware that lacks “who/what/when/how,” so operators can’t execute consistently and auditors can’t verify control. Clause 6.3 is designed to prevent both outcomes by requiring an actionable plan that survives operational reality and planned change.

This page gives you a requirement-level implementation approach: scope, roles, step-by-step build, artifacts to retain, and audit-ready checkpoints so you can operationalize the plan quickly and keep it current.

Regulatory text

ISO/IEC 20000-1:2018 Clause 6.3 requires: the organization must plan for establishing, implementing, maintaining, and continually improving the service management system, including planned changes, and ensure the plan addresses who, what, when, and how to deliver the intended outcomes of the SMS. ¹

Operator interpretation (plain English):

• You must have a real, working plan for the SMS itself (governance, processes, measurement, improvements), not only a plan for IT operations.
• The plan has to be specific enough that a new service owner can read it and understand responsibilities, activities, timing/triggers, and the execution method.
• You must plan for change to the SMS (process changes, tooling changes, org changes) in a controlled way, not via ad hoc decisions. ¹

Plain-English interpretation of the requirement

Clause 6.3 asks a simple question: If someone challenged you to prove the SMS will deliver its outcomes, could you show a plan that makes execution predictable?
Predictable means:

• Accountability is named (role or person).
• Work is defined (deliverables and operating routines).
• Timing is defined (dates, cycles, or event triggers).
• Methods are defined (procedures, governance forums, change mechanisms, measurement). ¹

A good SMS plan also creates traceability:

• Intended outcomes → planned activities → owners → evidence produced.

Who it applies to

Applies to: organizations and service providers operating an SMS in scope for ISO/IEC 20000-1 certification or alignment. ¹

Operational contexts where this becomes “real”:

• Internal IT as a service provider to business units (shared services, enterprise IT).
• Managed service providers delivering services to external customers.
• Hybrid setups where third parties run parts of delivery (cloud, SaaS, outsourced operations). Clause 6.3 still expects you to plan the SMS, including how you govern third parties within your SMS activities, even though ISO/IEC 20000-1 Clause 6.3 itself does not list third-party specifics. ¹

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

Step 1: Define the SMS intended outcomes (make them auditable)

Create a short list of intended outcomes for the SMS that maps to your service management objectives. Keep it concrete (examples: consistent incident handling, controlled changes, reliable service reporting). The standard requires delivery of intended outcomes; your plan should name them and reference where they are defined. ¹

Evidence to produce: “SMS Intended Outcomes & Objectives” section within your SMS Plan.

Step 2: Build the “who/what/when/how” plan structure

Use a table-driven plan. Auditors and operators both prefer it.

Minimum plan fields (recommended):

• Workstream / SMS component (governance, process management, reporting, internal audit support, training, tool administration, continual improvement)
• Owner (role title, plus named individual where possible)
• Activities / deliverables
• Timing (calendar cadence or event trigger, such as “on major org change”)
• Method (procedure name, workflow tool, committee, change mechanism)
• Outputs/evidence (records created)

Practical tip: Put your “planned changes to the SMS” activities in the same plan, not in a separate doc that gets forgotten. Clause 6.3 explicitly calls out planned changes. ¹

Evidence to produce: SMS Plan (v1.0) with the required columns.

Step 3: Assign ownership and decision rights (RACI is helpful)

You need explicit accountability for:

• SMS owner (overall accountability)
• Process owners (incident, change, problem, service level, etc., as applicable in your SMS)
• Service owners
• Tool owners (ITSM platform, CMDB where in scope)
• Internal audit/compliance interface
• Change approval authority for SMS-level changes (process/tool/org changes)

A lightweight RACI reduces “orphan controls,” where a process exists but no one maintains it.

Evidence to produce: RACI or responsibility matrix referenced in the SMS Plan.

Step 4: Integrate the SMS plan into governance forums

A plan that is not reviewed does not control operations. Establish governance routines that:

• review plan progress,
• log deviations,
• approve planned SMS changes,
• capture improvement actions and owners.

This can be a service management steering committee, operational review, or existing governance body. The key is that it produces records tied back to the plan. ¹

Evidence to produce: meeting agendas, minutes, decision logs, action registers mapped to plan items.

Step 5: Define how “planned changes” to the SMS are proposed, assessed, approved, and implemented

Clause 6.3 requires planning that includes planned changes. Make it operational:

• Intake: how someone proposes a change (template, ticket type, or change request)
• Impact assessment: what you evaluate (process impact, training impact, tool/config impact, reporting impact)
• Approval: who approves and where the decision is recorded
• Implementation controls: communications, training, effective date, rollback plan where applicable
• Post-change validation: confirm adoption and evidence generation

Keep it proportional. You do not need to turn every wording change into bureaucracy, but you do need a consistent mechanism and proof it’s used. ¹

Evidence to produce: SMS change log, approved change records, updated procedures, training/comms artifacts.

Step 6: Connect the plan to measurement and continual improvement

Your plan must cover “maintenance and continual improvement.” That means:

• defined review cycles for key SMS documents and processes,
• a mechanism to log improvements (from audits, incidents, retrospectives, metrics trends),
• prioritization and tracking through completion,
• evidence that improvements were implemented and validated. ¹

Evidence to produce: continual improvement register, metric review notes, implemented improvement records, revised documentation versions.

Step 7: Operationalize with a single source of truth (avoid “plan sprawl”)

Operators lose confidence when the plan is spread across decks, spreadsheets, and chat threads. Put the SMS plan in a controlled repository with:

• version control,
• approvals,
• change history,
• clear links to supporting procedures and records.

If you use Daydream to manage compliance work, treat the SMS Plan as a controlled requirement workspace: assign owners, track tasks, attach evidence, and keep an audit-ready trail of planned changes, approvals, and outcomes without rebuilding the binder every audit cycle.

Required evidence and artifacts to retain

Keep artifacts that prove the plan exists, is owned, and is executed.

Core artifacts (retain and control):

• SMS Plan document with “who/what/when/how” for establishment, implementation, maintenance, continual improvement, and planned changes ¹
• Roles/responsibilities (RACI or responsibility matrix)
• Governance records: agendas, minutes, decision logs, action registers
• SMS change records: proposals, approvals, impact assessments, implementation notes
• Continual improvement register and closure evidence
• Training and communications artifacts for SMS changes (where applicable)
• Document control records: versions, approvals, publication dates

Retention approach (practical):

• Store each artifact with a clear naming convention and link it to the plan line item it supports.
• Ensure every recurring plan item produces a predictable record (meeting minutes, metric report, review sign-off).

Common exam/audit questions and hangups

Expect auditors to probe these points:

1. “Show me the plan.” They will ask for one plan that covers the SMS lifecycle, not just a project timeline. ¹
2. “Where does it say who does what?” Vague “IT team” language is a finding risk.
3. “How do you plan for and control changes to the SMS?” They want the mechanism and examples of it being used. ¹
4. “How do you know the SMS is maintained and improved?” Improvement registers that never close actions draw scrutiny.
5. “Prove this is not shelfware.” They will test execution: pick a line item and request the evidence output.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails audits	Fix
Treating the SMS plan as a certification project plan	Clause 6.3 includes maintenance and continual improvement, which require ongoing planning	Convert to an operating plan with recurring activities and triggers 1
No explicit “planned changes” method	Clause 6.3 explicitly includes planned changes	Create an SMS change intake/approval/log and use it 1
Owners named as teams only	Accountability becomes untestable	Assign role owners; name individuals where possible
Evidence doesn’t tie back to plan items	Auditors can’t trace execution	Add an “evidence/output” column and link records
Plan exists, governance doesn’t	No proof of operation	Put plan review onto a standing agenda and record decisions

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for ISO/IEC 20000-1 Clause 6.3. Practically, the risk is certification-related and operational: weak planning produces inconsistent service management outcomes, uncontrolled SMS changes, and gaps in accountability that show up as recurring incidents, failed changes, and audit findings. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize and draft)

• Appoint an SMS accountable owner and confirm scope boundaries for the SMS.
• Draft the SMS Plan in a table format with who/what/when/how across the lifecycle. ¹
• Stand up an SMS change log and define approval authority for SMS-level changes.
• Identify the minimum evidence set and set up a controlled repository.

Days 31–60 (operate the plan)

• Run the first governance cycle that reviews the SMS plan and logs actions.
• Socialize responsibilities with process and service owners; resolve overlaps and gaps.
• Pilot the planned-change mechanism with at least one planned SMS improvement (process update, reporting update, training update) and retain proof. ¹

Days 61–90 (prove repeatability)

• Tighten traceability: each plan line item links to an artifact produced in operations.
• Add continual improvement intake sources (audit findings, metrics, retrospectives) and track to closure.
• Perform an internal “audit-style” walkthrough: pick several plan items and confirm evidence exists, is current, and shows accountability.

Frequently Asked Questions

What counts as the “plan” for Clause 6.3?

A controlled document (or controlled workspace) that covers establishing, implementing, maintaining, and continually improving the SMS, including planned changes, and explicitly states who/what/when/how. ¹

Can we satisfy this with a project plan and a Gantt chart?

Only if it covers ongoing maintenance and continual improvement and clearly states who does what, when, and how after go-live. Most project plans stop at implementation and fail the maintenance/improvement expectation. ¹

Do we need a separate process for “planned changes to the SMS”?

You need a defined method and evidence it’s used; it can be integrated into existing change enablement if it clearly covers SMS-level changes (process/tool/governance changes) and produces records. ¹

How detailed do roles and responsibilities need to be?

Detailed enough that accountability is unambiguous and testable in an audit. Role titles with named owners are usually workable; “IT” or “operations” alone is usually too vague.

What will an auditor sample to test Clause 6.3?

They commonly sample plan line items, request the outputs (minutes, change records, improvement closures), then confirm the evidence matches the stated who/what/when/how. ¹

How can Daydream help without turning this into busywork?

Use Daydream to assign plan line items as owned tasks, collect evidence directly against each item, and maintain versioned change history for SMS changes so your audit trail stays intact across improvements and org changes.

Footnotes

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