Service Management System Manual

1. Purpose

This manual describes how the Organisation plans, establishes, operates, monitors and improves its service management system (SMS) so that the services it provides to customers are designed, delivered and supported in a controlled, repeatable way. It is the top-level document of the service management library: it states what the SMS covers, who is accountable for it, how its processes connect, and which procedure, statement or plan carries the detail for each requirement.

The manual follows the clause order of ISO/IEC 20000-1:2018 (clauses 4 to 10) so that a customer, auditor or new team member can see how each requirement is met without reading every document. It records the Organisation's own decisions; it does not restate the standard.

• Give top management one place that shows the SMS is planned, resourced, measured and improving.
• Let any team member find the document that governs a task within [two minutes] using the document map in this manual.
• Show a customer or auditor which document and which record evidence each requirement (Annexure A and Annexure B).
• Fix the vocabulary used by every other SMS document so that terms mean the same thing everywhere.

2. Scope

This manual applies to the SMS as defined in the scope statement held in the SMS Scope and Service Management Plan and summarised in the Context of the Organization. It binds every employee, contractor and temporary worker who designs, builds, transitions, operates, supports or manages an in-scope service, and every supplier that delivers part of an in-scope service under contract.

• In scope: the services listed in the service catalogue as [live and in-scope], the service components, infrastructure, applications and tools used to deliver them, and the locations from which they are delivered.
• In scope: all SMS processes in clauses 8.1 to 8.7 of the standard, including parts performed by suppliers or by internal groups outside the service management team.
• Out of scope: [named internal services, pilot services or business units] that are not offered to customers. Each exclusion is justified in writing, approved by top management, and re-examined at every management review.
• Out of scope: the personal devices and accounts of staff, except where they are used to deliver an in-scope service.

3. Terms and definitions

The terms below are used consistently across the SMS library. Where a procedure uses a more specific term it defines it in its own terms section.

4. Roles and Responsibilities

Roles are defined by what the person is accountable for, not by job title. One person may hold several roles in a small organisation, but the roles of change authority and change requester for the same change, and of auditor and auditee for the same process, must not be held by the same person.

5. Structure of the Service Management System

5.1 How the SMS fits together

The SMS is a set of linked processes governed by one policy and one set of objectives. Clause 4 to 7 documents set the frame: who the Organisation serves, what it has committed to, who is responsible and what resources and information it needs. Clause 8 documents define the operational processes. Clause 9 and 10 documents measure how the processes perform and drive improvement. Each process takes inputs from another and produces outputs that another uses, so a weakness in one shows up as symptoms in several.

• Plan: context, policy, objectives, risks, the service management plan and the service catalogue define what is to be delivered.
• Do: design and transition, change, release, incident, request and problem processes deliver and support services.
• Check: monitoring, service reporting, internal audit and management review show whether services and processes meet targets.
• Act: nonconformity handling and continual improvement turn findings into funded, tracked actions.

5.2 Document hierarchy

Levels 1 and 2 are approved by top management. Level 3 is approved by the process owner and the management representative. Level 4 is approved by the process owner. Level 5 is created by doing the work and is controlled under the Documents and Records Management Procedure and the retention schedule in section 9.5.

5.3 Process interactions

The principal hand-offs between processes are listed below. A procedure must state which of these it sends and receives.

6. Context of the Organization

Clause 4 of the standard asks the Organisation to understand its situation before it designs a management system. The decisions are recorded in the Context of the Organization and the SMS Scope and Service Management Plan; this section summarises how they are made and kept current.

6.1 Understanding the organization and its context

Top management, the management representative and the service owners identify external and internal issues that affect the SMS's ability to deliver its intended outcomes. External issues cover legal and regulatory requirements, market and customer expectations, technology change, supplier markets and threats. Internal issues cover strategy, structure, skills, culture, tooling, and the maturity of existing processes.

• The issues are recorded in the Context of the Organization with the effect each has on services and the response chosen.
• The register is reviewed at least every [6 months], at each management review, and after any significant change in strategy, ownership, law or technology.
• An issue that creates a risk is carried into the risk and opportunity register described in section 8.1; an issue that creates an opportunity is carried into the improvement log.

