COBIT (Control Objectives for Information and Related Technology): COBIT – Tutorial (about 60 minutes)

COBIT is ISACA's framework for the governance and management of enterprise information and technology. Boards, chief information officers, risk and compliance teams, IT auditors and consultants use it to decide what the organisation needs from its technology, who is accountable for it, and how well the supporting processes actually work. After this tutorial you will be able to explain how COBIT separates governance from management, read its core model of 40 objectives, tailor a governance system with design factors, run an assessment of process capability, and place COBIT next to ITIL, ISO/IEC 38500, ISO/IEC 27001, COSO and NIST CSF.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: COBIT is owned and published by ISACA. The edition that is fully published and documented today is COBIT 2019, released in late 2018 as the successor of COBIT 5 (2012); its four core publications are the Introduction and Methodology, the Governance and Management Objectives, the Design Guide and the Implementation Guide. ISACA has announced a new version, COBIT 7, for October 2026: ISACA's certificate page states that the COBIT 2019 Foundation certificate is being replaced by a COBIT 7 Foundations certificate from 27 October 2026, with the COBIT 2019 program sunset on 26 April 2027. ISACA says much of the new version will be delivered digitally and that it will include a flexible, customisable assessment module; launch reports from training partners and conference attendees describe COBIT 7 as building on COBIT 2019. At the time of writing its detailed content was not yet publicly available for independent review, and ISACA's main COBIT page still presents the COBIT 2019 publications. This tutorial therefore teaches the COBIT 2019 architecture, which is the foundation COBIT 7 extends. When you work with COBIT 7, check ISACA's current material for any new design factors, objectives or terminology. Verified 2026-10-29.

Who it is for: IT managers and engineers who are asked to "align with COBIT", internal and external auditors, risk, security and compliance staff, service managers, enterprise architects, and anyone preparing for an introductory COBIT course. You do not need to be an executive; COBIT is written for executives, but it is usually operated by the people who build, run and check technology.

Prerequisites: none. A general idea of how an IT department works (projects, operations, suppliers, security) is helpful. No accounting or audit background is assumed.

Learning objectives. After this tutorial you will be able to:

Explain why enterprises need governance of information and technology and what problem COBIT solves.
Distinguish governance from management and name the five domains of the COBIT core model.
Describe the seven kinds of components that make up a governance system and give an example of each.
Use the goals cascade to connect stakeholder needs to specific governance and management objectives.
Tailor a governance system with design factors and focus areas instead of implementing everything.
Explain capability and maturity levels, how an assessment is rated, and what COBIT certification does and does not mean.
Relate COBIT to ITIL, ISO/IEC 38500, ISO/IEC 27001, COSO, NIST CSF and other frameworks.

Lesson 1 – Origins, purpose and scope

Why technology needs governance

Almost every important business decision today depends on information and technology. A bank cannot open accounts without its core platform, a hospital cannot treat patients safely without accurate records, and a retailer cannot sell online without a working website and payment chain. Because technology is now woven into how value is created, the board and executives carry responsibility for it whether they like it or not. If a system fails, data leaks or a large programme overruns its budget, regulators, customers and shareholders hold the enterprise leadership accountable, not just the IT department.

Yet many organisations still treat technology as a cost centre run by specialists. Decisions about investment, risk and priorities are made inside IT with little business input, while the board receives technical reports it cannot judge. The result is familiar: projects that deliver features nobody needed, security spending that does not match the real threats, duplicated tools, and audits that find the same weaknesses year after year. Governance is the discipline that closes this gap. It makes sure that the enterprise decides, at the right level, what it wants from technology, and then checks that it gets it.

From audit checklist to governance framework

COBIT began in 1996 as a set of control objectives for IT auditors, published by the organisation now called ISACA (originally the Information Systems Audit and Control Association). The original name, Control Objectives for Information and Related Technology, explains that starting point: auditors needed a common reference for what good control over IT looks like. Over the following versions the scope widened. Later editions added management guidelines, maturity models and, with COBIT 4 in 2005, a full IT governance framework. COBIT 5 in 2012 merged ISACA's separate value and risk frameworks (Val IT and Risk IT) into one model and introduced the clear split between governance and management. COBIT 2019 kept that split, refreshed the content and added flexible tailoring through design factors and focus areas. ISACA no longer expands the acronym; the framework is simply called COBIT.

