ISO/IEC 20000-1:2018 certification means an independent auditor has checked that a vendor runs a documented service management system: defined service levels, a working incident and problem process, controlled changes, and regular reviews with evidence behind them. For you as a buyer, it means SLAs and incident handling should be written down and measurable, not improvised.
On this page
- What is ISO/IEC 20000-1:2018?
- How does ISO 20000-1 change the SLAs you get?
- What does certified incident management look like in practice?
- How does the standard affect changes and releases?
- What doesn’t ISO 20000-1 guarantee?
- What should you ask a certified vendor?
- Is ISO 20000-1 relevant if you’re buying development rather than IT services?
- Frequently asked questions
It doesn’t mean the vendor writes good code, and it isn’t a security certification. Dignep holds ISO/IEC 20000-1:2018 for IT service management. This post explains what that does and doesn’t promise, and what to ask any certified vendor so the certificate turns into something useful in your contract.
What is ISO/IEC 20000-1:2018?
It’s the international standard that sets requirements for a service management system: how an organisation plans, delivers, monitors and improves IT services. It covers service level management, incident and problem management, change and release management, supplier management and continual improvement. Organisations are certified against it by accredited auditors.
If you know ITIL, the territory is familiar. The difference is that ITIL is guidance, while ISO 20000-1 is an auditable standard: the organisation has to show records proving the processes actually run.
| Standard | What it covers | What it tells a software buyer |
|---|---|---|
| ISO/IEC 20000-1 | IT service management | SLAs, incidents, changes and reviews are defined and evidenced |
| ISO/IEC 27001 | Information security management | Security risks and controls are managed systematically |
| ISO 9001 | General quality management | A quality system exists; not specific to IT services |
How does ISO 20000-1 change the SLAs you get?
A certified vendor has to define service levels, measure them, report against them and act when they’re missed. So you should be able to see targets, how each is measured, how often it’s reported, and what happens after a breach. If a certified vendor can’t show you that for your engagement, the certificate isn’t doing its job.
The standard doesn’t set the targets themselves. A 99.5% uptime target or a one-hour response time is something you negotiate. What the standard adds is the discipline around them. Typical metrics in a software engagement include:
- Availability of the systems the vendor operates
- Response and resolution times by incident priority
- Change success rate and the number of emergency changes
- Delivery measures agreed for the engagement, such as release cadence or defect escape rate
Our guide to software development SLAs covers which metrics to include and how to word them.
What does certified incident management look like in practice?
Every incident is logged, classified by impact and urgency, worked to a target time, communicated to the people affected, and closed with a record. Recurring incidents go to problem management, which looks for the root cause so the same failure doesn’t keep coming back. Major incidents get a written review.
A common priority scheme looks like this, though the exact definitions belong in your contract:
- P1, critical: service down or data at risk, no workaround
- P2, high: major function impaired, workaround exists
- P3, medium: limited impact on a few users
- P4, low: cosmetic issues and minor requests
One practical note for offshore work: response targets only mean something if they say which hours they apply to. Dignep’s standard hours are 09:00–18:00 Nepal Time (UTC+5:45). Coverage outside those hours has to be agreed and priced explicitly, especially for US clients, who have no natural overlap with that day.
How does the standard affect changes and releases?
Changes are requested, assessed for risk and impact, approved by the right person, tested, and released with a rollback plan. Afterwards, failed or emergency changes are reviewed. For you this means fewer surprise deployments and a clear record of what changed when something breaks.
In a modern CI/CD setup most of this is automated: pull request review, automated tests and a deployment pipeline are the change control. The standard doesn’t require heavyweight meetings. It requires that the process exists, is followed and leaves evidence. If you’re building or reviewing that pipeline, see building a CI/CD pipeline for enterprise teams.
What doesn’t ISO 20000-1 guarantee?
It doesn’t guarantee code quality, technical skill, security or that a specific team will be good. It shows that processes exist and were working when audited. A vendor can be certified and still staff your project badly. Treat the certificate as a reason to ask sharper questions, not as a replacement for a pilot and references.
It also only applies to the scope written on the certificate. Ask what’s in scope. A certificate that covers one data centre or one service line says little about the team building your product.
What should you ask a certified vendor?
Ask for the certificate, its scope statement and the issuing body; ask to see a sample SLA report and an incident record with personal data removed; and ask how a recent major incident was reviewed and what changed afterwards. Real answers come with documents. Vague answers suggest the certificate sits in a drawer.
- Can you show the current certificate, scope and issuing body?
- What does your monthly service report look like?
- Walk me through your incident priorities and escalation contacts.
- How are changes approved and rolled back on a project like mine?
- How do you manage your own suppliers and subcontractors?
- Which improvements came out of your last management review?
We expect clients to ask us the same questions, and we share the certificate details during due diligence.
Is ISO 20000-1 relevant if you’re buying development rather than IT services?
Partly. It matters most when the vendor will operate, support or maintain systems for you, or when you need evidence of vendor controls for your own auditors. For a pure build project, delivery practice and the team matter more. For an engagement that includes support, it’s directly relevant.
If your own organisation is working towards ISO 27001, SOC 2 or AI governance requirements, that’s a different engagement. Our cybersecurity and GRC services cover that work, and Certifyi, our AI SaaS GRC platform, is described in the Certifyi case study. For the delivery side, see our software outsourcing service.
Frequently asked questions
How long is an ISO 20000-1 certificate valid?
Certification under accredited schemes normally runs on a three-year cycle, with surveillance audits in between and a recertification audit at the end. Check the dates on the certificate itself.
Can a small company be certified?
Yes. The standard scales to the size of the organisation and the services in scope. What matters is that the processes fit the services and that there’s evidence they’re followed.
