COBIT vs ITIL vs ISO 27001: How Governance, Service and Security Frameworks Fit Together

Organisations often treat COBIT, ITIL and ISO/IEC 27001 as rival choices, then end up running three parallel programmes with three risk registers, three sets of process owners and three audit trails. They are not alternatives. COBIT is a governance framework for enterprise information and technology, ITIL is service management practice guidance, and ISO/IEC 27001 is a certifiable requirements standard for an information security management system (ISMS). Each answers a different question for a different audience. This guide compares their purpose, audience, certification options and overlap, shows how to combine them into one operating model, and sets out what auditors expect to see. It is for CISOs, CIOs, GRC leads, ITSM owners and IT auditors, and goes beyond the single-framework COBIT 2019 Guide, ITIL 4 Information Security Management Guide and ISO 27001 Certification Guide, which it does not repeat.

Status checked 14 November 2026: ISACA presents COBIT 2019 as the current COBIT release; PeopleCert offers both ITIL 4 and ITIL Version 5 certifications; ISO lists ISO/IEC 27001:2022 as the current edition.

Key takeaways

• Three questions, three frameworks. COBIT asks "is I&T governed and does it serve enterprise goals?", ITIL asks "are services delivered and supported well?", ISO/IEC 27001 asks "is information security risk managed by a system that works?".
• Only ISO/IEC 27001 certifies the organisation. COBIT and ITIL certify individuals. ITIL's organisational counterpart is ISO/IEC 20000-1, which PeopleCert says ITIL aligns with.
• Overlap is large but not duplication. Change, incident, asset, configuration and supplier management appear in all three, at different levels: COBIT sets the objective, ITIL describes the practice, ISO/IEC 27001 Annex A states the control the auditor tests.
• Combine by layering, not merging. Use COBIT for the governance layer and board reporting, ISO/IEC 27001 for the security management system and its evidence, ITIL for the day-to-day processes that produce that evidence.
• Auditors want one story. A single risk methodology, one owner per process, and records that trace from a board objective to a tested control are worth more than three separate maturity scores.

The short answer

If you need a certificate that customers and regulators recognise for information security, implement ISO/IEC 27001. If you need your IT services to run predictably, use ITIL practices (and ISO/IEC 20000-1 if you need to certify service management). If your board, regulator or internal audit needs assurance that technology is governed against business goals, use COBIT. Most medium and large organisations end up using all three, each in its own lane. A small organisation usually starts with ISO/IEC 27001, adopts the ITIL practices it needs for change and incident handling, and borrows COBIT ideas only when governance reporting becomes a requirement.

Side-by-side comparison

COBIT: the governance layer

Purpose and audience

ISACA describes COBIT as a framework to govern and manage IT holistically across end-to-end business and IT areas. Its value is a common language between the board and technology: the governance domain (Evaluate, Direct and Monitor) separates what the board decides from what management executes. The core publication set is the Introduction and Methodology, the Governance and Management Objectives, the Design Guide and the Implementation Guide, with focus area guides including Information Security, Information and Technology Risk, and DevOps.

What it does well and where it stops

• Strength: links technology objectives to enterprise goals through a goals cascade, and gives audit a structured way to assess whether governance is designed and operating.
• Strength: design factors (strategy, risk profile, threat landscape, compliance requirements, sourcing, size) make the scope proportionate.
• Limit: it is not a security control catalogue. Security objectives such as APO13 Managed Security, DSS05 Managed Security Services and DSS06 Managed Business Process Controls point to standards like ISO/IEC 27001 for the detail.
• Limit: no organisational certificate, so it does not answer a customer asking for proof of security.

Failure modes

Treating COBIT as a document library rather than a governance system; scoring capability across all 40 objectives instead of prioritising with design factors; running COBIT assessments that never feed decisions at the board.

ITIL: the service operations layer

Purpose and audience

PeopleCert positions ITIL as best practice for anyone delivering or supporting IT services and states that it aligns with international quality standards including ISO/IEC 20000. ITIL 4 organises guidance around the service value system and management practices, and treats information security management as one of them. ITIL Version 5 is now offered alongside ITIL 4, with a Foundation bridge for ITIL 4 holders and new modules including AI governance. Practice content for security in this guide refers to ITIL 4, which remains available.

What it does well and where it stops

• Strength: the practices that generate most security evidence (change enablement, incident management, service configuration management, IT asset management, supplier management, service request management) are described in operational depth.
• Strength: a shared vocabulary for service desks, operations and suppliers, which matters when security processes cross outsourced boundaries.
• Limit: no requirements to audit against, so "we follow ITIL" is not evidence. ISO/IEC 20000-1, edition 3 (2018), amended in 2024 for climate action changes, is the standard that specifies service management system requirements an organisation can be certified against.
• Limit: security risk assessment and control selection are not its focus; those come from the ISMS.

Failure modes

Change advisory boards that approve risky changes without a security reviewer; service accounts and certificates not recorded as configuration items, so nobody owns their rotation; incident and security incident queues that never meet. See the Service Account Inventory Template for the identity side.

ISO/IEC 27001: the security management system layer

Purpose and audience

ISO describes ISO/IEC 27001:2022 as the standard that sets requirements for an information security management system, with certification optional and not carried out by ISO itself. Clauses 4 to 10 cover context, leadership, planning (including risk assessment and treatment), support, operation, performance evaluation and improvement. Annex A lists controls that the organisation compares against its risk treatment, recording inclusions and exclusions in a Statement of Applicability. See the ISO 27001 Statement of Applicability Template.

What it does well and where it stops

