ITIL 4 Information Security Management Practice Guide

Most IT organisations run service management on ITIL and security on ISO/IEC 27001, and the two often meet only when an incident or an audit forces them to. ITIL 4 treats information security management as one of its management practices, which gives service teams a shared language for protecting the information the business depends on. This guide explains what the practice is, how it fits the ITIL 4 service value system, where it overlaps with an ISO 27001 information security management system (ISMS), and how to make the two work as one operating model rather than two parallel bureaucracies. It also covers where identities, including service accounts, API keys and other non-human identities (NHIs), sit inside the practice. It is written for service owners, ITSM process owners, security managers and the executives who sponsor both.

Key takeaways

ITIL 4 ISM is a practice, not a management system. It describes how service teams protect information; ISO/IEC 27001 defines the certifiable ISMS requirements. Use ITIL to run the work and 27001 to govern and evidence it.
Security lives inside other practices. Change enablement, incident management, service configuration management, supplier management and service request management carry most of the day-to-day security work.
The practice balances prevention, detection and correction. Controls that block delivery get bypassed, so security requirements must be designed into value streams, not bolted onto approvals.
ITIL Version 5 is now available, but ITIL 4 practice guidance remains current. PeopleCert lists both, with a Foundation bridge for ITIL 4 holders; the practice content described here is ITIL 4.
Non-human identities are a service asset. Service accounts, certificates and API keys should be configuration items with owners, change records and rotation, or they fall between the ITSM and security teams.

What it is and who it applies to

ITIL 4 is the service management framework owned by PeopleCert (which acquired Axelos). It is organised around the service value system: guiding principles, governance, the service value chain, practices and continual improvement, viewed through four dimensions (organisations and people, information and technology, partners and suppliers, value streams and processes). ITIL 4 describes 34 management practices in three groups: general management, service management and technical management. Information security management (ISM) is a general management practice, which signals that it applies across the organisation and not only to the IT department.

PeopleCert describes the ITIL 4 Practitioner: Information Security Management module as best practice guidance on how to protect the information needed by an organisation to conduct its business. The ITIL 4 practice guide frames that purpose in terms of managing risks to the confidentiality, integrity and availability of information, alongside other aspects such as authentication and non-repudiation.

Who uses it: organisations that already run ITIL-based service management and want security embedded in it, managed service providers that must show customers how security is handled in delivery, and ISMS owners who need operational processes their auditors can test.
What it is not: it is not a standard, carries no certification for the organisation, and contains no control catalogue comparable to ISO/IEC 27002. Individuals certify; organisations do not.
ITIL 4 and ITIL Version 5: PeopleCert's ITIL catalogue now lists ITIL (Version 5) alongside ITIL 4, announcing "The new ITIL is here!". The ITIL Version 5 Foundation page describes a focus on digital product and service management in AI-enabled environments and offers an ITIL Foundation Bridge for ITIL 4 Foundation holders. The page does not say ITIL 4 certifications lapse, and the ITIL 4 Practitioner: Information Security Management module was still listed when checked on 24 October 2026. Plan for the practice content to be carried into ITIL 5 practice guides, but check the PeopleCert catalogue before committing training budgets.

Certification facts (PeopleCert, checked 24 October 2026)

Item	ITIL 4 Practitioner: Information Security Management
Exam	20 multiple-choice questions, 30 minutes, closed book, 65% pass mark, English
Prerequisites	Any ITIL v3 certification, ITIL 4 Foundation or ITIL 4 Managing Professional, plus training through an accredited training organisation or ITIL official eLearning
Validity	3 years, renewed with 60 CPD points
Alternative route	ITIL 4 Specialist: Collaborate, Assure and Improve, which covers relationship management, supplier management, service level management, continual improvement and information security management together
Related module	ITIL Cyber Resilience, described by PeopleCert as guidance for cybersecurity and resilience management

Structure and key requirements

The practitioner syllabus follows the standard ITIL 4 practice structure. Each element is a useful checklist for designing the practice in your own organisation, whether or not anyone sits the exam.

Practice element	What it covers	What to define locally
Key concepts	Purpose of ISM; confidentiality, integrity and availability of information assets	Information classification scheme; risk appetite statement agreed with the board
Practice success factors and metrics	How effectiveness and maturity in reducing risk and meeting security standards are evaluated	3-6 measurable outcomes (see Evidence and assessment)
Processes	The practice's main activities and how they fit value streams	Risk assessment, control design, security incident handling, security testing, exception management
Roles and competencies	Key roles and how to position the practice in the organisation	Practice owner, practice manager, security risk owners, service owners' security responsibilities
Information and technology	Tools and technologies supporting security controls	SIEM, vulnerability scanning, identity governance, secrets management, ITSM integration
Partners and suppliers	Working with suppliers to strengthen security and resilience	Supplier security clauses, onboarding assessments, access for third-party support
Capability model	ITIL capability criteria to guide development of the practice	Current and target capability level, with a dated improvement plan