6.2 Understanding the needs and expectations of interested parties

The Organisation lists every interested party relevant to the SMS and, for each, the needs and expectations that become requirements: contractual terms, regulatory duties, service levels, communication, information security and cost. Customers and users are consulted through the Business Relationship Management Procedure; suppliers through the Supplier Management Procedure; staff through team meetings and the annual survey.

• Each party has a named owner on the Organisation's side who maintains the entry.
• A requirement becomes a compliance obligation only after the owner and the management representative confirm it is binding and who must meet it.
• Legal requirements are confirmed with [the legal adviser] at least every [12 months]; the Organisation does not rely on this manual as legal advice.

6.3 Determining the scope of the service management system

The scope states which services, which locations, which organisational units and which processes the SMS covers, and what is excluded and why. It must be consistent with the service catalogue, the contracts in force and the context analysis. It is documented in the SMS Scope and Service Management Plan and approved by top management.

6.4 Service management system

The Organisation establishes, implements, maintains and continually improves the SMS, including the processes needed and their interactions. For each process it defines the inputs and outputs, the sequence and interaction with other processes, the criteria and methods used to operate and control it, the resources, the responsibilities, the risks and the measures. Process descriptions are the procedures named throughout this manual. The management representative keeps Annexure A, the register of SMS documents, so that the full set of processes can be seen on one page.

7. Leadership

Clause 5 places accountability for the SMS with top management. The commitments below are examined at each management review and tested during internal audit.

7.1 Leadership and commitment

Top management demonstrates leadership and commitment by acting on the following, each of which is evidenced in the record shown.

Top management also ensures the service management plan exists, that the scope is kept current, and that the SMS is integrated with the Organisation's information security management system where both apply.

7.2 Service management policy

Top management establishes the Service Management Policy. It is appropriate to the purpose of the Organisation, provides a framework for setting objectives, includes a commitment to satisfy applicable requirements and a commitment to continually improve the SMS and the services. The policy is communicated within the Organisation, available to interested parties on request, and reviewed at least every [12 months]. The text is held in the Service Management Policy and the related objectives in SMS Objectives.

• The policy is displayed on [the intranet home page] and given to every new joiner at induction.
• Customers receive a summary with their service level agreement and can request the full policy through their customer representative.
• Any change to the policy is approved by top management, versioned, and announced within [5 working days].

7.3 Organizational roles, responsibilities and authorities

Top management assigns and communicates the responsibilities and authorities for the SMS and its processes. The roles are defined in section 4 and in each procedure. The management representative has the authority to stop a release, suspend a process change, or raise a nonconformity at any level of the Organisation if the SMS requirements are not being met.

• A process owner and a process manager are named for every process in Annexure A, and the names are published on [the intranet].
• Where a post is vacant for more than [10 working days], top management names an acting holder in writing.
• Delegates are recorded; accountability stays with the named role.
• Authority levels for approving changes, expenditure, exceptions and service level concessions are set in the delegation of authority table in the SMS Scope and Service Management Plan.

8. Planning

Clause 6 covers how the Organisation decides what could go wrong or be gained, what it wants to achieve, and how it will put the management system in place.

8.1 Actions to address risks and opportunities

When planning the SMS, the Organisation considers the issues in the Context of the Organization and the requirements of interested parties, and determines the risks and opportunities that must be addressed to give assurance that the SMS will achieve its outcomes, prevent or reduce undesired effects, and achieve improvement. Risks to services, to the SMS and to customers are held in one register, assessed with the method in the Risk Management Policy.

• Actions to address a risk are planned into the service management plan, with an owner, a due date and the way their effectiveness will be judged.
• Risks from suppliers, change, capacity, continuity and security are linked to the matching process owner, who reviews them at least every [3 months].
• Opportunities (for example automation, new service offerings or consolidation of tools) are assessed for benefit, cost and risk before they are adopted and are tracked in the improvement log.
• Where a risk touches information security, it is also recorded in the information security risk register under the Risk Management Policy.

8.2 Service management objectives and planning to achieve them

8.2.1 Establish objectives

Objectives are set for the SMS and the services at relevant functions and levels. Each is consistent with the policy, measurable, takes account of applicable requirements, is monitored, communicated and updated as appropriate. The objectives, their owners, targets, measures and review frequency are held in SMS Objectives.

