Templates and records · ISO 20000 · Clause 8.5.1

ISO 20000-1 request for change (RFC) template

Every modification to a service or a controlled item: what changes, why, what risk it carries, who approves it, how to back it out if it goes wrong and whether it worked.

In one sentence

A request for change records the description of and reason for the change, its classification, the assessment of risks, benefits, feasibility and financial impact, approval by whoever has authority, the planned date communicated, the back-out plan, test results and the review of its effectiveness, because clause 8.5.1 of ISO/IEC 20000-1 requires every request to be recorded and classified and decisions to be taken with the parties involved in line with the change management policy.

Content reviewed on 17 October 2026

Where the standard requires it: ISO 20000 · Clause 8.5.1 Clauses are cited using the numbering of ISO/IEC 20000-1:2018, the current edition and the same one the Academy uses.
Type of information: Mandatory record Recording and classification of requests for change (8.5.1.2), with the documented policy (8.5.1.1)
Who fills it in: Change manager Approved by whoever the policy specifies; significant changes go to a board with the parties involved
When: Before any controlled change Emergency changes can be approved through a fast track, but are recorded all the same
How long it is kept: Set by the organisation The standard requires control of the retention and disposition of documented information (7.5.3) without setting periods. It is usual to cover at least the three-year certification cycle, or the term of the customer contract if longer.

What the standard requires

What ISO 20000 demands and what it leaves to your judgement

The standard requires a change management policy defining which configuration items are under its control, the criteria for identifying changes with the potential for major impact — which are managed through service design and transition under 8.5.2 — and how emergency changes are handled.

Each request is recorded and classified. The decision is taken with the parties involved, assessing risks, benefits, feasibility and financial impact. Planned dates are communicated, back-out activities are prepared and, where possible, tested, and if the change fails they are applied.

After implementation the effectiveness of the change is reviewed, and change request records are analysed periodically to detect trends.

Read it in context: Service design and transition, in the ISO 20000 Academy

Structure

Fields the template should include

Number, date and requester
Description and reason
Services and configuration items affected
Classification: standard, normal, emergency or major impact
Assessment of risks, benefits, feasibility and financial impact
Approval and who decides
Planned window and communication
Back-out plan and whether it has been tested
Test results and implementation
Review of effectiveness and closure

Example

Example: certificate inventory with warning

Company, people and figures are fictitious: the example only shows what a properly completed record looks like.

Field	Content
Change	CHG-26-077 · 22 April 2026 · source: problem PRB-26-021
Description	Register the 46 server certificates as configuration items with an automatic 30-day warning
Affects	Configuration database and monitoring tool
Classification	Normal · low risk
Assessment	No service interruption · internal cost of 3 days' effort · prevents outages like April's
Approval	Change advisory board of 24 April
Window	28 April, 19:00-21:00 · communicated to the customer on the 24th
Back-out	Disable the warning rule · tested in pre-production
Effectiveness	First warning received on 12 June, 30 days before expiry · effective

At the audit

Mistakes auditors commonly flag

Changes made in production with no recorded request.
Emergency changes that are never recorded afterwards.
Back-out plans that do not exist or have not been tested.
No subsequent review of whether the change worked.
The policy does not define which items are under change control.

In Kimobox

How this record is kept in Kimobox

1Requests for change are managed as an approval workflow.
2Each change keeps its approval, testing and outcome documented in the same workflow.
3Configuration items are recorded as versioned assets.

Frequently asked questions

What people ask us before getting started

What is a standard change?

A low-risk, frequent change with a known procedure, which is pre-approved and does not go to the board each time. ISO/IEC 20000-1 does not use that term, but it allows the policy to define which changes are handled that way.

How is an emergency change handled?

The change management policy must define how they are managed. The usual approach is fast approval by an authorised person and a full record afterwards, with its review.

Keep your ISO 20000 records without loose templates

We'll show you the module running with data similar to yours.

Request a demo

Keep exploring