This history matters because it explains two features you will meet throughout the course. First, COBIT still speaks the language of control and assurance, which is why auditors like it. Second, it has grown into a framework for running technology as part of the business, which is why chief information officers and boards use it.

What COBIT is and is not

COBIT is a framework, not a standard you certify against. It describes what a well-governed enterprise should have in place for information and technology: objectives, practices, roles, information flows and other elements. It does not prescribe one way of working, a particular tool or a fixed organisation chart. It is also not an IT service management method in the sense that ITIL is; COBIT tells you that incident management must exist, perform well and be accountable, while ITIL offers detailed guidance on how to run it.

The scope of COBIT is the whole enterprise, not only the IT department. ISACA uses the phrase information and technology, often shortened to I&T, to stress that it covers all the information the enterprise generates and uses and all the technology that supports it, whether it is run internally, bought as a cloud service or operated by a business unit outside IT. COBIT calls the overall goal enterprise governance of information and technology, abbreviated EGIT.

The questions COBIT helps answer

What do our stakeholders need from information and technology, and how do we turn that into priorities?
Who decides, who is accountable and who does the work for each important area?
Which processes, policies, skills and tools must exist, and how well do they perform today?
How do we show the board, regulators and auditors that technology risk is under control?
How do we improve step by step, focusing on the areas that matter most for our situation?

Lesson 2 – Key concepts and vocabulary

COBIT has a precise vocabulary. Learning it early will make the rest of the framework much easier to read, because the same words appear in every publication and in every audit report that cites COBIT.

Information and technology (I&T) – all information the enterprise creates, processes and uses, together with the technology that supports it, regardless of who operates it.
Enterprise governance of information and technology (EGIT) – the part of corporate governance that ensures I&T creates value for stakeholders while risk and resources are kept under control.
Stakeholder – any party with an interest in how the enterprise uses I&T: board members, executives, business managers, IT staff, regulators, customers, shareholders, auditors and partners.
Governance – evaluating stakeholder needs and options, setting direction through prioritisation and decision-making, and monitoring performance and compliance against that direction. In most enterprises it is the responsibility of the board under its chair.
Management – planning, building, running and monitoring activities in line with the direction set by governance. It is the responsibility of executive management under the chief executive officer.
Governance system – the actual set of components an enterprise puts in place to govern I&T: its processes, structures, policies, information, culture, skills and supporting services. Each enterprise builds its own.
Governance framework – the reference that helps an enterprise design its governance system. COBIT is a governance framework.
Component – a building block of the governance system. COBIT names seven kinds of component, described in Lesson 3. Older editions called them enablers.
Governance or management objective – a statement of something the enterprise must achieve to govern or manage I&T, such as managed risk or managed changes. The core model has 40 of them.
Practice and activity – each objective's process is broken into practices (what must be done), and each practice into activities (more detailed steps). Activities are the unit that capability assessments rate.
Goals cascade – the mechanism that translates stakeholder needs into enterprise goals, then into alignment goals and finally into priority objectives.
Design factor – a characteristic of the enterprise, such as its strategy, risk profile or size, that influences how its governance system should be designed.
Focus area – a governance topic or situation, such as small enterprises, information security, risk or DevOps, that can be addressed by a set of objectives and components tailored to it.
Capability level – a rating from 0 to 5 that expresses how well a process is implemented and performs.
Maturity level – a rating from 0 to 5 that expresses how well a whole focus area or set of objectives is performing.
Core model – the generic set of 40 objectives, organised into five domains, that every tailored governance system starts from.

Two short phrases summarise the whole framework. Value creation is the overall governance objective: realising benefits at optimal resource cost while optimising risk. And governance is not management: different people, different activities and different questions.