• Objectives are set annually by top management on proposals from service owners and process owners.
• Each objective has one named owner and one measure; where two objectives conflict, top management decides the priority.
• The objective is retired or changed only through the management review.

8.2.2 Plan to achieve objectives

For each objective the plan states what will be done, what resources are needed, who is responsible, when it will be completed, and how results will be evaluated. The plan is part of the SMS Scope and Service Management Plan.

8.3 Plan the service management system

The Organisation plans the SMS to meet the requirements of the standard and to achieve the objectives. The SMS Scope and Service Management Plan covers the activities, the services in scope, the processes to implement or change, the resources, the roles, the timetable, the methods for monitoring and measuring, the criteria for accepting changes to the SMS, and how the SMS interacts with the information security management system. The plan is reviewed at least every [6 months] and whenever the scope or the Organisation's services change materially.

• A change to the SMS itself (for example merging two processes) is treated as a change and goes through the Change Management Procedure.
• The plan includes the service management plan for each new or substantially changed service, produced under the Service Design and Transition Procedure.
• Implementation of the plan is reported at every management review.

9. Support of the Service Management System

Clause 7 covers the people, information and tools that the SMS depends on.

9.1 Resources

The Organisation determines and provides the resources needed to establish, implement, maintain and continually improve the SMS and to operate the services. Resource needs are raised by process owners and service owners in the annual plan, and in-year through a resource request that the management representative reviews within [10 working days].

9.2 Competence

The Organisation determines the competence needed of people doing work that affects service performance, ensures they are competent on the basis of education, training or experience, takes action to acquire competence where it is missing, and keeps evidence.

• Each role in section 4 has a competence profile listing required skills, certifications that are desirable, and training the role-holder must complete within [3 months] of joining.
• Competence is checked at recruitment, at the annual appraisal, and when a person moves to a new role.
• Effectiveness of training is checked by assessment, supervised work, or review of tickets and records within [3 months] of completion.
• Training, assessment and appraisal records are kept by Human Resources in line with the HR Security Policy.

9.3 Awareness

People doing work under the Organisation's control are made aware of the Service Management Policy, the objectives that relate to their work, how they contribute to the effectiveness of the SMS and the benefits of improved performance, and the consequences of not conforming to SMS requirements. They also learn how their work fits into the service lifecycle.

• Awareness is delivered at induction, in an annual refresher of [45 minutes], and in short briefings after significant incidents or audit findings.
• At least [95 percent] of staff must complete the annual refresher within [30 days] of assignment.
• Awareness is tested with a short quiz and by sampling tickets for correct use of categories, priorities and closure codes.

9.4 Communication

The Organisation determines the internal and external communications relevant to the SMS: what is communicated, when, to whom, how, and who is responsible. The rules are set in the Communication Procedure.

9.5 Documented information

9.5.1 General

The SMS includes the documented information required by the standard and the documented information the Organisation has determined necessary for effectiveness. This covers the policy and objectives, the service management plan, the catalogue, SLAs, OLAs and supplier contracts, the process procedures and the records they produce. The extent varies with the size and complexity of services, the competence of staff and the risk to customers. Annexure A is the SMS document register.

• Documents required by the standard are marked in Annexure A so that none is removed in error.
• The documented information on the plan for each service, the catalogue entries, SLAs, policies and process definitions are maintained as documents; tickets, logs and review minutes are maintained as records.

9.5.2 Creating and updating

When creating or updating documented information the Organisation ensures appropriate identification and description (title, date, author, reference number), format (template, language, media), and review and approval for suitability and adequacy. Every document carries a unique code, a version number and a document history table.

1. DraftThe author uses the controlled template, assigns the next code and version, and describes the change in the document history.
2. ReviewThe process owner and one peer reviewer check accuracy and consistency with other SMS documents within [5 working days].
3. ApproveThe approver named in Annexure A signs off; policies and plans are approved by top management.
4. PublishThe document controller replaces the old version in the document management system, retains the old one as superseded, and announces the change.

9.5.3 Control of documented information

