Knowledge base
ISO/IEC 20000-1:2018: documentation and compliance requirements
Everything ISO/IEC 20000-1:2018 requires you to document, clause by clause, with what an auditor asks to see for each. Written as requirements rather than as a check
Prem Kumar Dvivedi · 12 September 2026
This is what ISO/IEC 20000-1:2018 requires you to have, clause by clause, and what an auditor will ask to see for each of it. It covers 69 requirements across 7 areas.
It is deliberately not a checklist. A checklist asks whether you have something; this says what is required and what counts as evidence, which is the question that matters when you are building a system rather than testing one. If you would rather find out where you stand first, the same ground is covered by our free ISO/IEC 20000-1:2018 readiness assessment, which scores you out of 100.
4 Your organisation and the services you run
Clauses 4.1, 4.2, 4.3, 4.4.
You must have written down the outside things that affect your services — customers, technology, suppliers, regulation, security threats.
Evidence: A short list of these issues, with a note of when you last looked at it.
You must have written down the inside things — skills, tools, capacity, how you are organised.
Evidence: The same list, covering internal issues.
You must have listed your customers, users, suppliers and anyone else with an interest, and what each needs.
Evidence: A list of these groups with their requirements.
You must know your legal, regulatory and contractual duties around the services.
Evidence: A register of these duties.
You must have written down what the service management system covers — which services, which teams, which locations.
Evidence: A scope statement naming the services, the organisational units and the places they are delivered from.
It must be defined where another party runs part of the service — a supplier, an internal team, or the customer — you must be able to show you still govern that work.
Evidence: The list of those parties. Evidence you are accountable for the process, control it, and decide what it must deliver. A process run entirely by someone else, with no evidence of governance, cannot be claimed inside your scope.
You must know what your main processes are and how they fit together.
Evidence: A process map or a list with owners.
5 Leadership
Clauses 5.1, 5.2, 5.3.
Senior management must be able to point to service decisions they made in the last year.
Evidence: Management review notes. Investment approvals. Ask them directly.
Senior managers must make sure the system has the people, money and tools it needs.
Evidence: Budget. Staffing. Tooling bought.
You must have a written service management policy.
Evidence: The policy, signed and dated, promising to meet requirements and to keep improving.
It must be shared with your people and with the suppliers who need it.
Evidence: Where it is published.
It must be clear who owns each service and each process.
Evidence: Named service owners and process owners. Organisation chart.
Those must be roles assigned across suppliers and internal teams too, not just your own staff.
Evidence: Responsibilities agreed with each party involved in delivering the service.
6 Planning
Clauses 6.1, 6.2, 6.3.
You must have worked out what could go wrong and what opportunities there are.
Evidence: A risk and opportunity list covering service, technology, supplier, security, capacity and continuity.
You must have set service management objectives, and they must be able to be measured.
Evidence: Objectives with targets and numbers.
For each objective, it must be clear what will be done, by whom, by when, with what, and how you will judge it.
Evidence: An action plan covering all five points.
You must have a service management plan showing how you will achieve those objectives.
Evidence: A plan covering the services, the parties involved, the people and money needed, the technology supporting the system, and how you will measure, audit, report and improve.
The must be plan kept up to date and actually used.
Evidence: Revision history. Evidence it drives work rather than sitting on a shelf.
7 Support — people, knowledge and documents
Clauses 7.1, 7.2, 7.3, 7.4, 7.5, 7.6.
You must provide the people, money and tools the system needs.
Evidence: Budget. Staffing. Tooling.
You must know what skills each role needs, and you must be able to show your people have them.
Evidence: Competence criteria. Skills matrix. Training and certification records, covering supplier staff where they perform your processes.
Your people must know the policy, their part in it and what happens if things go wrong.
Evidence: Induction and awareness records. Ask them.
You must have decided what to communicate, to whom, when and how.
Evidence: A communication plan or table.
You must have the documents and records the standard asks for.
Evidence: A list including the scope, policy, objectives, service management plan, service catalogue, service level agreements and process records.
When a document is created or changed, it must be checked and approved before use.
Evidence: Approval on the document.
People must be able to find the current version, including suppliers who need it.
Evidence: How documents are shared.
You must capture the knowledge people need to run the services — and what happens when someone leaves.
Evidence: A knowledge base or known error list available to support staff. Runbooks. Evidence articles are kept current. Handover arrangements at supplier transition.
8 Running the services
Clauses 8.1, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.3.2, 8.3.3, 8.3.4, 8.4.1, 8.4.2, 8.4.3, 8.5.1, 8.5.2, 8.5.3, 8.6.1, 8.6.2, 8.6.3, 8.7.1, 8.7.2, 8.7.3.
You must have planned and put in place the processes needed to deliver the services.
Evidence: Documented processes and evidence they are followed.
The services must be delivered as agreed with the customer.
Evidence: Agreed service requirements. Evidence delivery matches them.
You must plan new and changed services — the resources, technology, interfaces and dependencies.
Evidence: Service plans covering the whole life of the service, not just building it.
For each party running part of your service, you must have decided what they do and how you keep control.
Evidence: A register of external suppliers, internal teams and customers acting as suppliers. What each runs, the performance criteria, and how you monitor them.
You must have a service catalogue that customers and users can actually see.
Evidence: The catalogue with service descriptions, what each service delivers, and its dependencies.
You must know what assets are used to deliver the services.
Evidence: Asset records covering the assets the services depend on.
You must record and control your configuration items, and check the records are right.
Evidence: Configuration records at a sensible level of detail. Relationships between items. Verification checks with records of what was wrong and how it was fixed.
There must be someone responsible for the relationship with each customer, and you must meet them regularly.
Evidence: Named contacts. Service review meetings with agendas, minutes and actions.
You must have a complaints process, and you must measure customer satisfaction.
Evidence: A definition of what counts as a complaint. A complaints register with outcomes. Satisfaction results and trends, with actions arising.
You must have service level agreements with targets, and they must be based on what the customer needs.
Evidence: SLAs covering the services, targets, workload assumptions and exceptions. Review records.
You must report performance against those targets, including the reasons for misses.
Evidence: Performance reports with the data source stated, and evidence you verify it.
You must manage your external suppliers with contracts that set out the services, targets and interfaces.
Evidence: Supplier contracts and monitoring records. Review meetings. Action taken when performance slipped.
You must manage internal teams and customers acting as suppliers just as rigorously — with written agreements.
Evidence: Documented agreements, which cannot be contracts. Performance monitoring. Most organisations manage external suppliers well and internal ones informally, and that is where the finding lands.
You must budget for the services and track the cost against it.
Evidence: Budgets and cost tracking at a level that lets you control spend.
You must forecast demand and check it against what actually happens.
Evidence: Demand forecasts with the method used, and comparison against actual demand.
You must have a capacity plan covering people, technology and money.
Evidence: A capacity plan taking account of current and forecast demand and the agreed targets. Monitoring and tuning records. Evidence capacity decisions are made before failure, not after.
You must have a change process that says what counts as a change and who can approve one.
Evidence: A change policy defining the types of change, including emergency changes, and the approval rules.
Each must be change assessed for risk and impact before it is approved.
Evidence: Change records with the reason, the risk, and the impact on services and customers.
Changes must be tested and given a way back before they go live.
Evidence: Test evidence. Back-out plans. Approval by someone with the authority, dated before deployment.
You must review changes afterwards, and look at how many fail or are done as emergencies.
Evidence: Post-implementation reviews. Analysis of failed, backed-out and unauthorised changes. A high number of emergency changes means the normal route is being bypassed.
New or must be changed services designed against agreed requirements before they are built.
Evidence: Requirements agreed and documented. Design records showing how they will be met, including resources, roles, dependencies, technology and the SLAs to be set.
Acceptance criteria must be agreed in advance and met before a service goes live.
Evidence: Acceptance criteria set beforehand. Test results against them. Deployment approval and verification in the live environment. Handover into support with documentation and known errors.
You must record, classify, prioritise and resolve incidents, and keep users informed.
Evidence: Incident records with classification, priority, updates and resolution.
You must have a separate route for major incidents, with senior accountability and a review afterwards.
Evidence: A defined major incident procedure. Post-incident reviews.
You must handle service requests within agreed timeframes.
Evidence: Request records with elapsed times against target.
You must look at incident trends to find underlying problems, and fix the cause.
Evidence: Problem records created from incident analysis. Root cause where it can be found. Changes raised to remove the cause. Evidence repeat incidents are actually falling.
You must record known errors and workarounds so support staff can use them.
Evidence: A known error list available to the service desk.
You must agree availability requirements and monitor whether you meet them.
Evidence: Availability targets. Monitoring against them. Unavailability investigated and acted on.
You must agree continuity requirements, have plans, and test them.
Evidence: Continuity requirements. Plans with invocation criteria and responsibilities. Test records with dates and results against the agreed recovery targets.
You must manage information security within the services — a policy, controls, and security incidents handled.
Evidence: A security policy applying to the services. Risk-based controls. Security requirements in supplier agreements. Security incidents recorded and analysed. If you hold ISO/IEC 27001, refer to that system rather than duplicating it.
9 Checking how you are doing
Clauses 9.1, 9.4, 9.2, 9.3.
You must have decided what you will measure about the services and the system, and how often.
Evidence: A monitoring plan naming what, how, how often and who evaluates.
You must analyse the results rather than just collecting them.
Evidence: Analysis and evaluation records, with actions arising.
You must report to customers and other interested parties at agreed intervals.
Evidence: Service reports covering performance against targets, major incidents, changes, continuity invocations, workload, nonconformities and trends. An agreed reporting schedule.
You must audit the system, covering the whole standard over time.
Evidence: An audit programme. Audit reports and findings.
The auditors must be independent of the work they audit, and competent.
Evidence: Auditor training. Who audited what.
Senior management must review the system at planned intervals.
Evidence: Review dates and attendance.
The review must cover everything the standard asks for.
Evidence: An agenda covering: previous actions, changes in issues, performance and effectiveness of the system and the services, resources, risks and opportunities, improvement.
The review must produce decisions and actions, not just minutes.
Evidence: Decisions and an action list with owners and dates.
10 Putting things right and getting better
Clauses 10.1, 10.2.
When something goes wrong, you must deal with it and work out why.
Evidence: Nonconformity and corrective action records with root cause, covering audit findings, incidents, missed targets and supplier failures.
You must check whether the same problem exists on another service, customer or supplier.
Evidence: Evidence you looked wider.
You must check later that your fix worked.
Evidence: A follow-up record with a date.
You must collect improvement ideas, decide which to do, and measure whether they worked.
Evidence: An improvement register with owners and status. Criteria for prioritising. Completed improvements with the measured effect.
You must be able to show the services are better than last year.
Evidence: Trends in incidents, repeat incidents, change success, target achievement and satisfaction.
Using this document
Nothing above asks for a manual, a template pack, or a filing system. It asks for decisions that have been taken deliberately and can be shown to have been taken — which is a far smaller job than most organisations expect, and a different one.
Length is not compliance. A procedure nobody follows is worse than no procedure, because an auditor finds the gap between the two. The test we apply is whether the person who has to do the job recognises their own work in what is written down.
What this covers
See how this looks as a working system
Reading about a requirement and seeing the documentation that satisfies it are different things. In a short demo we open the actual manual, procedures and records set for ISO 20000-1, show you how each clause is answered and where your existing way of working already fits. You will know what implementation involves before you commit to it.
More reading
- DPDP Act: documentation and compliance requirements
Everything DPDP Act requires you to document, clause by clause, with what an auditor asks to see for each. Written as requirements rather than as a checklist.
12 September 2026
- GDPR: documentation and compliance requirements
Everything GDPR requires you to document, clause by clause, with what an auditor asks to see for each. Written as requirements rather than as a checklist.
12 September 2026
- HIPAA: documentation and compliance requirements
Everything HIPAA requires you to document, clause by clause, with what an auditor asks to see for each. Written as requirements rather than as a checklist.
12 September 2026
