6.3 Focus Areas

Quick Answer: A focus area describes a governance topic, domain, or issue that can be addressed by a collection of objectives and components. ISACA has published examples such as SME, cybersecurity, DevOps, information security, and I&T risk. Focus areas can be assessed for maturity (the collection); individual processes are assessed for capability. New focus areas can appear because the framework is open and flexible. A focus area is not a ninth Foundation exam domain and not a replacement for EDM/APO/BAI/DSS/MEA.

You now have seven components (6.1) and the generic-versus-variant cut (6.2). Focus areas are how COBIT 2019 packages a topic so those ideas can be applied to SME governance, cyber, DevOps, information security, or I&T risk without inventing a second framework. Focus areas were introduced in 2019; they are not a COBIT 5 leftover. They also sit in the product family as optional overlays — Chapter 2 already warned you they do not add Foundation exam domains. This section is the definition, the published examples, the maturity-versus-capability distinction, and the two traps that cost points in the 30% domain.

Definition worth memorizing

ISACA's wording is close to what the exam expects: a focus area describes a certain governance topic, domain, or issue that can be addressed by a collection of objectives and their components.

Unpack the three pieces:

• Topic, domain, or issue — not "a new COBIT" and not "a new exam domain." A slice of EGIT: how a small enterprise governs, how DevOps is governed, how cyber or I&T risk is governed.
• Collection of objectives — selected and prioritized from the 40-objective core model, often with guidance on which objectives matter most for that issue.
• And their components — including the variant components from 6.2.

A focus area is therefore a lens and a package, not a replacement library. The 40 objectives remain. The five domains remain. The seven components remain. The focus area tells you which objectives to emphasize and how the components should look for that issue.

Published examples (know the list)

ISACA has published or announced focus-area guidance including the set below. You do not need unpublished working titles. You do need to recognize these names as focus areas, not as components, not as design factors, and not as Foundation domains.

The list is open-ended. Privacy, digital transformation, or a future industry slice can become a focus area without a new COBIT version. That is the open and flexible governance-framework principle at work. The core model stays stable; topical packages can be added, updated, or retired without rewriting the 40 objectives.

Exam implication: if a stem describes a new digital-ethics or AI-governance package built from existing objectives and variant components, the COBIT-shaped name is a focus area, not a new domain, not an eighth component, and not a new principle.

Maturity versus capability

This is a high-value 2019 distinction, and it lives here because it explains what a focus area is:

• Capability is scored on individual processes, using the CMMI-based scheme of levels 0–5. The question is "How well is this process performed?"
• Maturity can be associated with a focus area, because a focus area is a collection of objectives and supporting components. The question is "How mature is our DevOps governance, our SME governance system, or our information-security focus?"

Do not invert them. Do not say a single process has "maturity 3" in COBIT 2019 language. Do not give a focus area a capability rating as if it were one process. A focus-area maturity view uses the capability of its constituent processes plus the other components — structures, policies, information, culture, people, and services.

Performance Management is only 4% of the exam, but this vocabulary is planted in the components domain. A stem that offers "the DevOps process is at maturity 4" is mixing the words. DevOps is a focus area (a collection). The processes inside it have capability. The collection can be discussed as maturity.

Open and flexible — new focus areas are allowed

One of the three governance framework principles is that the framework should be open and flexible. That principle is why focus areas exist as an extension mechanism. You already met the product-family version of this idea: optional focus-area publications sit beside the four core books. Here the exam question is conceptual, not bibliographic. COBIT can absorb a new issue by publishing a focus area that reuses the core model. It does not need a COBIT 2027 and it does not need a ninth Foundation domain.

That openness is also why you should not treat today's published list as frozen. SME, cybersecurity, DevOps, information security, and I&T risk are the examples to recognize. The category is what you must defend on a novel stem.

What a focus area is not

Hard rejects — memorize them as a checklist:

1. Not a ninth Foundation exam domain. The certificate has eight official domains. Governance System and Components is 30%. There is no "DevOps domain" and no "SME domain" on the sitting.
2. Not a replacement for EDM / APO / BAI / DSS / MEA. Those five domains organize the 40 objectives. A focus area selects and varies across them. A DevOps focus still needs EDM direction, APO planning, BAI change, DSS operations, and MEA monitoring.
3. Not a replacement for the 40-objective core model.
4. Not a component. Components are the seven building blocks. A focus area uses components, often as variants.
5. Not a design factor. Design factors are enterprise inputs (size, threat landscape, sourcing). A focus area is a topical package. Design factors may lead you to choose a focus area.
6. Not a COBIT 5 leftover. Focus areas are a 2019 introduction, alongside design factors and the design workflow.

Scenario: Apex Municipal Utility

Apex runs a generation-and-distribution utility with about 200 staff and a growing OT estate. Leadership wants "COBIT for OT cybersecurity and for a workforce this size." A vendor offers to install "the cybersecurity domain of COBIT" and skip APO and BAI because "those are for IT shops."

That offer fails this section on two counts. Cybersecurity is a focus area, not a Foundation domain and not a substitute for the five objective domains. Skipping APO and BAI would delete planning, risk, security management, and change — exactly the work an OT cyber program still needs.

Apex's COBIT-shaped move:

• keep the core model and the five domains,
• apply cybersecurity and size-driven SME focus areas as overlays,
• use variant components for OT monitoring services, combined roles, and cyber-policy variants,
• still have EDM for board direction, APO for risk and security planning, BAI for change to controllers, DSS for operations, and MEA for monitoring and assurance.

The focus areas did not become a ninth domain. They did not delete BAI. They told Apex which objectives to emphasize and how the seven components should look in a small, cyber-heavy OT environment.

How this chapter fits the 30% domain

This chapter was the map, not the deep dive:

• 6.1 — the seven components, purpose one-liners, POP-I-CPS, and the enabler rename
• 6.2 — generic versus variant, driven by design factors and focus areas
• 6.3 — focus areas as collections, with maturity on the collection and capability on the process

Chapters 7 through 9 teach processes, structures, policies, information, culture, people, services, then how they integrate with RACI and objectives. Do not try to memorize practice lists or role tables yet. Recite the map. On exam day, if a stem offers a ninth domain, a replacement for EDM/APO/BAI/DSS/MEA, or "enablers" as the 2019 default, you are looking at a trap this chapter was built to catch.

How this shows up on the exam

Prefer answers that define a focus area as a topic addressed by a collection of objectives and components, name the published examples, assign maturity to the collection and capability to the process, credit open and flexible for new focus areas, and refuse "ninth domain" or "replaces EDM/APO/BAI/DSS/MEA." A stem that names DevOps, SME, or cybersecurity and asks what kind of COBIT object it is should resolve to focus area, then stop — do not promote it to a domain, a component, or a rival core model.