Documented information is controlled so that it is available and suitable for use where and when needed, and is adequately protected against loss of confidentiality, improper use or loss of integrity. Control covers distribution, access, retrieval, use, storage and preservation, control of change, and retention and disposal.

9.5.4 Service management system documented information

The SMS maintains the following documented information, each named in Annexure A. This list is a minimum and the Organisation may add more.

• Scope of the SMS; Service Management Policy; SMS Objectives; Context of the Organization and the register of interested parties.
• The service management plan and the plan for each service; the service catalogue; service level agreements; operational level agreements; underpinning contracts.
• Procedures for each process in clause 8, including the service requirements and the criteria for deciding if a service is accepted.
• Records of competence, audit, management review, nonconformities and corrective actions, service reports, continuity tests, and capacity and availability plans.

9.6 Knowledge

The Organisation determines and maintains the knowledge needed to operate the SMS and to deliver and support services, so that it can address changing needs and trends. Sources include lessons learned, post-incident reviews, supplier documentation and customer feedback.

• A knowledge base holds known errors, workarounds, runbooks and service information; articles have an owner and are reviewed every [12 months].
• Knowledge held by a single person is identified in the risk register and shared through documentation, pairing or cross-training within [6 months].
• Knowledge acquired in projects is added to the service documentation before the project is closed.

10. Operation of the Service Management System

Clause 8 contains the processes through which services are planned, delivered, supported and assured. Each subsection states how the requirement is met, the rules that bind the Organisation, and the document and evidence that prove it.

10.1 Operational planning and control

The Organisation plans, implements and controls the processes needed to meet service requirements and to carry out the actions in clause 6. It does this by setting criteria for each process, controlling processes against those criteria, keeping documented information to show the processes were carried out as planned, controlling planned changes and reviewing the consequences of unintended ones, and ensuring that outsourced processes are controlled.

• Process criteria are the targets in the key performance indicator table of each procedure.
• Every planned change to a process or service goes through the Change Management Procedure; an unplanned change is recorded as an incident and reviewed at the next process review.
• The management representative reviews a sample of [10] tickets per process each month for adherence to the procedure and reports the finding to the process owner.
• Outsourced processes are listed in Annexure A with the supplier, the contract and the control used (section 10.2.3).

10.2 Service portfolio

10.2.1 Service delivery

The Organisation delivers services according to the service management plan, the catalogue and the agreements with customers. The portfolio of services, with their status (proposed, in design, live, being retired), is held by the service owners and reviewed with the management representative every [quarter].

• A service enters the portfolio only after top management or its delegate approves the business case.
• A service leaves the portfolio only through the retirement steps in the Service Design and Transition Procedure.

10.2.2 Plan the services

For each new or changed service the Organisation determines the customer and service requirements, sets service objectives, assesses risk, identifies who will perform each activity, and defines how the service will be measured. Output is a service plan that is reviewed at the service design review and approved by the service owner. Planning is described in the Service Design and Transition Procedure.

10.2.3 Control of parties involved in the service lifecycle

Where another party performs part of the service lifecycle or a process of the SMS, the Organisation remains accountable and must show control. The party may be a supplier, an internal group outside the SMS, or a customer who performs part of the service. The Organisation determines and applies criteria for the evaluation and selection of such parties, defines the process or service that each performs, and monitors performance.

Detail is in the Supplier Management Procedure and the Supplier Relationship Management Procedure of the information security library for suppliers that handle information. Accountability for the outcome is not transferred; the service owner retains it.

10.2.4 Service catalogue management

The Organisation creates and maintains one or more service catalogues. Each entry states what the service is, its owner, the hours it is available, the support tier, the dependencies, the SLA reference, and the categories used for incidents and requests. The catalogue is the basis for the SLA, the ticket categories and the customer communications.

• Each entry is reviewed by its service owner at least every [6 months].
• The catalogue is published to customers and users in a form appropriate to each audience; a technical view is kept for support teams.
• A service that is live and not in the catalogue is a nonconformity and is raised at once.
• Detail is in the Service Catalogue Management Procedure.

10.2.5 Asset management

The Organisation manages the assets used to deliver services across their life: acquisition, identification, ownership, use, maintenance, licensing, and disposal. Licensed software is tracked for compliance with licence terms, and assets are reconciled with the records at least every [12 months]. Rules are set in the Configuration and Asset Management Procedure and, for information security aspects, the Asset Management Procedure.