Lesson 3 – Structure of the framework

Principles

COBIT 2019 rests on two sets of principles. Six principles describe what a good governance system should look like, and three describe what a good governance framework should look like. In paraphrase, the six governance system principles are:

Provide stakeholder value. The governance system exists to satisfy stakeholder needs and to create value from I&T; it is not an end in itself.
Holistic approach. It is built from several kinds of component that work together; processes alone are never enough.
Dynamic governance system. When a design factor changes, such as a new strategy, regulation or technology, the system must adapt.
Governance distinct from management. The two involve different activities, structures and accountabilities.
Tailored to enterprise needs. Design factors are used to customise and prioritise the components.
End-to-end governance system. It covers the whole enterprise and all information and technology, not just the IT function.

The three governance framework principles say that a framework should be based on a clear conceptual model, should be open and flexible so that new content can be added, and should be aligned with relevant major standards, frameworks and regulations. These are the reasons COBIT maps itself to other standards and offers focus-area guidance instead of a single fixed text.

The seven components

A governance system is made of components of seven kinds. Thinking about all seven avoids the classic mistake of believing that writing a process document is the same as governing something.

Processes – organised sets of practices and activities that achieve an objective, for example how changes are assessed and approved.
Organisational structures – the decision-making bodies and roles, such as the board, an executive committee, an architecture board or a chief information security officer, with their responsibilities.
Principles, policies and procedures – the rules that translate desired behaviour into practical guidance, from a short acceptable-use principle to a detailed procedure.
Information – the information items the governance system needs and produces, for example a risk register, a service-level report or an approved budget.
Culture, ethics and behaviour – how people actually behave, which can support or undermine everything else.
People, skills and competencies – the knowledge and abilities needed to make good decisions and carry out the work.
Services, infrastructure and applications – the tools and services that support governance itself, such as a governance, risk and compliance platform or a configuration management database.

Components can be generic, as described in the core model, or variants adapted to a focus area. For example, the information security focus area guidance contains security-specific practices, metrics and roles.

The core model: five domains and 40 objectives

The heart of COBIT is the core model, a set of 40 governance and management objectives grouped into five domains. One domain is for governance and four are for management. Each objective has a three-letter domain code and a number, which makes them easy to refer to in plans and audit reports.

Figure 1 – Governance sets direction and monitors; the four management domains plan, build, run and monitor in line with it.

The domains are:

EDM – Evaluate, Direct and Monitor (5 objectives). The governance domain. The governing body evaluates strategic options, directs management on the chosen options and monitors achievement. Its objectives cover setting up the governance framework itself, ensuring benefits delivery, ensuring risk optimisation, ensuring resource optimisation and ensuring stakeholder engagement.
APO – Align, Plan and Organise (14 objectives). Overall organisation, strategy and supporting activities: the I&T management framework, strategy, enterprise architecture, innovation, portfolio, budget and costs, human resources, relationships, service agreements, vendors, quality, risk, security and data.
BAI – Build, Acquire and Implement (11 objectives). Defining, acquiring and implementing solutions and integrating them into business processes: programmes, requirements, solution build, availability and capacity, organisational change, IT changes, change acceptance and transition, knowledge, assets, configuration and projects.
DSS – Deliver, Service and Support (6 objectives). Operational delivery and support: operations, service requests and incidents, problems, continuity, security services and business process controls.
MEA – Monitor, Evaluate and Assess (4 objectives). Monitoring performance and conformance: performance and conformance monitoring, the system of internal control, compliance with external requirements, and assurance.

Notice the naming pattern. Governance objectives start with "Ensured", because the board ensures that something is in place, while management objectives start with "Managed", because management manages it. So you will read EDM03 as the objective for ensured risk optimisation and APO12 as the objective for managed risk. The two are related but different: the board decides the risk appetite and checks that risk stays within it, while management identifies, analyses and responds to individual risks every day.

Another point that often surprises newcomers: MEA is a management domain, even though it monitors. EDM monitoring is the board looking at the big picture; MEA monitoring is management checking its own performance, internal controls, compliance and assurance and reporting upward.

