Study guide
7.1 Processes Component
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
7.1 Processes Component
Key Takeaways Explain This Topic AI
A COBIT 2019 process is a set of practices and activities that achieve a governance or management objective and produce outputs that support goals.
Each of the 40 objectives has a related process that shares the same ID (EDM03 the objective, EDM03 the process) — that pairing is not proof that COBIT equals 40 processes.
Process is only one of seven components; the objective is still described with structures, policies, information, culture, people, and services.
Process guidance includes purpose, process goals, inputs, and outputs; an output is a work product, not a metric and not a capability score.
Capability is primarily measured on the process component with a CMMI-inspired 0–5 scale; the exam trap is “COBIT is just 40 processes.”
Last updated: August 2026
Quick Answer: A COBIT 2019 process is a set of practices and activities that achieve a governance or management objective and produce outputs that support goals. Each of the 40 objectives has a related process that shares the objective’s ID. Process is only one of seven components — it is not the whole objective. Capability is scored primarily on the process component. The exam trap is treating COBIT as “just 40 processes.”
Governance System and Components is 30% of the COBIT 2019 Foundation exam — roughly 23 of 75 items. Chapter 6 mapped all seven components. This chapter starts the deep dive with the component candidates already think they know: processes . Sections 7.3 and 7.4 then add organizational structures and principles, policies and frameworks . The remaining four components are the next chapter.
A process is organized work, not the objective
A governance or management objective is an outcome . EDM03 Ensured Risk Optimization is the result that I&T-related risk stays inside the enterprise’s appetite. APO12 Managed Risk is the result that management continually identifies, assesses, and treats that risk. Neither title is a binder, a ticket queue, or a GRC tool.
The process is the organized set of practices and activities that help produce that outcome and that emit outputs other people can use — a directed appetite statement, a maintained risk profile, a treated-risk log. COBIT 2019 therefore publishes a related process for each of the 40 objectives , using the same ID . You will see process EDM03 next to objective EDM03, process APO12 next to objective APO12, and the same pattern through EDM, APO, BAI, DSS, and MEA.
That one-to-one pairing is useful and dangerous. It is useful because Foundation items name objectives and processes with the same codes. It is dangerous because candidates collapse the pairing and say “COBIT is 40 processes.” The objective is still described with all seven components . The process is the work-and-output slot. The same objective also needs a body that can decide, a policy that states expected behavior, information that shows whether risk is moving, a culture that will escalate bad news, people who can analyze risk, and services that host the registers.
Picture a hospital’s “ensure patient safety” outcome. The clinical pathway (process) is necessary. It is not sufficient if no committee can stop an unsafe protocol, no policy forbids workarounds, no dashboard shows infection rates, no culture reports near-misses, no trained staff remain on nights, and no system records incidents. COBIT’s process component is the clinical pathway, not the entire safety system.
What the process component actually contains
ISACA’s core-model pages for each objective include a process description and a purpose statement — the exam-ready answer to “what is this process for?” They also include process goals : the nearer-term results the process should produce so that alignment goals and, upstream, enterprise goals stay on track. The goals cascade is a later chapter. Here, remember only that a process has its own goals; those goals are not the same thing as the 40 objectives, and they are not the same thing as a metric.
The process also has inputs and outputs . An input is a work product this process consumes — often an output of another process. An output is a work product this process produces for other processes, structures, or stakeholders. EDM03 consumes management’s risk analyses and produces directed risk appetite and monitoring conclusions. APO12 consumes that direction and produces a maintained risk profile and a risk-action portfolio. The arrows between processes are those work products, not org-chart reporting lines.
Foundation items will not ask you to recite every input for every process. They will ask whether you know that processes exchange outputs , that an output is not a metric, and that the process is still only one component. If a stem says “the output of APO12 is a capability score of 3,” that stem has mixed units: capability is a performance rating on the process, not a work product the next process files.
- Process-component piece What it is What it is not
- Process Organized practices and activities for one objective The objective itself; the whole governance system
- Process goals Nearer results the process should achieve Enterprise goals; example metrics
- Inputs Work products this process consumes Skills, culture, or a committee charter
- Outputs Work products this process produces Capability scores; design factors
- Related process ID Same code as the objective (EDM03, APO12) Proof that COBIT equals 40 processes
Keep that table closed-book. If an item asks what a process produces, answer outputs that support goals . If it asks what EDM03 “is,” read the stem: outcome language means the objective ; practices-and-activities language means the process . Same code, two exam objects.
Capability is scored on the process first
COBIT 2019 performance management measures capability primarily on the process component, using a CMMI-inspired 0–5 scale from incomplete through optimizing. Chapter 14 teaches the six levels. The Foundation fact you need now is narrower: when a stem asks where capability is scored, the default answer is the process , not the committee, not the policy binder, and not the culture survey.
That is why the next section tags activities to capability levels . A process that is merely performed does some of the work. A process that is established uses a defined, organized way of working. Higher capability is not a new objective and not an eighth component. It is a more complete, organized, and measured version of the same process.
Do not confuse capability (one process) with maturity (a collection, often a focus area ). Chapter 6 already drew that line. Do not confuse a capability rating with a process output. The rating tells you how well the process runs. The output is what the next process picks up.
Exam trap: “COBIT is just 40 processes”
This trap has three faces.
First, counting . Yes, there are 40 related processes. Counting to 40 does not make processes the whole framework. The framework also has seven components, six system principles, three framework principles, a goals cascade, design factors, and focus areas.
Second, equivalence . Saying “EDM03 is a process” on an item that asked for a governance objective is a miss. EDM03 is the objective and it has a related process. The official title Ensured Risk Optimization names the outcome.
Third, history . People who learned COBIT 5 as “37 processes” often update the number to 40 and stop. COBIT 2019 kept processes and renamed enablers to components . The process slot is still one of seven.
If a stem says the enterprise documented process APO12 beautifully and risk still surprises the board, look at the other six components before you conclude the process ID is wrong. A complete process narrative with no risk committee, no appetite policy, and no skilled analysts is how a “perfect” COBIT process still fails in production.