10.2.6 Configuration management

The Organisation records the configuration items needed to deliver each service, their attributes, and the relationships between them, in a configuration management database. Records are updated through change and release records, and a verification compares the database with the live environment.

10.3 Relationship and agreement

10.3.1 General

The Organisation manages the relationships with customers, users and suppliers through three connected processes: business relationship management for customers and users, service level management for the agreed targets, and supplier management for the contracts that support delivery. They share one set of service definitions from the catalogue.

10.3.2 Business relationship management

The Organisation identifies its customers, users and other interested parties, and for each customer names a service owner and a customer representative. It establishes regular communication, collects feedback, measures satisfaction, and handles complaints and compliments.

Detail is in the Business Relationship Management Procedure.

10.3.3 Service level management

The Organisation agrees the service level targets with each customer, documents them in service level agreements, monitors performance against them, and reports. Targets are set from the customer's needs, the capability of the service and the limits of operational level agreements and underpinning contracts; the Organisation does not promise a target that its OLAs and contracts cannot support.

• Each SLA has an owner, a review date, defined hours of service, targets for availability, response and resolution, and a way of reporting.
• Targets are measured from [the ticketing tool and monitoring system] and reported [monthly] to the customer.
• A missed target triggers a cause analysis and an improvement action; repeated misses are raised at the management review.
• An SLA is reviewed at least every [12 months] and when the service changes materially.
• Detail is in the Service Level Management Procedure.

10.3.4 Supplier management

The Organisation manages each external supplier and each internal group that contributes to a service so that the agreed levels are met. Suppliers are classified by criticality, assessed before selection, bound by contract, monitored, and reviewed. Exit plans are held for critical suppliers.

Detail is in the Supplier Management Procedure. Where the supplier handles information, the Organisation also applies the Supplier Relationship Management Policy and the Supplier Relationship Management Procedure from the information security library.

10.4 Supply and demand

10.4.1 Budgeting and accounting for services

The Organisation budgets and accounts for the cost of services so that it knows what each service costs to deliver and whether charges (if any) recover that cost. Costs are recorded by service, under agreed cost categories, and compared to budget at least [monthly].

• Service owners review their actual cost against budget [monthly]; variance above [10 percent] requires an explanation to the management representative.
• Changes to charges follow the customer agreement and are communicated at least [30 days] before they take effect.

10.4.2 Demand management

The Organisation monitors demand for services, forecasts it, and plans how to meet or shape it. Demand is tracked from ticket volumes, usage statistics, sales forecasts and customer plans; patterns of business activity are recorded for each service so that capacity and staffing are planned ahead of need.

• A demand forecast is produced for each in-scope service every [quarter] and sent to the capacity manager.
• Seasonal peaks and customer launches are recorded in the demand calendar and communicated at least [30 days] ahead.
• Detail is in the Capacity and Demand Management Procedure.

10.4.3 Capacity management

The Organisation ensures that capacity (technology, people, facilities and budget) meets current and future agreed demand. A capacity plan is produced for each service, monitored against thresholds and updated when forecasts change.

Capacity data is reviewed [monthly] and the plan is reviewed [every 6 months]. Detail is in the Capacity and Demand Management Procedure and, for information security aspects, the Capacity Management and Planning Procedure.

10.5 Service design, build and transition

10.5.1 Change management

The Organisation controls changes to services, service components and the SMS so that harm is minimised and benefits are achieved. Every change is recorded, assessed for risk and impact, categorised, authorised at the right level, scheduled, implemented, reviewed and closed. Emergency changes are allowed but are reviewed after the event.

Detail is in the Change Management Procedure. The information security aspects are in the Change Management Policy and Procedure.

10.5.2 Service design and transition

New services and changes with significant effect are designed, built, tested and moved to live in a planned way. Service design records the requirements, the architecture, operational acceptance criteria, the financial case and the support arrangements. Transition produces a service that is ready to operate: tested, documented, staffed, in the catalogue, covered by an SLA and handed to the support teams.