What each objective contains

In the Governance and Management Objectives publication, each of the 40 objectives is described in the same layout. There is a purpose statement, the related enterprise and alignment goals with example metrics, and then guidance for each of the seven component types. The process component lists the practices with their activities; each activity is tagged with the capability level at which it is expected. The organisational structures component shows a responsibility chart for the practices. The information component lists inputs and outputs, showing which practice in which objective produces or consumes each item. The remaining components add skills, policies, cultural elements and supporting services, together with references to related standards. This consistent layout is what makes COBIT usable as a checklist and as a design reference at the same time.

The goals cascade

How do you decide which of the 40 objectives matter most for your enterprise? COBIT answers with the goals cascade. Stakeholder drivers, such as new regulation, a merger or a shift to digital channels, create stakeholder needs. These needs are expressed as enterprise goals, a generic list of 13 business-level goals grouped in the four perspectives of a balanced scorecard: financial, customer, internal, and growth. Each enterprise goal is supported by alignment goals, a second list of 13 goals that describe what I&T must achieve, for example secure information and infrastructure, or delivery of programmes on time and on budget. Finally, mapping tables show which governance and management objectives contribute most strongly to each alignment goal.

COBIT 2019 renamed the second level from "IT-related goals" in COBIT 5 to "alignment goals" to emphasise that these are goals for aligning I&T with the business, not technical goals of the IT department. The cascade is a guide, not an algorithm: the mapping tables show primary and secondary relationships, and a tailored cascade should always be checked with business managers.

Lesson 4 – How it works in practice

Designing a tailored governance system

COBIT is explicit that no enterprise should implement all 40 objectives at the highest capability level. That would be expensive and pointless. Instead, the COBIT 2019 Design Guide describes how to design a governance system that fits the enterprise, using design factors.

The design factors in COBIT 2019 are, in paraphrase: enterprise strategy (for example growth, innovation, cost leadership or stability), enterprise goals, risk profile, current I&T-related issues, threat landscape, compliance requirements, the role of IT (from a support function to a strategic one), the sourcing model, the IT implementation methods used (such as agile or traditional), the technology adoption strategy (early adopter or follower) and enterprise size. Partner reports indicate that COBIT 7 adds further design factors; check ISACA's current list when you use the new version.

Design factors influence three things: the priority of each governance and management objective, the target capability level for each process, and the choice of component variants, for example using DevOps-specific guidance for change management in a team that deploys many times a day. A strongly regulated bank with a high risk profile will push compliance, risk and security objectives up; a small, cloud-native start-up following an innovation strategy may prioritise innovation, portfolio and agile delivery and keep formal structures light.

Figure 3 – The design workflow uses design factors in four steps to produce a tailored governance system.

The workflow in Figure 3 has four steps. First, the team understands the enterprise context and strategy, using the strategy, goals, risk profile and current issues. Second, it determines an initial scope: a first list of priority objectives and target levels. Third, it refines that scope with the remaining design factors, adjusting priorities up or down. Fourth, it resolves conflicts between factors (for example a low-cost strategy against a demanding regulatory environment) and concludes the design. ISACA provides a spreadsheet design toolkit that turns design factor scores into suggested priorities; treat the toolkit output as a starting point for discussion, not a final answer.

Implementing and improving

Once the design is agreed, the COBIT 2019 Implementation Guide describes how to put it into practice and keep improving it. The guide uses a lifecycle of seven phases, each framed as a question, and three layers of concern that run through every phase: programme management, change enablement, and the continual improvement lifecycle itself.

Figure 4 – The seven-phase implementation lifecycle repeats, so governance improves in successive cycles.

What are the drivers? Identify the pain points and trigger events that make change necessary now, and secure sponsorship from senior management.
Where are we now? Use the design results to scope the work and assess the current capability of the priority processes and other components.
Where do we want to be? Set target capability levels, analyse the gaps and identify potential improvements, distinguishing quick wins from longer projects.
What needs to be done? Define practical improvement projects with business cases, owners and measures of success.
How do we get there? Implement the improvements, embed new practices in daily work and support people through the change.
Did we get there? Check that the improvements are working and that the expected benefits are being realised.
How do we keep the momentum going? Review the overall success, identify further needs and start the next cycle.

