ITIL is a widely used approach to service management in IT departments, from handling incidents to controlling changes to systems. How closely those same practices sit next to cyber security risk gets less attention. If you already run ITIL-based service management, you have much of the structure a security process needs, and the gaps that remain tend to be specific and fixable.
What ITIL Covers
ITIL is a framework for managing IT services, covering how incidents get logged and resolved, how changes to systems are approved and rolled out, and how the organisation tracks the assets and configurations it has running. It was built to keep services reliable and users supported. ITIL 4 does include an information security management practice, but the framework is centred on service delivery. Reliability and security overlap more than people expect, because both depend on knowing what you have, who can change it, and what happens when something goes wrong.
Incident Management Is Already Half a Security Process
Every organisation running ITIL has some form of incident management: a process for logging a problem, assigning it, working it, and closing it. A security incident needs the same skeleton. The differences are in the detail. You need faster escalation for anything that looks like a breach, earlier involvement from legal or compliance people, and a way to decide whether the incident has to be reported externally. If your ITIL responsibilities already define who owns incident response, extending that definition to security incidents is less work than building a parallel process from nothing.
Change Management Is Where Risk Gets Introduced
A change is one of the common ways security problems get introduced. A new piece of software goes in, a firewall rule gets loosened to fix an unrelated problem, a server gets rebuilt slightly differently from the last one. ITIL controls this risk by requiring review and approval before a change goes live. ITIL 4 has renamed change management to change enablement, which puts more weight on delivery speed and on delegating approval, so the security question needs to be built in explicitly.
The practical fix is small. Make security risk one of the standing questions at change approval, so it is asked before a change goes live. A change advisory board, or whatever your change authority looks like, already meets regularly and is a natural place for that question. It does not need a separate security committee.
Configuration and Asset Records Answer the Question Security Starts With
One of the hardest parts of cyber security work is knowing what exists: which servers are running, which software versions are deployed, and who has access to what. ITIL configuration management, often tracked through a configuration management database (CMDB), exists to answer that question for operational reasons. An accurate, current record is a key input to any security review or risk assessment, because you cannot assess risk on assets you do not know you have. Configuration records decay quickly if nobody owns keeping them accurate, and a stale CMDB can be worse than none, because it gives false confidence.
Where the Overlap Runs Out
Run well, ITIL practices cover a lot of ground but stop short of a full security programme. Legal obligations around personal data are a separate area, set out in the data protection requirements for UK businesses. ITIL is also not a guide to proactive testing, such as finding out whether your defences hold up against a real attempt to break in, or to the governance decisions a board must make on risk appetite and accountability. Service management keeps things running smoothly and predictably. Security strategy decides what “secure enough” means for your organisation and checks whether you are there, and that needs its own ownership and skills.
Bringing the Two Together Properly
Name someone early whose job includes making sure the ITIL practices and the security requirements talk to each other. Both teams sitting in IT does not make that happen on its own. It is often a natural extension of what a cyber security consultant does, bridging operational process and security risk across two disciplines that usually report to different people. If you are weighing whether to bring someone in for that work or build the capability internally, work through the practical questions in the cyber security consultant FAQs before committing either way.
If you want to find out where your service management practices already support good security and where the gaps are, see what a cyber security consultant’s role involves.