Prevention, detection and correction

ITIL 4 Foundation teaches that information security management must balance prevention (stopping incidents happening), detection (finding incidents that do happen) and correction (recovering from them). The practical point for service teams is that a value stream cannot rely on prevention alone. A change approval gate is prevention; it is worthless without monitoring that would detect an unauthorised change, and without a tested route to restore service.

How ISM touches the other practices

ITIL 4 practice	Security responsibility carried	Typical ISO/IEC 27001:2022 Annex A link
Change enablement	Security impact assessment, segregation of duties for approvers, emergency change review	A.8.32 Change management
Incident management	Recognising security incidents, handover to the security team, evidence handling	A.5.24 to A.5.28
Service configuration management	CMDB records for assets, owners and dependencies, including credentials and certificates	A.5.9 Inventory of information and other associated assets
Service request management	Access requests, approvals and fulfilment records	A.5.15 Access control, A.5.18 Access rights
Supplier management	Security requirements in contracts, supplier access, monitoring	A.5.19 to A.5.22
Service continuity management	Security during disruption, recovery of security controls	A.5.29, A.5.30
Monitoring and event management	Security event sources, alert routing, log retention	A.8.15 Logging, A.8.16 Monitoring activities
Problem management	Root cause of recurring security incidents and known errors with security impact	A.5.27 Learning from information security incidents

See the ISO 27002 Controls Guide for the control content behind each Annex A reference.

Identity and NHI requirements

Identity is where ITIL and security most often lose track of each other. The service desk fulfils access requests, the identity team runs the directory, and nobody owns the service account a project created three years ago. Treat identities, human and non-human, as first-class objects in the practices that already exist.

Service configuration management: record service accounts, workload identities, certificates and API keys as configuration items, with an accountable owner, the services that depend on them and an expiry or rotation date. See the Service Account Inventory Template.
Change enablement: creating a new NHI, granting it a privileged role or rotating a production secret is a change. Standard changes work well for routine rotation; new privileged grants should be normal changes with security review.
Service request management: access requests should carry an end date by default, and leaver events should trigger revocation of tokens and keys the person created, not only their account.
Incident management: a leaked key is a security incident with a service impact. Runbooks must say who can revoke it, how dependent services are kept running, and how rotation is verified.
Continuity and availability: rotation that is paused after an outage and never resumed is a classic gap. In the Microsoft Storm-0558 key breach, the US Cyber Safety Review Board found that manual rotation of consumer signing keys stopped in 2021 after an outage, leaving an old key active and unmonitored. That is a change, availability and security decision made in one practice without the others noticing.

See the Service Account Security Guide and the Secrets Rotation Runbook Template for operational detail.

Implementation steps

Agree the operating model. Decide whether the ISMS owner (often the CISO) is also the ITIL ISM practice owner. In most organisations one person should own both, with the ITSM process owners accountable for the security steps inside their practices.
Map the practices to the ISMS. Build a table like the one above for your own control set: for each applicable Annex A control in the Statement of Applicability, name the ITIL practice and the record that evidences it.
Fix the categorisation first. Add a "security" category and a security-flag field to incident, change and request records, with clear criteria for when the service desk hands over to the security team. Test it with a sample of last quarter's tickets.
Bring identities into the CMDB. Start with privileged service accounts and production secrets linked to critical services. Do not try to load every API key in one go.
Embed security in change. Add a short security impact question set to normal changes, define which change models need security approval, and create standard change models for routine security work such as certificate renewal and secret rotation.
Pilot in one value stream. Choose a value stream with a clear owner (for example, onboarding a new SaaS application) and run it end to end with the new steps. Measure lead time before and after; if security steps add more than they should, simplify before scaling.
Scale and automate. Integrate the ITSM tool with identity governance, vulnerability management and the SIEM so that records are created automatically. Keep a manual fallback documented for when integrations fail.
Roll back safely. If a new approval step blocks delivery, revert it to advisory mode with logging rather than removing it, and fix the criteria. Removing controls silently is how gaps like stopped rotation appear.

Small and large organisations