The change enablement layer reminds you that governance improvement is mostly a people problem. New approval rules, new committees or new reporting will be resisted if staff see them as bureaucracy. Communicating the reasons, involving the people affected and celebrating early results are as important as the process designs themselves.

Roles and responsibilities

COBIT's responsibility charts use a familiar pattern: for each practice they indicate which role is accountable and which roles are responsible, with others consulted or informed. Typical roles include the board, an executive committee, the chief executive officer, chief financial officer, chief risk officer, chief information officer, chief technology officer, chief digital officer, chief information security officer, an I&T governance board, an architecture board, an enterprise risk committee, business process owners, portfolio, programme and project managers, service and relationship managers, and the internal audit function. The names are examples. A small company may combine several roles in one person; what matters is that for each important practice, one role is clearly accountable.

Key artefacts

Implementing COBIT produces artefacts that you will see in many organisations: a governance charter or terms of reference for the governance bodies, an I&T strategy and roadmap, a risk appetite statement and risk register, a policy framework, a portfolio of investments with business cases, service-level agreements, a capability assessment report with target levels and gaps, an improvement roadmap, and regular performance and conformance reports to the board. None of these is mandated in a fixed form; COBIT describes the information items, and the enterprise decides how to produce them.

Focus areas and newer guidance

Because the framework is open and flexible, ISACA publishes focus-area guidance that adapts the core model to specific topics. Examples include guidance for small and medium enterprises, information security, information and technology risk, and DevOps, together with companion audit programmes and white papers, such as a 2025 paper on using COBIT to govern artificial intelligence systems. Focus areas do not add new objectives to the core model; they add variants, extra practices and examples relevant to the topic.

Lesson 5 – Assessment, certification and compliance

The COBIT performance management approach

Governance is only credible if you can say how well things are working. COBIT 2019 includes a performance management approach, often abbreviated CPM, that is based on and aligned with the capability concepts of CMMI. It uses two related scales.

Capability levels apply to processes, the process component of each objective. A process at level 0 lacks basic capability, so its purpose is not achieved. At level 1 it more or less achieves its purpose, but through an incomplete set of activities and in an unpredictable, reactive way. At level 2 the basic purpose is achieved through a complete set of activities that are planned and managed. Level 3 adds a defined, organisation-wide way of working; level 4 adds quantitative measurement and control; and level 5 adds continuous improvement based on that measurement. Because each activity in the core model is tagged with a capability level, an assessor can see which activities must be in place to reach a given level.

Maturity levels apply to focus areas or to a selected set of objectives, for example the information security focus area as a whole. They use the same 0 to 5 scale and express whether all the processes in scope reach the corresponding capability level. COBIT 2019 provides a formal scale for processes and lighter guidance for other components, for example quality criteria for information items.

How an assessment is rated

An assessor gathers evidence through interviews, document reviews, observation and system data, and then rates whether each activity at a given level is performed. COBIT 2019 suggests four rating values: fully achieved (more than 85 %), largely achieved (over 50 % up to 85 %), partially achieved (over 15 % up to 50 %) and not achieved (15 % or less). ISACA also notes that simpler methods, such as a binary yes/no or an informal 1–5 score, can be used in less formal improvement contexts. The levels build on each other: the activities of a higher level only make sense when those of the lower levels are in place, which is why levels cannot be skipped.

The value of an assessment is not the number itself but the gap analysis. A process at level 2 against a target of 3 tells you which defined-level activities are missing, and the improvement plan follows from that. Setting every target to 5 is a warning sign that design factors were ignored.

Who assesses

Assessments can be self-assessments run by process owners, internal assessments by internal audit or a governance office, or independent assessments by external consultants or audit firms. Auditors also use COBIT as a reference for IT audits, for example when evaluating IT general controls under the Sarbanes-Oxley Act; ISACA has published guidance on control objectives for that purpose. In each case the assessor should be competent and independent enough for the purpose, and the evidence should be retained so that the result can be checked.

