9.3 Components Supporting Objectives
Key Takeaways
- An objective is achieved by a combination of seven components, not by a process alone.
- The Governance and Management Objectives publication describes each of the 40 objectives through all seven components.
- Capability is assessed primarily on the process component; the other six are still required for the objective to be met in practice.
- Performance management, taught later, can also consider other components — that does not turn culture into a second 0–5 process scale on Foundation day.
- Refuse the equation objective = process = capability level.
Quick Answer: A governance or management objective is achieved by a combination of components, not by a process alone. COBIT 2019 Framework: Governance and Management Objectives describes each of the 40 objectives through all seven components. Capability is assessed primarily on the process component. The other six are still required for the objective to be met in practice. The exam trap is objective = process = capability level.
Section 9.1 walked one objective across seven slots. Section 9.2 showed how structures assign the work. This section names the publication pattern and the scoring rule you will meet again in the performance-management chapter.
Meridian Credit Union’s risk committee reports “APO13 is at level 3.” Ask what they measured. If they mean the security process is Established — a complete, organized activity set using organizational assets — that can be a correct capability statement. If they mean the objective is achieved, you still have to ask about the policy, the CISO’s decision rights, the register, the willingness to escalate, the skills, and the services. Capability answered a process question. The objective is a system question.
The Objectives publication is a seven-component description
The core-model book COBIT 2019 Framework: Governance and Management Objectives is not a process catalog with six appendixes. For each of the 40 objectives it describes the outcome, then fills the same seven component slots you have been carrying since Chapter 6:
| Component described for every objective | What the publication puts in that slot |
|---|---|
| Processes | Purpose, practices, activities, and example metrics |
| Organizational structures | Decision-making entities, including the generic RACI on those practices |
| Principles, policies and frameworks | Related policy topics that translate desired behavior |
| Information | Information flows the practices need and produce |
| Culture, ethics and behavior | Desired behaviors that make the other slots operate |
| People, skills and competencies | Skill topics the work requires |
| Services, infrastructure and applications | Services that host the work |
That layout is why “we implemented the process” is never a complete answer for an objective. ISACA already printed the other six sections. Skipping them is not a tailoring decision. It is an incomplete reading of the core model.
Generic descriptions in that book apply to any enterprise. Variants — Chapter 6 — change how a small credit union or a DevOps shop fills a slot. They do not delete slots. Meridian can combine roles. It cannot claim APO13 is done because a process PDF exists.
The same page pattern holds for DSS02, EDM03, BAI06, or any other official title. Governance objectives and management objectives use the same seven-component card. EDM does not get a lighter card because the board is the audience. DSS does not get a process-only card because the work is operational. End-to-end coverage and holistic approach meet here: every objective, every function, seven slots.
Capability is process-primary; the objective is still a system
COBIT 2019 performance management uses a CMMI-inspired 0–5 capability scheme on processes:
- 0 Incomplete — lacks basic capability
- 1 Initial / intuitive — incomplete activity set; more or less achieves purpose
- 2 Performed — basic yet complete activity set
- 3 Established — organized with organizational assets; well defined
- 4 Predictable — quantitatively measured
- 5 Optimizing — measured in order to improve
Learn the scheme; the dedicated performance chapter will drill the boundaries. The integration point is this: capability is assessed primarily on the process component. That is why an assessor can say “the APO13 process is Established” without having scored culture, information, or skills on the same 0–5 scale.
The other components are still required for the objective to be met in practice. A level-3 process with no skilled people, no usable information, and a culture that punishes escalation has not delivered Managed Security. It has delivered a documented process. Those are different claims.
Later, performance management can also consider other components — for example, looking at whether information quality, skills, or culture are adequate to sustain the process rating. Preview that idea; do not invent a second official 0–5 scale for culture on Foundation day. The exam still wants you to know capability’s primary home is the process, and that the objective is bigger than that home.
Maturity, when it appears, attaches to a focus area (a collection of objectives and components), not to a single process and not to “the enterprise’s COBIT score.” Do not use maturity as a synonym for capability, and do not use either word as a synonym for “objective achieved.”
The equation the exam wants you to refuse
Write this and then cross it out:
objective = process = capability level
All three identities are false.
- An objective is an outcome described with seven components.
- A process is one of those seven components.
- A capability level is a process-performance rating.
Meridian can have a process at 3 and an objective that is not met. It can also have energetic culture and still have an Incomplete process if the activity set does not exist. Filling six slots does not invent a capability rating. Scoring the process does not fill six slots.
This is the same holistic idea you met in Chapter 4, now in the vocabulary of the 30% components domain and the 23% objectives domain. Principles said different types must work together. This section says the published objective is the place those types are specified, and capability is a narrower instrument.
Keep a reject list for nearby official words that distractors will swap in:
- A design factor (risk profile, threat landscape, enterprise size) may change which objectives you prioritize and how you variant a component. It does not collapse seven slots into a process score.
- A focus area (cybersecurity, SME, DevOps) is a collection you might assess for maturity. It is not a replacement title for APO13 and not a capability number.
- A domain (EDM, APO, BAI, DSS, MEA) groups objectives. It is not a component and not a capability level.
- Enablers is the COBIT 5 name for components. It does not restore a process-only reading of an objective.
How to read a Foundation stem
When a stem says an enterprise “achieved DSS02 at level 4,” separate the claims:
- Process claim: the request-and-incident process is being scored, probably Predictable if the number is 4.
- Objective claim: Managed Service Requests and Incidents as an outcome — still needs structures, policy, information, culture, skills, and services.
- Capability claim: a 0–5 process rating, not a proof that MEA, the board, or a focus area is mature.
Prefer answers that (1) send you to the Objectives publication’s seven-component description, (2) keep capability on the process, (3) still require the other components in practice, and (4) refuse to treat a number as the objective.
You now have the integration picture for this 30% domain: seven components, RACI on structures, and objectives that are larger than any one process score. The next domain — goals cascade and the 40-objective core model — will hang enterprise goals on that picture. Do not walk into it thinking a capability number is the destination.
How does COBIT 2019 describe each governance and management objective?
Which statement correctly separates an objective, a process, and a capability level?