Small organisations: one person may hold the practice owner, ISMS manager and change approver roles. Compensate with peer review of that person's own changes and a short monthly security report to leadership.
Large organisations: separate the practice owner (policy and design) from practice managers in each region or platform team, and use the capability model to compare maturity across them.
Managed service providers: customers will ask how their security requirements flow into your change and incident processes. A documented practice mapping is often the fastest way to answer supplier security questionnaires.

Evidence and assessment

There is no organisational ITIL certification, so assurance comes from the ISMS audit, customer assessments and internal audit. Design records so they serve all three.

Evidence	Source	What an auditor checks
Security-categorised incident records	ITSM tool	Handover time to security, linkage to post-incident review
Change records with security assessment	ITSM tool	Sample of normal and emergency changes, approver independence
Access request and removal records	ITSM and identity governance	Approval before grant, removal within the target time
CMDB entries for privileged NHIs	CMDB	Owner present, rotation date, link to dependent services
Supplier security assessments	Supplier management records	Assessment before access, periodic review
Capability assessment	Practice owner	Current and target levels, dated improvement actions

Metrics that show the practice works

Security handover time: median time from a service desk ticket being flagged as security to the security team acknowledging it.
Changes causing security incidents: percentage of security incidents traced to a change, by change model.
Emergency change review rate: percentage of emergency changes reviewed retrospectively within the agreed period.
NHI ownership coverage: percentage of privileged service accounts and production secrets in the CMDB with a named owner and a rotation date not in the past.
Access removal time: median time between a leaver event and removal of all access, including tokens.
Security exceptions overdue: number of risk acceptances past their review date.

Mapping to other frameworks

ITIL 4 ISM activity	ISO/IEC 27001:2022	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Policy and risk appetite	Clauses 5.2, 6.1	GV.PO, GV.RM	PM-9
Security risk assessment of services	Clauses 6.1.2, 8.2	ID.RA	RA-3
Access requests and identity lifecycle	A.5.15 to A.5.18	PR.AA	AC-2, IA-5
Security in change enablement	A.8.32	ID.RA	CM-3
Security incident handling	A.5.24 to A.5.28	RS.MA, RS.AN	IR-4, IR-6, IR-8
Monitoring and event management	A.8.15, A.8.16	DE.CM, DE.AE	AU-6
Supplier security	A.5.19 to A.5.22	GV.SC	SR-6
Continual improvement	Clause 10	ID.IM	IR-4

CIS Controls v8.1 covers much of the same ground at safeguard level, notably Control 17 (Incident Response and Management). COBIT 2019 sits above both as a governance framework; see the COBIT 2019 Guide.

Choosing between ITIL ISM and an ISO 27001 ISMS

You need certification or customer assurance: ISO/IEC 27001 is the requirement; ITIL ISM helps you operate it. See the ISO 27001 Certification Guide.
You run ITSM but security is informal: start with the ITIL ISM practice to embed security in change, incident and request handling, then formalise as an ISMS when assurance demand grows.
You have a certified ISMS that service teams ignore: use the ITIL practice mapping to push ISMS controls into the tools and records teams already use.

Common pitfalls

Parallel processes: the security team runs its own incident queue and ticketing outside the ITSM tool, so service impact and security impact are never seen together.
Security as a change approval gate only: the security reviewer becomes a bottleneck, teams classify changes as standard to avoid review, and nothing detects unauthorised change.
Paused controls never resumed: a rotation or monitoring job is disabled after an outage under an emergency change and stays off, as the Storm-0558 key rotation gap showed.
Service desk as a social engineering route: password and MFA resets are fulfilled as routine requests without strong caller verification. See the Identity Incident Response Playbook.
CMDB without identities: servers and applications are recorded, but the credentials that connect them are not, so nobody can assess the impact of revoking a key during an incident.
Training mistaken for capability: staff hold the practitioner certificate but the practice has no metrics, no owner and no improvement plan.

Practitioner checklist

Name a single practice owner for information security management and record it alongside the ISMS roles.
Map every applicable Annex A control to an ITIL practice and the record that evidences it.
Add security categorisation and handover criteria to incident, change and request records.
Record privileged service accounts, certificates and production secrets as configuration items with owners and rotation dates.
Create standard change models for routine security work and require security review for new privileged grants.
Require strong caller verification for credential and MFA resets at the service desk.
Review every emergency change that disables or weakens a security control within an agreed period.
Report 3-6 practice metrics monthly and assess the practice against the capability model annually.
Check the PeopleCert catalogue for ITIL Version 5 practice guidance before renewing training plans.

ITIL 4 Information Security Management Guide: The Practice and Its Links to ISO 27001