Certification: individuals, not organisations

There is no formal certification of organisations against COBIT. No accredited body issues a "COBIT certified" certificate to an enterprise, in contrast to ISO/IEC 27001 or ISO 9001, where accredited certification bodies audit and certify management systems. An organisation can say that its governance system is based on COBIT, or that an independent assessment found certain processes at certain capability levels, but such claims should always state who assessed what and when.

Certification exists for individuals. ISACA offers a COBIT Foundation certificate for understanding the framework and a COBIT Design and Implementation certificate for applying it. With the launch of COBIT 7, ISACA is replacing the COBIT 2019 Foundation certificate with a COBIT 7 Foundations certificate. Accredited training partners report that certificates already earned under COBIT 2019 are not cancelled. Training is delivered by ISACA and by accredited training partners. ISACA's professional certifications for auditors, security managers and governance professionals also draw heavily on COBIT concepts.

COBIT and regulation

COBIT is not a law, and no regulation makes it mandatory in general. Some financial supervisors refer to it in their IT governance guidance, and public-sector and internal auditors often use it as a reference when they audit technology. Because COBIT maps itself to other standards, it is also used as an umbrella to show how a single control set supports several regulatory requirements at once, for example operational resilience, data protection and security regulations.

Lesson 6 – Worked example

The organisation

Northwind Mutual is a fictional mid-sized insurance company with 1,800 employees. Its IT department of 140 people runs a mix of an older policy administration system, a growing set of cloud services and several outsourced functions, including the service desk. In the last year it suffered two serious incidents: an outage of its online claims portal during a storm, and a misconfigured cloud storage bucket that exposed customer documents. The insurance supervisor has asked the board to show how it governs technology risk, and the internal audit function has repeated findings on change management and supplier oversight.

Phase 1 – Drivers

The board appoints the chief operating officer as sponsor and asks the chief information officer and the chief risk officer to lead a COBIT-based improvement programme. The drivers are clear: supervisory pressure, two incidents with customer impact, and audit findings. The sponsor sets a scope of eighteen months and agrees that the board's risk committee will receive quarterly progress reports. This already applies a COBIT idea: governance stays with the board, and management delivers.

Design – using the design factors

The programme team runs workshops to score the design factors. Northwind's strategy is mainly stability and customer service, with some growth in digital channels. Its risk profile is high for availability, information security and third-party risk. The threat landscape is elevated because insurers hold valuable personal data. Compliance requirements are strong. The role of IT is "factory": the business cannot operate without it, although technology is not itself the product. The sourcing model is mixed, with significant outsourcing. Implementation methods are mixed, with agile teams for the portal and traditional projects for the core system. The company is a medium-to-large enterprise.

Using the goals cascade, the team links the board's concerns to enterprise goals about managed business risk, compliance with external laws and regulations, and business service continuity and availability. These in turn point to alignment goals about secure information and infrastructure, managed I&T-related risk and dependable delivery of services. The mapping tables and the design toolkit then suggest the highest-priority objectives. After discussion, the team agrees a focused list:

Governance: EDM03 (ensured risk optimisation) and EDM05 (ensured stakeholder engagement, including reporting to the supervisor).
Management: APO10 (managed vendors), APO12 (managed risk), APO13 (managed security), BAI06 (managed IT changes), BAI10 (managed configuration), DSS02 (managed service requests and incidents), DSS04 (managed continuity) and MEA03 (managed compliance with external requirements).

The team deliberately leaves objectives such as APO04 (innovation) at a lower priority for this cycle. That is not because innovation is unimportant, but because the design factors say that risk and stability dominate today.

Phases 2 and 3 – Current state and targets

