The Service Management System Discovery - 1
Why "Having ITSM" Is No Longer Enough
This article is part 1 of 4 in the "Service Management System Discovery" series. In part 2 we explore what a Service Management System actually is (and isn't). In part 3 we look at governance, risk and compliance, and in part 4 we discuss how to make it stick in practice and where external help adds real value.
The new pressure on ITSM: Boards, NIS2 and audits
For years, IT could get away with talking about tickets, uptime and "best practice." That era is ending. NIS2 and similar regulations put direct accountability on management bodies for cybersecurity and service resilience. Boards are expected to:
Approve concrete risk‑management measures
Oversee implementation, not just sign a policy
Demonstrate that governance and controls actually work in practice
At the same time, standards such as ISO/IEC 20000‑1 (service management) and ISO/IEC 27001 (information security) have become the reference points for what "good management" looks like. They share the same basic expectation: there is a management system in place – not just a collection of tools and processes.
In my work with Danish and international organisations, I almost never see a lack of ITSM tooling. What I see missing is a simple, explicit management system that leaders can actually recognise and use.
Three patterns you see without a Service Management System
When ITSM exists without a Service Management System around it, three patterns repeat across organisations and sectors.
1. Ownership of ITSM, but not of "the system"
Somebody always "owns" the ITSM tool. Often, there are process owners for incident, change and problem. But when you ask, "Who owns the Service Management System – the way we manage services as a whole?" the room gets very quiet.
Without a clear owner for the system
- Scope is fuzzy: no‑one can say exactly which services, units and suppliers are inside "our ITSM world".
- Policies are scattered: security, risk, architecture and operations each have their own rules.
- Improvement is tactical: every team runs its own mini‑projects with no coherent direction.
What I consistently see in IT organisations is that the ITSM tool has an owner, but the Service Management System does not. And if nobody owns the system, nobody really owns the risks either.
2. Data everywhere, decision support nowhere
The data flood
Most IT organisations are drowning in data. Incidents, SLAs, availability, change success, vulnerabilities, CMDB attributes – every tool produces beautiful dashboards. But without a management system, these numbers are rarely connected to a clear set of service objectives, risk appetite or regulatory requirements.
The result
- Reports are produced for their own sake, not for specific decisions.
- Definitions differ between teams and tools, so numbers cannot be compared.
- Boards and executives get high‑level summaries that feel more like marketing than governance.
In the NIS2 context, this becomes dangerous. Article 20 expects management bodies to approve measures and oversee implementation on an informed basis. If information is not organised by a Service Management System – scope, roles, routines, evidence – it is very hard to claim that decisions are truly informed.
3. Parallel worlds for cloud, DevOps and security
The third pattern is fragmentation. Classic ITSM tends to cover the service desk, infrastructure and some applications. Meanwhile:
Cloud & DevOps
Teams run on sprint boards and CI/CD tools, operating outside traditional ITSM boundaries.
Security
Has its own incident and risk processes, separate from the broader service management landscape.
Suppliers
Each bring their own portals and workflows, adding further fragmentation to the picture.
Everyone has good reasons. "We're too agile for ITSM." "Security is special." "The vendor contract requires their tool." But when incidents cross these boundaries, or when a NIS2‑relevant event spans multiple environments, leadership discovers that they do not have one way of managing services – they have several partial, incompatible ways.
Why this is a management‑system problem, not a tooling problem
It is tempting to respond with more of the same: a new ITSM module, more integrations, extra reports. The harsh truth is that tools cannot fix what is essentially a management‑system problem.
Standards like ISO/IEC 20000‑1 define what an effective Service Management System (SMS) looks like: clear scope, policies, roles, processes and a PDCA‑style improvement cycle. ISO/IEC 27001 does the same for information security; NIS2 assumes something similar exists for cyber and resilience.
The good news is that you do not have to "become a standard" to learn from this. The core idea is simple:
Treat Service Management as a management system, not as a set of tools and isolated practices.
In the rest of this series, we explore what that means
01
Service Management System Discovery - 2
We define what a Service Management System actually is – and how it differs from both ITIL and your IT Operating Model.
02
Discovery - 3
We look at how an SMS becomes the backbone of governance, risk and compliance (including NIS2).
03
Discovery - 4
We get more opinionated: why "implementing ITIL" is often the wrong starting point, and how to make your SMS light, pragmatic and sustainable.
If you recognise your own organisation in these patterns, you are not alone. The point is not to feel guilty about your current ITSM. The point is to name the missing layer so you can start fixing the right problem.