1. RequestA service owner or customer raises a new or changed service request; the management representative confirms it falls within the SMS scope.
2. PlanThe service owner creates the service plan and a transition plan, and puts the matching changes into the change schedule.
3. DesignThe design team documents requirements and design; risk, security and cost are reviewed at the design review.
4. Build and testThe build is tested against the acceptance criteria. Test evidence is attached to the change.
5. AcceptThe service owner and the customer representative agree the service meets the criteria in the Service Evaluation Criteria.
6. Go live and reviewThe release is deployed; a post-implementation review is held within [30 days] and results are recorded.

Detail is in the Service Design and Transition Procedure.

10.5.3 Release and deployment management

Releases are planned, built, tested and deployed so that changes reach the live environment in a controlled way. Each release has a release plan, deployment steps, a rollback plan, entry and exit criteria, and a named release manager. The live configuration is verified after deployment, and the configuration database is updated.

• Releases are scheduled on the release calendar in agreed windows; out-of-window releases follow the emergency change path.
• No release is deployed without a successful test in an environment that matches production closely enough for the risk.
• After deployment, the release manager confirms success against the exit criteria and the service desk is briefed on changes in behaviour.
• Detail is in the Release and Deployment Management Procedure.

10.6 Resolution and fulfilment

10.6.1 Incident management

The Organisation restores service as quickly as possible after an incident. Incidents are logged, classified, prioritised, assigned, escalated, resolved, and closed, and users are kept informed. A major incident has its own process with an incident manager, regular communication, and a post-incident review.

Targets are measured in the hours of service of the SLA. The complete matrix, escalation path and critical incident process are in the Service Operating Model; steps are in the Service Incident Management Procedure. Incidents that are also security events are handled under the Information Security Incident Management Policy and the Incident Management Procedure.

10.6.2 Service request management

Service requests are fulfilled through defined procedures. Each request type has a catalogue entry, a form, an approval path where needed, a fulfilment owner and a time target. Users can see the status of their request.

• Standard requests are pre-approved and fulfilled within [2 working days] unless the catalogue states otherwise.
• Requests that need access follow the User Access Management Procedure and are approved by the system owner.
• A request that cannot be fulfilled is closed with a reason; the user is told why and what to do next.
• Detail is in the Service Request Management Procedure.

10.6.3 Problem management

Problems are identified from incidents, trend analysis, supplier advice and monitoring, and their root causes are investigated. A problem record holds the root cause analysis, the workaround, the known error record and the permanent fix, which is delivered through the change process. Problems are prioritised by the harm they cause.

Detail is in the Problem Management Procedure and, for information security, the Problem Management Policy and Process.

10.7 Service assurance

10.7.1 Service availability management

The Organisation agrees availability requirements with customers, assesses the risks to availability, plans for them, monitors availability, and acts when it falls short. Availability targets are included in each SLA and are measured from monitoring data, not from reports of outages alone.

• Each service has an availability plan reviewed [annually] and after each major incident.
• Single points of failure in critical services are listed and either removed or accepted by the service owner.
• Planned downtime is agreed with the customer, scheduled in the change calendar and excluded from availability only if the SLA says so.
• Detail is in the Availability and Service Continuity Management Procedure.

10.7.2 Service continuity management

The Organisation identifies the services most important to customers, assesses the risks to continuity, and maintains plans that allow it to meet agreed service levels in a disaster or other serious disruption. Plans are tested and the results are used to improve them.

• Continuity plans state the trigger, the decision maker, the steps, the contacts and the criteria for returning to normal operations.
• Continuity arrangements are reviewed after each test, each major incident and each material change to a service.
• Detail is in the Availability and Service Continuity Management Procedure and, for information security aspects, the BCP and DR Procedure.

10.7.3 Information security management

The Organisation protects the confidentiality, integrity and availability of information within the SMS and of the services. The SMS and the information security management system share controls; the SMS applies the Information Security Policy and the controls selected by risk assessment. Security aspects of service processes (access in requests, security incidents, changes with security impact, supplier access) are described in Information Security Management for Services.

• Security incidents are recorded in the ticketing tool, classified under the Information Security Incident Management Policy, and linked to service incidents when both occur.
• Security requirements are set when services are designed and tested before service acceptance.
• Changes to security controls follow the Change Management Procedure; emergency security fixes follow the emergency path.
• Security performance of services is reported with other service measures at the management review.