Internal audit, with an external adviser for independence, performs a capability assessment of the eight management processes. Evidence includes interviews with process owners, change records, incident tickets, supplier contracts and continuity test reports. The results show that incident management (DSS02) is at level 2, because the outsourced service desk follows a complete, managed procedure. Change management (BAI06) is only at level 1: changes are often approved, but emergency changes bypass review and cloud configuration changes are not recorded at all, which explains the storage incident. Vendor management (APO10) is at level 1, because contracts lack security and service-level clauses and nobody monitors supplier performance. Continuity (DSS04) is at level 1, because plans exist but have never been tested against a regional outage.

The team sets target levels using the design factors: level 3 for change, security, risk, continuity and incident management, because the risk profile and supervision demand an organisation-wide defined approach; level 2 for configuration and vendor management in the first cycle, aiming at 3 in the next. No target is set at 4 or 5 yet; quantitative management is a later ambition.

Phases 4 and 5 – Improvements

The improvement plan considers all seven component types, not only processes:

Processes: one change procedure for all platforms, including infrastructure-as-code pipelines, with automated recording of cloud configuration changes and a short, documented emergency path.
Organisational structures: a technology risk committee reporting to the board risk committee, and a named owner for each critical supplier.
Principles, policies and procedures: an updated supplier policy requiring security and continuity clauses and annual reviews.
Information: a single risk register for technology risks linked to the enterprise risk register, and a quarterly board dashboard.
Culture, ethics and behaviour: leaders publicly support "no change without a record", and teams review incidents without blame.
People, skills and competencies: training for product owners on change and risk, and cloud security skills for platform engineers.
Services, infrastructure and applications: a configuration management database fed automatically from cloud accounts, and continuity testing tools.

The agile portal team uses the DevOps focus-area guidance so that controls are built into the delivery pipeline rather than added as manual approval gates. Change enablement activities include a short explanation of why each new rule exists and early wins, such as faster approval of standard changes.

Phases 6 and 7 – Results and momentum

After twelve months a follow-up assessment finds change management at level 3, continuity at level 2 after a first full test, and vendor management at level 2. The number of failed changes falls and the supervisor accepts the board's governance report. The board risk committee reviews the results, confirms that technology risk is within appetite and directs management to start the next cycle, adding data management (APO14) and enterprise architecture (APO03) as the company plans a new claims platform. The lifecycle starts again with new drivers.

Notice how the example uses each part of the framework: governance and management are kept separate, the goals cascade and design factors select priorities, capability levels measure progress, all seven components are improved, and the implementation lifecycle keeps the effort repeating rather than ending as a one-off project.

Lesson 7 – Relationship to other standards and frameworks

COBIT is designed to work alongside other frameworks rather than replace them. Its role is often described as an umbrella or integrator: it says what must be governed and managed and how well, and it points to more detailed standards for how to do specific things. ISACA publishes mappings between COBIT objectives and many other references.

Framework or standard	Main purpose	Relationship to COBIT
ISO/IEC 38500 (governance of IT)	Principles and a model for boards governing the use of IT	Its evaluate–direct–monitor model is reflected in COBIT's EDM domain; COBIT adds detailed objectives, practices and measurement.
ITIL	Detailed guidance for IT and digital service management practices	COBIT defines what service-related objectives must achieve and how well; ITIL explains how to run practices such as incident, change and service level management.
ISO/IEC 27001 and 27002	Requirements for an information security management system and a reference set of security controls; certifiable	COBIT treats security as objectives APO13 and DSS05 within wider governance; ISO/IEC 27001 gives the certifiable security management system and detailed controls.
COSO Internal Control – Integrated Framework	Enterprise-wide internal control, widely used for financial reporting	COBIT translates internal-control thinking to information and technology; MEA02 addresses the system of internal control, and auditors use both together.
NIST Cybersecurity Framework	Outcomes for managing cybersecurity risk, organised into functions	NIST CSF focuses on cybersecurity outcomes; COBIT places them within enterprise governance, risk appetite and performance management. ISACA has published guidance on implementing the NIST CSF with COBIT.
ISO/IEC 20000-1	Certifiable requirements for a service management system	Provides an auditable service management system; COBIT's DSS and BAI objectives overlap and add governance context.
CMMI	Capability and maturity model for improving performance	COBIT's performance management approach is based on CMMI capability concepts; both are now owned by ISACA.
TOGAF	Method for developing enterprise architecture	COBIT's APO03 requires managed enterprise architecture; TOGAF offers a method for doing it.

