Study guide
9.3 Components Supporting Objectives
ISACA COBIT 2019 Foundation Certificate Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Certificate Rules, Retakes, and How to Study
2 Chapter 2: Framework Introduction
2.1 Purpose of COBIT and EGIT 2.2 I&T Versus the IT Function 2.3 COBIT 2019 Product Family 2.4 Stakeholders, Audience, and Benefits
3 Chapter 3: Framework Positioning
3.1 Umbrella Framework and Related Standards 3.2 Evolution from COBIT 5 to COBIT 2019
4 Chapter 4: Governance System Principles I
4.1 Provide Stakeholder Value 4.2 Holistic Approach 4.3 Dynamic Governance System
5 Chapter 5: Governance System Principles II and Framework Principles
5.1 Governance Distinct from Management 5.2 Tailored to Enterprise Needs 5.3 End-to-End Coverage 5.4 Three Governance Framework Principles
6 Chapter 6: Governance System Components Overview
6.1 Seven Governance System Components 6.2 Generic Versus Variant Components 6.3 Focus Areas
7 Chapter 7: Process and Structure Components
7.1 Processes Component 7.2 Practices, Activities, and Metrics 7.3 Organizational Structures 7.4 Principles, Policies, and Frameworks
8 Chapter 8: Information and People Components
8.1 Information Component 8.2 Culture, Ethics, and Behavior 8.3 People, Skills, and Competencies 8.4 Services, Infrastructure, and Applications
9 Chapter 9: Integrating Governance System Components
9.1 How Components Work Together 9.2 RACI Charts and Key Roles 9.3 Components Supporting Objectives
10 Chapter 10: The Goals Cascade
10.1 The Goals Cascade 10.2 Enterprise Goals and Alignment Goals
11 Chapter 11: Core Model and EDM Governance Objectives
11.1 The 40-Objective Core Model 11.2 EDM Governance Objectives 11.3 Governance Versus Management Objectives
12 Chapter 12: APO Align, Plan, and Organize
12.1 APO Strategy, Architecture, and Innovation 12.2 APO Portfolio, Resources, and Relationships 12.3 APO Risk, Security, Data, and Quality
13 Chapter 13: BAI, DSS, and MEA Management Objectives
13.1 BAI Build, Acquire, and Implement 13.2 DSS Deliver, Service, and Support 13.3 MEA Monitor, Evaluate, and Assess
14 Chapter 14: Performance Management
14.1 Performance Management Principles 14.2 Capability Levels 0–5 and Maturity
15 Chapter 15: Designing a Tailored Governance System
15.1 Why Tailor: Design Factors 15.2 The Eleven Design Factors 15.3 Design Workflow and Toolkit
16 Chapter 16: Business Case
16.1 Business Case for EGIT 16.2 Benefits, Costs, Risk, and Tracking
17 Chapter 17: Implementation Lifecycle
17.1 Implementation Lifecycle Overview 17.2 Seven Implementation Phases 17.3 Roles, Pain Points, and Challenges 17.4 Design Guide and Implementation Guide Together
9.3 Components Supporting Objectives
Key Takeaways Explain This Topic AI
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.
Last updated: August 2026
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.