11. Performance Evaluation

Clause 9 asks the Organisation to know whether the SMS and the services work. It does this through measurement, internal audit, management review and service reporting.

11.1 Monitoring, measurement, analysis and evaluation

The Organisation determines what needs to be monitored and measured, the methods, when monitoring and measuring takes place, and when results are analysed and evaluated. It evaluates the performance and effectiveness of the SMS and the services, and the performance of each process against its objectives.

Measures are analysed for trend, not only for the last period. The process owner records an interpretation and a decision (accept, investigate, improve) with each report. Detailed definitions are held in the Service Reporting and Continual Improvement Procedure and the criteria for judging services in the Service Evaluation Criteria.

11.2 Internal audit

The Organisation conducts internal audits at planned intervals to provide information on whether the SMS conforms to its own requirements and to the standard, and is effectively implemented and maintained. The audit programme considers the importance of the processes and the results of previous audits.

• The audit programme covers all clauses of the standard and every SMS process at least once in [12 months]; higher-risk processes are audited more often.
• Auditors are trained, objective and impartial and do not audit their own work.
• Findings are reported to the process owner and the management representative within [10 working days] of the audit and logged as nonconformities or observations.
• Corrective action is agreed within [15 working days], and verified by the auditor on completion.
• The audit calendar, audit plan, report and checklist templates are in the Internal Audit and Management Review Procedure.

11.3 Management review

Top management reviews the SMS and the services at planned intervals of no more than [6 months] to ensure continuing suitability, adequacy and effectiveness. The review includes the items below and results in documented decisions.

• Outputs are decisions on opportunities for improvement, any need to change the SMS or services, and the resources needed.
• Minutes are issued within [5 working days] with each action owner and due date, and actions are tracked until closed.
• A template for the agenda and minutes is in the Internal Audit and Management Review Procedure.

11.4 Service reporting

The Organisation produces service reports from information collected during delivery and support. For each report it defines purpose, audience, content and format, and the frequency. Reports state the performance against targets, significant events, trends, and customer satisfaction.

Report errors are corrected and re-issued with a note of what changed. Detail is in the Service Reporting and Continual Improvement Procedure.

12. Improvement

Clause 10 describes how the Organisation corrects what fails and improves what works.

12.1 Nonconformity and corrective action

When a nonconformity occurs, the Organisation reacts to it, takes action to control and correct it, deals with the consequences, and evaluates whether action is needed to eliminate the cause so that it does not recur or occur elsewhere. It reviews the effectiveness of the corrective action and, if needed, changes the SMS.

1. IdentifyAnyone may raise a nonconformity from an audit, an incident, a complaint, a supplier review or an observation. It is entered in the nonconformity register the same day.
2. ContainThe process owner decides within [2 working days] what must be done to stop further harm and records it.
3. AnalyseThe owner finds the root cause using the method in the Problem Management Procedure, proportionate to the severity.
4. ActThe owner proposes corrective action, an owner and a due date, normally within [30 days]; the management representative approves.
5. VerifyAfter [the verification period of 60 days] the auditor or management representative checks the action is effective.
6. CloseThe nonconformity is closed with evidence, and reported at the next management review. If it recurs, it is escalated to top management.

12.2 Continual improvement

The Organisation continually improves the suitability, adequacy and effectiveness of the SMS and the services. Improvement is managed through a single log that collects ideas, audit findings, customer feedback, lessons learned and root cause findings. The management representative assesses each item for benefit, effort and risk, prioritises it, and either plans it or records why it is not being pursued.

Improvement is described in the Service Reporting and Continual Improvement Procedure; the status of the log is a standing item at management review.

Annexure A: Map of SMS documents to the standard

Annexure B: Register of SMS records

Annexure C: Register of process owners

Annexure D: Document history

13. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

14. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

15. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 20000-1:2018 references

Related documents

• Service Management Policy
• SMS Objectives
• Context of the Organization
• SMS Scope and Service Management Plan
• Service Operating Model
• Internal Audit and Management Review Procedure
• ISMS Manual
• Documents and Records Management Procedure