Many organisations run information security and IT service management as two separate worlds. Security has its ISO/IEC 27001 programme, its risk register and its own policies. Service management has incident, change and problem processes, perhaps aligned to ITIL or ISO/IEC 20000. Each side has its own owners, its own meetings and its own audits.
On paper that looks tidy. In practice, it creates duplicated effort, conflicting procedures and gaps where each side assumes the other has things covered. The two overlap far more than most people expect, and treating them as one joined-up system usually makes both stronger.
Where the overlap sits
ISO/IEC 27001 is about managing information security risk. It asks organisations to understand their context, assess risks, choose controls and keep improving. Annex A lists the controls, and a surprising number of them describe things a service management team already does every day.
A few obvious examples:
- Incident management. Security incidents need to be reported, assessed, handled and learned from. The service desk is often where they are first noticed.
- Change management. Uncontrolled changes are one of the most common sources of security weaknesses. A working change process is a security control in its own right.
- Asset and configuration management. You cannot protect what you do not know you have. A reliable asset register or CMDB underpins much of 27001.
- Supplier management. Both disciplines care about what suppliers do, what they can access and whether they meet their obligations.
- Continuity and availability. Backup, recovery and resilience appear on both sides.
The two standards also share the same management system structure. ISO/IEC 27001 and ISO/IEC 20000-1 follow the same high-level clause layout: context, leadership, planning, support, operation, performance evaluation and improvement. That makes running them together far easier than it used to be.
What goes wrong when they are kept apart
The symptoms are familiar. The security team writes an incident response procedure that does not match the service desk’s incident process, so analysts are not sure which one to follow. Changes that affect security controls go through a separate approval route the change advisory board knows nothing about. Asset data is held in two places and neither is complete.
Audits become painful too. The same people answer the same questions twice, for two auditors, about two versions of essentially the same process. Evidence is gathered separately, and inconsistencies between the two sets are exactly what auditors tend to spot.
Bringing them together
You do not need to merge teams or rewrite everything to see the benefit. A few practical steps go a long way.
Map the shared processes
Start by listing the processes and controls that appear in both worlds. For each one, decide which process is the single source of truth. In most cases the service management process should be the operational backbone, with security requirements built into it rather than run alongside it.
Build security into incident and change
Add security categories and triage questions to your incident process, with a clear handover to the security team when an incident meets agreed criteria. In change management, flag changes that affect security controls and make sure the right people review them within the normal process, not around it.
Use one asset and configuration record
Agree a single source for asset and configuration data, and add the attributes security needs, such as information classification, ownership and criticality. This one change often removes a large amount of duplicated work.
Look at risk together
Security risks and service risks often share the same causes. An ageing system with no support contract is both a continuity risk and a security risk. Reviewing them side by side gives a more honest picture and avoids competing priorities.
Plan audits together
If you hold, or are working towards, both certifications, consider an integrated management system and a combined audit. Many certification bodies will audit 27001 and 20000-1 together, which saves time and gives a more coherent view of how the organisation really runs.
Start where the friction is
If full integration feels like too much, pick the point where the two worlds rub against each other most. For many organisations that is security incident handling, because confusion there is most visible and the cost of a gap is highest. Fixing that one interface often builds the trust and momentum needed to tackle the rest.
The aim is not to make security a sub-process of IT, or the other way round. It is to make sure the way the organisation runs its services is also the way it protects its information, so people follow one set of steps and the evidence for both standards comes from the same place.
Trying to bring security and service management together? We work alongside specialist ISO/IEC 27001 partners on joined-up programmes. Book a free scoping call to talk it through.
