What the Service Management Plan Is and Is Not
The Service Management Plan (SMP) is the primary governing document that describes how the organization will pursue its service management objectives. It is not the project plan for implementing ISO 20000 (that is a separate implementation project plan). It is not a collection of operational procedures (those are described separately). It is not a marketing document (though it may be used in governance discussions with clients or regulators). The SMP is the authoritative description of how the SMS is designed and how it will operate.
ISO 20000 Requirements for the SMP
ISO 20000-1:2018 Clause 6.2 requires the organization to establish, implement, and maintain a service management plan. The SMP must describe:
The organization's approach to plan, design, transition, deliver, and improve services.
The service management objectives and how they will be achieved.
The organizational roles and responsibilities for service management.
The resources required for service management.
The schedule and timeline for service management activities.
The SMP must be kept current and reviewed at planned intervals (typically at least annually, more frequently during the first one to two years after implementation).
Who Owns the Service Management Plan
The SMP is owned by the SMS owner or service management manager--a role with responsibility for overall SMS governance and effectiveness. The SMP is approved by top management (typically the Chief Information Officer, CEO, or equivalent). The SMP is reviewed and updated on a scheduled basis (typically at the annual management review, but also whenever significant organizational, service, or SMS objective changes occur).
Required Content of the Service Management Plan
An effective SMP is organized into clear sections, each addressing a distinct governance dimension:
(1) Scope section: explicitly states which services and organizational boundaries the SMP covers (aligned to the scope statement produced during Phase 1).
(2) Service management objectives section: describes the specific, measurable objectives the SMS is pursuing in the current planning period. Objectives must have quantified targets (e.g., "Achieve 95% incident first-response SLA compliance") and measurement approaches. Objectives change from year to year as the SMS matures.
(3) Roles and responsibilities section: documents the SMS organizational structure--who is responsible for service management overall, who owns each major practice, what the internal audit function reports to, etc. A RACI (Responsible, Accountable, Consulted, Informed) matrix for key SMS functions can be helpful here.
(4) Resources section: describes what resources (people, tools, budget) are allocated to SMS operation and improvement. This section makes explicit the resource commitment top management is making to the SMS--no surprises about effort or cost.
(5) Service management practices section: describes how each Clause 8 practice (incident, problem, service request, change, release, configuration, service portfolio, relationship, continuity, availability, capacity, information security) is implemented and governed. This section can be brief, with detailed practice procedures referenced separately.
(6) Service portfolio summary: lists all services managed within the SMS scope, with references to individual SLAs. This connects the SMP to the actual service offerings the organization provides.
(7) Supplier arrangements section: identifies key suppliers whose services contribute to in-scope services, and describes how supplier relationships are managed.
(8) Internal audit and management review schedule: specifies when internal audits and management reviews will be conducted, and what they will cover.
(9) Improvement program section: describes current improvement priorities and their status. This shows that the SMS is being actively improved, not static.
(10) Plan review and update mechanism: describes how and when the SMP is reviewed and updated, and who approves changes.
| KEY CONCEPT | The SMP is the single document that a new top manager, a regulator, or an external auditor would read to understand how the SMS works. It must be complete, accurate, and current. If a new CIO takes over, they should be able to read the SMP and understand the SMS approach within an hour. If POJK requests documentation of the SMS, the SMP is the primary document to provide. |
Length and Format
A realistic SMP for a mid-sized organization (50-200 FTE in IT operations, 20-50 in-scope services) is typically 15-30 pages. It is not a 100-page operations manual. The SMP provides governance overview and references operational procedures for detailed process descriptions. For example, the SMP might say "Incident management is described in Procedure SM-IM-001" rather than including the entire incident management procedure in the SMP.
Format: clearly structured with numbered sections, headings, and references to supporting documents. Tables (roles and responsibilities, service list) should be easy to read. Version control information (date, version number, approval signatures) should be clear.
The SMP as a Living Document
A common failure is producing the SMP for the ISO 20000 implementation, then never updating it after certification. An effective SMP is a living document that is actively maintained.
Version control: the SMP should have version numbers, dates, and approval sign-offs. Each update should be tracked (what changed, why, who approved).
Update triggers: The SMP should be updated when: new services are added to scope, new customers are added, new objectives are defined, organizational structure changes, top management changes, operational experience suggests that the planned approach is not working as designed, or management review identifies needed improvements.
Update frequency: at minimum, the SMP should be formally reviewed annually. In the first 1-2 years after SMS implementation, quarterly review is common as the organization learns what works and refines its approach.
Integration with Related Documents
The SMP sits at the top of the SMS documentation hierarchy:
Scope statement: the SMP references and is consistent with the scope statement.
Service portfolio: the SMP references the service portfolio, which lists all services in scope.
Service level agreements: the SMP references the set of SLAs that define service requirements.
Practice procedures: the SMP references the detailed procedures for each Clause 8 practice (incident management procedure, change management procedure, etc.).
CMDB: the SMP describes the approach to configuration management and references the CMDB.
Supplier contracts: the SMP references key supplier relationships and their role in supporting in-scope services.
If these documents are inconsistent with the SMP, it is a red flag. For example, if the SMP says "Change management is fully implemented and operational," but the change management procedure is outdated and not being followed, auditors will note this inconsistency.
The SMP and Audit
Stage 1 auditors use the SMP as the primary lens on SMS design maturity. They will assess: Is the SMP complete? Does it address all required elements? Is it realistic given the organization's scope and resources? Are the objectives measurable? Are roles and responsibilities clearly assigned? Does the SMP appear to reflect a thoughtful, deliberate design?
Stage 2 auditors will check whether SMS operation matches what the SMP describes. For example, if the SMP says "Incident management is designed to resolve critical incidents within 4 hours," Stage 2 auditors will sample incident records to see if this is actually happening. If the SMP version being described in interviews is different from the controlled version in the documentation system, this is a finding.
Common audit issues: SMP is generic and does not reflect the organization's specific situation; SMP version on file is outdated and not being used operationally; SMP objectives are not measurable ("improve incident management" vs. "achieve 95% incident SLA compliance"); roles and responsibilities are unclear or absent; SMP does not align with the service portfolio or customer contracts.
Common SMP Failures
Produced for the implementation, never updated after certification: organizations invest in creating a good SMP, then do not maintain it. Within 18 months, the SMP no longer reflects current state, and it loses value as a governing document.
Lacks measurable objectives: an SMP that says "Improve incident response" is not useful. An SMP that says "Achieve 95% incident resolution SLA compliance within 12 months" is actionable and measurable.
Confuses the SMP with operational procedures: some organizations try to include detailed procedure steps in the SMP, making it too long and too operational. The SMP should be governance-level; procedures should be separate.
Does not reference the service portfolio: if the SMP does not list the services being managed, it is incomplete. The service portfolio list (brief descriptions) should be in the SMP or clearly referenced.
Top management sign-off missing: an SMP without top management approval is not credible. Auditors will ask who approved the SMP and when.
Not used operationally: if the SMP is a document created for the audit and then filed away, it is not serving its purpose. The SMP should be actively used to guide SMS decisions and explain SMS approach to new team members, customers, and stakeholders.
| IMPORTANT | An SMP that describes processes differently from how they are actually implemented is evidence of an SMS operating outside its documented design. This is a significant audit risk. If the organization discovers during implementation that the designed approach is not working as planned, the SMP must be updated to match the actual approach. Auditors will accept practical adjustments to the original design if the SMP is kept current. |
Building the SMP: Process and Timeline
SMP development typically takes 6-10 weeks during Phase 2:
Week 1-2: Conduct workshops with key stakeholders (SMS coordinator, practice owners, customer account managers, operations leaders) to understand current state and desired objectives. Identify service portfolio, key suppliers, and organizational boundaries.
Week 3-4: Develop draft SMP addressing all required sections. Allocate roles and responsibilities, define objectives, document the planned practices approach.
Week 5-6: Internal review--SMS coordinator, key stakeholders review draft for completeness, accuracy, and feasibility. Revise based on feedback.
Week 7-8: Management review and approval--SMP is presented to top management for review and approval. Top management may request refinements to objectives, resource allocation, or timeline.
Week 9-10: Final approval, version control, distribution--approved SMP is formally versioned, approved signatures applied, and distributed to SMS team.
| BITLION INSIGHT | Bitlion GRC provides a pre-built SMP template aligned to ISO 20000 Clause 6 requirements, with section-by-section guidance, examples from Indonesian IT organizations, and decision frameworks for defining objectives and roles. Organizations using Bitlion SMP templates reduce SMP development time from 10-12 weeks to 6-8 weeks while improving quality and completeness. |
Service Management Plan Content Checklist
| Section | Required Content | ISO 20000 Clause Reference | Common Failure Mode |
|---|---|---|---|
| Scope | Services, customers, organizational units, exclusions with justifications | 4.3, 6.2 | Vague or incomplete scope; no justification for exclusions |
| Objectives | Measurable service management objectives with targets and measurement approach | 6.2(a) | Objectives not measurable; no targets; no measurement plan |
| Roles & Responsibilities | SMS organizational structure; RACI for key functions; reporting relationships | 5.3, 6.2(c) | Unclear responsibilities; no RACI; missing key roles |
| Resources | Budget, personnel, tools, training allocation for SMS operation and improvement | 6.2(c) | Resources not specified; unclear funding; no budget commitment |
| Practices | Approach to each Clause 8 practice; references to detailed procedures | 8.1-8.12, 6.2(b) | Generic descriptions; no procedure references; practices not aligned to scope |
| Service Portfolio | List of in-scope services; references to SLAs | 6.2(b) | Missing service list; no SLA references; portfolio not current |
| Suppliers | Key suppliers, their role, how relationships are managed | 8.7, 6.2 | No supplier identification; no supplier agreements; no relationship management plan |
| Internal Audit Schedule | Audit schedule, auditor competence plan, audit approach | 9.2, 6.2 | No schedule; auditors not competent; no planned audit coverage |
| Management Review Schedule | Management review frequency, what will be reviewed, decision authority | 9.3, 6.2 | Review frequency not defined; no defined topics; decision authority unclear |
| Improvement Program | Current improvement initiatives, status, owners, timelines | 10, 6.2(c) | No improvement initiatives identified; status not tracked; no ownership |