ISO/IEC 20000-1 Practical Guidance PDF

Implementing the requirements of ISO/IEC 20000-1 - practical guidance on documented information This chapter provides practical guidance on how to implement and document the requirements of ISO/IEC 20000-1. It shows ways to conform to them and refers to document templates from the ISO/IEC 20000-1:20...

Implementing the requirements of ISO/IEC 20000-1 - practical guidance on documented information This chapter provides practical guidance on how to implement and document the requirements of ISO/IEC 20000-1. It shows ways to conform to them and refers to document templates from the ISO/IEC 20000-1:2018 Documentation Toolkit where possible. This is done in a clause-by-clause manner based on the text of the standard. In many cases the guidance goes beyond the strict requirements of the standard and is based on good practice from a more general point of view. For example, the risk register in the documentation Toolkit is quite a bit more extensive than strictly required by the standard. However, in practice, the full extent of it will generally benefit the organization and make integration with other management system standards easier. A distinction is made between both mandatory and non-mandatory documented information: the mandatory documentation is explicitly mentioned in the standard as having to be available. "The non-mandatory documentation is mentioned in the standard in phrases such as, "the organization shall determine " or, "the organization shall ensure..." without an explicit requirement to have this available. These non-mandatory documents have been made available in the Documentation Toolkit anyway, as it will 24 benefit the organization to document these items and auditors will often ask for some sort of evidence of conformance with these requirements. 5.1 - CLAUSE 4 Template 4.3 Scope.docx Mandatory documented information 4.3 Document Scope Statement The scope statement is the only mandatory documented information to be supplied in Clause 4's requirements. In its simplest form, it is a single sentence indicating what is included in the scope of the SMS: mentioning the organization's name, type of services supplied, locations where services are provided and, possibly, specific customers to whom the services are provided. The toolkit document is a bit more extensive than this: it includes an introduction, reference to terms and definitions, policies, an organization chart, the scope statement itself, and considerations of future scope changes. This information is not all mandatory, but is useful to have included. Non-mandatory documented Information 5.1.1 Internal and external issues the requirement for the organization to "determine internal and external issues that are relevant to its purpose" can simply result in a list of issues as a result of a SWOT analysis and/or PESTLE analysis. A SWOT analysis is an overview of an organization's internal Strengths and Weaknesses, and external Opportunities and Threats. Figure 1 illustrates this. 25 A SWOT analysis is an overview of an organization's internal Strengths and Weaknesses, and external Opportunities and Threats. Figure 1 illustrates - The Internal and External Issues Tracker template is a more extensive version of this list, including more formal registration of these issues and any indication of follow-up actions and owners where necessary. Given that issues may eventually become risks or improvement opportunities, a possible link to the respective registers for those has been provided as well. 5.1.1 Interested parties The name of the interested party - these can be either internal groups with some interest in your SMS (such as Human Resources, Finance, Sales, Security) or external ones (such as customers, suppliers, regulatory bodies). The interface between your organization and the interested party typically a named person or a system through which communication is carried out. The reason why the party is interested — what are the requirements from all these parties for your SMS and services? A PESTLE analysis looks at the context of the organization in terms of Politics, Economy, Social, Technological, Legal and Environmental aspects: Political aspects: Government policies; wars, terrorism and conflicts; intercountry relationships; bureaucracy. Economic aspects: Local economy; taxes; international trade; seasonality. Social aspects: Brand, company, technology image; ethical issues; culture; media views; demographics. Technological aspects: Emerging technologies; competitor technology development; market readiness. Legal aspects: Current and future legislation; regulatory bodies; competition law; industry regulations. Environmental aspects: Environmental regulations; ecology; sustainability. The output of the SWOT and PESTLE analysis will produce a list of issues or factors that can be positive or negative, internal or external and that can be maintained as a simple list. Examples are provided in the toolkit template. 26 5.2 CLAUSE5 Mandatory documented information The service management policy can be a fairly short document, stating the organization's commitment to service management, establishing principles for a framework of setting service management objectives, committing to fulfilling the requirements contained in ISO/IEC 20000-1, and committing to performing continual improvement of the SMS and the services. The template can be used as is, or be altered as required to reflect service management principles used in your organization. Make sure this policy is available to all relevant parties, both inside and outside your organization, for as far as they are stakeholders in the services. Non-mandatory documented information 5.3 CLAUSE 6 Mandatory documented information 27 5.3.1 Risk management in ISO/IEC 20000-1 is not a very heavy process. What needs to be documented is limited to risks related to the organization; not meeting the service requirements; and the involvement of other parties in the service lifecycle. The impact upon the customers of these risks for the SMS and the services needs to be determined, together with a risk acceptance criterion (also known as risk appetite) as well as the requirement to document the approach on how to deal with them. Note that in other parts of the standard, additional risks need to be identified, which may as well be included in this phase: these include risks to service availability, risks to service continuity and information security risks. Two Risk Register Templates are provided: a basic one with only the mandatory fields and an extended one that contains much more information that can also be used for risk management in ISO/IEC 27001 (for example). The risk register provided is a general operational risk management tool The overview of roles, responsibilities and authorities for running the SMS can in practice be contained in the job descriptions of relevant personnel. If you want to highlight specific roles and make their responsibilities, authorities and qualifications explicit, then you can use the template document as an example to work from. suitable for a broader risk management approach than required by the ISO/IEC 20000-1 standard. It is a straightforward spreadsheet that uses the following information: 1. Date when risk got opened. 2. Name of risk. 3. Description of risk. 4. Reference number. 5. Date of last update. 6. Relevant ISO standard (20000-1 in this case). 7. Owner of risk - the person who needs to act. 8. Management reviewed - indicator of whether (top) management has 28 9. reviewed the risk. They are the ones who can determine the treatment or acceptance of risks. Impact if risk occurs — on a scale from 1 (Low) to 5 (High). 10. Likelihood that risk occurs — on a scale from 1 (Low) to 5 (High). 11. Risk — calculated as Impact x Likelihood, so on a scale from 1 to 25. 12. Risk level — High, Medium or Low, based on the risk calculated under item 11. 13. Treatment - this is the approach taken for this risk. Typically, you can choose from: Accept (i.e. do nothing and hope that the risk does not occur); Reduce (reduce the likelihood or impact of the risk by implementing controls); Transfer (find someone else who is willing to accept the risk as their own). 14. Action plan — this is a log of activities performed to treat the risk. 15. Due date - date on which the risk is expected to be treated. 16. Completion date — actual date on which treatment has been completed. 17. Status — open or closed. 18. Post action plan impact — same as Impact (9) field, but now recalculated after the risk has been treated. This should therefore be lower than the original value, unless the risk has been accepted. 19. Post action plan likelihood — same as Likelihood (10) field, but now recalculated after the risk has been treated. This should therefore be lower than the original value, unless the risk has been accepted. 20. Post action plan risk — same as Risk (Il) field, but now recalculated after the risk has been treated. This should therefore be lower than the original value, unless the risk has been accepted. 21. Post action plan residual risk level — same as Risk Level (12) field, but now recalculated after the risk has been treated. This should therefore be lower than the original value, unless the risk has been accepted. The risk acceptance criteria and the risk management approach can be simply documented, and 29 once again, the exact criteria and approach will vary between organizations so you can make this as complex as you like. The template provided is called the Risk Management Framework, which includes both. It is an example of how you can set up a risk management framework, but should be tailored to the needs of your organization. Non-mandatory documented information Risk management is a broad area. ISO/IEC 20000-1 is not very demanding when it comes to risk management (compared to e.g. ISO/IEC 27001). There is a lot of literature regarding how to efficiently handle risk management, although it goes beyond the requirements of the ISO/IEC 20000-1 standard. The International Standard for risk management is ISO 31000, with many examples of approaches described in ISO 31010. All sorts of additional documented information may be necessary based on the exact risk management approach you decide to take. These are all optional from the perspective of ISO/IEC 20000-1. 5.3.2 Service management objectives Service management objectives can be defined as part of an annual performance objectives cycle and should be set at various levels of the organization and for the relevant functions. Objectives should be based on the framework set in the service management policy discussed previously, and they should be SMART — Specific, Measurable, Attainable, Realistic and Time- bound. The template is just a free-form document with a couple of high-level service management objectives that need to be translated into objectives for specific functions within the organization. It is advisable to communicate the high- level objectives to the relevant parties both inside and outside of the organization. 5.3.3 Service management plan the service management plan is a high-level document describing what is required to run the SMS and provide the services. It contains eight sections as follows: operated by these parties and what controls you have put in place to make sure they provide what is necessary. Mention contracts, SLAs, performance indicators and other controls. 30 Technology: describes what technology is needed to run the SMS. This is likely already covered in the "Resources" section, but any specifics can be mentioned here. Measurements and Improvements: this section documents what measurements are taken of the SMS and the services to verify that everything is running optimally. They should be used for (internal) audit purposes, reporting to top management and other stakeholders, and as input to the continual improvement process. Be clear about the tools, technology and human resources needed to achieve this, as well as how regularly reports and audits will be created depending on the audience. A list of services: list of your services in scope of the SMS. Limitations: a list of limitations, such as the geographical scope, staff working hours, financial situation, specific customer requirements, etc. Obligations: a list of obligations, such as relevant policies, standards, legal, regulatory and contractual requirements, and how these obligations apply to the SMS and the services. Authorities and responsibilities for the SMS and the services: these will usually have been documented in the Roles, Responsibilities and Authorities document from Clause 5.1. Resources: a list of resources required, such as the number of personnel, knowledge management system, documentation, servers, desktop computers, network infrastructure, cloud infrastructure, budget, etc. 31 Approach for working with other parties involved in the service lifecycle: you should describe here what other parties you use to provide services, including outsource and/or offshore partners, suppliers (both internal and external ones), customers acting as suppliers, etc. Be specific about the scope of what is provided or you need to determine what competence personnel working within the context of the SMS need, making sure it is also obtained by them through e.g. education and training. This competence can range from technical skills, communicative abilities, product and service knowledge, process and procedural knowledge to other types of competence. It can be obtained via internal or external training, self-study, consultation of documented processes or procedures, etc. Often, organizations have some form of training database where this can be recorded. The template provided is a simple spreadsheet where for each employee, their name, hiring date, training and completion date of training can be recorded. Note that a distinction has been made between "required" courses (Column K), which would be on the curriculum for a certain role, and "non-required" courses, which would be additional ones followed outside the curriculum. 5.4.2 Processes All processes required by the standard are to be documented and a Process template for process documentation is provided in the toolkit. The elements of this will be described in full detail under Section 5.5 Clause 8, as that is where most processes in the standard are described. 5.4.3 Procedures Procedures can be written as step-by-step work instructions or by using screenshots from an application. The Process Template contains a section where these procedures can be described. See section 5.5 for details. 5.4.4 Knowledge Knowledge exists in many forms and formats, ranging from training materials to process documents, incident and problem records to corporate policies. Given that this is such as broad area, no specific template has been provided in the toolkit to cover this section. It is up to the individual organization to make sure knowledge is actually documented and does not merely exist within the heads of individual employees. 32 Non-mandatory documented information The communication plan is an overview of what type of communication takes places, what the reason is, who is responsible for the communication, who the audience is and when or how frequently communication takes place. The template contains a long list of examples that may be included in this communication plan. It makes sense to review this plan regularly in order to verify if communication at the various levels has taken place. Other types of documented information that it may be necessary to create, which are relevant to the particular SMS that your organization needs, are not mentioned in the standard. These documents may be internal or external in origin. It is up to your organization itself to determine what documentation is to be maintained in this area. All processes used in the SMS need to be documented — this will be discussed in far more detail in the next section where most of the processes are mentioned. A generic Process Template has been provided in the toolkit. Section 7.5.4 requires you to provide any records that illustrate conformity to the requirements of the standard. This is a very broad category, most of which is already covered by the mandatory documented information in the standard. It can, however, be extended with records such as meeting minutes, presentations from top management spreading awareness, risk acceptances, action lists and any other records generated during the course of developing, implementing, operating and improving the SMS. 33