A useful rule of thumb: when a manager asks "should we use COBIT or ITIL?", the answer is usually both, at different levels. COBIT helps the board and executives decide priorities, accountability and how much capability is needed; ITIL, ISO/IEC 27001 and similar standards help practitioners do the work well. Using COBIT's mappings, an enterprise can also show auditors that one set of controls satisfies several frameworks, which reduces duplicated compliance effort.

COBIT is also close to ISACA's own Digital Trust Ecosystem Framework, which addresses trust across an organisation and its partners, and to ISACA's guidance on governing artificial intelligence. These do not replace COBIT; they extend governance thinking to newer concerns.

Common pitfalls and best practices

Pitfalls

Implementing all 40 objectives at once. Treating the core model as a checklist to complete leads to paperwork and fatigue. Use design factors to prioritise a few objectives per cycle.
Confusing governance with management. Boards that approve individual changes, or IT managers who set the enterprise's risk appetite, blur accountability. Keep direction-setting and monitoring with the board and execution with management.
Processes only. Writing process documents without addressing structures, skills, information, culture and tools produces governance that exists on paper but not in practice.
Chasing high capability levels for their own sake. A target of level 5 everywhere is costly and rarely justified. Targets should follow risk and value.
Claiming "COBIT certification" for the organisation. No such scheme exists; misleading claims damage credibility with auditors and customers.
A one-off project. Governance that stops after the first assessment decays quickly. The lifecycle is meant to repeat.
Ignoring culture and change. New rules imposed without explanation lead to workarounds, such as the unrecorded changes in the worked example.

Best practices

Start from pain points and stakeholder needs. Link every improvement to a real driver that the business recognises.
Secure board sponsorship and clear accountability. Name one accountable role for each priority practice and report results to the governing body.
Use the goals cascade and design factors openly. Document why objectives were prioritised or deprioritised so the decision can be revisited when circumstances change.
Assess with evidence. Base capability ratings on records and observation, not opinion, and keep the evidence for follow-up.
Integrate, do not duplicate. Use COBIT as the umbrella and map it to the standards already in use, such as ITIL, ISO/IEC 27001 and NIST CSF.
Build controls into daily work. Automate controls in delivery pipelines and tools where possible, especially for agile and DevOps teams.
Measure benefits, not just activity. Track outcomes such as fewer failed changes, faster recovery or audit findings closed.

Summary and key takeaways

COBIT is ISACA's framework for enterprise governance of information and technology; COBIT 2019 is the fully documented edition; COBIT 7, launched in October 2026, is reported to build on it.
Governance (the board: evaluate, direct, monitor) is distinct from management (executives: plan, build, run, monitor).
The core model has 40 objectives in five domains: EDM for governance, and APO, BAI, DSS and MEA for management.
A governance system is made of seven kinds of component, from processes and structures to culture, skills and tools.
The goals cascade links stakeholder needs to enterprise goals, alignment goals and priority objectives.
Design factors and focus areas tailor the system, setting priorities, target capability levels and component variants.
Capability levels (0–5) measure processes, maturity levels measure focus areas, and ratings use fully, largely, partially or not achieved.
Only individuals are certified in COBIT; organisations can be assessed but not certified.

Reflection questions

In your organisation, who acts as the governing body for information and technology decisions, and where do governance and management responsibilities currently overlap?
Score your organisation on five of the design factors. Which three objectives would you expect them to push to the top of the priority list, and why?
Pick one process you know well, such as change or incident management. What evidence would you collect to decide whether it is at capability level 2 or level 3?
For a governance problem you have seen, which of the seven component types was missing or weak, and how would you strengthen it?
Your organisation already uses ITIL and holds ISO/IEC 27001 certification. How would you explain to the board what COBIT would add, and what it would not replace?