7.1 Processes Component
Key Takeaways
- 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.”
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.
In COBIT 2019, what is a process?
A candidate describes COBIT 2019 as “just 40 processes.” Why is that wrong on the Foundation exam?
Where does COBIT 2019 primarily measure capability?