COBIT capability levels are the 0-to-5 scale on which COBIT 2019 rates each process, and they are easy to misread because the framework uses two scales that look alike. Capability is measured per process — the process component of each governance or management objective — and answers “how well is this process performed?” Maturity is measured per focus area, aggregating capability across the objectives a focus area contains, and answers “how mature is our governance of, say, information security?
The capability scale is where design targets are set and assessments are scored, which makes it the one that drives budgets. This guide defines the six COBIT capability levels as the framework describes them, explains how a process is rated (and why level 2 is where most first assessments land), how targets are set from the design factors, how the maturity levels aggregate, how a capability assessment is run and evidenced, and what to do when the assessment finds a process at 1 that the design says should be at 3.

The six COBIT capability levels
| Level | Name | What the process looks like | What an assessor needs to see |
|---|---|---|---|
| 0 | Incomplete | The process is not implemented, or fails to achieve its purpose; there is little or no evidence of systematic achievement | Nothing that qualifies as the process |
| 1 | Initial | The process more or less achieves its purpose through an incomplete set of activities, characterised as initial or intuitive — not very organised | Some of the practices performed, informally, inconsistently, dependent on individuals |
| 2 | Managed | The process achieves its purpose through the application of a basic, yet complete, set of activities that can be characterised as performed | All the base practices performed; the process planned, monitored and adjusted; work products controlled |
| 3 | Defined | The process achieves its purpose in a much more organised way, using organisational assets; processes typically are well defined | A defined standard process, documented, deployed consistently across the organisation, with roles and competences |
| 4 | Quantitative | The process achieves its purpose, is well defined, and its performance is (quantitatively) measured | Measurement objectives, data collected and analysed, performance understood in numbers |
| 5 | Optimizing | The process achieves its purpose, is well defined, its performance is measured to improve performance, and continuous improvement is pursued | Improvement driven by measurement; innovation in the process |
Two features of the scale shape every assessment. The levels are cumulative: a process at level 3 has met everything levels 1 and 2 require. And the framework’s activities within each objective’s management practices are themselves tagged with a capability level, so the assessor’s question at each level is whether the activities tagged for that level are performed — a level-2 rating means the level-2 activities are being done, not that the process feels “managed”. COBIT 2019 keeps the scale compatible with CMMI’s performance management concepts, which is why the level names echo CMMI’s.
How a COBIT capability level is rated
- Take the objective’s process and its management practices. Each objective — APO12 Managed Risk, DSS02 Managed Service Requests and Incidents — lists practices, and each practice lists activities with a capability level attached.
- Assess achievement level by level. Are the level-2 activities performed? Fully, largely, partially, not at all. The framework’s rating scale — fully (over 85% achieved), largely (50–85%), partially (15–50%), not (under 15%) — is what the score records.
- A level is achieved when its activities are fully or largely achieved, and the next level is assessed only if the current one is.
- Evidence, not opinion. Work products the activities produce, records that show consistency, people who perform them, and, from level 4, the measurements.
- Record the rating with the gap. “DSS02 at level 2, largely achieved; level 3 partially achieved — no defined standard process across sites” is an assessment result an implementation programme can use.
Most first assessments in organisations without a formal governance programme land at level 1 or 2 for the majority of processes, and that is not a failing grade: the design factors, not the scale, decide what level each process should be at. Our guide to COBIT design factors covers how the targets are set.
Setting target COBIT capability levels
| Target level | Typically appropriate when | Example |
|---|---|---|
| 1 | The objective is in scope only because completeness demands it; low priority from the design factors | APO04 innovation in a slow-adopter cost-leadership firm |
| 2 | The process must run reliably but organisation-wide standardisation is not worth the cost | BAI08 knowledge management in a single-site company |
| 3 | The default for objectives the design prioritises: a defined, consistently deployed process | DSS02 incidents, BAI06 changes, APO09 service agreements in most enterprises |
| 4 | The process is critical enough that performance must be measured and managed by number — high threat landscape, high compliance, regulator-facing | APO12 risk, APO13 security, DSS05 security services, MEA03 compliance in a regulated firm |
| 5 | Rarely justified; the process is a competitive differentiator whose continuous improvement pays | DSS01 operations in a cloud provider whose product is operations |
A governance system whose every target is 5 is a design that has not been done; one whose targets vary from 1 to 4 across the objectives in scope is the output the Design Guide expects.
COBIT capability levels versus maturity levels
| Capability | Maturity | |
|---|---|---|
| Unit | A process — the process component of one objective | A focus area — a governance topic spanning several objectives (e.g. security, risk, DevOps, SME) |
| Scale | 0–5 per process | 0–5 per focus area |
| How derived | Assessed directly against the activities | Aggregated from the capability levels of the objectives in the focus area — a maturity level is reached when all the relevant processes reach the corresponding capability level |
| Used for | Design targets; assessment scores; implementation phase 2 (where are we now?) and phase 3 (where do we want to be?) | Board-level statements about a topic’s governance |
| Common error | Rating the organisation instead of the process | Reporting a maturity level without the underlying capability assessment |
Running a COBIT capability assessment
- Scope it from the design. Assess the objectives the governance system design put in scope — fourteen, not forty — against their target levels.
- Use the framework’s activities as the checklist, with the level tag on each activity as the rating structure.
- Gather evidence per activity: work products, records, interviews with the people who perform it, and metrics where level 4 is targeted.
- Rate honestly with the four-point achievement scale, and stop at the first level not largely achieved.
- Report the gap per objective — current level, target level, the activities missing at each intervening level, and the components (structures, information, skills, tools, culture) the gap involves.
- Feed phase 4 of the implementation lifecycle. The gaps, prioritised, become the improvement programme. Our guide to COBIT 2019 implementation covers the seven phases.
Frequently asked questions
What are the COBIT capability levels?
A six-level scale, 0 to 5, on which COBIT 2019 rates each process: 0 incomplete, 1 initial, 2 managed, 3 defined, 4 quantitative, 5 optimizing. Each objective’s activities are tagged with a level, and a process achieves a level when the activities tagged for it are fully or largely performed.
What is the difference between capability and maturity in COBIT?
Capability is rated per process; maturity is rated per focus area by aggregating the capability of the objectives it contains. The design sets capability targets; boards tend to ask for maturity statements.
Should every process be at level 5?
No. Level 5 means measured, continuously improved and optimising, which is rarely worth the cost. Targets come from the design factors and typically range from 1 to 4 across the objectives in scope, with 3 as the usual level for prioritised objectives.
How is a level scored?
Against the activities tagged for that level, on a four-point achievement scale: fully (over 85%), largely (50–85%), partially (15–50%), not achieved (under 15%). A level counts as achieved when fully or largely achieved, and the next level is assessed only then.
Is a COBIT capability assessment an audit?
It can be performed as one — the scale and evidence model suit assurance work — but its purpose in the framework is to establish the current state (implementation phase 2) against the target (phase 3) so the improvement programme can be scoped.
Where this leaves you
Use the COBIT capability levels as a per-process scale with cumulative, activity-based criteria: set targets from the design factors so they vary, rate against the tagged activities with evidence, stop at the first level not largely achieved, and report the gap in terms an implementation programme can close. The number matters less than the sentence that follows it.
References
- ISACA — COBIT 2019 Framework: Introduction and Methodology — Chapter 6, performance management in COBIT: capability levels, the rating scale and maturity levels (ISACA publication page).
- ISACA — COBIT Foundation certificate — The exam domains include the performance management model.
More on COBIT
- COBIT capability levels — you are here
- COBIT 2019: the complete guide
- COBIT design factors: all eleven
- COBIT 2019 implementation: the seven phases
- COBIT domains: EDM, APO, BAI, DSS and MEA
- IT governance framework: the three layers
The capability assessment workbook with the activities and level tags per objective, the target capability register, the gap report template and the focus-area maturity roll-up are in the COBIT 2019 IT Governance Toolkit, or start with the free templates.