ISO 20000 ticket system: what does the standard require?
ISO 20000-1 does not prescribe a specific ticket system. The standard does require you to record, follow up and demonstrate incidents, service requests and problems. In practice, a ticket system is the evidence for this. What your system must be able to do follows from the requirements for incident management and the other service management processes in clause 8, and from the requirements for documentation and evidence in clause 7. The standard itself is ISO/IEC 20000-1:2018 , sold via NEN . The description of the certification can be found at BSI .
A ticket system does not need to be special ISO software. An ordinary service desk tool, a spreadsheet or a form with a log can all do the job. What counts is that you can find every ticket, that it shows a clear resolution, and that you can extract the figures you need for the internal audit.
What must a ticket demonstrate?
An auditor can pick a few tickets and trace them from start to finish. That way, they see whether your process works. On that journey, a ticket must answer three questions: what was the problem, who picked it up, and what was done? If one of those answers is missing, the evidence is weak.
The standard does not prescribe fields. The set below is a practical minimum that lets you demonstrate how a ticket was handled.
| Field | What you enter | Example |
|---|---|---|
| Ticket number | Unique, automatically increasing | INC-2026-0412 |
| Date and time of report | When it came in | 12 October 2026, 09:14 |
| Reporter | Who reported it | Planning, customer X |
| Category | Type of ticket | Incident, request or problem |
| Impact and urgency | How much it affects and how fast it must be fixed | High, within 4 hours |
| Priority | Derived from impact and urgency | P2 |
| Service | Which service is affected | Management of the mail environment |
| Assigned to | Who picks it up | Service desk, second line support |
| Status | Where it stands | New, in progress, resolved, closed |
| SLA deadline | When it must be resolved by | 12 October 2026, 13:14 |
| Resolution | What was done | Mail server restarted, cache cleared |
| Link | Link to the problem or change | PRB-2026-007 |
| Closing date | When it was closed | 12 October 2026, 11:02 |
Pay attention to the link. An incident that keeps coming back belongs in the problem register. Without that link, the auditor cannot see that you are looking for the cause, only that you are clearing the report.
Which statuses do you need?
You need a fixed set of statuses, so that everyone knows where a ticket stands. A simple set works for most organisations:
- New. Received, not yet assessed.
- In progress. Someone is working on it.
- Waiting for customer or supplier. Time you do not control. Record what you are waiting for.
- Resolved. Service restored, but not yet confirmed by the reporter.
- Closed. Confirmed, or closed after a fixed period without a response.
Your own status names are fine, as long as you use them consistently and record them in your process description.
Example: one ticket from start to finish
A customer reports that files on the network drive are not saving. This is how the ticket looks once it has been handled.
| Step | Time | Action | Status |
|---|---|---|---|
| Report by phone | 09:14 | Service desk registers the ticket, category incident, high impact | New |
| Assessment | 09:20 | Priority P2 assigned, allocated to second line support | In progress |
| Analysis | 10:05 | Disk quota reached, cause recorded | In progress |
| Resolution | 10:40 | Quota increased, customer confirms that saving works | Resolved |
| Closure | 11:02 | Ticket closed after confirmation. Cause linked to the problem register | Closed |
The auditor sees everything they need here: the report, the assessment, the SLA time and the resolution. The link to the problem register shows that the cause has been addressed, so it does not happen again.
What the auditor wants to see
At the stage 2 audit, the auditor looks at examples from practice. They often ask for a sample of tickets from recent months. Make sure you can deliver that sample quickly, without first searching for things manually.
- Completeness. Every ticket has the mandatory fields filled in, including the closed ones.
- Timeliness. You can show that you meet your SLA times, or why you do not.
- Consistency. The same categories and priorities are used everywhere.
- Feedback. Problems and changes can be traced back in their own registers.
- Reporting. You can produce an overview of volumes, lead times and recurring incidents.
Common mistakes
The most common mistake is closing a ticket without a resolution. “Closed” with no text in the resolution field is worth nothing to the auditor. Always record what was done, even if it is brief.
- Priority without a rule. If every service desk employee decides for themselves what P1 means, you cannot show that your system is consistent. Record the impact and urgency matrix.
- Not linking problems. A recurring incident without a problem record is a missed improvement.
- The system as the only source. If only one person knows how the tool works, the system is not under control. Document how you use it.
- Multiple versions of the truth. Tickets in the system and agreements in email that are not recorded make your evidence incomplete.
How do you choose a ticket system?
Start from the requirements on this page and from the process description you have, not from a product’s features. Ask a supplier whether the system can record the fields, statuses and links from the table. Also show how you export a sample of tickets. If that cannot be done quickly, the audit will be difficult, however good the tool looks.
For a small organisation, a simple system with a fixed list of fields is often enough. If your service delivery grows or you serve several customers, a full service desk tool quickly becomes the better choice. Whatever you choose, record the decision in your SMS documentation.
Relationship with ISO 27001
Many organisations that combine ISO 20000 and ISO 27001 use the same ticket system for security incidents and service faults. That is efficient, as long as the categories are clear. A data leak has different handling requirements from a slow server. Read more about the combination on ISO 20000 and ISO 27001.
Next steps
Sources
- NEN: IT service management with ISO/IEC 20000 - Netherlands Standardization Institute (NEN)
- BSI: ISO/IEC 20000-1 Service Management - British Standards Institution