• Strength: the only one of the three that produces an organisational certificate recognised in contracts and supplier assessments.
• Strength: a mandatory management cycle (internal audit, management review, corrective action) that keeps the system alive between audits.
• Limit: scope is chosen by the organisation, so a certificate can cover a narrow part of the business. See Verifying Supplier ISO 27001 Certificates.
• Limit: it says what must be managed, not how to run the service processes that do it day to day.

Failure modes

An ISMS built as a parallel bureaucracy with its own change and incident forms; a scope drawn to pass rather than to protect; risk assessments disconnected from the enterprise risk register that COBIT governance and the board actually use.

Where they overlap: one process, three lenses

The same operational process often answers to all three frameworks. The mapping below is NHI Mgmt Group guidance to show the layering; confirm objective and control wording against the licensed texts before using it as audit evidence.

How to combine them into one operating model

1. Decide the lanes: COBIT for governance objectives, board reporting and audit assessment; ISO/IEC 27001 for the ISMS (scope, risk method, Statement of Applicability, internal audit); ITIL for operational processes. Write this down in the ISMS scope document and the IT governance charter.
2. One risk method: use a single risk taxonomy and scale feeding both the enterprise risk register (COBIT APO12 and EDM03) and the ISMS risk treatment plan. Two scales guarantee disagreement at management review.
3. One process, one owner: change, incident, asset and supplier processes are designed once (ITIL), with security steps embedded, and referenced by the ISMS as the way Annex A controls operate. Do not create an ISMS-only change form.
4. One evidence trail: the records ITIL processes generate (change tickets with security review, incident post-reviews, CMDB ownership) are the evidence the ISO auditor samples and the COBIT assessment relies on.
5. One improvement loop: feed ISO/IEC 27001 internal audit findings, ITIL continual improvement items and COBIT capability gaps into one register with one prioritisation.
6. Pilot and test: run the combined model on one service first, then perform an internal audit against ISO/IEC 27001 and a COBIT-style assessment of the same scope. Fix gaps before extending. If the combined model slows delivery, roll back to the previous process for that service while you redesign, and record the decision.

What auditors expect

Accredited certification matters for ISO/IEC 27001 and ISO/IEC 20000-1. Mutual recognition of accredited certificates was historically coordinated through the IAF Multilateral Recognition Arrangement; the IAF site notes that IAF ceased operations on 1 January 2026, with current information published by its successor, Global Accreditation Cooperation Incorporated. Check the certification body's accreditation and the certificate scope before relying on a supplier's claim. See the ISO 27001 Certification Body Selection guide.

Decision guidance

Worked scenario: a mid-sized logistics company

A 1,200-person logistics firm has an ITIL-based service desk run partly by an outsourcer, a customer demanding ISO/IEC 27001 certification within a year, and an audit committee asking for assurance over IT governance after a failed system migration.

• Lane decision: ISO/IEC 27001 scope covers the customer-facing platform and supporting IT operations; ITIL processes stay as the operating model; internal audit adopts a COBIT-based programme focused on a short list of objectives chosen with design factors (BAI06 and BAI11 Managed Projects, given the migration failure, plus APO13).
• Integration: the change process gains a mandatory security impact field and a security approver for high-risk changes, which the ISMS cites as how A.8.32 operates; service accounts and certificates become configuration items with owners.
• Supplier: the outsourcer's obligations are written against the same incident and change processes, with right-to-audit clauses that the ISMS supplier controls reference.
• Result: one change record satisfies the ISO auditor's sample, the internal audit's COBIT assessment and the outsourcer's SLA reporting.

Detection and measurement

• Single-process coverage: share of in-scope processes with one owner and one procedure referenced by all three frameworks.
• Change security review rate: percentage of high-risk changes with a recorded security review before implementation.
• Audit finding recurrence: nonconformities or findings that reappear in consecutive ISO surveillance or internal audits.
• Risk register alignment: ISMS risks traceable to an enterprise risk entry (target 100%).
• Configuration item ownership: share of service accounts, certificates and keys recorded as configuration items with a named owner.
• Corrective action closure: median days to close audit actions, by framework source.

Framework mapping to NIST CSF 2.0

Common failure patterns

• Framework shopping: picking one framework and declaring the others irrelevant, then failing a customer or regulator who expects a different kind of assurance.
• Three registers: separate risk, issue and improvement registers per framework that never reconcile.
• ITIL as evidence: citing "we follow ITIL" to an ISO auditor instead of showing records from a defined process.
• Narrow certificate, broad claim: an ISO/IEC 27001 scope covering one site or product presented as company-wide assurance.
• Orphaned machine identities: service accounts and API keys owned by neither the service team nor the ISMS, so neither change nor access review touches them.

Practitioner checklist

• Write a one-page statement of which framework governs which layer and who owns each.
• Adopt one risk taxonomy and scale for the enterprise register and the ISMS.
• Design change, incident, asset, configuration and supplier processes once, with security steps embedded.
• Reference those processes in the Statement of Applicability as the way Annex A controls operate.
• Choose a short list of COBIT objectives using design factors rather than assessing all 40.
• Decide whether ISO/IEC 20000-1 certification adds value for customers before pursuing it.
• Verify certification body accreditation and certificate scope, for yourself and suppliers.
• Run one combined improvement register and report it at management review.

Standards and references

• ISO: ISO/IEC 27001 Information security management systems
• ISO: ISO/IEC 20000-1:2018 Service management system requirements
• ISACA: COBIT
• PeopleCert: ITIL certifications
• NIST: Cybersecurity Framework 2.0
• IAF: About the IAF MLA

Related NHI Mgmt Group resources: COBIT 2019 Guide · ITIL 4 Information Security Management Guide · ISO 27001 Certification Guide · Regulations and Frameworks Guide · Control Mapping Guide