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:
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.
When ITSM exists without a Service Management System around it, three patterns repeat across organisations and sectors.
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.
- 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.
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.
- 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.
The third pattern is fragmentation. Classic ITSM tends to cover the service desk, infrastructure and some applications. Meanwhile:
Teams run on sprint boards and CI/CD tools, operating outside traditional ITSM boundaries.
Has its own incident and risk processes, separate from the broader service management landscape.
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.
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.
We define what a Service Management System actually is – and how it differs from both ITIL and your IT Operating Model.
We look at how an SMS becomes the backbone of governance, risk and compliance (including NIS2).
We get more opinionated: why "implementing ITIL" is often the wrong starting point, and how to make your SMS light, pragmatic and sustainable.
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.